An Extension for EAP-Only Authentication in IKEv2
updates
- rfc-5996 — Internet Key Exchange Protocol Version 2 (IKEv2)
Extracted elements (24)
IKEv2 omits the EAP Identity Request/Response pair (see RFC 5996 Section 3.16), using the IKE ID payload instead to route AAA messages and select EAP methods. This means the ID payload identity is not directly authenticated by the EAP method itself.
PKI deployment (with trust anchor management on all supplicants) is often unrealistic in practice, making public key signature authentication no more secure than a self-signed certificate. Mutually authenticating EAP methods alone can provide sufficient security, as demonstrated by IEEE 802.11i deployments using EAP without any PKI.
The alternative of using unauthenticated public keys in the AUTH payload (Appendix A.2) was rejected because EAP method selection cannot account for incomplete certificate validation, creating a hidden security gap.
The extension uses an explicit notification (EAP_ONLY_AUTHENTICATION) from the initiator rather than silently ignoring the responder's AUTH payload (Appendix A.1 alternative). This allows the EAP method selection to take the authentication mode into account and avoids relying on undefined behavior.
The proposal to omit the IKEv2 Diffie-Hellman exchange and rely solely on EAP-derived session keys (Appendix A.3) was rejected because it would require designing a completely new protocol and the only benefit — saving g^xy computation — is insufficient justification.
An IKE SA established with EAP-only authentication can be resumed using the IKEv2 Session Resumption mechanism (RFC 5723). However, session resumption does not change the authentication method, so the EAP_ONLY_AUTHENTICATION notification MUST NOT be sent during the resumed IKE_AUTH exchange.
Channel binding support varies among the approved EAP methods. EAP-AKA, EAP-AKA', EAP-GPSK, EAP-EKE, EAP-PAX, and EAP-POTP support channel binding and are preferred in deployments requiring protection against gateway impersonation; EAP-SIM, EAP-pwd, EAP-SAKE, EAP-SRP, EAP-TLS, EAP-FAST, and EAP-TTLS do not.
AAA proxies between the IKEv2 gateway and the backend AAA server MUST be trusted for secure operation and therefore SHOULD be avoided when possible.
Both the initiator and responder MUST verify that the EAP method actually used provided mutual authentication and established a shared secret key.
During the IKE_AUTH exchange of a resumed session (RFC 5723), this extension MUST NOT be sent by the initiator, since session resumption does not change the authentication method.
EAP methods that do not provide mutual authentication or establish a shared secret key MUST NOT be used with the EAP-only authentication modification, since the IKEv2 SA authentication depends on the EAP-generated AUTH payload.
EAP methods used with this extension MUST provide: (1) mutual authentication of the peers, (2) key generation, and (3) resistance to dictionary attacks.
If the responder does not support or does not use the EAP_ONLY_AUTHENTICATION notification, it includes the AUTH payload in message 4, and the initiator MUST verify that payload and any associated certificates per RFC 4306.
The AUTH payloads sent after EAP Success MUST use the EAP-generated key and MUST NOT use SK_pi or SK_pr (as defined in RFC 5996 Section 2.15).
When receiving message 4, the initiator MUST verify that the proposed EAP method is allowed by this specification (i.e., provides mutual authentication, key agreement, and dictionary-attack resistance), and MUST abort the protocol immediately otherwise.
IKEv2 provides initiator identity confidentiality against passive attackers but not active attackers, and EAP-only does not improve this. Responder identity confidentiality is also weakened: without public-key responder auth, protection depends entirely on whether the chosen EAP method reveals the server identity first.
In the EAP-only authentication exchange, the responder omits both the public-key-based AUTH payload and CERT payloads from message 4 (first IKE_AUTH response), sending only IDr and the initial EAP Request. AUTH payloads from both sides appear only after EAP Success.
The EAP_ONLY_AUTHENTICATION notification payload (type 16417) is sent by the initiator in message 3 (first IKE_AUTH request) to signal that it does not wish to use public-key-based responder authentication. The Protocol ID and SPI size fields are set to zero, and there is no additional data.
This document registers a new IKEv2 Notification Payload type, EAP_ONLY_AUTHENTICATION, assigned type number 16417 from the 'Status Types' range in the IKEv2 Notify Message Types registry.
Each peer sends two identities: one in the IKE ID payload (used for routing AAA messages and selecting EAP types) and one inside the EAP method. Only the EAP-internal identity is directly authenticated; IPsec policy decisions must be based on the authenticated identity.
The IKEv2 SA is not authenticated by running an EAP conversation alone; the crucial step is the AUTH payload derived from the EAP-generated key. EAP methods that do not establish such a key are therefore prohibited with this extension.
Until the AUTH payload has been received and verified, a man-in-the-middle can change the KEi/KEr payloads and eavesdrop or modify the EAP payloads, even though they are encrypted and integrity-protected by SK_e/SK_a.
When a backend AAA server is used, EAP methods without channel binding leave the client able to verify only that it is talking to 'some gateway trusted by the home AAA server,' not a specific one. A compromised gateway can impersonate any other gateway until the compromise is revoked — the 'Lying NAS Problem.'
EAP_ONLY_AUTHENTICATION is a Notify payload with type number 16417, drawn from the IKEv2 'Status Types' range. Protocol ID field is zero, SPI size is zero, and no additional notification data follows.