< draft-ietf-cat-kerberos-pk-init-28.txt		draft-ietf-cat-kerberos-pk-init-29.txt >
	NETWORK WORKING GROUP B. Tung		NETWORK WORKING GROUP B. Tung
	Internet-Draft USC Information Sciences Institute		Internet-Draft USC Information Sciences Institute
	Expires: March 16, 2006 L. Zhu		Expires: April 22, 2006 L. Zhu
	Microsoft Corporation		Microsoft Corporation
	September 12, 2005		October 19, 2005
	Public Key Cryptography for Initial Authentication in Kerberos		Public Key Cryptography for Initial Authentication in Kerberos
	draft-ietf-cat-kerberos-pk-init-28		draft-ietf-cat-kerberos-pk-init-29
	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 March 16, 2006.		This Internet-Draft will expire on April 22, 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
	skipping to change at page 2, line 18 ¶		skipping to change at page 2, line 18 ¶
	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 . . . . . . . . . 4
	3.1.1. Required Algorithms . . . . . . . . . . . . . . . . . 4		3.1.1. Required Algorithms . . . . . . . . . . . . . . . . . 4
	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 . . . . . . . . . . . . . . 10
	3.2.3. Generation of KDC Reply . . . . . . . . . . . . . . . 14		3.2.3. Generation of KDC Reply . . . . . . . . . . . . . . . 14
	3.2.4. Receipt of KDC Reply . . . . . . . . . . . . . . . . . 19		3.2.4. Receipt of KDC Reply . . . . . . . . . . . . . . . . . 20
	3.3. Interoperability Requirements . . . . . . . . . . . . . . 20		3.3. Interoperability Requirements . . . . . . . . . . . . . . 21
	3.4. KDC Indication of PKINIT Support . . . . . . . . . . . . . 21		3.4. KDC Indication of PKINIT Support . . . . . . . . . . . . . 21
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 21		4. Security Considerations . . . . . . . . . . . . . . . . . . . 22
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 24		7.1. Normative References . . . . . . . . . . . . . . . . . . . 25
	7.2. Informative References . . . . . . . . . . . . . . . . . . 25		7.2. Informative References . . . . . . . . . . . . . . . . . . 26
	Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 25		Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 26
	Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 31		Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 32
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33		Appendix C. Miscellaneous Information about Microsoft Windows
	Intellectual Property and Copyright Statements . . . . . . . . . . 34		PKINIT Implementations . . . . . . . . . . . . . . . 33
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
			Intellectual Property and Copyright Statements . . . . . . . . . . 36
	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 5, line 14 ¶		skipping to change at page 5, line 14 ¶
	o AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-		o AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-
	sha1-96 [RFC3962].		sha1-96 [RFC3962].
	o Signature algorithm: sha-1WithRSAEncryption [RFC3279].		o Signature algorithm: sha-1WithRSAEncryption [RFC3279].
	o AS reply key delivery method: Diffie-Hellman key exchange		o AS reply key delivery method: Diffie-Hellman key exchange
	[RFC2631].		[RFC2631].
	In addition, implementations of this specification MUST be capable of		In addition, implementations of this specification MUST be capable of
	processing the Extended Key Usage (EKU) extension and the id-pksan		processing the Extended Key Usage (EKU) extension and the id-pkinit-
	(as defined in Section 3.2.2) otherName of the Subject Alternative		san (as defined in Section 3.2.2) otherName of the Subject
	Name (SAN) extension in X.509 certificates [RFC3280], if present.		Alternative Name (SAN) extension in X.509 certificates [RFC3280], if
			present.
	3.1.2. Defined Message and Encryption Types		3.1.2. Defined Message and Encryption Types
	PKINIT makes use of the following new pre-authentication types:		PKINIT makes use of the following new pre-authentication types:
	PA_PK_AS_REQ 16		PA_PK_AS_REQ 16
	PA_PK_AS_REP 17		PA_PK_AS_REP 17
	PKINIT also makes use of the following new authorization data type:		PKINIT also makes use of the following new authorization data type:
	skipping to change at page 5, line 47 ¶		skipping to change at page 5, line 48 ¶
	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
	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 AS-REQ		PKINIT defines the following encryption types, for use in the etype
	message to indicate acceptance of the corresponding algorithms that		field of the AS-REQ [RFC4120] message to indicate acceptance of the
	can used by Cryptographic Message Syntax (CMS) [RFC3852] messages in		corresponding algorithms that can used by Cryptographic Message
	the reply:		Syntax (CMS) [RFC3852] messages in the reply:
	dsaWithSHA1-CmsOID 9		dsaWithSHA1-CmsOID 9
			-- Indicates that the client supports dsaWithSHA1
	md5WithRSAEncryption-CmsOID 10		md5WithRSAEncryption-CmsOID 10
			-- Indicates that the client supports md5WithRSAEncryption
	sha1WithRSAEncryption-CmsOID 11		sha1WithRSAEncryption-CmsOID 11
			-- Indicates that the client supports sha1WithRSAEncryption
	rc2CBC-EnvOID 12		rc2CBC-EnvOID 12
	rsaEncryption-EnvOID (PKCS1 v1.5) 13		-- Indicates that the client supports rc2CBC
	rsaES-OAEP-EnvOID (PKCS1 v2.0) 14		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		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) [X690] (unless		encoded using Distinguished Encoding Rules (DER) [X680] [X690]
	otherwise noted). All data structures carried in OCTET STRINGs must		(unless otherwise noted). All data structures carried in OCTET
	be encoded according to the rules specified in corresponding		STRINGs must be encoded according to the rules specified in
	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 infinite 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
	skipping to change at page 6, line 48 ¶		skipping to change at page 7, line 8 ¶
	PKINIT uses the following signature algorithm identifiers [RFC3279]:		PKINIT uses the following signature algorithm identifiers [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 [RFC3447]
	for encrypting the temporary key with a public key:		for encrypting the temporary key with a public key:
	rsaEncryption (PKCS1 v1.5)		rsaEncryption (PKCS1 v2.1)
	id-RSAES-OAEP (PKCS1 v2.0)		id-RSAES-OAEP (PKCS1 v2.1)
	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)
	rc2-cbc (RC2, CBC mode)		rc2-cbc (RC2, CBC mode)
	id-aes256-CBC (AES-256, CBC mode)		id-aes256-CBC (AES-256, CBC mode)
	3.2. PKINIT Pre-authentication Syntax and Use		3.2. PKINIT Pre-authentication Syntax and Use
	skipping to change at page 7, line 29 ¶		skipping to change at page 7, line 38 ¶
	type PA-PK-AS-REQ, is included.		type PA-PK-AS-REQ, is included.
	PA-PK-AS-REQ ::= SEQUENCE {		PA-PK-AS-REQ ::= SEQUENCE {
	signedAuthPack [0] IMPLICIT OCTET STRING,		signedAuthPack [0] IMPLICIT OCTET STRING,
	-- Contains a CMS type ContentInfo encoded		-- Contains a CMS type ContentInfo encoded
	-- according to [RFC3852].		-- according to [RFC3852].
	-- 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-pkauthdata (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		-- A list of CAs, trusted by the client, that can
	-- be used to certify the KDC.		-- 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
	skipping to change at page 9, line 29 ¶		skipping to change at page 9, line 39 ¶
	...		...
	}		}
	The ContentInfo [RFC3852] structure for the signedAuthPack field is		The ContentInfo [RFC3852] structure for the signedAuthPack field is
	filled out as follows:		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-pkauthdata:		2. The eContentType field for the type SignedData is id-pkinit-
	{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)		authData: { iso(1) org(3) dod(6) internet(1) security(5)
	pkinit(3) pkauthdata(1) }.		kerberosv5(2) pkinit(3) authData(1) }.
	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 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
	skipping to change at page 12, line 15 ¶		skipping to change at page 12, line 25 ¶
	1. If the KDC has its own binding between either the client's		1. If the KDC has its own binding between either the client's
	signature-verification public key or the client's certificate and		signature-verification public key or the client's certificate and
	the client's Kerberos principal name, it uses that binding.		the client's Kerberos principal name, it uses that binding.
	2. Otherwise, if the client's X.509 certificate contains a Subject		2. Otherwise, if the client's X.509 certificate contains a Subject
	Alternative Name (SAN) extension carrying a KRB5PrincipalName		Alternative Name (SAN) extension carrying a KRB5PrincipalName
	(defined below) in the otherName field of the type GeneralName		(defined below) in the otherName field of the type GeneralName
	[RFC3280], it binds the client's X.509 certificate to that name.		[RFC3280], it binds the client's X.509 certificate to that name.
	The type of the otherName field is AnotherName. The type-id field		The type of the otherName field is AnotherName. The type-id field
	of the type AnotherName is id-pksan:		of the type AnotherName is id-pkinit-san:
	id-pksan OBJECT IDENTIFIER ::=		id-pkinit-san 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)
	x509-sanan (2) }		x509SanAN (2) }
	And the value field of the type AnotherName is a		And the value field of the type AnotherName is a
	KRB5PrincipalName.		KRB5PrincipalName.
	KRB5PrincipalName ::= SEQUENCE {		KRB5PrincipalName ::= SEQUENCE {
	realm [0] Realm,		realm [0] Realm,
	principalName [1] PrincipalName		principalName [1] PrincipalName
	}		}
	If the KDC does not have its own binding and there is no		If the KDC does not have its own binding and there is no
	skipping to change at page 12, line 42 ¶		skipping to change at page 12, line 52 ¶
	KRB5PrincipalName in the client's X.509 certificate (including the		KRB5PrincipalName in the client's X.509 certificate (including the
	realm name), the KDC MUST return an error message with the code		realm name), the KDC MUST return an error message with the code
	KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for		KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for
	this error message.		this error message.
	Even if the certification path is validated and the certificate is		Even if the certification path is validated and the certificate is
	mapped to the client's principal name, the KDC may decide not to		mapped to the client's principal name, the KDC may decide not to
	accept the client's certificate, depending on local policy.		accept the client's certificate, depending on local policy.
	The KDC MAY require the presence of an Extended Key Usage (EKU)		The KDC MAY require the presence of an Extended Key Usage (EKU)
	KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the		KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field
	client's X.509 certificate:		of the client's X.509 certificate:
	id-pkekuoid 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) pkekuoid(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.
	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-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 client's public key is not accepted, the KDC returns an error
	message with the code KDC_ERR_CLIENT_NOT_TRUSTED.		message with the code KDC_ERR_CLIENT_NOT_TRUSTED.
	skipping to change at page 14, line 41 ¶		skipping to change at page 14, line 51 ¶
	Application servers that understand this authorization data type		Application servers that understand this authorization data type
	SHOULD apply local policy to determine whether a given ticket bearing		SHOULD apply local policy to determine whether a given ticket bearing
	such a type *not* contained within an AD-IF-RELEVANT container is		such a type *not* contained within an AD-IF-RELEVANT container is
	acceptable. (This corresponds to the AP server checking the		acceptable. (This corresponds to the AP server checking the
	transited field when the TRANSITED-POLICY-CHECKED flag has not been		transited field when the TRANSITED-POLICY-CHECKED flag has not been
	set [RFC4120].) If such a data type is contained within an AD-IF-		set [RFC4120].) If such a data type is contained within an AD-IF-
	RELEVANT container, AP servers MAY apply local policy to determine		RELEVANT container, AP servers MAY apply local policy to determine
	whether the authorization data is acceptable.		whether the authorization data is acceptable.
	The content of the AS-REP is otherwise unchanged from [RFC4120]. The		A pre-authentication data element, whose padata-type is PA_PK_AS_REP
	KDC encrypts the reply as usual, but not with the client's long-term		and whose padata-value contains the DER encoding of the type PA-PK-
	key. Instead, it encrypts it with either a shared key derived from a		AS-REP (defined below), is included in the AS-REP [RFC4120].
	Diffie-Hellman exchange, or a generated encryption key. The contents
	of the PA-PK-AS-REP indicate which key delivery method is used:
	PA-PK-AS-REP ::= CHOICE {		PA-PK-AS-REP ::= CHOICE {
	dhInfo [0] DHRepInfo,		dhInfo [0] DHRepInfo,
	-- Selected when Diffie-Hellman key exchange is		-- Selected when Diffie-Hellman key exchange is
	-- used.		-- used.
	encKeyPack [1] IMPLICIT OCTET STRING,		encKeyPack [1] IMPLICIT OCTET STRING,
	-- Selected when public key encryption is used.		-- Selected when public key encryption is used.
	-- Contains a CMS type ContentInfo encoded		-- Contains a CMS type ContentInfo encoded
	-- according to [RFC3852].		-- according to [RFC3852].
	-- The contentType field of the type ContentInfo is		-- The contentType field of the type ContentInfo is
	-- id-envelopedData (1.2.840.113549.1.7.3).		-- id-envelopedData (1.2.840.113549.1.7.3).
	-- The content field is an EnvelopedData.		-- The content field is an EnvelopedData.
	-- The contentType field for the type EnvelopedData		-- The contentType field for the type EnvelopedData
	-- is id-signedData (1.2.840.113549.1.7.2).		-- is id-signedData (1.2.840.113549.1.7.2).
	-- The eContentType field for the inner type		-- The eContentType field for the inner type
	-- SignedData (when unencrypted) is id-pkrkeydata		-- SignedData (when unencrypted) is
	-- (1.2.840.113549.1.7.3) and the eContent field		-- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
	-- contains the DER encoding of the type		-- eContent field contains the DER encoding of the
	-- ReplyKeyPack.		-- type ReplyKeyPack.
	-- ReplyKeyPack is defined in Section 3.2.3.2.		-- ReplyKeyPack is defined in Section 3.2.3.2.
	...		...
	}		}
	DHRepInfo ::= SEQUENCE {		DHRepInfo ::= SEQUENCE {
	dhSignedData [0] IMPLICIT OCTET STRING,		dhSignedData [0] IMPLICIT OCTET STRING,
	-- 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-pkdhkeydata (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 in the KDCDHKeyInfo.		-- present in the KDCDHKeyInfo.
	}		}
	KDCDHKeyInfo ::= SEQUENCE {		KDCDHKeyInfo ::= SEQUENCE {
	subjectPublicKey [0] BIT STRING,		subjectPublicKey [0] BIT STRING,
	skipping to change at page 16, line 4 ¶		skipping to change at page 16, line 12 ¶
	nonce [1] INTEGER (0..4294967295),		nonce [1] INTEGER (0..4294967295),
	-- Contains the nonce in the PKAuthenticator of the		-- Contains the nonce in the PKAuthenticator of the
	-- request if DH keys are NOT reused,		-- request if 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 DH keys are reused. If
	-- this field is omitted then the serverDHNonce		-- this field is omitted then the serverDHNonce
	-- field MUST also be omitted. See Section 3.2.3.1.		-- field MUST also be omitted. See Section 3.2.3.1.
	...		...
	}		}
			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.
			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		3.2.3.1. Using Diffie-Hellman Key Exchange
	In this case, the PA-PK-AS-REP contains a DHRepInfo structure.		In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
	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-pkdhkeydata: { 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) pkdhkeydata(2) }.		security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }.
	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 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		5. The certificates field of the type SignedData contains
	certificates intended to facilitate certification path		certificates intended to facilitate certification path
	skipping to change at page 18, line 46 ¶		skipping to change at page 19, line 36 ¶
	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-pkrkeydata: { 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) pkrkeydata(3) }.		internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }.
	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.
	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 over 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
	skipping to change at page 19, line 45 ¶		skipping to change at page 20, line 33 ¶
	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.
	If the public key encrytion method is used, the client MUST verify		If the public key encryption method is used, the client MUST verify
	the asChecksum contained in the ReplyKeyPack.		the asChecksum contained in the ReplyKeyPack.
	In either case, the client MUST verify the signature in the		In either case, the client MUST verify the signature in the
	SignedData according to [RFC3852]. The KDC's X.509 certificate MUST		SignedData according to [RFC3852]. The KDC's X.509 certificate MUST
	be validated according to [RFC3280]. In addition, unless the client		be validated according to [RFC3280]. In addition, unless the client
	can otherwise verify that the public key used to verify the KDC's		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		signature is bound to the KDC of the target realm, the KDC's X.509
	certificate MUST contain a Subject Alternative Name extension		certificate MUST contain a Subject Alternative Name extension
	[RFC3280] carrying an AnotherName whose type-id is id-pksan (as		[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		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		matches the name of the TGS of the target realm (as defined in
	Section 7.3 of [RFC4120]).		Section 7.3 of [RFC4120]).
	Unless the client knows by some other means that the KDC certificate		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		is intended for a Kerberos KDC, the client MUST require that the KDC
	certificate contains the EKU KeyPurposeId [RFC3280] id-pkkdcekuoid:		certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc:
	id-pkkdcekuoid 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) pkkdcekuoid(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.
	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-pksan SAN, this certificate is certified by the issuing CA as a		id-pkinit-san SAN, this certificate is certified by the issuing CA as
	KDC certificate, therefore the id-pkkdcekuoid 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
	per GeneralName [RFC3280]) into the KDC certificate to allow maximum		per GeneralName [RFC3280]) into the KDC certificate to allow maximum
	flexibility.		flexibility.
	skipping to change at page 21, line 35 ¶		skipping to change at page 22, line 24 ¶
	KDC_ERR_PREAUTH_FAILED SHOULD be returned.		KDC_ERR_PREAUTH_FAILED SHOULD be returned.
	KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in		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		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		STRING), and clients MUST ignore this and any other value. Future
	extensions to this protocol may specify other data to send instead of		extensions to this protocol may specify other data to send instead of
	an empty OCTET STRING.		an empty OCTET STRING.
	4. Security Considerations		4. Security Considerations
			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		The symmetric reply key size and Diffie-Hellman field size or RSA
	modulus size should be chosen so as to provide sufficient		modulus size should be chosen so as to provide sufficient
	cryptographic security [RFC3766].		cryptographic security [RFC3766].
	When MODP Diffie-Hellman is used, the exponents should have at least		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		twice as many bits as the symmetric keys that will be derived from
	them [ODL99].		them [ODL99].
	PKINIT raises certain security considerations beyond those that can		PKINIT raises certain security considerations beyond those that can
	be regulated strictly in protocol definitions. We will address them		be regulated strictly in protocol definitions. We will address them
	in this section.		in this section.
	PKINIT extends the cross-realm model to the public-key		PKINIT extends the cross-realm model to the public-key
	infrastructure. Users of PKINIT must understand security policies		infrastructure. Users of PKINIT must understand security policies
	and procedures appropriate to the use of Public Key Infrastructures		and procedures appropriate to the use of Public Key Infrastructures
	[RFC3280].		[RFC3280].
	In order to trust a KDC certificate that is certified by a CA as a		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		KDC certificate for a target realm (for example, by asserting the TGS
	name of that Kerberos realm as an id-pksan SAN and/or restricting the		name of that Kerberos realm as an id-pkinit-san SAN and/or
	certificate usage by using the id-pkkdcekuoid EKU, as described in		restricting the certificate usage by using the id-pkinit-KPKdc EKU,
	Section 3.2.4), the client MUST verify that the KDC certificate's		as described in Section 3.2.4), the client MUST verify that the KDC
	issuing CA is authorized to issue KDC certificates for that target		certificate's issuing CA is authorized to issue KDC certificates for
	realm. Otherwise, the binding between the KDC certificate and the		that target realm. Otherwise, the binding between the KDC
	KDC of the target realm is not established.		certificate and the KDC of the target realm is not established.
	How to validate this authorization is a matter of local policy. A		How to validate this authorization is a matter of local policy. A
	way to achieve this is the configuration of specific sets of		way to achieve this is the configuration of specific sets of
	intermediary CAs and trust anchors, one of which must be on the KDC		intermediary CAs and trust anchors, one of which must be on the KDC
	certificate's certification path [RFC3280]; and for each CA or trust		certificate's certification path [RFC3280]; and for each CA or trust
	anchor the realms for which it is allowed to issue certificates.		anchor the realms for which it is allowed to issue certificates.
	In addition, if any CA is trusted to issue KDC certificates can also		In addition, if any CA is trusted to issue KDC certificates can also
	issue other kinds of certificates, then local policy must be able to		issue other kinds of certificates, then local policy must be able to
	distinguish between them: for example, it could require that KDC		distinguish between them: for example, it could require that KDC
	certificates contain the id-pkkdcekuoid EKU or that the realm be		certificates contain the id-pkinit-KPKdc EKU or that the realm be
	specified with the id-pksan SAN.		specified with the id-pkinit-san SAN.
	It is the responsibility of the PKI administrators for an		It is the responsibility of the PKI administrators for an
	organization to ensure that KDC certificates are only issued to KDCs,		organization to ensure that KDC certificates are only issued to KDCs,
	and that clients can ascertain this using their local policy.		and that clients can ascertain this using their local policy.
	Standard Kerberos allows the possibility of interactions between		Standard Kerberos allows the possibility of interactions between
	cryptosystems of varying strengths; this document adds interactions		cryptosystems of varying strengths; this document adds interactions
	with public-key cryptosystems to Kerberos. Some administrative		with public-key cryptosystems to Kerberos. Some administrative
	policies may allow the use of relatively weak public keys. Using		policies may allow the use of relatively weak public keys. Using
	such keys to wrap data encrypted under stronger conventional		such keys to wrap data encrypted under stronger conventional
	skipping to change at page 23, line 21 ¶		skipping to change at page 24, line 18 ¶
	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.
	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, Kristin Lauter, 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, Jonathan Trostle,
	Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik		Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik
	Jaganathan, Chaskiel M Grundman, Stefan Santesson, Andre Scedrov and		Jaganathan, and Chaskiel M Grundman.
	Aaron D. Jaggard.
			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, 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
	during the creation of this document.		during the creation of this document.
	Some of the ideas on which this document is based arose during		Some of the ideas on which this document is based arose during
	discussions over several years between members of the SAAG, the IETF		discussions over several years between members of the SAAG, the IETF
	skipping to change at page 25, line 20 ¶		skipping to change at page 26, line 20 ¶
	[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		[X.509-97] ITU-T Recommendation X.509: The Directory - Authentication
	Framework. 1997.		Framework, 1997.
	[X690] ASN.1 encoding rules: Specification of Basic Encoding		[X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
	Rules (BER), Canonical Encoding Rules (CER) and		Information technology - Abstract Syntax Notation One
	Distinguished Encoding Rules (DER), ITU-T Recommendation		(ASN.1): Specification of basic notation.
	X.690 (1997) | ISO/IEC International Standard
	8825-1:1998.		[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).
	7.2. Informative References		7.2. Informative References
	[CAPATH] RFC-Editor: To be replaced by RFC number for draft-ietf-		[CAPATH] RFC-Editor: To be replaced by RFC number for draft-ietf-
	pkix-certpathbuild. Work in Progress.		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
	skipping to change at page 26, line 20 ¶		skipping to change at page 27, line 20 ¶
	KerberosTime, PrincipalName, Realm, EncryptionKey		KerberosTime, PrincipalName, Realm, EncryptionKey
	FROM KerberosV5Spec2 { iso(1) identified-organization(3)		FROM KerberosV5Spec2 { iso(1) identified-organization(3)
	dod(6) internet(1) security(5) kerberosV5(2)		dod(6) internet(1) security(5) kerberosV5(2)
	modules(4) krb5spec2(2) } ;		modules(4) krb5spec2(2) } ;
	id-pkinit OBJECT IDENTIFIER ::=		id-pkinit OBJECT IDENTIFIER ::=
	{ iso (1) org (3) dod (6) internet (1) security (5)		{ iso (1) org (3) dod (6) internet (1) security (5)
	kerberosv5 (2) pkinit (3) }		kerberosv5 (2) pkinit (3) }
	id-pkauthdata OBJECT IDENTIFIER ::= { id-pkinit 1 }		id-pkinit-authData OBJECT IDENTIFIER ::= { id-pkinit 1 }
	id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 }		id-pkinit-DHKeyData OBJECT IDENTIFIER ::= { id-pkinit 2 }
	id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 }		id-pkinit-rkeyData OBJECT IDENTIFIER ::= { id-pkinit 3 }
	id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 }		id-pkinit-KPClientAuth OBJECT IDENTIFIER ::= { id-pkinit 4 }
	id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 }		id-pkinit-KPKdc OBJECT IDENTIFIER ::= { id-pkinit 5 }
	id-pksan OBJECT IDENTIFIER ::=		id-pkinit-san 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)
	x509-sanan (2) }		x509SanAN (2) }
	pa-pk-as-req INTEGER ::= 16		pa-pk-as-req INTEGER ::= 16
	pa-pk-as-rep INTEGER ::= 17		pa-pk-as-rep INTEGER ::= 17
	ad-initial-verified-cas INTEGER ::= 9		ad-initial-verified-cas INTEGER ::= 9
	td-trusted-certifiers INTEGER ::= 104		td-trusted-certifiers INTEGER ::= 104
	td-invalid-certificates INTEGER ::= 105		td-invalid-certificates INTEGER ::= 105
	td-dh-parameters INTEGER ::= 109		td-dh-parameters INTEGER ::= 109
	PA-PK-AS-REQ ::= SEQUENCE {		PA-PK-AS-REQ ::= SEQUENCE {
	signedAuthPack [0] IMPLICIT OCTET STRING,		signedAuthPack [0] IMPLICIT OCTET STRING,
	-- Contains a CMS type ContentInfo encoded		-- Contains a CMS type ContentInfo encoded
	-- according to [RFC3852].		-- according to [RFC3852].
	-- 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-pkauthdata (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		-- A list of CAs, trusted by the client, that can
	-- be used to certify the KDC.		-- 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
	skipping to change at page 29, line 32 ¶		skipping to change at page 30, line 32 ¶
	encKeyPack [1] IMPLICIT OCTET STRING,		encKeyPack [1] IMPLICIT OCTET STRING,
	-- Selected when public key encryption is used.		-- Selected when public key encryption is used.
	-- Contains a CMS type ContentInfo encoded		-- Contains a CMS type ContentInfo encoded
	-- according to [RFC3852].		-- according to [RFC3852].
	-- The contentType field of the type ContentInfo is		-- The contentType field of the type ContentInfo is
	-- id-envelopedData (1.2.840.113549.1.7.3).		-- id-envelopedData (1.2.840.113549.1.7.3).
	-- The content field is an EnvelopedData.		-- The content field is an EnvelopedData.
	-- The contentType field for the type EnvelopedData		-- The contentType field for the type EnvelopedData
	-- is id-signedData (1.2.840.113549.1.7.2).		-- is id-signedData (1.2.840.113549.1.7.2).
	-- The eContentType field for the inner type		-- The eContentType field for the inner type
	-- SignedData (when unencrypted) is id-pkrkeydata		-- SignedData (when unencrypted) is
	-- (1.2.840.113549.1.7.3) and the eContent field		-- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
	-- contains the DER encoding of the type		-- eContent field contains the DER encoding of the
	-- ReplyKeyPack.		-- type ReplyKeyPack.
	-- ReplyKeyPack is defined below.		-- ReplyKeyPack is defined below.
	...		...
	}		}
	DHRepInfo ::= SEQUENCE {		DHRepInfo ::= SEQUENCE {
	dhSignedData [0] IMPLICIT OCTET STRING,		dhSignedData [0] IMPLICIT OCTET STRING,
	-- 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-pkdhkeydata (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 {
	skipping to change at page 33, line 5 ¶		skipping to change at page 33, line 41 ¶
	10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e		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		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		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		0d 0e 0f 10 00 01 02 03 04 05 06 07 08
	Output of K-truncate() when the key size is 32 octets:		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		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		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 better interoperate 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 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 upper case. In addition, the
			UserPrincipalName attribute is globally unique in Windows 2000 and
			Windows 2003.
	Authors' Addresses		Authors' Addresses
	Brian Tung		Brian Tung
	USC Information Sciences Institute		USC Information Sciences Institute
	4676 Admiralty Way Suite 1001, Marina del Rey CA		4676 Admiralty Way Suite 1001
	Marina del Rey, CA 90292		Marina del Rey, CA 90292
	US		US
	Email: brian@isi.edu		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
End of changes. 53 change blocks.
	98 lines changed or deleted		176 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/