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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf