Hi Dave, Thanks for singling out my response. I am choosing to feel good about it:) Your point about the need for an API is really a good one that nobody is discussing in this lengthy thread and the other thread going on in Hokey. I alluded to it several times in EAP WG list, here and on hokey list. Yes, the fact that EMSK is not to be exported, is a scream in the forest, well guess what, For a while people wanted to even throw EMSK cache away, so we managed to get that out of the system:) Now, hokey and others want to use EMSK to generate usage specific root keys (USRK). Once those specs are out, implementers must implement EMSK and some sort of API as follows:
If EMSK never gets to the AAA layer, then the AAA layer cannot generate the USRK from EMSK itself. AAA layer must after authorizing a usage, ask EAP layer (who holds the EMSK) to generate a USRK for a specific usage. So this basically means a logical module acting as the EAP server that holds EMSK, must have an API to the AAA module to receive a request for USRK generate it and then send it back. R, Madjid -----Original Message----- From: David Mitton [mailto:[EMAIL PROTECTED] Sent: Friday, November 24, 2006 9:29 PM To: [email protected] Subject: RE: [Hokeyp] [Emu] Re: MSK but no EMSK I haven't had time to join this discussion prior to this, but I'll just pick this response out of the stream and make a comment or two: On 11/21/2006 11:50 AM, Madjid Nakhjiri wrote: >Hi Yoshi, > >I don't quite agree with this. Defining the full functionality of a new EAP >method (including how it spits out MSK and EMSK) should be the job the EAP >method designer. 3748, EAP keying framework and hokey specs then define how >MSK or EMSK is used. This is modular design. People who use EMSK then do not >have to worry about the crypto behind EMSK generation. >Using your analogy is "go buy the key and lock" but then wait to see which >door you want to install it on:) >I as a home owner do not need to know how to make locks. > >R, > >Madjid > The current specification require that a method generate EMSK, but then tell you not to show it to anyone. So to paraphrase the age old question, if an EAP method generates an EMSK in a forest and nobody hears it, does it comply with RFC3748? Until there is a standard API, or a definition of how a method exports an EMSK, or even uses an EMSK to produce a publicly visible result, this issue is a moot question, because there is no consequence of not producing an EMSK and saying that you did. The method is still a black box with this respect. In any case, when something does get defined that makes it matter, only then will method implementers have to make it happen. And it will require the modules to be updated to meet the new requirements, there's no other way. Dave. _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
