GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4307

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4307.txt · Last modified: 2005/12/21 00:41 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki