[OpenAFS] Re: OpenAFS 1.7.26 windows and not changed AFS service principle - OK?

[Andrew Deason]

On Thu, 25 Jul 2013 13:23:54 -0400
Jeffrey Hutzelman <jhutz@cmu.edu> wrote:

> > After thinking about this, it seems like we could make this more
> > robust, if the KDC doesn't do this. The behavior we're desiring is
> > that a KDC just _prefers_ using session key enctypes where it has an
> > associated long-term key, if the client doesn't specify an enctype.
> 
> Huh?  No, the client doesn't specify an enctype; it provides a list of
> the enctypes it supports.

Whatever; "if the client application doesn't specify a specific enctype
and the client machine sends a list of all the enctypes it understands".

> The text in RFC4120 is unfortunately scattered and a bit vague, but
> the intent is that the KDC must select an enctype from the
> client-provided list.  Further, it must select an enctype which is
> supported by the target service.  Both MIT and Heimdal determine this
> based on the list of enctypes stored for that service in the Kerberos
> database.  So, the selected session key must use an enctype that is
> both on the client's list _and_ in the service's list of long-term
> keys.

Okay, but that's not what happens for MIT in this specific case, as you
mention below.

> > if a client specifically requests e.g. a DES session key when the
> > principal only has an AES long term key, we do get the DES session key
> > (unless DES has been disabled kdc-wide or whatever).
> 
> This happens only with an MIT Kerberos KDC, which assumes that
> services support DES-CBC-MD5 even when they have no keys of that type.
> This is a reasonable assumption because implementation of DES-CBC-MD5
> is mandatory.

This answers my question, and indicates that if the client requests e.g.
{des-cbc-crc, aes256-cts}, and the service princ only has a DES key, we
will not get back an AES session key. My understanding after reading
your response is that at the very least, the possibility of getting back
an AES session key in that situation is not a practical concern (whether
or not it would be considered "incorrect").

> However, this thread is about Windows, not MIT or Heimdal.

Yes, well, threads can wander. As far as I can tell, Windows AD doesn't
do anything like this, and only Heimdal is possibly a problem, so
anything further on this will probably go in the Heimdal thread.

-- 
Andrew Deason
adeason@sinenomine.net