On Tue, Apr 12, 2011 at 1:01 PM, Dan Harkins <dhark...@lounge.org> wrote: > 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.
Who ships credentials? Customers control credentials, not vendors. (The only exception is default trust anchors, which are a sort of credential.) >> 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. Pluggable authentication frameworks are NOT the cause of multiplicity of authentication infrastructures. You might have argued that if we'd only ever had one True authentication mechanism then pluggable frameworks would have been bad, but a) you didn't so argue, b) that was never the case anyways (SASL mechanisms came first, the framework later, same for EAP, for example, and Kerberos and PKIX are contemporaries, and so on). Reading into what you write above you seem to think that it's not possible to abstract authentication sufficiently well (for IKEv2's purposes, in this case). I disagree. I'll grant only that there's only one framework that has gone any of the distance to properly abstracting authentication, and that's the GSS-API (which I gather you revile, but preferably you could explain in detail). >> 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! I'm not fond of the proliferation of authentication frameworks. If you thought I was, you misunderstood. I'd rather see one framework win (which is why we did the SASL/GS2 bridge to GSS-API mechanisms). We have all the frameworks that we have because historically various groups created them independently, often as a generalization of the reality that various protocols were pluggable but without a generic framework (this is true of EAP and SASL). And here Tero is proposing yet another pluggable framework. Tero's proposal: create a new pluggable authentication framework. My proposal: pick an off-the-shelf framework. Your proposal: ?? Force a single authentication mechanism on all? But you know what will result: eventually others will add alternatives, and then someone will say "hey! I know, we can generalize what we have and create a framework", and then we've repeated history, and badly at that. What am I missing? I mean, I get the sentiment and I sympathize (I wish we had had exactly one pluggable authentication framework, not N>3 as we do), I do. We need stronger arguments either way, however. >> 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. I'm not really fond of some aspects of it. I strongly dislike certain aspects of EAP, AAA, and SAML -- all major components of ABFAB. But it fills a void. And it will work with the infrastructures that people have. I don't see anyone coming forth with better alternatives. In any case, the ABFAB WG's mechanism fits in an existing framework, so there are only two possible outcomes: it gets adopted or it doesn't. Compare to the possible outcomes if we create new frameworks: likely more fragmentation of authentication mechanism support, leading to more redundant authentication infrastructure deployment or else market failure for the framework and the protocol consuming it. > 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. "Results in much insecurity" is a strong assertion and requires something a lot more concrete than pointing at TLS. The fact that TLS is used in weak ways is not really a result of having pluggable authentication systems -- I'd say it's exactly the reverse because the lack of suitable password-based authentication mechanisms meant it was easiest to just send passwords over some secure channel, and that channel could only really be secured with a PKI, all the while PKI could not scale to Internet scale, which meant we ended up with what we have. Whereas if we'd had composeable authentication mechanisms we could have had channel binding to TLS eons ago and saved ourselves a lot of trouble. The fact is that technology grows organically. When you analyze the failures of the past you have to be careful to find the right lessons. Here we see what would be a new branch of organic growth, but in this case we really can and must apply lessons from the past, one of which is that we shouldn't re-invent wheels willy nilly. Nico -- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
