Subject: Re: [MSEC] Next gkmarch I-D

From: Mark Baugher <[email-masked]>
Date: Thu, 31 Jul 2003 14:21:44 -0700

George,

At 11:58 AM 7/31/2003 -0400, George Gross wrote:
<...>
> > > > I should take a look at the latest word on this but someone can surely
> > > > present to the IETF any invention, system or apparatus for which 
> they have
> > > > previously filed a patent without invalidating the patent in any way.
>
>These days, no Internet Draft gets published unless it contains the
>RFC2026 boilerplate pledging compliance to IETF IPR policy.

There is the "posting" of an I-D and the "publication" of an I-D.  What you 
say is true for publication, at which point the I-D becomes some sort of 
RFC.  It is obviously possible to post an I-D without the IPR statement 
since this was done with the SD I-D two years ago.

>The IPR
>working group has been refining that policy, and has several drafts out. I
>would anticipate that several of them will publish as informational RFC
>this year and will become part of the IETF process too.
>
>So a new SDR draft will have to match those IPR guidelines.
>
>Wrt/ to Subset Difference Rekeying (SDR) and reliability, I think it is
>germane to mention a paper I encountered recently:
>
>"Adding Reliable and Self-Healing Key Distribution to the Subset
>Difference Group Re-keying Method for Secure Multicast"
>
>by S. Zhu, S. Setia, and S. Jajodia
>
>The paper underscores that although SDR is "stateless", it still needs
>reliable multicast transport. In other words, the stateless property as
>defined here means that if a group member does get the rekey multicast
>packet, he/she has all the info needed to acquire the new group key
>without dependency on state info received in other rekey packets. But
>members that don't get the rekey packet are out of luck until the next
>rekey message is sent, unless there is a recovery mechanism.
>
>The paper goes on to explain how adding FEC and Batched Key
>Re-transmission (BKR) to SDR could address the reliablity problem.
>
>I largely concur with Mark's outline, in that having the GKM-arch specify
>the base error recovery is a minimum starting point. However, I would also
>require that the group policy token have the hooks (i.e. reserved TLV) for
>describing the group's mandatory RMT protocol and its operating
>parameters. This finesses the "there are many deployment scenarios..."
>issues by specifying the extensibility that must be built into the GKM
>protocol and its policy token.
>
>To get this capability, at first sight it seems we need: an RMT protocol
>identifier space as an IANA consideration for the GKM-arch or else the
>group policy token spec. thoughts?

I would not put an identifier into a group key management protocol for an 
RMT protocol when there are no standard RMT protocols.  If reliable 
multicast were more important to group key management then I perceive it to 
be, we could add numbers for Experimental RFCs (IKE did that for 
SPKI).  But I don't think we lose anything with the status quo, which is to 
use a sequence number and periodic retransmission of the re-key message.

Mark

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

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

---

From: George Gross <[email-masked]>
Date: Mon, 4 Aug 2003 19:23:31 -0400 (EDT)

Hi Mark,

> At 11:58 AM 7/31/2003 -0400, George Gross wrote:

 <snip...>

> use a sequence number and periodic retransmission of the re-key message.

Hmmmm, I think we do lose/miss something. Suppose that in the future, a
RMT protocol is standardized, and that the MSEC policy token v2 was
"extended"  to include the formerly unspecified but now standard RMT
identifier. The endpoints that are running MSEC v1 will be unable to
reliably participate in the group, as they get dropped after the first
lost rekey packet.  There will not be retransmission of the rekey message
because the GCKS expects the v1 endpoints to handle the RMT. Detecting the
next rekey message's sequence number mismatch could be an unacceptably
long wait...

At the very least, this case raises a requirement in the registration
protocol to have the v1 endpoint tell the GCKS its version number and/or
supported RMT set. That way, the GCKS can straddle the v1 and v2 group
subsets with their respective RMT rekey policies. RMT aside, I would think
we need this capability to allow v1 endpoints to participate with v1 rekey
protocols in parallel to v2 endpoints using a "new" rekey protocol.

