< draft-ietf-cat-kerberos-pk-init-29.txt   draft-ietf-cat-kerberos-pk-init-30.txt >
NETWORK WORKING GROUP B. Tung NETWORK WORKING GROUP L. Zhu
Internet-Draft USC Information Sciences Institute Internet-Draft Microsoft Corporation
Expires: April 22, 2006 L. Zhu Expires: June 2, 2006 B. Tung
Microsoft Corporation USC Information Sciences Institute
October 19, 2005 November 29, 2005
Public Key Cryptography for Initial Authentication in Kerberos Public Key Cryptography for Initial Authentication in Kerberos
draft-ietf-cat-kerberos-pk-init-29 draft-ietf-cat-kerberos-pk-init-30
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 22, 2006. This Internet-Draft will expire on June 2, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes protocol extensions (hereafter called PKINIT) This document describes protocol extensions (hereafter called PKINIT)
to the Kerberos protocol specification. These extensions provide a to the Kerberos protocol specification. These extensions provide a
method for integrating public key cryptography into the initial method for integrating public key cryptography into the initial
authentication exchange, by using asymmetric-key signature and/or authentication exchange, by using asymmetric-key signature and/or
encryption algorithms in pre-authentication data fields. encryption algorithms in pre-authentication data fields.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Definitions, Requirements, and Constants . . . . . . . . . 4 3.1. Definitions, Requirements, and Constants . . . . . . . . . 5
3.1.1. Required Algorithms . . . . . . . . . . . . . . . . . 4 3.1.1. Required Algorithms . . . . . . . . . . . . . . . . . 5
3.1.2. Defined Message and Encryption Types . . . . . . . . . 5 3.1.2. Defined Message and Encryption Types . . . . . . . . . 5
3.1.3. Algorithm Identifiers . . . . . . . . . . . . . . . . 6 3.1.3. Algorithm Identifiers . . . . . . . . . . . . . . . . 6
3.2. PKINIT Pre-authentication Syntax and Use . . . . . . . . . 7 3.2. PKINIT Pre-authentication Syntax and Use . . . . . . . . . 7
3.2.1. Generation of Client Request . . . . . . . . . . . . . 7 3.2.1. Generation of Client Request . . . . . . . . . . . . . 7
3.2.2. Receipt of Client Request . . . . . . . . . . . . . . 10 3.2.2. Receipt of Client Request . . . . . . . . . . . . . . 12
3.2.3. Generation of KDC Reply . . . . . . . . . . . . . . . 14 3.2.3. Generation of KDC Reply . . . . . . . . . . . . . . . 16
3.2.4. Receipt of KDC Reply . . . . . . . . . . . . . . . . . 20 3.2.4. Receipt of KDC Reply . . . . . . . . . . . . . . . . . 22
3.3. Interoperability Requirements . . . . . . . . . . . . . . 21 3.3. Interoperability Requirements . . . . . . . . . . . . . . 24
3.4. KDC Indication of PKINIT Support . . . . . . . . . . . . . 21 3.4. KDC Indication of PKINIT Support . . . . . . . . . . . . . 24
4. Security Considerations . . . . . . . . . . . . . . . . . . . 22 4. Security Considerations . . . . . . . . . . . . . . . . . . . 25
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.1. Normative References . . . . . . . . . . . . . . . . . . . 25 7.1. Normative References . . . . . . . . . . . . . . . . . . . 28
7.2. Informative References . . . . . . . . . . . . . . . . . . 26 7.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 26 Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 29
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 32 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 35
Appendix C. Miscellaneous Information about Microsoft Windows Appendix C. Miscellaneous Information about Microsoft Windows
PKINIT Implementations . . . . . . . . . . . . . . . 33 PKINIT Implementations . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
Intellectual Property and Copyright Statements . . . . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . . . . 39
1. Introduction 1. Introduction
A client typically authenticates itself to a service in Kerberos A client typically authenticates itself to a service in Kerberos
using three distinct though related exchanges. First, the client using three distinct though related exchanges. First, the client
requests a ticket-granting ticket (TGT) from the Kerberos requests a ticket-granting ticket (TGT) from the Kerberos
authentication server (AS). Then, it uses the TGT to request a authentication server (AS). Then, it uses the TGT to request a
service ticket from the Kerberos ticket-granting server (TGS). service ticket from the Kerberos ticket-granting server (TGS).
Usually, the AS and TGS are integrated in a single device known as a Usually, the AS and TGS are integrated in a single device known as a
Kerberos Key Distribution Center, or KDC. Finally, the client uses Kerberos Key Distribution Center, or KDC. Finally, the client uses
skipping to change at page 4, line 7 skipping to change at page 4, line 7
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Both the AS and the TGS are referred to as the KDC. Both the AS and the TGS are referred to as the KDC.
In this document, the encryption key used to encrypt the enc-part In this document, 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 field of the KDC-REP in the AS-REP [RFC4120] is referred to as the AS
reply key. reply key.
In this document, an empty sequence in an optional field can be
either included or omitted: both encodings are permitted and
considered equivalent.
In this document, 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.
3. Extensions 3. Extensions
This section describes extensions to [RFC4120] for supporting the use This section describes extensions to [RFC4120] for supporting the use
of public-key cryptography in the initial request for a ticket. of public-key cryptography in the initial request for a ticket.
Briefly, this document defines the following extensions to [RFC4120]: Briefly, this document defines the following extensions to [RFC4120]:
1. The client indicates the use of public-key authentication by 1. The client indicates the use of public-key authentication by
including a special preauthenticator in the initial request. This including a special preauthenticator in the initial request. This
preauthenticator contains the client's public-key data and a preauthenticator contains the client's public-key data and a
skipping to change at page 5, line 41 skipping to change at page 5, line 47
KDC_ERR_CLIENT_NOT_TRUSTED 62 KDC_ERR_CLIENT_NOT_TRUSTED 62
KDC_ERR_INVALID_SIG 64 KDC_ERR_INVALID_SIG 64
KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65
KDC_ERR_CANT_VERIFY_CERTIFICATE 70 KDC_ERR_CANT_VERIFY_CERTIFICATE 70
KDC_ERR_INVALID_CERTIFICATE 71 KDC_ERR_INVALID_CERTIFICATE 71
KDC_ERR_REVOKED_CERTIFICATE 72 KDC_ERR_REVOKED_CERTIFICATE 72
KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
KDC_ERR_CLIENT_NAME_MISMATCH 75 KDC_ERR_CLIENT_NAME_MISMATCH 75
KDC_ERR_INCONSISTENT_KEY_PURPOSE 76 KDC_ERR_INCONSISTENT_KEY_PURPOSE 76
KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED 77
KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED 78
KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED 79
PKINIT uses the following typed data types for errors: PKINIT uses the following typed data types for errors:
TD_TRUSTED_CERTIFIERS 104 TD_TRUSTED_CERTIFIERS 104
TD_INVALID_CERTIFICATES 105 TD_INVALID_CERTIFICATES 105
TD_DH_PARAMETERS 109 TD_DH_PARAMETERS 109
PKINIT defines the following encryption types, for use in the etype
field of the AS-REQ [RFC4120] message to indicate acceptance of the
corresponding algorithms that can used by Cryptographic Message
Syntax (CMS) [RFC3852] messages in the reply:
dsaWithSHA1-CmsOID 9
-- Indicates that the client supports dsaWithSHA1
md5WithRSAEncryption-CmsOID 10
-- Indicates that the client supports md5WithRSAEncryption
sha1WithRSAEncryption-CmsOID 11
-- Indicates that the client supports sha1WithRSAEncryption
rc2CBC-EnvOID 12
-- Indicates that the client supports rc2CBC
rsaEncryption-EnvOID 13
-- Indicates that the client supports
-- rsaEncryption (PKCS1 v2.1)
id-RSAES-OAEP-EnvOID 14
-- Indicates that the client supports
-- id-RSAES-OAEP (PKCS1 v2.1)
des-ede3-cbc-EnvOID 15
-- Indicates that the client supports des-ede3-cbc
The ASN.1 module for all structures defined in this document (plus The ASN.1 module for all structures defined in this document (plus
IMPORT statements for all imported structures) is given in IMPORT statements for all imported structures) is given in
Appendix A. Appendix A.
All structures defined in or imported into this document MUST be All structures defined in or imported into this document MUST be
encoded using Distinguished Encoding Rules (DER) [X680] [X690] encoded using Distinguished Encoding Rules (DER) [X680] [X690]
(unless otherwise noted). All data structures carried in OCTET (unless otherwise noted). All data structures carried in OCTET
STRINGs must be encoded according to the rules specified in STRINGs must be encoded according to the rules specified in
corresponding specifications. corresponding specifications.
Interoperability note: Some implementations may not be able to decode Interoperability note: Some implementations may not be able to decode
wrapped CMS objects encoded with BER but not DER; specifically, they wrapped CMS objects encoded with BER but not DER; specifically, they
may not be able to decode infinite length encodings. To maximize may not be able to decode indefinite length encodings. To maximize
interoperability, implementers SHOULD encode CMS objects used in interoperability, implementers SHOULD encode CMS objects used in
PKINIT with DER. PKINIT with DER.
3.1.3. Algorithm Identifiers 3.1.3. Algorithm Identifiers
PKINIT does not define, but does make use of, the following algorithm PKINIT does not define, but does make use of, the following algorithm
identifiers. identifiers.
PKINIT uses the following algorithm identifier(s) for Diffie-Hellman PKINIT uses the following algorithm identifier(s) for Modular
key agreement [RFC3279]: Exponential Diffie-Hellman key agreement [RFC2631] [RFC3279]:
dhpublicnumber (Modular Exponential Diffie-Hellman [RFC2631]) dhpublicnumber (as described in [RFC3279])
PKINIT uses the following signature algorithm identifiers [RFC3279]: PKINIT uses the following signature algorithm identifiers as defined
in [RFC3279]:
sha-1WithRSAEncryption (RSA with SHA1) sha-1WithRSAEncryption (RSA with SHA1)
md5WithRSAEncryption (RSA with MD5) md5WithRSAEncryption (RSA with MD5)
id-dsa-with-sha1 (DSA with SHA1) id-dsa-with-sha1 (DSA with SHA1)
PKINIT uses the following encryption algorithm identifiers [RFC3447] PKINIT uses the following encryption algorithm identifiers as defined
for encrypting the temporary key with a public key: in [RFC3447] for encrypting the temporary key with a public key:
rsaEncryption (PKCS1 v2.1) rsaEncryption
id-RSAES-OAEP (PKCS1 v2.1) id-RSAES-OAEP
PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565] PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565]
for encrypting the AS reply key with the temporary key: for encrypting the AS reply key with the temporary key:
des-ede3-cbc (three-key 3DES, CBC mode) des-ede3-cbc (three-key 3DES, CBC mode, as defined in [RFC3370])
rc2-cbc (RC2, CBC mode) rc2-cbc (RC2, CBC mode, as defined in [RFC3370])
id-aes256-CBC (AES-256, CBC mode) id-aes256-CBC (AES-256, CBC mode, as defined in [RFC3565])
PKINIT defines the following encryption types, for use in the etype
field of the AS-REQ [RFC4120] message to indicate acceptance of the
corresponding algorithms that can used by Cryptographic Message
Syntax (CMS) [RFC3852] messages in the reply:
id-dsa-with-sha1-CmsOID 9
-- Indicates that the client supports id-dsa-with-sha1.
md5WithRSAEncryption-CmsOID 10
-- Indicates that the client supports md5WithRSAEncryption.
sha-1WithRSAEncryption-CmsOID 11
-- Indicates that the client supports sha-1WithRSAEncryption.
rc2-cbc-EnvOID 12
-- Indicates that the client supports rc2-cbc.
rsaEncryption-EnvOID 13
-- Indicates that the client supports rsaEncryption.
id-RSAES-OAEP-EnvOID 14
-- Indicates that the client supports id-RSAES-OAEP.
des-ede3-cbc-EnvOID 15
-- Indicates that the client supports des-ede3-cbc.
3.2. PKINIT Pre-authentication Syntax and Use 3.2. PKINIT Pre-authentication Syntax and Use
This section defines the syntax and use of the various pre- This section defines the syntax and use of the various pre-
authentication fields employed by PKINIT. authentication fields employed by PKINIT.
3.2.1. Generation of Client Request 3.2.1. Generation of Client Request
The initial authentication request (AS-REQ) is sent as per [RFC4120]; The initial authentication request (AS-REQ) is sent as per [RFC4120];
in addition, a pre-authentication data element, whose padata-type is in addition, a pre-authentication data element, whose padata-type is
skipping to change at page 7, line 44 skipping to change at page 8, line 4
-- The contentType field of the type ContentInfo -- The contentType field of the type ContentInfo
-- is id-signedData (1.2.840.113549.1.7.2), -- is id-signedData (1.2.840.113549.1.7.2),
-- and the content field is a SignedData. -- and the content field is a SignedData.
-- The eContentType field for the type SignedData is -- The eContentType field for the type SignedData is
-- id-pkinit-authData (1.3.6.1.5.2.3.1), and the -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
-- eContent field contains the DER encoding of the -- eContent field contains the DER encoding of the
-- type AuthPack. -- type AuthPack.
-- AuthPack is defined below. -- AuthPack is defined below.
trustedCertifiers [1] SEQUENCE OF trustedCertifiers [1] SEQUENCE OF
ExternalPrincipalIdentifier OPTIONAL, ExternalPrincipalIdentifier OPTIONAL,
-- A list of CAs, trusted by the client, that can
-- be used to certify the KDC. -- Contains a list of CAs, trusted by the client,
-- that can be used to certify the KDC.
-- Each ExternalPrincipalIdentifier identifies a CA -- Each ExternalPrincipalIdentifier identifies a CA
-- or a CA certificate (thereby its public key). -- or a CA certificate (thereby its public key).
-- The information contained in the -- The information contained in the
-- trustedCertifiers SHOULD be used by the KDC as -- trustedCertifiers SHOULD be used by the KDC as
-- hints to guide its selection of an appropriate -- hints to guide its selection of an appropriate
-- certificate chain to return to the client. -- certificate chain to return to the client.
kdcPkId [2] IMPLICIT OCTET STRING kdcPkId [2] IMPLICIT OCTET STRING
OPTIONAL, OPTIONAL,
-- Contains a CMS type SignerIdentifier encoded -- Contains a CMS type SignerIdentifier encoded
-- according to [RFC3852]. -- according to [RFC3852].
skipping to change at page 9, line 32 skipping to change at page 9, line 41
-- replay prevention. -- replay prevention.
nonce [2] INTEGER (0..4294967295), nonce [2] INTEGER (0..4294967295),
-- Chosen randomly; This nonce does not need to -- Chosen randomly; This nonce does not need to
-- match with the nonce in the KDC-REQ-BODY. -- match with the nonce in the KDC-REQ-BODY.
paChecksum [3] OCTET STRING, paChecksum [3] OCTET STRING,
-- Contains the SHA1 checksum, performed over -- Contains the SHA1 checksum, performed over
-- KDC-REQ-BODY. -- KDC-REQ-BODY.
... ...
} }
The ContentInfo [RFC3852] structure for the signedAuthPack field is The ContentInfo [RFC3852] structure contained in the signedAuthPack
filled out as follows: 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 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]), and the content field is a SignedData
(as defined in [RFC3852]). (as defined in [RFC3852]).
2. The eContentType field for the type SignedData is id-pkinit- 2. The eContentType field for the type SignedData is id-pkinit-
authData: { iso(1) org(3) dod(6) internet(1) security(5) authData: { iso(1) org(3) dod(6) internet(1) security(5)
kerberosv5(2) pkinit(3) authData(1) }. 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 3. The eContent field for the type SignedData contains the DER
encoding of the type AuthPack. encoding of the type AuthPack.
4. The signerInfos field of the type SignedData contains a single 4. The signerInfos field of the type SignedData contains a single
signerInfo, which contains the signature over the type AuthPack. signerInfo, which contains the signature over the type AuthPack.
5. The certificates field of the type SignedData contains 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
encryption types supported by the client in order of (decreasing)
preference. 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 contains a SHA1 checksum that is performed over
the KDC-REQ-BODY [RFC4120].
7. The certificates field of the type SignedData contains
certificates intended to facilitate certification path certificates intended to facilitate certification path
construction, so that the KDC can verify the signature over the construction, so that the KDC can verify the signature over the
type AuthPack. For path validation, these certificates SHOULD be type AuthPack. For path validation, these certificates SHOULD be
sufficient to construct at least one certification path from the sufficient to construct at least one certification path from the
client certificate to one trust anchor acceptable by the KDC client certificate to one trust anchor acceptable by the KDC
[CAPATH]. The client MUST be capable of including such a set of [RFC4158]. The client MUST be capable of including such a set of
certificates if configured to do so. The certificates field MUST certificates if configured to do so. The certificates field MUST
NOT contain "root" CA certificates. NOT contain "root" CA certificates.
6. The client's Diffie-Hellman public value (clientPublicValue) is 8. The client's Diffie-Hellman public value (clientPublicValue) is
included if and only if the client wishes to use the Diffie- included if and only if the client wishes to use the Diffie-
Hellman key agreement method. The Diffie-Hellman domain Hellman key agreement method. The Diffie-Hellman domain
parameters [IEEE1363] for the client's public key are specified parameters [IEEE1363] for the client's public key are specified
in the algorithm field of the type SubjectPublicKeyInfo [RFC3279] in the algorithm field of the type SubjectPublicKeyInfo [RFC3279]
and the client's Diffie-Hellman public key value is mapped to a and the client's Diffie-Hellman public key value is mapped to a
subjectPublicKey (a BIT STRING) according to [RFC3279]. When subjectPublicKey (a BIT STRING) according to [RFC3279]. When
using the Diffie-Hellman key agreement method, implementations using the Diffie-Hellman key agreement method, implementations
MUST support Oakley 1024-bit Modular Exponential (MODP) well- MUST support Oakley 1024-bit Modular Exponential (MODP) well-
known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group
14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known 14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known
group 16 [RFC3526]. group 16 [RFC3526].
The Diffie-Hellman field size should be chosen so as to provide The Diffie-Hellman field size should be chosen so as to provide
sufficient cryptographic security [RFC3766]. sufficient cryptographic security [RFC3766].
When MODP Diffie-Hellman is used, the exponents should have at When MODP Diffie-Hellman is used, the exponents should have at
least twice as many bits as the symmetric keys that will be least twice as many bits as the symmetric keys that will be
derived from them [ODL99]. derived from them [ODL99].
7. The client may wish to reuse DH keys or to allow the KDC to do so 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 (see Section 3.2.3.1). If so, then the client includes the
clientDHNonce field. This nonce string needs to be as long as clientDHNonce field. This nonce string MUST be as long as the
the longest key length of the symmetric key types that the client longest key length of the symmetric key types that the client
supports. This nonce MUST be chosen randomly. 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
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 3.2.2. Receipt of Client Request
Upon receiving the client's request, the KDC validates it. This Upon receiving the client's request, the KDC validates it. This
section describes the steps that the KDC MUST (unless otherwise section describes the steps that the KDC MUST (unless otherwise
noted) take in validating the request. noted) take in validating the request.
The KDC verifies the client's signature in the signedAuthPack field The KDC verifies the client's signature in the signedAuthPack field
according to [RFC3852]. according to [RFC3852].
If, while validating the client's X.509 certificate [RFC3280], the If, while validating the client's X.509 certificate [RFC3280], the
skipping to change at page 11, line 14 skipping to change at page 12, line 37
contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and
whose data-value contains the DER encoding of the type TD-TRUSTED- whose data-value contains the DER encoding of the type TD-TRUSTED-
CERTIFIERS: CERTIFIERS:
TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
ExternalPrincipalIdentifier ExternalPrincipalIdentifier
-- Identifies a list of CAs trusted by the KDC. -- Identifies a list of CAs trusted by the KDC.
-- Each ExternalPrincipalIdentifier identifies a CA -- Each ExternalPrincipalIdentifier identifies a CA
-- or a CA certificate (thereby its public key). -- 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 Upon receiving this error message, the client SHOULD retry only if it
has a different set of certificates (from those of the previous has a different set of certificates (from those of the previous
requests) that form a certification path (or a partial path) from one requests) that form a certification path (or a partial path) from one
of the trust anchors acceptable by the KDC to its own certificate. of the trust anchors acceptable by the KDC to its own certificate.
If, while processing the certification path, the KDC determines that If, while processing the certification path, the KDC determines that
the signature on one of the certificates in the signedAuthPack field the signature on one of the certificates in the signedAuthPack field
is invalid, it returns a KRB-ERROR [RFC4120] message with the code is invalid, it returns a KRB-ERROR [RFC4120] message with the code
KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data for this error KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data for this error
message is a TYPED-DATA that contains an element whose data-type is message is a TYPED-DATA that contains an element whose data-type is
TD_INVALID_CERTIFICATES, and whose data-value contains the DER TD_INVALID_CERTIFICATES, and whose data-value contains the DER
encoding of the type TD-INVALID-CERTIFICATES: encoding of the type TD-INVALID-CERTIFICATES:
TD-INVALID-CERTIFICATES ::= SEQUENCE OF TD-INVALID-CERTIFICATES ::= SEQUENCE OF
ExternalPrincipalIdentifier ExternalPrincipalIdentifier
-- Each ExternalPrincipalIdentifier identifies a -- Each ExternalPrincipalIdentifier identifies a
-- certificate (sent by the client) with an invalid -- certificate (sent by the client) with an invalid
-- signature. -- 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 If more than one X.509 certificate signature is invalid, the KDC MAY
include one IssuerAndSerialNumber per invalid signature within the include one IssuerAndSerialNumber per invalid signature within the
TD-INVALID-CERTIFICATES. TD-INVALID-CERTIFICATES.
The client's X.509 certificate is validated according to [RFC3280]. The client's X.509 certificate is validated according to [RFC3280].
Based on local policy, the KDC may also check whether any X.509 Based on local policy, the KDC may also check whether any X.509
certificates in the certification path validating the client's certificates in the certification path validating the client's
certificate have been revoked. If any of them have been revoked, the certificate have been revoked. If any of them have been revoked, the
KDC MUST return an error message with the code KDC MUST return an error message with the code
skipping to change at page 13, line 13 skipping to change at page 14, line 43
KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field
of the client's X.509 certificate: of the client's X.509 certificate:
id-pkinit-KPClientAuth OBJECT IDENTIFIER ::= id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
pkinit(3) keyPurposeClientAuth(4) } pkinit(3) keyPurposeClientAuth(4) }
-- PKINIT client authentication. -- PKINIT client authentication.
-- Key usage bits that MUST be consistent: -- Key usage bits that MUST be consistent:
-- digitalSignature. -- digitalSignature.
The digitalSignature key usage bit MUST be asserted when the intended
purpose of the client certificate is restricted with the id-pkinit-
KPClientAuth EKU.
If this EKU KeyPurposeId is required but it is not present or if the 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 client certificate is restricted not to be used for PKINIT client
authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return 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 an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE. There
is no accompanying e-data for this error message. KDCs implementing is no accompanying e-data for this error message. KDCs implementing
this requirement SHOULD also accept the EKU KeyPurposeId id-ms-kp-sc- 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 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 are a large number of X.509 client certificates deployed for use with
PKINIT which have this EKU. PKINIT which have this EKU.
As a matter of local policy, the KDC MAY decide to reject requests on 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 OID's. the basis of the absence or presence of other specific EKU OID's.
If the client's public key is not accepted, the KDC returns an error If the digest algorithm used in generating the CA signature for the
message with the code KDC_ERR_CLIENT_NOT_TRUSTED. 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
what were 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 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 replay, and that the time skew falls within acceptable limits. The
recommendations for clock skew times in [RFC4120] apply here. If 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 check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
KRB_AP_ERR_SKEW, respectively. KRB_AP_ERR_SKEW, respectively.
If the clientPublicValue is filled in, indicating that the client If the clientPublicValue is filled in, indicating that the client
wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD 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 check to see if the key parameters satisfy its policy. If they do
skipping to change at page 14, line 5 skipping to change at page 15, line 46
TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-- Each AlgorithmIdentifier specifies a set of -- Each AlgorithmIdentifier specifies a set of
-- Diffie-Hellman domain parameters [IEEE1363]. -- Diffie-Hellman domain parameters [IEEE1363].
-- This list is in decreasing preference order. -- This list is in decreasing preference order.
TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
that the KDC supports in decreasing preference order, from which the that the KDC supports in decreasing preference order, from which the
client SHOULD pick one to retry the request. 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 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 KDC does not possess the corresponding key, the KDC MUST ignore the
kdcPkId field as if the client did not include one. kdcPkId field as if the client did not include one.
If there is a supportedCMSTypes field in the AuthPack, the KDC must If the digest algorithm used by the id-pkinit-authData is not
check to see if it supports any of the listed types. If it supports acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120]
more than one of the types, the KDC SHOULD use the one listed first. message with the code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED.
If it does not support any of them, it MUST return an error message The accompanying e-data MUST be encoded in TYPED-DATA although none
with the code KDC_ERR_ETYPE_NOSUPP [RFC4120]. is defined at this point.
3.2.3. Generation of KDC Reply 3.2.3. Generation of KDC Reply
Assuming that the client's request has been properly validated, the Assuming that the client's request has been properly validated, the
KDC proceeds as per [RFC4120], except as follows. KDC proceeds as per [RFC4120], except as follows.
The KDC MUST set the initial flag and include an authorization data The KDC MUST set the initial flag and include an authorization data
element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
ticket. The ad-data [RFC4120] field contains the DER encoding of the ticket. The ad-data [RFC4120] field contains the DER encoding of the
type AD-INITIAL-VERIFIED-CAS: type AD-INITIAL-VERIFIED-CAS:
AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
ExternalPrincipalIdentifier ExternalPrincipalIdentifier
-- Identifies the certification path based on which -- Identifies the certification path based on which
-- the client certificate was validated. -- the client certificate was validated.
-- Each ExternalPrincipalIdentifier identifies a CA -- Each ExternalPrincipalIdentifier identifies a CA
-- or a CA certificate (thereby its public key). -- or a CA certificate (thereby its public key).
The AD-INITIAL-VERIFIED-CAS structure identifies the certification
path based on 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).
The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT 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 containers if the list of CAs satisfies the AS' realm's local policy
(this corresponds to the TRANSITED-POLICY-CHECKED ticket flag (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
[RFC4120]). Furthermore, any TGS MUST copy such authorization data [RFC4120]). Furthermore, any TGS MUST copy such authorization data
from tickets used within a PA-TGS-REQ of the TGS-REQ into the 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 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 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 container, otherwise it MAY unwrap the authorization data out of the
AD-IF-RELEVANT container. AD-IF-RELEVANT container.
skipping to change at page 15, line 47 skipping to change at page 18, line 4
-- eContent field contains the DER encoding of the -- eContent field contains the DER encoding of the
-- type KDCDHKeyInfo. -- type KDCDHKeyInfo.
-- KDCDHKeyInfo is defined below. -- KDCDHKeyInfo is defined below.
serverDHNonce [1] DHNonce OPTIONAL serverDHNonce [1] DHNonce OPTIONAL
-- Present if and only if dhKeyExpiration is -- Present if and only if dhKeyExpiration is
-- present in the KDCDHKeyInfo. -- present in the KDCDHKeyInfo.
} }
KDCDHKeyInfo ::= SEQUENCE { KDCDHKeyInfo ::= SEQUENCE {
subjectPublicKey [0] BIT STRING, subjectPublicKey [0] BIT STRING,
-- KDC's DH public key. -- The KDC's DH public key.
-- The DH public key value is encoded as a BIT -- The DH public key value is encoded as a BIT
-- STRING according to [RFC3279]. -- STRING according to [RFC3279].
nonce [1] INTEGER (0..4294967295), nonce [1] INTEGER (0..4294967295),
-- Contains the nonce in the PKAuthenticator of the -- Contains the nonce in the pkAuthenticator field
-- request if DH keys are NOT reused, -- in the request if the DH keys are NOT reused,
-- 0 otherwise. -- 0 otherwise.
dhKeyExpiration [2] KerberosTime OPTIONAL, dhKeyExpiration [2] KerberosTime OPTIONAL,
-- Expiration time for KDC's key pair, -- Expiration time for KDC's key pair,
-- present if and only if DH keys are reused. If -- present if and only if the DH keys are reused.
-- this field is omitted then the serverDHNonce -- If present, the KDC's DH public key MUST not be
-- field MUST also be omitted. See Section 3.2.3.1. -- used past the point of this expiration time.
-- If this field is omitted then the serverDHNonce
-- field MUST also be omitted.
... ...
} }
The content of the AS-REP is otherwise unchanged from [RFC4120]. The 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 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 key. Instead, it encrypts it with either a shared key derived from a
Diffie-Hellman exchange, or a generated encryption key. The contents Diffie-Hellman exchange, or a generated encryption key. The contents
of the PA-PK-AS-REP indicate which key delivery method is used. of the PA-PK-AS-REP indicate which key delivery method is used.
In addition, the lifetime of the ticket returned by the KDC MUST NOT In addition, the lifetime of the ticket returned by the KDC MUST NOT
skipping to change at page 16, line 40 skipping to change at page 18, line 47
The ContentInfo [RFC3852] structure for the dhSignedData field is The ContentInfo [RFC3852] structure for the dhSignedData field is
filled in as follows: filled in as follows:
1. The contentType field of the type ContentInfo is id-signedData 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]), and the content field is a SignedData
(as defined in [RFC3852]). (as defined in [RFC3852]).
2. The eContentType field for the type SignedData is the OID value 2. The eContentType field for the type SignedData is the OID value
for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1) for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1)
security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }. 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 3. The eContent field for the type SignedData contains the DER
encoding of the type KDCDHKeyInfo. encoding of the type KDCDHKeyInfo.
4. The signerInfos field of the type SignedData contains a single 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 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 signerInfo, which contains the signature over the type
KDCDHKeyInfo. KDCDHKeyInfo.
5. The certificates field of the type SignedData contains 6. The certificates field of the type SignedData contains
certificates intended to facilitate certification path certificates intended to facilitate certification path
construction, so that the client can verify the KDC's signature construction, so that the client can verify the KDC's signature
over the type KDCDHKeyInfo. The information contained in the over the type KDCDHKeyInfo. The information contained in the
trustedCertifiers in the request SHOULD be used by the KDC as trustedCertifiers in the request SHOULD be used by the KDC as
hints to guide its selection of an appropriate certificate chain hints to guide its selection of an appropriate certificate chain
to return to the client. This field may only. be left empty if to return to the client. This field may be left empty if the KDC
the KDC public key specified by the kdcPkId field in the PA-PK- public key specified by the kdcPkId field in the PA-PK-AS-REQ was
AS-REQ was used for signing. Otherwise, for path validation, used for signing. Otherwise, for path validation, these
these certificates SHOULD be sufficient to construct at least one certificates SHOULD be sufficient to construct at least one
certification path from the KDC certificate to one trust anchor certification path from the KDC certificate to one trust anchor
acceptable by the client [CAPATH]. The KDC MUST be capable of acceptable by the client [RFC4158]. The KDC MUST be capable of
including such a set of certificates if configured to do so. The including such a set of certificates if configured to do so. The
certificates field MUST NOT contain "root" CA certificates. certificates field MUST NOT contain "root" CA certificates.
6. If the client included the clientDHNonce field, then the KDC may 7. If the client included the clientDHNonce field, then the KDC may
choose to reuse its DH keys (see Section 3.2.3.1). If the server choose to reuse its DH keys (see Section 3.2.3.1). If the server
reuses DH keys then it MUST include an expiration time in the reuses DH keys then it MUST include an expiration time in the
dhKeyExpiration field. Past the point of the expiration time, dhKeyExpiration field. Past the point of the expiration time,
the signature over the type DHRepInfo is considered expired/ the signature over the type DHRepInfo is considered expired/
invalid. When the server reuses DH keys then it MUST include a invalid. When the server reuses DH keys then it MUST include a
serverDHNonce at least as long as the length of keys for the serverDHNonce at least as long as the length of keys for the
symmetric encryption system used to encrypt the AS reply. Note symmetric encryption system used to encrypt the AS reply. Note
that including the serverDHNonce changes how the client and that including the serverDHNonce changes how the client and
server calculate the key to use to encrypt the reply; see below server calculate the key to use to encrypt the reply; see below
for details. The KDC SHOULD NOT reuse DH keys unless the for details. The KDC SHOULD NOT reuse DH keys unless the
skipping to change at page 18, line 32 skipping to change at page 20, line 51
kcrypto profile [RFC3961] for the enctype of the AS reply key. 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 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 the serverDHNonce; otherwise, let both n_c and n_k be empty octet
strings. strings.
5. The AS reply key k is: 5. The AS reply key k is:
k = octetstring2key(DHSharedSecret | n_c | n_k) k = octetstring2key(DHSharedSecret | n_c | n_k)
3.2.3.2. Using Public Key Encryption If the hash algorithm used in the key derivation function (currently
only octetstring2key() is defined) is not acceptable by the KDC, the
KDC MUST return a KRB-ERROR [RFC4120] message with the code
KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED. The accompanying e-data MUST be
encoded in TYPED-DATA although none is defined at this point.
In this case, the PA-PK-AS-REP contains a ContentInfo structure 3.2.3.2. Using Public Key Encryption
wrapped in an OCTET STRING. The AS reply key is encrypted in the
encKeyPack field, which contains data of type ReplyKeyPack:
ReplyKeyPack ::= SEQUENCE { In this case, the PA-PK-AS-REP contains an encKeyPack structure where
replyKey [0] EncryptionKey, the AS reply key is encrypted.
-- Contains the session key used to encrypt the
-- enc-part field in the AS-REP.
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.
...
}
The ContentInfo [RFC3852] structure for the encKeyPack field is The ContentInfo [RFC3852] structure for the encKeyPack field is
filled in as follows: filled in as follows:
1. The contentType field of the type ContentInfo is id-envelopedData 1. The contentType field of the type ContentInfo is id-envelopedData
(as defined in [RFC3852]), and the content field is an (as defined in [RFC3852]), and the content field is an
EnvelopedData (as defined in [RFC3852]). EnvelopedData (as defined in [RFC3852]).
2. The contentType field for the type EnvelopedData is id- 2. The contentType field for the type EnvelopedData is id-
signedData: { iso (1) member-body (2) us (840) rsadsi (113549) signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
pkcs (1) pkcs7 (7) signedData (2) }. pkcs (1) pkcs7 (7) signedData (2) }.
3. The eContentType field for the inner type SignedData (when 3. The eContentType field for the inner type SignedData (when
decrypted from the encryptedContent field for the type decrypted from the encryptedContent field for the type
EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6) EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6)
internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }. 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 4. The eContent field for the inner type SignedData contains the DER
encoding of the type ReplyKeyPack. encoding of the type ReplyKeyPack (as described below).
5. The signerInfos field of the inner type SignedData contains a 5. The signerInfos field of the inner type SignedData contains a
single signerInfo, which contains the signature over the type single signerInfo, which contains the signature for the type
ReplyKeyPack. ReplyKeyPack.
6. The certificates field of the inner type SignedData contains 6. The certificates field of the inner type SignedData contains
certificates intended to facilitate certification path certificates intended to facilitate certification path
construction, so that the client can verify the KDC's signature construction, so that the client can verify the KDC's signature
over the type ReplyKeyPack. The information contained in the for the type ReplyKeyPack. The information contained in the
trustedCertifiers in the request SHOULD be used by the KDC as trustedCertifiers in the request SHOULD be used by the KDC as
hints to guide its selection of an appropriate certificate chain hints to guide its selection of an appropriate certificate chain
to return to the client. This field may only be left empty if to return to the client. This field may be left empty if the KDC
the KDC public key specified by the kdcPkId field in the PA-PK- public key specified by the kdcPkId field in the PA-PK-AS-REQ was
AS-REQ was used for signing. Otherwise, for path validation, used for signing. Otherwise, for path validation, these
these certificates SHOULD be sufficient to construct at least one certificates SHOULD be sufficient to construct at least one
certification path from the KDC certificate to one trust anchor certification path from the KDC certificate to one trust anchor
acceptable by the client [CAPATH]. The KDC MUST be capable of acceptable by the client [RFC4158]. The KDC MUST be capable of
including such a set of certificates if configured to do so. The including such a set of certificates if configured to do so. The
certificates field MUST NOT contain "root" CA certificates. certificates field MUST NOT contain "root" CA certificates.
7. The recipientInfos field of the type EnvelopedData is a SET which 7. The recipientInfos field of the type EnvelopedData is a SET which
MUST contain exactly one member of type KeyTransRecipientInfo. MUST contain exactly one member of type KeyTransRecipientInfo.
The encryptedKey of this member contains the temporary key which The encryptedKey of this member contains the temporary key which
is encrypted using the client's public key. is encrypted using the client's public key.
8. The unprotectedAttrs or originatorInfo fields of the type 8. The unprotectedAttrs or originatorInfo fields of the type
EnvelopedData MAY be present. EnvelopedData MAY be present.
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 Implementations of this RSA encryption key delivery method are
RECOMMENDED to support for RSA keys at least 2048 bits in size. RECOMMENDED to support RSA keys at least 2048 bits in size.
3.2.4. Receipt of KDC Reply 3.2.4. Receipt of KDC Reply
Upon receipt of the KDC's reply, the client proceeds as follows. If 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 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 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 in Section 3.2.3.1. Otherwise, the message contains the encKeyPack
field, and the client decrypts and extracts the temporary key in the field, and the client decrypts and extracts the temporary key in the
encryptedKey field of the member KeyTransRecipientInfo, and then uses encryptedKey field of the member KeyTransRecipientInfo, and then uses
that as the AS reply key. that as the AS reply key.
skipping to change at page 21, line 12 skipping to change at page 23, line 36
is intended for a Kerberos KDC, the client MUST require that the KDC is intended for a Kerberos KDC, the client MUST require that the KDC
certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc: certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc:
id-pkinit-KPKdc OBJECT IDENTIFIER ::= id-pkinit-KPKdc OBJECT IDENTIFIER ::=
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
pkinit(3) keyPurposeKdc(5) } pkinit(3) keyPurposeKdc(5) }
-- Signing KDC responses. -- Signing KDC responses.
-- Key usage bits that MUST be consistent: -- Key usage bits that MUST be consistent:
-- digitalSignature. -- digitalSignature.
The digitalSignature key usage bit MUST be asserted when the intended
purpose of KDC certificate is restricted with the id-pkinit-KPKdc
EKU.
If the KDC certificate contains the Kerberos TGS name encoded as an 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 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. a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required.
If all applicable checks are satisfied, the client then decrypts the 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, enc-part field of the KDC-REP in the AS-REP using the AS reply key,
and then proceeds as described in [RFC4120]. and then proceeds as described in [RFC4120].
Implementation note: CAs issuing KDC certificates SHOULD place all Implementation note: CAs issuing KDC certificates SHOULD place all
"short" and "fully-qualified" Kerberos realm names of the KDC (one "short" and "fully-qualified" Kerberos realm names of the KDC (one
skipping to change at page 24, line 15 skipping to change at page 26, line 44
operations. Strictly speaking, this is also true of standard operations. Strictly speaking, this is also true of standard
Kerberos, although the potential cost is not as great, because Kerberos, although the potential cost is not as great, because
standard Kerberos does not make use of public-key cryptography. By standard Kerberos does not make use of public-key cryptography. By
using DH based key delivery and reusing DH keys, the necessary crypto using DH based key delivery and reusing DH keys, the necessary crypto
processing cost per request can be minimized. processing cost per request can be minimized.
The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
permit empty SEQUENCEs to be encoded. Such empty sequences may only permit empty SEQUENCEs to be encoded. Such empty sequences may only
be used if the KDC itself vouches for the user's certificate. be used if the KDC itself vouches for the user's certificate.
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.
5. Acknowledgements 5. Acknowledgements
The following people have made significant contributions to this The following people have made significant contributions to this
draft: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist draft: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist
Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle, Astrand, Ken Raeburn, Nicolas Williams, John Wray, Tom Yu, Jeffrey
Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik Hutzelman, David Cross, Dan Simon, Karthik Jaganathan, Chaskiel M
Jaganathan, and Chaskiel M Grundman. Grundman and Jeffrey Altman.
Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay and Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay and
Chris Walstad discovered a binding issue between the AS-REQ and AS- Chris Walstad discovered a binding issue between the AS-REQ and AS-
REP in draft -26, the asChecksum field was added as the result. REP in draft -26, the asChecksum field was added as the result.
Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and
Jonathan Trostle who wrote earlier versions of this document. Jonathan Trostle who wrote earlier versions of this document.
The authors are indebted to the Kerberos working group chair Jeffrey The authors are indebted to the Kerberos working group chair Jeffrey
Hutzelman who kept track of various issues and was enormously helpful Hutzelman who kept track of various issues and was enormously helpful
skipping to change at page 26, line 20 skipping to change at page 27, line 107
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120, Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005. July 2005.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Version 5 Generic Security Service Application Program Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2", RFC 4121, Interface (GSS-API) Mechanism: Version 2", RFC 4121,
July 2005. July 2005.
[X.509-97] ITU-T Recommendation X.509: The Directory - Authentication
Framework, 1997.
[X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, [X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
Information technology - Abstract Syntax Notation One Information technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation. (ASN.1): Specification of basic notation.
[X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, [X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
Information technology - ASN.1 encoding Rules: Specification Information technology - ASN.1 encoding Rules: Specification
of Basic Encoding Rules (BER), Canonical Encoding Rules of Basic Encoding Rules (BER), Canonical Encoding Rules
(CER) and Distinguished Encoding Rules (DER). (CER) and Distinguished Encoding Rules (DER).
7.2. Informative References 7.2. Informative References
[CAPATH] RFC-Editor: To be replaced by RFC number for draft-ietf-
pkix-certpathbuild. Work in Progress.
[LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key [LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
Sizes", Journal of Cryptology 14 (2001) 255-293. Sizes", Journal of Cryptology 14 (2001) 255-293.
[ODL99] Odlyzko, A., "Discrete logarithms: The past and the [ODL99] Odlyzko, A., "Discrete logarithms: The past and the
future, Designs, Codes, and Cryptography (1999)". future, Designs, Codes, and Cryptography (1999)".
[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.
Appendix A. PKINIT ASN.1 Module Appendix A. PKINIT ASN.1 Module
KerberosV5-PK-INIT-SPEC { KerberosV5-PK-INIT-SPEC {
iso(1) identified-organization(3) dod(6) internet(1) iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2) modules(4) pkinit(5) security(5) kerberosV5(2) modules(4) pkinit(5)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN } DEFINITIONS EXPLICIT TAGS ::= BEGIN
IMPORTS IMPORTS
SubjectPublicKeyInfo, AlgorithmIdentifier SubjectPublicKeyInfo, AlgorithmIdentifier
FROM PKIX1Explicit88 { iso (1) FROM PKIX1Explicit88 { iso (1)
skipping to change at page 28, line 5 skipping to change at page 31, line 4
-- The contentType field of the type ContentInfo -- The contentType field of the type ContentInfo
-- is id-signedData (1.2.840.113549.1.7.2), -- is id-signedData (1.2.840.113549.1.7.2),
-- and the content field is a SignedData. -- and the content field is a SignedData.
-- The eContentType field for the type SignedData is -- The eContentType field for the type SignedData is
-- id-pkinit-authData (1.3.6.1.5.2.3.1), and the -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
-- eContent field contains the DER encoding of the -- eContent field contains the DER encoding of the
-- type AuthPack. -- type AuthPack.
-- AuthPack is defined below. -- AuthPack is defined below.
trustedCertifiers [1] SEQUENCE OF trustedCertifiers [1] SEQUENCE OF
ExternalPrincipalIdentifier OPTIONAL, ExternalPrincipalIdentifier OPTIONAL,
-- A list of CAs, trusted by the client, that can
-- be used to certify the KDC. -- Contains a list of CAs, trusted by the client,
-- that can be used to certify the KDC.
-- Each ExternalPrincipalIdentifier identifies a CA -- Each ExternalPrincipalIdentifier identifies a CA
-- or a CA certificate (thereby its public key). -- or a CA certificate (thereby its public key).
-- The information contained in the -- The information contained in the
-- trustedCertifiers SHOULD be used by the KDC as -- trustedCertifiers SHOULD be used by the KDC as
-- hints to guide its selection of an appropriate -- hints to guide its selection of an appropriate
-- certificate chain to return to the client. -- certificate chain to return to the client.
kdcPkId [2] IMPLICIT OCTET STRING kdcPkId [2] IMPLICIT OCTET STRING
OPTIONAL, OPTIONAL,
-- Contains a CMS type SignerIdentifier encoded -- Contains a CMS type SignerIdentifier encoded
-- according to [RFC3852]. -- according to [RFC3852].
skipping to change at page 31, line 4 skipping to change at page 33, line 51
-- Contains a CMS type ContentInfo encoded according -- Contains a CMS type ContentInfo encoded according
-- to [RFC3852]. -- to [RFC3852].
-- The contentType field of the type ContentInfo is -- The contentType field of the type ContentInfo is
-- id-signedData (1.2.840.113549.1.7.2), and the -- id-signedData (1.2.840.113549.1.7.2), and the
-- content field is a SignedData. -- content field is a SignedData.
-- The eContentType field for the type SignedData is -- The eContentType field for the type SignedData is
-- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
-- eContent field contains the DER encoding of the -- eContent field contains the DER encoding of the
-- type KDCDHKeyInfo. -- type KDCDHKeyInfo.
-- KDCDHKeyInfo is defined below. -- KDCDHKeyInfo is defined below.
serverDHNonce [1] DHNonce OPTIONAL serverDHNonce [1] DHNonce OPTIONAL
-- Present if and only if dhKeyExpiration is -- Present if and only if dhKeyExpiration is
-- present. -- present.
} }
KDCDHKeyInfo ::= SEQUENCE { KDCDHKeyInfo ::= SEQUENCE {
subjectPublicKey [0] BIT STRING, subjectPublicKey [0] BIT STRING,
-- KDC's DH public key. -- The KDC's DH public key.
-- The DH public key value is encoded as a BIT -- The DH public key value is encoded as a BIT
-- STRING according to [RFC3279]. -- STRING according to [RFC3279].
nonce [1] INTEGER (0..4294967295), nonce [1] INTEGER (0..4294967295),
-- Contains the nonce in the PKAuthenticator of the -- Contains the nonce in the pkAuthenticator field
-- request if DH keys are NOT reused, -- in the request if the DH keys are NOT reused,
-- 0 otherwise. -- 0 otherwise.
dhKeyExpiration [2] KerberosTime OPTIONAL, dhKeyExpiration [2] KerberosTime OPTIONAL,
-- Expiration time for KDC's key pair, -- Expiration time for KDC's key pair,
-- present if and only if DH keys are reused. If -- present if and only if the DH keys are reused.
-- this field is omitted then the serverDHNonce -- 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. -- field MUST also be omitted.
... ...
} }
ReplyKeyPack ::= SEQUENCE { ReplyKeyPack ::= SEQUENCE {
replyKey [0] EncryptionKey, replyKey [0] EncryptionKey,
-- Contains the session key used to encrypt the -- Contains the session key used to encrypt the
-- enc-part field in the AS-REP. -- enc-part field in the AS-REP, i.e. the
-- AS reply key.
asChecksum [1] Checksum, asChecksum [1] Checksum,
-- Contains the checksum of the AS-REQ -- Contains the checksum of the AS-REQ
-- corresponding to the containing AS-REP. -- corresponding to the containing AS-REP.
-- The checksum is performed over the type AS-REQ. -- The checksum is performed over the type AS-REQ.
-- The protocol key [RFC3961] of the checksum is the -- The protocol key [RFC3961] of the checksum is the
-- replyKey and the key usage number is 6. -- replyKey and the key usage number is 6.
-- If the replyKey's enctype is "newer" [RFC4120] -- If the replyKey's enctype is "newer" [RFC4120]
-- [RFC4121], the checksum is the required -- [RFC4121], the checksum is the required
-- checksum operation [RFC3961] for that enctype. -- checksum operation [RFC3961] for that enctype.
-- The client MUST verify this checksum upon receipt -- The client MUST verify this checksum upon receipt
skipping to change at page 35, line 7 skipping to change at page 38, line 7
client's public key is bound to the account that has this client's public key is bound to the account that has this
UserPrincipalName value). UserPrincipalName value).
It should be noted that all Microsoft Kerberos realm names are domain It should be noted that all Microsoft Kerberos realm names are domain
style realm names and strictly in upper case. In addition, the style realm names and strictly in upper case. In addition, the
UserPrincipalName attribute is globally unique in Windows 2000 and UserPrincipalName attribute is globally unique in Windows 2000 and
Windows 2003. Windows 2003.
Authors' Addresses Authors' Addresses
Brian Tung
USC Information Sciences Institute
4676 Admiralty Way Suite 1001
Marina del Rey, CA 90292
US
Email: brian@isi.edu
Larry Zhu Larry Zhu
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
US US
Email: lzhu@microsoft.com Email: lzhu@microsoft.com
Brian Tung
USC Information Sciences Institute
4676 Admiralty Way Suite 1001
Marina del Rey, CA 90292
US
Email: brian@isi.edu
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 66 change blocks. 
149 lines changed or deleted 314 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/