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

Andrew Deason adeason@sinenomine.net
Thu, 25 Jul 2013 11:38:46 -0500

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
that sees just a DES key should infer that the service only understands
DES, since DES is a bit of a special case?

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?)

Andrew Deason