doc/protocol/draft-ietf-tls-ecc-new-mac-04.txt

   1
   2
   3
   4 Network Working Group                                        E. Rescorla
   5 Internet-Draft                                                RTFM, Inc.
   6 Intended status:  Informational                        February 12, 2008
   7 Expires:  August 15, 2008
   8
   9
  10 TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter
  11                                   Mode
  12                    draft-ietf-tls-ecc-new-mac-04.txt
  13
  14 Status of this Memo
  15
  16    By submitting this Internet-Draft, each author represents that any
  17    applicable patent or other IPR claims of which he or she is aware
  18    have been or will be disclosed, and any of which he or she becomes
  19    aware will be disclosed, in accordance with Section 6 of BCP 79.
  20
  21    Internet-Drafts are working documents of the Internet Engineering
  22    Task Force (IETF), its areas, and its working groups.  Note that
  23    other groups may also distribute working documents as Internet-
  24    Drafts.
  25
  26    Internet-Drafts are draft documents valid for a maximum of six months
  27    and may be updated, replaced, or obsoleted by other documents at any
  28    time.  It is inappropriate to use Internet-Drafts as reference
  29    material or to cite them other than as "work in progress."
  30
  31    The list of current Internet-Drafts can be accessed at
  32    http://www.ietf.org/ietf/1id-abstracts.txt.
  33
  34    The list of Internet-Draft Shadow Directories can be accessed at
  35    http://www.ietf.org/shadow.html.
  36
  37    This Internet-Draft will expire on August 15, 2008.
  38
  39 Copyright Notice
  40
  41    Copyright (C) The IETF Trust (2008).
  42
  43 Abstract
  44
  45    RFC 4492 describes elliptic curve cipher suites for Transport Layer
  46    Security (TLS).  However, all those cipher suites use SHA-1 as their
  47    MAC algorithm.  This document describes eight new CipherSuites for
  48    TLS/DTLS which specify stronger digest algorithms.  Four use HMAC
  49    with SHA-256 or SHA-384 and four use AES in Galois Counter Mode
  50    (GCM).
  51
  52
  53
  54
  55 Rescorla                 Expires August 15, 2008                [Page 1]
  56 \f
  57 Internet-Draft               TLS ECC New MAC               February 2008
  58
  59
  60 Table of Contents
  61
  62    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
  63      1.1.  Conventions Used In This Document . . . . . . . . . . . . . 3
  64    2.  Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . . 3
  65      2.1.  HMAC-based Cipher Suites  . . . . . . . . . . . . . . . . . 3
  66      2.2.  Galois Counter Mode-based Cipher Suites . . . . . . . . . . 4
  67    3.  TLS Versions  . . . . . . . . . . . . . . . . . . . . . . . . . 5
  68    4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
  69      4.1.  Downgrade Attack  . . . . . . . . . . . . . . . . . . . . . 5
  70      4.2.  Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . 5
  71      4.3.  Counter Reuse with GCM  . . . . . . . . . . . . . . . . . . 6
  72    5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
  73    6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
  74    7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
  75      7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
  76      7.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
  77    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7
  78    Intellectual Property and Copyright Statements  . . . . . . . . . . 8
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111 Rescorla                 Expires August 15, 2008                [Page 2]
 112 \f
 113 Internet-Draft               TLS ECC New MAC               February 2008
 114
 115
 116 1.  Introduction
 117
 118    RFC 4492 [RFC4492] describes Elliptic Curve Cryptography (ECC) cipher
 119    suites for Transport Layer Security (TLS).  However, all of the RFC
 120    4492 suites use HMAC-SHA1 as their MAC algorithm.  Due to recent
 121    analytic work on SHA-1 [Wang05], the IETF is gradually moving away
 122    from SHA-1 and towards stronger hash algorithms.  This document
 123    specifies TLS ECC cipher suites which replace SHA-256 and SHA-384
 124    rather than SHA-1.
 125
 126    TLS 1.2 [I-D.ietf-tls-rfc4346-bis], adds support for authenticated
 127    encryption with additional data (AEAD) cipher modes
 128    [I-D.mcgrew-auth-enc].  This document also specifies a set of ECC
 129    cipher suites using one such mode, Galois Counter Mode (GCM) [GCM].
 130    Another document [I-D.salowey-tls-rsa-aes-gcm], provides support for
 131    GCM with other key establishment methods.
 132
 133 1.1.  Conventions Used In This Document
 134
 135    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 136    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 137    document are to be interpreted as described in [RFC2119].
 138
 139
 140 2.  Cipher Suites
 141
 142    This document defines 8 new cipher suites to be added to TLS.  All
 143    use Elliptic Curve Cryptography for key exchange and digital
 144    signature, as defined in RFC 4492.
 145
 146 2.1.  HMAC-based Cipher Suites
 147
 148    The first four cipher suites use AES [AES] in CBC [CBC] mode with an
 149    HMAC-based MAC:
 150
 151        CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256  = {0xXX,XX};
 152        CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384  = {0xXX,XX};
 153        CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX};
 154        CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX};
 155
 156    These four cipher suites are the same as the corresponding cipher
 157    suites in RFC 4492 (TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
 158    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
 159    TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, and
 160    TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA) except for the hash and PRF
 161    algorithms, which are SHA-256 and SHA-384 [SHS] as follows.
 162
 163
 164
 165
 166
 167 Rescorla                 Expires August 15, 2008                [Page 3]
 168 \f
 169 Internet-Draft               TLS ECC New MAC               February 2008
 170
 171
 172       Cipher Suite                                MAC          PRF
 173       ------------                                ---          ---
 174       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256     HMAC-SHA-256 P_SHA-256
 175       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384     HMAC-SHA-384 P_SHA-384
 176       TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256      HMAC-SHA-256 P_SHA-256
 177       TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384      HMAC-SHA-384 P_SHA-384
 178
 179 2.2.  Galois Counter Mode-based Cipher Suites
 180
 181    The second four cipher suites use the new authenticated encryption
 182    modes defined in TLS 1.2 with AES in Galois Counter Mode (GCM) [GCM]:
 183
 184        CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256  = {0xXX,XX};
 185        CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384  = {0xXX,XX};
 186        CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX};
 187        CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX};
 188
 189    These cipher suites use authenticated encryption with additional data
 190    algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM described in
 191    [I-D.mcgrew-auth-enc].  The "nonce" input to the AEAD algorithm SHALL
 192    be 12 bytes long, and is "partially implicit" (see Section 3.2.1 of
 193    [I-D.mcgrew-auth-enc]).  Part of the nonce is generated as part of
 194    the handshake process and is static for the entire session and part
 195    is carried in each packet.
 196
 197              struct {
 198                 opaque salt[4];
 199                 opaque explicit_nonce_part[8];
 200              } GCMNonce.
 201
 202    The salt value is either the client_write_IV if the client is sending
 203    or the server_write_IV if the server is sending.  These IVs SHALL be
 204    4 bytes long.  Therefore, for all the algorithms defined in this
 205    section, SecurityParameters.fixed_iv_length=4.
 206
 207    The explicit_nonce_part is chosen by the sender and included in the
 208    packet.  Each value of the explicit_nonce_part MUST be distinct from
 209    all other values, for any fixed key.  Failure to meet this uniqueness
 210    requirement can significantly degrade security.  The
 211    explicit_nonce_part is carried in the IV field of the
 212    GenericAEADCipher structure.  Therefore, for all the algorithms
 213    defined in this section, SecurityParameters.record_iv_length=8.
 214
 215    In the case of TLS the counter MAY be the 64-bit sequence number.  In
 216    the case of Datagram TLS [RFC4347] the counter MAY be formed from the
 217    concatenation of the 16-bit epoch with the 48-bit sequence number.
 218
 219    The PRF algorithms SHALL be as follows:
 220
 221
 222
 223 Rescorla                 Expires August 15, 2008                [Page 4]
 224 \f
 225 Internet-Draft               TLS ECC New MAC               February 2008
 226
 227
 228    For TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
 229    TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 it SHALL be P_SHA-256.
 230
 231    For TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA384 and
 232    TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA384 it SHALL be P_SHA-384.
 233
 234
 235 3.  TLS Versions
 236
 237    Because these cipher suites depend on features available only in TLS
 238    1.2 (PRF flexibility and combined authenticated encryption cipher
 239    modes), they MUST NOT be negotiated by older versions of TLS.
 240    Clients MUST NOT offer these cipher suites if they do not offer TLS
 241    1.2 or later.  Servers which select an earlier version of TLS MUST
 242    NOT select one of these cipher suites.  Because TLS has no way for
 243    the client to indicate that it supports TLS 1.2 but not earlier, a
 244    non-compliant server might potentially negotiate TLS 1.1 or earlier
 245    and select one of the cipher suites in this document.  Clients MUST
 246    check the TLS version and generate a fatal "illegal_parameter" alert
 247    if they detect an incorrect version.
 248
 249
 250 4.  Security Considerations
 251
 252    The security considerations in RFC 4346 and RFC 4492 apply to this
 253    document as well.  The remainder of this section describes security
 254    considerations specific to the cipher suites described in this
 255    document.
 256
 257 4.1.  Downgrade Attack
 258
 259    TLS negotiation is only as secure as the weakest cipher suite that is
 260    supported.  For instance, an implementation which supports both 160-
 261    bit and 256-bit elliptic curves can be subject to an active downgrade
 262    attack to the 160-bit security level.  An attacker who can attack
 263    that can then forge the Finished handshake check and successfully
 264    mount a man-in-the-middle attack.
 265
 266 4.2.  Perfect Forward Secrecy
 267
 268    The static ECDH cipher suites specified in this document do not
 269    provide perfect forward secrecy (PFS).  Thus, compromise of a single
 270    static key leads to potential decryption of all traffic protected
 271    using that key.  Implementors of this specification SHOULD provide at
 272    least one ECDHE mode of operation.
 273
 274
 275
 276
 277
 278
 279 Rescorla                 Expires August 15, 2008                [Page 5]
 280 \f
 281 Internet-Draft               TLS ECC New MAC               February 2008
 282
 283
 284 4.3.  Counter Reuse with GCM
 285
 286    AES-GCM is only secure if the counter is never reused.  The IV
 287    construction algorithm above is designed to ensure that this cannot
 288    happen.
 289
 290
 291 5.  IANA Considerations
 292
 293    IANA has assigned the following values for these cipher suites:
 294
 295       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX};
 296       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX};
 297       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256    = {0xXX,XX};
 298       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384    = {0xXX,XX};
 299       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX};
 300       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX};
 301       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256    = {0xXX,XX};
 302       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384    = {0xXX,XX};
 303
 304
 305 6.  Acknowledgements
 306
 307    This work was supported by the US Department of Defense.
 308
 309    David McGrew contributed substantual sections of the GCM nonce text
 310    as well as providing a review of this document.
 311
 312
 313 7.  References
 314
 315 7.1.  Normative References
 316
 317    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 318               Requirement Levels", BCP 14, RFC 2119, March 1997.
 319
 320    [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
 321               Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
 322               for Transport Layer Security (TLS)", RFC 4492, May 2006.
 323
 324    [I-D.mcgrew-auth-enc]
 325               McGrew, D., "An Interface and Algorithms for Authenticated
 326               Encryption", draft-mcgrew-auth-enc-05 (work in progress),
 327               November 2007.
 328
 329    [I-D.ietf-tls-rfc4346-bis]
 330               Dierks, T. and E. Rescorla, "The Transport Layer Security
 331               (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-09
 332
 333
 334
 335 Rescorla                 Expires August 15, 2008                [Page 6]
 336 \f
 337 Internet-Draft               TLS ECC New MAC               February 2008
 338
 339
 340               (work in progress), February 2008.
 341
 342    [AES]      National Institute of Standards and Technology,
 343               "Specification for the Advanced Encryption Standard
 344               (AES)", FIPS 197, November 2001.
 345
 346    [SHS]      National Institute of Standards and Technology, "Secure
 347               Hash Standard", FIPS 180-2, August 2002.
 348
 349    [CBC]      National Institute of Standards and Technology,
 350               "Recommendation for Block Cipher Modes of Operation -
 351               Methods and Techniques", SP 800-38A, December 2001.
 352
 353    [GCM]      National Institute of Standards and Technology,
 354               "Recommendation for Block Cipher Modes of Operation:
 355               Galois;/Counter Mode (GCM) for Confidentiality and
 356               Authentication", SP 800-38D, November 2007.
 357
 358 7.2.  Informative References
 359
 360    [Wang05]   Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the
 361               Full SHA-1", CRYPTO 2005, August 2005.
 362
 363    [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
 364               Security", RFC 4347, April 2006.
 365
 366    [I-D.salowey-tls-rsa-aes-gcm]
 367               Salowey, J., "RSA based AES-GCM Cipher Suites for TLS",
 368               draft-salowey-tls-rsa-aes-gcm-00 (work in progress),
 369               February 2007.
 370
 371
 372 Author's Address
 373
 374    Eric Rescorla
 375    RTFM, Inc.
 376    2064 Edgewood Drive
 377    Palo Alto  94303
 378    USA
 379
 380    Email:  ekr@rtfm.com
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391 Rescorla                 Expires August 15, 2008                [Page 7]
 392 \f
 393 Internet-Draft               TLS ECC New MAC               February 2008
 394
 395
 396 Full Copyright Statement
 397
 398    Copyright (C) The IETF Trust (2008).
 399
 400    This document is subject to the rights, licenses and restrictions
 401    contained in BCP 78, and except as set forth therein, the authors
 402    retain all their rights.
 403
 404    This document and the information contained herein are provided on an
 405    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 406    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 407    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 408    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 409    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 410    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 411
 412
 413 Intellectual Property
 414
 415    The IETF takes no position regarding the validity or scope of any
 416    Intellectual Property Rights or other rights that might be claimed to
 417    pertain to the implementation or use of the technology described in
 418    this document or the extent to which any license under such rights
 419    might or might not be available; nor does it represent that it has
 420    made any independent effort to identify any such rights.  Information
 421    on the procedures with respect to rights in RFC documents can be
 422    found in BCP 78 and BCP 79.
 423
 424    Copies of IPR disclosures made to the IETF Secretariat and any
 425    assurances of licenses to be made available, or the result of an
 426    attempt made to obtain a general license or permission for the use of
 427    such proprietary rights by implementers or users of this
 428    specification can be obtained from the IETF on-line IPR repository at
 429    http://www.ietf.org/ipr.
 430
 431    The IETF invites any interested party to bring to its attention any
 432    copyrights, patents or patent applications, or other proprietary
 433    rights that may cover technology that may be required to implement
 434    this standard.  Please address the information to the IETF at
 435    ietf-ipr@ietf.org.
 436
 437
 438 Acknowledgment
 439
 440    Funding for the RFC Editor function is provided by the IETF
 441    Administrative Support Activity (IASA).
 442
 443
 444
 445
 446
 447 Rescorla                 Expires August 15, 2008                [Page 8]
 448 \f