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

[Benjamin Kaduk <[e-mail]>]

Adding curdle@ for discussion of potential content changes to the
draft...

On Wed, Jun 21, 2017 at 11:49:35AM +0200, Martin Rex wrote:
> Benjamin Kaduk wrote:
> > On Mon, Jun 19, 2017 at 06:43:31PM +0200, Martin Rex wrote:
> >> 
> >> I have always been wondering about the following issue about
> >> Microsoft Kerberos and the RC4-enctype:
> > 
> > Just to note explicitly: I am listed in the To: line of this message
> > but am definitely not the right person to answer the questions here.
>  
> 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?

Thanks,

Ben

> The necessity for rekeying as a prerequisite of using new entypes is
> AFAIK caused by salting string2key differently in all Kerberos enctypes
> (except for RC4-HMAC) and storing only the resulting outputs, and this
> seems to apply to most, if not all Kerberos implementations, I believe.
> 
> While many users in "managed" environments have traditionally been
> pestered to change their user passwords on a regular basis, the same
> might not be true for service accounts, which typically have plaintext
> passwords configured in the registry on Windows Servers, or file-based
> keytabs for traditional MIT Kerberos, and may not be subject to the
> same regular re-keying as end user accounts in typical installations.
> 
> 
> -Martin