summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4556.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4556.txt')
-rw-r--r--doc/rfc/rfc4556.txt2355
1 files changed, 2355 insertions, 0 deletions
diff --git a/doc/rfc/rfc4556.txt b/doc/rfc/rfc4556.txt
new file mode 100644
index 0000000..2ff9439
--- /dev/null
+++ b/doc/rfc/rfc4556.txt
@@ -0,0 +1,2355 @@
+
+
+
+
+
+
+Network Working Group L. Zhu
+Request for Comments: 4556 Microsoft Corporation
+Category: Standards Track B. Tung
+ Aerospace Corporation
+ June 2006
+
+
+ Public Key Cryptography for
+ Initial Authentication in Kerberos (PKINIT)
+
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document describes protocol extensions (hereafter called PKINIT)
+ to the Kerberos protocol specification. These extensions provide a
+ method for integrating public key cryptography into the initial
+ authentication exchange, by using asymmetric-key signature and/or
+ encryption algorithms in pre-authentication data fields.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Conventions Used in This Document ...............................4
+ 3. Extensions ......................................................5
+ 3.1. Definitions, Requirements, and Constants ...................6
+ 3.1.1. Required Algorithms .................................6
+ 3.1.2. Recommended Algorithms ..............................6
+ 3.1.3. Defined Message and Encryption Types ................7
+ 3.1.4. Kerberos Encryption Types Defined for CMS
+ Algorithm Identifiers ...............................8
+ 3.2. PKINIT Pre-authentication Syntax and Use ...................9
+ 3.2.1. Generation of Client Request ........................9
+ 3.2.2. Receipt of Client Request ..........................14
+ 3.2.3. Generation of KDC Reply ............................18
+ 3.2.3.1. Using Diffie-Hellman Key Exchange .........21
+ 3.2.3.2. Using Public Key Encryption ...............23
+
+
+
+Zhu & Tung Standards Track [Page 1]
+
+RFC 4556 PKINIT June 2006
+
+
+ 3.2.4. Receipt of KDC Reply ...............................25
+ 3.3. Interoperability Requirements .............................26
+ 3.4. KDC Indication of PKINIT Support ..........................27
+ 4. Security Considerations ........................................27
+ 5. Acknowledgements ...............................................30
+ 6. References .....................................................30
+ 6.1. Normative References ......................................30
+ 6.2. Informative References ....................................32
+ Appendix A. PKINIT ASN.1 Module ..................................33
+ Appendix B. Test Vectors .........................................38
+ Appendix C. Miscellaneous Information about Microsoft Windows
+ PKINIT Implementations ...............................40
+
+1. Introduction
+
+ The Kerberos V5 protocol [RFC4120] involves use of a trusted third
+ party known as the Key Distribution Center (KDC) to negotiate shared
+ session keys between clients and services and provide mutual
+ authentication between them.
+
+ The corner-stones of Kerberos V5 are the Ticket and the
+ Authenticator. A Ticket encapsulates a symmetric key (the ticket
+ session key) in an envelope (a public message) intended for a
+ specific service. The contents of the Ticket are encrypted with a
+ symmetric key shared between the service principal and the issuing
+ KDC. The encrypted part of the Ticket contains the client principal
+ name, among other items. An Authenticator is a record that can be
+ shown to have been recently generated using the ticket session key in
+ the associated Ticket. The ticket session key is known by the client
+ who requested the ticket. The contents of the Authenticator are
+ encrypted with the associated ticket session key. The encrypted part
+ of an Authenticator contains a timestamp and the client principal
+ name, among other items.
+
+ As shown in Figure 1, below, the Kerberos V5 protocol consists of the
+ following message exchanges between the client and the KDC, and the
+ client and the application service:
+
+ - The Authentication Service (AS) Exchange
+
+ The client obtains an "initial" ticket from the Kerberos
+ authentication server (AS), typically a Ticket Granting Ticket
+ (TGT). The AS-REQ message and the AS-REP message are the request
+ and the reply message, respectively, between the client and the
+ AS.
+
+
+
+
+
+
+Zhu & Tung Standards Track [Page 2]
+
+RFC 4556 PKINIT June 2006
+
+
+ - The Ticket Granting Service (TGS) Exchange
+
+ The client subsequently uses the TGT to authenticate and request a
+ service ticket for a particular service, from the Kerberos
+ ticket-granting server (TGS). The TGS-REQ message and the TGS-REP
+ message are the request and the reply message respectively between
+ the client and the TGS.
+
+ - The Client/Server Authentication Protocol (AP) Exchange
+
+ The client then makes a request with an AP-REQ message, consisting
+ of a service ticket and an authenticator that certifies the
+ client's possession of the ticket session key. The server may
+ optionally reply with an AP-REP message. AP exchanges typically
+ negotiate session-specific symmetric keys.
+
+ Usually, the AS and TGS are integrated in a single device also known
+ as the KDC.
+
+ +--------------+
+ +--------->| KDC |
+ AS-REQ / +-------| |
+ / / +--------------+
+ / / ^ |
+ / |AS-REP / |
+ | | / TGS-REQ + TGS-REP
+ | | / /
+ | | / /
+ | | / +---------+
+ | | / /
+ | | / /
+ | | / /
+ | v / v
+ ++-------+------+ +-----------------+
+ | Client +------------>| Application |
+ | | AP-REQ | Server |
+ | |<------------| |
+ +---------------+ AP-REP +-----------------+
+
+ Figure 1: The Message Exchanges in the Kerberos V5 Protocol
+
+ In the AS exchange, the KDC reply contains the ticket session key,
+ among other items, that is encrypted using a key (the AS reply key)
+ shared between the client and the KDC. The AS reply key is typically
+ derived from the client's password for human users. Therefore, for
+ human users, the attack resistance strength of the Kerberos protocol
+ is no stronger than the strength of their passwords.
+
+
+
+
+Zhu & Tung Standards Track [Page 3]
+
+RFC 4556 PKINIT June 2006
+
+
+ The use of asymmetric cryptography in the form of X.509 certificates
+ [RFC3280] is popular for facilitating data origin authentication and
+ perfect secrecy. An established Public Key Infrastructure (PKI)
+ provides key management and key distribution mechanisms that can be
+ used to establish authentication and secure communication. Adding
+ public-key cryptography to Kerberos provides a nice congruence to
+ public-key protocols, obviates the human users' burden to manage
+ strong passwords, and allows Kerberized applications to take
+ advantage of existing key services and identity management.
+
+ The advantage afforded by the Kerberos TGT is that the client exposes
+ his long-term secrets only once. The TGT and its associated session
+ key can then be used for any subsequent service ticket requests. One
+ result of this is that all further authentication is independent of
+ the method by which the initial authentication was performed.
+ Consequently, initial authentication provides a convenient place to
+ integrate public-key cryptography into Kerberos authentication. In
+ addition, the use of symmetric cryptography after the initial
+ exchange is preferred for performance.
+
+ This document describes the methods and data formats using which the
+ client and the KDC can use public and private key pairs to mutually
+ authenticate in the AS exchange and negotiate the AS reply key, known
+ only by the client and the KDC, to encrypt the AS-REP sent by the
+ KDC.
+
+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].
+
+ In this protocol, both the client and the KDC have a public-private
+ key pair in order to prove their identities to each other over the
+ open network. The term "signature key" is used to refer to the
+ private key of the key pair being used.
+
+ The encryption key used to encrypt the enc-part field of the KDC-REP
+ in the AS-REP [RFC4120] is referred to as the AS reply key.
+
+ An empty sequence in an optional field can be either included or
+ omitted: both encodings are permitted and considered equivalent.
+
+ The term "Modular Exponential Diffie-Hellman" is used to refer to the
+ Diffie-Hellman key exchange, as described in [RFC2631], in order to
+ differentiate it from other equivalent representations of the same
+ key agreement algorithm.
+
+
+
+
+Zhu & Tung Standards Track [Page 4]
+
+RFC 4556 PKINIT June 2006
+
+
+3. Extensions
+
+ This section describes extensions to [RFC4120] for supporting the use
+ of public-key cryptography in the initial request for a ticket.
+
+ Briefly, this document defines the following extensions to [RFC4120]:
+
+ 1. The client indicates the use of public-key authentication by
+ including a special preauthenticator in the initial request. This
+ preauthenticator contains the client's public-key data and a
+ signature.
+
+ 2. The KDC tests the client's request against its authentication
+ policy and trusted Certification Authorities (CAs).
+
+ 3. If the request passes the verification tests, the KDC replies as
+ usual, but the reply is encrypted using either:
+
+ a. a key generated through a Diffie-Hellman (DH) key exchange
+ [RFC2631] [IEEE1363] with the client, signed using the KDC's
+ signature key; or
+
+ b. a symmetric encryption key, signed using the KDC's signature
+ key and encrypted using the client's public key.
+
+ Any keying material required by the client to obtain the
+ encryption key for decrypting the KDC reply is returned in a pre-
+ authentication field accompanying the usual reply.
+
+ 4. The client validates the KDC's signature, obtains the encryption
+ key, decrypts the reply, and then proceeds as usual.
+
+ Section 3.1 of this document enumerates the required algorithms and
+ necessary extension message types. Section 3.2 describes the
+ extension messages in greater detail.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Tung Standards Track [Page 5]
+
+RFC 4556 PKINIT June 2006
+
+
+3.1. Definitions, Requirements, and Constants
+
+3.1.1. Required Algorithms
+
+ All PKINIT implementations MUST support the following algorithms:
+
+ o AS reply key enctypes: aes128-cts-hmac-sha1-96 and aes256-cts-
+ hmac-sha1-96 [RFC3962].
+
+ o Signature algorithm: sha-1WithRSAEncryption [RFC3370].
+
+ o AS reply key delivery method: the Diffie-Hellman key delivery
+ method, as described in Section 3.2.3.1.
+
+ In addition, implementations of this specification MUST be capable of
+ processing the Extended Key Usage (EKU) extension and the id-pkinit-
+ san (as defined in Section 3.2.2) otherName of the Subject
+ Alternative Name (SAN) extension in X.509 certificates [RFC3280].
+
+3.1.2. Recommended Algorithms
+
+ All PKINIT implementations SHOULD support the following algorithm:
+
+ o AS reply key delivery method: the public key encryption key
+ delivery method, as described in Section 3.2.3.2.
+
+ For implementations that support the public key encryption key
+ delivery method, the following algorithms MUST be supported:
+
+ a) Key transport algorithms identified in the keyEncryptionAlgorithm
+ field of the type KeyTransRecipientInfo [RFC3852] for encrypting
+ the temporary key in the encryptedKey field [RFC3852] with a
+ public key, as described in Section 3.2.3.2: rsaEncryption (this
+ is the RSAES-PKCS1-v1_5 encryption scheme) [RFC3370] [RFC3447].
+
+ b) Content encryption algorithms identified in the
+ contentEncryptionAlgorithm field of the type EncryptedContentInfo
+ [RFC3852] for encrypting the AS reply key with the temporary key
+ contained in the encryptedKey field of the type
+ KeyTransRecipientInfo [RFC3852], as described in Section 3.2.3.2:
+ des-ede3-cbc (three-key 3DES, CBC mode) [RFC3370].
+
+
+
+
+
+
+
+
+
+
+Zhu & Tung Standards Track [Page 6]
+
+RFC 4556 PKINIT June 2006
+
+
+3.1.3. Defined Message and Encryption Types
+
+ PKINIT makes use of the following new pre-authentication types:
+
+ PA_PK_AS_REQ 16
+ PA_PK_AS_REP 17
+
+ PKINIT also makes use of the following new authorization data type:
+
+ AD_INITIAL_VERIFIED_CAS 9
+
+ PKINIT introduces the following new error codes:
+
+ KDC_ERR_CLIENT_NOT_TRUSTED 62
+ KDC_ERR_INVALID_SIG 64
+ KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65
+ KDC_ERR_CANT_VERIFY_CERTIFICATE 70
+ KDC_ERR_INVALID_CERTIFICATE 71
+ KDC_ERR_REVOKED_CERTIFICATE 72
+ KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
+ KDC_ERR_CLIENT_NAME_MISMATCH 75
+ KDC_ERR_INCONSISTENT_KEY_PURPOSE 77
+ KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED 78
+ KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED 79
+ KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED 80
+ KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED 81
+
+ PKINIT uses the following typed data types for errors:
+
+ TD_TRUSTED_CERTIFIERS 104
+ TD_INVALID_CERTIFICATES 105
+ TD_DH_PARAMETERS 109
+
+ The ASN.1 module for all structures defined in this document (plus
+ IMPORT statements for all imported structures) is given in Appendix
+ A.
+
+ All structures defined in or imported into this document MUST be
+ encoded using Distinguished Encoding Rules (DER) [X680] [X690]
+ (unless otherwise noted). All data structures carried in OCTET
+ STRINGs MUST be encoded according to the rules specified in the
+ specifications defining each data structure; a reference to the
+ appropriate specification is provided for each data structure.
+
+
+
+
+
+
+
+
+Zhu & Tung Standards Track [Page 7]
+
+RFC 4556 PKINIT June 2006
+
+
+ Interoperability note: Some implementations may not be able to decode
+ wrapped Cryptographic Message Syntax (CMS) [RFC3852] objects encoded
+ with BER; specifically, they may not be able to decode indefinite-
+ length encodings. To maximize interoperability, implementers SHOULD
+ encode CMS objects used in PKINIT with DER.
+
+3.1.4. Kerberos Encryption Types Defined for CMS Algorithm Identifiers
+
+ PKINIT defines the following Kerberos encryption type numbers
+ [RFC3961], which can be used in the etype field of the AS-REQ
+ [RFC4120] message to indicate to the KDC the client's acceptance of
+ the corresponding algorithms (including key transport algorithms
+ [RFC3370], content encryption algorithms [RFC3370], and signature
+ algorithms) for use with Cryptographic Message Syntax (CMS) [RFC3852]
+ [RFC3370].
+
+ Per [RFC4120], the encryption types in the etype field are in the
+ decreasing preference order of the client. Note that there is no
+ significance in the relative order between any two of different types
+ of algorithms: key transport algorithms, content encryption
+ algorithms, and signature algorithms.
+
+ The presence of each of these encryption types in the etype field is
+ equivalent to the presence of the corresponding algorithm Object
+ Identifier (OID) in the supportedCMSTypes field as described in
+ Section 3.2.1. And the preference order expressed in the
+ supportedCMSTypes field would override the preference order listed in
+ the etype field.
+
+ Kerberos Encryption Type Name Num Corresponding Algorithm OID
+ ============================== === ===============================
+ id-dsa-with-sha1-CmsOID 9 id-dsa-with-sha1 [RFC3370]
+ md5WithRSAEncryption-CmsOID 10 md5WithRSAEncryption [RFC3370]
+ sha-1WithRSAEncryption-CmsOID 11 sha-1WithRSAEncryption [RFC3370]
+ rc2-cbc-EnvOID 12 rc2-cbc [RFC3370]
+ rsaEncryption-EnvOID 13 rsaEncryption [RFC3447][RFC3370]
+ id-RSAES-OAEP-EnvOID 14 id-RSAES-OAEP [RFC3447][RFC3560]
+ des-ede3-cbc-EnvOID 15 des-ede3-cbc [RFC3370]
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Tung Standards Track [Page 8]
+
+RFC 4556 PKINIT June 2006
+
+
+ The above encryption type numbers are used only to indicate support
+ for the use of the corresponding algorithms in PKINIT; they do not
+ correspond to actual Kerberos encryption types [RFC3961] and MUST NOT
+ be used in the etype field of the Kerberos EncryptedData type
+ [RFC4120]. The practice of assigning Kerberos encryption type
+ numbers to indicate support for CMS algorithms is considered
+ deprecated, and new numbers should not be assigned for this purpose.
+ Instead, the supportedCMSTypes field should be used to identify the
+ algorithms supported by the client and the preference order of the
+ client.
+
+ For maximum interoperability, however, PKINIT clients wishing to
+ indicate to the KDC the support for one or more of the algorithms
+ listed above SHOULD include the corresponding encryption type
+ number(s) in the etype field of the AS-REQ.
+
+3.2. PKINIT Pre-authentication Syntax and Use
+
+ This section defines the syntax and use of the various pre-
+ authentication fields employed by PKINIT.
+
+3.2.1. Generation of Client Request
+
+ The initial authentication request (AS-REQ) is sent as per [RFC4120];
+ in addition, a pre-authentication data element, whose padata-type is
+ PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
+ type PA-PK-AS-REQ, is included.
+
+ PA-PK-AS-REQ ::= SEQUENCE {
+ signedAuthPack [0] IMPLICIT OCTET STRING,
+ -- Contains a CMS type ContentInfo encoded
+ -- according to [RFC3852].
+ -- The contentType field of the type ContentInfo
+ -- is id-signedData (1.2.840.113549.1.7.2),
+ -- and the content field is a SignedData.
+ -- The eContentType field for the type SignedData is
+ -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
+ -- eContent field contains the DER encoding of the
+ -- type AuthPack.
+ -- AuthPack is defined below.
+ trustedCertifiers [1] SEQUENCE OF
+ ExternalPrincipalIdentifier OPTIONAL,
+ -- Contains a list of CAs, trusted by the client,
+ -- that can be used to certify the KDC.
+ -- Each ExternalPrincipalIdentifier identifies a CA
+ -- or a CA certificate (thereby its public key).
+ -- The information contained in the
+ -- trustedCertifiers SHOULD be used by the KDC as
+
+
+
+Zhu & Tung Standards Track [Page 9]
+
+RFC 4556 PKINIT June 2006
+
+
+ -- hints to guide its selection of an appropriate
+ -- certificate chain to return to the client.
+ kdcPkId [2] IMPLICIT OCTET STRING
+ OPTIONAL,
+ -- Contains a CMS type SignerIdentifier encoded
+ -- according to [RFC3852].
+ -- Identifies, if present, a particular KDC
+ -- public key that the client already has.
+ ...
+ }
+
+ DHNonce ::= OCTET STRING
+
+ ExternalPrincipalIdentifier ::= SEQUENCE {
+ subjectName [0] IMPLICIT OCTET STRING OPTIONAL,
+ -- Contains a PKIX type Name encoded according to
+ -- [RFC3280].
+ -- Identifies the certificate subject by the
+ -- distinguished subject name.
+ -- REQUIRED when there is a distinguished subject
+ -- name present in the certificate.
+ issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL,
+ -- Contains a CMS type IssuerAndSerialNumber encoded
+ -- according to [RFC3852].
+ -- Identifies a certificate of the subject.
+ -- REQUIRED for TD-INVALID-CERTIFICATES and
+ -- TD-TRUSTED-CERTIFIERS.
+ subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL,
+ -- Identifies the subject's public key by a key
+ -- identifier. When an X.509 certificate is
+ -- referenced, this key identifier matches the X.509
+ -- subjectKeyIdentifier extension value. When other
+ -- certificate formats are referenced, the documents
+ -- that specify the certificate format and their use
+ -- with the CMS must include details on matching the
+ -- key identifier to the appropriate certificate
+ -- field.
+ -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
+ ...
+ }
+
+ AuthPack ::= SEQUENCE {
+ pkAuthenticator [0] PKAuthenticator,
+ clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
+ -- Type SubjectPublicKeyInfo is defined in
+ -- [RFC3280].
+ -- Specifies Diffie-Hellman domain parameters
+ -- and the client's public key value [IEEE1363].
+
+
+
+Zhu & Tung Standards Track [Page 10]
+
+RFC 4556 PKINIT June 2006
+
+
+ -- The DH public key value is encoded as a BIT
+ -- STRING according to [RFC3279].
+ -- This field is present only if the client wishes
+ -- to use the Diffie-Hellman key agreement method.
+ supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
+ OPTIONAL,
+ -- Type AlgorithmIdentifier is defined in
+ -- [RFC3280].
+ -- List of CMS algorithm [RFC3370] identifiers
+ -- that identify key transport algorithms, or
+ -- content encryption algorithms, or signature
+ -- algorithms supported by the client in order of
+ -- (decreasing) preference.
+ clientDHNonce [3] DHNonce OPTIONAL,
+ -- Present only if the client indicates that it
+ -- wishes to reuse DH keys or to allow the KDC to
+ -- do so (see Section 3.2.3.1).
+ ...
+ }
+
+ PKAuthenticator ::= SEQUENCE {
+ cusec [0] INTEGER (0..999999),
+ ctime [1] KerberosTime,
+ -- cusec and ctime are used as in [RFC4120], for
+ -- replay prevention.
+ nonce [2] INTEGER (0..4294967295),
+ -- Chosen randomly; this nonce does not need to
+ -- match with the nonce in the KDC-REQ-BODY.
+ paChecksum [3] OCTET STRING OPTIONAL,
+ -- MUST be present.
+ -- Contains the SHA1 checksum, performed over
+ -- KDC-REQ-BODY.
+ ...
+ }
+
+ The ContentInfo [RFC3852] structure contained in the signedAuthPack
+ field of the type PA-PK-AS-REQ is encoded according to [RFC3852] and
+ is filled out as follows:
+
+ 1. The contentType field of the type ContentInfo is id-signedData
+ (as defined in [RFC3852]), and the content field is a SignedData
+ (as defined in [RFC3852]).
+
+
+
+
+
+
+
+
+
+Zhu & Tung Standards Track [Page 11]
+
+RFC 4556 PKINIT June 2006
+
+
+ 2. The eContentType field for the type SignedData is id-pkinit-
+ authData: { iso(1) org(3) dod(6) internet(1) security(5)
+ kerberosv5(2) pkinit(3) authData(1) }. Notes to CMS
+ implementers: the signed attribute content-type MUST be present
+ in this SignedData instance, and its value is id-pkinit-authData
+ according to [RFC3852].
+
+ 3. The eContent field for the type SignedData contains the DER
+ encoding of the type AuthPack.
+
+ 4. The signerInfos field of the type SignedData contains a single
+ signerInfo, which contains the signature over the type AuthPack.
+
+ 5. The AuthPack structure contains a PKAuthenticator, the client
+ public key information, the CMS encryption types supported by the
+ client, and a DHNonce. The pkAuthenticator field certifies to
+ the KDC that the client has recent knowledge of the signing key
+ that authenticates the client. The clientPublicValue field
+ specifies Diffie-Hellman domain parameters and the client's
+ public key value. The DH public key value is encoded as a BIT
+ STRING according to [RFC3279]. The clientPublicValue field is
+ present only if the client wishes to use the Diffie-Hellman key
+ agreement method. The supportedCMSTypes field specifies the list
+ of CMS algorithm identifiers that are supported by the client in
+ order of (decreasing) preference, and can be used to identify a
+ signature algorithm or a key transport algorithm [RFC3370] in the
+ keyEncryptionAlgorithm field of the type KeyTransRecipientInfo,
+ or a content encryption algorithm [RFC3370] in the
+ contentEncryptionAlgorithm field of the type EncryptedContentInfo
+ [RFC3852] when encrypting the AS reply key as described in
+ Section 3.2.3.2. However, there is no significance in the
+ relative order between any two of different types of algorithms:
+ key transport algorithms, content encryption algorithms, and
+ signature algorithms. The clientDHNonce field is described later
+ in this section.
+
+ 6. The ctime field in the PKAuthenticator structure contains the
+ current time on the client's host, and the cusec field contains
+ the microsecond part of the client's timestamp. The ctime and
+ cusec fields are used together to specify a reasonably accurate
+ timestamp [RFC4120]. The nonce field is chosen randomly. The
+ paChecksum field MUST be present and it contains a SHA1 checksum
+ that is performed over the KDC-REQ-BODY [RFC4120]. In order to
+ ease future migration from the use of SHA1, the paChecksum field
+ is made optional syntactically: when the request is extended to
+ negotiate hash algorithms, the new client wishing not to use SHA1
+ will send the request in the extended message syntax without the
+ paChecksum field. The KDC conforming to this specification MUST
+
+
+
+Zhu & Tung Standards Track [Page 12]
+
+RFC 4556 PKINIT June 2006
+
+
+ return a KRB-ERROR [RFC4120] message with the code
+ KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED (see Section 3.2.3). That
+ will allow a new client to retry with SHA1 if allowed by the
+ local policy.
+
+ 7. The certificates field of the type SignedData contains
+ certificates intended to facilitate certification path
+ construction, so that the KDC can verify the signature over the
+ type AuthPack. For path validation, these certificates SHOULD be
+ sufficient to construct at least one certification path from the
+ client certificate to one trust anchor acceptable by the KDC
+ [RFC4158]. The client MUST be capable of including such a set of
+ certificates if configured to do so. The certificates field MUST
+ NOT contain "root" CA certificates.
+
+ 8. The client's Diffie-Hellman public value (clientPublicValue) is
+ included if and only if the client wishes to use the Diffie-
+ Hellman key agreement method. The Diffie-Hellman domain
+ parameters [IEEE1363] for the client's public key are specified
+ in the algorithm field of the type SubjectPublicKeyInfo
+ [RFC3279], and the client's Diffie-Hellman public key value is
+ mapped to a subjectPublicKey (a BIT STRING) according to
+ [RFC3279]. When using the Diffie-Hellman key agreement method,
+ implementations MUST support Oakley 1024-bit Modular Exponential
+ (MODP) well-known group 2 [RFC2412] and Oakley 2048-bit MODP
+ well-known group 14 [RFC3526] and SHOULD support Oakley 4096-bit
+ MODP well-known group 16 [RFC3526].
+
+ The Diffie-Hellman field size should be chosen so as to provide
+ sufficient cryptographic security [RFC3766].
+
+ When MODP Diffie-Hellman is used, the exponents should have at
+ least twice as many bits as the symmetric keys that will be
+ derived from them [ODL99].
+
+ 9. The client may wish to reuse DH keys or to allow the KDC to do so
+ (see Section 3.2.3.1). If so, then the client includes the
+ clientDHNonce field. This nonce string MUST be as long as the
+ longest key length of the symmetric key types that the client
+ supports. This nonce MUST be chosen randomly.
+
+ The ExternalPrincipalIdentifier structure is used in this document to
+ identify the subject's public key thereby the subject principal.
+ This structure is filled out as follows:
+
+ 1. The subjectName field contains a PKIX type Name encoded according
+ to [RFC3280]. This field identifies the certificate subject by
+ the distinguished subject name. This field is REQUIRED when
+
+
+
+Zhu & Tung Standards Track [Page 13]
+
+RFC 4556 PKINIT June 2006
+
+
+ there is a distinguished subject name present in the certificate
+ being used.
+
+ 2. The issuerAndSerialNumber field contains a CMS type
+ IssuerAndSerialNumber encoded according to [RFC3852]. This field
+ identifies a certificate of the subject. This field is REQUIRED
+ for TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS (both
+ structures are defined in Section 3.2.2).
+
+ 3. The subjectKeyIdentifier [RFC3852] field identifies the subject's
+ public key by a key identifier. When an X.509 certificate is
+ referenced, this key identifier matches the X.509
+ subjectKeyIdentifier extension value. When other certificate
+ formats are referenced, the documents that specify the
+ certificate format and their use with the CMS must include
+ details on matching the key identifier to the appropriate
+ certificate field. This field is RECOMMENDED for TD-TRUSTED-
+ CERTIFIERS (as defined in Section 3.2.2).
+
+ The trustedCertifiers field of the type PA-PK-AS-REQ contains a list
+ of CAs, trusted by the client, that can be used to certify the KDC.
+ Each ExternalPrincipalIdentifier identifies a CA or a CA certificate
+ (thereby its public key).
+
+ The kdcPkId field of the type PA-PK-AS-REQ contains a CMS type
+ SignerIdentifier encoded according to [RFC3852]. This field
+ identifies, if present, a particular KDC public key that the client
+ already has.
+
+3.2.2. Receipt of Client Request
+
+ Upon receiving the client's request, the KDC validates it. This
+ section describes the steps that the KDC MUST (unless otherwise
+ noted) take in validating the request.
+
+ The KDC verifies the client's signature in the signedAuthPack field
+ according to [RFC3852].
+
+ If, while validating the client's X.509 certificate [RFC3280], the
+ KDC cannot build a certification path to validate the client's
+ certificate, it sends back a KRB-ERROR [RFC4120] message with the
+ code KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for
+ this error message is a TYPED-DATA (as defined in [RFC4120]) that
+ contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and
+ whose data-value contains the DER encoding of the type TD-TRUSTED-
+ CERTIFIERS:
+
+
+
+
+
+Zhu & Tung Standards Track [Page 14]
+
+RFC 4556 PKINIT June 2006
+
+
+ TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
+ ExternalPrincipalIdentifier
+ -- Identifies a list of CAs trusted by the KDC.
+ -- Each ExternalPrincipalIdentifier identifies a CA
+ -- or a CA certificate (thereby its public key).
+
+ Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
+ TD-TRUSTED-CERTIFIERS structure identifies a CA or a CA certificate
+ (thereby its public key) trusted by the KDC.
+
+ Upon receiving this error message, the client SHOULD retry only if it
+ has a different set of certificates (from those of the previous
+ requests) that form a certification path (or a partial path) from one
+ of the trust anchors acceptable by the KDC to its own certificate.
+
+ If, while processing the certification path, the KDC determines that
+ the signature on one of the certificates in the signedAuthPack field
+ is invalid, it returns a KRB-ERROR [RFC4120] message with the code
+ KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data for this error
+ message is a TYPED-DATA that contains an element whose data-type is
+ TD_INVALID_CERTIFICATES, and whose data-value contains the DER
+ encoding of the type TD-INVALID-CERTIFICATES:
+
+ TD-INVALID-CERTIFICATES ::= SEQUENCE OF
+ ExternalPrincipalIdentifier
+ -- Each ExternalPrincipalIdentifier identifies a
+ -- certificate (sent by the client) with an invalid
+ -- signature.
+
+ Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
+ TD-INVALID-CERTIFICATES structure identifies a certificate (that was
+ sent by the client) with an invalid signature.
+
+ If more than one X.509 certificate signature is invalid, the KDC MAY
+ include one IssuerAndSerialNumber per invalid signature within the
+ TD-INVALID-CERTIFICATES.
+
+ The client's X.509 certificate is validated according to [RFC3280].
+
+ Depending on local policy, the KDC may also check whether any X.509
+ certificates in the certification path validating the client's
+ certificate have been revoked. If any of them have been revoked, the
+ KDC MUST return an error message with the code
+ KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
+ revocation status but is unable to do so, it SHOULD return an error
+ message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN. The
+ certificate or certificates affected are identified exactly as for
+ the error code KDC_ERR_INVALID_CERTIFICATE (see above).
+
+
+
+Zhu & Tung Standards Track [Page 15]
+
+RFC 4556 PKINIT June 2006
+
+
+ Note that the TD_INVALID_CERTIFICATES error data is only used to
+ identify invalid certificates sent by the client in the request.
+
+ The client's public key is then used to verify the signature. If the
+ signature fails to verify, the KDC MUST return an error message with
+ the code KDC_ERR_INVALID_SIG. There is no accompanying e-data for
+ this error message.
+
+ In addition to validating the client's signature, the KDC MUST also
+ check that the client's public key used to verify the client's
+ signature is bound to the client principal name specified in the AS-
+ REQ as follows:
+
+ 1. If the KDC has its own binding between either the client's
+ signature-verification public key or the client's certificate and
+ the client's Kerberos principal name, it uses that binding.
+
+ 2. Otherwise, if the client's X.509 certificate contains a Subject
+ Alternative Name (SAN) extension carrying a KRB5PrincipalName
+ (defined below) in the otherName field of the type GeneralName
+ [RFC3280], it binds the client's X.509 certificate to that name.
+
+ The type of the otherName field is AnotherName. The type-id field
+ of the type AnotherName is id-pkinit-san:
+
+ id-pkinit-san OBJECT IDENTIFIER ::=
+ { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+ x509SanAN (2) }
+
+ And the value field of the type AnotherName is a
+ KRB5PrincipalName.
+
+ KRB5PrincipalName ::= SEQUENCE {
+ realm [0] Realm,
+ principalName [1] PrincipalName
+ }
+
+ If the Kerberos client name in the AS-REQ does not match a name bound
+ by the KDC (the binding can be in the certificate, for example, as
+ described above), or if there is no binding found by the KDC, the KDC
+ MUST return an error message with the code
+ KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for
+ this error message.
+
+ Even if the certification path is validated and the certificate is
+ mapped to the client's principal name, the KDC may decide not to
+ accept the client's certificate, depending on local policy.
+
+
+
+
+Zhu & Tung Standards Track [Page 16]
+
+RFC 4556 PKINIT June 2006
+
+
+ The KDC MAY require the presence of an Extended Key Usage (EKU)
+ KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field
+ of the client's X.509 certificate:
+
+ id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
+ { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+ pkinit(3) keyPurposeClientAuth(4) }
+ -- PKINIT client authentication.
+ -- Key usage bits that MUST be consistent:
+ -- digitalSignature.
+
+ The digitalSignature key usage bit [RFC3280] MUST be asserted when
+ the intended purpose of the client's X.509 certificate is restricted
+ with the id-pkinit-KPClientAuth EKU.
+
+ If this EKU KeyPurposeId is required but it is not present, or if the
+ client certificate is restricted not to be used for PKINIT client
+ authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
+ an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE. There
+ is no accompanying e-data for this error message. KDCs implementing
+ this requirement SHOULD also accept the EKU KeyPurposeId
+ id-ms-kp-sc-logon (1.3.6.1.4.1.311.20.2.2) as meeting the
+ requirement, as there are a large number of X.509 client certificates
+ deployed for use with PKINIT that have this EKU.
+
+ As a matter of local policy, the KDC MAY decide to reject requests on
+ the basis of the absence or presence of other specific EKU OIDs.
+
+ If the digest algorithm used in generating the CA signature for the
+ public key in any certificate of the request is not acceptable by the
+ KDC, the KDC MUST return a KRB-ERROR [RFC4120] message with the code
+ KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED. The accompanying e-data MUST be
+ encoded in TYPED-DATA, although none is defined at this point.
+
+ If the client's public key is not accepted with reasons other than
+ those specified above, the KDC returns a KRB-ERROR [RFC4120] message
+ with the code KDC_ERR_CLIENT_NOT_TRUSTED. There is no accompanying
+ e-data currently defined for this error message.
+
+ The KDC MUST check the timestamp to ensure that the request is not a
+ replay, and that the time skew falls within acceptable limits. The
+ recommendations for clock skew times in [RFC4120] apply here. If the
+ check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
+ KRB_AP_ERR_SKEW, respectively.
+
+ If the clientPublicValue is filled in, indicating that the client
+ wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
+ check to see if the key parameters satisfy its policy. If they do
+
+
+
+Zhu & Tung Standards Track [Page 17]
+
+RFC 4556 PKINIT June 2006
+
+
+ not, it MUST return an error message with the code
+ KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a
+ TYPED-DATA that contains an element whose data-type is
+ TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
+ the type TD-DH-PARAMETERS:
+
+ TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
+ -- Each AlgorithmIdentifier specifies a set of
+ -- Diffie-Hellman domain parameters [IEEE1363].
+ -- This list is in decreasing preference order.
+
+ TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
+ that the KDC supports in decreasing preference order, from which the
+ client SHOULD pick one to retry the request.
+
+ The AlgorithmIdentifier structure is defined in [RFC3280] and is
+ filled in according to [RFC3279]. More specifically, Section 2.3.3
+ of [RFC3279] describes how to fill in the AlgorithmIdentifier
+ structure in the case where MODP Diffie-Hellman key exchange is used.
+
+ If the client included a kdcPkId field in the PA-PK-AS-REQ and the
+ KDC does not possess the corresponding key, the KDC MUST ignore the
+ kdcPkId field as if the client did not include one.
+
+ If the digest algorithm used by the id-pkinit-authData is not
+ acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120]
+ message with the code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED.
+ The accompanying e-data MUST be encoded in TYPED-DATA, although none
+ is defined at this point.
+
+3.2.3. Generation of KDC Reply
+
+ If the paChecksum filed in the request is not present, the KDC
+ conforming to this specification MUST return a KRB-ERROR [RFC4120]
+ message with the code KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED. The
+ accompanying e-data MUST be encoded in TYPED-DATA (no error data is
+ defined by this specification).
+
+ Assuming that the client's request has been properly validated, the
+ KDC proceeds as per [RFC4120], except as follows.
+
+ The KDC MUST set the initial flag and include an authorization data
+ element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
+ ticket. The ad-data [RFC4120] field contains the DER encoding of the
+ type AD-INITIAL-VERIFIED-CAS:
+
+
+
+
+
+
+Zhu & Tung Standards Track [Page 18]
+
+RFC 4556 PKINIT June 2006
+
+
+ AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
+ ExternalPrincipalIdentifier
+ -- Identifies the certification path with which
+ -- the client certificate was validated.
+ -- Each ExternalPrincipalIdentifier identifies a CA
+ -- or a CA certificate (thereby its public key).
+
+ The AD-INITIAL-VERIFIED-CAS structure identifies the certification
+ path with which the client certificate was validated. Each
+ ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the AD-
+ INITIAL-VERIFIED-CAS structure identifies a CA or a CA certificate
+ (thereby its public key).
+
+ Note that the syntax for the AD-INITIAL-VERIFIED-CAS authorization
+ data does permit empty SEQUENCEs to be encoded. Such empty sequences
+ may only be used if the KDC itself vouches for the user's
+ certificate.
+
+ The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
+ containers if the list of CAs satisfies the AS' realm's local policy
+ (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
+ [RFC4120]). Furthermore, any TGS MUST copy such authorization data
+ from tickets used within a PA-TGS-REQ of the TGS-REQ into the
+ resulting ticket. If the list of CAs satisfies the local KDC's
+ realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT
+ container; otherwise, it MAY unwrap the authorization data out of the
+ AD-IF-RELEVANT container.
+
+ Application servers that understand this authorization data type
+ SHOULD apply local policy to determine whether a given ticket bearing
+ such a type *not* contained within an AD-IF-RELEVANT container is
+ acceptable. (This corresponds to the AP server's checking the
+ transited field when the TRANSITED-POLICY-CHECKED flag has not been
+ set [RFC4120].) If such a data type is contained within an AD-IF-
+ RELEVANT container, AP servers MAY apply local policy to determine
+ whether the authorization data is acceptable.
+
+ A pre-authentication data element, whose padata-type is PA_PK_AS_REP
+ and whose padata-value contains the DER encoding of the type PA-PK-
+ AS-REP (defined below), is included in the AS-REP [RFC4120].
+
+ PA-PK-AS-REP ::= CHOICE {
+ dhInfo [0] DHRepInfo,
+ -- Selected when Diffie-Hellman key exchange is
+ -- used.
+ encKeyPack [1] IMPLICIT OCTET STRING,
+ -- Selected when public key encryption is used.
+ -- Contains a CMS type ContentInfo encoded
+
+
+
+Zhu & Tung Standards Track [Page 19]
+
+RFC 4556 PKINIT June 2006
+
+
+ -- according to [RFC3852].
+ -- The contentType field of the type ContentInfo is
+ -- id-envelopedData (1.2.840.113549.1.7.3).
+ -- The content field is an EnvelopedData.
+ -- The contentType field for the type EnvelopedData
+ -- is id-signedData (1.2.840.113549.1.7.2).
+ -- The eContentType field for the inner type
+ -- SignedData (when unencrypted) is
+ -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
+ -- eContent field contains the DER encoding of the
+ -- type ReplyKeyPack.
+ -- ReplyKeyPack is defined in Section 3.2.3.2.
+ ...
+ }
+
+ DHRepInfo ::= SEQUENCE {
+ dhSignedData [0] IMPLICIT OCTET STRING,
+ -- Contains a CMS type ContentInfo encoded according
+ -- to [RFC3852].
+ -- The contentType field of the type ContentInfo is
+ -- id-signedData (1.2.840.113549.1.7.2), and the
+ -- content field is a SignedData.
+ -- The eContentType field for the type SignedData is
+ -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
+ -- eContent field contains the DER encoding of the
+ -- type KDCDHKeyInfo.
+ -- KDCDHKeyInfo is defined below.
+ serverDHNonce [1] DHNonce OPTIONAL,
+ -- Present if and only if dhKeyExpiration is
+ -- present in the KDCDHKeyInfo.
+ ...
+ }
+
+ KDCDHKeyInfo ::= SEQUENCE {
+ subjectPublicKey [0] BIT STRING,
+ -- The KDC's DH public key.
+ -- The DH public key value is encoded as a BIT
+ -- STRING according to [RFC3279].
+ nonce [1] INTEGER (0..4294967295),
+ -- Contains the nonce in the pkAuthenticator field
+ -- in the request if the DH keys are NOT reused,
+ -- 0 otherwise.
+ dhKeyExpiration [2] KerberosTime OPTIONAL,
+ -- Expiration time for KDC's key pair,
+ -- present if and only if the DH keys are reused.
+ -- If present, the KDC's DH public key MUST not be
+ -- used past the point of this expiration time.
+ -- If this field is omitted then the serverDHNonce
+
+
+
+Zhu & Tung Standards Track [Page 20]
+
+RFC 4556 PKINIT June 2006
+
+
+ -- field MUST also be omitted.
+ ...
+ }
+
+ The content of the AS-REP is otherwise unchanged from [RFC4120]. The
+ KDC encrypts the reply as usual, but not with the client's long-term
+ key. Instead, it encrypts it with either a shared key derived from a
+ Diffie-Hellman exchange or a generated encryption key. The contents
+ of the PA-PK-AS-REP indicate which key delivery method is used.
+
+ If the client does not wish to use the Diffie-Hellman key delivery
+ method (the clientPublicValue field is not present in the request)
+ and the KDC does not support the public key encryption key delivery
+ method, the KDC MUST return an error message with the code
+ KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED. There is no
+ accompanying e-data for this error message.
+
+ In addition, the lifetime of the ticket returned by the KDC MUST NOT
+ exceed that of the client's public-private key pair. The ticket
+ lifetime, however, can be shorter than that of the client's public-
+ private key pair. For the implementations of this specification, the
+ lifetime of the client's public-private key pair is the validity
+ period in X.509 certificates [RFC3280], unless configured otherwise.
+
+3.2.3.1. Using Diffie-Hellman Key Exchange
+
+ In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
+
+ The ContentInfo [RFC3852] structure for the dhSignedData field is
+ filled in as follows:
+
+ 1. The contentType field of the type ContentInfo is id-signedData
+ (as defined in [RFC3852]), and the content field is a SignedData
+ (as defined in [RFC3852]).
+
+ 2. The eContentType field for the type SignedData is the OID value
+ for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1)
+ security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }. Notes to CMS
+ implementers: the signed attribute content-type MUST be present
+ in this SignedData instance, and its value is id-pkinit-DHKeyData
+ according to [RFC3852].
+
+ 3. The eContent field for the type SignedData contains the DER
+ encoding of the type KDCDHKeyInfo.
+
+ 4. The KDCDHKeyInfo structure contains the KDC's public key, a
+ nonce, and, optionally, the expiration time of the KDC's DH key
+ being reused. The subjectPublicKey field of the type
+
+
+
+Zhu & Tung Standards Track [Page 21]
+
+RFC 4556 PKINIT June 2006
+
+
+ KDCDHKeyInfo field identifies KDC's DH public key. This DH
+ public key value is encoded as a BIT STRING according to
+ [RFC3279]. The nonce field contains the nonce in the
+ pkAuthenticator field in the request if the DH keys are NOT
+ reused. The value of this nonce field is 0 if the DH keys are
+ reused. The dhKeyExpiration field is present if and only if the
+ DH keys are reused. If the dhKeyExpiration field is present, the
+ KDC's public key in this KDCDHKeyInfo structure MUST NOT be used
+ past the point of this expiration time. If this field is
+ omitted, then the serverDHNonce field MUST also be omitted.
+
+ 5. The signerInfos field of the type SignedData contains a single
+ signerInfo, which contains the signature over the type
+ KDCDHKeyInfo.
+
+ 6. The certificates field of the type SignedData contains
+ certificates intended to facilitate certification path
+ construction, so that the client can verify the KDC's signature
+ over the type KDCDHKeyInfo. The information contained in the
+ trustedCertifiers in the request SHOULD be used by the KDC as
+ hints to guide its selection of an appropriate certificate chain
+ to return to the client. This field may be left empty if the KDC
+ public key specified by the kdcPkId field in the PA-PK-AS-REQ was
+ used for signing. Otherwise, for path validation, these
+ certificates SHOULD be sufficient to construct at least one
+ certification path from the KDC certificate to one trust anchor
+ acceptable by the client [RFC4158]. The KDC MUST be capable of
+ including such a set of certificates if configured to do so. The
+ certificates field MUST NOT contain "root" CA certificates.
+
+ 7. If the client included the clientDHNonce field, then the KDC may
+ choose to reuse its DH keys. If the server reuses DH keys, then
+ it MUST include an expiration time in the dhKeyExpiration field.
+ Past the point of the expiration time, the signature over the
+ type DHRepInfo is considered expired/invalid. When the server
+ reuses DH keys then, it MUST include a serverDHNonce at least as
+ long as the length of keys for the symmetric encryption system
+ used to encrypt the AS reply. Note that including the
+ serverDHNonce changes how the client and server calculate the key
+ to use to encrypt the reply; see below for details. The KDC
+ SHOULD NOT reuse DH keys unless the clientDHNonce field is
+ present in the request.
+
+ The AS reply key is derived as follows:
+
+ 1. Both the KDC and the client calculate the shared secret value as
+ follows:
+
+
+
+
+Zhu & Tung Standards Track [Page 22]
+
+RFC 4556 PKINIT June 2006
+
+
+ a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
+ shared secret value. DHSharedSecret is the value ZZ, as
+ described in Section 2.1.1 of [RFC2631].
+
+ DHSharedSecret is first padded with leading zeros such that the
+ size of DHSharedSecret in octets is the same as that of the
+ modulus, then represented as a string of octets in big-endian
+ order.
+
+ Implementation note: Both the client and the KDC can cache the
+ triple (ya, yb, DHSharedSecret), where ya is the client's public
+ key and yb is the KDC's public key. If both ya and yb are the
+ same in a later exchange, the cached DHSharedSecret can be used.
+
+ 2. Let K be the key-generation seed length [RFC3961] of the AS reply
+ key whose enctype is selected according to [RFC4120].
+
+ 3. Define the function octetstring2key() as follows:
+
+ octetstring2key(x) == random-to-key(K-truncate(
+ SHA1(0x00 | x) |
+ SHA1(0x01 | x) |
+ SHA1(0x02 | x) |
+ ...
+ ))
+
+ where x is an octet string; | is the concatenation operator; 0x00,
+ 0x01, 0x02, etc. are each represented as a single octet; random-
+ to-key() is an operation that generates a protocol key from a
+ bitstring of length K; and K-truncate truncates its input to the
+ first K bits. Both K and random-to-key() are as defined in the
+ kcrypto profile [RFC3961] for the enctype of the AS reply key.
+
+ 4. When DH keys are reused, let n_c be the clientDHNonce and n_k be
+ the serverDHNonce; otherwise, let both n_c and n_k be empty octet
+ strings.
+
+ 5. The AS reply key k is:
+ k = octetstring2key(DHSharedSecret | n_c | n_k)
+
+3.2.3.2. Using Public Key Encryption
+
+ In this case, the PA-PK-AS-REP contains the encKeyPack field where
+ the AS reply key is encrypted.
+
+ The ContentInfo [RFC3852] structure for the encKeyPack field is
+ filled in as follows:
+
+
+
+
+Zhu & Tung Standards Track [Page 23]
+
+RFC 4556 PKINIT June 2006
+
+
+ 1. The contentType field of the type ContentInfo is id-envelopedData
+ (as defined in [RFC3852]), and the content field is an
+ EnvelopedData (as defined in [RFC3852]).
+
+ 2. The contentType field for the type EnvelopedData is id-
+ signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
+ pkcs (1) pkcs7 (7) signedData (2) }.
+
+ 3. The eContentType field for the inner type SignedData (when
+ decrypted from the encryptedContent field for the type
+ EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6)
+ internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }.
+ Notes to CMS implementers: the signed attribute content-type MUST
+ be present in this SignedData instance, and its value is id-
+ pkinit-rkeyData according to [RFC3852].
+
+ 4. The eContent field for the inner type SignedData contains the DER
+ encoding of the type ReplyKeyPack (as described below).
+
+ 5. The signerInfos field of the inner type SignedData contains a
+ single signerInfo, which contains the signature for the type
+ ReplyKeyPack.
+
+ 6. The certificates field of the inner type SignedData contains
+ certificates intended to facilitate certification path
+ construction, so that the client can verify the KDC's signature
+ for the type ReplyKeyPack. The information contained in the
+ trustedCertifiers in the request SHOULD be used by the KDC as
+ hints to guide its selection of an appropriate certificate chain
+ to return to the client. This field may be left empty if the KDC
+ public key specified by the kdcPkId field in the PA-PK-AS-REQ was
+ used for signing. Otherwise, for path validation, these
+ certificates SHOULD be sufficient to construct at least one
+ certification path from the KDC certificate to one trust anchor
+ acceptable by the client [RFC4158]. The KDC MUST be capable of
+ including such a set of certificates if configured to do so. The
+ certificates field MUST NOT contain "root" CA certificates.
+
+ 7. The recipientInfos field of the type EnvelopedData is a SET that
+ MUST contain exactly one member of type KeyTransRecipientInfo.
+ The encryptedKey of this member contains the temporary key that
+ is encrypted using the client's public key.
+
+ 8. The unprotectedAttrs or originatorInfo fields of the type
+ EnvelopedData MAY be present.
+
+
+
+
+
+
+Zhu & Tung Standards Track [Page 24]
+
+RFC 4556 PKINIT June 2006
+
+
+ If there is a supportedCMSTypes field in the AuthPack, the KDC must
+ check to see if it supports any of the listed types. If it supports
+ more than one of the types, the KDC SHOULD use the one listed first.
+ If it does not support any of them, it MUST return an error message
+ with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
+
+ Furthermore, the KDC computes the checksum of the AS-REQ in the
+ client request. This checksum is performed over the type AS-REQ, and
+ the protocol key [RFC3961] of the checksum operation is the replyKey,
+ and the key usage number is 6. If the replyKey's enctype is "newer"
+ [RFC4120] [RFC4121], the checksum operation is the required checksum
+ operation [RFC3961] of that enctype.
+
+ ReplyKeyPack ::= SEQUENCE {
+ replyKey [0] EncryptionKey,
+ -- Contains the session key used to encrypt the
+ -- enc-part field in the AS-REP, i.e., the
+ -- AS reply key.
+ asChecksum [1] Checksum,
+ -- Contains the checksum of the AS-REQ
+ -- corresponding to the containing AS-REP.
+ -- The checksum is performed over the type AS-REQ.
+ -- The protocol key [RFC3961] of the checksum is the
+ -- replyKey and the key usage number is 6.
+ -- If the replyKey's enctype is "newer" [RFC4120]
+ -- [RFC4121], the checksum is the required
+ -- checksum operation [RFC3961] for that enctype.
+ -- The client MUST verify this checksum upon receipt
+ -- of the AS-REP.
+ ...
+ }
+
+ Implementations of this RSA encryption key delivery method are
+ RECOMMENDED to support RSA keys at least 2048 bits in size.
+
+3.2.4. Receipt of KDC Reply
+
+ Upon receipt of the KDC's reply, the client proceeds as follows. If
+ the PA-PK-AS-REP contains the dhSignedData field, the client derives
+ the AS reply key using the same procedure used by the KDC, as defined
+ in Section 3.2.3.1. Otherwise, the message contains the encKeyPack
+ field, and the client decrypts and extracts the temporary key in the
+ encryptedKey field of the member KeyTransRecipientInfo and then uses
+ that as the AS reply key.
+
+ If the public key encryption method is used, the client MUST verify
+ the asChecksum contained in the ReplyKeyPack.
+
+
+
+
+Zhu & Tung Standards Track [Page 25]
+
+RFC 4556 PKINIT June 2006
+
+
+ In either case, the client MUST verify the signature in the
+ SignedData according to [RFC3852]. The KDC's X.509 certificate MUST
+ be validated according to [RFC3280]. In addition, unless the client
+ can otherwise verify that the public key used to verify the KDC's
+ signature is bound to the KDC of the target realm, the KDC's X.509
+ certificate MUST contain a Subject Alternative Name extension
+ [RFC3280] carrying an AnotherName whose type-id is id-pkinit-san (as
+ defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
+ matches the name of the TGS of the target realm (as defined in
+ Section 7.3 of [RFC4120]).
+
+ Unless the client knows by some other means that the KDC certificate
+ is intended for a Kerberos KDC, the client MUST require that the KDC
+ certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc:
+
+ id-pkinit-KPKdc OBJECT IDENTIFIER ::=
+ { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+ pkinit(3) keyPurposeKdc(5) }
+ -- Signing KDC responses.
+ -- Key usage bits that MUST be consistent:
+ -- digitalSignature.
+
+ The digitalSignature key usage bit [RFC3280] MUST be asserted when
+ the intended purpose of the KDC's X.509 certificate is restricted
+ with the id-pkinit-KPKdc EKU.
+
+ If the KDC certificate contains the Kerberos TGS name encoded as an
+ id-pkinit-san SAN, this certificate is certified by the issuing CA as
+ a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required.
+
+ If all applicable checks are satisfied, the client then decrypts the
+ enc-part field of the KDC-REP in the AS-REP, using the AS reply key,
+ and then proceeds as described in [RFC4120].
+
+3.3. Interoperability Requirements
+
+ The client MUST be capable of sending a set of certificates
+ sufficient to allow the KDC to construct a certification path for the
+ client's certificate, if the correct set of certificates is provided
+ through configuration or policy.
+
+ If the client sends all the X.509 certificates on a certification
+ path to a trust anchor acceptable by the KDC, and if the KDC cannot
+ verify the client's public key otherwise, the KDC MUST be able to
+ process path validation for the client's certificate based on the
+ certificates in the request.
+
+
+
+
+
+Zhu & Tung Standards Track [Page 26]
+
+RFC 4556 PKINIT June 2006
+
+
+ The KDC MUST be capable of sending a set of certificates sufficient
+ to allow the client to construct a certification path for the KDC's
+ certificate, if the correct set of certificates is provided through
+ configuration or policy.
+
+ If the KDC sends all the X.509 certificates on a certification path
+ to a trust anchor acceptable by the client, and the client can not
+ verify the KDC's public key otherwise, the client MUST be able to
+ process path validation for the KDC's certificate based on the
+ certificates in the reply.
+
+3.4. KDC Indication of PKINIT Support
+
+ If pre-authentication is required but was not present in the request,
+ per [RFC4120] an error message with the code KDC_ERR_PREAUTH_FAILED
+ is returned, and a METHOD-DATA object will be stored in the e-data
+ field of the KRB-ERROR message to specify which pre-authentication
+ mechanisms are acceptable. The KDC can then indicate the support of
+ PKINIT by including an empty element whose padata-type is
+ PA_PK_AS_REQ in that METHOD-DATA object.
+
+ Otherwise if it is required by the KDC's local policy that the client
+ must be pre-authenticated using the pre-authentication mechanism
+ specified in this document, but no PKINIT pre-authentication was
+ present in the request, an error message with the code
+ KDC_ERR_PREAUTH_FAILED SHOULD be returned.
+
+ KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
+ the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
+ STRING), and clients MUST ignore this and any other value. Future
+ extensions to this protocol may specify other data to send instead of
+ an empty OCTET STRING.
+
+4. Security Considerations
+
+ The security of cryptographic algorithms is dependent on generating
+ secret quantities [RFC4086]. The number of truly random bits is
+ extremely important in determining the attack resistance strength of
+ the cryptosystem; for example, the secret Diffie-Hellman exponents
+ must be chosen based on n truly random bits (where n is the system
+ security requirement). The security of the overall system is
+ significantly weakened by using insufficient random inputs: a
+ sophisticated attacker may find it easier to reproduce the
+ environment that produced the secret quantities and to search the
+ resulting small set of possibilities than to locate the quantities in
+ the whole of the potential number space.
+
+
+
+
+
+Zhu & Tung Standards Track [Page 27]
+
+RFC 4556 PKINIT June 2006
+
+
+ Kerberos error messages are not integrity protected; as a result, the
+ domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
+ with by an attacker so that the set of domain parameters selected
+ could be either weaker or not mutually preferred. Local policy can
+ configure sets of domain parameters acceptable locally, or disallow
+ the negotiation of DH domain parameters.
+
+ The symmetric reply key size and Diffie-Hellman field size or RSA
+ modulus size should be chosen so as to provide sufficient
+ cryptographic security [RFC3766].
+
+ When MODP Diffie-Hellman is used, the exponents should have at least
+ twice as many bits as the symmetric keys that will be derived from
+ them [ODL99].
+
+ PKINIT raises certain security considerations beyond those that can
+ be regulated strictly in protocol definitions. We will address them
+ in this section.
+
+ PKINIT extends the cross-realm model to the public-key
+ infrastructure. Users of PKINIT must understand security policies
+ and procedures appropriate to the use of Public Key Infrastructures
+ [RFC3280].
+
+ In order to trust a KDC certificate that is certified by a CA as a
+ KDC certificate for a target realm (for example, by asserting the TGS
+ name of that Kerberos realm as an id-pkinit-san SAN and/or
+ restricting the certificate usage by using the id-pkinit-KPKdc EKU,
+ as described in Section 3.2.4), the client MUST verify that the KDC
+ certificate's issuing CA is authorized to issue KDC certificates for
+ that target realm. Otherwise, the binding between the KDC
+ certificate and the KDC of the target realm is not established.
+
+ How to validate this authorization is a matter of local policy. A
+ way to achieve this is the configuration of specific sets of
+ intermediary CAs and trust anchors, one of which must be on the KDC
+ certificate's certification path [RFC3280], and, for each CA or trust
+ anchor, the realms for which it is allowed to issue certificates.
+
+ In addition, if any CA that is trusted to issue KDC certificates can
+ also issue other kinds of certificates, then local policy must be
+ able to distinguish between them; for example, it could require that
+ KDC certificates contain the id-pkinit-KPKdc EKU or that the realm be
+ specified with the id-pkinit-san SAN.
+
+ It is the responsibility of the PKI administrators for an
+ organization to ensure that KDC certificates are only issued to KDCs,
+ and that clients can ascertain this using their local policy.
+
+
+
+Zhu & Tung Standards Track [Page 28]
+
+RFC 4556 PKINIT June 2006
+
+
+ Standard Kerberos allows the possibility of interactions between
+ cryptosystems of varying strengths; this document adds interactions
+ with public-key cryptosystems to Kerberos. Some administrative
+ policies may allow the use of relatively weak public keys. When
+ using such weak asymmetric keys to protect/exchange stronger
+ symmetric Keys, the attack resistant strength of the overall system
+ is no better than that of these weak keys [RFC3766].
+
+ PKINIT requires that keys for symmetric cryptosystems be generated.
+ Some such systems contain "weak" keys. For recommendations regarding
+ these weak keys, see [RFC4120].
+
+ PKINIT allows the use of the same RSA key pair for encryption and
+ signing when doing RSA encryption-based key delivery. This is not
+ recommended usage of RSA keys [RFC3447]; by using DH-based key
+ delivery, this is avoided.
+
+ Care should be taken in how certificates are chosen for the purposes
+ of authentication using PKINIT. Some local policies may require that
+ key escrow be used for certain certificate types. Deployers of
+ PKINIT should be aware of the implications of using certificates that
+ have escrowed keys for the purposes of authentication. Because
+ signing-only certificates are normally not escrowed, by using DH-
+ based key delivery this is avoided.
+
+ PKINIT does not provide for a "return routability" test to prevent
+ attackers from mounting a denial-of-service attack on the KDC by
+ causing it to perform unnecessary and expensive public-key
+ operations. Strictly speaking, this is also true of standard
+ Kerberos, although the potential cost is not as great, because
+ standard Kerberos does not make use of public-key cryptography. By
+ using DH-based key delivery and reusing DH keys, the necessary crypto
+ processing cost per request can be minimized.
+
+ When the Diffie-Hellman key exchange method is used, additional pre-
+ authentication data [RFC4120] (in addition to the PA_PK_AS_REQ, as
+ defined in this specification) is not bound to the AS_REQ by the
+ mechanisms discussed in this specification (meaning it may be dropped
+ or added by attackers without being detected by either the client or
+ the KDC). Designers of additional pre-authentication data should
+ take that into consideration if such additional pre-authentication
+ data can be used in conjunction with the PA_PK_AS_REQ. The future
+ work of the Kerberos working group is expected to update the hash
+ algorithms specified in this document and provide a generic mechanism
+ to bind additional pre-authentication data with the accompanying
+ AS_REQ.
+
+
+
+
+
+Zhu & Tung Standards Track [Page 29]
+
+RFC 4556 PKINIT June 2006
+
+
+ The key usage number 6 used by the asChecksum field is also used for
+ the authenticator checksum (cksum field of AP-REQ) contained in the
+ PA-TGS-REQ preauthentication data contained in a TGS-REQ [RFC4120].
+ This conflict is present for historical reasons; the reuse of key
+ usage numbers is strongly discouraged.
+
+5. Acknowledgements
+
+ The following people have made significant contributions to this
+ document: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist
+ Astrand, Ken Raeburn, Nicolas Williams, John Wray, Tom Yu, Jeffrey
+ Hutzelman, David Cross, Dan Simon, Karthik Jaganathan, Chaskiel M
+ Grundman, and Jeffrey Altman.
+
+ Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay, and
+ Chris Walstad discovered a binding issue between the AS-REQ and AS-
+ REP in draft -26; the asChecksum field was added as the result.
+
+ Special thanks to Clifford Neuman, Matthew Hur, Ari Medvinsky, Sasha
+ Medvinsky, and Jonathan Trostle who wrote earlier versions of this
+ document.
+
+ The authors are indebted to the Kerberos working group chair, Jeffrey
+ Hutzelman, who kept track of various issues and was enormously
+ helpful during the creation of this document.
+
+ Some of the ideas on which this document is based arose during
+ discussions over several years between members of the SAAG, the IETF
+ CAT working group, and the PSRG, regarding integration of Kerberos
+ and SPX. Some ideas have also been drawn from the DASS system.
+ These changes are by no means endorsed by these groups. This is an
+ attempt to revive some of the goals of those groups, and this
+ document approaches those goals primarily from the Kerberos
+ perspective.
+
+ Lastly, comments from groups working on similar ideas in DCE have
+ been invaluable.
+
+6. References
+
+6.1. Normative References
+
+ [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.
+
+
+
+
+Zhu & Tung Standards Track [Page 30]
+
+RFC 4556 PKINIT June 2006
+
+
+ [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC
+ 2412, November 1998.
+
+ [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
+ 2631, June 1999.
+
+ [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
+ Identifiers for the Internet X.509 Public Key
+ Infrastructure Certificate and Certificate Revocation List
+ (CRL) Profile", RFC 3279, April 2002.
+
+ [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+ X.509 Public Key Infrastructure Certificate and
+ Certificate Revocation List (CRL) Profile", RFC 3280,
+ April 2002.
+
+ [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
+ Algorithms", RFC 3370, August 2002.
+
+ [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
+ Standards (PKCS) #1: RSA Cryptography Specifications
+ Version 2.1", RFC 3447, February 2003.
+
+ [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
+ Diffie-Hellman groups for Internet Key Exchange (IKE)",
+ RFC 3526, May 2003.
+
+ [RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport
+ Algorithm in Cryptographic Message Syntax (CMS)", RFC
+ 3560, July 2003.
+
+ [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
+ Public Keys Used For Exchanging Symmetric Keys", BCP 86,
+ RFC 3766, April 2004.
+
+ [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
+ 3852, July 2004.
+
+ [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.
+
+ [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+ "Randomness Requirements for Security", BCP 106, RFC 4086,
+ June 2005.
+
+
+
+
+Zhu & Tung Standards Track [Page 31]
+
+RFC 4556 PKINIT June 2006
+
+
+ [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+ Kerberos Network Authentication Service (V5)", RFC 4120,
+ July 2005.
+
+ [X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
+ Information technology - Abstract Syntax Notation One
+ (ASN.1): Specification of basic notation.
+
+ [X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
+ Information technology - ASN.1 encoding Rules:
+ Specification of Basic Encoding Rules (BER), Canonical
+ Encoding Rules (CER) and Distinguished Encoding Rules
+ (DER).
+
+6.2. Informative References
+
+ [ODL99] Odlyzko, A., "Discrete logarithms: The past and the
+ future, Designs, Codes, and Cryptography (1999)". April
+ 1999.
+
+ [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+ Version 5 Generic Security Service Application Program
+ Interface (GSS-API) Mechanism: Version 2", RFC 4121, July
+ 2005.
+
+ [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
+ Nicholas, "Internet X.509 Public Key Infrastructure:
+ Certification Path Building", RFC 4158, September 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Tung Standards Track [Page 32]
+
+RFC 4556 PKINIT June 2006
+
+
+Appendix A. PKINIT ASN.1 Module
+
+ KerberosV5-PK-INIT-SPEC {
+ iso(1) identified-organization(3) dod(6) internet(1)
+ security(5) kerberosV5(2) modules(4) pkinit(5)
+ } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+ IMPORTS
+
+ SubjectPublicKeyInfo, AlgorithmIdentifier
+ FROM PKIX1Explicit88 { iso (1)
+ identified-organization (3) dod (6) internet (1)
+ security (5) mechanisms (5) pkix (7) id-mod (0)
+ id-pkix1-explicit (18) }
+ -- As defined in RFC 3280.
+
+ KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum
+ FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+ dod(6) internet(1) security(5) kerberosV5(2)
+ modules(4) krb5spec2(2) };
+ -- as defined in RFC 4120.
+
+ id-pkinit OBJECT IDENTIFIER ::=
+ { iso(1) identified-organization(3) dod(6) internet(1)
+ security(5) kerberosv5(2) pkinit (3) }
+
+ id-pkinit-authData OBJECT IDENTIFIER ::= { id-pkinit 1 }
+ id-pkinit-DHKeyData OBJECT IDENTIFIER ::= { id-pkinit 2 }
+ id-pkinit-rkeyData OBJECT IDENTIFIER ::= { id-pkinit 3 }
+ id-pkinit-KPClientAuth OBJECT IDENTIFIER ::= { id-pkinit 4 }
+ id-pkinit-KPKdc OBJECT IDENTIFIER ::= { id-pkinit 5 }
+
+ id-pkinit-san OBJECT IDENTIFIER ::=
+ { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+ x509SanAN (2) }
+
+ pa-pk-as-req INTEGER ::= 16
+ pa-pk-as-rep INTEGER ::= 17
+
+ ad-initial-verified-cas INTEGER ::= 9
+
+ td-trusted-certifiers INTEGER ::= 104
+ td-invalid-certificates INTEGER ::= 105
+ td-dh-parameters INTEGER ::= 109
+
+ PA-PK-AS-REQ ::= SEQUENCE {
+ signedAuthPack [0] IMPLICIT OCTET STRING,
+ -- Contains a CMS type ContentInfo encoded
+
+
+
+Zhu & Tung Standards Track [Page 33]
+
+RFC 4556 PKINIT June 2006
+
+
+ -- according to [RFC3852].
+ -- The contentType field of the type ContentInfo
+ -- is id-signedData (1.2.840.113549.1.7.2),
+ -- and the content field is a SignedData.
+ -- The eContentType field for the type SignedData is
+ -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
+ -- eContent field contains the DER encoding of the
+ -- type AuthPack.
+ -- AuthPack is defined below.
+ trustedCertifiers [1] SEQUENCE OF
+ ExternalPrincipalIdentifier OPTIONAL,
+ -- Contains a list of CAs, trusted by the client,
+ -- that can be used to certify the KDC.
+ -- Each ExternalPrincipalIdentifier identifies a CA
+ -- or a CA certificate (thereby its public key).
+ -- The information contained in the
+ -- trustedCertifiers SHOULD be used by the KDC as
+ -- hints to guide its selection of an appropriate
+ -- certificate chain to return to the client.
+ kdcPkId [2] IMPLICIT OCTET STRING
+ OPTIONAL,
+ -- Contains a CMS type SignerIdentifier encoded
+ -- according to [RFC3852].
+ -- Identifies, if present, a particular KDC
+ -- public key that the client already has.
+ ...
+ }
+
+ DHNonce ::= OCTET STRING
+
+ ExternalPrincipalIdentifier ::= SEQUENCE {
+ subjectName [0] IMPLICIT OCTET STRING OPTIONAL,
+ -- Contains a PKIX type Name encoded according to
+ -- [RFC3280].
+ -- Identifies the certificate subject by the
+ -- distinguished subject name.
+ -- REQUIRED when there is a distinguished subject
+ -- name present in the certificate.
+ issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL,
+ -- Contains a CMS type IssuerAndSerialNumber encoded
+ -- according to [RFC3852].
+ -- Identifies a certificate of the subject.
+ -- REQUIRED for TD-INVALID-CERTIFICATES and
+ -- TD-TRUSTED-CERTIFIERS.
+ subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL,
+ -- Identifies the subject's public key by a key
+ -- identifier. When an X.509 certificate is
+ -- referenced, this key identifier matches the X.509
+
+
+
+Zhu & Tung Standards Track [Page 34]
+
+RFC 4556 PKINIT June 2006
+
+
+ -- subjectKeyIdentifier extension value. When other
+ -- certificate formats are referenced, the documents
+ -- that specify the certificate format and their use
+ -- with the CMS must include details on matching the
+ -- key identifier to the appropriate certificate
+ -- field.
+ -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
+ ...
+ }
+
+ AuthPack ::= SEQUENCE {
+ pkAuthenticator [0] PKAuthenticator,
+ clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
+ -- Type SubjectPublicKeyInfo is defined in
+ -- [RFC3280].
+ -- Specifies Diffie-Hellman domain parameters
+ -- and the client's public key value [IEEE1363].
+ -- The DH public key value is encoded as a BIT
+ -- STRING according to [RFC3279].
+ -- This field is present only if the client wishes
+ -- to use the Diffie-Hellman key agreement method.
+ supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
+ OPTIONAL,
+ -- Type AlgorithmIdentifier is defined in
+ -- [RFC3280].
+ -- List of CMS algorithm [RFC3370] identifiers
+ -- that identify key transport algorithms, or
+ -- content encryption algorithms, or signature
+ -- algorithms supported by the client in order of
+ -- (decreasing) preference.
+ clientDHNonce [3] DHNonce OPTIONAL,
+ -- Present only if the client indicates that it
+ -- wishes to reuse DH keys or to allow the KDC to
+ -- do so.
+ ...
+ }
+
+ PKAuthenticator ::= SEQUENCE {
+ cusec [0] INTEGER (0..999999),
+ ctime [1] KerberosTime,
+ -- cusec and ctime are used as in [RFC4120], for
+ -- replay prevention.
+ nonce [2] INTEGER (0..4294967295),
+ -- Chosen randomly; this nonce does not need to
+ -- match with the nonce in the KDC-REQ-BODY.
+ paChecksum [3] OCTET STRING OPTIONAL,
+ -- MUST be present.
+ -- Contains the SHA1 checksum, performed over
+
+
+
+Zhu & Tung Standards Track [Page 35]
+
+RFC 4556 PKINIT June 2006
+
+
+ -- KDC-REQ-BODY.
+ ...
+ }
+
+ TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
+ ExternalPrincipalIdentifier
+ -- Identifies a list of CAs trusted by the KDC.
+ -- Each ExternalPrincipalIdentifier identifies a CA
+ -- or a CA certificate (thereby its public key).
+
+ TD-INVALID-CERTIFICATES ::= SEQUENCE OF
+ ExternalPrincipalIdentifier
+ -- Each ExternalPrincipalIdentifier identifies a
+ -- certificate (sent by the client) with an invalid
+ -- signature.
+
+ KRB5PrincipalName ::= SEQUENCE {
+ realm [0] Realm,
+ principalName [1] PrincipalName
+ }
+
+ AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
+ ExternalPrincipalIdentifier
+ -- Identifies the certification path based on which
+ -- the client certificate was validated.
+ -- Each ExternalPrincipalIdentifier identifies a CA
+ -- or a CA certificate (thereby its public key).
+
+ PA-PK-AS-REP ::= CHOICE {
+ dhInfo [0] DHRepInfo,
+ -- Selected when Diffie-Hellman key exchange is
+ -- used.
+ encKeyPack [1] IMPLICIT OCTET STRING,
+ -- Selected when public key encryption is used.
+ -- Contains a CMS type ContentInfo encoded
+ -- according to [RFC3852].
+ -- The contentType field of the type ContentInfo is
+ -- id-envelopedData (1.2.840.113549.1.7.3).
+ -- The content field is an EnvelopedData.
+ -- The contentType field for the type EnvelopedData
+ -- is id-signedData (1.2.840.113549.1.7.2).
+ -- The eContentType field for the inner type
+ -- SignedData (when unencrypted) is
+ -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
+ -- eContent field contains the DER encoding of the
+ -- type ReplyKeyPack.
+ -- ReplyKeyPack is defined below.
+ ...
+
+
+
+Zhu & Tung Standards Track [Page 36]
+
+RFC 4556 PKINIT June 2006
+
+
+ }
+
+ DHRepInfo ::= SEQUENCE {
+ dhSignedData [0] IMPLICIT OCTET STRING,
+ -- Contains a CMS type ContentInfo encoded according
+ -- to [RFC3852].
+ -- The contentType field of the type ContentInfo is
+ -- id-signedData (1.2.840.113549.1.7.2), and the
+ -- content field is a SignedData.
+ -- The eContentType field for the type SignedData is
+ -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
+ -- eContent field contains the DER encoding of the
+ -- type KDCDHKeyInfo.
+ -- KDCDHKeyInfo is defined below.
+ serverDHNonce [1] DHNonce OPTIONAL,
+ -- Present if and only if dhKeyExpiration is
+ -- present.
+ ...
+ }
+
+ KDCDHKeyInfo ::= SEQUENCE {
+ subjectPublicKey [0] BIT STRING,
+ -- The KDC's DH public key.
+ -- The DH public key value is encoded as a BIT
+ -- STRING according to [RFC3279].
+ nonce [1] INTEGER (0..4294967295),
+ -- Contains the nonce in the pkAuthenticator field
+ -- in the request if the DH keys are NOT reused,
+ -- 0 otherwise.
+ dhKeyExpiration [2] KerberosTime OPTIONAL,
+ -- Expiration time for KDC's key pair,
+ -- present if and only if the DH keys are reused.
+ -- If present, the KDC's DH public key MUST not be
+ -- used past the point of this expiration time.
+ -- If this field is omitted then the serverDHNonce
+ -- field MUST also be omitted.
+ ...
+ }
+
+ ReplyKeyPack ::= SEQUENCE {
+ replyKey [0] EncryptionKey,
+ -- Contains the session key used to encrypt the
+ -- enc-part field in the AS-REP, i.e., the
+ -- AS reply key.
+ asChecksum [1] Checksum,
+ -- Contains the checksum of the AS-REQ
+ -- corresponding to the containing AS-REP.
+ -- The checksum is performed over the type AS-REQ.
+
+
+
+Zhu & Tung Standards Track [Page 37]
+
+RFC 4556 PKINIT June 2006
+
+
+ -- The protocol key [RFC3961] of the checksum is the
+ -- replyKey and the key usage number is 6.
+ -- If the replyKey's enctype is "newer" [RFC4120]
+ -- [RFC4121], the checksum is the required
+ -- checksum operation [RFC3961] for that enctype.
+ -- The client MUST verify this checksum upon receipt
+ -- of the AS-REP.
+ ...
+ }
+
+ TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
+ -- Each AlgorithmIdentifier specifies a set of
+ -- Diffie-Hellman domain parameters [IEEE1363].
+ -- This list is in decreasing preference order.
+ END
+
+Appendix B. Test Vectors
+
+ Function octetstring2key() is defined in Section 3.2.3.1. This
+ section describes a few sets of test vectors that would be useful for
+ implementers of octetstring2key().
+
+ Set 1:
+ =====
+ Input octet string x is:
+
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+ Output of K-truncate() when the key size is 32 octets:
+
+ 5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83
+ 75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41
+
+
+
+
+Zhu & Tung Standards Track [Page 38]
+
+RFC 4556 PKINIT June 2006
+
+
+ Set 2:
+ =====
+ Input octet string x is:
+
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+ Output of K-truncate() when the key size is 32 octets:
+
+ ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb
+ a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e
+
+
+ Set 3:
+ ======
+ Input octet string x is:
+
+ 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
+ 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
+ 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
+ 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
+ 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b
+ 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a
+ 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09
+ 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
+
+ Output of K-truncate() when the key size is 32 octets:
+
+ c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3
+ 73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e
+
+
+ Set 4:
+ =====
+ Input octet string x is:
+
+ 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
+ 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
+ 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
+ 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
+ 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
+
+
+
+
+Zhu & Tung Standards Track [Page 39]
+
+RFC 4556 PKINIT June 2006
+
+
+ Output of K-truncate() when the key size is 32 octets:
+
+ 00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a
+ 59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc
+
+Appendix C. Miscellaneous Information about Microsoft Windows PKINIT
+ Implementations
+
+ Earlier revisions of the PKINIT I-D were implemented in various
+ releases of Microsoft Windows and deployed in fairly large numbers.
+ To enable the community to interoperate better with systems running
+ those releases, the following information may be useful.
+
+ KDC certificates issued by Windows 2000 Enterprise CAs contain a
+ dNSName SAN with the DNS name of the host running the KDC, and the
+ id-kp-serverAuth EKU [RFC3280].
+
+ KDC certificates issued by Windows 2003 Enterprise CAs contain a
+ dNSName SAN with the DNS name of the host running the KDC, the id-
+ kp-serverAuth EKU, and the id-ms-kp-sc-logon EKU.
+
+ It is anticipated that the next release of Windows is already too far
+ along to allow it to support the issuing KDC certificates with id-
+ pkinit-san SAN as specified in this RFC. Instead, they will have a
+ dNSName SAN containing the domain name of the KDC, and the intended
+ purpose of these KDC certificates will be restricted by the presence
+ of the id-pkinit-KPKdc EKU and id-kp-serverAuth EKU.
+
+ In addition to checking that the above are present in a KDC
+ certificate, Windows clients verify that the issuer of the KDC
+ certificate is one of a set of allowed issuers of such certificates,
+ so those wishing to issue KDC certificates need to configure their
+ Windows clients appropriately.
+
+ Client certificates accepted by Windows 2000 and Windows 2003 Server
+ KDCs must contain an id-ms-san-sc-logon-upn (1.3.6.1.4.1.311.20.2.3)
+ SAN and the id-ms-kp-sc-logon EKU. The id-ms-san-sc-logon-upn SAN
+ contains a UTF8-encoded string whose value is that of the Directory
+ Service attribute UserPrincipalName of the client account object, and
+ the purpose of including the id-ms-san-sc-logon-upn SAN in the client
+ certificate is to validate the client mapping (in other words, the
+ client's public key is bound to the account that has this
+ UserPrincipalName value).
+
+ It should be noted that all Microsoft Kerberos realm names are
+ domain-style realm names and strictly in uppercase. In addition, the
+ UserPrincipalName attribute is globally unique in Windows 2000 and
+ Windows 2003.
+
+
+
+Zhu & Tung Standards Track [Page 40]
+
+RFC 4556 PKINIT June 2006
+
+
+Authors' Addresses
+
+ Larry Zhu
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052
+ US
+
+ EMail: lzhu@microsoft.com
+
+
+ Brian Tung
+ Aerospace Corporation
+ 2350 E. El Segundo Blvd.
+ El Segundo, CA 90245
+ US
+
+ EMail: brian@aero.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Tung Standards Track [Page 41]
+
+RFC 4556 PKINIT June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zhu & Tung Standards Track [Page 42]
+