Subject: [MSEC] Re-key as a separate, standards-track protocol specification

From: Mark Baugher <[email-masked]>
Date: Fri, 06 Jul 2001 21:44:37 -0700

http://search.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt took 
a surprising turn by introducing Re-key as a separate protocol.  David 
McGrew and Lakshminath Dondeti are working on a Re-key draft.  Up to this 
point, the Re-key message was part of GSAKMP, called "Re-key," and GDOI, 
called "GROUPKEY-PUSH."  Like many things between GSAKMP and GDOI, they 
have some differences and the latter uses ISAKMP encoding.

The authors discussed this at length and agreed to take the route of a 
separate specification though it is and may remain controversial.  There 
are a couple of ways that we can go here.  We could unbundle the key 
mangement protocol into truly separate protocols that interface through a 
security association database, as suggested in gkmarch.  I expect that GDOI 
and GSAKMP will continue to offer an integrated solution where the 
exchanges and messages are bundled into a single protocol.  We need to 
discuss these alternatives and the direction that msec key management will 
take over the next year.

My view is that the separate document should explore the issues such as 
implosion, member feedback, reliable delivery, and other concerns 
associated with Re-key, which can be sent either multicast or unicast.  It 
will also define a common encoding for key download and membership 
management that we will expect the msec key management protocols to adhere 
to.  I don't think we will achieve an identical message format so long as 
we expect to implement the Re-key message in diverse protocols such as 
IKE.  For this reason, I question whether this can be a standards-track 
protocol.

Mark

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

---

From: "David A. McGrew" <[email-masked]>
Date: Mon, 09 Jul 2001 14:00:51 -0400

Mark,

Mark Baugher wrote:
> security association database, as suggested in gkmarch.  

This approach has logical consistency and extensibility on its side.

> I expect that GDOI
> exchanges and messages are bundled into a single protocol.  

This is certainly possible, though I'd hope that the rekey protocol could be
easily picked up.

> We need to
> associated with Re-key, which can be sent either multicast or unicast.  

My thoughts as well.

> It
> to.  

Perhaps.  That depends on the extent to which the group key management is
separated from member mangement.  For example, if the mapping between LKH leaves
and members is defined externally from the rekey protocol, then that protocol is
pretty much agnostic about membership management, and can satisfy itself with
talking about nodes.

> I don't think we will achieve an identical message format so long as

To my mind, there can be a standardized re-key protocol, though the architecture
need not mandate the use of that particular protocol.  

thanks,

David

---

From: Thomas Hardjono <[email-masked]>
Date: Tue, 10 Jul 2001 11:25:38 -0400

David,

>This approach has logical consistency and extensibility on its side.

OK, this is true to some extent.  The danger I see is that we end-up
with several document-pairs for each group key management protocol:

    (a) GDOI-Registration and  (b) GDOI-Rekey, and
    (c) GSAKMP-Registration and (d) GSAKMP-Rekey
    (e) Prot-X-Registration and (f) Prot-X-Rekey

It would remain to be seen if (a) can function with (d)
or (c) with (b), etc. and the various combinations.

>pretty much agnostic about membership management, and can satisfy itself with

Good point.  I think we should look into if membership management
is an application-layer issue or wether member data can be managed
at layer 3/4 and be accessible by the application.

Perhaps a common Membership Management Database (MMD)
can be created which contains information such as:

   - a member's IP address(s)
   - a member's certificate
   - the group-IDs of all multicast groups a member is currently joining
   - the status of a member (eg. active or sleep-mode)
   - the OFT/LKH tree-ID that a member is employing
   - the keys of the LKH/OFT key-tree that a member is known
     to have been given (or perhaps just the key-IDs)
   - the GCKS designated as the primary GCKS of that member (in anticipation
     of a distributed GCKS).
   - IGMP membership information
   - others (please add)

All of these should be at the GCKS/KDC MMD, while
some may perhaps reside also at the member/client side MMD.

The issue as to *who* decides some of the entry-values, I think,
is a Group Policy/Owner matter (at some level).  (Not that I'm trying
to push the problem under the carpet :)
Things like IGMP membership information are available only at
group "run time".

I think we should define what goes into that MMD and come-up
with a simple list.

Later we can add more entries to the MMD when we address
the broader definition of a group from a layer-3-parameters perspective.
That is, later (soon) we will need to address
also the notion of "Group" versus "Session" for
cases where two or more multicast addresses are used
for the same collection of members/hosts (ie. video, audio).

If we can see the MMD sitting next to the SAD, then perhaps
the MMD is the "interface" (meeting-point) of all of:

    - IGMP (or IPv6 MLD) -- that may need application-driven
      membership parameters to carry-out IGMP joins/prunes authentically.

    - the Rekey Protocol -- that may need parameters to identify
      tree-IDs, node-key-IDs, member-IDs and Group-IDs

    - the Application above -- that may set some of these parameters.

(Have I confused myself and everyone else :).

thomas
------

---

From: Thomas Hardjono <[email-masked]>
Date: Tue, 10 Jul 2001 10:47:07 -0400

Mark,

>have some differences and the latter uses ISAKMP encoding.

In both GSAKMP and GDOI the "Re-key" message looks deceptively simple, since
it is a unidirectional message from the GCKS to the member.
Both GSAKMP and GDOI the Rekey message hides much of the
details involved with managing the LKH/OFT tree, both on the GCKS side
and the member/client side.

I am still rather vague about the meaning of "Re-key as a separate
protocol", for if we follow what is in GSAKMP and GDOI then
the "protocol" would only consist of 2 (control) message types (commands
and messages carrying keying material).

Initially I sounded the idea of developing (as far as possible)
a common payload format for LKH and OFT, so that an implementation
could do both without too much differences in code.
The understanding was that it would be up to the implementor
to implement the mechanics of how to re-shape the key-tree (eg. after
a member joins/leaves).

>security association database, as suggested in gkmarch.

There are a number of issues that need to be clarified and/or decided
upon:

  - would the Rekey Protocol be unidirectional or would a feedback
    channel be needed by a member to the GCKS (in the context of rekeying
    situation/scenario)?

  - does the Rekey Protocol assume that the Cat-1 SA is still around
    and does it use it or rely on it in anyway?

  - does the Rekey Protocol assume reliability of the control channel?

  - would the Rekey Protocol look different for cases such as ALC
    and other solutions that embedd rekeying-material in
    the data stream?  Should it try to address these now (or later)?

  - does the Rekey Protocol manage keys or SAs as well?

  - if the interface is the SAD, how to delete entries when
    a rekey occurs and the SAs are "partly" modified (eg. keys
    changed, but not the other materials, such as the SPI)?
etc.

>I expect that GDOI and GSAKMP will continue to offer an integrated 
>solution where the exchanges and messages are bundled into a single 
>protocol.  We need to discuss these alternatives and the direction that 
>msec key management will take over the next year.

  - Is the question of bundling a matter of architecture clarity and
    RFC-readability, or does it go deeper into the fact that
    the mechanics of the implementation would be simplified
    if the implementation of Registration and the implementation
    of the Rekey were truly separated?

>associated with Re-key, which can be sent either multicast or unicast.

Yes, OK, agree.

>It will also define a common encoding for key download and membership 

Yes, that was what we set out to at least do, initially.

>I don't think we will achieve an identical message format so long as we 
>expect to implement the Re-key message in diverse protocols such as 

I think the aim initially was to write an RFC for LKH/OFT so that
a developer can easily implement one or both of LKH and OFT.
Whether LKH and OFT are so different that this aim cannot be accomplished,
must first be studied. If there is sufficient similarities, then
perhaps the differences can be put into separate sections/subsections of 
the document.

thomas
------

---

From: "Lakshminath Dondeti" <[email-masked]>
Date: Tue, 10 Jul 2001 19:44:42 -0400

Thomas,

Please see inline:

> to implement the mechanics of how to re-shape the key-tree (eg. after

We probably can abstract all the messaging requirements of LKH and its 
cousins.  For example, we can say the KDC needs to i) send changes
to the key tree, ii)changes in assignment of members to leaf key nodes,
and iii)new keys along with their IDs.  That information is probably
sufficient for a member to figure out which keys it needs to decrypt.
I have seen some schemes which work with less information than that.

>     changed, but not the other materials, such as the SPI)?

Thanks much for this list.  David and I are addressing most of the 
above issues and you might keep us honest :) when you review the 
rekey I-D. 

In particular, I believe ALC for reliable transport of rekey messages
should be an option in the rekey protocol.

> perhaps the differences can be put into separate sections/subsections of

I think the three things (changes to key nodes, changes in member 
assignment and new keys) I listed earlier are common to LKH/OFC/OFT.

best regards,
Lakshminath

---

From: "Sandro Rafaeli" <[email-masked]>
Date: Wed, 11 Jul 2001 10:44:57 +0100

|  -----Original Message-----
|  From: [email-masked]
|  [mailto:[email-masked]]On Behalf Of
|  Lakshminath Dondeti
|  Sent: 11 July 2001 00:45
|  To: [email-masked]
|  Subject: Re: [MSEC] Re-key as a separate, standards-track protocol
|  specification
|
|  (deleted text)
|
|  We probably can abstract all the messaging requirements of
|  LKH and its
|  cousins.  For example, we can say the KDC needs to i) send changes
|  to the key tree, ii)changes in assignment of members to leaf
|  key nodes,
|  and iii)new keys along with their IDs.  That information is probably
|  sufficient for a member to figure out which keys it needs to decrypt.
|  I have seen some schemes which work with less information than that.

I wrote a document on an OFT implementation I did in Java. It contains among
other things a description of the REKEY protocol I used (message types and
formats). It is a very simple protocol, but seems to do the job. After I
wrote this document, I implemented another key management protocol
(tree-based; very similar to the one of Canetti) and I can use my messages
to convey either of them. If anyone is interested in having a look at it I
can send you a copy of the document.

Regards,
Sandro.

---

From: "David A. McGrew" <[email-masked]>
Date: Wed, 11 Jul 2001 09:46:32 -0400

> or (c) with (b), etc. and the various combinations.

I agree that it would probably not be possible to make this method work given
two existing protocols.  However, I do think that definining the interfaces
between the protocols is the appropriate thing for the architecture to do, and
is the only way to make the architecture protocol-independent.

I'm thinking that what is needed here is a STREAMS architecture for security
protocols, in which there are well defined interfaces between each layer, and
any module conforming to those interfaces will work in the architecture.  I
think that the STREAMS analogy is a good one, because one of the major issues
that technology deals with is the naming/addressing of endpoints, and
interfacing the naming of different protocols is an issue in the crypto
architecture.  (Please no anti-STREAMS flames!  I run BSD all the time!) 

>    - the OFT/LKH tree-ID that a member is employing

I think that the node with which a member is associated should be dynamic, so
that groups can shrink and grow, so I'd have the initial node assigned in the
registration, but the rekey protocol control it once that protocol started.  Or
did you mean that the MMD exists across both the registration and rekey
protocols?

> (Have I confused myself and everyone else :).

I don't think so, but you tell me :-)  I see the MMD as a set of data which is
written and read by the registration and rekey protocols (and perhaps other
processes).  Presumably there would be an interface defining who writes what
when, and what data are allowed to be read when.

thanks,

David

---

From: "David A. McGrew" <[email-masked]>
Date: Wed, 11 Jul 2001 10:33:13 -0400

Thomas,

good to hear your thoughts, more below:

> and messages carrying keying material).

Does a protocol need to have more than one message to be a protocol?  I don't
honestly know.

Sure, there aren't many messages, but the tree-based keying involves some
non-trivial processing.

> to implement the mechanics of how to re-shape the key-tree (eg. after

And that's exactly what we're working towards.  We want the protocol to be
independent of the many different design choices that are possible in tree-based
keying.  For example, the KDC can assign new members anywhere in the tree, can
reassign members to different nodes upon deletion or to balance the tree, can
create but not assign keys in the tree for future use, and so on.  It's clearly
best to allow implementations the freedom to make these choices.

>     channel be needed by a member to the GCKS (in the context of rekeying

We thought that an optional feedback channel (something like RTP's RTCP receiver
reports) would be worthwhile, but it's really an open issue.

>     and does it use it or rely on it in anyway?

This is an important unresolved design decision.

>   - does the Rekey Protocol assume reliability of the control channel?

No.  Our thoughts are that the KDC -> member messages should be idempotent, so
that KDC has the option of using repetition to achieve forward error
correction.  Achieving idempotence is easy enough, and repetition seems to be a
sensible way of achieving reliability.

>     the data stream?  Should it try to address these now (or later)?

Sorry, what's ALC?

>   - does the Rekey Protocol manage keys or SAs as well?

Our thoughts are that it should transport the Data Security SAs, since a change
in the group key due to membership changes implies that the keys which it
protects should be changed as well.

>     changed, but not the other materials, such as the SPI)?

Is it possible in MSEC to change the keys for a fixed SPI?  

thanks,

David

---

From: "Carl F. Muckenhirn" <[email-masked]>
Date: Wed, 11 Jul 2001 11:01:06 -0400

On 7/6/01 at 9:44 PM -0700, Mark Baugher wrote:

>http://search.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt 
>took a surprising turn by introducing Re-key as a separate protocol. 
>David McGrew and Lakshminath Dondeti are working on a Re-key draft. 
>Up to this point, the Re-key message was part of GSAKMP, called 
>"Re-key," and GDOI, called "GROUPKEY-PUSH."  Like many things 
>between GSAKMP and GDOI, they have some differences and the latter 
>uses ISAKMP encoding.
>
>The authors discussed this at length and agreed to take the route of 
>a separate specification though it is and may remain controversial. 
>There are a couple of ways that we can go here.  We could unbundle 
>the key mangement protocol into truly separate protocols that 
>interface through a security association database, as suggested in 
>gkmarch.  I expect that GDOI and GSAKMP will continue to offer an 
>integrated solution where the exchanges and messages are bundled 
>into a single protocol.  We need to discuss these alternatives and 
>the direction that msec key management will take over the next year.

In relooking at the gkmarch document, it is unclear that within the 
document you are consistent. The requirements stated in "2.0 
Requirements for a group key management protocol" indicate that a 
group rekey is part (a function) of the group key management protocol.

Requirement 2. "Keys ... will be periodically refreshed."
Requirement 3. "Key material must be delivered securely ... and 
refreshed securely at the end of the key lifetime."
Requirement 6. "It must be possible to provide re-key for the group ..."

Your description in 3.1 (2) of a "rekey protocol" as optional implies 
that the requirements above (mandates) will not be met. Your note 
that there may be other ways of causing members to arrive at a new 
key, simply states that there are protocols which do not require data 
transmission, that's ok, its still a protocol.

>My view is that the separate document should explore the issues such 
>as implosion, member feedback, reliable delivery, and other concerns 
>associated with Re-key, which can be sent either multicast or 
>unicast.  It will also define a common encoding for key download and 
>membership management that we will expect the msec key management 
>protocols to adhere to.  I don't think we will achieve an identical 
>message format so long as we expect to implement the Re-key message 
>in diverse protocols such as IKE.  For this reason, I question 
>whether this can be a standards-track protocol.

I think all of these issues are important, but I don't believe that 
they'll be able to be handled by a "rekey-only" protocol. For 
example, if we want to work on reliable delivery, what happens when 
its not delivered, we pop back over to some other protocol. I think 
it is safer to keep all elements of the group key management protocol 
together to assure coverage of the features and functions.

>Mark

carl.
-- 
Carl F. Muckenhirn
Division Manager
SPARTA, Inc.
Security Engineering Division
9861 Broken Land Parkway, Suite 300
Columbia, Maryland  21046
410.381.9400 x208
410.381.5559 (fax)

---

From: "David A. McGrew" <[email-masked]>
Date: Wed, 11 Jul 2001 13:08:23 -0400

> can send you a copy of the document.

could you please post a pointer to the document to the list, or summarize the
message formats for the working group?

thanks,

David
[email-masked]

---

From: "Sandro Rafaeli" <[email-masked]>
Date: Wed, 11 Jul 2001 18:32:28 +0100

David,

The document can be found at
http://www.comp.lancs.ac.uk/computing/users/rafaeli/oft.zip

Any comments are welcomed,
Sandro.

|  -----Original Message-----
|  From: [email-masked]
|  [mailto:[email-masked]]On Behalf Of David A. McGrew
|  Sent: 11 July 2001 18:08
|  To: Sandro Rafaeli
|  Cc: [email-masked]
|  Subject: Re: [MSEC] Re-key as a separate, standards-track protocol
|  specification
|  
|  
|  Sandro Rafaeli wrote:
|  > 
|  > |  -----Original Message-----
|  > |  From: [email-masked]
|  > |  [mailto:[email-masked]]On Behalf Of
|  > |  Lakshminath Dondeti
|  > |  Sent: 11 July 2001 00:45
|  > |  To: [email-masked]
|  > |  Subject: Re: [MSEC] Re-key as a separate, 
|  standards-track protocol
|  > |  specification
|  > |
|  > |  (deleted text)
|  > |
|  > |  We probably can abstract all the messaging requirements of
|  > |  LKH and its
|  > |  cousins.  For example, we can say the KDC needs to i) 
|  send changes
|  > |  to the key tree, ii)changes in assignment of members to leaf
|  > |  key nodes,
|  > |  and iii)new keys along with their IDs.  That 
|  information is probably
|  > |  sufficient for a member to figure out which keys it 
|  needs to decrypt.
|  > |  I have seen some schemes which work with less 
|  information than that.
|  > 
|  > I wrote a document on an OFT implementation I did in Java. 
|  It contains among
|  > other things a description of the REKEY protocol I used 
|  (message types and
|  > formats). It is a very simple protocol, but seems to do 
|  the job. After I
|  > wrote this document, I implemented another key management protocol
|  > (tree-based; very similar to the one of Canetti) and I can 
|  use my messages
|  > to convey either of them. If anyone is interested in 
|  having a look at it I
|  > can send you a copy of the document.
|  
|  could you please post a pointer to the document to the list, 
|  or summarize the
|  message formats for the working group?
|  
|  thanks,
|  
|  David
|  [email-masked]
|  
|  
|  > 
|  > Regards,
|  > Sandro.
|  > 
|  > _______________________________________________
|  > 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: Mark Baugher <[email-masked]>
Date: Wed, 11 Jul 2001 10:43:47 -0700

At 11:01 AM 7/11/2001 -0400, Carl F. Muckenhirn wrote:
>>David McGrew and Lakshminath Dondeti are working on a Re-key draft. Up to 
>>this point, the Re-key message was part of GSAKMP, called "Re-key," and 
>>GDOI, called "GROUPKEY-PUSH."  Like many things between GSAKMP and GDOI, 
>>they have some differences and the latter uses ISAKMP encoding.
>>
>>security association database, as suggested in gkmarch.  I expect that 
>>GDOI and GSAKMP will continue to offer an integrated solution where the 
>>discuss these alternatives and the direction that msec key management 
>>will take over the next year.
>
>document you are consistent. The requirements stated in "2.0 Requirements 
>for a group key management protocol" indicate that a group rekey is part 
>(a function) of the group key management protocol.
>
>Requirement 3. "Key material must be delivered securely ... and refreshed 
>securely at the end of the key lifetime."
>Your description in 3.1 (2) of a "rekey protocol" as optional implies that 
>the requirements above (mandates) will not be met. Your note that there 
>may be other ways of causing members to arrive at a new key, simply states 
>that there are protocols which do not require data transmission, that's 
>ok, its still a protocol.

We are not talking about "re-key" in the generic meaning of the word:  When 
a threshold is passed on the lifetime of a key, the member can be 
programmed to use a new Registration exchange to establish a new SA and 
thereby "refresh" the key.  We are talking about a specific message called 
the "Re-key protocol message."  Maybe it will be multiple messages.

>>message format so long as we expect to implement the Re-key message in 
>>diverse protocols such as IKE.  For this reason, I question whether this 
>>can be a standards-track protocol.
>
>they'll be able to be handled by a "rekey-only" protocol. For example, if 
>we want to work on reliable delivery, what happens when its not delivered, 
>we pop back over to some other protocol. I think it is safer to keep all 
>elements of the group key management protocol together to assure coverage 
>of the features and functions.

I agree with your conclusions though I'm a bit shaky on your premises.

Mark

---

From: Thomas Hardjono <[email-masked]>
Date: Sat, 14 Jul 2001 15:18:05 -0400

David,

> >     the data stream?  Should it try to address these now (or later)?

Sorry David.  ALC is the (latest) name for the FEC-based reliable multicast
and similar protocols.

I should think that from the perception of a Rekeying protocol,
FEC/ALC is just a transport mechanism.  That is, the determination
of how the Tree-Keys is broken-up and sent should not be
be transport dependent.

>Is it possible in MSEC to change the keys for a fixed SPI?

OK, so this is an interesting question :)  I think a while ago
the question came-up about the definition of SAs and GSAs.

So, technically-speaking, if the key is part of the definition
of an instance of an SA, then changing it (while keeping other
parameters fixed) results in a different SA.

Now, is this just "tech-speak" (and we don't really care about this
problem) or does swapping to a new key has other implications?
For example, if we swap keys for the Cat-3 SA (IPsec), do we need to
also modifiy the IPsec sequence numbering (or do we just
start with a new sequence number).

thomas
------