Subject: RE: [MSEC] Is ID payload missing in GROUPKEY-PUSH?

From: "Sheela Rowles \(srowles\)" <[email-masked]>
Date: Tue, 14 Nov 2006 12:01:23 -0800

Xu Chen,

You don't need the ID in the rekey messages since you can use the  SPI
to identify the information. During Registration, a KEK payload is sent
to the Group Members with the SPI information.  Then later during the
rekey, the same SPI information is in the header, so the group member
can identify the KEK information.

Also, note from RFC 3547:

   Unlike ISAKMP or IKE, the cookie pair is completely determined by the
   GCKS.  The cookie pair in the GDOI ISAKMP header identifies the Re-
   key SA to differentiate the secure groups managed by a GCKS.  Thus,
   GDOI uses the cookie fields as an SPI.

Sheela

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of chenxu
Sent: Monday, November 13, 2006 8:37 PM
To: [email-masked]
Cc: Mark Baugher (mbaugher); [email-masked]
Subject: [MSEC] Is ID payload missing in GROUPKEY-PUSH?

Hi, everybody, 

Recently, I did some research on GDOI and one thing has confused me a
bit. I noticed there is an ID payload in GROUPKEY-PULL, which is used to
identify the group the member-initiator wishes to join. (RFC3547, Page
8). This payload is further described in Page 17. "The Identification
Payload is used to identify a group identity ....... ". 

However, I also noticed that there is no ID payload in GROUPKEY-PUSH
message. When a member receives a GROUPKEY-PUSH message, he/she has no
idea which group this message belongs to. Does this mean he/she must try
to deal with all GROUPKEY-PUSH messages? 

Why not just include an ID payload in GROUPKEY-PUSH message after HDR
and the SIG payload is a signature of a hash of the entire message
including ID payload. 

E.g.  <---- HDR*, ID, SEQ, SA, KD, [CERT,] SIG

Best Regards,

Xu Chen

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

---

From: Xu Chen <[email-masked]>
Date: Sat, 25 Nov 2006 10:23:17 +0800

hi Sheela,
 
Many thanks for answering my question. Another question just confused
me. According to RFC3547 section 3.3,  "If the policy in the SA
payload is acceptable...., the initiator continues the protocol."
However, what will happen, if the SA payload is not acceptable(such as
an unsupported SIG_ALGORITHM)? 

IKE has a SA negotiation in Quick Mode and the responder may choose
prefered SA proposal. Also, it is more reasonable for a group member
to follow group SA policy than to negotiate it. However, if the second
message of GROUPKEY-PULL(with group SA payload) is lost , GDOI GCKS
may not be able to distinguish this situation with unacceptable group
SA policy . 

Best Regards,
Xu Chen

	From: Sheela Rowles (srowles) [mailto:[email-masked]] 
	Sent: Wednesday, November 15, 2006 4:01 AM
	To: chenxu; [email-masked]
	Cc: Mark Baugher (mbaugher); [email-masked]
	Subject: RE: [MSEC] Is ID payload missing in GROUPKEY-PUSH?

	Xu Chen,

	You don't need the ID in the rekey messages since you can use
the  SPI to identify the information. During Registration, a KEK
payload is sent to the Group Members with the SPI information.  Then
later during the rekey, the same SPI information is in the header, so
the group member can identify the KEK information.

	   Unlike ISAKMP or IKE, the cookie pair is completely
determined by the
	   GCKS.  The cookie pair in the GDOI ISAKMP header identifies
the Re-
	   key SA to differentiate the secure groups managed by a
GCKS.  Thus,
	   GDOI uses the cookie fields as an SPI.

	Sheela

	Hi, everybody, 

	Recently, I did some research on GDOI and one thing has
confused me a bit. I noticed there is an ID payload in GROUPKEY-PULL,
which is used to identify the group the member-initiator wishes to
join. (RFC3547, Page 8). This payload is further described in Page 17.
"The Identification Payload is used to identify a group identity ...
". 

	However, I also noticed that there is no ID payload in
GROUPKEY-PUSH message. When a member receives a GROUPKEY-PUSH message,
he/she has no idea which group this message belongs to. Does this mean
he/she must try to deal with all GROUPKEY-PUSH messages? 

	Why not just include an ID payload in GROUPKEY-PUSH message
after HDR and the SIG payload is a signature of a hash of the entire
message including ID payload. 

	Best Regards,

	Xu Chen