Suite VPN-D: Cryptographic Algorithm Suite with 112-bit Security for IPSEC
draft-grieco-suite-vpn-d-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/ietf/1id-abstracts.txt.

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

This Internet-Draft will expire on January 7, 2010.

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.

Abstract

This document defines a suite of cryptographic algorithms that target a 112-bit security level. Additionally, this document defines the use of these algorithms for use in IPSEC.

Table of Contents

1.  Introduction
    1.1.  Conventions Used In This Document
2.  Algorithms
    2.1.  Considerations
        2.1.1.  Naming
    2.2.  Suite D Algorithms
3.  Suite D Algorithms in IPSec
4.  Security Considerations
5.  IANA Considerations
6.  Acknowledgements
7.  References
    7.1.  Normative References
    7.2.  Informative References
Appendix A.  Other 2048 bit MODP Groups
§  Authors' Addresses

1.  Introduction

[SuiteB] (, “Fact Sheet for NSA Suite B Cryptography,” .) defines a set of cryptographic algorithms that are secure, well reviewed, and are efficient at high data rates and high security levels. Currently, support for Suite B is only partly available across the industry. Traditionally, the adoption of new algorithms by the industry is a complex and slow process involving multiple actors, including policy makers in government and industry, standards organizations, and vendors of crypto software and hardware, network devices and software, and operating systems. Complications around ownership of some intellectual property rights as also slowed adoption of Suite B.

In this document, we define a suite of crypto algorithms that overlap with Suite B, that contains only algorithms that are believed to be unencumbered by intellectual property considerations and that targets a 112-bit security level. This level is not as high as that of Suite B, but it is believed to be adequately secure to meet present commercial needs. It provides a halfway point between current industry practice and Suite B.

It is hoped that the adoption of this new suite will simplify and shorten the process of adopting Suite B while providing 112-bit security.

As with previous user interface suites ("UI suites") for IPSec (see [RFC4308] (Hoffman, P., “Cryptographic Suites for IPsec,” December 2005.) and [RFC4869] (Law, L. and J. Solinas, “Suite B Cryptographic Suites for IPsec,” May 2007.)), this document simply defines a few collections of algorithms for IPSec and does not modify the protocol itself in any way.

1.1.  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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  Algorithms

2.1.  Considerations

There were four main criteria taken into consideration when developing the list of algorithms to be recommended:

• IPR licensing concerns
• Targeted strength equivalence of at least 112 bits of security
• Acceptance of algorithms by the industry and governments, including NIST approval of algorithms
• Interoperability between VPN devices

2.1.1.  Naming

The naming of the suite of algorithms defined here is based on the precedent set forth in RFC4308 where the denotation of "VPN-A" and "VPN-B" is used. Due to concerns over naming conflicts with organizations that already exist in the industry, the "VPN-C" designation was bypassed and therefore the suite defined here is referenced as "VPN-D".

2.2.  Suite D Algorithms

For Authenticated Encryption in the data plane, AES with 128 bit keys in GCM mode with 128 bit ICV [RFC4106] (Viega, J. and D. McGrew, “The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP),” June 2005.) MUST be used.

For Integrity checks (when Authenticated Encryption is not in use), HMAC-SHA-256-128 [RFC4868] (Kelly, S. and S. Frankel, “Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec,” May 2007.) MUST be used.

For hashing algorithms, SHA-256 [SHA2] (, “FIPS 180-2: Secure Hash Standard,,” 2002.) MUST be used.

For certificate based signatures, RSA-2048 and SHA-256 MUST be used.

For Diffie-Hellman key exchanges, a 2048-bit MODP group MUST be used. Explicitly, Diffie-Hellman Group 14 [RFC3526] (Kivinen, T. and M. Kojo, “More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE),” May 2003.) MUST be used.

For pseudo-random generation function, PRF-HMAC-SHA-256 [RFC4868] (Kelly, S. and S. Frankel, “Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec,” May 2007.) MUST be used.

3.  Suite D Algorithms in IPSec

Suite-VPN-D defines the set of algorithms intended to be used for IPSec VPN applications and fully complies with the MUST Suite D algorithms defined above.

For IKEv1 implementations, Main mode SHOULD be used.

IKEv1 implementations MUST support rekeying of Phase 2. For IKEv2 implementations, CREATE-CHILD_SA exchanges MUST be supported. Rekey operations that include the optional Diffie-Hellman key MUST use a key that is DH Group 14.

If the pre-shared key option is used, then it MUST have a min-entropy of 128 bits. This means that the key must be chosen at random in such a way that the most probable key will occur with probability no greater than 2^(-128). A practical way to achieve this is to choose the key uniformly at random; for example, a string of 22 base64 characters chosen uniformly at random has sufficient min-entropy.

4.  Security Considerations

The target of 112-bit security level for the suite is generally believed to be sufficient for some time given current technologies [RFC3766] (Orman, H. and P. Hoffman, “Determining Strengths For Public Keys Used For Exchanging Symmetric Keys,” April 2004.). This security level is also supported by current NIST recommendations for key strengths [NIST.800‑57.2007] (National Institute of Standards and Technology, “Recommendation for Key Management - Part 1: General,” March 2007.).

5.  IANA Considerations

The IANA registry called "Cryptographic Suites for IKEv1, IKEv2, and IPsec" should be updated with an identifier of 'VPN-D' following the criteria set forth in [RFC4308] (Hoffman, P., “Cryptographic Suites for IPsec,” December 2005.).

6.  Acknowledgements

The authors would like to thank Scott Fluhrer and Igor Balabine for their review and comment on this document.

7.  References

7.1. Normative References

7.2. Informative References

Appendix A.  Other 2048 bit MODP Groups

In this document, we make use of Diffie-Hellman Group 14 in Suite VPN-D to provide 2048 bit MODP for IKE. Diffie-Hellman Group 24 [RFC5114] (Lepinski, M. and S. Kent, “Additional Diffie-Hellman Groups for Use with IETF Standards,” January 2008.) might also be considered to for this purpose. However, the authors note, the prime chosen for Group 24 is not a safe prime and modified IKE hanlding based on public key validation routines might be required.

Authors' Addresses