From msec-admin@securemulticast.org Wed May 2 05:38:54 2001 Received: from pairlist.net ([216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04444 for ; Wed, 2 May 2001 05:38:52 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C87BA5364B; Wed, 2 May 2001 05:38:23 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 5E47353606 for ; Wed, 2 May 2001 05:36:05 -0400 (EDT) Received: (qmail 25784 invoked by uid 3269); 2 May 2001 09:36:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 25781 invoked from network); 2 May 2001 09:36:04 -0000 Received: from smtp4.cluster.oleane.net (195.25.12.62) by klesh.pair.com with SMTP; 2 May 2001 09:36:04 -0000 Received: from oleane (dyn-1-1-106.Vin.dialup.oleane.fr [195.25.4.106]) by smtp4.cluster.oleane.net with SMTP id f429a3w45383 for ; Wed, 2 May 2001 11:36:03 +0200 (CEST) Message-ID: <01e601c0d2eb$61b56800$8001a8c0@oleane.com> From: "Peter Lewis" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E3_01C0D2FC.24F37360" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [MSEC] IPsec Global Summit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Wed, 2 May 2001 11:36:35 +0200 This is a multi-part message in MIME format. ------=_NextPart_000_01E3_01C0D2FC.24F37360 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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 ------=_NextPart_000_01E3_01C0D2FC.24F37360 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hello,
The third edition of the IPsec Global Summit will be = organised=20 next 23-26 October in Paris.
A call for proposals is online at:
http://www.uppe= rside.fr/ipsec2001/ipsec01cfp.htm
 
------=_NextPart_000_01E3_01C0D2FC.24F37360-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed May 23 16:51:06 2001 Received: from pairlist.net ([216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14823 for ; Wed, 23 May 2001 16:51:04 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1EC9F536A3; Wed, 23 May 2001 16:50:07 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id D87D4535B5 for ; Wed, 23 May 2001 16:48:53 -0400 (EDT) Received: (qmail 26136 invoked by uid 3269); 23 May 2001 20:48:53 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 26133 invoked from network); 23 May 2001 20:48:53 -0000 Received: from softdnserror (HELO sj-msg-core-1.cisco.com) (171.71.163.11) by klesh.pair.com with SMTP; 23 May 2001 20:48:53 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f4NKmQ929798 for ; Wed, 23 May 2001 13:48:26 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-546.cisco.com [10.21.66.34]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ABQ56675; Wed, 23 May 2001 13:48:21 -0700 (PDT) Message-Id: <4.3.2.7.2.20010523132937.04114ed8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: msec@securemulticast.org From: Mark Baugher In-Reply-To: <01e601c0d2eb$61b56800$8001a8c0@oleane.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] MSEC key management activities Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: 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 msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed May 23 18:59:07 2001 Received: from pairlist.net ([216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17150 for ; Wed, 23 May 2001 18:59:06 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A4D505375A; Wed, 23 May 2001 18:58:09 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id B05815374C for ; Wed, 23 May 2001 18:57:30 -0400 (EDT) Received: (qmail 38326 invoked by uid 3269); 23 May 2001 22:57:30 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 38323 invoked from network); 23 May 2001 22:57:30 -0000 Received: from chmls20.mediaone.net (24.147.1.156) by klesh.pair.com with SMTP; 23 May 2001 22:57:30 -0000 Received: from HARDJONO-LAP.mediaone.net ([63.90.80.228]) by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id f4NMvR609829; Wed, 23 May 2001 18:57:28 -0400 (EDT) Message-Id: <5.0.0.25.2.20010523172604.01bee460@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: msec@securemulticast.org From: Thomas Hardjono Subject: Re: [MSEC] MSEC key management activities Cc: mbaugher@cisco.com In-Reply-To: <4.3.2.7.2.20010523132937.04114ed8@mira-sjc5-6.cisco.com> References: <01e601c0d2eb$61b56800$8001a8c0@oleane.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: 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: >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 >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec