[Docs] [txt|pdf|xml] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-nir-ipsecme-rfc4307bis) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 RFC 8247

Network Working Group                                             Y. Nir
Internet-Draft                                               Check Point
Intended status: Standards Track                              T. Kivinen
Expires: April 20, 2016                                    INSIDE Secure
                                                              P. Wouters
                                                                 Red Hat
                                                              D. Migault
                                                                Ericsson
                                                        October 18, 2015


Cryptographic Algorithms for Use in the Internet Key Exchange Version 2
                                (IKEv2)
                    draft-ietf-ipsecme-rfc4307bis-00

Abstract

   The IPsec series of protocols makes use of various cryptographic
   algorithms in order to provide security services.  The Internet Key
   Exchange protocol provides 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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 20, 2016.






Nir, et al.              Expires April 20, 2016                 [Page 1]


Internet-Draft       IKEv2 Cryptographic Algorithms         October 2015


Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
   3.  Algorithm Selection . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  IKEv2 Transform Type 1 Algorithms . . . . . . . . . . . .   3
     3.2.  IKEv2 Transform Type 3 Algorithms . . . . . . . . . . . .   4
     3.3.  IKEv2 Transform Type 2 Algorithms . . . . . . . . . . . .   4
     3.4.  Diffie-Hellman Groups . . . . . . . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6

1.  Introduction

   The Internet Key Exchange protocol [RFC7296] 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.

   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



Nir, et al.              Expires April 20, 2016                 [Page 2]


Internet-Draft       IKEv2 Cryptographic Algorithms         October 2015


   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.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 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-.

3.  Algorithm Selection

3.1.  IKEv2 Transform Type 1 Algorithms

   The algorithms in the below table are negotiated in the SA payload
   and used in the ENCR payload.  References to the specifications
   defining these algorithms and the ones in the following subsections
   are in the IANA registry [IKEV2-IANA].  Some of these algorithms are



Nir, et al.              Expires April 20, 2016                 [Page 3]


Internet-Draft       IKEv2 Cryptographic Algorithms         October 2015


   Authenticated Encryption with Associated Data (AEAD - [RFC5282]).
   Algorithms that are not AEAD MUST be used in conjunction with the
   integrity algorithms in Section 3.2.

       +-----------------------------+----------+-------+---------+
       | Name                        | Status   | AEAD? | Comment |
       +-----------------------------+----------+-------+---------+
       | ENCR_AES_CBC                | MUST     | No    | [1]     |
       | ENCR_CHACHA20_POLY1305      | SHOULD   | Yes   |         |
       | AES-GCM with a 16 octet ICV | SHOULD   | Yes   | [1]     |
       | ENCR_AES_CCM_8              | SHOULD   | Yes   | [1]     |
       | ENCR_3DES                   | MAY      | No    |         |
       | ENCR_DES                    | MUST NOT | No    |         |
       +-----------------------------+----------+-------+---------+

    [1] - Both 256-bit and 128-bit keys should be supported at the same
                           level of requirement.

3.2.  IKEv2 Transform Type 3 Algorithms

   The algorithms in the below table are negotiated in the SA payload
   and used in the ENCR payload.  References to the specifications
   defining these algorithms are in the IANA registry.  When an AEAD
   algorithm (see Section 3.1) is used, no algorithm from this table
   needs to be used.

                   +------------------------+---------+
                   | Name                   | Status  |
                   +------------------------+---------+
                   | AUTH_HMAC_SHA2_256_128 | MUST    |
                   | AUTH_HMAC_SHA2_384_192 | SHOULD+ |
                   | AUTH_HMAC_SHA1_96      | MUST-   |
                   | AUTH_AES_128_GMAC      | MAY     |
                   | AUTH_AES_XCBC_96       | MAY     |
                   | AUTH_HMAC_MD5_96       | MAY     |
                   +------------------------+---------+

3.3.  IKEv2 Transform Type 2 Algorithms

   Transform Type 2 Algorithms are pseudo-random functions used to
   generate random values when needed.










Nir, et al.              Expires April 20, 2016                 [Page 4]


Internet-Draft       IKEv2 Cryptographic Algorithms         October 2015


                      +-------------------+---------+
                      | Name              | Status  |
                      +-------------------+---------+
                      | PRF_HMAC_SHA2_256 | MUST    |
                      | PRF_HMAC_SHA2_384 | SHOULD+ |
                      | PRF_HMAC_SHA1     | MUST-   |
                      | PRF_AES128_CBC    | MAY     |
                      | PRF_HMAC_MD5      | MAY     |
                      +-------------------+---------+

3.4.  Diffie-Hellman Groups

   There are several Modular Exponential (MODP) groups and several
   Elliptic Curve groups (ECC) that are defined for use in IKEv2.  They
   are defined in both the [IKEv2] base document and in extensions
   documents.  They are identified by group number.

            +--------+--------------------------+------------+
            | Number | Description              | Status     |
            +--------+--------------------------+------------+
            | 14     | 2048-bit MODP Group      | MUST       |
            | 19     | 256-bit random ECP group | SHOULD     |
            | 20     | 384-bit random ECP group | MAY        |
            | 2      | 1024-bit MODP Group      | SHOULD NOT |
            +--------+--------------------------+------------+

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.






Nir, et al.              Expires April 20, 2016                 [Page 5]


Internet-Draft       IKEv2 Cryptographic Algorithms         October 2015


5.  IANA Considerations

   This document makes no requests of IANA.

6.  Acknowledgements

   The first version of this document was RFC 4307 by Jeffrey I.
   Schiller of the Massachusetts Institute of Technology (MIT).  Much of
   the text has been copied verbatim.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, October 2014.

   [RFC5282]  Black, D. and D. McGrew, "Using Authenticated Encryption
              Algorithms with the Encrypted Payload of the Internet Key
              Exchange version 2 (IKEv2) Protocol", RFC 5282, DOI
              10.17487/RFC5282, August 2008,
              <http://www.rfc-editor.org/info/rfc5282>.

7.2.  Informative References

   [IKEV2-IANA]
              "Internet Key Exchange Version 2 (IKEv2) Parameters",
              <http://www.iana.org/assignments/ikev2-parameters>.

Authors' Addresses

   Yoav Nir
   Check Point Software Technologies Ltd.
   5 Hasolelim st.
   Tel Aviv  6789735
   Israel

   EMail: ynir.ietf@gmail.com









Nir, et al.              Expires April 20, 2016                 [Page 6]


Internet-Draft       IKEv2 Cryptographic Algorithms         October 2015


   Tero Kivinen
   INSIDE Secure
   Eerikinkatu 28
   HELSINKI  FI-00180
   FI

   EMail: kivinen@iki.fi


   Paul Wouters
   Red Hat

   EMail: pwouters@redhat.com


   Daniel Migault
   Ericsson
   8400 boulevard Decarie
   Montreal, QC   H4P 2N2
   Canada

   Phone: +1 514-452-2160
   EMail: daniel.migault@ericsson.com




























Nir, et al.              Expires April 20, 2016                 [Page 7]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/