< draft-ietf-kitten-pkinit-alg-agility-03.txt		draft-ietf-kitten-pkinit-alg-agility-04.txt >
	Kitten Working Group L. Hornquist Astrand		Kitten Working Group L. Hornquist Astrand
	Internet-Draft Apple, Inc		Internet-Draft Apple, Inc
	Updates: 4556 (if approved) L. Zhu		Updates: 4556 (if approved) L. Zhu
	Intended status: Standards Track Microsoft Corporation		Intended status: Standards Track Microsoft Corporation
	Expires: May 9, 2019 M. Wasserman		Expires: August 7, 2019 M. Wasserman
	Painless Security		Painless Security
	G. Hudson, Ed.		G. Hudson, Ed.
	MIT		MIT
	November 5, 2018		February 3, 2019
	PKINIT Algorithm Agility		PKINIT Algorithm Agility
	draft-ietf-kitten-pkinit-alg-agility-03		draft-ietf-kitten-pkinit-alg-agility-04
	Abstract		Abstract
	This document updates PKINIT, as defined in RFC 4556, to remove		This document updates PKINIT, as defined in RFC 4556, to remove
	protocol structures tied to specific cryptographic algorithms. The		protocol structures tied to specific cryptographic algorithms. The
	PKINIT key derivation function is made negotiable, the digest		PKINIT key derivation function is made negotiable, and the digest
	algorithms for signing the pre-authentication data and the client's		algorithms for signing the pre-authentication data and the client's
	X.509 certificates are made discoverable.		X.509 certificates are made discoverable.
	These changes provide preemptive protection against vulnerabilities		These changes provide preemptive protection against vulnerabilities
	discovered in the future against any specific cryptographic		discovered in the future against any specific cryptographic
	algorithm, and allow incremental deployment of newer algorithms.		algorithm, and allow incremental deployment of newer algorithms.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on May 9, 2019.		This Internet-Draft will expire on August 7, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 40 ¶		skipping to change at page 2, line 40 ¶
	2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4		2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
	3. paChecksum Agility . . . . . . . . . . . . . . . . . . . . . 4		3. paChecksum Agility . . . . . . . . . . . . . . . . . . . . . 4
	4. CMS Digest Algorithm Agility . . . . . . . . . . . . . . . . 4		4. CMS Digest Algorithm Agility . . . . . . . . . . . . . . . . 4
	5. X.509 Certificate Signer Algorithm Agility . . . . . . . . . 5		5. X.509 Certificate Signer Algorithm Agility . . . . . . . . . 5
	6. KDF agility . . . . . . . . . . . . . . . . . . . . . . . . . 6		6. KDF agility . . . . . . . . . . . . . . . . . . . . . . . . . 6
	7. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . 11		7. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . 11
	7.1. Common Inputs . . . . . . . . . . . . . . . . . . . . . . 11		7.1. Common Inputs . . . . . . . . . . . . . . . . . . . . . . 11
	7.2. Test Vector for SHA-1, enctype 18 . . . . . . . . . . . . 12		7.2. Test Vector for SHA-1, enctype 18 . . . . . . . . . . . . 12
	7.2.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 12		7.2.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 12
	7.2.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 12		7.2.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 12
	7.3. Test Vector for SHA-256, enctype . . . . . . . . . . . . 12		7.3. Test Vector for SHA-256, enctype . . . . . . . . . . . . 13
	7.3.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 12		7.3.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13
	7.3.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 12		7.3.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13
	7.4. Test Vector for SHA-512, enctype . . . . . . . . . . . . 12		7.4. Test Vector for SHA-512, enctype . . . . . . . . . . . . 13
	7.4.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 12		7.4.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13
	7.4.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13		7.4.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 13		8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	11.1. Normative References . . . . . . . . . . . . . . . . . . 13		11.1. Normative References . . . . . . . . . . . . . . . . . . 14
	11.2. Informative References . . . . . . . . . . . . . . . . . 15		11.2. Informative References . . . . . . . . . . . . . . . . . 15
	Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . 15		Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	This document updates PKINIT [RFC4556] to remove protocol structures		This document updates PKINIT [RFC4556] to remove protocol structures
	tied to specific cryptographic algorithms. The PKINIT key derivation		tied to specific cryptographic algorithms. The PKINIT key derivation
	function is made negotiable, the digest algorithms for signing the		function is made negotiable, the digest algorithms for signing the
	pre-authentication data and the client's X.509 certificates are made		pre-authentication data and the client's X.509 certificates are made
	discoverable.		discoverable.
	These changes provide preemptive protection against vulnerabilities		These changes provide preemptive protection against vulnerabilities
	skipping to change at page 3, line 30 ¶		skipping to change at page 3, line 30 ¶
	attacks on later hash function designs in the MD4, MD5 [RFC1321] and		attacks on later hash function designs in the MD4, MD5 [RFC1321] and
	SHA [RFC6234] family. These attacks and their consequences are		SHA [RFC6234] family. These attacks and their consequences are
	discussed in [RFC6194]. These discoveries challenged the security of		discussed in [RFC6194]. These discoveries challenged the security of
	protocols relying on the collision resistance properties of these		protocols relying on the collision resistance properties of these
	hashes.		hashes.
	The Internet Engineering Task Force (IETF) called for actions to		The Internet Engineering Task Force (IETF) called for actions to
	update existing protocols to provide crypto algorithm agility so that		update existing protocols to provide crypto algorithm agility so that
	protocols support multiple cryptographic algorithms (including hash		protocols support multiple cryptographic algorithms (including hash
	functions) and provide clean, tested transition strategies between		functions) and provide clean, tested transition strategies between
	algorithms.		algorithms, as recommended by BCP 201 [RFC7696].
	This document updates PKINIT to provide crypto algorithm agility.		This document updates PKINIT to provide crypto algorithm agility.
	Several protocol structures used in the [RFC4556] protocol are either		Several protocol structures used in the [RFC4556] protocol are either
	tied to SHA-1, or do not support negotiation or discovery, but are		tied to SHA-1, or do not support negotiation or discovery, but are
	instead based on local policy. The following concerns have been		instead based on local policy. The following concerns have been
	addressed in this update:		addressed in this update:
	o The checksum algorithm in the authentication request is hardwired		o The checksum algorithm in the authentication request is hardwired
	to use SHA-1 [RFC6234].		to use SHA-1 [RFC6234].
	o The acceptable digest algorithms for signing the authentication		o The acceptable digest algorithms for signing the authentication
	data are not discoverable.		data are not discoverable.
	o The key derivation function in Section 3.2.3 of [RFC4556] is		o The key derivation function in Section 3.2.3.1 of [RFC4556] is
	hardwired to use SHA-1.		hardwired to use SHA-1.
	o The acceptable digest algorithms for signing the client X.509		o The acceptable digest algorithms for signing the client X.509
	certificates are not discoverable.		certificates are not discoverable.
	To address these concerns, new key derivation functions (KDFs),		To address these concerns, new key derivation functions (KDFs),
	identified by object identifiers, are defined. The PKINIT client		identified by object identifiers, are defined. The PKINIT client
	provides a list of KDFs in the request and the Key Distribution		provides a list of KDFs in the request and the Key Distribution
	Center (KDC) picks one in the response, thus a mutually-supported KDF		Center (KDC) picks one in the response, thus a mutually-supported KDF
	is negotiated.		is negotiated.
	Furthermore, structures are defined to allow the client to discover		Furthermore, structures are defined to allow the client to discover
	the Cryptographic Message Syntax (CMS) [RFC5652] digest algorithms		the Cryptographic Message Syntax (CMS) [RFC5652] digest algorithms
	supported by the KDC for signing the pre-authentication data and		supported by the KDC for signing the pre-authentication data and
	signing the client X.509 certificate.		signing the client X.509 certificate.
	2. Requirements Notation		2. Requirements Notation
	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", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in [RFC2119].		"OPTIONAL" in this document are to be interpreted as described in BCP
			14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	3. paChecksum Agility		3. paChecksum Agility
	The paChecksum defined in Section 3.2.1 of [RFC4556] provides a		The paChecksum defined in Section 3.2.1 of [RFC4556] provides a
	cryptographic binding between the client's pre-authentication data		cryptographic binding between the client's pre-authentication data
	and the corresponding Kerberos request body. This also prevents the		and the corresponding Kerberos request body. This also prevents the
	KDC body from being tampered with. SHA-1 is the only allowed		KDC-REQ body from being tampered with. SHA-1 is the only allowed
	checksum algorithm defined in [RFC4556]. This facility relies on the		checksum algorithm defined in [RFC4556]. This facility relies on the
	collision resistance properties of the SHA-1 checksum [RFC6234].		collision resistance properties of the SHA-1 checksum [RFC6234].
	When the reply key delivery mechanism is based on public key		When the reply key delivery mechanism is based on public key
	encryption as described in Section 3.2.3. of [RFC4556], the		encryption as described in Section 3.2.3.2 of [RFC4556], the
	asChecksum in the KDC reply provides the binding between the pre-		asChecksum in the KDC reply provides the binding between the pre-
	authentication and the ticket request and response messages, and		authentication and the ticket request and response messages, and
	integrity protection for the unauthenticated clear text in these		integrity protection for the unauthenticated clear text in these
	messages. However, if the reply key delivery mechanism is based on		messages. However, if the reply key delivery mechanism is based on
	the Diffie-Hellman key agreement as described in Section 3.2.3.1 of		the Diffie-Hellman key agreement as described in Section 3.2.3.1 of
	[RFC4556], the security provided by using SHA-1 in the paChecksum is		[RFC4556], the security provided by using SHA-1 in the paChecksum is
	weak. In this case, the new KDF selected by the KDC as described in		weak, and nothing else cryptographically binds the AS request to the
	Section 6 provides the cryptographic binding and integrity		ticket response. In this case, the new KDF selected by the KDC as
	protection.		described in Section 6 provides the cryptographic binding and
			integrity protection.
	4. CMS Digest Algorithm Agility		4. CMS Digest Algorithm Agility
	When the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned		When the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned
	as described In section 3.2.2 of [RFC4556], implementations		as described in Section 3.2.2 of [RFC4556], implementations
	comforming to this specification can OPTIONALLY send back a list of		conforming to this specification can OPTIONALLY send back a list of
	supported CMS types signifying the digest algorithms supported by the		supported CMS types signifying the digest algorithms supported by the
	KDC, in the decreasing preference order. This is accomplished by		KDC, in the decreasing preference order. This is accomplished by
	including a TD_CMS_DATA_DIGEST_ALGORITHMS typed data element in the		including a TD_CMS_DATA_DIGEST_ALGORITHMS typed data element in the
	error data.		error data.
	td-cms-digest-algorithms INTEGER ::= 111		td-cms-digest-algorithms INTEGER ::= 111
	The corresponding data for the TD_CMS_DATA_DIGEST_ALGORITHMS contains		The corresponding data for the TD_CMS_DATA_DIGEST_ALGORITHMS contains
	the ASN.1 Distinguished Encoding Rules (DER) [X680] [X690] encoded		the ASN.1 Distinguished Encoding Rules (DER) [X680] [X690] encoded
	TD-CMS-DIGEST-ALGORITHMS-DATA structure defined as follows:		TD-CMS-DIGEST-ALGORITHMS-DATA structure defined as follows:
	TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF		TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF
	AlgorithmIdentifier		AlgorithmIdentifier
	-- Contains the list of CMS algorithm [RFC5652]		-- Contains the list of CMS algorithm [RFC5652]
	-- identifiers that identify the digest algorithms		-- identifiers that indicate the digest algorithms
	-- acceptable by the KDC for signing CMS data in		-- acceptable by the KDC for signing CMS data in
	-- the order of decreasing preference.		-- the order of decreasing preference.
	The algorithm identifiers in the TD-CMS-DIGEST-ALGORITHMS identifiy		The algorithm identifiers in the TD-CMS-DIGEST-ALGORITHMS identifiy
	digest algorithms supported by the KDC.		digest algorithms supported by the KDC.
	This information sent by the KDC via TD_CMS_DATA_DIGEST_ALGORITHMS		This information sent by the KDC via TD_CMS_DATA_DIGEST_ALGORITHMS
	can facilitate trouble-shooting when none of the digest algorithms		can facilitate trouble-shooting when none of the digest algorithms
	supported by the client is supported by the KDC.		supported by the client is supported by the KDC.
	5. X.509 Certificate Signer Algorithm Agility		5. X.509 Certificate Signer Algorithm Agility
	When the client's X.509 certificate is rejected and the		When the client's X.509 certificate is rejected and the
	KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned as		KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned as
	described in section 3.2.2 of [RFC4556], conforming implementations		described in Section 3.2.2 of [RFC4556], implementations conforming
	can OPTIONALLY send a list of digest algorithms acceptable by the KDC		to this specification can OPTIONALLY send a list of digest algorithms
	for use by the Certificate Authority (CA) in signing the client's		acceptable by the KDC for use by the Certificate Authority (CA) in
	X.509 certificate, in the decreasing preference order. This is		signing the client's X.509 certificate, in the decreasing preference
	accomplished by including a TD_CERT_DIGEST_ALGORITHMS typed data		order. This is accomplished by including a TD_CERT_DIGEST_ALGORITHMS
	element in the error data. The corresponding data contains the ASN.1		typed data element in the error data. The corresponding data
	DER encoding of the structure TD-CERT-DIGEST-ALGORITHMS-DATA defined		contains the ASN.1 DER encoding of the structure TD-CERT-DIGEST-
	as follows:		ALGORITHMS-DATA defined as follows:
	td-cert-digest-algorithms INTEGER ::= 112		td-cert-digest-algorithms INTEGER ::= 112
	TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE {		TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE {
	allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier,		allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier,
	-- Contains the list of CMS algorithm [RFC5652]		-- Contains the list of CMS algorithm [RFC5652]
	-- identifiers that identify the digest algorithms		-- identifiers that identify the digest algorithms
	-- that are used by the CA to sign the client's		-- that are used by the CA to sign the client's
	-- X.509 certificate and acceptable by the KDC in		-- X.509 certificate and acceptable by the KDC in
	-- the process of validating the client's X.509		-- the process of validating the client's X.509
	skipping to change at page 6, line 41 ¶		skipping to change at page 6, line 41 ¶
	X.509 certificate that has been rejected by the KDC in the process of		X.509 certificate that has been rejected by the KDC in the process of
	validating the client's certificate [RFC5280].		validating the client's certificate [RFC5280].
	6. KDF agility		6. KDF agility
	Based on [RFC3766] and [X9.42], Section 3.2.3.1 of [RFC4556] defines		Based on [RFC3766] and [X9.42], Section 3.2.3.1 of [RFC4556] defines
	a Key Derivation Function (KDF) that derives a Kerberos protocol key		a Key Derivation Function (KDF) that derives a Kerberos protocol key
	based on the secret value generated by the Diffie-Hellman key		based on the secret value generated by the Diffie-Hellman key
	exchange. This KDF requires the use of SHA-1 [RFC6234].		exchange. This KDF requires the use of SHA-1 [RFC6234].
	New KDFs defined in this document based on [SP80056A] can be used in		The KDF algorithm described in this document (based on [SP80056A])
	conjunction with any hash functions.		can be implemented using any cryptographic hash function.
	A new KDF is identified by an object identifier. The following KDF		A new KDF for PKINIT usage is identified by an object identifier.
	object identifiers are defined:		The following KDF object identifiers are defined:
	id-pkinit OBJECT IDENTIFIER ::=		id-pkinit OBJECT IDENTIFIER ::=
	{ iso(1) identified-organization(3) dod(6) internet(1)		{ iso(1) identified-organization(3) dod(6) internet(1)
	security(5) kerberosv5(2) pkinit (3) }		security(5) kerberosv5(2) pkinit (3) }
	-- Defined in RFC 4556 and quoted here for the reader.		-- Defined in RFC 4556 and quoted here for the reader.
	id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit kdf(6) }		id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit kdf(6) }
	-- PKINIT KDFs		-- PKINIT KDFs
	id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER		id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER
	::= { id-pkinit-kdf sha1(1) }		::= { id-pkinit-kdf sha1(1) }
	-- SP800-56A ASN.1 structured hash based KDF using SHA-1		-- SP800-56A ASN.1 structured hash-based KDF using SHA-1
	id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER		id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER
	::= { id-pkinit-kdf sha256(2) }		::= { id-pkinit-kdf sha256(2) }
	-- SP800-56A ASN.1 structured hash based KDF using SHA-256		-- SP800-56A ASN.1 structured hash-based KDF using SHA-256
	id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER		id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER
	::= { id-pkinit-kdf sha512(3) }		::= { id-pkinit-kdf sha512(3) }
	-- SP800-56A ASN.1 structured hash based KDF using SHA-512		-- SP800-56A ASN.1 structured hash-based KDF using SHA-512
	id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER		id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER
	::= { id-pkinit-kdf sha384(4) }		::= { id-pkinit-kdf sha384(4) }
	-- SP800-56A ASN.1 structured hash based KDF using SHA-384		-- SP800-56A ASN.1 structured hash-based KDF using SHA-384
	Where id-pkinit is defined in [RFC4556]. The id-pkinit-kdf-ah-sha1		Where id-pkinit is defined in [RFC4556]. All key derivation
	KDF is the ASN.1 structured hash based KDF (HKDF) [SP80056A] that		functions specified above use the one-step key derivation method
	uses SHA-1 [RFC6234] as the hash function. Similarly id-pkinit-kdf-		described in Section 5.8.2.1 of [SP80056A], using the ASN.1 format
	ah-sha256 and id-pkinit-kdf-ah-sha512 are the ASN.1 structured HKDF		for FixedInfo, and Section 4.1 of [SP80056C], using option 1 for the
	using SHA-256 [RFC6234] and SHA-512 [RFC6234] respectively.		auxiliary function H. id-pkinit-kdf-ah-sha1 uses SHA-1 [RFC6234] as
			the hash function. id-pkinit-kdf-ah-sha256, id-pkinit-kdf-ah-sha356,
			and id-pkinit-kdf-ah-sha512 use SHA-256 [RFC6234], SHA-384 ([RFC6234]
			and SHA-512 [RFC6234] respectively.
	To name the input parameters, an abbreviated version of the ASN.1		To name the input parameters, an abbreviated version of the key
	version of the KDF from [SP80056A] is described below, use [SP80056A]		derivation method is described below.
	for the full reference.
	1. reps = ceiling (keydatalen/hash length (H))		1. reps = ceiling(L/H_outputBits)
	2. Initialize a 32-bit, big-endian bit string counter as 1.		2. Initialize a 32-bit, big-endian bit string counter as 1.
	3. For i = 1 to reps by 1, do the following:		3. For i = 1 to reps by 1, do the following:
	1. Compute Hashi = H(counter || Z || OtherInfo).		1. Compute Hashi = H(counter || Z || OtherInfo).
	2. Increment counter (modulo 2^32)		2. Increment counter (not to exceed 2^32-1)
	4. Set key_material = Hash1 || Hash2 || ... so that length of key is		4. Set key_material = Hash1 || Hash2 || ... so that the length of
	K bits.		key_material is L bits, truncating the last block as necessary.
	5. The above ASN.1 structured [SP80056A] HKDF produces a bit string		5. The above KDF produces a bit string of length L in bits as the
	of length K in bits as the keying material, and then the AS reply		keying material. The AS reply key is the output of random-to-
	key is the output of random-to-key() [RFC3961] using that		key() [RFC3961] using that keying material as the input.
	returned keying material as the input.
	The input parameters for these KDFs are provided as follows:		The input parameters for these KDFs are provided as follows:
	o The key data length (K) is the key-generation seed length in bits		o H_outputBits is 160 bits for id-pkinit-kdf-ah-sha1, 256 bits for
	[RFC3961] for the Authentication Service (AS) reply key. The		id-pkinit-kdf-ah-sha256, 384 bits for id-pkinit-kdf-ah-sha384, and
	enctype of the AS reply key is selected according to [RFC4120].		512 bits for id-pkinit-kdf-ah-sha512.
	o The hash length (H) is 160 bits for id-pkinit-kdf-ah-sha1, 256		o max_H_inputBits is 2^64.
	bits for id-pkinit-kdf-ah-sha256, 384 bits for id-pkinit-kdf-ah-
	sha384 and 512 bits for id-pkinit-kdf-ah-sha512.
	o The secret value (Z) is the shared secret value generated by the		o The secret value (Z) is the shared secret value generated by the
	Diffie-Hellman exchange. The Diffie-Hellman shared value is first		Diffie-Hellman exchange. The Diffie-Hellman shared value is first
	padded with leading zeros such that the size of the secret value		padded with leading zeros such that the size of the secret value
	in octets is the same as that of the modulus, then represented as		in octets is the same as that of the modulus, then represented as
	a string of octets in big-endian order.		a string of octets in big-endian order.
			o The key data length (L) is the key-generation seed length in bits
			[RFC3961] for the Authentication Service (AS) reply key. The
			enctype of the AS reply key is selected according to [RFC4120].
	o The algorithm identifier (algorithmID) input parameter is the		o The algorithm identifier (algorithmID) input parameter is the
	identifier of the respective KDF. For example, this is id-pkinit-		identifier of the respective KDF. For example, this is id-pkinit-
	kdf-ah-sha1 if the KDF is the [SP80056A] ASN.1 structured HKDF		kdf-ah-sha1 if the KDF uses SHA-1 as the hash.
	using SHA-1 as the hash.
	o The initiator identifier (partyUInfo) contains the ASN.1 DER		o The initiator identifier (partyUInfo) contains the ASN.1 DER
	encoding of the KRB5PrincipalName [RFC4556] that identifies the		encoding of the KRB5PrincipalName [RFC4556] that identifies the
	client as specified in the AS-REQ [RFC4120] in the request.		client as specified in the AS-REQ [RFC4120] in the request.
	o The recipient identifier (partyVInfo) contains the ASN.1 DER		o The recipient identifier (partyVInfo) contains the ASN.1 DER
	encoding of the KRB5PrincipalName [RFC4556] that identifies the		encoding of the KRB5PrincipalName [RFC4556] that identifies the
	TGS as specified in the AS-REQ [RFC4120] in the request.		TGS as specified in the AS-REQ [RFC4120] in the request.
	o The supplemental public information (suppPubInfo) is the ASN.1 DER		o The supplemental public information (suppPubInfo) is the ASN.1 DER
	encoding of the structure PkinitSuppPubInfo as defined later in		encoding of the structure PkinitSuppPubInfo as defined later in
	this section.		this section.
	o The supplemental private information (suppPrivInfo) is absent.		o The supplemental private information (suppPrivInfo) is absent.
	o The maximum hash input length is 2^64 in bits.		OtherInfo is the ASN.1 DER encoding of the following sequence:
	The structure for OtherInfo is defined as follows:
	OtherInfo ::= SEQUENCE {		OtherInfo ::= SEQUENCE {
	algorithmID AlgorithmIdentifier,		algorithmID AlgorithmIdentifier,
	partyUInfo [0] OCTET STRING,		partyUInfo [0] OCTET STRING,
	partyVInfo [1] OCTET STRING,		partyVInfo [1] OCTET STRING,
	suppPubInfo [2] OCTET STRING OPTIONAL,		suppPubInfo [2] OCTET STRING OPTIONAL,
	suppPrivInfo [3] OCTET STRING OPTIONAL		suppPrivInfo [3] OCTET STRING OPTIONAL
	}		}
	The structure PkinitSuppPubInfo is defined as follows:		The structure PkinitSuppPubInfo is defined as follows:
	PkinitSuppPubInfo ::= SEQUENCE {		PkinitSuppPubInfo ::= SEQUENCE {
	enctype [0] Int32,		enctype [0] Int32,
	-- The enctype of the AS reply key		-- The enctype of the AS reply key.
	as-REQ [1] OCTET STRING,		as-REQ [1] OCTET STRING,
	-- This contains the AS-REQ in the request.		-- The DER encoding of the AS-REQ [RFC4120] from the
			-- client.
	pk-as-rep [2] OCTET STRING,		pk-as-rep [2] OCTET STRING,
	-- Contains the DER encoding of the type		-- The DER encoding of the PA-PK-AS-REP [RFC4556] in the
	-- PA-PK-AS-REP [RFC4556] in the KDC reply.		-- KDC reply.
	...		...
	}		}
	The PkinitSuppPubInfo structure contains mutually-known public		The PkinitSuppPubInfo structure contains mutually-known public
	information specific to the authentication exchange. The enctype		information specific to the authentication exchange. The enctype
	field is the enctype of the AS reply key as selected according to		field is the enctype of the AS reply key as selected according to
	[RFC4120]. The as-REQ field contains the DER encoding of the type		[RFC4120]. The as-REQ field contains the DER encoding of the type
	AS-REQ [RFC4120] in the request sent from the client to the KDC.		AS-REQ [RFC4120] in the request sent from the client to the KDC.
	Note that the as-REQ field does not include the wrapping 4 octet		Note that the as-REQ field does not include the wrapping 4 octet
	length field when TCP is used. The pk-as-rep field contains the DER		length field when TCP is used. The pk-as-rep field contains the DER
	skipping to change at page 10, line 50 ¶		skipping to change at page 11, line 6 ¶
	}		}
	The new field kdf in the extended DHRepInfo structure identifies the		The new field kdf in the extended DHRepInfo structure identifies the
	KDF picked by the KDC. This kdf field MUST be filled by the		KDF picked by the KDC. This kdf field MUST be filled by the
	comforming KDC if the supportedKDFs field is present in the request,		comforming KDC if the supportedKDFs field is present in the request,
	and it MUST be one of the KDFs supported by the client as indicated		and it MUST be one of the KDFs supported by the client as indicated
	in the request. Which KDF is chosen is a matter of the local policy		in the request. Which KDF is chosen is a matter of the local policy
	on the KDC.		on the KDC.
	If the supportedKDFs field is not present in the request, the kdf		If the supportedKDFs field is not present in the request, the kdf
	field in the reply MUST be absent.		field in the reply MUST be absent, and the key derivation function
			from Section 3.2.3.1 of [RFC4556] MUST be used.
	If the client fills the supportedKDFs field in the request, but the		If the client fills the supportedKDFs field in the request, but the
	kdf field in the reply is not present, the client can deduce that the		kdf field in the reply is not present, the client can deduce that the
	KDC is not updated to conform with this specification. In that case,		KDC is not updated to conform with this specification, or that the
	it is a matter of local policy on the client whether to reject the		exchange was subjected to a downgrade attack. It is a matter of
	reply when the kdf field is absent in the reply.		local policy on the client whether to reject the reply when the kdf
			field is absent in the reply; if compatibility with non-updated KDCs
			is not a concern, the reply should be rejected.
	Implementations comforming to this specification MUST support id-		Implementations comforming to this specification MUST support id-
	pkinit-kdf-ah-sha256.		pkinit-kdf-ah-sha256.
	This document introduces the following new PKINIT error code:		This document introduces the following new PKINIT error code:
	o KDC_ERR_NO_ACCEPTABLE_KDF 100		o KDC_ERR_NO_ACCEPTABLE_KDF 100
	If no acceptable KDF is found, the error KDC_ERR_NO_ACCEPTABLE_KDF		If no acceptable KDF is found, the error KDC_ERR_NO_ACCEPTABLE_KDF
	(100) will be returned..		(100) will be returned..
	skipping to change at page 13, line 4 ¶		skipping to change at page 13, line 26 ¶
	key-material: Length = 32 bytes, Hex Representation =		key-material: Length = 32 bytes, Hex Representation =
	77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5		77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5
	key: Length = 32 bytes, Hex Representation =		key: Length = 32 bytes, Hex Representation =
	77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5		77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5
	7.4. Test Vector for SHA-512, enctype		7.4. Test Vector for SHA-512, enctype
	7.4.1. Specific Inputs		7.4.1. Specific Inputs
	algorithm-id: (id-pkinit-kdf-ah-sha512) Length = 8 bytes, Hex		algorithm-id: (id-pkinit-kdf-ah-sha512) Length = 8 bytes, Hex
	Representation = 2B060105 02030603		Representation = 2B060105 02030603
	enctype: (des3-cbc-sha1-kd) Length = 1 byte, Decimal Representation = 16		enctype: (des3-cbc-sha1-kd) Length = 1 byte, Decimal Representation = 16
	7.4.2. Outputs		7.4.2. Outputs
	key-material: Length = 24 bytes, Hex Representation =		key-material: Length = 24 bytes, Hex Representation =
	D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6		D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6
	key: Length = 32 bytes, Hex Representation =		key: Length = 32 bytes, Hex Representation =
	D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6		D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6
	8. Security Considerations		8. Security Considerations
	This document describes negotiation of checksum types, key derivation		This document describes negotiation of checksum types, key derivation
	functions and other cryptographic functions. If negotiation is done		functions and other cryptographic functions. If a given negotiation
	unauthenticated, care MUST be taken to accept only acceptable values.		is unauthenticated, care must be taken to accept only secure values;
			to do otherwise allows an active attacker to perform a downgrade
			attack.
	9. Acknowledgements		9. Acknowledgements
	Jeffery Hutzelman, Shawn Emery, Tim Polk and Kelley Burgin reviewed		Jeffery Hutzelman, Shawn Emery, Tim Polk and Kelley Burgin reviewed
	the document and provided suggestions for improvements.		the document and provided suggestions for improvements.
	10. IANA Considerations		10. IANA Considerations
	IANA is requested to update the following registrations in the		IANA is requested to update the following registrations in the
	Kerberos Pre-authentication and Typed Data Registry created by		Kerberos Pre-authentication and Typed Data Registry created by
	skipping to change at page 14, line 34 ¶		skipping to change at page 15, line 14 ¶
	[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,		[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
	RFC 5652, DOI 10.17487/RFC5652, September 2009,		RFC 5652, DOI 10.17487/RFC5652, September 2009,
	<https://www.rfc-editor.org/info/rfc5652>.		<https://www.rfc-editor.org/info/rfc5652>.
	[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms		[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
	(SHA and SHA-based HMAC and HKDF)", RFC 6234,		(SHA and SHA-based HMAC and HKDF)", RFC 6234,
	DOI 10.17487/RFC6234, May 2011,		DOI 10.17487/RFC6234, May 2011,
	<https://www.rfc-editor.org/info/rfc6234>.		<https://www.rfc-editor.org/info/rfc6234>.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[SP80056A]		[SP80056A]
	Barker, E., Don, D., and M. Smid, "Recommendation for		Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R.
	Pair-Wise Key Establishment Schemes Using Discrete		Davis, "Recommendation for Pair-Wise Key Establishment
	Logarithm Cryptography", March 2006.		Schemes Using Discrete Logarithm Cryptography", April
			2018.
			[SP80056C]
			Barker, E., Chen, L., and R. Davis, "Recommendation for
			Key-Derivation Methods in Key-Establishment Schemes",
			April 2018.
	[X680] ITU, "ITU-T Recommendation X.680 (2002) | ISO/IEC		[X680] ITU, "ITU-T Recommendation X.680 (2002) | ISO/IEC
	8824-1:2002, Information technology - Abstract Syntax		8824-1:2002, Information technology - Abstract Syntax
	Notation One (ASN.1): Specification of basic notation",		Notation One (ASN.1): Specification of basic notation",
	November 2008.		November 2008.
	[X690] ITU, "ITU-T Recommendation X.690 (2002) | ISO/IEC		[X690] ITU, "ITU-T Recommendation X.690 (2002) | ISO/IEC
	8825-1:2002, Information technology - ASN.1 encoding		8825-1:2002, Information technology - ASN.1 encoding
	Rules: Specification of Basic Encoding Rules (BER),		Rules: Specification of Basic Encoding Rules (BER),
	Canonical Encoding Rules (CER) and Distinguished Encoding		Canonical Encoding Rules (CER) and Distinguished Encoding
	skipping to change at page 15, line 25 ¶		skipping to change at page 16, line 14 ¶
	[RFC6150] Turner, S. and L. Chen, "MD4 to Historic Status",		[RFC6150] Turner, S. and L. Chen, "MD4 to Historic Status",
	RFC 6150, DOI 10.17487/RFC6150, March 2011,		RFC 6150, DOI 10.17487/RFC6150, March 2011,
	<https://www.rfc-editor.org/info/rfc6150>.		<https://www.rfc-editor.org/info/rfc6150>.
	[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security		[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
	Considerations for the SHA-0 and SHA-1 Message-Digest		Considerations for the SHA-0 and SHA-1 Message-Digest
	Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,		Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
	<https://www.rfc-editor.org/info/rfc6194>.		<https://www.rfc-editor.org/info/rfc6194>.
			[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
			Agility and Selecting Mandatory-to-Implement Algorithms",
			BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
			<https://www.rfc-editor.org/info/rfc7696>.
	[WANG04] Wang, X., Lai, X., Fheg, D., Chen, H., and X. Yu,		[WANG04] Wang, X., Lai, X., Fheg, D., Chen, H., and X. Yu,
	"Cryptanalysis of Hash functions MD4 and RIPEMD", August		"Cryptanalysis of Hash functions MD4 and RIPEMD", August
	2004.		2004.
	[X9.42] ANSI, "Public Key Cryptography for the Financial Services		[X9.42] ANSI, "Public Key Cryptography for the Financial Services
	Industry: Agreement of Symmetric Keys Using Discrete		Industry: Agreement of Symmetric Keys Using Discrete
	Logarithm Cryptography", 2003.		Logarithm Cryptography", 2003.
	Appendix A. PKINIT ASN.1 Module		Appendix A. PKINIT ASN.1 Module
	skipping to change at page 16, line 17 ¶		skipping to change at page 17, line 11 ¶
	FROM KerberosV5-PK-INIT-SPEC {		FROM KerberosV5-PK-INIT-SPEC {
	iso(1) identified-organization(3) dod(6) internet(1)		iso(1) identified-organization(3) dod(6) internet(1)
	security(5) kerberosV5(2) modules(4) pkinit(5) };		security(5) kerberosV5(2) modules(4) pkinit(5) };
	-- as defined in RFC 4556.		-- as defined in RFC 4556.
	id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit kdf(6) }		id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit kdf(6) }
	-- PKINIT KDFs		-- PKINIT KDFs
	id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER		id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER
	::= { id-pkinit-kdf sha1(1) }		::= { id-pkinit-kdf sha1(1) }
	-- SP800-56A ASN.1 structured hash based KDF using SHA-1		-- SP800-56A ASN.1 structured hash-based KDF using SHA-1
	id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER		id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER
	::= { id-pkinit-kdf sha256(2) }		::= { id-pkinit-kdf sha256(2) }
	-- SP800-56A ASN.1 structured hash based KDF using SHA-256		-- SP800-56A ASN.1 structured hash-based KDF using SHA-256
	id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER		id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER
	::= { id-pkinit-kdf sha512(3) }		::= { id-pkinit-kdf sha512(3) }
	-- SP800-56A ASN.1 structured hash based KDF using SHA-512		-- SP800-56A ASN.1 structured hash-based KDF using SHA-512
	id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER		id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER
	::= { id-pkinit-kdf sha384(4) }		::= { id-pkinit-kdf sha384(4) }
	-- SP800-56A ASN.1 structured hash based KDF using SHA-384		-- SP800-56A ASN.1 structured hash-based KDF using SHA-384
	TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF		TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF
	AlgorithmIdentifier		AlgorithmIdentifier
	-- Contains the list of CMS algorithm [RFC5652]		-- Contains the list of CMS algorithm [RFC5652]
	-- identifiers that identify the digest algorithms		-- identifiers that identify the digest algorithms
	-- acceptable by the KDC for signing CMS data in		-- acceptable by the KDC for signing CMS data in
	-- the order of decreasing preference.		-- the order of decreasing preference.
	TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE {		TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE {
	allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier,		allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier,
	skipping to change at page 17, line 20 ¶		skipping to change at page 18, line 14 ¶
	partyUInfo [0] OCTET STRING,		partyUInfo [0] OCTET STRING,
	partyVInfo [1] OCTET STRING,		partyVInfo [1] OCTET STRING,
	suppPubInfo [2] OCTET STRING OPTIONAL,		suppPubInfo [2] OCTET STRING OPTIONAL,
	suppPrivInfo [3] OCTET STRING OPTIONAL		suppPrivInfo [3] OCTET STRING OPTIONAL
	}		}
	PkinitSuppPubInfo ::= SEQUENCE {		PkinitSuppPubInfo ::= SEQUENCE {
	enctype [0] Int32,		enctype [0] Int32,
	-- The enctype of the AS reply key.		-- The enctype of the AS reply key.
	as-REQ [1] OCTET STRING,		as-REQ [1] OCTET STRING,
	-- This contains the AS-REQ in the request.		-- The DER encoding of the AS-REQ [RFC4120] from the
			-- client.
	pk-as-rep [2] OCTET STRING,		pk-as-rep [2] OCTET STRING,
	-- Contains the DER encoding of the type		-- The DER encoding of the PA-PK-AS-REP [RFC4556] in the
	-- PA-PK-AS-REP [RFC4556] in the KDC reply.		-- KDC reply.
	...		...
	}		}
	AuthPack ::= SEQUENCE {		AuthPack ::= SEQUENCE {
	pkAuthenticator [0] PKAuthenticator,		pkAuthenticator [0] PKAuthenticator,
	clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,		clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
	supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier		supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
	OPTIONAL,		OPTIONAL,
	clientDHNonce [3] DHNonce OPTIONAL,		clientDHNonce [3] DHNonce OPTIONAL,
	...,		...,
End of changes. 51 change blocks.
	92 lines changed or deleted		118 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/