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

[Benjamin Kaduk]

I think jhutz has covered most of the points already, but:

On Thu, 25 Jul 2013, Andrew Deason wrote:

> On Thu, 25 Jul 2013 11:36:52 -0400 (EDT)
> Benjamin Kaduk <kaduk@MIT.EDU> wrote:
>
>> and in the absence of other information, the KDC should not assume
>> that a service supports an enctype for which it has no long-term key.
>
> 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. Is that
> mandated by the Kerberos standards or anything? It seems like if the
> client doesn't specify an enctype, any enctype if possible. After all,
> 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).
>
> I know in draft-kaduk-afs3-rxkad-kdf-03 you/we explicitly say that KDCs
> need to not issue non-DES session keys when we only have a DES long-term
> key, but do they all actually do that? Is the reasoning there that a KDC

As jhutz said, MIT and Heimdal do.  I assume that AD has some mechanism to 
cope with application servers that don't speak AES, though I don't know 
what exactly the mechanism is.

> that sees just a DES key should infer that the service only understands
> DES, since DES is a bit of a special case?

Not a special case, just the standard use of the service principals key 
list as a proxy for what enctypes it supports.  If the list has only one 
element, then only one enctype is supported.

> It seems like we could try to request a DES session key, and if that
> fails due to a refused enctype, try again without specifically
> requesting DES. That's not what we do and not what
> draft-kaduk-afs3-rxkad-kdf-03 recommends, but wouldn't that be more
> likely to work? (Or do KDCs where this is a problem just not exist, and
> so this is pointless to think about?)

Asking for a DES session key first would unnecessarily weaken the session 
key for some clients.  I don't think there are really standard C APIs for 
getting and parsing the contents of an error packet, so it seems like this 
would be quite unpleasant to try and implement, and would also introduce 
delays into normal operation.  I don't think it's worth pursuing this 
route.

-Ben