Subject: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-07.txt

From: [email-masked]
Date: Thu, 03 Dec 2015 10:24:16 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF.

        Title           : AES Encryption with HMAC-SHA2 for Kerberos 5
        Authors         : Michael J. Jenkins
                          Michael A. Peck
                          Kelley W. Burgin
	Filename        : draft-ietf-kitten-aes-cts-hmac-sha2-07.txt
	Pages           : 16
	Date            : 2015-12-03

Abstract:
   This document specifies two encryption types and two corresponding
   checksum types for Kerberos 5.  The new types use AES in CTS mode
   (CBC mode with ciphertext stealing) for confidentiality and HMAC with
   a SHA-2 hash for integrity.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-aes-cts-hmac-sha2-07

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/

---

From: "Peck, Michael A" <[email-masked]>
Date: Thu, 3 Dec 2015 18:32:39 +0000

Hi -

We would appreciate working group feedback on this new finally posted draft.
I believe we’ve addressed all of the action items from Ben’s April 17 email (quoted below).

While removing truncation from the PRF output, we also changed (with the goal of simplifying) the PRF computation (end of section 5 / top of page 7).
If the new computation isn’t desired, please let us know and we can change it back.

We re-did the encryption and checksum test vectors to use the Kc, Ke, and Ki values generated by the key derivation test vectors so that all the steps would be shown.
We also added verbosity to the PRF test vectors.

Thanks,
Mike

On 4/17/2015 5:23 PM, Benjamin Kaduk wrote:
>That seems to leave us with the following action items:
>For the document editor:
>* remove truncation from the PRF output and use the natural hash output
>length
>* remove the use of random-to-key() and discussion of constant values from
>section 3
>* add an output length argument to KDF-HMAC-SHA2() and adjust text
>accordingly
>* update test vectors to include base keys and key usage values for all
>test cases
>* reword the text discussing aes256 with 192-bit keys

On 12/3/15, 1:24 PM, "Kitten on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

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

---

From: Greg Hudson <[email-masked]>
Date: Thu, 3 Dec 2015 22:05:02 -0500

> We would appreciate working group feedback on this new finally posted draft.

This revision removes a random-to-key() invocation in section 4, which
defines the PBKDF2 construction for deriving long-term keys from
passphrases.  I don't think that's right.  (If I seem to be reversing
myself, note that the action item was to remove random-to-key() from
section 3, and that part is fine.)

Abstractly, random-to-key() maps a byte string of exactly 128 or 256
bits to a protocol key using the identity function.  KDF-HMAC-SHA2()
outputs a byte string after the change to section 3.

Since PBKDF2() outputs a byte string, we must convert it to a protocol
key with random-to-key() to have the right abstract type as input to
KDF-HMAC-SHA2().  Moreover, , we must apply random-to-key() again to
convert the output of KDF-HMAC-SHA2() to a protocol key.

So, I think we want to preserve the random-to-key() for the assignment
to tkey, and add another one for the assignment to base-key.

None of this is likely to affect implementation correctness, of course,
since random-to-key() is the identity function.

> While removing truncation from the PRF output, we also changed (with the goal of simplifying) the PRF computation (end of section 5 / top of page 7).

I think that's a good change.  The old definition performed two HMACs,
the first with a fixed string and the second with the PRF input.  The
new definition stuffs the PRF input into the first HMAC along with the
fixed parts.

There's some trailing whitespace at the end of some lines in the text;
you may want to check for that.

