|
I agree with Dan. The added complexity seems to have very little if any benefit. Moreover, the existing IKEv2/EAP design has some very desirable cryptographic properties (such as the ability to support PFS even in situations where weak EAP methods are used) that could go by the wayside. Dan Harkins said: > > Hi Jari, > > I don't believe the simpler solution will increase code size or > complexity when compared to the the reuse EAP solution. In fact, > it will be less on both counts. > > In both cases the core key exchange will have to be implemented > and in both cases some configuration glue will be needed. But in the > reuse EAP solution there is the added code to implement an EAP client > and its accompanying state machine, which no IKEv2 gateway currently > needs to implement. In addition, a true EAP server, and accompanying > state machine, will need to be implemented and IKEv2 gateways will > no longer get away with just being a "pass through authenticator". > The reuse EAP solution will also have to implement some new > fragmentation/reassembly code since EAP methods (like ones supporting > "weak" shared secrets) have to roll-their-own. The reuse EAP solution > will also have to implement other, unneeded, exchanges (which is why the > roundtrips/overhead are greater). When you compare the two, it really > is obvious that trying to use EAP in this case increases code size and > complexity versus just doing the exchange as part of IKE. > > EAP is attractive because it provides a generic authentication solution, > but here there is really only one type of authentication to do-- using a > "weak" shared secret. It is also attractive because authentication can be > centralized with one server serving many network access points. But in > this case both sides must have possession of the shared secret and both > sides must be capable of initiating the exchange so use of a centralized > server is not possible. So all of the attractive features of EAP do not > apply and we're left with the undesirable features of EAP-- duplicate > identity exchanges, yet more fragmentation/reassembly code, and > pointless overhead. > > I don't think it's better architecturally to reuse EAP in this situation. > EAP is a network access protocol where one side attempts to obtain network > access from another. There are strict roles played in EAP. In this > situation there are no roles and creating a host-to-host SA or network- > to-network SA is not really the same thing as obtaining network access. > > There are some things that EAP is not appropriate for and this is > one of them. > > regards, > > Dan. > > On Fri, February 19, 2010 5:39 am, Jari Arkko wrote: > > Pasi, > > > > (Adding the working group mailing list to the discussion; previous > > discussion has been at ietf@xxxxxxxxx) > > > >> You're right that implementing a "weak shared secret" EAP method (both > >> the EAP peer and EAP server roles) on both IPsec nodes, combined with > >> the "EAP mutual authentication" work item (also in the new charter) > >> could be used in this situation, and would result in roughly the same > >> functionality (perhaps with slightly more roundtrips/other overhead -- > >> but that's probably not a critical factor here). > >> > > > > OK. And yes, I agree about the significance of roundtrips. > > > >> NEW: > >> However, user-configured shared secrets are still useful for many > >> other IPsec scenarios, such as authentication between two servers > >> or routers. These scenarios are usually symmetric: both peers know > >> the shared secret, no back-end authentication servers are involved, > >> and either peer can initiate an IKEv2 SA. While it would be > >> possible to use EAP in such situations (by having both peers > >> implement both the EAP peer and the EAP server roles of an EAP > >> method intended for "weak" shared secrets) with the mutual > >> EAP-based authentication work item (above), a simpler solution may > >> be desirable in many situations. > >> > > > > This formulation is better than what we had previously. I can live with > > this. > > > > But for the record, I am still surprised that I am the only one worried > > about this. In my view this additional solution, while perhaps simpler > > on its own, will increase code size and complexity for most > > implementations. For instance, a device that serves remote access > > clients has to implement at least parts of EAP. To support > > gateway-gateway weak secrets it now has to add support for another, > > completely different authentication mode and associated configuration > > mechanisms & policies. Architecturally, it would be better to rely on > > few general solutions than to build special case "simpler" solutions > > that taken together, actually become more complex. Not to mention the > > impact on interoperability. > > > > Jari > > > > _______________________________________________ > > Ietf mailing list > > Ietf@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/ietf > > > > > > > ------------------------------ > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > > > End of Ietf Digest, Vol 21, Issue 38 > ************************************ |
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf