[kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-08

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

[kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-08

Benjamin Kaduk-2
This message begins the third Working Group Last Call (WGLC) of "AES
Encryption with HMAC-SHA2 for Kerberos 5"
<draft-ietf-kitten-aes-cts-hmac-sha2-08>.  Previous WGLCs were held for
versions 06 and 02 of this document.  Review during the second WGLC raised
some issues that required changes to the content of the document, so
another WGLC is needed. The WGLC will last two weeks, ending on Wednesay,
January 20th.  The draft is available at:

https://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-08

A diff of the changes since the previous WGLC is available at:

https://tools.ietf.org/rfcdiff?url2=draft-ietf-kitten-aes-cts-hmac-sha2-08.txt&url1=draft-ietf-kitten-aes-cts-hmac-sha2-06.txt

Please review the document and send comments to the Working Group mailing
list [hidden email] or the co-chairs [hidden email] before the
end of the WGLC.  Any and all comments on the document are sought in order
to access the strength of consensus.  Even if you have read and commented
on this or earlier versions of the draft, please feel free to comment
again.  This is particularly important if you found issues with the
previous version.

As a reminder, comments can be anything from "this looks fine" to "this is
a horrible idea"; they can include suggestions for minor editorial
corrections to significant editorial changes.


- Your Kitten Chairs

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

Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-08

Benjamin Kaduk-2
Just a reminder: only one week remains in this WGLC.

-Ben

On Wed, 6 Jan 2016, Benjamin Kaduk wrote:

> This message begins the third Working Group Last Call (WGLC) of "AES
> Encryption with HMAC-SHA2 for Kerberos 5"
> <draft-ietf-kitten-aes-cts-hmac-sha2-08>.  Previous WGLCs were held for
> versions 06 and 02 of this document.  Review during the second WGLC raised
> some issues that required changes to the content of the document, so
> another WGLC is needed. The WGLC will last two weeks, ending on Wednesay,
> January 20th.  The draft is available at:
>
> https://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-08
>
> A diff of the changes since the previous WGLC is available at:
>
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-kitten-aes-cts-hmac-sha2-08.txt&url1=draft-ietf-kitten-aes-cts-hmac-sha2-06.txt
>
> Please review the document and send comments to the Working Group mailing
> list [hidden email] or the co-chairs [hidden email] before the
> end of the WGLC.  Any and all comments on the document are sought in order
> to access the strength of consensus.  Even if you have read and commented
> on this or earlier versions of the draft, please feel free to comment
> again.  This is particularly important if you found issues with the
> previous version.
>
> As a reminder, comments can be anything from "this looks fine" to "this is
> a horrible idea"; they can include suggestions for minor editorial
> corrections to significant editorial changes.
>
>
> - Your Kitten Chairs
>

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

Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-08

Greg Hudson
In reply to this post by Benjamin Kaduk-2
I did another read-through of the draft.  I found some minor issues,
which I hope can be resolved without requiring another WGLC.

* There is no specification of how to read the string-to-key parameter.
 RFC 3962 says, "The parameter string is four octets indicating an
unsigned number in big-endian order," but this draft does not reference
the RFC 3962 string-to-key and just says "iter_count = string-to-key
parameter (default is decimal 32768 if not specified)".  I assume the
intent is to be consistent with RFC 3962.

* Section 5 says "specific key structure: three protocol-format keys: {
Kc, Ke, Ki }".  Kc, Ke, and Ki are not protocol-format keys; Kc and Ki
don't even have the same length for aes256.  I suggest "three derived keys."

* Section 8 says, "The salt and iteration count resist brute force and
dictionary attacks, however, it is still important to choose or generate
strong passphrases."  This is a run-on sentence; the comma preceding
"however" should be a semicolon.

* Section 8.1 says, "The string-to-key function as defined in [RFC3961]
requires the salt to be valid UTF-8 strings."  This sentence should end
with "a valid UTF-8 string."

* Section 8.1 says, "ktutil's add_entry command assumes the default
salt."  That might be too specific; I suggest "Some key table
manipulation programs assume the default salt when adding entries based
on passwords."

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

Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-08

Benjamin Kaduk-2
Thanks for the review, Greg.

On Fri, 15 Jan 2016, Greg Hudson wrote:

> I did another read-through of the draft.  I found some minor issues,
> which I hope can be resolved without requiring another WGLC.

Assuming that the intent is to be consistent with RFC 3962 for the
string-to-key parameter, I expect that these notes can be resolved without
the need for an additional WGLC.

-Ben

> * There is no specification of how to read the string-to-key parameter.
>  RFC 3962 says, "The parameter string is four octets indicating an
> unsigned number in big-endian order," but this draft does not reference
> the RFC 3962 string-to-key and just says "iter_count = string-to-key
> parameter (default is decimal 32768 if not specified)".  I assume the
> intent is to be consistent with RFC 3962.
>
> * Section 5 says "specific key structure: three protocol-format keys: {
> Kc, Ke, Ki }".  Kc, Ke, and Ki are not protocol-format keys; Kc and Ki
> don't even have the same length for aes256.  I suggest "three derived keys."
>
> * Section 8 says, "The salt and iteration count resist brute force and
> dictionary attacks, however, it is still important to choose or generate
> strong passphrases."  This is a run-on sentence; the comma preceding
> "however" should be a semicolon.
>
> * Section 8.1 says, "The string-to-key function as defined in [RFC3961]
> requires the salt to be valid UTF-8 strings."  This sentence should end
> with "a valid UTF-8 string."
>
> * Section 8.1 says, "ktutil's add_entry command assumes the default
> salt."  That might be too specific; I suggest "Some key table
> manipulation programs assume the default salt when adding entries based
> on passwords."
>
>

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

Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-08

