Internet DRAFT - draft-mcgrew-ipsec-me-esp-ah-reqts

draft-mcgrew-ipsec-me-esp-ah-reqts






Internet Engineering Task Force                                D. McGrew
Internet-Draft                                             Cisco Systems
Intended status: Standards Track                              W. Feghali
Expires: April 18, 2013                                      Intel Corp.
                                                        October 15, 2012


 Cryptographic Algorithm Implementation Requirements and Usage Guidance
for Encapsulating Security Payload (ESP) and Authentication Header (AH)
                 draft-mcgrew-ipsec-me-esp-ah-reqts-00

Abstract

   This Internet Draft is an individual submission that proposes an
   update to the Cryptographic Algorithm Implementation Requirements for
   ESP and AH; it also adds usage guidance to help in the selection of
   these algorithms.

   The Encapsulating Security Payload (ESP) and Authentication Header
   (AH) protocols makes use of various cryptographic algorithms to
   provide confidentiality and/or data origin authentication to
   protected data communications in the IP Security (IPsec)
   architecture.  To ensure interoperability between disparate
   implementations, the IPsec standard specifies a set of mandatory-to-
   implement algorithms.  This document specifies the current set of
   mandatory-to-implement algorithms for ESP and AH, specifies
   algorithms that should be implemented because they may be promoted to
   mandatory at some future time, and also recommends against the
   implementation of some obsolete algorithms.  Usage guidance is also
   provided to help the user of ESP and AH best achieve their security
   goals through appropriate choices of cryptographic algorithms.

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 18, 2013.



McGrew & Feghali         Expires April 18, 2013                 [Page 1]

Internet-Draft  Requirements and Guidance for ESP and AH    October 2012


Copyright Notice

   Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   2.  Implementation Requirements  . . . . . . . . . . . . . . . . .  5
     2.1.  ESP Authenticated Encryption (Combined Mode Algorithms)  .  5
     2.2.  ESP Encryption Algorithms  . . . . . . . . . . . . . . . .  5
     2.3.  ESP Authentication Algorithms  . . . . . . . . . . . . . .  5
     2.4.  AH Authentication Algorithms . . . . . . . . . . . . . . .  5
     2.5.  Summary of Changes . . . . . . . . . . . . . . . . . . . .  6
   3.  Usage Guidance . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Rationale  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Authenticated Encryption . . . . . . . . . . . . . . . . .  8
     4.2.  Encryption Transforms  . . . . . . . . . . . . . . . . . .  8
     4.3.  Authentication Transforms  . . . . . . . . . . . . . . . .  8
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15













McGrew & Feghali         Expires April 18, 2013                 [Page 2]

Internet-Draft  Requirements and Guidance for ESP and AH    October 2012


1.  Introduction

   The Encapsulating Security Payload (ESP) [RFC4303] and the
   Authentication Header (AH) [RFC4302] are the mechanisms for applying
   cryptographic protection to data being sent over an IPsec Security
   Association (SA) [RFC4301].

   To ensure interoperability between disparate implementations, it is
   necessary to specify a set of mandatory-to-implement algorithms.
   This ensures that there is at least one algorithm that all
   implementations will have in common.  This document specifies the
   current set of mandatory-to-implement algorithms for ESP and AH,
   specifies algorithms that should be implemented because they may be
   promoted to mandatory at some future time, and also recommends
   against the implementation of some obsolete algorithms.  Usage
   guidance is also provided to help the user of ESP and AH best achieve
   their security goals through appropriate choices of mechanisms.

   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.

   The ESP and AH mandatory-to-implement algorithm(s) may need to change
   over time to adapt to new developments in cryptography.  For this
   reason, the specification of the mandatory-to-implement algorithms is
   not included in the main IPsec, ESP, or AH specifications, but is
   instead placed in this document.  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, this document identifies such algorithms, as they
   are known today.  There is no guarantee that the algorithms that 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.

1.1.  Requirements Language

   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 RFC 2119 [RFC2119].

   Following [RFC4835], we define some additional key words:




McGrew & Feghali         Expires April 18, 2013                 [Page 3]

Internet-Draft  Requirements and Guidance for ESP and AH    October 2012


   MUST-  This term means the same as MUST.  However, we expect that at
      some point in the future this algorithm will no longer be a MUST.

   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, it is likely
      that an algorithm marked as SHOULD- will be deprecated to a MAY or
      worse in a future version of this document.

   SHOULD NOT+  This term means the same as SHOULD NOT.  However, it is
      likely that an algorithm marked as SHOULD NOT+ will be deprecated
      to a MUST NOT in a future version of this document.





































