Thanks Joel. Followup notes inline: On 3/17/2008 6:47 PM, Joel M. Halpern wrote: > Thank you. Comment following your clarification. > Joel > > > Lakshminath Dondeti wrote: > ... >>> The one thing that bothers me a little is the intended status of >>> this document. Given that the EMSK is entirely inside a system, and >>> that therefore the actual generation process is internal to that >>> system, I am not sure that a registry tied to the specifics of the >>> generation mechanism, is appropriate. A lot of this document is of >>> the form "if you don't define it some other way, do this." While >>> very useful text, it actually doesn't seem to affect on-the-wire >>> interoperability. So I wonder if this whole document is more >>> informational than "proposed standard?" I'm not sure on this, but >>> the containment property did strike me reading the document. >> >> The peer and the server need to arrive at the same derivations. The >> keynames derived as specified in this document would be used in >> protocols specified elsewhere to refer to the keys derived >> independently at both ends. So, whereas there are no "on the wire" >> packet formats in this document, other documents will put information >> derived as specified in this document in their packets. > > That does make for a good reason for PS. I am however then confused by > the description that the EMSK never leaves the server. I presume that > this relates to other aspects of EAP that I am not familiar with. You > may want to see if there is a way to phrase it that makes it a bit > clearer. But given what you say, this is another minor issue, not a big > deal. > The note about EMSK never leaving the server is contextual; the other master session key, the MSK is sent to the authenticator (and thus "leaves" the server). We'll make a note of this as well for clarification. So, on balance, we have two clarifications make: one on domains (that came up elsewhere too, so we'll work on the text once again -- we did that during WG discussions) and another on EMSK being held at the server. regards, Lakshminath _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf