< draft-ietf-cat-kerberos-pk-init-23.txt		draft-ietf-cat-kerberos-pk-init-24.txt >
	NETWORK WORKING GROUP B. Tung		NETWORK WORKING GROUP B. Tung
	Internet-Draft USC Information Sciences Institute		Internet-Draft USC Information Sciences Institute
	Expires: August 4, 2005 L. Zhu		Expires: August 13, 2005 L. Zhu
	Microsoft Corporation		Microsoft Corporation
	January 31, 2005		February 9, 2005
	Public Key Cryptography for Initial Authentication in Kerberos		Public Key Cryptography for Initial Authentication in Kerberos
	draft-ietf-cat-kerberos-pk-init-23		draft-ietf-cat-kerberos-pk-init-24
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		This document is an Internet-Draft and is subject to all provisions
	of Section 3 of RFC 3667. By submitting this Internet-Draft, each		of Section 3 of RFC 3667. By submitting this Internet-Draft, each
	author represents that any applicable patent or other IPR claims of		author represents that any 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 is aware have been or will be disclosed, and any of
	which he or she become aware will be disclosed, in accordance with		which he or she become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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 August 4, 2005.		This Internet-Draft will expire on August 13, 2005.
	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 passing digital certificates and		authentication exchange, by using asymmetric-key signature and/or
	associated authenticators 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 . . . . . . . . . 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 . . . . . . . . . 6		3.2 PKINIT Pre-authentication Syntax and Use . . . . . . . . . 6
	3.2.1 Generation of Client Request . . . . . . . . . . . . . 7		3.2.1 Generation of Client Request . . . . . . . . . . . . . 6
	3.2.2 Receipt of Client Request . . . . . . . . . . . . . . 9		3.2.2 Receipt of Client Request . . . . . . . . . . . . . . 10
	3.2.3 Generation of KDC Reply . . . . . . . . . . . . . . . 12		3.2.3 Generation of KDC Reply . . . . . . . . . . . . . . . 13
	3.2.4 Receipt of KDC Reply . . . . . . . . . . . . . . . . . 17		3.2.4 Receipt of KDC Reply . . . . . . . . . . . . . . . . . 19
	3.3 KDC Indication of PKINIT Support . . . . . . . . . . . . . 18		3.3 Interoperability Requirements . . . . . . . . . . . . . . 20
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 18		3.4 KDC Indication of PKINIT Support . . . . . . . . . . . . . 20
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19		4. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	7.1 Normative References . . . . . . . . . . . . . . . . . . . 20		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
	7.2 Informative References . . . . . . . . . . . . . . . . . . 21		7.1 Normative References . . . . . . . . . . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21		7.2 Informative References . . . . . . . . . . . . . . . . . . 24
	A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
	Intellectual Property and Copyright Statements . . . . . . . . 27		A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 25
			Intellectual Property and Copyright Statements . . . . . . . . 30
	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. (In this document, we will		Kerberos Key Distribution Center, or KDC. (In this document, both
	refer to both the AS and the TGS as the KDC.) Finally, the client		the AS and the TGS are referred to as the KDC.) Finally, the client
	uses the service ticket to authenticate itself to the service.		uses the service ticket to authenticate itself to the service.
	The advantage afforded by the TGT is that the client exposes his		The advantage afforded by the TGT is that the client exposes his
	long-term secrets only once. The TGT and its associated session key		long-term secrets only once. The TGT and its associated session key
	can then be used for any subsequent service ticket requests. One		can then be used for any subsequent service ticket requests. One
	result of this is that all further authentication is independent of		result of this is that all further authentication is independent of
	the method by which the initial authentication was performed.		the method by which the initial authentication was performed.
	Consequently, initial authentication provides a convenient place to		Consequently, initial authentication provides a convenient place to
	integrate public-key cryptography into Kerberos authentication.		integrate public-key cryptography into Kerberos authentication.
	skipping to change at page 4, line 5 ¶		skipping to change at page 3, line 50 ¶
	authentication exchange. This document describes the methods and		authentication exchange. This document describes the methods and
	data formats for integrating public-key cryptography into Kerberos		data formats for integrating public-key cryptography into Kerberos
	initial authentication.		initial authentication.
	2. Conventions Used in This Document		2. Conventions Used in This Document
	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].
			In this document, the encryption key used to encrypt the enc-part
			field of the KDC-REP in the AS-REP [CLAR] is referred to as the KDC
			AS reply key.
	3. Extensions		3. Extensions
	This section describes extensions to [CLAR] for supporting the use of		This section describes extensions to [CLAR] for supporting the use of
	public-key cryptography in the initial request for a ticket.		public-key cryptography in the initial request for a ticket.
	Briefly, this document defines the following extensions to [CLAR]:		Briefly, this document defines the following extensions to [CLAR]:
	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
	signature.		signature.
	2. The KDC tests the client's request against its authentication		2. The KDC tests the client's request against its authentication
	policy and trusted Certification Authorities (CAs).		policy and trusted Certification Authorities (CAs).
	3. If the request passes the verification tests, the KDC replies as		3. If the request passes the verification tests, the KDC replies as
	usual, but the reply is encrypted using either:		usual, but the reply is encrypted using either:
	a. a key generated through a Diffie-Hellman (DH) key exchange		a. a key generated through a Diffie-Hellman (DH) key exchange
	[RFC2631] with the client, signed using the KDC's signature		[RFC2631][IEEE1363] with the client, signed using the KDC's
	key; or		signature key; or
	b. a symmetric encryption key, signed using the KDC's signature		b. a symmetric encryption key, signed using the KDC's signature
	key and encrypted using the client's public key.		key and encrypted using the client's public key.
	Any keying material required by the client to obtain the		Any keying material required by the client to obtain the
	encryption key for decrypting the KDC reply is returned in a		encryption key for decrypting the KDC reply is returned in a
	pre-authentication field accompanying the usual reply.		pre-authentication field accompanying the usual reply.
	4. The client obtains the encryption key, decrypts the reply, and		4. The client validates the KDC's signature, obtains the encryption
	then proceeds as usual.		key, decrypts the reply, and then proceeds as usual.
	Section 3.1 of this document enumerates the required algorithms and		Section 3.1 of this document enumerates the required algorithms and
	necessary extension message types. Section 3.2 describes the		necessary extension message types. Section 3.2 describes the
	extension messages in greater detail.		extension messages in greater detail.
	3.1 Definitions, Requirements, and Constants		3.1 Definitions, Requirements, and Constants
	3.1.1 Required Algorithms		3.1.1 Required Algorithms
	All PKINIT implementations MUST support the following algorithms:		All PKINIT implementations MUST support the following algorithms:
	o AS reply key: AES256-CTS-HMAC-SHA1-96 etype [KCRYPTO].		o KDC AS reply key enctype: AES256-CTS-HMAC-SHA1-96 etype [KCRYPTO].
	o Signature algorithm: sha-1WithRSAEncryption [RFC3279].		o Signature algorithm: sha-1WithRSAEncryption [RFC3279].
	o KDC AS reply key delivery method: ephemeral-ephemeral		o KDC AS reply key delivery method: Diffie-Hellman key exchange
	Diffie-Hellman exchange (Diffie-Hellman keys are not cached).		[RFC2631].
	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:
	AD-INITIAL-VERIFIED-CAS 9		AD_INITIAL_VERIFIED_CAS 9
	PKINIT introduces the following new error codes:		PKINIT introduces the following new error codes:
	KDC_ERR_CLIENT_NOT_TRUSTED 62		KDC_ERR_CLIENT_NOT_TRUSTED 62
	KDC_ERR_KDC_NOT_TRUSTED 63		KDC_ERR_INVALID_SIG 64
	KDC_ERR_INVALID_SIG 64		KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65
	KDC_ERR_KEY_SIZE 65		KDC_ERR_CANT_VERIFY_CERTIFICATE 70
	KDC_ERR_CERTIFICATE_MISMATCH 66		KDC_ERR_INVALID_CERTIFICATE 71
	KDC_ERR_CANT_VERIFY_CERTIFICATE 70		KDC_ERR_REVOKED_CERTIFICATE 72
	KDC_ERR_INVALID_CERTIFICATE 71		KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
	KDC_ERR_REVOKED_CERTIFICATE 72		KDC_ERR_CLIENT_NAME_MISMATCH 75
	KDC_ERR_REVOCATION_STATUS_UNKNOWN 73		KDC_ERR_INCONSISTENT_KEY_PURPOSE 76
	KDC_ERR_CLIENT_NAME_MISMATCH 75
	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-CERTIFICATE-INDEX 105		TD_INVLID_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 AS-REQ
	message (to indicate acceptance of the corresponding encryption		message to indicate acceptance of the corresponding algorithms that
	Object Identifiers (OIDs) in PKINIT):		can used by Cryptographic Message Syntax (CMS) [RFC3852] messages in
			the reply:
	dsaWithSHA1-CmsOID 9
	md5WithRSAEncryption-CmsOID 10
	sha1WithRSAEncryption-CmsOID 11
	rc2CBC-EnvOID 12
	rsaEncryption-EnvOID (PKCS1 v1.5) 13
	rsaES-OAEP-EnvOID (PKCS1 v2.0) 14
	des-ede3-cbc-EnvOID 15
	The above encryption types are used by the client only within the		dsaWithSHA1-CmsOID 9
	KDC-REQ-BODY to indicate which Cryptographic Message Syntax (CMS)		md5WithRSAEncryption-CmsOID 10
	[RFC3852] algorithms it supports. Their use within Kerberos		sha1WithRSAEncryption-CmsOID 11
	EncryptedData structures is not specified by this document.		rc2CBC-EnvOID 12
			rsaEncryption-EnvOID (PKCS1 v1.5) 13
			rsaES-OAEP-EnvOID (PKCS1 v2.0) 14
			des-ede3-cbc-EnvOID 15
	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) are 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]. All data		encoded using Distinguished Encoding Rules (DER) [X690] (unless
	structures wrapped in OCTET STRINGs must be encoded according to the		otherwise noted). All data structures carried in OCTET STRINGs must
	rules specified in corresponding specifications.		be encoded according to the rules specified in corresponding
			specifications.
	Interoperability note: Some implementations may not be able to decode		Interoperability note: Some implementations may not be able to decode
	CMS objects encoded with BER but not DER; specifically, they may not		wrapped CMS objects encoded with BER but not DER; specifically, they
	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
	identifiers.		identifiers.
	PKINIT uses the following algorithm identifier for Diffie-Hellman key		PKINIT uses the following algorithm identifiers for Diffie-Hellman
	agreement [RFC3279]:		key agreement [RFC3279]:
	dhpublicnumber		dhpublicnumber (Diffie-Hellman modulo a prime p [RFC2631])
			id-ecPublicKey (Elliptic Curve Diffie-Hellman [IEEE1363])
	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 v1.5)
	id-RSAES-OAEP (PKCS1 v2.0)		id-RSAES-OAEP (PKCS1 v2.0)
	PKINIT uses the following algorithm identifiers [RFC3370][RFC3565]		PKINIT uses the following algorithm identifiers [RFC3370][RFC3565]
	for encrypting the reply key with the temporary key:		for encrypting the KDC 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
	This section defines the syntax and use of the various		This section defines the syntax and use of the various
	pre-authentication fields employed by PKINIT.		pre-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 [CLAR]; in		The initial authentication request (AS-REQ) is sent as per [CLAR]; in
	addition, a pre-authentication field contains data signed by the		addition, a pre-authentication data element, whose padata-type is
	client's private signature key, as follows:		PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
			type PA-PK-AS-REQ, is included.
	PA-PK-AS-REQ ::= SEQUENCE {		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-pkauthdata (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 TrustedCA OPTIONAL,		trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,
	-- A list of CAs, trusted by the client, that can		-- A list of CAs, trusted by the client, that can
	-- be used to validate KDC certificates.		-- be used as the trust anchor to validate the KDC's
	kdcCert [2] IMPLICIT OCTET STRING		-- signature.
			-- Each TrustedCA identifies a CA or a CA
			-- certificate (thereby its public key).
			kdcPkId [2] IMPLICIT OCTET STRING
	OPTIONAL,		OPTIONAL,
	-- Contains a CMS type IssuerAndSerialNumber encoded		-- Contains a CMS type SignerIdentifier encoded
	-- according to [RFC3852].		-- according to [RFC3852].
	-- Identifies a particular KDC certificate, if the		-- Identifies, if present, a particular KDC
	-- client already has it.		-- public key that the client already has.
	...		...
	}		}
	DHNonce ::= OCTET STRING		DHNonce ::= OCTET STRING
	TrustedCA ::= CHOICE {		TrustedCA ::= SEQUENCE {
	caName [1] IMPLICIT OCTET STRING,		caName [0] IMPLICIT OCTET STRING,
	-- Contains a PKIX type Name encoded according to		-- Contains a PKIX type Name encoded according to
	-- [RFC3280].		-- [RFC3280].
	issuerAndSerial [2] IMPLICIT OCTET STRING,		-- Specifies the CA distinguished subject name.
	-- Contains a CMS type IssuerAndSerialNumber encoded		certificateSerialNumber [1] INTEGER OPTIONAL,
	-- according to [RFC3852].		-- Specifies the certificate serial number.
	-- Identifies a specific CA certificate.		-- The defintion of the certificate serial number
			-- is taken from X.509 [X.509-97].
			subjectKeyIdentifier [2] OCTET STRING OPTIONAL,
			-- Identifies the CA'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.
	...		...
	}		}
	AuthPack ::= SEQUENCE {		AuthPack ::= SEQUENCE {
	pkAuthenticator [0] PKAuthenticator,		pkAuthenticator [0] PKAuthenticator,
	clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,		clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
	-- Defined in [RFC3280].		-- Defined in [RFC3280].
			-- The pubic key value (the subjectPublicKey field
			-- of the type SubjectPublicKeyInfo) MUST be encoded
			-- according to [RFC3279].
	-- Present only if the client wishes to use the		-- Present only if the client wishes to use the
	-- Diffie-Hellman key agreement method.		-- Diffie-Hellman key agreement method.
	supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier		supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
	OPTIONAL,		OPTIONAL,
	-- List of CMS encryption types supported by		-- List of CMS encryption types supported by
	-- client in order of (decreasing) preference.		-- client in order of (decreasing) preference.
	clientDHNonce [3] DHNonce OPTIONAL,		clientDHNonce [3] DHNonce OPTIONAL,
	-- Present only if the client indicates that it		-- Present only if the client indicates that it
	-- wishes to cache DH keys or to allow the KDC to		-- wishes to reuse DH keys or to allow the KDC to
	-- do so.		-- do so (see Section 3.2.3.1).
	...		...
	}		}
	PKAuthenticator ::= SEQUENCE {		PKAuthenticator ::= SEQUENCE {
	cusec [0] INTEGER (0..999999),		cusec [0] INTEGER (0..999999),
	ctime [1] KerberosTime,		ctime [1] KerberosTime,
	-- cusec and ctime are used as in [CLAR], for replay		-- cusec and ctime are used as in [CLAR], for replay
	-- prevention.		-- 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
	skipping to change at page 8, line 47 ¶		skipping to change at page 9, line 15 ¶
	2. The eContentType field for the type SignedData is id-pkauthdata:		2. The eContentType field for the type SignedData is id-pkauthdata:
	{ 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) pkauthdata(1) }.		pkinit(3) pkauthdata(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 the		5. The certificates field of the type SignedData contains
	client's certificate and additional certificates intended to		certificates intended to facilitate certification path
	facilitate certification path construction, so that the KDC can		construction, so that the KDC can verify the signature over the
	validate the client's certificate and verify the signature over		type AuthPack. For path validation, these certificates SHOULD be
	the type AuthPack. The certificates field MUST NOT contain		sufficient to construct at least one certification path from the
	"root" CA certificates.		client certificate to one trust anchor acceptable by the KDC
			[CAPATH]. The certificates field MUST NOT contain "root" CA
			certificates.
	6. The client's Diffie-Hellman public value (clientPublicValue) is		6. The client's Diffie-Hellman public value (clientPublicValue) is
	included if and only if the client wishes to use the		included if and only if the client wishes to use the
	Diffie-Hellman key agreement method. For the Diffie-Hellman key		Diffie-Hellman key agreement method. For the Diffie-Hellman key
	agreement method, implementations MUST support Oakley 1024-bit		agreement method, implementations MUST support Oakley 1024-bit
	MODP well-known group 2 [RFC2412] and SHOULD support Oakley		MODP well-known group 2 [RFC2412] and SHOULD support Oakley
	2048-bit MODP well-known group 14 and Oakley 4096-bit MODP		2048-bit MODP well-known group 14 and Oakley 4096-bit MODP
	well-known group 16 [RFC3526]. They MAY support Oakley 185-bit		well-known group 16 [RFC3526].
	EC2N group 4 [RFC2412]. The Diffie-Hellman group size should be
	chosen so as to provide sufficient cryptographic security. The
	exponents should have at least twice as many bits as the
	symmetric keys that will be derived from them [ODL99].
	7. The client may wish to cache DH keys or to allow the KDC to do		The Diffie-Hellman field size should be chosen so as to provide
	so. If so, then the client includes the clientDHNonce field.		sufficient cryptographic security. The following table, based on
	This nonce string needs to be as long as the longest key length		[LENSTRA], gives approximate comparable key sizes for symmetric-
	of the symmetric key types that the client supports. This nonce		and asymmetric-key cryptosystems based on the best-known
	MUST be chosen randomly.		algorithms for attacking them.
			Symmetric | ECC | DH/DSA/RSA
			-------------+---------+------------
			80 | 163 | 1024
			112 | 233 | 2048
			128 | 283 | 3072
			192 | 409 | 7680
			256 | 571 | 15360
			Table 1: Comparable key sizes (in bits)
			When Diffie-Hellma modulo a prime p is used, the exponents should
			have at least twice as many bits as the symmetric keys that will
			be derived from them [ODL99].
			7. The client may wish to reuse DH keys or to allow the KDC to do so
			(see Section 3.2.3.1). If so, then the client includes the
			clientDHNonce field. This nonce string needs to be as long as
			the longest key length of the symmetric key types that the client
			supports. This nonce MUST be chosen randomly.
	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 looks for the client's certificate in the signedAuthPack		The KDC verifies the client's signature in the signedAuthPack field
	(based on the signerInfo) and validate this certificate.		according to [RFC3852].
	If the KDC cannot find a certification path to validate the client's		If, while validating the client's X.509 certificate [RFC3280], the
	certificate, it sends back an error of type		KDC cannot build a certification path to validate the client's
			certificate, it sends back a KRB-ERROR [CLAR] message with the code
	KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for this		KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for this
	error is a TYPED-DATA (as defined in [CLAR]). For this error, the		error message is a TYPED-DATA (as defined in [CLAR]) that contains an
	data-type is TD-TRUSTED-CERTIFIERS, and the data-value is the DER		element whose data-type is TD_TRUSTED_CERTIFIERS, and whose
	encoding of		data-value contains the DER encoding of the type
			TD-TRUSTED-CERTIFIERS:
	TrustedCertifiers ::= SEQUENCE OF OCTET STRING		TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA
	-- The OCTET STRING contains a PKIX type Name encoded		-- Identifies a list of CAs trusted by the KDC.
	-- according to [RFC3280].		-- Each TrustedCA identifies a CA or a CA
			-- certificate (thereby its public key).
			Upon receiving this error message, the client SHOULD retry only if it
			has a different set of certificates (from those of the previous
			requests) that form a certification path (or a partial path) from one
			of the trust anchors selected 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 is		the signature on one of the certificates in the signedAuthPack field
	invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE.		is invalid, it returns a KRB-ERROR [CLAR] message with the code
	The accompanying e-data for this error is a TYPED-DATA, whose		KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data for this error
	data-type is TD-CERTIFICATE-INDEX, and whose data-value is the DER		message is a TYPED-DATA that contains an element whose data-type is
	encoding of the index into the CertificateSet field, ordered as sent		TD_INVALID_CERTIFICATES, and whose data-value contains the DER
	by the client:		encoding of the type TD-INVALID-CERTIFICATES:
	CertificateIndex ::= OCTET STRING		TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING
	-- Contains a CMS type IssuerAndSerialNumber encoded		-- Each OCTET STRING contains a CMS type
	-- according to [RFC3852].		-- IssuerAndSerialNumber encoded according to
	-- IssuerAndSerialNumber of certificate with an		-- [RFC3852].
	-- invalid signature.		-- Each IssuerAndSerialNumber indentifies a
			-- certificate (sent by the client) with an invalid
			-- signature.
	If more than one certificate signature is invalid, the KDC MAY send		If more than one X.509 certificate signature is invalid, the KDC MAY
	one TYPED-DATA per invalid signature.		send one TYPED-DATA element per invalid signature.
	The KDC SHOULD also check whether any certificates in the client's		Based on local policy, the KDC may also check whether any X.509
	certification path have been revoked. If any of them have been		certificates in the certification path validating the client's
	revoked, the KDC MUST return an error of type		certificate have been revoked. If any of them have been revoked, the
			KDC MUST return an error message with the code
	KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the		KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
	revocation status but is unable to do so, it SHOULD return an error		revocation status but is unable to do so, it SHOULD return an error
	of type KDC_ERR_REVOCATION_STATUS_UNKNOWN. The certificate or		message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN. The
	certificates affected are identified exactly as for an error of type		certificate or certificates affected are identified exactly as for
	KDC_ERR_INVALID_CERTIFICATE (see above).		the error code KDC_ERR_INVALID_CERTIFICATE (see above).
	In addition to validating the client's certificate, the KDC MUST also		The client's public key is then used to verify the signature. If the
	check that this certificate properly maps to the client's principal		signature fails to verify, the KDC MUST return an error message with
	name as specified in the AS-REQ as follows:		the code KDC_ERR_INVALID_SIG. There is no accompanying e-data for
			this error message.
	1. If the KDC has its own mapping from the name in the client's		In addition to validating the client's signature, the KDC MUST also
	certificate to a Kerberos name, it uses that Kerberos name.		check that the client's public key used to verify the client's
			signature is bound to the client's principal name as specified in the
			AS-REQ as follows:
	2. Otherwise, if the client's certificate contains a SubjectAltName		1. If the KDC has its own binding between either the client's
	extension with a Kerberos name in the otherName field, it uses		signature-verification public key or the client's certificate and
			the client's Kerberos principal name, it uses that binding.
			2. Otherwise, if the client's X.509 certificate contains a
			SubjectAltName extension with a KRB5PrincipalName (defined below)
			in the otherName field, it binds the client's X.509 certificate to
	that name.		that name.
	The otherName field (of type AnotherName) in the SubjectAltName		The otherName field (of type AnotherName) in the SubjectAltName
	extension MUST contain KRB5PrincipalName as defined below.		extension MUST contain KRB5PrincipalName as defined below.
	The type-id field of the type AnotherName is id-pksan:		The type-id field of the type AnotherName is id-pksan:
	id-pksan OBJECT IDENTIFIER ::=		id-pksan 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) }		x509-sanan (2) }
	The value field of the type AnotherName is the DER encoding of the		The value field of the type AnotherName is the DER encoding of the
	following ASN.1 type:		following ASN.1 type:
	KRB5PrincipalName ::= SEQUENCE {		KRB5PrincipalName ::= SEQUENCE {
	realm [0] Realm,		realm [0] Realm,
	principalName [1] PrincipalName		principalName [1] PrincipalName
	}		}
	If the KDC does not have its own mapping and there is no Kerberos		If the KDC does not have its own binding and there is no
	name present in the client's certificate, or if the name in the		KRB5PrincipalName name present in the client's X.509 certificate, and
	request does not match the name in the certificate (including the		if the Kerberos name in the request does not match the
	realm name), the KDC MUST return error code		KRB5PrincipalName in the client's X.509 certificate (including the
			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.		this error message.
	Even if the client's certificate is validated and it is mapped to the
	client's principal name, the KDC may decide not to 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-pkekuoid in the extensions field of the
	client's certificate:		client's X.509 certificate:
	id-pkekuoid OBJECT IDENTIFIER ::=		id-pkekuoid 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) pkekuoid(4) }
	-- PKINIT client authentication.		-- PKINIT client authentication.
	-- Key usage bits that may be consistent: digitalSignature		-- Key usage bits that MUST be consistent:
			-- digitalSignature;
			-- Key usage bits that MAY be consistent:
	-- nonRepudiation, and (keyEncipherment or keyAgreement).		-- nonRepudiation, and (keyEncipherment or keyAgreement).
	As a matter of local policy, the KDC may decide to reject requests on		If this EKU is required but is missing, the KDC MUST return an error
	the basis of the absence or presence of specific EKU OIDs. KDCs		message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE. There is no
	implementing this requirement SHOULD also accept the EKU KeyPurposeId		accompanying e-data for this error message. KDCs implementing this
	id-ms-sc-logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement,		requirement SHOULD also accept the EKU KeyPurposeId id-ms-sc-logon
	as there are a large number of client certificates deployed for use		(1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there are a
	with PKINIT which have this EKU.		large number of X.509 client certificates deployed for use with
			PKINIT which have this EKU.
	The KDC MUST return the error code KDC_ERR_CLIENT_NOT_TRUSTED if the
	client's certificate is not accepted.
	Once the client's certificate is accepted, the KDC can then verify		If for any other reasons, the client's public key is not accepted,
	the client's signature over the type AuthPack according to [RFC3852].		the KDC MUST return an error message with the code
	If the signature fails to verify, the KDC MUST return error		KDC_ERR_CLIENT_NOT_TRUSTED.
	KDC_ERR_INVALID_SIG. There is no accompanying e-data for this error.
	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 clock skew times in [CLAR] apply here. If the check		recommendations for clock skew times in [CLAR] apply here. If the
	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
	not, it MUST return error code KDC_ERR_KEY_SIZE. The accompanying		not, it MUST return an error message with the code
	e-data is a TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and		KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a
	whose data-value is the DER encoding of the following:		TYPED-DATA that contains an element whose data-type is
			TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
			the type TD-DH-PARAMETERS:
	TD-DH-PARAMETERS ::= SEQUENCE OF DomainParameters		TD-DH-PARAMETERS ::= SEQUENCE OF DHDomainParameters
	-- Type DomainParameters is defined in [RFC3279].		-- Contains a list of Diffie-Hellman domain
	-- Contains a list of Diffie-Hellman group
	-- parameters in decreasing preference order.		-- parameters in decreasing preference order.
	TD-DH-PARAMETERS contains a list of Diffie-Hellman group parameters		DHDomainParameters ::= CHOICE {
			modp [0] DomainParameters,
			-- Type DomainParameters is defined in [RFC3279].
			ec [1] EcpkParameters,
			-- Type EcpkParameters is defined in [RFC3279].
			...
			}
			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 KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the		If the client included a kdcPkId field in the PA-PK-AS-REQ and the
	client included a kdcCert field in the PA-PK-AS-REQ and the KDC does		KDC does not possess the corresponding key, the KDC MUST ignore the
	not have the corresponding certificate.		kdcPkId field as if the client did not include one.
	The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client		If the client included a trustedCertifiers field, and the KDC does
	did not include a kdcCert field, but did include a trustedCertifiers		not possesses the private key for any one of the listed certifiers,
	field, and the KDC does not possesses a certificate issued by one of		the KDC MUST ignore the trustedCertifiers field as if the client did
	the listed certifiers.		not include any.
	If there is a supportedCMSTypes field in the AuthPack, the KDC must		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		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.		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 of type		If it does not support any of them, it MUST return an error message
	KRB5KDC_ERR_ETYPE_NOSUPP.		with the code KDC_ERR_ETYPE_NOSUPP [CLAR].
	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 [CLAR], except as follows.		KDC proceeds as per [CLAR], 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
	of type AD-INITIAL-VERIFIED-CAS in the issued ticket. The value is		element of ad-type [CLAR] AD_INITIAL_VERIFIED_CAS in the issued
	an OCTET STRING containing the DER encoding of InitialVerifiedCAs:		ticket. The ad-data [CLAR] field contains the DER encoding of the
			type AD-INITIAL-VERIFIED-CAS:
	InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {		AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA
	ca [0] IMPLICIT OCTET STRING,		-- Identifies the certification path based on which
	-- Contains a PKIX type Name encoded according to		-- the client certificate was validated.
	-- [RFC3280].		-- Each TrustedCA identifies a CA or a CA
	validated [1] BOOLEAN,		-- certificate (thereby its public key).
	...
	}
	The KDC MAY wrap 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 KDC's realm's 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
	[CLAR]). Furthermore, any TGS must copy such authorization data from		[CLAR]). Furthermore, any TGS MUST copy such authorization data from
	tickets used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket,		tickets used in a PA-TGS-REQ [CLAR] of the TGS-REQ to the resulting
	including the AD-IF-RELEVANT container, if present.		ticket, and it can wrap or unwrap the data into or out-of the
			AD-IF-RELEVANT container, depends on if the list of CAs satisfies the
			TGS' realm's local policy.
	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 [CLAR].) If such a data type is contained within an		set [CLAR].) If such a data type is contained within an
	AD-IF-RELEVANT container, AP servers MAY apply local policy to		AD-IF-RELEVANT container, AP servers MAY apply local policy to
	determine whether the authorization data is acceptable.		determine whether the authorization data is acceptable.
	The AS-REP is otherwise unchanged from [CLAR]. The KDC encrypts the		The content of the AS-REP is otherwise unchanged from [CLAR]. The
	reply as usual, but not with the client's long-term key. Instead, it		KDC encrypts the reply as usual, but not with the client's long-term
	encrypts it with either a shared key derived from a Diffie-Hellman		key. Instead, it encrypts it with either a shared key derived from a
	exchange, or a generated encryption key. The contents of the		Diffie-Hellman exchange, or a generated encryption key. The contents
	PA-PK-AS-REP indicate which key delivery method is used:		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
			-- used.
	encKeyPack [1] IMPLICIT OCTET STRING,		encKeyPack [1] IMPLICIT OCTET STRING,
			-- 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 id-pkrkeydata
	-- (1.2.840.113549.1.7.3) and the eContent field		-- (1.2.840.113549.1.7.3) and the eContent field
	-- contains the DER encoding of the type		-- contains the DER encoding of the type
	-- ReplyKeyPack.		-- ReplyKeyPack.
	-- ReplyKeyPack is defined below.
			-- 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-pkdhkeydata (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 in the KDCDHKeyInfo.
	}		}
	KDCDHKeyInfo ::= SEQUENCE {		KDCDHKeyInfo ::= SEQUENCE {
	subjectPublicKey [0] BIT STRING,		subjectPublicKey [0] BIT STRING,
	-- KDC's public key, y = g^x mod p.		-- KDC's DH public key.
	-- MUST be ASN.1 encoded as an INTEGER;		-- The DH pubic key value is mapped to a BIT STRING
	-- This encoding is then used as the contents		-- according to [RFC3279].
	-- (i.e., the value) of this BIT STRING field.
	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 cached DH keys are NOT used,		-- request if DH keys are NOT reused,
	-- 0 otherwise.		-- 0 otherwise.
	dhKeyExpiration [2] KerberosTime OPTIONAL,		dhKeyExpiration [2] KerberosTime OPTIONAL,
	-- Expiration time for KDC's cached values, present		-- Expiration time for KDC's key pair,
	-- if and only if cached DH keys are used. If this		-- present if and only if DH keys are reused. If
	-- field is omitted then the serverDHNonce field		-- this field is omitted then the serverDHNonce
	-- MUST also be omitted.		-- field MUST also be omitted. See Section 3.2.3.1.
	...		...
	}		}
	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:
	skipping to change at page 14, line 47 ¶		skipping to change at page 16, line 17 ¶
	for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)		for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
	security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }.		security(5) kerberosv5(2) pkinit(3) pkdhkeydata(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 the KDC's		5. The certificates field of the type SignedData contains
	certificate and additional certificates intended to facilitate		certificates intended to facilitate certification path
	certification path construction, so that the client can validate		construction, so that the client can verify the KDC's signature
	the KDC's certificate and verify the KDC's signature over the		over the type KDCDHKeyInfo. This field may only be left empty if
	type KDCDHKeyInfo. This field may only be left empty if the		the KDC public key specified by the kdcPkId field in the
	client did include a kdcCert field in the PA-PK-AS-REQ,		PA-PK-AS-REQ was used for signing. Otherwise, for path
	indicating that the client already has the KDC's certificate.		validation, these certificates SHOULD be sufficient to construct
	The certificates field MUST NOT contain "root" CA certificates.		at least one certification path from the KDC certificate to one
			trust anchor acceptable by the client [CAPATH]. The certificates
			field MUST NOT contain "root" CA certificates.
	6. If the client included the clientDHNonce field, then the KDC may		6. If the client included the clientDHNonce field, then the KDC may
	choose to reuse its DH keys. If the server reuses DH keys then		choose to reuse its DH keys (see Section 3.2.3.1). If the server
	it MUST include an expiration time in the dhKeyExperiation field.		reuses DH keys then it MUST include an expiration time in the
	Past the point of the expiration time, the signature over the		dhKeyExperiation field. Past the point of the expiration time,
	type DHRepInfo is considered expired/invalid. When the server		the signature over the type DHRepInfo is considered
	reuses DH keys then it MUST include a serverDHNonce at least as		expired/invalid. When the server reuses DH keys then it MUST
	long as the length of keys for the symmetric encryption system		include a serverDHNonce at least as long as the length of keys
	used to encrypt the AS reply. Note that including the		for the symmetric encryption system used to encrypt the AS reply.
	serverDHNonce changes how the client and server calculate the key		Note that including the serverDHNonce changes how the client and
	to use to encrypt the reply; see below for details. The KDC		server calculate the key to use to encrypt the reply; see below
	SHOULD NOT reuse DH keys unless the clientDHNonce field is		for details. The KDC SHOULD NOT reuse DH keys unless the
	present in the request.		clientDHNonce field is present in the request.
	The reply key for use to decrypt the KDC reply [CLAR] is derived as		The KDC AS reply key is derived as follows:
	follows:
	1. Both the KDC and the client calculate the shared secret value		1. Both the KDC and the client calculate the shared secret value as
	DHKey:		follows:
	DHKey = g^(xb * xa) mod p		a) When Diffie-Hellman modulo a prime p ([RFC2631]) is used, let
			DHSharedSecret be the shared secret value.
	where xb and xa are the KDC's and client's private exponents,		b) When Elliptic Curve Diffie-Hellman (ECDH) (with each party
	respectively. DHKey, padded first with leading zeros as needed to		contributing one key pair) [IEEE1363] is used, let
	make it as long as the modulus p, is represented as a string of		DHSharedSecret be the x-coordinate of the shared secret value
	octets in big-endian order (such that the size of DHKey in octets		(an elliptic curve point).
	is the size of the modulus p).
	2. Let K be the key-generation seed length [KCRYPTO] of the reply		DHSharedSecret is first padded with leading zeros such that the
	key whose enctype is selected according to [CLAR].		size of DHSharedSecret in octets is the same as that of the
			modulus, then represented as a string of octets in big-endian
			order.
			Implementation note: Both the client and the KDC can cache the
			triple (ya, yb, DHSharedSecret), where ya is the client's public
			key and yb is the KDC's public key. If both ya and yb are the
			same in a later exchange, the cached DHSharedSecret can be used.
			2. Let K be the key-generation seed length [KCRYPTO] of the KDC AS
			reply key whose enctype is selected according to [CLAR].
	3. Define the function octetstring2key() as follows:		3. Define the function octetstring2key() as follows:
	octetstring2key(x) == random-to-key(K-truncate(		octetstring2key(x) == random-to-key(K-truncate(
	SHA1(0x00 | x) |		SHA1(0x00 | x) |
	SHA1(0x01 | x) |		SHA1(0x01 | x) |
	SHA1(0x02 | x) |		SHA1(0x02 | x) |
	...		...
	))		))
	where x is an octet string; | is the concatenation operator; 0x00,		where x is an octet string; | is the concatenation operator; 0x00,
	0x01, 0x02, etc., are each represented as a single octet;		0x01, 0x02, etc., are each represented as a single octet;
	random-to-key() is an operation that generates a protocol key from		random-to-key() is an operation that generates a protocol key from
	a bitstring of length K; and K-truncate truncates its input to the		a bitstring of length K; and K-truncate truncates its input to the
	first K bits. Both K and random-to-key() are defined in the		first K bits. Both K and random-to-key() are as defined in the
	kcrypto profile [KCRYPTO] for the enctype of the reply key.		kcrypto profile [KCRYPTO] for the enctype of the KDC AS reply key.
	4. When cached DH keys are used, let n_c be the clientDHNonce, and		4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
	n_k be the serverDHNonce; otherwise, let both n_c and n_k be empty		the serverDHNonce; otherwise, let both n_c and n_k be empty octet
	octet strings.		strings.
	5. The reply key k is:		5. The KDC AS reply key k is:
	k = octetstring2key(DHKey | n_c | n_k)		k = octetstring2key(DHSharedSecret | n_c | n_k)
	3.2.3.2 Using Public Key Encryption		3.2.3.2 Using Public Key Encryption
	In this case, the PA-PK-AS-REP contains a ContentInfo structure		In this case, the PA-PK-AS-REP contains a ContentInfo structure
	wrapped in an OCTET STRING. The reply key for use to decrypt the KDC		wrapped in an OCTET STRING. The KDC AS reply key is encrypted in the
	reply [CLAR] is encrypted in the encKeyPack field, which contains		encKeyPack field, which contains data of type ReplyKeyPack:
	data of type ReplyKeyPack:
	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.
	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.		-- request.
	...		...
	}		}
	skipping to change at page 17, line 9 ¶		skipping to change at page 18, line 38 ¶
	EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6)		EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6)
	internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }.		internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(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 the		6. The certificates field of the inner type SignedData contains
	KDC's certificate and additional certificates intended to		certificates intended to facilitate certification path
	facilitate certification path construction, so that the client		construction, so that the client can verify the KDC's signature
	can validate the KDC's certificate and verify the KDC's signature
	over the type ReplyKeyPack. This field may only be left empty if		over the type ReplyKeyPack. This field may only be left empty if
	the client included a kdcCert field in the PA-PK-AS-REQ,		the KDC public key specified by the kdcPkId field in the
	indicating that the client already has the KDC's certificate.		PA-PK-AS-REQ was used for signing. Otherwise, for path
	The certificates field MUST NOT contain "root" CA certificates.		validation, these certificates SHOULD be sufficient to construct
			at least one certification path from the KDC certificate to one
			trust anchor acceptable by the client [CAPATH]. The 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.
	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 shared key using the same procedure used by the KDC as defined in		the KDC AS reply key using the same procedure used by the KDC as
	Section 3.2.3.1. Otherwise, the message contains an encKeyPack, and		defined in Section 3.2.3.1. Otherwise, the message contains the
	the client decrypts and verifies the temporary encryption key.		encKeyPack field, and the client decrypts and extracts the temporary
			key in the encryptedKey field of the member KeyTransRecipientInfo,
			and then uses that as the KDC AS reply key.
	In either case, the client MUST validate the KDC's certificate and		In either case, the client MUST verify the signature in the
	verify the signature in the SignedData according to [RFC3852].		SignedData according to [RFC3852]. Unless the client can otherwise
	Unless the client can otherwise prove that the KDC's certificate is		prove that the public key used to verify the KDC's signature is bound
	for the target KDC (i.e., the subject distinguished name in the KDC		to the target KDC, the KDC's X.509 certificate MUST satisfy at least
	certificate is bound to the hostname or IP address of the KDC		one of the follow two requirements:
	authenticating the client), it MUST do the following to verify the
	responder's identity:
	1. The client checks to see if the included certificate contains a		1. The certificate contains a Subject Alternative Name (SAN)
	Subject Alternative Name extension [RFC3280] carrying a dNSName or		extension carrying a dNSName and that name value matches the
	an iPAddress (if the KDC is specified by an IP address instead of		following name format:
	a name). If it does, it MUST check to see if that name value
	matches that of the KDC it believes it is communicating with, with
	matching rules specified in [RFC3280].
	2. The client verifies that the KDC's certificate MUST contain the		_Service._Proto.Realm
	EKU KeyPurposeId [RFC3280] id-pkkdcekuoid:
			Where the Service name is the string literal "kerberos", the
			Proto can be "udp" or "tcp", and the Realm is the domain style
			Kerberos realm name [CLAR] of the target KDC. This name format
			is identical to the owner label format used in the DNS SRV
			records for specifying the KDC location as described in [CLAR].
			For example, the X.509 certificate for the KDC of the Kerberos
			realm "EXAMPLE.COM" would contain a dNSName value of
			"_kerberos._tcp.EXAMPLE.COM" or "_kerberos._udp.EXAMPLE.COM".
			2. The certificate contains the EKU KeyPurposeId [RFC3280]
			id-pkkdcekuoid (defined below) and an SAN extension [RFC3280]
			carrying an AnotherName whose type-id is id-pksan (as defined in
			Section 3.2.2) and whose value contains a KRB5PrincipalName name,
			and the realm name of that KRB5PrincipalName matches the realm
			name of the target KDC.
	id-pkkdcekuoid OBJECT IDENTIFIER ::=		id-pkkdcekuoid 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) pkkdcekuoid(5) }
	-- Signing KDC responses.		-- Signing KDC responses.
	-- Key usage bits that may be consistent:		-- Key usage bits that MUST be consistent:
	-- digitalSignature.		-- digitalSignature.
			If no SAN id-pksan extension is present (but the id-pkkdcekuoid
			EKU is) in the KDC's X.509 certificate, and the client has a
			priori knowledge of the KDC's hostname (or IP address), the
			client SHOULD accept the KDC's X.509 certificate if that
			certificate contains an SAN extension carrying a dNSName and the
			dNSName value matches the hostname (or the IP address) of the KDC
			with which the client believes it is communicating.
			Matching rules used for the dNSName value are specified in [RFC3280].
	If all applicable checks are satisfied, the client then decrypts the		If all applicable checks are satisfied, the client then decrypts the
	enc-part of the KDC-REP in the AS_REP with the resulting key, and		enc-part field of the KDC-REP in the AS-REP using the KDC AS reply
	then proceeds as described in [CLAR].		key, and then proceeds as described in [CLAR].
	3.3 KDC Indication of PKINIT Support		Implementation note: CAs issuing KDC certificates SHOULD place all
			"short" and "fully-qualified" Kerberos realm names of the KDC (one
			per SAN extension) into the KDC certificate to allow maximum
			flexibility.
			3.3 Interoperability Requirements
			The client MUST be capable of sending a set of certificates
			sufficient to allow the KDC to construct a certification path for the
			client's certificate, if the correct set of certificates is provided
			through configuration or policy.
			If the client sends all the X.509 certificates on a certification
			path to a trust anchor acceptable by the KDC, and the KDC can not
			verify the client's public key otherwise, the KDC MUST be able to
			process path validation for the client's certificate based on the
			certificates in the request.
			The KDC MUST be capable of sending a set of certificates sufficient
			to allow the client to construct a certification path for the KDC's
			certificate, if the correct set of certificates is provided through
			configuration or policy.
			If the KDC sends all the X.509 certificates on a certification path
			to a trust anchor acceptable by the client, and the client can not
			verify the KDC's public key otherwise, the client MUST be able to
			process path validation for the KDC's certificate based on the
			certificates in the reply.
			3.4 KDC Indication of PKINIT Support
	If pre-authentication is required, but was not present in the		If pre-authentication is required, but was not present in the
	request, per [CLAR] an error message with the code		request, per [CLAR] an error message with the code
	KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be		KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
	stored in the e-data field of the KRB-ERROR message to specify which		stored in the e-data field of the KRB-ERROR message to specify which
	pre-authentication mechanisms are acceptable. The KDC can then		pre-authentication mechanisms are acceptable. The KDC can then
	indicate the support of PKINIT by including a PA-PK-AS-REQ element in		indicate the support of PKINIT by including an empty element whose
	that METHOD-DATA object.		padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
	Otherwise if it is required by the KDC's local policy that the client		Otherwise if it is required by the KDC's local policy that the client
	must be pre-authenticated using the pre-authentication mechanism		must be pre-authenticated using the pre-authentication mechanism
	specified in this document, but no PKINIT pre-authentication was		specified in this document, but no PKINIT pre-authentication was
	present in the request, an error message with the code		present in the request, an error message with the code
	KDC_ERR_PREAUTH_FAILED SHOULD be returned.		KDC_ERR_PREAUTH_FAILED SHOULD be returned.
	KDCs MUST leave the padata-value of PA-PK-AS-REQ entry in the		KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
	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
	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].
	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
	cryptosystems may be inappropriate.		cryptosystems may be inappropriate.
	PKINIT requires keys for symmetric cryptosystems to be generated.		PKINIT requires keys for symmetric cryptosystems to be generated.
	Some such systems contain "weak" keys. For recommendations regarding		Some such systems contain "weak" keys. For recommendations regarding
	these weak keys, see [CLAR].		these weak keys, see [CLAR].
	PKINIT uses the same RSA key pair for encryption and signing when		PKINIT allows the use of the same RSA key pair for encryption and
	doing RSA encryption based key delivery. This is not recommended		signing when doing RSA encryption based key delivery. This is not
	usage of RSA keys [RFC3447], by using DH based key delivery this is		recommended usage of RSA keys [RFC3447], by using DH based key
	avoided.		delivery this is avoided.
	Care should be taken in how certificates are chosen for the purposes		Care should be taken in how certificates are chosen for the purposes
	of authentication using PKINIT. Some local policies may require that		of authentication using PKINIT. Some local policies may require that
	key escrow be used for certain certificate types. Deployers of		key escrow be used for certain certificate types. Deployers of
	PKINIT should be aware of the implications of using certificates that		PKINIT should be aware of the implications of using certificates that
	have escrowed keys for the purposes of authentication.		have escrowed keys for the purposes of authentication. Because
			signing only certificates are normally not escrowed, by using DH
			based key delivery this is avoided.
	PKINIT does not provide for a "return routability" test to prevent		PKINIT does not provide for a "return routability" test to prevent
	attackers from mounting a denial-of-service attack on the KDC by		attackers from mounting a denial-of-service attack on the KDC by
	causing it to perform unnecessary and expensive public-key		causing it to perform unnecessary and expensive public-key
	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.		standard Kerberos does not make use of public-key cryptography. By
			using DH based key delivery and reusing DH keys, the necessary crypto
			processing cost per request can be minimized.
	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, Phil Hallin, Kelvin Yiu, Sam Hartman, Love		draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist
	Hornquist Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan		Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle,
	Trostle, Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon and		Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon and Karthik
	Karthik Jaganathan.		Jaganathan.
	Special thanks to Clifford Neuman, Mat Hur and Sasha Medvinsky who		Special thanks to Clifford Neuman, Matthew Hur and Sasha Medvinsky
	wrote earlier versions of this document.		who wrote earlier versions of this document.
	The authors are indebt to the Kerberos working group chair Jeffrey		The authors are indebt 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
	CAT working group, and the PSRG, regarding integration of Kerberos		CAT working group, and the PSRG, regarding integration of Kerberos
	and SPX. Some ideas have also been drawn from the DASS system.		and SPX. Some ideas have also been drawn from the DASS system.
	These changes are by no means endorsed by these groups. This is an		These changes are by no means endorsed by these groups. This is an
	skipping to change at page 20, line 24 ¶		skipping to change at page 23, line 12 ¶
	This document has no actions for IANA.		This document has no actions for IANA.
	7. References		7. References
	7.1 Normative References		7.1 Normative References
	[CLAR] RFC-Editor: To be replaced by RFC number for draft-ietf-		[CLAR] RFC-Editor: To be replaced by RFC number for draft-ietf-
	krb-wg-kerberos-clarifications. Work in Progress.		krb-wg-kerberos-clarifications. Work in Progress.
			[IEEE1363]
			IEEE, "Standard Specifications for Public Key
			Cryptography", IEEE 1363, 2000.
	[KCRYPTO] RFC-Editor: To be replaced by RFC number for draft-ietf-		[KCRYPTO] RFC-Editor: To be replaced by RFC number for draft-ietf-
	krb-wg-crypto. Work in Progress.		krb-wg-crypto. Work in Progress.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",		[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
	RFC 2412, November 1998.		RFC 2412, November 1998.
	[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",		[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
	skipping to change at page 21, line 17 ¶		skipping to change at page 24, line 8 ¶
	Diffie-Hellman groups for Internet Key Exchange (IKE)",		Diffie-Hellman groups for Internet Key Exchange (IKE)",
	RFC 3526, May 2003.		RFC 3526, May 2003.
	[RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES)		[RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES)
	Encryption Algorithm in Cryptographic Message Syntax		Encryption Algorithm in Cryptographic Message Syntax
	(CMS)", RFC 3565, July 2003.		(CMS)", RFC 3565, July 2003.
	[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",		[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
	RFC 3852, July 2004.		RFC 3852, July 2004.
			[X.509-97] ITU-T. Recommendation X.509: The Directory - Authentication
			Framework. 1997.
	[X690] ASN.1 encoding rules: Specification of Basic Encoding		[X690] ASN.1 encoding rules: Specification of Basic Encoding
	Rules (BER), Canonical Encoding Rules (CER) and		Rules (BER), Canonical Encoding Rules (CER) and
	Distinguished Encoding Rules (DER), ITU-T Recommendation		Distinguished Encoding Rules (DER), ITU-T Recommendation
	X.690 (1997) | ISO/IEC International Standard		X.690 (1997) | ISO/IEC International Standard
	8825-1:1998.		8825-1:1998.
	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
			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)".
	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
	Marina del Rey, CA 90292		Marina del Rey, CA 90292
	US		US
	skipping to change at page 21, line 47 ¶		skipping to change at page 25, line 4 ¶
	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
	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)
	identified-organization (3) dod (6) internet (1)		identified-organization (3) dod (6) internet (1)
	security (5) mechanisms (5) pkix (7) id-mod (0)		security (5) mechanisms (5) pkix (7) id-mod (0)
	id-pkix1-explicit (18) }		id-pkix1-explicit (18) }
	-- As defined in RFC 3280.		-- As defined in RFC 3280.
	DomainParameters		DomainParameters, EcpkParameters
	FROM PKIX1Algorithms88 { iso(1)		FROM PKIX1Algorithms88 { iso(1)
	identified-organization(3) dod(6)		identified-organization(3) dod(6)
	internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)		internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
	id-mod-pkix1-algorithms(17) }		id-mod-pkix1-algorithms(17) }
	-- As defined in RFC 3279.		-- As defined in RFC 3279.
	KerberosTime, TYPED-DATA, PrincipalName, Realm, EncryptionKey		KerberosTime, TYPED-DATA, 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) } ;
	skipping to change at page 22, line 37 ¶		skipping to change at page 25, line 39 ¶
	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-pkauthdata OBJECT IDENTIFIER ::= { id-pkinit 1 }
	id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 }		id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 }
	id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 }		id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 }
	id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 }		id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 }
	id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 }		id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 }
	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-certificate-index 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-pkauthdata (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 TrustedCA OPTIONAL,		trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,
	-- A list of CAs, trusted by the client, that can		-- A list of CAs, trusted by the client, that can
	-- be used to validate KDC certificates.		-- be used as the trust anchor to validate the KDC's
	kdcCert [2] IMPLICIT OCTET STRING		-- signature.
			-- Each TrustedCA identifies a CA or a CA
			-- certificate (thereby its public key).
			kdcPkId [2] IMPLICIT OCTET STRING
	OPTIONAL,		OPTIONAL,
	-- Contains a CMS type IssuerAndSerialNumber encoded		-- Contains a CMS type SignerIdentifier encoded
	-- according to [RFC3852].		-- according to [RFC3852].
	-- Identifies a particular KDC certificate, if the		-- Identifies, if present, a particular KDC
	-- client already has it.		-- public key that the client already has.
	...		...
	}		}
	DHNonce ::= OCTET STRING		DHNonce ::= OCTET STRING
	TrustedCA ::= CHOICE {		TrustedCA ::= SEQUENCE {
	caName [1] IMPLICIT OCTET STRING,		caName [0] IMPLICIT OCTET STRING,
	-- Contains a PKIX type Name encoded according to		-- Contains a PKIX type Name encoded according to
	-- [RFC3280].		-- [RFC3280].
	issuerAndSerial [2] IMPLICIT OCTET STRING,		-- Identifies a CA.
	-- Contains a CMS type IssuerAndSerialNumber encoded		-- Prefer the sid field below if that is available.
	-- according to [RFC3852].		certificateSerialNumber [1] INTEGER OPTIONAL,
	-- Identifies a specific CA certificate.		-- Specifies the certificate serial number.
			-- The defintion of the certificate serial number
			-- is taken from X.509 [X.509-97].
			subjectKeyIdentifier [2] OCTET STRING OPTIONAL,
			-- Identifies the CA'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.
	...		...
	}		}
	AuthPack ::= SEQUENCE {		AuthPack ::= SEQUENCE {
	pkAuthenticator [0] PKAuthenticator,		pkAuthenticator [0] PKAuthenticator,
	clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,		clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
	-- Defined in [RFC3280].		-- Defined in [RFC3280].
			-- The pubic key value (the subjectPublicKey field
			-- of the type SubjectPublicKeyInfo) MUST be encoded
			-- according to [RFC3279].
	-- Present only if the client wishes to use the		-- Present only if the client wishes to use the
	-- Diffie-Hellman key agreement method.		-- Diffie-Hellman key agreement method.
	supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier		supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
	OPTIONAL,		OPTIONAL,
	-- List of CMS encryption types supported by		-- List of CMS encryption types supported by
	-- client in order of (decreasing) preference.		-- client in order of (decreasing) preference.
	clientDHNonce [3] DHNonce OPTIONAL,		clientDHNonce [3] DHNonce OPTIONAL,
	-- Present only if the client indicates that it		-- Present only if the client indicates that it
	-- wishes to cache DH keys or to allow the KDC to		-- wishes to reuse DH keys or to allow the KDC to
	-- do so.		-- do so.
	...		...
	}		}
	PKAuthenticator ::= SEQUENCE {		PKAuthenticator ::= SEQUENCE {
	cusec [0] INTEGER (0..999999),		cusec [0] INTEGER (0..999999),
	ctime [1] KerberosTime,		ctime [1] KerberosTime,
	-- cusec and ctime are used as in [CLAR], for replay		-- cusec and ctime are used as in [CLAR], for replay
	-- prevention.		-- 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.
	...		...
	}		}
	TrustedCertifiers ::= SEQUENCE OF OCTET STRING		TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA
	-- The OCTET STRING contains a PKIX type Name encoded		-- Identifies a list of CAs trusted by the KDC.
	-- according to [RFC3280].		-- Each TrustedCA identifies a CA or a CA
			-- certificate (thereby its public key).
	CertificateIndex ::= OCTET STRING		TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING
	-- Contains a CMS type IssuerAndSerialNumber encoded		-- Each OCTET STRING contains a CMS type
	-- according to [RFC3852].		-- IssuerAndSerialNumber encoded according to
			-- [RFC3852].
			-- Each IssuerAndSerialNumber indentifies a
			-- certificate (sent by the client) with an invalid
			-- signature.
	KRB5PrincipalName ::= SEQUENCE {		KRB5PrincipalName ::= SEQUENCE {
	realm [0] Realm,		realm [0] Realm,
	principalName [1] PrincipalName		principalName [1] PrincipalName
	}		}
	InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {		AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA
	ca [0] IMPLICIT OCTET STRING,		-- Identifies the certification path based on which
	-- Contains a PKIX type Name encoded according to		-- the client certificate was validated.
	-- [RFC3280].		-- Each TrustedCA identifies a CA or a CA
	validated [1] BOOLEAN,		-- certificate (thereby its public key).
	...
	}
	PA-PK-AS-REP ::= CHOICE {		PA-PK-AS-REP ::= CHOICE {
	dhInfo [0] DHRepInfo,		dhInfo [0] DHRepInfo,
			-- Selected when Diffie-Hellman key exchange is
			-- used.
	encKeyPack [1] IMPLICIT OCTET STRING,		encKeyPack [1] IMPLICIT OCTET STRING,
			-- 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 id-pkrkeydata
	-- (1.2.840.113549.1.7.3) and the eContent field		-- (1.2.840.113549.1.7.3) and the eContent field
	skipping to change at page 25, line 26 ¶		skipping to change at page 29, line 4 ¶
	-- 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-pkdhkeydata (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 public key, y = g^x mod p.		-- KDC's DH public key.
	-- MUST be ASN.1 encoded as an INTEGER;		-- The DH pubic key value is mapped to a BIT STRING
	-- This encoding is then used as the contents		-- according to [RFC3279].
	-- (i.e., the value) of this BIT STRING field.
	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 cached DH keys are NOT used,		-- request if DH keys are NOT reused,
	-- 0 otherwise.		-- 0 otherwise.
	dhKeyExpiration [2] KerberosTime OPTIONAL,		dhKeyExpiration [2] KerberosTime OPTIONAL,
	-- Expiration time for KDC's cached values, present		-- Expiration time for KDC's key pair,
	-- if and only if cached DH keys are used. If this		-- present if and only if DH keys are reused. If
	-- field is omitted then the serverDHNonce field		-- this field is omitted then the serverDHNonce
	-- 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.
	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.		-- request.
	skipping to change at page 26, line 4 ¶		skipping to change at page 29, line 28 ¶
	...		...
	}		}
	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.
	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.		-- request.
	...		...
	}		}
	TD-DH-PARAMETERS ::= SEQUENCE OF DomainParameters		TD-DH-PARAMETERS ::= SEQUENCE OF DHDomainParameters
	-- Contains a list of Diffie-Hellman group		-- Contains a list of Diffie-Hellman domain
	-- parameters in decreasing preference order.		-- parameters in decreasing preference order.
			DHDomainParameters ::= CHOICE {
			modp [0] DomainParameters,
			-- Type DomainParameters is defined in [RFC3279].
			ec [1] EcpkParameters,
			-- Type EcpkParameters is defined in [RFC3279].
			...
			}
	END		END
	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
End of changes. 133 change blocks.
	341 lines changed or deleted		517 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/