From msec-admin@securemulticast.org Sun Apr 1 10:51:37 2001 Received: from pairlist.net ([216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29519 for ; Sun, 1 Apr 2001 10:51:37 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id CBDBE5374E; Sun, 1 Apr 2001 10:51:06 -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 A7EA35377D for ; Sun, 1 Apr 2001 10:43:08 -0400 (EDT) Received: (qmail 3046 invoked by uid 3269); 1 Apr 2001 14:43:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 3043 invoked from network); 1 Apr 2001 14:43:06 -0000 Received: from chmls20.mediaone.net (24.147.1.156) by klesh.pair.com with SMTP; 1 Apr 2001 14:43:06 -0000 Received: from hardjono.mediaone.net (h0010a4057f65.ne.mediaone.net [24.128.45.6]) by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id f31Eh4a06379 for ; Sun, 1 Apr 2001 10:43:05 -0400 (EDT) Message-Id: <4.3.1.2.20010401104442.0225a390@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 To: msec@securemulticast.org From: Thomas Hardjono Subject: Re: Group Key Determination Algorithms --- Re: [MSEC] Session ID and Group ID In-Reply-To: <200103311820.NAA22786@ornavella.watson.ibm.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: Sun, 01 Apr 2001 10:51:15 -0400 Ran, I was not referring to the general GKMBB draft here, but rather to the specific key-tree type algorithms, three of which are LKH, OFT, OFC. If these are similar enough, then we need to have a draft describing them in detail to help implementors. If they are not similar, then we will need individual drafts for each. Obviously there will be other group rekey algorithms not based on key-trees. They will have to be introduced as separate drafts. However, we must deal with what we have in front of us now (namely the key-tree algorithms). cheers, thomas ------ At 3/31/01||01:20 PM, Ran Canetti wrote: > > I think we did agree somewhere along the line that a draft(s) is needed > > to cover the "Group Key Determination Algorithms", > > which is my formal way of saying LKH, OFT, OFC, etc. (ie. Key Trees > > in general). > > >alternative names are "group re-keying algorithm" or "group key update >algorithm". > > > Are we limited to simply providing a variable-length payload > > for a flattened Key-Tree, or is there sufficient similarity > > among the Algorithms that we can provide a finer granularity > > standard payload? > > > Also, is there a "standard" that describes how (say) the LKH algorithm > > works (in the same way that there is, say, a DES standard document)? > > I know LKH isn't an algorithms in the sense of DES, but really > > a standard is this sense is just a step-by-step description of > > how to manipulate the bits (be they keys or data). > > >There are many ways of going about the re-keying >process, even if we are restricting ourselves to LKH/OFT (e.g., doing >"heartbeat rekeying", different ways of generating the keys in the tree >pseudorandomly from each other, changing keys at specific times (as >suggested by Bob Briscoe a couple years back) and more). Furthremore, >there are key update algorithms that are not based on trees at all. >So, to allow for extra flexibility in the choice of the key update >algorithm it may be good to specify, in the general GKMBB framework, >only a generic payload for the key update information. Then, specific >drafts will describe how this generic payloads are interpreted by >specific key update algorithms. > > >Ran _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From test-admin@pairlist.net Sun Apr 1 12:38:55 2001 Received: from pairlist.net ([216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20151 for ; Sun, 1 Apr 2001 12:38:54 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1422D5378B for ; Sun, 1 Apr 2001 12:38:17 -0400 (EDT) Subject: securemulticast.org mailing list memberships reminder From: mailman-owner@pairlist.net To: msec-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: test-admin@pairlist.net Errors-To: test-admin@pairlist.net X-BeenThere: test@pairlist.net X-Mailman-Version: 2.0 Precedence: bulk Message-Id: <20010401163817.1422D5378B@pairlist.net> Date: Sun, 1 Apr 2001 12:38:17 -0400 (EDT) This is a reminder, sent out once a month, about your securemulticast.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, msec-request@securemulticast.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@one.pairlist.net. Thanks! Passwords for msec-archive@lists.ietf.org: List Password // URL ---- -------- msec@securemulticast.org ucweat http://www.pairlist.net/mailman/options/msec/msec-archive%40lists.ietf.org From msec-admin@securemulticast.org Sun Apr 1 14:28:35 2001 Received: from pairlist.net ([216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11939 for ; Sun, 1 Apr 2001 14:28:35 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 3687B537D7; Sun, 1 Apr 2001 14:28:04 -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 E6E1B53552 for ; Sun, 1 Apr 2001 14:26:58 -0400 (EDT) Received: (qmail 16773 invoked by uid 3269); 1 Apr 2001 18:26:58 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 16770 invoked from network); 1 Apr 2001 18:26:58 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 1 Apr 2001 18:26:58 -0000 Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw3.watson.ibm.com (8.11.2/8.11.2) with ESMTP id f31IQR220856; Sun, 1 Apr 2001 14:26:27 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id OAA19900; Sun, 1 Apr 2001 14:26:27 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id OAA18584; Sun, 1 Apr 2001 14:26:27 -0400 From: Ran Canetti Message-Id: <200104011826.OAA18584@ornavella.watson.ibm.com> To: msec@securemulticast.org, thardjono@mediaone.net Subject: Re: Group Key Determination Algorithms --- Re: [MSEC] Session ID and Group ID 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: Sun, 1 Apr 2001 14:26:27 -0400 I agree that it's a good idea to see if we can manage to have a single coherent draft that puts the various tree-based rekeying schemes in one framework and in particular uses a single template encoding mechanism for the "key update payload" when one of these schemes is used. This would both enhance our understanding of these schemes and would simplify coding. (This will not harm the overall flexibility since the GKMBB draft will refer to this payload as a generic one, and will allow other rekeying mechanisms.) Any volunteers? Ran > > Ran, > > I was not referring to the general GKMBB draft here, but rather to the > specific key-tree type algorithms, three of which are LKH, OFT, OFC. > If these are similar enough, then we need to have a draft describing > them in detail to help implementors. If they are not similar, then we will > need individual drafts for each. > > Obviously there will be other group rekey algorithms not based on key-trees. > They will have to be introduced as separate drafts. > > However, we must deal with what we have in front of us now (namely the > key-tree algorithms). > > cheers, > > thomas > ------ > > > > At 3/31/01||01:20 PM, Ran Canetti wrote: > > > I think we did agree somewhere along the line that a draft(s) is needed > > > to cover the "Group Key Determination Algorithms", > > > which is my formal way of saying LKH, OFT, OFC, etc. (ie. Key Trees > > > in general). > > > > > >alternative names are "group re-keying algorithm" or "group key update > >algorithm". > > > > > Are we limited to simply providing a variable-length payload > > > for a flattened Key-Tree, or is there sufficient similarity > > > among the Algorithms that we can provide a finer granularity > > > standard payload? > > > > > Also, is there a "standard" that describes how (say) the LKH algorithm > > > works (in the same way that there is, say, a DES standard document)? > > > I know LKH isn't an algorithms in the sense of DES, but really > > > a standard is this sense is just a step-by-step description of > > > how to manipulate the bits (be they keys or data). > > > > > >There are many ways of going about the re-keying > >process, even if we are restricting ourselves to LKH/OFT (e.g., doing > >"heartbeat rekeying", different ways of generating the keys in the tree > >pseudorandomly from each other, changing keys at specific times (as > >suggested by Bob Briscoe a couple years back) and more). Furthremore, > >there are key update algorithms that are not based on trees at all. > >So, to allow for extra flexibility in the choice of the key update > >algorithm it may be good to specify, in the general GKMBB framework, > >only a generic payload for the key update information. Then, specific > >drafts will describe how this generic payloads are interpreted by > >specific key update algorithms. > > > > > >Ran > > > _______________________________________________ > 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 From msec-admin@securemulticast.org Mon Apr 2 00:43:10 2001 Received: from pairlist.net ([216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA19541 for ; Mon, 2 Apr 2001 00:43:08 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B292053875; Mon, 2 Apr 2001 00:42:02 -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 3E3EA53874 for ; Mon, 2 Apr 2001 00:41:50 -0400 (EDT) Received: (qmail 59569 invoked by uid 3269); 2 Apr 2001 04:41:50 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 59566 invoked from network); 2 Apr 2001 04:41:49 -0000 Received: from relay.eecs.berkeley.edu (169.229.34.228) by klesh.pair.com with SMTP; 2 Apr 2001 04:41:49 -0000 Received: from gateway.EECS.Berkeley.EDU (nsmail@gateway.EECS.Berkeley.EDU [169.229.60.73]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id VAA04758 for ; Sun, 1 Apr 2001 21:41:48 -0700 (PDT) Received: from acm.org (c787017-a.pinol1.sfba.home.com [24.5.193.121]) by gateway.EECS.Berkeley.EDU (Netscape Messaging Server 4.15) with ESMTP id GB5EDM00.9MI; Sun, 1 Apr 2001 21:41:46 -0700 Message-ID: <3AC80453.9A7C5817@acm.org> From: Adrian Perrig X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.10 i686) X-Accept-Language: en MIME-Version: 1.0 To: Lakshminath Dondeti Cc: msec@securemulticast.org Subject: Re: [MSEC] Session ID and Group ID References: <4.3.1.2.20010329155417.014d8030@pop.ne.mediaone.net> <3AC347E2.58074E5D@cisco.com> <3AC3C34E.B806D4DB@nortelnetworks.com> <3AC4E18A.342BEDB9@cisco.com> <3AC4F018.44378DD4@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: Sun, 01 Apr 2001 21:47:15 -0700 Content-Transfer-Encoding: 7bit Hi Lakshminath, > About revision (and it needs a version number to go with it) numbering, > as I explained earlier in another message, we can use it and not > send a new SA/SPI/notification during join rekeying in LKH+ and similar > algorithms. This is interesting. If I correctly understand, the proposal is to compute a one-way function on all keys that the new member receives, right? However, this approach still requires to send out version/revision numbers of keys, so that the receivers know which keys need to be updated. We recently worked on a new key distribution protocol which took a more drastic approach: We update all the keys in the entire key tree in each time interval. This approach trades off computation with communication. It does not require sending any information to anybody, since all group members update the key tree independently. We assume that the key server can update the key tree efficiently with a fast one-way function. The main focus of our work, however, was to provide reliability for key updates without using underlying reliable multicast protocols. We present a number of mechanisms. In case you're interested, a summary of the paper is available at: http://www.perrig.net/projects/elk/elksummary.html We will present the paper at this year's Oakland conference. The paper is available at: http://www.perrig.net/projects/elk/elk.ps Greetings, Adrian _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Apr 2 09:00:35 2001 Received: from pairlist.net ([216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06377 for ; Mon, 2 Apr 2001 09:00:34 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id EFF00535FA; Mon, 2 Apr 2001 09:00:04 -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 D710F5356C for ; Mon, 2 Apr 2001 08:58:41 -0400 (EDT) Received: (qmail 16025 invoked by uid 3269); 2 Apr 2001 12:58:41 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 16022 invoked from network); 2 Apr 2001 12:58:41 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by klesh.pair.com with SMTP; 2 Apr 2001 12:58:41 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id FAA22191; Mon, 2 Apr 2001 05:56:53 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (rtp-dial-1-6.cisco.com [10.83.97.6]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AAB26737; Mon, 2 Apr 2001 05:58:03 -0700 (PDT) Message-Id: <4.3.2.7.2.20010402055257.036c5388@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Thomas Hardjono From: Mark Baugher Subject: Re: Group Key Determination Algorithms --- Re: [MSEC] Session ID and Group ID Cc: msec@securemulticast.org In-Reply-To: <4.3.1.2.20010331101055.01ef6de0@ZBL6C002.corpeast.baynetwo rks.com> References: <4.3.2.7.2.20010331034836.0354d3a8@mira-sjc5-6.cisco.com> <3AC4D5EF.6D3788AB@nortelnetworks.com> <4.3.1.2.20010329155417.014d8030@pop.ne.mediaone.net> <3AC347E2.58074E5D@cisco.com> <4.3.2.7.2.20010330053041.00bb7698@mira-sjc5-6.cisco.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: Mon, 02 Apr 2001 05:57:07 -0800 Hi Thomas At 10:18 AM 3/31/2001 -0500, Thomas Hardjono wrote: >i think we did agree somewhere along the line that a draft(s) is needed >to cover the "group key determination algorithms", >which is my formal way of saying lkh, oft, ofc, etc. (ie. key trees >in general). > >are we limited to simply providing a variable-length payload >for a flattened key-tree, or is there sufficient similarity >among the algorithms that we can provide a finer granularity >standard payload? > >also, is there a "standard" that describes how (say) the lkh algorithm >works (in the same way that there is, say, a des standard document)? >i know lkh isn't an algorithms in the sense of des, but really >a standard is this sense is just a step-by-step description of >how to manipulate the bits (be they keys or data). I think that we need to have 1 specification for every n implementations. The implementations will be specific to the protocol framework. GSAKMP already has LKH+ specified - it's more of a complete system than a single protocol. For GDOI, we need to have an LKH specification. GDOI is useful without LKH, OFT, AMESP, and TESLA, but it needs them to offer a complete specification for a wide variety of application environments. So for GDOI, I'd like to see separate specifications for each membership management algorithm of interest. Mark >thomas >------ > > >at 3/31/01||03:53 am, mark baugher wrote: >>hi lakshminath >> i think that we need to have a separate draft document >>that describes how an lkh security protocol should >>operate. what we have in the gdoi draft is our first >>take on what the security-association traffic encryption key >>(sa tek) payload needs to be to support an lkh security >>protocol. i would not be surprised if we need to change >>this by the time we finish an lkh security protocol >>document. it hope that the security association key >>encrypting key (sa kek) won't need any changes - >>if we find that we need to change sa kek for new >>security protocols, then there's something wrong. the >>sa kek needs to be general wrt security protocols. >> >>best regards, mark >>at 01:52 pm 3/30/2001 -0500, lakshminath dondeti wrote: >>>mark, >>> >>>thanks for the explanation. it makes sense. i am looking for >>>opinions on incorporating version and revision numbers with >>>keys. particularly in case of lkh+ and similar key determination >>>algorithms it makes life easy. for example, in lkh+, when a join >>>occurs, the gcks need not even notify current membership. when >>>data comes with a new "revision number", the members "update" the >>>corresponding sa appropriately. >>> >>>i am bringing this up so we can discuss and decide whether it is >>>worthwhile to add this to gdoi i-d key payloads. >>> >>>best regards, >>>lakshminath >>> >>>ps: i want to reiterate the disclaimer that this was an idea proposed >>>in the literature (not by me, see below). >>> >>> >>>mark baugher wrote: >>> > >>> > lakshminath, >>> > >>> > at 06:20 pm 3/29/2001 -0500, lakshminath dondeti wrote: >>> > >brian, >>> > > >>> > >i am not getting into this sid discussion at this time. >>> > > >>> > >but, i am concerned about having a single "active" tek. i believe >>> > >in reality a member needs to maintain a list of teks. consider >>> > >data going over a reliable multicast channel. it is plausible >>> > >that a member receives two (e.g.) versions of teks before she >>> > >receives any encrypted data. when the data eventually arrives, >>> > >the first few packets could be encrypted with tek 1.0 and the rest >>> > >with tek 2.0, or vice versa. >>> > >>> > we use an spi for this purpose. >>> > >>> > mark >>> > >>> > >i propose that both key and data packets should have "version" and >>> > >"revision" tags. the terminology and idea comes from the versakey >>> > >paper in jsac 1999/2000 by m. waldvogel, g. caronni, b. plattner and >>> > >others. as i recall each time a new key is generated, the version >>> > >number is increased, and when a one-way function is used on the current >>> > >tek/kek for rekeying (ala lkh+), the revision number is increased. >>> > > >>> > > >>> > > >>> > >best regards, >>> > >lakshminath >>> > > >>> > >brian weis wrote: >>> > > > >>> > > > hi thomas, >>> > > > >>> > > > thomas hardjono wrote: >>> > > > > >>> > > > > recently we had a discussion with some folks who wanted to >>> > > > > do group key management in wireless, and a number of questions >>> arose >>> > > > > regarding the gsa model and definition, and in particular >>> > > > > about the notion of group ids (gid). >>> > > > > >>> > > > > so we all know that we need some way to identify a group >>> > > > > other than using the (s, g) pair. gsakmp uses the notion >>> > > > > of a group id (gid) which can identify a group a high level >>> > > > > and which is included in all the gsakmp messages/headers. >>> > > > > in gsakmp the gid is a 32-bit number (though i think we may >>> > > > > need a bigger number). >>> > > > > >>> > > > > this notion of a gid is also being carried-over into the gdoi work >>> > > > > (at least implicitly). >>> > > > > >>> > > > > so here is the scenario: there is one control channel (cat-2) >>> > > > > and there is multiple data channel (cat-3), say one for audio and >>> > > > > one for video. >>> > > > > >>> > > > > the question is, if i was a receiver and was in the process of >>> > > > > receiving a key-update (rekey pack) through the push/control sa, >>> > > > > how do i identify which key-packs are to be applied to the >>> > > > > 2 data channels? in gdoi the update will consist of 2 kek sas, >>> > > > > but the question still arises: how do i know how to match the keks >>> > > > > to the multiple cat-3 sas. >>> > > > >>> > > > i followed you up until the last paragraph. in the scenario you >>> mention, >>> > > > there could be one kek sa (not two as you say in this paragraph), and >>> > > > two tek sas. maybe you meant that the "update will consist of 2 tek >>> > > > sas"? >>> > > > >>> > > > in gdoi, the push message includes an sa payload containing the >>> policy >>> > > > for the two data channels, and the kd payload contains the new >>> keys for >>> > > > the two channels. the sa payload identifies the (s,g) of the data >>> > > > channel along with a new spi (assuming ipsec encapsulation). the kd >>> > > > payload includes the new spi and the new key. it will be obvious >>> which >>> > > > key is associated with which data channel. >>> > > > >>> > > > or, if you really considering confusion between the two keks, the >>> only >>> > > > confusion between would be between the current kek and a new one sent >>> > > > down in the push message. >>> > > > however, the new one replaces the current kek after the push message >>> > > > processing has completed -- only one should be active at a time per >>> > > > group. >>> > > > >>> > > > > one answer is using a session-id (sid) in conjunction with the gid. >>> > > > > thus, each kek and tek would need to identify the gid & sid >>> > > > > to which the kek/tek applies. >>> > > > >>> > > > the gdoi, there is already a unique value associated with each >>> kek. the >>> > > > cookie-pair in the ike header is used as the "spi" for the kek. >>> if a new >>> > > > kek is sent in a push message, the sa payload sends a new cookie-pair >>> > > > for the new kek. >>> > > > >>> > > > i don't see where a sid is needed for either a tek or kek. >>> > > > >>> > > > brian weis >>> > > > bew@cisco.com >>> > > > >>> > > > > would it be possible, say, to have a 32-bit gid and a 32-bit sid, >>> > > > > (assuming that 32-bits of gid is enough)? if a 32-bit gid is >>> too much, >>> > > > > perhaps we can re-use some of the bits (least significant 8 bit) >>> > > > > for the sid? >>> > > > > >>> > > > > does this whole sid thing make any sense? >>> > > > > >>> > > > > thomas >>> > > > > ------ >>> > > > > >>> > > > > _______________________________________________ >>> > > > > 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 >>> > > >>> > >_______________________________________________ >>> > >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 > > >_______________________________________________ >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 From msec-admin@securemulticast.org Mon Apr 2 11:00:22 2001 Received: from pairlist.net ([216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13725 for ; Mon, 2 Apr 2001 11:00:21 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D57E553756; Mon, 2 Apr 2001 10:54:31 -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 76DC35374A for ; Mon, 2 Apr 2001 10:53:24 -0400 (EDT) Received: (qmail 25394 invoked by uid 3269); 2 Apr 2001 14:53:24 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 25391 invoked from network); 2 Apr 2001 14:53:23 -0000 Received: from smtprch1.nortelnetworks.com (HELO smtprch1.nortel.com) (192.135.215.14) by klesh.pair.com with SMTP; 2 Apr 2001 14:53:23 -0000 Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com; Mon, 2 Apr 2001 09:44:32 -0500 Received: from zbl6c016.corpeast.baynetworks.com ([132.245.205.66]) by zsc4c000.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H0BPHRSA; Mon, 2 Apr 2001 07:44:18 -0700 Received: from nortelnetworks.com (arc.engeast.baynetworks.com [192.32.137.28]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HJCWZ0R3; Mon, 2 Apr 2001 10:44:16 -0400 Message-ID: <3AC89316.66228649@nortelnetworks.com> From: "Lakshminath Dondeti" X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Adrian Perrig Cc: msec@securemulticast.org Subject: Re: [MSEC] Session ID and Group ID References: <4.3.1.2.20010329155417.014d8030@pop.ne.mediaone.net> <3AC347E2.58074E5D@cisco.com> <3AC3C34E.B806D4DB@nortelnetworks.com> <3AC4E18A.342BEDB9@cisco.com> <3AC4F018.44378DD4@nortelnetworks.com> <3AC80453.9A7C5817@acm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: Mon, 02 Apr 2001 10:56:22 -0400 Content-Transfer-Encoding: 7bit Adrian, Adrian Perrig wrote: > > Hi Lakshminath, > > > About revision (and it needs a version number to go with it) numbering, > > as I explained earlier in another message, we can use it and not > > send a new SA/SPI/notification during join rekeying in LKH+ and similar > > algorithms. > > This is interesting. If I correctly understand, the proposal is to > compute a one-way function on all keys that the new member receives, > right? However, this approach still requires to send out > version/revision numbers of keys, so that the receivers know which > keys need to be updated. > This proposal was published 1-3 years ago in WetICE and JSAC (not by me). Actually the GCKS does not need to send the version/revision numbers to all members. Only the sender(s) need(s) to know this. It then simply uses the version/revision number in the headers while sending future data. In case of the GDOI protocol, this translates to a unicast "notification" as opposed to a multicast notification to the group. (Disclaimer: There is no provision for these notifications currently, in the GDOI I-D.) All that during join rekeying only. :-) I will read your paper. It sounds interesting! best regards, Lakshminath > We recently worked on a new key distribution protocol which took a > more drastic approach: We update all the keys in the entire key tree > in each time interval. This approach trades off computation with > communication. It does not require sending any information to anybody, > since all group members update the key tree independently. We assume > that the key server can update the key tree efficiently with a fast > one-way function. > > The main focus of our work, however, was to provide reliability for > key updates without using underlying reliable multicast protocols. We > present a number of mechanisms. In case you're interested, a summary > of the paper is available at: > http://www.perrig.net/projects/elk/elksummary.html > > We will present the paper at this year's Oakland conference. The paper > is available at: > http://www.perrig.net/projects/elk/elk.ps > > Greetings, > Adrian _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Apr 2 11:40:32 2001 Received: from pairlist.net ([216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16033 for ; Mon, 2 Apr 2001 11:40:32 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0A21353652; Mon, 2 Apr 2001 11:40:03 -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 38C8353689 for ; Mon, 2 Apr 2001 11:38:10 -0400 (EDT) Received: (qmail 29627 invoked by uid 3269); 2 Apr 2001 15:38:09 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 29624 invoked from network); 2 Apr 2001 15:38:09 -0000 Received: from zcars04e.nortelnetworks.com (47.129.242.56) by klesh.pair.com with SMTP; 2 Apr 2001 15:38:09 -0000 Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.nortelnetworks.com; Mon, 2 Apr 2001 11:36:38 -0400 Received: from zbl6c016.corpeast.baynetworks.com ([132.245.205.66]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H9V900MT; Mon, 2 Apr 2001 11:36:35 -0400 Received: from nortelnetworks.com (arc.engeast.baynetworks.com [192.32.137.28]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HJCWZ0SW; Mon, 2 Apr 2001 11:36:36 -0400 Message-ID: <3AC89F57.3E0E09B8@nortelnetworks.com> From: "Lakshminath Dondeti" X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Session ID and Group ID References: <4.3.1.2.20010329155417.014d8030@pop.ne.mediaone.net> <3AC347E2.58074E5D@cisco.com> <4.3.2.7.2.20010330053041.00bb7698@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010331034836.0354d3a8@mira-sjc5-6.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: 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: Mon, 02 Apr 2001 11:48:39 -0400 Content-Transfer-Encoding: 7bit Mark, Thanks much for your comments. We probably do need a separate document for the logical key tree mechanisms. The stuff I was proposing is an addition to the GDOI protocol. They were, in more abstract terms, 1) notification messages: unicast/multicast (to support LKH+ and similar mechanisms) 2) version/revision numbers in data messages (again I made the case in context of LKH+, but this would apply to OFT+ and any others, may be future ones.) You are right, we'll know more once a common framework document for tree-based rekeying schemes, as Ran proposed, materializes. Best regards, Lakshminath Mark Baugher wrote: > > hi Lakshminath > I think that we need to have a separate draft document > that describes how an LKH security protocol should > operate. What we have in the GDOI draft is our first > take on what the Security-Association traffic encryption key > (SA TEK) payload needs to be to support an LKH security > protocol. I would not be surprised if we need to change > this by the time we finish an LKH security protocol > document. It hope that the security association key > encrypting key (SA KEK) won't need any changes - > if we find that we need to change SA KEK for new > security protocols, then there's something wrong. The > SA KEK needs to be general wrt security protocols. > > best regards, Mark > At 01:52 PM 3/30/2001 -0500, Lakshminath Dondeti wrote: > >Mark, > > > >Thanks for the explanation. It makes sense. I am looking for > >opinions on incorporating version and revision numbers with > >keys. Particularly in case of LKH+ and similar key determination > >algorithms it makes life easy. For example, in LKH+, when a join > >occurs, the GCKS need not even notify current membership. When > >data comes with a new "revision number", the members "update" the > >corresponding SA appropriately. > > > >I am bringing this up so we can discuss and decide whether it is > >worthwhile to add this to GDOI I-D key payloads. > > > >best regards, > >Lakshminath > > > >PS: I want to reiterate the disclaimer that this was an idea proposed > >in the literature (not by me, see below). > > > > > >Mark Baugher wrote: > > > > > > Lakshminath, > > > > > > At 06:20 PM 3/29/2001 -0500, Lakshminath Dondeti wrote: > > > >Brian, > > > > > > > >I am not getting into this SID discussion at this time. > > > > > > > >But, I am concerned about having a single "active" TEK. I believe > > > >in reality a member needs to maintain a list of TEKs. Consider > > > >data going over a reliable multicast channel. It is plausible > > > >that a member receives two (e.g.) versions of TEKs before she > > > >receives any encrypted data. When the data eventually arrives, > > > >the first few packets could be encrypted with TEK 1.0 and the rest > > > >with TEK 2.0, or vice versa. > > > > > > We use an SPI for this purpose. > > > > > > Mark > > > > > > >I propose that both key and data packets should have "version" and > > > >"revision" tags. The terminology and idea comes from the VersaKey > > > >paper in JSAC 1999/2000 by M. Waldvogel, G. Caronni, B. Plattner and > > > >others. As I recall each time a new key is generated, the version > > > >number is increased, and when a one-way function is used on the current > > > >TEK/KEK for rekeying (ala LKH+), the revision number is increased. > > > > > > > > > > > > > > > >best regards, > > > >Lakshminath > > > > > > > >Brian Weis wrote: > > > > > > > > > > Hi Thomas, > > > > > > > > > > Thomas Hardjono wrote: > > > > > > > > > > > > Recently we had a discussion with some folks who wanted to > > > > > > do group key management in wireless, and a number of questions arose > > > > > > regarding the GSA Model and Definition, and in particular > > > > > > about the notion of Group IDs (GID). > > > > > > > > > > > > So we all know that we need some way to identify a group > > > > > > other than using the (S, G) pair. GSAKMP uses the notion > > > > > > of a Group ID (GID) which can identify a group a high level > > > > > > and which is included in all the GSAKMP messages/headers. > > > > > > In GSAKMP the GID is a 32-bit number (though I think we may > > > > > > need a bigger number). > > > > > > > > > > > > This notion of a GID is also being carried-over into the GDOI work > > > > > > (at least implicitly). > > > > > > > > > > > > So here is the scenario: there is one control channel (Cat-2) > > > > > > and there is multiple data channel (Cat-3), say one for audio and > > > > > > one for video. > > > > > > > > > > > > The question is, if I was a Receiver and was in the process of > > > > > > receiving a key-update (rekey pack) through the push/control SA, > > > > > > how do I identify which key-packs are to be applied to the > > > > > > 2 data channels? In GDOI the update will consist of 2 KEK SAs, > > > > > > but the question still arises: how do I know how to match the KEKs > > > > > > to the multiple Cat-3 SAs. > > > > > > > > > > I followed you up until the last paragraph. In the scenario you > > mention, > > > > > there could be one KEK SA (not two as you say in this paragraph), and > > > > > two TEK SAs. Maybe you meant that the "update will consist of 2 TEK > > > > > SAs"? > > > > > > > > > > In GDOI, the push message includes an SA payload containing the policy > > > > > for the two data channels, and the KD payload contains the new keys for > > > > > the two channels. The SA payload identifies the (S,G) of the data > > > > > channel along with a new SPI (assuming IPSec encapsulation). The KD > > > > > payload includes the new SPI and the new key. It will be obvious which > > > > > key is associated with which data channel. > > > > > > > > > > Or, if you really considering confusion between the two KEKs, the only > > > > > confusion between would be between the current KEK and a new one sent > > > > > down in the push message. > > > > > However, the new one replaces the current KEK after the push message > > > > > processing has completed -- only one should be active at a time per > > > > > group. > > > > > > > > > > > One answer is using a Session-ID (SID) in conjunction with the GID. > > > > > > Thus, each KEK and TEK would need to identify the GID & SID > > > > > > to which the KEK/TEK applies. > > > > > > > > > > The GDOI, there is already a unique value associated with each KEK. The > > > > > cookie-pair in the IKE header is used as the "SPI" for the KEK. If > > a new > > > > > KEK is sent in a push message, the SA payload sends a new cookie-pair > > > > > for the new KEK. > > > > > > > > > > I don't see where a SID is needed for either a TEK or KEK. > > > > > > > > > > Brian Weis > > > > > bew@cisco.com > > > > > > > > > > > Would it be possible, say, to have a 32-bit GID and a 32-bit SID, > > > > > > (assuming that 32-bits of GID is enough)? If a 32-bit GID is too > > much, > > > > > > perhaps we can re-use some of the bits (least significant 8 bit) > > > > > > for the SID? > > > > > > > > > > > > Does this whole SID thing make any sense? > > > > > > > > > > > > thomas > > > > > > ------ > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > > > > > >_______________________________________________ > > > >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 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Apr 2 13:33:02 2001 Received: from pairlist.net ([216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22391 for ; Mon, 2 Apr 2001 13:33:01 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D550C53771; Mon, 2 Apr 2001 13:32:04 -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 D6F735393F for ; Mon, 2 Apr 2001 13:30:18 -0400 (EDT) Received: (qmail 39655 invoked by uid 3269); 2 Apr 2001 17:30:18 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 39652 invoked from network); 2 Apr 2001 17:30:18 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by klesh.pair.com with SMTP; 2 Apr 2001 17:30:18 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id KAA04521; Mon, 2 Apr 2001 10:29:50 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (rtp-dial-1-73.cisco.com [10.83.97.73]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AAB30587; Mon, 2 Apr 2001 10:29:40 -0700 (PDT) Message-Id: <4.3.2.7.2.20010402102725.04086d28@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Lakshminath Dondeti" From: Mark Baugher Subject: Re: [MSEC] Session ID and Group ID Cc: msec@securemulticast.org In-Reply-To: <3AC89F57.3E0E09B8@nortelnetworks.com> References: <4.3.1.2.20010329155417.014d8030@pop.ne.mediaone.net> <3AC347E2.58074E5D@cisco.com> <4.3.2.7.2.20010330053041.00bb7698@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010331034836.0354d3a8@mira-sjc5-6.cisco.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: Mon, 02 Apr 2001 10:28:45 -0700 Lakshminath What is the benefit of having a common framework for group membership management? Mark At 11:48 AM 4/2/2001 -0400, Lakshminath Dondeti wrote: >Mark, > >Thanks much for your comments. We probably do need a separate >document for the logical key tree mechanisms. The stuff I was >proposing is an addition to the GDOI protocol. They were, in >more abstract terms, > > 1) notification messages: unicast/multicast (to support LKH+ >and similar mechanisms) > 2) version/revision numbers in data messages (again I made the >case in context of LKH+, but this would apply to OFT+ and any >others, may be future ones.) > >You are right, we'll know more once a common framework document >for tree-based rekeying schemes, as Ran proposed, materializes. > >Best regards, >Lakshminath > >Mark Baugher wrote: > > > > hi Lakshminath > > I think that we need to have a separate draft document > > that describes how an LKH security protocol should > > operate. What we have in the GDOI draft is our first > > take on what the Security-Association traffic encryption key > > (SA TEK) payload needs to be to support an LKH security > > protocol. I would not be surprised if we need to change > > this by the time we finish an LKH security protocol > > document. It hope that the security association key > > encrypting key (SA KEK) won't need any changes - > > if we find that we need to change SA KEK for new > > security protocols, then there's something wrong. The > > SA KEK needs to be general wrt security protocols. > > > > best regards, Mark > > At 01:52 PM 3/30/2001 -0500, Lakshminath Dondeti wrote: > > >Mark, > > > > > >Thanks for the explanation. It makes sense. I am looking for > > >opinions on incorporating version and revision numbers with > > >keys. Particularly in case of LKH+ and similar key determination > > >algorithms it makes life easy. For example, in LKH+, when a join > > >occurs, the GCKS need not even notify current membership. When > > >data comes with a new "revision number", the members "update" the > > >corresponding SA appropriately. > > > > > >I am bringing this up so we can discuss and decide whether it is > > >worthwhile to add this to GDOI I-D key payloads. > > > > > >best regards, > > >Lakshminath > > > > > >PS: I want to reiterate the disclaimer that this was an idea proposed > > >in the literature (not by me, see below). > > > > > > > > >Mark Baugher wrote: > > > > > > > > Lakshminath, > > > > > > > > At 06:20 PM 3/29/2001 -0500, Lakshminath Dondeti wrote: > > > > >Brian, > > > > > > > > > >I am not getting into this SID discussion at this time. > > > > > > > > > >But, I am concerned about having a single "active" TEK. I believe > > > > >in reality a member needs to maintain a list of TEKs. Consider > > > > >data going over a reliable multicast channel. It is plausible > > > > >that a member receives two (e.g.) versions of TEKs before she > > > > >receives any encrypted data. When the data eventually arrives, > > > > >the first few packets could be encrypted with TEK 1.0 and the rest > > > > >with TEK 2.0, or vice versa. > > > > > > > > We use an SPI for this purpose. > > > > > > > > Mark > > > > > > > > >I propose that both key and data packets should have "version" and > > > > >"revision" tags. The terminology and idea comes from the VersaKey > > > > >paper in JSAC 1999/2000 by M. Waldvogel, G. Caronni, B. Plattner and > > > > >others. As I recall each time a new key is generated, the version > > > > >number is increased, and when a one-way function is used on the > current > > > > >TEK/KEK for rekeying (ala LKH+), the revision number is increased. > > > > > > > > > > > > > > > > > > > >best regards, > > > > >Lakshminath > > > > > > > > > >Brian Weis wrote: > > > > > > > > > > > > Hi Thomas, > > > > > > > > > > > > Thomas Hardjono wrote: > > > > > > > > > > > > > > Recently we had a discussion with some folks who wanted to > > > > > > > do group key management in wireless, and a number of > questions arose > > > > > > > regarding the GSA Model and Definition, and in particular > > > > > > > about the notion of Group IDs (GID). > > > > > > > > > > > > > > So we all know that we need some way to identify a group > > > > > > > other than using the (S, G) pair. GSAKMP uses the notion > > > > > > > of a Group ID (GID) which can identify a group a high level > > > > > > > and which is included in all the GSAKMP messages/headers. > > > > > > > In GSAKMP the GID is a 32-bit number (though I think we may > > > > > > > need a bigger number). > > > > > > > > > > > > > > This notion of a GID is also being carried-over into the GDOI > work > > > > > > > (at least implicitly). > > > > > > > > > > > > > > So here is the scenario: there is one control channel (Cat-2) > > > > > > > and there is multiple data channel (Cat-3), say one for audio and > > > > > > > one for video. > > > > > > > > > > > > > > The question is, if I was a Receiver and was in the process of > > > > > > > receiving a key-update (rekey pack) through the push/control SA, > > > > > > > how do I identify which key-packs are to be applied to the > > > > > > > 2 data channels? In GDOI the update will consist of 2 KEK SAs, > > > > > > > but the question still arises: how do I know how to match the > KEKs > > > > > > > to the multiple Cat-3 SAs. > > > > > > > > > > > > I followed you up until the last paragraph. In the scenario you > > > mention, > > > > > > there could be one KEK SA (not two as you say in this > paragraph), and > > > > > > two TEK SAs. Maybe you meant that the "update will consist of 2 TEK > > > > > > SAs"? > > > > > > > > > > > > In GDOI, the push message includes an SA payload containing the > policy > > > > > > for the two data channels, and the KD payload contains the new > keys for > > > > > > the two channels. The SA payload identifies the (S,G) of the data > > > > > > channel along with a new SPI (assuming IPSec encapsulation). The KD > > > > > > payload includes the new SPI and the new key. It will be > obvious which > > > > > > key is associated with which data channel. > > > > > > > > > > > > Or, if you really considering confusion between the two KEKs, > the only > > > > > > confusion between would be between the current KEK and a new > one sent > > > > > > down in the push message. > > > > > > However, the new one replaces the current KEK after the push > message > > > > > > processing has completed -- only one should be active at a time per > > > > > > group. > > > > > > > > > > > > > One answer is using a Session-ID (SID) in conjunction with > the GID. > > > > > > > Thus, each KEK and TEK would need to identify the GID & SID > > > > > > > to which the KEK/TEK applies. > > > > > > > > > > > > The GDOI, there is already a unique value associated with each > KEK. The > > > > > > cookie-pair in the IKE header is used as the "SPI" for the KEK. If > > > a new > > > > > > KEK is sent in a push message, the SA payload sends a new > cookie-pair > > > > > > for the new KEK. > > > > > > > > > > > > I don't see where a SID is needed for either a TEK or KEK. > > > > > > > > > > > > Brian Weis > > > > > > bew@cisco.com > > > > > > > > > > > > > Would it be possible, say, to have a 32-bit GID and a 32-bit SID, > > > > > > > (assuming that 32-bits of GID is enough)? If a 32-bit GID is too > > > much, > > > > > > > perhaps we can re-use some of the bits (least significant 8 bit) > > > > > > > for the SID? > > > > > > > > > > > > > > Does this whole SID thing make any sense? > > > > > > > > > > > > > > thomas > > > > > > > ------ > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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 > > > > > > > > > >_______________________________________________ > > > > >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 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Apr 2 15:44:54 2001 Received: from pairlist.net ([216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27467 for ; Mon, 2 Apr 2001 15:44:54 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B8C045372F; Mon, 2 Apr 2001 15:44:13 -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 13BE6535E6 for ; Mon, 2 Apr 2001 15:43:09 -0400 (EDT) Received: (qmail 50932 invoked by uid 3269); 2 Apr 2001 19:43:08 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 50927 invoked from network); 2 Apr 2001 19:43:08 -0000 Received: from zcars04f.nortelnetworks.com (HELO zcars04f.ca.nortel.com) (47.129.242.57) by klesh.pair.com with SMTP; 2 Apr 2001 19:43:08 -0000 Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Mon, 2 Apr 2001 15:16:26 -0400 Received: from zbl6c016.corpeast.baynetworks.com ([132.245.205.66]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H9V9009Y; Mon, 2 Apr 2001 15:16:26 -0400 Received: from nortelnetworks.com (arc.engeast.baynetworks.com [192.32.137.28]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HJCWZ0Y1; Mon, 2 Apr 2001 15:16:25 -0400 Message-ID: <3AC8D2DF.4C9B6EFA@nortelnetworks.com> From: "Lakshminath Dondeti" X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Session ID and Group ID References: <4.3.1.2.20010329155417.014d8030@pop.ne.mediaone.net> <3AC347E2.58074E5D@cisco.com> <4.3.2.7.2.20010330053041.00bb7698@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010331034836.0354d3a8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010402102725.04086d28@mira-sjc5-6.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: 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: Mon, 02 Apr 2001 15:28:31 -0400 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > > Lakshminath > What is the benefit of having a common framework for group > membership management? > > Mark Mark, Good question! :-) Although I am not sure my message below is proposing a common framework for group membership management. Let me address both key tree management and group membership management, to the best of my knowledge :-) Case for common framework for key tree management: -------------------------------------------------- As I understand, for join rekeying we can use the "one-way hash function" technique to cut down on rekeying (communication) overhead in LKH, OFT(?), and others? I know of some distributed key determination schemes that could use this technique. My guess is that there are other common aspects (similar payload formats should help in implementation -- Ran and Thomas' opinion/idea) of rekeying mechanisms. My thinking is that the common framework document would glean that information. Out of that, we could figure out what needs to be added to the GDOI (or similar) protocol, or whatever (I am not sure yet). Group membership management: ---------------------------- The layer-3 thing for this is IGMP. In our case (may be this was resolved earlier, I am sorry I was not there), this means a way for the GCKS to get leave "notifications" from members. For completeness, SA1 of GDOI is an implicit join "notification" (request really). I am sure there will be other kinds of notifications that will come up (distributed GCKS comes to mind). Oh well, that is my stab at that question :-) best regards, Lakshminath > At 11:48 AM 4/2/2001 -0400, Lakshminath Dondeti wrote: > >Mark, > > > >Thanks much for your comments. We probably do need a separate > >document for the logical key tree mechanisms. The stuff I was > >proposing is an addition to the GDOI protocol. They were, in > >more abstract terms, > > > > 1) notification messages: unicast/multicast (to support LKH+ > >and similar mechanisms) > > 2) version/revision numbers in data messages (again I made the > >case in context of LKH+, but this would apply to OFT+ and any > >others, may be future ones.) > > > >You are right, we'll know more once a common framework document > >for tree-based rekeying schemes, as Ran proposed, materializes. > > > >Best regards, > >Lakshminath > > > >Mark Baugher wrote: > > > > > > hi Lakshminath > > > I think that we need to have a separate draft document > > > that describes how an LKH security protocol should > > > operate. What we have in the GDOI draft is our first > > > take on what the Security-Association traffic encryption key > > > (SA TEK) payload needs to be to support an LKH security > > > protocol. I would not be surprised if we need to change > > > this by the time we finish an LKH security protocol > > > document. It hope that the security association key > > > encrypting key (SA KEK) won't need any changes - > > > if we find that we need to change SA KEK for new > > > security protocols, then there's something wrong. The > > > SA KEK needs to be general wrt security protocols. > > > > > > best regards, Mark > > > At 01:52 PM 3/30/2001 -0500, Lakshminath Dondeti wrote: > > > >Mark, > > > > > > > >Thanks for the explanation. It makes sense. I am looking for > > > >opinions on incorporating version and revision numbers with > > > >keys. Particularly in case of LKH+ and similar key determination > > > >algorithms it makes life easy. For example, in LKH+, when a join > > > >occurs, the GCKS need not even notify current membership. When > > > >data comes with a new "revision number", the members "update" the > > > >corresponding SA appropriately. > > > > > > > >I am bringing this up so we can discuss and decide whether it is > > > >worthwhile to add this to GDOI I-D key payloads. > > > > > > > >best regards, > > > >Lakshminath > > > > > > > >PS: I want to reiterate the disclaimer that this was an idea proposed > > > >in the literature (not by me, see below). > > > > > > > > > > > >Mark Baugher wrote: > > > > > > > > > > Lakshminath, > > > > > > > > > > At 06:20 PM 3/29/2001 -0500, Lakshminath Dondeti wrote: > > > > > >Brian, > > > > > > > > > > > >I am not getting into this SID discussion at this time. > > > > > > > > > > > >But, I am concerned about having a single "active" TEK. I believe > > > > > >in reality a member needs to maintain a list of TEKs. Consider > > > > > >data going over a reliable multicast channel. It is plausible > > > > > >that a member receives two (e.g.) versions of TEKs before she > > > > > >receives any encrypted data. When the data eventually arrives, > > > > > >the first few packets could be encrypted with TEK 1.0 and the rest > > > > > >with TEK 2.0, or vice versa. > > > > > > > > > > We use an SPI for this purpose. > > > > > > > > > > Mark > > > > > > > > > > >I propose that both key and data packets should have "version" and > > > > > >"revision" tags. The terminology and idea comes from the VersaKey > > > > > >paper in JSAC 1999/2000 by M. Waldvogel, G. Caronni, B. Plattner and > > > > > >others. As I recall each time a new key is generated, the version > > > > > >number is increased, and when a one-way function is used on the > > current > > > > > >TEK/KEK for rekeying (ala LKH+), the revision number is increased. > > > > > > > > > > > > > > > > > > > > > > > >best regards, > > > > > >Lakshminath > > > > > > > > > > > >Brian Weis wrote: > > > > > > > > > > > > > > Hi Thomas, > > > > > > > > > > > > > > Thomas Hardjono wrote: > > > > > > > > > > > > > > > > Recently we had a discussion with some folks who wanted to > > > > > > > > do group key management in wireless, and a number of > > questions arose > > > > > > > > regarding the GSA Model and Definition, and in particular > > > > > > > > about the notion of Group IDs (GID). > > > > > > > > > > > > > > > > So we all know that we need some way to identify a group > > > > > > > > other than using the (S, G) pair. GSAKMP uses the notion > > > > > > > > of a Group ID (GID) which can identify a group a high level > > > > > > > > and which is included in all the GSAKMP messages/headers. > > > > > > > > In GSAKMP the GID is a 32-bit number (though I think we may > > > > > > > > need a bigger number). > > > > > > > > > > > > > > > > This notion of a GID is also being carried-over into the GDOI > > work > > > > > > > > (at least implicitly). > > > > > > > > > > > > > > > > So here is the scenario: there is one control channel (Cat-2) > > > > > > > > and there is multiple data channel (Cat-3), say one for audio and > > > > > > > > one for video. > > > > > > > > > > > > > > > > The question is, if I was a Receiver and was in the process of > > > > > > > > receiving a key-update (rekey pack) through the push/control SA, > > > > > > > > how do I identify which key-packs are to be applied to the > > > > > > > > 2 data channels? In GDOI the update will consist of 2 KEK SAs, > > > > > > > > but the question still arises: how do I know how to match the > > KEKs > > > > > > > > to the multiple Cat-3 SAs. > > > > > > > > > > > > > > I followed you up until the last paragraph. In the scenario you > > > > mention, > > > > > > > there could be one KEK SA (not two as you say in this > > paragraph), and > > > > > > > two TEK SAs. Maybe you meant that the "update will consist of 2 TEK > > > > > > > SAs"? > > > > > > > > > > > > > > In GDOI, the push message includes an SA payload containing the > > policy > > > > > > > for the two data channels, and the KD payload contains the new > > keys for > > > > > > > the two channels. The SA payload identifies the (S,G) of the data > > > > > > > channel along with a new SPI (assuming IPSec encapsulation). The KD > > > > > > > payload includes the new SPI and the new key. It will be > > obvious which > > > > > > > key is associated with which data channel. > > > > > > > > > > > > > > Or, if you really considering confusion between the two KEKs, > > the only > > > > > > > confusion between would be between the current KEK and a new > > one sent > > > > > > > down in the push message. > > > > > > > However, the new one replaces the current KEK after the push > > message > > > > > > > processing has completed -- only one should be active at a time per > > > > > > > group. > > > > > > > > > > > > > > > One answer is using a Session-ID (SID) in conjunction with > > the GID. > > > > > > > > Thus, each KEK and TEK would need to identify the GID & SID > > > > > > > > to which the KEK/TEK applies. > > > > > > > > > > > > > > The GDOI, there is already a unique value associated with each > > KEK. The > > > > > > > cookie-pair in the IKE header is used as the "SPI" for the KEK. If > > > > a new > > > > > > > KEK is sent in a push message, the SA payload sends a new > > cookie-pair > > > > > > > for the new KEK. > > > > > > > > > > > > > > I don't see where a SID is needed for either a TEK or KEK. > > > > > > > > > > > > > > Brian Weis > > > > > > > bew@cisco.com > > > > > > > > > > > > > > > Would it be possible, say, to have a 32-bit GID and a 32-bit SID, > > > > > > > > (assuming that 32-bits of GID is enough)? If a 32-bit GID is too > > > > much, > > > > > > > > perhaps we can re-use some of the bits (least significant 8 bit) > > > > > > > > for the SID? > > > > > > > > > > > > > > > > Does this whole SID thing make any sense? > > > > > > > > > > > > > > > > thomas > > > > > > > > ------ > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > 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 > > > > > > > > > > > >_______________________________________________ > > > > > >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 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Apr 3 12:47:54 2001 Received: from pairlist.net ([216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07505 for ; Tue, 3 Apr 2001 12:47:53 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 54C1753890; Tue, 3 Apr 2001 12:46:12 -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 BEE2D5373B for ; Tue, 3 Apr 2001 12:45:28 -0400 (EDT) Received: (qmail 58261 invoked by uid 3269); 3 Apr 2001 16:45:28 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 58258 invoked from network); 3 Apr 2001 16:45:28 -0000 Received: from softdnserror (HELO sj-msg-core-4.cisco.com) (171.71.163.10) by klesh.pair.com with SMTP; 3 Apr 2001 16:45:28 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id JAA25099; Tue, 3 Apr 2001 09:45:00 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-439.cisco.com [10.21.65.183]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AAB49338; Tue, 3 Apr 2001 09:44:54 -0700 (PDT) Message-Id: <4.3.2.7.2.20010403091534.03f89c20@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Lakshminath Dondeti" From: Mark Baugher Subject: Re: [MSEC] Session ID and Group ID Cc: msec@securemulticast.org In-Reply-To: <3AC8D2DF.4C9B6EFA@nortelnetworks.com> References: <4.3.1.2.20010329155417.014d8030@pop.ne.mediaone.net> <3AC347E2.58074E5D@cisco.com> <4.3.2.7.2.20010330053041.00bb7698@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010331034836.0354d3a8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010402102725.04086d28@mira-sjc5-6.cisco.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: Tue, 03 Apr 2001 09:43:59 -0700 Hi Lakshminath We have a problem with the word "Group" in our group:-) we use Group ID in GDOI (taken from GSAKMP) and this may be confused with DH groups in OAKLEY/IKE. We use group management and that can be confused with multicast group management - IGMP. All of these things are quite different. Our groups can encompass zero or more multicast groups. We talk about group management in the context of different group management algorithms that can use multicast to efficiently add or remove group members, which may or may not use multicast communications amongst themselves. We know of a few good algorithms. I expect more work in this area but personally don't see the value in coming up with a common specification for them. It would be better to develop the key management framework to accommodate them without forcing them to use common payloads. Mark At 03:28 PM 4/2/2001 -0400, Lakshminath Dondeti wrote: >Mark Baugher wrote: > > > > Lakshminath > > What is the benefit of having a common framework for group > > membership management? > > > > Mark > >Mark, > >Good question! :-) Although I am not sure my message below is >proposing a common framework for group membership management. >Let me address both key tree management and group membership >management, to the best of my knowledge :-) > >Case for common framework for key tree management: >-------------------------------------------------- >As I understand, for join rekeying we can use the "one-way >hash function" technique to cut down on rekeying (communication) >overhead in LKH, OFT(?), and others? I know of some distributed >key determination schemes that could use this technique. > >My guess is that there are other common aspects (similar >payload formats should help in implementation -- Ran and >Thomas' opinion/idea) of rekeying mechanisms. My thinking >is that the common framework document would glean that >information. Out of that, we could figure out what >needs to be added to the GDOI (or similar) protocol, or >whatever (I am not sure yet). > >Group membership management: >---------------------------- >The layer-3 thing for this is IGMP. > >In our case (may be this was resolved earlier, I am sorry I was not >there), this means a way for the GCKS to get leave "notifications" >from members. For completeness, SA1 of GDOI is an implicit join >"notification" (request really). I am sure there will be other >kinds of notifications that will come up (distributed GCKS comes >to mind). > >Oh well, that is my stab at that question :-) > >best regards, >Lakshminath > > > > At 11:48 AM 4/2/2001 -0400, Lakshminath Dondeti wrote: > > >Mark, > > > > > >Thanks much for your comments. We probably do need a separate > > >document for the logical key tree mechanisms. The stuff I was > > >proposing is an addition to the GDOI protocol. They were, in > > >more abstract terms, > > > > > > 1) notification messages: unicast/multicast (to support LKH+ > > >and similar mechanisms) > > > 2) version/revision numbers in data messages (again I made the > > >case in context of LKH+, but this would apply to OFT+ and any > > >others, may be future ones.) > > > > > >You are right, we'll know more once a common framework document > > >for tree-based rekeying schemes, as Ran proposed, materializes. > > > > > >Best regards, > > >Lakshminath > > > > > >Mark Baugher wrote: > > > > > > > > hi Lakshminath > > > > I think that we need to have a separate draft document > > > > that describes how an LKH security protocol should > > > > operate. What we have in the GDOI draft is our first > > > > take on what the Security-Association traffic encryption key > > > > (SA TEK) payload needs to be to support an LKH security > > > > protocol. I would not be surprised if we need to change > > > > this by the time we finish an LKH security protocol > > > > document. It hope that the security association key > > > > encrypting key (SA KEK) won't need any changes - > > > > if we find that we need to change SA KEK for new > > > > security protocols, then there's something wrong. The > > > > SA KEK needs to be general wrt security protocols. > > > > > > > > best regards, Mark > > > > At 01:52 PM 3/30/2001 -0500, Lakshminath Dondeti wrote: > > > > >Mark, > > > > > > > > > >Thanks for the explanation. It makes sense. I am looking for > > > > >opinions on incorporating version and revision numbers with > > > > >keys. Particularly in case of LKH+ and similar key determination > > > > >algorithms it makes life easy. For example, in LKH+, when a join > > > > >occurs, the GCKS need not even notify current membership. When > > > > >data comes with a new "revision number", the members "update" the > > > > >corresponding SA appropriately. > > > > > > > > > >I am bringing this up so we can discuss and decide whether it is > > > > >worthwhile to add this to GDOI I-D key payloads. > > > > > > > > > >best regards, > > > > >Lakshminath > > > > > > > > > >PS: I want to reiterate the disclaimer that this was an idea proposed > > > > >in the literature (not by me, see below). > > > > > > > > > > > > > > >Mark Baugher wrote: > > > > > > > > > > > > Lakshminath, > > > > > > > > > > > > At 06:20 PM 3/29/2001 -0500, Lakshminath Dondeti wrote: > > > > > > >Brian, > > > > > > > > > > > > > >I am not getting into this SID discussion at this time. > > > > > > > > > > > > > >But, I am concerned about having a single "active" TEK. I believe > > > > > > >in reality a member needs to maintain a list of TEKs. Consider > > > > > > >data going over a reliable multicast channel. It is plausible > > > > > > >that a member receives two (e.g.) versions of TEKs before she > > > > > > >receives any encrypted data. When the data eventually arrives, > > > > > > >the first few packets could be encrypted with TEK 1.0 and the rest > > > > > > >with TEK 2.0, or vice versa. > > > > > > > > > > > > We use an SPI for this purpose. > > > > > > > > > > > > Mark > > > > > > > > > > > > >I propose that both key and data packets should have "version" and > > > > > > >"revision" tags. The terminology and idea comes from the VersaKey > > > > > > >paper in JSAC 1999/2000 by M. Waldvogel, G. Caronni, B. > Plattner and > > > > > > >others. As I recall each time a new key is generated, the version > > > > > > >number is increased, and when a one-way function is used on the > > > current > > > > > > >TEK/KEK for rekeying (ala LKH+), the revision number is increased. > > > > > > > > > > > > > > > > > > > > > > > > > > > >best regards, > > > > > > >Lakshminath > > > > > > > > > > > > > >Brian Weis wrote: > > > > > > > > > > > > > > > > Hi Thomas, > > > > > > > > > > > > > > > > Thomas Hardjono wrote: > > > > > > > > > > > > > > > > > > Recently we had a discussion with some folks who wanted to > > > > > > > > > do group key management in wireless, and a number of > > > questions arose > > > > > > > > > regarding the GSA Model and Definition, and in particular > > > > > > > > > about the notion of Group IDs (GID). > > > > > > > > > > > > > > > > > > So we all know that we need some way to identify a group > > > > > > > > > other than using the (S, G) pair. GSAKMP uses the notion > > > > > > > > > of a Group ID (GID) which can identify a group a high level > > > > > > > > > and which is included in all the GSAKMP messages/headers. > > > > > > > > > In GSAKMP the GID is a 32-bit number (though I think we may > > > > > > > > > need a bigger number). > > > > > > > > > > > > > > > > > > This notion of a GID is also being carried-over into the GDOI > > > work > > > > > > > > > (at least implicitly). > > > > > > > > > > > > > > > > > > So here is the scenario: there is one control channel > (Cat-2) > > > > > > > > > and there is multiple data channel (Cat-3), say one for > audio and > > > > > > > > > one for video. > > > > > > > > > > > > > > > > > > The question is, if I was a Receiver and was in the > process of > > > > > > > > > receiving a key-update (rekey pack) through the > push/control SA, > > > > > > > > > how do I identify which key-packs are to be applied to the > > > > > > > > > 2 data channels? In GDOI the update will consist of 2 > KEK SAs, > > > > > > > > > but the question still arises: how do I know how to match the > > > KEKs > > > > > > > > > to the multiple Cat-3 SAs. > > > > > > > > > > > > > > > > I followed you up until the last paragraph. In the scenario you > > > > > mention, > > > > > > > > there could be one KEK SA (not two as you say in this > > > paragraph), and > > > > > > > > two TEK SAs. Maybe you meant that the "update will consist > of 2 TEK > > > > > > > > SAs"? > > > > > > > > > > > > > > > > In GDOI, the push message includes an SA payload containing the > > > policy > > > > > > > > for the two data channels, and the KD payload contains the new > > > keys for > > > > > > > > the two channels. The SA payload identifies the (S,G) of > the data > > > > > > > > channel along with a new SPI (assuming IPSec > encapsulation). The KD > > > > > > > > payload includes the new SPI and the new key. It will be > > > obvious which > > > > > > > > key is associated with which data channel. > > > > > > > > > > > > > > > > Or, if you really considering confusion between the two KEKs, > > > the only > > > > > > > > confusion between would be between the current KEK and a new > > > one sent > > > > > > > > down in the push message. > > > > > > > > However, the new one replaces the current KEK after the push > > > message > > > > > > > > processing has completed -- only one should be active at a > time per > > > > > > > > group. > > > > > > > > > > > > > > > > > One answer is using a Session-ID (SID) in conjunction with > > > the GID. > > > > > > > > > Thus, each KEK and TEK would need to identify the GID & SID > > > > > > > > > to which the KEK/TEK applies. > > > > > > > > > > > > > > > > The GDOI, there is already a unique value associated with each > > > KEK. The > > > > > > > > cookie-pair in the IKE header is used as the "SPI" for the > KEK. If > > > > > a new > > > > > > > > KEK is sent in a push message, the SA payload sends a new > > > cookie-pair > > > > > > > > for the new KEK. > > > > > > > > > > > > > > > > I don't see where a SID is needed for either a TEK or KEK. > > > > > > > > > > > > > > > > Brian Weis > > > > > > > > bew@cisco.com > > > > > > > > > > > > > > > > > Would it be possible, say, to have a 32-bit GID and a > 32-bit SID, > > > > > > > > > (assuming that 32-bits of GID is enough)? If a 32-bit > GID is too > > > > > much, > > > > > > > > > perhaps we can re-use some of the bits (least significant > 8 bit) > > > > > > > > > for the SID? > > > > > > > > > > > > > > > > > > Does this whole SID thing make any sense? > > > > > > > > > > > > > > > > > > thomas > > > > > > > > > ------ > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > 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 > > > > > > > > > > > > > >_______________________________________________ > > > > > > >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 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Apr 3 15:13:42 2001 Received: from pairlist.net ([216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13801 for ; Tue, 3 Apr 2001 15:13:42 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 94A60538D6; Tue, 3 Apr 2001 15:12:37 -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 197E853777 for ; Tue, 3 Apr 2001 15:11:42 -0400 (EDT) Received: (qmail 71469 invoked by uid 3269); 3 Apr 2001 19:11:41 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 71464 invoked from network); 3 Apr 2001 19:11:41 -0000 Received: from zcars04e.nortelnetworks.com (47.129.242.56) by klesh.pair.com with SMTP; 3 Apr 2001 19:11:41 -0000 Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.nortelnetworks.com; Tue, 3 Apr 2001 15:10:44 -0400 Received: from zbl6c016.corpeast.baynetworks.com ([132.245.205.66]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H9V0ABQF; Tue, 3 Apr 2001 15:10:42 -0400 Received: from nortelnetworks.com (arc.engeast.baynetworks.com [192.32.137.28]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HJCW5ASH; Tue, 3 Apr 2001 15:10:43 -0400 Message-ID: <3ACA2304.11CC8D74@nortelnetworks.com> From: "Lakshminath Dondeti" X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Session ID and Group ID References: <4.3.1.2.20010329155417.014d8030@pop.ne.mediaone.net> <3AC347E2.58074E5D@cisco.com> <4.3.2.7.2.20010330053041.00bb7698@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010331034836.0354d3a8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010402102725.04086d28@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010403091534.03f89c20@mira-sjc5-6.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: 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: Tue, 03 Apr 2001 15:22:44 -0400 Content-Transfer-Encoding: 7bit Mark, Thanks much for the clarification. You know we probably should compile a glossary of terms used in the MSEC context. There are others such as PFS in IKE/ISAKMP/IPSEC and PFS in group security literature (forward access control in our terminology). Anyway, as I understand, you are for having something similar to Appendix B (LKH Data Key Download Definitions) in GDOI I-D, separately for each of the proposed/future key management schemes. Is that correct? best regards, Lakshminath Mark Baugher wrote: > > Hi Lakshminath > We have a problem with the word "Group" in our group:-) > we use Group ID in GDOI (taken from GSAKMP) and this may > be confused with DH groups in OAKLEY/IKE. We use > group management and that can be confused with multicast > group management - IGMP. All of these things are quite > different. Our groups can encompass zero or more multicast > groups. > > We talk about group management in the context of different > group management algorithms that can use multicast to > efficiently add or remove group members, which may or > may not use multicast communications amongst themselves. > We know of a few good algorithms. I expect more work > in this area but personally don't see the value in coming up > with a common specification for them. It would be better > to develop the key management framework to accommodate > them without forcing them to use common payloads. > > Mark > At 03:28 PM 4/2/2001 -0400, Lakshminath Dondeti wrote: > >Mark Baugher wrote: > > > > > > Lakshminath > > > What is the benefit of having a common framework for group > > > membership management? > > > > > > Mark > > > >Mark, > > > >Good question! :-) Although I am not sure my message below is > >proposing a common framework for group membership management. > >Let me address both key tree management and group membership > >management, to the best of my knowledge :-) > > > >Case for common framework for key tree management: > >-------------------------------------------------- > >As I understand, for join rekeying we can use the "one-way > >hash function" technique to cut down on rekeying (communication) > >overhead in LKH, OFT(?), and others? I know of some distributed > >key determination schemes that could use this technique. > > > >My guess is that there are other common aspects (similar > >payload formats should help in implementation -- Ran and > >Thomas' opinion/idea) of rekeying mechanisms. My thinking > >is that the common framework document would glean that > >information. Out of that, we could figure out what > >needs to be added to the GDOI (or similar) protocol, or > >whatever (I am not sure yet). > > > >Group membership management: > >---------------------------- > >The layer-3 thing for this is IGMP. > > > >In our case (may be this was resolved earlier, I am sorry I was not > >there), this means a way for the GCKS to get leave "notifications" > >from members. For completeness, SA1 of GDOI is an implicit join > >"notification" (request really). I am sure there will be other > >kinds of notifications that will come up (distributed GCKS comes > >to mind). > > > >Oh well, that is my stab at that question :-) > > > >best regards, > >Lakshminath > > > > > > > At 11:48 AM 4/2/2001 -0400, Lakshminath Dondeti wrote: > > > >Mark, > > > > > > > >Thanks much for your comments. We probably do need a separate > > > >document for the logical key tree mechanisms. The stuff I was > > > >proposing is an addition to the GDOI protocol. They were, in > > > >more abstract terms, > > > > > > > > 1) notification messages: unicast/multicast (to support LKH+ > > > >and similar mechanisms) > > > > 2) version/revision numbers in data messages (again I made the > > > >case in context of LKH+, but this would apply to OFT+ and any > > > >others, may be future ones.) > > > > > > > >You are right, we'll know more once a common framework document > > > >for tree-based rekeying schemes, as Ran proposed, materializes. > > > > > > > >Best regards, > > > >Lakshminath > > > > > > > >Mark Baugher wrote: > > > > > > > > > > hi Lakshminath > > > > > I think that we need to have a separate draft document > > > > > that describes how an LKH security protocol should > > > > > operate. What we have in the GDOI draft is our first > > > > > take on what the Security-Association traffic encryption key > > > > > (SA TEK) payload needs to be to support an LKH security > > > > > protocol. I would not be surprised if we need to change > > > > > this by the time we finish an LKH security protocol > > > > > document. It hope that the security association key > > > > > encrypting key (SA KEK) won't need any changes - > > > > > if we find that we need to change SA KEK for new > > > > > security protocols, then there's something wrong. The > > > > > SA KEK needs to be general wrt security protocols. > > > > > > > > > > best regards, Mark > > > > > At 01:52 PM 3/30/2001 -0500, Lakshminath Dondeti wrote: > > > > > >Mark, > > > > > > > > > > > >Thanks for the explanation. It makes sense. I am looking for > > > > > >opinions on incorporating version and revision numbers with > > > > > >keys. Particularly in case of LKH+ and similar key determination > > > > > >algorithms it makes life easy. For example, in LKH+, when a join > > > > > >occurs, the GCKS need not even notify current membership. When > > > > > >data comes with a new "revision number", the members "update" the > > > > > >corresponding SA appropriately. > > > > > > > > > > > >I am bringing this up so we can discuss and decide whether it is > > > > > >worthwhile to add this to GDOI I-D key payloads. > > > > > > > > > > > >best regards, > > > > > >Lakshminath > > > > > > > > > > > >PS: I want to reiterate the disclaimer that this was an idea proposed > > > > > >in the literature (not by me, see below). > > > > > > > > > > > > > > > > > >Mark Baugher wrote: > > > > > > > > > > > > > > Lakshminath, > > > > > > > > > > > > > > At 06:20 PM 3/29/2001 -0500, Lakshminath Dondeti wrote: > > > > > > > >Brian, > > > > > > > > > > > > > > > >I am not getting into this SID discussion at this time. > > > > > > > > > > > > > > > >But, I am concerned about having a single "active" TEK. I believe > > > > > > > >in reality a member needs to maintain a list of TEKs. Consider > > > > > > > >data going over a reliable multicast channel. It is plausible > > > > > > > >that a member receives two (e.g.) versions of TEKs before she > > > > > > > >receives any encrypted data. When the data eventually arrives, > > > > > > > >the first few packets could be encrypted with TEK 1.0 and the rest > > > > > > > >with TEK 2.0, or vice versa. > > > > > > > > > > > > > > We use an SPI for this purpose. > > > > > > > > > > > > > > Mark > > > > > > > > > > > > > > >I propose that both key and data packets should have "version" and > > > > > > > >"revision" tags. The terminology and idea comes from the VersaKey > > > > > > > >paper in JSAC 1999/2000 by M. Waldvogel, G. Caronni, B. > > Plattner and > > > > > > > >others. As I recall each time a new key is generated, the version > > > > > > > >number is increased, and when a one-way function is used on the > > > > current > > > > > > > >TEK/KEK for rekeying (ala LKH+), the revision number is increased. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >best regards, > > > > > > > >Lakshminath > > > > > > > > > > > > > > > >Brian Weis wrote: > > > > > > > > > > > > > > > > > > Hi Thomas, > > > > > > > > > > > > > > > > > > Thomas Hardjono wrote: > > > > > > > > > > > > > > > > > > > > Recently we had a discussion with some folks who wanted to > > > > > > > > > > do group key management in wireless, and a number of > > > > questions arose > > > > > > > > > > regarding the GSA Model and Definition, and in particular > > > > > > > > > > about the notion of Group IDs (GID). > > > > > > > > > > > > > > > > > > > > So we all know that we need some way to identify a group > > > > > > > > > > other than using the (S, G) pair. GSAKMP uses the notion > > > > > > > > > > of a Group ID (GID) which can identify a group a high level > > > > > > > > > > and which is included in all the GSAKMP messages/headers. > > > > > > > > > > In GSAKMP the GID is a 32-bit number (though I think we may > > > > > > > > > > need a bigger number). > > > > > > > > > > > > > > > > > > > > This notion of a GID is also being carried-over into the GDOI > > > > work > > > > > > > > > > (at least implicitly). > > > > > > > > > > > > > > > > > > > > So here is the scenario: there is one control channel > > (Cat-2) > > > > > > > > > > and there is multiple data channel (Cat-3), say one for > > audio and > > > > > > > > > > one for video. > > > > > > > > > > > > > > > > > > > > The question is, if I was a Receiver and was in the > > process of > > > > > > > > > > receiving a key-update (rekey pack) through the > > push/control SA, > > > > > > > > > > how do I identify which key-packs are to be applied to the > > > > > > > > > > 2 data channels? In GDOI the update will consist of 2 > > KEK SAs, > > > > > > > > > > but the question still arises: how do I know how to match the > > > > KEKs > > > > > > > > > > to the multiple Cat-3 SAs. > > > > > > > > > > > > > > > > > > I followed you up until the last paragraph. In the scenario you > > > > > > mention, > > > > > > > > > there could be one KEK SA (not two as you say in this > > > > paragraph), and > > > > > > > > > two TEK SAs. Maybe you meant that the "update will consist > > of 2 TEK > > > > > > > > > SAs"? > > > > > > > > > > > > > > > > > > In GDOI, the push message includes an SA payload containing the > > > > policy > > > > > > > > > for the two data channels, and the KD payload contains the new > > > > keys for > > > > > > > > > the two channels. The SA payload identifies the (S,G) of > > the data > > > > > > > > > channel along with a new SPI (assuming IPSec > > encapsulation). The KD > > > > > > > > > payload includes the new SPI and the new key. It will be > > > > obvious which > > > > > > > > > key is associated with which data channel. > > > > > > > > > > > > > > > > > > Or, if you really considering confusion between the two KEKs, > > > > the only > > > > > > > > > confusion between would be between the current KEK and a new > > > > one sent > > > > > > > > > down in the push message. > > > > > > > > > However, the new one replaces the current KEK after the push > > > > message > > > > > > > > > processing has completed -- only one should be active at a > > time per > > > > > > > > > group. > > > > > > > > > > > > > > > > > > > One answer is using a Session-ID (SID) in conjunction with > > > > the GID. > > > > > > > > > > Thus, each KEK and TEK would need to identify the GID & SID > > > > > > > > > > to which the KEK/TEK applies. > > > > > > > > > > > > > > > > > > The GDOI, there is already a unique value associated with each > > > > KEK. The > > > > > > > > > cookie-pair in the IKE header is used as the "SPI" for the > > KEK. If > > > > > > a new > > > > > > > > > KEK is sent in a push message, the SA payload sends a new > > > > cookie-pair > > > > > > > > > for the new KEK. > > > > > > > > > > > > > > > > > > I don't see where a SID is needed for either a TEK or KEK. > > > > > > > > > > > > > > > > > > Brian Weis > > > > > > > > > bew@cisco.com > > > > > > > > > > > > > > > > > > > Would it be possible, say, to have a 32-bit GID and a > > 32-bit SID, > > > > > > > > > > (assuming that 32-bits of GID is enough)? If a 32-bit > > GID is too > > > > > > much, > > > > > > > > > > perhaps we can re-use some of the bits (least significant > > 8 bit) > > > > > > > > > > for the SID? > > > > > > > > > > > > > > > > > > > > Does this whole SID thing make any sense? > > > > > > > > > > > > > > > > > > > > thomas > > > > > > > > > > ------ > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > 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 > > > > > > > > > > > > > > > >_______________________________________________ > > > > > > > >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 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Apr 3 16:29:16 2001 Received: from pairlist.net ([216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15797 for ; Tue, 3 Apr 2001 16:29:15 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4A677538E0; Tue, 3 Apr 2001 16:28:12 -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 3D473537F4 for ; Tue, 3 Apr 2001 16:27:31 -0400 (EDT) Received: (qmail 82578 invoked by uid 3269); 3 Apr 2001 20:27:30 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 82575 invoked from network); 3 Apr 2001 20:27:30 -0000 Received: from sj-msg-core-2.cisco.com (171.69.43.88) by klesh.pair.com with SMTP; 3 Apr 2001 20:27:30 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA18184; Tue, 3 Apr 2001 13:27:15 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-439.cisco.com [10.21.65.183]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AAB54838; Tue, 3 Apr 2001 13:26:46 -0700 (PDT) Message-Id: <4.3.2.7.2.20010403132402.0401aef0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Lakshminath Dondeti" From: Mark Baugher Subject: Re: [MSEC] Session ID and Group ID Cc: msec@securemulticast.org In-Reply-To: <3ACA2304.11CC8D74@nortelnetworks.com> References: <4.3.1.2.20010329155417.014d8030@pop.ne.mediaone.net> <3AC347E2.58074E5D@cisco.com> <4.3.2.7.2.20010330053041.00bb7698@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010331034836.0354d3a8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010402102725.04086d28@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010403091534.03f89c20@mira-sjc5-6.cisco.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: Tue, 03 Apr 2001 13:25:51 -0700 Lakshminath, At 03:22 PM 4/3/2001 -0400, Lakshminath Dondeti wrote: >Anyway, as I understand, you are for having something similar to >Appendix B (LKH Data Key Download Definitions) in GDOI I-D, >separately for each of the proposed/future key management schemes. >Is that correct? Yes. I think that trying to get 1 spec right for N implementations will be easier than getting m specs right for N implementations. I think that there should be separate drafts for LKH, OFT, OFC and any other group management algorithms. Mark >best regards, >Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Apr 4 03:48:31 2001 Received: from pairlist.net ([216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA10851 for ; Wed, 4 Apr 2001 03:48:31 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 51FAD535BC; Wed, 4 Apr 2001 03:48:02 -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 B4E7B535B5 for ; Wed, 4 Apr 2001 03:47:34 -0400 (EDT) Received: (qmail 36488 invoked by uid 3269); 4 Apr 2001 07:47:34 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 36485 invoked from network); 4 Apr 2001 07:47:34 -0000 Received: from chmls20.mediaone.net (24.147.1.156) by klesh.pair.com with SMTP; 4 Apr 2001 07:47:34 -0000 Received: from tph.mediaone.net (h0010a4c49f9e.ne.mediaone.net [24.128.45.87]) by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id f347kaa03458; Wed, 4 Apr 2001 03:46:36 -0400 (EDT) Message-Id: <5.0.0.25.2.20010404035515.01ba2180@127.0.0.1> X-Sender: thardjono/pop.ne.mediaone.net@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: "Lakshminath Dondeti" , Mark Baugher From: Thomas Hardjono Subject: Glossary --- Re: [MSEC] Session ID and Group ID Cc: msec@securemulticast.org In-Reply-To: <3ACA2304.11CC8D74@nortelnetworks.com> References: <4.3.1.2.20010329155417.014d8030@pop.ne.mediaone.net> <3AC347E2.58074E5D@cisco.com> <4.3.2.7.2.20010330053041.00bb7698@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010331034836.0354d3a8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010402102725.04086d28@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010403091534.03f89c20@mira-sjc5-6.cisco.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, 04 Apr 2001 04:00:09 -0700 A glossary was in fact intended for the GKM building block document, but never made it to the final version (ie. there was a short one). Perhaps now is a good time to start it again, as it is becoming clear that some words are overloaded with meanings. btw. This also why we ended-up with the term "Category" for SAs :). cheers, thomas ------ At 4/3/01||03:22 PM, Lakshminath Dondeti wrote: >Mark, > >Thanks much for the clarification. You know we probably should >compile a glossary of terms used in the MSEC context. There >are others such as PFS in IKE/ISAKMP/IPSEC and PFS in group >security literature (forward access control in our terminology). > >Anyway, as I understand, you are for having something similar to >Appendix B (LKH Data Key Download Definitions) in GDOI I-D, >separately for each of the proposed/future key management schemes. >Is that correct? > > >best regards, >Lakshminath > >Mark Baugher wrote: > > > > Hi Lakshminath > > We have a problem with the word "Group" in our group:-) > > we use Group ID in GDOI (taken from GSAKMP) and this may > > be confused with DH groups in OAKLEY/IKE. We use > > group management and that can be confused with multicast > > group management - IGMP. All of these things are quite > > different. Our groups can encompass zero or more multicast > > groups. > > > > We talk about group management in the context of different > > group management algorithms that can use multicast to > > efficiently add or remove group members, which may or > > may not use multicast communications amongst themselves. > > We know of a few good algorithms. I expect more work > > in this area but personally don't see the value in coming up > > with a common specification for them. It would be better > > to develop the key management framework to accommodate > > them without forcing them to use common payloads. > > > > Mark > > At 03:28 PM 4/2/2001 -0400, Lakshminath Dondeti wrote: > > >Mark Baugher wrote: > > > > > > > > Lakshminath > > > > What is the benefit of having a common framework for group > > > > membership management? > > > > > > > > Mark > > > > > >Mark, > > > > > >Good question! :-) Although I am not sure my message below is > > >proposing a common framework for group membership management. > > >Let me address both key tree management and group membership > > >management, to the best of my knowledge :-) > > > > > >Case for common framework for key tree management: > > >-------------------------------------------------- > > >As I understand, for join rekeying we can use the "one-way > > >hash function" technique to cut down on rekeying (communication) > > >overhead in LKH, OFT(?), and others? I know of some distributed > > >key determination schemes that could use this technique. > > > > > >My guess is that there are other common aspects (similar > > >payload formats should help in implementation -- Ran and > > >Thomas' opinion/idea) of rekeying mechanisms. My thinking > > >is that the common framework document would glean that > > >information. Out of that, we could figure out what > > >needs to be added to the GDOI (or similar) protocol, or > > >whatever (I am not sure yet). > > > > > >Group membership management: > > >---------------------------- > > >The layer-3 thing for this is IGMP. > > > > > >In our case (may be this was resolved earlier, I am sorry I was not > > >there), this means a way for the GCKS to get leave "notifications" > > >from members. For completeness, SA1 of GDOI is an implicit join > > >"notification" (request really). I am sure there will be other > > >kinds of notifications that will come up (distributed GCKS comes > > >to mind). > > > > > >Oh well, that is my stab at that question :-) > > > > > >best regards, > > >Lakshminath > > > > > > > > > > At 11:48 AM 4/2/2001 -0400, Lakshminath Dondeti wrote: > > > > >Mark, > > > > > > > > > >Thanks much for your comments. We probably do need a separate > > > > >document for the logical key tree mechanisms. The stuff I was > > > > >proposing is an addition to the GDOI protocol. They were, in > > > > >more abstract terms, > > > > > > > > > > 1) notification messages: unicast/multicast (to support LKH+ > > > > >and similar mechanisms) > > > > > 2) version/revision numbers in data messages (again I made the > > > > >case in context of LKH+, but this would apply to OFT+ and any > > > > >others, may be future ones.) > > > > > > > > > >You are right, we'll know more once a common framework document > > > > >for tree-based rekeying schemes, as Ran proposed, materializes. > > > > > > > > > >Best regards, > > > > >Lakshminath > > > > > > > > > >Mark Baugher wrote: > > > > > > > > > > > > hi Lakshminath > > > > > > I think that we need to have a separate draft document > > > > > > that describes how an LKH security protocol should > > > > > > operate. What we have in the GDOI draft is our first > > > > > > take on what the Security-Association traffic encryption key > > > > > > (SA TEK) payload needs to be to support an LKH security > > > > > > protocol. I would not be surprised if we need to change > > > > > > this by the time we finish an LKH security protocol > > > > > > document. It hope that the security association key > > > > > > encrypting key (SA KEK) won't need any changes - > > > > > > if we find that we need to change SA KEK for new > > > > > > security protocols, then there's something wrong. The > > > > > > SA KEK needs to be general wrt security protocols. > > > > > > > > > > > > best regards, Mark > > > > > > At 01:52 PM 3/30/2001 -0500, Lakshminath Dondeti wrote: > > > > > > >Mark, > > > > > > > > > > > > > >Thanks for the explanation. It makes sense. I am looking for > > > > > > >opinions on incorporating version and revision numbers with > > > > > > >keys. Particularly in case of LKH+ and similar key determination > > > > > > >algorithms it makes life easy. For example, in LKH+, when a join > > > > > > >occurs, the GCKS need not even notify current membership. When > > > > > > >data comes with a new "revision number", the members "update" the > > > > > > >corresponding SA appropriately. > > > > > > > > > > > > > >I am bringing this up so we can discuss and decide whether it is > > > > > > >worthwhile to add this to GDOI I-D key payloads. > > > > > > > > > > > > > >best regards, > > > > > > >Lakshminath > > > > > > > > > > > > > >PS: I want to reiterate the disclaimer that this was an idea > proposed > > > > > > >in the literature (not by me, see below). > > > > > > > > > > > > > > > > > > > > >Mark Baugher wrote: > > > > > > > > > > > > > > > > Lakshminath, > > > > > > > > > > > > > > > > At 06:20 PM 3/29/2001 -0500, Lakshminath Dondeti wrote: > > > > > > > > >Brian, > > > > > > > > > > > > > > > > > >I am not getting into this SID discussion at this time. > > > > > > > > > > > > > > > > > >But, I am concerned about having a single "active" TEK. I > believe > > > > > > > > >in reality a member needs to maintain a list of > TEKs. Consider > > > > > > > > >data going over a reliable multicast channel. It is plausible > > > > > > > > >that a member receives two (e.g.) versions of TEKs before she > > > > > > > > >receives any encrypted data. When the data eventually > arrives, > > > > > > > > >the first few packets could be encrypted with TEK 1.0 and > the rest > > > > > > > > >with TEK 2.0, or vice versa. > > > > > > > > > > > > > > > > We use an SPI for this purpose. > > > > > > > > > > > > > > > > Mark > > > > > > > > > > > > > > > > >I propose that both key and data packets should have > "version" and > > > > > > > > >"revision" tags. The terminology and idea comes from the > VersaKey > > > > > > > > >paper in JSAC 1999/2000 by M. Waldvogel, G. Caronni, B. > > > Plattner and > > > > > > > > >others. As I recall each time a new key is generated, the > version > > > > > > > > >number is increased, and when a one-way function is used > on the > > > > > current > > > > > > > > >TEK/KEK for rekeying (ala LKH+), the revision number is > increased. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >best regards, > > > > > > > > >Lakshminath > > > > > > > > > > > > > > > > > >Brian Weis wrote: > > > > > > > > > > > > > > > > > > > > Hi Thomas, > > > > > > > > > > > > > > > > > > > > Thomas Hardjono wrote: > > > > > > > > > > > > > > > > > > > > > > Recently we had a discussion with some folks who > wanted to > > > > > > > > > > > do group key management in wireless, and a number of > > > > > questions arose > > > > > > > > > > > regarding the GSA Model and Definition, and in particular > > > > > > > > > > > about the notion of Group IDs (GID). > > > > > > > > > > > > > > > > > > > > > > So we all know that we need some way to identify a group > > > > > > > > > > > other than using the (S, G) pair. GSAKMP uses the notion > > > > > > > > > > > of a Group ID (GID) which can identify a group a high > level > > > > > > > > > > > and which is included in all the GSAKMP messages/headers. > > > > > > > > > > > In GSAKMP the GID is a 32-bit number (though I think > we may > > > > > > > > > > > need a bigger number). > > > > > > > > > > > > > > > > > > > > > > This notion of a GID is also being carried-over into > the GDOI > > > > > work > > > > > > > > > > > (at least implicitly). > > > > > > > > > > > > > > > > > > > > > > So here is the scenario: there is one control channel > > > (Cat-2) > > > > > > > > > > > and there is multiple data channel (Cat-3), say one for > > > audio and > > > > > > > > > > > one for video. > > > > > > > > > > > > > > > > > > > > > > The question is, if I was a Receiver and was in the > > > process of > > > > > > > > > > > receiving a key-update (rekey pack) through the > > > push/control SA, > > > > > > > > > > > how do I identify which key-packs are to be applied > to the > > > > > > > > > > > 2 data channels? In GDOI the update will consist of 2 > > > KEK SAs, > > > > > > > > > > > but the question still arises: how do I know how to > match the > > > > > KEKs > > > > > > > > > > > to the multiple Cat-3 SAs. > > > > > > > > > > > > > > > > > > > > I followed you up until the last paragraph. In the > scenario you > > > > > > > mention, > > > > > > > > > > there could be one KEK SA (not two as you say in this > > > > > paragraph), and > > > > > > > > > > two TEK SAs. Maybe you meant that the "update will consist > > > of 2 TEK > > > > > > > > > > SAs"? > > > > > > > > > > > > > > > > > > > > In GDOI, the push message includes an SA payload > containing the > > > > > policy > > > > > > > > > > for the two data channels, and the KD payload contains > the new > > > > > keys for > > > > > > > > > > the two channels. The SA payload identifies the (S,G) of > > > the data > > > > > > > > > > channel along with a new SPI (assuming IPSec > > > encapsulation). The KD > > > > > > > > > > payload includes the new SPI and the new key. It will be > > > > > obvious which > > > > > > > > > > key is associated with which data channel. > > > > > > > > > > > > > > > > > > > > Or, if you really considering confusion between the two > KEKs, > > > > > the only > > > > > > > > > > confusion between would be between the current KEK and > a new > > > > > one sent > > > > > > > > > > down in the push message. > > > > > > > > > > However, the new one replaces the current KEK after the > push > > > > > message > > > > > > > > > > processing has completed -- only one should be active at a > > > time per > > > > > > > > > > group. > > > > > > > > > > > > > > > > > > > > > One answer is using a Session-ID (SID) in conjunction > with > > > > > the GID. > > > > > > > > > > > Thus, each KEK and TEK would need to identify the GID > & SID > > > > > > > > > > > to which the KEK/TEK applies. > > > > > > > > > > > > > > > > > > > > The GDOI, there is already a unique value associated > with each > > > > > KEK. The > > > > > > > > > > cookie-pair in the IKE header is used as the "SPI" for the > > > KEK. If > > > > > > > a new > > > > > > > > > > KEK is sent in a push message, the SA payload sends a new > > > > > cookie-pair > > > > > > > > > > for the new KEK. > > > > > > > > > > > > > > > > > > > > I don't see where a SID is needed for either a TEK or KEK. > > > > > > > > > > > > > > > > > > > > Brian Weis > > > > > > > > > > bew@cisco.com > > > > > > > > > > > > > > > > > > > > > Would it be possible, say, to have a 32-bit GID and a > > > 32-bit SID, > > > > > > > > > > > (assuming that 32-bits of GID is enough)? If a 32-bit > > > GID is too > > > > > > > much, > > > > > > > > > > > perhaps we can re-use some of the bits (least significant > > > 8 bit) > > > > > > > > > > > for the SID? > > > > > > > > > > > > > > > > > > > > > > Does this whole SID thing make any sense? > > > > > > > > > > > > > > > > > > > > > > thomas > > > > > > > > > > > ------ > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > > > > >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 > >_______________________________________________ >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 From msec-admin@securemulticast.org Wed Apr 4 03:50:29 2001 Received: from pairlist.net ([216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA10887 for ; Wed, 4 Apr 2001 03:50:29 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 3BCE5535BC; Wed, 4 Apr 2001 03:50:01 -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 DEBE8535D9 for ; Wed, 4 Apr 2001 03:48:33 -0400 (EDT) Received: (qmail 36530 invoked by uid 3269); 4 Apr 2001 07:48:33 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 36527 invoked from network); 4 Apr 2001 07:48:33 -0000 Received: from chmls20.mediaone.net (24.147.1.156) by klesh.pair.com with SMTP; 4 Apr 2001 07:48:33 -0000 Received: from tph.mediaone.net (h0010a4c49f9e.ne.mediaone.net [24.128.45.87]) by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id f347mWa03937 for ; Wed, 4 Apr 2001 03:48:32 -0400 (EDT) Message-Id: <5.0.0.25.2.20010404040020.0278ae70@127.0.0.1> X-Sender: thardjono/pop.ne.mediaone.net@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: msec@securemulticast.org From: Thomas Hardjono Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Slides from IETF50 Minn. up on the website 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, 04 Apr 2001 04:02:05 -0700 Folks, The slides from the MSEC WG meeting is up. http://www.securemulticast.org/msec-meetings.htm The minutes should be up this week. thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Apr 15 19:03:26 2001 Received: from pairlist.net ([216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12432 for ; Sun, 15 Apr 2001 19:03:25 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2C91153652; Sun, 15 Apr 2001 19:02:06 -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 7A2D253652 for ; Sun, 15 Apr 2001 19:00:38 -0400 (EDT) Received: (qmail 36839 invoked by uid 3269); 15 Apr 2001 23:00:38 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 36836 invoked from network); 15 Apr 2001 23:00:37 -0000 Received: from chmls05.mediaone.net (24.147.1.143) by klesh.pair.com with SMTP; 15 Apr 2001 23:00:37 -0000 Received: from hardjono.mediaone.net (h0010a4c49f9e.ne.mediaone.net [24.128.45.87]) by chmls05.mediaone.net (8.11.1/8.11.1) with ESMTP id f3FN0Zx20472 for ; Sun, 15 Apr 2001 19:00:36 -0400 (EDT) Message-Id: <5.0.0.25.2.20010415191151.01b7b700@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 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] MSEC WG gets a whole page in April Information Security Magazine 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: Sun, 15 Apr 2001 19:14:17 -0700 Folks, The April issue of Information Security magazine has a page on the MSEC WG. http://www.infosecuritymag.com/articles/april01/columns_standards_watch.shtml Thank you to Pete Loshin for the review. cheers, thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec