Re: Issue 254: Key Lifetime Issues
From: Bernard Aboba (abobainternaut.com)
Date: Tue, 16 Nov 2004 18:31:16 -0500 (EST)
Jari Arkko said:

"The reader may wonder why we suddenly talk about
IKE. Suggest s/A difference/To take an example from IKE,
the difference/"

[BA] OK.

>    Note that deletion of the AAA-Key does not necessarily imply deletion
>    of the corresponding TSKs.  Replacement or deletion of TSKs only
>    implies replacement of the AAA-Key when the TSKs are taken from a
>    portion of the AAA-Key.

"I do not understand this paragraph. The first part appears to claim
that TSKs can break the death-of-the-parent rule. The second part
appears to claim that AAA-Key gets changed because it is used twice.
Or maybe the latter is something that we do want to mandate, but
the text still reads funny, it sounds like the requirement only
exists if we take a part of AAA-Key, not all of it. Or did you
want to say that when TSKs are bit-by-bit copies of the AAA-Keys
parts, then we throw that part away?"

[BA] How about if we delete this paragraph entirely?
On rereading it, I don't believe it makes sense.

"Is it really "prior to"? Not "latest at"?"

[BA] Yes, that's better.

>      Where TSKs are established as the result of a Secure Association
>      Protocol exchange, it is RECOMMENDED that the Secure Association
>      Protocol include secure negotiation of the TSK lifetime between the
>      peer and authenticator.

Why do we recommend this? What if the lower layer uses the IKEv2
principle?

[BA] Actually the requirement is really support for resynchronization,
since it's possible to accomplish this without key lifetime negotiation
(e.g. IKEv2) How about this?

Change:

"Where TSKs are established as the result of a Secure Association
Protocol exchange, it is RECOMMENDED that the Secure Association
Protocol include secure negotiation of the TSK lifetime between the
peer and authenticator."

To:

"Where TSKs are established as the result of a Secure Association
Protocol exchange, it is RECOMMENDED that the Secure Association
Protocol include support for TSK resynchronization."



Results generated by Tiger Technologies using MHonArc.