Re: [kitten] [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-03.txt

[[e-mail] (Martin Rex)]

Benjamin Kaduk wrote:
> Adding curdle@ for discussion of potential content changes to the
> draft...
> 
> On Wed, Jun 21, 2017 at 11:49:35AM +0200, Martin Rex wrote:
>>  
>> Partially true, it would be good to get some light shed on that
>> issue from *all* Kerberos implementors (not just Microsoft).
>> 
>> The new paragraph that you quoted as having been added to the I-D
>> currently _only_ talks about support for Kerberos AES enctypes in code.
>> The new text fails to mention the issue of availability of longterm secrets
>> in the Kerberos KDC database that are properly encoded for AES enctypes
>> --as a prerequisite of actually _using_ AES enctypes.
>> 
>> It's not just about availability of sufficiently recent code,
>> but also a necessity for re-keying all accounts in the Kerberos KDC database
>> _after_ sufficiently recend code has been deployed.  And it may not be
>> the deployment of new code on the KDC alone, there may be additonal
>> administrative changes necessary on the KDC to acutally enable use of
>> AES enctypes (e.g. changing the domain functional level in Active Directory)
> 
> 
> It sounds like you are asking for the addition of some text along
> the lines of:
> 
>   Software support is only a bare minimum requirement for deprecating
>   RC4 enctypes; there may be additional logistical considerations
>   involved such as provisioning AES keys for all principals and
>   updating software configuration to enable AES and disable deprecated
>   encryption types.
> 
> Is that something you are asking for?

Yes, thank your.  This sounds good to me.  I consider it even more
helpful than the reference to particular versions of particular
OpenSource Kerberos implementations, because this is a characteristic
that is sort-of implied by how kerberos-enctypes keys are created
(derived by string2key) and probably affect all implementations of
Kerberos, yet it is non-obvious to consumers of the technology.


There is a substantial difference between cipher suites in TLS, where
key length, strength and algorithm for the symmetric crypto is mostly
irrelevant to the (PKI) credentials, and where using new TLS cipher suites
and deprecating old TLS cipher suites does not have a rekeying requirement.


I do believe that it is very appropriate to provide such kind of a
guidance in an RFC, so that it this recommendation for deprecation
becomes more comprehensible and the trade-offs clearer to mere consumers
of the Kerberos technology, readers that aren't Kerberos protocol experts
and senior Kerberos implementers.

When making admins sufficiently aware of predictable interop-problems,
we may actually see more administrative deprecation of weak Kerberos
enctypes than leaving them in the dark, and it helps reducing the amount
of stumped users, helpdesks and admins.


-Martin