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. >> 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