Network Working Group K. Burgin Internet Draft K. Igoe Intended Status: Informational National Security Agency Expires: April 22, 2013 October 19, 2012 Suite B Profile for Kerberos 5 draft-burgin-kerberos-suiteb-01 Abstract The United States Government has published guidelines for "NSA Suite B Cryptography" dated July, 2005, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using Suite B algorithms in the Kerberos 5 protocol specification. Since many of the Suite B algorithms enjoy uses in other environments as well, the majority of the conventions needed for the Suite B algorithms are already specified in other documents. This document references the source of these conventions, with some relevant details repeated to aid developers that choose to support Suite B. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 21, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Burgin & Igoe Expires April 22, 2013 [Page 1] Internet-Draft Suite B Profile for Kerberos 5 October 19, 2012 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this Document . . . . . . . . . . . . . . 3 3. Suite B Requirements . . . . . . . . . . . . . . . . . . . . . 3 4. Minimum Levels of Security (minLOS) . . . . . . . . . . . . . 3 4.1. Non-signature Primitives . . . . . . . . . . . . . . . . . 4 4.2. Suite B Authentication . . . . . . . . . . . . . . . . . . 4 4.3. Digital Signatures and Certificates . . . . . . . . . . . 5 5. PKINIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Algorithm Agility . . . . . . . . . . . . . . . . . . . . 6 5.2. ECDH Key Exchange . . . . . . . . . . . . . . . . . . . . 6 5.3. ECDSA Digital Signatures . . . . . . . . . . . . . . . . . 7 6. Encryption and Checksum Types . . . . . . . . . . . . . . . . 8 6.1. Suite B Requirements . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 Authors' addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Burgin & Igoe Expires April 22, 2013 [Page 2] Internet-Draft Suite B Profile for Kerberos 5 October 19, 2012 1. Introduction This document specifies the use of the United States National Security Agency's Suite B algorithms [NSA] in Kerberos 5. Symmetric key encryption algorithms and checksum types are specified for use in the protocol. Additionally, the use of elliptic curve cryptography in the initial authentication protocol (PKINIT) is specified. 2. Conventions used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Suite B Requirements Suite B requires that key establishment and signature algorithms be based upon Elliptic Curve Cryptography and that the encryption algorithm be AES [FIPS197]. Suite B includes [NSA]: Encryption: Advanced Encryption Standard (AES) [FIPS197] (key sizes of 128 and 256 bits) Digital Signature: Elliptic Curve Digital Signature Algorithm (ECDSA) [FIPS186-3] (using the curves with 256- and 384-bit prime moduli) Key Exchange: Elliptic Curve Diffie-Hellman (ECDH) [SP800-56A] (using the curves with 256- and 384-bit prime moduli) Hashes: SHA-256 and SHA-384 [FIPS180-3] The two elliptic curves used in Suite B each appear in the literature under two different names. For sake of clarity, we list both names below: Curve NIST Name SECG Name OID [FIPS186-3] --------------------------------------------------------- nistp256 P-256 secp256r1 1.2.840.10045.3.1.7 nistp384 P-384 secp384r1 1.3.132.0.34 4. Minimum Levels of Security (minLOS) Suite B provides for two levels of cryptographic security, namely a 128-bit minimum level of security (minLOS_128) and a 192-bit minimum Burgin & Igoe Expires April 22, 2013 [Page 3] Internet-Draft Suite B Profile for Kerberos 5 October 19, 2012 level of security (minLOS_192). Each level defines a minimum strength that all cryptographic algorithms must provide. 4.1. Non-signature Primitives We divide the Suite B non-signature primitives into two columns as shown in Table 1. Column 1 Column 2 +-------------------+------------------+ Encryption | AES-128 | AES-256 | +-------------------+------------------+ Key Agreement | ECDH on P-256 | ECDH on P-384 | +-------------------+------------------+ Hash for PRF/MAC | SHA-256 | SHA-384 | +-------------------+------------------+ Table 1: Suite B Cryptographic Non-Signature Primitives At the 128-bit minimum level of security: - the non-signature primitives MUST either come exclusively from Column 1 or exclusively from Column 2. At the 192-bit minimum level of security: - the non-signature primitives MUST come exclusively from Column 2. 4.2. Suite B Authentication Digital signatures using ECDSA MUST be used for authentication by Suite B compliant Kerberos implementations. To simplify notation, ECDSA-256 will be used to represent an instantiation of the ECDSA algorithm using the P-256 curve and the SHA-256 hash function, and ECDSA-384 will be used to represent an instantiation of the ECDSA algorithm using the P-384 curve and the SHA-384 hash function. If configured at a minimum level of security of 128 bits, a Suite B Kerberos implementation MUST use either ECDSA-256 or ECDSA-384 for authentication. It is allowable for one party to authenticate with ECDSA-256 and the other party to authenticate with ECDSA-384. This flexibility will allow interoperability between a client and a server that have different sizes of ECDSA authentication keys. Clients and servers in a Suite B Kerberos implementation configured at a minimum level of security of 128 bits MUST be able to verify ECDSA-256 signatures and SHOULD be able to verify ECDSA-384 Burgin & Igoe Expires April 22, 2013 [Page 4] Internet-Draft Suite B Profile for Kerberos 5 October 19, 2012 signatures unless it is absolutely certain that the implementation will never need to verify certificates from an authority which uses an ECDSA-384 signing key. If configured at a minimum level of security of 192 bits, ECDSA-384 MUST be used by both parties for authentication. Clients and servers in a Suite B Kerberos implementation configured at a minimum level of security of 192 bits MUST be able to verify ECDSA-384 signatures. 4.3. Digital Signatures and Certificates The client and server in a Suite B compliant Kerberos implementation, at both minimum levels of security, MUST each use an X.509 certificate that complies with the "Suite B Certificate and Certificate Revocation List (CRL) Profile" [RFC5759] and that contains an elliptic curve public key with the key usage field set for digital signature. 5. PKINIT This section specifies the use of Suite B algorithms for integrating public key cryptography into the initial authentication protocol (PKINIT). The use of public key certificates and signature schemes allows the client and KDC to mutually authenticate in the Authentication Service (AS) request and reply. Furthermore, PKINIT eliminates the dependency of the AS reply key on a password, enhancing the security of the Kerberos protocol. The original protocol extensions which include public key cryptography are described in PKINIT [RFC4556] and specifications for using elliptic curve cryptography are presented in ECC for PKINIT [RFC5349]. The majority of the conventions needed for Suite B are in those two documents and only the necessary details are provided here. In Suite B, public key cryptography (PKINIT) MUST be used in the initial authentication protocol to avoid the need for password-based authentication. As defined in [RFC4556], one of the following pre- authentication data elements MUST be included in the AS_REQ and AS_REP messages. padata-type Name Included in ------------------------------------------ 16 PA_PK_AS_REQ AS_REQ 17 PA_PK_AS_REP AS_REP Burgin & Igoe Expires April 22, 2013 [Page 5] Internet-Draft Suite B Profile for Kerberos 5 October 19, 2012 The specific requirements for using ECDH and ECDSA in PKINIT are presented in Sections 5.2 and 5.3 respectively. 5.1. Algorithm Agility PKINIT [RFC4556] has several dependencies on SHA-1 as a checksum algorithm. The first occurrence is the paChecksum field of the PKAuthenticator structure in the authentication request which is defined to contain the SHA-1 checksum of the KDC-REQ-BODY. PKINIT also requires SHA-1 in the key derivation function used to derive the AS reply key from the shared secret value generated by the Diffie-Hellman key exchange. Since Suite B requires SHA-256 or SHA-384 for hashing, the client and KDC need a method to negotiate the hash algorithm used in PKINIT. [alg-agility] updates PKINIT by allowing the client and KDC to negotiate a KDF from [SP800-56A] which will provide integrity of the request body as well as a cryptographic binding between the client's pre-authentication data and the corresponding request body. This is achieved as described in Section 6 of [alg-agility] by including the AS-REQ and PA-PK-AS-REP messages and the ticket from the KDC in the OtherInfo input parameter to the KDF. Choosing a KDF from [SP800-56A] that uses SHA-256 or SHA-384 as the hash function therefore eliminates the need for the paChecksum field. In Suite B, the client MUST NOT include the SHA-1 checksum of the KDC-REQ-BODY in the paChecksum field of the cryptographic binding and integrity protection. The KDC MUST NOT return a KRB-ERROR message due to the absence of the paChecksum field when validating the client's request since the paChecksum field is optional syntactically in [RFC4556]. Section 6 of [alg-agility] describes the new structures and fields included in the AS request and reply messages. In Suite B, one of the following KDFs defined in [alg-agility] MUST be used to derive the AS reply key from the Diffie-Hellman shared secret. Key Derivation Function OID [alg-agility] ----------------------------------------------- id-pkinit-kdf-ah-sha256 1.3.6.1.5.2.3.6.2 id-pkinit-kdf-ah-sha384 1.3.6.1.5.2.3.6.4 5.2. ECDH Key Exchange The use of elliptic curve cryptography in PKINIT is described in [RFC5349]. This section describes the Suite B requirements for using Elliptic Curve Diffie-Hellman (ECDH) to generate the AS reply key. Burgin & Igoe Expires April 22, 2013 [Page 6] Internet-Draft Suite B Profile for Kerberos 5 October 19, 2012 In Suite B, ephemeral-ephemeral ECDH MUST be used as the AS reply key agreement method. In a Suite B Kerberos system configured at a minimum level of security of 128 bits, ephemeral-ephemeral ECDH MUST be used with the SHA-256 KDF and the P-256 elliptic curve or used with the SHA-384 KDF and the P-384 elliptic curve. In a Suite B Kerberos system configured at a minimum level of security of 192 bits, ephemeral-ephemeral ECDH MUST be used with the SHA-384 KDF and the P-384 elliptic curve. A detailed description of the uses of the ECDH key exchange in PKINIT is provided in [RFC5349]. The client MUST include its encoded ECDH ephemeral public key value and domain parameters in the clientPublicValue field of the AuthPack structure as described in [RFC4556]. The clientPublicValue field MUST comply with the SubjectPublicKeyInfo guidance in [RFC5759] Section 4.4. The KDC MUST include its encoded ECDH ephemeral public key value in the subjectPublicKey field of the KDCDHKeyInfo structure in the authentication reply. Section 2.2 of [RFC5480] provides guidance on the format of the subjectPublicKey field. The KDC MUST NOT reuse its DH keys, even if the client includes the clientDHNonce field. Section 5.6.4.3 of [SP800-56A] states that an ephemeral private key MUST be used in exactly one key establishment transaction, SHOULD be generated as close to its time of use as possible and MUST be zeroized after its use. Section 5.8 of [SP800-56A] states that the Diffie-Hellman shared secret MUST be zeroized immediately after its use. Suite B Kerberos implementations MUST follow the mandates in SP800-56A. The ECDH shared secret value (Z) is calculated using the ECSVDP-DH primitive described in Section 7.2.1 of [IEEE1363]. Note this primitive is also described in Section 5.7.1.2 of [SP800-56A] under the name ECC CDH. The AS reply key is derived from the ECDH shared secret value using a negotiated key derivation function from [SP800-56A] with the method described in Section 6 of [alg-agility]. The KDF based on SHA-256 MUST be used when ECDH is used with the 256-bit prime modulus elliptic curve and the KDF based on SHA-384 MUST be used when ECDH is used with the 384-bit prime modulus elliptic curve. Additional guidance on implementing the Ephemeral Unified Model Key Agreement Scheme for Suite B is provided in [IG]. 5.3. ECDSA Digital Signatures The use of elliptic curve signature schemes in PKINIT is described in [RFC5349]. This section describes the use of digital signatures that are compatible with Suite B. Burgin & Igoe Expires April 22, 2013 [Page 7] Internet-Draft Suite B Profile for Kerberos 5 October 19, 2012 The signatureAlgorithm field of the SignerInfo data type in both the AS request and reply messages MUST contain one of the following signature algorithm identifiers: Signature Algorithm OID [FIPS186-3] ------------------------------------------------ ecdsa-with-Sha256 1.2.840.10045.4.3.2 ecdsa-with-Sha384 1.2.840.10045.4.3.3 If configured at a minimum level of security of 128 bits, a Suite B Kerberos client MUST list one or both of ecdsa-with-sha256 and ecdsa-with-sha384 in the supportedCMSTypes field of the authentication request as the only acceptable signature algorithms for the server's response. If configured at a minimum level of security of 192 bits, a Suite B Kerberos client MUST list authentication request as the only acceptable signature algorithm for the server's response. The corresponding digestAlgorithm field of the SignerInfo data type MUST contain one of the following hash algorithm identifiers. Hash Algorithm OID [FIPS180-3] --------------------------------------------------- id-sha256 2.16.840.1.101.3.4.2.2 id-sha384 2.16.840.1.101.3.4.2.3 id-sha256 MUST be used with ecdsa-with-Sha256 and id-sha384 MUST be used with ecdsa-with-Sha384, as noted in [RFC5349]. 6. Encryption and Checksum Types Encryption and checksum types for Kerberos 5 are described in [RFC3961] and specifications for using AES in Kerberos 5 are detailed in [RFC3962]. The dependencies of those types on SHA-1 make them inappropriate choices for Suite B. [AES-CBC-SHA2] defines the encryption and checksum types required by Suite B. 6.1. Suite B Requirements If configured at a minimum level of security of 128 bits, a Suite B Kerberos implementation MUST use either the combination of aes128-cts-hmac-sha256-128 for content encryption and hmac-sha256-128-aes-128 for message integrity or the combination of aes256-cts-hmac-sha384-192 for content encryption and hmac-sha384-192-aes256 for message integrity. If configured at a minimum level of security of 192 bits, a Suite B Kerberos implementation MUST use aes256-cts-hmac-sha384-192 for Burgin & Igoe Expires April 22, 2013 [Page 8] Internet-Draft Suite B Profile for Kerberos 5 October 19, 2012 content encryption and hmac-sha384-192-aes256 for message integrity. If the Suite B Kerberos client is using ECDH P-256 for its ephemeral public key in its request, it MUST list aes128-cts-hmac-sha256-128 in the etype field of the req-body in the initial request message. If the Suite B Kerberos client is using ECDH P-384 for its ephemeral public key in its request, it MUST list aes256-cts-hmac-sha384-192 in the etype field of the req-body in the initial request message. 7. Security Considerations The security considerations in [RFC4556] discuss PKINIT in general and the security considerations in [RFC5349] discuss the use of elliptic curve cryptography (ECC). 8. IANA Considerations None. 9. References 9.1. Normative References [AES-CBC-SHA2] Burgin, K. and M. Peck, "AES Encryption with HMAC-SHA2 for Kerberos 5", draft-burgin-kerberos-aes-cbc-hmac- sha2-02, (work in progress), June 2011. [alg-agility] Astrand, L., Zhu, L., and M. Wasserman, "PKINIT Algorithm Agility", draft-ietf-krb-wg-pkinit-alg- agility-06, March 2012. [IEEE1363] IEEE, "Standard Specifications for Public Key Cryptography", IEEE 1363, 2000. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005. [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) Encryption for Kerberos 5", RFC 3962, February 2005. [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. Burgin & Igoe Expires April 22, 2013 [Page 9] Internet-Draft Suite B Profile for Kerberos 5 October 19, 2012 [RFC5349] Zhu, L., Jaganathan, K. and K. Lauter, "Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 5349, September 2008. [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009. [RFC5759] Solinas, J. and L. Zieglar, "Suite B certificate and Certificate Revocation List (CRL) Profile", RFC 5759, January 2010. [FIPS180-3] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-3, October 2008. [FIPS186-3] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-3, June 2009. [FIPS197] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001. 9.2. Informative References [IG] U.S. National Security Agency, "Suite B Implementers' Guide to NIST SP 800-56A", July 2009, [http://www.nsa.gov/ia/_files/ SuiteB_Implementer_G-113808.pdf]. [NSA] U.S. National Security Agency, "Fact Sheet NSA Suite B Cryptography", January 2009, [http://www.nsa.gov/ia/programs/suiteb_cryptography/]. [SP800-56A] National Institute of Standards and Technology, "Recommendation for Pair-wise Key Establishment Schemes Using Discrete Logarithm Cryptography", NIST Special Publication 800-56A, March 2007. Appendix A. Acknowledgements The authors would like to thank Mike Peck for his initial work on this document, useful discussions on AES modes and his thorough review of the final draft. Burgin & Igoe Expires April 22, 2013 [Page 10] Internet-Draft Suite B Profile for Kerberos 5 October 19, 2012 Authors' addresses Kelley W. Burgin National Security Agency EMail: kwburgi@tycho.ncsc.mil Kevin M. Igoe NSA/CSS Commercial Solutions Center National Security Agency EMail: kmigoe@nsa.gov Burgin & Igoe Expires April 22, 2013 [Page 11]