doc/protocol/draft-rescorla-tls-suiteb-02.txt

   1
   2
   3
   4 Network Working Group                                          M. Salter
   5 Internet-Draft                                  National Security Agency
   6 Intended status:  Informational                              E. Rescorla
   7 Expires:  October 16, 2008                             Network Resonance
   8                                                           April 14, 2008
   9
  10
  11                      Suite B Cipher Suites for TLS
  12                     draft-rescorla-tls-suiteb-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 October 16, 2008.
  38
  39 Copyright Notice
  40
  41    Copyright (C) The IETF Trust (2008).
  42
  43 Abstract
  44
  45    The United States Government has published guidelines for "NSA Suite
  46    B Cryptography" dated July, 2005, which defines cryptographic
  47    algorithm polcy for national security applications.  This document
  48    defines a profile of TLS which is conformant with Suite B.
  49
  50
  51
  52
  53
  54
  55 Salter & Rescorla       Expires October 16, 2008                [Page 1]
  56 \f
  57 Internet-Draft               Suite B for TLS                  April 2008
  58
  59
  60 Table of Contents
  61
  62    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
  63    2.  Conventions Used In This Document . . . . . . . . . . . . . . . 3
  64    3.  Suite B Requirements  . . . . . . . . . . . . . . . . . . . . . 3
  65    4.  Suite B Compliance Requirements . . . . . . . . . . . . . . . . 4
  66      4.1.  Security Levels . . . . . . . . . . . . . . . . . . . . . . 4
  67      4.2.  Acceptable Curves . . . . . . . . . . . . . . . . . . . . . 5
  68    5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
  69    6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
  70    7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
  71    8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
  72      8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
  73      8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
  74    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7
  75    Intellectual Property and Copyright Statements  . . . . . . . . . . 8
  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
 110
 111 Salter & Rescorla       Expires October 16, 2008                [Page 2]
 112 \f
 113 Internet-Draft               Suite B for TLS                  April 2008
 114
 115
 116 1.  Introduction
 117
 118    In July, 2005 the National Security Agency posted "Fact Sheet, NSA
 119    Suite B Cryptography" which stated:
 120
 121        To complement the existing policy for the use of the Advanced
 122        Encryption Standard (AES) to protect national security systems
 123        and information as specified in The National Policy on the use of
 124        the Advanced Encryption Standard (AES) to Protect National
 125        Security Systems and National Security Information (CNSSP-15),
 126        the National Security Agency (NSA) announced Suite B Cryptography
 127        at the 2005 RSA Conference.  In addition to the AES, Suite B
 128        includes cryptographic algorithms for hashing, digital
 129        signatures, and key exchange.
 130
 131        Suite B only specifies the cryptographic algorithms to be
 132        used. Many other factors need to be addressed in determining
 133        whether a particular device implementing a particular set of
 134        cryptographic algorithms should be used to satisfy a particular
 135        requirement.
 136
 137    Among those factors are "requirements for interoperability both
 138    domestically and internationally".
 139
 140    This document is a profile of of TLS 1.2 [I-D.ietf-tls-rfc4346-bis]
 141    and of the cipher suites defined in [I-D.ietf-tls-ecc-new-mac], but
 142    does not itself define any new cipher suites.  This profile requires
 143    TLS 1.2.
 144
 145
 146 2.  Conventions Used In This Document
 147
 148    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 149    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 150    document are to be interpreted as described in [RFC2119].
 151
 152
 153 3.  Suite B Requirements
 154
 155    The "Suite B Fact Sheet" requires that key establishment and
 156    authentication algorithms be based on Elliptic Curve Cryptography,
 157    that the encryption algorithm be AES [AES], and that the function
 158    used for key derivation and data integrity be SHA [SHS].  It defines
 159    two security levels, of 128 and 192 bits.
 160
 161    In particular it states:
 162
 163
 164
 165
 166
 167 Salter & Rescorla       Expires October 16, 2008                [Page 3]
 168 \f
 169 Internet-Draft               Suite B for TLS                  April 2008
 170
 171
 172       SUITE B includes:
 173
 174        Encryption:          Advanced Encryption Standard (AES)  -
 175                             FIPS 197 (with keys sizes of 128 and 256
 176                             bits)
 177
 178        Digital Signature:   Elliptic Curve Digital Signature Algorithm -
 179                             FIPS 186-2 (using the curves with 256 and
 180                             384-bit prime moduli)
 181
 182        Key Exchange:        Elliptic Curve Diffie-Hellman or Elliptic
 183                             Curve MQV Draft NIST Special Publication
 184                             800-56 (using the curves with 256 and
 185                             384-bit prime moduli)
 186
 187        Hashing:             Secure Hash Algorithm - FIPS 180-2
 188                             (using SHA-256 and SHA-384)
 189
 190       All implementations of Suite B must, at a minimum, include AES
 191       with 128-bit keys, the 256-bit prime modulus elliptic curve and
 192       SHA-256 as a common mode for widespread interoperability.
 193
 194    The 128-bit security level corresponds to an elliptic curve size of
 195    256 bits, AES-128, and SHA-256.  The 192-bit security level
 196    corresponds to an elliptic curve size of 384 bits, AES-256, and SHA-
 197    384.
 198
 199
 200 4.  Suite B Compliance Requirements
 201
 202    To be considered "Suite B compatible" at least one of the Galois
 203    Counter Mode (GCM) CipherSuites defined in [I-D.ietf-tls-ecc-new-mac]
 204    MUST be negotiated.  In compliance with the guidance in the Suite B
 205    Fact Sheet every TLS implementation of Suite B SHOULD implement
 206    TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.
 207
 208 4.1.  Security Levels
 209
 210    As described in Section 1, Suite B specifies two security levels, 128
 211    and 192 bit.  The following table lists the security levels for each
 212    cipher suite:
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223 Salter & Rescorla       Expires October 16, 2008                [Page 4]
 224 \f
 225 Internet-Draft               Suite B for TLS                  April 2008
 226
 227
 228        +-----------------------------------------+----------------+
 229        | Cipher Suite                            | Security Level |
 230        +-----------------------------------------+----------------+
 231        | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | 128            |
 232        | TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256  | 128            |
 233        | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | 192            |
 234        | TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384  | 192            |
 235        +-----------------------------------------+----------------+
 236
 237 4.2.  Acceptable Curves
 238
 239    RFC 4492 defines a variety of elliptic curves.  For cipher suites
 240    defined in this specification, only secp256r1 (23) or secp384r1 (24)
 241    may be used.  (These are the same curves that appear in FIPS 186-2
 242    [DSS] as P-256 and P-384, respectively.)  For cipher suites at the
 243    128-bit security level, secp256r1 MUST be used.  For cipher suites at
 244    the 192-bit security level, secp384r1 MUST be used.  RFC 4492
 245    requires that uncompressed (0) form be supported.
 246    ansiX962_compressed_prime(1) point formats MAY be supported.
 247
 248    Clients desiring to negotiate only a Suite B-compliant connection
 249    MUST generate a "Supported Elliptic Curves Extension" containing only
 250    the allowed curves.  These curves MUST match the cipher suite
 251    security levels being offered.  Clients which are willing to do both
 252    Suite B-compliant and non-Suite B-compliant connections MAY omit the
 253    extension or send the extension but offer other curves as well as the
 254    appropriate Suite B ones.
 255
 256    Servers desiring to negotiate a Suite B-compliant connection SHOULD
 257    check for the presence of the extension, but MUST NOT negotiate
 258    inappropriate curves even if they are offered by the client.  This
 259    allows a Client which is willing to do either Suite B-compliant or
 260    non-Suite B-compliant modes to interoperate with a server which will
 261    only do Suite B-compliant modes.  If the client does not advertise an
 262    acceptable curve, the server MUST generate a fatal
 263    "handshake_failure" alert and terminate the connection.  Clients MUST
 264    check the chosen curve to make sure it is acceptable.
 265
 266
 267 5.  Security Considerations
 268
 269    Most of the security considerations for this document are described
 270    in TLS 1.2 [I-D.ietf-tls-rfc4346-bis], RFC 4492 [RFC4492],
 271    [I-D.ietf-tls-rsa-aes-gcm], and [I-D.ietf-tls-ecc-new-mac].  Readers
 272    should consult those documents.
 273
 274    In order to meet the goal of a consistent security level for the
 275    entire cipher suite, in Suite B mode TLS implementations MUST ONLY
 276
 277
 278
 279 Salter & Rescorla       Expires October 16, 2008                [Page 5]
 280 \f
 281 Internet-Draft               Suite B for TLS                  April 2008
 282
 283
 284    use the curves defined in Section 4.2.  Otherwise, it is possible to
 285    have a set of symmetric algorithms with much weaker or stronger
 286    security properties than the asymmetric (ECC) algorithms.
 287
 288
 289 6.  IANA Considerations
 290
 291    This document defines no actions for IANA.
 292
 293
 294 7.  Acknowledgements
 295
 296    This work was supported by the US Department of Defense.
 297
 298
 299 8.  References
 300
 301 8.1.  Normative References
 302
 303    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 304               Requirement Levels", BCP 14, RFC 2119, March 1997.
 305
 306    [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
 307               Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
 308               for Transport Layer Security (TLS)", RFC 4492, May 2006.
 309
 310    [I-D.ietf-tls-rfc4346-bis]
 311               Dierks, T. and E. Rescorla, "The Transport Layer Security
 312               (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-10
 313               (work in progress), March 2008.
 314
 315    [I-D.ietf-tls-ecc-new-mac]
 316               Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
 317               256/384 and AES Galois Counter  Mode",
 318               draft-ietf-tls-ecc-new-mac-04 (work in progress),
 319               February 2008.
 320
 321    [AES]      National Institute of Standards and Technology,
 322               "Specification for the Advanced Encryption Standard
 323               (AES)", FIPS 197, November 2001.
 324
 325    [SHS]      National Institute of Standards and Technology, "Secure
 326               Hash Standard", FIPS 180-2, August 2002.
 327
 328    [DSS]      National Institute of Standards and Technology, "Digital
 329               Signature Standard", FIPS 186-2, January 2000.
 330
 331
 332
 333
 334
 335 Salter & Rescorla       Expires October 16, 2008                [Page 6]
 336 \f
 337 Internet-Draft               Suite B for TLS                  April 2008
 338
 339
 340 8.2.  Informative References
 341
 342    [I-D.ietf-tls-rsa-aes-gcm]
 343               Salowey, J., Choudhury, A., and D. McGrew, "AES-GCM Cipher
 344               Suites for TLS", draft-ietf-tls-rsa-aes-gcm-02 (work in
 345               progress), February 2008.
 346
 347
 348 Authors' Addresses
 349
 350    Margaret Salter
 351    National Security Agency
 352    9800 Savage Rd.
 353    Fort Meade  20755-6709
 354    USA
 355
 356    Email:  msalter@restarea.ncsc.mil
 357
 358
 359    Eric Rescorla
 360    Network Resonance
 361    2064 Edgewood Drive
 362    Palo Alto  94303
 363    USA
 364
 365    Email:  ekr@rtfm.com
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391 Salter & Rescorla       Expires October 16, 2008                [Page 7]
 392 \f
 393 Internet-Draft               Suite B for TLS                  April 2008
 394
 395
 396 Full Copyright Statement
 397
 398    Copyright (C) The IETF Trust (2008).
 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 Salter & Rescorla       Expires October 16, 2008                [Page 8]
 448 \f
 449