[Top] [All Lists]

Re: IETF Last Call on Walled Garden Standard for the Internet

2008-03-19 06:34:50
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:

Yoshihiro Ohba

On Mon, Mar 17, 2008 at 09:39:04PM -0700, Narayanan, Vidya wrote:

-----Original Message-----
From: Lakshminath Dondeti [mailto:ldondeti(_at_)qualcomm(_dot_)com] 
Sent: Monday, March 17, 2008 7:58 PM
To: Harald Tveit Alvestrand
Cc: Narayanan, Vidya; ietf(_at_)ietf(_dot_)org
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 
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

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



IETF mailing list

IETF mailing list

IETF mailing list

<Prev in Thread] Current Thread [Next in Thread>