< draft-ietf-cat-kerberos-pk-init-21.txt		draft-ietf-cat-kerberos-pk-init-22.txt >
	INTERNET-DRAFT Brian Tung
	draft-ietf-cat-kerberos-pk-init-21.txt Clifford Neuman		NETWORK WORKING GROUP B. Tung
	expires April 25, 2005 USC/ISI		Internet-Draft C. Neuman
	Sasha Medvinsky		Expires: June 6, 2005 USC Information Sciences Institute
			L. Zhu
			M. Hur
			Microsoft Corporation
			S. Medvinsky
	Motorola, Inc.		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
	0. Status Of This Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		This document is an Internet-Draft and is subject to all provisions
	patent or other IPR claims of which I am aware have been disclosed,		of section 3 of RFC 3667. By submitting this Internet-Draft, each
	or will be disclosed, and any of which I become aware will be		author represents that any applicable patent or other IPR claims of
	disclosed, in accordance with RFC 3668.		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
			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.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six months
	months and may be updated, replaced, or obsoleted by other documents		and may be updated, replaced, or obsoleted by other documents at any
	at any time. It is inappropriate to use Internet-Drafts as		time. It is inappropriate to use Internet-Drafts as reference
	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.
	The distribution of this memo is unlimited. It is filed as		This Internet-Draft will expire on June 6, 2005.
	draft-ietf-cat-kerberos-pk-init-21.txt and expires April 25, 2005.
	Please send comments to the authors.
	1. Abstract		Copyright Notice
	This document describes protocol extensions (hereafter called		Copyright (C) The Internet Society (2004).
	PKINIT) to the Kerberos protocol specification [1]. These
	extensions provide a method for integrating public key cryptography
	into the initial authentication exchange, by passing digital
	certificates and associated authenticators in preauthentication data
	fields.
	2. Introduction		Abstract
	A client typically authenticates itself to a service in Kerberos		This document describes protocol extensions (hereafter called PKINIT)
	using three distinct though related exchanges. First, the client		to the Kerberos protocol specification. These extensions provide a
	requests a ticket-granting ticket (TGT) from the Kerberos		method for integrating public key cryptography into the initial
	authentication server (AS). Then, it uses the TGT to request a		authentication exchange, by passing digital certificates and
	service ticket from the Kerberos ticket-granting server (TGS).		associated authenticators in preauthentication data fields.
	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 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		Table of Contents
	request a ticket and expose his credentials only once. The TGT and
	its associated session key can then be used for any subsequent
	requests. One result of this is that all further authentication is
	independent of the method by which the initial authentication was
	performed. Consequently, initial authentication provides a
	convenient place to integrate public-key cryptography into Kerberos
	authentication.
	As defined, Kerberos authentication exchanges use symmetric-key		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	cryptography, in part for performance. One cost of using		2. Conventions Used in This Document . . . . . . . . . . . . . . 4
	symmetric-key cryptography is that the keys must be shared, so that		3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	before a client can authenticate itself, he must already be		3.1 Definitions, Requirements, and Constants . . . . . . . . . 5
	registered with the KDC.		3.1.1 Required Algorithms . . . . . . . . . . . . . . . . . 5
			3.1.2 Defined Message and Encryption Types . . . . . . . . . 6
			3.1.3 Algorithm Identifiers . . . . . . . . . . . . . . . . 7
			3.2 PKINIT Preauthentication Syntax and Use . . . . . . . . . 7
			3.2.1 Client Request . . . . . . . . . . . . . . . . . . . . 8
			3.2.2 Validation of Client Request . . . . . . . . . . . . . 10
			3.2.3 KDC Reply . . . . . . . . . . . . . . . . . . . . . . 12
			3.2.4 Validation of KDC Reply . . . . . . . . . . . . . . . 17
			3.3 KDC Indication of PKINIT Support . . . . . . . . . . . . . 17
			4. Security Considerations . . . . . . . . . . . . . . . . . . . 19
			5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
			6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
			7. Normative References . . . . . . . . . . . . . . . . . . . . . 22
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
			A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 24
			Intellectual Property and Copyright Statements . . . . . . . . 28
	Conversely, public-key cryptography (in conjunction with an		1. Introduction
	established Public Key Infrastructure) permits authentication
	without prior registration with a KDC. Adding it to Kerberos allows
	the widespread use of Kerberized applications by clients without
	requiring them to register first with a KDC--a requirement that has
	no inherent security benefit.
	As noted above, a convenient and efficient place to introduce		A client typically authenticates itself to a service in Kerberos
	public-key cryptography into Kerberos is in the initial		using three distinct though related exchanges. First, the client
	authentication exchange. This document describes the methods and		requests a ticket-granting ticket (TGT) from the Kerberos
	data formats for integrating public-key cryptography into Kerberos		authentication server (AS). Then, it uses the TGT to request a
	initial authentication.		service ticket from the Kerberos ticket-granting server (TGS).
			Usually, the AS and TGS are integrated in a single device known as a
			Kerberos Key Distribution Center, or KDC. Finally, the client uses
			the service ticket to authenticate itself to the service.
	3. Extensions		The advantage afforded by the TGT is that the client need explicitly
			request a ticket and expose his credentials only once. The TGT and
			its associated session key can then be used for any subsequent
			requests. One result of this is that all further authentication is
			independent of the method by which the initial authentication was
			performed. Consequently, initial authentication provides a
			convenient place to integrate public-key cryptography into Kerberos
			authentication.
	This section describes extensions to [1] for supporting the use of		As defined, Kerberos authentication exchanges use symmetric-key
	public-key cryptography in the initial request for a ticket.		cryptography, in part for performance. One cost of using
			symmetric-key cryptography is that the keys must be shared, so that
			before a client can authenticate itself, he must already be
			registered with the KDC.
	Briefly, this document defines the following extensions to [1]:		Conversely, public-key cryptography (in conjunction with an
			established Public Key Infrastructure) permits authentication without
			prior registration with a KDC. Adding it to Kerberos allows the
			widespread use of Kerberized applications by clients without
			requiring them to register first with a KDC--a requirement that has
			no inherent security benefit.
	1. The client indicates the use of public-key authentication by		As noted above, a convenient and efficient place to introduce
	including a special preauthenticator in the initial request.		public-key cryptography into Kerberos is in the initial
	This preauthenticator contains the client's public-key data		authentication exchange. This document describes the methods and
	and a signature.		data formats for integrating public-key cryptography into Kerberos
			initial authentication.
	2. The KDC tests the client's request against its policy and		2. Conventions Used in This Document
	trusted Certification Authorities (CAs).
	3. If the request passes the verification tests, the KDC		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	replies as usual, but the reply is encrypted using either:		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [RFC2119].
	a. a symmetric encryption key, signed using the KDC's		In this document, we will refer to both the AS and the TGS as the
	signature key and encrypted using the client's encryption		KDC.
	key; or
	b. a key generated through a Diffie-Hellman exchange with		3. Extensions
	the client, signed using the KDC's signature key.
	Any keying material required by the client to obtain the		This section describes extensions to [CLAR] for supporting the use of
	Encryption key is returned in a preauthentication field		public-key cryptography in the initial request for a ticket.
	accompanying the usual reply.
	4. The client obtains the encryption key, decrypts the reply,		Briefly, this document defines the following extensions to [CLAR]:
	and then proceeds as usual.
	Section 3.1 of this document defines the necessary message formats.		1. The client indicates the use of public-key authentication by
	Section 3.2 describes their syntax and use in greater detail.		including a special preauthenticator in the initial request. This
			preauthenticator contains the client's public-key data and a
			signature.
	3.1. Definitions, Requirements, and Constants		2. The KDC tests the client's request against its policy and trusted
			Certification Authorities (CAs).
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		3. If the request passes the verification tests, the KDC replies as
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		usual, but the reply is encrypted using either:
	document are to be interpreted as described in RFC 2119 [12].
	3.1.1. Required Algorithms		a. a symmetric encryption key, signed using the KDC's signature
			key and encrypted using the client's encryption key; or
	All PKINIT implementations MUST support the following algorithms:		b. a key generated through a Diffie-Hellman exchange with the
			client, signed using the KDC's signature key.
	- Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype.		Any keying material required by the client to obtain the
			Encryption key is returned in a preauthentication field
			accompanying the usual reply.
	- Signature algorithm: SHA-1 digest and RSA.		4. The client obtains the encryption key, decrypts the reply, and
			then proceeds as usual.
	- Reply key delivery method: ephemeral-ephemeral Diffie-Hellman		Section 3.1 of this document defines the necessary message formats.
	with a non-zero nonce.		Section 3.2 describes their syntax and use in greater detail.
	- Unkeyed checksum type for the paChecksum member of		3.1 Definitions, Requirements, and Constants
	PKAuthenticator: SHA1 (unkeyed), Kerberos checksum type 14
	[11].
	3.1.2. Defined Message and Encryption Types		3.1.1 Required Algorithms
	PKINIT makes use of the following new preauthentication types:		All PKINIT implementations MUST support the following algorithms:
	PA-PK-AS-REQ TBD		o AS reply key: AES256-CTS-HMAC-SHA1-96 etype [KCRYPTO].
	PA-PK-AS-REP TBD
	PKINIT also makes use of the following new authorization data type:		o Signature algorithm: SHA-1 digest and RSA.
	AD-INITIAL-VERIFIED-CAS TBD		o Reply key delivery method: RSA or ephemeral-ephemeral
			Diffie-Hellman.
	PKINIT introduces the following new error codes:		3.1.2 Defined Message and Encryption Types
	KDC_ERR_CLIENT_NOT_TRUSTED 62		PKINIT makes use of the following new preauthentication types:
	KDC_ERR_KDC_NOT_TRUSTED 63
	KDC_ERR_INVALID_SIG 64
	KDC_ERR_KEY_SIZE 65
	KDC_ERR_CERTIFICATE_MISMATCH 66
	KDC_ERR_CANT_VERIFY_CERTIFICATE 70
	KDC_ERR_INVALID_CERTIFICATE 71
	KDC_ERR_REVOKED_CERTIFICATE 72
	KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
	KDC_ERR_CLIENT_NAME_MISMATCH 75
	PKINIT uses the following typed data types for errors:		PA-PK-AS-REQ 16
			PA-PK-AS-REP 17
	TD-DH-PARAMETERS TBD		PKINIT also makes use of the following new authorization data type:
	TD-TRUSTED-CERTIFIERS 104
	TD-CERTIFICATE-INDEX 105
	TD-UNKEYED-CHECKSUM-INFO 109
	PKINIT defines the following encryption types, for use in the AS-REQ		AD-INITIAL-VERIFIED-CAS 9
	message (to indicate acceptance of the corresponding encryption OIDs
	in PKINIT):
	dsaWithSHA1-CmsOID 9		PKINIT introduces the following new error codes:
	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		KDC_ERR_CLIENT_NOT_TRUSTED 62
	KDC-REQ-BODY to indicate which CMS [2] algorithms it supports. Their		KDC_ERR_KDC_NOT_TRUSTED 63
	use within Kerberos EncryptedData structures is not specified by this		KDC_ERR_INVALID_SIG 64
	document.		KDC_ERR_KEY_SIZE 65
			KDC_ERR_CERTIFICATE_MISMATCH 66
			KDC_ERR_CANT_VERIFY_CERTIFICATE 70
			KDC_ERR_INVALID_CERTIFICATE 71
			KDC_ERR_REVOKED_CERTIFICATE 72
			KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
			KDC_ERR_CLIENT_NAME_MISMATCH 75
	The ASN.1 module for all structures defined in this document (plus		PKINIT uses the following typed data types for errors:
	IMPORT statements for all imported structures) are given in Appendix
	A. In the event of a discrepancy between Appendix A and the portions
	of ASN.1 in the main text, the appendix is normative.
	All structures defined in this document MUST be encoded using		TD-TRUSTED-CERTIFIERS 104
	Distinguished Encoding Rules (DER). All imported data structures		TD-CERTIFICATE-INDEX 105
	must be encoded according to the rules specified in Kerberos [1] or		TD-DH-PARAMETERS 109
	CMS [2] as appropriate.
	Interoperability note: Some implementations may not be able to		PKINIT defines the following encryption types, for use in the
	decode CMS objects encoded with BER but not DER; specifically, they		KRB_AS_REQ message (to indicate acceptance of the corresponding
	may not be able to decode infinite length encodings. To maximize		encryption OIDs in PKINIT):
	interoperability, implementers SHOULD encode CMS objects used in
	PKINIT with DER.
	3.1.3. Algorithm Identifiers		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
	PKINIT does not define, but does make use of, the following		The above encryption types are used by the client only within the
	algorithm identifiers.		KDC-REQ-BODY to indicate which CMS [RFC2630] algorithms it supports.
			Their use within Kerberos EncryptedData structures is not specified
			by this document.
	PKINIT uses the following algorithm identifier for Diffie-Hellman		The ASN.1 module for all structures defined in this document (plus
	key agreement [9]:		IMPORT statements for all imported structures) are given in Appendix
			A.
	dhpublicnumber		All structures defined in this document MUST be encoded using
			Distinguished Encoding Rules (DER) [X690]. All imported data
			structures must be encoded according to the rules specified in
			Kerberos [CLAR] or CMS [RFC2630] as appropriate.
	PKINIT uses the following signature algorithm identifiers [8, 12]:		Interoperability note: Some implementations may not be able to decode
			CMS objects encoded with BER but not DER; specifically, they may not
			be able to decode infinite length encodings. To maximize
			interoperability, implementers SHOULD encode CMS objects used in
			PKINIT with DER.
	sha-1WithRSAEncryption (RSA with SHA1)		3.1.3 Algorithm Identifiers
	md5WithRSAEncryption (RSA with MD5)
	id-dsa-with-sha1 (DSA with SHA1)
	PKINIT uses the following encryption algorithm identifiers [5] for		PKINIT does not define, but does make use of, the following algorithm
	encrypting the temporary key with a public key:		identifiers.
	rsaEncryption (PKCS1 v1.5)		PKINIT uses the following algorithm identifier for Diffie-Hellman key
	id-RSAES-OAEP (PKCS1 v2.0)		agreement [FIPS74]:
	PKINIT uses the following algorithm identifiers [2] for encrypting		dhpublicnumber
	the reply key with the temporary key:
	des-ede3-cbc (three-key 3DES, CBC mode)		PKINIT uses the following signature algorithm identifiers [RFC3279]:
	rc2-cbc (RC2, CBC mode)
	aes256_CBC (AES-256, CBC mode)
	3.2. PKINIT Preauthentication Syntax and Use		sha-1WithRSAEncryption (RSA with SHA1)
			md5WithRSAEncryption (RSA with MD5)
			id-dsa-with-sha1 (DSA with SHA1)
	This section defines the syntax and use of the various		PKINIT uses the following encryption algorithm identifiers [RFC2437]
	preauthentication fields employed by PKINIT.		for encrypting the temporary key with a public key:
	3.2.1. Client Request		rsaEncryption (PKCS1 v1.5)
			id-RSAES-OAEP (PKCS1 v2.0)
	The initial authentication request (AS-REQ) is sent as per [1]; in		PKINIT uses the following algorithm identifiers [RFC2630] for
	addition, a preauthentication field contains data signed by the		encrypting the reply key with the temporary key:
	client's private signature key, as follows:
	WrapContentInfo ::= OCTET STRING (CONSTRAINED BY {		des-ede3-cbc (three-key 3DES, CBC mode)
	-- Contains a BER encoding of		rc2-cbc (RC2, CBC mode)
	-- ContentInfo		aes256_CBC (AES-256, CBC mode)
	})
	WrapIssuerAndSerial ::= OCTET STRING (CONSTRAINED BY {		3.2 PKINIT Preauthentication Syntax and Use
	-- Contains a BER encoding of
	-- IssuerAndSerialNumber
	})
	PA-PK-AS-REQ ::= SEQUENCE {		This section defines the syntax and use of the various
	signedAuthPack [0] IMPLICIT WrapContentInfo,		preauthentication fields employed by PKINIT.
	-- Type is SignedData.
	-- Content is AuthPack
	-- (defined below).
	trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,
	-- A list of CAs, trusted by
	-- the client, used to certify
	-- KDCs.
	kdcCert [2] IMPLICIT WrapIssuerAndSerial
	OPTIONAL,
	-- Identifies a particular KDC
	-- certificate, if the client
	-- already has it.
	...
	}
	TrustedCA ::= CHOICE {		3.2.1 Client Request
	caName [1] Name,
	-- Fully qualified X.500 name
	-- as defined in RFC 3280 [4].
	issuerAndSerial [2] IMPLICIT WrapIssuerAndSerial,
	-- Identifies a specific CA
	-- certificate.
	...
	}
	AuthPack ::= SEQUENCE {		The initial authentication request (KRB_AS_REQ) is sent as per
	pkAuthenticator [0] PKAuthenticator,		[CLAR]; in addition, a preauthentication field contains data signed
	clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,		by the client's private signature key, as follows:
	-- Defined in RFC 3280 [4].
	-- Present only if the client
	-- is using ephemeral-ephemeral
	-- Diffie-Hellman.
	supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
	OPTIONAL,
	-- List of CMS encryption types
	-- supported by client in order
	-- of (decreasing) preference.
	...
	}
	PKAuthenticator ::= SEQUENCE {		WrapContentInfo ::= OCTET STRING (CONSTRAINED BY {
	cusec [0] INTEGER (0..999999),		-- Contains a BER encoding of ContentInfo.
	ctime [1] KerberosTime,		})
	-- cusec and ctime are used as
	-- in [1], for replay
	-- prevention.
	nonce [2] INTEGER (0..4294967295),
	-- Binds reply to request,
	-- MUST be zero when client
	-- will accept cached
	-- Diffie-Hellman parameters
	-- from KDC. MUST NOT be
	-- zero otherwise.
	paChecksum [3] Checksum,
	-- Defined in [1].
	-- Performed over KDC-REQ-BODY,
	-- MUST be unkeyed.
	...
	}
	The ContentInfo in the signedAuthPack is filled out as follows:		WrapIssuerAndSerial ::= OCTET STRING (CONSTRAINED BY {
			-- Contains a BER encoding of IssuerAndSerialNumber.
			})
	1. The eContent field contains data of type AuthPack. It MUST		PA-PK-AS-REQ ::= SEQUENCE {
	contain the pkAuthenticator, and MAY also contain the		signedAuthPack [0] IMPLICIT WrapContentInfo,
	client's Diffie-Hellman public value (clientPublicValue).		-- Type is SignedData.
			-- Content is AuthPack
			-- (defined below).
			trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,
			-- A list of CAs, trusted by
			-- the client, used to certify
			-- KDCs.
			kdcCert [2] IMPLICIT WrapIssuerAndSerial
			OPTIONAL,
			-- Identifies a particular KDC
			-- certificate, if the client
			-- already has it.
			clientDHNonce [3] DHNonce OPTIONAL,
			...
			}
	2. The eContentType field MUST contain the OID value for		TrustedCA ::= CHOICE {
	id-pkauthdata: { iso(1) org(3) dod(6) internet(1)		caName [1] Name,
	security(5) kerberosv5(2) pkinit(3) pkauthdata(1)}		-- Fully qualified X.500 name
			-- as defined in [RFC3280].
			issuerAndSerial [2] IMPLICIT WrapIssuerAndSerial,
			-- Identifies a specific CA
			-- certificate.
			...
			}
			AuthPack ::= SEQUENCE {
			pkAuthenticator [0] PKAuthenticator,
			clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
			-- Defined in [RFC3280].
			-- Present only if the client
			-- is using ephemeral-ephemeral
			-- Diffie-Hellman.
			supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
			OPTIONAL,
			-- List of CMS encryption types
			-- supported by client in order
			-- of (decreasing) preference.
			...
			}
	3. The signerInfos field MUST contain the signature over the		PKAuthenticator ::= SEQUENCE {
	AuthPack.		cusec [0] INTEGER (0..999999),
			ctime [1] KerberosTime,
			-- cusec and ctime are used as
			-- in [CLAR], for replay
			-- prevention.
			nonce [2] INTEGER (0..4294967295),
			paChecksum [3] OCTET STRING,
			-- Contains the SHA1 checksum,
			-- performed over KDC-REQ-BODY.
			...
			}
	4. The certificates field MUST contain at least a signature		The ContentInfo in the signedAuthPack is filled out as follows:
	verification certificate chain that the KDC can use to
	verify the 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		1. The eContent field contains data of type AuthPack. It MUST
	be chosen from Oakley Group 2 or 14. Implementations MUST		contain the pkAuthenticator, and MAY also contain the client's
	support Group 2; they are RECOMMENDED to support Group 14.		Diffie-Hellman public value (clientPublicValue).
	(See RFC 2409 [10].)
	6. The KDC may wish to use cached Diffie-Hellman parameters.		2. The eContentType field MUST contain the OID value for
	To indicate acceptance of caching, the client sends zero in		id-pkauthdata: { iso(1) org(3) dod(6) internet(1) security(5)
	the nonce field of the pkAuthenticator. Zero is not a valid		kerberosv5(2) pkinit(3) pkauthdata(1) }.
	value for this field under any other circumstances. Since
	zero is used to indicate acceptance of cached parameters,
	message binding in this case is performed using only the
	nonce in the main request.
	3.2.2. Validation of Client Request		3. The signerInfos field MUST contain the signature over the
			AuthPack.
	Upon receiving the client's request, the KDC validates it. This		4. The certificates field MUST contain at least a signature
	section describes the steps that the KDC MUST (unless otherwise		verification certificate chain that the KDC can use to verify the
	noted) take in validating the request.		signature over the AuthPack. The certificate chain(s) MUST NOT
			contain the root CA certificate.
	The KDC must look for a client certificate in the signedAuthPack.		5. If a Diffie-Hellman key is being used, the parameters MUST be
	If it cannot find one signed by a CA it trusts, it sends back an		chosen from Oakley Group 2 or 14. Implementations MUST support
	error of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying		Group 2; they are RECOMMENDED to support Group 14 (See
	e-data for this error is a TYPED-DATA (as defined in [1]). For this		[RFC2409]).
	error, the data-type is TD-TRUSTED-CERTIFIERS, and the data-value is
	the DER encoding of
	TrustedCertifiers ::= SEQUENCE OF Name		6. The client may wish to cache DH parameters or to allow the KDC to
			do so. If so, then the client must include the clientDHNonce
			field. The nonce string needs to be as long as the longest key
			length of the symmetric key types that the client supports. The
			nonce MUST be chosen randomly.
	If, while verifying the certificate chain, the KDC determines that		3.2.2 Validation of Client Request
	the signature on one of the certificates in the signedAuthPack is
	invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE.
	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
	encoding of the index into the CertificateSet field, ordered as sent
	by the client:
	CertificateIndex ::= IssuerAndSerialNumber		Upon receiving the client's request, the KDC validates it. This
	-- IssuerAndSerialNumber of		section describes the steps that the KDC MUST (unless otherwise
	-- certificate with invalid signature		noted) take in validating the request.
	If more than one certificate signature is invalid, the KDC MAY send		The KDC must look for a client certificate in the signedAuthPack. If
	one TYPED-DATA per invalid signature.		it cannot find one signed by a CA it trusts, 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
	The KDC MAY also check whether any certificates in the client's		TrustedCertifiers ::= SEQUENCE OF Name
	chain have been revoked. If any of them have been revoked, the KDC
	MUST return an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC
	attempts to determine the revocation status but is unable to do so,
	it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN.
	The certificate or certificates affected are identified exactly as
	for an error of type KDC_ERR_INVALID_CERTIFICATE (see above).
	In addition to validating the certificate chain, the KDC MUST also		If, while verifying the certificate chain, the KDC determines that
	check that the certificate properly maps to the client's principal name		the signature on one of the certificates in the signedAuthPack is
	as specified in the AS-REQ as follows:		invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE.
			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
			encoding of the index into the CertificateSet field, ordered as sent
			by the client:
	1. If the KDC has its own mapping from the name in the		CertificateIndex ::= IssuerAndSerialNumber
	certificate to a Kerberos name, it uses that Kerberos		-- IssuerAndSerialNumber of
	name.		-- certificate with invalid signature.
	2. Otherwise, if the certificate contains a SubjectAltName		If more than one certificate signature is invalid, the KDC MAY send
	extension with a Kerberos name in the otherName field,		one TYPED-DATA per invalid signature.
	it uses that name. The otherName field (of type AnotherName)
	in the SubjectAltName extension MUST contain the following:
	The type-id is:		The KDC MAY also check whether any certificates in the client's chain
			have been revoked. If any of them have been revoked, the KDC MUST
			return an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC
			attempts to determine the revocation status but is unable to do so,
			it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN.
	krb5PrincipalName OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6)		The certificate or certificates affected are identified exactly as
	internet (1) security (5) kerberosv5 (2) 2 }		for an error of type KDC_ERR_INVALID_CERTIFICATE (see above).
	The value is:		In addition to validating the certificate chain, the KDC MUST also
			check that the certificate properly maps to the client's principal
			name as specified in the KRB_AS_REQ as follows:
	KRB5PrincipalName ::= SEQUENCE {		1. If the KDC has its own mapping from the name in the certificate
	realm [0] Realm,		to a Kerberos name, it uses that Kerberos name.
	principalName [1] PrincipalName
	}
	If the KDC does not have its own mapping and there is no Kerberos		2. Otherwise, if the certificate contains a SubjectAltName extension
	name present in the certificate, or if the name in the request does		with a Kerberos name in the otherName field, it uses that name.
	not match the name in the certificate (including the realm name), or
	if there is no name in the request, the KDC MUST return error code
	KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data
	for this error.
	Even if the chain is validated, and the names in the certificate and		The otherName field (of type AnotherName) in the SubjectAltName
	the request match, the KDC may decide not to trust the client. For		extension MUST contain krb5PrincipalName as defined below.
	example, the certificate may include an Extended Key Usage (EKU) OID
	in the extensions field. 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. In this case, the KDC MUST return error code
	KDC_ERR_CLIENT_NOT_TRUSTED. The PKINIT EKU OID is defined as:
	{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)		The type-id is:
	pkinit(3) pkekuoid(4) }
	If the client's signature on the signedAuthPack fails to verify, the KDC		krb5PrincipalName OBJECT IDENTIFIER ::= iso (1) org (3) dod (6)
	MUST return error KDC_ERR_INVALID_SIG. There is no accompanying		internet (1) security (5) kerberosv5 (2) 2
	e-data for this error.
	The KDC MUST check the timestamp to ensure that the request is not		The value is the DER encoding of the following ASN.1 type:
	a replay, and that the time skew falls within acceptable limits.
	The recommendations clock skew times in [1] apply here. If the
	check fails, the KDC MUSTreturn error code KRB_AP_ERR_REPEAT or
	KRB_AP_ERR_SKEW, respectively.
	If the clientPublicValue is filled in, indicating that the client		KRB5PrincipalName ::= SEQUENCE {
	wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC checks to		realm [0] Realm,
	see if the parameters satisfy its policy. If they do not, it MUST		principalName [1] PrincipalName
	return error code KDC_ERR_KEY_SIZE. The accompanying e-data is a		}
	TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and whose
	data-value is the DER encoding of a DomainParameters (see [3]),
	including appropriate Diffie-Hellman parameters with which to retry
	the request.
	The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the		If the KDC does not have its own mapping and there is no Kerberos
	client included a kdcCert field in the PA-PK-AS-REQ and the KDC does		name present in the certificate, or if the name in the request does
	not have the corresponding certificate.		not match the name in the certificate (including the realm name), or
			if there is no name in the request, the KDC MUST return error code
			KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for
			this error.
	The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client		Even if the certificate chain is validated, and the names in the
	did not include a kdcCert field, but did include a trustedCertifiers		certificate and the request match, the KDC may decide to reject
	field, and the KDC does not possesses a certificate issued by one of		requests on the basis of the absence or presence of specific EKU
	the listed certifiers.		OIDs. For example, the certificate may include an Extended Key Usage
			(EKU) OID of id-pkekuoid in the extensions field:
	If there is a supportedCMSTypes field in the AuthPack, the KDC must		{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
	check to see if it supports any of the listed types. If it supports		pkinit(3) pkekuoid(4) }
	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
	KRB5KDC_ERR_ETYPE_NOSUPP.
	3.2.3. KDC Reply		The KDC MUST return the error code KDC_ERR_CLIENT_NOT_TRUSTED if the
			client's cerficate is not accepted.
	Assuming that the client's request has been properly validated, the		If the client's signature on the signedAuthPack fails to verify, the
	KDC proceeds as per [1], except as follows.		KDC MUST return error KDC_ERR_INVALID_SIG. There is no accompanying
			e-data for this error.
	The KDC MUST set the initial flag and include an authorization data		The KDC MUST check the timestamp to ensure that the request is not a
	of type AD-INITIAL-VERIFIED-CAS in the issued ticket. The value is		replay, and that the time skew falls within acceptable limits. The
	an OCTET STRING containing the DER encoding of InitialVerifiedCAs:		recommendations clock skew times in [CLAR] apply here. If the check
			fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
			KRB_AP_ERR_SKEW, respectively.
	InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {		If the clientPublicValue is filled in, indicating that the client
	ca [0] Name,		wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC checks to
	Validated [1] BOOLEAN,		see if the parameters satisfy its policy. If they do not, it MUST
	...		return error code KDC_ERR_KEY_SIZE. The accompanying e-data is a
	}		TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and whose data-value
			is the DER encoding of a DomainParameters (see [RFC3279]), including
			appropriate Diffie-Hellman parameters with which to retry the
			request.
	The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT		The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the
	containers if the list of CAs satisfies the KDC's realm's policy.		client included a kdcCert field in the PA-PK-AS-REQ and the KDC does
	(This corresponds to the TRANSITED-POLICY-CHECKED ticket flag.)		not have the corresponding certificate.
	Furthermore, any TGS must copy such authorization data from tickets
	used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket,
	including the AD-IF-RELEVANT container, if present.
	Application servers that understand this authorization data type		The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client
	SHOULD apply local policy to determine whether a given ticket		did not include a kdcCert field, but did include a trustedCertifiers
	bearing such a type *not* contained within an AD-IF-RELEVANT		field, and the KDC does not possesses a certificate issued by one of
	container is acceptable. (This corresponds to the AP server		the listed certifiers.
	checking the transited field when the TRANSITED-POLICY-CHECKED flag
	has not been set.) If such a data type is contained within an
	AD-IF-RELEVANT container, AP servers MAY apply local policy to
	determine whether the authorization data is acceptable.
	The AS-REP is otherwise unchanged from [1]. The KDC encrypts the		If there is a supportedCMSTypes field in the AuthPack, the KDC must
	reply as usual, but not with the client's long-term key. Instead,		check to see if it supports any of the listed types. If it supports
	it encrypts it with either a generated encryption key, or a key		more than one of the types, the KDC SHOULD use the one listed first.
	derived from a Diffie-Hellman exchange. The contents of the		If it does not support any of them, it MUST return an error of type
	PA-PK-AS-REP indicate the type of encryption key that was used:		KRB5KDC_ERR_ETYPE_NOSUPP.
	PA-PK-AS-REP ::= CHOICE {		3.2.3 KDC Reply
	dhSignedData [0] IMPLICIT WrapContentInfo,
	-- Type is SignedData.
	-- Content is KDCDHKeyInfo
	-- (defined below).
	encKeyPack [1] IMPLICIT WrapContentInfo,
	-- Type is EnvelopedData.
	-- Content is SignedData over
	-- ReplyKeyPack (defined below).
	...
	}
	KDCDHKeyInfo ::= SEQUENCE {		Assuming that the client's request has been properly validated, the
	subjectPublicKey [0] BIT STRING,		KDC proceeds as per [CLAR], except as follows.
	-- Equals public exponent
	-- (g^a mod p).
	-- INTEGER encoded as payload
	-- of BIT STRING.
	nonce [1] INTEGER (0..4294967295),
	-- Binds reply to request.
	-- Exception: A value of zero
	-- indicates that the KDC is
	-- using cached values.
	dhKeyExpiration [2] KerberosTime OPTIONAL,
	-- Expiration time for KDC's
	-- cached values.
	...
	}
	The fields of the ContentInfo for dhSignedData are to be filled in		The KDC MUST set the initial flag and include an authorization data
	as follows:		of type AD-INITIAL-VERIFIED-CAS in the issued ticket. The value is
			an OCTET STRING containing the DER encoding of InitialVerifiedCAs:
	1. The eContent field contains data of type KDCDHKeyInfo.		InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
			ca [0] Name,
			Validated [1] BOOLEAN,
			...
			}
	2. The eContentType field contains the OID value for		The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
	id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)		containers if the list of CAs satisfies the KDC's realm's policy
	security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }		(this corresponds to the TRANSITED-POLICY-CHECKED ticket flag).
			Furthermore, any TGS must copy such authorization data from tickets
			used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket,
			including the AD-IF-RELEVANT container, if present.
	3. The signerInfos field contains a single signerInfo, which is		Application servers that understand this authorization data type
	the signature of the KDCDHKeyInfo.		SHOULD apply local policy to determine whether a given ticket bearing
			such a type *not* contained within an AD-IF-RELEVANT container is
			acceptable. (This corresponds to the AP server checking the
			transited field when the TRANSITED-POLICY-CHECKED flag has not been
			set.) If such a data type is contained within an AD-IF-RELEVANT
			container, AP servers MAY apply local policy to determine whether the
			authorization data is acceptable.
	4. The certificates field contains a signature verification		The KRB_AS_REP is otherwise unchanged from [CLAR]. The KDC encrypts
	certificate chain that the client will use to verify the		the reply as usual, but not with the client's long-term key.
	KDC's signature over the KDCDHKeyInfo. This field may only		Instead, it encrypts it with either a generated encryption key, or a
	be left empty if the client did include a kdcCert field in		key derived from a Diffie-Hellman exchange. The contents of the
	the PA-PK-AS-REQ, indicating that it has the KDC's		PA-PK-AS-REP indicate the type of encryption key that was used:
	certificate. The certificate chain MUST NOT contain the
	root CA certificate.
	5. If the client and KDC agree to use cached parameters, the		PA-PK-AS-REP ::= CHOICE {
	KDC MUST return a zero in the nonce field and include the		dhInfo [0] DHRepInfo,
	expiration time of the cached values in the dhKeyExpiration		encKeyPack [1] IMPLICIT WrapContentInfo,
	field. If this time is exceeded, the client MUST NOT use		-- Type is EnvelopedData.
	the reply. If the time is absent, the client MUST NOT use		-- Content is SignedData over
	the reply and MAY resubmit a request with a non-zero nonce,		-- ReplyKeyPack (defined below).
	thus indicating non-acceptance of the cached parameters.		...
			}
	The KDC reply key is derived as follows:		DHRepInfo ::= SEQUENCE {
			dhSignedData [0] ContentInfo,
			-- Type is SignedData.
			-- Content is KDCDHKeyInfo
			-- (defined below).
			serverDHNonce [1] DHNonce OPTIONAL
			}
	1. Both the KDC and the client calculate the shared secret		KDCDHKeyInfo ::= SEQUENCE {
	value		subjectPublicKey [0] BIT STRING,
			-- Equals public exponent
			-- (g^a mod p).
			-- INTEGER encoded as payload
			-- of BIT STRING.
			nonce [1] INTEGER (0..4294967295),
			dhKeyExpiration [2] KerberosTime OPTIONAL,
			-- Expiration time for KDC's
			-- cached values. If this field
			-- is omitted then the
			-- serverDHNonce field MUST also
			-- be omitted.
			...
			}
	DHKey = g^(ab) mod p		The fields of the ContentInfo for dhSignedData are to be filled in as
			follows:
	where a and b are the client's and KDC's private exponents,		1. The eContent field contains data of type KDCDHKeyInfo.
	respectively. DHKey, padded first with leading zeros as
	needed to 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 is the size of the modulus p).
	2. Let K be the key-generation seed length [6] of the reply key		2. The eContentType field contains the OID value for id-pkdhkeydata:
	whose enctype is selected according to [1].		{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
			pkinit(3) pkdhkeydata(2) }.
	3. Define the function octetstring2key() as follows:		3. The signerInfos field contains a single signerInfo, which is the
			signature of the KDCDHKeyInfo.
	octetstring2key(h, x) == random-to-key(K-truncate(		4. The certificates field contains a signature verification
	h(0x00 | x) |		certificate chain that the client will use to verify the KDC's
	h(0x01 | x) |		signature over the KDCDHKeyInfo. This field may only be left
	h(0x02 | x) |		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.
	where x is an octet string; h:octet string -> octet string		5. If the client included the clientDHNonce field, then the KDC may
	is a cryptographically strong hash function; | is the		choose to reuse its DH parameters. If the server reuses DH
	concatenation operator; 0x00, 0x01, 0x02, etc. are each		parameters then it MUST include an expiration time in the
	represented as a single octet; random-to-key() is an		dhKeyExperiation field. Past the point of the expiration time,
	operation that generates a protocolkey from a bitstring of		the signature of the DHRepInfo is considered invalid. When the
	length K; and K-truncate truncates its input to K bits.		server reuses DH parameters then it MUST include a serverDHNonce
	Both K and random-to-key() are defined in the kcrypto		at least as long as the length of keys for the symmetric
	profile [6] for the enctype of the reply key.		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.
	A good example of h() is SHA1.		If the Diffie-Hellman key exchange is used, the KDC reply key [CLAR]
			is derived as follows:
	4. Define H to be a hash function based on operations of a		1. Both the KDC and the client calculate the shared secret value
	given checksum type [6], as follows:
	H(x) = get_mic(dummy-key, x)		DHKey = g^(ab) mod p
	where x is an octet string.		where a and b are the client's and KDC's private exponents,
			respectively. DHKey, padded first with leading zeros as needed to
			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
			is the size of the modulus p).
	H() MUST be a cryptographically strong hash, in order to be		2. Let K be the key-generation seed length [KCRYPTO] of the reply
	suitable for use in the octetstring2key() operation above.		key whose enctype is selected according to [CLAR].
	5. The client specifies a checksum type to use in the		3. Define the function octetstring2key() as follows:
	paChecksum of the PKAuthenticator. If the H() operation
	based on this checksum is not suitable for use in
	octetstring2key(), or this checksum type is too weak or not
	supported by the KDC, the KDC MUST return an error of type
	KDC_ERR_PA_CKSUMTYPE_NOT_SUPPORTED. The accompanying e-data
	for this error is a TYPED-DATA: the data-type is
	TD-UNKEYED-CHECKSUM-INFO, and the data-value is the DER
	encoding of
	UNKEYED-CHECKSUM-INFO ::= SEQUENCE OF SEQUENCE {		octetstring2key(x) == random-to-key(K-truncate(
	cksumtype [0] Int32,		SHA1(0x00 | x) |
	...		SHA1(0x01 | x) |
	}		SHA1(0x02 | x) |
			...
			))
	This list is in the preference order (best choice first) of		where x is an octet string; | is the concatenation operator; 0x00,
	the KDC, and the client SHOULD retry with the first		0x01, 0x02, etc., are each represented as a single octet;
	available checksum type.		random-to-key() is an operation that generates a protocolkey from
			a bitstring of length K; and K-truncate truncates its input to K
			bits. Both K and random-to-key() are defined in the kcrypto
			profile [KCRYPTO] for the enctype of the reply key.
	6. When cached DH parameters are used, let n_c be the		4. When cached DH parameters are used, let n_c be the clientDHNonce,
	clientDHNonce, and n_k be the serverDHNonce; otherwise, let		and n_k be the serverDHNonce; otherwise, let both n_c and n_k be
	both n_c and n_k be empty octet strings. The reply key k is		empty octet strings.
	k = octetstring2key(H, DHKey | n_c | n_k)		5. The KDC reply key k is:
	where H() is the hash function based on the checksum type		k = octetstring2key(DHKey | n_c | n_k)
	used in the paChecksum of the PKAuthenticator (as defined in
	step 4).
	Both the KDC and the client calculate		If the Diffie-Hellman key exchange is not used, the KDC reply key
	the value g^(ab) mod p, where a and b are the client's and KDC's		[CLAR] is encrypted in the encKeyPack, which contains data of type
	private exponents, respectively. They both take the first k bits of		ReplyKeyPack:
	this secret value as a key generation seed, where the parameter k
	(the size of the seed) is dependent on the selected key type, as
	specified in [6]. The seed is then converted into a protocol key by
	applying to it a random-to-key function, which is also dependent on
	key type.
	If the KDC and client are not using Diffie-Hellman, the KDC encrypts		ReplyKeyPack ::= SEQUENCE {
	the reply with an encryption key, packed in the encKeyPack, which		replyKey [0] EncryptionKey,
	contains data of type ReplyKeyPack:		-- Defined in [CLAR].
			-- Used to encrypt main reply.
			-- 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),
			-- Contains the nonce in
			-- the KDCDHKeyInfo.
			...
			}
	ReplyKeyPack ::= SEQUENCE {		The fields of the ContentInfo for encKeyPack MUST be filled in as
	replyKey [0] EncryptionKey,		follows:
	-- Defined in [1].
	-- Used to encrypt main reply.
	-- 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),
	-- Binds reply to request.
	...
	}
	The fields of the ContentInfo for encKeyPack MUST be filled in as		1. The content is of type SignedData. The eContent for the
	follows:		SignedData is of type ReplyKeyPack.
	1. The content is of type SignedData. The eContent for		2. The eContentType for the SignedData contains the OID value for
	the SignedData is of type ReplyKeyPack.		id-pkrkeydata: { iso(1) org(3) dod(6) internet(1) security(5)
			kerberosv5(2) pkinit(3) pkrkeydata(3) }.
	2. The eContentType for the SignedData contains the OID value		3. The signerInfos field contains a single signerInfo, which is the
	for id-pkrkeydata: { iso(1) org(3) dod(6) internet(1)		signature of the ReplyKeyPack.
	security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }
	3. The signerInfos field contains a single signerInfo, which is		4. The certificates field contains a signature verification
	the signature of the ReplyKeyPack.		certificate chain that the client will use to verify the KDC's
			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.
	4. The certificates field contains a signature verification		5. The contentType for the EnvelopedData contains the OID value for
	certificate chain that the client will use to verify the		id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
	KDC's signature over the ReplyKeyPack. This field may only		pkcs (1) pkcs7 (7) signedData (2) }.
	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		6. The recipientInfos field is a SET which MUST contain exactly one
	for id-signedData: { iso (1) member-body (2) us (840) rsadsi		member of type KeyTransRecipientInfo. The encryptedKey for this
	(113549) pkcs (1) pkcs7 (7) signedData (2) }		member contains the temporary key which is encrypted using the
			client's public key.
	6. The recipientInfos field is a SET which MUST contain exactly		7. The unprotectedAttrs or originatorInfo fields MAY be present.
	one member of type KeyTransRecipientInfo. The encryptedKey
	for this member contains the temporary key which is
	encrypted using the client's public key.
	7. The unprotectedAttrs or originatorInfo fields MAY be		3.2.4 Validation of KDC Reply
	present.
	3.2.4. Validation of KDC Reply		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
			verifies the Diffie-Hellman parameters, and obtains the shared key as
			described above. Otherwise, the message contains an encKeyPack, and
			the client decrypts and verifies the temporary encryption key.
	Upon receipt of the KDC's reply, the client proceeds as follows. If		In either case, the client MUST check to see if the included
	the PA-PK-AS-REP contains a dhSignedData, the client obtains and		certificate contains a subjectAltName extension of type dNSName or
	verifies the Diffie-Hellman parameters, and obtains the shared key		iPAddress (if the KDC is specified by IP address instead of name).
	as described above. Otherwise, the message contains an encKeyPack,		If it does, it MUST check to see if that extension matches the KDC it
	and the client decrypts and verifies the temporary encryption key.		believes it is communicating with, with matching rules specified in
			RFC 2459. Exception: If the client has some external information as
			to the identity of the KDC, this check MAY be omitted.
	In either case, the client MUST check to see if the included		The client also MUST check that the KDC's certificate contains an
	certificate contains a subjectAltName extension of type dNSName or		extendedKeyUsage OID of id-pkkdcekuoid:
	iPAddress (if the KDC is specified by IP address instead of name).
	If it does, it MUST check to see if that extension matches the KDC
	it believes it is communicating with, with matching rules specified
	in RFC 2459. Exception: If the client has some external information
	as to the identity of the KDC, this check MAY be omitted.
	The client also MUST check that the KDC's certificate contains an		{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
	extendedKeyUsage OID of id-pkkdcekuoid:		pkinit(3) pkkdcekuoid(5) }
	{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)		If all applicable checks are satisfied, the client then decrypts the
	pkinit(3) pkkdcekuoid(5) }		main reply with the resulting key, and then proceeds as described in
			[1].
	If all applicable checks are satisfied, the client then decrypts the		3.3 KDC Indication of PKINIT Support
	main reply with the resulting key, and then proceeds as described in
	[1].
	4. Security Considerations		If pre-authentication is required, but was not present in the
			request, per [CLAR] an error message with the code
			KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
			stored in the e-data field of the KRB-ERROR message to specify which
			pre-authentication mechanisms are acceptable. The KDC can then
			indicate the support of PKINIT by including a PA-PK-AS-REQ element in
			that METHOD-DATA object.
	PKINIT raises certain security considerations beyond those that can		Otherwise if it is required by the KDC's local policy that the client
	be regulated strictly in protocol definitions. We will address them		must be pre-authenticated using the preauthentication mechanism
	in this section.		specified in this document, but no PKINIT pre-authentication was
			present in the request, an error message with the code
			KDC_ERR_PREAUTH_FAILED SHOULD be returned.
	PKINIT extends the cross-realm model to the public-key		The padata-value for the PA-PK-AS-REQ entry in the METHOD-DATA object
	infrastructure. Users of PKINIT must understand security policies		is an empty octet string and SHOULD be ignored otherwise.
	and procedures appropriate to the use of Public Key Infrastructures.
	Standard Kerberos allows the possibility of interactions between		4. Security Considerations
	cryptosystems of varying strengths; this document adds interactions
	with public-key cryptosystems to Kerberos. Some administrative
	policies may allow the use of relatively weak public keys. Using
	such keys to wrap data encrypted under stronger conventional
	cryptosystems may be inappropriate.
	PKINIT requires keys for symmetric cryptosystems to be generated.		PKINIT raises certain security considerations beyond those that can
	Some such systems contain "weak" keys. For recommendations regarding		be regulated strictly in protocol definitions. We will address them
	these weak keys, see [1].		in this section.
	PKINIT allows the use of a zero nonce in the PKAuthenticator when		PKINIT extends the cross-realm model to the public-key
	cached Diffie-Hellman keys are used. In this case, message binding		infrastructure. Users of PKINIT must understand security policies
	is performed using the nonce in the main request in the same way as		and procedures appropriate to the use of Public Key Infrastructures.
	it is done for ordinary AS-REQs (without the PKINIT
	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 AS-REP has a		Standard Kerberos allows the possibility of interactions between
	zero-nonce, and an attacker has somehow recorded this		cryptosystems of varying strengths; this document adds interactions
	pre-authenticator and discovered the corresponding Diffie-Hellman		with public-key cryptosystems to Kerberos. Some administrative
	private key (e.g., with a brute-force attack), the attacker will be		policies may allow the use of relatively weak public keys. Using
	able to fabricate his own AS-REP messages that impersonate the KDC		such keys to wrap data encrypted under stronger conventional
	with this same pre-authenticator. This compromised pre-authenticator		cryptosystems may be inappropriate.
	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.
	If a client also caches its Diffie-Hellman keys, then the session key		PKINIT requires keys for symmetric cryptosystems to be generated.
	could remain the same during multiple AS-REQ/AS-REP exchanges and an		Some such systems contain "weak" keys. For recommendations regarding
	attacker which compromised the session key could fabricate his own		these weak keys, see [CLAR].
	AS-REP messages with a pre-recorded pre-authenticator until the
	client starts using a new Diffie-Hellman key pair and while the KDC
	pre-authenticator has not yet expired. It is therefore not
	recommended for KDC clients to also cache their Diffie-Hellman keys.
	Care should be taken in how certificates are chosen for the purposes		PKINIT allows the use of a zero nonce in the PKAuthenticator when
	of authentication using PKINIT. Some local policies may require		cached Diffie-Hellman keys are used. In this case, message binding
	that key escrow be used for certain certificate types. Deployers of		is performed using the nonce in the main request in the same way as
	PKINIT should be aware of the implications of using certificates that		it is done for ordinary KRB_AS_REQs (without the PKINIT
	have escrowed keys for the purposes of authentication.		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.
	PKINIT does not provide for a "return routability" test to prevent		However, when a PKINIT pre-authenticator in the KRB_AS_REP has a
	attackers from mounting a denial-of-service attack on the KDC by		zero-nonce, and an attacker has somehow recorded this
	causing it to perform unnecessary and expensive public-key		pre-authenticator and discovered the corresponding Diffie-Hellman
	operations. Strictly speaking, this is also true of standard		private key (e.g., with a brute-force attack), the attacker will be
	Kerberos, although the potential cost is not as great, because		able to fabricate his own KRB_AS_REP messages that impersonate the
	standard Kerberos does not make use of public-key cryptography.		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.
	The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does		Care should be taken in how certificates are chosen for the purposes
	permit empty SEQUENCEs to be encoded. Such empty sequences may only		of authentication using PKINIT. Some local policies may require that
	be used if the KDC itself vouches for the user's certificate. [This		key escrow be used for certain certificate types. Deployers of
	seems to reflect the consensus of the Kerberos working group.]		PKINIT should be aware of the implications of using certificates that
			have escrowed keys for the purposes of authentication.
			PKINIT does not provide for a "return routability" test to prevent
			attackers from mounting a denial-of-service attack on the KDC by
			causing it to perform unnecessary and expensive public-key
			operations. Strictly speaking, this is also true of standard
			Kerberos, although the potential cost is not as great, because
			standard Kerberos does not make use of public-key cryptography.
			The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
			permit empty SEQUENCEs to be encoded. Such empty sequences may only
			be used if the KDC itself vouches for the user's certificate. [This
			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: Ari Medvinsky, Matt Hur, John Wray, Jonathan Trostle, Nicolas		draft: Paul Leach, Sam Hartman, Love Hornquist Astrand, Ken Raeburn,
	Williams, Tom Yu, Sam Hartman, and Jeff Hutzelman.		Nicolas Williams, John Wray, Jonathan Trostle, Tom Yu and Jeff
			Hutzelman.
	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. Lastly, comments from groups working on similar ideas
	in DCE have been invaluable.		in DCE have been invaluable.
	6. Expiration Date		6. IANA Considerations
	This draft expires January 25, 2004.		This document has no actions for IANA.
	7. Bibliography		7 Normative References
	[1] RFC-Editor: To be replaced by RFC number for		[CLAR] Neuman, B., Yu, Y., Hartman, S. and K. Raeburn, "The
	draft-ietf-krb-wg-kerberos-clarifications.		Kerberos Network Authentication Service (V5)",
			draft-ietf-krb-wg-kerberos-clarifications, work in
			progress.
	[2] R. Housley. Cryptographic Message Syntax. April 1999. Request		[FIPS74] NIST, Guidelines for Implementing and Using
	For Comments 2630.		the NBS Encryption Standard, April 1981. FIPS PUB 74.
	[3] W. Polk, R. Housley, and L. Bassham. Algorithms and Identifiers		[KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for
	for the Internet X.509 Public Key Infrastructure Certificate and		Kerberos 5", December 2004.
	Certificate Revocation List (CRL) Profile, April 2002. Request For
	Comments 3279.
	[4] R. Housley, W. Polk, W. Ford, D. Solo. Internet X.509 Public		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Key Infrastructure Certificate and Certificate Revocation List		Requirement Levels", BCP 14, RFC 2119, March 1997.
	(CRL) Profile, April 2002. Request for Comments 3280.
	[5] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography		[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
	Specifications, October 1998. Request for Comments 2437.		(IKE)", RFC 2409, November 1998.
	[6] RFC-Editor: To be replaced by RFC number for		[RFC2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
	draft-ietf-krb-wg-crypto.		Specifications Version 2.0", RFC 2437, October 1998.
	[7] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and		[RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630,
	T. Wright. Transport Layer Security (TLS) Extensions, June 2003.		June 1999.
	Request for Comments 3546.
	[8] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams.		[RFC3279] Bassham, L., Polk, W. and R. Housley, "Algorithms and
	Internet X.509 Public Key Infrastructure: Online Certificate Status		Identifiers for the Internet X.509 Public Key
	Protocol - OCSP, June 1999. Request for Comments 2560.		Infrastructure Certificate and Certificate Revocation List
			(CRL) Profile", RFC 3279, April 2002.
	[9] NIST, Guidelines for Implementing and Using the NBS Encryption		[RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
	Standard, April 1981. FIPS PUB 74.		X.509 Public Key Infrastructure Certificate and
			Certificate Revocation List (CRL) Profile", RFC 3280,
			April 2002.
	[10] D. Harkins and D. Carrel. The Internet Key Exchange (IKE),		[X690] ASN.1 encoding rules: Specification of Basic
	November 1998. Request for Comments 2409.		Encoding Rules (BER), Canonical Encoding Rules (CER) and
			Distinguished Encoding Rules (DER), ITU-T Recommendation
			X.690 (1997) | ISO/IEC International Standard
			8825-1:1998.
	[11] K. Raeburn. Unkeyed SHA-1 Checksum Specification for Kerberos		Authors' Addresses
	5. Internet-Draft, draft-ietf-krb-wg-sha1-00.txt.
	[12] S. Bradner. Key Words for Use in RFCs to Indicate Requirement		Brian Tung
	Levels. March 1997. Request for Comments 2119 (BCP 14).		USC Information Sciences Institute
			4676 Admiralty Way Suite 1001, Marina del Rey CA
			Marina del Rey, CA 90292
			US
	8. Authors		EMail: brian@isi.edu
	Brian Tung		Clifford Neuman
	Clifford Neuman		USC Information Sciences Institute
	USC Information Sciences Institute		4676 Admiralty Way Suite 1001, Marina del Rey CA
	4676 Admiralty Way Suite 1001		Marina del Rey, CA 90292
	Marina del Rey CA 90292-6695		US
	Phone: +1 310 822 1511
	E-mail: {brian,bcn}@isi.edu
	Matthew Hur		EMail: brian@isi.edu
	Ari Medvinsky
	Microsoft Corporation
	One Microsoft Way
	Redmond WA 98052
	Phone: +1 425 707 3336
	E-mail: matthur@microsoft.com, arimed@windows.microsoft.com
	Sasha Medvinsky		Larry Zhu
	Motorola, Inc.		Microsoft Corporation
	6450 Sequence Drive		One Microsoft Way
	San Diego, CA 92121		Redmond, WA 98052
	+1 858 404 2367		US
	E-mail: smedvinsky@motorola.com
	John Wray		EMail: lzhu@microsoft.com
	Iris Associates, Inc.
	5 Technology Park Dr.
	Westford, MA 01886
	E-mail: John_Wray@iris.com
	Jonathan Trostle		Matt Hur
	E-mail: jtrostle@world.std.com		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(TBD)		security(5) kerberosV5(2) modules(4) pkinit(3)
	} DEFINITIONS EXPLICIT TAGS ::= BEGIN		} DEFINITIONS EXPLICIT TAGS ::= BEGIN
	IMPORTS		IMPORTS
	SubjectPublicKeyInfo, AlgorithmIdentifier, Name		SubjectPublicKeyInfo, AlgorithmIdentifier, Name
	FROM PKIX1Explicit88 { iso (1) identified-organization (3)		FROM PKIX1Explicit88 { iso (1)
	dod (6) internet (1) security (5) mechanisms (5)		identified-organization (3) dod (6) internet (1)
	pkix (7) id-mod (0) id-pkix1-explicit (18) }		security (5) mechanisms (5) pkix (7) id-mod (0)
			id-pkix1-explicit (18) }
	ContentInfo, IssuerAndSerialNumber		ContentInfo, IssuerAndSerialNumber
	FROM CryptographicMessageSyntax { iso(1) member-body(2)		FROM CryptographicMessageSyntax { iso(1) member-body(2)
	us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)		us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
	modules(0) cms(1) }		modules(0) cms(1) }
	KerberosTime, Checksum, 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) modules(4)		dod(6) internet(1) security(5) kerberosV5(2)
	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-pkdhkeydata 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 ::= TBD		pa-pk-as-req INTEGER ::= 16
	pa-pk-as-rep INTEGER ::= TBD		pa-pk-as-rep INTEGER ::= 17
	pa-pk-ocsp-req INTEGER ::= TBD
	pa-pk-ocsp-rep INTEGER ::= TBD
	ad-initial-verified-cas INTEGER ::= TBD		ad-initial-verified-cas INTEGER ::= 9
	td-dh-parameters INTEGER ::= TBD		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
			WrapContentInfo ::= OCTET STRING (CONSTRAINED BY {
			-- Contains a BER encoding of ContentInfo.
			})
	WrapContentInfo ::= OCTET STRING (CONSTRAINED BY {		WrapIssuerAndSerial ::= OCTET STRING (CONSTRAINED BY {
	-- Contains a BER encoding of		-- Contains a BER encoding of IssuerAndSerialNumber.
	-- ContentInfo		})
	})
	WrapIssuerAndSerial ::= OCTET STRING (CONSTRAINED BY {		PA-PK-AS-REQ ::= SEQUENCE {
	-- Contains a BER encoding of		signedAuthPack [0] IMPLICIT WrapContentInfo,
	-- IssuerAndSerialNumber		-- Type is SignedData.
	})		-- Content is AuthPack
			-- (defined below).
			trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,
			-- A list of CAs, trusted by
			-- the client, used to certify
			-- KDCs.
			kdcCert [2] IMPLICIT WrapIssuerAndSerial
			OPTIONAL,
			-- Identifies a particular KDC
			-- certificate, if the client
			-- already has it.
			clientDHNonce [3] DHNonce OPTIONAL,
			...
			}
	PA-PK-AS-REQ ::= SEQUENCE {		TrustedCA ::= CHOICE {
	signedAuthPack [0] IMPLICIT WrapContentInfo,		caName [1] Name,
	trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,		-- Fully qualified X.500 name
	kdcCert [2] IMPLICIT WrapIssuerAndSerial		-- as defined in [RFC3280].
	OPTIONAL,		issuerAndSerial [2] IMPLICIT WrapIssuerAndSerial,
	...		-- Identifies a specific CA
	}		-- certificate.
			...
			}
	TrustedCA ::= CHOICE {		AuthPack ::= SEQUENCE {
	caName [1] Name,		pkAuthenticator [0] PKAuthenticator,
	issuerAndSerial [2] IMPLICIT WrapIssuerAndSerial,		clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
	...		-- Defined in [RFC3280].
	}		-- Present only if the client
			-- is using ephemeral-ephemeral
			-- Diffie-Hellman.
			supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
			OPTIONAL,
			-- List of CMS encryption types
			-- supported by client in order
			-- of (decreasing) preference.
			...
			}
	AuthPack ::= SEQUENCE {		PKAuthenticator ::= SEQUENCE {
	pkAuthenticator [0] PKAuthenticator,		cusec [0] INTEGER (0..999999),
	clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,		ctime [1] KerberosTime,
	supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier		-- cusec and ctime are used as
	OPTIONAL,		-- in [CLAR], for replay
	...		-- prevention.
	}		nonce [2] INTEGER (0..4294967295),
			paChecksum [3] OCTET STRING,
			-- Contains the SHA1 checksum,
			-- performed over KDC-REQ-BODY.
			...
			}
	PKAuthenticator ::= SEQUENCE {		TrustedCertifiers ::= SEQUENCE OF Name
	cusec [0] INTEGER (0..999999),
	ctime [1] KerberosTime,
	nonce [2] INTEGER (0..4294967295),
	paChecksum [3] Checksum,
	...
	}
	TrustedCertifiers ::= SEQUENCE OF Name		CertificateIndex ::= IssuerAndSerialNumber
	CertificateIndex ::= IssuerAndSerialNumber		KRB5PrincipalName ::= SEQUENCE {
			realm [0] Realm,
			principalName [1] PrincipalName
			}
	KRB5PrincipalName ::= SEQUENCE {		InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
	realm [0] Realm,		ca [0] Name,
	principalName [1] PrincipalName		Validated [1] BOOLEAN,
	}		...
			}
	InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {		PA-PK-AS-REP ::= CHOICE {
	ca [0] Name,		dhInfo [0] DHRepInfo,
	validated [1] BOOLEAN,		encKeyPack [1] IMPLICIT WrapContentInfo,
	...		-- Type is EnvelopedData.
	}		-- Content is SignedData over
			-- ReplyKeyPack (defined below).
			...
	PA-PK-AS-REP ::= CHOICE {		}
	dhSignedData [0] IMPLICIT WrapContentInfo,
	encKeyPack [1] IMPLICIT WrapContentInfo,
	...
	}
	KDCDHKeyInfo ::= SEQUENCE {		DHRepInfo ::= SEQUENCE {
	subjectPublicKey [0] BIT STRING,		dhSignedData [0] ContentInfo,
	nonce [1] INTEGER (0..4294967295),		-- Type is SignedData.
	dhKeyExpiration [2] KerberosTime OPTIONAL,		-- Content is KDCDHKeyInfo
	...		-- (defined below).
	}		serverDHNonce [1] DHNonce OPTIONAL
			}
	ReplyKeyPack ::= SEQUENCE {		KDCDHKeyInfo ::= SEQUENCE {
	replyKey [0] EncryptionKey,		subjectPublicKey [0] BIT STRING,
	nonce [1] INTEGER (0..4294967295),		-- Equals public exponent
	...		-- (g^a mod p).
	}		-- INTEGER encoded as payload
			-- of BIT STRING.
			nonce [1] INTEGER (0..4294967295),
			dhKeyExpiration [2] KerberosTime OPTIONAL,
			-- Expiration time for KDC's
			-- cached values. If this field
			-- is omitted then the
			-- serverDHNonce field MUST also
			-- be omitted.
			...
			}
	END		ReplyKeyPack ::= SEQUENCE {
			replyKey [0] EncryptionKey,
			-- Defined in [CLAR].
			-- Used to encrypt main reply.
			-- 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),
			-- Contains the nonce in
			-- the KDCDHKeyInfo.
			...
			}
	Copyright (C) The Internet Society 2004. This document is subject		END
	to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.
	This document and the information contained herein are provided on		Intellectual Property Statement
	an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE		The IETF takes no position regarding the validity or scope of any
	INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR		Intellectual Property Rights or other rights that might be claimed to
	IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		pertain to the implementation or use of the technology described in
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		this document or the extent to which any license under such rights
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		might or might not be available; nor does it represent that it has
			made any independent effort to identify any such rights. Information
			on the procedures with respect to rights in RFC documents can be
			found in BCP 78 and BCP 79.
			Copies of IPR disclosures made to the IETF Secretariat and any
			assurances of licenses to be made available, or the result of an
			attempt made to obtain a general license or permission for the use of
			such proprietary rights by implementers or users of this
			specification can be obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
			The IETF invites any interested party to bring to its attention any
			copyrights, patents or patent applications, or other proprietary
			rights that may cover technology that may be required to implement
			this standard. Please address the information to the IETF at
			ietf-ipr@ietf.org.
			Disclaimer of Validity
			This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
			ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
			INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
			INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Copyright Statement
			Copyright (C) The Internet Society (2004). This document is subject
			to the rights, licenses and restrictions contained in BCP 78, and
			except as set forth therein, the authors retain all their rights.
			Acknowledgment
			Funding for the RFC Editor function is currently provided by the
			Internet Society.
End of changes. 213 change blocks.
	792 lines changed or deleted		842 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/