Subject: [MSEC] distributed GSAKMP

From: "Prashant Pillai" <[email-masked]>
Date: Thu, 27 Jul 2006 11:53:25 +0100

Hi,

Could someone pleased help me with some doubts on distributed architecture:

   - In RFC3740, Section 2.3 mention having separate policy servers in a
   distributed multicast framework. While in GSAKMP, there is only a single GO,
   which is reposbile for the policy.
   - In the GSAKMP document, it is stated that a subset of the GMs will
   be authorised to be S-GCKS. Is there any particular way in which these GMs
   are selected? I am not sure how this is done in a distributed architecture.
   Is GM selected per domain?
   - What if there is only a single GM (in each of the distributed
   domains) who wants to access the content? And what happens for indivduals on
   the internet?
   - Also what happens if the GM acting as the S-GCKS decides to leave?
   - In a distributed environment - like two separate corporates who want
   to access the content, is it not more feasible to have one of the servers
   act as a GCKS, instead of a GM.

Regards
Prashant Pillai

Research Assistant
School of Engineering, Design and Technology,
University of Bradford
United Kingdom
_______________________________________________
MSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/msec

---

From: George Gross <[email-masked]>
Date: Thu, 27 Jul 2006 05:50:11 -0400 (EDT)

Hi Prashant,

>    which is reposbile for the policy.

Yes, that is correct. The GSAKMP framework uses multicast to distribute
the policy token whenever it changes. Since this policy distribution
method is scalable, it mitigates the need for multiple policy servers.
Besides, having multiple policy authorities would be extremely complicated
for minimumal benefit, IMHO.

>    Is GM selected per domain?

The answer is application policy specific. The GO decides what is the
"right" policy, and encodes the policy token to authorize the S-GCKS
subset within the overall group membership.

For example, composite groups could be organized to have a S-GCKS per
homogeneous sub-group. Again, what attributes constitute a "sub-group" for
a composite group is application specific.

>    domains) who wants to access the content? And what happens for indivduals on

I don't understand this question.

>    - Also what happens if the GM acting as the S-GCKS decides to leave?

This answer is also application security policy specific.

Usually a S-GCKS doesn't leave until after its sub-group reaches an empty
membership condition.  If a S-GCKS is compromised, then its sub-group
membership must re-register at another GCKS to rejoin the group. This is
because after primary GCKS rekeys the group to expell the S-GCKS, the
S-GCKS is no longer able to decrypt the RKE multicasts from the primary
GCKS and propagate the new GTPK and PT to the sub-group.

Alternatively, after a S-GCKS compromise the whole group should be
terminated and then re-built.

>    act as a GCKS, instead of a GM.

Yes. Yet another example of delegating S-GCKS responsibility on the basis
of application specific policy.

hth,
	George

---

From: George Gross <[email-masked]>
Date: Thu, 27 Jul 2006 05:50:11 -0400 (EDT)

Hi Prashant,

hth,
	George

---

From: "Prashant Pillai" <[email-masked]>
Date: Thu, 27 Jul 2006 15:12:41 +0100

Hi George,

Thanx for ur reply. See inline.

Regards
Prashant Pillai

> for minimumal benefit, IMHO.

I agree, I was also not sure why we would need multiple policy servers. It
adds to more complexity for interoperability of these policy server.

> a composite group is application specific.

Why is the definition of "Sub-groups" application specific? Do you mean the
type of application shall define the sub-group? I am not sure why this
should be so.

What I wanted to ask was if GSAKMP is only suitable when different corporate
LANs want to share secure multicast content or can it be also used over the
internet - say a company decides to offer Secure multicast video streaming
which should be accessible to any user on the internet. How is a S-GSKC
selected then? Note here that users may connect from any part of the world
at any time. Who can be an S-GCKS in such a scenario?

membership condition.

If the S-GCKS is a GM (hence an end user am I correct in saying this), I am
not sure why it may not leave, unless GM is not an end user but another
server or router that is always on. Not sure if this is possbile though.

 If a S-GCKS is compromised, then its sub-group

hth,
       George

---

From: "Prashant Pillai" <[email-masked]>
Date: Thu, 27 Jul 2006 15:12:41 +0100

Hi George,

Regards
Prashant Pillai

hth,
       George

---

From: George Gross <[email-masked]>
Date: Thu, 27 Jul 2006 07:32:50 -0400 (EDT)

Hi Prashant,

<snip for brevity>
> type of application shall define the sub-group? I am not sure why this

The Group Owner gets to decide this policy for each group. The criteria
for S-GCKS can be anything:

- scalability: 1 S-GCKS per 1,000 GM

- divide up a group along administrative domain boundaries, S-GCKS per
domain

- composite group: S-GCKS per sub-group.

- picked at random from a dart board, so long as that GM is considered
trustworthy in that S-GCKS role o;)

in other words, GSAKMP provides the tools to do it any way that makes
sense to the GO.

> at any time. Who can be an S-GCKS in such a scenario?

Discovery of S-GCKS is yet another question for which there is no "one
size fits all" answer. See RFC 4535 section 4.3 for a survey of methods.

> server or router that is always on. Not sure if this is possbile though.

Accepting the S-GCKS role implies taking responsibility for the
sub-group's membership management throughout a sub-group's lifespan. One
part of that responsibility is the LKH key server for the sub-group. In
that sense, S-GCKS are indeed a superset of an ordinary Group Member.

However, as explained in RFC 4535 section 4.4.6, any Group Member must be
prepared to accept becoming a S-GCKS if the GO authorized it AND local
policy permits executing in that mode.

	George

---

From: George Gross <[email-masked]>
Date: Thu, 27 Jul 2006 07:32:50 -0400 (EDT)

Hi Prashant,

<snip for brevity>

	George

---

From: "Prashant Pillai" <[email-masked]>
Date: Fri, 28 Jul 2006 10:08:28 +0100

Hi George

Is the GM an end user (receiver of the multicast content) or can it be any
device (some server/ router)? RFC 4535 states that the GM is one who has
access to the group keys. Am I correct in saying that the GM is any device
who is registered (out-of- band) with the GO and hence is present in the
access list?... and this GM should authenticate itself before it can act as
a S-GSKC or as an end user receiving the multicast content.

Regards
Prashant

P.S. Thanx a lot for you helpful replies.

---

From: "Prashant Pillai" <[email-masked]>
Date: Fri, 28 Jul 2006 10:08:28 +0100

Hi George

Regards
Prashant

---

From: George Gross <[email-masked]>
Date: Fri, 28 Jul 2006 05:09:10 -0400 (EDT)

Hi Prashant,

On Fri, 28 Jul 2006, Prashant Pillai wrote:

> access to the group keys.

GSAKMP does not care whether a GM is a human carrying a smart card versus
a server/router device with a secure cryptographic storage. What matters
is that during the registration protocol exchange the GM proves possession
of the signature private key for the identity asserted in the public key
certificate.

> Am I correct in saying that the GM is any device
> access list?...

The word "registered" is misleading, a GM would be more accurately said to
be "authorized" by the GO. The GM would have registered with a PKI
Certificate Authority or Registration Authority as part of the PKI
enrollment process to get its public key certificate.

Yes, the GO must know the GM's identity within the PKI being used by a
group. The GO adds the GM's identity to the group access list before
signing and distributing the PT.

> and this GM should authenticate itself before it can act as

Yes, GM authentication occurs during the GSAKMP registration protocol
exchange.

	George

---

From: George Gross <[email-masked]>
Date: Fri, 28 Jul 2006 05:09:10 -0400 (EDT)

Hi Prashant,

	George