< draft-ietf-kitten-pkinit-alg-agility-05.txt		draft-ietf-kitten-pkinit-alg-agility-06.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 Oracle Corporation
	Expires: August 30, 2019 M. Wasserman		Expires: September 7, 2019 M. Wasserman
	Painless Security		Painless Security
	G. Hudson, Ed.		G. Hudson, Ed.
	MIT		MIT
	February 26, 2019		March 6, 2019
	PKINIT Algorithm Agility		PKINIT Algorithm Agility
	draft-ietf-kitten-pkinit-alg-agility-05		draft-ietf-kitten-pkinit-alg-agility-06
	Abstract		Abstract
	This document updates PKINIT, as defined in RFC 4556, to remove		This document updates the Public Key Cryptography for Initial
			Authentication in Kerberos standard (PKINIT) [RFC4556], 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
	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
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 44 ¶
	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 30, 2019.		This Internet-Draft will expire on September 7, 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 36 ¶		skipping to change at page 2, line 41 ¶
	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. Interoperability . . . . . . . . . . . . . . . . . . . . . . 11		7. Interoperability . . . . . . . . . . . . . . . . . . . . . . 11
	8. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . 11		8. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . 12
	8.1. Common Inputs . . . . . . . . . . . . . . . . . . . . . . 11		8.1. Common Inputs . . . . . . . . . . . . . . . . . . . . . . 12
	8.2. Test Vector for SHA-1, enctype 18 . . . . . . . . . . . . 12		8.2. Test Vector for SHA-1, enctype 18 . . . . . . . . . . . . 12
	8.2.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 12		8.2.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 12
	8.2.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 12		8.2.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 12
	8.3. Test Vector for SHA-256, enctype . . . . . . . . . . . . 13		8.3. Test Vector for SHA-256, enctype . . . . . . . . . . . . 13
	8.3.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13		8.3.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13
	8.3.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13		8.3.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13
	8.4. Test Vector for SHA-512, enctype . . . . . . . . . . . . 13		8.4. Test Vector for SHA-512, enctype . . . . . . . . . . . . 13
	8.4.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13		8.4.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13
	8.4.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13		8.4.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 13		9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	12.1. Normative References . . . . . . . . . . . . . . . . . . 14		12.1. Normative References . . . . . . . . . . . . . . . . . . 14
	12.2. Informative References . . . . . . . . . . . . . . . . . 15		12.2. Informative References . . . . . . . . . . . . . . . . . 15
	Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . 16		Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	This document updates PKINIT [RFC4556] to remove protocol structures		The Public Key Cryptography for Initial Authentication in Kerberos
	tied to specific cryptographic algorithms. The PKINIT key derivation		(PKINIT) standard [RFC4556] defines several protocol structures that
	function is made negotiable, the digest algorithms for signing the		are either tied to SHA-1 [RFC6234], or do not support negotiation or
	pre-authentication data and the client's X.509 certificates are made		discovery, but are instead based on local policy:
	discoverable.
	These changes provide preemptive protection against vulnerabilities		o The checksum algorithm in the authentication request is hardwired
	discovered in the future against any specific cryptographic		to use SHA-1.
	algorithm, and allow incremental deployment of newer algorithms.
			o The acceptable digest algorithms for signing the authentication
			data are not discoverable.
			o The key derivation function in Section 3.2.3.1 of [RFC4556] is
			hardwired to use SHA-1.
			o The acceptable digest algorithms for signing the client X.509
			certificates are not discoverable.
	In August 2004, Xiaoyun Wang's research group reported MD4 [RFC6150]		In August 2004, Xiaoyun Wang's research group reported MD4 [RFC6150]
	collisions generated using hand calculation [WANG04], alongside		collisions generated using hand calculation [WANG04], alongside
	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, as recommended by BCP 201 [RFC7696].		algorithms, as recommended by BCP 201 [RFC7696].
	This document updates PKINIT to provide crypto algorithm agility.
	Several protocol structures used in the [RFC4556] protocol are either
	tied to SHA-1, or do not support negotiation or discovery, but are
	instead based on local policy. The following concerns have been
	addressed in this update:
	o The checksum algorithm in the authentication request is hardwired
	to use SHA-1 [RFC6234].
	o The acceptable digest algorithms for signing the authentication
	data are not discoverable.
	o The key derivation function in Section 3.2.3.1 of [RFC4556] is
	hardwired to use SHA-1.
	o The acceptable digest algorithms for signing the client X.509
	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.
	skipping to change at page 4, line 48 ¶		skipping to change at page 4, line 42 ¶
	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, and nothing else cryptographically binds the AS request to the		weak, and nothing else cryptographically binds the AS request to the
	ticket response. In this case, the new KDF selected by the KDC as		ticket response. In this case, the new KDF selected by the KDC as
	described in Section 6 provides the cryptographic binding and		described in Section 6 provides the cryptographic binding and
	integrity protection.		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		Section 3.2.2 of [RFC4556] is updated to add optional typed data to
	as described in Section 3.2.2 of [RFC4556], implementations		the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error. When a KDC
	conforming to this specification can OPTIONALLY send back a list of		implementation conforming to this specification returns this error
	supported CMS types signifying the digest algorithms supported by the		code, it MAY include in a list of supported CMS types signifying the
	KDC, in the decreasing preference order. This is accomplished by		digest algorithms supported by the KDC, in the decreasing preference
	including a TD_CMS_DATA_DIGEST_ALGORITHMS typed data element in the		order. This is accomplished by including a
	error data.		TD_CMS_DATA_DIGEST_ALGORITHMS typed data element in the 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 indicating the digest algorithms		-- identifiers indicating the digest algorithms
	-- acceptable to 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		Section 3.2.2 of [RFC4556] is updated to add optional typed data to
	KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned as		the KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED error. When a KDC conforming
	described in Section 3.2.2 of [RFC4556], implementations conforming		to this specification returns this error, it MAY send a list of
	to this specification can OPTIONALLY send a list of digest algorithms		digest algorithms acceptable to the KDC for use by the Certificate
	acceptable to the KDC for use by the Certificate Authority (CA) in		Authority (CA) in signing the client's X.509 certificate, in the
	signing the client's X.509 certificate, in the decreasing preference		decreasing preference order. This is accomplished by including a
	order. This is accomplished by including a TD_CERT_DIGEST_ALGORITHMS		TD_CERT_DIGEST_ALGORITHMS typed data element in the error data. The
	typed data element in the error data. The corresponding data		corresponding data contains the ASN.1 DER encoding of the structure
	contains the ASN.1 DER encoding of the structure TD-CERT-DIGEST-		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 indicating 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 are acceptable to the KDC		-- X.509 certificate and are acceptable to the KDC
	-- in the process of validating the client's X.509		-- in the process of validating the client's X.509
	skipping to change at page 6, line 36 ¶		skipping to change at page 6, line 36 ¶
	algorithm [RFC5652] identifiers indicating digest algorithms that are		algorithm [RFC5652] identifiers indicating digest algorithms that are
	used by the CA to sign the client's X.509 certificate and are		used by the CA to sign the client's X.509 certificate and are
	acceptable to the KDC in the process of validating the client's X.509		acceptable to the KDC in the process of validating the client's X.509
	certificate, in the order of decreasing preference. The		certificate, in the order of decreasing preference. The
	rejectedAlgorithm field identifies the signing algorithm for use in		rejectedAlgorithm field identifies the signing algorithm for use in
	signing the client's X.509 certificate that has been rejected by the		signing the client's X.509 certificate that has been rejected by the
	KDC in the process of 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		Section 3.2.3.1 of [RFC4556] is updated to define additional Key
	a Key Derivation Function (KDF) that derives a Kerberos protocol key		Derivation Functions (KDFs) to derive a Kerberos protocol key based
	based on the secret value generated by the Diffie-Hellman key		on the secret value generated by the Diffie-Hellman key exchange.
	exchange. This KDF requires the use of SHA-1 [RFC6234].		Section 3.2.1 of [RFC4556] is updated to add a new field to the
			AuthPack structure to indicate which new KDFs are supported by the
			client. Section 3.2.3 of [RFC4556] is updated to add a new field to
			the DHRepInfo structure to indicate which KDF is selected by the KDC.
	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.
	A new KDF for PKINIT usage is identified by an object identifier.		A new KDF for PKINIT usage is identified by an object identifier.
	The following KDF 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) }
	skipping to change at page 11, line 20 ¶		skipping to change at page 11, line 20 ¶
	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 conforming to this specification MUST support id-		Implementations conforming to this specification MUST support id-
	pkinit-kdf-ah-sha256.		pkinit-kdf-ah-sha256.
	7. Interoperability		7. Interoperability
			An old client interoperating with a new KDC will not recognize a TD-
			CMS-DIGEST-ALGORITHMS-DATA element in a
			KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error, or a TD-CERT-
			DIGEST-ALGORITHMS-DATA element in a
			KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED error. Because the error data is
			encoded as typed data, the client will ignore the unrecognized
			elements.
			An old KDC interoperating with a new client will not include a TD-
			CMS-DIGEST-ALGORITHMS-DATA element in a
			KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error, or a TD-CERT-
			DIGEST-ALGORITHMS-DATA element in a
			KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED error. To the client this
			appears just as if a new KDC elected not to include a list of digest
			algorithms.
	An old client interoperating with a new KDC will not include the		An old client interoperating with a new KDC will not include the
	supportedKDFs field in the request. The KDC MUST omit the kdf field		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		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.		reject the request if local policy forbids use of the old KDF.
	A new client interoperating with an old KDC will include the		A new client interoperating with an old KDC will include the
	supportedKDFs field in the request; this field will be ignored as an		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		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		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		omitted kdf field that the KDC is not updated to conform to this
	skipping to change at page 15, line 46 ¶		skipping to change at page 16, line 5 ¶
	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.
	12.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
	Public Keys Used For Exchanging Symmetric Keys", BCP 86,
	RFC 3766, DOI 10.17487/RFC3766, April 2004,
	<https://www.rfc-editor.org/info/rfc3766>.
	[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		[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
	Agility and Selecting Mandatory-to-Implement Algorithms",		Agility and Selecting Mandatory-to-Implement Algorithms",
	BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,		BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
	<https://www.rfc-editor.org/info/rfc7696>.		<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
	Industry: Agreement of Symmetric Keys Using Discrete
	Logarithm Cryptography", 2003.
	Appendix A. PKINIT ASN.1 Module		Appendix A. PKINIT ASN.1 Module
	KerberosV5-PK-INIT-Agility-SPEC {		KerberosV5-PK-INIT-Agility-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) agility (1)		security(5) kerberosV5(2) modules(4) pkinit(5) agility (1)
	} DEFINITIONS EXPLICIT TAGS ::= BEGIN		} DEFINITIONS EXPLICIT TAGS ::= BEGIN
	IMPORTS		IMPORTS
	AlgorithmIdentifier, SubjectPublicKeyInfo		AlgorithmIdentifier, SubjectPublicKeyInfo
	FROM PKIX1Explicit88 { iso (1)		FROM PKIX1Explicit88 { iso (1)
	skipping to change at page 19, line 6 ¶		skipping to change at page 19, line 4 ¶
	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.
	...		...
	}		}
	END		END
	Authors' Addresses		Authors' Addresses
	Love Hornquist Astrand		Love Hornquist Astrand
	Apple, Inc		Apple, Inc
	Cupertino, CA		Cupertino, CA
	USA		USA
	Email: lha@apple.com		Email: lha@apple.com
	Larry Zhu		Larry Zhu
	Microsoft Corporation		Oracle Corporation
	One Microsoft Way		500 Oracle Parkway
	Redmond, WA 98052		Redwood Shores, CA 94065
	USA		USA
	Email: lzhu@microsoft.com		Email: larryzhu@live.com
	Margaret Wasserman		Margaret Wasserman
	Painless Security		Painless Security
	356 Abbott Street		356 Abbott Street
	North Andover, MA 01845		North Andover, MA 01845
	USA		USA
	Phone: +1 781 405-7464		Phone: +1 781 405-7464
	Email: mrw@painless-security.com		Email: mrw@painless-security.com
	URI: http://www.painless-security.com		URI: http://www.painless-security.com
End of changes. 22 change blocks.
	73 lines changed or deleted		69 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/