On Tue, Apr 12, 2011 at 8:29 AM, Yoav Nir <y...@checkpoint.com> wrote: > I have mixed feelings about this. It's better than all four of those drafts > advancing separately. OTOH this plug-innable architecture is pretty much > admitting defeat. It sets us up to have a situation like EAP, with lots of > different methods, and no guide to implementers as to which methods to > implement.
Plugin architecture != no guidance as to required to implement mechanisms/methods. Besides, one of the nice things about plugin architectures is that third parties can fill in voids when specific methods/mechanisms go unimplemented. > But I guess it's the lesser evil. 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? 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? The *only* way to put a stop to this madness is to make all these protocols pluggable. 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. Other work items in progress that should help round up this picture: - PKU2U (a PKIX-based GSS-API mechanism). - Additional GSS mechanisms being proposed at ABFAB and/or KITTEN (there's a SAML-based one and an OAuth-based one). - draft-williams-tls-sasl-opt. We have quite a few protocols that support SASL or the GSS-API straight out: - SASL application protocols: LDAP, IMAP, SMTP/SUBMIT, ... - GSS application protocols: RPCSEC_GSS/NFSv4, DNS (GSS-TSIG), SSHv2, FTP, ... We also have protocols that only support PKIX well and everything else in a half-hearted way, if at all (TLS, I'm looking at you). Please, let's put an end to the madness and adopt a pluggable approach to authentication (being careful to ensure channel binding to the actual security layers whenever the authentication facility's security layers are not used or when it lacks them). Nico PS: "Security layer" is a term from SASL meaning "the layer that provides integrity and, optionally, confidentiality protection to application data. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
