Subject: [MSEC] The new GKM architecture draft

From: Ran Canetti <[email-masked]>
Date: Thu, 28 Jun 2001 15:11:30 -0400

Folks,

[For the purpose of this discussion I am taking my "co-chair hat" off, and
writing as a document editor.]

I had planned this mail to precede the publication of the GKM architecture
draft, but did not make it in time. My apologies.

The goal of this draft is to provide a common framework for various
key management protocols (including GDOI, GSAKMP with its many options, and
potentially others). The main thesis of this architecture is to separate
between the the following two components of group key management:

o The "registration protocol" (ie, the unicast protocol between a
  joining member and the KDC).
 
o The "rekey protocol" (ie, the protocol in which the KDC sends update 
  messages to current group members). 

The draft states that the two protocols can be separate and need not be
"bundles up". This allows for greater flexibility: Once can decide whether
to do IKE/IPSEC/TLS-based registration without changing the rekey protocol.
Similarly, one can decide on different rekey protocols (OFE/LKH/Others, 
or to not rekey at all, as [MARKS] does), again without affecting the
registration protocol. 

The obvious issue here is how will the necessary information will be 
communicated from the registration protocol to the rekey protocol to the
data-security protocol. This will be done via the following security
associations (which are regarded as databases sitting inside each member):

o The "rekey SA". This SA is potentially initialized by the registration 
protocol and is used and updated  by the rekey protocol.

o The "data SA". This SA is potentially initialized by the registration
protocol, is updated by the rekey protocol, and is used by the data security
protocol.

This is the main framework of the suggested architecture. There are many
more details; please see the draft. When reading, please keep in mind that
this is a preliminary draft, and post any remarks you have to the list.
We will update it accordingly.

Best,

Ran

Some remarks:

1.  Note that the rekey SA is not mandatory - if the policy does not use
rekeys then this SA is redundant.

2. Note that the data SA need not necessarily be initialized by the
registration protocol. One can think of a scenario where a member registers
in advance to actually joining the group, and the actual initialization of
the dat SA is done at a later time by the rekey protocol.

3. Note that the "cat 1 SA" (or, registration SA) does not appear in the
above description at all. Indeed, this SA is internal to the registration
protocol and therefore does not need to be specified/dicussed in this
architectural document. It is up to the registration protocol.

4. A word on the issue of distributed versus centralized KDC. 
It seems to me that the distinction between the two cases is to a large
extent "transparent" for the GKM architecture draft. Indeed, the draft 
specifies two protocols (registration and rekey). These protocols would
remain unchanged regarless of whether all members run the protocol with the
same KDC or alternatively different members talk to different KDC's.
Same goes for the rekey protocol. So, in other words, the decision of
whether to have a distribued or centralized KDC architecture is up to the
group manager and is "transparent" to the KGM architecture and to the group
members.
  
5. Neither of the current proposals for key management - GDOI and GSAKMP -
are compatible with this architecture, since they bundle the rekey
protocol within the registration protocol. Both will need to be modified
accordingly if this architecture is to be accepted by msec. The big benefit
is that both protocols will be able to co-exist within one framework.

6. A separate draft on the rekey protocol is currently being written 
by Lakshminath Dondeti and David Mcgrew. Hopefully it will be available
soon.

7. There is another issue which I wanted to bring up - a possible 
"de-registration" protocol. We discussed this issue among the authors 
of this draft and decided to bring it up to the list. But I'll defer
this issue to a differnt message.

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

---

From: Thomas Hardjono <[email-masked]>
Date: Fri, 29 Jun 2001 11:32:28 -0400

Mark, Ran,

I have a *real* problem with the optionality of the Re-Key Protocol
(pages 6 and 7).

We have moved from a single model (as decribed in the GKMBB draft
and Reference [HBH01] in the arch-doc), to having 2 separate
protocols (possibly 3 if we include de-registration),
and now to the possibility of excluding multicast itself to aid
the scalability of key management.

If indeed the Re-Key protocol is optional, and that Cat-2 SA is thus
also optional, then really the keywords "SHOULD" that appears twice
on page-7 of the document is redundant. Also, if we are trying
to avoid the implosion problem, then clearly systems that use
only Cat-1 SA (and nothing else) are not very useful and perhaps
not worth addressing here (ie. just use pair-wise SSL or IPsec tunnels
for joins and re-keys).

My May posting (http://www.pairlist.net/pipermail/msec/2001-May/000123.html)
was not meant to be an exercise in essay-writing, but to remind
people that we are trying to stay with one model.

I think the whole concept of "Registration" is incorrect, and that
it is an Application-layer function.  That is, a user is able to register
to a website and download suitable parameters (and even code/puggins)
to join the group.  The user's Application then uses the parameters
to join the group.

At layer-3 and layer-4, a software does not register to the GCKS.
When the software contacts the GCKS, it already knows:
         - the address/ports of the GCKS
         - the expected security mechanisms to talk to the GCKS
         - the key-management functions expected by the GCKS

Perhaps in trying to accomodate all sorts of scenarios (ie. MARKS,
ALC, etc), we are forgetting the primary means of
key updates: multicast itself.

thomas
------
ps. More comments to come as I read along.

---

From: Mark Baugher <[email-masked]>
Date: Fri, 29 Jun 2001 09:05:11 -0700

Thomas

>I have a *real* problem with the optionality of the Re-Key Protocol

If an application does not need it, then why should they use it?

>the scalability of key management.

Scalability goes in two directions:  We want to be able to scale
down as well as scale up.  For very small groups, I see no
reason to require that Re-key be used.  I have seen group
security applications where there are few members in a group
and each member can contact the sender via the unicast
exchange of the Registration protocol to get key material.
Once that's done, there is no reason for Re-key.  When the
key expires, another run of the Registration protocol is
performed.

>not worth addressing here (ie. just use pair-wise SSL or IPsec tunnels

Yes, there's no need for a Cat-2 SA (Re-key SA) if there is to be
no Re-key operations for the group.  The SHOULD refers to the case
when Re-key operations are used for the group.  There is no implosion
problem to avoid if the group has only a few members.  So the
Registration protocol has the option of delivering TEKs (Data Security
SAs) but no KEK (Re-key SA).  SSL or IPsec still won't work even
when there is no Re-key operation since the TEK needs to be
common to a group.

>people that we are trying to stay with one model.

I agree with that.  I believe the motivation for the architecture is to
define what that model is rather than having two or three specifications
define their own models.  I guess it won't be painless, either.
If the model allows the Re-key operation to not be used when it is
not needed (sounds reasonable, doesn't it), then this is an option
within a single model.

>to join the group.  The user's Application then uses the parameters

Registration is the same as the GROUPKEY-PULL of GDOI, although
changes will be needed in the latter to conform to the former.
When you say "register at a website," this sounds vague to me.
Are you doing everything over http, ssl, or does the website run the
registration protocol?  Key management is usually an application-layer
function.  I really don't understand your point here.

>         - the key-management functions expected by the GCKS

I agree.

>key updates: multicast itself.

You're going off the deep end here.  The optional Re-key protocol is
not that much different than the optional GROUPKEY-PUSH message
in GDOI.  Both can be sent using multicast or unicast.

Mark

---

From: Thomas Hardjono <[email-masked]>
Date: Fri, 29 Jun 2001 15:48:39 -0400

Mark,

>when there is no Re-key operation since the TEK needs to be

OK, I'll accept this argument.

>function.  I really don't understand your point here.

When I used the term "Registration" in our discussions last year,
it was for a process/protocol that was outside GDOI.
Meaning that a user would need to "Register" his/her name (say to
a website), pay and dowload pluggings/policy-info/etc.

Ran insisted on using IPsec tunnels instead of modified-IKE-phase-2,
and started talking about a separate "registration" protocol
to achieve his end.

OK, I accept the mix-and-match argument (ie. using differing
protocols at diferent layers) to achieve Cat-1 and Cat-2.
However, I think when it comes to implementations, the two will
be so closely linked that in reality we cannot easily mix-and-match.

To get back to my point, perhaps calling it an "Initialization"
protocol would be better since we are in fact initializing
all the members.

thomas
------

---

From: Brian Weis <[email-masked]>
Date: Fri, 29 Jun 2001 13:30:03 -0700

There are some benefits and problems to the mix-and-match protocol
approach. It's a nice property  that different Registration protocols
could be used in a large group (perhaps based on receiver capabilities
or network topology), but they could all be pushed the KEK and KEK
policy for a single Re-Key message.

However, as Thomas points out below, that does increase the complexity
of any system which implements just one registration protocol and a
Re-key message. For simplicity they'd want the protocol formatting of
the two to be similar, and also the policy & key representation to be
similar. That's not likely to happen with protocols which are derived
independently.

I'm just wondering we'll ultimately end up with a Re-key protocol per
Registration protocol.

Brian

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

---

From: Thomas Hardjono <[email-masked]>
Date: Fri, 29 Jun 2001 17:10:17 -0400

Brian,

>I'm just wondering we'll ultimately end up with a Re-key protocol per

Yes, actually this is what I'm rather concerned about.
But perhaps we can just wait and see.

thomas
------

---

From: Mark Baugher <[email-masked]>
Date: Fri, 29 Jun 2001 15:26:50 -0700

>I'm just wondering we'll ultimately end up with a Re-key protocol per

That's what we have today with GDOI and GSAKMP.  GDOI uses an
IKE Phase 1 for protecting the Registration protocol exchange (which
is an IKE Phase 2 in GDOI).  GSAKMP does not use an IKE Phase 2.

cheers, Mark