Diff: draft-ietf-cat-kerberos-pk-init-18.txt - draft-ietf-cat-kerberos-pk-init-19.txt

	< draft-ietf-cat-kerberos-pk-init-18.txt	draft-ietf-cat-kerberos-pk-init-19.txt >
	INTERNET-DRAFT Brian Tung	INTERNET-DRAFT Brian Tung

	draft-ietf-cat-kerberos-pk-init-18.txt Clifford Neuman	draft-ietf-cat-kerberos-pk-init-19.txt Clifford Neuman
	Updates: RFC 1510bis USC/ISI	Updates: RFC 1510bis USC/ISI

	expires August 20, 2004 Matthew Hur	expires September 30, 2004 Matthew Hur
	Ari Medvinsky	Ari Medvinsky
	Microsoft Corporation	Microsoft Corporation
	Sasha Medvinsky	Sasha Medvinsky
	Motorola, Inc.	Motorola, Inc.
	John Wray	John Wray
	Iris Associates, Inc.	Iris Associates, Inc.
	Jonathan Trostle	Jonathan Trostle

	Public Key Cryptography for Initial Authentication in Kerberos	Public Key Cryptography for Initial Authentication in Kerberos


	skipping to change at line 35 ¶	skipping to change at line 35 ¶
	at any time. It is inappropriate to use Internet-Drafts as	at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as "work in progress."	reference 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	The distribution of this memo is unlimited. It is filed as

	draft-ietf-cat-kerberos-pk-init-18.txt and expires August 20, 2004.	draft-ietf-cat-kerberos-pk-init-19.txt and expires September 30,
	Please send comments to the authors.	2004. Please send comments to the authors.

	1. Abstract	1. Abstract


	This draft describes protocol extensions (hereafter called PKINIT)	This document describes protocol extensions (hereafter called PKINIT)
	to the Kerberos protocol specification (RFC 1510bis [1]). These	to the Kerberos protocol specification (RFC 1510bis [1]). These
	extensions provide a method for integrating public key cryptography	extensions provide a method for integrating public key cryptography

	into the initial authentication exchange, by passing cryptographic	into the initial authentication exchange, by passing digital
	certificates and associated authenticators in preauthentication data	certificates and associated authenticators in preauthentication data
	fields.	fields.

	2. Introduction	2. 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	Usually, the AS and TGS are integrated in a single device known as

	a Kerberos Key Distribution Center, or KDC. (In this draft, we will	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	refer to both the AS and the TGS as the KDC.) Finally, the client
	uses the service ticket to authenticate itself to the service.	uses the service ticket to authenticate itself to the service.


	The advantage afforded by the TGT is that the user need only	The advantage afforded by the TGT is that the client need
	explicitly request a ticket and expose his credentials once. The	explicitly request a ticket and expose his credentials only once. The
	TGT and its associated session key can then be used for any	TGT and its associated session key can then be used for any

	subsequent requests. One implication of this is that all further	subsequent requests. One result of this is that all further
	authentication is independent of the method by which the initial	authentication is independent of the method by which the initial
	authentication was performed. Consequently, initial authentication	authentication was performed. Consequently, initial authentication
	provides a convenient place to integrate public-key cryptography	provides a convenient place to integrate public-key cryptography
	into Kerberos authentication.	into Kerberos authentication.

	As defined, Kerberos authentication exchanges use symmetric-key	As defined, Kerberos authentication exchanges use symmetric-key

	cryptography, in part for performance. (Symmetric-key cryptography	cryptography, in part for performance. One cost of using
	is typically 10-100 times faster than public-key cryptography,
	depending on the public-key operations. [cite]) One cost of using
	symmetric-key cryptography is that the keys must be shared, so that	symmetric-key cryptography is that the keys must be shared, so that

	before a user can authentication himself, he must already be	before a client can authenticate itself, he must already be
	registered with the KDC.	registered with the KDC.


	Conversely, public-key cryptography--in conjunction with an	Conversely, public-key cryptography (in conjunction with an
	established certification infrastructure--permits authentication	established Public Key Infrastructure) permits authentication
	without prior registration. Adding it to Kerberos allows the	without prior registration with a KDC. Adding it to Kerberos allows the
	widespread use of Kerberized applications by users without requiring	widespread use of Kerberized applications by clients without requiring
	them to register first--a requirement that has no inherent security	them to register first with a KDC: a requirement that has no inherent
	benefit.	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. Another document (PKCROSS) describes a	initial authentication.
	similar protocol for Kerberos cross-realm authentication.

	3. Extensions	3. Extensions

	This section describes extensions to RFC 1510bis for supporting the	This section describes extensions to RFC 1510bis for supporting the

	use of public-key cryptography in the initial request for a ticket	use of public-key cryptography in the initial request for a ticket.
	granting ticket (TGT).


	Briefly, the following changes to RFC 1510bis are proposed:	Briefly, this document defines the following extensions to RFC 1510bis:


	1. If public-key authentication is indicated, the client sends	1. The client indicates the use of public-key authentication by
	the user's public-key data and an authenticator in a	including a special preauthenticator in the initial request.
	preauthentication field accompanying the usual request.	This preauthenticator contains the client's public-key data
	This authenticator is signed by the user's private	and a signature.
	signature key.


	2. The KDC verifies the client's request against its own	2. 2. The KDC tests the client's request against its policy and
	policy and certification authorities.	trusted Certification Authorities (CAs).

	3. If the request passes the verification tests, the KDC	3. If the request passes the verification tests, the KDC
	replies as usual, but the reply is encrypted using either:	replies as usual, but the reply is encrypted using either:


	a. a randomly generated key, signed using the KDC's	a. a symmetric encryption key, signed using the KDC?s
	signature key and encrypted using the user's encryption	signature key and encrypted using the client?s encryption
	key; or	key; or

	b. a key generated through a Diffie-Hellman exchange with	b. a key generated through a Diffie-Hellman exchange with
	the client, signed using the KDC's signature key.	the client, signed using the KDC's signature key.


	Any key data required by the client to obtain the encryption	Any keying material required by the client to obtain the
	key is returned in a preauthentication field accompanying	Encryption key is returned in a preauthentication field in
	the usual reply.	the usual reply.

	4. The client obtains the encryption key, decrypts the reply,	4. The client obtains the encryption key, decrypts the reply,
	and then proceeds as usual.	and then proceeds as usual.

	Section 3.1 of this document defines the necessary message formats.	Section 3.1 of this document defines the necessary message formats.
	Section 3.2 describes their syntax and use in greater detail.	Section 3.2 describes their syntax and use in greater detail.

	Implementation of all specified formats and uses in these sections
	is REQUIRED for compliance with PKINIT.

	3.1. Definitions	3.1. Definitions

	3.1.1. Required Algorithms	3.1.1. Required Algorithms


	At minimum, PKINIT must be able to use the following algorithms:	All PKINIT implementations MUST support the following algorithms:


	Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype	- Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype;
	(as required by clarifications).
	Signature algorithm: SHA-1 digest and RSA.	- Signature algorithm: SHA-1 digest and RSA;
	Reply key delivery method: ephemeral-ephemeral Diffie-Hellman
	with a non-zero nonce.	- Reply key delivery method: ephemeral-ephemeral Diffie-Hellman
	Unkeyed checksum type for the paChecksum member of	with a non-zero nonce;

		- Unkeyed checksum type for the paChecksum member of
	PKAuthenticator: SHA1 (unkeyed).	PKAuthenticator: SHA1 (unkeyed).

	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 preauthentication types:

	PA-PK-AS-REQ TBD	PA-PK-AS-REQ TBD
	PA-PK-AS-REP TBD	PA-PK-AS-REP TBD
	PA-PK-OCSP-REQ TBD	PA-PK-OCSP-REQ TBD
	PA-PK-OCSP-REP TBD	PA-PK-OCSP-REP TBD

	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 TBD	AD-INITIAL-VERIFIED-CAS TBD


	PKINIT introduces the following new error types:	PKINIT introduces the following new error codes:

	KDC_ERR_CLIENT_NOT_TRUSTED 62	KDC_ERR_CLIENT_NOT_TRUSTED 62
	KDC_ERR_KDC_NOT_TRUSTED 63	KDC_ERR_KDC_NOT_TRUSTED 63
	KDC_ERR_INVALID_SIG 64	KDC_ERR_INVALID_SIG 64

	KDC_ERR_KEY_TOO_WEAK 65	KDC_ERR_KEY_SIZE 65
	KDC_ERR_CERTIFICATE_MISMATCH 66	KDC_ERR_CERTIFICATE_MISMATCH 66
	KDC_ERR_CANT_VERIFY_CERTIFICATE 70	KDC_ERR_CANT_VERIFY_CERTIFICATE 70
	KDC_ERR_INVALID_CERTIFICATE 71	KDC_ERR_INVALID_CERTIFICATE 71
	KDC_ERR_REVOKED_CERTIFICATE 72	KDC_ERR_REVOKED_CERTIFICATE 72
	KDC_ERR_REVOCATION_STATUS_UNKNOWN 73	KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
	KDC_ERR_CLIENT_NAME_MISMATCH 75	KDC_ERR_CLIENT_NAME_MISMATCH 75

	PKINIT uses the following typed data types for errors:	PKINIT uses the following typed data types for errors:


	TD-DH-PARAMETERS 102	TD-DH-PARAMETERS TBD
	TD-TRUSTED-CERTIFIERS 104	TD-TRUSTED-CERTIFIERS 104
	TD-CERTIFICATE-INDEX 105	TD-CERTIFICATE-INDEX 105

	PKINIT defines the following encryption types, for use in the AS-REQ	PKINIT defines the following encryption types, for use in the AS-REQ
	message (to indicate acceptance of the corresponding encryption OIDs	message (to indicate acceptance of the corresponding encryption OIDs
	in PKINIT):	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-ENV-OID (PKCS1 v2.0) 14	rsaES-OAEP-EnvOID (PKCS1 v2.0) 14
	des-ede3-cbc-Env-OID 15	des-ede3-cbc-EnvOID 15


	The above encryption types are used (in PKINIT) only within CMS [8]	The above encryption types are used by the client only within the
	structures within the PKINIT preauthentication fields. Their use	KDC-REQ-BODY to indicate which CMS [2] algorithms it supports. Their
	within Kerberos EncryptedData structures is unspecified.	use within Kerberos EncryptedData structures is not specified by this
		document.

	3.1.3. Algorithm Identifiers	3.1.3. Algorithm Identifiers

	PKINIT does not define, but does make use of, the following	PKINIT does not define, but does make use of, the following
	algorithm identifiers.	algorithm identifiers.

	PKINIT uses the following algorithm identifier for Diffie-Hellman	PKINIT uses the following algorithm identifier for Diffie-Hellman

	key agreement [11]:	key agreement [9]:

	dhpublicnumber	dhpublicnumber

	PKINIT uses the following signature algorithm identifiers [8, 12]:	PKINIT uses the following signature algorithm identifiers [8, 12]:

	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 [12] for	PKINIT uses the following encryption algorithm identifiers [5] for
	encrypting the temporary key with a public key:	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)


	These OIDs are not to be confused with the encryption types listed	PKINIT uses the following algorithm identifiers [2] for encrypting
	above.

	PKINIT uses the following algorithm identifiers [8] for encrypting
	the reply key with the temporary key:	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)


	Again, these OIDs are not to be confused with the encryption types	Kerberos data structures require the use of integer etypes, while CMS
	listed above.	objects use OIDs. Therefore, each cryptographic algorithm supported
		by PKINIT is identified both by a CMS OID and by an equivalent
		Kerberos etype (defined in section 3.1.2).

	3.2. PKINIT Preauthentication Syntax and Use	3.2. PKINIT Preauthentication Syntax and Use


	In this section, we describe the syntax and use of the various	This section defines the syntax and use of the various
	preauthentication fields employed to implement PKINIT.	preauthentication fields employed by PKINIT.

	3.2.1. Client Request	3.2.1. Client Request

	The initial authentication request (AS-REQ) is sent as per RFC	The initial authentication request (AS-REQ) is sent as per RFC

	1510bis, except that a preauthentication field containing data	1510bis; the preauthentication field contains data signed by the
	signed by the user's private signature key accompanies the request,	client's private signature key as follows:
	as follows:

	PA-PK-AS-REQ ::= SEQUENCE {	PA-PK-AS-REQ ::= SEQUENCE {

	-- PAType TBD
	signedAuthPack [0] ContentInfo,	signedAuthPack [0] ContentInfo,

	-- Defined in CMS.	-- Defined in CMS [2].
	-- Type is SignedData.	-- Type is SignedData.
	-- Content is AuthPack	-- Content is AuthPack
	-- (defined below).	-- (defined below).

	trustedCertifiers [1] SEQUENCE OF TrustedCAs OPTIONAL,	trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,
	-- A list of CAs, trusted by	-- A list of CAs, trusted by
	-- the client, used to certify	-- the client, used to certify
	-- KDCs.	-- KDCs.
	kdcCert [2] IssuerAndSerialNumber OPTIONAL,	kdcCert [2] IssuerAndSerialNumber OPTIONAL,

	-- Defined in CMS.	-- Defined in CMS [2].
	-- Identifies a particular KDC	-- Identifies a particular KDC
	-- certificate, if the client	-- certificate, if the client
	-- already has it.	-- already has it.
	encryptionCert [3] IssuerAndSerialNumber OPTIONAL,	encryptionCert [3] IssuerAndSerialNumber OPTIONAL,

	-- May identify the user's	-- May identify the client's
	-- Diffie-Hellman certificate,	-- Diffie-Hellman certificate,
	-- or an RSA encryption key	-- or an RSA encryption key
	-- certificate.	-- certificate.
	...	...
	}	}


	TrustedCAs ::= CHOICE {	TrustedCA ::= CHOICE {
	caName [0] Name,	caName [0] Name,
	-- Fully qualified X.500 name	-- Fully qualified X.500 name

	-- as defined in X.509 [11].	-- as defined in RFC 3280 [4].
	issuerAndSerial [1] IssuerAndSerialNumber,	issuerAndSerial [1] IssuerAndSerialNumber,
	-- Identifies a specific CA	-- Identifies a specific CA

	-- certificate, if the client	-- certificate.
	-- only trusts one.
	...	...
	}	}

	AuthPack ::= SEQUENCE {	AuthPack ::= SEQUENCE {
	pkAuthenticator [0] PKAuthenticator,	pkAuthenticator [0] PKAuthenticator,

	clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL	clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
	-- Defined in X.509,	-- Defined in RFC 3280 [4].
	-- reproduced below.
	-- Present only if the client	-- Present only if the client
	-- is using ephemeral-ephemeral	-- is using ephemeral-ephemeral
	-- Diffie-Hellman.	-- Diffie-Hellman.

		...
	}	}

	PKAuthenticator ::= SEQUENCE {	PKAuthenticator ::= SEQUENCE {
	cusec [0] INTEGER,	cusec [0] INTEGER,
	ctime [1] KerberosTime,	ctime [1] KerberosTime,
	-- cusec and ctime are used as	-- cusec and ctime are used as
	-- in RFC 1510bis, for replay	-- in RFC 1510bis, for replay
	-- prevention.	-- prevention.
	nonce [2] INTEGER,	nonce [2] INTEGER,
	-- Binds reply to request,	-- Binds reply to request,

	-- except is zero when client	-- MUST be zero when client
	-- will accept cached	-- will accept cached
	-- Diffie-Hellman parameters	-- Diffie-Hellman parameters

	-- from KDC and MUST NOT be	-- from KDC. MUST NOT be
	-- zero otherwise.	-- zero otherwise.

	-- MUST be < 2^32.	-- MUST be 0 <= nonce < 2^32.
	paChecksum [3] Checksum,	paChecksum [3] Checksum,

	-- Defined in [15].	-- Defined in RFC 1510bis [1].
	-- Performed over KDC-REQ-BODY,	-- Performed over KDC-REQ-BODY,

	-- must be unkeyed.	-- MUST be unkeyed.
	...	...
	}	}

	IMPORTS	IMPORTS

	-- from X.509	-- from RFC 3280 [4]
	SubjectPublicKeyInfo, AlgorithmIdentifier, DomainParameters,	SubjectPublicKeyInfo, AlgorithmIdentifier, Name
	ValidationParms
	FROM PKIX1Explicit88 { iso (1) identified-organization (3)	FROM PKIX1Explicit88 { iso (1) identified-organization (3)
	dod (6) internet (1) security (5) mechanisms (5)	dod (6) internet (1) security (5) mechanisms (5)

	pkix (7) id-mod (0) id-pkix1-explicit-88 (1) }	pkix (7) id-mod (0) id-pkix1-explicit (18) }

		IMPORTS
		-- from RFC 2630 [2]
		ContentInfo, IssuerAndSerialNumber
		FROM CryptographicMessageSyntax { iso(1) member-body(2)
		us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
		modules(0) cms(1) }

		IMPORTS
		-- from RFC 1510bis [1]
		KerberosTime, Checksum
		FROM KerberosV5Spec2 { iso(1) identified-organization(3)
		dod(6) internet(1) security(5) kerberosV5(2) modules(4)
		krb5spec2(2) }

	The ContentInfo in the signedAuthPack is filled out as follows:	The ContentInfo in the signedAuthPack is filled out as follows:

	1. The eContent field contains data of type AuthPack. It MUST	1. The eContent field contains data of type AuthPack. It MUST
	contain the pkAuthenticator, and MAY also contain the	contain the pkAuthenticator, and MAY also contain the

	user's Diffie-Hellman public value (clientPublicValue).	client's Diffie-Hellman public value (clientPublicValue).

	2. The eContentType field MUST contain the OID value for	2. The eContentType field MUST contain the OID value for
	pkauthdata: { iso (1) org (3) dod (6) internet (1)	pkauthdata: { iso (1) org (3) dod (6) internet (1)
	security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)}	security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)}


	3. The signerInfos field MUST contain the signature of the	3. The signerInfos field MUST contain the signature over the
	AuthPack.	AuthPack.

	4. The certificates field MUST contain at least a signature	4. The certificates field MUST contain at least a signature
	verification certificate chain that the KDC can use to	verification certificate chain that the KDC can use to

	verify the signature on the AuthPack. Additionally, the	verify the signature over the AuthPack. Additionally, the
	client may also insert an encryption certificate chain, if	client MAY insert an encryption certificate chain, if
	(for example) the client is not using ephemeral-ephemeral	(for example) the client is not using ephemeral-ephemeral
	Diffie-Hellman.	Diffie-Hellman.

	5. If a Diffie-Hellman key is being used, the parameters SHOULD	5. If a Diffie-Hellman key is being used, the parameters SHOULD
	be chosen from the First or Second defined Oakley Groups.	be chosen from the First or Second defined Oakley Groups.

	(See RFC 2409 [c].)	(See RFC 2409 [10].)

	6. The KDC may wish to use cached Diffie-Hellman parameters.	6. The KDC may wish to use cached Diffie-Hellman parameters.
	To indicate acceptance of caching, the client sends zero in	To indicate acceptance of caching, the client sends zero in
	the nonce field of the pkAuthenticator. Zero is not a valid	the nonce field of the pkAuthenticator. Zero is not a valid
	value for this field under any other circumstances. Since	value for this field under any other circumstances. Since
	zero is used to indicate acceptance of cached parameters,	zero is used to indicate acceptance of cached parameters,

	message binding in this case is performed instead using the	message binding in this case is performed using only the
	nonce in the main request.	nonce in the main request.

	3.2.2. Validation of Client Request	3.2.2. Validation 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 user certificate in the signedAuthPack.	The KDC must look for a client certificate in the signedAuthPack.
	If it cannot find one signed by a CA it trusts, it sends back an	If it cannot find one signed by a CA it trusts, it sends back an
	error of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying	error of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying

	e-data for this error is a SEQUENCE OF TypedData:	e-data for this error is a SEQUENCE OF TYPED-DATA:


	TypedData ::= SEQUENCE {	TYPED-DATA ::= SEQUENCE {
	-- As defined in RFC 1510bis.	-- As defined in RFC 1510bis.
	data-type [0] INTEGER,	data-type [0] INTEGER,
	data-value [1] OCTET STRING	data-value [1] OCTET STRING
	}	}


		IMPORTS
		-- from RFC 1510bis [1]
		TYPED-DATA, Checksum
		FROM KerberosV5Spec2 { iso(1) identified-organization(3)
		dod(6) internet(1) security(5) kerberosV5(2) modules(4)
		krb5spec2(2) }

	For this error, the data-type is TD-TRUSTED-CERTIFIERS, and the	For this error, the data-type is TD-TRUSTED-CERTIFIERS, and the
	data-value is an OCTET STRING containing the DER encoding of	data-value is an OCTET STRING containing the DER encoding of

	TrustedCertifiers ::= SEQUENCE OF Name	TrustedCertifiers ::= SEQUENCE OF Name

	If, while verifying the certificate chain, the KDC determines that	If, while verifying the certificate chain, 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 SEQUENCE OF TypedData,	The accompanying e-data for this error is a SEQUENCE OF TYPED-DATA,
	whose data-type is TD-CERTIFICATE-INDEX, and whose data-value is an	whose data-type is TD-CERTIFICATE-INDEX, and whose data-value is an
	OCTET STRING containing the DER encoding of the index into the	OCTET STRING containing the DER encoding of the index into the
	CertificateSet field, ordered as sent by the client:	CertificateSet field, ordered as sent by the client:


	CertificateIndex ::= INTEGER	CertificateIndex ::= IssuerAndSerialNumber
	-- 0 = first certificate (in	-- IssuerAndSerialNumber of
	-- order of encoding),	-- certificate with invalid signature
	-- 1 = second certificate, etc.


	If more than one signature is invalid, the KDC sends one TypedData	If more than one certificate signature is invalid, the KDC MAY send one
	per invalid signature.	TYPED-DATA per invalid signature.


	The KDC MAY also check whether any of the certificates in the user's	The KDC MAY also check whether any of the certificates in the client's
	chain have been revoked. If any of them have been revoked, the KDC	chain have been revoked. If any of them have been revoked, the KDC

	returns an error of type KDC_ERR_REVOKED_CERTIFICATE; if 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,	attempts to determine the revocation status but is unable to do so,
	it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN.	it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN.
	The certificate or certificates affected are identified exactly as	The certificate or certificates affected are identified exactly as
	for an error of type KDC_ERR_INVALID_CERTIFICATE (see above).	for an error of type KDC_ERR_INVALID_CERTIFICATE (see above).


	If the certificate chain is successfully validated, but the user's	In addition to validating the certificate chain, the KDC MUST also
	certificate is not authorized to the client's principal name in the	check that the certificate properly maps to the client's principal name
	AS-REQ (when present), the KDC MUST return an error of type	as specified in the AS-REQ as follows:
	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	1. If the KDC has its own mapping from the name in the
	the request match, the KDC may decide not to trust the client. For	certificate to a Kerberos name, it uses that Kerberos
	example, the certificate may include (or not include) an Enhanced	name.
	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
	returns an error of type KDC_ERR_CLIENT_NOT_TRUSTED. For the
	benefit of implementors, we define a PKINIT EKU OID as follows:
	{ iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2)
	pkinit (3) pkekuoid (4) }.


	If the certificate chain and usage check out, but the client's	2. Otherwise, if the certificate contains a SubjectAltName
	signature on the signedAuthPack fails to verify, the KDC returns an	extension with a Kerberos name in the otherName field,
	error of type KDC_ERR_INVALID_SIG. There is no accompanying e-data	it uses that name. The otherName field (of type AnotherName) in
	for this error.	the SubjectAltName extension MUST contain the following:


	The KDC must check the timestamp to ensure that the request is not	The type-id is:
	a replay, and that the time skew falls within acceptable limits.
	The recommendations for ordinary (that is, non-PKINIT) skew times
	apply here. If the check fails, the KDC returns an error of type
	KRB_AP_ERR_REPEAT or KRB_AP_ERR_SKEW, respectively.


	Finally, if the clientPublicValue is filled in, indicating that the	krb5PrincipalName OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6)
	client wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC	internet (1) security (5) kerberosv5 (2) 2 }
	checks to see if the parameters satisfy its policy. If they do not,
	it returns an error of type KDC_ERR_KEY_TOO_WEAK. The accompanying
	e-data is a SEQUENCE OF TypedData, whose data-type is
	TD-DH-PARAMETERS, and whose data-value is an OCTET STRING containing
	the DER encoding of a DomainParameters (see above), including
	appropriate Diffie-Hellman parameters with which to retry the
	request.


	In order to establish authenticity of the reply, the KDC will sign	The value is:
	some key data (either the random key used to encrypt the reply in
	the case of a KDCDHKeyInfo, or the Diffie-Hellman parameters used to
	generate the reply-encrypting key in the case of a ReplyKeyPack).
	The signature certificate to be used is to be selected as follows:


	1. If the client included a kdcCert field in the PA-PK-AS-REQ,	KRB5PrincipalName ::= SEQUENCE {
	use the referred-to certificate, if the KDC has it. If it	realm [0] Realm,
	does not, the KDC returns an error of type	principalName [1] PrincipalName
	KDC_ERR_CERTIFICATE_MISMATCH.	}


	2. Otherwise, if the client did not include a kdcCert field,	IMPORTS
	but did include a trustedCertifiers field, and the KDC	-- from RFC 3280 [4]
	possesses a certificate issued by one of the listed	GeneralName
	certifiers, use that certificate. if it does not possess	FROM PKIX1Explicit88 { iso (1) identified-organization (3)
	one, it returns an error of type KDC_ERR_KDC_NOT_TRUSTED.	dod (6) internet (1) security (5) mechanisms (5)
		pkix (7) id-mod (0) id-pkix1-explicit (18) }


	3. Otherwise, if the client included neither a kdcCert field	IMPORTS
	nor a trustedCertifiers field, and the KDC has only one	-- from RFC 1510bis [1]
	signature certificate, use that certificate. If it has	PrincipalName, Realm
	more than one certificate, it returns an error of type	FROM KerberosV5Spec2 { iso(1) identified-organization(3)
	KDC_ERR_CERTIFICATE_MISMATCH.	dod(6) internet(1) security(5) kerberosV5(2) modules(4)
		krb5spec2(2) }


	3.2.3. KDC Reply	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
		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. If the name in the request is [special "blank"
		name], the KDC MAY insert a different name in the reply.


	Assuming that the client's request has been properly validated, the	Even if the chain is validated, and the names in the certificate and
	KDC proceeds as per RFC 1510bis, except as follows.	the request match, the KDC may decide not to trust the client. For
		example, the certificate may include an Enxtended 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:


	The user's name as represented in the AS-REP must be derived from	{ iso (1) org (3) dod (6) internet (1) security (5)
	the certificate provided in the client's request. If the KDC has	kerberosv5 (2) pkinit (3) pkekuoid (4) }
	its own mapping from the name in the certificate to a Kerberos name,
	it uses that Kerberos name.


	Otherwise, if the certificate contains a SubjectAltName extension	If the client's signature on the signedAuthPack fails to verify, the KDC
	with a KerberosName in the otherName field, it uses that name.	MUST return error KDC_ERR_INVALID_SIG. There is no accompanying
		e-data for this error.


	AnotherName ::= SEQUENCE {	The KDC MUST check the timestamp to ensure that the request is not
	-- Defined in [11].	a replay, and that the time skew falls within acceptable limits.
	type-id OBJECT IDENTIFIER,	The recommendations clock skew times in RFC 1510bis [1] apply here.
	value [0] EXPLICIT ANY DEFINED BY type-id	If the check fails, the KDC MUSTreturn error code KRB_AP_ERR_REPEAT
	}	or KRB_AP_ERR_SKEW, respectively.


	KerberosName ::= SEQUENCE {	If the clientPublicValue is filled in, indicating that the
	realm [0] Realm,	client wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC
	principalName [1] PrincipalName	checks to 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 SEQUENCE OF TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and whose
		data-value is an OCTET STRING containing the DER encoding of a
		DomainParameters (see [3]), including appropriate Diffie-Hellman
		parameters with which to retry the request.


	with OID	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 not
		have the corresponding certificate.


	krb5 OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6) internet (1)	The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client did
	security (5) kerberosv5 (2) }	not include a kdcCert field, but did include a trustedCertifiers field,
		and the KDC does not possesses a certificate issued by one of the listed
		certifiers.


	krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }	3.2.3. KDC Reply


	In this case, the realm in the ticket is that of the local realm (or	Assuming that the client's request has been properly validated, the
	some other realm name chosen by that realm). Otherwise, the KDC	KDC proceeds as per RFC 1510bis, except as follows.
	returns an error of type KDC_ERR_CLIENT_NAME_MISMATCH.


	In addition, the KDC MUST set the initial flag in the issued TGT	The KDC MUST set the initial flag and include an authorization data of
	and add an authorization data of type AD-INITIAL-VERIFIED-CAS to	type AD-INITIAL-VERIFIED-CAS in the issued ticket. The value is an
	the TGT. The value is an OCTET STRING containing the DER encoding	OCTET STRING containing the DER encoding of InitialVerifiedCAs:
	of InitialVerifiedCAs:

	InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {	InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
	ca [0] Name,	ca [0] Name,

	ocspValidated [1] BOOLEAN,	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	Furthermore, any TGS must copy such authorization data from tickets
	used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket,	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.

	AP servers that understand this authorization data type SHOULD apply	AP servers that understand this authorization data type SHOULD apply
	local policy to determine whether a given ticket bearing such a type	local policy to determine whether a given ticket bearing such a type
	(not contained within an AD-IF-RELEVANT container) is acceptable.	(not contained within an AD-IF-RELEVANT container) is acceptable.
	(This corresponds to the AP server checking the transited field when	(This corresponds to the AP server checking the transited field when
	the TRANSITED-POLICY-CHECKED flag has not been set.) If such a data	the TRANSITED-POLICY-CHECKED flag has not been set.) If such a data

	type is contained within an AD-IF-RELEVANT container, AP servers	type is contained within an AD-IF-RELEVANT container, AP servers
	still MAY apply local policy to determine whether the authorization	MAY apply local policy to determine whether the authorization
	data is acceptable.	data is acceptable.


	The AS-REP is otherwise unchanged from RFC 1510bis. The KDC then	The AS-REP is otherwise unchanged from RFC 1510bis. The KDC encrypts
	encrypts the reply as usual, but not with the user's long-term key.	the reply as usual, but not with the client's long-term key.
	Instead, it encrypts it with either a random encryption key, or a	Instead, it encrypts it with either a generated encryption key, or a
	key derived from a Diffie-Hellman exchange. Which is the case is	key derived from a Diffie-Hellman exchange. The contents of the
	indicated by the contents of the PA-PK-AS-REP (note tags):	PA-PK-AS-REP indicate the type of encryption key that was used:

	PA-PK-AS-REP ::= CHOICE {	PA-PK-AS-REP ::= CHOICE {

	-- PAType YY (TBD)
	dhSignedData [0] ContentInfo,	dhSignedData [0] ContentInfo,
	-- Type is SignedData.	-- Type is SignedData.
	-- Content is KDCDHKeyInfo	-- Content is KDCDHKeyInfo
	-- (defined below).	-- (defined below).
	encKeyPack [1] ContentInfo,	encKeyPack [1] ContentInfo,

	-- Type is EnvelopedData.	-- Type is SignedData.
	-- Content is ReplyKeyPack	-- Content is ReplyKeyPack
	-- (defined below).	-- (defined below).
	...	...
	}	}


	Note that PA-PK-AS-REP is a CHOICE: either a dhSignedData, or an
	encKeyPack, but not both. The former contains data of type
	KDCDHKeyInfo, and is used only when the reply is encrypted using a
	Diffie-Hellman derived key:

	KDCDHKeyInfo ::= SEQUENCE {	KDCDHKeyInfo ::= SEQUENCE {
	subjectPublicKey [0] BIT STRING,	subjectPublicKey [0] BIT STRING,
	-- Equals public exponent	-- Equals public exponent
	-- (g^a mod p).	-- (g^a mod p).
	-- INTEGER encoded as payload	-- INTEGER encoded as payload
	-- of BIT STRING.	-- of BIT STRING.
	nonce [1] INTEGER,	nonce [1] INTEGER,
	-- Binds reply to request.	-- Binds reply to request.
	-- Exception: A value of zero	-- Exception: A value of zero
	-- indicates that the KDC is	-- indicates that the KDC is

	skipping to change at line 566 ¶	skipping to change at line 565 ¶
	1. The eContent field contains data of type KDCDHKeyInfo.	1. The eContent field contains data of type KDCDHKeyInfo.

	2. The eContentType field contains the OID value for	2. The eContentType field contains the OID value for
	pkdhkeydata: { iso (1) org (3) dod (6) internet (1)	pkdhkeydata: { iso (1) org (3) dod (6) internet (1)
	security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2) }	security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2) }

	3. The signerInfos field contains a single signerInfo, which is	3. The signerInfos field contains a single signerInfo, which is
	the signature of the KDCDHKeyInfo.	the signature of the KDCDHKeyInfo.

	4. The certificates field contains a signature verification	4. The certificates field contains a signature verification

	certificate chain that the client may use to verify the	certificate chain that the client will use to verify the
	KDC's signature over the KDCDHKeyInfo.) It may only be left	KDC's signature over the KDCDHKeyInfo. This field may only
	empty if the client did not include a trustedCertifiers	be left empty if the client did include a kdcCert field in
	field in the PA-PK-AS-REQ, indicating that it has the KDC's	the PA-PK-AS-REQ, indicating that it has the KDC's certificate.
	certificate.

	5. If the client and KDC agree to use cached parameters, the	5. If the client and KDC agree to use cached parameters, the

	KDC SHOULD return a zero in the nonce field and include the	KDC MUST return a zero in the nonce field and include the
	expiration time of the cached values in the dhKeyExpiration	expiration time of the cached values in the dhKeyExpiration

	field. If this time is exceeded, the client SHOULD NOT use	field. If this time is exceeded, the client MUST NOT use
	the reply. If the time is absent, the client SHOULD NOT use	the reply. If the time is absent, the client MUST NOT use
	the reply and MAY resubmit a request with a non-zero nonce,	the reply and MAY resubmit a request with a non-zero nonce,
	thus indicating non-acceptance of the cached parameters.	thus indicating non-acceptance of the cached parameters.

	The key is derived as follows: Both the KDC and the client calculate	The key is derived as follows: Both the KDC and the client calculate
	the value g^(ab) mod p, where a and b are the client's and KDC's	the value g^(ab) mod p, where a and b are the client's and KDC's
	private exponents, respectively. They both take the first k bits of	private exponents, respectively. They both take the first k bits of
	this secret value as a key generation seed, where the parameter k	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	(the size of the seed) is dependent on the selected key type, as

	specified in the Kerberos crypto draft [15]. The seed is then	specified in [6]. The seed is then converted into a protocol key by
	converted into a protocol key by applying to it a random-to-key	applying to it a random-to-key function, which is also dependent on
	function, which is also dependent on key type.	key type.

	The protocol key is used to derive the integrity key Ki and the
	encryption key Ke according to [15]. Ke and Ki are used to generate
	the encrypted part of the AS-REP.

	1. For example, if the encryption type is DES with MD4, k = 64	1. For example, if the encryption type is DES with MD4, k = 64
	bits and the random-to-key function consists of replacing	bits and the random-to-key function consists of replacing
	some of the bits with parity bits, according to FIPS PUB 74	some of the bits with parity bits, according to FIPS PUB 74

	[cite]. In this case, the key derivation function for Ke is	[9].
	the identity function, and Ki is not needed because the
	checksum in the EncryptedData is not keyed.

	2. If the encryption type is three-key 3DES with HMAC-SHA1,	2. If the encryption type is three-key 3DES with HMAC-SHA1,
	k = 168 bits and the random-to-key function is	k = 168 bits and the random-to-key function is

	DES3random-to-key as defined in [15]. This function inserts	DES3random-to-key as defined in [6]. This function inserts
	parity bits to create a 192-bit 3DES protocol key that is	parity bits to create a 192-bit 3DES protocol key that is

	compliant with FIPS PUB 74 [cite]. Ke and Ki are derived	compliant with FIPS PUB 74 [9]. This key is used to
	from this protocol key according to [15] with the key usage	generate additional keys Ke and Ki, for encryption and
	number set to 3 (AS-REP encrypted part).	integrity protection, respectively, using the key usage
		value of 3, as per [6] for the handling of the encrypted
		part of the AS-REP.

	If the KDC and client are not using Diffie-Hellman, the KDC encrypts	If the KDC and client are not using Diffie-Hellman, the KDC encrypts
	the reply with an encryption key, packed in the encKeyPack, which	the reply with an encryption key, packed in the encKeyPack, which
	contains data of type ReplyKeyPack:	contains data of type ReplyKeyPack:

	ReplyKeyPack ::= SEQUENCE {	ReplyKeyPack ::= SEQUENCE {
	replyKey [0] EncryptionKey,	replyKey [0] EncryptionKey,
	-- Defined in RFC 1510bis.	-- Defined in RFC 1510bis.
	-- Used to encrypt main reply.	-- Used to encrypt main reply.

	-- MUST be at least as large	-- MUST be at least as strong
	-- as session key.	-- as session key. (Using the
		-- same enctype and a strong
		-- prng should suffice, if no
		-- stronger encryption system
		-- is available.)
	nonce [1] INTEGER,	nonce [1] INTEGER,
	-- Binds reply to request.	-- Binds reply to request.

	-- MUST be < 2^32.	-- MUST be 0 < nonce < 2^32.
	...	...
	}	}


		IMPORTS
		-- from RFC 1510bis [1]
		EncryptionKey
		FROM KerberosV5Spec2 { iso(1) identified-organization(3)
		dod(6) internet(1) security(5) kerberosV5(2) modules(4)
		krb5spec2(2) }

	The fields of the ContentInfo for encKeyPack MUST be filled in as	The fields of the ContentInfo for encKeyPack MUST be filled in as
	follows:	follows:


	1. The innermost data is of type SignedData. The eContent for	1. The content is of type SignedData. The eContent for
	this data is of type ReplyKeyPack.	the SignedData is of type ReplyKeyPack.


	2. The eContentType for this data contains the OID value for	2. The eContentType for the SignedData contains the OID value for
	pkrkeydata: { iso (1) org (3) dod (6) internet (1)	pkrkeydata: { iso (1) org (3) dod (6) internet (1)
	security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3) }	security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3) }

	3. The signerInfos field contains a single signerInfo, which is	3. The signerInfos field contains a single signerInfo, which is
	the signature of the ReplyKeyPack.	the signature of the ReplyKeyPack.

	4. The certificates field contains a signature verification	4. The certificates field contains a signature verification

	certificate chain, which the client may use to verify the	certificate chain that the client will use to verify the
	KDC's signature over the ReplyKeyPack.) It may only be left	KDC's signature over the ReplyKeyPack. This field may only
	empty if the client did not include a trustedCertifiers	be left empty if the client did include a kdcCert field in
	field in the PA-PK-AS-REQ, indicating that it has the KDC's	the PA-PK-AS-REQ, indicating that it has the KDC's certificate.
	certificate.

	5. The outer data is of type EnvelopedData. The
	encryptedContent for this data is the SignedData described
	in items 1 through 4, above.


	6. The encryptedContentType for this data contains the OID	5. The encryptedContentType for the EnvelopedData contains the OID
	value for id-signedData: { iso (1) member-body (2) us (840)	value for id-signedData: { iso (1) member-body (2) us (840)
	rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) }	rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) }


	7. The recipientInfos field is a SET which MUST contain exactly	6. The recipientInfos field is a SET which MUST contain exactly
	one member of type KeyTransRecipientInfo. The encryptedKey	one member of type KeyTransRecipientInfo. The encryptedKey
	for this member contains the temporary key which is	for this member contains the temporary key which is
	encrypted using the client's public key.	encrypted using the client's public key.


	8. Neither the unprotectedAttrs field nor the originatorInfo	7. The unprotectedAttrs or originatorInfo fields MAY be present.
	field is required for PKINIT.

	3.2.4. Validation of KDC Reply	3.2.4. Validation 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 a dhSignedData, the client obtains and
	verifies the Diffie-Hellman parameters, and obtains the shared key	verifies the Diffie-Hellman parameters, and obtains the shared key
	as described above. Otherwise, the message contains an encKeyPack,	as described above. Otherwise, the message contains an encKeyPack,
	and the client decrypts and verifies the temporary encryption key.	and the client decrypts and verifies the temporary encryption key.
	In either case, the client then decrypts the main reply with the	In either case, the client then decrypts the main reply with the
	resulting key, and then proceeds as described in RFC 1510bis.	resulting key, and then proceeds as described in RFC 1510bis.

	3.2.5. Support for OCSP	3.2.5. Support for OCSP


	OCSP (Online Certificate Status Protocol) [cite] allows the use of	OCSP (Online Certificate Status Protocol) [8] allows the use of
	on-line requests for a client or server to determine the validity of	on-line requests for a client or server to determine the validity of
	each other's certificates. It is particularly useful for clients	each other's certificates. It is particularly useful for clients
	authenticating each other across a constrained network. These	authenticating each other across a constrained network. These
	clients will not have to download the entire CRL to check for the	clients will not have to download the entire CRL to check for the
	validity of the KDC's certificate.	validity of the KDC's certificate.

	In these cases, the KDC generally has better connectivity to the	In these cases, the KDC generally has better connectivity to the
	OCSP server, and it therefore processes the OCSP request and	OCSP server, and it therefore processes the OCSP request and

	response and sends the results to the client. The changes proposed	response and sends the results to the client. The mechanism defined
	in this section allow a client to request an OCSP response from the	in this section allow a client to request an OCSP response from the
	KDC when using PKINIT. This is similar to the way that OCSP is	KDC when using PKINIT. This is similar to the way that OCSP is

	handled in [cite].	handled in [7].

	OCSP support is provided in PKINIT through the use of additional	OCSP support is provided in PKINIT through the use of additional
	preauthentication data. The following new preauthentication types	preauthentication data. The following new preauthentication types
	are defined:	are defined:

	PA-PK-OCSP-REQ ::= SEQUENCE {	PA-PK-OCSP-REQ ::= SEQUENCE {
	-- PAType TBD	-- PAType TBD
	responderIDList [0] SEQUENCE of ResponderID OPTIONAL,	responderIDList [0] SEQUENCE of ResponderID OPTIONAL,
	-- ResponderID is a DER-encoded	-- ResponderID is a DER-encoded

	-- ASN.1 type defined in [cite]	-- ASN.1 type defined in [8]
	requestExtensions [1] Extensions OPTIONAL	requestExtensions [1] Extensions OPTIONAL
	-- Extensions is a DER-encoded	-- Extensions is a DER-encoded

	-- ASN.1 type defined in [cite]	-- ASN.1 type defined in [8]
	}	}

	PA-PK-OCSP-REP ::= SEQUENCE of OCSPResponse	PA-PK-OCSP-REP ::= SEQUENCE of OCSPResponse
	-- OCSPResponse is a DER-encoded	-- OCSPResponse is a DER-encoded

	-- ASN.1 type defined in [cite]	-- ASN.1 type defined in [8]

	A KDC that receives a PA-PK-OCSP-REQ MAY send a PA-PK-OCSP-REP.	A KDC that receives a PA-PK-OCSP-REQ MAY send a PA-PK-OCSP-REP.
	KDCs MUST NOT send a PA-PK-OCSP-REP if they do not first receive a	KDCs MUST NOT send a PA-PK-OCSP-REP if they do not first receive a

	PA-PK-OCSP-REQ from the client. The KDC may either send a cached	PA-PK-OCSP-REQ from the client. The KDC MAY either send a cached
	OCSP response or send an on-line request to the OCSP server.	OCSP response or send an on-line request to the OCSP server.


		In the case that a responderIDList is not sent or is empty, the OCSP
		response must be signed by the authority that issued the
		certificate, unless specified otherwise by a mutually agreed policy
		between the client and the KDC.

	When using OCSP, the response is signed by the OCSP server, which is	When using OCSP, the response is signed by the OCSP server, which is
	trusted by the client. Depending on local policy, further	trusted by the client. Depending on local policy, further
	verification of the validity of the OCSP server may need to be done.	verification of the validity of the OCSP server may need to be done.

	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. Anyone using PKINIT must be aware of how the	infrastructure. Users of PKINIT must understand security policies
	certification infrastructure they are linking to works.	and procedures appropriate to the use of Public Key Infrastructures.


	Also, as in standard Kerberos, PKINIT presents the possibility of	Standard Kerberos allows the possibility of interactions between
	interactions between cryptosystems of varying strengths, and this	cryptosystems of varying strengths; this document adds interactions
	now includes public-key cryptosystems. Many systems, for example,	with public-key cryptosystems to Kerberos. Some administrative
	allow the use of 512-bit public keys. Using such keys to wrap data	policies may allow the use of relatively weak public keys. Using
	encrypted under strong conventional cryptosystems, such as 3DES, may	such keys to wrap data encrypted under stronger conventional
	be inappropriate.	cryptosystems may be inappropriate.


	PKINIT calls for randomly generated keys for conventional	PKINIT requires keys for symmetric cryptosystems to be generated.
	cryptosystems. Many such systems contain systematically "weak"	Some such systems contain "weak" keys. For recommendations regarding
	keys. For recommendations regarding these weak keys, see RFC	these weak keys, see RFC 1510bis.
	1510bis.

	PKINIT allows the use of a zero nonce in the PKAuthenticator when	PKINIT allows the use of a zero nonce in the PKAuthenticator when

	cached Diffie-Hellman parameters are used. In this case, message	cached Diffie-Hellman keys are used. In this case, message binding
	binding is performed using the nonce in the main request in the same	is performed using the nonce in the main request in the same way as
	way as it is done for ordinary (that is, non-PKINIT) AS-REQs. The	it is done for ordinary AS-REQs (without the PKINIT
	nonce field in the KDC request body is signed through the checksum	pre-authenticator). The nonce field in the KDC request body is
	in the PKAuthenticator, and it therefore cryptographically binds the	signed through the checksum in the PKAuthenticator, which
	AS-REQ with the AS-REP. If cached parameters are also used on the	cryptographically binds the PKINIT pre-authenticator to the main body
	client side, the generated session key will be the same, and a	of the AS Request and also provides message integrity for the full
	compromised session key could lead to the compromise of future	AS Request.
	cached exchanges. It is desirable to limit the use of cached
	parameters to just the KDC, in order to eliminate this exposure.	However, when a PKINIT pre-authenticator in the 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 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.

		If a client also caches its Diffie-Hellman keys, then the session key
		could remain the same during multiple AS-REQ/AS-REP exchanges and an
		attacker which compromised the session key could fabricate his own
		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	Care should be taken in how certificates are chosen for the purposes
	of authentication using PKINIT. Some local policies may require	of authentication using PKINIT. Some local policies may require

	that key escrow be applied for certain certificate types. People	that key escrow be used for certain certificate types. Deployers of
	deploying PKINIT should be aware of the implications of using	PKINIT should be aware of the implications of using certificates that
	certificates that have escrowed keys for the purposes of	have escrowed keys for the purposes of authentication.
	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.

	It might be possible to address this using a preauthentication field
	as part of the proposed Kerberos preauthenticatino framework.

	5. Acknowledgements	5. Acknowledgements


	Some of the ideas on which this proposal 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

	proposal 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. Expiration Date


	This draft expires August 20, 2004.	This draft expires September 30, 2004.

	7. Bibliography	7. Bibliography


	[1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service	[1] RFC-Editor: To be replaced by RFC number for
	(V5). Request for Comments 1510.	draft-ietf-krb-wg-kerberos-clarifications.

	[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
	for Computer Networks, IEEE Communications, 32(9):33-38. September
	1994.

	[3] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos
	Using Public Key Cryptography. Symposium On Network and Distributed
	System Security, 1997.

	[4] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction
	Protocol. In Proceedings of the USENIX Workshop on Electronic
	Commerce, July 1995.

	[5] T. Dierks, C. Allen. The TLS Protocol, Version 1.0. Request
	for Comments 2246, January 1999.

	[6] B.C. Neuman, Proxy-Based Authorization and Accounting for
	Distributed Systems. In Proceedings of the 13th International
	Conference on Distributed Computing Systems, May 1993.

	[7] ITU-T (formerly CCITT) Information technology - Open Systems
	Interconnection - The Directory: Authentication Framework
	Recommendation X.509 ISO/IEC 9594-8

	[8] R. Housley. Cryptographic Message Syntax.
	draft-ietf-smime-cms-13.txt, April 1999, approved for publication as
	RFC.


	[9] PKCS #7: Cryptographic Message Syntax Standard. An RSA	[2] R. Housley. Cryptographic Message Syntax., April 1999.
	Laboratories Technical Note Version 1.5. Revised November 1, 1993	Request For Comments 2630.


	[10] R. Rivest, MIT Laboratory for Computer Science and RSA Data	[3] W. Polk, R. Housley, and L. Bassham. Algorithms and Identifiers
	Security, Inc. A Description of the RC2(r) Encryption Algorithm.	for the Internet X.509 Public Key Infrastructure Certificate and
	March 1998. Request for Comments 2268.	Certificate Revocation List (CRL) Profile, April 2002. Request For
		Comments 3279.


	[11] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public	[4] R. Housley, W. Polk, W. Ford, D. Solo. Internet X.509 Public
	Key Infrastructure, Certificate and CRL Profile, April 2002.	Key Infrastructure Certificate and Certificate Revocation List
	Request for Comments 3280.	(CRL) Profile, April 2002. Request for Comments 3280.


	[12] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography	[5] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
	Specifications, October 1998. Request for Comments 2437.	Specifications, October 1998. Request for Comments 2437.


	[13] ITU-T (formerly CCITT) Information Processing Systems - Open	[6] RFC-Editor: To be replaced by RFC number for
	Systems Interconnection - Specification of Abstract Syntax Notation	draft-ietf-krb-wg-crypto.
	One (ASN.1) Rec. X.680 ISO/IEC 8824-1.

	[14] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA
	Laboratories Technical Note, Version 1.4, Revised November 1, 1993.

	[15] K. Raeburn. Encryption and Checksum Specifications for
	Kerberos 5, October 2003. draft-ietf-krb-wg-crypto-06.txt.


	[16] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and	[7] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and
	T. Wright. Transport Layer Security (TLS) Extensions, June 2003.	T. Wright. Transport Layer Security (TLS) Extensions, June 2003.
	Request for Comments 3546.	Request for Comments 3546.


	[17] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams.	[8] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams.
	Internet X.509 Public Key Infrastructure: Online Certificate Status	Internet X.509 Public Key Infrastructure: Online Certificate Status
	Protocol - OCSP, June 1999. Request for Comments 2560.	Protocol - OCSP, June 1999. Request for Comments 2560.


		[9] NIST, Guidelines for Implementing and Using the NBS Encryption
		Standard, April 1981. FIPS PUB 74.

		[10] D. Harkins and D. Carrel. The Internet Key Exchange (IKE),
		November 1998. Request for Comments 2409.

	8. Authors	8. Authors

	Brian Tung	Brian Tung
	Clifford Neuman	Clifford Neuman
	USC Information Sciences Institute	USC Information Sciences Institute
	4676 Admiralty Way Suite 1001	4676 Admiralty Way Suite 1001
	Marina del Rey CA 90292-6695	Marina del Rey CA 90292-6695
	Phone: +1 310 822 1511	Phone: +1 310 822 1511
	E-mail: {brian,bcn}@isi.edu	E-mail: {brian,bcn}@isi.edu


End of changes. 131 change blocks.
	329 lines changed or deleted	319 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/