rfc-8247

Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)

Y. Nir, T. Kivinen, P. Wouters, D. Migault
date2017-09 streamIETF areasec wgipsecme statusPROPOSED STANDARD pages19 canonicalhttps://www.rfc-editor.org/rfc/rfc8247 doi10.17487/RFC8247
The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document updates RFC 7296 and obsoletes RFC 4307 in defining the current algorithm implementation requirements and usage guidance for IKEv2, and does minor cleaning up of the IKEv2 IANA registry. This document does not update the algorithms used for packet encryption using IPsec Encapsulating Security Payload (ESP).

obsoletes

updated by

updates

Extracted elements (30)

design-rationale §1.3

Algorithm deprecation is performed gradually (MUST → MUST- → SHOULD → MAY → MUST NOT) to give implementations time to update while remaining interoperable, unless there are strong security reasons for immediate removal.

ipsec, crypto, security

design-rationale §2.4

DH Groups 22, 23, and 24 are demoted because their group seeds were never publicly released, reducing trust, and they never saw wide deployment despite being proposed as alternatives to groups 2 and 14.

ipsec, crypto, security

design-rationale §2.1

ENCR_AES_GCM_16 is kept at SHOULD rather than promoted higher because, while widely implemented for ESP, the relatively small computation load of IKEv2 meant many IKEv2 implementations never added AES-GCM support.

ipsec, crypto

design-rationale §4

IoT devices prefer AES-CCM and AES-XCBC over SHA-based algorithms to minimize code footprint and enable hardware crypto reuse; IEEE 802.15.4 mandates AES-CCM at the link layer, making AES-CCM the natural IKEv2 choice for those devices.

ipsec, crypto

interoperability-note §2.1

ENCR_AES_CBC is the only mandatory-to-implement algorithm shared with RFC 4307; implementations must retain it to remain interoperable with RFC 4307-conformant peers.

ipsec, crypto

normative-requirement §2.3 MUST NOT

AUTH_HMAC_MD5_96, AUTH_DES_MAC, and AUTH_KPDK_MD5 MUST NOT be implemented due to the industry-wide deprecation of DES and MD5.

ipsec, crypto, security

normative-requirement §2.3 MUST

AUTH_HMAC_SHA2_256_128 MUST be implemented for IKEv2 integrity, replacing AUTH_HMAC_SHA1_96.

ipsec, crypto

normative-requirement §2.4 MUST NOT

DH Group 1 (768-bit MODP) MUST NOT be used; it can be broken within hours using cheap off-the-shelf hardware.

ipsec, crypto, security

normative-requirement §2.4 MUST NOT

DH Group 22 (1024-bit MODP with 160-bit Prime Order Subgroup) MUST NOT be used; academia can generate malicious values at this key size.

ipsec, crypto, security

normative-requirement §2.4 SHOULD NOT

DH Groups 2 (1024-bit MODP) and 5 (1536-bit MODP) are downgraded to SHOULD NOT as their security margin is considered too narrow against well-funded attackers.

ipsec, crypto, security

normative-requirement §2.4 MUST

Diffie-Hellman Group 14 (2048-bit MODP) MUST be implemented, raised from SHOULD+ in RFC 4307 as a replacement for the 1024-bit group.

ipsec, crypto

normative-requirement §3.1 SHOULD NOT

DSS Digital Signature (IANA value 3) SHOULD NOT be used; it is bound to SHA-1 and has the security equivalent of 1024-bit RSA.

ipsec, crypto, security

normative-requirement §2.1 MUST

ENCR_AES_CBC MUST be implemented for IKEv2 encryption. This applies to 128-bit and 256-bit keys; 192-bit keys remain at MAY.

ipsec, crypto, vpn

normative-requirement §2.1 SHOULD

ENCR_AES_CCM_8 SHOULD be implemented for IoT interoperability, using 128-bit keys; 256-bit keys remain at MAY.

ipsec, crypto, vpn

normative-requirement §2.1 SHOULD

ENCR_AES_GCM_16 SHOULD be implemented. It is an AEAD cipher preferred over traditional encrypt+auth; 8- and 12-octet ICVs remain at MAY.

ipsec, crypto

normative-requirement §2.1 SHOULD

ENCR_CHACHA20_POLY1305 SHOULD be implemented as an AEAD alternative to AES-CBC and AES-GCM, recommended by the CFRG.

ipsec, crypto

normative-requirement §2.1 MUST NOT

ENCR_DES MUST NOT be implemented. It can be brute-forced using off-the-shelf hardware and provides no meaningful security.

ipsec, crypto, security

normative-requirement §2.1 MUST NOT

ENCR_NULL MUST NOT be used. RFC 7296 Section 5 already prohibited it; RFC 4307 incorrectly listed it as MAY, which this document corrects.

ipsec, crypto, security

normative-requirement §2.1 MUST

Non-AEAD encryption algorithms MUST be used in conjunction with one of the integrity algorithms listed in Section 2.3.

ipsec, crypto, security

normative-requirement §2.2 MUST NOT

PRF_HMAC_MD5 MUST NOT be implemented. MD5 is subject to collision attacks and is being removed from cryptographic libraries industry-wide.

ipsec, crypto, security

normative-requirement §2.2 MUST

PRF_HMAC_SHA1 is downgraded to MUST- due to increasing cryptographic attacks against SHA1; it will eventually be deprecated further.

ipsec, crypto, security

normative-requirement §2.2 MUST

PRF_HMAC_SHA2_256 MUST be implemented as the primary pseudorandom function, replacing PRF_HMAC_SHA1.

ipsec, crypto

normative-requirement §3.1 MUST

RSA Digital Signature (method 1) and Shared Key Message Integrity Code (method 2) MUST be implemented as IKEv2 authentication methods.

ipsec, crypto, pkix

normative-requirement §3.1.1 SHOULD NOT

RSA keys of length smaller than 2048 bits SHOULD NOT be used. RSA with 2048-bit keys MUST be supported; 3072 and 4096-bit keys SHOULD be supported.

ipsec, crypto, pkix, security

normative-requirement §2.4 MUST

When DH Groups 23 or 24 are used, the small-subgroup checks specified in RFC 6989 Section 2.2 MUST be performed.

ipsec, crypto, security

normative-requirement §3.2 MUST NOT

When the Digital Signature method is used, SHA1 MUST NOT be used for hashing; SHA2-256 MUST be used, and SHA2-512 SHOULD be used.

ipsec, crypto, security

normative-requirement §3.2 MUST

When the Digital Signature method is used with RSA, RSASSA-PSS MUST be supported; RSASSA-PKCS1-v1.5 MAY be supported.

ipsec, crypto, pkix

registry §6

This document renames six entries in the IANA 'Transform Type 1 - Encryption Algorithm Transform IDs' registry: AES-GCM entries are renamed to ENCR_AES_GCM_8/12/16 and Camellia CCM entries to ENCR_CAMELLIA_CCM_8/12/16 for naming consistency.

ipsec, registry

security-consideration §5

Algorithms marked MUST or SHOULD implement are not known to be broken at time of publication, but this document is expected to be periodically revised as cryptographic research evolves.

ipsec, security, crypto

security-consideration §5

The Diffie-Hellman Group is the most critical parameter to choose conservatively. An attacker who can later break the DH group used in IKE can retroactively decrypt all recorded ESP traffic, since the DH exchange provides the symmetric session keys.

ipsec, crypto, security, vpn