Internet DRAFT - draft-burgin-kerberos-suiteb
draft-burgin-kerberos-suiteb
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]
