Subject: Rekey SA identifier (Re: [MSEC] msec-gkmarch-06.txt: GCKS implosion, scalability)

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Fri, 16 Jan 2004 16:26:13 -0500

GKMarch-06- says that a Rekey SA is identified by a triple <Group ID, 
SPI, Identifier for "Rekey Protocol" a la ESP/AH>.  Brian and George 
noted that there is no need for the third parameter.  I agree (can't 
recall why we put it there :-[ ).   However, I have two questions.

Existing protocols use the following:
GDOI:  Brian noted that GDOI uses {protocol, src addr/port, dst 
addr/port, SPI}.  Do we really need all those?
GSAKMP:  uses Group ID TLV

2) I notice on further thought that <Group ID, SPI> or any of the above 
two sets of parameters might not be collision-proof.  If a member is 
part of two secure groups managed by two different GCKSs, it may receive 
the same Group ID and SPI for two rekey SAs.  If the "Group ID" is an 
SSM address <src, dst>, this can be avoided.  In other cases, e.g., 
ASM/ISM address or an arbitrary 32-bit number, we might run into problems.

Any ideas?

regards,
Lakshminath

Brian Weis wrote:

> 2. section 6.2.6 mentions "an identifier for Rekey SA", and I was not
>
>>>clear from the text here why this extra identifier was needed in
>>>addition to the SPI?
>>>
>>>      
>>>
>>The identifier would be similar to protocol IDs, viz., AH and ESP, in IPsec.
>>    
>>
>
>I'm still confused ... why would we need a protocol id to identify a
>rekey message? I can see where a group identifier (as defined in Section
>6.3.1) could be useful to uniquely identifier a rekey message as being
>part of a specific group, but not why the rekey message would need its
>own protocol type?
>
>In GDOI, a receiver of a rekey message recognizes a rekey message
>matching {protocol, src addr/port, dst addr/port, SPI}. Strictly
>speaking, there is neither a group identifier nor a rekey identifier. I
>can see where adding a group identifier might be useful in the rare case
>that two GDOI groups used the same network layer address, and also chose
>the same SPIs. But how would a rekey identifier help?
>
>Thanks,
>Brian
>
>  
>

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

---

From: George Gross <[email-masked]>
Date: Sat, 17 Jan 2004 09:54:22 -0500 (EST)

Hi Lakshminath,

> addr/port, SPI}.  Do we really need all those?

I'm fairly sure that you do. You would need to fully qualify your SPD
entries to direct the "right" traffic into the group data SA. On the
receive side, you may be dealing with source-specific multicast, so there
is a requirement for source address. As per the rfc401bis Internet Draft,
right?

> GSAKMP:  uses Group ID TLV

Yup. The GSAKMP group policy token is being reworked, and the IPSEC
mapping aspects will initialize the multicast data SPD/SAD entries. The
Group ID is simply a handle that refs that policy token blob.

> ASM/ISM address or an arbitrary 32-bit number, we might run into problems.

This topic has been discussed among the GSAKMP co-authors. However, the
spec probably won't be rev'd to change bits on the wire to handle this
issue. The algorithm I thought up to mitigate it didn't cover all cases
and was complex. I think the best defence is static configuration of the
multiple GC/KS to avoid duplicate SPI assignments to a common multicast
channel. You're probably faced with an operational step like this anyway
to avoid SPI collisions with IKE originated unicast SA.

Lakshminath, did you have a solution in mind?

br,
	George

---

From: canetti <[email-masked]>
Date: Mon, 19 Jan 2004 16:05:32 -0500 (EST)

I'm a bit confused, since I dont see an "update period" counter included
in the signed message. Is this information implicit in another field? 

Ran

---

From: Brian Weis <[email-masked]>
Date: Mon, 19 Jan 2004 17:24:34 -0800

Hi Ran,

It's called a "sequence number" in Section 5.3, and specified in Section
6.2.5.

Brian

-- 
Brian Weis
Strategic Cryptographic Development, ITD, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: canetti <[email-masked]>
Date: Tue, 20 Jan 2004 13:02:40 -0500 (EST)

Yes. thanks for the reminder.

But, looking at the text again, it seems to me that the need to
authenticate the rekey messages is not stressed enough in the text 
(section 5). Some language should be added... 

Ran