I think Vidya has a good point. My opinion is that, bootstrapping protocols from long-term credentials used for network access authentication is not such a bad idea, but we just do not know yet the best way to realize it: http://user.informatik.uni-goettingen.de/~mobiarch/2007/slides/mobiarch07-panel-YoshiroOhba.pdf Yoshihiro Ohba On Mon, Mar 17, 2008 at 09:39:04PM -0700, Narayanan, Vidya wrote: > > > > -----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 > _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf