>Can you please provide a pointer? Authenticator and peer identication issues are discussed in Section 2.2.1 of draft-ietf-eap-keying-15.txt >I'm wondering why we open the door for children keys living longer than the >parent key. There is a distinction between maximum and actual lifetime which is discussed in Sections 3.3, 3.4 and 3.5 in the EAP key management framework document. Since the topic is fairly involved, I'm not sure this issue deserves much if any discussion in the AAA key management guidelines. A short summary is that since EAP does not support re-authentication without re-key, if the root keying material changes (MSK, EMSK), so do the child keys (TSKs). On the other hand, there is no requirement for authenticators to cache EAP keying material once TSKs are derived, and so TSKs (children) can continue to exist even after the parent (e.g. MSK) has been deleted. 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. >I understand. What is the affect of "SHOULD but not a requirement"? Is this >like a "SHOULD-"? I mean, what do we lose if we drop the "but such a >protection is not a requirement"? I think what is meant here is that this is not mandatory (e.g. it's not a REQUIREMENT in RFC 4017). _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf