draft-ietf-ipsecme-rfc4307bis-00.txt   draft-ietf-ipsecme-rfc4307bis-01.txt 
Network Working Group Y. Nir Network Working Group Y. Nir
Internet-Draft Check Point Internet-Draft Check Point
Intended status: Standards Track T. Kivinen Intended status: Standards Track T. Kivinen
Expires: April 20, 2016 INSIDE Secure Expires: May 12, 2016 INSIDE Secure
P. Wouters P. Wouters
Red Hat Red Hat
D. Migault D. Migault
Ericsson Ericsson
October 18, 2015 November 9, 2015
Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 Cryptographic Algorithms for Use in the Internet Key Exchange Version 2
(IKEv2) (IKEv2)
draft-ietf-ipsecme-rfc4307bis-00 draft-ietf-ipsecme-rfc4307bis-01
Abstract Abstract
The IPsec series of protocols makes use of various cryptographic The IPsec series of protocols makes use of various cryptographic
algorithms in order to provide security services. The Internet Key algorithms in order to provide security services. The Internet Key
Exchange protocol provides a mechanism to negotiate which algorithms Exchange protocol provides a mechanism to negotiate which algorithms
should be used in any given association. However, to ensure should be used in any given association. However, to ensure
interoperability between disparate implementations, it is necessary interoperability between disparate implementations, it is necessary
to specify a set of mandatory-to-implement algorithms to ensure that to specify a set of mandatory-to-implement algorithms to ensure that
there is at least one algorithm that all implementations will have there is at least one algorithm that all implementations will have
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 20, 2016. This Internet-Draft will expire on May 12, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 3 3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 3
3.1. IKEv2 Transform Type 1 Algorithms . . . . . . . . . . . . 3 3.1. IKEv2 Transform Type 1 Algorithms . . . . . . . . . . . . 3
3.2. IKEv2 Transform Type 3 Algorithms . . . . . . . . . . . . 4 3.2. IKEv2 Transform Type 3 Algorithms . . . . . . . . . . . . 4
3.3. IKEv2 Transform Type 2 Algorithms . . . . . . . . . . . . 4 3.3. IKEv2 Transform Type 2 Algorithms . . . . . . . . . . . . 5
3.4. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 5 3.4. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
The Internet Key Exchange protocol [RFC7296] provides for the The Internet Key Exchange protocol [RFC7296] provides for the
negotiation of cryptographic algorithms between both endpoints of a negotiation of cryptographic algorithms between both endpoints of a
cryptographic association. Different implementations of IPsec and cryptographic association. Different implementations of IPsec and
IKE may provide different algorithms. However, the IETF desires that IKE may provide different algorithms. However, the IETF desires that
all implementations should have some way to interoperate. In all implementations should have some way to interoperate. In
particular, this requires that IKE define a set of mandatory-to- particular, this requires that IKE define a set of mandatory-to-
implement algorithms because IKE itself uses such algorithms as part implement algorithms because IKE itself uses such algorithms as part
skipping to change at page 4, line 19 skipping to change at page 4, line 20
| Name | Status | AEAD? | Comment | | Name | Status | AEAD? | Comment |
+-----------------------------+----------+-------+---------+ +-----------------------------+----------+-------+---------+
| ENCR_AES_CBC | MUST | No | [1] | | ENCR_AES_CBC | MUST | No | [1] |
| ENCR_CHACHA20_POLY1305 | SHOULD | Yes | | | ENCR_CHACHA20_POLY1305 | SHOULD | Yes | |
| AES-GCM with a 16 octet ICV | SHOULD | Yes | [1] | | AES-GCM with a 16 octet ICV | SHOULD | Yes | [1] |
| ENCR_AES_CCM_8 | SHOULD | Yes | [1] | | ENCR_AES_CCM_8 | SHOULD | Yes | [1] |
| ENCR_3DES | MAY | No | | | ENCR_3DES | MAY | No | |
| ENCR_DES | MUST NOT | No | | | ENCR_DES | MUST NOT | No | |
+-----------------------------+----------+-------+---------+ +-----------------------------+----------+-------+---------+
[1] - Both 256-bit and 128-bit keys should be supported at the same [1] - This requirement level is for 128-bit keys. 256-bit keys are at
level of requirement. MAY. 192-bit keys can safely be ignored.
Explanation about AES-CBC is TBD.
Explanation about ChaCha20 is TBD.
Explanation about AES-GCM is TBD.
Explanation about AES-CCM is TBD.
Explanation about 3DES is TBD.
Explanation about DES is TBD.
3.2. IKEv2 Transform Type 3 Algorithms 3.2. IKEv2 Transform Type 3 Algorithms
The algorithms in the below table are negotiated in the SA payload The algorithms in the below table are negotiated in the SA payload
and used in the ENCR payload. References to the specifications and used in the ENCR payload. References to the specifications
defining these algorithms are in the IANA registry. When an AEAD defining these algorithms are in the IANA registry. When an AEAD
algorithm (see Section 3.1) is used, no algorithm from this table algorithm (see Section 3.1) is used, no algorithm from this table
needs to be used. needs to be used.
+------------------------+---------+ +------------------------+---------+
| Name | Status | | Name | Status |
+------------------------+---------+ +------------------------+---------+
| AUTH_HMAC_SHA2_256_128 | MUST | | AUTH_HMAC_SHA2_256_128 | MUST |
| AUTH_HMAC_SHA2_384_192 | SHOULD+ | | AUTH_HMAC_SHA2_512_256 | SHOULD+ |
| AUTH_HMAC_SHA1_96 | MUST- | | AUTH_HMAC_SHA1_96 | MUST- |
| AUTH_AES_128_GMAC | MAY |
| AUTH_AES_XCBC_96 | MAY | | AUTH_AES_XCBC_96 | MAY |
| AUTH_HMAC_MD5_96 | MAY |
+------------------------+---------+ +------------------------+---------+
Explanation about SHA-256 is TBD.
Explanation about SHA-512 is TBD.
Explanation about SHA-1 is TBD.
Explanation about AES-XCBC is TBD.
3.3. IKEv2 Transform Type 2 Algorithms 3.3. IKEv2 Transform Type 2 Algorithms
Transform Type 2 Algorithms are pseudo-random functions used to Transform Type 2 Algorithms are pseudo-random functions used to
generate random values when needed. generate random values when needed.
+-------------------+---------+ +-------------------+---------+
| Name | Status | | Name | Status |
+-------------------+---------+ +-------------------+---------+
| PRF_HMAC_SHA2_256 | MUST | | PRF_HMAC_SHA2_256 | MUST |
| PRF_HMAC_SHA2_384 | SHOULD+ | | PRF_HMAC_SHA2_512 | SHOULD+ |
| PRF_HMAC_SHA1 | MUST- | | PRF_HMAC_SHA1 | MUST- |
| PRF_AES128_CBC | MAY | | PRF_AES128_CBC | MAY |
| PRF_HMAC_MD5 | MAY |
+-------------------+---------+ +-------------------+---------+
Explanation about SHA-256 is TBD.
Explanation about SHA-512 is TBD.
Explanation about SHA-1 is TBD.
Explanation about AES-XCBC is TBD.
3.4. Diffie-Hellman Groups 3.4. Diffie-Hellman Groups
There are several Modular Exponential (MODP) groups and several There are several Modular Exponential (MODP) groups and several
Elliptic Curve groups (ECC) that are defined for use in IKEv2. They Elliptic Curve groups (ECC) that are defined for use in IKEv2. They
are defined in both the [IKEv2] base document and in extensions are defined in both the [IKEv2] base document and in extensions
documents. They are identified by group number. documents. They are identified by group number.
+--------+--------------------------+------------+ +--------+--------------------------+------------+
| Number | Description | Status | | Number | Description | Status |
+--------+--------------------------+------------+ +--------+--------------------------+------------+
| 14 | 2048-bit MODP Group | MUST | | 14 | 2048-bit MODP Group | MUST |
| 19 | 256-bit random ECP group | SHOULD | | 19 | 256-bit random ECP group | SHOULD |
| 20 | 384-bit random ECP group | MAY |
| 2 | 1024-bit MODP Group | SHOULD NOT | | 2 | 1024-bit MODP Group | SHOULD NOT |
| 1 | 768-bit MODP Group | MUST NOT |
+--------+--------------------------+------------+ +--------+--------------------------+------------+
Explanation about Group 14 is TBD.
Explanation about Group 19 is TBD.
Explanation about Group 2 is TBD.
Explanation about Group 1 is TBD.
4. Security Considerations 4. Security Considerations
The security of cryptographic-based systems depends on both the The security of cryptographic-based systems depends on both the
strength of the cryptographic algorithms chosen and the strength of strength of the cryptographic algorithms chosen and the strength of
the keys used with those algorithms. The security also depends on the keys used with those algorithms. The security also depends on
the engineering of the protocol used by the system to ensure that the engineering of the protocol used by the system to ensure that
there are no non-cryptographic ways to bypass the security of the there are no non-cryptographic ways to bypass the security of the
overall system. overall system.
This document concerns itself with the selection of cryptographic This document concerns itself with the selection of cryptographic
skipping to change at page 6, line 13 skipping to change at page 6, line 39
this area. this area.
5. IANA Considerations 5. IANA Considerations
This document makes no requests of IANA. This document makes no requests of IANA.
6. Acknowledgements 6. Acknowledgements
The first version of this document was RFC 4307 by Jeffrey I. The first version of this document was RFC 4307 by Jeffrey I.
Schiller of the Massachusetts Institute of Technology (MIT). Much of Schiller of the Massachusetts Institute of Technology (MIT). Much of
the text has been copied verbatim. the original text has been copied verbatim.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, October 2014. (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption
Algorithms with the Encrypted Payload of the Internet Key Algorithms with the Encrypted Payload of the Internet Key
Exchange version 2 (IKEv2) Protocol", RFC 5282, DOI Exchange version 2 (IKEv2) Protocol", RFC 5282,
10.17487/RFC5282, August 2008, DOI 10.17487/RFC5282, August 2008,
<http://www.rfc-editor.org/info/rfc5282>. <http://www.rfc-editor.org/info/rfc5282>.
7.2. Informative References 7.2. Informative References
[IKEV2-IANA] [IKEV2-IANA]
"Internet Key Exchange Version 2 (IKEv2) Parameters", "Internet Key Exchange Version 2 (IKEv2) Parameters",
<http://www.iana.org/assignments/ikev2-parameters>. <http://www.iana.org/assignments/ikev2-parameters>.
Authors' Addresses Authors' Addresses
 End of changes. 22 change blocks. 
20 lines changed or deleted 57 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/