< draft-iab-crypto-alg-agility-01.txt		draft-iab-crypto-alg-agility-02.txt >
	Internet-Draft R. Housley		Internet-Draft R. Housley
	Intended Status: Best Current Practice Vigil Security		Intended Status: Best Current Practice Vigil Security
	Expires: 29 December 2014 27 June 2014		Expires: 2 July 2015 29 December 2014
	Guidelines for Cryptographic Algorithm Agility		Guidelines for Cryptographic Algorithm Agility
	<draft-iab-crypto-alg-agility-01.txt>		<draft-iab-crypto-alg-agility-02.txt>
	Abstract		Abstract
	Many IETF protocols may use of cryptographic algorithms to provide		Many IETF protocols use cryptographic algorithms to provide
	confidentiality, integrity, or non-repudiation. Communicating peers		confidentiality, integrity, or non-repudiation. Communicating peers
	must support the same cryptographic algorithm or algorithms for these		must support the same set of cryptographic algorithms for these
	mechanisms to work properly. This memo provides guidelines for		mechanisms to work properly. This memo provides guidelines to ensure
	ensuring that such a protocol has the ability to migrate from one		that protocols have the ability to migrate from one algorithm suite
	algorithm to another over time.		to another over time.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	skipping to change at page 2, line 5 ¶		skipping to change at page 2, line 5 ¶
	http://www.ietf.org/1id-abstracts.html		http://www.ietf.org/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	Copyright and License Notice		Copyright and License Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
			Guidelines for Cryptographic Algorithm Agility December 2014
	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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	1. Introduction		1. Introduction
	Many IETF protocols use cryptographic algorithms to provide		Many IETF protocols use cryptographic algorithms to provide
	confidentiality, integrity, authentication, or digital signature.		confidentiality, integrity, authentication, or digital signature.
	For interoperability, communicating peers must support the same		For interoperability, communicating peers must support the same set
	cryptographic algorithm or algorithms. Yet, cryptographic algorithms		of cryptographic algorithms. In most cases, a combination of
	become weaker with time. As new cryptanalysis techniques are		compatible cryptographic algorithms will be used to provide the
	developed and computing capabilities improve, the work factor to		desired security services. The set of cryptographic algorithms being
	break a particular cryptographic algorithm will reduce. Algorithm		used at a particular time is often referred to as a cryptographic
	agility is achieved when a protocol can easily support more that one		algorithm suite.
	set of cryptographic algorithms. For the protocol implementer, this
	means that implementations should be modular to easily accommodate		Cryptographic algorithms age; they become weaker with time. As new
	the insertion of new algorithms. For the protocol designer, this		cryptanalysis techniques are developed and computing capabilities
	means that one or more algorithm identifier must be carried, the set		improve, the work factor to break a particular cryptographic
	of mandatory-to-implement algorithms will change over time, and an		algorithm will reduce. Algorithm agility is achieved when a protocol
	IANA registry of algorithm identifiers will be needed.		can easily support more that one cryptographic algorithm suite, which
			ensures that protocols can migrate from one algorithm suite to
			another over time. For the protocol implementer, this means that
			implementations should be modular to easily accommodate the insertion
			of new algorithms. For the protocol designer, this means that one or
			more algorithm identifier must be carried, the set of mandatory-to-
			implement algorithms will change over time, and an IANA registry of
			algorithm identifiers will be needed.
	1.1. Terminology		1.1. Terminology
	The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,		The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
	SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this		SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
	document, are to be interpreted as described in [RFC2119].		document, are to be interpreted as described in [RFC2119].
	2. Algorithm Agility Guidelines		2. Algorithm Agility Guidelines
	These guidelines are for use by IETF working groups and protocol		These guidelines are for use by IETF working groups and protocol
	authors for IETF protocols that make use of cryptographic algorithms.		authors for IETF protocols that make use of cryptographic algorithms.
	2.1. Algorithm Identifiers		2.1. Algorithm Identifiers
	IETF protocols that make use of cryptographic algorithms MUST carry		IETF protocols that make use of cryptographic algorithms MUST carry
			Guidelines for Cryptographic Algorithm Agility December 2014
	one or more algorithm identifier.		one or more algorithm identifier.
	Some approaches carry one identifier for each algorithm that is used.		Some approaches carry one identifier for each algorithm that is used.
	Other approaches carry one identifier for a suite of algorithms.		Other approaches carry one identifier for a suite of algorithms.
	Both approaches are used in IETF protocols. Designers are encouraged		Both approaches are used in IETF protocols. Designers are encouraged
	to pick one of these approaches and use it consistently throughout		to pick one of these approaches and use it consistently throughout
	the protocol or family of protocols. However, suite identifiers make		the protocol or family of protocols. However, suite identifiers make
	it easier for the protocol designer to ensure that the algorithm		it easier for the protocol designer to ensure that the algorithm
	selections are complete and compatible for future assignments.		selections are complete and compatible for future assignments.
			Regardless of the approach used, protocols MUST NOT negotiate
			symmetric ciphers and cipher modes separately.
	In the IPsec protocol suite, IKE [RFC2409][RFC4306] carries the		In the IPsec protocol suite, IKE [RFC2409][RFC4306] carries the
	algorithm identifiers for AH and ESP [RFC4302][RFC4303]. Such		algorithm identifiers for AH and ESP [RFC4302][RFC4303]. Such
	separation is completely fine design choice.		separation is completely fine design choice.
	An IANA registry SHOULD be used for these algorithm identifiers.		An IANA registry SHOULD be used for these algorithm identifiers.
	2.2. Mandatory-to-Implement Algorithms		2.2. Mandatory-to-Implement Algorithms
	For interoperability, communicating peers must support the same		For interoperability, communicating peers must support the
	cryptographic algorithm or algorithms. For this reason, the protocol		cryptographic algorithm suite. For this reason, the protocol SHOULD
	SHOULD specify one or more mandatory-to-implement algorithm. This is		specify one or more mandatory-to-implement algorithm. This is not
	not done for protocols that are embedded in other protocols. For		done for protocols that are embedded in other protocols. For
	example, S/MIME [RFC5751] makes use of the cryptographic message		example, S/MIME [RFC5751] makes use of the cryptographic message
	Syntax (CMS) [RFC5652]. Other protocols also make use of CMS.		Syntax (CMS) [RFC5652]. Other protocols also make use of CMS.
	S/MIME specifies the mandatory-to-implement algorithms, not CMS.		S/MIME specifies the mandatory-to-implement algorithms, not CMS.
	The IETF must be able to change the mandatory-to-implement algorithms		The IETF needs to be able to change the mandatory-to-implement
	over time. It is highly desirable to make this change without		algorithms over time. It is highly desirable to make this change
	updating the base protocol specification. Therefore the base		without updating the base protocol specification. Therefore the base
	protocol specification SHOULD reference a companion algorithms		protocol specification SHOULD reference a companion algorithms
	document, allowing the update of one document without necessarily		document, allowing the update of one document without necessarily
	requiring an update to the other. This division also facilitates the		requiring an update to the other. This division also facilitates the
	advancement of the base protocol specification on the maturity ladder		advancement of the base protocol specification on the standards
	even if the algorithm document changes frequently.		maturity ladder even if the algorithm document changes frequently.
	Some cryptographic algorithms are inherently tied to a specific key		Some cryptographic algorithms are inherently tied to a specific key
	size, but others allow many different key sizes. Likewise, some		size, but others allow many different key sizes. Likewise, some
	algorithms support parameters of different sizes, such as integrity		algorithms support parameters of different sizes, such as integrity
	check values or nonces. The algorithm specification MUST identify		check values or nonces. The algorithm specification MUST identify
	the specific key sizes ans parameter sizes that are to be supported.		the specific key sizes and parameter sizes that are to be supported.
	When more than one key size is available, expect the mandatory-to-		When more than one key size is available, expect the mandatory-to-
	implement key size to increase over time.		implement key size to increase over time.
	Guidance on cryptographic key size for public keys can be found in		Guidance on cryptographic key size for asymmetric keys can be found
	BCP 86 [RFC3766].		in BCP 86 [RFC3766].
			Guidelines for Cryptographic Algorithm Agility December 2014
	Symmetric keys used for protection of long-term values SHOULD be at		Symmetric keys used for protection of long-term values SHOULD be at
	least 128 bits.		least 128 bits.
	2.3. Transition from Weak Algorithms		2.3. Transition from Weak Algorithms
	Transition from an algorithm that is found to be weak can be tricky.		Transition from an algorithm that is found to be weak can be tricky.
	It is straightforward to specify an alternative algorithm. When the		It is straightforward to specify an alternative algorithm. When the
	alternative algorithm is widely deployed, then the weak algorithm		alternative algorithm is widely deployed, then the weak algorithm
	should no longer be used. However, knowledge about the		should no longer be used. However, knowledge about the
	implementation and deployment of the alternative algorithm is		implementation and deployment of the alternative algorithm is
	imperfect, so one cannot be completely assured of interoperability		imperfect, so one cannot be completely assured of interoperability
	with alternative algorithm.		with alternative algorithm.
	To facilitate transition, protocols MUST be able to advertise which		To facilitate transition, protocols MUST be able to advertise which
	algorithms are supported. This may naturally occur as part of an		algorithms are supported. This may naturally occur as part of an
	algorithm selection or negotiation mechanism.		algorithm selection or negotiation mechanism.
	In the worst case, the algorithm may be found to be tragically		In the worst case, the algorithm may be found to be tragically
	flawed, permitting a casual attacker to download a simple script to		flawed, permitting a casual attacker to download a simple script to
	break it. This has happened when a secure algorithm is used		break it. Sadly, this has happened when a secure algorithm is used
	incorrectly or used with poor key management. In such situations,		incorrectly or used with poor key management. In such situations,
	the protection offered by the algorithm is severely compromised,		the protection offered by the algorithm is severely compromised,
	perhaps to the point that one wants to stop offering to use the weak		perhaps to the point that one wants to stop using the weak algorithm
	algorithm and refuse offers to use the weak algorithm well before the		altogether, rejecting offers to use the weak algorithm well before
	alternative algorithm is widely deployed.		the alternative algorithm is widely deployed.
	In any case, there come a point where one refuses to use the weak		In any case, there comes a point in time where one refuses to use the
	algorithm. This can happen on a flag day, or each installation can		weak algorithm. This can happen on a flag day, or each installation
	select a date on their own.		can select a date on their own.
	2.4. Balance Security Strength		2.4. Balance Security Strength
	When selecting a suite of cryptographic algorithms, the strength of		When selecting a suite of cryptographic algorithms, the strength of
	each algorithm MUST be considered.		each algorithm MUST be considered.
	In CMS [RFC5652], a previously distributed symmetric key-encryption		In CMS [RFC5652], a previously distributed symmetric key-encryption
	key can be used to encrypt a content-encryption key, which is in turn		key can be used to encrypt a content-encryption key, which is in turn
	used to encrypt the content. The key-encryption and content-		used to encrypt the content. The key-encryption and content-
	encryption algorithms are often different. If, for example, a		encryption algorithms are often different. If, for example, a
	message content is encrypted with 168-bit Triple-DES key and the		message content is encrypted with 128-bit AES key and the content-
	Triple-DES content-encryption key is wrapped with a 40-bit RC2 key,		encryption key is wrapped with a 256-bit AES key, then at most 128
	then at most 40 bits of protection is provided. Thus, a trivial		bits of protection is provided. In this situation, the algorithm and
	search to determine the value of the 40-bit RC2 key will recover		key size selections should ensure that the key encryption is at least
	Triple-DES key, and then the recovered Triple-DES key can be used to		as strong as the content encryption. In general, wrapping one key
	decrypt the content. In this situation, the algorithm and key size		with another key of a different size yields the security strength of
	selections should ensure that the key encryption is at least as		the shorter key.
	strong as the content encryption.
			Guidelines for Cryptographic Algorithm Agility December 2014
	3. Algorithm Agility in Protocol Design		3. Algorithm Agility in Protocol Design
	Some attempts at algorithm agility have not been completely		Some attempts at algorithm agility have not been completely
	successful. This section provides some of the insights based on		successful. This section provides some of the insights based on
	protocol designs and deployments.		protocol designs and deployments.
	3.1. Algorithm Identifiers		3.1. Algorithm Identifiers
	If a protocol does not carry an algorithm identifier, then the		If a protocol does not carry an algorithm identifier, then the
	protocol version number or some other major change is needed to		protocol version number or some other major change is needed to
	transition from one algorithm to another. The inclusion of an		transition from one algorithm to another. The inclusion of an
	algorithm identifier is a minimal step toward cryptographic algorithm		algorithm identifier is a minimal step toward cryptographic algorithm
	agility. In addition, an IANA registry is needed to pair the		agility. In addition, an IANA registry is needed to pair the
	identifier with an algorithm specification.		identifier with an algorithm specification.
	Sometimes application layer protocols can make use of transport layer		Sometimes application layer protocols can make use of transport layer
	security protocols, such as TLS or DTLS. This insulates the		security protocols, such as TLS or DTLS. This insulates the
	application layer protocol from the cryptography altogether, but it		application layer protocol from the cryptography altogether, but it
	may still be necessary to handle the transition from unprotected to		may still be necessary to handle the transition from unprotected
	protected use of the the application layer protocol.		traffic to protected traffic in the application layer protocol.
	3.2. Migration Mechanisms		3.2. Migration Mechanisms
	Cryptographic algorithm selection or negotiation MUST be integrity		Cryptographic algorithm selection or negotiation SHOULD be integrity
	protected. When a protocol specifies a single mandatory-to-implement		protected. If selection is not integrity-protected, then the
	integrity algorithm, eventually that algorithm will be found to be		protocol will be subject to a downgrade attack. Without integrity
	weak. Perhaps there will be a flaw found in the integrity algorithm		protection of algorithm selection, transition to a new cryptographic
	that greatly shortens its expected life.		algorithm suite will not be smooth.
			When a protocol specifies a single mandatory-to-implement integrity
			algorithm, eventually that algorithm will be found to be weak.
			Perhaps there will be a flaw found in the integrity algorithm that
			greatly shortens its expected life.
	Extra care is needed when a mandatory-to-implement algorithm is used		Extra care is needed when a mandatory-to-implement algorithm is used
	to provide integrity protection for the negotiation of other		to provide integrity protection for the negotiation of other
	cryptographic algorithms used by the protocol. In this situation, a		cryptographic algorithms. In this situation, a flaw in the
	flaw in the mandatory-to-implement algorithm may allow an attacker to		mandatory-to-implement algorithm may allow an attacker to influence
	influence the choices of other algorithms.		the choices of the other algorithms.
	All algorithms age, and the advances in computing power available to		Performance is always a factor is selecting cryptographic algorithms.
	the attacker will eventually make them obsolete. For this reason,		In many algorithms, shorter keys offer higher performance, but less
	protocols need mechanisms to migrate from one algorithm to another		security. Performance and security need to be balanced. Yet, all
	over time, not just the integrity algorithm, but all cryptographic		algorithms age, and the advances in computing power available to the
	algorithms used by the protocol.		attacker will eventually make them obsolete. For this reason,
			protocols need mechanisms to migrate from one algorithm suite to
			another over time, not just the integrity algorithm, but all
			cryptographic algorithms.
			Guidelines for Cryptographic Algorithm Agility December 2014
	3.3. Cryptographic Key Management		3.3. Cryptographic Key Management
	Traditionally, protocol designers have avoided a more than one		Traditionally, protocol designers have avoided a more than one
	approach to key management because it makes the security analysis of		approach to key management because it makes the security analysis of
	the overall protocol more difficult. However, with the increasing		the overall protocol more difficult. However, with the increasing
	deployment of frameworks such as EAP and GSSAPI, the key management		deployment of frameworks such as EAP and GSSAPI, the key management
	is very flexible, often hiding many of the details from the		is very flexible, often hiding many of the details from the
	application. As a result, more and more protocols support multiple		application. As a result, more and more protocols support multiple
	key management approaches. In fact, the key management approach may		key management approaches. In fact, the key management approach may
	be negotiable, which creates a design challenge to protect the		be negotiable, which creates a design challenge to protect the
	negotiation of the key management approach before it is used to		negotiation of the key management approach before it is used to
	produce cryptographic keys for the cryptographic algorithm.		produce cryptographic keys.
	Protocols can negotiate a key management approach, derive an initial		Protocols can negotiate a key management approach, derive an initial
	cryptographic key, and then authenticate the negotiation. However,		cryptographic key, and then authenticate the negotiation. However,
	if the authentication fails, the only recourse is to start the		if the authentication fails, the only recourse is to start the
	negotiation over from the beginning.		negotiation over from the beginning.
	Some environments will restrict the key management approaches by		Some environments will restrict the key management approaches by
	policy. Such policies tend to improve interoperability within a		policy. Such policies tend to improve interoperability within a
	particular environment, but they cause problems for individuals that		particular environment, but they cause problems for individuals that
	need to work in multiple incompatible environments.		need to work in multiple incompatible environments.
	skipping to change at page 6, line 27 ¶		skipping to change at page 6, line 42 ¶
	This document provides guidance to working groups and protocol		This document provides guidance to working groups and protocol
	designers. The security of the Internet is improved when broken or		designers. The security of the Internet is improved when broken or
	weak cryptographic algorithms can be easily replaced with strong		weak cryptographic algorithms can be easily replaced with strong
	ones.		ones.
	The ability to use a algorithm of one's own choosing is very		The ability to use a algorithm of one's own choosing is very
	desirable; however, this does not mean that any and all cryptographic		desirable; however, this does not mean that any and all cryptographic
	algorithms ought to be available in every implementation. Mandatory-		algorithms ought to be available in every implementation. Mandatory-
	to-implement algorithms ought to be well studied, giving rise to		to-implement algorithms ought to be well studied, giving rise to
	significant confidence. In addition, inclusion of too many		significant confidence. In addition, inclusion of too many
	alternative may add complexity to algorithm selection or negotiation.		alternatives may add complexity to algorithm selection or
			negotiation.
	Some protocols are used to protected stored data. For example,		Some protocols are used to protected stored data. For example,
	S/MIME [RFC5751] can protect a message kept in a mailbox. To recover		S/MIME [RFC5751] can protect a message kept in a mailbox. To recover
	the protected stored data, protocol implementations need to support		the protected stored data, protocol implementations need to support
	older algorithms, even when they no longer use the older algorithms		older algorithms, even when they no longer use the older algorithms
	for the protection of new stored data.		for the protection of new stored data.
	Support for too many algorithms can lead to implementation		Support for too many algorithms can lead to implementation
	vulnerabilities. When many algorithms are supported, some of them		vulnerabilities. When many algorithms are supported, some of them
	will be rarely used. Any code that is rarely used can contain		will be rarely used. Any code that is rarely used can contain
	undetected bugs, and algorithm implementations are no different.		undetected bugs, and algorithm implementations are no different.
			Guidelines for Cryptographic Algorithm Agility December 2014
	Section 2.3 talks about algorithm transition without considering any		Section 2.3 talks about algorithm transition without considering any
	other aspects of the protocol design. In practice, there are		other aspects of the protocol design. In practice, there are
	dependencies between the cryptographic algorithm and other aspects of		dependencies between the cryptographic algorithm and other aspects of
	the protocol. For example, the BEAST attack [BEAST] against TLS		the protocol. For example, the BEAST attack [BEAST] against TLS
	[RFC5246] caused many sites to turn off modern cryptographic		[RFC5246] caused many sites to turn off modern cryptographic
	algorithms in favor of older and clearly weaker algorithms.		algorithms in favor of older and clearly weaker algorithms.
	5. Normative References		5. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	skipping to change at page 7, line 41 ¶		skipping to change at page 8, line 5 ¶
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
	[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,		[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
	RFC 5652, September 2009.		RFC 5652, September 2009.
	[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet		[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
	Mail Extensions (S/MIME) Version 3.2 Message		Mail Extensions (S/MIME) Version 3.2 Message
	Specification", RFC 5751, January 2010.		Specification", RFC 5751, January 2010.
			Guidelines for Cryptographic Algorithm Agility December 2014
	Acknowledgements		Acknowledgements
	Thanks to Bernard Aboba, David Black, Tony Finch, Ian Grigg, Wes		Thanks to Bernard Aboba, David Black, Jon Callas, Tony Finch, Ian
	Hardaker, Joe Hildebrand, Paul Lambert, Ben Laurie, Eliot Lear, and		Grigg, Wes Hardaker, Joe Hildebrand, Christian Huitema, Paul Lambert,
	Kristof Teichel for their review and insightful comments. While some		Ben Laurie, Eliot Lear, Kristof Teichel, and Nico Williams for their
	of these people do not agree with some aspects of this document, the		review and insightful comments. While some of these people do not
	discussion that resulted for their comments has certainly resulted in		agree with some aspects of this document, the discussion that
	a better document.		resulted for their comments has certainly resulted in a better
			document.
	Author's Address		Author's Address
	Russell Housley		Russell Housley
	Vigil Security, LLC		Vigil Security, LLC
	918 Spring Knoll Drive		918 Spring Knoll Drive
	Herndon, VA 20170		Herndon, VA 20170
	USA		USA
	EMail: housley@vigilsec.com		EMail: housley@vigilsec.com
End of changes. 26 change blocks.
	69 lines changed or deleted		103 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/