Re: WG Review: Recharter of IP Security Maintenance and Extensions (ipsecme)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]