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

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 21 Jun 2017 12:45:58 -0500

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

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 21 Jun 2017 15:38:36 -0400

> Is that something you are asking for?

In my opinion, such text is inappropriate for an RFC.  The deprecation
of the encryption type is a protocol action.  The RFC is not guidance
for system administrators.  Such guidance should come from the protocol
implementations.

As such I believe the addition of text similar to the above is
unnecessary for publication.

Jeffrey Altman

---

From: [email-masked] (Martin Rex)
Date: Fri, 23 Jun 2017 14:03:41 +0200 (CEST)

> 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

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 25 Jun 2017 21:11:35 -0500

Hi Martin,

> Kerberos, yet it is non-obvious to consumers of the technology.

Thank you for clarifying your comment into a request.

> and deprecating old TLS cipher suites does not have a rekeying requirement.

To some extent this is inherent in Kerberos's use of symmetric crypto for
authentication, as opposed to TLS which uses asymmetric crypto for
authentication and switches to symmetric crypto for efficiency for
bulk data transfer.

(Jeffrey Altman wrote:)
% In my opinion, such text is inappropriate for an RFC.  The deprecation
% of the encryption type is a protocol action.  The RFC is not guidance
% for system administrators.  Such guidance should come from the protocol
% implementations.
%
% As such I believe the addition of text similar to the above is
% unnecessary for publication.

> and senior Kerberos implementers.

In general I tend to hew more to Jeffrey's track that protocol specifications
should limit themseles to protocol-level work.  I could see some grounds
for an exception here, though, in that the deployment difficulties are
inherent to any Kerberos deployment that follows best practice of not storing
user passwords (only derived keys).

Given Jeffrey's reasoning, I do not think my above "proposed text"
(to get clarification from Martin) should be used as-is; if we do want
to provide the clarification that Martin wants, I would want to rephrase
things somewhat.  But, it still seems unclear where the WG consensus lies
on the question of including any guidance at all, here.  Can others
please weigh in?

> of stumped users, helpdesks and admins.

Admins are more likely to read software-provided documentation than
protocol specs; this argument seems speculative to me.

-Ben