Nico Williams
In reply to this post by Greg Hudson
On Fri, Jan 15, 2016 at 12:25:58PM -0500, Greg Hudson wrote:
> I did another read-through of the draft.  I found some minor issues,
> which I hope can be resolved without requiring another WGLC.

I did as well.  I don't have anything substantial to add to your
comments:

> * Section 8 says, "The salt and iteration count resist brute force and
> dictionary attacks, however, it is still important to choose or generate
> strong passphrases."  This is a run-on sentence; the comma preceding
> "however" should be a semicolon.

   The use PBKDF2, a salt, and a large iteration count, adds some
   resistance to off-line dictionary attacks by passive eavesdroppers.
   Salting prevents rainbow table attacks, while large iteration counts
   slow password guess attempts.  Nonetheless, it is important to choose
   strong passphrases, and/or to use other Kerberos extensions that
   protect against off-line dictionary attacks.  For example, FAST
   [RFC6113] with a suitable armor ticket, or a future password-
   authenticated key exchange (PAKE) pre-authentication method.

> * Section 8.1 says, "ktutil's add_entry command assumes the default
> salt."  That might be too specific; I suggest "Some key table
> manipulation programs assume the default salt when adding entries based
> on passwords."

Even the words "key table" are a bit too specific.  The salient point is
that non-interaction with the KDC implies not knowing the salt;
utilities that need a salt but do not or cannot interact with a KDC to
find out what the salt is need a default salt, and that needs to work
else such utilities cannot.

ktutil in particular could have an option to learn the salt, but if it
has to work off-line then it cannot.

Lastly, as to not every random salt being a UTF-8 string, it is possible
to increase the length of the salt to accomodate any NIST guidance as to
entropy content of salts when they are generated.

Nico
--

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

Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-08

Kenneth G Raeburn
In reply to this post by Benjamin Kaduk-2
Aside from the stuff Greg brought up, which all looks pretty straightforward to address, the rest looks good to me.

A couple minor things, which may or may not be worth doing anything about:

Section 8: I think one can argue that the formulation using the fixed IV and random confounder is mathematically identical to using a random IV; it’s just expressed differently, for historical reasons.  This document probably wouldn’t be the place for it, but I wonder if a formal write-up of equivalent (fully compatible) cryptosystems using a more standard approach (random IV, no confounder) and laying out the alternate formulation of all the messages (e.g., what do the checksums cover, and how does the “cipher state” fit in then?) would be a useful way to say, “Yes, see right here, these Kerberos cryptosystems really do conform to these specs; the historical formulation is just weird.”  In fact, perhaps we should have reworked them for RFC 3961.

But I digress… for this draft, what’s there is good, though I wonder if it’s straightforward enough to reassure a reader not sufficiently familiar with cryptography, or if they’ll just see “does not…comply” with NIST requirements.  Granted, most people reading it will probably figure it out, if they care, but our audience isn’t exclusively cryptographers, it’s people wanting to understand and/or implement protocols.

Section 8.1: It’d be easy enough to define an encoding to carry 128 random bits while being compatible with UTF-8; I don’t think it’s required that the 128 random bits be contiguous, is it?  It’s good to note the issue, but this is one with an easy solution.

“Some known issues…” is followed by a list of one protocol-related item.  (I would read “Further… the following issues…” as introducing a second list, of implementation issues, not a continuation of the first list.)  A list-of-one reads awkwardly; I’d suggest perhaps something like:

  … shall be randomly generated.  The string-to-key function…valid UTF-8 strings, so a UTF-8 compatible encoding would be needed to encapsulate the 128+ random bits.  However, using a salt containing a random portion may have…

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

Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-08

Nico Williams
In reply to this post by Nico Williams
On Mon, Jan 18, 2016 at 07:24:16PM -0600, Nico Williams wrote:
> On Fri, Jan 15, 2016 at 12:25:58PM -0500, Greg Hudson wrote:
> > I did another read-through of the draft.  I found some minor issues,
> > which I hope can be resolved without requiring another WGLC.
>
> I did as well.  I don't have anything substantial to add to your
> comments:

