Subject: RE: GSSAPI/AES draft

From: "JK Jaganathan" <[email-masked]>
Date: Wed, 20 Aug 2003 21:12:03 -0700

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Wednesday, August 20, 2003 6:35 AM
> To: JK Jaganathan
> Cc: [email-masked]
> Subject: Re: GSSAPI/AES draft
> 
> In general, this draft looks good.  I wouldn't object if the 
> working group decided to take this draft as the basis for our 
> GSSAPI direction.
> 
> I consider the following issues to be minor, but since I 
> noticed them I thought I would bring them up.
> 
> 
> I'm not convinced the current draft handles block cipher 
> alignment in the general case, but I believe I have personal 
> mail discussing that issue.
> 
> There is inconsistent text on backwards compatibility.  
> Section 3 seems to assert a requirement that the new token 
> formats not be used with older algorithms.  Section 7 seems 
> to allow it but discourages it.
> 
> I think I prefer the approach in section 7.  i would 
> recommend that we require implementations support the new 
> token formats even for old algorithms, so that for example a 
> pure extensions implementation of Kerberos need not implement 
> the old token formats.  I would also be OK with consistently 
> forbidding use of new tokens with old algorithms. 

I think we should forbid the generation of the new token format for
older algorithms (being conservative in what we send) and
recommend that implementations be able to accept the newer tokens
even when the key type specifies an older algorithm(being liberal 
in accepting). If we start sending newer tokens for older algorithms
the interop problems with the older versions just blow my mind. 
Accepting the newer token formats for the older algorithms doesn't
buy us much(assuming everyone implements this correctly) but does 
give us some flexbility in the future - so it is not strictly 
required and I am ok with cutting it. If we pass the buck to the
implementation and say 'use the newer format if you can determine 
that both sides can understand it' it will never really work
across different implementations as each might use its own mechanism. 

If we really want to do away with the older token formats then I think 
we should just define new enc types(for use with the newer tokens)
for the older algorithms.
This way if the enc type is supported then we can be assured the 
corresponding token format is also supported.  
 We will also not be hosing interop with older implementations. 

> 
> Do we want to make this draft stand on its own and define 
> context establishment tokens, or do we want it to simply be 
> an adjunct to RFC 1964?
> 
> --Sam
> 
>

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 20 Aug 2003 21:24:29 -0700

> the interop problems with the older versions just blow my mind. 

Once we have Kerberos extensions off the drawing board it makes sense to
always use the new token formats between peers that both support
extended Kerberos.  That was Sam's point.

To specify this now all we have to do is say that "a sender SHOULD NOT
use the new tokens with old enctypes _unless_ it has prior knowledge of
its peer's ability to handle the new tokens" - with extensions both
peers would know that they both support the new tokens if the they know
that they both support Kerberos extensions, which, in turn, they'll know
from the AP exchange in the context tokens.

> across different implementations as each might use its own mechanism. 

It will work with Kerberos extensions.

> for the older algorithms.

This would just another way to negotiate support for the new token
formats, but we already know that we'll be negotiating support for
Kerberos extensions anyways, so we will have an appropriate method of
mech version negotiation.

(The Kerberos extensions negotiation will happen in the KDC exchanges.
 If a client uses extended KDC exchanges and the target principal
 supports extended Kerberos then the KDC will return an extended ticket,
 which will inform the client that the target principal support extended
 Kebreros [and the new GSS mechanism].)

Nico
--