Subject: [Dtls-iot] ECDHE-PSK AES-CCM Cipher Suites with Forward Secrecy

From: Carsten Bormann <[email-masked]>
Date: Fri, 14 Feb 2014 16:24:41 +0100

Lars and I have written up some work that he did on a cipher suite that is based on the AES-CCM crypto we often have in constrained devices, and on PSK, but does provide forward secrecy.

The main part of the document is pretty straightforward, I think.  In DICE, we should think about whether we need this and whether the choices made here are the right ones.  If we agree, this could then go on to the appropriate places to define a cipher suite.

There is also a more radical proposal in the document: in AES-CCM, SHA-256 is only used in the PRF, and for this kind of application, it would be nice to be able to save those 2 KiB or so.  So we define a CMAC-based PRF as a potential alternative.  Of course, we don’t even play cryptographers on TV, so this part is just a strawman that would need some significant scrutiny.  Again, DICE might be a forum to consider whether this is worth pursuing.

Grüße, Carsten

Begin forwarded message:

> From: [email-masked]
> Subject: I-D Action: draft-schmertmann-dice-ccm-psk-pfs-00.txt
> Date: 14 Feb 2014 16:10:44 +0100
> To: [email-masked]
> Reply-To: [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>        Title           : ECDHE-PSK AES-CCM Cipher Suites with Forward Secrecy for Transport Layer Security (TLS)
>        Authors         : Lars Schmertmann
>                          Carsten Bormann
> 	Filename        : draft-schmertmann-dice-ccm-psk-pfs-00.txt
> 	Pages           : 7
> 	Date            : 2014-02-14
> 
> Abstract:
>   RFC 6655 describes the use of the Advanced Encryption Standard (AES)
>   in the Counter with Cipher Block Chaining - Message Authentication
>   Code (CBC-MAC) Mode (CCM) of operation within Transport Layer
>   Security (TLS) and Datagram TLS (DTLS) to provide confidentiality and
>   data origin authentication.  The AES-CCM algorithm is amenable to
>   compact implementations, making it suitable for constrained
>   environments.  It has been chosen as one of the preferred cipher
>   suites for use with DTLS in the Constrained Application Protocol,
>   CoAP.
> 
>   The present document defines additional cipher suites that provide
>   forward secrecy.  It also discusses an option to replace the Hash-
>   based PRF in RFC 6655 by CMAC, reducing the number of cryptographic
>   primitives required for implementation.  (The intention is that the
>   option is either chosen or not chosen before this document is agreed,
>   not that both options are defined.)
> 
>   This document is initially addressed at the DICE working group in
>   order to build consensus that there is an actual gap to be filled and
>   about the technical parameters of a solution for that gap.  Once this
>   is agreed, the usual path for agreeing a cipher suite will need to be
>   taken.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-schmertmann-dice-ccm-psk-pfs/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-schmertmann-dice-ccm-psk-pfs-00
> 
> 
> 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/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 14 Feb 2014 16:39:12 +0100

On 14 Feb 2014, at 16:24, Carsten Bormann <[email-masked]> wrote:

> In DICE, we should think about whether we need this

(See also http://tools.ietf.org/html/draft-hartke-dice-profile-03#section-10 for some motivation for this.)

Grüße, Carsten

---

From: "FOSSATI, Thomas (Thomas)" <[email-masked]>
Date: Fri, 14 Feb 2014 16:59:30 +0000

Hi Carsten,

On 14/02/2014 15:24, "Carsten Bormann" <[email-masked]> wrote:
>There is also a more radical proposal in the document: in AES-CCM,
>SHA-256 is only used in the PRF, and for this kind of application, it
>would be nice to be able to save those 2 KiB or so.  So we define a
>CMAC-based PRF as a potential alternative.  Of course, we don’t even play
>cryptographers on TV, so this part is just a strawman that would need
>some significant scrutiny.  Again, DICE might be a forum to consider
>whether this is worth pursuing.

an even deeper scrutiny for the “radical” bit in your proposal could come
from [email-masked].

I think it’d be worth dropping an email there as well.

Cheers

---

From: Michael StJohns <[email-masked]>
Date: Sun, 16 Feb 2014 22:57:23 -0500

> There is also a more radical proposal in the document: in AES-CCM, SHA-256 is only used in the PRF, and for this kind of application, it would be nice to be able to save those 2 KiB or so.  So we d…

Cryptographically, there's really no problem with using CMAC as a PRF 
(and in fact there is a definition of a KDF that does exactly that in 
SP800-108 as you note).  The constraining  issue is that CMAC doesn't 
have  a defined compression/expansion function defined for a provided key.

The CMAC key is expected to be the native key length of the underlying 
block cipher (e.g. 128, 192 or 256 bits for AES).   This differs from 
HMAC as HMAC defines a mechanism for taking in any length of key bytes 
and either compressing (by hashing the key bytes) or expanding (by 
padding with zero) to the length of the underlying hash's block size.

Given that the pre-master secret for TLS could notionally be any length 
and the master secret is always 48 bytes in length, we'd need to define 
how to impedance match to the CMAC key length.

Mike

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 17 Feb 2014 09:57:31 +0100

On 17 Feb 2014, at 04:57, Michael StJohns <[email-masked]> wrote:

> Given that the pre-master secret for TLS could notionally be any length and the master secret is always 48 bytes in length, we'd need to define how to impedance match to the CMAC key length.

Yes.  We stole the idea from RFC 4615 (compress the PRF key by MACing it with all-zeroes AES key) and modified it slightly to get more entropy out of the key (use a counter instead of all-zeroes).  RFC 4615 is from 2006, is there more experience with this approach now?

Grüße, Carsten

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Thu, 20 Feb 2014 11:56:35 +0000

Hi Lars, Carsten

Seems like a worthwhile initiative...see comments below

> -----Original Message-----

> From: dtls-iot [mailto:[email-masked]] On Behalf Of Carsten

> Bormann

> Sent: Monday, February 17, 2014 9:58 AM

> To: Michael StJohns

> Cc: [email-masked]

> Subject: Re: [Dtls-iot] ECDHE-PSK AES-CCM Cipher Suites with Forward

> Secrecy

> On 17 Feb 2014, at 04:57, Michael StJohns <[email-masked]<mailto:[email-masked]>>

> wrote:

> > Given that the pre-master secret for TLS could notionally be any length and

> the master secret is always 48 bytes in length, we'd need to define how to

> impedance match to the CMAC key length.

[SK]The pre-master secret seems to be fed as the message to the CMAC, assuming you are using the same format T := AES-CMAC(K,M,len) as in RFC4493. Then the size of the pre-master secret is not an issue and can be any long, message padding is defined in CMAC. The 48 byte master-secret can be generated as in TLS by the right number of iterations and discarding the last bytes from the final iteration. With AES-CMAC there won't be any need for that discarding. However not clear to me why TLS chose for the key expansion already for the master-secret when additional key expansion is done during the Key Calculation phase ( rfc5246 section-6.3).

> Yes.  We stole the idea from RFC 4615 (compress the PRF key by MACing it

> with all-zeroes AES key) and modified it slightly to get more entropy out of

> the key (use a counter instead of all-zeroes).  RFC 4615 is from 2006, is there

> more experience with this approach now?

[SK] There is http://tools.ietf.org/html/rfc5869 with newer recommendation on the KDF, however this is restricted to HMAC. The NIST SP-800-56C http://csrc.nist.gov/publications/nistpubs/800-56C/SP-800-56C.pdf recommendation is based on this RFC and does include CMAC variants. Maybe good to look at those recommendations too.

There is an additional hash used  in finished message (rfc5246 section-7.4.9)

verify_data := PRF(master_secret, finished_label, Hash(handshake_messages)) [0..verify_data_length-1];

Removing SHA-256 would mean changing this part too.

Sandeep

> dtls-iot mailing list

> [email-masked]<mailto:[email-masked]>

> https://www.ietf.org/mailman/listinfo/dtls-iot

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 20 Feb 2014 13:22:23 +0100

> I think it’d be worth dropping an email there as well.

Indeed.  There was a thread already four years ago, starting at:

http://www.ietf.org/mail-archive/web/cfrg/current/msg02692.html

In particular, Hugo Krawczyk wrote:

> As for CMAC, you could use it, in principle, but you would need to be careful about HOW to use it. In particular, how are you going to key the cipher, what happens when you need more bits of output than those coming out of the cipher (e.g. you want a key for AES-256 but the output is only 128 bits), and even  if your application can get all things right, the analytical results for this construction are weaker than for HMAC. For example, the only results we have for block ciphers as extractors assume these ciphers are ideal random permutations (even if you can use salt to key the cipher) while for HMAC, in many usage scenarios you do not need to resort to ideal assumptions.

(That remark is the background for the strawman in the draft.)
In 2009, the thread on CFRG ended a bit inconclusive, partially because it was mixed up with another discussion, but also because it wasn’t quite clear what specifically we were proposing.
So I thought it would be good to come up with a DICE strawman first, based on some consensus what it is that we are trying to achieve.
Then, indeed, we should go to CFRG again if we agree this should be done.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 20 Feb 2014 17:43:14 +0100

On 20 Feb 2014, at 12:56, Kumar, Sandeep <[email-masked]> wrote:

> [SK]The pre-master secret seems to be fed as the message to the CMAC, assuming you are using the same format T := AES-CMAC(K,M,len) as in RFC4493. Then the size of the pre-master secret is not an issue and can be any long, message padding is defined in CMAC. The 48 byte master-secret can be generated as in TLS by the right number of iterations and discarding the last bytes from the final iteration. With AES-CMAC there won’t be any need for that discarding. However not clear to me why TLS chose for the key expansion already for the master-secret when additional key expansion is done during the Key Calculation phase ( rfc5246 section-6.3).

We tried to emulate the TLS 1.2 PRF, but aren’t making use of any profound insights as to its construction.
Since every round of the way we are using CMAC is generating 16 bytes, we’ll need three rounds for the master-secret.

> [SK] There is http://tools.ietf.org/html/rfc5869 with newer recommendation on the KDF, however this is restricted to HMAC. The NIST SP-800-56Chttp://csrc.nist.gov/publications/nistpubs/800-56C/SP-800-56C.pdf recommendation is based on this RFC and does include CMAC variants. Maybe good to look at those recommendations too.

RFC 4615 is essentially using the key extraction procedure defined for CMAC in SP-800-56C.  Both have in common that they are only making use of 128 bits of entropy; there is only a single key extraction step (which in RFC 4615, as recommended in SP-800-56C, is based on a public salt of 0 = 128 bits of all zeroes).  While SP-800-56C does provide for the protocol to generate other salts, it does not provide for parallel key extraction steps of the form our proposal uses to extract more entropy.  This construct is not validated by SP-800-56C.  If we agree that the attempt to extract more entropy is worthwhile, we’ll have to check with CFRG whether this or another extended extraction procedure can be used with CMAC.  But since much of the IoT world is going to 128-bit security only, maybe that’s not necessary in the first place.

(And thanks for pointing out section 7.4.9 of RFC 5246; we actually are using another CMAC here in place of the hash, but the way the key is derived for that may need to be generalized from the way we are doing this in our implementation.)

Grüße, Carsten

---

From: Michael StJohns <[email-masked]>
Date: Thu, 20 Feb 2014 13:42:08 -0500

On 2/20/2014 6:56 AM, Kumar, Sandeep wrote:
> /[SK]The pre-master secret seems to be fed as the message to the CMAC, 
> assuming you are using the same format T := AES-CMAC(K,M,len) as in 
> RFC4493. Then the size of the pre-master secret is not an issue and 
> can be any long, message padding is defined in CMAC./
>
Um... no.  The K in AES-CMAC has to be the length of the underlying AES 
block cipher - either 128, 192, or 256 bits.  RFC4493 is the same as the 
NIST CMAC definition.  So there has to be a way of translating the input 
key of length N into the native key of length 128, 192, or 256.

> /The 48 byte master-secret can be generated as in TLS by the right 
> number of iterations and discarding the last bytes from the final 
> iteration. With AES-CMAC there won't be any need for that discarding. 
> However not clear to me why TLS chose for the key expansion already 
> for the master-secret when additional key expansion is done during the 
> Key Calculation phase ( rfc5246 section-6.3)./
>

As near as I can tell, its for impedance matching.  The pre-master can 
be agreed to (DH/ECDH) or transported (RSA) or pre-shared.  All of those 
can be of varying lengths.  So running everything through a derivation 
function to get 48 bytes of key for later expansion makes some sense.

The other piece of it is that the master secret is used both for key 
expansion and as the "signing" key for the finish message.  That's 
actually one of the bigger problems with the current scheme.  In any 
event, since you don't know where the key bits came from and there's 
guidance that you shouldn't use the output of either DH or ECDH without 
running it through a KDF then it makes sense to do the premaster -> 
master derivation before using it as key bits.

Mike

> //
> *//*
> /[SK] There is http://tools.ietf.org/html/rfc5869 with newer 
> recommendation on the KDF, however this is restricted to HMAC. The 
> NIST SP-800-56C 
> http://csrc.nist.gov/publications/nistpubs/800-56C/SP-800-56C.pdf 
> recommendation is based on this RFC and does include CMAC variants. 
> Maybe good to look at those recommendations too./
>
> //
>
> /There is an additional hash used  in finished message (rfc5246 
> section-7.4.9)/
>
> /verify_data := PRF(master_secret, finished_label, 
> Hash(handshake_messages)) [0..verify_data_length-1];/
>
> /Removing SHA-256 would mean changing this part too./
>

For TLS1.2 this is a lost cause.  Basically, the master secret produces 
both private (the key expansion key data) and public (this finished 
message stuff) data and does it in a way that its impossible to isolate 
the two.

I'm in the process of drafting a replacement for the text that describes 
how the PRF works and that consists of changing how the key hierarchy is 
generated as well as moving the functions that depend on the PRF to a 
more standard basis.  I don't know if they'll be accepted, but the 
current versions have issues with respect to securing them in a hardware 
security module.

For key derivation the KDF function would be based on one of the 
MAC-based KDF constructs in SP800-108 an the hierarchy would change as:

premaster
       -> finishedKey  (MAC key)
       -> masterSecret (master key)
               -> clientEncrypt (encryption key)
               -> serverEncrypt (encryption key)
               -> clientMAC (MAC key)
               -> serverMAC (MAC key)

Both the finishedKey and the masterSecret would be derived off of the 
premaster secret.  The session keys would be derived  from the 
masterSecret as before - but none of the IV stuff (e.g. public data).

For random data derivation, we'd use the same KDF function based on the 
PRF function, but with a key of all '0's to produce a stream of public 
pseudo-random data.

The finished message signature would use the pure underlying MAC 
function - CMAC or HMAC - and truncate that to 12 octets for the 
finished message tag.

No key in the hierarchy would be used to produce both public and private 
data, and the usage of the keys would be strongly typed as either 
master, encryption or mac.  That allows reasonable implementation of 
policy logic in an HSM and prevents the current class of extraction attacks.

> //
> *//*
> *//*
> /Sandeep/
> *//*
> > [email-masked] <mailto:[email-masked]>
>
> ------------------------------------------------------------------------
> The information contained in this message may be confidential and 
> legally protected under applicable law. The message is intended solely 
> for the addressee(s). If you are not the intended recipient, you are 
> hereby notified that any use, forwarding, dissemination, or 
> reproduction of this message is strictly prohibited and may be 
> unlawful. If you are not the intended recipient, please contact the 
> sender by return e-mail and destroy all copies of the original message.

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Thu, 20 Feb 2014 19:52:18 +0000

> From: Carsten Bormann [mailto:[email-masked]]
> Sent: Thursday, February 20, 2014 5:43 PM
>
> > [SK]The pre-master secret seems to be fed as the message to the CMAC,
> RFC4493. Then the size of the pre-master secret is not an issue and can be
> any long, message padding is defined in CMAC. The 48 byte master-secret
> can be generated as in TLS by the right number of iterations and discarding
> the last bytes from the final iteration. With AES-CMAC there won't be any
> need for that discarding. However not clear to me why TLS chose for the key
> expansion already for the master-secret when additional key expansion is
> done during the Key Calculation phase ( rfc5246 section-6.3).
>
> We tried to emulate the TLS 1.2 PRF, but aren't making use of any profound
> insights as to its construction.
> Since every round of the way we are using CMAC is generating 16 bytes, we'll
> need three rounds for the master-secret.
>
> > [SK] There is http://tools.ietf.org/html/rfc5869 with newer
> recommendation on the KDF, however this is restricted to HMAC. The NIST
> SP-800-56Chttp://csrc.nist.gov/publications/nistpubs/800-56C/SP-800-
> 56C.pdf recommendation is based on this RFC and does include CMAC
> variants. Maybe good to look at those recommendations too.
>
> RFC 4615 is essentially using the key extraction procedure defined for CMAC
> in SP-800-56C.  Both have in common that they are only making use of 128
> bits of entropy; there is only a single key extraction step (which in RFC 4615,
> as recommended in SP-800-56C, is based on a public salt of 0 = 128 bits of all
> zeroes).  While SP-800-56C does provide for the protocol to generate other
> salts, it does not provide for parallel key extraction steps of the form our
> proposal uses to extract more entropy.  This construct is not validated by SP-
> 800-56C.  If we agree that the attempt to extract more entropy is
> worthwhile, we'll have to check with CFRG whether this or another
> extended extraction procedure can be used with CMAC.  But since much of
> the IoT world is going to 128-bit security only, maybe that's not necessary in
> the first place.
>
[SK] Indeed SP-800-56C recommends to use AES-CMAC to first extract a 128-bit key
from the pre-master secret  and then perform the expansion as a next step.
TLS does this in an interleaved way to generate the 48 byte master key and your
proposal does visually matches the TLS PRF. However the PRF could also be defined as
the combination of these two steps as in SP-800-56C avoiding the validation question of this
parallel key extraction.

> (And thanks for pointing out section 7.4.9 of RFC 5246; we actually are using
> another CMAC here in place of the hash, but the way the key is derived for
> that may need to be generalized from the way we are doing this in our
> implementation.)

[SK] Ideally this finished message could have been a CMAC with a 128-bit extracted key,
however TLS only has the expanded 48 byte master key.

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Thu, 20 Feb 2014 20:03:19 +0000

From: Michael StJohns [mailto:[email-masked]]
Sent: Thursday, February 20, 2014 7:42 PM

Hi Lars, Carsten

> Cc: [email-masked]<mailto:[email-masked]>

> impedance match to the CMAC key length.

[SK]The pre-master secret seems to be fed as the message to the CMAC, assuming you are using the same format T := AES-CMAC(K,M,len) as in RFC4493. Then the size of the pre-master secret is not an issue and can be any long, message padding is defined in CMAC.
Um... no.  The K in AES-CMAC has to be the length of the underlying AES block cipher - either 128, 192, or 256 bits.  RFC4493 is the same as the NIST CMAC definition.  So there has to be a way of translating the input key of length N into the native key of length 128, 192, or 256.
[SK] True K has to be the AES key length, but the key K used during extraction is all 0 (or the counter here), and the length N pre-master (agreed  (DH/ECDH) or transported (RSA) or pre-shared) is the  message M of AES-CMAC which could be any length. Do not see the impedance mismatch here. This is also what is suggested in SP-800-56C for the extraction stage. During the expansion stage, the key for AES-CMAC is the extracted 128-bit key. The current proposal does something similar in an interleaved parallel way.

The 48 byte master-secret can be generated as in TLS by the right number of iterations and discarding the last bytes from the final iteration. With AES-CMAC there won't be any need for that discarding. However not clear to me why TLS chose for the key expansion already for the master-secret when additional key expansion is done during the Key Calculation phase ( rfc5246 section-6.3).

As near as I can tell, its for impedance matching.  The pre-master can be agreed to (DH/ECDH) or transported (RSA) or pre-shared.  All of those can be of varying lengths.  So running everything through a derivation function to get 48 bytes of key for later expansion makes some sense.

The other piece of it is that the master secret is used both for key expansion and as the "signing" key for the finish message.  That's actually one of the bigger problems with the current scheme.  In any event, since you don't know where the key bits came from and there's guidance that you shouldn't use the output of either DH or ECDH without running it through a KDF then it makes sense to do the premaster -> master derivation before using it as key bits.

Mike

For TLS1.2 this is a lost cause.  Basically, the master secret produces both private (the key expansion key data) and public (this finished message stuff) data and does it in a way that its impossible to isolate the two.

I'm in the process of drafting a replacement for the text that describes how the PRF works and that consists of changing how the key hierarchy is generated as well as moving the functions that depend on the PRF to a more standard basis.  I don't know if they'll be accepted, but the current versions have issues with respect to securing them in a hardware security module.

For key derivation the KDF function would be based on one of the MAC-based KDF constructs in SP800-108 an the hierarchy would change as:

premaster
      -> finishedKey  (MAC key)

Both the finishedKey and the masterSecret would be derived off of the premaster secret.  The session keys would be derived  from the masterSecret as before - but none of the IV stuff (e.g. public data).

For random data derivation, we'd use the same KDF function based on the PRF function, but with a key of all '0's to produce a stream of public pseudo-random data.

The finished message signature would use the pure underlying MAC function - CMAC or HMAC - and truncate that to 12 octets for the finished message tag.

No key in the hierarchy would be used to produce both public and private data, and the usage of the keys would be strongly typed as either master, encryption or mac.  That allows reasonable implementation of policy logic in an HSM and prevents the current class of extraction attacks.

Sandeep