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

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 15 Jun 2017 23:07:25 -0500

Hi everyone,

As far as I know, this version is ready to be sent to the IESG for
approval.

The -03 adds this text (including known typo):

   Fortuntately, modern (i.e., supported) Kerberos implementations
   support a secure alternative to RC4, in the form of AES.  Windows has
   supported AES since 2007-2008 with the release of Windows Vista and
   Server 2008, respectively; MIT Kerberos [MITKRB5] has fully supported
   AES (including the GSSAPI mechanism) since 2004 with the release of
   version 1.3.2; Heimdal [HEIMDAL] has fully supported AES since 2005
   with the release of version 0.7.  Though there may still be issues
   running ten-year-old unsupported software in mixed environments with
   new software, issues of that sort seem unlikely to be unique to
   Kerberos, and the aministrators of such environments are expected to
   be capable of devising workarounds.

It would be good to get independent confirmation of those
dates/release numbers; the windows ones I took from Michiko's email
and the Heimdal one from Chaskiel's mail.  (I did the MIT research
myself, and picked 1.3.2 to include the GSSAPI mechanism instead of
1.3 which had the bare enctype.)

Thanks,

Ben

On Thu, Jun 15, 2017 at 09:01:48PM -0700, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF.
> 
>         Title           : Deprecate 3DES and RC4 in Kerberos
>         Authors         : Benjamin Kaduk
>                           Michiko Short
> 	Filename        : draft-ietf-curdle-des-des-des-die-die-die-03.txt
> 	Pages           : 9
> 	Date            : 2017-06-15
> 
> Abstract:
>    The 3DES and RC4 encryption types are steadily weakening in
>    cryptographic strength, and the deprecation process should be begun
>    for their use in Kerberos.  Accordingly, RFC 4757 is moved to
>    Obsolete status, as none of the encryption types it specifies should
>    be used, and RFC 3961 is updated to note the deprecation of the
>    triple-DES encryption types.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-curdle-des-des-des-die-die-die-03
> https://datatracker.ietf.org/doc/html/draft-ietf-curdle-des-des-des-die-die-die-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-des-des-des-die-die-die-03
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 16 Jun 2017 09:46:32 -0400

I will confirm the Heimdal dates.

AES was added to Heimdal's source tree on Jul 23 13:00:42 2003 and
support for the krb5 AES OIDs were added on Apr 26 21:08:01 2004.  The
0.7 release is the first tagged release to include the AES OIDs.  The
tag was applied on Jun 16 16:23:19 2005.

Jeffrey Altman

On 6/16/2017 12:07 AM, Benjamin Kaduk wrote:
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 17 Jun 2017 00:30:39 -0500

> tag was applied on Jun 16 16:23:19 2005.

Thanks!

-Ben

---

From: [email-masked] (Martin Rex)
Date: Mon, 19 Jun 2017 18:43:31 +0200 (CEST)

> 1.3 which had the bare enctype.)

I have always been wondering about the following issue about
Microsoft Kerberos and the RC4-enctype:

To be able to use AES enctypes with Microsoft Kerberos, not only
the client, the server and the domain controllers must be using
Vista or higher, but I assume that *also* Active Directory must
be running a Domain functional level 2008 or higher (rather than
domain functional level 2003).

Can Active Directory store AES enctype longterm secrets of service accounts
(for 2-token Kerberos authentication) when the domain controllers
are Windows 2008, 2008R2 or maybe even 2012R2, but domain functional
level is still at Windows 2003?

If not, is it documented anywhere that _after_ upgrading a windows
domain to functional level 2008+, and _before_ being able to use
AES enctypes with serice accounts, it will be necessary to
_manually_ _administratively_ set a new password (or the same password)
for each and every service account, otherwise only RC4-enctypes and
NTLM-authentication will work for that service account (unless storing
passwords with reversible encryption has been enabled for a service
account, I assume).

Kerberos with RC4 enctypes seemed to always have worked instantly after
upgrading Windows domains, but AES enctypes seem to have never worked.

Does anyone know about the exact details, and why RC4-enctypes seem
to work so much better in Windows?

(I'm not a real Kerberos user myself, but I've worked on a number of
 support calls, and for some customers, administratively setting a
 new password seemed to fix some of the Kerberos authentication issues,
 and I am mainly guessing at potential issues here).

-Martin

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 20 Jun 2017 22:46:15 -0500

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

> domain functional level 2003).

Such an assumption is plausible.

> level is still at Windows 2003?

I don't know.

> passwords with reversible encryption has been enabled for a service

Such a property is a natural consequence of a design that stores
only the string2key'd keys and not the original passwords.  (I
think I heard vague rumors that very old AD DCs did in fact store
actual user passwords, but cannot substantiate such rumors.)

> upgrading Windows domains, but AES enctypes seem to have never worked.

