< draft-ietf-cat-kerberos-pk-init-22.txt		draft-ietf-cat-kerberos-pk-init-23.txt >
	NETWORK WORKING GROUP B. Tung		NETWORK WORKING GROUP B. Tung
	Internet-Draft C. Neuman		Internet-Draft USC Information Sciences Institute
	Expires: June 6, 2005 USC Information Sciences Institute		Expires: August 4, 2005 L. Zhu
	L. Zhu
	M. Hur
	Microsoft Corporation		Microsoft Corporation
	S. Medvinsky		January 31, 2005
	Motorola, Inc.
	December 6, 2004
	Public Key Cryptography for Initial Authentication in Kerberos		Public Key Cryptography for Initial Authentication in Kerberos
	draft-ietf-cat-kerberos-pk-init		draft-ietf-cat-kerberos-pk-init-23
	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.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	skipping to change at page 1, line 41 ¶		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 June 6, 2005.		This Internet-Draft will expire on August 4, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004).		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 passing digital certificates and
	associated authenticators in preauthentication data fields.		associated authenticators in pre-authentication data fields.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions Used in This Document . . . . . . . . . . . . . . 4		2. Conventions Used in This Document . . . . . . . . . . . . . . 3
	3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1 Definitions, Requirements, and Constants . . . . . . . . . 5		3.1 Definitions, Requirements, and Constants . . . . . . . . . 4
	3.1.1 Required Algorithms . . . . . . . . . . . . . . . . . 5		3.1.1 Required Algorithms . . . . . . . . . . . . . . . . . 4
	3.1.2 Defined Message and Encryption Types . . . . . . . . . 6		3.1.2 Defined Message and Encryption Types . . . . . . . . . 5
	3.1.3 Algorithm Identifiers . . . . . . . . . . . . . . . . 7		3.1.3 Algorithm Identifiers . . . . . . . . . . . . . . . . 6
	3.2 PKINIT Preauthentication Syntax and Use . . . . . . . . . 7		3.2 PKINIT Pre-authentication Syntax and Use . . . . . . . . . 6
	3.2.1 Client Request . . . . . . . . . . . . . . . . . . . . 8		3.2.1 Generation of Client Request . . . . . . . . . . . . . 7
	3.2.2 Validation of Client Request . . . . . . . . . . . . . 10		3.2.2 Receipt of Client Request . . . . . . . . . . . . . . 9
	3.2.3 KDC Reply . . . . . . . . . . . . . . . . . . . . . . 12		3.2.3 Generation of KDC Reply . . . . . . . . . . . . . . . 12
	3.2.4 Validation of KDC Reply . . . . . . . . . . . . . . . 17		3.2.4 Receipt of KDC Reply . . . . . . . . . . . . . . . . . 17
	3.3 KDC Indication of PKINIT Support . . . . . . . . . . . . . 17		3.3 KDC Indication of PKINIT Support . . . . . . . . . . . . . 18
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 19		4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	7. Normative References . . . . . . . . . . . . . . . . . . . . . 22		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23		7.1 Normative References . . . . . . . . . . . . . . . . . . . 20
	A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 24		7.2 Informative References . . . . . . . . . . . . . . . . . . 21
	Intellectual Property and Copyright Statements . . . . . . . . 28		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
			A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 21
			Intellectual Property and Copyright Statements . . . . . . . . 27
	1. Introduction		1. Introduction
	A client typically authenticates itself to a service in Kerberos		A client typically authenticates itself to a service in Kerberos
	using three distinct though related exchanges. First, the client		using three distinct though related exchanges. First, the client
	requests a ticket-granting ticket (TGT) from the Kerberos		requests a ticket-granting ticket (TGT) from the Kerberos
	authentication server (AS). Then, it uses the TGT to request a		authentication server (AS). Then, it uses the TGT to request a
	service ticket from the Kerberos ticket-granting server (TGS).		service ticket from the Kerberos ticket-granting server (TGS).
	Usually, the AS and TGS are integrated in a single device known as a		Usually, the AS and TGS are integrated in a single device known as a
	Kerberos Key Distribution Center, or KDC. Finally, the client uses		Kerberos Key Distribution Center, or KDC. (In this document, we will
	the service ticket to authenticate itself to the service.		refer to both the AS and the TGS as the KDC.) Finally, the client
			uses the service ticket to authenticate itself to the service.
	The advantage afforded by the TGT is that the client need explicitly		The advantage afforded by the TGT is that the client exposes his
	request a ticket and expose his credentials only once. The TGT and		long-term secrets only once. The TGT and its associated session key
	its associated session key can then be used for any subsequent		can then be used for any subsequent service ticket requests. One
	requests. One result of this is that all further authentication is		result of this is that all further authentication is independent of
	independent of the method by which the initial authentication was		the method by which the initial authentication was performed.
	performed. Consequently, initial authentication provides a		Consequently, initial authentication provides a convenient place to
	convenient place to integrate public-key cryptography into Kerberos		integrate public-key cryptography into Kerberos authentication.
	authentication.
	As defined, Kerberos authentication exchanges use symmetric-key		As defined in [CLAR], Kerberos authentication exchanges use
	cryptography, in part for performance. One cost of using		symmetric-key cryptography, in part for performance. One
	symmetric-key cryptography is that the keys must be shared, so that		disadvantage of using symmetric-key cryptography is that the keys
	before a client can authenticate itself, he must already be		must be shared, so that before a client can authenticate itself, he
	registered with the KDC.		must already be registered with the KDC.
	Conversely, public-key cryptography (in conjunction with an		Conversely, public-key cryptography (in conjunction with an
	established Public Key Infrastructure) permits authentication without		established Public Key Infrastructure) permits authentication without
	prior registration with a KDC. Adding it to Kerberos allows the		prior registration with a KDC. Adding it to Kerberos allows the
	widespread use of Kerberized applications by clients without		widespread use of Kerberized applications by clients without
	requiring them to register first with a KDC--a requirement that has		requiring them to register first with a KDC--a requirement that has
	no inherent security benefit.		no inherent security benefit.
	As noted above, a convenient and efficient place to introduce		As noted above, a convenient and efficient place to introduce
	public-key cryptography into Kerberos is in the initial		public-key cryptography into Kerberos is in the initial
	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, we will refer to both the AS and the TGS as the
	KDC.
	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 policy and trusted		2. The KDC tests the client's request against its authentication
	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 symmetric encryption key, signed using the KDC's signature		a. a key generated through a Diffie-Hellman (DH) key exchange
	key and encrypted using the client's encryption key; or		[RFC2631] with the client, signed using the KDC's signature
			key; or
	b. a key generated through a Diffie-Hellman exchange with the		b. a symmetric encryption key, signed using the KDC's signature
	client, signed using the KDC's signature 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 is returned in a preauthentication field		encryption key for decrypting the KDC reply is returned in a
	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 obtains the encryption key, decrypts the reply, and
	then proceeds as usual.		then proceeds as usual.
	Section 3.1 of this document defines the necessary message formats.		Section 3.1 of this document enumerates the required algorithms and
	Section 3.2 describes their syntax and use in greater detail.		necessary extension message types. Section 3.2 describes the
			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 AS reply key: AES256-CTS-HMAC-SHA1-96 etype [KCRYPTO].
	o Signature algorithm: SHA-1 digest and RSA.		o Signature algorithm: sha-1WithRSAEncryption [RFC3279].
	o Reply key delivery method: RSA or ephemeral-ephemeral		o KDC AS reply key delivery method: ephemeral-ephemeral
	Diffie-Hellman.		Diffie-Hellman exchange (Diffie-Hellman keys are not cached).
	3.1.2 Defined Message and Encryption Types		3.1.2 Defined Message and Encryption Types
	PKINIT makes use of the following new preauthentication 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:
	skipping to change at page 6, line 35 ¶		skipping to change at page 5, line 35 ¶
	KDC_ERR_REVOKED_CERTIFICATE 72		KDC_ERR_REVOKED_CERTIFICATE 72
	KDC_ERR_REVOCATION_STATUS_UNKNOWN 73		KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
	KDC_ERR_CLIENT_NAME_MISMATCH 75		KDC_ERR_CLIENT_NAME_MISMATCH 75
	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-CERTIFICATE-INDEX 105
	TD-DH-PARAMETERS 109		TD-DH-PARAMETERS 109
	PKINIT defines the following encryption types, for use in the		PKINIT defines the following encryption types, for use in the AS-REQ
	KRB_AS_REQ message (to indicate acceptance of the corresponding		message (to indicate acceptance of the corresponding encryption
	encryption OIDs in PKINIT):		Object Identifiers (OIDs) in PKINIT):
	dsaWithSHA1-CmsOID 9		dsaWithSHA1-CmsOID 9
	md5WithRSAEncryption-CmsOID 10		md5WithRSAEncryption-CmsOID 10
	sha1WithRSAEncryption-CmsOID 11		sha1WithRSAEncryption-CmsOID 11
	rc2CBC-EnvOID 12		rc2CBC-EnvOID 12
	rsaEncryption-EnvOID (PKCS1 v1.5) 13		rsaEncryption-EnvOID (PKCS1 v1.5) 13
	rsaES-OAEP-EnvOID (PKCS1 v2.0) 14		rsaES-OAEP-EnvOID (PKCS1 v2.0) 14
	des-ede3-cbc-EnvOID 15		des-ede3-cbc-EnvOID 15
	The above encryption types are used by the client only within the		The above encryption types are used by the client only within the
	KDC-REQ-BODY to indicate which CMS [RFC2630] algorithms it supports.		KDC-REQ-BODY to indicate which Cryptographic Message Syntax (CMS)
	Their use within Kerberos EncryptedData structures is not specified		[RFC3852] algorithms it supports. Their use within Kerberos
	by this document.		EncryptedData structures is not specified by this document.
	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 Appendix		IMPORT statements for all imported structures) are given in
	A.		Appendix A.
	All structures defined in this document MUST be encoded using		All structures defined in or imported into this document MUST be
	Distinguished Encoding Rules (DER) [X690]. All imported data		encoded using Distinguished Encoding Rules (DER) [X690]. All data
	structures must be encoded according to the rules specified in		structures wrapped in OCTET STRINGs must be encoded according to the
	Kerberos [CLAR] or CMS [RFC2630] as appropriate.		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		CMS objects encoded with BER but not DER; specifically, they may not
	be able to decode infinite length encodings. To maximize		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 identifier for Diffie-Hellman key
	agreement [FIPS74]:		agreement [RFC3279]:
	dhpublicnumber		dhpublicnumber
	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 [RFC2437]		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 [RFC2630] for		PKINIT uses the following algorithm identifiers [RFC3370][RFC3565]
	encrypting the reply key with the temporary key:		for encrypting the 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)
	aes256_CBC (AES-256, CBC mode)		id-aes256-CBC (AES-256, CBC mode)
	3.2 PKINIT Preauthentication 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
	preauthentication fields employed by PKINIT.		pre-authentication fields employed by PKINIT.
	3.2.1 Client Request
	The initial authentication request (KRB_AS_REQ) is sent as per
	[CLAR]; in addition, a preauthentication field contains data signed
	by the client's private signature key, as follows:
	WrapContentInfo ::= OCTET STRING (CONSTRAINED BY {		3.2.1 Generation of Client Request
	-- Contains a BER encoding of ContentInfo.
	})
	WrapIssuerAndSerial ::= OCTET STRING (CONSTRAINED BY {		The initial authentication request (AS-REQ) is sent as per [CLAR]; in
	-- Contains a BER encoding of IssuerAndSerialNumber.		addition, a pre-authentication field contains data signed by the
	})		client's private signature key, as follows:
	PA-PK-AS-REQ ::= SEQUENCE {		PA-PK-AS-REQ ::= SEQUENCE {
	signedAuthPack [0] IMPLICIT WrapContentInfo,		signedAuthPack [0] IMPLICIT OCTET STRING,
	-- Type is SignedData.		-- Contains a CMS type ContentInfo encoded
	-- Content is AuthPack		-- according to [RFC3852].
	-- (defined below).		-- The contentType field of the type ContentInfo
	trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,		-- is id-signedData (1.2.840.113549.1.7.2),
	-- A list of CAs, trusted by		-- and the content field is a SignedData.
	-- the client, used to certify		-- The eContentType field for the type SignedData is
	-- KDCs.		-- id-pkauthdata (1.3.6.1.5.2.3.1), and the
	kdcCert [2] IMPLICIT WrapIssuerAndSerial		-- eContent field contains the DER encoding of the
	OPTIONAL,		-- type AuthPack.
	-- Identifies a particular KDC		-- AuthPack is defined below.
	-- certificate, if the client		trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,
	-- already has it.		-- A list of CAs, trusted by the client, that can
	clientDHNonce [3] DHNonce OPTIONAL,		-- be used to validate KDC certificates.
	...		kdcCert [2] IMPLICIT OCTET STRING
			OPTIONAL,
			-- Contains a CMS type IssuerAndSerialNumber encoded
			-- according to [RFC3852].
			-- Identifies a particular KDC certificate, if the
			-- client already has it.
			...
	}		}
			DHNonce ::= OCTET STRING
	TrustedCA ::= CHOICE {		TrustedCA ::= CHOICE {
	caName [1] Name,		caName [1] IMPLICIT OCTET STRING,
	-- Fully qualified X.500 name		-- Contains a PKIX type Name encoded according to
	-- as defined in [RFC3280].		-- [RFC3280].
	issuerAndSerial [2] IMPLICIT WrapIssuerAndSerial,		issuerAndSerial [2] IMPLICIT OCTET STRING,
	-- Identifies a specific CA		-- Contains a CMS type IssuerAndSerialNumber encoded
	-- certificate.		-- according to [RFC3852].
	...		-- Identifies a specific CA certificate.
			...
	}		}
	AuthPack ::= SEQUENCE {		AuthPack ::= SEQUENCE {
	pkAuthenticator [0] PKAuthenticator,		pkAuthenticator [0] PKAuthenticator,
	clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,		clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
	-- Defined in [RFC3280].		-- Defined in [RFC3280].
	-- Present only if the client		-- Present only if the client wishes to use the
	-- is using ephemeral-ephemeral		-- Diffie-Hellman key agreement method.
	-- Diffie-Hellman.		supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
	supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier		OPTIONAL,
	OPTIONAL,		-- List of CMS encryption types supported by
	-- List of CMS encryption types		-- client in order of (decreasing) preference.
	-- supported by client in order		clientDHNonce [3] DHNonce OPTIONAL,
	-- of (decreasing) preference.		-- Present only if the client indicates that it
	...		-- wishes to cache DH keys or to allow the KDC to
			-- 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		-- cusec and ctime are used as in [CLAR], for replay
	-- in [CLAR], for replay		-- prevention.
	-- prevention.		nonce [2] INTEGER (0..4294967295),
	nonce [2] INTEGER (0..4294967295),		-- Chosen randomly; This nonce does not need to
	paChecksum [3] OCTET STRING,		-- match with the nonce in the KDC-REQ-BODY.
	-- Contains the SHA1 checksum,		paChecksum [3] OCTET STRING,
	-- performed over KDC-REQ-BODY.		-- Contains the SHA1 checksum, performed over
	...		-- KDC-REQ-BODY.
			...
	}		}
	The ContentInfo in the signedAuthPack is filled out as follows:		The ContentInfo [RFC3852] structure for the signedAuthPack field is
			filled out as follows:
	1. The eContent field contains data of type AuthPack. It MUST		1. The contentType field of the type ContentInfo is id-signedData
	contain the pkAuthenticator, and MAY also contain the client's		(as defined in [RFC3852]), and the content field is a SignedData
	Diffie-Hellman public value (clientPublicValue).		(as defined in [RFC3852]).
	2. The eContentType field MUST contain the OID value for		2. The eContentType field for the type SignedData is id-pkauthdata:
	id-pkauthdata: { iso(1) org(3) dod(6) internet(1) security(5)		{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
	kerberosv5(2) pkinit(3) pkauthdata(1) }.		pkinit(3) pkauthdata(1) }.
	3. The signerInfos field MUST contain the signature over the		3. The eContent field for the type SignedData contains the DER
	AuthPack.		encoding of the type AuthPack.
	4. The certificates field MUST contain at least a signature		4. The signerInfos field of the type SignedData contains a single
	verification certificate chain that the KDC can use to verify the		signerInfo, which contains the signature over the type AuthPack.
	signature over the AuthPack. The certificate chain(s) MUST NOT
	contain the root CA certificate.
	5. If a Diffie-Hellman key is being used, the parameters MUST be		5. The certificates field of the type SignedData contains the
	chosen from Oakley Group 2 or 14. Implementations MUST support		client's certificate and additional certificates intended to
	Group 2; they are RECOMMENDED to support Group 14 (See		facilitate certification path construction, so that the KDC can
	[RFC2409]).		validate the client's certificate and verify the signature over
			the type AuthPack. The certificates field MUST NOT contain
			"root" CA certificates.
	6. The client may wish to cache DH parameters or to allow the KDC to		6. The client's Diffie-Hellman public value (clientPublicValue) is
	do so. If so, then the client must include the clientDHNonce		included if and only if the client wishes to use the
	field. The nonce string needs to be as long as the longest key		Diffie-Hellman key agreement method. For the Diffie-Hellman key
	length of the symmetric key types that the client supports. The		agreement method, implementations MUST support Oakley 1024-bit
	nonce MUST be chosen randomly.		MODP well-known group 2 [RFC2412] and SHOULD support Oakley
			2048-bit MODP well-known group 14 and Oakley 4096-bit MODP
			well-known group 16 [RFC3526]. They MAY support Oakley 185-bit
			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].
	3.2.2 Validation of Client Request		7. The client may wish to cache DH keys or to allow the KDC to do
			so. 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
	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 must look for a client certificate in the signedAuthPack. If		The KDC looks for the client's certificate in the signedAuthPack
	it cannot find one signed by a CA it trusts, it sends back an error		(based on the signerInfo) and validate this certificate.
	of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for
	this error is a TYPED-DATA (as defined in [CLAR]). For this error,		If the KDC cannot find a certification path to validate the client's
	the data-type is TD-TRUSTED-CERTIFIERS, and the data-value is the DER		certificate, it sends back an error of type
			KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for this
			error is a TYPED-DATA (as defined in [CLAR]). For this error, the
			data-type is TD-TRUSTED-CERTIFIERS, and the data-value is the DER
	encoding of		encoding of
	TrustedCertifiers ::= SEQUENCE OF Name		TrustedCertifiers ::= SEQUENCE OF OCTET STRING
			-- The OCTET STRING contains a PKIX type Name encoded
			-- according to [RFC3280].
	If, while verifying the certificate chain, 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 is
	invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE.		invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE.
	The accompanying e-data for this error is a TYPED-DATA, whose		The accompanying e-data for this error is a TYPED-DATA, whose
	data-type is TD-CERTIFICATE-INDEX, and whose data-value is the DER		data-type is TD-CERTIFICATE-INDEX, and whose data-value is the DER
	encoding of the index into the CertificateSet field, ordered as sent		encoding of the index into the CertificateSet field, ordered as sent
	by the client:		by the client:
	CertificateIndex ::= IssuerAndSerialNumber		CertificateIndex ::= OCTET STRING
	-- IssuerAndSerialNumber of		-- Contains a CMS type IssuerAndSerialNumber encoded
	-- certificate with invalid signature.		-- according to [RFC3852].
			-- IssuerAndSerialNumber of certificate with an
			-- invalid signature.
	If more than one certificate signature is invalid, the KDC MAY send		If more than one certificate signature is invalid, the KDC MAY send
	one TYPED-DATA per invalid signature.		one TYPED-DATA per invalid signature.
	The KDC MAY also check whether any certificates in the client's chain		The KDC SHOULD also check whether any certificates in the client's
	have been revoked. If any of them have been revoked, the KDC MUST		certification path have been revoked. If any of them have been
	return an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC		revoked, the KDC MUST return an error of type
	attempts to determine the revocation status but is unable to do so,		KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
	it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN.		revocation status but is unable to do so, it SHOULD return an error
			of type KDC_ERR_REVOCATION_STATUS_UNKNOWN. The certificate or
	The certificate or certificates affected are identified exactly as		certificates affected are identified exactly as for an error of type
	for an error of type KDC_ERR_INVALID_CERTIFICATE (see above).		KDC_ERR_INVALID_CERTIFICATE (see above).
	In addition to validating the certificate chain, the KDC MUST also		In addition to validating the client's certificate, the KDC MUST also
	check that the certificate properly maps to the client's principal		check that this certificate properly maps to the client's principal
	name as specified in the KRB_AS_REQ as follows:		name as specified in the AS-REQ as follows:
	1. If the KDC has its own mapping from the name in the certificate		1. If the KDC has its own mapping from the name in the client's
	to a Kerberos name, it uses that Kerberos name.		certificate to a Kerberos name, it uses that Kerberos name.
	2. Otherwise, if the certificate contains a SubjectAltName extension		2. Otherwise, if the client's certificate contains a SubjectAltName
	with a Kerberos name in the otherName field, it uses that name.		extension with a Kerberos name in the otherName field, it uses
			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 is:		The type-id field of the type AnotherName is id-pksan:
	krb5PrincipalName OBJECT IDENTIFIER ::= iso (1) org (3) dod (6)		id-pksan OBJECT IDENTIFIER ::=
	internet (1) security (5) kerberosv5 (2) 2		{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
			x509-sanan (2) }
	The value is the DER encoding of the following ASN.1 type:		The value field of the type AnotherName is the DER encoding of the
			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 mapping and there is no Kerberos
	name present in the certificate, or if the name in the request does		name present in the client's certificate, or if the name in the
	not match the name in the certificate (including the realm name), or		request does not match the name in the certificate (including the
	if there is no name in the request, the KDC MUST return error code		realm name), the KDC MUST return error 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.
	Even if the certificate chain is validated, and the names in the		Even if the client's certificate is validated and it is mapped to the
	certificate and the request match, the KDC may decide to reject		client's principal name, the KDC may decide not to accept the
	requests on the basis of the absence or presence of specific EKU		client's certificate, depending on local policy.
	OIDs. For example, the certificate may include an Extended Key Usage
	(EKU) OID of id-pkekuoid in the extensions field:
	{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)		The KDC MAY require the presence of an Extended Key Usage (EKU)
	pkinit(3) pkekuoid(4) }		KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the
			client's certificate:
			id-pkekuoid OBJECT IDENTIFIER ::=
			{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
			pkinit(3) pkekuoid(4) }
			-- PKINIT client authentication.
			-- Key usage bits that may be consistent: digitalSignature
			-- nonRepudiation, and (keyEncipherment or keyAgreement).
			As a matter of local policy, the KDC may decide to reject requests on
			the basis of the absence or presence of specific EKU OIDs. KDCs
			implementing this requirement SHOULD also accept the EKU KeyPurposeId
			id-ms-sc-logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement,
			as there are a large number of 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		The KDC MUST return the error code KDC_ERR_CLIENT_NOT_TRUSTED if the
	client's cerficate is not accepted.		client's certificate is not accepted.
	If the client's signature on the signedAuthPack fails to verify, the		Once the client's certificate is accepted, the KDC can then verify
	KDC MUST return error KDC_ERR_INVALID_SIG. There is no accompanying		the client's signature over the type AuthPack according to [RFC3852].
	e-data for this error.		If the signature fails to verify, the KDC MUST return error
			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 clock skew times in [CLAR] apply here. If the check
	fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or		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 ephemeral-ephemeral Diffie-Hellman, the KDC checks to		wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
	see if the parameters satisfy its policy. If they do not, it MUST		check to see if the key parameters satisfy its policy. If they do
	return error code KDC_ERR_KEY_SIZE. The accompanying e-data is a		not, it MUST return error code KDC_ERR_KEY_SIZE. The accompanying
	TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and whose data-value		e-data is a TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and
	is the DER encoding of a DomainParameters (see [RFC3279]), including		whose data-value is the DER encoding of the following:
	appropriate Diffie-Hellman parameters with which to retry the
	request.		TD-DH-PARAMETERS ::= SEQUENCE OF DomainParameters
			-- Type DomainParameters is defined in [RFC3279].
			-- Contains a list of Diffie-Hellman group
			-- parameters in decreasing preference order.
			TD-DH-PARAMETERS contains a list of Diffie-Hellman group parameters
			that the KDC supports in decreasing preference order, from which the
			client should pick one to retry the request.
	The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the		The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the
	client included a kdcCert field in the PA-PK-AS-REQ and the KDC does		client included a kdcCert field in the PA-PK-AS-REQ and the KDC does
	not have the corresponding certificate.		not have the corresponding certificate.
	The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client		The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client
	did not include a kdcCert field, but did include a trustedCertifiers		did not include a kdcCert field, but did include a trustedCertifiers
	field, and the KDC does not possesses a certificate issued by one of		field, and the KDC does not possesses a certificate issued by one of
	the listed certifiers.		the listed certifiers.
	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 of type
	KRB5KDC_ERR_ETYPE_NOSUPP.		KRB5KDC_ERR_ETYPE_NOSUPP.
	3.2.3 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		of type AD-INITIAL-VERIFIED-CAS in the issued ticket. The value is
	an OCTET STRING containing the DER encoding of InitialVerifiedCAs:		an OCTET STRING containing the DER encoding of InitialVerifiedCAs:
	InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {		InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
	ca [0] Name,		ca [0] IMPLICIT OCTET STRING,
	Validated [1] BOOLEAN,		-- Contains a PKIX type Name encoded according to
	...		-- [RFC3280].
			validated [1] BOOLEAN,
			...
	}		}
	The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT		The KDC MAY wrap 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 KDC's realm's policy
	(this corresponds to the TRANSITED-POLICY-CHECKED ticket flag).		(this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
	Furthermore, any TGS must copy such authorization data from tickets		[CLAR]). Furthermore, any TGS must copy such authorization data from
	used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket,		tickets used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket,
	including the AD-IF-RELEVANT container, if present.		including the AD-IF-RELEVANT container, if present.
	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.) If such a data type is contained within an AD-IF-RELEVANT		set [CLAR].) If such a data type is contained within an
	container, AP servers MAY apply local policy to determine whether the		AD-IF-RELEVANT container, AP servers MAY apply local policy to
	authorization data is acceptable.		determine whether the authorization data is acceptable.
	The KRB_AS_REP is otherwise unchanged from [CLAR]. The KDC encrypts		The AS-REP is otherwise unchanged from [CLAR]. The KDC encrypts the
	the reply as usual, but not with the client's long-term key.		reply as usual, but not with the client's long-term key. Instead, it
	Instead, it encrypts it with either a generated encryption key, or a		encrypts it with either a shared key derived from a Diffie-Hellman
	key derived from a Diffie-Hellman exchange. The contents of the		exchange, or a generated encryption key. The contents of the
	PA-PK-AS-REP indicate the type of encryption key that was used:		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,
	encKeyPack [1] IMPLICIT WrapContentInfo,		encKeyPack [1] IMPLICIT OCTET STRING,
	-- Type is EnvelopedData.		-- Contains a CMS type ContentInfo encoded
	-- Content is SignedData over		-- according to [RFC3852].
	-- ReplyKeyPack (defined below).		-- The contentType field of the type ContentInfo is
	...		-- id-envelopedData (1.2.840.113549.1.7.3).
			-- The content field is an EnvelopedData.
			-- The contentType field for the type EnvelopedData
			-- is id-signedData (1.2.840.113549.1.7.2).
			-- The eContentType field for the inner type
			-- SignedData (when unencrypted) is id-pkrkeydata
			-- (1.2.840.113549.1.7.3) and the eContent field
			-- contains the DER encoding of the type
			-- ReplyKeyPack.
			-- ReplyKeyPack is defined below.
			...
	}		}
	DHRepInfo ::= SEQUENCE {		DHRepInfo ::= SEQUENCE {
	dhSignedData [0] ContentInfo,		dhSignedData [0] IMPLICIT OCTET STRING,
	-- Type is SignedData.		-- Contains a CMS type ContentInfo encoded according
	-- Content is KDCDHKeyInfo		-- to [RFC3852].
	-- (defined below).		-- The contentType field of the type ContentInfo is
	serverDHNonce [1] DHNonce OPTIONAL		-- id-signedData (1.2.840.113549.1.7.2), and the
			-- content field is a SignedData.
			-- The eContentType field for the type SignedData is
			-- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
			-- eContent field contains the DER encoding of the
			-- type KDCDHKeyInfo.
			-- KDCDHKeyInfo is defined below.
			serverDHNonce [1] DHNonce OPTIONAL
			-- Present if and only if dhKeyExpiration is
			-- present.
	}		}
	KDCDHKeyInfo ::= SEQUENCE {		KDCDHKeyInfo ::= SEQUENCE {
	subjectPublicKey [0] BIT STRING,		subjectPublicKey [0] BIT STRING,
	-- Equals public exponent		-- KDC's public key, y = g^x mod p.
	-- (g^a mod p).		-- MUST be ASN.1 encoded as an INTEGER;
	-- INTEGER encoded as payload		-- This encoding is then used as the contents
	-- of BIT STRING.		-- (i.e., the value) of this BIT STRING field.
	nonce [1] INTEGER (0..4294967295),		nonce [1] INTEGER (0..4294967295),
	dhKeyExpiration [2] KerberosTime OPTIONAL,		-- Contains the nonce in the PKAuthenticator of the
	-- Expiration time for KDC's		-- request if cached DH keys are NOT used,
	-- cached values. If this field		-- 0 otherwise.
	-- is omitted then the		dhKeyExpiration [2] KerberosTime OPTIONAL,
	-- serverDHNonce field MUST also		-- Expiration time for KDC's cached values, present
	-- be omitted.		-- if and only if cached DH keys are used. If this
	...		-- field is omitted then the serverDHNonce field
			-- MUST also be omitted.
			...
	}		}
	The fields of the ContentInfo for dhSignedData are to be filled in as		3.2.3.1 Using Diffie-Hellman Key Exchange
	follows:
	1. The eContent field contains data of type KDCDHKeyInfo.		In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
	2. The eContentType field contains the OID value for id-pkdhkeydata:		The ContentInfo [RFC3852] structure for the dhSignedData field is
	{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)		filled in as follows:
	pkinit(3) pkdhkeydata(2) }.
	3. The signerInfos field contains a single signerInfo, which is the		1. The contentType field of the type ContentInfo is id-signedData
	signature of the KDCDHKeyInfo.		(as defined in [RFC3852]), and the content field is a SignedData
			(as defined in [RFC3852]).
	4. The certificates field contains a signature verification		2. The eContentType field for the type SignedData is the OID value
	certificate chain that the client will use to verify the KDC's		for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
	signature over the KDCDHKeyInfo. This field may only be left		security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }.
	empty if the client did include a kdcCert field in the
	PA-PK-AS-REQ, indicating that it has the KDC's certificate. The
	certificate chain MUST NOT contain the root CA certificate.
	5. If the client included the clientDHNonce field, then the KDC may		3. The eContent field for the type SignedData contains the DER
	choose to reuse its DH parameters. If the server reuses DH		encoding of the type KDCDHKeyInfo.
	parameters then it MUST include an expiration time in the
	dhKeyExperiation field. Past the point of the expiration time,
	the signature of the DHRepInfo is considered invalid. When the
	server reuses DH parameters then it MUST include a serverDHNonce
	at least as long as the length of keys for the symmetric
	encryption system used to encrypt the AS reply. Note that
	including the serverDHNonce changes how the client and server
	calculate the key to use to encrypt the reply; see below for
	details. Clients MUST NOT reuse DH parameters unless the
	response includes the serverDHNonce field.
	If the Diffie-Hellman key exchange is used, the KDC reply key [CLAR]		4. The signerInfos field of the type SignedData contains a single
	is derived as follows:		signerInfo, which contains the signature over the type
			KDCDHKeyInfo.
			5. The certificates field of the type SignedData contains the KDC's
			certificate and additional certificates intended to facilitate
			certification path construction, so that the client can validate
			the KDC's certificate and verify the KDC's signature over the
			type KDCDHKeyInfo. This field may only be left empty if the
			client did include a kdcCert field in the PA-PK-AS-REQ,
			indicating that the client already has the KDC's certificate.
			The certificates field MUST NOT contain "root" CA certificates.
			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
			it MUST include an expiration time in the dhKeyExperiation field.
			Past the point of the expiration time, the signature over the
			type DHRepInfo is considered expired/invalid. When the server
			reuses DH keys then it MUST include a serverDHNonce at least as
			long as the length of keys for the symmetric encryption system
			used to encrypt the AS reply. Note that including the
			serverDHNonce changes how the client and server calculate the key
			to use to encrypt the reply; see below for details. The KDC
			SHOULD NOT reuse DH keys unless the clientDHNonce field is
			present in the request.
			The reply key for use to decrypt the KDC reply [CLAR] is derived as
			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
			DHKey:
	DHKey = g^(ab) mod p		DHKey = g^(xb * xa) mod p
	where a and b are the client's and KDC's private exponents,		where xb and xa are the KDC's and client's private exponents,
	respectively. DHKey, padded first with leading zeros as needed to		respectively. DHKey, padded first with leading zeros as needed to
	make it as long as the modulus p, is represented as a string of		make it as long as the modulus p, is represented as a string of
	octets in big-endian order (such that the size of DHKey in octets		octets in big-endian order (such that the size of DHKey in octets
	is the size of the modulus p).		is the size of the modulus p).
	2. Let K be the key-generation seed length [KCRYPTO] of the reply		2. Let K be the key-generation seed length [KCRYPTO] of the reply
	key whose enctype is selected according to [CLAR].		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 protocolkey 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 K		a bitstring of length K; and K-truncate truncates its input to the
	bits. Both K and random-to-key() are defined in the kcrypto		first K bits. Both K and random-to-key() are defined in the
	profile [KCRYPTO] for the enctype of the reply key.		kcrypto profile [KCRYPTO] for the enctype of the reply key.
	4. When cached DH parameters are used, let n_c be the clientDHNonce,		4. When cached DH keys are used, let n_c be the clientDHNonce, and
	and n_k be the serverDHNonce; otherwise, let both n_c and n_k be		n_k be the serverDHNonce; otherwise, let both n_c and n_k be empty
	empty octet strings.		octet strings.
	5. The KDC reply key k is:		5. The reply key k is:
	k = octetstring2key(DHKey | n_c | n_k)		k = octetstring2key(DHKey | n_c | n_k)
	If the Diffie-Hellman key exchange is not used, the KDC reply key		3.2.3.2 Using Public Key Encryption
	[CLAR] is encrypted in the encKeyPack, which contains data of type
	ReplyKeyPack:		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
			reply [CLAR] is encrypted in the encKeyPack field, which contains
			data of type ReplyKeyPack:
	ReplyKeyPack ::= SEQUENCE {		ReplyKeyPack ::= SEQUENCE {
	replyKey [0] EncryptionKey,		replyKey [0] EncryptionKey,
	-- Defined in [CLAR].		-- Contains the session key used to encrypt the
	-- Used to encrypt main reply.		-- enc-part field in the AS-REP.
	-- MUST be at least as strong		nonce [1] INTEGER (0..4294967295),
	-- as session key. (Using the		-- Contains the nonce in the PKAuthenticator of the
	-- same enctype and a strong		-- request.
	-- prng should suffice, if no		...
	-- stronger encryption system
	-- is available.)
	nonce [1] INTEGER (0..4294967295),
	-- Contains the nonce in
	-- the KDCDHKeyInfo.
	...
	}		}
	The fields of the ContentInfo for encKeyPack MUST be filled in as		The ContentInfo [RFC3852] structure for the encKeyPack field is
	follows:		filled in as follows:
	1. The content is of type SignedData. The eContent for the		1. The contentType field of the type ContentInfo is id-envelopedData
	SignedData is of type ReplyKeyPack.		(as defined in [RFC3852]), and the content field is an
			EnvelopedData (as defined in [RFC3852]).
	2. The eContentType for the SignedData contains the OID value for		2. The contentType field for the type EnvelopedData is
	id-pkrkeydata: { iso(1) org(3) dod(6) internet(1) security(5)		id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
	kerberosv5(2) pkinit(3) pkrkeydata(3) }.		pkcs (1) pkcs7 (7) signedData (2) }.
	3. The signerInfos field contains a single signerInfo, which is the		3. The eContentType field for the inner type SignedData (when
	signature of the ReplyKeyPack.		decrypted from the encryptedContent field for the type
			EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6)
			internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }.
	4. The certificates field contains a signature verification		4. The eContent field for the inner type SignedData contains the DER
	certificate chain that the client will use to verify the KDC's		encoding of the type ReplyKeyPack.
	signature over the ReplyKeyPack. This field may only be left
	empty if the client included a kdcCert field in the PA-PK-AS-REQ,
	indicating that it has the KDC's certificate. The certificate
	chain MUST NOT contain the root CA certificate.
	5. The contentType for the EnvelopedData contains the OID value for		5. The signerInfos field of the inner type SignedData contains a
	id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549)		single signerInfo, which contains the signature over the type
	pkcs (1) pkcs7 (7) signedData (2) }.		ReplyKeyPack.
	6. The recipientInfos field is a SET which MUST contain exactly one		6. The certificates field of the inner type SignedData contains the
	member of type KeyTransRecipientInfo. The encryptedKey for this		KDC's certificate and additional certificates intended to
	member contains the temporary key which is encrypted using the		facilitate certification path construction, so that the client
	client's public key.		can validate the KDC's certificate and verify the KDC's signature
			over the type ReplyKeyPack. This field may only be left empty if
			the client included a kdcCert field in the PA-PK-AS-REQ,
			indicating that the client already has the KDC's certificate.
			The certificates field MUST NOT contain "root" CA certificates.
	7. The unprotectedAttrs or originatorInfo fields MAY be present.		7. The recipientInfos field of the type EnvelopedData is a SET which
			MUST contain exactly one member of type KeyTransRecipientInfo.
			The encryptedKey of this member contains the temporary key which
			is encrypted using the client's public key.
	3.2.4 Validation of KDC Reply		8. The unprotectedAttrs or originatorInfo fields of the type
			EnvelopedData MAY be present.
			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 a dhSignedData, the client obtains and		the PA-PK-AS-REP contains the dhSignedData field, the client derives
	verifies the Diffie-Hellman parameters, and obtains the shared key as		the shared key using the same procedure used by the KDC as defined in
	described above. Otherwise, the message contains an encKeyPack, and		Section 3.2.3.1. Otherwise, the message contains an encKeyPack, and
	the client decrypts and verifies the temporary encryption key.		the client decrypts and verifies the temporary encryption key.
	In either case, the client MUST check to see if the included		In either case, the client MUST validate the KDC's certificate and
	certificate contains a subjectAltName extension of type dNSName or		verify the signature in the SignedData according to [RFC3852].
	iPAddress (if the KDC is specified by IP address instead of name).		Unless the client can otherwise prove that the KDC's certificate is
	If it does, it MUST check to see if that extension matches the KDC it		for the target KDC (i.e., the subject distinguished name in the KDC
	believes it is communicating with, with matching rules specified in		certificate is bound to the hostname or IP address of the KDC
	RFC 2459. Exception: If the client has some external information as		authenticating the client), it MUST do the following to verify the
	to the identity of the KDC, this check MAY be omitted.		responder's identity:
	The client also MUST check that the KDC's certificate contains an		1. The client checks to see if the included certificate contains a
	extendedKeyUsage OID of id-pkkdcekuoid:		Subject Alternative Name extension [RFC3280] carrying a dNSName or
			an iPAddress (if the KDC is specified by an IP address instead of
			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].
	{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)		2. The client verifies that the KDC's certificate MUST contain the
	pkinit(3) pkkdcekuoid(5) }		EKU KeyPurposeId [RFC3280] id-pkkdcekuoid:
			id-pkkdcekuoid OBJECT IDENTIFIER ::=
			{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
			pkinit(3) pkkdcekuoid(5) }
			-- Signing KDC responses.
			-- Key usage bits that may be consistent:
			-- digitalSignature.
	If all applicable checks are satisfied, the client then decrypts the		If all applicable checks are satisfied, the client then decrypts the
	main reply with the resulting key, and then proceeds as described in		enc-part of the KDC-REP in the AS_REP with the resulting key, and
	[1].		then proceeds as described in [CLAR].
	3.3 KDC Indication of PKINIT Support		3.3 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 a PA-PK-AS-REQ element in
	that METHOD-DATA object.		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 preauthentication 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.
	The padata-value for the PA-PK-AS-REQ entry in the METHOD-DATA object		KDCs MUST leave the padata-value of PA-PK-AS-REQ entry in the
	is an empty octet string and SHOULD be ignored otherwise.		KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
			STRING), and clients MUST ignore this and any other value. Future
			extensions to this protocol may specify other data to send instead of
			an empty OCTET STRING.
	4. Security Considerations		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.
	skipping to change at page 19, line 26 ¶		skipping to change at page 19, line 12 ¶
	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 allows the use of a zero nonce in the PKAuthenticator when		PKINIT uses the same RSA key pair for encryption and signing when
	cached Diffie-Hellman keys are used. In this case, message binding		doing RSA encryption based key delivery. This is not recommended
	is performed using the nonce in the main request in the same way as		usage of RSA keys [RFC3447], by using DH based key delivery this is
	it is done for ordinary KRB_AS_REQs (without the PKINIT		avoided.
	pre-authenticator). The nonce field in the KDC request body is
	signed through the checksum in the PKAuthenticator, which
	cryptographically binds the PKINIT pre-authenticator to the main body
	of the AS Request and also provides message integrity for the full AS
	Request.
	However, when a PKINIT pre-authenticator in the KRB_AS_REP has a
	zero-nonce, and an attacker has somehow recorded this
	pre-authenticator and discovered the corresponding Diffie-Hellman
	private key (e.g., with a brute-force attack), the attacker will be
	able to fabricate his own KRB_AS_REP messages that impersonate the
	KDC with this same pre-authenticator. This compromised
	pre-authenticator will remain valid as long as its expiration time
	has not been reached and it is therefore important for clients to
	check this expiration time and for the expiration time to be
	reasonably short, which depends on the size of the Diffie-Hellman
	group.
	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.
	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.
	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. [This		be used if the KDC itself vouches for the user's certificate.
	seems to reflect the consensus of the Kerberos working group.]
	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, Sam Hartman, Love Hornquist Astrand, Ken Raeburn,		draft: Paul Leach, Phil Hallin, Kelvin Yiu, Sam Hartman, Love
	Nicolas Williams, John Wray, Jonathan Trostle, Tom Yu and Jeff		Hornquist Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan
	Hutzelman.		Trostle, Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon and
			Karthik Jaganathan.
			Special thanks to Clifford Neuman, Mat Hur and Sasha Medvinsky who
			wrote earlier versions of this document.
			The authors are indebt to the Kerberos working group chair Jeffrey
			Hutzelman who kept track of various issues and was enormously helpful
			during the creation of this document.
	Some of the ideas on which this document is based arose during		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
	attempt to revive some of the goals of those groups, and this		attempt to revive some of the goals of those groups, and this
	document approaches those goals primarily from the Kerberos		document approaches those goals primarily from the Kerberos
	perspective. Lastly, comments from groups working on similar ideas		perspective.
	in DCE have been invaluable.
			Lastly, comments from groups working on similar ideas in DCE have
			been invaluable.
	6. IANA Considerations		6. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	7 Normative References		7. References
	[CLAR] Neuman, B., Yu, Y., Hartman, S. and K. Raeburn, "The		7.1 Normative References
	Kerberos Network Authentication Service (V5)",
	draft-ietf-krb-wg-kerberos-clarifications, work in
	progress.
	[FIPS74] NIST, Guidelines for Implementing and Using		[CLAR] RFC-Editor: To be replaced by RFC number for draft-ietf-
	the NBS Encryption Standard, April 1981. FIPS PUB 74.		krb-wg-kerberos-clarifications. Work in Progress.
	[KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for		[KCRYPTO] RFC-Editor: To be replaced by RFC number for draft-ietf-
	Kerberos 5", December 2004.		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.
	[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange		[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
	(IKE)", RFC 2409, November 1998.		RFC 2412, November 1998.
	[RFC2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
	Specifications Version 2.0", RFC 2437, October 1998.
	[RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630,		[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
	June 1999.		RFC 2631, June 1999.
	[RFC3279] Bassham, L., Polk, W. and R. Housley, "Algorithms and		[RFC3279] Bassham, L., Polk, W. and R. Housley, "Algorithms and
	Identifiers for the Internet X.509 Public Key		Identifiers for the Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 3279, April 2002.		(CRL) Profile", RFC 3279, April 2002.
	[RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet		[RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
	X.509 Public Key Infrastructure Certificate and		X.509 Public Key Infrastructure Certificate and
	Certificate Revocation List (CRL) Profile", RFC 3280,		Certificate Revocation List (CRL) Profile", RFC 3280,
	April 2002.		April 2002.
	[X690] ASN.1 encoding rules: Specification of Basic		[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
	Encoding Rules (BER), Canonical Encoding Rules (CER) and		Algorithms", RFC 3370, August 2002.
			[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
			Standards (PKCS) #1: RSA Cryptography Specifications
			Version 2.1", RFC 3447, February 2003.
			[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
			Diffie-Hellman groups for Internet Key Exchange (IKE)",
			RFC 3526, May 2003.
			[RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES)
			Encryption Algorithm in Cryptographic Message Syntax
			(CMS)", RFC 3565, July 2003.
			[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
			RFC 3852, July 2004.
			[X690] ASN.1 encoding rules: Specification of Basic Encoding
			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.
	Authors' Addresses		7.2 Informative References
	Brian Tung		[ODL99] Odlyzko, A., "Discrete logarithms: The past and the
	USC Information Sciences Institute		future, Designs, Codes, and Cryptography (1999)".
	4676 Admiralty Way Suite 1001, Marina del Rey CA
	Marina del Rey, CA 90292
	US
	EMail: brian@isi.edu		Authors' Addresses
	Clifford Neuman		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
	EMail: brian@isi.edu		Email: brian@isi.edu
	Larry Zhu		Larry Zhu
	Microsoft Corporation		Microsoft Corporation
	One Microsoft Way		One Microsoft Way
	Redmond, WA 98052		Redmond, WA 98052
	US		US
	EMail: lzhu@microsoft.com		Email: lzhu@microsoft.com
	Matt Hur
	Microsoft Corporation
	One Microsoft Way
	Redmond, WA 98052
	US
	EMail: matthur@microsoft.com
	Sasha Medvinsky
	Motorola, Inc.
	6450 Sequence Drive
	San Diego, CA 92121
	US
	EMail: smedvinsky@motorola.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(3)		security(5) kerberosV5(2) modules(4) pkinit(5)
	} DEFINITIONS EXPLICIT TAGS ::= BEGIN		} DEFINITIONS EXPLICIT TAGS ::= BEGIN
	IMPORTS		IMPORTS
	SubjectPublicKeyInfo, AlgorithmIdentifier, Name		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.
	ContentInfo, IssuerAndSerialNumber		DomainParameters
	FROM CryptographicMessageSyntax { iso(1) member-body(2)		FROM PKIX1Algorithms88 { iso(1)
	us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)		identified-organization(3) dod(6)
	modules(0) cms(1) }		internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
			id-mod-pkix1-algorithms(17) }
			-- 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) } ;
	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-pkdhkeydata 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-certificate-index INTEGER ::= 105
	td-dh-parameters INTEGER ::= 109		td-dh-parameters INTEGER ::= 109
	WrapContentInfo ::= OCTET STRING (CONSTRAINED BY {
	-- Contains a BER encoding of ContentInfo.
	})
	WrapIssuerAndSerial ::= OCTET STRING (CONSTRAINED BY {
	-- Contains a BER encoding of IssuerAndSerialNumber.
	})
	PA-PK-AS-REQ ::= SEQUENCE {		PA-PK-AS-REQ ::= SEQUENCE {
	signedAuthPack [0] IMPLICIT WrapContentInfo,		signedAuthPack [0] IMPLICIT OCTET STRING,
	-- Type is SignedData.		-- Contains a CMS type ContentInfo encoded
	-- Content is AuthPack		-- according to [RFC3852].
	-- (defined below).		-- The contentType field of the type ContentInfo
			-- is id-signedData (1.2.840.113549.1.7.2),
			-- and the content field is a SignedData.
			-- The eContentType field for the type SignedData is
			-- id-pkauthdata (1.3.6.1.5.2.3.1), and the
			-- eContent field contains the DER encoding of the
			-- type AuthPack.
			-- AuthPack is defined below.
	trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,		trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,
	-- A list of CAs, trusted by		-- A list of CAs, trusted by the client, that can
	-- the client, used to certify		-- be used to validate KDC certificates.
	-- KDCs.		kdcCert [2] IMPLICIT OCTET STRING
	kdcCert [2] IMPLICIT WrapIssuerAndSerial
	OPTIONAL,		OPTIONAL,
	-- Identifies a particular KDC		-- Contains a CMS type IssuerAndSerialNumber encoded
	-- certificate, if the client		-- according to [RFC3852].
	-- already has it.		-- Identifies a particular KDC certificate, if the
	clientDHNonce [3] DHNonce OPTIONAL,		-- client already has it.
	...		...
	}		}
			DHNonce ::= OCTET STRING
	TrustedCA ::= CHOICE {		TrustedCA ::= CHOICE {
	caName [1] Name,		caName [1] IMPLICIT OCTET STRING,
	-- Fully qualified X.500 name		-- Contains a PKIX type Name encoded according to
	-- as defined in [RFC3280].		-- [RFC3280].
	issuerAndSerial [2] IMPLICIT WrapIssuerAndSerial,		issuerAndSerial [2] IMPLICIT OCTET STRING,
	-- Identifies a specific CA		-- Contains a CMS type IssuerAndSerialNumber encoded
	-- certificate.		-- according to [RFC3852].
			-- Identifies a specific CA certificate.
	...		...
	}		}
	AuthPack ::= SEQUENCE {		AuthPack ::= SEQUENCE {
	pkAuthenticator [0] PKAuthenticator,		pkAuthenticator [0] PKAuthenticator,
	clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,		clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
	-- Defined in [RFC3280].		-- Defined in [RFC3280].
	-- Present only if the client		-- Present only if the client wishes to use the
	-- is using ephemeral-ephemeral		-- Diffie-Hellman key agreement method.
	-- Diffie-Hellman.
	supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier		supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
	OPTIONAL,		OPTIONAL,
	-- List of CMS encryption types		-- List of CMS encryption types supported by
	-- supported by client in order		-- client in order of (decreasing) preference.
	-- of (decreasing) preference.		clientDHNonce [3] DHNonce OPTIONAL,
			-- Present only if the client indicates that it
			-- wishes to cache DH keys or to allow the KDC to
			-- 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		-- cusec and ctime are used as in [CLAR], for replay
	-- in [CLAR], for replay		-- prevention.
	-- prevention.
	nonce [2] INTEGER (0..4294967295),		nonce [2] INTEGER (0..4294967295),
			-- Chosen randomly; This nonce does not need to
			-- match with the nonce in the KDC-REQ-BODY.
	paChecksum [3] OCTET STRING,		paChecksum [3] OCTET STRING,
	-- Contains the SHA1 checksum,		-- Contains the SHA1 checksum, performed over
	-- performed over KDC-REQ-BODY.		-- KDC-REQ-BODY.
	...		...
	}		}
	TrustedCertifiers ::= SEQUENCE OF Name		TrustedCertifiers ::= SEQUENCE OF OCTET STRING
			-- The OCTET STRING contains a PKIX type Name encoded
			-- according to [RFC3280].
	CertificateIndex ::= IssuerAndSerialNumber		CertificateIndex ::= OCTET STRING
			-- Contains a CMS type IssuerAndSerialNumber encoded
			-- according to [RFC3852].
	KRB5PrincipalName ::= SEQUENCE {		KRB5PrincipalName ::= SEQUENCE {
	realm [0] Realm,		realm [0] Realm,
	principalName [1] PrincipalName		principalName [1] PrincipalName
	}		}
	InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {		InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
	ca [0] Name,		ca [0] IMPLICIT OCTET STRING,
	Validated [1] BOOLEAN,		-- Contains a PKIX type Name encoded according to
			-- [RFC3280].
			validated [1] BOOLEAN,
	...		...
	}		}
	PA-PK-AS-REP ::= CHOICE {		PA-PK-AS-REP ::= CHOICE {
	dhInfo [0] DHRepInfo,		dhInfo [0] DHRepInfo,
	encKeyPack [1] IMPLICIT WrapContentInfo,		encKeyPack [1] IMPLICIT OCTET STRING,
	-- Type is EnvelopedData.		-- Contains a CMS type ContentInfo encoded
	-- Content is SignedData over		-- according to [RFC3852].
	-- ReplyKeyPack (defined below).		-- The contentType field of the type ContentInfo is
			-- id-envelopedData (1.2.840.113549.1.7.3).
			-- The content field is an EnvelopedData.
			-- The contentType field for the type EnvelopedData
			-- is id-signedData (1.2.840.113549.1.7.2).
			-- The eContentType field for the inner type
			-- SignedData (when unencrypted) is id-pkrkeydata
			-- (1.2.840.113549.1.7.3) and the eContent field
			-- contains the DER encoding of the type
			-- ReplyKeyPack.
			-- ReplyKeyPack is defined below.
	...		...
	}		}
	DHRepInfo ::= SEQUENCE {		DHRepInfo ::= SEQUENCE {
	dhSignedData [0] ContentInfo,		dhSignedData [0] IMPLICIT OCTET STRING,
	-- Type is SignedData.		-- Contains a CMS type ContentInfo encoded according
	-- Content is KDCDHKeyInfo		-- to [RFC3852].
	-- (defined below).		-- The contentType field of the type ContentInfo is
			-- id-signedData (1.2.840.113549.1.7.2), and the
			-- content field is a SignedData.
			-- The eContentType field for the type SignedData is
			-- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
			-- eContent field contains the DER encoding of the
			-- type KDCDHKeyInfo.
			-- KDCDHKeyInfo is defined below.
	serverDHNonce [1] DHNonce OPTIONAL		serverDHNonce [1] DHNonce OPTIONAL
			-- Present if and only if dhKeyExpiration is
			-- present.
	}		}
	KDCDHKeyInfo ::= SEQUENCE {		KDCDHKeyInfo ::= SEQUENCE {
	subjectPublicKey [0] BIT STRING,		subjectPublicKey [0] BIT STRING,
	-- Equals public exponent		-- KDC's public key, y = g^x mod p.
	-- (g^a mod p).		-- MUST be ASN.1 encoded as an INTEGER;
	-- INTEGER encoded as payload		-- This encoding is then used as the contents
	-- of BIT STRING.		-- (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
			-- request if cached DH keys are NOT used,
			-- 0 otherwise.
	dhKeyExpiration [2] KerberosTime OPTIONAL,		dhKeyExpiration [2] KerberosTime OPTIONAL,
	-- Expiration time for KDC's		-- Expiration time for KDC's cached values, present
	-- cached values. If this field		-- if and only if cached DH keys are used. If this
	-- is omitted then the		-- field is omitted then the serverDHNonce field
	-- serverDHNonce field MUST also		-- MUST also be omitted.
	-- be omitted.
	...		...
	}		}
	ReplyKeyPack ::= SEQUENCE {		ReplyKeyPack ::= SEQUENCE {
	replyKey [0] EncryptionKey,		replyKey [0] EncryptionKey,
	-- Defined in [CLAR].		-- Contains the session key used to encrypt the
	-- Used to encrypt main reply.		-- enc-part field in the AS-REP.
	-- MUST be at least as strong
	-- as session key. (Using the
	-- same enctype and a strong
	-- prng should suffice, if no
	-- stronger encryption system
	-- is available.)
	nonce [1] INTEGER (0..4294967295),		nonce [1] INTEGER (0..4294967295),
	-- Contains the nonce in		-- Contains the nonce in the PKAuthenticator of the
	-- the KDCDHKeyInfo.		-- request.
	...		...
	}		}
	END		TD-DH-PARAMETERS ::= SEQUENCE OF DomainParameters
			-- Contains a list of Diffie-Hellman group
			-- parameters in decreasing preference order.
			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
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	skipping to change at page 28, line 41 ¶		skipping to change at page 27, line 41 ¶
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2004). This document is subject		Copyright (C) The Internet Society (2005). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 152 change blocks.
	505 lines changed or deleted		623 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/