doc/protocol/draft-ietf-tls-suiteb-00.txt

   1
   2 Network Working Group                                          M. Salter
   3 Internet-Draft                                  National Security Agency
   4 Intended status:  Informational                              E. Rescorla
   5 Expires:  October 25, 2007                             Network Resonance
   6                                                           April 23, 2007
   7
   8
   9                      Suite B Cipher Suites for TLS
  10                       draft-ietf-tls-suiteb-00.txt
  11
  12 Status of this Memo
  13
  14    By submitting this Internet-Draft, each author represents that any
  15    applicable patent or other IPR claims of which he or she is aware
  16    have been or will be disclosed, and any of which he or she becomes
  17    aware will be disclosed, in accordance with Section 6 of BCP 79.
  18
  19    Internet-Drafts are working documents of the Internet Engineering
  20    Task Force (IETF), its areas, and its working groups.  Note that
  21    other groups may also distribute working documents as Internet-
  22    Drafts.
  23
  24    Internet-Drafts are draft documents valid for a maximum of six months
  25    and may be updated, replaced, or obsoleted by other documents at any
  26    time.  It is inappropriate to use Internet-Drafts as reference
  27    material or to cite them other than as "work in progress."
  28
  29    The list of current Internet-Drafts can be accessed at
  30    http://www.ietf.org/ietf/1id-abstracts.txt.
  31
  32    The list of Internet-Draft Shadow Directories can be accessed at
  33    http://www.ietf.org/shadow.html.
  34
  35    This Internet-Draft will expire on October 25, 2007.
  36
  37 Copyright Notice
  38
  39    Copyright (C) The IETF Trust (2007).
  40
  41 Abstract
  42
  43    The United States Government has published guidelines for "NSA Suite
  44    B Cryptography" dated July, 2005, which defines cryptographic
  45    algorithm polcy for national security applications.  This document
  46    defines a profile of TLS which is conformant with Suite B.
  47
  48
  49
  50
  51
  52
  53 Salter & Rescorla       Expires October 25, 2007                [Page 1]
  54 \f
  55 Internet-Draft               Suite B for TLS                  April 2007
  56
  57
  58 Table of Contents
  59
  60    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
  61    2.  Conventions Used In This Document . . . . . . . . . . . . . . . 3
  62    3.  Suite B Requirements  . . . . . . . . . . . . . . . . . . . . . 3
  63    4.  Suite B Compliance Requirements . . . . . . . . . . . . . . . . 4
  64      4.1.  Security Levels . . . . . . . . . . . . . . . . . . . . . . 4
  65      4.2.  Acceptable Curves . . . . . . . . . . . . . . . . . . . . . 5
  66    5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
  67    6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
  68    7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
  69    8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
  70      8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
  71      8.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
  72    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6
  73    Intellectual Property and Copyright Statements  . . . . . . . . . . 8
  74
  75
  76
  77
  78
  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 Salter & Rescorla       Expires October 25, 2007                [Page 2]
 110 \f
 111 Internet-Draft               Suite B for TLS                  April 2007
 112
 113
 114 1.  Introduction
 115
 116    In July, 2005 the National Security Agency posted "Fact Sheet, NSA
 117    Suite B Cryptography" which stated:
 118
 119        To complement the existing policy for the use of the Advanced
 120        Encryption Standard (AES) to protect national security systems
 121        and information as specified in The National Policy on the use of
 122        the Advanced Encryption Standard (AES) to Protect National
 123        Security Systems and National Security Information (CNSSP-15),
 124        the National Security Agency (NSA) announced Suite B Cryptography
 125        at the 2005 RSA Conference.  In addition to the AES, Suite B
 126        includes cryptographic algorithms for hashing, digital
 127        signatures, and key exchange.
 128
 129        Suite B only specifies the cryptographic algorithms to be
 130        used. Many other factors need to be addressed in determining
 131        whether a particular device implementing a particular set of
 132        cryptographic algorithms should be used to satisfy a particular
 133        requirement.
 134
 135    Among those factors are "requirements for interoperability both
 136    domestically and internationally".
 137
 138    This document is a profile of of TLS 1.2 [I-D.ietf-tls-rfc4346-bis]
 139    and of the cipher suites defined in [I-D.ietf-tls-ecc-new-mac], but
 140    does not itself define any new cipher suites.  This profile requires
 141    TLS 1.2.
 142
 143
 144 2.  Conventions Used In This Document
 145
 146    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 147    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 148    document are to be interpreted as described in [RFC2119].
 149
 150
 151 3.  Suite B Requirements
 152
 153    The "Suite B Fact Sheet" requires that key establishment and
 154    authentication algorithms be based on Elliptic Curve Cryptography,
 155    that the encryption algorithm be AES [AES], and that the function
 156    used for key derivation and data integrity be SHA [SHS].  It defines
 157    two security levels, of 128 and 192 bits.
 158
 159    In particular it states:
 160
 161
 162
 163
 164
 165 Salter & Rescorla       Expires October 25, 2007                [Page 3]
 166 \f
 167 Internet-Draft               Suite B for TLS                  April 2007
 168
 169
 170       SUITE B includes:
 171
 172        Encryption:          Advanced Encryption Standard (AES)  -
 173                             FIPS 197 (with keys sizes of 128 and 256
 174                             bits)
 175
 176        Digital Signature:   Elliptic Curve Digital Signature Algorithm -
 177                             FIPS 186-2 (using the curves with 256 and
 178                             384-bit prime moduli)
 179
 180        Key Exchange:        Elliptic Curve Diffie-Hellman or Elliptic
 181                             Curve MQV Draft NIST Special Publication
 182                             800-56 (using the curves with 256 and
 183                             384-bit prime moduli)
 184
 185        Hashing:             Secure Hash Algorithm - FIPS 180-2
 186                             (using SHA-256 and SHA-384)
 187
 188       All implementations of Suite B must, at a minimum, include AES
 189       with 128-bit keys, the 256-bit prime modulus elliptic curve and
 190       SHA-256 as a common mode for widespread interoperability.
 191
 192    The 128-bit security level corresponds to an elliptic curve size of
 193    256 bits, AES-128, and SHA-256.  The 192-bit security level
 194    corresponds to an elliptic curve size of 384 bits, AES-256, and SHA-
 195    384.
 196
 197
 198 4.  Suite B Compliance Requirements
 199
 200    To be considered "Suite B compatible" at least one of the Galois
 201    Counter Mode (GCM) CipherSuites defined in [I-D.ietf-tls-ecc-new-mac]
 202    MUST be negotiated.  In compliance with the guidance in the Suite B
 203    Fact Sheet every TLS implementation of Suite B SHOULD implement
 204    TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.
 205
 206 4.1.  Security Levels
 207
 208    As described in Section 1, Suite B specifies two security levels, 128
 209    and 192 bit.  The following table lists the security levels for each
 210    cipher suite:
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221 Salter & Rescorla       Expires October 25, 2007                [Page 4]
 222 \f
 223 Internet-Draft               Suite B for TLS                  April 2007
 224
 225
 226        +-----------------------------------------+----------------+
 227        | Cipher Suite                            | Security Level |
 228        +-----------------------------------------+----------------+
 229        | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | 128            |
 230        | TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256  | 128            |
 231        | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | 192            |
 232        | TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384  | 192            |
 233        +-----------------------------------------+----------------+
 234
 235 4.2.  Acceptable Curves
 236
 237    RFC 4492 defines a variety of elliptic curves.  For cipher suites
 238    defined in this specification, only secp256r1 (23) or secp384r1 (24)
 239    may be used.  (These are the same curves that appear in FIPS 186-2 as
 240    P-256 and P-384, respectively.)  For cipher suites at the 128-bit
 241    security level, secp256r1 MUST be used.  For cipher suites at the
 242    192-bit security level, secp384r1 MUST be used.  RFC 4492 requires
 243    that uncompressed (0) form be supported. ansiX962_compressed_prime(1)
 244    point formats MAY be supported.
 245
 246    Clients desiring to negotiate only a Suite B-compliant connection
 247    MUST generate a "Supported Elliptic Curves Extension" containing only
 248    the allowed curves.  These curves MUST match the cipher suite
 249    security levels being offered.  Clients which are willing to do both
 250    Suite B-compliant and non-Suite B-compliant connections MAY omit the
 251    extension or send the extension but offer other curves as well as the
 252    appropriate Suite B ones.
 253
 254    Servers desiring to negotiate a Suite B-compliant connection SHOULD
 255    check for the presence of the extension, but MUST NOT negotiate
 256    inappropriate curves even if they are offered by the client.  This
 257    allows a Client which is willing to do either Suite B-compliant or
 258    non-Suite B-compliant modes to interoperate with a server which will
 259    only do Suite B-compliant modes.  If the client does not advertise an
 260    acceptable curve, the server MUST generate a fatal
 261    "handshake_failure" alert and terminate the connection.  Clients MUST
 262    check the chosen curve to make sure it is acceptable.
 263
 264
 265 5.  Security Considerations
 266
 267    Most of the security considerations for this document are described
 268    in TLS 1.2 [I-D.ietf-tls-rfc4346-bis], RFC 4492 [RFC4492], and
 269    [I-D.ietf-tls-ecc-new-mac].  Readers should consult those documents.
 270
 271    In order to meet the goal of a consistent security level for the
 272    entire cipher suite, in Suite B mode TLS implementations MUST ONLY
 273    use the curves defined in Section 4.2.  Otherwise, it is possible to
 274
 275
 276
 277 Salter & Rescorla       Expires October 25, 2007                [Page 5]
 278 \f
 279 Internet-Draft               Suite B for TLS                  April 2007
 280
 281
 282    have a set of symmetric algorithms with much weaker or stronger
 283    security properties than the asymmetric (ECC) algorithms.
 284
 285
 286 6.  IANA Considerations
 287
 288    This document defines no actions for IANA.
 289
 290
 291 7.  Acknowledgements
 292
 293    This work was supported by the US Department of Defense.
 294
 295
 296 8.  References
 297
 298 8.1.  Normative References
 299
 300    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 301               Requirement Levels", BCP 14, RFC 2119, March 1997.
 302
 303    [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
 304               Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
 305               for Transport Layer Security (TLS)", RFC 4492, May 2006.
 306
 307    [I-D.ietf-tls-rfc4346-bis]
 308               Dierks, T. and E. Rescorla, "The TLS Protocol Version
 309               1.2", draft-ietf-tls-rfc4346-bis-03 (work in progress),
 310               March 2007.
 311
 312    [AES]      National Institute of Standards and Technology,
 313               "Specification for the Advanced Encryption Standard
 314               (AES)", FIPS 197, November 2001.
 315
 316    [SHS]      National Institute of Standards and Technology, "Secure
 317               Hash Standard", FIPS 180-2, August 2002.
 318
 319    [I-D.ietf-tls-ecc-new-mac]
 320               Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
 321               256/384 and AES Galois Counter Mode", April 2007.
 322
 323 8.2.  Informative References
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333 Salter & Rescorla       Expires October 25, 2007                [Page 6]
 334 \f
 335 Internet-Draft               Suite B for TLS                  April 2007
 336
 337
 338 Authors' Addresses
 339
 340    Margaret Salter
 341    National Security Agency
 342    9800 Savage Rd.
 343    Fort Meade  20755-6709
 344    USA
 345
 346    Email:  msalter@restarea.ncsc.mil
 347
 348
 349    Eric Rescorla
 350    Network Resonance
 351    2483 E. Bayshore #212
 352    Palo Alto  94303
 353    USA
 354
 355    Email:  ekr@networkresonance.com
 356
 357
 358
 359
 360
 361
 362
 363
 364
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389 Salter & Rescorla       Expires October 25, 2007                [Page 7]
 390 \f
 391 Internet-Draft               Suite B for TLS                  April 2007
 392
 393
 394 Full Copyright Statement
 395
 396    Copyright (C) The IETF Trust (2007).
 397
 398    This document is subject to the rights, licenses and restrictions
 399    contained in BCP 78, and except as set forth therein, the authors
 400    retain all their rights.
 401
 402    This document and the information contained herein are provided on an
 403    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 404    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 405    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 406    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 407    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 408    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 409
 410
 411 Intellectual Property
 412
 413    The IETF takes no position regarding the validity or scope of any
 414    Intellectual Property Rights or other rights that might be claimed to
 415    pertain to the implementation or use of the technology described in
 416    this document or the extent to which any license under such rights
 417    might or might not be available; nor does it represent that it has
 418    made any independent effort to identify any such rights.  Information
 419    on the procedures with respect to rights in RFC documents can be
 420    found in BCP 78 and BCP 79.
 421
 422    Copies of IPR disclosures made to the IETF Secretariat and any
 423    assurances of licenses to be made available, or the result of an
 424    attempt made to obtain a general license or permission for the use of
 425    such proprietary rights by implementers or users of this
 426    specification can be obtained from the IETF on-line IPR repository at
 427    http://www.ietf.org/ipr.
 428
 429    The IETF invites any interested party to bring to its attention any
 430    copyrights, patents or patent applications, or other proprietary
 431    rights that may cover technology that may be required to implement
 432    this standard.  Please address the information to the IETF at
 433    ietf-ipr@ietf.org.
 434
 435
 436 Acknowledgment
 437
 438    Funding for the RFC Editor function is provided by the IETF
 439    Administrative Support Activity (IASA).
 440
 441
 442
 443
 444
 445 Salter & Rescorla       Expires October 25, 2007                [Page 8]
 446 \f
 447