doc/protocol/draft-ietf-tls-rsa-aes-gcm-01.txt

   1
   2
   3
   4 TLS Working Group                                             J. Salowey
   5 Internet-Draft                                              A. Choudhury
   6 Intended status: Standards Track                               D. McGrew
   7 Expires: July 16, 2008                               Cisco Systems, Inc.
   8                                                         January 13, 2008
   9
  10
  11                 RSA based AES-GCM Cipher Suites for TLS
  12                      draft-ietf-tls-rsa-aes-gcm-01
  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 July 16, 2008.
  38
  39 Copyright Notice
  40
  41    Copyright (C) The IETF Trust (2008).
  42
  43 Abstract
  44
  45    This memo describes the use of the Advanced Encryption Standard (AES)
  46    in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS)
  47    authenticated encryption operation.  GCM provides both
  48    confidentiality and data origin authentication, can be efficiently
  49    implemented in hardware for speeds of 10 gigabits per second and
  50    above, and is also well-suited to software implementations.  This
  51    memo defines TLS ciphersuites that use AES-GCM with RSA.
  52
  53
  54
  55 Salowey, et al.           Expires July 16, 2008                 [Page 1]
  56 \f
  57 Internet-Draft          RSA AES-GCM Ciphersuites            January 2008
  58
  59
  60 Table of Contents
  61
  62    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
  63
  64    2.  Conventions Used In This Document . . . . . . . . . . . . . . . 3
  65
  66    3.  RSA Based AES-GCM Cipher Suites . . . . . . . . . . . . . . . . 3
  67      3.1.  Recommendations for Multiple Cryptographic Processors . . . 4
  68
  69    4.  TLS Versions  . . . . . . . . . . . . . . . . . . . . . . . . . 5
  70
  71    5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
  72
  73    6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
  74      6.1.  Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . 6
  75      6.2.  Counter Reuse . . . . . . . . . . . . . . . . . . . . . . . 6
  76
  77    7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
  78
  79    8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
  80      8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
  81      8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
  82
  83    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8
  84    Intellectual Property and Copyright Statements  . . . . . . . . . . 9
  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 Salowey, et al.           Expires July 16, 2008                 [Page 2]
 112 \f
 113 Internet-Draft          RSA AES-GCM Ciphersuites            January 2008
 114
 115
 116 1.  Introduction
 117
 118    This document describes the use of AES [AES]in Galois Counter Mode
 119    (GCM) [GCM] (AES-GCM) with RSA based key exchange as a ciphersuite
 120    for TLS.  This mechanism is not only efficient and secure, hardware
 121    implementations can achieve high speeds with low cost and low
 122    latency, because the mode can be pipelined.  Applications like
 123    CAPWAP, which uses DTLS, can benefit from the high-speed
 124    implementations when wireless termination points (WTPs) and
 125    controllers (ACs) have to meet requirements to support higher
 126    throughputs in the future.  AES-GCM has been specified as a mode that
 127    can be used with IPsec ESP [RFC4106] and 802.1AE MAC Security
 128    [IEEE8021AE].  It also is part of the NSA suite B ciphersuites for
 129    TLS [I-D.rescorla-tls-suiteb]; however in order to meet Suite B
 130    requirements these ciphersuites require ECC base key exchange and TLS
 131    1.2.  The ciphersuites defined in this document are based on RSA
 132    which allows the use of AES-GCM in environments that have not
 133    deployed ECC algorithms and do not need to meet NSA Suite B
 134    requirements.  AES-GCM is an authenticated encryption with associated
 135    data (AEAD) cipher, as defined in TLS 1.2[I-D.ietf-tls-rfc4346-bis].
 136    The ciphersuites defined in this draft may be used with Datagram TLS
 137    defined in [RFC4347].  This memo uses GCM in a way similar to
 138    [I-D.ietf-tls-ecc-new-mac].
 139
 140
 141 2.  Conventions Used In This Document
 142
 143    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 144    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 145    document are to be interpreted as described in [RFC2119]
 146
 147
 148 3.  RSA Based AES-GCM Cipher Suites
 149
 150    The following ciphersuites use the new authenticated encryption modes
 151    defined in TLS 1.2 with AES in Galois Counter Mode (GCM) [GCM]:
 152
 153       CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD1,TBD1}
 154       CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD2,TBD2}
 155       CipherSuite TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 = {TBD3,TBD3}
 156       CipherSuite TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 = {TBD4,TBD4}
 157
 158    These ciphersuites use the AES-GCM authenticated encryption with
 159    associated data (AEAD) algorithms AEAD_AES_128_GCM and
 160    AEAD_AES_256_GCM described in [I-D.mcgrew-auth-enc].  Note that this
 161    specification uses a 128-bit authentication tag with GCM.  The
 162    "nonce" SHALL be 12 bytes long and it is "partially implicit" (see
 163    section 3.2.1 in [I-D.mcgrew-auth-enc]).  Part of the nonce is
 164
 165
 166
 167 Salowey, et al.           Expires July 16, 2008                 [Page 3]
 168 \f
 169 Internet-Draft          RSA AES-GCM Ciphersuites            January 2008
 170
 171
 172    generated as part of the handshake process and is static for the
 173    entire session and part is carried in each packet.
 174
 175              Struct{
 176                 opaque salt[4];
 177                 opaque explicit_nonce_part[8];
 178              } GCMNonce
 179
 180    The salt is the "implicit" part of the nonce and is not sent in the
 181    packet.  It is either the client_write_IV if the client is sending or
 182    the server_write_IV if the server is sending.  These IVs SHALL be 4
 183    bytes long.
 184
 185    The explicit_nonce_part is chosen by the sender and included in the
 186    packet.  Each value of the explicit_nonce_part MUST be distinct for
 187    each distinct invocation of GCM encrypt function for any fixed key.
 188    Failure to meet this uniqueness requirement can significantly degrade
 189    security.  The explicit_nonce_part is carried in the IV field of the
 190    GenericAEADCipher structure.  Therefore, for all the algorithms
 191    defined in this section, SecurityParameters.iv_length=8.
 192
 193    In the case of TLS the explicit_nonce_part MAY be the 64-bit sequence
 194    number.  In the case of Datagram TLS [RFC4347] the
 195    explicit_nonce_part MAY be formed from the concatenation of the 16-
 196    bit epoch with the 48-bit DTLS seq_num.
 197
 198    The RSA and RSA-DHE key exchange is performed as defined in
 199    [I-D.ietf-tls-rfc4346-bis].
 200
 201    The PRF algorithms SHALL be as follows:
 202
 203    For TLS_RSA_WITH_AES_128_GCM_SHA256 and
 204    TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 the hash function is SHA256.
 205
 206    For TLS_RSA_WITH_AES_256_GCM_SHA384 and
 207    TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 the hash function is SHA384.
 208
 209 3.1.  Recommendations for Multiple Cryptographic Processors
 210
 211    If multiple cryptographic processors are in use by the sender, then
 212    the sender MUST ensure that each value of the explicit_nonce_part
 213    that is used by each processor is distinct.  In this case each
 214    encryption processor SHOULD include in the explicit_nonce_part a a
 215    fixed value that is distinct for each processor.  The recommended
 216    format is
 217
 218         explicit_nonce_part = FixedDistinct || Variable
 219
 220
 221
 222
 223 Salowey, et al.           Expires July 16, 2008                 [Page 4]
 224 \f
 225 Internet-Draft          RSA AES-GCM Ciphersuites            January 2008
 226
 227
 228    where the FixedDistinct field is distinct for each encryption
 229    processor, but is fixed for a given processor, and the Variable field
 230    is distinct for each distinct nonce used by a particular encryption
 231    processor.  When this method is used, the FixedDistinct fields used
 232    by the different processors MUST have the same length.
 233
 234    In the terms of Figure 2 in [I-D.mcgrew-auth-enc], the Salt is the
 235    Fixed-Common part of the nonce (it is fixed, and it is common across
 236    all encryption processors), the FixedDistinct field exactly
 237    corresponds to the Fixed-Distinct field, and the Variable field
 238    corresponds to the Counter field, and the explicit part exactly
 239    corresponds to the explicit_nonce_part.
 240
 241    For clarity, we provide an example for TLS in which there are two
 242    distinct encryption processors, each of which uses a one-byte
 243    FixedDistinct field:
 244
 245           Salt          = eedc68dc
 246           FixedDistinct = 01       (for the first encryption processor)
 247           FixedDistinct = 02       (for the second encryption processor)
 248
 249    The GCMnonces generated by the first encryption processor, and their
 250    corresponding explicit_nonce_parts, are:
 251
 252           GCMNonce                    explicit_nonce_part
 253           ------------------------    ----------------------------
 254           eedc68dc0100000000000000    0100000000000000
 255           eedc68dc0100000000000001    0100000000000001
 256           eedc68dc0100000000000002    0100000000000002
 257           ...
 258
 259    The GCMnonces generated by the second encryption processor, and their
 260    corresponding explicit_nonce_parts, are
 261
 262           GCMNonce                    explicit_nonce_part
 263           ------------------------    ----------------------------
 264           eedc68dc0200000000000000    0200000000000000
 265           eedc68dc0200000000000001    0200000000000001
 266           eedc68dc0200000000000002    0200000000000002
 267           ...
 268
 269
 270
 271 4.  TLS Versions
 272
 273    These ciphersuites make use of the authenticated encryption with
 274    additional data defined in TLS 1.2 [I-D.ietf-tls-rfc4346-bis].  They
 275    MUST NOT be negotiated in older versions of TLS.  Clients MUST NOT
 276
 277
 278
 279 Salowey, et al.           Expires July 16, 2008                 [Page 5]
 280 \f
 281 Internet-Draft          RSA AES-GCM Ciphersuites            January 2008
 282
 283
 284    offer these cipher suites if they do not offer TLS 1.2 or later.
 285    Servers which select an earlier version of TLS MUST NOT select one of
 286    these cipher suites.  Because TLS has no way for the client to
 287    indicate that it supports TLS 1.2 but not earlier, a non-compliant
 288    server might potentially negotiate TLS 1.1 or earlier and select one
 289    of the cipher suites in this document.  Clients MUST check the TLS
 290    version and generate a fatal "illegal_parameter" alert if they detect
 291    an incorrect version.
 292
 293
 294 5.  IANA Considerations
 295
 296    IANA has assigned the following values for the ciphersuites defined
 297    in this draft:
 298
 299       CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD1,TBD1}
 300       CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD2,TBD2}
 301       CipherSuite TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 = {TBD3,TBD3}
 302       CipherSuite TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 = {TBD4,TBD4}
 303
 304
 305 6.  Security Considerations
 306
 307    The security considerations in [I-D.ietf-tls-rfc4346-bis] apply to
 308    this document as well.  The remainder of this section describes
 309    security considerations specific to the cipher suites described in
 310    this document.
 311
 312 6.1.  Perfect Forward Secrecy
 313
 314    The perfect forward secrecy properties of RSA based TLS ciphersuites
 315    are discussed in the security analysis of [I-D.ietf-tls-rfc4346-bis].
 316    It should be noted that only the ephemeral Diffie-Hellman based
 317    ciphersuites (RSA_DHE) are capable of providing perfect forward
 318    secrecy.
 319
 320 6.2.  Counter Reuse
 321
 322    AES-GCM security requires that the counter is never reused.  The IV
 323    construction in Section 3 is designed to prevent counter reuse.
 324
 325
 326 7.  Acknowledgements
 327
 328    This draft borrows heavily from [I-D.ietf-tls-ecc-new-mac].
 329
 330
 331 8.  References
 332
 333
 334
 335 Salowey, et al.           Expires July 16, 2008                 [Page 6]
 336 \f
 337 Internet-Draft          RSA AES-GCM Ciphersuites            January 2008
 338
 339
 340 8.1.  Normative References
 341
 342    [AES]      National Institute of Standards and Technology,
 343               "Specification for the Advanced Encryption Standard
 344               (AES)", FIPS 197, November 2001.
 345
 346    [GCM]      National Institute of Standards and Technology,
 347               "Recommendation for Block Cipher Modes of Operation:
 348               Galois Counter Mode (GCM) for Confidentiality and
 349               Authentication", SP 800-38D, April 2006.
 350
 351    [I-D.ietf-tls-rfc4346-bis]
 352               Dierks, T. and E. Rescorla, "The Transport Layer Security
 353               (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-07
 354               (work in progress), November 2007.
 355
 356    [I-D.mcgrew-auth-enc]
 357               McGrew, D., "An Interface and Algorithms for Authenticated
 358               Encryption", draft-mcgrew-auth-enc-05 (work in progress),
 359               November 2007.
 360
 361    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 362               Requirement Levels", BCP 14, RFC 2119, March 1997.
 363
 364    [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
 365               (TLS) Protocol Version 1.1", RFC 4346, April 2006.
 366
 367    [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
 368               Security", RFC 4347, April 2006.
 369
 370 8.2.  Informative References
 371
 372    [I-D.ietf-tls-ecc-new-mac]
 373               Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
 374               256/384 and AES Galois Counter  Mode",
 375               draft-ietf-tls-ecc-new-mac-02 (work in progress),
 376               December 2007.
 377
 378    [I-D.rescorla-tls-suiteb]
 379               Salter, M. and E. Rescorla, "Suite B Cipher Suites for
 380               TLS", draft-rescorla-tls-suiteb-01 (work in progress),
 381               June 2007.
 382
 383    [IEEE8021AE]
 384               Institute of Electrical and Electronics Engineers, "Media
 385               Access Control Security", IEEE Standard 802.1AE,
 386               August 2006.
 387
 388
 389
 390
 391 Salowey, et al.           Expires July 16, 2008                 [Page 7]
 392 \f
 393 Internet-Draft          RSA AES-GCM Ciphersuites            January 2008
 394
 395
 396    [RFC4106]  Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
 397               (GCM) in IPsec Encapsulating Security Payload (ESP)",
 398               RFC 4106, June 2005.
 399
 400
 401 Authors' Addresses
 402
 403    Joseph Salowey
 404    Cisco Systems, Inc.
 405    2901 3rd. Ave
 406    Seattle, WA  98121
 407    USA
 408
 409    Email: jsalowey@cisco.com
 410
 411
 412    Abhijit Choudhury
 413    Cisco Systems, Inc.
 414    3625 Cisco Way
 415    San Jose, CA  95134
 416    USA
 417
 418    Email: abhijitc@cisco.com
 419
 420
 421    David McGrew
 422    Cisco Systems, Inc.
 423    170 W Tasman Drive
 424    San Jose, CA  95134
 425    USA
 426
 427    Email: mcgrew@cisco.com
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447 Salowey, et al.           Expires July 16, 2008                 [Page 8]
 448 \f
 449 Internet-Draft          RSA AES-GCM Ciphersuites            January 2008
 450
 451
 452 Full Copyright Statement
 453
 454    Copyright (C) The IETF Trust (2008).
 455
 456    This document is subject to the rights, licenses and restrictions
 457    contained in BCP 78, and except as set forth therein, the authors
 458    retain all their rights.
 459
 460    This document and the information contained herein are provided on an
 461    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 462    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 463    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 464    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 465    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 466    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 467
 468
 469 Intellectual Property
 470
 471    The IETF takes no position regarding the validity or scope of any
 472    Intellectual Property Rights or other rights that might be claimed to
 473    pertain to the implementation or use of the technology described in
 474    this document or the extent to which any license under such rights
 475    might or might not be available; nor does it represent that it has
 476    made any independent effort to identify any such rights.  Information
 477    on the procedures with respect to rights in RFC documents can be
 478    found in BCP 78 and BCP 79.
 479
 480    Copies of IPR disclosures made to the IETF Secretariat and any
 481    assurances of licenses to be made available, or the result of an
 482    attempt made to obtain a general license or permission for the use of
 483    such proprietary rights by implementers or users of this
 484    specification can be obtained from the IETF on-line IPR repository at
 485    http://www.ietf.org/ipr.
 486
 487    The IETF invites any interested party to bring to its attention any
 488    copyrights, patents or patent applications, or other proprietary
 489    rights that may cover technology that may be required to implement
 490    this standard.  Please address the information to the IETF at
 491    ietf-ipr@ietf.org.
 492
 493
 494 Acknowledgment
 495
 496    Funding for the RFC Editor function is provided by the IETF
 497    Administrative Support Activity (IASA).
 498
 499
 500
 501
 502
 503 Salowey, et al.           Expires July 16, 2008                 [Page 9]
 504 \f