[Top] [All Lists]

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

2008-03-18 15:23:53

-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org 
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On
Behalf Of Narayanan, Vidya
Sent: Monday, March 17, 2008 6:54 PM
To: ietf(_at_)ietf(_dot_)org
Cc: aboba(_at_)internaut(_dot_)com
Subject: RE: IETF Last Call on Walled Garden Standard for the Internet

As much fun as I've had in catching up with this thread, I'd
like to remind all of us that we, at the IETF, do not dictate
the way systems get built in the real world.  There are SDOs
that have gone ahead and defined their own hierarchies out of
the MSK and EMSK for various usages at higher layers.  And, I
use the term "usage" here, since "application"
seems unclear in terms of layering - for the purposes of this
document, "application" refers to anything that may be able
to use EAP keying material and not literally Layer 7.


Having said that, I find it interesting that some people here
find it okay for Mobile IP to use EAP keying material, but
not other applications.  I have to deduce that this is
because the term "applications" to many of us reminds us of
real applications, rather than applications of the keying
material.  I don't see why the argument that using EAP-based
keying material for applications would hinder them running
over non-EAP capable interfaces would not apply to Mobile IP.
Mobile IP is as much decoupled from a specific interface as
any application is - so, does that mean it is okay to not be
able to provide mobility across non-EAP capable interfaces
using Mobile IP?  That would certainly defeat the purpose of
the protocol!  Not to say that Mobile IP is THE solution to
mobility, but let's save that discussion for another day.


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.


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.


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.


IETF mailing list

IETF mailing list

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