Yoav Nir writes: > > 0) Overall: A couple of folks that I mentioned this to asked: is anybody > > really doing ERP? So I'm just curious if they are. This obviously > > non-blocking. > > My guess is that it is not widely deployed, because 802.1x is for > now not widely deployed. EAP is used in some other contexts, like > L2TP VPN clients and cable modem/ADSL dialers, but those don't tend > to need support for roaming.
EAP-RP also got just added to the IEEE 802.11ai (fast initial link setup) specification framework document, so support for it should be coming to the 802.11 networks in the future. That might allow things like moving from the company WLAN to the VPN over 3G or similar. On the other hand you might still want to run VPN over the WLAN too... > > 1) General: In case people missed it, the first EAP message for ERX is > > moved to the initial IKE_AUTH request. I haven't seen any objections to > > this but I'd like to make sure implementers are okay with this!? > > > > Maybe it's splitting hairs but could you do the following to maintain > > architectural integrity/purity (i.e., not mix them): > > > > first request --> EAP(EAP_Initiate/Re-auth), > > > > be this: > > > > first request --> N[EAP(EAP_Initiate/Re-auth)], > > > > I guess you could do the same thing for the first response. > > The responder has indicated support for ERX in the Initial exchange > response, so it is expecting to get an EAP message in the first > IKE_AUTH request. I guess architectural integrity is a matter of > taste, but to me it seems that EAP messages should go in EAP > payloads rather than Notify payloads. I agree on that. We have EAP payload to transmit EAP payloads and we should keep that for it... I do not see any problems having EAP payload in the first IKE_AUTH request, as it is negotiated beforehand. I.e. server who did send N(ERX_SUPPORTED) do know how to process it there. > > 12) s5: I think you did a good job explaining protecting the clients > > identity. Can you add some more text about exposing the servers > > identity first and why you don't think it's a problem? > > The KeyName-NAI TLV sent in the IDi payload should be meaningful > enough to the Authenticator to be able to look up the true identity > of the client, so here, as in regular IKE, the initiator goes first. > It's true that for an active MitM, only the server reveals its > identity, as opposed to both client and server, but that is a good > thing, no? I assume you mean that the client ID that is releaved to the active MitM attacker is that ephemeral username, so it is no use for attacker? I assume that ephemeral username is still sent in the IKE EAP packet without any other encryption than normal IKEv2 packet encryption, thus it is visible to the active MitM attacker. > How about: > With this variant of the IKEv2 protocol, the initiator never sends its > identity on the wire, while the server does. An active attacker could > get the server identity from the exchange, but not the user identity. > In regular IKE, both the user and gateway identities are exposed to an > active attacker. I would replace /its identity on the wire/its real identity on the wire (only ephemeral identity is transmitted)/. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
