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

   1
   2
   3
   4 TLS Working Group                                             J. Salowey
   5 Internet-Draft                                              A. Choudhury
   6 Intended status: Standards Track                               D. McGrew
   7 Expires: December 20, 2007                           Cisco Systems, Inc.
   8                                                            June 18, 2007
   9
  10
  11                 RSA based AES-GCM Cipher Suites for TLS
  12                      draft-ietf-tls-rsa-aes-gcm-00
  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 December 20, 2007.
  38
  39 Copyright Notice
  40
  41    Copyright (C) The IETF Trust (2007).
  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 December 20, 2007               [Page 1]
  56 \f
  57 Internet-Draft          RSA AES-GCM Ciphersuites               June 2007
  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
  68    4.  TLS Versions  . . . . . . . . . . . . . . . . . . . . . . . . . 5
  69
  70    5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
  71
  72    6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
  73      6.1.  Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . 6
  74      6.2.  Counter Reuse . . . . . . . . . . . . . . . . . . . . . . . 6
  75
  76    7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
  77
  78    8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
  79      8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
  80      8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
  81
  82    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8
  83    Intellectual Property and Copyright Statements  . . . . . . . . . . 9
  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 Salowey, et al.         Expires December 20, 2007               [Page 2]
 112 \f
 113 Internet-Draft          RSA AES-GCM Ciphersuites               June 2007
 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) operation, as used in TLS 1.2[I-D.ietf-tls-rfc4346-bis].
 136    The ciphersuites defined in this draft may be used with DTLS defined
 137    in [RFC4347] and [I-D.ietf-tls-ecc-new-mac].  This memo uses GCM in a
 138    way similar to [I-D.rescorla-tls-suiteb].
 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 ciphersuites defined in this document are based on the the AES-
 151    GCM authenticated encryption with associated data (AEAD) algorithms
 152    AEAD_AES_128_GCM and AEAD_AES_256_GCM described in
 153    [I-D.mcgrew-auth-enc].  Note that this specification uses a 128-bit
 154    authentication tag with GCM.  The following ciphersuites are defined:
 155
 156       CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD1,TBD1}
 157       CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD2,TBD2}
 158       CipherSuite TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 = {TBD3,TBD3}
 159       CipherSuite TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 = {TBD4,TBD4}
 160
 161    The "nonce" SHALL be 12 bytes long and it is "partially implicit"
 162    (see section 3.2.1 in [I-D.mcgrew-auth-enc]); that is, part of the
 163    nonce is explicitly carried in each packet, and part of the nonce is
 164
 165
 166
 167 Salowey, et al.         Expires December 20, 2007               [Page 3]
 168 \f
 169 Internet-Draft          RSA AES-GCM Ciphersuites               June 2007
 170
 171
 172    implicit.  The nonce is constructed from a salt and an explicit
 173    Counter, sent as part of the packet, as follows:
 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 using a particular
 188    fixed key.  Failure to meet this uniqueness requirement can
 189    significantly degrade security.  The explicit_nonce_part is carried
 190    in the IV field of the GenericAEADCipher structure.  Therefore, for
 191    all the algorithms defined in this section,
 192    SecurityParameters.iv_length=8.
 193
 194    In the case of TLS the explicit_nonce_part MAY be the 64-bit sequence
 195    number.  In the case of DTLS the explicit_nonce_part MAY be the 16-
 196    bit epoch with the concatenated 48-bit DTLS seq_num.
 197
 198    If multiple cryptographic processors are in use by the sender, then
 199    the sender MUST ensure that each value of the explicit_nonce_part
 200    that is used by each processor is distinct.  In this case each
 201    encryption processor SHOULD include in the explicit_nonce_part a a
 202    fixed value that is distinct for each processor.  The recommended
 203    format is
 204
 205         explicit_nonce_part = FixedDistinct || Variable
 206
 207    where the FixedDistinct field is distinct for each encryption
 208    processor, but is fixed for a given processor, and the Variable field
 209    is distinct for each distinct nonce used by a particular encryption
 210    processor.  When this method is used, the FixedDistinct fields used
 211    by the different processors MUST have the same length.
 212
 213    In the terms of Figure 2 in [I-D.mcgrew-auth-enc], the Salt is the
 214    Fixed-Common part of the nonce (it is fixed, and it is common across
 215    all encryption processors), the FixedDistinct field exactly
 216    corresponds to the Fixed-Distinct field, and the Variable field
 217    corresponds to the Counter field, and the explicit part exactly
 218    corresponds to the explicit_nonce_part.
 219
 220
 221
 222
 223 Salowey, et al.         Expires December 20, 2007               [Page 4]
 224 \f
 225 Internet-Draft          RSA AES-GCM Ciphersuites               June 2007
 226
 227
 228    For clarity, we provide an example for TLS in which there are two
 229    distinct encryption processors, each of which uses a one-byte
 230    FixedDistinct field:
 231
 232           Salt          = eedc68dc
 233           FixedDistinct = 01       (for the first encryption processor)
 234           FixedDistinct = 02       (for the second encryption processor)
 235
 236    The GCMnonces generated by the first encryption processor, and their
 237    corresponding explicit_nonce_parts, are:
 238
 239           GCMNonce                    explicit_nonce_part
 240           ------------------------    ----------------------------
 241           eedc68dc0100000000000000    0100000000000000
 242           eedc68dc0100000000000001    0100000000000001
 243           eedc68dc0100000000000002    0100000000000002
 244           ...
 245
 246    The GCMnonces generated by the second encryption processor, and their
 247    corresponding explicit_nonce_parts, are
 248
 249           GCMNonce                    explicit_nonce_part
 250           ------------------------    ----------------------------
 251           eedc68dc0200000000000000    0200000000000000
 252           eedc68dc0200000000000001    0200000000000001
 253           eedc68dc0200000000000002    0200000000000002
 254           ...
 255
 256
 257    The RSA and RSA-DHE key exchange is performed as defined in
 258    [I-D.ietf-tls-rfc4346-bis].
 259
 260    Recall that an AEAD operation replaces the use of HMAC as a MAC, but
 261    not as a PRF for the purposes of key derivation.  Consequently, the
 262    hash function for the TLS PRF must be explicitly specified by the
 263    ciphersuite.  The PRF algorithms SHALL be as follows:
 264
 265    For TLS_RSA_WITH_AES_128_GCM_SHA256 and
 266    TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 the hash function is SHA256.
 267
 268    For TLS_RSA_WITH_AES_256_GCM_SHA384 and
 269    TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 the hash function is SHA384.
 270
 271
 272 4.  TLS Versions
 273
 274    These ciphersuites make use of the authenticated encryption with
 275    additional data defined in TLS 1.2 [I-D.ietf-tls-rfc4346-bis].  They
 276
 277
 278
 279 Salowey, et al.         Expires December 20, 2007               [Page 5]
 280 \f
 281 Internet-Draft          RSA AES-GCM Ciphersuites               June 2007
 282
 283
 284    MUST NOT be negotiated in older versions of TLS.  Clients MUST NOT
 285    offer these cipher suites if they do not offer TLS 1.2 or later.
 286    Servers which select an earlier version of TLS MUST NOT select one of
 287    these cipher suites.  Because TLS has no way for the client to
 288    indicate that it supports TLS 1.2 but not earlier, a non-compliant
 289    server might potentially negotiate TLS 1.1 or earlier and select one
 290    of the cipher suites in this document.  Clients MUST check the TLS
 291    version and generate a fatal "illegal_parameter" alert if they detect
 292    an incorrect version.
 293
 294
 295 5.  IANA Considerations
 296
 297    IANA has assigned the following values for the ciphersuites defined
 298    in this draft:
 299
 300       CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD1,TBD1}
 301       CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD2,TBD2}
 302       CipherSuite TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 = {TBD3,TBD3}
 303       CipherSuite TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 = {TBD4,TBD4}
 304
 305
 306 6.  Security Considerations
 307
 308 6.1.  Perfect Forward Secrecy
 309
 310    The perfect forward secrecy properties of RSA based TLS ciphersuites
 311    are discussed in the security analysis of [RFC4346].  It should be
 312    noted that only the ephemeral Diffie-Hellman based ciphersuites are
 313    capable of providing perfect forward secrecy.
 314
 315 6.2.  Counter Reuse
 316
 317    AES-GCM security requires that the counter is never reused.  The IV
 318    construction in Section 3 is designed to prevent counter reuse.
 319
 320
 321 7.  Acknowledgements
 322
 323    This draft borrows heavily from [I-D.ietf-tls-ecc-new-mac] and
 324    [I-D.rescorla-tls-suiteb]
 325
 326
 327 8.  References
 328
 329
 330
 331
 332
 333
 334
 335 Salowey, et al.         Expires December 20, 2007               [Page 6]
 336 \f
 337 Internet-Draft          RSA AES-GCM Ciphersuites               June 2007
 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 TLS Protocol Version
 353               1.2", draft-ietf-tls-rfc4346-bis-03 (work in progress),
 354               March 2007.
 355
 356    [I-D.mcgrew-auth-enc]
 357               McGrew, D., "An Interface and Algorithms for Authenticated
 358               Encryption", draft-mcgrew-auth-enc-02 (work in progress),
 359               March 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-01 (work in progress),
 376               June 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 December 20, 2007               [Page 7]
 392 \f
 393 Internet-Draft          RSA AES-GCM Ciphersuites               June 2007
 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 December 20, 2007               [Page 8]
 448 \f
 449 Internet-Draft          RSA AES-GCM Ciphersuites               June 2007
 450
 451
 452 Full Copyright Statement
 453
 454    Copyright (C) The IETF Trust (2007).
 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 December 20, 2007               [Page 9]
 504 \f