Subject: Re: [MSEC] GSAKMP issue 07: Leave Group semantics unspecified

From: Ken Calvert <[email-masked]>
Date: Mon, 11 Aug 2003 09:33:46 -0400 (EDT)

On Sat, 9 Aug 2003, George Gross wrote:

> 	an example use case is an interactive gaming group with the $
> meter running for every minute consumed.
>

So in that case the member is really asking that
the policy be changed (so she doesn't get charged).

Should policy-change mechanisms (like the proposed LEAVE
request) be part of the key-management protocol?  I would
argue that they should not, just due to the amount of
application-variability.  For example, in the above example
the departing member may want a signed/timestamped
confirmation that the policy has been changed, but that may
not be true in all cases.

KC

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

---

From: George Gross <[email-masked]>
Date: Mon, 11 Aug 2003 08:48:07 -0400 (EDT)

Hi,

	inline....

br,
	George

> the policy be changed (so she doesn't get charged).

I don't see a policy change here, just a membership set change to assure
that she does not continue to watch content that was not paid for. The
group key changes, but not the group's policy.

> application-variability.

I do not see things the same way as you ;o)

MPOV: The protocol is incomplete and not interoperable until it adds a
basic "leave group" mechanism that covers the cases discussed below.

If the application doesn't ever need members to leave, they don't use the
leave mechanism. But omitting definition of the mechanism is a sure way to
promote non-inter-operability between those implementations that need that
capability. Note that GSAKMP is a network layer service, and by definition
it must have the versatility to serve such a diverse set of application
layer requirements. The application requirements boil down to three cases:

1. no "leave group" events are reported to the GCKS

2. Leave Group Request and its ACK are authenticated by the registration
SA keying material, with the implied SA state storage requirement

3. Leave Group Request is authenticated by digital signature by the GM and
the GCKS for the ACK messages in the exchange. No SA state storage.

Your commment does identify the requirement on the Group Policy Token to
express the leave group policy, with an enumerated value for each of the
above cases.

> For example, in the above example

If the GCKS sends the former group member an "ACK" for their "leave group
request" then the exchange could be authenticated by the registration SA
key known only to the GCKS and the group member. That way the former group
member has basic assurance that the $ meter stopped.

In the case you bring up, if "receipt requested"  flag was set on the
Leave Group Request (or in the group policy) then the ACK could include
the GCKS signature on a nonce or notarized timestamp supplied by the Leave
Group Request. The GCKS could include its own notarized timestamp in the
ACK if group policy required it. However....

I think the above extra steps for a timstamped receipt that supports
non-repudiation in a court of law are an example of extensions beyond the
base specification. The base specification MUST have a Leave Group
Request/Ack exchange. This is an example of an engineering decision that
assures inter-operability across a wide cross section of use cases, and
yet it leaves room for future standardization as the market matures.

FWIW, At a certain point, it becomes a credit card dispute, and in all the
disputes I've had with Internet based vendors to date, the case was
resolved without the credit card company needing a timestamped digital
signature ;o)