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