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

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 6 Jan 2016 00:26:27 -0500 (EST)

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 [email-masked] or the co-chairs [email-masked] 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

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 13 Jan 2016 19:19:48 -0500 (EST)

Just a reminder: only one week remains in this WGLC.

-Ben

---

From: Greg Hudson <[email-masked]>
Date: Fri, 15 Jan 2016 12:25:58 -0500

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 15 Jan 2016 22:56:03 -0500 (EST)

Thanks for the review, Greg.

> 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

---

From: Nico Williams <[email-masked]>
Date: Mon, 18 Jan 2016 19:24:16 -0600

> which I hope can be resolved without requiring another WGLC.

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

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

> manipulation programs assume the default salt when adding entries based

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

---

From: Kenneth G Raeburn <[email-masked]>
Date: Tue, 19 Jan 2016 08:13:16 +0000

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

---

From: Nico Williams <[email-masked]>
Date: Tue, 19 Jan 2016 12:44:01 -0600

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

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 25 Jan 2016 22:32:26 -0500 (EST)

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