idnits 2.17.1 draft-burgin-kerberos-suiteb-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 8, 2011) is 4705 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-burgin-kerberos-aes-cbc-hmac-sha2-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K.W. Burgin 3 Internet Draft K.M. Igoe 4 Intended Status: Informational National Security Agency 5 Expires: December 10, 2011 June 8, 2011 7 Suite B in Kerberos 5 8 draft-burgin-kerberos-suiteb-00 10 Abstract 12 The United States Government has published guidelines for "NSA 13 Suite B Cryptography" dated July, 2005, which defines cryptographic 14 algorithm policy for national security applications. This document 15 specifies the conventions for using Suite B algorithms in the 16 Kerberos 5 protocol specification. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 10, 2011. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 This document may contain material from IETF Documents or IETF 51 Contributions published or made publicly available before November 52 10, 2008. The person(s) controlling the copyright in some of this 53 material may not have granted the IETF Trust the right to allow 54 modifications of such material outside the IETF Standards Process. 55 Without obtaining an adequate license from the person(s) controlling 56 the copyright in such materials, this document may not be modified 57 outside the IETF Standards Process, and derivative works of it may 58 not be created outside the IETF Standards Process, except to format 59 it for publication as an RFC or to translate it into languages other 60 than English. 62 Table of Contents 64 1. Introduction .................................................. 3 65 2. Conventions used in this Document ............................. 3 66 3. Suite B Requirements .......................................... 3 67 4. Minimum Levels of Security (minLOS) ........................... 4 68 4.1. Non-signature Primitives ................................ 4 69 4.2. Digital Signatures and Certificates ..................... 5 70 5. PKINIT ........................................................ 5 71 5.1. Algorithm Agility ....................................... 6 72 5.2. ECDH Key Exchange ....................................... 7 73 5.3. ECDSA and X.509 v3 Certificates ......................... 8 74 6. Encryption and Checksum Types ................................. 9 75 6.1. Suite B Requirements .................................... 9 76 7. Security Considerations ....................................... 9 77 8. IANA Considerations .......................................... 10 78 9. References ................................................... 10 79 9.1. Normative References ................................... 10 80 9.2. Informative References ................................. 11 81 Appendix A. Acknowledgements .................................... 11 83 1. Introduction 85 The Fact Sheet on National Security Agency (NSA) Suite B Cryptography 86 [NSA] states: 88 A Cryptographic Interoperability Strategy (CIS) was developed to 89 find ways to increase assured rapid sharing of information both 90 within the U.S. and between the U.S. and her partners through 91 the use of a common suite of public standards, protocols, 92 algorithms and modes referred to as the "Secure Sharing Suite" 93 or S.3 The implementation of CIS will facilitate the development 94 of a broader range of secure cryptographic products which will 95 be available to a wide customer base. The use of selected 96 public cryptographic standards and protocols and Suite B is the 97 core of CIS. 99 In 2005, NSA announced Suite B Cryptography which built upon the 100 National Policy on the use of the Advanced Encryption Standard 101 (AES) to Protect National Security Systems and National Security 102 Information. In addition to the AES algorithm, Suite B includes 103 cryptographic algorithms for key exchanges, digital signatures 104 and hashing. Suite B cryptography has been selected from 105 cryptography that has been approved by NIST for use by the U.S. 106 Government and specified in NIST standards or recommendations. 108 This document specifies the use of the United States National 109 Security Agency's Suite B algorithms [NSA] in Kerberos 5. 110 Symmetric key encryption algorithms and checksum types are 111 specified for use in the protocol. Additionally, the use of 112 elliptic curve cryptography in the initial authentication protocol 113 (PKINIT) is specified. 115 2. Conventions used in this Document 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 119 this document are to be interpreted as described in [RFC2119]. 121 3. Suite B Requirements 123 Suite B requires that key establishment and signature algorithms be 124 based upon Elliptic Curve Cryptography and that the encryption 125 algorithm be AES [FIPS197]. 127 Suite B includes [NSA]: 129 Encryption: Advanced Encryption Standard (AES) [FIPS197] 130 (key sizes of 128 and 256 bits) 131 Digital Signature: Elliptic Curve Digital Signature Algorithm 132 (ECDSA) [FIPS186-3] (using the curves with 133 256- and 384-bit prime moduli) 134 Key Exchange: Elliptic Curve Diffie-Hellman (ECDH) 135 [SP800-56A] (using the curves with 256- and 136 384-bit prime moduli) 137 Hashes: SHA-256 and SHA-384 [FIPS180-3] 139 The two elliptic curves used in Suite B each appear in the literature 140 under two different names. For sake of clarity, we list both names 141 below: 143 Curve NIST Name SECG Name OID [FIPS186-3] 144 --------------------------------------------------------- 145 nistp256 P-256 secp256r1 1.2.840.10045.3.1.7 146 nistp384 P-384 secp384r1 1.3.132.0.34 148 4. Minimum Levels of Security (minLOS) 150 Suite B provides for two levels of cryptographic security, namely a 151 128-bit minimum level of security (minLOS_128) and a 192-bit 152 minimum level of security (minLOS_192). Each level defines a 153 minimum strength that all cryptographic algorithms must provide. 155 4.1. Non-signature Primitives 157 We divide the Suite B non-signature primitives into two columns as 158 shown in Table 1. 160 Column 1 Column 2 161 +-------------------+------------------+ 162 Encryption | AES-128 | AES-256 | 163 +-------------------+------------------+ 164 Key Agreement | ECDH on P-256 | ECDH on P-384 | 165 +-------------------+------------------+ 166 Hash for PRF/MAC | SHA-256 | SHA-384 | 167 +-------------------+------------------+ 168 Table 1: Suite B Cryptographic Non-Signature Primitives 170 At the 128-bit minimum level of security: 172 - the non-signature primitives MUST either come exclusively from 173 Column 1 or exclusively from Column 2. 175 At the 192-bit minimum level of security: 177 - the non-signature primitives MUST come exclusively from 178 Column 2. 180 4.2. Digital Signatures and Certificates 182 Digital signatures using ECDSA MUST be used for authentication by 183 Suite B compliant implementations. To simplify notation, ECDSA-256 184 will be used to represent an instantiation of the ECDSA algorithm 185 using the P-256 curve and the SHA-256 hash function, and ECDSA-384 186 will be used to represent an instantiation of the ECDSA algorithm 187 using the P-384 curve and the SHA-384 hash function. 189 If configured at a minimum level of security of 128 bits, a Suite B 190 Kerberos implementation MUST use either ECDSA-256 or ECDSA-384 for 191 authentication. It is allowable for one party to authenticate with 192 ECDSA-256 and the other party to authenticate with ECDSA-384. This 193 flexibility will allow interoperability between a client and a 194 server that have different sizes of ECDSA authentication keys. 196 Clients and servers in a Suite B Kerberos implementation configured 197 at a minimum level of security of 128 bits MUST be able to verify 198 ECDSA-256 signatures and SHOULD be able to verify ECDSA-384 199 signatures unless it is absolutely certain that the implementation 200 will never need to verify certificates from an authority which uses 201 an ECDSA-384 signing key. 203 If configured at a minimum level of security of 192 bits, ECDSA-384 204 MUST be used by both parties for authentication. 206 Clients and servers in a Suite B Kerberos implementation configured 207 at a minimum level of security of 192 bits MUST be able to verify 208 ECDSA-384 signatures. 210 The client and server, at both minimum levels of security, MUST 211 each have an X.509 certificate that complies with the Suite B End 212 Entity Signature Certificate profile as defined in [RFC5759]. 214 5. PKINIT 216 This section specifies the use of Suite B algorithms for 217 integrating public key cryptography into the initial authentication 218 protocol (PKINIT). The use of public key certificates and 219 signature schemes allows the client and KDC to mutually 220 authenticate in the Authentication Service (AS) request and reply. 221 Furthermore, without PKINIT, the security strength of the AS reply 222 key is usually determined by the strength of the user's password. 223 Using a public key cryptography key exchange eliminates the 224 dependency of the AS reply key on a password, enhancing the security 225 of the Kerberos protocol. 227 The original protocol extensions which include public key 228 cryptography are described in PKINIT [RFC4556] and specifications 229 for using elliptic curve cryptography are presented in ECC for 230 PKINIT [RFC5349]. The majority of the conventions needed for Suite 231 B are in those two documents and only the necessary details are 232 provided here. 234 In Suite B, public key cryptography (PKINIT) MUST be used in the 235 initial authentication protocol to avoid the need for password- 236 based authentication. As defined in [RFC4556], one of the 237 following pre-authentication data elements MUST be included in the 238 AS_REQ and AS_REP messages. 240 padata-type Name Included in 241 ------------------------------------------ 242 16 PA_PK_AS_REQ AS_REQ 243 17 PA_PK_AS_REP AS_REP 245 The specific requirements for using ECDH and ECDSA in PKINIT are 246 presented in Sections 5.2 and 5.3 respectively. 248 5.1. Algorithm Agility 250 PKINIT [RFC4556] has several dependencies on SHA-1 as a checksum 251 algorithm. The first occurrence is the paChecksum field of the 252 PKAuthenticator structure in the authentication request which is 253 defined to contain the SHA-1 checksum of the KDC-REQ-BODY. PKINIT 254 also requires SHA-1 in the key derivation function used to derive 255 the AS reply key from the shared secret value generated by the 256 Diffie-Hellman key exchange. Since Suite B requires SHA-256 or 257 SHA-384 for hashing, the client and KDC need a method to negotiate 258 the hash algorithm used in PKINIT. 260 [alg-agility] updates PKINIT by allowing the client and KDC to 261 negotiate a KDF from [SP800-56A] which will provide integrity of 262 the request body as well as a cryptographic binding between the 263 client's pre-authentication data and the corresponding request 264 body. This is achieved as described in Section 6 of [alg-agility] 265 by including the AS-REQ and PA-PK-AS-REP messages and the ticket 266 from the KDC in the OtherInfo input parameter to the KDF. 268 Choosing a KDF from [SP800-56A] that uses SHA-256 or SHA-384 269 as the hash function therefore eliminates the need for the 270 paChecksum field. In Suite B, the client MUST NOT include the 271 SHA-1 checksum of the KDC-REQ-BODY in the paChecksum field of the 272 authentication request since the KDF will provide the desired 273 cryptographic binding and integrity protection. The KDC MUST NOT 274 return a KRB-ERROR message due to the absence of the paChecksum field 275 when validating the client's request since the paChecksum field is 276 optional syntactically in [RFC4556]. Section 6 of [alg-agility] 277 describes the new structures and fields included in the AS request 278 and reply messages. 280 In Suite B, one of the following KDFs defined in [alg-agility] MUST 281 be used to derive the AS reply key from the Diffie-Hellman shared 282 secret. 284 Key Derivation Function OID [alg-agility] 285 ----------------------------------------------- 286 id-pkinit-kdf-ah-sha256 1.3.6.1.5.2.3.6.2 287 id-pkinit-kdf-ah-sha384 TBD 289 5.2. ECDH Key Exchange 291 The use of elliptic curve cryptography in PKINIT is described in 292 [RFC5349]. This section describes the Suite B requirements for 293 using Elliptic Curve Diffie-Hellman (ECDH) to generate the AS reply 294 key. 296 In Suite B, ephemeral-ephemeral ECDH MUST be used as the AS reply 297 key agreement method. In a Suite B Kerberos system configured at a 298 minimum level of security of 128 bits, ephemeral-ephemeral ECDH 299 MUST be used with the SHA-256 KDF and the P-256 elliptic curve or 300 used with the SHA-384 KDF and the P-384 elliptic curve. In a Suite 301 B Kerberos system configured at a minimum level of security of 192 302 bits, ephemeral-ephemeral ECDH MUST be used with the SHA-384 KDF 303 and the P-384 elliptic curve. A detailed description of the uses 304 of the ECDH key exchange in PKINIT is provided in [RFC5349]. 306 The client MUST include its encoded ECDH ephemeral public key value 307 and domain parameters in the clientPublicValue field of the 308 AuthPack structure as described in [RFC4556]. The clientPublicValue 309 field MUST comply with the SubjectPublicKeyInfo guidance in [RFC5759] 310 Section 4.4. The domain parameters in the clientPublicValue field 311 MUST be for one of the following curves. Since the curves appear 312 under two different names, both names are listed below. 314 Curve NIST Name SECG Name OID [FIPS186-3] 315 --------------------------------------------------------- 316 nistp256 P-256 secp256r1 1.2.840.10045.3.1.7 317 nistp384 P-384 secp384r1 1.3.132.0.34 319 A description of the two curves can be found in [FIPS186-3] or 320 [SEC2]. 322 The KDC MUST include its encoded ECDH ephemeral public key value in 323 the subjectPublicKey field of the KDCDHKeyInfo structure in the 324 authentication reply. Section 2.2 of [RFC5480] provides guidance on 325 the format of the subjectPublicKey field. The KDC MUST NOT reuse its 326 DH keys, even if the client includes the clientDHNonce field. 327 Section 5.6.4.3 of [SP800-56A] states that an ephemeral private key 328 MUST be used in exactly one key establishment transaction, SHOULD be 329 generated as close to its time of use as possible and MUST be 330 zeroized after its use. Section 5.8 of [SP800-56A] states that the 331 Diffie-Hellman shared secret MUST be zeroized immediately after its 332 use. Suite B Kerberos implementations MUST follow the mandates in 333 SP800-56A. 335 The ECDH shared secret value (Z) is calculated using the ECSVDP-DH 336 primitive described in Section 7.2.1 of [IEEE1363]. Note this 337 primitive is also described in Section 5.7.1.2 of [SP800-56A] under 338 the name ECC CDH. 340 The AS reply key is derived from the ECDH shared secret value using 341 a negotiated key derivation function from [SP800-56A] with the 342 method described in Section 6 of [alg-agility]. The KDF based on 343 SHA-256 MUST be used when ECDH is used with the 256-bit prime 344 modulus elliptic curve and the KDF based on SHA-384 MUST be used 345 when ECDH is used with the 384-bit prime modulus elliptic curve. 346 Additional guidance on implementing the Ephemeral Unified Model Key 347 Agreement Scheme for Suite B is provided in [IG]. 349 5.3. ECDSA and X.509 Certificates 351 The use of elliptic curve signature schemes in PKINIT is described 352 in [RFC5349]. This section describes the use of digital signatures 353 and certificates that are compatible with Suite B. 355 The signatureAlgorithm field of the SignerInfo data type in both the 356 AS request and reply messages MUST contain one of the following 357 signature algorithm identifiers: 359 Signature Algorithm OID [FIPS186-3] 360 ------------------------------------------------ 361 ecdsa-with-Sha256 1.2.840.10045.4.3.2 362 ecdsa-with-Sha384 1.2.840.10045.4.3.3 364 If configured at a minimum level of security of 128 bits, a Suite B 365 Kerberos client MUST list one or both of ecdsa-with-sha256 and 366 ecdsa-with-sha384 in the supportedCMSTypes field of the 367 authentication request as the only acceptable signature algorithms 368 for the server's response. If configured at a minimum level of 369 security of 192 bits, a Suite B Kerberos client MUST list 370 ecdsa-with-sha384 in the supportedCMSTypes field of the 371 authentication request as the only acceptable signature algorithm for 372 the server's response. 374 The corresponding digestAlgorithm field of the SignerInfo data type 375 MUST contain one of the following hash algorithm identifiers. 377 Hash Algorithm OID [FIPS180-3] 378 --------------------------------------------------- 379 id-sha256 2.16.840.1.101.3.4.2.2 380 id-sha384 2.16.840.1.101.3.4.2.3 382 id-sha256 MUST be used with ecdsa-with-Sha256 and id-sha384 MUST be 383 used with ecdsa-with-Sha384, as noted in [RFC5349]. 385 6. Encryption and Checksum Types 387 Encryption and checksum types for Kerberos 5 are described in 388 [RFC3961] and specifications for using AES in Kerberos 5 are 389 detailed in [RFC3962]. The dependencies of those types on SHA-1 make 390 them inappropriate choices for Suite B. [AES-CBC-SHA2] defines the 391 encryption and checksum types required by Suite B. 393 6.1. Suite B Requirements 395 If configured at a minimum level of security of 128 bits, a Suite B 396 Kerberos implementation MUST use either the combination of 397 aes128-cbc-hmac-sha256-128 for content encryption and 398 hmac-sha256-128-aes-128 for message integrity or the combination of 399 aes256-cbc-hmac-sha384-192 for content encryption and 400 hmac-sha384-192-aes256 for message integrity. 402 If configured at a minimum level of security of 192 bits, a Suite B 403 Kerberos implementation MUST use aes256-cbc-hmac-sha384-192 for 404 content encryption and hmac-sha384-192-aes256 for message integrity. 406 If the Suite B Kerberos client is using ECDH P-256 for its ephemeral 407 public key in its request, it MUST list aes128-cbc-hmac-sha256-128 in 408 the etype field of the req-body in the initial request message. If 409 the Suite B Kerberos client is using ECDH P-384 for its ephemeral 410 public key in its request, it MUST list aes256-cbc-hmac-sha384-192 in 411 the etype field of the req-body in the initial request message. 413 7. Security Considerations 415 The security considerations in [RFC4556] discuss PKINIT in general 416 and the security considerations in [RFC5349] discuss the use of 417 elliptic curve cryptography (ECC). 419 8. IANA Considerations 421 No IANA considerations. 423 9. References 425 9.1. Normative References 427 [alg-agility] 428 Astrand, L. and L. Zhu, "PK-INIT algorithm agility", 429 draft-ietf-krb-wg-pkinit-alg-agility-04, August 2008. 431 [IEEE1363] IEEE, "Standard Specifications for Public Key 432 Cryptography", IEEE 1363, 2000. 434 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 435 Requirement Levels", BCP 14, RFC 2119, March 1997. 437 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications 438 for Kerberos 5", RFC 3961, February 2005. 440 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 441 Encryption for Kerberos 5", RFC 3962, February 2005. 443 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for 444 Initial Authentication in Kerberos (PKINIT)", 445 RFC 4556, June 2006. 447 [RFC5349] Zhu, L., Jaganathan, K. and K. Lauter, "Elliptic Curve 448 Cryptography (ECC) Support for Public Key Cryptography 449 for Initial Authentication in Kerberos (PKINIT)", RFC 450 5349, September 2008. 452 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. 453 Polk, "Elliptic Curve Cryptography Subject Public Key 454 Information", RFC 5480, March 2009. 456 [RFC5759] Solinas, J. and L. Zieglar, "Suite B certificate and 457 Certificate Revocation List (CRL) Profile", RFC 5759, 458 January 2010. 460 [FIPS180-3] National Institute of Standards and Technology, 461 "Secure Hash Standard", FIPS PUB 180-3, October 2008. 463 [FIPS186-3] National Institute of Standards and Technology, 464 "Digital Signature Standard (DSS)", FIPS PUB 186-3, 465 June 2009. 467 [FIPS197] National Institute of Standards and Technology, 468 "Advanced Encryption Standard (AES)", FIPS PUB 197, 469 November 2001. 471 9.2. Informative References 473 [IG] U.S. National Security Agency, "Suite B Implementers' 474 Guide to NIST SP 800-56A", July 2009, 475 [http://www.nsa.gov/ia/_files/ 476 SuiteB_Implementer_G-113808.pdf]. 478 [NSA] U.S. National Security Agency, "Fact Sheet NSA Suite B 479 Cryptography", January 2009, 480 [http://www.nsa.gov/ia/programs/suiteb_cryptography/]. 482 [SEC2] Standards for Efficient Cryptography Group, "SEC 2 - 483 Recommended Elliptic Curve Domain Parameters", 484 Ver. 1.0, 2000, [http://www.secg.org]. 486 [SP800-56A] 487 National Institute of Standards and Technology, 488 "Recommendation for Pair-wise Key Establishment Schemes 489 Using Discrete Logarithm Cryptography", NIST Special 490 Publication 800-56A, March 2007. 492 [AES-CBC-SHA2] 493 Burgin, K. and M. Peck, "AES-CBC Mode with HMAC-SHA2 For 494 Kerberos 5", draft-burgin-kerberos-aes-cbc-hmac-sha2-00, 495 (work in progress), June 2011. 497 Appendix A. Acknowledgements 499 The authors would like to thank Mike Peck for his initial work on 500 this document, useful discussions on AES modes and his thorough 501 review of the final draft. 503 Authors' addresses 505 Kelley W. Burgin 506 National Security Agency 508 EMail: kwburgi@tycho.ncsc.mil 510 Kevin M. Igoe 511 NSA/CSS Commercial Solutions Center 512 National Security Agency 514 EMail: kmigoe@nsa.gov