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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf