IKEv2 with EAP and use of anonymous identity

Irfan

12/21/23, 2:58 AM

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]
   HDR, SK {IDi, [CERTREQ,]
       [IDr,] SAi2,
       TSi, TSr}  -->
                                <--  HDR, SK {IDr, [CERT,] AUTH,
                                         EAP}
   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 + 0

data-privacy

Score:0

Crypto

ecdsa

12/21/23, 11:00 AM

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.

+ 3

Irfan

12/23/23, 1:56 AM

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.

ecdsa

12/23/23, 7:46 AM

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).

ecdsa

12/23/23, 7:48 AM

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.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: IKEv2 with EAP and use of anonymous identity

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.