Subject: [MSEC] Simple(r) resynch methods and the policy token

From: canetti <[email-masked]>
Date: Thu, 14 Aug 2003 11:35:12 -0400 (EDT)

Folks,

Currently the GKMARCH draft says that if a group member becomes
out-of-synch with the group key then it should re-register with the GCKS.
However, in many cases there are other, simpler methods for re-synching
with the group:

- The member can open a simple, unprotected  connection (say, TCP)
with the GCKS and obtain the current (or several recent) rekey messages.
Note that there is no need in authentication or encryption here, since the
rekey message is already signed and is anyway multicased in the clear.
[Remark: One may think that this opens the GCKS to DoS attacks by many
bogus such requests. But this doesnt seem to worsen the situation: in
fact, bombarding the GCKS with bogus resynch requests would be much more
problematic...]

- The GCKS can post the rekey messages on some public site (say, web site)
and the out-of-synch  memeber can obtain the rekey messages from that
site.

We'd like to include these re-synching methods in the upcoming version of
GKMARCH. We see two ways to go about this. Our question to the list is 
which one seems preferable:

Option 1: It is mandated that the GCKS Always provides all three
ways of resynching (ie, re-registration, simple TCP, and public
posting). This way, it is up to the member to choose how to resynch
and we do not need any additional fleilds in the policy token.

Option 2: Add a field in the policy token specifying which method(s) 
should be used for re-synching.

What do people say?

Mark, Ran, Lakshminath, Frederik

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

---

From: "Lakshminath Dondeti" <[email-masked]>
Date: Thu, 14 Aug 2003 11:39:08 -0400

One small change in the wording:  s/mandated/suggested/

regards,
Lakshminath

---

From: Brian Weis <[email-masked]>
Date: Mon, 18 Aug 2003 14:25:41 -0700

Dear GKMARCH authors,

Option 1 results in too many required mechanisms, if the word "mandated"
is kept. Not all mechanisms are feasible in all applications, either.

Option 1 is fine, if the word "suggested" is used. Note that this
becomes a "SHOULD" condition. The group controller gets to choose which
methods he is capable and willing to provide. But now in order for the
group member to be able to choose which method ot can use, the group
controller has to describe which methods it supports in the policy it
gives the group members. 

But then, Option 2 becomes complementary to Option 1. Option 2 is a
natural way of providing that policy, in the case where a policy token
is used in the protocol. 

If there is no policy token (e.g., GDOI), then the policy would need to
be provided using a different mechanism. (e.g., GDOI could specify a new
KEK Attribute sent in the SA_KEK payload).

Thanks,
Brian

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

---

From: George Gross <[email-masked]>
Date: Mon, 18 Aug 2003 16:50:52 -0400 (EDT)

Hi Brian,

	things are not as simple as one would hope here...inline below...

> controller has to describe which methods it supports in the policy it

The catch is that unless one re-sync mechanism is a MUST implement for all
endpoints, then GCKS and GM from different vendors will not inter-operate.
The alternative is that a GM endpoint must implement _all_ of the
potential re-sync mechanisms because it will never know what type of GCKS
it will talk to next. After all, if the GM attempts to join group A having
vendor X GCKS that only offers resync method 1, and then at a later time
that same GM endpoint wanted to join group B having vendor Y GCKS that
only supported resync method 2...

So the revised wording is: "re-sync method Foo is the MUST implement
method, and re-sync methods Bar and Zoo SHOULD be implemented."

I leave to the group's consensus whether the re-sync method is negotiable
at group join time.

> natural way of providing that policy, in the case where a policy token

I agree with this, but would take it one step further...

> KEK Attribute sent in the SA_KEK payload).

Brian, I like to suggest the possibility that GDOI-v2 (where this new
re-sync mechanism information would be specified) could introduce a
generic group policy payload rather than trying to exhaustively anticipate
and specify every possible policy attribute. The GDOI group policy payload
would encapsulate an extensible policy token syntax, as a syntaxically
well formed list of TLV (a.k.a. AVP in other protocols). The set of TLV
that are MUST supported in a particular context would a profile on the
universe of all TLV, and spec'd in standards track RFC.

From what I have seen from discussion on this list, there is alot of
diversity in the application domains where GKM protocols are applied and
the policies they need to encode. That said, I do see enough commonality
across those application domains that we could standardize a core set of
policy token TLV across the three protocols: GSAKMP, GDOI, and MIKE.
Beyond the core set, one would define the protocol specific TLV. This
approach resembles the Diameter AAA protocol, wherein a base protocol is
common to all application specific extensions to that base.

thoughts?

br,
	George

---

From: Mark Baugher <[email-masked]>
Date: Mon, 18 Aug 2003 20:45:09 -0700

hi Brian, Ran
   I don't think options 1 or 2 are necessarily meaningful for msec key 
management protocols.  If the resync method is registration, then that is 
certainly handled in the protocols; nothing more needs to be said about 
it.  If the method uses tcp or some other reliable connection protocol, 
then that is outside the scope of msec key management protocols.  If it 
relies on the caching of re-key messages, then that is also outside the 
scope of key management protocols since the messages are intended to be 
sent over a network that is under the control of an attacker; the 
protection should be sufficient so that messages can be cached and 
distributed using other, even insecure, protocols.  The latter two cases 
are pretty much the same though a GCKS might not allow unauthenticated 
connections as a matter of policy.  As I see it, we're discussing GCKS 
policy and that does not need to be a key management protocol issue.  It's 
an msec policy token thing.

   If the key management protocol incorporates the policy token, then it's 
of course managed by the key management protocol.  But the msec group key 
management architecture does not require that the policy token be 
integrated into key management.  It could use, say, internet session 
description protocol (SDP) or other means to securely communicate the group 
policy.

   I agree with Brian that we don't want to mandate that a GCKS support all 
three ways of re-synchronizing the rekey.  I think the issue is what 
elements of the policy token must be supported versus may or should be 
supported.  This is something to be considered in the policy token work.

Mark

---

From: "Lakshminath Dondeti" <[email-masked]>
Date: Tue, 19 Aug 2003 11:21:03 -0400

Brian and George,

I was going to reply soon after I saw Brian's message, but could not get 
to it.  The discussion on MUST/SHOULD/MAY is moot w.r.t. the gkmarch I-D 
as it is informational.  That's why I corrected Ran's "mandated" to 
"suggested."

regards,
Lakshminath