On Thu, 25 Jul 2013 11:36:52 -0400 (EDT) Benjamin Kaduk <ka...@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 adea...@sinenomine.net _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
