skip to content

In IKEv2 remote access, how does EAP authenticate the user inside IKE_AUTH, and why must the gateway still authenticate with a signature?

level: middleimportance: should knowfreq 13%

answer

  1. users have passwords, not certificates
  2. the missing AUTH payload
  3. extra IKE_AUTH round trips
  4. MSK binds EAP to the IKE SA
  5. EAP is often one-way

basics

~20 s

The client omits AUTH from its first IKE_AUTH message; the gateway answers with its certificate, signed AUTH and an EAP request; the method runs over extra IKE_AUTH round trips; both sides finish with AUTH keyed from the EAP MSK.

solid answer

~40 s

An IKEv2 initiator asks for EAP by sending `IDi` without an `AUTH` payload in its first `IKE_AUTH` message. The gateway replies with `IDr`, usually `CERT`, its own `AUTH` and an `EAP` payload, and holds back `SAr2`, `TSi` and `TSr`. The EAP method — password, token or SIM-based — then runs over further `IKE_AUTH` exchanges until the gateway sends EAP Success, and both sides send a final `AUTH` computed from the EAP method's MSK, which binds the EAP run to this IKE SA; the last message carries the Child SA. RFC 7296 requires the gateway to authenticate with a public-key signature because EAP methods are typically one-way and may not authenticate the server at all, so the client must know whom it is talking to before it runs one.

go deeper

for a junior

Recall that IKEv2 can authenticate a remote-access user with EAP, carrying passwords or tokens, while the gateway still proves itself with a certificate.

for a middle

Walk the eight-message exchange: no AUTH in message 3, the gateway's signed AUTH and EAP request, the method's round trips, EAP Success, and MSK-keyed AUTH payloads.

for a senior

Explain the defensive rules: responder signature as a MUST because EAP may be one-way, key-generating methods to bind EAP to the IKE SA, and authorisation on the authenticated identity.

for a principal

Weigh the remote-access authentication design: gateway certificate lifecycle and client trust anchors, AAA dependency and its failure mode, and which EAP methods the estate permits.

## Why EAP appears in IKEv2 A site-to-site gateway can hold a certificate or a pre-shared key. A remote-access user usually has a password, a one-time code, a smart card or a mobile subscriber identity instead. IKEv2 (RFC 7296) therefore supports, besides public-key signatures and shared secrets, the **Extensible Authentication Protocol (EAP)**: a framework that carries many authentication **methods** without IKE needing to know each one. RFC 7296 runs EAP as **additional `IKE_AUTH` exchanges** that MUST complete before the IKE SA exists. ## The exchange With a minimal EAP method the setup looks like this: | Message | Direction | Contents | |---|---|---| | 1-2 | Both | `IKE_SA_INIT`: proposals, key exchange, nonces | | 3 | Client to gateway | `IDi`, `SAi2`, `TSi`, `TSr` — and **no `AUTH`** | | 4 | Gateway to client | `IDr`, `CERT`, `AUTH` (signature), `EAP` request | | 5 | Client to gateway | `EAP` response | | 6 | Gateway to client | `EAP` Success | | 7 | Client to gateway | `AUTH` keyed from the MSK | | 8 | Gateway to client | `AUTH`, `SAr2`, `TSi`, `TSr` | Leaving `AUTH` out of message 3 is the signal: the client has *declared* an identity but not proven it. A real method may need many more round trips than this minimal one, and an initiator must be able to extend the exchange to at least ten `IKE_AUTH` exchanges. The gateway MUST end the method with an EAP Success or an EAP Failure, and may send Failure at any point. Remote-access clients usually also put a configuration request, `CP(CFG_REQUEST)`, in the message that carries `SAi2`, and receive their inner address in the `CP(CFG_REPLY)` that accompanies `SAr2`. ## Why the gateway must still sign RFC 7296 is explicit: EAP methods are typically **asymmetric** — designed for a user proving itself to a server — and **may not be mutual**. So EAP authenticates the initiator to the responder, and it **MUST** be used together with **public-key-signature authentication of the responder**. In practice: 1. In message 4 the client receives the gateway's certificate and a signature over the exchange. 2. It validates them against its trust anchors and the expected gateway name before answering the EAP request. 3. Only then does it run a method that may reveal something about the user's credentials. Without that step, a client could complete EAP with an impostor gateway — exactly the server-impersonation risk the requirement exists to close. ## Binding EAP to the IKE SA The final `AUTH` payloads are what tie the EAP conversation to *this* IKE SA: - For EAP methods that generate a shared key, both sides MUST use that key — the field the EAP specification calls the **MSK** — to compute the `AUTH` payloads in messages 7 and 8, and the MSK MUST NOT be used for anything else. - Methods that do not generate a key **SHOULD NOT** be used; RFC 7296 points to man-in-the-middle attacks against them. If one is used anyway, the `AUTH` payloads are computed with `SK_pi` and `SK_pr`. A defender's rule of thumb follows: choose key-generating methods, and treat a non-key-generating one as a finding. ## Identity and the AAA server - The EAP server often lives in a separate **AAA server** the gateway talks to. - `IDi` may serve only to route the request to that server and pick the method; it **may differ** from the identity EAP actually authenticates. - RFC 7296 says policy lookups and access-control decisions must use the **authenticated** identity, which the AAA server must hand back to the gateway when it differs. ## What interviewers listen for - the missing `AUTH` as the trigger, and the extra `IKE_AUTH` round trips; - the server-side signature as a MUST, with the reason: EAP is often one-way; - the MSK-keyed `AUTH` as the binding, and why non-key-generating methods are discouraged; - policy keyed on the EAP-authenticated identity, not the claimed `IDi`.

  • In IKEv2 with EAP, why should the gateway's policy use the EAP-authenticated identity rather than IDi?
    IDi is only what the client claimed; with EAP it may be used just to route the request to the AAA server and choose a method, and it can differ from the identity the method actually proved. RFC 7296 requires policy lookups and access decisions to use the authenticated identity, which the AAA server returns to the gateway.
  • What does an IKEv2 remote-access client lose if it runs an EAP method that generates no shared key?
    The cryptographic binding between the EAP run and the IKE SA. With a key-generating method, the final AUTH payloads are computed from the MSK, so an attacker relaying the EAP conversation cannot complete them. Without one, AUTH falls back to SK_pi and SK_pr, and RFC 7296 warns such methods are exposed to man-in-the-middle attacks.

saying these in an interview costs you the question

  • With EAP, neither side of IKEv2 needs a certificate.
  • EAP is negotiated as a transform in the IKE_SA_INIT proposal.
  • The EAP exchange runs in cleartext before the IKE SA is encrypted.
  • Any EAP method is fine, whether or not it produces a key.
  • The gateway should authorise the user by the IDi it received.