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

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(_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

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(_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

_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf