On 7/25/2013 2:16 PM, Benjamin Kaduk wrote:
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 <[email protected]> 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.
AD has these attributes for an account attributes:
http://support.microsoft.com/kb/305144
The userAccountControl USE_DES_KEY_ONLY
and with AD 2008:
http://msdn.microsoft.com/en-us/library/cc223853.aspx
msDS-SupportedEncrtptionTypes
msktutil can set this using --enctypes n where n is the decimal value of the
msDS-SupportedEncrtptionTypes
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
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
--
Douglas E. Engert <[email protected]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