AFAIK, neither GDOI nor the GSAKMP registration protocol handle this case.

br,
	George

---

From: Hugh Harney <[email-masked]>
Date: Tue, 5 Aug 2003 11:25:24 -0400

George,

I think that the key management architecture and security policy 
definitions should be separated from the communications network 
mechanisms.

I understand your concerns about different network reliability 
characteristics perhaps presenting problems for rekey actions. I 
believe the answer is to identify how the security protocols will 
handle failures in the communications system (ref: GSAKMP protocol 
state diagram). The answer is not to have the security system start 
managing the communications network.

GSAKMP does not need to identify the RMT protocol supporting rekey. 
GSAKMP passes information to the GM about the life-span of the keys, 
and the rekey frequency to be expected. If either of these parameters 
is exceeded GSAKMP closes out the group and can then try to rejoin. 
This failing to a secure state is critical in high assurance key 
management protocols.

That said. The GSAKMP Policy Token is defined for GSAKMP and IPSec, 
using multiple transmissions as the reliability mechanism for rekey. If 
another protocol or architecture wants to use the GSAKMP PT, we allow 
them to branch at the protocol ID field in the protocol. If someone 
takes that branch they can define the "Protocol Something Else" to 
include the identification of RMT protocol. We hopefully will make 
their job easier since they have a worked example to follow.

Hugh

> AFAIK, neither GDOI nor the GSAKMP registration protocol handle this 
Hugh Harney							Sparta, Inc.
[email-masked]						7075 Samuel Morse Drive
(410) 872-1515 x203					Columbia, MD, 21046

---

From: George Gross <[email-masked]>
Date: Tue, 5 Aug 2003 12:45:10 -0400 (EDT)

Hugh,

> managing the communications network.

If I understand what you're saying, then you would be adding a new
event/signal to the GSAKMP finite state machine in the v04 version of the
GSAKMP ID, right? The event would be something like: "RMT service had an
unrecoverable error for these group members". For GSAKMP v1, the RMT
service is simply the rudimentary retransmission policy we have discussed
on the list, and this "RMT error" event would be unlikely to occur.

However, my example below discussed a hetrogenous group composed of both
v1 and v2 endpoints. Your response does not fully speak to backward
compatibility for a group formed from a mixture of endpoints.

Please explain to me how you would anticipate that GSAKMP v2 will
interoperate with a GSAKMP v1 embedded base?

In prior e-mails, I had been using RMT as a litmus test for my thinking
about this scenario.  Setting aside RMT, there are likely to be other
parameters in v2 not known to a v1 endpoint. There should be a way to
express that a policy parameter is "critical" in that it can not be
ignored if it is not implemented. Other parameters could be safely
ignored. This extensibility needs to be in v1 even if it is not being used
yet.

Also, wouldn't it make sense to have the group member identify its GSAKMP
version in the RTJ?

Or are you saying that a group can't have a mixture of endpoints where
both GSAKMP versions co-exist concurrently? If so, then that must be
highlighted as a restriction in the spec.

> is exceeded GSAKMP closes out the group and can then try to rejoin.
               |
I assume you are saying "the group member times out" here?

So after a rekey packet loss the endpoint stalls for the duration of the
time (i.e. minutes?) that elapses until the next rekey?

> include the identification of RMT protocol.

Perhaps I've overlooked it, but where in GSAKMP or the policy token does
one declare vendor-specific extensions? The "Protocol ID" field makes no
mention of this capability. An old GSAKMP ID (v02?) I have floating around
mentions that the Vendor ID payload was removed but did not explain why.

There is no IANA considerations section in msec-tokenspec-sec-00.txt for
this and other identifier fields.

> We hopefully will make

---

From: Mark Baugher <[email-masked]>
Date: Tue, 05 Aug 2003 22:30:48 -0700

hi George,
   I think the interoperability issue that you mention below could happen 
on any element of policy.  Somehow the policy is determined and if it has 
advanced or new features than some legacy members don't support, then there 
will be an interoperability problem.

Best regards, Mark

---

From: George Gross <[email-masked]>
Date: Wed, 6 Aug 2003 07:56:38 -0400 (EDT)

