Network Working Group K.W. Burgin
Internet Draft K.M. Igoe
Intended Status: Informational National Security Agency
Expires: December 10, 2011 June 8, 2011
Suite B in Kerberos 5
draft-burgin-kerberos-suiteb-00
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.
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 December 10, 2011.
Copyright Notice
Copyright (c) 2011 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
(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
described in the Simplified BSD License.
Burgin & Igoe Expires December 10, 2011 [Page 1]
Internet-Draft Suite B in Kerberos 5 June 2011
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) ........................... 4
4.1. Non-signature Primitives ................................ 4
4.2. Digital Signatures and Certificates ..................... 5
5. PKINIT ........................................................ 5
5.1. Algorithm Agility ....................................... 6
5.2. ECDH Key Exchange ....................................... 7
5.3. ECDSA and X.509 v3 Certificates ......................... 8
6. Encryption and Checksum Types ................................. 9
6.1. Suite B Requirements .................................... 9
7. Security Considerations ....................................... 9
8. IANA Considerations .......................................... 10
9. References ................................................... 10
9.1. Normative References ................................... 10
9.2. Informative References ................................. 11
Appendix A. Acknowledgements .................................... 11
Burgin & Igoe Expires December 10, 2011 [Page 2]
Internet-Draft Suite B in Kerberos 5 June 2011
1. Introduction
The Fact Sheet on National Security Agency (NSA) Suite B Cryptography
[NSA] states:
A Cryptographic Interoperability Strategy (CIS) was developed to
find ways to increase assured rapid sharing of information both
within the U.S. and between the U.S. and her partners through
the use of a common suite of public standards, protocols,
algorithms and modes referred to as the "Secure Sharing Suite"
or S.3 The implementation of CIS will facilitate the development
of a broader range of secure cryptographic products which will
be available to a wide customer base. The use of selected
public cryptographic standards and protocols and Suite B is the
core of CIS.
In 2005, NSA announced Suite B Cryptography which built upon the
National Policy on the use of the Advanced Encryption Standard
(AES) to Protect National Security Systems and National Security
Information. In addition to the AES algorithm, Suite B includes
cryptographic algorithms for key exchanges, digital signatures
and hashing. Suite B cryptography has been selected from
cryptography that has been approved by NIST for use by the U.S.
Government and specified in NIST standards or recommendations.
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].
Burgin & Igoe Expires December 10, 2011 [Page 3]
Internet-Draft Suite B in Kerberos 5 June 2011
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 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.
Burgin & Igoe Expires December 10, 2011 [Page 4]
Internet-Draft Suite B in Kerberos 5 June 2011
At the 192-bit minimum level of security:
- the non-signature primitives MUST come exclusively from
Column 2.
4.2. Digital Signatures and Certificates
Digital signatures using ECDSA MUST be used for authentication by
Suite B compliant 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
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.
The client and server, at both minimum levels of security, MUST
each have an X.509 certificate that complies with the Suite B End
Entity Signature Certificate profile as defined in [RFC5759].
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, without PKINIT, the security strength of the AS reply
key is usually determined by the strength of the user's password.
Using a public key cryptography key exchange eliminates the
Burgin & Igoe Expires December 10, 2011 [Page 5]
Internet-Draft Suite B in Kerberos 5 June 2011
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
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
authentication request since the KDF will provide the desired
Burgin & Igoe Expires December 10, 2011 [Page 6]
Internet-Draft Suite B in Kerberos 5 June 2011
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 TBD
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.
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 domain parameters in the clientPublicValue field
MUST be for one of the following curves. Since the curves appear
under two different names, both names are listed 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
A description of the two curves can be found in [FIPS186-3] or
[SEC2].
Burgin & Igoe Expires December 10, 2011 [Page 7]
Internet-Draft Suite B in Kerberos 5 June 2011
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 and X.509 Certificates
The use of elliptic curve signature schemes in PKINIT is described
in [RFC5349]. This section describes the use of digital signatures
and certificates that are compatible with Suite B.
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
ecdsa-with-sha384 in the supportedCMSTypes field of the
Burgin & Igoe Expires December 10, 2011 [Page 8]
Internet-Draft Suite B in Kerberos 5 June 2011
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-cbc-hmac-sha256-128 for content encryption and
hmac-sha256-128-aes-128 for message integrity or the combination of
aes256-cbc-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-cbc-hmac-sha384-192 for
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-cbc-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-cbc-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).
Burgin & Igoe Expires December 10, 2011 [Page 9]
Internet-Draft Suite B in Kerberos 5 June 2011
8. IANA Considerations
No IANA considerations.
9. References
9.1. Normative References
[alg-agility]
Astrand, L. and L. Zhu, "PK-INIT algorithm agility",
draft-ietf-krb-wg-pkinit-alg-agility-04, August 2008.
[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.
[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.
Burgin & Igoe Expires December 10, 2011 [Page 10]
Internet-Draft Suite B in Kerberos 5 June 2011
[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/].
[SEC2] Standards for Efficient Cryptography Group, "SEC 2 -
Recommended Elliptic Curve Domain Parameters",
Ver. 1.0, 2000, [http://www.secg.org].
[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.
[AES-CBC-SHA2]
Burgin, K. and M. Peck, "AES-CBC Mode with HMAC-SHA2 For
Kerberos 5", draft-burgin-kerberos-aes-cbc-hmac-sha2-00,
(work in progress), June 2011.
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.
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 December 10, 2011 [Page 11]