I suspect that what is going on is that RC4 always existed and is
always supported, but AES was added later and so had backwards
compatibility requirements that involved not breaking existing
deployments, so you had to explicitly opt-in all parties to the
exchange.  It's hard to know for sure when the risk of breaking
things has gone away and it's safe to enable the new feature by
default.

>  and I am mainly guessing at potential issues here).

Your guesses seem reasonable to me, but I'm also just guessing,
myself.

-Ben

---

From: [email-masked] (Martin Rex)
Date: Wed, 21 Jun 2017 11:49:35 +0200 (CEST)

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

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: Benjamin Kaduk <[email-masked]>
Date: Wed, 21 Jun 2017 12:45:58 -0500

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

> 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

---

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: Michiko Short <[email-masked]>
Date: Wed, 21 Jun 2017 20:31:40 +0000

inline

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Monday, June 19, 2017 9:44 AM
To: Benjamin Kaduk <[email-masked]>
Cc: [email-masked]
Subject: Re: [kitten] [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-03.txt

> 1.3 which had the bare enctype.)

I have always been wondering about the following issue about Microsoft Kerberos and the RC4-enctype:
[Michiko Short] Not sure this is only a MS issue. 

To be able to use AES enctypes with Microsoft Kerberos, not only the client, the server and the domain controllers must be using Vista or higher, but I assume that *also* Active Directory must be running a Domain functional level 2008 or higher (rather than domain functional level 2003).
[Michiko Short]  correct. This is why we had a matrix published with the AES announcement since Kerberos uses encryption for multiple things and thus DFL is one of the things that must be understood. I probably should revise that table and add to our docs for clarity, but I believe there have been a couple of blogs in the AskDS and protocol licensee space released since that Vista announcement. 

Can Active Directory store AES enctype longterm secrets of service accounts (for 2-token Kerberos authentication) when the domain controllers are Windows 2008, 2008R2 or maybe even 2012R2, but domain functional level is still at Windows 2003?
[Michiko Short] The problem with mixed modes domains (which I would assume applies to MIT & Heimdal as well) is that the DC can only create the keys it knows. When we shipped the GP to configure etype support we had to fix the DC logic to create all keys it knew vs supported to avoid the problem that when you flip the config on a DC then everything needs to change password. It is also why AES support becomes DFL. You cannot have a key used with the DC which is not understood by one or move DCs. 

If not, is it documented anywhere that _after_ upgrading a windows domain to functional level 2008+, and _before_ being able to use AES enctypes with serice accounts, it will be necessary to _manually_ _administratively_ set a new password (or the same password) for each and every service account, otherwise only RC4-enctypes and NTLM-authentication will work for that service account (unless storing passwords with reversible encryption has been enabled for a service account, I assume).
[Michiko Short] Actually it is more subtle than that. But I agree, when we evangelize RC4 deprecation in AD, we create better documentation. 

Kerberos with RC4 enctypes seemed to always have worked instantly after upgrading Windows domains, but AES enctypes seem to have never worked.
[Michiko Short] RC4 is supported by every version of Windows so it will work as it is the default. AES came later and unfortunately requires a lot of manual work. 

Does anyone know about the exact details, and why RC4-enctypes seem to work so much better in Windows?
[Michiko Short] Every version of Windows supports it and was the default in the design. 

(I'm not a real Kerberos user myself, but I've worked on a number of  support calls, and for some customers, administratively setting a  new password seemed to fix some of the Kerberos authentication issues,  and I am mainly guessing at potential issues here).

-Martin

---

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

---

From: Greg Hudson <[email-masked]>
Date: Mon, 26 Jun 2017 12:02:07 -0400

On 06/25/2017 10:11 PM, Benjamin Kaduk wrote:
>>>   [...] there may be additional logistical considerations
>>>   involved such as provisioning AES keys [...]

> % for system administrators.

Ben wrote:
> Can others please weigh in?

I don't think we need guidance for system administrators in this
document, and we don't appear to have any such guidance in RFC 6649.  I
am okay with including such guidance in an appendix, but I don't believe
it is a requirement for publication.

---

From: Michael Jenkins <[email-masked]>
Date: Mon, 26 Jun 2017 13:37:12 -0400

Hi all,

I would agree that guidance for system administrators need not appear in a
document like this, and I don't see any in RFC 6649.

On the other hand, most of the justification for deprecating both RC4 and
3DES /is/ about system administration. The NTLM discussion is about
deployment upgrade, and the cross-realm discussion is about architecture.
Neither have anything to do with the weakness of the algorithms, and both
are problems that could arise with any transition.

Seems that you should either remove what's not cryptographic or a direct
problem that the algorithm/enc-type causes for the security of the protocol
(not deployment of the protocol) ala RFC 6649, or acknowledge that your
discussion has crossed over into deployment-land and at least put in a
disclaimer that what you've written is merely justification for the
deprecation, and not an assessment that the deprecation can be implemented
with no breakage.

-- 
Mike Jenkins
[email-masked] - if you want me to read it only at my desk
[email-masked] - to read everywhere
443-634-3951