I was able to verify all of the test vectors using my Python
implementation.  (I didn't check the intermediate values.)  It's in the
the aes-sha2 branch of https://github.com/greghudson/pyk5 ; no promises
of stability.

---

From: Luke Howard <[email-masked]>
Date: Fri, 4 Dec 2015 14:07:37 +1100

Hi Mike,

Thanks for this. I’ve updated the Heimdal implementation with the PRF changes and verified all of the test vectors.

https://github.com/heimdal/heimdal/tree/lukeh/aes-cts-hmac-sha2

Cheers,
Luke

> On 4 Dec 2015, at 5:32 AM, Peck, Michael A <[email-masked]> wrote:
> 
> Hi -
> 

--
www.lukehoward.com
soundcloud.com/lukehoward

---

From: Greg Hudson <[email-masked]>
Date: Fri, 4 Dec 2015 12:22:17 -0500

> We would appreciate working group feedback on this new finally posted draft.

I'm looking at the description of ciphertext state in this draft versus
the description in RFC 3962.  RFC 3962 says:

   The initial vector carried out from one encryption for use in a
   subsequent encryption is the next-to-last block of the encryption
   output; this is the encrypted form of the last plaintext block.  When
   decrypting, the next-to-last block of the supplied ciphertext is
   carried forward as the next initial vector.  If only one ciphertext
   block is available (decrypting one block, or encrypting one block or
   less), then that one block is carried out instead.

The draft says:

      ciphertext = C | H[1..h]
      cipherstate = the last full (128 bit) block of C
      (i.e. the next-to-last block if the last block
      is not a full 128 bits)

I believe the intent was to align the draft with RFC 3962 (in that a
previous version of the draft used a simpler construction involving the
confounder, and it was later changed), but these definitions are not
identical when the last plaintext block is a full 128 bits, unless I'm
missing something.

As an implementor, I would like to reuse the AES enc-provider in MIT
krb5, which consumes and outputs ciphertext state, so I would prefer
that the definitions align.  It looks like Luke's implementation for
Heimdal also reuses the _krb5_evp_encrypt_cts() function, which consumes
and outputs ciphertext state.

(This discussion does not affect the test vectors, which do not use
cipher state.  Cipher state is really only used for the obsolete krb5
rlogin, as far as I know.)

---

From: Luke Howard <[email-masked]>
Date: Sat, 5 Dec 2015 09:52:49 +1100

Thanks for pointing this out Greg – obviously, yes, another vote for RFC3962 alignment from me (also prefer to reuse code).

— Luke

> On 5 Dec 2015, at 4:22 AM, Greg Hudson <[email-masked]> wrote:
>

---

From: Greg Hudson <[email-masked]>
Date: Tue, 8 Dec 2015 22:04:49 -0500

> https://github.com/heimdal/heimdal/tree/lukeh/aes-cts-hmac-sha2

I have an implementation for MIT krb5 at:

https://github.com/greghudson/krb5/tree/aes-sha2

(No guarantee of commit ID stability, and the branch will likely go away
if and when it is merged to the upstream master branch.)  Obviously no
implementation can be production-ready until we have enctype and
checksumtype assignments.  All of the test vectors are verified.

---

From: Luke Howard <[email-masked]>
Date: Wed, 9 Dec 2015 17:09:37 +1100

> On 9 Dec 2015, at 2:04 PM, Greg Hudson <[email-masked]> wrote:
> 

I have verified:

* MIT kinit against Heimdal KDC
* Heimdal gss-client against MIT gss-server

Greg – what do you think about default enctype ordering, should it be preferred over the 3962 enctypes?

— Luke

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 26 Dec 2015 16:43:42 -0500 (EST)

> new definition stuffs the PRF input into the first HMAC along with the

I think I had asked for/suggested this, out of an abundance of caution and
a sense of alignment with some other PRF scheme in the sense of having an
intermediate Kp.  (Maybe in [0]?)

I believe the version in the -08 is fine, though -- me-from-2014 was
probably overcautious.

-Ben

[0] http://www.ietf.org/mail-archive/web/kitten/current/msg04692.html

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 26 Dec 2015 17:05:10 -0500 (EST)

> preferred over the 3962 enctypes?

I'm not Greg, and this topic is out of scope for the document at hand, but
probably merits some discussion.  The immediate benefits of these new
enctypes are somewhat marginal -- use of encrypt-then-mac-with-confounder
instead of encrypt-and-mac-with-confounder is a more well-known secure
construction and a wider security margin due to the larger tag, and it
allows people to check off the box that they don't use SHA-1.  But, the
ciphertexts are larger, and there are potential issues if a service ends
up with a key for the new enctype but without software that can handle it.

For me, that would indicate a pretty gradual adoption scheme -- for a
software distribution like MIT krb5 that has regular releases, ship a
version that supports the new enctype but doesn't use it by default
anywhere, then in the next release start offering it for AS exchanges
(i.e., obtaining tickets that are mostly only going to be sent back to the
KDC and not to random application servers) and generating keys for it but
leave it un-preferred elsewhere, then in the following release consider
increasing its priority more generally.  I'm not sure whether Heimdal
would be able to get away with such a delayed rollout, though.

-Ben