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

[Douglas E. Engert]

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 <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.
>

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

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444