On Tue, Apr 12, 2011 at 2:39 PM, Dan Harkins <dhark...@lounge.org> wrote: > 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.
I strongly disagree with this. I mean, I agree with not wanting to implement N>1 or N>2 mechanisms, but that's the beauty of pluggable frameworks: you publish a plugin SPI and then you can let third parties ship the plugins that you don't care about. The only other alternative that works for customers is "protocol transition", which I'll admit I like as well. Think of SACRED, kx509, PKINIT, and so on. Each of these allows you to use one credential of one type to obtain a temporary credential of another type. > 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). I'm quite skeptical that you (the IPsec WG in this case) can design a pluggable framework that will only be used for password-based authentication and which will not grow to be yet another pluggable framework with all the issues you dislike (including the need to implement N>1 mechanisms). And yes, we agree that yet another pluggable framework would be bad. I fail to see how Tero's proposal makes any headway. Customers who have and want to use AAA will not be able to use it, near as I can tell, and if you undertake to make it possible to use AAA in Tero's proposal then you'll be quickly approximating EAP re-invention. Thus my skepticism. It's not pessimism because the obvious solution is to use an off-the-shelf solution. > 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. Which I-Ds are in last call?? _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
