The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2)
updates
- rfc-4301 — Security Architecture for the Internet Protocol
Extracted elements (24)
ID_NULL is defined to avoid the need to send a bogus ID Type with placeholder data when a remote peer is unauthenticated. It is primarily intended for use with NULL authentication but may be used in other contexts (e.g., raw public key authentication) where the Identification payload content is not consumed, to be described in separate documents.
NULL Authentication is introduced to enable Opportunistic Security (RFC 7435) for IKEv2, allowing unauthenticated or single-side authenticated IKE sessions. This defends against Pervasive Monitoring attacks (RFC 7258) without requiring peers to sacrifice anonymity, covering scenarios where mutual authentication is undesirable, superfluous, or impossible.
The AUTH payload is retained even under NULL authentication because it cryptographically links the IKE_SA_INIT exchange messages with the IKE_AUTH messages, preserving IKEv2's message integrity guarantees even when peer identity is not verified. The use of SK_pi/SK_pr as the 'shared secret' mirrors EAP non-key-generating method behavior.
Existing IKEv2 implementations may have assumed that remote peers are always identified; NULL authentication invalidates this assumption. Omissions or errors in handling abusive authenticated clients may have been unnoticed previously but will be exposed and exploited when unauthenticated peers are supported.
PAD processing from RFC 4301 Section 4.4.3 is updated to add NULL authentication as a supported method (with no authentication data), add ID_NULL as an allowed ID type, and add an SPD flag indicating whether unauthenticated peers may use an SPD entry. Only SPD entries with the flag explicitly set can be used for unauthenticated connections.
An unauthenticated IKE peer MUST NOT be able to reach resources only meant for authenticated IKE peers and MUST NOT be able to replace the Child SAs of an authenticated IKE peer.
If a host's local policy requires non-null authentication of its peer and it receives an AUTH payload containing the NULL Authentication method type, it MUST return an AUTHENTICATION_FAILED notification.
If an initiator uses EAP, the responder MUST NOT use the NULL Authentication method, in conformance with Section 2.16 of RFC 7296.
If NULL authentication is in use and anonymity is a concern, ID_NULL SHOULD be used in the Identification payload. The content of the Identification payload MUST NOT be used for any trust and policy checking in IKE_AUTH exchange when NULL authentication is employed.
Implementations SHOULD restrict and isolate all anonymous IKE peers from each other and itself, allowing only access to itself and possibly its intended network ranges, to prevent rogue peers from stealing traffic via malicious Traffic Selectors.
INITIAL_CONTACT notifications MUST NOT be used to delete other IKE SAs based on the same peer identity when NULL authentication is in use, without additional verification that the existing IKE SAs are actually stale, because the peer identity is not authenticated.
The Identification Data field of the ID payload for ID_NULL MUST be empty.
When using IPv6, implementations MUST be able to assign a full /64 address block to the peer as described in RFC 5739, even if it is not authenticated, since forcing unauthenticated peers to single host-to-host IPsec SAs is not always possible with IPv6.
When using the NULL Authentication method, matching rules MUST include matching of a new flag in the SPD entry specifying whether unauthenticated users are allowed to use that entry. Only those SPD rules that explicitly have that flag turned on can be used with unauthenticated connections.
A new ID Type, ID_NULL (value 13), is defined for the IKEv2 Identification payload. It is used when a remote peer is not authenticated and no validated identity can be presented. The Identification Data field for ID_NULL MUST be empty.
NULL authentication still requires a properly formed AUTH payload in the IKE_AUTH exchange. The AUTH payload content is computed using pre-shared secret authentication syntax (RFC 7296 Section 2.15), with SK_pi used as the shared secret for the initiator and SK_pr for the responder. This is identical to the non-key-generating EAP method.
The IKEv2 Authentication Method value for NULL Authentication is 13, assigned in the 'IKEv2 Authentication Method' registry.
IANA has added entry 13 ('ID_NULL') to the 'IKEv2 Identification Payload ID Types' registry per this document.
IANA has added entry 13 ('NULL Authentication') to the 'IKEv2 Authentication Method' registry per this document.
Establishing an IPsec SA for an unauthenticated peer may accidentally circumvent packet filters or firewall rules, as ESP (protocol 50) or ESPinUDP (port 4500) traffic does not match filters defined for unencrypted traffic. IKE peers supporting unauthenticated IKE MUST pass all decrypted traffic through the same packet filters as plaintext traffic.
Existing IKEv2 DoS defenses (COOKIES per RFC 7296 Section 2.6) do not distinguish NULL-authenticated peers from legitimate peers; an attacker using NULL authentication is a fully legitimate IKE peer. Implementers must ensure no assumptions are made that IKE peers are 'friendly', 'trusted', or 'identifiable'.
If authenticated IKE sessions are possible for a given Traffic Selector range, unauthenticated IKE SHOULD NOT be allowed for that same range. When mixing authenticated and unauthenticated IKE with the same peer, policy rules should ensure the highest level of security is used.
When both peers use NULL authentication, the entire key exchange becomes unauthenticated and is vulnerable to active MITM attacks. Using an ID Type other than ID_NULL with NULL Authentication may also compromise client anonymity in the event of an active MITM attack.
With NULL authentication, logged ID payloads cannot be verified; any logging of such IDs should be clearly marked as 'untrusted' and accompanied by the remote IP address. Rate limiting of logging may be required to prevent resource exhaustion.