| Re: Issue 254: Key Lifetime Issues | <– Date –> <– Thread –> |
|
From: Bernard Aboba (aboba |
|
| 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."
-
Issue 254: Key Lifetime Issues Bernard Aboba, August 10 2004
-
Issue 254: Key Lifetime Issues Bernard Aboba, August 21 2004
- Re: Issue 254: Key Lifetime Issues Jari Arkko, August 21 2004
- Re: Issue 254: Key Lifetime Issues Bernard Aboba, November 16 2004
- Re: Re: Issue 254: Key Lifetime Issues Jari Arkko, November 17 2004
-
Issue 254: Key Lifetime Issues Bernard Aboba, August 21 2004
Results generated by Tiger Technologies using MHonArc.