McGrew & Feghali         Expires April 18, 2013                 [Page 4]

Internet-Draft  Requirements and Guidance for ESP and AH    October 2012


2.  Implementation Requirements

   This section specifies the cryptographic algorithms that MUST be
   implemented, and provides guidance about ones that SHOULD or SHOULD
   NOT be implemented.

2.1.  ESP Authenticated Encryption (Combined Mode Algorithms)

   ESP combined mode algorithms provide both confidentiality and
   authentication services; in cryptographic terms, these are
   authenticated encryption algorithms [RFC5116].  Authenticated
   encryption transforms are listed in the ESP encryption transforms
   IANA registry.

           Requirement    Authenticated Encryption Algorithm
           -----------    ----------------------------------
           SHOULD+        AES-GCM [RFC4106]
           MAY            AES-CCM [RFC4309]

2.2.  ESP Encryption Algorithms

           Requirement    Encryption Algorithm
           -----------    --------------------------
           MUST           NULL [RFC2410]
           MUST           AES-128-CBC [RFC3602]
           MAY            AES-CTR [RFC3686]
           SHOULD NOT     TripleDES-CBC [RFC2451]
           SHOULD NOT+    DES-CBC [RFC2405]

2.3.  ESP Authentication Algorithms

           Requirement    Authentication Algorithm (notes)
           -----------    -----------------------------
           MUST           HMAC-SHA1-96 [RFC2404]
           SHOULD+        AES-GMAC [RFC4543]
           SHOULD         AES-XCBC-MAC-96 [RFC3566]
           MAY            NULL [RFC4303]
           MAY            HMAC-SHA-256 [RFC4868]
           MAY            HMAC-SHA-384 [RFC4868]
           MAY            HMAC-SHA-512 [RFC4868]
           SHOULD NOT     HMAC-MD5-96 [RFC2403]

2.4.  AH Authentication Algorithms

   The requirements for AH are the same as for ESP Authentication
   Algorithms, except that NULL authentication is inapplicable.





McGrew & Feghali         Expires April 18, 2013                 [Page 5]

Internet-Draft  Requirements and Guidance for ESP and AH    October 2012


2.5.  Summary of Changes

         Old            New
         Requirement    Requirement      Algorithm (notes)
         ----           -----------      -----------------
         MAY            SHOULD+          AES-GCM [RFC4106]
         MAY            SHOULD+          AES-GMAC [RFC4543]
         MUST-          SHOULD NOT       TripleDES-CBC [RFC2451]
         SHOULD+        SHOULD           AES-XCBC-MAC-96 [RFC3566]
         SHOULD         MAY              AES-CTR [RFC3686]
         MAY            SHOULD NOT       HMAC-MD5-96 [RFC2403]








































McGrew & Feghali         Expires April 18, 2013                 [Page 6]

Internet-Draft  Requirements and Guidance for ESP and AH    October 2012


3.  Usage Guidance

   Since ESP and AH can be used in several different ways, this note
   provides guidance on the best way to utilize these mechanisms.

   ESP can provide confidentiality, data origin authentication, or the
   combination of both of those security services.  AH provides only
   data origin authentication.  Background information on those security
   services is available [RFC4949].  In the following, we shorten `data
   origin authentication' to `authentication'.

   Both confidentiality and authentication SHOULD be provided.  If
   confidentiality is not needed, then authentication MAY be provided.
   Confidentiality without authentication is not effective [DP07] and
   SHOULD NOT be used.  We describe each of these cases in more detail
   below.

   To provide confidentiality and authentication, an authenticated
   encryption transform SHOULD be used in ESP, in conjunction with NULL
   authentication.  Alternatively, an ESP encryption transform and ESP
   authentication transform MAY be used together (provided that neither
   transform is NULL).  If authentication on the IP header is needed in
   conjunction with confidentiality of higher-layer data, then AH SHOULD
   be used in addition to the transforms recommended above.  It is NOT
   RECOMMENDED to use ESP with NULL authentication in conjunction with
   AH; some configurations of this combination of services have been
   shown to be insecure [PD10].

   To provide authentication without confidentiality, an authentication
   transform MUST be used in either ESP or AH.  It is not possible to
   provide effective confidentiality without authentication, because the
   lack of authentication undermines the efficacy of encryption
   [B96][V02].  An encryption transform MUST NOT be used with a NULL
   authentication transform (unless the encryption transform is an
   authenticated encryption transform).
















