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 -----Original Message----- From: Yoshihiro Ohba [mailto:[EMAIL PROTECTED] Sent: Friday, November 17, 2006 11:36 AM To: Blumenthal, Uri Cc: [EMAIL PROTECTED]; [email protected] Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK Hi Uri, I have a different view. Mandating generation of EMSK without having defined its usage *when it was introduced* seems not much different from not having defining it at all. It looks like selling a key without a lock, make the lock later and say "You MUST use this key and lock for your car." Make sense?? Yoshihiro Ohba
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
