340 lines
13 KiB
Plaintext
340 lines
13 KiB
Plaintext
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Network Working Group J. Schiller
|
|||
|
Request for Comments: 4307 Massachusetts Institute of Technology
|
|||
|
Category: Standards Track December 2005
|
|||
|
|
|||
|
|
|||
|
Cryptographic Algorithms for Use in the
|
|||
|
Internet Key Exchange Version 2 (IKEv2)
|
|||
|
|
|||
|
Status of This Memo
|
|||
|
|
|||
|
This document specifies an Internet standards track protocol for the
|
|||
|
Internet community, and requests discussion and suggestions for
|
|||
|
improvements. Please refer to the current edition of the "Internet
|
|||
|
Official Protocol Standards" (STD 1) for the standardization state
|
|||
|
and status of this protocol. Distribution of this memo is unlimited.
|
|||
|
|
|||
|
Copyright Notice
|
|||
|
|
|||
|
Copyright (C) The Internet Society (2005).
|
|||
|
|
|||
|
Abstract
|
|||
|
|
|||
|
The IPsec series of protocols makes use of various cryptographic
|
|||
|
algorithms in order to provide security services. The Internet Key
|
|||
|
Exchange (IKE (RFC 2409) and IKEv2) provide a mechanism to negotiate
|
|||
|
which algorithms should be used in any given association. However,
|
|||
|
to ensure interoperability between disparate implementations, it is
|
|||
|
necessary to specify a set of mandatory-to-implement algorithms to
|
|||
|
ensure that there is at least one algorithm that all implementations
|
|||
|
will have available. This document defines the current set of
|
|||
|
algorithms that are mandatory to implement as part of IKEv2, as well
|
|||
|
as algorithms that should be implemented because they may be promoted
|
|||
|
to mandatory at some future time.
|
|||
|
|
|||
|
1. Introduction
|
|||
|
|
|||
|
The Internet Key Exchange protocol provides for the negotiation of
|
|||
|
cryptographic algorithms between both endpoints of a cryptographic
|
|||
|
|
|||
|
association. Different implementations of IPsec and IKE may provide
|
|||
|
different algorithms. However, the IETF desires that all
|
|||
|
implementations should have some way to interoperate. In particular,
|
|||
|
this requires that IKE define a set of mandatory-to-implement
|
|||
|
algorithms because IKE itself uses such algorithms as part of its own
|
|||
|
negotiations. This requires that some set of algorithms be specified
|
|||
|
as "mandatory-to-implement" for IKE.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Schiller Standards Track [Page 1]
|
|||
|
|
|||
|
RFC 4307 IKEv2 Cryptographic Algorithms December 2005
|
|||
|
|
|||
|
|
|||
|
The nature of cryptography is that new algorithms surface
|
|||
|
continuously and existing algorithms are continuously attacked. An
|
|||
|
algorithm believed to be strong today may be demonstrated to be weak
|
|||
|
tomorrow. Given this, the choice of mandatory-to-implement algorithm
|
|||
|
should be conservative so as to minimize the likelihood of it being
|
|||
|
compromised quickly. Thought should also be given to performance
|
|||
|
considerations as many uses of IPsec will be in environments where
|
|||
|
performance is a concern.
|
|||
|
|
|||
|
Finally, we need to recognize that the mandatory-to-implement
|
|||
|
algorithm(s) may need to change over time to adapt to the changing
|
|||
|
world. For this reason, the selection of mandatory-to-implement
|
|||
|
algorithms was removed from the main IKEv2 specification and placed
|
|||
|
in this document. As the choice of algorithm changes, only this
|
|||
|
document should need to be updated.
|
|||
|
|
|||
|
Ideally, the mandatory-to-implement algorithm of tomorrow should
|
|||
|
already be available in most implementations of IPsec by the time it
|
|||
|
is made mandatory. To facilitate this, we will attempt to identify
|
|||
|
those algorithms (that are known today) in this document. There is
|
|||
|
no guarantee that the algorithms we believe today may be mandatory in
|
|||
|
the future will in fact become so. All algorithms known today are
|
|||
|
subject to cryptographic attack and may be broken in the future.
|
|||
|
|
|||
|
2. Requirements Terminology
|
|||
|
|
|||
|
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and
|
|||
|
"MAY" that appear in this document are to be interpreted as described
|
|||
|
in [RFC2119].
|
|||
|
|
|||
|
We define some additional terms here:
|
|||
|
|
|||
|
SHOULD+ This term means the same as SHOULD. However, it is likely
|
|||
|
that an algorithm marked as SHOULD+ will be promoted at
|
|||
|
some future time to be a MUST.
|
|||
|
|
|||
|
SHOULD- This term means the same as SHOULD. However, an algorithm
|
|||
|
marked as SHOULD- may be deprecated to a MAY in a future
|
|||
|
version of this document.
|
|||
|
|
|||
|
MUST- This term means the same as MUST. However, we expect at
|
|||
|
some point that this algorithm will no longer be a MUST in
|
|||
|
a future document. Although its status will be determined
|
|||
|
at a later time, it is reasonable to expect that if a
|
|||
|
future revision of a document alters the status of a MUST-
|
|||
|
algorithm, it will remain at least a SHOULD or a SHOULD-.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Schiller Standards Track [Page 2]
|
|||
|
|
|||
|
RFC 4307 IKEv2 Cryptographic Algorithms December 2005
|
|||
|
|
|||
|
|
|||
|
3. Algorithm Selection
|
|||
|
|
|||
|
3.1. IKEv2 Algorithm Selection
|
|||
|
|
|||
|
3.1.1. Encrypted Payload Algorithms
|
|||
|
|
|||
|
The IKEv2 Encrypted Payload requires both a confidentiality algorithm
|
|||
|
and an integrity algorithm. For confidentiality, implementations
|
|||
|
MUST- implement 3DES-CBC and SHOULD+ implement AES-128-CBC. For
|
|||
|
integrity, HMAC-SHA1 MUST be implemented.
|
|||
|
|
|||
|
3.1.2. Diffie-Hellman Groups
|
|||
|
|
|||
|
There are several Modular Exponential (MODP) groups that are defined
|
|||
|
for use in IKEv2. They are defined in both the [IKEv2] base document
|
|||
|
and in the MODP extensions document. They are identified by group
|
|||
|
number. Any groups not listed here are considered as "MAY be
|
|||
|
implemented".
|
|||
|
|
|||
|
Group Number Bit Length Status Defined
|
|||
|
2 1024 MODP Group MUST- [RFC2409]
|
|||
|
14 2048 MODP Group SHOULD+ [RFC3526]
|
|||
|
|
|||
|
3.1.3. IKEv2 Transform Type 1 Algorithms
|
|||
|
|
|||
|
IKEv2 defines several possible algorithms for Transfer Type 1
|
|||
|
(encryption). These are defined below with their implementation
|
|||
|
status.
|
|||
|
|
|||
|
Name Number Defined In Status
|
|||
|
RESERVED 0
|
|||
|
ENCR_3DES 3 [RFC2451] MUST-
|
|||
|
ENCR_NULL 11 [RFC2410] MAY
|
|||
|
ENCR_AES_CBC 12 [AES-CBC] SHOULD+
|
|||
|
ENCR_AES_CTR 13 [AES-CTR] SHOULD
|
|||
|
|
|||
|
3.1.4. IKEv2 Transform Type 2 Algorithms
|
|||
|
|
|||
|
Transfer Type 2 Algorithms are pseudo-random functions used to
|
|||
|
generate random values when needed.
|
|||
|
|
|||
|
Name Number Defined In Status
|
|||
|
RESERVED 0
|
|||
|
PRF_HMAC_MD5 1 [RFC2104] MAY
|
|||
|
PRF_HMAC_SHA1 2 [RFC2104] MUST
|
|||
|
PRF_AES128_CBC 4 [AESPRF] SHOULD+
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Schiller Standards Track [Page 3]
|
|||
|
|
|||
|
RFC 4307 IKEv2 Cryptographic Algorithms December 2005
|
|||
|
|
|||
|
|
|||
|
3.1.5. IKEv2 Transform Type 3 Algorithms
|
|||
|
|
|||
|
Transfer Type 3 Algorithms are Integrity algorithms used to protect
|
|||
|
data against tampering.
|
|||
|
|
|||
|
Name Number Defined In Status
|
|||
|
NONE 0
|
|||
|
AUTH_HMAC_MD5_96 1 [RFC2403] MAY
|
|||
|
AUTH_HMAC_SHA1_96 2 [RFC2404] MUST
|
|||
|
AUTH_AES_XCBC_96 5 [AES-MAC] SHOULD+
|
|||
|
|
|||
|
4. Security Considerations
|
|||
|
|
|||
|
The security of cryptographic-based systems depends on both the
|
|||
|
strength of the cryptographic algorithms chosen and the strength of
|
|||
|
the keys used with those algorithms. The security also depends on
|
|||
|
the engineering of the protocol used by the system to ensure that
|
|||
|
there are no non-cryptographic ways to bypass the security of the
|
|||
|
overall system.
|
|||
|
|
|||
|
This document concerns itself with the selection of cryptographic
|
|||
|
algorithms for the use of IKEv2, specifically with the selection of
|
|||
|
"mandatory-to-implement" algorithms. The algorithms identified in
|
|||
|
this document as "MUST implement" or "SHOULD implement" are not known
|
|||
|
to be broken at the current time, and cryptographic research so far
|
|||
|
leads us to believe that they will likely remain secure into the
|
|||
|
foreseeable future. However, this isn't necessarily forever. We
|
|||
|
would therefore expect that new revisions of this document will be
|
|||
|
issued from time to time that reflect the current best practice in
|
|||
|
this area.
|
|||
|
|
|||
|
5. Normative References
|
|||
|
|
|||
|
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
|
|||
|
(IKE)", RFC 2409, November 1998.
|
|||
|
|
|||
|
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
|
|||
|
Protocol", RFC 4306, December 2005.
|
|||
|
|
|||
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|||
|
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential
|
|||
|
(MODP) Diffie-Hellman groups for Internet Key Exchange
|
|||
|
(IKE)", RFC 3526, May 2003.
|
|||
|
|
|||
|
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
|
|||
|
Algorithms", RFC 2451, November 1998.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Schiller Standards Track [Page 4]
|
|||
|
|
|||
|
RFC 4307 IKEv2 Cryptographic Algorithms December 2005
|
|||
|
|
|||
|
|
|||
|
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm
|
|||
|
and Its Use With IPsec", RFC 2410, November 1998.
|
|||
|
|
|||
|
[AES-CBC] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC
|
|||
|
Cipher Algorithm and Its Use with IPsec", RFC 3602,
|
|||
|
September 2003.
|
|||
|
|
|||
|
[AES-CTR] Housley, R., "Using Advanced Encryption Standard (AES)
|
|||
|
Counter Mode With IPsec Encapsulating Security Payload
|
|||
|
(ESP)", RFC 3686, January 2004.
|
|||
|
|
|||
|
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
|
|||
|
Keyed-Hashing for Message Authentication", RFC 2104,
|
|||
|
February 1997.
|
|||
|
|
|||
|
[AESPRF] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
|
|||
|
Internet Key Exchange Protocol (IKE)", RFC 3664, January
|
|||
|
2004.
|
|||
|
|
|||
|
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
|
|||
|
ESP and AH", RFC 2403, November 1998.
|
|||
|
|
|||
|
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96
|
|||
|
within ESP and AH", RFC 2404, November 1998.
|
|||
|
|
|||
|
[AES-MAC] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96
|
|||
|
Algorithm and Its Use With IPsec", RFC 3566, September
|
|||
|
2003.
|
|||
|
|
|||
|
Author's Address
|
|||
|
|
|||
|
Jeffrey I. Schiller
|
|||
|
Massachusetts Institute of Technology
|
|||
|
Room W92-190
|
|||
|
77 Massachusetts Avenue
|
|||
|
Cambridge, MA 02139-4307
|
|||
|
USA
|
|||
|
|
|||
|
Phone: +1 (617) 253-0161
|
|||
|
EMail: jis@mit.edu
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Schiller Standards Track [Page 5]
|
|||
|
|
|||
|
RFC 4307 IKEv2 Cryptographic Algorithms December 2005
|
|||
|
|
|||
|
|
|||
|
Full Copyright Statement
|
|||
|
|
|||
|
Copyright (C) The Internet Society (2005).
|
|||
|
|
|||
|
This document is subject to the rights, licenses and restrictions
|
|||
|
contained in BCP 78, and except as set forth therein, the authors
|
|||
|
retain all their rights.
|
|||
|
|
|||
|
This document and the information contained herein are provided on an
|
|||
|
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
|||
|
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
|||
|
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
|||
|
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
|||
|
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
|||
|
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|||
|
Intellectual Property
|
|||
|
|
|||
|
The IETF takes no position regarding the validity or scope of any
|
|||
|
Intellectual Property Rights or other rights that might be claimed to
|
|||
|
pertain to the implementation or use of the technology described in
|
|||
|
this document or the extent to which any license under such rights
|
|||
|
might or might not be available; nor does it represent that it has
|
|||
|
made any independent effort to identify any such rights. Information
|
|||
|
on the procedures with respect to rights in RFC documents can be
|
|||
|
found in BCP 78 and BCP 79.
|
|||
|
|
|||
|
Copies of IPR disclosures made to the IETF Secretariat and any
|
|||
|
assurances of licenses to be made available, or the result of an
|
|||
|
attempt made to obtain a general license or permission for the use of
|
|||
|
such proprietary rights by implementers or users of this
|
|||
|
specification can be obtained from the IETF on-line IPR repository at
|
|||
|
http://www.ietf.org/ipr.
|
|||
|
|
|||
|
The IETF invites any interested party to bring to its attention any
|
|||
|
copyrights, patents or patent applications, or other proprietary
|
|||
|
rights that may cover technology that may be required to implement
|
|||
|
this standard. Please address the information to the IETF at ietf-
|
|||
|
ipr@ietf.org.
|
|||
|
|
|||
|
Acknowledgement
|
|||
|
|
|||
|
Funding for the RFC Editor function is currently provided by the
|
|||
|
Internet Society.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Schiller Standards Track [Page 6]
|
|||
|
|