From msec-admin@securemulticast.org Thu Mar 29 16:07:55 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10923 for ; Thu, 29 Mar 2001 16:07:53 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 465E5535CE; Thu, 29 Mar 2001 16:07:03 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 4E779535A5 for ; Thu, 29 Mar 2001 16:05:59 -0500 (EST) Received: (qmail 44755 invoked by uid 3269); 29 Mar 2001 21:05:58 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 44752 invoked from network); 29 Mar 2001 21:05:58 -0000 Received: from chmls20.mediaone.net (24.147.1.156) by klesh.pair.com with SMTP; 29 Mar 2001 21:05:58 -0000 Received: from hardjono.mediaone.net (h8994.sc020.BayNetworks.COM [192.32.137.148] (may be forged)) by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id f2TL5pa16316 for ; Thu, 29 Mar 2001 16:05:51 -0500 (EST) Message-Id: <4.3.1.2.20010329155417.014d8030@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 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [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: Thu, 29 Mar 2001 16:14:33 -0500 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. 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. 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 From msec-admin@securemulticast.org Thu Mar 29 17:30:36 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14736 for ; Thu, 29 Mar 2001 17:30:35 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id E0FD453568; Thu, 29 Mar 2001 17:30:05 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id E8B2C5355C for ; Thu, 29 Mar 2001 17:28:57 -0500 (EST) Received: (qmail 52754 invoked by uid 3269); 29 Mar 2001 22:28:57 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 52751 invoked from network); 29 Mar 2001 22:28:57 -0000 Received: from sj-msg-core-2.cisco.com (171.69.43.88) by klesh.pair.com with SMTP; 29 Mar 2001 22:28:57 -0000 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA17279; Thu, 29 Mar 2001 14:28:28 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2TMS5119113; Thu, 29 Mar 2001 14:28:05 -0800 (PST) Received: from cisco.com (IDENT:bew@dhcp-128-107-143-60.cisco.com [128.107.143.60]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id OAA18527; Thu, 29 Mar 2001 14:28:03 -0800 (PST) Message-ID: <3AC347E2.58074E5D@cisco.com> From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Hardjono Cc: msec@securemulticast.org Subject: Re: [MSEC] Session ID and Group ID References: <4.3.1.2.20010329155417.014d8030@pop.ne.mediaone.net> 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: Thu, 29 Mar 2001 06:34:10 -0800 Content-Transfer-Encoding: 7bit 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 From msec-admin@securemulticast.org Thu Mar 29 18:24:35 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17507 for ; Thu, 29 Mar 2001 18:24:35 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id DEE17535A8; Thu, 29 Mar 2001 18:24:05 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id F10D053552 for ; Thu, 29 Mar 2001 18:23:44 -0500 (EST) Received: (qmail 55583 invoked by uid 3269); 29 Mar 2001 23:23:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 55580 invoked from network); 29 Mar 2001 23:23:44 -0000 Received: from smtprch1.nortelnetworks.com (HELO smtprch1.nortel.com) (192.135.215.14) by klesh.pair.com with SMTP; 29 Mar 2001 23:23:44 -0000 Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com; Thu, 29 Mar 2001 17:09:10 -0600 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 H74LDX8P; Thu, 29 Mar 2001 15:08:55 -0800 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 HJCWZ8N2; Thu, 29 Mar 2001 18:08:54 -0500 Message-ID: <3AC3C34E.B806D4DB@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: Brian Weis 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> 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: Thu, 29 Mar 2001 18:20:46 -0500 Content-Transfer-Encoding: 7bit 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.  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 From msec-admin@securemulticast.org Fri Mar 30 03:02:38 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA17408 for ; Fri, 30 Mar 2001 03:02:37 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A7D6B53650; Fri, 30 Mar 2001 03:02:04 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 080B15363D for ; Fri, 30 Mar 2001 03:01:22 -0500 (EST) Received: (qmail 89818 invoked by uid 3269); 30 Mar 2001 08:01:21 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 89815 invoked from network); 30 Mar 2001 08:01:21 -0000 Received: from sequoia.mms.fr (140.94.82.14) by klesh.pair.com with SMTP; 30 Mar 2001 08:01:21 -0000 Received: from tlmaco01.tls.mms.fr (TLMACO01.tls.mms.fr [140.94.2.107]) by sequoia.mms.fr (8.9.3/jtpda-5.3.1) with ESMTP id KAA28456 for ; Fri, 30 Mar 2001 10:01:12 +0200 (MET DST) Received: by TLMACO01.tls.mms.fr with Internet Mail Service (5.5.2650.21) id ; Fri, 30 Mar 2001 10:00:41 +0200 Message-ID: From: "ZXMULINSA004, Ext" To: "'msec@securemulticast.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [MSEC] (no subject) 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: Fri, 30 Mar 2001 10:00:40 +0200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id DAA17408 subscribe いいいいいいいいいいいいいいいいいいい Yann FINCK Ingnieur INSA Gnie Informatique & Industriel ASTRIUM - Satellite Network Engineering Tel : +33 (0) 5 62 88 06 01 Fax : +33 (0) 5 62 88 06 01 いいいいいいいいいいいいいいいいいいい 羆&j)b b荷yy褒zkザ'貨莅m 0〓X嫌涎Yb茄~ From msec-admin@securemulticast.org Fri Mar 30 08:30:50 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14300 for ; Fri, 30 Mar 2001 08:30:50 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B50515363C; Fri, 30 Mar 2001 08:30:06 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 3FE5A53604 for ; Fri, 30 Mar 2001 08:29:43 -0500 (EST) Received: (qmail 11879 invoked by uid 3269); 30 Mar 2001 13:29:43 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 11876 invoked from network); 30 Mar 2001 13:29:42 -0000 Received: from sj-msg-core-2.cisco.com (171.69.43.88) by klesh.pair.com with SMTP; 30 Mar 2001 13:29:42 -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 FAA25345; Fri, 30 Mar 2001 05:29:33 -0800 (PST) Received: from mbaugher-w2k1.cisco.com (rtp-dial-1-197.cisco.com [10.83.97.197]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AAB03636; Fri, 30 Mar 2001 05:29:09 -0800 (PST) Message-Id: <4.3.2.7.2.20010330051559.03552230@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: [MSEC] Session ID and Group ID Cc: msec@securemulticast.org In-Reply-To: <4.3.1.2.20010329155417.014d8030@pop.ne.mediaone.net> 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: Fri, 30 Mar 2001 05:28:12 -0800 Thomas, At 04:14 PM 3/29/2001 -0500, 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 don't think there's any problem to solve here. There is only one SA KEK in your description because there is only one category-2 SA. The GCKS keys category-3 SAs with SA TEK payloads. There is a security protocol that requests, receives, and manages the category-3 SA data. Each security protocol may have its own way of uniquely identifying a category-3 SA (as well as how to form SPIs and other security-protocol specific parameters). It could be a number, like a session number, if that's what the particular security protocol uses. If the security protocol is ESP, the security protocol could use a pair - or any other identification data specified by RFC 2407 and supported by IKE. Mark >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. > >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 From msec-admin@securemulticast.org Fri Mar 30 08:34:36 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14525 for ; Fri, 30 Mar 2001 08:34:36 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9CF5553619; Fri, 30 Mar 2001 08:34:04 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 699E05360E for ; Fri, 30 Mar 2001 08:33:00 -0500 (EST) Received: (qmail 12104 invoked by uid 3269); 30 Mar 2001 13:33:00 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 12101 invoked from network); 30 Mar 2001 13:32:59 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by klesh.pair.com with SMTP; 30 Mar 2001 13:32:59 -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 FAA23436; Fri, 30 Mar 2001 05:32:32 -0800 (PST) Received: from mbaugher-w2k1.cisco.com (rtp-dial-1-197.cisco.com [10.83.97.197]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AAB03656; Fri, 30 Mar 2001 05:32:24 -0800 (PST) Message-Id: <4.3.2.7.2.20010330053041.00bb7698@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: <3AC3C34E.B806D4DB@nortelnetworks.com> References: <4.3.1.2.20010329155417.014d8030@pop.ne.mediaone.net> <3AC347E2.58074E5D@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: Fri, 30 Mar 2001 05:31:28 -0800 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 From msec-admin@securemulticast.org Fri Mar 30 10:28:47 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20718 for ; Fri, 30 Mar 2001 10:28:47 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0EA71536B5; Fri, 30 Mar 2001 10:28:10 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 4D0C9535D8 for ; Fri, 30 Mar 2001 10:24:55 -0500 (EST) Received: (qmail 24162 invoked by uid 3269); 30 Mar 2001 15:24:54 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 24159 invoked from network); 30 Mar 2001 15:24:54 -0000 Received: from chmls06.mediaone.net (24.147.1.144) by klesh.pair.com with SMTP; 30 Mar 2001 15:24:54 -0000 Received: from hardjono.mediaone.net (h0010a4057f65.ne.mediaone.net [24.128.45.6]) by chmls06.mediaone.net (8.11.1/8.11.1) with ESMTP id f2UFOpU12835; Fri, 30 Mar 2001 10:24:51 -0500 (EST) Message-Id: <4.3.1.2.20010330102030.02390450@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 To: Brian Weis From: Thomas Hardjono Cc: msec@securemulticast.org In-Reply-To: <3AC347E2.58074E5D@cisco.com> References: <4.3.1.2.20010329155417.014d8030@pop.ne.mediaone.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Re: 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: Fri, 30 Mar 2001 10:33:51 -0500 Hi, Thanks Brian for the correction. (2 TEK SAs). Rethinking this question again, perhaps I'm asking the question at the wrong layer. We know we need some way to announce a "Group" (in a broad sense) which in the scenario uses 1 control channel (IP multicast address) and 2 data channels (2 separate IP multicast addresses). We need some way to identify this "Group", which is where the GID comes into play. Thus, perhaps the GID is an Application layer identification method. If an application uses GDOI, then it must link the GID with the appropriate SPIs of each channel at layer 3. In other words, perhaps the question of GID is irrelevant in GDOI at layer 3 since the GID is an application layer identification method. On the other hand, in GSAKMP the GID makes sense since it must be used to identify Groups in the Request to join (flow-1) and the Invitation message (flow-2) of the GSAKMP exchanges. Does all this make sense? btw. I still think that a GID-thing will be needed when we start looking at group announcement methods. The candidate-member then learns about the key management protocol and the channels, etc. through the Policy Token (which carries also the GID number). cheers, thomas ------ At 3/29/01||06:34 AM, 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 From msec-admin@securemulticast.org Fri Mar 30 10:44:33 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21648 for ; Fri, 30 Mar 2001 10:44:32 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2D67C535EE; Fri, 30 Mar 2001 10:44:02 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 60BD353583 for ; Fri, 30 Mar 2001 10:41:37 -0500 (EST) Received: (qmail 25517 invoked by uid 3269); 30 Mar 2001 15:41:37 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 25514 invoked from network); 30 Mar 2001 15:41:36 -0000 Received: from softdnserror (HELO sparta.com) (root@157.185.61.1) by klesh.pair.com with SMTP; 30 Mar 2001 15:41:36 -0000 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by sparta.com (8.11.0/8.11.0) with ESMTP id f2UFfZY19611; Fri, 30 Mar 2001 09:41:35 -0600 Received: from robin (robin.columbia.sparta.com [157.185.80.228]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id KAA16020; Fri, 30 Mar 2001 10:41:32 -0500 (EST) Message-Id: <4.2.2.20010330102517.00adbe80@pop.columbia.sparta.com> X-Sender: hh@pop.columbia.sparta.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 To: Thomas Hardjono , Brian Weis From: Hugh Harney Subject: Re: [MSEC] Re: Session ID and Group ID Cc: msec@securemulticast.org In-Reply-To: <4.3.1.2.20010330102030.02390450@pop.ne.mediaone.net> References: <3AC347E2.58074E5D@cisco.com> <4.3.1.2.20010329155417.014d8030@pop.ne.mediaone.net> 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: Fri, 30 Mar 2001 10:35:49 -0500 Thomas, Let me speak for the GSAKMP case. The GID identifies the abstract group. Many keys maybe associated with an abstract group. This abstraction is very important, because all keys being used in a group effect the groups overall security. For example, if a group is supporting a collaborative environment, then the key and algorithms used to protect the audio stream must be as strong as those used to protect the video frames. So in GSAKMP a GID is used to define the abstract group (and keys used to management that group). Then the key download payload for that group specifies many types of keys. Each of these types can carry management information to ensure proper allocation of that individual key. For example, rekey is a key download type. The specification for the rekey data, includes information about the rekey type (LKH, OFT...), and information about where a specific LKH key is located in the key tree. In your wireless example, a key download payload type may be called wireless. Then under that key type the wireless designers can specify a management structure that can differentiate between multiple types of data channels and multiple TEKs per channel. In this manner the key download payloads can be used for broad categories of keys. The individual key types can be specified as much as desired. Hugh At 10:33 AM 3/30/01 -0500, Thomas Hardjono wrote: >Hi, > >Thanks Brian for the correction. (2 TEK SAs). > >Rethinking this question again, perhaps I'm asking the question at >the wrong layer. > >We know we need some way to announce a "Group" (in a broad sense) which >in the scenario uses 1 control channel (IP multicast address) and >2 data channels (2 separate IP multicast addresses). > >We need some way to identify this "Group", which is where the GID >comes into play. Thus, perhaps the GID is an Application layer >identification method. If an application uses GDOI, then it must >link the GID with the appropriate SPIs of each channel at layer 3. > >In other words, perhaps the question of GID is irrelevant in GDOI >at layer 3 since the GID is an application layer identification method. >On the other hand, in GSAKMP the GID makes sense since it must be used >to identify Groups in the Request to join (flow-1) and the Invitation >message (flow-2) of the GSAKMP exchanges. > >Does all this make sense? > >btw. I still think that a GID-thing will be needed when we start looking at >group announcement methods. The candidate-member then learns about >the key management protocol and the channels, etc. through the Policy Token >(which carries also the GID number). > >cheers, > >thomas >------ > > >At 3/29/01||06:34 AM, 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 ________________________________________________________ Hugh Harney hh@sparta.com 410-381-9400 x203 ________________________________________________________ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Mar 30 14:20:01 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06950 for ; Fri, 30 Mar 2001 14:20:01 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2247053622; Fri, 30 Mar 2001 14:19:29 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 61A6E5364A for ; Fri, 30 Mar 2001 14:17:31 -0500 (EST) Received: (qmail 42515 invoked by uid 3269); 30 Mar 2001 19:17:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 42512 invoked from network); 30 Mar 2001 19:17:30 -0000 Received: from softdnserror (HELO sparta.com) (root@157.185.61.1) by klesh.pair.com with SMTP; 30 Mar 2001 19:17:30 -0000 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by sparta.com (8.11.0/8.11.0) with ESMTP id f2UJHRY27380 for ; Fri, 30 Mar 2001 13:17:28 -0600 Received: from robin (robin.columbia.sparta.com [157.185.80.228]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id OAA18459 for ; Fri, 30 Mar 2001 14:17:23 -0500 (EST) Message-Id: <4.2.2.20010330113900.00ad6b50@pop.columbia.sparta.com> X-Sender: hh@pop.columbia.sparta.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 To: msec@securemulticast.org From: Hugh Harney Subject: Re: [MSEC] Re: Session ID and Group ID Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; 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: Fri, 30 Mar 2001 14:13:40 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA06950 Thomas, In the previous e-mail I tried to discuss how one could specify a key download payload without a policy token. In the absence of a policy token you must make the key download data rich enough to clearly state where the key is to be used. I've omitted my pitch for a fully specified policy token :) Now let's talk about GSAKMP. Let me try to pull an example of how GSAKMP would supply key to one RAT channel and several IPSec channels in a single group. First, GSAKMP has a policy token that specifies all the mechanisms used in the group. So for a single GID the policy token can specify the following mechanism. BEGIN POLICY TOKEN: Cat 1 mechanisms to define the unicast SA. Let's skip this as it is not important in this example. Cat 2 mechanisms to define group maintenance SA. Let's skip this as it is not important in this example. Cat 3 mechanism to define data channel mechanisms. (We may have the following data channel mechanims for a GID. This is an ordered list. I've tagged them to illustrate.) #1 RAT encryption key: 128 bits long. Rat session #123 Security ProtocolRat interanl key length128 #2 IPSec encryption key SPI4847474747474747 Security ProtocolESP Processing DirectionOutgoing ESP AlgorithmESP-DES ESP AuthenticationHMAC-SHA Encapsulation ModeTunnel SA Lifetypekilobytes SA Lifetime1000 Source Addr* Destination Addr224.0.1 (Multicast) Transport ProtocolUDP GroupID224.0.1, 12345678 Security LabelReference [7] Key Creationpreplaced (via GSAKMP) #3 IPSec encryption key SPI5888888888888 Security ProtocolESP Processing DirectionOutgoing ESP AlgorithmESP-DES ESP AuthenticationHMAC-SHA Encapsulation ModeTunnel SA Lifetypekilobytes SA Lifetime1000 Source Addr* Destination Addr224.0.1 (Multicast) Transport ProtocolUDP GroupID224.0.1, 12345678 Security LabelReference [7] Key Creationpreplaced (via GSAKMP) This can go on and on. END POLICY TOKEN Well in the key download payload we have a type of GTEK. So all we need to do is link the keys downloaded under the type GTEK to the mechanisms definition above. So the first GTEK would go to the RAT application, the second to: #2 IPSec encryption key (SPI = 4847474747474747) and the third to: #3 IPSec encryption key (SPI = 5888888888888). ________________________________________________________ Hugh Harney hh@sparta.com 410-381-9400 x203 ________________________________________________________ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Mar 30 14:44:37 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08940 for ; Fri, 30 Mar 2001 14:44:37 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id F1F6853671; Fri, 30 Mar 2001 14:44:05 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 8FBD453587 for ; Fri, 30 Mar 2001 14:43:39 -0500 (EST) Received: (qmail 44455 invoked by uid 3269); 30 Mar 2001 19:43:39 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 44452 invoked from network); 30 Mar 2001 19:43:38 -0000 Received: from sj-msg-core-2.cisco.com (171.69.43.88) by klesh.pair.com with SMTP; 30 Mar 2001 19:43:38 -0000 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.43.85]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA03877; Fri, 30 Mar 2001 11:42:26 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f2UJg4g27304; Fri, 30 Mar 2001 11:42:04 -0800 (PST) Received: from cisco.com (IDENT:bew@dhcp-128-107-143-60.cisco.com [128.107.143.60]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA09110; Fri, 30 Mar 2001 11:42:03 -0800 (PST) Message-ID: <3AC4E18A.342BEDB9@cisco.com> From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 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> 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: Fri, 30 Mar 2001 11:42:02 -0800 Content-Transfer-Encoding: 7bit Hi Lakshminath, 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. I didn't mean to imply that there was a single "active" TEK. Certainly there's a window at the key change time where both an old TEK and a new TEK are valid. A few more data packets could be encrypted the old key before the new one is used. As Mark replied, if you're using ESP the SPI provides a clear definition of which key to use during that period. (Remember that if there is a key change, there must also be a SPI change.) In the KEK case, once a receiver gets a push message with a new KEK the old KEK is immediately made obsolete -- the GCKS is declaring that it won't use the old KEK anymore. > 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. The GDOI push message contains a sequence number (in the SEQ payload). This plays the role of a "version" tag, since it provides a clear ordering of messages. Any push message containing a KEK supercedes all push messages with smaller sequence numbers. I'm not sure about the need of a "revision" flag. If the push message contains an LKH+ tree update, it seems to me that the sequence number serves the same role in providing a clear ordering of which set of keys is most current. Brian Weis bew@cisco.com > 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 From msec-admin@securemulticast.org Fri Mar 30 14:47:15 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09173 for ; Fri, 30 Mar 2001 14:47:14 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 7CDCB53606; Fri, 30 Mar 2001 14:46:43 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 2A1A553587 for ; Fri, 30 Mar 2001 14:44:26 -0500 (EST) Received: (qmail 44523 invoked by uid 3269); 30 Mar 2001 19:44:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 44520 invoked from network); 30 Mar 2001 19:44:25 -0000 Received: from smtprch1.nortelnetworks.com (HELO smtprch1.nortel.com) (192.135.215.14) by klesh.pair.com with SMTP; 30 Mar 2001 19:44:25 -0000 Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com; Fri, 30 Mar 2001 12:40:58 -0600 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 H74L125W; Fri, 30 Mar 2001 10:40:44 -0800 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 HJCWZ9AQ; Fri, 30 Mar 2001 13:40:42 -0500 Message-ID: <3AC4D5EF.6D3788AB@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> 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: Fri, 30 Mar 2001 13:52:31 -0500 Content-Transfer-Encoding: 7bit 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 From msec-admin@securemulticast.org Fri Mar 30 16:17:06 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15039 for ; Fri, 30 Mar 2001 16:17:05 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B1BB953562; Fri, 30 Mar 2001 16:16:33 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id B7B925354D for ; Fri, 30 Mar 2001 16:15:20 -0500 (EST) Received: (qmail 54964 invoked by uid 3269); 30 Mar 2001 21:15:20 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 54961 invoked from network); 30 Mar 2001 21:15:19 -0000 Received: from smtprch1.nortelnetworks.com (HELO smtprch1.nortel.com) (192.135.215.14) by klesh.pair.com with SMTP; 30 Mar 2001 21:15:19 -0000 Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com; Fri, 30 Mar 2001 14:32:39 -0600 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 H0BPG5L3; Fri, 30 Mar 2001 12:32:25 -0800 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 HJCWZ9DB; Fri, 30 Mar 2001 15:32:23 -0500 Message-ID: <3AC4F018.44378DD4@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: Brian Weis 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> 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: Fri, 30 Mar 2001 15:44:08 -0500 Content-Transfer-Encoding: 7bit Brian, Thanks much for the explanation. Thomas explained earlier (private communication) that the SEQ along with the SPI obviates the need for a version field (although I still believe an explicit version number makes life easy :-); also, see below). 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. Version and revision numbering will make the key payloads a bit bigger than they are, but i) makes it easy to maintain and index keys ii) allows us not to send join rekeying notifications in LKH+ etc. Any other pros and cons? My interest in this is that it is a good technique, that is all! Thanks much for considering this. best regards, Lakshminath Brian Weis wrote: > > Hi Lakshminath, > > 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. > > I didn't mean to imply that there was a single "active" TEK. Certainly > there's a window at the key change time where both an old TEK and a new > TEK are valid. A few more data packets could be encrypted the old key > before the new one is used. As Mark replied, if you're using ESP the SPI > provides a clear definition of which key to use during that period. > (Remember that if there is a key change, there must also be a SPI > change.) > > In the KEK case, once a receiver gets a push message with a new KEK the > old KEK is immediately made obsolete -- the GCKS is declaring that it > won't use the old KEK anymore. > > > 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. > > The GDOI push message contains a sequence number (in the SEQ payload). > This plays the role of a "version" tag, since it provides a clear > ordering of messages. Any push message containing a KEK supercedes all > push messages with smaller sequence numbers. > > I'm not sure about the need of a "revision" flag. If the push message > contains an LKH+ tree update, it seems to me that the sequence number > serves the same role in providing a clear ordering of which set of keys > is most current. > > Brian Weis > bew@cisco.com > > > 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 From msec-admin@securemulticast.org Sat Mar 31 07:18:33 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28837 for ; Sat, 31 Mar 2001 07:18:33 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4FC7B535E7; Sat, 31 Mar 2001 07:18:03 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 8385A535D6 for ; Sat, 31 Mar 2001 07:16:27 -0500 (EST) Received: (qmail 14157 invoked by uid 3269); 31 Mar 2001 12:16:27 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 14154 invoked from network); 31 Mar 2001 12:16:26 -0000 Received: from sj-msg-core-2.cisco.com (171.69.43.88) by klesh.pair.com with SMTP; 31 Mar 2001 12:16:26 -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 EAA26582; Sat, 31 Mar 2001 04:16:17 -0800 (PST) Received: from mbaugher-w2k1.cisco.com (rtp-dial-1-40.cisco.com [10.83.97.40]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AAB19911; Sat, 31 Mar 2001 04:15:39 -0800 (PST) Message-Id: <4.3.2.7.2.20010331034836.0354d3a8@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: <3AC4D5EF.6D3788AB@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> 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: Sat, 31 Mar 2001 03:53:58 -0800 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 From msec-admin@securemulticast.org Sat Mar 31 10:11:08 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13259 for ; Sat, 31 Mar 2001 10:11:08 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 76C7553652; Sat, 31 Mar 2001 10:10:39 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id BEA99535B5 for ; Sat, 31 Mar 2001 10:09:56 -0500 (EST) Received: (qmail 23522 invoked by uid 3269); 31 Mar 2001 15:09:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 23519 invoked from network); 31 Mar 2001 15:09:56 -0000 Received: from chmls20.mediaone.net (24.147.1.156) by klesh.pair.com with SMTP; 31 Mar 2001 15:09:56 -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 f2VF9sa12159 for ; Sat, 31 Mar 2001 10:09:54 -0500 (EST) Message-Id: <4.3.1.2.20010331101055.01ef6de0@ZBL6C002.corpeast.baynetworks.com> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 To: msec@securemulticast.org From: Thomas Hardjono Subject: Group Key Determination Algorithms --- Re: [MSEC] Session ID and Group ID In-Reply-To: <4.3.2.7.2.20010331034836.0354d3a8@mira-sjc5-6.cisco.com> References: <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: Sat, 31 Mar 2001 10:18:52 -0500 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). 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 From msec-admin@securemulticast.org Sat Mar 31 13:22:34 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14423 for ; Sat, 31 Mar 2001 13:22:33 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8E3C653618; Sat, 31 Mar 2001 13:22:03 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 66D2753602 for ; Sat, 31 Mar 2001 13:21:06 -0500 (EST) Received: (qmail 36292 invoked by uid 3269); 31 Mar 2001 18:21:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 36289 invoked from network); 31 Mar 2001 18:21:05 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 31 Mar 2001 18:21:05 -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 f2VIKY229064; Sat, 31 Mar 2001 13:20:34 -0500 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 NAA27038; Sat, 31 Mar 2001 13:20:34 -0500 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id NAA22786; Sat, 31 Mar 2001 13:20:34 -0500 From: Ran Canetti Message-Id: <200103311820.NAA22786@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: Sat, 31 Mar 2001 13:20:34 -0500 > 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