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

   1
   2
   3
   4 Network Working Group                                        E. Rescorla
   5 Internet-Draft                                         Network Resonance
   6 Intended status:  Informational                        December 19, 2007
   7 Expires:  June 21, 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-02.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 June 21, 2008.
  38
  39 Copyright Notice
  40
  41    Copyright (C) The IETF Trust (2007).
  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 June 21, 2008                 [Page 1]
  56 \f
  57 Internet-Draft               TLS ECC New MAC               December 2007
  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      2.3.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . 5
  68      2.4.  TLS Versions  . . . . . . . . . . . . . . . . . . . . . . . 5
  69      2.5.  Security Considerations . . . . . . . . . . . . . . . . . . 5
  70        2.5.1.  Downgrade Attack  . . . . . . . . . . . . . . . . . . . 5
  71        2.5.2.  Perfect Forward Secrecy . . . . . . . . . . . . . . . . 6
  72        2.5.3.  Counter Reuse with GCM  . . . . . . . . . . . . . . . . 6
  73      2.6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . 6
  74    3.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
  75      3.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
  76      3.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 June 21, 2008                 [Page 2]
 112 \f
 113 Internet-Draft               TLS ECC New MAC               December 2007
 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 June 21, 2008                 [Page 3]
 168 \f
 169 Internet-Draft               TLS ECC New MAC               December 2007
 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.
 205
 206    The explicit_nonce_part is chosen by the sender and included in the
 207    packet.  Each value of the explicit_nonce_part MUST be distinct from
 208    all other values, for any fixed key.  Failure to meet this uniqueness
 209    requirement can significantly degrade security.  The
 210    explicit_nonce_part is carried in the IV field of the
 211    GenericAEADCipher structure.  Therefore, for all the algorithms
 212    defined in this section, SecurityParameters.iv_length=8.
 213
 214    In the case of TLS the counter MAY be the 64-bit sequence number.  In
 215    the case of Datagram TLS [RFC4347] [NOTE:  there needs to be a new
 216    DTLS draft for AEAD, this is a placeholder] the counter MAY be formed
 217    from the concatenation of the 16-bit epoch with the 48-bit sequence
 218    number.
 219
 220
 221
 222
 223 Rescorla                  Expires June 21, 2008                 [Page 4]
 224 \f
 225 Internet-Draft               TLS ECC New MAC               December 2007
 226
 227
 228    The PRF algorithms SHALL be as follows:
 229
 230    For TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
 231    TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 it SHALL be P_SHA-256.
 232
 233    For TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
 234    TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 it SHALL be P_SHA-384.
 235
 236 2.3.  Acknowledgements
 237
 238    This work was supported by the US Department of Defense.
 239
 240    David McGrew contributed substantual sections of the GCM nonce text
 241    as well as providing a review of this document.
 242
 243 2.4.  TLS Versions
 244
 245    Because these cipher suites depend on features available only in TLS
 246    1.2 (PRF flexibility and combined authenticated encryption cipher
 247    modes), they MUST NOT be negotiated by older versions of TLS.
 248    Clients MUST NOT offer these cipher suites if they do not offer TLS
 249    1.2 or later.  Servers which select an earlier version of TLS MUST
 250    NOT select one of these cipher suites.  Because TLS has no way for
 251    the client to indicate that it supports TLS 1.2 but not earlier, a
 252    non-compliant server might potentially negotiate TLS 1.1 or earlier
 253    and select one of the cipher suites in this document.  Clients MUST
 254    check the TLS version and generate a fatal "illegal_parameter" alert
 255    if they detect an incorrect version.
 256
 257 2.5.  Security Considerations
 258
 259    The security considerations in RFC 4346 and RFC 4492 apply to this
 260    document as well.  The remainder of this section describes security
 261    considerations specific to the cipher suites described in this
 262    document.
 263
 264 2.5.1.  Downgrade Attack
 265
 266    TLS negotiation is only as secure as the weakest cipher suite that is
 267    supported.  For instance, an implementation which supports both 160-
 268    bit and 256-bit elliptic curves can be subject to an active downgrade
 269    attack to the 160-bit security level.  An attacker who can attack
 270    that can then forge the Finished handshake check and successfully
 271    mount a man-in-the-middle attack.
 272
 273
 274
 275
 276
 277
 278
 279 Rescorla                  Expires June 21, 2008                 [Page 5]
 280 \f
 281 Internet-Draft               TLS ECC New MAC               December 2007
 282
 283
 284 2.5.2.  Perfect Forward Secrecy
 285
 286    The static ECDH cipher suites specified in this document do not
 287    provide perfect forward secrecy (PFS).  Thus, compromise of a single
 288    static key leads to potential decryption of all traffic protected
 289    using that key.  Implementors of this specification SHOULD provide at
 290    least one ECDHE mode of operation.
 291
 292 2.5.3.  Counter Reuse with GCM
 293
 294    AES-GCM is only secure if the counter is never reused.  The IV
 295    construction algorithm above is designed to ensure that this cannot
 296    happen.
 297
 298 2.6.  IANA Considerations
 299
 300    IANA has assigned the following values for these cipher suites:
 301
 302       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX};
 303       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX};
 304       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256    = {0xXX,XX};
 305       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384    = {0xXX,XX};
 306       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX};
 307       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX};
 308       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256    = {0xXX,XX};
 309       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384    = {0xXX,XX};
 310
 311
 312 3.  References
 313
 314 3.1.  Normative References
 315
 316    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 317               Requirement Levels", BCP 14, RFC 2119, March 1997.
 318
 319    [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
 320               Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
 321               for Transport Layer Security (TLS)", RFC 4492, May 2006.
 322
 323    [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
 324               Security", RFC 4347, April 2006.
 325
 326    [I-D.mcgrew-auth-enc]
 327               McGrew, D., "An Interface and Algorithms for Authenticated
 328               Encryption", draft-mcgrew-auth-enc-05 (work in progress),
 329               November 2007.
 330
 331    [I-D.ietf-tls-rfc4346-bis]
 332
 333
 334
 335 Rescorla                  Expires June 21, 2008                 [Page 6]
 336 \f
 337 Internet-Draft               TLS ECC New MAC               December 2007
 338
 339
 340               Dierks, T. and E. Rescorla, "The Transport Layer Security
 341               (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-07
 342               (work in progress), November 2007.
 343
 344    [AES]      National Institute of Standards and Technology,
 345               "Specification for the Advanced Encryption Standard
 346               (AES)", FIPS 197, November 2001.
 347
 348    [SHS]      National Institute of Standards and Technology, "Secure
 349               Hash Standard", FIPS 180-2, August 2002.
 350
 351    [CBC]      National Institute of Standards and Technology,
 352               "Recommendation for Block Cipher Modes of Operation -
 353               Methods and Techniques", SP 800-38A, December 2001.
 354
 355    [GCM]      National Institute of Standards and Technology,
 356               "Recommendation for Block Cipher Modes of Operation:
 357               Galois;/Counter Mode (GCM) for Confidentiality and
 358               Authentication", SP 800-38D (DRAFT), April 2006.
 359
 360    [Wang05]   Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the
 361               Full SHA-1", CRYPTO 2005, August 2005.
 362
 363 3.2.  Informative References
 364
 365    [I-D.salowey-tls-rsa-aes-gcm]
 366               Salowey, J., "RSA based AES-GCM Cipher Suites for TLS",
 367               draft-salowey-tls-rsa-aes-gcm-00 (work in progress),
 368               February 2007.
 369
 370
 371 Author's Address
 372
 373    Eric Rescorla
 374    Network Resonance
 375    2483 E. Bayshore #212
 376    Palo Alto  94303
 377    USA
 378
 379    Email:  ekr@networkresonance.com
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391 Rescorla                  Expires June 21, 2008                 [Page 7]
 392 \f
 393 Internet-Draft               TLS ECC New MAC               December 2007
 394
 395
 396 Full Copyright Statement
 397
 398    Copyright (C) The IETF Trust (2007).
 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 June 21, 2008                 [Page 8]
 448 \f
 449