< draft-ietf-cat-kerberos-pk-init-31.txt		draft-ietf-cat-kerberos-pk-init-32.txt >
	NETWORK WORKING GROUP L. Zhu		NETWORK WORKING GROUP L. Zhu
	Internet-Draft Microsoft Corporation		Internet-Draft Microsoft Corporation
	Expires: June 24, 2006 B. Tung		Expires: July 15, 2006 B. Tung
	USC Information Sciences Institute		USC Information Sciences Institute
	December 21, 2005		January 11, 2006
	Public Key Cryptography for Initial Authentication in Kerberos		Public Key Cryptography for Initial Authentication in Kerberos
	draft-ietf-cat-kerberos-pk-init-31		draft-ietf-cat-kerberos-pk-init-32
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on June 24, 2006.		This Internet-Draft will expire on July 15, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document describes protocol extensions (hereafter called PKINIT)		This document describes protocol extensions (hereafter called PKINIT)
	to the Kerberos protocol specification. These extensions provide a		to the Kerberos protocol specification. These extensions provide a
	method for integrating public key cryptography into the initial		method for integrating public key cryptography into the initial
	authentication exchange, by using asymmetric-key signature and/or		authentication exchange, by using asymmetric-key signature and/or
	encryption algorithms in pre-authentication data fields.		encryption algorithms in pre-authentication data fields.
	Table of Contents		Table of Contents
	skipping to change at page 7, line 24 ¶		skipping to change at page 7, line 24 ¶
	KDC_ERR_CLIENT_NOT_TRUSTED 62		KDC_ERR_CLIENT_NOT_TRUSTED 62
	KDC_ERR_INVALID_SIG 64		KDC_ERR_INVALID_SIG 64
	KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65		KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65
	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
	KDC_ERR_INCONSISTENT_KEY_PURPOSE 77		KDC_ERR_INCONSISTENT_KEY_PURPOSE 77
	KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED 78		KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED 78
	KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED 79		KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED 79
	KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED 80		KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED 80
	PKINIT uses the following typed data types for errors:		PKINIT uses the following typed data types for errors:
	TD_TRUSTED_CERTIFIERS 104		TD_TRUSTED_CERTIFIERS 104
	TD_INVALID_CERTIFICATES 105		TD_INVALID_CERTIFICATES 105
	TD_DH_PARAMETERS 109		TD_DH_PARAMETERS 109
	The ASN.1 module for all structures defined in this document (plus		The ASN.1 module for all structures defined in this document (plus
	IMPORT statements for all imported structures) is given in		IMPORT statements for all imported structures) is given in
	skipping to change at page 11, line 12 ¶		skipping to change at page 11, line 12 ¶
	...		...
	}		}
	PKAuthenticator ::= SEQUENCE {		PKAuthenticator ::= SEQUENCE {
	cusec [0] INTEGER (0..999999),		cusec [0] INTEGER (0..999999),
	ctime [1] KerberosTime,		ctime [1] KerberosTime,
	-- cusec and ctime are used as in [RFC4120], for		-- cusec and ctime are used as in [RFC4120], for
	-- replay prevention.		-- replay prevention.
	nonce [2] INTEGER (0..4294967295),		nonce [2] INTEGER (0..4294967295),
	-- Chosen randomly; This nonce does not need to		-- Chosen randomly; This nonce does not need to
	-- match with the nonce in the KDC-REQ-BODY.		-- match with the nonce in the KDC-REQ-BODY.
	paChecksum [3] OCTET STRING,		paChecksum [3] OCTET STRING OPTIONAL,
			-- MUST be present.
	-- Contains the SHA1 checksum, performed over		-- Contains the SHA1 checksum, performed over
	-- KDC-REQ-BODY.		-- KDC-REQ-BODY.
	...		...
	}		}
	The ContentInfo [RFC3852] structure contained in the signedAuthPack		The ContentInfo [RFC3852] structure contained in the signedAuthPack
	field of the type PA-PK-AS-REQ is encoded according to [RFC3852] and		field of the type PA-PK-AS-REQ is encoded according to [RFC3852] and
	is filled out as follows:		is filled out as follows:
	1. The contentType field of the type ContentInfo is id-signedData		1. The contentType field of the type ContentInfo is id-signedData
	skipping to change at page 12, line 10 ¶		skipping to change at page 12, line 11 ¶
	method. The supportedCMSTypes field specifies the list of CMS		method. The supportedCMSTypes field specifies the list of CMS
	encryption types supported by the client in order of (decreasing)		encryption types supported by the client in order of (decreasing)
	preference. The clientDHNonce field is described later in this		preference. The clientDHNonce field is described later in this
	section.		section.
	6. The ctime field in the PKAuthenticator structure contains the		6. The ctime field in the PKAuthenticator structure contains the
	current time on the client's host, and the cusec field contains		current time on the client's host, and the cusec field contains
	the microsecond part of the client's timestamp. The ctime and		the microsecond part of the client's timestamp. The ctime and
	cusec fields are used together to specify a reasonably accurate		cusec fields are used together to specify a reasonably accurate
	timestamp [RFC4120]. The nonce field is chosen randomly. The		timestamp [RFC4120]. The nonce field is chosen randomly. The
	paChecksum field contains a SHA1 checksum that is performed over		paChecksum field MUST be present and it contains a SHA1 checksum
	the KDC-REQ-BODY [RFC4120].		that is performed over the KDC-REQ-BODY [RFC4120]. In order to
			ease future migration from the use of SHA1, the paChecksum field
			is made optional syntactically: when the request is extended to
			negotiate hash algorithms, the new client wishing not to use SHA1
			will send the request in the extended message syntax without the
			paChecksum field. The KDC conforming to this specification MUST
			return a KRB-ERROR [RFC4120] message with the code
			KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED (see Section 3.2.3). That
			will allow a new client to retry with SHA1 if allowed by the
			local policy.
	7. The certificates field of the type SignedData contains		7. The certificates field of the type SignedData contains
	certificates intended to facilitate certification path		certificates intended to facilitate certification path
	construction, so that the KDC can verify the signature over the		construction, so that the KDC can verify the signature over the
	type AuthPack. For path validation, these certificates SHOULD be		type AuthPack. For path validation, these certificates SHOULD be
	sufficient to construct at least one certification path from the		sufficient to construct at least one certification path from the
	client certificate to one trust anchor acceptable by the KDC		client certificate to one trust anchor acceptable by the KDC
	[RFC4158]. The client MUST be capable of including such a set of		[RFC4158]. The client MUST be capable of including such a set of
	certificates if configured to do so. The certificates field MUST		certificates if configured to do so. The certificates field MUST
	NOT contain "root" CA certificates.		NOT contain "root" CA certificates.
	skipping to change at page 17, line 40 ¶		skipping to change at page 17, line 48 ¶
	kdcPkId field as if the client did not include one.		kdcPkId field as if the client did not include one.
	If the digest algorithm used by the id-pkinit-authData is not		If the digest algorithm used by the id-pkinit-authData is not
	acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120]		acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120]
	message with the code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED.		message with the code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED.
	The accompanying e-data MUST be encoded in TYPED-DATA although none		The accompanying e-data MUST be encoded in TYPED-DATA although none
	is defined at this point.		is defined at this point.
	3.2.3. Generation of KDC Reply		3.2.3. Generation of KDC Reply
			If the paChecksum filed in the request is not present, the KDC
			conforming to this specification MUST return a KRB-ERROR [RFC4120]
			message with the code KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED. The
			accompanying e-data MUST be encoded in TYPED-DATA (no error data is
			defined by this specification).
	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 [RFC4120], except as follows.		KDC proceeds as per [RFC4120], except as follows.
	The KDC MUST set the initial flag and include an authorization data		The KDC MUST set the initial flag and include an authorization data
	element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued		element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
	ticket. The ad-data [RFC4120] field contains the DER encoding of the		ticket. The ad-data [RFC4120] field contains the DER encoding of the
	type AD-INITIAL-VERIFIED-CAS:		type AD-INITIAL-VERIFIED-CAS:
	AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF		AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
	ExternalPrincipalIdentifier		ExternalPrincipalIdentifier
	skipping to change at page 22, line 32 ¶		skipping to change at page 22, line 46 ¶
	kcrypto profile [RFC3961] for the enctype of the AS reply key.		kcrypto profile [RFC3961] for the enctype of the AS reply key.
	4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be		4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
	the serverDHNonce; otherwise, let both n_c and n_k be empty octet		the serverDHNonce; otherwise, let both n_c and n_k be empty octet
	strings.		strings.
	5. The AS reply key k is:		5. The AS reply key k is:
	k = octetstring2key(DHSharedSecret | n_c | n_k)		k = octetstring2key(DHSharedSecret | n_c | n_k)
	If the hash algorithm used in the key derivation function (currently
	only octetstring2key() is defined) is not acceptable by the KDC, the
	KDC MUST return a KRB-ERROR [RFC4120] message with the code
	KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED. The accompanying e-data MUST be
	encoded in TYPED-DATA although none is defined at this point.
	3.2.3.2. Using Public Key Encryption		3.2.3.2. Using Public Key Encryption
	In this case, the PA-PK-AS-REP contains the encKeyPack field where		In this case, the PA-PK-AS-REP contains the encKeyPack field where
	the AS reply key is encrypted.		the AS reply key is encrypted.
	The ContentInfo [RFC3852] structure for the encKeyPack field is		The ContentInfo [RFC3852] structure for the encKeyPack field is
	filled in as follows:		filled in as follows:
	1. The contentType field of the type ContentInfo is id-envelopedData		1. The contentType field of the type ContentInfo is id-envelopedData
	(as defined in [RFC3852]), and the content field is an		(as defined in [RFC3852]), and the content field is an
	skipping to change at page 34, line 10 ¶		skipping to change at page 34, line 20 ¶
	}		}
	PKAuthenticator ::= SEQUENCE {		PKAuthenticator ::= SEQUENCE {
	cusec [0] INTEGER (0..999999),		cusec [0] INTEGER (0..999999),
	ctime [1] KerberosTime,		ctime [1] KerberosTime,
	-- cusec and ctime are used as in [RFC4120], for		-- cusec and ctime are used as in [RFC4120], for
	-- replay prevention.		-- replay prevention.
	nonce [2] INTEGER (0..4294967295),		nonce [2] INTEGER (0..4294967295),
	-- Chosen randomly; This nonce does not need to		-- Chosen randomly; This nonce does not need to
	-- match with the nonce in the KDC-REQ-BODY.		-- match with the nonce in the KDC-REQ-BODY.
	paChecksum [3] OCTET STRING,		paChecksum [3] OCTET STRING OPTIONAL,
			-- MUST be present.
	-- Contains the SHA1 checksum, performed over		-- Contains the SHA1 checksum, performed over
	-- KDC-REQ-BODY.		-- KDC-REQ-BODY.
	...		...
	}		}
	TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF		TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
	ExternalPrincipalIdentifier		ExternalPrincipalIdentifier
	-- Identifies a list of CAs trusted by the KDC.		-- Identifies a list of CAs trusted by the KDC.
	-- Each ExternalPrincipalIdentifier identifies a CA		-- Each ExternalPrincipalIdentifier identifies a CA
	-- or a CA certificate (thereby its public key).		-- or a CA certificate (thereby its public key).
	skipping to change at page 41, line 41 ¶		skipping to change at page 41, line 41 ¶
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2005). This document is subject		Copyright (C) The Internet Society (2006). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 12 change blocks.
	17 lines changed or deleted		28 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/