Hi Mark,

> will be an interoperability problem.

Ok, so would you agree then that a version number should be introduced in
the group member's registration "request to join" message?

Also, in a related post to this list, I had proposed the protocol feature
of having a "critical" or mandatory to implement flag in the key
management protocol's Type/Length/Value encodings. This mechanism
specifically addresses this backward compatibility interoperability issue.

I would not expect this to be a controversial concept to require in
GSAKMP or GDOI. It is a basic protocol design feature, examples of which
can be found in IKE, Diameter, L2TP, etc... BTW in these protocols, it is
illegal to mark a vendor specific TLV critical.

br,
	George

---

From: Mark Baugher <[email-masked]>
Date: Wed, 06 Aug 2003 10:13:10 -0700

George,
   GDOI has a version number in it.  So does GSAKMP. Perhaps we should 
mention this need in gkmarch.

Mark

---

From: George Gross <[email-masked]>
Date: Wed, 6 Aug 2003 15:16:13 -0400 (EDT)

Mark,

On Wed, 6 Aug 2003, Mark Baugher wrote:

> George,
>    GDOI has a version number in it.  So does GSAKMP.

Oops, sorry, my e-mail was not precise. What I really should have said was
"the semantics for mismatched version numbers between GCKS and group
member are currently underspecified...".

In GSAKMP, there are Notify payloads for invalid version numbers, but I
did not find any text explaining when that would be triggered. I think
that this needs to be added, in alignment with the requirement for
backward compatibility.

In GDOI there is no explicit discussion of version number processing. In
fact, RFC3547 does not have the word "error" in it at all. Amazing, an
error free protocol ;o) The text in section 3.2.2 seems to hint ISAKMP
version error processing is implied? it would be reasonable for GDOI v2 to
say more here....

> Perhaps we should

Yes, I might go so far as to say that backward compatibility would be
important to have specified as a MUST. If we are talking about large-scale
multicast, it is likely that a protocol software upgrade transition from
v1->v2 will straddle large numbers of endpoints, and could take many
weeks/months.

In other words, the GCKS is required to accept any group member protocol
version less than or equal to the highest version the GCKS supports.

George

---

From: Brian Weis <[email-masked]>
Date: Wed, 06 Aug 2003 15:03:36 -0700

Hi George,

> version error processing is implied? it would be reasonable for GDOI v2 to

I absolutely agree with your conclusion.

New attributes can be added to GDOI (e.g., KEK attributes), and these
could add a new policy attribute such as "must use a reliable multicast
protocol". But as you imply, there is no clear specification of how a
receiver would deal with the new attribute (e.g., ignore, or drop the
session). That should be made more clear in GDOI v2 as well.

> version less than or equal to the highest version the GCKS supports.

I'm not sure if requiring this is a good idea. If v1 had a security
problem that v2 fixed, I'm not sure all protocols supporting v2 should
be required to speak the insecure v1 version. But a discussion of the
migration issue might be a good idea, with recommendations on what to
do.

Thanks,
Brian

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

---

From: canetti <[email-masked]>
Date: Wed, 13 Aug 2003 16:40:08 -0400 (EDT)

George, 

Your proposal to add a (currently unused) field to the policy token
specifying the RMT protocl in use ofr rekeying sounds like a reasonable
thing to do. The cost is minimal, and although the chance it will ever be
used are small, if we do need it and dont have it it will be ugly.

But I'm weary of the requirement that future versions must be backwards
compatible. You sometime want future versions to explicitly NOT be
backwards compatible, eg when there is a security hole found in the old
version. In fact, in such a case you;d want to protect against "version
rollback" attacks. (cf the SSL v2/v3 story).

Ran

---

From: George Gross <[email-masked]>
Date: Thu, 14 Aug 2003 05:07:48 -0400 (EDT)

Hi Ran,

> used are small, if we do need it and dont have it it will be ugly.

good, I think this parameter will prove its worth in the long-term...

given the discussions on the policy token in a parallel thread, I'd like
to hear the GSAKMP folk weigh in on this parameter too...

> rollback" attacks. (cf the SSL v2/v3 story).

Yup, see what you mean...so each GSAKMP (or GDOI) GCKS needs to be able to
refuse a GM request to join for those protocol versions that are on the
"drain bamaged" version list ;o) and in the inverse direction, GM should
be able to decline membership in a group whose GCKS software version is on
that list.

Would the "drain bamaged version list" make sense to add to the policy
token? I'm leaning towards "yes", as it would allow a GM to offer a
mutually acceptable version in the request to join...

George

---

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

See inline:

> mutually acceptable version in the request to join...

In principle you're right. But this is another one of those "extension
fields" that may well never be necessary. Perhaps it will suffice to leave 
some "currently unused" fields in the policy token. If the need ever comes
up, it should be easy to update the standard (and its implementations) to
pur concrete meaning to those fields.

Ran

---

From: George Gross <[email-masked]>
Date: Thu, 14 Aug 2003 09:28:54 -0400 (EDT)

Hi Ran,

On Thu, 14 Aug 2003, canetti wrote:

<snip>
> pur concrete meaning to those fields.

I am not comfortable with a fixed data structure policy token, that does
not have the ability to extend gracefully. As I mentioned in the parallel
policy token e-mail thread, I think a strong extensibility case can be
made for TLV encoded group policy token.  The set of TLV not explicitly
present in a given token would have an implicit default value and
semantics. In the cases we've been discussing, we've identified two
candidate TLV: RMT policy, version blacklist. Once we've decided the
"minumum MUST implement set", I could easily imagine many other TLV being
added in an incremental way as our understanding of the problem space
matures...

George

> Ran
<snip>

---

From: "hugh harney" <[email-masked]>
Date: Thu, 14 Aug 2003 14:55:21 -0400

George,

I believe that we are just scratching surface of the capabilities of a
security policy token. There are many more fields that can be useful given
different applications (IPSec, SMIME, collaborative environments...) and
different communication architectures (IP networks, space networks,
wireless...).

This is NOT GSAKMP centric. This expandable Policy Token that will be good
for the foreseeable future is a goal onto itself. GSAKMP should reference a
GSAKMP policy token that is optimized for the current target applications.
GSAKMP "the protocol" will specify a policy token ID field to allow the
incorporation of future Policy Tokens.

There are two efforts taking place - GSAKMP is moving forward using a
workable Policy Token AND the MSEC community is beginning to discuss and
specify generic security policy tokens. The two efforts are separate. The
GSAKMP protocol should not be held up from advancement unnecessarily. I feel
that the convergence to a general Policy Token that will accommodate a wide
range of applications and communication environments will evolve over
several years. I'm strongly in favor of decoupling these two efforts. Let
GSAKMP proceed to standardization with a simple policy token, and with the
mechanisms to accommodate upgraded versions. Let the working group proceed
with the definition of the next version of a Policy Token.

GSAKMP will ensure that the mechanisms to accommodate future versions of the
MSEC Policy Token are planned for in the basic protocol.

Hugh

----- Original Message ----- 
From: "George Gross" <[email-masked]>
To: "canetti" <[email-masked]>
Cc: "George Gross" <[email-masked]>; "Mark Baugher" <[email-masked]>;
<[email-masked]>
Sent: Thursday, August 14, 2003 5:07 AM
Subject: Re: [MSEC] Next gkmarch I-D

> > > > > > > > >I largely concur with Mark's outline, in that having the
GKM-arch
> > > > > specify
> > > > > > > > >the base error recovery is a minimum starting point.
However, I
> > > > > would also
> > > > > > > > >require that the group policy token have the hooks (i.e.
reserved
> > > > > TLV) for
> > > > > > > > >To get this capability, at first sight it seems we need: an
RMT
> > > > > protocol
> > > > > > > > I would not put an identifier into a group key management
protocol
> > > > > for an
> > > > > > > > SPKI).  But I don't think we lose anything with the status
quo,
> > > > > which is to
> > > > > > > > use a sequence number and periodic retransmission of the
re-key
> > > > > message.