Subject: [MSEC] IPsec Global Summit

From: "Peter Lewis" <[email-masked]>
Date: Wed, 2 May 2001 11:36:35 +0200

Hello,
The third edition of the IPsec Global Summit will be organised next 23-26 October in Paris.
A call for proposals is online at:
http://www.upperside.fr/ipsec2001/ipsec01cfp.htm

---

From: Mark Baugher <[email-masked]>
Date: Wed, 23 May 2001 13:47:06 -0700

I want to give an update to the list of the work we have been doing on 
multicast key management.  In fact, there are a number of people involved 
in this effort as we have two key management drafts, GDOI and GSAKMP.  This 
led us to the need for a document that provides an architecture for key 
management that distills the best elements of the two approaches, one 
IKE-based and the other using SSL, IPSec or almost any security protocol, 
and provides guidelines for these protocols.  In some ways, the key 
management architecture work builds upon and extends the SMuG Group Key 
Management Building Block work that Thomas, Hugh and I did some time ago in 
a now-expired draft.  It has three types of security associations and, like 
GSAKMP, two types of messages.

GDOI and GSAKMP differ most in the exchanges used to "register" a new 
member to a group (the "registration protocol") and give initial keys for 
the group.  GDOI uses IKE exchanges for this and GSAKMP builds messages on 
top of some security protocol.  The second type of message pushes keys to 
group members for re-key, and sending new keys to security protocols for 
sessions (i.e. the commencement of data packets being sent to a multicast 
or unicast transport address).  We've been referring to this as the "key 
update" protocol, which has requirements for pushing keys semi-reliably 
over a datagram service, doing LKH-style membership management, and dealing 
with potential implosion problems that might occur if many members from a 
large group who are missing keys revert to the registration protocol to get 
key updates..  Ran noted that the key update protocol does not have to be 
that different between GDOI and GSAKMP in its format or payloads and 
suggested putting it out as a separate protocol specification.  We had a 
brief discussion yesterday with the GDOI and GSAKMP authors to consider 
this.  As a group, we think that there is merit to doing a draft on the 
key-update protocol and decided that we should take this issue to the list 
as well.

Mark

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

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 23 May 2001 19:10:56 -0400

OK, folks, this is long (so bare with me).

There are some issues I should like to bring-up with respect to
the practical aspects of a separated/divorced "registration" protocol.
I'd also like to give some background for the people who are new to this list.

I see "Group Key Management" as essentially being the management of not
only keys, but also the Security Associations (SA) as defined in the IPsec
context.  The aim (in simple terms) is for a Key Distributor (KD) or GCKS
(in SMuG language) to distribute a pre-defined set of SAs to members in a
1-to-Many IP multicast, such that the Sender can begin to send IP/IPsec
packets with a multicast address and for the Receivers to be able to
process the packets, look-up the SAD/SPD, get the matching key and
decrypt the packets.

Thus, my first point is that the very use of the terms "SA" implies that
we are living in the IP world, since the definition of an SA includes that
of the destination address (class D).  As a product of the MSEC WG, any
resulting protocol must aim first and foremost at satisfying this need of
a "group-shared SA" to be deployed by IP multicast.

To this end, SMuG defined the concept of Group SA (GSA) which consists of
three (3) Categories of SAs (Cat-1, Cat-2, Cat-3).

Cat-1 SA is the SA used to establish a shared-key (secure channel) between
a member and the KD, through which the other SAs (Cat-2 and Cat-3) and
sent from the KD to that member.

Assuming that a LKH of keys are used to perform scalable key update of the
Traffic-Encryption Key (TEK), then the KD must also be clever enough to
realize that it must give each member a different subset of the keys from
the LKH-tree. (Only the KD know the full LKH-tree).  For a given member,
the subset of the LKH-tree that it receives is part of the Cat-2 SA that
the member receives (under that earlier secure channel).  Thus, it is even
fair to say that technically speaking, the composition of Cat-2 SA bundle
is different for each member.

Furthermore, the Cat-2 SA is a Security Association as understood at the
IP/IPsec layer.  This means that the "control channel" through which
"key update" and other text-messages are sent (one-way) is in fact an
IP multicast transmission (not layer-4 or layer-5).

The Cat-3 is an IPsec SA in the usual sense, where the key (the TEK) and
the other elements of the SA has been pre-defined.  Assuming the SA and
key has been loaded by (the Sender and Receivers independely), a Sender
can start sending IPsec packets to the group and the Receivers can start
receiving/parsing/decrypting.

I think this is a general enough model that borrows a lot from previous
work (ie. ISAKMP/IKE,IPsec) that for most people familiar with those RFCs,
the concept of the GSA is not difficult to understand (if not simple).

