IKEv2 RFC7296 Section 2.16, provides overview of how IKEv2 is used with EAP. That section states the following when a different identity (IDi) is used in message 2 IKE_AUTH from initiator to responder, eg anonymous@realm, and realId@realm used in EAP identity response:

When the initiator authentication uses EAP, it is possible that the contents of the IDi payload is used only for Authentication, Authorization, and Accounting (AAA) routing purposes and selecting which EAP method to use. This value may be different from the identity authenticated by the EAP method. It is important that policy lookups and access control decisions use the actual authenticated identity. Often the EAP server is implemented in a separate AAA server that communicates with the IKEv2 responder. In this case, the authenticated identity, if different from that in the IDi payload, has to be sent from the AAA server to the IKEv2 responder.

This text is not clear about what identity that the initiator uses in Step 7 below in computing the AUTH:

   Initiator                         Responder
   HDR, SAi1, KEi, Ni  -->
                                <--  HDR, SAr1, KEr, Nr, [CERTREQ]
       [IDr,] SAi2,
       TSi, TSr}  -->
                                <--  HDR, SK {IDr, [CERT,] AUTH,
   HDR, SK {EAP}  -->
                                <--  HDR, SK {EAP (success)}
   HDR, SK {AUTH}  -->
                                <--  HDR, SK {AUTH, SAr2, TSi, TSr}

The AUTH data for initiator is derived as specified in Section 2.15

InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI 

where MACedIDforI is "value prf(SK_pi, IDi')" where IDi' is "entire ID payloads excluding the fixed header"

The question is whether IDi used in Step 7 (from initiator to responder: HDR SK {AUTH} -->) should be anonymous@realm (that is the IDi sent in message 3), or realId@realm (the identity provided by initiator in the EAP identity response.


1 Answer 1


The RFC clearly states that the IDi payload (without fixed header, also referred to as IDi') is the input for MACedIDForI, i.e.

RestOfInitIDPayload = IDType | RESERVED | InitIDData
MACedIDForI = prf(SK_pi, RestOfInitIDPayload)

And unless RFC 4739 is implemented, which enables multiple authentication exchanges each with their own identities and AUTH payloads, there is only a single IDi payload.

That there could be an EAP identity (or actually multiple as the optional EAP-Identity exchange could provide one, as could the actual EAP authentication exchange itself) isn't relevant at that point and they are never referred to as IDi. However, as section 2.16 specifies, the (final) EAP identity is relevant for other uses like authorization and policy checks.

  • $\begingroup$ Thank you for the answer. I tend to agree. However, the following text makes it a bit confusing. In Section 2.16 of RFC 7296, it states that MSK generated by EAP is the shared secret used for AUTH and then in Section 1.2 of the same RFC it states If either side uses a shared secret for authentication, the names in the ID payload MUST correspond to the key used to generate the AUTH payload. This could imply that the IDi in message 7 and the IDi' used should be realId@realm, or am I reading too much into the RFC. $\endgroup$
    – Irfan
    Commented Dec 23, 2022 at 1:56
  • $\begingroup$ You are (and you'd disagree with all existing IKEv2 implementations that implement EAP authentication ;-). While the MSK (if there is one, not all EAP methods are even key-generating) is used like a shared secret in terms of AUTH computation, authentication with "shared secret" (PSK) is something different and the ID payloads are the only identities in that case (how exactly an identity can correspond to a key I don't know exactly, but I guess the authors meant that they should be used to look up the key instead of e.g. the IP addresses that were used with IKEv1 in main mode). $\endgroup$
    – ecdsa
    Commented Dec 23, 2022 at 7:46
  • $\begingroup$ Also, with e.g. a key-generating method like EAP-TLS the peers are clearly not authenticated with a shared secret they have stored locally and look up, it's rather that the MSK is the shared output that can be derived from the certificate-authenticated TLS exchange. $\endgroup$
    – ecdsa
    Commented Dec 23, 2022 at 7:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.