Internet DRAFT - draft-schmertmann-dice-ccm-psk-pfs

draft-schmertmann-dice-ccm-psk-pfs







Network Working Group                                     L. Schmertmann
Internet-Draft                                           C. Bormann, Ed.
Intended status: Informational                   Universitaet Bremen TZI
Expires: February 16, 2015                               August 15, 2014


          ECDHE-PSK AES-CCM Cipher Suites with Forward Secrecy
                   for Transport Layer Security (TLS)
                 draft-schmertmann-dice-ccm-psk-pfs-01

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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any




Schmertmann & Bormann   Expires February 16, 2015               [Page 1]

Internet-Draft         TLS_ECDHE_PSK_WITH_AES_CCM            August 2014


   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on February 16, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  AES-CCM Cipher Suites with Forward Secrecy  . . . . . . . . .   3
   3.  Option: Replacing the SHA-256 PRF with a CMAC-based PRF . . .   3
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Appendix A.  Recommended Curves and Algorithms  . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   [RFC6655] describes the use of Advanced Encryption Standard (AES)
   [AES] in Counter with CBC-MAC Mode (CCM) [CCM] in several TLS cipher
   suites.  AES-CCM provides both authentication and confidentiality and
   uses as its only primitive the AES encrypt operation (the AES decrypt
   operation is not needed).  This makes it amenable to compact
   implementations, which is advantageous in constrained environments.
   For instance, the use of AES-CCM has been specified for IPsec
   Encapsulating Security Payload (ESP) [RFC4309] and 802.15.4 wireless
   networks [IEEE802154].





Schmertmann & Bormann   Expires February 16, 2015               [Page 2]

Internet-Draft         TLS_ECDHE_PSK_WITH_AES_CCM            August 2014


   One of the cipher suites defined in RFC 6655,
   TLS_PSK_WITH_AES_128_CCM_8, has been made one of the preferred cipher
   suites for use with DTLS in CoAP, [RFC7252].

   The cipher suites defined in RFC 6655 do not provide forward secrecy
   (see [RFC4949] for a definition).

   The cipher suites defined in this document use Ephemeral Elliptic
   Curve Diffie-Hellman (ECDHE) as their key establishment mechanism;
   these cipher suites can be used with DTLS [RFC6347].

   Similar to the way [RFC5489] defines ECDHE_PSK cipher suites for RC4,
   3DES, and AES, the present document defines equivalents of the cipher
   suites defined in RFC 6655 (Table 1).

     +----------------------------+----------------------------------+
     | RFC 6655                   | Forward Secrecy (new)            |
     +----------------------------+----------------------------------+
     | TLS_PSK_WITH_AES_128_CCM   | TLS_ECDHE_PSK_WITH_AES_128_CCM   |
     |                            |                                  |
     | TLS_PSK_WITH_AES_128_CCM_8 | TLS_ECDHE_PSK_WITH_AES_128_CCM_8 |
     +----------------------------+----------------------------------+

             Table 1: new ECDHE_PSK ciphersuites using AES-CCM

   These cipher suites are only defined for use with TLS version 1.2 and
   above.  They are DTLS-OK.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  AES-CCM Cipher Suites with Forward Secrecy

   The cipher suites defined in this document operate exactly like the
   equivalent cipher suites defined in [RFC6655], except that the
   ECDHE_PSK Key Exchange Algorithm from [RFC5489] is used for forming
   the premaster secret.

3.  Option: Replacing the SHA-256 PRF with a CMAC-based PRF

   For both the cipher suites defined in RFC 6655 and the ones defined
   in the previous section, the PRF is the TLS PRF [RFC5246] with
   SHA-256 as the hash function.





Schmertmann & Bormann   Expires February 16, 2015               [Page 3]

Internet-Draft         TLS_ECDHE_PSK_WITH_AES_CCM            August 2014


   This means that, besides AES encryption and ECDHE, implementations
   have to provide SHA-256.  The option discussed in this section would,
   if taken, replace the SHA-256-based hash function with an AES-based
   PRF.

   In this section, we propose examining the use of AES-CMAC [RFC4493]
   as the function underlying the TLS PRF, based on the recommendations
   in [NISTKDF].  One way to do this (patterned somewhat after
   [RFC4615], but with a counter that attempts to preserve more of the
   entropy) is shown in Figure 1.

     PRF(secret, label, seed) = P_CMAC(secret, label || seed)

     P_CMAC(secret, seed) = STEP(0, 0, secret, A(1) || seed) ||
                            STEP(0, 1, secret, A(2) || seed) ||
                            STEP(0, 2, secret, A(3) || seed) || ...
     A(0) = seed
     A(i) = STEP(1, i, secret, A(i-1))

     STEP(v, i, secret, seed) = AES-CMAC(K(v, i, secret), seed)

     K(v, i, secret) = AES-CMAC((v || 0^127) + i, secret)
     (note that the + is addition)

                     Figure 1: CMAC-based PRF for TLS

   P_CMAC can be iterated as many times as necessary to produce the
   required quantity of data.

   Defining such an alternative PRF requires security analysis that is
   not provided in the present version of this document.