My second point is, thus, that we should maintain this GSA model and
preserve the definition as found in the GKM-BB draft.  Yes, it does not
focus on the Many-to-Many multicast, but MSEC started with the
understanding that it will try to solve the 1-to-Many problem scope first.
(No point doing M-to-M if we can't solve the 1-to-M).

Both GSAKMP and GDOI follow the GSA concept and definition (not
surprisingly).  I think with few exceptions (and excluding GSAKMP's
distributed architecture), the two are very similar.  I think the
MSEC WG should strive to develop a common definiton of payload *items*
and *meanings* of those items, independent of any payload format or
header.  (btw. we have been striving for this target, though the efforts
have slowed down recently, ie. post-BOF syndrome).

One of interesting issues has been the communication method within which
a Member obtains the Cat-2 SA and Cat-3 SA.  GSAKMP is transport-
independent, in that the Member simply opens up a secure channel (such
as SSL) through which it "downloads" the two SAs.

In contrast GDOI uses an "extended-IKE" where the Phase-2 IKE payload is
modified to carry a more complex payload (namely the Cat-2 and Cat-3 SAs).
Initially we did think of simply adding a Phase-3 to IKE, but after some
though we concluded that a Phase-3 would be a repetition of much of
Phase-2 IKE.

Now, the most recent issue has been whether or not we should separate-out
the "registration" step (Cat-1) and make it independent from the
control-channel (Cat-2).

There are some merits and some inconveniences to a separate registration 
"protocol".  The good side:

  + we can use SSL, IPsec Tunnels (Ran's proposal) or even XML to download
    the Cat-2 and Cat-3 SAs (yes, they are still IPsec SAs).  In fact, we
    can use anything provided it presents the same security level as
    that of IKE/SSL.

The bad side:

  - We end-up having a "Key Update" protocol (using Cat-2 SA) that
    functions based on the assumption that some previous protocol has
    installed the Cat-2 and Cat-3 SAs.  Thus, there is a discontinuity
    in the group key management functions.

As it stands, within GDOI there is a tight relationship between the
"Registration" part and the "Key Update" part, where some elements from
the Registration (eg. cookies) is used to initialize the Key-Update part.
I'm unsure as to which way the complexity tends to increase (ie. having
a separate Regsitration and Key-Update protocol, or having them integrated
into one).

I would even argue that within GSAKMP there is a tight relationship
between the Registration part ("Group Establishment") and Key-Update part.

In both GDOI and GSAKMP the tight relationship is due to the
unity of the functions within group-key management (not because
the authors could not separate-out the pieces).

This brings me to Ran's notion and understanding/definition of the
term "protocol".

I understand the term "protocol" from layer-3, meaning a complete
specification of a communications method, down to the packet formats
and payloads. (ie. not just key exchange flows in a general manner).

If we simply want a generic Registration Step independent of transport
(ie. can use SSL, IPsec Tunnel, XML), then we cannot dictate the
protocol (in a layer-3 sense) since protocols in layer-3 dictate the
exact payload format.  At the very best, we can only talk about
"items/component/pieces" of data that has to be delivered through
that transport.

If this is indeed the case (ie. a generic list of items with no packet
formats), then perhaps the GKM Architecture document is the best place to
express this (leaving the implementor to choose the secure channel).

We don't need a separate document just list general items to be sent
by the KD to the Member. (Not to be a pain, but I think this was the
organizational purpose of "Building Blocks" and "Protocol Instantiations";
namely to separate between general items and actual protocols in the
layer-3 sense).

Thus, in summary, my suggestion is keep all architecture-level
designs and items/components list within the GKM Architecture
document.  This document should list precisely:

  - the items being downloaded/pulled from the KD to a Member
  - the items being pushed in the "Key Update"
  - the exact *meaning" and *purpose* of each item

The GKM Arch document should not talk about payload formats.
It should be neutral to other future Protocol Instantiations.

If someone wants to propose a specific Registration protocol
(in a layer-3 sense), then she/he must write a precise spec
containing the relevant items (from the Arch Document) and
the precise format for delivery of the items.

thomas
------

At 5/23/01||01:47 PM, Mark Baugher wrote:
>in this effort as we have two key management drafts, GDOI and 
>GSAKMP.  This led us to the need for a document that provides an 
>architecture for key management that distills the best elements of the two 
>approaches, one IKE-based and the other using SSL, IPSec or almost any 
>security protocol, and provides guidelines for these protocols.  In some 
>ways, the key management architecture work builds upon and extends the 
>SMuG Group Key Management Building Block work that Thomas, Hugh and I did 
>some time ago in a now-expired draft.  It has three types of security 
>associations and, like GSAKMP, two types of messages.
>
>top of some security protocol.

>The second type of message pushes keys to group members for re-key, and 
>sending new keys to security protocols for sessions (i.e. the commencement 
>of data packets being sent to a multicast or unicast transport 
>address).  We've been referring to this as the "key update" protocol, 
>which has requirements for pushing keys semi-reliably over a datagram 
>service, doing LKH-style membership management, and dealing with potential 
>implosion problems that might occur if many members from a large group who 
>are missing keys revert to the registration protocol to get key updates..

>Ran noted that the key update protocol does not have to be that different 
>between GDOI and GSAKMP in its format or payloads and suggested putting it 
>out as a separate protocol specification.  We had a brief discussion 
>yesterday with the GDOI and GSAKMP authors to consider this.  As a group, 
>we think that there is merit to doing a draft on the key-update protocol 
>and decided that we should take this issue to the list as well.
>
>Mark
>
>