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 <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
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
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
