Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)
RFC 4307

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 05

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