Thank you. Comment following your clarification.
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
IETF mailing list