doc/protocol/rfc3268.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                           P. Chown
   8 Request for Comments: 3268                            Skygate Technology
   9 Category: Standards Track                                      June 2002
  10
  11
  12   Advanced Encryption Standard (AES) Ciphersuites for Transport Layer
  13                              Security (TLS)
  14
  15 Status of this Memo
  16
  17    This document specifies an Internet standards track protocol for the
  18    Internet community, and requests discussion and suggestions for
  19    improvements.  Please refer to the current edition of the "Internet
  20    Official Protocol Standards" (STD 1) for the standardization state
  21    and status of this protocol.  Distribution of this memo is unlimited.
  22
  23 Copyright Notice
  24
  25    Copyright (C) The Internet Society (2002).  All Rights Reserved.
  26
  27 Abstract
  28
  29    This document proposes several new ciphersuites.  At present, the
  30    symmetric ciphers supported by Transport Layer Security (TLS) are
  31    RC2, RC4, International Data Encryption Algorithm (IDEA), Data
  32    Encryption Standard (DES), and triple DES.  The protocol would be
  33    enhanced by the addition of Advanced Encryption Standard (AES)
  34    ciphersuites.
  35
  36 Overview
  37
  38    At present, the symmetric ciphers supported by TLS are RC2, RC4,
  39    IDEA, DES, and triple DES.  The protocol would be enhanced by the
  40    addition of AES [AES] ciphersuites, for the following reasons:
  41
  42    1. RC2, RC4, and IDEA are all subject to intellectual property
  43       claims.  RSA Security Inc. has trademark rights in the names RC2
  44       and RC4, and claims that the RC4 algorithm itself is a trade
  45       secret.  Ascom Systec Ltd. owns a patent on the IDEA algorithm.
  46
  47    2. Triple DES is much less efficient than more modern ciphers.
  48
  49    3. Now that the AES process is completed there will be commercial
  50       pressure to use the selected cipher.  The AES is efficient and has
  51       withstood extensive cryptanalytic efforts.  The AES is therefore a
  52       desirable choice.
  53
  54
  55
  56
  57
  58 Chown                       Standards Track                     [Page 1]
  59 \f
  60 RFC 3268                AES Ciphersuites for TLS               June 2002
  61
  62
  63    4. Currently the DHE ciphersuites only allow triple DES (along with
  64       some "export" variants which do not use a satisfactory key
  65       length).  At the same time the DHE ciphersuites are the only ones
  66       to offer forward secrecy.
  67
  68    This document proposes several new ciphersuites, with the aim of
  69    overcoming these problems.
  70
  71 Cipher Usage
  72
  73    The new ciphersuites proposed here are very similar to the following,
  74    defined in [TLS]:
  75
  76    TLS_RSA_WITH_3DES_EDE_CBC_SHA
  77    TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
  78    TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
  79    TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
  80    TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
  81    TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
  82
  83    All the ciphersuites described here use the AES in cipher block
  84    chaining (CBC) mode.  Furthermore, they use SHA-1 [SHA-1] in an HMAC
  85    construction as described in section 5 of [TLS].  (Although the TLS
  86    ciphersuite names include the text "SHA", this actually refers to the
  87    modified SHA-1 version of the algorithm.)
  88
  89    The ciphersuites differ in the type of certificate and key exchange
  90    method.  The ciphersuites defined here use the following options for
  91    this part of the protocol:
  92
  93    CipherSuite                        Certificate type (if applicable)
  94                                       and key exchange algorithm
  95
  96    TLS_RSA_WITH_AES_128_CBC_SHA       RSA
  97    TLS_DH_DSS_WITH_AES_128_CBC_SHA    DH_DSS
  98    TLS_DH_RSA_WITH_AES_128_CBC_SHA    DH_RSA
  99    TLS_DHE_DSS_WITH_AES_128_CBC_SHA   DHE_DSS
 100    TLS_DHE_RSA_WITH_AES_128_CBC_SHA   DHE_RSA
 101    TLS_DH_anon_WITH_AES_128_CBC_SHA   DH_anon
 102
 103    TLS_RSA_WITH_AES_256_CBC_SHA       RSA
 104    TLS_DH_DSS_WITH_AES_256_CBC_SHA    DH_DSS
 105    TLS_DH_RSA_WITH_AES_256_CBC_SHA    DH_RSA
 106    TLS_DHE_DSS_WITH_AES_256_CBC_SHA   DHE_DSS
 107    TLS_DHE_RSA_WITH_AES_256_CBC_SHA   DHE_RSA
 108    TLS_DH_anon_WITH_AES_256_CBC_SHA   DH_anon
 109
 110
 111
 112
 113
 114 Chown                       Standards Track                     [Page 2]
 115 \f
 116 RFC 3268                AES Ciphersuites for TLS               June 2002
 117
 118
 119    For the meanings of the terms RSA, DH_DSS, DH_RSA, DHE_DSS, DHE_RSA
 120    and DH_anon, please refer to sections 7.4.2 and 7.4.3 of [TLS].
 121
 122    The AES supports key lengths of 128, 192 and 256 bits.  However, this
 123    document only defines ciphersuites for 128- and 256-bit keys.  This
 124    is to avoid unnecessary proliferation of ciphersuites.  Rijndael
 125    actually allows for 192- and 256-bit block sizes as well as the 128-
 126    bit blocks mandated by the AES process.  The ciphersuites defined
 127    here all use 128-bit blocks.
 128
 129    The new ciphersuites will have the following definitions:
 130
 131    CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA      = { 0x00, 0x2F };
 132    CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA   = { 0x00, 0x30 };
 133    CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA   = { 0x00, 0x31 };
 134    CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA  = { 0x00, 0x32 };
 135    CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA  = { 0x00, 0x33 };
 136    CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA  = { 0x00, 0x34 };
 137
 138    CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA      = { 0x00, 0x35 };
 139    CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA   = { 0x00, 0x36 };
 140    CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA   = { 0x00, 0x37 };
 141    CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA  = { 0x00, 0x38 };
 142    CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA  = { 0x00, 0x39 };
 143    CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA  = { 0x00, 0x3A };
 144
 145 Security Considerations
 146
 147    It is not believed that the new ciphersuites are ever less secure
 148    than the corresponding older ones.  The AES is believed to be secure,
 149    and it has withstood extensive cryptanalytic attack.
 150
 151    The ephemeral Diffie-Hellman ciphersuites provide forward secrecy
 152    without any known reduction in security in other areas.  To obtain
 153    the maximum benefit from these ciphersuites:
 154
 155    1. The ephemeral keys should only be used once.  With the TLS
 156       protocol as currently defined there is no significant efficiency
 157       gain from reusing ephemeral keys.
 158
 159    2. Ephemeral keys should be destroyed securely when they are no
 160       longer required.
 161
 162    3. The random number generator used to create ephemeral keys must not
 163       reveal past output even when its internal state is compromised.
 164
 165
 166
 167
 168
 169
 170 Chown                       Standards Track                     [Page 3]
 171 \f
 172 RFC 3268                AES Ciphersuites for TLS               June 2002
 173
 174
 175    [TLS] describes the anonymous Diffie-Hellman (ADH) ciphersuites as
 176    deprecated.  The ADH ciphersuites defined here are not deprecated.
 177    However, when they are used, particular care must be taken:
 178
 179    1. ADH provides confidentiality but not authentication.  This means
 180       that (if authentication is required) the communicating parties
 181       must authenticate to each other by some means other than TLS.
 182
 183    2. ADH is vulnerable to man-in-the-middle attacks, as a consequence
 184       of the lack of authentication.  The parties must have a way of
 185       determining whether they are participating in the same TLS
 186       connection.  If they are not, they can deduce that they are under
 187       attack, and presumably abort the connection.
 188
 189       For example, if the parties share a secret, it is possible to
 190       compute a MAC of the TLS Finished message.  An attacker would have
 191       to negotiate two different TLS connections; one with each
 192       communicating party.  The Finished messages would be different in
 193       each case, because they depend on the parties' public keys (among
 194       other things).  For this reason, the MACs computed by each party
 195       would be different.
 196
 197       It is important to note that authentication techniques which do
 198       not use the Finished message do not usually provide protection
 199       from this attack.  For example, the client could authenticate to
 200       the server with a password, but it would still be vulnerable to
 201       man-in-the-middle attacks.
 202
 203       Recent research has identified a chosen plaintext attack which
 204       applies to all ciphersuites defined in [TLS] which use CBC mode.
 205       This weakness does not affect the common use of TLS on the World
 206       Wide Web, but may affect the use of TLS in other applications.
 207       When TLS is used in an application where this attack is possible,
 208       attackers can determine the truth or otherwise of a hypothesis
 209       that particular plaintext data was sent earlier in the session.
 210       No key material is compromised.
 211
 212       It is likely that the CBC construction will be changed in a future
 213       revision of the TLS protocol.
 214
 215 Intellectual Property
 216
 217    The IETF takes no position regarding the validity or scope of any
 218    intellectual property or other rights that might be claimed to
 219    pertain to the implementation or use other technology described in
 220    this document or the extent to which any license under such rights
 221    might or might not be available; neither does it represent that it
 222    has made any effort to identify any such rights.  Information on the
 223
 224
 225
 226 Chown                       Standards Track                     [Page 4]
 227 \f
 228 RFC 3268                AES Ciphersuites for TLS               June 2002
 229
 230
 231    IETF's procedures with respect to rights in standards-track and
 232    standards-related documentation can be found in BCP-11.  Copies of
 233    claims of rights made available for publication and any assurances of
 234    licenses to be made available, or the result of an attempt made to
 235    obtain a general license or permission for the use of such
 236    proprietary rights by implementors or users of this specification can
 237    be obtained from the IETF Secretariat.
 238
 239    The IETF invites any interested party to bring to its attention any
 240    copyrights, patents or patent applications, or other proprietary
 241    rights which may cover technology that may be required to practice
 242    this standard.  Please address the information to the IETF Executive
 243    Director.
 244
 245    During the development of the AES, NIST published the following
 246    statement on intellectual property:
 247
 248       SPECIAL NOTE - Intellectual Property
 249
 250       NIST reminds all interested parties that the adoption of AES is
 251       being conducted as an open standards-setting activity.
 252       Specifically, NIST has requested that all interested parties
 253       identify to NIST any patents or inventions that may be required
 254       for the use of AES.  NIST hereby gives public notice that it may
 255       seek redress under the antitrust laws of the United States against
 256       any party in the future who might seek to exercise patent rights
 257       against any user of AES that have not been disclosed to NIST in
 258       response to this request for information.
 259
 260 Acknowledgements
 261
 262    I would like to thank the ietf-tls mailing list contributors who have
 263    made helpful suggestions for this document.
 264
 265 References
 266
 267    [TLS]    Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
 268             2246, January 1999.
 269
 270    [AES]    National Institute of Standards and Technology,
 271             "Specification for the Advanced Encryption Standard (AES)"
 272             FIPS 197.  November 26, 2001.
 273
 274    [SHA-1]  FIPS PUB 180-1, "Secure Hash Standard," National Institute
 275             of Standards and Technology, U.S. Department of Commerce,
 276             April 17, 1995.
 277
 278
 279
 280
 281
 282 Chown                       Standards Track                     [Page 5]
 283 \f
 284 RFC 3268                AES Ciphersuites for TLS               June 2002
 285
 286
 287 Author's Address
 288
 289    Pete Chown
 290    Skygate Technology Ltd
 291    8 Lombard Road
 292    London
 293    SW19 3TZ
 294    United Kingdom
 295
 296    Phone: +44 20 8542 7856
 297    EMail: pc@skygate.co.uk
 298
 299
 300
 301
 302
 303
 304
 305
 306
 307
 308
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Chown                       Standards Track                     [Page 6]
 339 \f
 340 RFC 3268                AES Ciphersuites for TLS               June 2002
 341
 342
 343 Full Copyright Statement
 344
 345    Copyright (C) The Internet Society (2002).  All Rights Reserved.
 346
 347    This document and translations of it may be copied and furnished to
 348    others, and derivative works that comment on or otherwise explain it
 349    or assist in its implementation may be prepared, copied, published
 350    and distributed, in whole or in part, without restriction of any
 351    kind, provided that the above copyright notice and this paragraph are
 352    included on all such copies and derivative works.  However, this
 353    document itself may not be modified in any way, such as by removing
 354    the copyright notice or references to the Internet Society or other
 355    Internet organizations, except as needed for the purpose of
 356    developing Internet standards in which case the procedures for
 357    copyrights defined in the Internet Standards process must be
 358    followed, or as required to translate it into languages other than
 359    English.
 360
 361    The limited permissions granted above are perpetual and will not be
 362    revoked by the Internet Society or its successors or assigns.
 363
 364    This document and the information contained herein is provided on an
 365    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 366    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 367    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 368    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 369    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 370
 371 Acknowledgement
 372
 373    Funding for the RFC Editor function is currently provided by the
 374    Internet Society.
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Chown                       Standards Track                     [Page 7]
 395 \f