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

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Benjamin Kaduk-2
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, [hidden email] 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
> [hidden email]
> https://www.ietf.org/mailman/listinfo/curdle

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Altman-2
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:

> 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, [hidden email] 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
>> [hidden email]
>> https://www.ietf.org/mailman/listinfo/curdle
>
> _______________________________________________
> Kitten mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/kitten
>

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Benjamin Kaduk-2
On Fri, Jun 16, 2017 at 09:46:32AM -0400, Jeffrey Altman wrote:
> 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.

Thanks!

-Ben

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Martin Rex-2
In reply to this post by Benjamin Kaduk-2
Benjamin Kaduk wrote:

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


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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Benjamin Kaduk-2
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.

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

Such an assumption is plausible.

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

I don't know.

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

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

>
> Kerberos with RC4 enctypes seemed to always have worked instantly after
> 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.

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

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

-Ben

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Martin Rex-2
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)

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Benjamin Kaduk-2
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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Altman-2
On 6/21/2017 1:45 PM, Benjamin Kaduk wrote:

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


_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Michiko Short
In reply to this post by Martin Rex-2
inline

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

Benjamin Kaduk wrote:

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


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


_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Martin Rex-2
In reply to this post by Benjamin Kaduk-2
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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Benjamin Kaduk-2
Hi Martin,

On Fri, Jun 23, 2017 at 02:03:41PM +0200, Martin Rex wrote:

> Benjamin Kaduk wrote:
> >
> > 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.

Thank you for clarifying your comment into a request.

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

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.

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

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?


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

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

-Ben

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

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

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

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.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

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

On Mon, Jun 26, 2017 at 12:02 PM, Greg Hudson <[hidden email]> wrote:
On 06/25/2017 10:11 PM, Benjamin Kaduk wrote:
>>>   [...] there may be additional logistical considerations
>>>   involved such as provisioning AES keys [...]

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

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.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten



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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Daniel Migault
In reply to this post by Benjamin Kaduk-2
Hi,

Thank you for the discussion. It seems that overall the current draft has a reached consensus. Are we ready to move the draft forward or do we need any additional discussions ? If you think more discussion is needed please let us know as soon as possible. Unless concerns are raised, I am planning to set  the shepherd write up early next week.

Regards,
Daniel

On Sun, Jun 25, 2017 at 10:11 PM, Benjamin Kaduk <[hidden email]> wrote:
Hi Martin,

On Fri, Jun 23, 2017 at 02:03:41PM +0200, Martin Rex wrote:
> Benjamin Kaduk wrote:
> >
> > 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.

Thank you for clarifying your comment into a request.

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

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.

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

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?


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

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

-Ben

_______________________________________________
Curdle mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/curdle


_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Benjamin Kaduk-2
On Thu, Jul 06, 2017 at 12:01:49PM -0400, Daniel Migault wrote:
> Hi,
>
> Thank you for the discussion. It seems that overall the current draft has a
> reached consensus. Are we ready to move the draft forward or do we need any
> additional discussions ? If you think more discussion is needed please let
> us know as soon as possible. Unless concerns are raised, I am planning to
> set  the shepherd write up early next week.

(Intentionally retaining quoted text below.)

I think we're ready to move the draft forward (as-is).

Having reviewed the extra comments, as well as the current text,
I don't think that there is a need to add something along the lines
of what Martin had proposed.  If I was going to add anything, it would
be along the lines of:

  Administrators are additionally expected to be capable of designing rollout      
  plans that minimize disruption, provisioning keys with the new enctypes before    
  enabling new enctypes in configuration.                                          

(at the end of section 5.4).  But it's not clear that this is really adding
value.

-Ben


> On Sun, Jun 25, 2017 at 10:11 PM, Benjamin Kaduk <[hidden email]> wrote:
>
> > Hi Martin,
> >
> > On Fri, Jun 23, 2017 at 02:03:41PM +0200, Martin Rex wrote:
> > > Benjamin Kaduk wrote:
> > > >
> > > > 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.
> >
> > Thank you for clarifying your comment into a request.
> >
> > >
> > > 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.
> >
> > 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.
> >
> > >
> > > 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.
> >
> > 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?
> >
> >
> > > 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.
> >
> > Admins are more likely to read software-provided documentation than
> > protocol specs; this argument seems speculative to me.
> >
> > -Ben
> >
> > _______________________________________________
> > Curdle mailing list
> > [hidden email]
> > https://www.ietf.org/mailman/listinfo/curdle
> >

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten