Subject: [MSEC] GSAKMP - rekeying - synchronisation

From: Haitham Cruickshank <[email-masked]>
Date: Tue, 18 Mar 2003 12:45:09 +0000

Hi Hugh and Peter,

We have a small question regarding the synchronisation between a secure
multicast group members after a rekeying event.  This is a general
concept for GSAKMP and GDOI, however I will ask the question in context
of GSAKMP.

The question is: After the GSAKMP server sends a server-rekey message to
all GSAKMP clients to update their traffic keys (such as member leaving
or joining, etc..), how the traffic sender (multicast source) and the
multicast traffic receivers will synchronise the use of the new keys
that has been just distributed by the GSAKMP server ?.

In the context of using GSAKMP with IPSEC, one idea is to use the
traffic key-handle (which is distributed by the GSAKMP server with the
key itself) as the SPI (Security Parameter Index) in IPSEC.    If this
is correct, then a server re-key message received by the GSAKMP client
means a new IPSEC key and new SPI as well (new security association).
In this case, re-synchronisation is not a problem as more.

Any comments on this are welcome.

Haitham & the Surrey team.
--
Dr. Haitham S. Cruickshank

Senior Research Fellow in Communications
Centre for Communication Systems Research (CCSR)
School of Electronics, Computing and Mathematics
University of Surrey
Guildford, Surrey GU2 7XH, UK

Tel: +44 1483 686007 (indirect 689844)
Fax: +44 1483 686011
e-mail: [email-masked]
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/

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

---

From: Hugh Harney <[email-masked]>
Date: Fri, 21 Mar 2003 14:32:16 -0500

Haitham,

I'm sorry I was at the IETF last week and was distracted.

The problem of group synchronisation for encryption and decryption is a 
well known problem. The solution is not perfect. We can allow an 
encryptor to use the old key k for a period of time t1. The decryptors 
will hopefully get the new key k* before the encryptor starts using the 
new key for transmission at t1+1.

If the decryptors get k* before t1 they can store it and decrypt on k 
or k*.

If the decryptor does not get k* by t1+1, there is a problem. Some 
traffic will be lost due to the decryptors inability to decrypt traffic 
encrypted in k*.  Due to the unreliable nature of group communications, 
this problem is difficult to deal with gracefully.  I think that the 
responsibility for staying in synch lies with the decryptor. If the 
decryptor detects that it lost synch, it re-joins the group. This is 
the simplest mode of operation.

If we require all members of the group to notify the receipt and 
processing of a rekey message we would bring the multicast group to 
it's knees.

thanks

Hugh

On Tuesday, Mar 18, 2003, at 07:45 US/Eastern, Haitham Cruickshank 
wrote:

> Hi Hugh and Peter,
>
> We have a small question regarding the synchronization between a secure
Hugh Harney							Sparta, Inc.
[email-masked]						7075 Samuel Morse Drive
(410) 872-1515 x203					Columbia, MD, 21046