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.
> 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!"
Harald
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf