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

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

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

Internet-Drafts

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/

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

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

Peck, Michael A
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 [hidden email]" <[hidden email] on behalf of [hidden email]> wrote:

>
>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/
>
>_______________________________________________
>Kitten mailing list
>[hidden email]
>https://www.ietf.org/mailman/listinfo/kitten
_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson
On 12/03/2015 01:32 PM, Peck, Michael A wrote:
> 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.

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

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

Luke Howard
In reply to this post by Peck, Michael A
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 <[hidden email]> wrote:
>
> 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 [hidden email]" <[hidden email] on behalf of [hidden email]> wrote:
>
>>
>> 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/
>>
>> _______________________________________________
>> Kitten mailing list
>> [hidden email]
>> https://www.ietf.org/mailman/listinfo/kitten
> _______________________________________________
> Kitten mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/kitten

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

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

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

Greg Hudson
In reply to this post by Peck, Michael A
On 12/03/2015 01:32 PM, Peck, Michael A wrote:
> 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.)

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

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

Luke Howard
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 <[hidden email]> wrote:
>
> On 12/03/2015 01:32 PM, Peck, Michael A wrote:
>> 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.)
>
> _______________________________________________
> Kitten mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/kitten

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

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

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

Greg Hudson
In reply to this post by Luke Howard
On 12/03/2015 10:07 PM, Luke Howard wrote:
> 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

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.

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

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

Luke Howard

> On 9 Dec 2015, at 2:04 PM, Greg Hudson <[hidden email]> wrote:
>
> On 12/03/2015 10:07 PM, Luke Howard wrote:
>> 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
>
> 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.

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
_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Benjamin Kaduk-2
In reply to this post by Greg Hudson
On Thu, 3 Dec 2015, Greg Hudson wrote:

> On 12/03/2015 01:32 PM, Peck, Michael A wrote:
> > We would appreciate working group feedback on this new finally posted draft.
>
> > 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.

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

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

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

Benjamin Kaduk-2
In reply to this post by Luke Howard
On Wed, 9 Dec 2015, Luke Howard wrote:

>
> Greg – what do you think about default enctype ordering, should it be
> 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
_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten