< draft-ietf-cat-kerberos-pk-init-30.txt		draft-ietf-cat-kerberos-pk-init-31.txt >
	NETWORK WORKING GROUP L. Zhu		NETWORK WORKING GROUP L. Zhu
	Internet-Draft Microsoft Corporation		Internet-Draft Microsoft Corporation
	Expires: June 2, 2006 B. Tung		Expires: June 24, 2006 B. Tung
	USC Information Sciences Institute		USC Information Sciences Institute
	November 29, 2005		December 21, 2005
	Public Key Cryptography for Initial Authentication in Kerberos		Public Key Cryptography for Initial Authentication in Kerberos
	draft-ietf-cat-kerberos-pk-init-30		draft-ietf-cat-kerberos-pk-init-31
	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 2, 2006.		This Internet-Draft will expire on June 24, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	This document describes protocol extensions (hereafter called PKINIT)		This document describes protocol extensions (hereafter called PKINIT)
	to the Kerberos protocol specification. These extensions provide a		to the Kerberos protocol specification. These extensions provide a
	method for integrating public key cryptography into the initial		method for integrating public key cryptography into the initial
	authentication exchange, by 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
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions Used in This Document . . . . . . . . . . . . . . 3		2. Conventions Used in This Document . . . . . . . . . . . . . . 5
	3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Definitions, Requirements, and Constants . . . . . . . . . 5		3.1. Definitions, Requirements, and Constants . . . . . . . . . 6
	3.1.1. Required Algorithms . . . . . . . . . . . . . . . . . 5		3.1.1. Required Algorithms . . . . . . . . . . . . . . . . . 6
	3.1.2. Defined Message and Encryption Types . . . . . . . . . 5		3.1.2. Defined Message and Encryption Types . . . . . . . . . 6
	3.1.3. Algorithm Identifiers . . . . . . . . . . . . . . . . 6		3.1.3. Algorithm Identifiers . . . . . . . . . . . . . . . . 7
	3.2. PKINIT Pre-authentication Syntax and Use . . . . . . . . . 7		3.2. PKINIT Pre-authentication Syntax and Use . . . . . . . . . 9
	3.2.1. Generation of Client Request . . . . . . . . . . . . . 7		3.2.1. Generation of Client Request . . . . . . . . . . . . . 9
	3.2.2. Receipt of Client Request . . . . . . . . . . . . . . 12		3.2.2. Receipt of Client Request . . . . . . . . . . . . . . 13
	3.2.3. Generation of KDC Reply . . . . . . . . . . . . . . . 16		3.2.3. Generation of KDC Reply . . . . . . . . . . . . . . . 17
	3.2.4. Receipt of KDC Reply . . . . . . . . . . . . . . . . . 22		3.2.4. Receipt of KDC Reply . . . . . . . . . . . . . . . . . 24
	3.3. Interoperability Requirements . . . . . . . . . . . . . . 24		3.3. Interoperability Requirements . . . . . . . . . . . . . . 25
	3.4. KDC Indication of PKINIT Support . . . . . . . . . . . . . 24		3.4. KDC Indication of PKINIT Support . . . . . . . . . . . . . 26
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 25		4. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 28		7.1. Normative References . . . . . . . . . . . . . . . . . . . 29
	7.2. Informative References . . . . . . . . . . . . . . . . . . 29		7.2. Informative References . . . . . . . . . . . . . . . . . . 31
	Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 29		Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 31
	Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 35		Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 36
	Appendix C. Miscellaneous Information about Microsoft Windows		Appendix C. Miscellaneous Information about Microsoft Windows
	PKINIT Implementations . . . . . . . . . . . . . . . 36		PKINIT Implementations . . . . . . . . . . . . . . . 38
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
	Intellectual Property and Copyright Statements . . . . . . . . . . 39		Intellectual Property and Copyright Statements . . . . . . . . . . 41
	1. Introduction		1. Introduction
	A client typically authenticates itself to a service in Kerberos		The Kerberos V5 protocol [RFC4120] involves use of a trusted third
	using three distinct though related exchanges. First, the client		party known as the Key Distribution Center (KDC) to negotiate shared
	requests a ticket-granting ticket (TGT) from the Kerberos		session keys between clients and services and provide mutual
	authentication server (AS). Then, it uses the TGT to request a		authentication between them.
	service ticket from the Kerberos ticket-granting server (TGS).
	Usually, the AS and TGS are integrated in a single device known as a
	Kerberos Key Distribution Center, or KDC. Finally, the client uses
	the service ticket to authenticate itself to the service.
	The advantage afforded by the TGT is that the client exposes his		The corner-stone of Kerberos V5 is the Ticket and the Authenticator.
	long-term secrets only once. The TGT and its associated session key		A Ticket encapsulates a symmetric key (the ticket session key) in an
	can then be used for any subsequent service ticket requests. One		envelope (a public message) intended for a specific service. The
			contents of the Ticket are encrypted with a symmetric key shared
			between the service principal and the issuing KDC. The encrypted
			part of the Ticket contains the client principal name, amongst other
			items. An Authenticator is a record that can be shown to have been
			recently generated using the ticket session key in the associated
			Ticket. The ticket session key is known by the client who requested
			the ticket. The contents of the Authenticator are encrypted with the
			associated ticket session key. The encrypted part of an
			Authenticator contains a timestamp and the client principal name,
			amongst other items.
			As shown in Figure 1 below, the Kerberos V5 protocol consists of the
			following message exchanges between the client and the KDC, and the
			client and the application service:
			- The Authentication Service (AS) Exchange
			The client obtains an "initial" ticket from the Kerberos
			authentication server (AS), typically a Ticket Granting Ticket
			(TGT). The AS-REQ message and the AS-REP message are the request
			and the reply message respectively between the client and the AS.
			- The Ticket Granting Service (TGS) Exchange
			The client subsequently uses the TGT to authenticate and request a
			service ticket for a particular service, from the Kerberos ticket-
			granting server (TGS). The TGS-REQ message and the TGS-REP
			message are the request and the reply message respectively between
			the client and the TGS.
			- The Client/Server Authentication Protocol (AP) Exchange
			The client then makes a request with an AP-REQ message, consisting
			of a service ticket and an authenticator that certifies the
			client's possession of the ticket session key. The server may
			optionally reply with an AP-REP message. AP exchanges typically
			negotiate session specific symmetric keys.
			Usually, the AS and TGS are integrated in a single device also known
			as the KDC.
			Figure 1: The Message Exchanges in the Kerberos V5 Protocol
			+--------------+
			+--------->| KDC |
			AS-REQ / +-------| |
			/ / +--------------+
			/ / ^ |
			/ |AS-REP / |
			| | / TGS-REQ + TGS-REP
			| | / /
			| | / /
			| | / +---------+
			| | / /
			| | / /
			| | / /
			| v / v
			++-------+------+ +-----------------+
			| Client +------------>| Application |
			| | AP-REQ | Server |
			| |<------------| |
			+---------------+ AP-REP +-----------------+
			In the AS exchange, the KDC reply contains the ticket session key,
			amongst other items, that is encrypted using a key (the AS reply key)
			shared between the client and the KDC. The AS reply key is typically
			derived from the client's password for human users. Therefore for
			human users the attack resistance strength of the Kerberos protocol
			is no stronger than the strength of their passwords.
			The use of asymmetric cryptography in the form of X.509 certificates
			[RFC3280] is popular for facilitating non-repudiation and perfect
			secrecy. An established Public Key Infrastructure (PKI) provides key
			management and key distribution mechanisms that can be used to
			establish authentication and secure communication. Adding public-key
			cryptography to Kerberos provides a nice congruence to public-key
			protocols, obviates the human users' burden to manage strong
			passwords, and allows Kerberized applications to take advantage of
			existing key services and identity management.
			The advantage afforded by the Kerberos TGT is that the client exposes
			his long-term secrets only once. The TGT and its associated session
			key can then be used for any subsequent service ticket requests. One
	result of this is that all further authentication is independent of		result of this is that all further authentication is independent of
	the method by which the initial authentication was performed.		the method by which the initial authentication was performed.
	Consequently, initial authentication provides a convenient place to		Consequently, initial authentication provides a convenient place to
	integrate public-key cryptography into Kerberos authentication.		integrate public-key cryptography into Kerberos authentication. In
			addition, the use of symmetric cryptography after the initial
	As defined in [RFC4120], Kerberos authentication exchanges use		exchange is preferred for performance.
	symmetric-key cryptography, in part for performance. One
	disadvantage of using symmetric-key cryptography is that the keys
	must be shared, so that before a client can authenticate itself, he
	must already be registered with the KDC.
	Conversely, public-key cryptography (in conjunction with an
	established Public Key Infrastructure) permits authentication without
	prior registration with a KDC. Adding it to Kerberos allows the
	widespread use of Kerberized applications by clients without
	requiring them to register first with a KDC--a requirement that has
	no inherent security benefit.
	As noted above, a convenient and efficient place to introduce public-		This document describes the methods and data formats using which the
	key cryptography into Kerberos is in the initial authentication		client and the KDC can use public and private key pairs to mutually
	exchange. This document describes the methods and data formats for		authenticate in the AS exchange and negotiate the AS reply key, known
	integrating public-key cryptography into Kerberos initial		only by the client and the KDC, to encrypt the AS-REP sent by the
	authentication.		KDC.
	2. Conventions Used in This Document		2. Conventions Used in This Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	Both the AS and the TGS are referred to as the KDC.		In this protocol, both the client and the KDC have a public-private
			key pair in order to prove their identities to each other over the
			open network. The term "signature key" is used to refer to the
			private key of the key pair being used.
	In this document, the encryption key used to encrypt the enc-part		The encryption key used to encrypt the enc-part field of the KDC-REP
	field of the KDC-REP in the AS-REP [RFC4120] is referred to as the AS		in the AS-REP [RFC4120] is referred to as the AS reply key.
	reply key.
	In this document, an empty sequence in an optional field can be		An empty sequence in an optional field can be either included or
	either included or omitted: both encodings are permitted and		omitted: both encodings are permitted and considered equivalent.
	considered equivalent.
	In this document, the term "Modular Exponential Diffie-Hellman" is		The term "Modular Exponential Diffie-Hellman" is used to refer to the
	used to refer to the Diffie-Hellman key exchange as described in		Diffie-Hellman key exchange as described in [RFC2631], in order to
	[RFC2631], in order to differentiate it from other equivalent		differentiate it from other equivalent representations of the same
	representations of the same key agreement algorithm.		key agreement algorithm.
	3. Extensions		3. Extensions
	This section describes extensions to [RFC4120] for supporting the use		This section describes extensions to [RFC4120] for supporting the use
	of public-key cryptography in the initial request for a ticket.		of public-key cryptography in the initial request for a ticket.
	Briefly, this document defines the following extensions to [RFC4120]:		Briefly, this document defines the following extensions to [RFC4120]:
	1. The client indicates the use of public-key authentication by		1. The client indicates the use of public-key authentication by
	including a special preauthenticator in the initial request. This		including a special preauthenticator in the initial request. This
	skipping to change at page 5, line 46 ¶		skipping to change at page 7, line 22 ¶
	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_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 76		KDC_ERR_INCONSISTENT_KEY_PURPOSE 77
	KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED 77		KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED 78
	KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED 78		KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED 79
	KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED 79		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
	Appendix A.		Appendix A.
	All structures defined in or imported into this document MUST be		All structures defined in or imported into this document MUST be
	encoded using Distinguished Encoding Rules (DER) [X680] [X690]		encoded using Distinguished Encoding Rules (DER) [X680] [X690]
	(unless otherwise noted). All data structures carried in OCTET		(unless otherwise noted). All data structures carried in OCTET
	STRINGs must be encoded according to the rules specified in		STRINGs must be encoded according to the rules specified in
	corresponding specifications.		corresponding specifications.
	Interoperability note: Some implementations may not be able to decode		Interoperability note: Some implementations may not be able to decode
	wrapped CMS objects encoded with BER but not DER; specifically, they		wrapped CMS objects encoded with BER; specifically, they may not be
	may not be able to decode indefinite length encodings. To maximize		able to decode indefinite length encodings. To maximize
	interoperability, implementers SHOULD encode CMS objects used in		interoperability, implementers SHOULD encode CMS objects used in
	PKINIT with DER.		PKINIT with DER.
	3.1.3. Algorithm Identifiers		3.1.3. Algorithm Identifiers
	PKINIT does not define, but does make use of, the following algorithm		PKINIT does not define, but does make use of, the following algorithm
	identifiers.		identifiers.
	PKINIT uses the following algorithm identifier(s) for Modular		PKINIT uses the following algorithm identifier(s) for Modular
	Exponential Diffie-Hellman key agreement [RFC2631] [RFC3279]:		Exponential Diffie-Hellman key agreement [RFC2631] [RFC3279]:
	skipping to change at page 14, line 43 ¶		skipping to change at page 16, line 20 ¶
	KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field		KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field
	of the client's X.509 certificate:		of the client's X.509 certificate:
	id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=		id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
	{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)		{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
	pkinit(3) keyPurposeClientAuth(4) }		pkinit(3) keyPurposeClientAuth(4) }
	-- PKINIT client authentication.		-- PKINIT client authentication.
	-- Key usage bits that MUST be consistent:		-- Key usage bits that MUST be consistent:
	-- digitalSignature.		-- digitalSignature.
	The digitalSignature key usage bit MUST be asserted when the intended		The digitalSignature key usage bit [RFC3280] MUST be asserted when
	purpose of the client certificate is restricted with the id-pkinit-		the intended purpose of the client's X.509 certificate is restricted
	KPClientAuth EKU.		with the id-pkinit-KPClientAuth EKU.
	If this EKU KeyPurposeId is required but it is not present or if the		If this EKU KeyPurposeId is required but it is not present or if the
	client certificate is restricted not to be used for PKINIT client		client certificate is restricted not to be used for PKINIT client
	authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return		authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
	an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE. There		an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE. There
	is no accompanying e-data for this error message. KDCs implementing		is no accompanying e-data for this error message. KDCs implementing
	this requirement SHOULD also accept the EKU KeyPurposeId id-ms-kp-sc-		this requirement SHOULD also accept the EKU KeyPurposeId id-ms-kp-sc-
	logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there		logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there
	are a large number of X.509 client certificates deployed for use with		are a large number of X.509 client certificates deployed for use with
	PKINIT which have this EKU.		PKINIT which have this EKU.
	skipping to change at page 17, line 45 ¶		skipping to change at page 19, line 21 ¶
	-- Contains a CMS type ContentInfo encoded according		-- Contains a CMS type ContentInfo encoded according
	-- to [RFC3852].		-- to [RFC3852].
	-- The contentType field of the type ContentInfo is		-- The contentType field of the type ContentInfo is
	-- id-signedData (1.2.840.113549.1.7.2), and the		-- id-signedData (1.2.840.113549.1.7.2), and the
	-- content field is a SignedData.		-- content field is a SignedData.
	-- The eContentType field for the type SignedData is		-- The eContentType field for the type SignedData is
	-- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the		-- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
	-- eContent field contains the DER encoding of the		-- eContent field contains the DER encoding of the
	-- type KDCDHKeyInfo.		-- type KDCDHKeyInfo.
	-- KDCDHKeyInfo is defined below.		-- KDCDHKeyInfo is defined below.
	serverDHNonce [1] DHNonce OPTIONAL		serverDHNonce [1] DHNonce OPTIONAL,
	-- Present if and only if dhKeyExpiration is		-- Present if and only if dhKeyExpiration is
	-- present in the KDCDHKeyInfo.		-- present in the KDCDHKeyInfo.
			...
	}		}
	KDCDHKeyInfo ::= SEQUENCE {		KDCDHKeyInfo ::= SEQUENCE {
	subjectPublicKey [0] BIT STRING,		subjectPublicKey [0] BIT STRING,
	-- The KDC's DH public key.		-- The KDC's DH public key.
	-- The DH public key value is encoded as a BIT		-- The DH public key value is encoded as a BIT
	-- STRING according to [RFC3279].		-- STRING according to [RFC3279].
	nonce [1] INTEGER (0..4294967295),		nonce [1] INTEGER (0..4294967295),
	-- Contains the nonce in the pkAuthenticator field		-- Contains the nonce in the pkAuthenticator field
	-- in the request if the DH keys are NOT reused,		-- in the request if the DH keys are NOT reused,
	skipping to change at page 19, line 42 ¶		skipping to change at page 21, line 21 ¶
	to return to the client. This field may be left empty if the KDC		to return to the client. This field may be left empty if the KDC
	public key specified by the kdcPkId field in the PA-PK-AS-REQ was		public key specified by the kdcPkId field in the PA-PK-AS-REQ was
	used for signing. Otherwise, for path validation, these		used for signing. Otherwise, for path validation, these
	certificates SHOULD be sufficient to construct at least one		certificates SHOULD be sufficient to construct at least one
	certification path from the KDC certificate to one trust anchor		certification path from the KDC certificate to one trust anchor
	acceptable by the client [RFC4158]. The KDC MUST be capable of		acceptable by the client [RFC4158]. The KDC MUST be capable of
	including such a set of certificates if configured to do so. The		including such a set of certificates if configured to do so. The
	certificates field MUST NOT contain "root" CA certificates.		certificates field MUST NOT contain "root" CA certificates.
	7. If the client included the clientDHNonce field, then the KDC may		7. If the client included the clientDHNonce field, then the KDC may
	choose to reuse its DH keys (see Section 3.2.3.1). If the server		choose to reuse its DH keys. If the server reuses DH keys then
	reuses DH keys then it MUST include an expiration time in the		it MUST include an expiration time in the dhKeyExpiration field.
	dhKeyExpiration field. Past the point of the expiration time,		Past the point of the expiration time, the signature over the
	the signature over the type DHRepInfo is considered expired/		type DHRepInfo is considered expired/invalid. When the server
	invalid. When the server reuses DH keys then it MUST include a		reuses DH keys then it MUST include a serverDHNonce at least as
	serverDHNonce at least as long as the length of keys for the		long as the length of keys for the symmetric encryption system
	symmetric encryption system used to encrypt the AS reply. Note		used to encrypt the AS reply. Note that including the
	that including the serverDHNonce changes how the client and		serverDHNonce changes how the client and server calculate the key
	server calculate the key to use to encrypt the reply; see below		to use to encrypt the reply; see below for details. The KDC
	for details. The KDC SHOULD NOT reuse DH keys unless the		SHOULD NOT reuse DH keys unless the clientDHNonce field is
	clientDHNonce field is present in the request.		present in the request.
	The AS reply key is derived as follows:		The AS reply key is derived as follows:
	1. Both the KDC and the client calculate the shared secret value as		1. Both the KDC and the client calculate the shared secret value as
	follows:		follows:
	a) When MODP Diffie-Hellman is used, let DHSharedSecret be the		a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
	shared secret value. DHSharedSecret is the value ZZ as		shared secret value. DHSharedSecret is the value ZZ as
	described in Section 2.1.1 of [RFC2631].		described in Section 2.1.1 of [RFC2631].
	skipping to change at page 21, line 10 ¶		skipping to change at page 22, line 40 ¶
	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		If the hash algorithm used in the key derivation function (currently
	only octetstring2key() is defined) is not acceptable by the KDC, the		only octetstring2key() is defined) is not acceptable by the KDC, the
	KDC MUST return a KRB-ERROR [RFC4120] message with the code		KDC MUST return a KRB-ERROR [RFC4120] message with the code
	KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED. The accompanying e-data MUST be		KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED. The accompanying e-data MUST be
	encoded in TYPED-DATA although none is defined at this point.		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 an encKeyPack structure 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
	EnvelopedData (as defined in [RFC3852]).		EnvelopedData (as defined in [RFC3852]).
	2. The contentType field for the type EnvelopedData is id-		2. The contentType field for the type EnvelopedData is id-
	skipping to change at page 23, line 36 ¶		skipping to change at page 25, line 16 ¶
	is intended for a Kerberos KDC, the client MUST require that the KDC		is intended for a Kerberos KDC, the client MUST require that the KDC
	certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc:		certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc:
	id-pkinit-KPKdc OBJECT IDENTIFIER ::=		id-pkinit-KPKdc OBJECT IDENTIFIER ::=
	{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)		{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
	pkinit(3) keyPurposeKdc(5) }		pkinit(3) keyPurposeKdc(5) }
	-- Signing KDC responses.		-- Signing KDC responses.
	-- Key usage bits that MUST be consistent:		-- Key usage bits that MUST be consistent:
	-- digitalSignature.		-- digitalSignature.
	The digitalSignature key usage bit MUST be asserted when the intended		The digitalSignature key usage bit [RFC3280] MUST be asserted when
	purpose of KDC certificate is restricted with the id-pkinit-KPKdc		the intended purpose of the KDC's X.509 certificate is restricted
	EKU.		with the id-pkinit-KPKdc EKU.
	If the KDC certificate contains the Kerberos TGS name encoded as an		If the KDC certificate contains the Kerberos TGS name encoded as an
	id-pkinit-san SAN, this certificate is certified by the issuing CA as		id-pkinit-san SAN, this certificate is certified by the issuing CA as
	a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required.		a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required.
	If all applicable checks are satisfied, the client then decrypts the		If all applicable checks are satisfied, the client then decrypts the
	enc-part field of the KDC-REP in the AS-REP using the AS reply key,		enc-part field of the KDC-REP in the AS-REP using the AS reply key,
	and then proceeds as described in [RFC4120].		and then proceeds as described in [RFC4120].
	Implementation note: CAs issuing KDC certificates SHOULD place all		Implementation note: CAs issuing KDC certificates SHOULD place all
	skipping to change at page 33, line 51 ¶		skipping to change at page 35, line 26 ¶
	-- Contains a CMS type ContentInfo encoded according		-- Contains a CMS type ContentInfo encoded according
	-- to [RFC3852].		-- to [RFC3852].
	-- The contentType field of the type ContentInfo is		-- The contentType field of the type ContentInfo is
	-- id-signedData (1.2.840.113549.1.7.2), and the		-- id-signedData (1.2.840.113549.1.7.2), and the
	-- content field is a SignedData.		-- content field is a SignedData.
	-- The eContentType field for the type SignedData is		-- The eContentType field for the type SignedData is
	-- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the		-- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
	-- eContent field contains the DER encoding of the		-- eContent field contains the DER encoding of the
	-- type KDCDHKeyInfo.		-- type KDCDHKeyInfo.
	-- KDCDHKeyInfo is defined below.		-- KDCDHKeyInfo is defined below.
	serverDHNonce [1] DHNonce OPTIONAL		serverDHNonce [1] DHNonce OPTIONAL,
	-- Present if and only if dhKeyExpiration is		-- Present if and only if dhKeyExpiration is
	-- present.		-- present.
			...
	}		}
	KDCDHKeyInfo ::= SEQUENCE {		KDCDHKeyInfo ::= SEQUENCE {
	subjectPublicKey [0] BIT STRING,		subjectPublicKey [0] BIT STRING,
	-- The KDC's DH public key.		-- The KDC's DH public key.
	-- The DH public key value is encoded as a BIT		-- The DH public key value is encoded as a BIT
	-- STRING according to [RFC3279].		-- STRING according to [RFC3279].
	nonce [1] INTEGER (0..4294967295),		nonce [1] INTEGER (0..4294967295),
	-- Contains the nonce in the pkAuthenticator field		-- Contains the nonce in the pkAuthenticator field
	-- in the request if the DH keys are NOT reused,		-- in the request if the DH keys are NOT reused,
End of changes. 24 change blocks.
	95 lines changed or deleted		166 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/