4.  IANA Considerations

   IANA is requested to assign values for the new ciphersuites defined
   in Table 1 from the "TLS Cipher Suite" registry.

5.  Security Considerations

   The security considerations of [RFC5489] and [RFC6655] apply.

   If the option to define a CMAC-based PRF is chosen, this section will
   need to discuss its security considerations.








Schmertmann & Bormann   Expires February 16, 2015               [Page 4]

Internet-Draft         TLS_ECDHE_PSK_WITH_AES_CCM            August 2014


6.  Acknowledgements

   This document borrows heavily from RFC 6655.

7.  References

7.1.  Normative References

   [AES]      National Institute of Standards and Technology,
              "Specification for the Advanced Encryption Standard
              (AES)", FIPS 197, November 2001.

   [CCM]      National Institute of Standards and Technology,
              "Recommendation for Block Cipher Modes of Operation: The
              CCM Mode for Authentication and Confidentiality", SP
              800-38C, May 2004.

   [NISTKDF]  Chen, L., "Recommendation for Key Derivation Using
              Pseudorandom Functions", NIST Special Publication 800-108,
              n.d..

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
              for Transport Layer Security (TLS)", RFC 4492, May 2006.

   [RFC4493]  Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
              AES-CMAC Algorithm", RFC 4493, June 2006.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC5489]  Badra, M. and I. Hajjeh, "ECDHE_PSK Cipher Suites for
              Transport Layer Security (TLS)", RFC 5489, March 2009.

   [RFC5639]  Lochter, M. and J. Merkle, "Elliptic Curve Cryptography
              (ECC) Brainpool Standard Curves and Curve Generation", RFC
              5639, March 2010.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, January 2012.

   [RFC6655]  McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for
              Transport Layer Security (TLS)", RFC 6655, July 2012.





Schmertmann & Bormann   Expires February 16, 2015               [Page 5]

Internet-Draft         TLS_ECDHE_PSK_WITH_AES_CCM            August 2014


7.2.  Informative References

   [IEEE802154]
              Institute of Electrical and Electronics Engineers,
              "Wireless Personal Area Networks", IEEE Standard
              802.15.4-2006, 2006.

   [RFC4309]  Housley, R., "Using Advanced Encryption Standard (AES) CCM
              Mode with IPsec Encapsulating Security Payload (ESP)", RFC
              4309, December 2005.

   [RFC4615]  Song, J., Poovendran, R., Lee, J., and T. Iwata, "The
              Advanced Encryption Standard-Cipher-based Message
              Authentication Code-Pseudo-Random Function-128 (AES-CMAC-
              PRF-128) Algorithm for the Internet Key Exchange Protocol
              (IKE)", RFC 4615, August 2006.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2", RFC
              4949, August 2007.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252, June 2014.

Appendix A.  Recommended Curves and Algorithms

   This memo does not mandate any particular elliptic curves or
   cryptographic algorithms, for the sake of flexibility.  However,
   since the main motivation for the AES-CCM-ECC cipher suites is their
   suitability for constrained environments, it is valuable to identify
   a particular suitable set of curves and algorithms.

   This appendix identifies a set of elliptic curves and cryptographic
   algorithms that meet the requirements of this note, which are widely
   supported and believed to be secure.

   Where the following recommendations mention a hash function, the hash
   function does not apply if the option to use CMAC as a PRF is chosen.

   The curves and hash algorithms recommended for each cipher suite are:

     An implementation that includes either
     TLS_ECDHE_PSK_WITH_AES_128_CCM or
     TLS_ECDHE_PSK_WITH_AES_128_CCM_8 SHOULD support the secp256r1
     curve and the SHA-256 hash function.

   More information about the secp256r1, secp384r1, and secp521r1 curves
   is available in Appendix A of [RFC4492].




Schmertmann & Bormann   Expires February 16, 2015               [Page 6]

Internet-Draft         TLS_ECDHE_PSK_WITH_AES_CCM            August 2014


   It is not necessary to implement the above curves and hash functions
   in order to conform to this specification.  Other elliptic curves,
   such as the Brainpool curves [RFC5639] for example, meet the criteria
   laid out in this memo.

Authors' Addresses

   Lars Schmertmann
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  D-28359
   Germany

   Email: lars@tzi.de


   Carsten Bormann (editor)
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  D-28359
   Germany

   Phone: +49-421-218-63921
   Email: cabo@tzi.org



























Schmertmann & Bormann   Expires February 16, 2015               [Page 7]