Subject: [MSEC] WG Last Call for GKM-Architecture draft (closing date 17 October 2003)

From: Thomas Hardjono <[email-masked]>
Date: Thu, 02 Oct 2003 21:28:33 -0400

Folks,

Now that the GKM-Arch draft has been revised (currently version-06), I'd 
like to set a new closing date of 17 October (Friday) for WG Last Call.

Please review the draft and post issues/questions to the list a.s.a.p.

thomas
------

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

---

From: George Gross <[email-masked]>
Date: Wed, 8 Oct 2003 12:43:38 -0400 (EDT)

Hi,

	I've taken a look see at this draft, it is in very good shape,
kudos to the co-authors for their hard work ;o)

a few minor Qs/comments:

1. Section 5.5 discusses various techniques to deal with implosion. As
noted on page 19 in section 5.3, the group member could open a
conventional unsecured TCP connection to the GCKS to resync with the GCKS.
Why not talk to a peer group member instead?  this side steps the
implosion issue by distributing the resync requests across the group. the
rekey message sent by the local recovery peer would still be
encrypted/source authenticated in the same form as the peer had received
it from the GCKS. the local peer's address could be a parameter downloaded
at registration time (or some other mechanism).

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?

3. section 7.0 last paragraph asserts that scalability using delegated
GCKS is an area that needs "...more analysis and work to be done on the
protocol...". That may be true, however, it is my understanding that
GSAKMP already specifies such a solution through its policy token role
authorization rules. Perhaps this section could mention as an example that
GSAKMP uses the policy token within the rekey message to facilitate
delegate GCKS scalability.

all and all, a good read, and largely ready to go forward to RFC...

br,
	George

---

From: "Lakshminath Dondeti" <[email-masked]>
Date: Thu, 09 Oct 2003 13:38:33 -0400

Comments inline:

>at registration time (or some other mechanism).
Let us discuss and write about distributed operation of GCKS services 
once the centralized architecture is complete.  Replay protection may 
become tricky in case of member retransmissions.  You know "local 
recovery" brings old RMRG/RMT discussions to memory!

>clear from the text here why this extra identifier was needed in
The identifier would be similar to protocol IDs, viz., AH and ESP, in IPsec.

>delegate GCKS scalability.
We will make a reference to GSAKMP here (I made a note to self on that 
after I submitted the I-D)!

thanks again,
Lakshminath

---

From: Brian Weis <[email-masked]>
Date: Wed, 15 Oct 2003 14:55:13 -0700

Hi Lakshminath,

> George Gross wrote:

[snip]

> 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

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