McGrew & Feghali         Expires April 18, 2013                 [Page 7]

Internet-Draft  Requirements and Guidance for ESP and AH    October 2012


4.  Rationale

   This section explains the principles behind the implementation
   requirements described above.

4.1.  Authenticated Encryption

   This note encourages the use of authenticated encryption algorithms
   because they can provide significant efficiency and throughput
   advantages, and the tight binding between authentication and
   encryption can be a security advantage [RFC5116].

   AES-GCM [RFC4106] brings significant performance benefits [KKGEGD],
   has been incorporated into IPsec recommendations [RFC6379] and has
   emerged as the preferred authenticated encryption method in IPsec and
   other standards.

4.2.  Encryption Transforms

   Since ESP encryption is optional, support for the "NULL" algorithm is
   required to maintain consistency with the way services are
   negotiated.  Note that while authentication and encryption can each
   be "NULL", they MUST NOT both be "NULL" [RFC4301] [H10].

   AES Counter Mode (AES-CTR) is an efficient encryption method, but it
   provides no authentication capability.  The AES-GCM authenticated
   encryption method has all of the advantages of AES-CTR, while also
   providing authentication.  Thus this note moves AES-CTR from a SHOULD
   to a MAY.

   The Triple Data Encryption Standard (TDES) is obsolete because of its
   small block size; as with all 64-bit block ciphers, it SHOULD NOT be
   used to encrypt more than one gigabyte of data with a single key.
   Its key size is smaller than that of the Advanced Encryption Standard
   (AES), while at the same time its performance and efficiency is
   worse.  Thus, its use in new implementations is discouraged.

   The Data Encryption Standard (DES) is obsolete because of its small
   key size and small block size.  There have been publicly demonstrated
   and open-design special-purpose cracking hardware.  Therefore, its
   use is discouraged.

4.3.  Authentication Transforms

   AES-GMAC provides good security along with performance advantages,
   even over HMAC-MD5.  In addition, it uses the same internal
   components as AES-GCM and is easy to implement in a way that shares
   components with that authenticated encryption algorithm.



McGrew & Feghali         Expires April 18, 2013                 [Page 8]

Internet-Draft  Requirements and Guidance for ESP and AH    October 2012


   The MD5 hash function has been found to not meet its goal of
   collision resistance; it is so weak that its use in digital
   signatures is highly discouraged [RFC6151].  There have been
   theoretical results against HMAC-MD5, but that message authentication
   code does not seem to have a practical vulnerability.  Thus, it may
   not be urgent to remove HMAC-MD5 from the existing protocols;
   however, since MD5 must not be used for digital signatures, HMAC-MD5
   should not be included in new implementations.

   SHA-1 has been found to not meet its goal of collision resistance.
   However, HMAC-SHA-1 does not rely on this property, and HMAC-SHA-1 is
   believed to be secure.

   The HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 are believed to
   provide a good security margin, and they perform adequately on many
   platforms.  However, these algorithms are listed only as MAY
   implement in this note, because HMAC-SHA-1 support is widespread and
   its security is good, AES-GMAC provides good security with better
   performance, and Authenticated Encryption algorithms do not need any
   authentication methods.

   AES-XCBC has not seen widespread deployment, despite being previously
   being recommended as a SHOULD+ in RFC4305.  Thus this draft lists it
   only as a SHOULD.



























McGrew & Feghali         Expires April 18, 2013                 [Page 9]

Internet-Draft  Requirements and Guidance for ESP and AH    October 2012


5.  Acknowledgements

   Much of the wording herein was adapted from [RFC4835], the parent
   document of this document.  That RFC itself borrows from [RFC4305],
   which borrows in turn from [RFC4307].  RFC4835, RFC4305, and RFC4307
   were authored by Vishwas Manral, Donald Eastlake, and Jeffrey
   Schiller respectively.

   Thanks are due to Scott Fluhrer, Dan Harkins, Brian Weis, and Cheryl
   Madson for insightful feedback on this draft.









































McGrew & Feghali         Expires April 18, 2013                [Page 10]

