Subject: [MSEC] GKM arch editorial comments...

From: George Gross <[email-masked]>
Date: Wed, 8 Oct 2003 19:18:32 -0400 (EDT)

Hi,
	in follow up to my prior e-mail, this one is just editorial
nits...

1. figure 2 may be easier to understand if there was a way to distinquish
between protocol communication and internal API primitives. I would expect
that the SAD/SPD/cred interactions would be an API primitive, not a
protocol.

2. section 5.1, first use of the acronym GKMA is not defined

3. section 6.1, the sentence on page 24 that says: "information is
externally managed." was confusing. Externally managed by whom/what
component? would this be a group policy server? or the group owner? or its
administrator?

4. section 6.3.3 caption has a typo

5. reference JKKV94 has the title listed twice...

br,
	George

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

---

From: Mark Baugher <[email-masked]>
Date: Thu, 09 Oct 2003 06:55:08 -0700

thanks, George
>that the SAD/SPD/cred interactions would be an API primitive, not a

That should be easy to do for the msec gkm protocol:  We could make the 
arrow ==> instead of --> but in general, there is no necessary distinction 
between an API implemented on top of some RPC and the box-to-box protocols 
that are the subject of the I-D.  But a lot of what's in that diagram is 
supportive of msec gkm and incidental to it.  We should point that out in 
the diagram.

>2. section 5.1, first use of the acronym GKMA is not defined

I believe it is in section 5.0.

>component? would this be a group policy server? or the group owner? or its

how about "externally management by a security-policy management function 
that is outside the scope of this document" or something like that?

>4. section 6.3.3 caption has a typo

Somebody's been subjected to too much spam :!)

>5. reference JKKV94 has the title listed twice...

thanks, Mark

---

From: George Gross <[email-masked]>
Date: Thu, 9 Oct 2003 08:25:52 -0400 (EDT)

Hi,

> supportive of msec gkm and incidental to it.  We should point that out in

ok

> I believe it is in section 5.0.

got it, I missed that on first read.

> that is outside the scope of this document" or something like that?

close. Or how about:  "...configured by a security policy manager.  The
security policy manager's design and its interface to the policy
repository is outside the scope of this architecture."

BTW, I noticed a preceeding sentence:

"Thus group security policy will be represented in a policy repository and
accessible using a policy protocol."

which seems to preclude multicasting the policy token in a message (e.g.
GSAKMP), which is not what I think you intended to say, right? How about
adding:

"Alternatively, the group security policy also can be multicast
distributed from a group policy server to the group's candidate membership
in a source authenticated message."

---

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

Thanks for the review, George.

6.3.3.'s title is what I got when I married protection and encryption :-)!

More later,
Lakshminath

Mark Baugher wrote:

> That should be easy to do for the msec gkm protocol:  We could make 
> the arrow ==> instead of --> but in general, there is no necessary 
> distinction between an API implemented on top of some RPC and the 
> box-to-box protocols that are the subject of the I-D.  But a lot of 
> what's in that diagram is supportive of msec gkm and incidental to 
> it.  We should point that out in the diagram.
>
>
> how about "externally management by a security-policy management 
> function that is outside the scope of this document" or something like 
> that?
>
>