Subject: [MSEC] RE: Responder-initiated TGK re-keying/CSB updating allowed in MIK EY?

From: "Fredrik Lindholm (KI/EAB)" <[email-masked]>
Date: Fri, 15 Aug 2003 09:30:34 +0200

Hi Martin,

sorry for the late reply.

> 
> Dear experts,
> 
> MIKEY-07 describes means how the initiator can update the CSB 
> or re-key the TGK (see section 4.5).
> 
> Questions are: What about responder-initiated key update etc 
> where the responder requests key update actions from the 
> initiator? Is this possible using MIKEY?

You mean a message that can be sent from any member to the 
initiator (or group controller) that requests the group key 
to be changed? No, that is not possible to do in MIKEY.
 
> Is that something that can be done with some non-MIKEY 
> (request) message from the responder to the initiator? I 
> believe yes, but 1) it's non-standard and 2) yields a 2- or 
> 3-way handshake.
> 
> Is some role change during an active CSB allowed where the 
> responder takes over the initiator role for the purpose of 
> key updating? Would that really work?

The exchange mechanisms would work even if the roles changes. 
However, to allow for role change we are then coming into the 
area of authorization, i.e. who is allowed to add/change/remove 
new members and information. We didn't define any special 
authorization token to allow for delegation of authorization 
(the policy token work that are discussed on the list, will
be one way to achieve this). Though, I would imaging that for 
a peer-to-peer case (as the DH-HMAC), you might not need an 
explicit authorization token to allow for this role change 
(but rely on the initial authorization).

BR,
Fredrik

> My understanding is, that the initiator or responder roles 
> are static throughout the lifetime of the protocol 
> instantiation. The definition in 1.3 is not entirely precise 
> about that, but I infer this more from statements like 
> "...This is done by executing the transport/exchange phase 
> once again to obtain a new TGK (....".
> 
> 
> With kind regards
> 
> Martin Euchner.

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec

---

From: Euchner Martin <[email-masked]>
Date: Mon, 18 Aug 2003 15:52:01 +0200

Fredrik,

Thanks for your reply. Please find my comments embedded below.

 
MEU:> ok, that is also my understanding.

MEU:> I'm not talking about invoking group membership changes by some non-initiator member. This is clearly a separate problem that deserves or course some authorization means.

My question is simply: Can the responder request a new (group) key from the initiator? For example, the responder could be aware that the current group key on his/her own machine has expired/has been compromized or that the key will soon to expire etc, while the initiator considers the TGK secure for much longer time. Could the responder communicate this matter (using MIKEY) to the initiator, and trigger the initiator to distribute a new TGK?

This should be something that does not require any deeper authorization, does it?

Cheers

Martin

---

From: "Fredrik Lindholm (KI/EAB)" <[email-masked]>
Date: Mon, 18 Aug 2003 15:57:32 +0200

> MEU:> I'm not talking about invoking group membership changes 
> by some non-initiator member. This is clearly a separate 
> problem that deserves or course some authorization means.
> 
> My question is simply: Can the responder request a new 
> (group) key from the initiator? For example, the responder 
> could be aware that the current group key on his/her own 
> machine has expired/has been compromized or that the key will 
> soon to expire etc, while the initiator considers the TGK 
> secure for much longer time. Could the responder communicate 
> this matter (using MIKEY) to the initiator, and trigger the 
> initiator to distribute a new TGK?

No.

Cheers,
Fredrik