> -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@xxxxxxxxxxxx] > Sent: Monday, March 17, 2008 7:58 PM > To: Harald Tveit Alvestrand > Cc: Narayanan, Vidya; ietf@xxxxxxxx > Subject: Re: IETF Last Call on Walled Garden Standard for the Internet > > On 3/17/2008 7:23 PM, Harald Tveit Alvestrand wrote: > > Narayanan, Vidya skrev: > >> All said and done, here is what it boils down to - any > application of > >> EAP keying material to other services (using the term here > to include > >> things ranging from handoffs to mobility to L7 > applications) is only > >> feasible when those services are provided either by or through the > >> provider handling network access. It is also only feasible when > >> those services are only running over EAP-capable interfaces (well, > >> without horrible abominations, anyway). So, if a network access > >> provider requiring EAP is rolling out applications, I don't see a > >> good reason why the application cannot use keys coming out > of the EMSK. > >> > > The counterargument is, of course, that such coupling will put the > > network access provider into a privilleged position wrt providing > > those applications on his networks; in particular, any competitor > > wanting to deliver those same services (think Internet > telephony/Skype > > or > > video-on-demand/YouTube) will have to roll out his own > > authentication/authorization infrastrucure, and get users > to adopt it > > in addition to the one they already have - OR to beg > permission from > > the network owner to leverage his infrastructure. > > > > This violates the principle of "network neutrality"; you > could easily > > argue that this is a battle that should be fought in the courts of > > public opinion and the US legislature, not in the standards > > organizations, but traditionally, the IETF's participants has had > > strong opinions on this matter. > > Fair enough. Although, we already facilitate this with EAP > over IKEv2. > The new stuff is just optimization, as Jari noted. The > contention, at least between him and me is whether the > optimization is needed or not. > Jari also noted that such providers should be able to reuse the same credentials in EAP and the application; just that the key hierarchies should not have any inter-dependencies. This essentially gives the same level of control to the provider with respect to the applications as Harald notes, just doesn't allow the optimizations to happen. This seems like a false level of separation that we think we may achieve by maintaining an imaginary protocol boundary at the IETF. Recognizing that credential provisioning is an issue is a good step that in my mind by itself warrants this EMSK-based key hierarchy for meaningful usages. In fact, I'd argue that credential reuse by multiple protocols is a bad idea - we would be trading off cryptographically coordinated key derivations for a mechanism that has no control over disparate usages of the credentials with different algorithms and so on. In fact, credential provisioning issues (and avoiding credential reuse) is a far more compelling reason to allow the EAP-based keying hierarchy for layers above than the optimizations itself. Of course, the optimizations are much needed in some cases, but, that is not the sole reason. - Vidya > >> Our role at the IETF should be in defining the > applicability of using > >> such key material such that readers understand that this does not > >> work when the application provider is independent of the network > >> access provider or when the application runs over > interfaces that do > >> not do EAP. And, I believe our role ends there. > >> > > I believe I agree with this statement, mostly. > >> Jari wrote "Tighten up the language in the hokey spec to not allow > >> application keying, and we're done" and I don't believe we > are. We > >> can do that and just sit back and watch non-compliant key > hierarchies > >> propping up everywhere (and worry about interoperating with those > >> when we write our next spec) or do the responsible thing, which > >> would be to clearly define the applicability, along with > providing an > >> interoperable means of defining the key hierarchy for those usages > >> that want to/can use it. > > If usages exist that we find reasonable at all (that is, if > we define > > ANY extensible hierarchy), I think experience shows that we'll have > > trouble achieving control by restricting the registration > procedure - > > the early years of MIME is the poster child for that. > > > > While I have my doubts as to how much effect we have on the > world by > > explaining why a particular thing is > stupid/wrong/offensive/immoral, I > > have even more doubts about the effect of restricting > registration as > > a controlling tool. > > > > The anecdote I'm reminded of is one from the Norwegian army, just > > before the German invasion of 1940.... > > > > Senior Officer: "And if the country is invaded, Lieutenant, > how would > > you prevent the enemy from using the railroad system to > move troops?" > > Junior Officer: "Burn all the tickets, SIR!" > > Funny! :) Applicability statements and strong applicability > statements come to mind! > > regards, > Lakshminath > > > > Harald > > > > > > _______________________________________________ > > IETF mailing list > > IETF@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/ietf > > > _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf