> MSK is exported by the EAP method. So, I'd think the EAP method shall > provide the authenticator identity. EAP methods (optionally) export the Peer-Id and Server-Id. They don't export the authenticator identity, since the authenticator is not a party in the EAP method conversation; it only acts as a forwarder. > I'm talking about MSK, not TSK. By the time EAP authentication is completed > successfully, there is an MSK but the EAP peer does not know the "identifier > of the parties to whom the session key is available." At the completion of the EAP method conversation, the MSK/EMSK is provided to two parties, the peer (identified by the Peer-Id) and the server (identified by the Server-Id). The lower layer then needs to bind the exported keying material to the lower layer identities of the peer and authenticator. For example, within IKEv2, the peer and authenticator identities are defined by the initiator and responder ID payloads. In IEEE 802.11r they are defined by the peer MAC address and the R1KH-ID; this implies that on an authenticator, the key scope includes multiple ports, but on the peer it only includes the port over which the EAP conversation ran. > > Is there an issue with the explanation in the document? > > The I-D currently does not have any text describing this. So, it'd be useful > to include one. Russ had agreed with me, but I had a question about the > normative language. Your above text clarifies it all. Thanks. Ideally this should be clarified in the document itself, not just in an email on the IETF list :) _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf