< draft-ietf-kitten-pkinit-alg-agility-04.txt		draft-ietf-kitten-pkinit-alg-agility-05.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: August 7, 2019 M. Wasserman		Expires: August 30, 2019 M. Wasserman
	Painless Security		Painless Security
	G. Hudson, Ed.		G. Hudson, Ed.
	MIT		MIT
	February 3, 2019		February 26, 2019
	PKINIT Algorithm Agility		PKINIT Algorithm Agility
	draft-ietf-kitten-pkinit-alg-agility-04		draft-ietf-kitten-pkinit-alg-agility-05
	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, and 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
	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 August 7, 2019.		This Internet-Draft will expire on August 30, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 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
	skipping to change at page 2, line 35 ¶		skipping to change at page 2, line 35 ¶
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	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. Interoperability . . . . . . . . . . . . . . . . . . . . . . 11
	7.1. Common Inputs . . . . . . . . . . . . . . . . . . . . . . 11		8. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . 11
	7.2. Test Vector for SHA-1, enctype 18 . . . . . . . . . . . . 12		8.1. Common Inputs . . . . . . . . . . . . . . . . . . . . . . 11
	7.2.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 12		8.2. Test Vector for SHA-1, enctype 18 . . . . . . . . . . . . 12
	7.2.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 12		8.2.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 12
	7.3. Test Vector for SHA-256, enctype . . . . . . . . . . . . 13		8.2.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 12
	7.3.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13		8.3. Test Vector for SHA-256, enctype . . . . . . . . . . . . 13
	7.3.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13		8.3.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13
	7.4. Test Vector for SHA-512, enctype . . . . . . . . . . . . 13		8.3.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13
	7.4.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13		8.4. Test Vector for SHA-512, enctype . . . . . . . . . . . . 13
	7.4.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13		8.4.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 13		8.4.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14		9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	11.1. Normative References . . . . . . . . . . . . . . . . . . 14		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	11.2. Informative References . . . . . . . . . . . . . . . . . 15		12.1. Normative References . . . . . . . . . . . . . . . . . . 14
			12.2. Informative References . . . . . . . . . . . . . . . . . 15
	Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . 16		Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		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.
	skipping to change at page 5, line 14 ¶		skipping to change at page 5, line 16 ¶
	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 indicate the digest algorithms		-- identifiers indicating the digest algorithms
	-- acceptable by the KDC for signing CMS data in		-- acceptable to 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], implementations conforming		described in Section 3.2.2 of [RFC4556], implementations conforming
	to this specification can OPTIONALLY send a list of digest algorithms		to this specification can OPTIONALLY send a list of digest algorithms
	acceptable by the KDC for use by the Certificate Authority (CA) in		acceptable to the KDC for use by the Certificate Authority (CA) in
	signing the client's X.509 certificate, in the decreasing preference		signing the client's X.509 certificate, in the decreasing preference
	order. This is accomplished by including a TD_CERT_DIGEST_ALGORITHMS		order. This is accomplished by including a TD_CERT_DIGEST_ALGORITHMS
	typed data element in the error data. The corresponding data		typed data element in the error data. The corresponding data
	contains the ASN.1 DER encoding of the structure TD-CERT-DIGEST-		contains the ASN.1 DER encoding of the structure TD-CERT-DIGEST-
	ALGORITHMS-DATA defined 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 indicating 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 are acceptable to the KDC
	-- the process of validating the client's X.509		-- in the process of validating the client's X.509
	-- certificate, in the order of decreasing		-- certificate, in the order of decreasing
	-- preference.		-- preference.
	rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL,		rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL,
	-- This identifies the digest algorithm that was		-- This identifies the digest algorithm that was
	-- used to sign the client's X.509 certificate and		-- used to sign the client's X.509 certificate and
	-- has been rejected by the KDC in the process of		-- has been rejected by the KDC in the process of
	-- validating the client's X.509 certificate		-- validating the client's X.509 certificate
	-- [RFC5280].		-- [RFC5280].
	...		...
	}		}
	The KDC fills in allowedAlgorithm field with the list of algorithm		The KDC fills in the allowedAlgorithm field with the list of
	[RFC5652] identifiers that identify digest algorithms that are used		algorithm [RFC5652] identifiers indicating digest algorithms that are
	by the CA to sign the client's X.509 certificate and acceptable by		used by the CA to sign the client's X.509 certificate and are
	the KDC in the process of validating the client's X.509 certificate,		acceptable to the KDC in the process of validating the client's X.509
	in the order of decreasing preference. The rejectedAlgorithm field		certificate, in the order of decreasing preference. The
	identifies the signing algorithm for use in signing the client's		rejectedAlgorithm field identifies the signing algorithm for use in
	X.509 certificate that has been rejected by the KDC in the process of		signing the client's X.509 certificate that has been rejected by the
	validating the client's certificate [RFC5280].		KDC in the process of 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].
	The KDF algorithm described in this document (based on [SP80056A])		The KDF algorithm described in this document (based on [SP80056A])
	can be implemented using any cryptographic hash function.		can be implemented using any cryptographic hash function.
	skipping to change at page 9, line 43 ¶		skipping to change at page 9, line 43 ¶
	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
	encoding of the type PA-PK-AS-REP [RFC4556] in the KDC reply. The		encoding of the type PA-PK-AS-REP [RFC4556] in the KDC reply. The
	PkinitSuppPubInfo provides a cryptographic bindings between the pre-		PkinitSuppPubInfo provides a cryptographic bindings between the pre-
	authentication data and the corresponding ticket request and		authentication data and the corresponding ticket request and
	response, thus addressing the concerns described in Section 3.		response, thus addressing the concerns described in Section 3.
	The KDF is negotiated between the client and the KDC. The client		The KDF is negotiated between the client and the KDC. The client
	sends an unordered set of supported KDFs in the request, and the KDC		sends an unordered set of supported KDFs in the request, and the KDC
	picks one from the set in the reply.		picks one from the set in the reply.
	To acomplish this, the AuthPack structure in [RFC4556] is extended as		To accomplish this, the AuthPack structure in [RFC4556] is extended
	follows:		as follows:
	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,
	...,		...,
	supportedKDFs [4] SEQUENCE OF KDFAlgorithmId OPTIONAL,		supportedKDFs [4] SEQUENCE OF KDFAlgorithmId OPTIONAL,
	-- Contains an unordered set of KDFs supported by the		-- Contains an unordered set of KDFs supported by the
	skipping to change at page 10, line 43 ¶		skipping to change at page 10, line 43 ¶
	DHRepInfo ::= SEQUENCE {		DHRepInfo ::= SEQUENCE {
	dhSignedData [0] IMPLICIT OCTET STRING,		dhSignedData [0] IMPLICIT OCTET STRING,
	serverDHNonce [1] DHNonce OPTIONAL,		serverDHNonce [1] DHNonce OPTIONAL,
	...,		...,
	kdf [2] KDFAlgorithmId OPTIONAL,		kdf [2] KDFAlgorithmId OPTIONAL,
	-- The KDF picked by the KDC.		-- The KDF picked by the KDC.
	...		...
	}		}
	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. If the supportedKDFs field is present in the
	comforming KDC if the supportedKDFs field is present in the request,		request, a KDC conforming to this specification MUST choose one of
	and it MUST be one of the KDFs supported by the client as indicated		the KDFs supported by the client and indicate its selection in the
	in the request. Which KDF is chosen is a matter of the local policy		kdf field in the reply. If the supportedKDFs field is absent in the
	on the KDC.		request, the KDC MUST omit the kdf field in the reply and use the key
			derivation function from Section 3.2.3.1 of [RFC4556]. If none of
			the KDFs supported by the client is acceptable to the KDC, the KDC
			MUST reply with the new error code KDC_ERR_NO_ACCEPTABLE_KDF:
	If the supportedKDFs field is not present in the request, the kdf		o KDC_ERR_NO_ACCEPTABLE_KDF 100
	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, or that the		KDC is not updated to conform with this specification, or that the
	exchange was subjected to a downgrade attack. It is a matter of		exchange was subjected to a downgrade attack. It is a matter of
	local policy on the client whether to reject the reply when the kdf		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		field is absent in the reply; if compatibility with non-updated KDCs
	is not a concern, the reply should be rejected.		is not a concern, the reply should be rejected.
	Implementations comforming to this specification MUST support id-		Implementations conforming to this specification MUST support id-
	pkinit-kdf-ah-sha256.		pkinit-kdf-ah-sha256.
	This document introduces the following new PKINIT error code:		7. Interoperability
	o KDC_ERR_NO_ACCEPTABLE_KDF 100		An old client interoperating with a new KDC will not include the
			supportedKDFs field in the request. The KDC MUST omit the kdf field
			in the reply and use the [RFC4556] KDF as expected by the client, or
			reject the request if local policy forbids use of the old KDF.
	If no acceptable KDF is found, the error KDC_ERR_NO_ACCEPTABLE_KDF		A new client interoperating with an old KDC will include the
	(100) will be returned..		supportedKDFs field in the request; this field will be ignored as an
			unknown extension by the KDC. The KDC will omit the kdf field in the
			reply and will use the [RFC4556] KDF. The client can deduce from the
			omitted kdf field that the KDC is not updated to conform to this
			specification, or that the exchange was subjected to a downgrade
			attack. The client MUST use the [RFC4556] KDF, or reject the reply
			if local policy forbids the use of the old KDF.
	7. Test vectors		8. Test vectors
	This section contains test vectors for the KDF defined above.		This section contains test vectors for the KDF defined above.
	7.1. Common Inputs		8.1. Common Inputs
	Z: Length = 256 bytes, Hex Representation = (All Zeros)		Z: Length = 256 bytes, Hex Representation = (All Zeros)
	00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000		00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
	00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000		00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
	00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000		00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
	00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000		00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
	00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000		00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
	00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000		00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
	00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000		00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
	00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000		00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
	skipping to change at page 12, line 28 ¶		skipping to change at page 12, line 28 ¶
	as-req: Length = 10 bytes, Hex Representation =		as-req: Length = 10 bytes, Hex Representation =
	AAAAAAAA AAAAAAAA AAAA		AAAAAAAA AAAAAAAA AAAA
	pk-as-rep: Length = 9 bytes, Hex Representation =		pk-as-rep: Length = 9 bytes, Hex Representation =
	BBBBBBBB BBBBBBBB BB		BBBBBBBB BBBBBBBB BB
	ticket: Length = 55 bytes, Hex Representation =		ticket: Length = 55 bytes, Hex Representation =
	61353033 A0030201 05A1071B 0553552E 5345A210 300EA003 020101A1 0730051B		61353033 A0030201 05A1071B 0553552E 5345A210 300EA003 020101A1 0730051B
	036C6861 A311300F A0030201 12A20804 0668656A 68656A		036C6861 A311300F A0030201 12A20804 0668656A 68656A
	7.2. Test Vector for SHA-1, enctype 18		8.2. Test Vector for SHA-1, enctype 18
	7.2.1. Specific Inputs		8.2.1. Specific Inputs
	algorithm-id: (id-pkinit-kdf-ah-sha1) Length = 8 bytes, Hex		algorithm-id: (id-pkinit-kdf-ah-sha1) Length = 8 bytes, Hex
	Representation = 2B060105 02030601		Representation = 2B060105 02030601
	enctype: (aes256-cts-hmac-sha1-96) Length = 1 byte, Decimal		enctype: (aes256-cts-hmac-sha1-96) Length = 1 byte, Decimal
	Representation = 18		Representation = 18
	7.2.2. Outputs		8.2.2. Outputs
	key-material: Length = 32 bytes, Hex Representation =		key-material: Length = 32 bytes, Hex Representation =
	E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD		E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD
	key: Length = 32 bytes, Hex Representation =		key: Length = 32 bytes, Hex Representation =
	E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD		E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD
	7.3. Test Vector for SHA-256, enctype		8.3. Test Vector for SHA-256, enctype
	7.3.1. Specific Inputs		8.3.1. Specific Inputs
	algorithm-id: (id-pkinit-kdf-ah-sha256) Length = 8 bytes, Hex		algorithm-id: (id-pkinit-kdf-ah-sha256) Length = 8 bytes, Hex
	Representation = 2B060105 02030602		Representation = 2B060105 02030602
	enctype: (aes256-cts-hmac-sha1-96) Length = 1 byte, Decimal		enctype: (aes256-cts-hmac-sha1-96) Length = 1 byte, Decimal
	Representation = 18		Representation = 18
	7.3.2. Outputs		8.3.2. Outputs
	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		8.4. Test Vector for SHA-512, enctype
	7.4.1. Specific Inputs		8.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		8.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		9. 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 a given negotiation		functions and other cryptographic functions. If a given negotiation
	is unauthenticated, care must be taken to accept only secure values;		is unauthenticated, care must be taken to accept only secure values;
	to do otherwise allows an active attacker to perform a downgrade		to do otherwise allows an active attacker to perform a downgrade
	attack.		attack.
	9. Acknowledgements		10. Acknowledgements
	Jeffery Hutzelman, Shawn Emery, Tim Polk and Kelley Burgin reviewed		Jeffery Hutzelman, Shawn Emery, Tim Polk, Kelley Burgin, Ben Kaduk,
	the document and provided suggestions for improvements.		and Scott Bradner reviewed the document and provided suggestions for
			improvements.
	10. IANA Considerations		11. 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
	section 7.1 of RFC 6113 to refer to this specification. These values		section 7.1 of RFC 6113 to refer to this specification. These values
	were reserved for this specification in the initial registrations.		were reserved for this specification in the initial registrations.
	TD-CMS-DIGEST-ALGORITHMS 111 [ALG-AGILITY]		TD-CMS-DIGEST-ALGORITHMS 111 [ALG-AGILITY]
	TD-CERT-DIGEST-ALGORITHMS 112 [ALG-AGILITY]		TD-CERT-DIGEST-ALGORITHMS 112 [ALG-AGILITY]
	11. References		12. References
	11.1. Normative References		12.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for		[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
	Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February		Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February
	2005, <https://www.rfc-editor.org/info/rfc3961>.		2005, <https://www.rfc-editor.org/info/rfc3961>.
	skipping to change at page 15, line 40 ¶		skipping to change at page 15, line 40 ¶
	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
	Rules (DER)", November 2008.		Rules (DER)", November 2008.
	11.2. Informative References		12.2. Informative References
	[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,		[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
	DOI 10.17487/RFC1321, April 1992,		DOI 10.17487/RFC1321, April 1992,
	<https://www.rfc-editor.org/info/rfc1321>.		<https://www.rfc-editor.org/info/rfc1321>.
	[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For		[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
	Public Keys Used For Exchanging Symmetric Keys", BCP 86,		Public Keys Used For Exchanging Symmetric Keys", BCP 86,
	RFC 3766, DOI 10.17487/RFC3766, April 2004,		RFC 3766, DOI 10.17487/RFC3766, April 2004,
	<https://www.rfc-editor.org/info/rfc3766>.		<https://www.rfc-editor.org/info/rfc3766>.
	skipping to change at page 17, line 28 ¶		skipping to change at page 17, line 28 ¶
	::= { 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 indicating the digest algorithms
	-- acceptable by the KDC for signing CMS data in		-- acceptable to 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,
	-- Contains the list of CMS algorithm [RFC5652]		-- Contains the list of CMS algorithm [RFC5652]
	-- identifiers that identify the digest algorithms		-- identifiers indicating 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 are acceptable to the KDC
	-- the process of validating the client's X.509		-- in the process of validating the client's X.509
	-- certificate, in the order of decreasing		-- certificate, in the order of decreasing
	-- preference.		-- preference.
	rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL,		rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL,
	-- This identifies the digest algorithm that was		-- This identifies the digest algorithm that was
	-- used to sign the client's X.509 certificate and		-- used to sign the client's X.509 certificate and
	-- has been rejected by the KDC in the process of		-- has been rejected by the KDC in the process of
	-- validating the client's X.509 certificate		-- validating the client's X.509 certificate
	-- [RFC5280].		-- [RFC5280].
	...		...
	}		}
End of changes. 38 change blocks.
	74 lines changed or deleted		87 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/