Internet-Draft  Requirements and Guidance for ESP and AH    October 2012


6.  IANA Considerations

   This memo includes no request to IANA.
















































McGrew & Feghali         Expires April 18, 2013                [Page 11]

Internet-Draft  Requirements and Guidance for ESP and AH    October 2012


7.  Security Considerations

   The security of a system that uses cryptography 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 and administration 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 ESP and AH, 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 is not 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.
































McGrew & Feghali         Expires April 18, 2013                [Page 12]

Internet-Draft  Requirements and Guidance for ESP and AH    October 2012


8.  References

8.1.  Normative References

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

   [RFC2403]  Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
              ESP and AH", 1998.

   [RFC2404]  Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
              ESP and AH", 1998.

   [RFC2405]  Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
              Algorithm With Explicit IV", 1998.

   [RFC2410]  Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
              Its Use With IPsec", 1998.

   [RFC3566]  Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm
              and Its Use With IPsec", 2003.

   [RFC3602]  Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
              Algorithm and Its Use with IPsec", 2003.

   [RFC3686]  Housley, R., "Using Advanced Encryption Standard (AES)
              Counter Mode With IPsec Encapsulating Security Payload
              (ESP)", 2004.

   [RFC4106]  Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
              (GCM) in IPsec Encapsulating Security Payload (ESP)",
              2005.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", 2005.

   [RFC4302]  Kent, S., "IP Authentication Header", 2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload", 2005.

8.2.  Informative References

   [B96]      Bellovin, S., "Problem areas for the IP security protocols
              (Proceedings of the Sixth Usenix Unix Security
              Symposium)", 1996.

   [DP07]     Degabriele, J. and K. Paterson, "Attacking the IPsec
              Standards in Encryption-only Configurations (IEEE



McGrew & Feghali         Expires April 18, 2013                [Page 13]

Internet-Draft  Requirements and Guidance for ESP and AH    October 2012


              Symposium on Privacy and Security)", 2007.

   [H10]      Hoban, A., "Using Intel AES New Instructions and PCLMULQDQ
              to Significantly Improve IPSec Performance on Linux",
              2010.

   [KKGEGD]   Kounavis, M., Kang, X., Grewal, K., Eszenyi, M., Gueron,
              S., and D. Durham, "Encrypting the Internet (SIGCOMM)",
              2010.

   [PD10]     Paterson, K. and J. Degabriele, "On the (in)security of
              IPsec in MAC-then-encrypt configurations (ACM Conference
              on Computer and Communications Security, ACM CCS)", 2010.

   [RFC4305]  Eastlake, D., "Cryptographic Algorithm Implementation
              Requirements for Encapsulating Security Payload (ESP) and
              Authentication Header (AH)".

   [RFC4307]  Schiller, J., "Cryptographic Algorithms for Use in the
              Internet Key Exchange Version 2 (IKEv2)", 2005.

   [RFC4309]  Housley, R., "Using Advanced Encryption Standard (AES) CCM
              Mode with IPsec Encapsulating Security Payload (ESP)",
              2005.

   [RFC4835]  Manral, V., "Cryptographic Algorithm Implementation
              Requirements for Encapsulating Security Payload (ESP) and
              Authentication Header (AH)".

   [RFC4949]  Shirley, R., "Internet Security Glossary, Version 2",
              2007.

   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
              Encryption", 2008.

   [RFC6151]  Turner, S. and L. Chen, "Updated Security Considerations
              for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
              2011.

   [RFC6379]  Law, L. and J. Solinas, "Suite B Cryptographic Suites for
              IPsec", 2011.

   [V02]      Vaudenay, S., "Security Flaws Induced by CBC Padding -
              Applications to SSL, IPSEC, WTLS ... (EUROCRYPT)", 2002.







McGrew & Feghali         Expires April 18, 2013                [Page 14]

Internet-Draft  Requirements and Guidance for ESP and AH    October 2012


Authors' Addresses

   David McGrew
   Cisco Systems
   13600 Dulles Technology Drive
   Herndon, Virginia  20171
   USA

   Phone: 408 525 8651
   Email: mcgrew@cisco.com


   Wajdi Feghali
   Intel Corp.
   75 Reed Road
   Hudson, Massachusetts
   USA

   Phone:
   Email: wajdi.k.feghali@intel.com































McGrew & Feghali         Expires April 18, 2013                [Page 15]