Jari, reading your contribution <http://www.IETF.ORG/mail-archive/web/ietf/current/msg60267.html>, a few point come to mind. I have not been actively participating in the discussion of the revised ipsecme charter, so this note gives me an opportunity to point to facts and arguments that could be taken into account in clarifying and further enhancing the revised charter. (1) EAP is asymmetric, and so far EAP support in IKEv2 only serves to authenticate the IKE initiator to the IKE responder. The IKE responder (most likly actually a server or a security gateway protecting the server) still authenticates to the client via other means, e.g. using a certificate. (That's almost fairly described in the draft charter.) The EAP integration with IKEv2 has been purposely designed for the the asymmetrical network access scenario and unidirectional authentication. (2) EAP adds additional round trips to the IKE handshake - most likeley two or more full round trips (depending on the EAP method), and thus it adds delay to the setup of the IKE SA. (That seems to miss from the reasoning in the draft charter.) Existing EAP methods contain elements and functionality not needed in IKE, e.g. because IKE performs SA negotiation on its own. (3) The target scenario is _symmetric_, i.e. it is indeterminate which peer will be in the role of IKE initiator and IKE responder, and this balance in role should preferably be reflected in the mutual authentication method(s) used. If you wanted to apply EAP authentication bidirectionally, either a second EAP exchange would have to be carried out (sequentially or in parallel), or there would be the need forcibly overlay bidirectionality to the EAP/IKEv2 integration. IMO, the latter would be very questionable from an architectural PoV. Note that in this model, IKEv2 would have to be changed in a non-trivial manner, since the 'embedding' of an EAP exchange into IKEv2 takes the proper sequencing of messages (payloads) and actions into account ('proper' from a cryptographical point-of-view). The interface to EAP would need to be changed to carry information about the state and outcome of authentication in both directions: both peers at a minimum need the two bits of information indicating "we have authenticated the peer" and "the peer has successfully authenticated us", and at different stages of the IKE handshake. In the former case (using two independent EAP exchanges with existimg EAP methods and the current interface between EAP and IKE, and initiated by the two peers "independently"), non-trivial changes to IKEv2 payload sequences and state machine would perhaps be needed as well, and a lot more messages would need to be exchanged. So it looks like using EAP for bidirectional authentication in IKE would make necessary a lot of changes, and result in a solution that could not be faster than in the case of unidirectional EAP authentication, with more round trips needed and greater latency. Note that existing EAP methods that make use of passwords and provide mutual authentication (EAP-PAK comes into mind) do so in an asymmetric manner -- still the client/server roles are defined (I apologize for not using EAP terminology in this context but designating higher level roles of the entities), and the (network access) server is authenticated by other means. Thus, EAP-PAK follows the same model as IKEv2 with EAP in general, includes functionality already provided by IKE on its own, and hence does not offer a solution for the problem under consideration. I'd appreciate some elaborations to this end in the revised charter in order to make the rationale behind that statement-of-direction more transparent to folks with less intimate knowledge of IKEv2 internals than typically found in the WG. (4) While I agree that EAP does not _need_ backend AAA, its design apparently is customized for such environments. EAP integration with IKEv2 was designed to leverage existing EAP implementations and infrastructure, where possible, and thus is also oriented towards such environments. (5) Existing wireless network deployments have to deal with asymmetrical cases, most importantly authentication between mobile clients and "the network", and network-internal symmetrical peer-to-peer authentication, e.g. between access routers for secure fast handover management. Whereas EAP seems appropriate (an indeed is used) for the former case, I've never heard that EAP would also be used, or there be a requirement to use it for the latter purpose -- even in other SDO / proprietary protocol stacks. However, you have much better insight into such deploymants and standards than I have; so please tell me if I'm wrong. (6) Last week, RFC 5683 has been published, which specifies the PAK (Password-Authenticated Key Diffie-Hellman Exchange) scheme for the IETF. At first glance, the one-and-half round-trips needed for PAK (three messages, A --> B --> A --> B ) seems well suited for instantiation/adaption and integration in the basic IKEv2 handshake. So there indeed seem to exist candidate building blocks already approved by other SDOs that promise a solution that matches well with the goals of efficiency and short delay. This should not be taken as a statement of endorsement of PAK for this purpose; I simply want to point out that there is recent evidence that this work item plan and the goals in the revised ipsecme charter seem to be sound. Kind regards, Alfred Hönes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@xxxxxxxxx | +------------------------+--------------------------------------------+ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf