Subject: [MSEC] Next gkmarch I-D

From: Mark Baugher <[email-masked]>
Date: Tue, 29 Jul 2003 13:49:14 -0700

Hi,
   I have posted two notes to msec about reliable delivery of re-key 
messages.  We want to discuss the role of reliable multicast in the MSEC 
Group Key Management I-D.  In outline form, here is what I think we should 
say in the I-D.

1. The Re-key message may be sent multicast and may be sent using reliable 
multicast.

2. There are multiple types of reliable multicast protocols and products 
that have different properties.

3.  There are no reliable multicast protocols that are standards - yet.

4.  The RECOMMENDED design is to NOT incorporate a special-purpose reliable 
multicast protocol for the Re-key message but to use existing products and 
future standards for reliable multicast service when such a service is 
needed for the Re-key message.

5.  The minimal operational capability of an MSEC group key management 
protocol is to support sequencing of the Re-key messages through a sequence 
number, which is authenticated along with the Re-key message.  A sender of 
Re-key messages may re-transmit multiple copies of the message provided 
that they have the same sequence number and this repetition is a 
rudimentary means of overcoming loss along the network path.  A member who 
receives the Re-key message will check the sequence number to detect 
duplicate and missing Re-key messages.  The member receiver will discard 
duplicate messages that it receives.

6.  The group member might be out of synchrony with the GCKS if it receives 
a Re-key message having a sequence number that is more than one greater 
than the last sequence number processed.  This is one means by which the 
GCKS member detects that it has missed a Re-key message.  A second means 
occurs when the application that uses the key notifies its group key 
provider, which is the GCKS member.   What action the GCKS member takes is 
a matter of group policy:  The GCKS member SHOULD log the condition and MAY 
contact the GCKS to re-run the re-registration protocol to obtain a fresh 
group key.  The group policy needs to take into account boundary 
conditions, such as re-ordered Re-key messages where rekeying is so 
frequent that two messages can get reordered in an IP network.   The group 
key policy also needs to take into account the potential for denial of 
service attacks where an attacker delays or deletes a Re-key message in 
order to force a subnetwork or subset of the members to synchronously 
contact the GCKS.

I think we can write a short section based on this outline.

Mark

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 29 Jul 2003 16:59:03 -0400

Mark and I went back and forth on this topic and decided that we should 
take the discussion to the list.  So, here is my response.

+++++++++++
I have additional thoughts that I was discussing with Thomas, along the 
following lines.

Some of the reliable rekey transport protocols use FEC (which is one of 
the RMT experimental track protocols) with NACKs for feedback.  There 
are two ways (perhaps more) for members to provide feedback to the 
GCKS.  One is to have a secure feedback channel between the members and 
the GCKS.  The other is to have members that go out of sync to 
re-register with the GCKS to download the latest SAs, but in doing so 
allow a feedback message be part of the re-registration request.  This 
will allow the GCKS to change the FEC encoding parameters.

And yes, these thoughts and discussion should be part of the GKMarch I-D.

A general question is whether RM protocols need any special signaling 
that need to be part of the MSEC protocols.  Feedback (some form of 
member to GCKS communication)  protection comes to mind.

cheers,
Lakshminath

++++++++++

Mark Baugher wrote:

> messages.  We want to discuss the role of reliable multicast in the 
> MSEC Group Key Management I-D.  In outline form, here is what I think 
> we should say in the I-D.
>
> 1. The Re-key message may be sent multicast and may be sent using 
> reliable multicast.
>
> 2. There are multiple types of reliable multicast protocols and 
> products that have different properties.
>
> 4.  The RECOMMENDED design is to NOT incorporate a special-purpose 
> reliable multicast protocol for the Re-key message but to use existing 
> products and future standards for reliable multicast service when such 
> a service is needed for the Re-key message.
>
> protocol is to support sequencing of the Re-key messages through a 
> sequence number, which is authenticated along with the Re-key 
> message.  A sender of Re-key messages may re-transmit multiple copies 
> of the message provided that they have the same sequence number and 
> this repetition is a rudimentary means of overcoming loss along the 
> network path.  A member who receives the Re-key message will check the 
> sequence number to detect duplicate and missing Re-key messages.  The 
> member receiver will discard duplicate messages that it receives.
>
> 6.  The group member might be out of synchrony with the GCKS if it 
> receives a Re-key message having a sequence number that is more than 
> one greater than the last sequence number processed.  This is one 
> means by which the GCKS member detects that it has missed a Re-key 
> message.  A second means occurs when the application that uses the key 
> notifies its group key provider, which is the GCKS member.   What 
> action the GCKS member takes is a matter of group policy:  The GCKS 
> member SHOULD log the condition and MAY contact the GCKS to re-run the 
> re-registration protocol to obtain a fresh group key.  The group 
> policy needs to take into account boundary conditions, such as 
> re-ordered Re-key messages where rekeying is so frequent that two 
> messages can get reordered in an IP network.   The group key policy 
> also needs to take into account the potential for denial of service 
> attacks where an attacker delays or deletes a Re-key message in order 
> to force a subnetwork or subset of the members to synchronously 
> contact the GCKS.
>

---

From: Andrea Colegrove <[email-masked]>
Date: Tue, 29 Jul 2003 18:09:28 -0400

Mark,

It might be preferable not to suggest any particular reliable multicast 
standards as they become available.  The r-multicast standards are more 
focussed on IP-multicast.  I believe that our charter was changed to 
focus more on group communications in general (I may be wrong as the 
charter does not appear to be updated on ietf.org.)  It would be a shame 
to needlessly couple the rekey protocol with transport protocols and 
lose the application layer multicast folks.  Perhaps that is what you 
were saying in 3 and 4, but I am misreading your intent to include 
reliable standards as they are available?

Also, another suggestion, for environments where a simple 
re-registration is not a desireable method of recovery from lost rekey 
messages, it might be proposed as a matter of that group's policy that 
they use more loss-tolerant methods such as subset-difference for rekey. 
 Oops, I said the P-word again :-)  Anyway, loss-tolerant rekey schemes 
deserve a paragraph as well.

--- Andrea

---

From: Mark Baugher <[email-masked]>
Date: Tue, 29 Jul 2003 16:35:58 -0700

hi Andrea,

At 06:09 PM 7/29/2003 -0400, Andrea Colegrove wrote:
>focussed on IP-multicast.  I believe that our charter was changed to focus 
>more on group communications in general (I may be wrong as the charter 
>does not appear to be updated on ietf.org.)  It would be a shame to 
>needlessly couple the rekey protocol with transport protocols and lose the 
>application layer multicast folks.  Perhaps that is what you were saying 
>in 3 and 4, but I am misreading your intent to include reliable standards 
>as they are available?

My intent is de-couple reliable multicast transport from key management.  I 
think that's clear from my previous posts but not necessarily from the 
outline.   The outline addresses the question of what to do *if* a reliable 
multicast service is wanted for the rekey message, which may be sent via IP 
multicast and thus using reliable multicast if desired.  The outline points 
out that there are no standards yet and recommends that we not standardize 
a reliable multicast protocol as part of group key management.  For those 
persons who want reliable multicast service for the rekey, and a couple 
have voiced this need on this mailing list, I would recommend that they use 
one of the RMT standards when RMT produces them.  RMT keying will need to 
used msec group key management in the form of GDOI, GSAKMP or possibly 
MIKEY (though this application is not high on MIKEY's list of 
applications).  So it might sound circular for me to then recommend use of 
an RMT protocol for group key management.  But for those who need it, the 
outline recommends that RMT keys be established through the registration 
protocol.

I think we're in agreement and I just need to clarify my intent.

>Also, another suggestion, for environments where a simple re-registration 
>is not a desireable method of recovery from lost rekey messages, it might 
>be proposed as a matter of that group's policy that they use more 
>loss-tolerant methods such as subset-difference for rekey.

I don't think SD is loss tolerant.  I expect that an SD keying message will 
look more like a small file transfer, no part of which can be lost.  Also, 
we need to keep in mind that SD is not an open standard and has known IPR 
encumbrances.  I don't think it looks promising for IETF standardization at 
the present time.

>Oops, I said the P-word again :-)

Hopefully someone will start on the msec policy specification soon.

>Anyway, loss-tolerant rekey schemes deserve a paragraph as well.

I don't understand your point about SD.  We did have a presentation from 
Jessica Staddon in GSEC some time back 
(http://www.securemulticast.org/GSEC/gsec2_staddon.pdf) on this 
topic.  Frankly, I have not looked closely at the relevant literature on 
loss-tolerant rekey.  Perhaps you're right and we should add a paragraph on 
it.  I'm open to suggestions.

Mark

>> Group Key Management I-D.  In outline form, here is what I think we 
>> should say in the I-D.
>>
>>products and future standards for reliable multicast service when such a 
>>service is needed for the Re-key message.
>>
>>sequence number, which is authenticated along with the Re-key message.  A 
>>sender of Re-key messages may re-transmit multiple copies of the message 
>>provided that they have the same sequence number and this repetition is a 
>>rudimentary means of overcoming loss along the network path.  A member 
>>who receives the Re-key message will check the sequence number to detect 
>>receives a Re-key message having a sequence number that is more than one 
>>greater than the last sequence number processed.  This is one means by 
>>which the GCKS member detects that it has missed a Re-key message.  A 
>>second means occurs when the application that uses the key notifies its 
>>group key provider, which is the GCKS member.   What action the GCKS 
>>member takes is a matter of group policy:  The GCKS member SHOULD log the 
>>condition and MAY contact the GCKS to re-run the re-registration protocol 
>>to obtain a fresh group key.  The group policy needs to take into account 
>>boundary conditions, such as re-ordered Re-key messages where rekeying is 
>>so frequent that two messages can get reordered in an IP network.   The 
>>group key policy also needs to take into account the potential for denial 
>>of service attacks where an attacker delays or deletes a Re-key message 
>>in order to force a subnetwork or subset of the members to synchronously 
>>contact the GCKS.
>>

---

From: Andrea Colegrove <[email-masked]>
Date: Tue, 29 Jul 2003 19:48:12 -0400

Mark

>> re-registration is not a desireable method of recovery from lost 
>> rekey messages, it might be proposed as a matter of that group's 
>> policy that they use more loss-tolerant methods such as 
>> subset-difference for rekey.
>
>
> I don't think SD is loss tolerant.  I expect that an SD keying message 
> will look more like a small file transfer, no part of which can be 
> lost.  Also, we need to keep in mind that SD is not an open standard 
> and has known IPR encumbrances.  I don't think it looks promising for 
> IETF standardization at the present time.
>
> I don't understand your point about SD.  We did have a presentation 
> from Jessica Staddon in GSEC some time back 
> topic.  Frankly, I have not looked closely at the relevant literature 
> on loss-tolerant rekey.  Perhaps you're right and we should add a 
> paragraph on it.  I'm open to suggestions. 

I believe that you can miss a rekey "event" and still be able to 
understand subsequent events (i.e., all your keys do not change as they 
do with some of the other schemes.)  While you would be out for a small 
epoch, you would be back in at the next rekey.  Also, smaller rekey 
messages will allow more resends within the same amount of bandwidth 
expended.

Didn't the authors of SD provide an I-D a little while back?  I am 
really largely ignorant of the I-D process, but I thought that the 
"thoughts" presented through the IETF are not encumbered.

--- Andrea

---

From: Mark Baugher <[email-masked]>
Date: Tue, 29 Jul 2003 18:46:59 -0700

hi

At 07:48 PM 7/29/2003 -0400, Andrea Colegrove wrote:
>>lost.  Also, we need to keep in mind that SD is not an open standard and 
>>has known IPR encumbrances.  I don't think it looks promising for IETF 
>>standardization at the present time.
>>
>>loss-tolerant rekey.  Perhaps you're right and we should add a paragraph 
>>on it.  I'm open to suggestions.
>
>understand subsequent events (i.e., all your keys do not change as they do 
>with some of the other schemes.)  While you would be out for a small 
>messages will allow more resends within the same amount of bandwidth expended.

With SD you would encrypt a session key with a key encrypting key that is 
derived from your current subset of the tree.  SD requires that the 
receiver have enough of that tree to be able to derive the keys from its 
particular subset.  That's the data structure that must be passed to the 
member in its entirety.

In this sense, SD is no different from LKH or OFT if the entire history of 
the latter algorithms were passed down with the tree.  SD does this much 
more efficiently in terms of storage and computation compared with LKH and 
OFT.  Unlike LKH and OFT, incremental updates to the tree are not needed by 
SD.  So, I would not use "loss tolerant" to describe SD.

>Didn't the authors of SD provide an I-D a little while back?

Yes they did.  But they let us know that their company had IPR on it and 
they would give us an IPR statement in the second revision of the I-D.  But 
they never did a second revision.

>I am really largely ignorant of the I-D process, but I thought that the 

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.

Mark

---

From: Hugh Harney <[email-masked]>
Date: Wed, 30 Jul 2003 10:05:58 -0400

Mark,

I completely agree with this outline on reliable delivery of re-key 
messages.

Hugh

On Tuesday, Jul 29, 2003, at 16:49 US/Eastern, Mark Baugher wrote:

> sequence number, which is authenticated along with the Re-key message. 
>  A sender of Re-key messages may re-transmit multiple copies of the 
> message provided that they have the same sequence number and this 
> repetition is a rudimentary means of overcoming loss along the network 
> path.  A member who receives the Re-key message will check the 
Hugh Harney							Sparta, Inc.
[email-masked]						7075 Samuel Morse Drive
(410) 872-1515 x203					Columbia, MD, 21046

---

From: canetti <[email-masked]>
Date: Thu, 31 Jul 2003 12:31:50 -0400 (EDT)

Mark,

Your outline looks good to me. It well represents the (unfortunately not
very well documented) understanding at SMUG, and indeed seems
like the right thing to do. See some small remarks inline.

Ran

> needed for the Re-key message.

I'm not sure we should recommend a design. There are many different
deployment scenarios, with very different needs. We should mandate the
rudimentary design and leave other designs optional. 
 
> I think we can write a short section based on this outline.

A couple more points:

* I think that the decision to mandate only the "rudimentary" reliability
mechanism should be well motivated in the text. Also, we can say that this
decision may be revisited in few years if/when other mechanisms will
become popular/standardized and it will make sense to mandate their
implementation.

* I think that we're missing a good comparative discussion of GKM
algorithms and their salient properties. The fact that SD can easily
revover from loss of rekey messages is a point to be highlighted. 

Mark > >

---

From: canetti <[email-masked]>
Date: Thu, 31 Jul 2003 12:37:23 -0400 (EDT)

...

If there is interest then I can ping the uthors regarding IP/ second version of
the I-D.

Ran

---

From: Mark Baugher <[email-masked]>
Date: Thu, 31 Jul 2003 09:50:20 -0700

Ran,
   My comments are inline.

At 12:31 PM 7/31/2003 -0400, canetti wrote:

> reliable

The question to be answered is should msec key management protocols 
incorporate a reliable multicast protocol.  If we recommend that they 
don't, then there is nothing for us to do.  If we recommend that they do, 
then we should provide some guidance for reliable multicast in group key 
management.  If we don't say anything, then it seems to me that we are 
overlooking an important question that has been raised in msec regarding 
the architecture of msec group key management.

> sequence
> receives

ok.

>revover from loss of rekey messages is a point to be highlighted.

I don't think it is true that SD can recover from lost rekey 
messages.  Andrea and I just had an exchange on this point.  A couple of 
years ago, J.Staddon made a presentation to GSEC on a mechanism that 
recovered from lost key management but that's different from an SD tree, 
which needs to be received in its entirety.  I think that the SD tree does 
not need rekey messages when members are evicted or join the tree, and 
that's not the same as saying that it is loss resilient.

ciao, Mark

---

From: canetti <[email-masked]>
Date: Thu, 31 Jul 2003 12:58:19 -0400 (EDT)

> the architecture of msec group key management.

We should certainly discuss the relevant arguments pro/con using RMT
protocols here. But in the end I'm not sure we should recommend anything
(or that our recommendation will be of any value. Each scenario would
have its own constraints.)

> that's not the same as saying that it is loss resilient.

Yes, you're right that there is a (subset :) difference here. But the end
result is similar: there is no need in any reliability mechanisms (not
even simple restransmission) 

Ran

---

From: Mark Baugher <[email-masked]>
Date: Thu, 31 Jul 2003 10:02:08 -0700

>If there is interest then I can ping the uthors regarding IP/ second 

That would be great.

thanks, Mark

---

From: George Gross <[email-masked]>
Date: Thu, 31 Jul 2003 11:58:30 -0400 (EDT)

Hi,
	comments inline...

br,
	George

> > > 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. 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?

---

From: canetti <[email-masked]>
Date: Thu, 31 Jul 2003 15:48:23 -0400 (EDT)

see inline:

> So a new SDR draft will have to match those IPR guidelines.

Ofcourse. There aer still several options there and we should ask them to
clarify which one they take.

> Re-transmission (BKR) to SDR could address the reliablity problem.

Thanks for pointing out (and thanks also to Sanjeev for the introduction).
It's ofcourse right that even in SDR a group member cannot rekey unless it gets
*Some* rekey message. The point was that if one gets lost then the next one
suffices. This is very different from schemes (such as FLAMES) where there are
no rekey messages and the rekeying is done completely off-line.

> protocol and its policy token.

I concur.

> group policy token spec. thoughts?

Since the GKMARCH document is not standards-track then the policy token
document seems like a better place.

Ran

BTW, another "last recourse" solution for the reliability of rekey messages is
to have the GCKS post the current rekey message at some public place (say, a
web-site). This way, when all else fails, but before re-registering, a member 
can try to download the current rekey message from that location. 
(The posting can ofcourse be replicated for scalability using standard techniques).

---

From: Mark Baugher <[email-masked]>
Date: Thu, 31 Jul 2003 13:36:03 -0700

Lakshminath,

At 04:59 PM 7/29/2003 -0400, Lakshminath Dondeti wrote:
>the RMT experimental track protocols) with NACKs for feedback.  There are 
>two ways (perhaps more) for members to provide feedback to the GCKS.  One 
>is to have a secure feedback channel between the members and the 
>GCKS.  The other is to have members that go out of sync to re-register 
>with the GCKS to download the latest SAs, but in doing so allow a feedback 
>message be part of the re-registration request.  This will allow the GCKS 
>to change the FEC encoding parameters.

In most cases, applying FEC to the re-key will be indistinguishable from 
simply resending the re-key message some number of times (re-key messages 
will often be less than the MTU of the path).   I believe there are 
applications that might benefit from something more complex, such as 
applications that send LKH or OFT trees.  The approach that I propose is to 
have a reliable multicast service provide this function rather than 
incorporate it into the group key management system.  With this approach, 
the GCKS does not concern itself with FEC encoding, NACKS, etc.

>And yes, these thoughts and discussion should be part of the GKMarch I-D.

Hugh agreed with my outline.  I think Andrea did once I clarified a couple 
of things.  Are you okay with it?

>A general question is whether RM protocols need any special signaling that 
>need to be part of the MSEC protocols.  Feedback (some form of member to 
>GCKS communication)  protection comes to mind.

If group key management is to provide keys for an RMT security protocol, 
then the keys and policies need to be defined for that data-security 
protocol in the registration protocol.  GDOI does this through the SA-TEK 
payload.  If group key management is going to use a secure RM protocol, 
then there will need to be signaling.  How this is done will be specified 
by the RMT.  Unless we plan to incorporate an RMP into group key 
management, I don't think we have to worry about the signaling yet.

ciao, Mark