> > Through the exchange of such identifiers one can bind the MSK to the > > identity of the authenticator. But.... this has issues, imho. RFC 3748 > does > > not mandate such a feature on the EAP lower layers. > > RFC 3748 doesn't talk about this because it isn't an EAP issue -- EAP > methods treat the authenticator identity as an opaque blob (e.g. channel > bindings). MSK is exported by the EAP method. So, I'd think the EAP method shall provide the authenticator identity. > > Not sure if any supports such a thing. > > IKEv2 and IEEE 802.11r both support binding of the authenticator identity > to the transient session keys. IEEE 802.11i only supported binding of a > port identity (MAC address). 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." > > > So child keys often do persist longer than the parent key, and there > is > > > no issue with this. However, the maximum lifetime of the child keys > > > cannot be longer than the maximum lifetime of the parent. > > > > This explains it very well. Thank you. > > 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. Alper _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf