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

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

	draft-ietf-cat-kerberos-pk-init-19.txt Clifford Neuman	draft-ietf-cat-kerberos-pk-init-20.txt Clifford Neuman
	Updates: RFC 1510bis USC/ISI	Updates: CLARIFICATIONS USC/ISI
	expires September 30, 2004 Matthew Hur	expires January 25, 2005 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

	0. Status Of This Memo	0. Status Of This Memo


		By submitting this Internet-Draft, I certify that any applicable
		patent or other IPR claims of which I am aware have been disclosed,
		or will be disclosed, and any of which I become aware will be
		disclosed, in accordance with RFC 3668.

	This document is an Internet-Draft and is in full conformance with	This document is an Internet-Draft and is in full conformance with
	all provision of Section 10 of RFC 2026. Internet-Drafts are	all provision of Section 10 of RFC 2026. Internet-Drafts are
	working documents of the Internet Engineering Task Force (IETF), its	working documents of the Internet Engineering Task Force (IETF), its
	areas, and its working groups. Note that other groups may also	areas, and its working groups. Note that other groups may also
	distribute working documents as Internet-Drafts.	distribute working documents as 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 and may be updated, replaced, or obsoleted by other documents	months and may be updated, replaced, or obsoleted by other documents
	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-19.txt and expires September 30,	draft-ietf-cat-kerberos-pk-init-20.txt and expires January 25, 2005.
	2004. Please send comments to the authors.	Please send comments to the authors.

	1. Abstract	1. Abstract


	This document describes protocol extensions (hereafter called PKINIT)	This document describes protocol extensions (hereafter called
	to the Kerberos protocol specification (RFC 1510bis [1]). These	PKINIT) to the Kerberos protocol specification ([1], hereafter
	extensions provide a method for integrating public key cryptography	called CLARIFICATIONS). These extensions provide a method for
	into the initial authentication exchange, by passing digital	integrating public key cryptography into the initial authentication
	certificates and associated authenticators in preauthentication data	exchange, by passing digital certificates and associated
	fields.	authenticators in preauthentication data 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 document, we will	a Kerberos Key Distribution Center, or KDC. (In this document, we
	refer to both the AS and the TGS as the KDC.) Finally, the client	will refer to both the AS and the TGS as the KDC.) Finally, the
	uses the service ticket to authenticate itself to the service.	client uses the service ticket to authenticate itself to the
		service.


	The advantage afforded by the TGT is that the client need	The advantage afforded by the TGT is that the client need explicitly
	explicitly request a ticket and expose his credentials only once. The	request a ticket and expose his credentials only once. The TGT and
	TGT and its associated session key can then be used for any	its associated session key can then be used for any subsequent
	subsequent requests. One result of this is that all further	requests. One result of this is that all further authentication is
	authentication is independent of the method by which the initial	independent of the method by which the initial authentication was
	authentication was performed. Consequently, initial authentication	performed. Consequently, initial authentication provides a
	provides a convenient place to integrate public-key cryptography	convenient place to integrate public-key cryptography into Kerberos
	into Kerberos authentication.	authentication.

	As defined, Kerberos authentication exchanges use symmetric-key	As defined, Kerberos authentication exchanges use symmetric-key
	cryptography, in part for performance. One cost of using	cryptography, in part for performance. 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 client can authenticate itself, 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 Public Key Infrastructure) permits authentication	established Public Key Infrastructure) permits authentication

	without prior registration with a KDC. Adding it to Kerberos allows the	without prior registration with a KDC. Adding it to Kerberos allows
	widespread use of Kerberized applications by clients without requiring	the widespread use of Kerberized applications by clients without
	them to register first with a KDC: a requirement that has no inherent	requiring them to register first with a KDC--a requirement that has
	security benefit.	no inherent security benefit.

	As noted above, a convenient and efficient place to introduce	As noted above, a convenient and efficient place to introduce
	public-key cryptography into Kerberos is in the initial	public-key cryptography into Kerberos is in the initial
	authentication exchange. This document describes the methods and	authentication exchange. This document describes the methods and
	data formats for integrating public-key cryptography into Kerberos	data formats for integrating public-key cryptography into Kerberos
	initial authentication.	initial authentication.

	3. Extensions	3. Extensions


	This section describes extensions to RFC 1510bis for supporting the	This section describes extensions to CLARIFICATIONS for supporting
	use of public-key cryptography in the initial request for a ticket.	the use of public-key cryptography in the initial request for a
		ticket.


	Briefly, this document defines the following extensions to RFC 1510bis:	Briefly, this document defines the following extensions to
		CLARIFICATIONS:

	1. The client indicates the use of public-key authentication by	1. The client indicates the use of public-key authentication by
	including a special preauthenticator in the initial request.	including a special preauthenticator in the initial request.
	This preauthenticator contains the client's public-key data	This preauthenticator contains the client's public-key data
	and a signature.	and a signature.


	2. 2. The KDC tests the client's request against its policy and	2. The KDC tests the client's request against its policy and
	trusted Certification Authorities (CAs).	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 symmetric encryption key, signed using the KDC?s	a. a symmetric encryption key, signed using the KDC's
	signature key and encrypted using the client?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 keying material required by the client to obtain the	Any keying material required by the client to obtain the

	Encryption key is returned in a preauthentication field in	Encryption key is returned in a preauthentication field
	the usual reply.	accompanying 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.

	3.1. Definitions	3.1. Definitions

	3.1.1. Required Algorithms	3.1.1. Required Algorithms

	All PKINIT implementations MUST support the following algorithms:	All PKINIT implementations MUST support the following algorithms:


	- Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype;	- Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype.


	- Signature algorithm: SHA-1 digest and RSA;	- Signature algorithm: SHA-1 digest and RSA.

	- Reply key delivery method: ephemeral-ephemeral Diffie-Hellman	- Reply key delivery method: ephemeral-ephemeral Diffie-Hellman

	with a non-zero nonce;	with a non-zero nonce.

	- Unkeyed checksum type for the paChecksum member of	- 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-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 codes:	PKINIT introduces the following new error codes:

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

	skipping to change at line 187 ¶	skipping to change at line 193 ¶
	rc2CBC-EnvOID 12	rc2CBC-EnvOID 12
	rsaEncryption-EnvOID (PKCS1 v1.5) 13	rsaEncryption-EnvOID (PKCS1 v1.5) 13
	rsaES-OAEP-EnvOID (PKCS1 v2.0) 14	rsaES-OAEP-EnvOID (PKCS1 v2.0) 14
	des-ede3-cbc-EnvOID 15	des-ede3-cbc-EnvOID 15

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


		The ASN.1 module for all structures defined in this document (plus
		IMPORT statements for all imported structures) are given in Appendix
		A. All structures MUST be encoded using Distinguished Encoding
		Rules (DER).

	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 [9]:	key agreement [9]:

	dhpublicnumber	dhpublicnumber


	skipping to change at line 228 ¶	skipping to change at line 239 ¶
	Kerberos etype (defined in section 3.1.2).	Kerberos etype (defined in section 3.1.2).

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

	This section defines the syntax and use of the various	This section defines the syntax and use of the various
	preauthentication fields employed by PKINIT.	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; the preauthentication field contains data signed by the	1510bis; in addition, a preauthentication field contains data signed
	client's private signature key as follows:	by the client's private signature key, as follows:

	PA-PK-AS-REQ ::= SEQUENCE {	PA-PK-AS-REQ ::= SEQUENCE {
	signedAuthPack [0] ContentInfo,	signedAuthPack [0] ContentInfo,
	-- Defined in CMS [2].	-- Defined in CMS [2].
	-- Type is SignedData.	-- Type is SignedData.
	-- Content is AuthPack	-- Content is AuthPack
	-- (defined below).	-- (defined below).
	trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,	trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,
	-- A list of CAs, trusted by	-- A list of CAs, trusted by
	-- the client, used to certify	-- the client, used to certify
	-- KDCs.	-- KDCs.
	kdcCert [2] IssuerAndSerialNumber OPTIONAL,	kdcCert [2] IssuerAndSerialNumber OPTIONAL,
	-- Defined in CMS [2].	-- 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,
	-- May identify the client's
	-- Diffie-Hellman certificate,
	-- or an RSA encryption key
	-- certificate.
	...	...
	}	}

	TrustedCA ::= CHOICE {	TrustedCA ::= CHOICE {
	caName [0] Name,	caName [0] Name,
	-- Fully qualified X.500 name	-- Fully qualified X.500 name
	-- as defined in RFC 3280 [4].	-- as defined in RFC 3280 [4].

	issuerAndSerial [1] IssuerAndSerialNumber,	issuerAndSerial [2] IssuerAndSerialNumber,
	-- Identifies a specific CA	-- Identifies a specific CA
	-- certificate.	-- certificate.
	...	...
	}	}

	AuthPack ::= SEQUENCE {	AuthPack ::= SEQUENCE {
	pkAuthenticator [0] PKAuthenticator,	pkAuthenticator [0] PKAuthenticator,
	clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,	clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
	-- Defined in RFC 3280 [4].	-- Defined in RFC 3280 [4].
	-- Present only if the client	-- Present only if the client
	-- is using ephemeral-ephemeral	-- is using ephemeral-ephemeral
	-- Diffie-Hellman.	-- Diffie-Hellman.

		supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
		OPTIONAL,
		-- List of CMS encryption types
		-- supported by client in order
		-- of (decreasing) preference.
	...	...
	}	}

	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 CLARIFICATIONS, for replay
	-- prevention.	-- prevention.

	nonce [2] INTEGER,	nonce [2] INTEGER (0..4294967295),
	-- Binds reply to request,	-- Binds reply to request,
	-- MUST be zero when client	-- MUST be zero when client
	-- will accept cached	-- will accept cached
	-- Diffie-Hellman parameters	-- Diffie-Hellman parameters
	-- from KDC. MUST NOT be	-- from KDC. MUST NOT be
	-- zero otherwise.	-- zero otherwise.

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

	-- Defined in RFC 1510bis [1].	-- Defined in CLARIFICATIONS.
	-- Performed over KDC-REQ-BODY,	-- Performed over KDC-REQ-BODY,
	-- MUST be unkeyed.	-- MUST be unkeyed.
	...	...
	}	}


	IMPORTS
	-- from RFC 3280 [4]
	SubjectPublicKeyInfo, AlgorithmIdentifier, Name
	FROM PKIX1Explicit88 { iso (1) identified-organization (3)
	dod (6) internet (1) security (5) mechanisms (5)
	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
	client'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)	id-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 over 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 over the AuthPack. Additionally, the	verify the signature over the AuthPack. Additionally, the
	client MAY 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.

	skipping to change at line 357 ¶	skipping to change at line 346 ¶

	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 client 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 TYPED-DATA:	e-data for this error is a SEQUENCE OF TYPED-DATA (as defined in RFC
		1510bis). For this error, the data-type is TD-TRUSTED-CERTIFIERS,
	TYPED-DATA ::= SEQUENCE {	and the data-value is an OCTET STRING containing the DER encoding of
	-- As defined in RFC 1510bis.
	data-type [0] INTEGER,
	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
	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 TYPED-DATA,	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 ::= IssuerAndSerialNumber	CertificateIndex ::= IssuerAndSerialNumber
	-- IssuerAndSerialNumber of	-- IssuerAndSerialNumber of
	-- certificate with invalid signature	-- certificate with invalid signature


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


	The KDC MAY also check whether any of the certificates in the client's	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	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	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).

	In addition to validating the certificate chain, the KDC MUST also	In addition to validating the certificate chain, the KDC MUST also
	check that the certificate properly maps to the client's principal name	check that the certificate properly maps to the client's principal name
	as specified in the AS-REQ as follows:	as specified in the AS-REQ as follows:

	1. If the KDC has its own mapping from the name in the	1. If the KDC has its own mapping from the name in the
	certificate to a Kerberos name, it uses that Kerberos	certificate to a Kerberos name, it uses that Kerberos
	name.	name.

	2. Otherwise, if the certificate contains a SubjectAltName	2. Otherwise, if the certificate contains a SubjectAltName
	extension with a Kerberos name in the otherName field,	extension with a Kerberos name in the otherName field,

	it uses that name. The otherName field (of type AnotherName) in	it uses that name. The otherName field (of type AnotherName)
	the SubjectAltName extension MUST contain the following:	in the SubjectAltName extension MUST contain the following:

	The type-id is:	The type-id is:

	krb5PrincipalName OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6)	krb5PrincipalName OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6)
	internet (1) security (5) kerberosv5 (2) 2 }	internet (1) security (5) kerberosv5 (2) 2 }

	The value is:	The value is:

	KRB5PrincipalName ::= SEQUENCE {	KRB5PrincipalName ::= SEQUENCE {
	realm [0] Realm,	realm [0] Realm,
	principalName [1] PrincipalName	principalName [1] PrincipalName
	}	}


	IMPORTS
	-- from RFC 3280 [4]
	GeneralName
	FROM PKIX1Explicit88 { iso (1) identified-organization (3)
	dod (6) internet (1) security (5) mechanisms (5)
	pkix (7) id-mod (0) id-pkix1-explicit (18) }

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

	If the KDC does not have its own mapping and there is no Kerberos	If the KDC does not have its own mapping and there is no Kerberos
	name present in the certificate, or if the name in the request does	name present in the certificate, or if the name in the request does
	not match the name in the certificate (including the realm name), or	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	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	KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data

	for this error. If the name in the request is [special "blank"	for this error.
	name], the KDC MAY insert a different name in the reply.

	Even if the chain is validated, and the names in the certificate and	Even if the chain is validated, and the names in the certificate and
	the request match, the KDC may decide not to trust the client. For	the request match, the KDC may decide not to trust the client. For
	example, the certificate may include an Enxtended Key Usage (EKU) OID	example, the certificate may include an Enxtended Key Usage (EKU) OID
	in the extensions field. As a matter of local policy, the KDC may	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	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	specific EKU OIDs. In this case, the KDC MUST return error code
	KDC_ERR_CLIENT_NOT_TRUSTED. The PKINIT EKU OID is defined as:	KDC_ERR_CLIENT_NOT_TRUSTED. The PKINIT EKU OID is defined as:


	{ iso (1) org (3) dod (6) internet (1) security (5)	{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
	kerberosv5 (2) pkinit (3) pkekuoid (4) }	pkinit(3) pkekuoid(4) }

	If the client's signature on the signedAuthPack fails to verify, the KDC	If the client's signature on the signedAuthPack fails to verify, the KDC
	MUST return error KDC_ERR_INVALID_SIG. There is no accompanying	MUST return error KDC_ERR_INVALID_SIG. There is no accompanying
	e-data for this error.	e-data for this error.

	The KDC MUST check the timestamp to ensure that the request is not	The KDC MUST check the timestamp to ensure that the request is not
	a replay, and that the time skew falls within acceptable limits.	a replay, and that the time skew falls within acceptable limits.

	The recommendations clock skew times in RFC 1510bis [1] apply here.	The recommendations clock skew times in CLARIFICATIONS apply here.
	If the check fails, the KDC MUSTreturn error code KRB_AP_ERR_REPEAT	If the check fails, the KDC MUSTreturn error code KRB_AP_ERR_REPEAT
	or KRB_AP_ERR_SKEW, respectively.	or KRB_AP_ERR_SKEW, respectively.


	If the clientPublicValue is filled in, indicating that the	If the clientPublicValue is filled in, indicating that the client
	client wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC	wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC checks to
	checks to see if the parameters satisfy its policy. If they do not,	see if the parameters satisfy its policy. If they do not, it MUST
	it MUST return error code KDC_ERR_KEY_SIZE. The accompanying e-data is	return error code KDC_ERR_KEY_SIZE. The accompanying e-data is a
	a SEQUENCE OF TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and whose	SEQUENCE OF TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and
	data-value is an OCTET STRING containing the DER encoding of a	whose data-value is an OCTET STRING containing the DER encoding of a
	DomainParameters (see [3]), including appropriate Diffie-Hellman	DomainParameters (see [3]), including appropriate Diffie-Hellman
	parameters with which to retry the request.	parameters with which to retry the request.

	The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the	The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the

	client included a kdcCert field in the PA-PK-AS-REQ and the KDC does not	client included a kdcCert field in the PA-PK-AS-REQ and the KDC does
	have the corresponding certificate.	not have the corresponding certificate.


	The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client did	The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client
	not include a kdcCert field, but did include a trustedCertifiers field,	did not include a kdcCert field, but did include a trustedCertifiers
	and the KDC does not possesses a certificate issued by one of the listed	field, and the KDC does not possesses a certificate issued by one of
	certifiers.	the listed certifiers.

		If there is a supportedCMSTypes field in the AuthPack, the KDC must
		check to see if it supports any of the listed types. If it supports
		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	3.2.3. KDC Reply

	Assuming that the client's request has been properly validated, the	Assuming that the client's request has been properly validated, the

	KDC proceeds as per RFC 1510bis, except as follows.	KDC proceeds as per CLARIFICATIONS, except as follows.


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

	InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {	InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
	ca [0] Name,	ca [0] Name,
	Validated [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	Application servers that understand this authorization data type
	local policy to determine whether a given ticket bearing such a type	SHOULD apply local policy to determine whether a given ticket
	(not contained within an AD-IF-RELEVANT container) is acceptable.	bearing such a type not contained within an AD-IF-RELEVANT
	(This corresponds to the AP server checking the transited field when	container is acceptable. (This corresponds to the AP server
	the TRANSITED-POLICY-CHECKED flag has not been set.) If such a data	checking the transited field when the TRANSITED-POLICY-CHECKED flag
	type is contained within an AD-IF-RELEVANT container, AP servers	has not been set.) If such a data type is contained within an
	MAY apply local policy to determine whether the authorization	AD-IF-RELEVANT container, AP servers MAY apply local policy to
	data is acceptable.	determine whether the authorization data is acceptable.


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

	PA-PK-AS-REP ::= CHOICE {	PA-PK-AS-REP ::= CHOICE {
	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 SignedData.	-- Type is EnvelopedData.
	-- Content is ReplyKeyPack	-- Content is SignedData over
	-- (defined below).	-- ReplyKeyPack (defined below).
	...	...
	}	}

	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,

	skipping to change at line 558 ¶	skipping to change at line 525 ¶
	-- cached values.	-- cached values.
	...	...
	}	}

	The fields of the ContentInfo for dhSignedData are to be filled in	The fields of the ContentInfo for dhSignedData are to be filled in
	as follows:	as follows:

	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)	id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
	security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2) }	security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }

	3. The 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 will use to verify the	certificate chain that the client will use to verify the
	KDC's signature over the KDCDHKeyInfo. This field may only	KDC's signature over the KDCDHKeyInfo. This field may only
	be left empty if the client did include a kdcCert field in	be left empty if the client did include a kdcCert field in

	the PA-PK-AS-REQ, indicating that it has the KDC's certificate.	the PA-PK-AS-REQ, indicating that it has the KDC's
		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 MUST 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 MUST NOT use	field. If this time is exceeded, the client MUST NOT use
	the reply. If the time is absent, the client MUST 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 [6]. The seed is then converted into a protocol key by	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	applying to it a random-to-key function, which is also dependent on
	key type.	key type.


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

	2. If the encryption type is three-key 3DES with HMAC-SHA1,
	k = 168 bits and the random-to-key function is
	DES3random-to-key as defined in [6]. This function inserts
	parity bits to create a 192-bit 3DES protocol key that is
	compliant with FIPS PUB 74 [9]. This key is used to
	generate additional keys Ke and Ki, for encryption and
	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 CLARIFICATIONS.
	-- Used to encrypt main reply.	-- Used to encrypt main reply.
	-- MUST be at least as strong	-- MUST be at least as strong
	-- as session key. (Using the	-- as session key. (Using the
	-- same enctype and a strong	-- same enctype and a strong
	-- prng should suffice, if no	-- prng should suffice, if no
	-- stronger encryption system	-- stronger encryption system
	-- is available.)	-- is available.)

	nonce [1] INTEGER,	nonce [1] INTEGER (0..4294967295),
	-- Binds reply to request.	-- Binds reply to request.

	-- 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 content is of type SignedData. The eContent for	1. The content is of type SignedData. The eContent for
	the SignedData is of type ReplyKeyPack.	the SignedData is of type ReplyKeyPack.


	2. The eContentType for the SignedData contains the OID value for	2. The eContentType for the SignedData contains the OID value
	pkrkeydata: { iso (1) org (3) dod (6) internet (1)	for id-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 that the client will use to verify the	certificate chain that the client will use to verify the
	KDC's signature over the ReplyKeyPack. This field may only	KDC's signature over the ReplyKeyPack. This field may only

	be left empty if the client did include a kdcCert field in	be left empty if the client included a kdcCert field in the
	the PA-PK-AS-REQ, indicating that it has the KDC's certificate.	PA-PK-AS-REQ, indicating that it has the KDC's certificate.


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

	6. 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.


	7. The unprotectedAttrs or originatorInfo fields MAY be present.	7. The unprotectedAttrs or originatorInfo fields MAY be
		present.

	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
	resulting key, and then proceeds as described in RFC 1510bis.

	3.2.5. Support for OCSP


	OCSP (Online Certificate Status Protocol) [8] allows the use of	In either case, the client MUST check to see if the included
	on-line requests for a client or server to determine the validity of	certificate contains a subjectAltName extension of type dNSName or
	each other's certificates. It is particularly useful for clients	iPAddress (if the KDC is specified by IP address instead of name).
	authenticating each other across a constrained network. These	If it does, it MUST check to see if that extension matches the KDC
	clients will not have to download the entire CRL to check for the	it believes it is communicating with, with matching rules specified
	validity of the KDC's certificate.	in RFC 2459. Exception: If the client has some external information
		as to the identity of the KDC, this check MAY be omitted.
	In these cases, the KDC generally has better connectivity to the
	OCSP server, and it therefore processes the OCSP request and
	response and sends the results to the client. The mechanism defined
	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
	handled in [7].

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

	PA-PK-OCSP-REQ ::= SEQUENCE {
	-- PAType TBD
	responderIDList [0] SEQUENCE of ResponderID OPTIONAL,
	-- ResponderID is a DER-encoded
	-- ASN.1 type defined in [8]
	requestExtensions [1] Extensions OPTIONAL
	-- Extensions is a DER-encoded
	-- ASN.1 type defined in [8]
	}

	PA-PK-OCSP-REP ::= SEQUENCE of OCSPResponse
	-- OCSPResponse is a DER-encoded
	-- ASN.1 type defined in [8]


	A KDC that receives a PA-PK-OCSP-REQ MAY send a PA-PK-OCSP-REP.	The client also MUST check that the KDC's certificate contains an
	KDCs MUST NOT send a PA-PK-OCSP-REP if they do not first receive a	extendedKeyUsage OID of id-pkkdcekuoid:
	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.


	In the case that a responderIDList is not sent or is empty, the OCSP	{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
	response must be signed by the authority that issued the	pkinit(3) pkkdcekuoid(5) }
	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	If all applicable checks are satisfied, the client then decrypts the
	trusted by the client. Depending on local policy, further	main reply with the resulting key, and then proceeds as described in
	verification of the validity of the OCSP server may need to be done.	CLARIFICATIONS.

	4. Security Considerations	4. Security Considerations

	PKINIT raises certain security considerations beyond those that can	PKINIT raises certain security considerations beyond those that can
	be regulated strictly in protocol definitions. We will address them	be regulated strictly in protocol definitions. We will address them
	in this section.	in this section.

	PKINIT extends the cross-realm model to the public-key	PKINIT extends the cross-realm model to the public-key
	infrastructure. Users of PKINIT must understand security policies	infrastructure. Users of PKINIT must understand security policies
	and procedures appropriate to the use of Public Key Infrastructures.	and procedures appropriate to the use of Public Key Infrastructures.

	Standard Kerberos allows the possibility of interactions between	Standard Kerberos allows the possibility of interactions between
	cryptosystems of varying strengths; this document adds interactions	cryptosystems of varying strengths; this document adds interactions
	with public-key cryptosystems to Kerberos. Some administrative	with public-key cryptosystems to Kerberos. Some administrative
	policies may allow the use of relatively weak public keys. Using	policies may allow the use of relatively weak public keys. Using
	such keys to wrap data encrypted under stronger conventional	such keys to wrap data encrypted under stronger conventional
	cryptosystems may be inappropriate.	cryptosystems may be inappropriate.

	PKINIT requires keys for symmetric cryptosystems to be generated.	PKINIT requires keys for symmetric cryptosystems to be generated.
	Some such systems contain "weak" keys. For recommendations regarding	Some such systems contain "weak" keys. For recommendations regarding

	these weak keys, see RFC 1510bis.	these weak keys, see CLARIFICATIONS.

	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 keys are used. In this case, message binding	cached Diffie-Hellman keys are used. In this case, message binding
	is performed using the nonce in the main request in the same way as	is performed using the nonce in the main request in the same way as
	it is done for ordinary AS-REQs (without the PKINIT	it is done for ordinary AS-REQs (without the PKINIT
	pre-authenticator). The nonce field in the KDC request body is	pre-authenticator). The nonce field in the KDC request body is
	signed through the checksum in the PKAuthenticator, which	signed through the checksum in the PKAuthenticator, which

	cryptographically binds the PKINIT pre-authenticator to the main body	cryptographically binds the PKINIT pre-authenticator to the main
	of the AS Request and also provides message integrity for the full	body of the AS Request and also provides message integrity for the
	AS Request.	full AS Request.

	However, when a PKINIT pre-authenticator in the AS-REP has a	However, when a PKINIT pre-authenticator in the AS-REP has a
	zero-nonce, and an attacker has somehow recorded this	zero-nonce, and an attacker has somehow recorded this
	pre-authenticator and discovered the corresponding Diffie-Hellman	pre-authenticator and discovered the corresponding Diffie-Hellman
	private key (e.g., with a brute-force attack), the attacker will be	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	able to fabricate his own AS-REP messages that impersonate the KDC
	with this same pre-authenticator. This compromised pre-authenticator	with this same pre-authenticator. This compromised pre-authenticator
	will remain valid as long as its expiration time has not been reached	will remain valid as long as its expiration time has not been reached
	and it is therefore important for clients to check this expiration	and it is therefore important for clients to check this expiration
	time and for the expiration time to be reasonably short, which	time and for the expiration time to be reasonably short, which
	depends on the size of the Diffie-Hellman group.	depends on the size of the Diffie-Hellman group.

	If a client also caches its Diffie-Hellman keys, then the session key	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	could remain the same during multiple AS-REQ/AS-REP exchanges and an
	attacker which compromised the session key could fabricate his own	attacker which compromised the session key could fabricate his own
	AS-REP messages with a pre-recorded pre-authenticator until the	AS-REP messages with a pre-recorded pre-authenticator until the
	client starts using a new Diffie-Hellman key pair and while the KDC	client starts using a new Diffie-Hellman key pair and while the KDC
	pre-authenticator has not yet expired. It is therefore not	pre-authenticator has not yet expired. It is therefore not
	recommended for KDC clients to also cache their Diffie-Hellman keys.	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 used for certain certificate types. Deployers of	that key escrow be used for certain certificate types. Deployers of
	PKINIT should be aware of the implications of using certificates that	PKINIT should be aware of the implications of using certificates that
	have escrowed keys for the purposes of authentication.	have escrowed keys for the purposes of authentication.

	PKINIT does not provide for a "return routability" test to prevent	PKINIT does not provide for a "return routability" test to prevent
	attackers from mounting a denial-of-service attack on the KDC by	attackers from mounting a denial-of-service attack on the KDC by
	causing it to perform unnecessary and expensive public-key	causing it to perform unnecessary and expensive public-key
	operations. Strictly speaking, this is also true of standard	operations. Strictly speaking, this is also true of standard
	Kerberos, although the potential cost is not as great, because	Kerberos, although the potential cost is not as great, because
	standard Kerberos does not make use of public-key cryptography.	standard Kerberos does not make use of public-key cryptography.


		The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
		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

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


	This draft expires September 30, 2004.	This draft expires January 25, 2004.

	7. Bibliography	7. Bibliography

	[1] RFC-Editor: To be replaced by RFC number for	[1] RFC-Editor: To be replaced by RFC number for
	draft-ietf-krb-wg-kerberos-clarifications.	draft-ietf-krb-wg-kerberos-clarifications.

	[2] R. Housley. Cryptographic Message Syntax., April 1999.	[2] R. Housley. Cryptographic Message Syntax., April 1999.
	Request For Comments 2630.	Request For Comments 2630.

	[3] W. Polk, R. Housley, and L. Bassham. Algorithms and Identifiers	[3] W. Polk, R. Housley, and L. Bassham. Algorithms and Identifiers

	skipping to change at line 866 ¶	skipping to change at line 785 ¶
	E-mail: smedvinsky@motorola.com	E-mail: smedvinsky@motorola.com

	John Wray	John Wray
	Iris Associates, Inc.	Iris Associates, Inc.
	5 Technology Park Dr.	5 Technology Park Dr.
	Westford, MA 01886	Westford, MA 01886
	E-mail: John_Wray@iris.com	E-mail: John_Wray@iris.com

	Jonathan Trostle	Jonathan Trostle
	E-mail: jtrostle@world.std.com	E-mail: jtrostle@world.std.com


		Appendix A. PKINIT ASN.1 Module

		KerberosV5-PK-INIT-SPEC {
		iso(1) identified-organization(3) dod(6) internet(1)
		security(5) kerberosV5(2) modules(4) pkinit(TBD)
		} DEFINITIONS EXPLICIT TAGS ::= BEGIN

		IMPORTS
		SubjectPublicKeyInfo, AlgorithmIdentifier, Name
		FROM PKIX1Explicit88 { iso (1) identified-organization (3)
		dod (6) internet (1) security (5) mechanisms (5)
		pkix (7) id-mod (0) id-pkix1-explicit (18) }

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

		KerberosTime, Checksum, TYPED-DATA, PrincipalName, Realm, EncryptionKey
		FROM KerberosV5Spec2 { iso(1) identified-organization(3)
		dod(6) internet(1) security(5) kerberosV5(2) modules(4)
		krb5spec2(2) } ;

		id-pkinit OBJECT IDENTIFIER ::=
		{ iso (1) org (3) dod (6) internet (1) security (5)
		kerberosv5 (2) pkinit (3) }

		id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 1 }
		id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 }
		id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 }
		id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 }
		id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 }

		pa-pk-as-req INTEGER ::= TBD
		pa-pk-as-rep INTEGER ::= TBD
		pa-pk-ocsp-req INTEGER ::= TBD
		pa-pk-ocsp-rep INTEGER ::= TBD

		ad-initial-verified-cas INTEGER ::= TBD

		td-dh-parameters INTEGER ::= TBD
		td-trusted-certifiers INTEGER ::= 104
		td-certificate-index INTEGER ::= 105

		PA-PK-AS-REQ ::= SEQUENCE {
		signedAuthPack [0] ContentInfo,
		trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,
		kdcCert [2] IssuerAndSerialNumber OPTIONAL,
		...
		}

		TrustedCA ::= CHOICE {
		caName [0] Name,
		issuerAndSerial [2] IssuerAndSerialNumber,
		...
		}

		AuthPack ::= SEQUENCE {
		pkAuthenticator [0] PKAuthenticator,
		clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
		supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
		OPTIONAL,
		...
		}

		PKAuthenticator ::= SEQUENCE {
		cusec [0] INTEGER,
		ctime [1] KerberosTime,
		nonce [2] INTEGER (0..4294967295),
		paChecksum [3] Checksum,
		...
		}

		TrustedCertifiers ::= SEQUENCE OF Name

		CertificateIndex ::= IssuerAndSerialNumber

		KRB5PrincipalName ::= SEQUENCE {
		realm [0] Realm,
		principalName [1] PrincipalName
		}

		InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
		ca [0] Name,
		validated [1] BOOLEAN,
		...
		}

		PA-PK-AS-REP ::= CHOICE {
		dhSignedData [0] ContentInfo,
		encKeyPack [1] ContentInfo,
		...
		}

		KDCDHKeyInfo ::= SEQUENCE {
		subjectPublicKey [0] BIT STRING,
		nonce [1] INTEGER,
		dhKeyExpiration [2] KerberosTime OPTIONAL,
		...
		}

		ReplyKeyPack ::= SEQUENCE {
		replyKey [0] EncryptionKey,
		nonce [1] INTEGER (0..4294967295),
		...
		}

		END

		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.

		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.

End of changes. 65 change blocks.
	237 lines changed or deleted	156 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/