> -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On > Behalf Of Narayanan, Vidya > Sent: Monday, March 17, 2008 6:54 PM > To: ietf@xxxxxxxx > Cc: aboba@xxxxxxxxxxxxx > 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. Right. > > 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. Right. > > 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. Exactly. > > 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. Exactly. > > 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. Exactly. > > Vidya > _______________________________________________ > IETF mailing list > IETF@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf