INTERNET-DRAFT                                                    L. Law
Obsoletes: 4869 (if approved)                                 J. Solinas
Intended status: Informational                                       NSA
Expires: May 5, 2010                                    November 5, 2009


                Suite B Cryptographic Suites for IPsec
                    <draft-law-rfc4869bis-00.txt>


Status of This Memo

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

  Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF), its areas, and its working groups. Note that 
  other groups may also distribute working documents as 
  Internet-Drafts.

  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."

  The list of current Internet-Drafts can be accessed at
  http://www.ietf.org/1id-abstracts.html.

  The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html.


  Copyright Notice

  Copyright (c) 2009 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 in effect on the date of
  publication of this document (http://trustee.ietf.org/license-info).
  Please review these documents carefully, as they describe your 
  rights and restrictions with respect to this document.












Law, Solinas                 Expires May 5, 2010                [Page 1]

RFC 4869         Suite B Cryptographic Suites for IPsec        July 2009


Abstract

  This document proposes four optional cryptographic user interface
  suites ("UI suites") for IPsec, similar to the two suites specified
  in RFC 4308.  The four new suites provide compatibility with the
  United States National Security Agency's Suite B specifications.
  This document obsoletes RFC 4869, which presented earlier versions of
  these suites.


Table of Contents

  1. Introduction ....................................................2
  2. Requirements Terminology ........................................2
  3. New UI Suites ...................................................3
     3.1. Suite "Suite-B-GCM-128" ....................................3
     3.2. Suite "Suite-B-GCM-256" ....................................4
     3.3. Suite "Suite-B-GMAC-128" ...................................5
     3.4. Suite "Suite-B-GMAC-256" ...................................6
     3.5. Lifetimes for IKEv1 ........................................7
  4. Security Considerations .........................................7
  5. IANA Considerations .............................................7
  6. Changes from RFC 4869............................................8
  7. References ......................................................8
     7.1. Normative References .......................................8
     7.2. Informative References .....................................9


1.  Introduction

  [RFC4308] proposes two optional cryptographic user interface suites
  ("UI suites") for IPsec.  The two suites, VPN-A and VPN-B, represent
  commonly used present-day corporate VPN security choices and
  anticipated future choices, respectively.  [RFC4869] proposed four
  new UI suites based on implementations of the United States National
  Security Agency's Suite B algorithms (see [SuiteB]). 

  As with the VPN suites, the Suite B suites are simply collections of
  values for some options in IPsec.  Use of UI suites does not change
  the IPsec protocols in any way.

  This document makes several minor changes to the suites in [RFC4869] 
  while retaining the original suite names. A detailed list of the 
  changes is given in Section 6.  This document obsoletes RFC 4869.

2.  Requirements Terminology

  The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
  in this document are to be interpreted as described in [RFC2119].


Law, Solinas                 Expires May 5, 2010                [Page 2]

RFC 4869         Suite B Cryptographic Suites for IPsec     October 2009


3.  New UI Suites

  Each of the following UI suites provides choices for ESP (see
  [RFC4303]) and for IKEv1 and IKEv2 (see [RFC2409] and [RFC4306]).
  The four suites are differentiated by the choice of cryptographic
  algorithm strengths and a choice of whether the Encapsulating
  Security Payload (ESP) is to provide both confidentiality and
  integrity or integrity only.  The suite names are based on the
  Advanced Encryption Standard [AES] mode and AES key length specified
  for ESP.

  IPsec implementations that use these UI suites SHOULD use the suite
  names listed here.  IPsec implementations SHOULD NOT use names
  different than those listed here for the suites that are described,
  and MUST NOT use the names listed here for suites that do not match
  these values.  These requirements are necessary for interoperability.


3.1.  Suite "Suite-B-GCM-128"

  This suite provides ESP integrity protection and confidentiality
  using 128-bit AES-GCM (see [RFC4106]).  This suite or the following
  suite should be used when ESP integrity protection and encryption are
  both needed.

  ESP:
    Encryption     AES with 128-bit keys and 16-octet Integrity
                     Check Value (ICV) in GCM mode [RFC4106]
    Integrity      NULL


  IKEv1:
    Encryption                   AES with 128-bit keys in CBC mode
                                   [RFC3602]
    Pseudo-random function       HMAC-SHA-256 [RFC4868]
    Hash                         SHA-256 [FIPS-180-2] [RFC4634]
    Diffie-Hellman group         256-bit random ECP group [RFC4753]

  For IKEv1, Phase 1 MUST use Main mode.  IKEv1 implementations MUST
  support pre-shared key authentication [RFC2409] for interoperability.
  The authentication method used with IKEv1 MUST be either pre-shared
  key [RFC2409] or ECDSA-256 [RFC4754].

  IKEv2:
    Encryption                   AES with 128-bit keys in CBC mode
                                   [RFC3602]
    Pseudo-random function       HMAC-SHA-256 [RFC4868]
    Integrity                    HMAC-SHA-256-128 [RFC4868]
    Diffie-Hellman group         256-bit random ECP group [RFC4753]


Law, Solinas                 Expires May 5, 2010                [Page 3]

RFC 4869         Suite B Cryptographic Suites for IPsec     October 2009


  The authentication method for systems that use IKEv2 MUST be either 
  ECDSA-256 or ECDSA-384 [RFC4754]. It is allowable for one party to 
  authenticate with ECDSA-256 and the other party to authenticate with 
  ECDSA-384. However, the security level of each authentication method 
  should be at least as high as the security strength desired for the 
  negotiated security associations (SAs). To support interoperability 
  when each party uses a different authentication method, all 
  implementations SHOULD have the capability to verify both ECDSA-256 
  and ECDSA-384.

  Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2)
  MUST be supported by both parties in this suite.  The initiator of
  this exchange MAY include a new Diffie-Hellman key; if it is
  included, it MUST use the 256-bit random ECP group.  If the 
  initiator of the exchange includes a Diffie-Hellman key, the 
  responder MUST include a Diffie-Hellman key, and it MUST use the 
  256-bit random ECP group.


3.2.  Suite "Suite-B-GCM-256"

  This suite provides ESP integrity protection and confidentiality
  using 256-bit AES-GCM (see [RFC4106]).  This suite or the preceding
  suite should be used when ESP integrity protection and encryption are
  both needed.

  ESP:
    Encryption     AES with 256-bit keys and 16-octet ICV in GCM mode
                     [RFC4106]
    Integrity      NULL

  IKEv1:
    Encryption                   AES with 256-bit keys in CBC mode
                                   [RFC3602]
    Pseudo-random function       HMAC-SHA-384 [RFC4868]
    Hash                         SHA-384 [FIPS-180-2] [RFC4634]
    Diffie-Hellman group         384-bit random ECP group [RFC4753]

  For IKEv1, Phase 1 MUST use Main mode.  IKEv1 implementations MUST
  support pre-shared key authentication [RFC2409] for interoperability.
  The authentication method used with IKEv1 MUST be either pre-shared
  key [RFC2409] or ECDSA-384 [RFC4754].

  IKEv2:
    Encryption                   AES with 256-bit keys in CBC mode
                                   [RFC3602]
    Pseudo-random function       HMAC-SHA-384 [RFC4868]
    Integrity                    HMAC-SHA-384-192 [RFC4868]
    Diffie-Hellman group         384-bit random ECP group [RFC4753]


Law, Solinas                 Expires May 5, 2010                [Page 4]

RFC 4869         Suite B Cryptographic Suites for IPsec     October 2009


  The authentication method for systems that use IKEv2 MUST be either 
  ECDSA-256 or ECDSA-384 [RFC4754]. It is allowable for one party to 
  authenticate with ECDSA-256 and the other party to authenticate with 
  ECDSA-384. However, the security level of each authentication method 
  should be at least as high as the security strength desired for the 
  negotiated security associations (SAs). To support interoperability 
  when each party uses a different authentication method, all 
  implementations SHOULD have the capability to verify both ECDSA-256 
  and ECDSA-384.

  Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2) 
  MUST be supported by both parties in this suite.  The initiator of 
  this exchange MAY include a new Diffie-Hellman key; if it is 
  included, it MUST use the 384-bit random ECP group.  If the 
  initiator of the exchange includes a Diffie-Hellman key, the 
  responder MUST include a Diffie-Hellman key, and it MUST use the 384-
  bit random ECP group.


3.3.  Suite "Suite-B-GMAC-128"

  This suite provides ESP integrity protection using 128-bit AES-GMAC
  (see [RFC4543]) but does not provide confidentiality.  This suite or
  the following suite should be used only when there is no need for ESP
  encryption.

  ESP:
    Encryption     NULL
    Integrity      AES with 128-bit keys in GMAC mode [RFC4543]

  IKEv1:
    Encryption                   AES with 128-bit keys in CBC mode
                                   [RFC3602]
    Pseudo-random function       HMAC-SHA-256 [RFC4868]
    Hash                         SHA-256 [FIPS-180-2] [RFC4634]
    Diffie-Hellman group         256-bit random ECP group [RFC4753]

  For IKEv1, Phase 1 MUST use Main mode.  IKEv1 implementations MUST
  support pre-shared key authentication [RFC2409] for interoperability.
  The authentication method used with IKEv1 MUST be either pre-shared
  key [RFC2409] or ECDSA-256 [RFC4754].

  IKEv2:
    Encryption                   AES with 128-bit keys in CBC mode
                                   [RFC3602]
    Pseudo-random function       HMAC-SHA-256 [RFC4868]
    Integrity                    HMAC-SHA-256-128 [RFC4868]
    Diffie-Hellman group         256-bit random ECP group [RFC4753]



