Hi Nico, On Tue, April 12, 2011 11:53 am, Nico Williams wrote: > 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.)
I said _support_ some credential, not ship the credential. If your product supports EAP-SIM then what I'm saying is you are "dictating to users what kind of authentication infrastructure they must have", namely one that supports SIM cards. > 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? No no, not at all. Robust and misuse resistance is my proposal. Using the best technique directly in the protocol for the chosen credential. If you want to use certificates then use a certificates in the exchange. If you want to use a password then use a password in the exchange. But "lets use X" where X is some pluggable framework is definitely not my proposal. I proposed adding PAKE to IKE because people use passwords for authentication and that is rife with misuse. "Why not just use EAP?" was the question. Why not just use this pluggable authentication method? Well two reasons: 1) it's a pointless encapsulation that also increases the number of rounds; and 2) because it's pluggability encourages misuse (i.e. do EAP-MSCHAPv2 in EAP-only IKE). I'm a bit undecided on Tero's proposal. I tend to get in trouble when I ascribe motivation to things people do so I won't do that, but as someone who actually implements the protocols we design here I think having n protocols, where n > 1, to solve a single problem with no clear "winner" means that for interoperability reasons I have to implement all n and that's a shame. Since Tero actually implements these protocols too I think he might share that concern. It might be possible to get the authors of the competing drafts to rely on a common method of identifying the intent of the initiator (currently PACE uses a Notify and SPSK uses the mandatory bit) and ensure that their protocols all look the same-- send a blob, get a blob, send another blob, get another blob-- and to mix results from PAKE exchange into results of the D-H exchange in a uniform manner and we might get the equivalent of what he's proposing without Yet Another Pluggable Architecture (which I guess we both agree would be not-so-good). Now the drafts are in LC. Maybe a few comments could get the authors to align their drafts so they look architecturally identical while implementing different exchanges. regards, Dan. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
