On Tue, Apr 12, 2011 at 3:18 PM, Dan Harkins <[email protected]> wrote: > On Tue, April 12, 2011 1:00 pm, Nico Williams wrote: >> 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. > > See that's the whole thing! You can't use AAA because IKE is not a > client-server protocol designed for network access (although some people > try to use it for that). Each side can initiate to the other so each > side needs access to the credential and since there's no way for a AAA > server to initiate EAP to another AAA server you can't use AAA. And if > you can't use AAA then what's the point of using EAP? There isn't one! > It's a pointless encapsulation that increases the number of messages and > invites insecure misuse of IKE. I fail to see any value that a pluggable > authentication framework adds. > > (EAP re-invention might be a good idea. Maybe someone can make it so > a self-described authentication protocol has way of learning an identity > that is useful for authentication purposes. And if a message can get big > enough to be fragmented then maybe defining fragmentation/reassembly > might be a good idea too. Both of those tend to get reinvented with each > EAP method that needs them-- ggrrrrr).
I was just about to say the same thing regarding EAP re-invention :) I'd just neatly side-step the whole issue by using the GSS-API. Why? Because: a) you PAKEs are easy to specify as GSS-API mechanisms, so going the GSS way doesn't hurt, b) the GSS-API has an abstract API, which will lead to better PAKE mechanism design (e.g., regarding principal naming) and also better code design (because the GSS pattern is eminently reusable), c) if anyone wants AAA you point them to the ABFAB WG's work (and, if you must, hold your nose). Tell me: why not GSS? Oh, and by the way, I can prove that it's fairly easy to specify a GSS PAKE: just go read RFC5802, which defines one (SCRAM -- not a ZKPP, but good enough for you to use as a guide). SCRAM was designed to be specified as simply as possible, with as little reference to the GSS-API as possible, and with such references as boiler-plate as possible. I believe we succeeded. Moreover, SCRAM is both, a SASL and GSS mechanism, and this duality was not difficult to produce because the SASL->GSS bridge was also designed to be as simple and unobstrusive as possible. I urge (beg?) you to read RFC5802 _then_ RFC5801. You should find that RFC5802 (SCRAM) is comprehensible without much reference to GSS-API and SASL concepts, while RFC5801 (SASL/GS2) requires knowledge of GSS concepts. You don't need to implement RFC5801, not even RFC4422 (SASL) in order to implement SCRAM! That's the best part. I'm hoping that you'll agree with me that the SCRAM approach, substituting any PAKE's guts into it, is a good one. >>> 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?? > > The three PAKE I-Ds: > > - draft-harkins-ipsecme-spsk-auth > - draft-kuegler-ipsecme-pace-ikev2 > - draft-shin-augmented-pake Thanks. I'll take a look. I bet these can all be very easily turned into SASL and GSS mechanisms ala SCRAM without doing too much violence to them. Nico -- _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
