Subject: some initial notes from WG meeting

From: Ken Raeburn <[email-masked]>
Date: Tue, 12 Feb 2002 11:21:19 -0500

So, after John's recent email to the group and other stuff, we started
off the interim meeting looking at what items have been added or
discussed over time, in order to then try to get some idea what might
actually be important for kerberos-revisions or other working group
work.  The stuff we've come up with so far is below.

 - RFC1510 compatibility
 - clarifications to RFC 1510
 - internationalization
 - compat w/existing implementations
 - implementation notes
 - ticket extensions
 - authenticated plaintext
 - extensibility by vendors & IETF
 - evolvability by IETF
 - modern crypto
 - protect AS_REQ from weak passwords
 - PFS for KDC exchanges
 - PFS for appl exchanges (e.g., SAFE, PRIV)
 - remove address dependencies
 - minimize implementation cost
 - minimize testing cost
 - enable tying tickets to host/location/whatever
 - make PK & other WG work items possible
 - EDATA is screwed
 - new ticket flags: ANONYMOUS, TRANSITED-POLICY-CHECKED, OK-AS-DELEGATE
 - new KDC options: REQ-ANON, CANONICALIZE, DISABLE-TRANSITED-CHECK
 - cross-realm referrals
 - client name canonicalization
 - gnuftp.raeburn.org type of referral
 - realm authority for transited cross-realm authentication (the
   problem statement itself still needs some clarification)
 - key exchange without authentication
 - migration path for internationalization
 - clarification of principal name types

 + Packet Cable cares about auth plaintext and PK-CROSS
 + IBM cares about migration path for internationalization

If we've overlooked anything, please let us know.

Ken

---

From: Matt Crawford <[email-masked]>
Date: Wed, 13 Feb 2002 12:30:24 -0600

I still think DCE RFC 26.0 is the simplest way to go on this item.

---

From: Martin Rex <[email-masked]>
Date: Wed, 13 Feb 2002 19:52:56 +0100 (MET)

> I still think DCE RFC 26.0 is the simplest way to go on this item.

DCE requires DCE as a prerequisite...

If the scheme was adopted by Kerberos, how would the Kerberos client
implementation know whether a KDC requests the superencryption?

Going through a (cryptographic) failure and requiring a second
network roundtrip is only a second-best solution -- well, for
TGTs this might be a bearable overhead since it really doesn't
happen that often a day (broken Kerberos implementations excepted
-- I'm still puzzled about the repeated ticket acquisition in my KDC logs
 when running with a W2K pro Kerberos in an MIT-KDC realm ...).

-Martin

---

From: Ken Raeburn <[email-masked]>
Date: 13 Feb 2002 13:46:23 -0500

> I still think DCE RFC 26.0 is the simplest way to go on this item.

Yes, John and I were talking about it a few minutes ago.  For cases
where it applies, it looks like an excellent approach.  There are
cases where it doesn't, though.  (Mainly the "Athena public
workstation" model where a machine has no long-term key unknown to
random potential attackers.)  We might be able to adapt it for such
cases though.  We'll probably be talking about it more later on today.

Mostly, though, we're discussing importance of issues for inclusion in
updated Kerberos specs, not specific solutions to each issue.  (Yes,
it's a step or two backwards from where I thought we were before,
which was working out details of specific changes.)

---

From: "Douglas E. Engert" <[email-masked]>
Date: Wed, 13 Feb 2002 12:57:18 -0600

> I still think DCE RFC 26.0 is the simplest way to go on this item.

Thanks, RFC 26.0 did come up in the WG. One problem is is there is no
host key. 

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Martin Rex <[email-masked]>
Date: Wed, 13 Feb 2002 20:30:59 +0100 (MET)

Too much work, not enough sleep ... sorry for the typo:

> If the scheme was adopted by Kerberos, how would the Kerberos client
- implementation know whether a KDC requests the superencryption?
+ implementation know whether a KDC supports the superencryption?