Hi Nico, On Tue, April 12, 2011 7:38 am, Nico Williams wrote: > I don't get the hostility to pluggable authentication architectures. > Why on Earth should any of us dictate to users what kinds of > authentication infrastructures they must have?
We do that when we ship support for some authentication credential in product. Whether it's a particular EAP method or a TLS ciphersuite or support for particular authentication method in IKE. > For far too long we've had too many protocols with completely disjoint > authentication technology support, leading to customers having to > deploy many authentication infrastructures. Some protocols only > handle PKIX well. Others only handle Kerberos well. Others only > handle AAA well. Yet others have ad-hoc authentication systems. > > Forcing customers to deploy multiple authentication infrastructures > means forcing them to setup expensive synchronization for expensive > systems that they shouldn't need. How is that a good thing? That's exactly what this pluggable stuff gets us. GSS, EAP, RADIUS, and how is authentication happening? Well that's not really decided yet. But we have these multiple, pluggable, authentication infrastructures that you have to support before you can even get to the point of thinking of your authentication credential. > The *only* way to put a stop to this madness is to make all these > protocols pluggable. Actually I think that is the madness. If the EAP in TLS plan goes forward we could have some deployment of EAP-TLS with the TLS ciphersuite doing EAP and the EAP method used for that is IKEv2 and using EAP-only as the authentication method and EAP-GSS inside that! > Some of us have been trying to do so for a > while. We have the following successes to point to: > > - SASL/GS2 -- a new bridge for using GSS-API mechanisms in SASL > applications. > - SSHv2 support for GSS-API-based authentication. > - Channel binding (RFCs 5056 and 5929), which allows for composition > of security technologies. > - IKEv2 and KINK (which altogether allow IPsec to support the use of > PKIX, Kerberos and EAP for end-point authentication). > - ABFAB WG -- a WG working on standardizing an EAP-based, > federation-capable GSS-API mechanism. I count this as a success > because ABFAB is quite far along. I think I'm more in the camp of counting ABFAB as an abomination. Treating authentication protocols that have been designed for a particular purpose as some generic mechanism results in much insecurity in the deployed world (the "let's use TLS" instinct is widespread and it is seldom deployed correctly. Making them totally pluggable can only make it worse. regards, Dan. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
