< draft-iab-crypto-alg-agility-00.txt   draft-iab-crypto-alg-agility-01.txt >
Internet-Draft R. Housley Internet-Draft R. Housley
Intended Status: Best Current Practice Vigil Security Intended Status: Best Current Practice Vigil Security
Expires: 8 July 2014 8 January 2014 Expires: 29 December 2014 27 June 2014
Guidelines for Cryptographic Algorithm Agility Guidelines for Cryptographic Algorithm Agility
<draft-iab-crypto-alg-agility-00.txt> <draft-iab-crypto-alg-agility-01.txt>
Abstract Abstract
Many IETF protocols may use of cryptographic algorithms to provide Many IETF protocols may use of 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 cryptographic algorithm or algorithms for these
mechanisms to work properly. This memo provides guidelines for mechanisms to work properly. This memo provides guidelines for
ensuring that such a protocol has the ability to migrate from one ensuring that such a protocol has the ability to migrate from one
algorithm to another over time. algorithm to another over time.
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 January 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 may use of cryptographic algorithms to provide Many IETF protocols use cryptographic algorithms to provide
confidentiality, integrity, or non-repudiation. For the mechanisms confidentiality, integrity, authentication, or digital signature.
to work properly,communicating peers must support the same For interoperability, communicating peers must support the same
cryptographic algorithm or algorithms. Yet, cryptographic algorithms cryptographic algorithm or algorithms. Yet, cryptographic algorithms
become weaker with time. As new cryptanalysis techniques are become weaker with time. As new cryptanalysis techniques are
developed and computing performance improves, the work factor to developed and computing capabilities improve, the work factor to
break a particular cryptographic algorithm will reduce. For the break a particular cryptographic algorithm will reduce. Algorithm
protocol implementer, this means that implementations should be agility is achieved when a protocol can easily support more that one
modular to easily accommodate the insertion of new algorithms. For set of cryptographic algorithms. For the protocol implementer, this
the protocol designer, this means that one or more algorithm means that implementations should be modular to easily accommodate
identifier must be carried, the set of mandatory to implement the insertion of new algorithms. For the protocol designer, this
algorithms will change over time, and an IANA registry of algorithm means that one or more algorithm identifier must be carried, the set
identifiers will be needed. 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. 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
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.
Either approach is acceptable; however, designers are encouraged to Both approaches are used in IETF protocols. Designers are encouraged
pick one of these approaches and use it consistently throughout the to pick one of these approaches and use it consistently throughout
protocol. the protocol or family of protocols. However, suite identifiers make
it easier for the protocol designer to ensure that the algorithm
selections are complete and compatible for future assignments.
Guidelines for Cryptographic Algorithm Agility January 2014 In the IPsec protocol suite, IKE [RFC2409][RFC4306] carries the
algorithm identifiers for AH and ESP [RFC4302][RFC4303]. Such
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 same
cryptographic algorithm or algorithms. For this reason, the protocol cryptographic algorithm or algorithms. For this reason, the protocol
SHOULD specify one or more mandatory-to-implement algorithm. This is SHOULD specify one or more mandatory-to-implement algorithm. This is
not done for protocols that are embedded in other protocols. For not done for protocols that are embedded in other protocols. For
example, S/MIME [RFC5751] makes use of CMS [RFC5652]. Other example, S/MIME [RFC5751] makes use of the cryptographic message
protocols also make use of CMS. S/MIME specifies the mandatory-to- Syntax (CMS) [RFC5652]. Other protocols also make use of CMS.
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 must be able to change the mandatory-to-implement algorithms
over time. It is highly desirable to make this change without over time. It is highly desirable to make this change without
updating the base protocol specification. Therefore the base 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 maturity ladder
even if the algorithm document changes frequently. 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 allows many different key sizes. When more than one size, but others allow many different key sizes. Likewise, some
key size is available, the algorithm specification MUST identify the algorithms support parameters of different sizes, such as integrity
specific sizes that are to be supported. check values or nonces. The algorithm specification MUST identify
the specific key sizes ans parameter sizes that are to be supported.
When more than one key size is available, expect the mandatory-to-
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 public keys can be found in
BCP 86 [RFC3766]. BCP 86 [RFC3766].
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
algorithms are supported. This may naturally occur as part of an
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 happen when a secure algorithm is used break it. 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 refuse to use the weak perhaps to the point that one wants to stop offering to use the weak
algorithm and refuse offers to use the weak algorithm well before the
Guidelines for Cryptographic Algorithm Agility January 2014 alternative algorithm is widely deployed.
algorithm well before the alternative algorithm is widely deployed.
In any case, there come a point where one refuses to use the weak In any case, there come a point where one refuses to use the weak
algorithm. This can happen on a flag day, or each installation can algorithm. This can happen on a flag day, or each installation can
select a date on their own. 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.
skipping to change at page 4, line 31 skipping to change at page 4, line 43
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 168-bit Triple-DES key and the
Triple-DES content-encryption key is wrapped with a 40-bit RC2 key, Triple-DES content-encryption key is wrapped with a 40-bit RC2 key,
then at most 40 bits of protection is provided. Thus, a trivial then at most 40 bits of protection is provided. Thus, a trivial
search to determine the value of the 40-bit RC2 key will recover search to determine the value of the 40-bit RC2 key will recover
Triple-DES key, and then the recovered Triple-DES key can be used to Triple-DES key, and then the recovered Triple-DES key can be used to
decrypt the content. In this situation, the algorithm and key size decrypt the content. In this situation, the algorithm and key size
selections should ensure that the key encryption is at least as selections should ensure that the key encryption is at least as
strong as the content encryption. strong as the content encryption.
3. Algorithm Agility Considerations 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 necessary to handle the transition to from unprotected to may still be necessary to handle the transition from unprotected to
protected use of the the application layer protocol. protected use of the the application layer protocol.
3.2. Migration Mechanisms 3.2. Migration Mechanisms
When a protocol specifies a single mandatory-to-implement algorithm Cryptographic algorithm selection or negotiation MUST be integrity
protected. When a protocol specifies a single mandatory-to-implement
Guidelines for Cryptographic Algorithm Agility January 2014 integrity algorithm, eventually that algorithm will be found to be
weak. Perhaps there will be a flaw found in the integrity algorithm
for integrity and authentication, eventually that algorithm will be that greatly shortens its expected life.
found to be weak. Perhaps there will be a flaw found in the
algorithm that greatly shortens its expected life. Regardless, all
algorithms age, and the advances in computing power available to the
attacker will eventually make them obsolete. For this reason,
protocols need mechanisms to migrate from one algorithm to another
over time.
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 used by the protocol. In this situation, a
flaw in the mandatory-to-implement algorithm may allow an attacker to flaw in the mandatory-to-implement algorithm may allow an attacker to
influence the choices of other algorithms. influence the choices of other algorithms.
All algorithms age, and the advances in computing power available to
the attacker will eventually make them obsolete. For this reason,
protocols need mechanisms to migrate from one algorithm to another
over time, not just the integrity algorithm, but all cryptographic
algorithms used by the protocol.
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 for the cryptographic algorithm.
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 restriction 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.
4. Security Considerations 4. Security Considerations
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.
5. References The ability to use a algorithm of one's own choosing is very
desirable; however, this does not mean that any and all cryptographic
algorithms ought to be available in every implementation. Mandatory-
to-implement algorithms ought to be well studied, giving rise to
significant confidence. In addition, inclusion of too many
alternative may add complexity to algorithm selection or negotiation.
This section contains normative and informative references. Some protocols are used to protected stored data. For example,
S/MIME [RFC5751] can protect a message kept in a mailbox. To recover
the protected stored data, protocol implementations need to support
older algorithms, even when they no longer use the older algorithms
for the protection of new stored data.
Guidelines for Cryptographic Algorithm Agility January 2014 Support for too many algorithms can lead to implementation
vulnerabilities. When many algorithms are supported, some of them
will be rarely used. Any code that is rarely used can contain
undetected bugs, and algorithm implementations are no different.
5.1. Normative References Section 2.3 talks about algorithm transition without considering any
other aspects of the protocol design. In practice, there are
dependencies between the cryptographic algorithm and other aspects of
the protocol. For example, the BEAST attack [BEAST] against TLS
[RFC5246] caused many sites to turn off modern cryptographic
algorithms in favor of older and clearly weaker algorithms.
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
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public
Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766,
April 2004. April 2004.
5.2. Informative References 6. Informative References
[BEAST] http://en.wikipedia.org/wiki/
Transport_Layer_Security#BEAST_attack.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(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.
Acknowledgements Acknowledgements
Thanks to Bernard Aboba and Eliot Lear for their review and Thanks to Bernard Aboba, David Black, Tony Finch, Ian Grigg, Wes
insightful comments. Hardaker, Joe Hildebrand, Paul Lambert, Ben Laurie, Eliot Lear, and
Kristof Teichel for their review and insightful comments. While some
of these people do not agree with some aspects of this document, the
discussion that resulted for their comments has certainly resulted in
a better document.
Authors' Addresses 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. 25 change blocks. 
54 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/