rfc-4109

Algorithms for Internet Key Exchange version 1 (IKEv1)

P. Hoffman
date2005-05 streamIETF wgnon working group statusPROPOSED STANDARD pages5 canonicalhttps://www.rfc-editor.org/rfc/rfc4109 doi10.17487/RFC4109
The required and suggested algorithms in the original Internet Key Exchange version 1 (IKEv1) specification do not reflect the current reality of the IPsec market requirements. The original specification allows weak security and suggests algorithms that are thinly implemented. This document updates RFC 2409, the original specification, and is intended for all IKEv1 implementations deployed today. [STANDARDS-TRACK]

updates

Extracted elements (15)

design-rationale §3

DES for encryption, MD5 for hashing, and Diffie-Hellman MODP group 1 are dropped to MAY due to cryptographic weakness. These algorithms no longer provide adequate security for modern IPsec deployments.

ipsec, crypto, security, vpn

design-rationale §3

If additional updates are made to IKEv1 in the future, AES-128 in CBC mode for encryption is very likely to become mandatory, anticipating a future upgrade path beyond SHOULD.

ipsec, crypto, vpn

design-rationale §1

The original RFC 2409 requirements no longer reflect the current reality of IPsec market requirements; the original specification allows weak security and suggests algorithms that are thinly implemented, motivating this update.

ipsec, crypto, vpn, security

design-rationale §3

Tiger for hashing, DH groups with elliptic curves, DSA with signatures, and RSA with encryption are dropped to MAY due to lack of any significant deployment and interoperability, not because of known cryptographic weakness.

ipsec, crypto, vpn

interoperability-note §2

RFC 2409 gave two conflicting requirement levels for DH MODP groups with elliptic curves: Section 4 said MAY while Sections 6.3 and 6.4 said SHOULD for groups 3 and 4. This document resolves the conflict by setting all EC DH groups to MAY.

ipsec, crypto, vpn

normative-requirement §3 SHOULD

AES-128 in CBC mode (RFC 3602) for encryption SHOULD be supported. This is a new requirement not present in RFC 2409.

ipsec, crypto, vpn

normative-requirement §3 SHOULD

AES-128 in XCBC mode for PRF functions (per RFC 3566 and RFC 3664) SHOULD be supported. This is a new requirement not present in RFC 2409.

ipsec, crypto, vpn

normative-requirement §3 MAY

DES for encryption, MD5 for hashing/HMAC, Tiger for hashing, DH MODP group 1, DH elliptic curve groups, DSA with signatures, and RSA with encryption are all now MAY-level, downgraded from their RFC 2409 MUST or SHOULD levels.

ipsec, crypto, vpn

normative-requirement §3 SHOULD

Diffie-Hellman MODP group 14 (discrete log 2048 bits, per RFC 3526) SHOULD be supported. This is a new requirement not present in RFC 2409.

ipsec, crypto, vpn

normative-requirement §3 MUST

Diffie-Hellman MODP group 2 (discrete log 1024 bits) MUST be supported. This is upgraded from SHOULD in RFC 2409.

ipsec, crypto, vpn

normative-requirement §3 MUST

Pre-shared secrets for authentication MUST be supported. This requirement is carried over unchanged from RFC 2409.

ipsec, crypto, vpn

normative-requirement §3 SHOULD

RSA for authentication with signatures SHOULD be supported. This is carried over at the same level from RFC 2409.

ipsec, crypto, pkix, vpn

normative-requirement §3 MUST

SHA-1 for hashing and HMAC functions MUST be supported. This requirement is carried over from RFC 2409.

ipsec, crypto, vpn

normative-requirement §3 MUST

TripleDES for encryption MUST be supported by IKEv1 implementations. This is upgraded from SHOULD in RFC 2409.

ipsec, crypto, vpn

security-consideration §5

All algorithms at MUST-level or SHOULD-level in the new requirements are believed to be robust and secure at the time of writing. Algorithms dropped to MAY were either cryptographically weak (DES, MD5, DH group 1) or insufficiently deployed.

ipsec, crypto, security, vpn