One more comment:

 - Perhaps we should REQUIRE that GSS Kerberos mechanism implementations
   implement and use the RFC6542 channel binding hash agility extension
   when using the new enctypes.

   This means we can stop using MD5 in the GSS mechanism when using the
   new enctypes.

This is probably way too late now, and arguably that should be stated in
a separate RFC, but it'd be a trivial one to publish and get to publish
at the same time as the new enctypes.

Nico
--

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

Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-08

Benjamin Kaduk-2
In reply to this post by Benjamin Kaduk-2
Thanks to everyone who reviewed the document for this WGLC.  There were no
major issues raised, so the document will be able to be sent to the IESG
once a new version is produced that fixes the minor issues that were
raised.

-Ben

On Wed, 6 Jan 2016, Benjamin Kaduk wrote:

> This message begins the third Working Group Last Call (WGLC) of "AES
> Encryption with HMAC-SHA2 for Kerberos 5"
> <draft-ietf-kitten-aes-cts-hmac-sha2-08>.  Previous WGLCs were held for
> versions 06 and 02 of this document.  Review during the second WGLC raised
> some issues that required changes to the content of the document, so
> another WGLC is needed. The WGLC will last two weeks, ending on Wednesay,
> January 20th.  The draft is available at:
>
> https://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-08
>
> A diff of the changes since the previous WGLC is available at:
>
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-kitten-aes-cts-hmac-sha2-08.txt&url1=draft-ietf-kitten-aes-cts-hmac-sha2-06.txt
>
> Please review the document and send comments to the Working Group mailing
> list [hidden email] or the co-chairs [hidden email] before the
> end of the WGLC.  Any and all comments on the document are sought in order
> to access the strength of consensus.  Even if you have read and commented
> on this or earlier versions of the draft, please feel free to comment
> again.  This is particularly important if you found issues with the
> previous version.
>
> As a reminder, comments can be anything from "this looks fine" to "this is
> a horrible idea"; they can include suggestions for minor editorial
> corrections to significant editorial changes.
>
>
> - Your Kitten Chairs
>

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

Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-08

Jeffrey Altman-2
On 1/25/2016 9:32 PM, Benjamin Kaduk wrote:
> Thanks to everyone who reviewed the document for this WGLC.  There were no
> major issues raised, so the document will be able to be sent to the IESG
> once a new version is produced that fixes the minor issues that were
> raised.
>
> -Ben

Ben,

Where do we stand on this document?

https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2/
reports the state as being:

  In WG Last Call
  Revised I-D Needed - Issue raised by WGLC

but the revised I-D -09 was published on 26 January 2016.  Greg
confirmed that same day that all of the issues he raised had been addressed.

Heimdal has full implementation ready to be shipped as soon as the IANA
registry assignments are made.

Thank you.

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] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-08

Benjamin Kaduk-2
Hi Jeffrey,

On Sat, 16 Apr 2016, Jeffrey Altman wrote:

> On 1/25/2016 9:32 PM, Benjamin Kaduk wrote:
> > Thanks to everyone who reviewed the document for this WGLC.  There were no
> > major issues raised, so the document will be able to be sent to the IESG
> > once a new version is produced that fixes the minor issues that were
> > raised.
> >
> > -Ben
>
> Ben,
>
> Where do we stand on this document?
>
> https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2/
> reports the state as being:
>
>   In WG Last Call
>   Revised I-D Needed - Issue raised by WGLC

The "Revised I-D Needed" flag is no longer needed, sorry about that.

As mentioned during the IETF 95 session last week, this document is
waiting for the shepherd writeup.

-Ben

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

Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-08

Jeffrey Altman-2
On 4/16/2016 7:29 PM, Benjamin Kaduk wrote:

> Hi Jeffrey,
>
> On Sat, 16 Apr 2016, Jeffrey Altman wrote:
>
>> On 1/25/2016 9:32 PM, Benjamin Kaduk wrote:
>>> Thanks to everyone who reviewed the document for this WGLC.  There were no
>>> major issues raised, so the document will be able to be sent to the IESG
>>> once a new version is produced that fixes the minor issues that were
>>> raised.
>>>
>>> -Ben
>>
>> Ben,
>>
>> Where do we stand on this document?
>>
>> https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2/
>> reports the state as being:
>>
>>   In WG Last Call
>>   Revised I-D Needed - Issue raised by WGLC
>
> The "Revised I-D Needed" flag is no longer needed, sorry about that.
>
> As mentioned during the IETF 95 session last week, this document is
> waiting for the shepherd writeup.
>
> -Ben
Thanks Ben.




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

smime.p7s (5K) Download Attachment