Law, Solinas                 Expires May 5, 2010                [Page 5]

RFC 4869         Suite B Cryptographic Suites for IPsec     October 2009


  The authentication method for systems that use IKEv2 MUST be either 
  ECDSA-256 or ECDSA-384 [RFC4754]. It is allowable for one party to 
  authenticate with ECDSA-256 and the other party to authenticate with 
  ECDSA-384. However, the security level of each authentication method 
  should be at least as high as the security strength desired for the 
  negotiated security associations (SAs). To support interoperability 
  when each party uses a different authentication method, all 
  implementations SHOULD have the capability to verify both ECDSA-256 
  and ECDSA-384.

  Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2) 
  MUST be supported by both parties in this suite.  The initiator of 
  this exchange MAY include a new Diffie-Hellman key; if it is 
  included, it MUST use the 256-bit random ECP group.  If the 
  initiator of the exchange includes a Diffie-Hellman key, the 
  responder MUST include a  Diffie-Hellman key, and it MUST use the 
  256-bit random ECP group.  


3.4.  Suite "Suite-B-GMAC-256"

  This suite provides ESP integrity protection using 256-bit AES-GMAC
  (see [RFC4543]) but does not provide confidentiality.  This suite or
  the preceding suite should be used only when there is no need for ESP
  encryption.

  ESP:
    Encryption     NULL
    Integrity      AES with 256-bit keys in GMAC mode [RFC4543]

  IKEv1:
    Encryption                   AES with 256-bit keys in CBC mode
                                   [RFC3602]
    Pseudo-random function       HMAC-SHA-384 [RFC4868]
    Hash                         SHA-384 [FIPS-180-2] [RFC4634]
    Diffie-Hellman group         384-bit random ECP group [RFC4753]

  For IKEv1, Phase 1 MUST use Main mode.  IKEv1 implementations MUST
  support pre-shared key authentication [RFC2409] for interoperability.
  The authentication method used with IKEv1 MUST be either pre-shared
  key [RFC2409] or ECDSA-384 [RFC4754].

  IKEv2:
    Encryption                   AES with 256-bit keys in CBC mode
                                   [RFC3602]
    Pseudo-random function       HMAC-SHA-384 [RFC4868]
    Integrity                    HMAC-SHA-384-192 [RFC4868]
    Diffie-Hellman group         384-bit random ECP group [RFC4753]



Law, Solinas                 Expires May 5, 2010                [Page 6]

RFC 4869         Suite B Cryptographic Suites for IPsec     October 2009


  The authentication method for systems that use IKEv2 MUST be either 
  ECDSA-256 or ECDSA-384 [RFC4754]. It is allowable for one party to 
  authenticate with ECDSA-256 and the other party to authenticate with 
  ECDSA-384. However, the security level of each authentication method 
  should be at least as high as the security strength desired for the 
  negotiated security associations (SAs). To support interoperability 
  when each party uses a different authentication method, all 
  implementations SHOULD have the capability to verify both ECDSA-256 
  and ECDSA-384.

  Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2) 
  MUST be supported by both parties in this suite.  The initiator of 
  this exchange MAY include a new Diffie-Hellman key; if it is 
  included, it MUST use the 384-bit random ECP group.  If the 
  initiator of the exchange includes a Diffie-Hellman key, the 
  responder MUST include a Diffie-Hellman key, and it MUST use the 384-
  bit random ECP group.

3.5.  Lifetimes for IKEv1

  IKEv1 has two security parameters that do not appear in IKEv2,
  namely, the lifetime of the Phase 1 and Phase 2 security associations
  (SAs).  Systems that use IKEv1 with any of the four suites given in
  this document MUST use an SA lifetime of 86400 seconds (1 day) for 
  Phase 1 and an SA lifetime of 28800 seconds (8 hours) for Phase 2.


4.  Security Considerations

  This document inherits all of the security considerations of the
  IPsec, IKEv1, and IKEv2 documents.  See [CNSSP-15] for guidance on
  the use of AES in these suites for the protection of U.S. Government
  information.

  Some of the security options specified in these suites may be found
  in the future to have properties significantly weaker than those that
  were believed at the time this document was produced.


5.  IANA Considerations

  IANA maintains a registry called "Cryptographic Suites for IKEv1, 
  IKEv2, and IPsec" (see [IANA-Suites]).  The registry consists of a 
  text string and an RFC number that lists the associated transforms.  
  The four suites in this document have been listed with [RFC4869] as 
  the RFC reference.  These entries will be updated upon approval of 
  this document.

  The updated values for the registry are:


Law, Solinas                 Expires May 5, 2010                [Page 7]

RFC 4869         Suite B Cryptographic Suites for IPsec     October 2009


  Identifier              Defined in
  Suite-B-GCM-128         this document
  Suite-B-GCM-256         this document
  Suite-B-GMAC-128        this document
  Suite-B-GMAC-256        this document


6.  Changes from RFC 4869

  The changes from [RFC4869] are:

  1.  In the IKEv2 case, removed the requirement for a single
      authentication method in each suite.  Either party may now 
      use either ECDSA-256 or ECDSA-384.  This change will take 
      advantage of IKEv2's capability to allow interoperability 
      between an initiator and a responder that have different 
      types of ECDSA authentication keys.

  2.  In the IKEv1 case, specified the SA lifetimes for both Phase 1 
      and Phase 2.

  3.  Clarified requirements for an optional Diffie-Hellman exchange in
      Phase 2 (for IKEv1) and the CREATE_CHILD_SA (for IKEv2).

  4.  Specified that the authentication method used with IKEv1 MUST be 
      either pre-shared key or ECDSA.  (MUST was previously MAY.)

  5.  In the IKEv1 case, specified that Phase 1 MUST use Main mode.  
      (MUST was previously SHOULD.)

  6.  Deleted the statement that the IKEv1 group type is ECP in all 
      four suites, since this is covered in the description of the 
      Diffie-Hellman group.


7.  References

7.1.  Normative References

  [FIPS-180-3]  FIPS 180-3, "Secure Hash Standard", National Institute 
                of Standards and Technology, October 2008.

  [IANA-Suites] Internet Assigned Numbers Authority, "Cryptographic
                Suites for IKEv1, IKEv2, and IPsec",
                <http://www.iana.org/assignments/crypto-suites>.

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



Law, Solinas                 Expires May 5, 2010                [Page 8]

RFC 4869         Suite B Cryptographic Suites for IPsec     October 2009


  [RFC2409]     Harkins, D. and D. Carrel, "The Internet Key Exchange
                (IKE)", RFC 2409, November 1998.

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

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

  [RFC4303]     Kent, S., "IP Encapsulating Security Payload (ESP)",
                RFC 4303, December 2005.

  [RFC4306]     Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
                RFC 4306, December 2005.

  [RFC4308]     Hoffman, P., "Cryptographic Suites for IPsec", RFC
                4308, December 2005.

  [RFC4543]     McGrew, D. and J. Viega, "The Use of Galois Message
                Authentication Code (GMAC) in IPsec ESP and AH", RFC
                4543, May 2006.

  [RFC4753]     Fu, D. and J. Solinas, "ECP Groups for IKE and IKEv2",
                RFC 4753, November 2006.

  [RFC4754]     Fu, D. and J. Solinas, "IKE and IKEv2 Authentication
                Using ECDSA", RFC 4754, November 2006.

  [RFC4868]     Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-
                SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May
                2007.

  [RFC4869]     Law, L. and J. Solinas, "Suite B Cryptographic Suites 
                for IPsec", RFC 4869, May 2007.

7.2.  Informative References

  [AES]         U.S. Department of Commerce/National Institute of
                Standards and Technology, "Advanced Encryption Standard
                (AES)", FIPS PUB 197, November 2001,
                <http://csrc.nist.gov/publications/fips/index.html>.

  [CNSSP-15]    Committee on National Security Systems, "National
                Policy on the Use of the Advanced Encryption Standard
                (AES) to Protect National Security Systems and National
                Security Information", June 2003,
                <http://www.cnss.gov/Assets/pdf/cnssp_15_fs.pdf>.


Law, Solinas                 Expires May 5, 2010                [Page 9]

RFC 4869         Suite B Cryptographic Suites for IPsec     October 2007


  [RFC4634]     Eastlake 3rd, D. and T. Hansen, "US Secure Hash
                Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.

  [SuiteB]      U.S. National Security Agency, "NSA Suite B 
                Cryptography", January 2009, <http://www.nsa.gov/ia/
                programs/suiteb_cryptography/index.shtml>.



Authors' Addresses

  Laurie E. Law
  National Information Assurance Research Laboratory
  National Security Agency

  EMail: lelaw@orion.ncsc.mil


  Jerome A. Solinas
  National Information Assurance Research Laboratory
  National Security Agency

  EMail: jasolin@orion.ncsc.mil




























Law, Solinas                 Expires May 5, 2010               [Page 10]