From msec-admin@securemulticast.org Sun Jul 1 00:18:28 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA01542 for ; Sun, 1 Jul 2001 00:18:28 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 13CFC5365B; Sat, 30 Jun 2001 14:34:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 64B6D53659 for ; Sat, 30 Jun 2001 14:33:13 -0400 (EDT) Received: (qmail 10552 invoked by uid 3269); 30 Jun 2001 18:33:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10549 invoked from network); 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5UIWih02656; Sat, 30 Jun 2001 11:32:44 -0700 (PDT) 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 f5UIWeg14708; Sat, 30 Jun 2001 11:32:40 -0700 (PDT) Received: from cisco.com (IDENT:bew@jsales-dsl3.cisco.com [10.19.18.52]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA21143; Sat, 30 Jun 2001 11:32:39 -0700 (PDT) Message-ID: <3B3E1B46.711094C7@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: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Comments on draft-ietf-msec-gkmarch-00.txt References: <4.3.2.7.2.20010629162159.04298ef8@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: Sat, 30 Jun 2001 11:32:38 -0700 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > >2. From section 3.2: > > > The Re-key message is optional because all keys, KEK and TEKs, > > > can be delivered by the Registration Protocol exchanges shown in > > > Figure 1. > > > >Two comments: > >a. If there is no Re-key, then a KEK is not necessary. > > We should remove "KEK" from the sentence you cite in 3.2. > > >b. This should also state the obvious, which is the Re-key message is > >optional because rekey may be necessary in some scenarios. > > "optional because rekey may be necessary" does not make sense to me. Sorry, I should have had a comma between "optional" and "because". My point was really that rekey is optional, and if there is no rekey there is no need for a KEK because you won't be sending any more keying data. > >I suggest the following re-written sentence: "The Re-key message is > >optional because the keys can be delivered by the Registration Protocol > >exchanges shown in Figure 1, and those keys may not require updating." > > Why not substitute "TEK" for "key" in your re-written sentence? That would be fine too. Thanks, Brian > Mark > > >Brian > > > >-- > >Brian Weis > >Strategic Cryptographic Development, ITD, Cisco Systems > >Telephone: +1 408 526 4796 > >Email: bew@cisco.com > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Jul 1 01:41:55 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA03939 for ; Sun, 1 Jul 2001 01:41:53 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 13CFC5365B; Sat, 30 Jun 2001 14:34:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 64B6D53659 for ; Sat, 30 Jun 2001 14:33:13 -0400 (EDT) Received: (qmail 10552 invoked by uid 3269); 30 Jun 2001 18:33:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10549 invoked from network); 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5UIWih02656; Sat, 30 Jun 2001 11:32:44 -0700 (PDT) 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 f5UIWeg14708; Sat, 30 Jun 2001 11:32:40 -0700 (PDT) Received: from cisco.com (IDENT:bew@jsales-dsl3.cisco.com [10.19.18.52]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA21143; Sat, 30 Jun 2001 11:32:39 -0700 (PDT) Message-ID: <3B3E1B46.711094C7@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: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Comments on draft-ietf-msec-gkmarch-00.txt References: <4.3.2.7.2.20010629162159.04298ef8@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: Sat, 30 Jun 2001 11:32:38 -0700 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > >2. From section 3.2: > > > The Re-key message is optional because all keys, KEK and TEKs, > > > can be delivered by the Registration Protocol exchanges shown in > > > Figure 1. > > > >Two comments: > >a. If there is no Re-key, then a KEK is not necessary. > > We should remove "KEK" from the sentence you cite in 3.2. > > >b. This should also state the obvious, which is the Re-key message is > >optional because rekey may be necessary in some scenarios. > > "optional because rekey may be necessary" does not make sense to me. Sorry, I should have had a comma between "optional" and "because". My point was really that rekey is optional, and if there is no rekey there is no need for a KEK because you won't be sending any more keying data. > >I suggest the following re-written sentence: "The Re-key message is > >optional because the keys can be delivered by the Registration Protocol > >exchanges shown in Figure 1, and those keys may not require updating." > > Why not substitute "TEK" for "key" in your re-written sentence? That would be fine too. Thanks, Brian > Mark > > >Brian > > > >-- > >Brian Weis > >Strategic Cryptographic Development, ITD, Cisco Systems > >Telephone: +1 408 526 4796 > >Email: bew@cisco.com > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Jul 1 03:05:09 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA16556 for ; Sun, 1 Jul 2001 03:05:09 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 13CFC5365B; Sat, 30 Jun 2001 14:34:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 64B6D53659 for ; Sat, 30 Jun 2001 14:33:13 -0400 (EDT) Received: (qmail 10552 invoked by uid 3269); 30 Jun 2001 18:33:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10549 invoked from network); 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5UIWih02656; Sat, 30 Jun 2001 11:32:44 -0700 (PDT) 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 f5UIWeg14708; Sat, 30 Jun 2001 11:32:40 -0700 (PDT) Received: from cisco.com (IDENT:bew@jsales-dsl3.cisco.com [10.19.18.52]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA21143; Sat, 30 Jun 2001 11:32:39 -0700 (PDT) Message-ID: <3B3E1B46.711094C7@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: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Comments on draft-ietf-msec-gkmarch-00.txt References: <4.3.2.7.2.20010629162159.04298ef8@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: Sat, 30 Jun 2001 11:32:38 -0700 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > >2. From section 3.2: > > > The Re-key message is optional because all keys, KEK and TEKs, > > > can be delivered by the Registration Protocol exchanges shown in > > > Figure 1. > > > >Two comments: > >a. If there is no Re-key, then a KEK is not necessary. > > We should remove "KEK" from the sentence you cite in 3.2. > > >b. This should also state the obvious, which is the Re-key message is > >optional because rekey may be necessary in some scenarios. > > "optional because rekey may be necessary" does not make sense to me. Sorry, I should have had a comma between "optional" and "because". My point was really that rekey is optional, and if there is no rekey there is no need for a KEK because you won't be sending any more keying data. > >I suggest the following re-written sentence: "The Re-key message is > >optional because the keys can be delivered by the Registration Protocol > >exchanges shown in Figure 1, and those keys may not require updating." > > Why not substitute "TEK" for "key" in your re-written sentence? That would be fine too. Thanks, Brian > Mark > > >Brian > > > >-- > >Brian Weis > >Strategic Cryptographic Development, ITD, Cisco Systems > >Telephone: +1 408 526 4796 > >Email: bew@cisco.com > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Jul 1 04:28:26 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06118 for ; Sun, 1 Jul 2001 04:28:25 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 13CFC5365B; Sat, 30 Jun 2001 14:34:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 64B6D53659 for ; Sat, 30 Jun 2001 14:33:13 -0400 (EDT) Received: (qmail 10552 invoked by uid 3269); 30 Jun 2001 18:33:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10549 invoked from network); 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5UIWih02656; Sat, 30 Jun 2001 11:32:44 -0700 (PDT) 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 f5UIWeg14708; Sat, 30 Jun 2001 11:32:40 -0700 (PDT) Received: from cisco.com (IDENT:bew@jsales-dsl3.cisco.com [10.19.18.52]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA21143; Sat, 30 Jun 2001 11:32:39 -0700 (PDT) Message-ID: <3B3E1B46.711094C7@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: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Comments on draft-ietf-msec-gkmarch-00.txt References: <4.3.2.7.2.20010629162159.04298ef8@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: Sat, 30 Jun 2001 11:32:38 -0700 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > >2. From section 3.2: > > > The Re-key message is optional because all keys, KEK and TEKs, > > > can be delivered by the Registration Protocol exchanges shown in > > > Figure 1. > > > >Two comments: > >a. If there is no Re-key, then a KEK is not necessary. > > We should remove "KEK" from the sentence you cite in 3.2. > > >b. This should also state the obvious, which is the Re-key message is > >optional because rekey may be necessary in some scenarios. > > "optional because rekey may be necessary" does not make sense to me. Sorry, I should have had a comma between "optional" and "because". My point was really that rekey is optional, and if there is no rekey there is no need for a KEK because you won't be sending any more keying data. > >I suggest the following re-written sentence: "The Re-key message is > >optional because the keys can be delivered by the Registration Protocol > >exchanges shown in Figure 1, and those keys may not require updating." > > Why not substitute "TEK" for "key" in your re-written sentence? That would be fine too. Thanks, Brian > Mark > > >Brian > > > >-- > >Brian Weis > >Strategic Cryptographic Development, ITD, Cisco Systems > >Telephone: +1 408 526 4796 > >Email: bew@cisco.com > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Jul 1 05:51:44 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09055 for ; Sun, 1 Jul 2001 05:51:44 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 13CFC5365B; Sat, 30 Jun 2001 14:34:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 64B6D53659 for ; Sat, 30 Jun 2001 14:33:13 -0400 (EDT) Received: (qmail 10552 invoked by uid 3269); 30 Jun 2001 18:33:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10549 invoked from network); 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5UIWih02656; Sat, 30 Jun 2001 11:32:44 -0700 (PDT) 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 f5UIWeg14708; Sat, 30 Jun 2001 11:32:40 -0700 (PDT) Received: from cisco.com (IDENT:bew@jsales-dsl3.cisco.com [10.19.18.52]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA21143; Sat, 30 Jun 2001 11:32:39 -0700 (PDT) Message-ID: <3B3E1B46.711094C7@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: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Comments on draft-ietf-msec-gkmarch-00.txt References: <4.3.2.7.2.20010629162159.04298ef8@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: Sat, 30 Jun 2001 11:32:38 -0700 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > >2. From section 3.2: > > > The Re-key message is optional because all keys, KEK and TEKs, > > > can be delivered by the Registration Protocol exchanges shown in > > > Figure 1. > > > >Two comments: > >a. If there is no Re-key, then a KEK is not necessary. > > We should remove "KEK" from the sentence you cite in 3.2. > > >b. This should also state the obvious, which is the Re-key message is > >optional because rekey may be necessary in some scenarios. > > "optional because rekey may be necessary" does not make sense to me. Sorry, I should have had a comma between "optional" and "because". My point was really that rekey is optional, and if there is no rekey there is no need for a KEK because you won't be sending any more keying data. > >I suggest the following re-written sentence: "The Re-key message is > >optional because the keys can be delivered by the Registration Protocol > >exchanges shown in Figure 1, and those keys may not require updating." > > Why not substitute "TEK" for "key" in your re-written sentence? That would be fine too. Thanks, Brian > Mark > > >Brian > > > >-- > >Brian Weis > >Strategic Cryptographic Development, ITD, Cisco Systems > >Telephone: +1 408 526 4796 > >Email: bew@cisco.com > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Jul 1 07:15:09 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09359 for ; Sun, 1 Jul 2001 07:15:08 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 13CFC5365B; Sat, 30 Jun 2001 14:34:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 64B6D53659 for ; Sat, 30 Jun 2001 14:33:13 -0400 (EDT) Received: (qmail 10552 invoked by uid 3269); 30 Jun 2001 18:33:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10549 invoked from network); 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5UIWih02656; Sat, 30 Jun 2001 11:32:44 -0700 (PDT) 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 f5UIWeg14708; Sat, 30 Jun 2001 11:32:40 -0700 (PDT) Received: from cisco.com (IDENT:bew@jsales-dsl3.cisco.com [10.19.18.52]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA21143; Sat, 30 Jun 2001 11:32:39 -0700 (PDT) Message-ID: <3B3E1B46.711094C7@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: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Comments on draft-ietf-msec-gkmarch-00.txt References: <4.3.2.7.2.20010629162159.04298ef8@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: Sat, 30 Jun 2001 11:32:38 -0700 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > >2. From section 3.2: > > > The Re-key message is optional because all keys, KEK and TEKs, > > > can be delivered by the Registration Protocol exchanges shown in > > > Figure 1. > > > >Two comments: > >a. If there is no Re-key, then a KEK is not necessary. > > We should remove "KEK" from the sentence you cite in 3.2. > > >b. This should also state the obvious, which is the Re-key message is > >optional because rekey may be necessary in some scenarios. > > "optional because rekey may be necessary" does not make sense to me. Sorry, I should have had a comma between "optional" and "because". My point was really that rekey is optional, and if there is no rekey there is no need for a KEK because you won't be sending any more keying data. > >I suggest the following re-written sentence: "The Re-key message is > >optional because the keys can be delivered by the Registration Protocol > >exchanges shown in Figure 1, and those keys may not require updating." > > Why not substitute "TEK" for "key" in your re-written sentence? That would be fine too. Thanks, Brian > Mark > > >Brian > > > >-- > >Brian Weis > >Strategic Cryptographic Development, ITD, Cisco Systems > >Telephone: +1 408 526 4796 > >Email: bew@cisco.com > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Jul 1 08:38:25 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10301 for ; Sun, 1 Jul 2001 08:38:24 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 13CFC5365B; Sat, 30 Jun 2001 14:34:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 64B6D53659 for ; Sat, 30 Jun 2001 14:33:13 -0400 (EDT) Received: (qmail 10552 invoked by uid 3269); 30 Jun 2001 18:33:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10549 invoked from network); 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5UIWih02656; Sat, 30 Jun 2001 11:32:44 -0700 (PDT) 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 f5UIWeg14708; Sat, 30 Jun 2001 11:32:40 -0700 (PDT) Received: from cisco.com (IDENT:bew@jsales-dsl3.cisco.com [10.19.18.52]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA21143; Sat, 30 Jun 2001 11:32:39 -0700 (PDT) Message-ID: <3B3E1B46.711094C7@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: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Comments on draft-ietf-msec-gkmarch-00.txt References: <4.3.2.7.2.20010629162159.04298ef8@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: Sat, 30 Jun 2001 11:32:38 -0700 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > >2. From section 3.2: > > > The Re-key message is optional because all keys, KEK and TEKs, > > > can be delivered by the Registration Protocol exchanges shown in > > > Figure 1. > > > >Two comments: > >a. If there is no Re-key, then a KEK is not necessary. > > We should remove "KEK" from the sentence you cite in 3.2. > > >b. This should also state the obvious, which is the Re-key message is > >optional because rekey may be necessary in some scenarios. > > "optional because rekey may be necessary" does not make sense to me. Sorry, I should have had a comma between "optional" and "because". My point was really that rekey is optional, and if there is no rekey there is no need for a KEK because you won't be sending any more keying data. > >I suggest the following re-written sentence: "The Re-key message is > >optional because the keys can be delivered by the Registration Protocol > >exchanges shown in Figure 1, and those keys may not require updating." > > Why not substitute "TEK" for "key" in your re-written sentence? That would be fine too. Thanks, Brian > Mark > > >Brian > > > >-- > >Brian Weis > >Strategic Cryptographic Development, ITD, Cisco Systems > >Telephone: +1 408 526 4796 > >Email: bew@cisco.com > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Jul 1 10:02:39 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11282 for ; Sun, 1 Jul 2001 10:02:39 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 13CFC5365B; Sat, 30 Jun 2001 14:34:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 64B6D53659 for ; Sat, 30 Jun 2001 14:33:13 -0400 (EDT) Received: (qmail 10552 invoked by uid 3269); 30 Jun 2001 18:33:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10549 invoked from network); 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5UIWih02656; Sat, 30 Jun 2001 11:32:44 -0700 (PDT) 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 f5UIWeg14708; Sat, 30 Jun 2001 11:32:40 -0700 (PDT) Received: from cisco.com (IDENT:bew@jsales-dsl3.cisco.com [10.19.18.52]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA21143; Sat, 30 Jun 2001 11:32:39 -0700 (PDT) Message-ID: <3B3E1B46.711094C7@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: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Comments on draft-ietf-msec-gkmarch-00.txt References: <4.3.2.7.2.20010629162159.04298ef8@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: Sat, 30 Jun 2001 11:32:38 -0700 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > >2. From section 3.2: > > > The Re-key message is optional because all keys, KEK and TEKs, > > > can be delivered by the Registration Protocol exchanges shown in > > > Figure 1. > > > >Two comments: > >a. If there is no Re-key, then a KEK is not necessary. > > We should remove "KEK" from the sentence you cite in 3.2. > > >b. This should also state the obvious, which is the Re-key message is > >optional because rekey may be necessary in some scenarios. > > "optional because rekey may be necessary" does not make sense to me. Sorry, I should have had a comma between "optional" and "because". My point was really that rekey is optional, and if there is no rekey there is no need for a KEK because you won't be sending any more keying data. > >I suggest the following re-written sentence: "The Re-key message is > >optional because the keys can be delivered by the Registration Protocol > >exchanges shown in Figure 1, and those keys may not require updating." > > Why not substitute "TEK" for "key" in your re-written sentence? That would be fine too. Thanks, Brian > Mark > > >Brian > > > >-- > >Brian Weis > >Strategic Cryptographic Development, ITD, Cisco Systems > >Telephone: +1 408 526 4796 > >Email: bew@cisco.com > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Jul 1 11:25:05 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12082 for ; Sun, 1 Jul 2001 11:25:04 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 13CFC5365B; Sat, 30 Jun 2001 14:34:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 64B6D53659 for ; Sat, 30 Jun 2001 14:33:13 -0400 (EDT) Received: (qmail 10552 invoked by uid 3269); 30 Jun 2001 18:33:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10549 invoked from network); 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5UIWih02656; Sat, 30 Jun 2001 11:32:44 -0700 (PDT) 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 f5UIWeg14708; Sat, 30 Jun 2001 11:32:40 -0700 (PDT) Received: from cisco.com (IDENT:bew@jsales-dsl3.cisco.com [10.19.18.52]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA21143; Sat, 30 Jun 2001 11:32:39 -0700 (PDT) Message-ID: <3B3E1B46.711094C7@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: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Comments on draft-ietf-msec-gkmarch-00.txt References: <4.3.2.7.2.20010629162159.04298ef8@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: Sat, 30 Jun 2001 11:32:38 -0700 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > >2. From section 3.2: > > > The Re-key message is optional because all keys, KEK and TEKs, > > > can be delivered by the Registration Protocol exchanges shown in > > > Figure 1. > > > >Two comments: > >a. If there is no Re-key, then a KEK is not necessary. > > We should remove "KEK" from the sentence you cite in 3.2. > > >b. This should also state the obvious, which is the Re-key message is > >optional because rekey may be necessary in some scenarios. > > "optional because rekey may be necessary" does not make sense to me. Sorry, I should have had a comma between "optional" and "because". My point was really that rekey is optional, and if there is no rekey there is no need for a KEK because you won't be sending any more keying data. > >I suggest the following re-written sentence: "The Re-key message is > >optional because the keys can be delivered by the Registration Protocol > >exchanges shown in Figure 1, and those keys may not require updating." > > Why not substitute "TEK" for "key" in your re-written sentence? That would be fine too. Thanks, Brian > Mark > > >Brian > > > >-- > >Brian Weis > >Strategic Cryptographic Development, ITD, Cisco Systems > >Telephone: +1 408 526 4796 > >Email: bew@cisco.com > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Jul 1 12:48:26 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12718 for ; Sun, 1 Jul 2001 12:48:26 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 13CFC5365B; Sat, 30 Jun 2001 14:34:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 64B6D53659 for ; Sat, 30 Jun 2001 14:33:13 -0400 (EDT) Received: (qmail 10552 invoked by uid 3269); 30 Jun 2001 18:33:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10549 invoked from network); 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5UIWih02656; Sat, 30 Jun 2001 11:32:44 -0700 (PDT) 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 f5UIWeg14708; Sat, 30 Jun 2001 11:32:40 -0700 (PDT) Received: from cisco.com (IDENT:bew@jsales-dsl3.cisco.com [10.19.18.52]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA21143; Sat, 30 Jun 2001 11:32:39 -0700 (PDT) Message-ID: <3B3E1B46.711094C7@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: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Comments on draft-ietf-msec-gkmarch-00.txt References: <4.3.2.7.2.20010629162159.04298ef8@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: Sat, 30 Jun 2001 11:32:38 -0700 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > >2. From section 3.2: > > > The Re-key message is optional because all keys, KEK and TEKs, > > > can be delivered by the Registration Protocol exchanges shown in > > > Figure 1. > > > >Two comments: > >a. If there is no Re-key, then a KEK is not necessary. > > We should remove "KEK" from the sentence you cite in 3.2. > > >b. This should also state the obvious, which is the Re-key message is > >optional because rekey may be necessary in some scenarios. > > "optional because rekey may be necessary" does not make sense to me. Sorry, I should have had a comma between "optional" and "because". My point was really that rekey is optional, and if there is no rekey there is no need for a KEK because you won't be sending any more keying data. > >I suggest the following re-written sentence: "The Re-key message is > >optional because the keys can be delivered by the Registration Protocol > >exchanges shown in Figure 1, and those keys may not require updating." > > Why not substitute "TEK" for "key" in your re-written sentence? That would be fine too. Thanks, Brian > Mark > > >Brian > > > >-- > >Brian Weis > >Strategic Cryptographic Development, ITD, Cisco Systems > >Telephone: +1 408 526 4796 > >Email: bew@cisco.com > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Jul 1 13:28:38 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12938 for ; Sun, 1 Jul 2001 13:28:38 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0B5EA53708; Sun, 1 Jul 2001 13:28:18 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 3C0AE536AE for ; Sun, 1 Jul 2001 13:27:47 -0400 (EDT) Received: (qmail 98946 invoked by uid 3269); 1 Jul 2001 17:27:46 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 98943 invoked from network); 1 Jul 2001 17:27:46 -0000 Received: from news.comp.lancs.ac.uk (148.88.152.70) by klesh.pair.com with SMTP; 1 Jul 2001 17:27:46 -0000 Received: from rafaeli (pepsi-33.lancs.ac.uk [194.80.33.233]) by news.comp.lancs.ac.uk (8.11.0/8.11.0) with SMTP id f61HRf014064 for ; Sun, 1 Jul 2001 18:27:41 +0100 (BST) From: "Sandro Rafaeli" To: Subject: RE: [MSEC] De-registration protocol? Message-ID: <000001c10253$0ff155a0$e92150c2@lancs.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <4.3.2.7.2.20010630162120.041c91e8@mira-sjc5-6.cisco.com> Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Sun, 1 Jul 2001 18:27:11 +0100 Content-Transfer-Encoding: 7bit The "waste" left in the LKH tree can do more damage to group members than it does to the KDC. If leaving members are not removed from the LKH tree, then the tree will be getting higher and higher, causing the number of keys held by members to increase. Not only that increases, but the computation required per rekey message also increases. The original idea of LKH-like protocols is to minimise bandwidth usage and members and KDC storage. That is a fair reason for maintaining a tight control of the group membership. Mark said that the de-registration (or whatever it's going to be called, if ata ll :)) is required only in conjunction with a rekey protocol. I would extend that to: de-registration is required only when membership management algorithm are employed!! If a unique Group KEK is being used, then there is no (clear) reason for the member to tell the KDC he has left the group. A future rekey in this case will not consider the leaving members for the simple reason that it is not possible to remove old members with a unique Group KEK (unless you want to encrypt the new KEK and TEK(s) with every remaining member's secret key. Cheers, Sandro. ps: Thomas proposed "a De-registration-KEK" to authenticate the leaving member's de-registration command. In order to save that "extra" key, what would the implication of using the current member's secret key (known only by himself and KDC) for that purpose? | -----Original Message----- | From: msec-admin@securemulticast.org | [mailto:msec-admin@securemulticast.org]On Behalf Of Mark Baugher | Sent: 01 July 2001 00:43 | To: Ran Canetti | Cc: canetti@watson.ibm.com; msec@securemulticast.org | Subject: Re: [MSEC] De-registration protocol? | | | Ran | I have not heard any support on this list for the | de-registration protocol | so I would not rush to say it's a an "integral part of the | msec protocol | suite." It's something we're discussing, but I think the | costs outweigh | the benefits. | | First, it's use is complicated. For example, it is a | REQUIREMENT that | you use the de-registration protocol only if you use the | re-key protocol. | One might expect that if you do a register, then you might do a | de-register, but this is a waste of resources unless it is | possible to | rekey some member out of the group. | | Someone pointed out that the name "register" is a problem since it's | an overloaded word. It's a metaphor really that conjures up | a lot of things | outside the scope of key management. I think we ought to change the | name of "register" and go back to GSAKMP or GDOI. We called the | GDOI IKE Phase 2 the GROUPKEY-PULL exchange; GSAKMP uses | "Group Establishment." I can't help but think the word "register" | invites a "de-register," which is not meaningful outside of | the context | of re-key. | | Another problem with de-register is that key management should not | be re-keying the group on a member's signal. There is an | authorization | application that controls the group and not the members. About all | the de-register protocol will do is to alert the | authorization app that | a member claims it has left the group. | | There is exactly one benefit to doing de-register: For a | KDC that has | a LKH or some other structure to maintain group membership, a | de-register allows a member to be nice and inform that KDC that | it can release some memory that is currently allocated for that | member. How much memory would that be? 128 bits plus some | metadata I suspect. No very much at all. | | I think we should drop the notion of a "de-register" | operation and take | up the issue of members announcing that they are leaving groups in | the re-key protocol work. If it belongs anywhere, that's where it | belongs. It really has nothing to do with register independent of | re-key. | | Mark _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Jul 1 14:11:44 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13206 for ; Sun, 1 Jul 2001 14:11:43 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 13CFC5365B; Sat, 30 Jun 2001 14:34:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 64B6D53659 for ; Sat, 30 Jun 2001 14:33:13 -0400 (EDT) Received: (qmail 10552 invoked by uid 3269); 30 Jun 2001 18:33:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10549 invoked from network); 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5UIWih02656; Sat, 30 Jun 2001 11:32:44 -0700 (PDT) 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 f5UIWeg14708; Sat, 30 Jun 2001 11:32:40 -0700 (PDT) Received: from cisco.com (IDENT:bew@jsales-dsl3.cisco.com [10.19.18.52]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA21143; Sat, 30 Jun 2001 11:32:39 -0700 (PDT) Message-ID: <3B3E1B46.711094C7@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: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Comments on draft-ietf-msec-gkmarch-00.txt References: <4.3.2.7.2.20010629162159.04298ef8@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: Sat, 30 Jun 2001 11:32:38 -0700 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > >2. From section 3.2: > > > The Re-key message is optional because all keys, KEK and TEKs, > > > can be delivered by the Registration Protocol exchanges shown in > > > Figure 1. > > > >Two comments: > >a. If there is no Re-key, then a KEK is not necessary. > > We should remove "KEK" from the sentence you cite in 3.2. > > >b. This should also state the obvious, which is the Re-key message is > >optional because rekey may be necessary in some scenarios. > > "optional because rekey may be necessary" does not make sense to me. Sorry, I should have had a comma between "optional" and "because". My point was really that rekey is optional, and if there is no rekey there is no need for a KEK because you won't be sending any more keying data. > >I suggest the following re-written sentence: "The Re-key message is > >optional because the keys can be delivered by the Registration Protocol > >exchanges shown in Figure 1, and those keys may not require updating." > > Why not substitute "TEK" for "key" in your re-written sentence? That would be fine too. Thanks, Brian > Mark > > >Brian > > > >-- > >Brian Weis > >Strategic Cryptographic Development, ITD, Cisco Systems > >Telephone: +1 408 526 4796 > >Email: bew@cisco.com > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Jul 1 14:29:59 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13282 for ; Sun, 1 Jul 2001 14:29:59 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id EF5EF537A3; Sun, 1 Jul 2001 14:30:03 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 161D353686 for ; Sun, 1 Jul 2001 14:28:20 -0400 (EDT) Received: (qmail 2528 invoked by uid 3269); 1 Jul 2001 18:28:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 2525 invoked from network); 1 Jul 2001 18:28:19 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by klesh.pair.com with SMTP; 1 Jul 2001 18:28:19 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f61IQAH19909; Sun, 1 Jul 2001 11:26:10 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-tmp100.cisco.com [10.21.64.100]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADL06338; Sun, 1 Jul 2001 11:27:42 -0700 (PDT) Message-Id: <4.3.2.7.2.20010701112021.041c9ef8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Sandro Rafaeli" From: Mark Baugher Subject: RE: [MSEC] De-registration protocol? Cc: In-Reply-To: <000001c10253$0ff155a0$e92150c2@lancs.ac.uk> References: <4.3.2.7.2.20010630162120.041c91e8@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: Sun, 01 Jul 2001 11:27:12 -0700 At 06:27 PM 7/1/2001 +0100, Sandro Rafaeli wrote: >The "waste" left in the LKH tree can do more damage to group members than it >does to the KDC. If leaving members are not removed from the LKH tree, then >the tree will be getting higher and higher, causing the number of keys held >by members to increase. Not only that increases, but the computation >required per rekey message also increases. The original idea of LKH-like >protocols is to minimise bandwidth usage and members and KDC storage. That >is a fair reason for maintaining a tight control of the group membership. The KEKs (leaf and node in the LKH case) will always have a lifetime and will expire. The KDC can reduce memory consumption and message-bandwidth by making the lifetime shorter. In so doing, it must endure more frequent "registrations" (GDOI Phase 2, GSAKMP Group (re-)Establishment), which impose a computation hit on the KDC. >Mark said that the de-registration (or whatever it's going to be called, if >ata ll :)) is required only in conjunction with a rekey protocol. I would >extend that to: de-registration is required only when membership management >algorithm are employed!! If a unique Group KEK is being used, then there is Yes, this is what I meant though it's not what I wrote. >no (clear) reason for the member to tell the KDC he has left the group. A If there is only a single KEK or no KEK then this is true. >future rekey in this case will not consider the leaving members for the >simple reason that it is not possible to remove old members with a unique >Group KEK (unless you want to encrypt the new KEK and TEK(s) with every >remaining member's secret key. So I amend what I wrote as follows: It would be a REQUIREMENT for a "de-register" operation that it MUST NOT be used when there is no LKH-like membership management algorithm used for the group. Mark >Cheers, >Sandro. > > >ps: Thomas proposed "a De-registration-KEK" to authenticate the leaving >member's de-registration command. In order to save that "extra" key, what >would the implication of using the current member's secret key (known only >by himself and KDC) for that purpose? > > >| -----Original Message----- >| From: msec-admin@securemulticast.org >| [mailto:msec-admin@securemulticast.org]On Behalf Of Mark Baugher >| Sent: 01 July 2001 00:43 >| To: Ran Canetti >| Cc: canetti@watson.ibm.com; msec@securemulticast.org >| Subject: Re: [MSEC] De-registration protocol? >| >| >| Ran >| I have not heard any support on this list for the >| de-registration protocol >| so I would not rush to say it's a an "integral part of the >| msec protocol >| suite." It's something we're discussing, but I think the >| costs outweigh >| the benefits. >| >| First, it's use is complicated. For example, it is a >| REQUIREMENT that >| you use the de-registration protocol only if you use the >| re-key protocol. >| One might expect that if you do a register, then you might do a >| de-register, but this is a waste of resources unless it is >| possible to >| rekey some member out of the group. >| >| Someone pointed out that the name "register" is a problem since it's >| an overloaded word. It's a metaphor really that conjures up >| a lot of things >| outside the scope of key management. I think we ought to change the >| name of "register" and go back to GSAKMP or GDOI. We called the >| GDOI IKE Phase 2 the GROUPKEY-PULL exchange; GSAKMP uses >| "Group Establishment." I can't help but think the word "register" >| invites a "de-register," which is not meaningful outside of >| the context >| of re-key. >| >| Another problem with de-register is that key management should not >| be re-keying the group on a member's signal. There is an >| authorization >| application that controls the group and not the members. About all >| the de-register protocol will do is to alert the >| authorization app that >| a member claims it has left the group. >| >| There is exactly one benefit to doing de-register: For a >| KDC that has >| a LKH or some other structure to maintain group membership, a >| de-register allows a member to be nice and inform that KDC that >| it can release some memory that is currently allocated for that >| member. How much memory would that be? 128 bits plus some >| metadata I suspect. No very much at all. >| >| I think we should drop the notion of a "de-register" >| operation and take >| up the issue of members announcing that they are leaving groups in >| the re-key protocol work. If it belongs anywhere, that's where it >| belongs. It really has nothing to do with register independent of >| re-key. >| >| Mark > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Jul 1 15:35:09 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13558 for ; Sun, 1 Jul 2001 15:35:08 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 13CFC5365B; Sat, 30 Jun 2001 14:34:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 64B6D53659 for ; Sat, 30 Jun 2001 14:33:13 -0400 (EDT) Received: (qmail 10552 invoked by uid 3269); 30 Jun 2001 18:33:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10549 invoked from network); 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5UIWih02656; Sat, 30 Jun 2001 11:32:44 -0700 (PDT) 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 f5UIWeg14708; Sat, 30 Jun 2001 11:32:40 -0700 (PDT) Received: from cisco.com (IDENT:bew@jsales-dsl3.cisco.com [10.19.18.52]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA21143; Sat, 30 Jun 2001 11:32:39 -0700 (PDT) Message-ID: <3B3E1B46.711094C7@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: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Comments on draft-ietf-msec-gkmarch-00.txt References: <4.3.2.7.2.20010629162159.04298ef8@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: Sat, 30 Jun 2001 11:32:38 -0700 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > >2. From section 3.2: > > > The Re-key message is optional because all keys, KEK and TEKs, > > > can be delivered by the Registration Protocol exchanges shown in > > > Figure 1. > > > >Two comments: > >a. If there is no Re-key, then a KEK is not necessary. > > We should remove "KEK" from the sentence you cite in 3.2. > > >b. This should also state the obvious, which is the Re-key message is > >optional because rekey may be necessary in some scenarios. > > "optional because rekey may be necessary" does not make sense to me. Sorry, I should have had a comma between "optional" and "because". My point was really that rekey is optional, and if there is no rekey there is no need for a KEK because you won't be sending any more keying data. > >I suggest the following re-written sentence: "The Re-key message is > >optional because the keys can be delivered by the Registration Protocol > >exchanges shown in Figure 1, and those keys may not require updating." > > Why not substitute "TEK" for "key" in your re-written sentence? That would be fine too. Thanks, Brian > Mark > > >Brian > > > >-- > >Brian Weis > >Strategic Cryptographic Development, ITD, Cisco Systems > >Telephone: +1 408 526 4796 > >Email: bew@cisco.com > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Jul 1 16:58:30 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13917 for ; Sun, 1 Jul 2001 16:58:29 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 13CFC5365B; Sat, 30 Jun 2001 14:34:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 64B6D53659 for ; Sat, 30 Jun 2001 14:33:13 -0400 (EDT) Received: (qmail 10552 invoked by uid 3269); 30 Jun 2001 18:33:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10549 invoked from network); 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5UIWih02656; Sat, 30 Jun 2001 11:32:44 -0700 (PDT) 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 f5UIWeg14708; Sat, 30 Jun 2001 11:32:40 -0700 (PDT) Received: from cisco.com (IDENT:bew@jsales-dsl3.cisco.com [10.19.18.52]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA21143; Sat, 30 Jun 2001 11:32:39 -0700 (PDT) Message-ID: <3B3E1B46.711094C7@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: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Comments on draft-ietf-msec-gkmarch-00.txt References: <4.3.2.7.2.20010629162159.04298ef8@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: Sat, 30 Jun 2001 11:32:38 -0700 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > >2. From section 3.2: > > > The Re-key message is optional because all keys, KEK and TEKs, > > > can be delivered by the Registration Protocol exchanges shown in > > > Figure 1. > > > >Two comments: > >a. If there is no Re-key, then a KEK is not necessary. > > We should remove "KEK" from the sentence you cite in 3.2. > > >b. This should also state the obvious, which is the Re-key message is > >optional because rekey may be necessary in some scenarios. > > "optional because rekey may be necessary" does not make sense to me. Sorry, I should have had a comma between "optional" and "because". My point was really that rekey is optional, and if there is no rekey there is no need for a KEK because you won't be sending any more keying data. > >I suggest the following re-written sentence: "The Re-key message is > >optional because the keys can be delivered by the Registration Protocol > >exchanges shown in Figure 1, and those keys may not require updating." > > Why not substitute "TEK" for "key" in your re-written sentence? That would be fine too. Thanks, Brian > Mark > > >Brian > > > >-- > >Brian Weis > >Strategic Cryptographic Development, ITD, Cisco Systems > >Telephone: +1 408 526 4796 > >Email: bew@cisco.com > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Jul 1 18:21:47 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14489 for ; Sun, 1 Jul 2001 18:21:47 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 13CFC5365B; Sat, 30 Jun 2001 14:34:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 64B6D53659 for ; Sat, 30 Jun 2001 14:33:13 -0400 (EDT) Received: (qmail 10552 invoked by uid 3269); 30 Jun 2001 18:33:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10549 invoked from network); 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5UIWih02656; Sat, 30 Jun 2001 11:32:44 -0700 (PDT) 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 f5UIWeg14708; Sat, 30 Jun 2001 11:32:40 -0700 (PDT) Received: from cisco.com (IDENT:bew@jsales-dsl3.cisco.com [10.19.18.52]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA21143; Sat, 30 Jun 2001 11:32:39 -0700 (PDT) Message-ID: <3B3E1B46.711094C7@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: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Comments on draft-ietf-msec-gkmarch-00.txt References: <4.3.2.7.2.20010629162159.04298ef8@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: Sat, 30 Jun 2001 11:32:38 -0700 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > >2. From section 3.2: > > > The Re-key message is optional because all keys, KEK and TEKs, > > > can be delivered by the Registration Protocol exchanges shown in > > > Figure 1. > > > >Two comments: > >a. If there is no Re-key, then a KEK is not necessary. > > We should remove "KEK" from the sentence you cite in 3.2. > > >b. This should also state the obvious, which is the Re-key message is > >optional because rekey may be necessary in some scenarios. > > "optional because rekey may be necessary" does not make sense to me. Sorry, I should have had a comma between "optional" and "because". My point was really that rekey is optional, and if there is no rekey there is no need for a KEK because you won't be sending any more keying data. > >I suggest the following re-written sentence: "The Re-key message is > >optional because the keys can be delivered by the Registration Protocol > >exchanges shown in Figure 1, and those keys may not require updating." > > Why not substitute "TEK" for "key" in your re-written sentence? That would be fine too. Thanks, Brian > Mark > > >Brian > > > >-- > >Brian Weis > >Strategic Cryptographic Development, ITD, Cisco Systems > >Telephone: +1 408 526 4796 > >Email: bew@cisco.com > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Jul 1 19:13:09 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14740 for ; Sun, 1 Jul 2001 19:13:09 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4FA985371F; Sun, 1 Jul 2001 19:12:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 68C6353729 for ; Sun, 1 Jul 2001 19:10:08 -0400 (EDT) Received: (qmail 20140 invoked by uid 3269); 1 Jul 2001 23:10:08 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 20137 invoked from network); 1 Jul 2001 23:10:07 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 1 Jul 2001 23:10:07 -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 f61N9T816214; Sun, 1 Jul 2001 19:09:29 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id TAA30030; Sun, 1 Jul 2001 19:09:29 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id TAA34422; Sun, 1 Jul 2001 19:09:29 -0400 From: Ran Canetti Message-Id: <200107012309.TAA34422@ornavella.watson.ibm.com> To: mbaugher@cisco.com, rafaeli@comp.lancs.ac.uk Subject: RE: [MSEC] De-registration protocol? Cc: msec@securemulticast.org Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Sun, 1 Jul 2001 19:09:29 -0400 Thomas, Mark, I think you misunderstand my intention regarding the de-registration protocol. So let me try to clarify. The de-registration protocol is a tool that allows the leaving member to securely notify the GCKS that it has left the group. There is no mechanism that forces the GCKS to rekey the group immediately or at any other time. This is up to the GCKS to decide, and is not up to us for standardization. (True, the design we have in mind would call for the GCKS to remove the member from the group in the next rekeying message. But this is again up to the GCKS.) My reason for making the de-registration protocol an (optional) part of the msec suite is to provide the application with a complete and uniform interface of secure group operations. This looks cleaner and better design to me than forcing the application to take care of securing leave operations by itself. In all, I see two options: 1. We believe that having members sign up only for preset periods of time is sufficient for now. In this case we can indeed leave de-registration for later. However, as Sandro noted, in this case there is much less need in the rekeying mechanism in the first place. Instead we can use the MARKS mechanism (or simply choose keys for preset periods of time) and avoid the rekeying messages altogether. 2. We decide that we need to provide the group controller with the ability to let members sign up for an unspecified time and then be charge them according to the actual amount of time used. In this case it is clear that secure de-registration is necessary. Here I strongly believe that we need to provide this functionality within msec. Ran BTW, Mark, in a model where a member pays acording to the time elapsed between registration and de-registration, the de-registration mechanism is not just for being nice. And this is true regardless of how these protocols are called... _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Jul 1 19:45:04 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14865 for ; Sun, 1 Jul 2001 19:45:04 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 13CFC5365B; Sat, 30 Jun 2001 14:34:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 64B6D53659 for ; Sat, 30 Jun 2001 14:33:13 -0400 (EDT) Received: (qmail 10552 invoked by uid 3269); 30 Jun 2001 18:33:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10549 invoked from network); 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5UIWih02656; Sat, 30 Jun 2001 11:32:44 -0700 (PDT) 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 f5UIWeg14708; Sat, 30 Jun 2001 11:32:40 -0700 (PDT) Received: from cisco.com (IDENT:bew@jsales-dsl3.cisco.com [10.19.18.52]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA21143; Sat, 30 Jun 2001 11:32:39 -0700 (PDT) Message-ID: <3B3E1B46.711094C7@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: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Comments on draft-ietf-msec-gkmarch-00.txt References: <4.3.2.7.2.20010629162159.04298ef8@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: Sat, 30 Jun 2001 11:32:38 -0700 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > >2. From section 3.2: > > > The Re-key message is optional because all keys, KEK and TEKs, > > > can be delivered by the Registration Protocol exchanges shown in > > > Figure 1. > > > >Two comments: > >a. If there is no Re-key, then a KEK is not necessary. > > We should remove "KEK" from the sentence you cite in 3.2. > > >b. This should also state the obvious, which is the Re-key message is > >optional because rekey may be necessary in some scenarios. > > "optional because rekey may be necessary" does not make sense to me. Sorry, I should have had a comma between "optional" and "because". My point was really that rekey is optional, and if there is no rekey there is no need for a KEK because you won't be sending any more keying data. > >I suggest the following re-written sentence: "The Re-key message is > >optional because the keys can be delivered by the Registration Protocol > >exchanges shown in Figure 1, and those keys may not require updating." > > Why not substitute "TEK" for "key" in your re-written sentence? That would be fine too. Thanks, Brian > Mark > > >Brian > > > >-- > >Brian Weis > >Strategic Cryptographic Development, ITD, Cisco Systems > >Telephone: +1 408 526 4796 > >Email: bew@cisco.com > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Jul 1 21:08:24 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15249 for ; Sun, 1 Jul 2001 21:08:24 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 13CFC5365B; Sat, 30 Jun 2001 14:34:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 64B6D53659 for ; Sat, 30 Jun 2001 14:33:13 -0400 (EDT) Received: (qmail 10552 invoked by uid 3269); 30 Jun 2001 18:33:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10549 invoked from network); 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5UIWih02656; Sat, 30 Jun 2001 11:32:44 -0700 (PDT) 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 f5UIWeg14708; Sat, 30 Jun 2001 11:32:40 -0700 (PDT) Received: from cisco.com (IDENT:bew@jsales-dsl3.cisco.com [10.19.18.52]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA21143; Sat, 30 Jun 2001 11:32:39 -0700 (PDT) Message-ID: <3B3E1B46.711094C7@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: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Comments on draft-ietf-msec-gkmarch-00.txt References: <4.3.2.7.2.20010629162159.04298ef8@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: Sat, 30 Jun 2001 11:32:38 -0700 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > >2. From section 3.2: > > > The Re-key message is optional because all keys, KEK and TEKs, > > > can be delivered by the Registration Protocol exchanges shown in > > > Figure 1. > > > >Two comments: > >a. If there is no Re-key, then a KEK is not necessary. > > We should remove "KEK" from the sentence you cite in 3.2. > > >b. This should also state the obvious, which is the Re-key message is > >optional because rekey may be necessary in some scenarios. > > "optional because rekey may be necessary" does not make sense to me. Sorry, I should have had a comma between "optional" and "because". My point was really that rekey is optional, and if there is no rekey there is no need for a KEK because you won't be sending any more keying data. > >I suggest the following re-written sentence: "The Re-key message is > >optional because the keys can be delivered by the Registration Protocol > >exchanges shown in Figure 1, and those keys may not require updating." > > Why not substitute "TEK" for "key" in your re-written sentence? That would be fine too. Thanks, Brian > Mark > > >Brian > > > >-- > >Brian Weis > >Strategic Cryptographic Development, ITD, Cisco Systems > >Telephone: +1 408 526 4796 > >Email: bew@cisco.com > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Jul 1 22:31:45 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17380 for ; Sun, 1 Jul 2001 22:31:45 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 13CFC5365B; Sat, 30 Jun 2001 14:34:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 64B6D53659 for ; Sat, 30 Jun 2001 14:33:13 -0400 (EDT) Received: (qmail 10552 invoked by uid 3269); 30 Jun 2001 18:33:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10549 invoked from network); 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5UIWih02656; Sat, 30 Jun 2001 11:32:44 -0700 (PDT) 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 f5UIWeg14708; Sat, 30 Jun 2001 11:32:40 -0700 (PDT) Received: from cisco.com (IDENT:bew@jsales-dsl3.cisco.com [10.19.18.52]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA21143; Sat, 30 Jun 2001 11:32:39 -0700 (PDT) Message-ID: <3B3E1B46.711094C7@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: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Comments on draft-ietf-msec-gkmarch-00.txt References: <4.3.2.7.2.20010629162159.04298ef8@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: Sat, 30 Jun 2001 11:32:38 -0700 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > >2. From section 3.2: > > > The Re-key message is optional because all keys, KEK and TEKs, > > > can be delivered by the Registration Protocol exchanges shown in > > > Figure 1. > > > >Two comments: > >a. If there is no Re-key, then a KEK is not necessary. > > We should remove "KEK" from the sentence you cite in 3.2. > > >b. This should also state the obvious, which is the Re-key message is > >optional because rekey may be necessary in some scenarios. > > "optional because rekey may be necessary" does not make sense to me. Sorry, I should have had a comma between "optional" and "because". My point was really that rekey is optional, and if there is no rekey there is no need for a KEK because you won't be sending any more keying data. > >I suggest the following re-written sentence: "The Re-key message is > >optional because the keys can be delivered by the Registration Protocol > >exchanges shown in Figure 1, and those keys may not require updating." > > Why not substitute "TEK" for "key" in your re-written sentence? That would be fine too. Thanks, Brian > Mark > > >Brian > > > >-- > >Brian Weis > >Strategic Cryptographic Development, ITD, Cisco Systems > >Telephone: +1 408 526 4796 > >Email: bew@cisco.com > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Jul 1 23:55:12 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18326 for ; Sun, 1 Jul 2001 23:55:07 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 13CFC5365B; Sat, 30 Jun 2001 14:34:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 64B6D53659 for ; Sat, 30 Jun 2001 14:33:13 -0400 (EDT) Received: (qmail 10552 invoked by uid 3269); 30 Jun 2001 18:33:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10549 invoked from network); 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5UIWih02656; Sat, 30 Jun 2001 11:32:44 -0700 (PDT) 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 f5UIWeg14708; Sat, 30 Jun 2001 11:32:40 -0700 (PDT) Received: from cisco.com (IDENT:bew@jsales-dsl3.cisco.com [10.19.18.52]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA21143; Sat, 30 Jun 2001 11:32:39 -0700 (PDT) Message-ID: <3B3E1B46.711094C7@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: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Comments on draft-ietf-msec-gkmarch-00.txt References: <4.3.2.7.2.20010629162159.04298ef8@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: Sat, 30 Jun 2001 11:32:38 -0700 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > >2. From section 3.2: > > > The Re-key message is optional because all keys, KEK and TEKs, > > > can be delivered by the Registration Protocol exchanges shown in > > > Figure 1. > > > >Two comments: > >a. If there is no Re-key, then a KEK is not necessary. > > We should remove "KEK" from the sentence you cite in 3.2. > > >b. This should also state the obvious, which is the Re-key message is > >optional because rekey may be necessary in some scenarios. > > "optional because rekey may be necessary" does not make sense to me. Sorry, I should have had a comma between "optional" and "because". My point was really that rekey is optional, and if there is no rekey there is no need for a KEK because you won't be sending any more keying data. > >I suggest the following re-written sentence: "The Re-key message is > >optional because the keys can be delivered by the Registration Protocol > >exchanges shown in Figure 1, and those keys may not require updating." > > Why not substitute "TEK" for "key" in your re-written sentence? That would be fine too. Thanks, Brian > Mark > > >Brian > > > >-- > >Brian Weis > >Strategic Cryptographic Development, ITD, Cisco Systems > >Telephone: +1 408 526 4796 > >Email: bew@cisco.com > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jul 2 01:18:28 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA19765 for ; Mon, 2 Jul 2001 01:18:27 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 13CFC5365B; Sat, 30 Jun 2001 14:34:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 64B6D53659 for ; Sat, 30 Jun 2001 14:33:13 -0400 (EDT) Received: (qmail 10552 invoked by uid 3269); 30 Jun 2001 18:33:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10549 invoked from network); 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5UIWih02656; Sat, 30 Jun 2001 11:32:44 -0700 (PDT) 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 f5UIWeg14708; Sat, 30 Jun 2001 11:32:40 -0700 (PDT) Received: from cisco.com (IDENT:bew@jsales-dsl3.cisco.com [10.19.18.52]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA21143; Sat, 30 Jun 2001 11:32:39 -0700 (PDT) Message-ID: <3B3E1B46.711094C7@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: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Comments on draft-ietf-msec-gkmarch-00.txt References: <4.3.2.7.2.20010629162159.04298ef8@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: Sat, 30 Jun 2001 11:32:38 -0700 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > >2. From section 3.2: > > > The Re-key message is optional because all keys, KEK and TEKs, > > > can be delivered by the Registration Protocol exchanges shown in > > > Figure 1. > > > >Two comments: > >a. If there is no Re-key, then a KEK is not necessary. > > We should remove "KEK" from the sentence you cite in 3.2. > > >b. This should also state the obvious, which is the Re-key message is > >optional because rekey may be necessary in some scenarios. > > "optional because rekey may be necessary" does not make sense to me. Sorry, I should have had a comma between "optional" and "because". My point was really that rekey is optional, and if there is no rekey there is no need for a KEK because you won't be sending any more keying data. > >I suggest the following re-written sentence: "The Re-key message is > >optional because the keys can be delivered by the Registration Protocol > >exchanges shown in Figure 1, and those keys may not require updating." > > Why not substitute "TEK" for "key" in your re-written sentence? That would be fine too. Thanks, Brian > Mark > > >Brian > > > >-- > >Brian Weis > >Strategic Cryptographic Development, ITD, Cisco Systems > >Telephone: +1 408 526 4796 > >Email: bew@cisco.com > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jul 2 02:42:11 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02768 for ; Mon, 2 Jul 2001 02:42:10 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 13CFC5365B; Sat, 30 Jun 2001 14:34:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 64B6D53659 for ; Sat, 30 Jun 2001 14:33:13 -0400 (EDT) Received: (qmail 10552 invoked by uid 3269); 30 Jun 2001 18:33:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10549 invoked from network); 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5UIWih02656; Sat, 30 Jun 2001 11:32:44 -0700 (PDT) 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 f5UIWeg14708; Sat, 30 Jun 2001 11:32:40 -0700 (PDT) Received: from cisco.com (IDENT:bew@jsales-dsl3.cisco.com [10.19.18.52]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA21143; Sat, 30 Jun 2001 11:32:39 -0700 (PDT) Message-ID: <3B3E1B46.711094C7@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: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Comments on draft-ietf-msec-gkmarch-00.txt References: <4.3.2.7.2.20010629162159.04298ef8@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: Sat, 30 Jun 2001 11:32:38 -0700 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > >2. From section 3.2: > > > The Re-key message is optional because all keys, KEK and TEKs, > > > can be delivered by the Registration Protocol exchanges shown in > > > Figure 1. > > > >Two comments: > >a. If there is no Re-key, then a KEK is not necessary. > > We should remove "KEK" from the sentence you cite in 3.2. > > >b. This should also state the obvious, which is the Re-key message is > >optional because rekey may be necessary in some scenarios. > > "optional because rekey may be necessary" does not make sense to me. Sorry, I should have had a comma between "optional" and "because". My point was really that rekey is optional, and if there is no rekey there is no need for a KEK because you won't be sending any more keying data. > >I suggest the following re-written sentence: "The Re-key message is > >optional because the keys can be delivered by the Registration Protocol > >exchanges shown in Figure 1, and those keys may not require updating." > > Why not substitute "TEK" for "key" in your re-written sentence? That would be fine too. Thanks, Brian > Mark > > >Brian > > > >-- > >Brian Weis > >Strategic Cryptographic Development, ITD, Cisco Systems > >Telephone: +1 408 526 4796 > >Email: bew@cisco.com > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jul 2 04:05:17 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04783 for ; Mon, 2 Jul 2001 04:05:17 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 13CFC5365B; Sat, 30 Jun 2001 14:34:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 64B6D53659 for ; Sat, 30 Jun 2001 14:33:13 -0400 (EDT) Received: (qmail 10552 invoked by uid 3269); 30 Jun 2001 18:33:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10549 invoked from network); 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5UIWih02656; Sat, 30 Jun 2001 11:32:44 -0700 (PDT) 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 f5UIWeg14708; Sat, 30 Jun 2001 11:32:40 -0700 (PDT) Received: from cisco.com (IDENT:bew@jsales-dsl3.cisco.com [10.19.18.52]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA21143; Sat, 30 Jun 2001 11:32:39 -0700 (PDT) Message-ID: <3B3E1B46.711094C7@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: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Comments on draft-ietf-msec-gkmarch-00.txt References: <4.3.2.7.2.20010629162159.04298ef8@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: Sat, 30 Jun 2001 11:32:38 -0700 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > >2. From section 3.2: > > > The Re-key message is optional because all keys, KEK and TEKs, > > > can be delivered by the Registration Protocol exchanges shown in > > > Figure 1. > > > >Two comments: > >a. If there is no Re-key, then a KEK is not necessary. > > We should remove "KEK" from the sentence you cite in 3.2. > > >b. This should also state the obvious, which is the Re-key message is > >optional because rekey may be necessary in some scenarios. > > "optional because rekey may be necessary" does not make sense to me. Sorry, I should have had a comma between "optional" and "because". My point was really that rekey is optional, and if there is no rekey there is no need for a KEK because you won't be sending any more keying data. > >I suggest the following re-written sentence: "The Re-key message is > >optional because the keys can be delivered by the Registration Protocol > >exchanges shown in Figure 1, and those keys may not require updating." > > Why not substitute "TEK" for "key" in your re-written sentence? That would be fine too. Thanks, Brian > Mark > > >Brian > > > >-- > >Brian Weis > >Strategic Cryptographic Development, ITD, Cisco Systems > >Telephone: +1 408 526 4796 > >Email: bew@cisco.com > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jul 2 05:28:24 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05336 for ; Mon, 2 Jul 2001 05:28:23 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 13CFC5365B; Sat, 30 Jun 2001 14:34:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 64B6D53659 for ; Sat, 30 Jun 2001 14:33:13 -0400 (EDT) Received: (qmail 10552 invoked by uid 3269); 30 Jun 2001 18:33:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10549 invoked from network); 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5UIWih02656; Sat, 30 Jun 2001 11:32:44 -0700 (PDT) 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 f5UIWeg14708; Sat, 30 Jun 2001 11:32:40 -0700 (PDT) Received: from cisco.com (IDENT:bew@jsales-dsl3.cisco.com [10.19.18.52]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA21143; Sat, 30 Jun 2001 11:32:39 -0700 (PDT) Message-ID: <3B3E1B46.711094C7@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: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Comments on draft-ietf-msec-gkmarch-00.txt References: <4.3.2.7.2.20010629162159.04298ef8@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: Sat, 30 Jun 2001 11:32:38 -0700 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > >2. From section 3.2: > > > The Re-key message is optional because all keys, KEK and TEKs, > > > can be delivered by the Registration Protocol exchanges shown in > > > Figure 1. > > > >Two comments: > >a. If there is no Re-key, then a KEK is not necessary. > > We should remove "KEK" from the sentence you cite in 3.2. > > >b. This should also state the obvious, which is the Re-key message is > >optional because rekey may be necessary in some scenarios. > > "optional because rekey may be necessary" does not make sense to me. Sorry, I should have had a comma between "optional" and "because". My point was really that rekey is optional, and if there is no rekey there is no need for a KEK because you won't be sending any more keying data. > >I suggest the following re-written sentence: "The Re-key message is > >optional because the keys can be delivered by the Registration Protocol > >exchanges shown in Figure 1, and those keys may not require updating." > > Why not substitute "TEK" for "key" in your re-written sentence? That would be fine too. Thanks, Brian > Mark > > >Brian > > > >-- > >Brian Weis > >Strategic Cryptographic Development, ITD, Cisco Systems > >Telephone: +1 408 526 4796 > >Email: bew@cisco.com > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jul 2 06:18:14 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05727 for ; Mon, 2 Jul 2001 06:18:12 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 39122537AF; Mon, 2 Jul 2001 06:18:24 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id F096D5378C for ; Mon, 2 Jul 2001 06:17:57 -0400 (EDT) Received: (qmail 65202 invoked by uid 3269); 2 Jul 2001 10:17:57 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 65199 invoked from network); 2 Jul 2001 10:17:57 -0000 Received: from news.comp.lancs.ac.uk (148.88.152.70) by klesh.pair.com with SMTP; 2 Jul 2001 10:17:57 -0000 Received: from rafaeli (dyn509.dhcp.lancs.ac.uk [148.88.245.9]) by news.comp.lancs.ac.uk (8.11.0/8.11.0) with SMTP id f62AHp019682; Mon, 2 Jul 2001 11:17:51 +0100 (BST) From: "Sandro Rafaeli" To: "'Ran Canetti'" , Cc: Subject: RE: [MSEC] De-registration protocol? Message-ID: <000001c102e0$2ea6d5a0$09f55894@lancs.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200107012309.TAA34422@ornavella.watson.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 2 Jul 2001 11:17:20 +0100 Content-Transfer-Encoding: 7bit Ran, Applications are prone to crash when you least expect :(. When that occurs, paying members may pay much more then they are supposed to for the simple reason that the de-registration/leave command was never issued. De-registration/leave command is not enough to control the time a member is participating in the group... Sandro. | BTW, Mark, in a model where a member pays acording to the | time elapsed | between registration and de-registration, the | de-registration mechanism | is not just for being nice. And this is true regardless of how these | protocols are called... _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jul 2 06:51:46 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05944 for ; Mon, 2 Jul 2001 06:51:45 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 13CFC5365B; Sat, 30 Jun 2001 14:34:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 64B6D53659 for ; Sat, 30 Jun 2001 14:33:13 -0400 (EDT) Received: (qmail 10552 invoked by uid 3269); 30 Jun 2001 18:33:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10549 invoked from network); 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5UIWih02656; Sat, 30 Jun 2001 11:32:44 -0700 (PDT) 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 f5UIWeg14708; Sat, 30 Jun 2001 11:32:40 -0700 (PDT) Received: from cisco.com (IDENT:bew@jsales-dsl3.cisco.com [10.19.18.52]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA21143; Sat, 30 Jun 2001 11:32:39 -0700 (PDT) Message-ID: <3B3E1B46.711094C7@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: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Comments on draft-ietf-msec-gkmarch-00.txt References: <4.3.2.7.2.20010629162159.04298ef8@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: Sat, 30 Jun 2001 11:32:38 -0700 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > >2. From section 3.2: > > > The Re-key message is optional because all keys, KEK and TEKs, > > > can be delivered by the Registration Protocol exchanges shown in > > > Figure 1. > > > >Two comments: > >a. If there is no Re-key, then a KEK is not necessary. > > We should remove "KEK" from the sentence you cite in 3.2. > > >b. This should also state the obvious, which is the Re-key message is > >optional because rekey may be necessary in some scenarios. > > "optional because rekey may be necessary" does not make sense to me. Sorry, I should have had a comma between "optional" and "because". My point was really that rekey is optional, and if there is no rekey there is no need for a KEK because you won't be sending any more keying data. > >I suggest the following re-written sentence: "The Re-key message is > >optional because the keys can be delivered by the Registration Protocol > >exchanges shown in Figure 1, and those keys may not require updating." > > Why not substitute "TEK" for "key" in your re-written sentence? That would be fine too. Thanks, Brian > Mark > > >Brian > > > >-- > >Brian Weis > >Strategic Cryptographic Development, ITD, Cisco Systems > >Telephone: +1 408 526 4796 > >Email: bew@cisco.com > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jul 2 08:15:07 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06830 for ; Mon, 2 Jul 2001 08:15:07 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 13CFC5365B; Sat, 30 Jun 2001 14:34:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 64B6D53659 for ; Sat, 30 Jun 2001 14:33:13 -0400 (EDT) Received: (qmail 10552 invoked by uid 3269); 30 Jun 2001 18:33:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10549 invoked from network); 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5UIWih02656; Sat, 30 Jun 2001 11:32:44 -0700 (PDT) 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 f5UIWeg14708; Sat, 30 Jun 2001 11:32:40 -0700 (PDT) Received: from cisco.com (IDENT:bew@jsales-dsl3.cisco.com [10.19.18.52]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA21143; Sat, 30 Jun 2001 11:32:39 -0700 (PDT) Message-ID: <3B3E1B46.711094C7@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: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Comments on draft-ietf-msec-gkmarch-00.txt References: <4.3.2.7.2.20010629162159.04298ef8@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: Sat, 30 Jun 2001 11:32:38 -0700 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > >2. From section 3.2: > > > The Re-key message is optional because all keys, KEK and TEKs, > > > can be delivered by the Registration Protocol exchanges shown in > > > Figure 1. > > > >Two comments: > >a. If there is no Re-key, then a KEK is not necessary. > > We should remove "KEK" from the sentence you cite in 3.2. > > >b. This should also state the obvious, which is the Re-key message is > >optional because rekey may be necessary in some scenarios. > > "optional because rekey may be necessary" does not make sense to me. Sorry, I should have had a comma between "optional" and "because". My point was really that rekey is optional, and if there is no rekey there is no need for a KEK because you won't be sending any more keying data. > >I suggest the following re-written sentence: "The Re-key message is > >optional because the keys can be delivered by the Registration Protocol > >exchanges shown in Figure 1, and those keys may not require updating." > > Why not substitute "TEK" for "key" in your re-written sentence? That would be fine too. Thanks, Brian > Mark > > >Brian > > > >-- > >Brian Weis > >Strategic Cryptographic Development, ITD, Cisco Systems > >Telephone: +1 408 526 4796 > >Email: bew@cisco.com > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jul 2 09:38:24 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08652 for ; Mon, 2 Jul 2001 09:38:23 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 13CFC5365B; Sat, 30 Jun 2001 14:34:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 64B6D53659 for ; Sat, 30 Jun 2001 14:33:13 -0400 (EDT) Received: (qmail 10552 invoked by uid 3269); 30 Jun 2001 18:33:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10549 invoked from network); 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5UIWih02656; Sat, 30 Jun 2001 11:32:44 -0700 (PDT) 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 f5UIWeg14708; Sat, 30 Jun 2001 11:32:40 -0700 (PDT) Received: from cisco.com (IDENT:bew@jsales-dsl3.cisco.com [10.19.18.52]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA21143; Sat, 30 Jun 2001 11:32:39 -0700 (PDT) Message-ID: <3B3E1B46.711094C7@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: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Comments on draft-ietf-msec-gkmarch-00.txt References: <4.3.2.7.2.20010629162159.04298ef8@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: Sat, 30 Jun 2001 11:32:38 -0700 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > >2. From section 3.2: > > > The Re-key message is optional because all keys, KEK and TEKs, > > > can be delivered by the Registration Protocol exchanges shown in > > > Figure 1. > > > >Two comments: > >a. If there is no Re-key, then a KEK is not necessary. > > We should remove "KEK" from the sentence you cite in 3.2. > > >b. This should also state the obvious, which is the Re-key message is > >optional because rekey may be necessary in some scenarios. > > "optional because rekey may be necessary" does not make sense to me. Sorry, I should have had a comma between "optional" and "because". My point was really that rekey is optional, and if there is no rekey there is no need for a KEK because you won't be sending any more keying data. > >I suggest the following re-written sentence: "The Re-key message is > >optional because the keys can be delivered by the Registration Protocol > >exchanges shown in Figure 1, and those keys may not require updating." > > Why not substitute "TEK" for "key" in your re-written sentence? That would be fine too. Thanks, Brian > Mark > > >Brian > > > >-- > >Brian Weis > >Strategic Cryptographic Development, ITD, Cisco Systems > >Telephone: +1 408 526 4796 > >Email: bew@cisco.com > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jul 2 10:50:01 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05434 for ; Mon, 2 Jul 2001 10:50:00 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 13CFC5365B; Sat, 30 Jun 2001 14:34:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 64B6D53659 for ; Sat, 30 Jun 2001 14:33:13 -0400 (EDT) Received: (qmail 10552 invoked by uid 3269); 30 Jun 2001 18:33:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10549 invoked from network); 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 30 Jun 2001 18:33:11 -0000 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5UIWih02656; Sat, 30 Jun 2001 11:32:44 -0700 (PDT) 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 f5UIWeg14708; Sat, 30 Jun 2001 11:32:40 -0700 (PDT) Received: from cisco.com (IDENT:bew@jsales-dsl3.cisco.com [10.19.18.52]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA21143; Sat, 30 Jun 2001 11:32:39 -0700 (PDT) Message-ID: <3B3E1B46.711094C7@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: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Comments on draft-ietf-msec-gkmarch-00.txt References: <4.3.2.7.2.20010629162159.04298ef8@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: Sat, 30 Jun 2001 11:32:38 -0700 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > >2. From section 3.2: > > > The Re-key message is optional because all keys, KEK and TEKs, > > > can be delivered by the Registration Protocol exchanges shown in > > > Figure 1. > > > >Two comments: > >a. If there is no Re-key, then a KEK is not necessary. > > We should remove "KEK" from the sentence you cite in 3.2. > > >b. This should also state the obvious, which is the Re-key message is > >optional because rekey may be necessary in some scenarios. > > "optional because rekey may be necessary" does not make sense to me. Sorry, I should have had a comma between "optional" and "because". My point was really that rekey is optional, and if there is no rekey there is no need for a KEK because you won't be sending any more keying data. > >I suggest the following re-written sentence: "The Re-key message is > >optional because the keys can be delivered by the Registration Protocol > >exchanges shown in Figure 1, and those keys may not require updating." > > Why not substitute "TEK" for "key" in your re-written sentence? That would be fine too. Thanks, Brian > Mark > > >Brian > > > >-- > >Brian Weis > >Strategic Cryptographic Development, ITD, Cisco Systems > >Telephone: +1 408 526 4796 > >Email: bew@cisco.com > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jul 2 11:56:53 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23057 for ; Mon, 2 Jul 2001 11:56:52 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 3392953542; Mon, 2 Jul 2001 11:57:01 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 448BF5352A for ; Mon, 2 Jul 2001 11:03:23 -0400 (EDT) Received: (qmail 96400 invoked by uid 3269); 2 Jul 2001 15:03:22 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 96397 invoked from network); 2 Jul 2001 15:03:22 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by klesh.pair.com with SMTP; 2 Jul 2001 15:03:22 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f62F00H13994; Mon, 2 Jul 2001 08:01:05 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-tmp185.cisco.com [10.21.64.185]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADQ01024; Mon, 2 Jul 2001 08:01:38 -0700 (PDT) Message-Id: <4.3.2.7.2.20010702074604.0203fb70@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Ran Canetti From: Mark Baugher Subject: RE: [MSEC] De-registration protocol? Cc: msec@securemulticast.org In-Reply-To: <200107012309.TAA34422@ornavella.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 02 Jul 2001 08:01:07 -0700 Hi Ran the model I have in my head of a group key management protocol is a protocol that operates on security association databases of the communicating endpoints: The group key management protocol causes SAs to be created, modified, and deleted. If a protocol is added that does not do any of these things, then it does not look like a "better and cleaner" design to me at all. It looks muddled to me. In the case of de-registration without an LKH tree, it looks like there is an expensive operation that has no point at all. Your example of using the key management protocol to measure the time that someone is in the group underwhelms me because this function surely would be provided by the authorization application that is telling key management what to do and not do. That is, the member will tell the authorization app that it is leaving the group and the authorization app will tell key management to re-key the group. Similarly, if the member does not report anything but is discovered to be a spy or a deadbeat, the authorization system will tell key management to re-key the group to remove the particular member. There is no need to put the de-register function into group key management. Your example is a rather specific and detailed electronic commerce example - a pay-per-time example. Keep in mind the kind of abstractions that we work with in key management. We have a 32-bit group identifier, or a network address, or email address, but nothing that could describe a subscription group called "Friday Night Fights" which has an option where you can pay for the time watched of a particular fight. It is clear in your example that there is a commerce application that is mapping key management constructs to something much more complicated. This is where the time measurement belongs, not in the lower-layer services like key management. Mark At 07:09 PM 7/1/2001 -0400, Ran Canetti wrote: >Thomas, Mark, > >I think you misunderstand my intention regarding the de-registration protocol. >So let me try to clarify. The de-registration protocol is a tool that allows >the leaving member to securely notify the GCKS that it has left the group. >There is no mechanism that forces the GCKS to rekey the group immediately >or at any other time. This is up to the GCKS to decide, and is not up to >us for standardization. (True, the design we have in mind would call for >the GCKS to remove the member from the group in the next rekeying message. >But this is again up to the GCKS.) > >My reason for making the de-registration protocol an (optional) part of the >msec suite is to provide the application with a complete and uniform >interface >of secure group operations. This looks cleaner and better design to me than >forcing the application to take care of securing leave operations by itself. > >In all, I see two options: > >1. We believe that having members sign up only for preset periods >of time is sufficient for now. In this case we can indeed leave >de-registration for later. However, as Sandro noted, in this case there >is much less need in the rekeying mechanism in the first place. Instead we >can use the MARKS mechanism (or simply choose keys for preset periods of >time) and avoid the rekeying messages altogether. > >2. We decide that we need to provide the group controller with the ability >to let members sign up for an unspecified time and then be charge them >according to the actual amount of time used. In this case it is clear that >secure de-registration is necessary. Here I strongly believe that we need to >provide this functionality within msec. > > >Ran > > >BTW, Mark, in a model where a member pays acording to the time elapsed >between registration and de-registration, the de-registration mechanism >is not just for being nice. And this is true regardless of how these >protocols are called... > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jul 2 12:00:58 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25756 for ; Mon, 2 Jul 2001 12:00:56 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 76B0A5353C; Mon, 2 Jul 2001 11:58:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 9FA6753543 for ; Mon, 2 Jul 2001 11:56:17 -0400 (EDT) Received: (qmail 6969 invoked by uid 3269); 2 Jul 2001 15:56:17 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 6965 invoked from network); 2 Jul 2001 15:56:15 -0000 Received: from softdnserror (HELO M5.sparta.com) (root@157.185.61.1) by klesh.pair.com with SMTP; 2 Jul 2001 15:56:15 -0000 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by M5.sparta.com (8.11.0/8.11.0) with ESMTP id f62Fu6x17274; Mon, 2 Jul 2001 10:56:07 -0500 Received: from robin (robin.columbia.sparta.com [157.185.80.228]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id LAA24709; Mon, 2 Jul 2001 11:56:01 -0400 (EDT) Message-Id: <4.2.2.20010702112018.00b31ec0@pop.columbia.sparta.com> X-Sender: hh@pop.columbia.sparta.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 To: Mark Baugher From: Hugh Harney Subject: Re: [MSEC] msec architecture draft and email flow Cc: msec@securemulticast.org In-Reply-To: <4.3.2.7.2.20010702080351.04175c60@mira-sjc5-6.cisco.com> References: <4.2.2.20010702081652.00b39410@pop.columbia.sparta.com> <4.3.2.7.2.20010630011412.041eb718@mira-sjc5-6.cisco.com> <4.2.2.20010628143506.00b31dc0@pop.columbia.sparta.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 02 Jul 2001 11:40:36 -0400 Mark, >>>>GDOI assumes that at least the following group-policy information is >>>>externally managed. >>>> o Group owner, authentication method, and delegation method >>>> for identifying a GCKS for the group >>>> o Group GCKS, authentication method, and any method used for >>>> delegating another GCKS for the group >>>> o Group membership rules or list and authentication method >>>> >>>>There is a team of individuals who are working on group policy within >>>>MSEC. This team may develop alternative group policy models that will >>>>necessitate update to the way group policy is referenced in GDOI. For >>>>example, the current GDOI draft assumes the existence of a group owner >>>>or owners who delegate key-distribution authority to a GCKS, which >>>>validates a member's credentials before adding a member to a particular >>>>group. Alternative group policy models might require changes to GDOI >>>>payloads, exchanges, or processing. >>>> >>> >>>Which items in the three bullets might belong in key management? >> >>Bullet one is ok outside. > >I always wondered why this would not be mandatory to be outside: The >Group Owner tells you which KDC/GCKS to trust. Would you go to the >KDC/GCKS and ask "who is the Group Owner that tells me to trust you?" Just as the root certificate is self signed, there has to be a core to start the trust. The group owner is that core. I think Carl's idea of passing out your business card with your fingerprint on the back is a good idea. If the group owner is someone you know and they give you their card, then they can be an owner of a group (in a reasonable domain) and you can verify it is them. People get involved somewhere. >>Bullet two is critical for a joining member to trust the key. It should >>be inside. This is an extension of the explicitness principle. If you are >>using an attribute certificate (or delegation cert) then this is passed >>via an LDAP or certificate payload. In either case the KM protocol needs >>to review that certificate and determine the GCKS is authorized. It is >>still part of the KM protocol. > >By virtue of the fact that a member is contacting a KDC/GCKS, it seems >that we have resolved the question of who the KDC/GCKS is. What am I >missing? How would this identification of policy take place within key >management? Anyone can reply to a join/registration request. We need to know that whomever replies is authorized to handout key for the group. It is critical to the acceptance of the key to know that the GC/KS is authorized to hand out the key. This is something that has to be enforced by the joining member. The decision has to be based on some security policy (singed by the GO) that the member has received. Yes, we can use attribute/delegation certificates, but the member must enforce the authorization policy before it can trust the key. This is different from IKE or pairwise key management protocols. Peer protocols are talking to the entity they will be using the key with. They directly exchange signed certificates with the other side. The verirfication of the certificate implies authorization to create key for that party. The know who they are talking to. In groups we are accepting a key download on behalf of an abstract GSA. >>Bullet 3 is critical only if the group members are going to be adding >>data to the group. The data contributors must be able to review the >>access control criteria to determine if their data is protected by that >>criteria. > >Would you see this as being necessarily inside of the key management >protocol? It might be useful to list the policy items that are inside GSAKMP. For multi source groups it is essential to be in the KM protocol. This again relates to the abstract nature of the group. I'm accepting a key from an authorized source. That key is to be used to protect my data. Without the inclusion of this security policy information, all I know is that I'm authorized to have the key to this group. What I need (as a data sharing member) is knowledge of how much other members may be trusted. If they have the key they have access to my data. The example I use is my bank asking me to share my SSN via a group key. I trust the bank, I trust myself, but I don't know who they gave the key to. If they tell me that the key is held by the bank, the IRS, and myself I'll send my SSN. If they tell me the key is held by all customers of the bank I'd balk. The access control rules have to be disclosed to any member risking personal data on that key. Again, If I'm just listening passively no problem (then I wouldn't need to know the access rules). >>Hey we may agree soon. Then where will the fun be? > >In making progress. We would make a lot of progress if we could merge >GSAKMP and GDOI into one protocol. Mark this was a joke. Yes convergence of GDOI and GSAKMP would be great. Hugh ________________________________________________________ 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 Mon Jul 2 12:17:28 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06654 for ; Mon, 2 Jul 2001 12:17:28 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8E4E653542; Mon, 2 Jul 2001 12:17:41 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id B5EDB5352F for ; Mon, 2 Jul 2001 11:20:52 -0400 (EDT) Received: (qmail 98373 invoked by uid 3269); 2 Jul 2001 15:20:52 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 98370 invoked from network); 2 Jul 2001 15:20:51 -0000 Received: from softdnserror (HELO sj-msg-core-4.cisco.com) (171.71.163.10) by klesh.pair.com with SMTP; 2 Jul 2001 15:20:51 -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.11.3/8.9.1) with ESMTP id f62FKRr01089; Mon, 2 Jul 2001 08:20:27 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-tmp185.cisco.com [10.21.64.185]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADQ01290; Mon, 2 Jul 2001 08:20:19 -0700 (PDT) Message-Id: <4.3.2.7.2.20010702080351.04175c60@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Hugh Harney From: Mark Baugher Subject: Re: [MSEC] msec architecture draft and email flow Cc: msec@securemulticast.org In-Reply-To: <4.2.2.20010702081652.00b39410@pop.columbia.sparta.com> References: <4.3.2.7.2.20010630011412.041eb718@mira-sjc5-6.cisco.com> <4.2.2.20010628143506.00b31dc0@pop.columbia.sparta.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 02 Jul 2001 08:19:48 -0700 Hi Hugh, I think it's useful to identify the policy that must be in key management from what may be in key management. Finally, there are some things that won't or should not be in key management. At 08:52 AM 7/2/2001 -0400, Hugh Harney wrote: >Mark, > > > >>> >>>A security policy repository having some access protocol may need to be >>>queried prior to key-management session establishment to determine what >>>the initial cryptographic policies are for that establishment. GDOI >>>assumes the existence of such a repository and protocol for GCKS and >>>member policy queries. Thus GDOI requires that group-security policy be >>>represented in a policy repository and accessible using a policy protocol. >>> >>>GDOI assumes that at least the following group-policy information is >>>externally managed. >>> o Group owner, authentication method, and delegation method for >>> identifying a GCKS for the group >>> o Group GCKS, authentication method, and any method used for >>> delegating another GCKS for the group >>> o Group membership rules or list and authentication method >>> >>>There is a team of individuals who are working on group policy within >>>MSEC. This team may develop alternative group policy models that will >>>necessitate update to the way group policy is referenced in GDOI. For >>>example, the current GDOI draft assumes the existence of a group owner >>>or owners who delegate key-distribution authority to a GCKS, which >>>validates a member's credentials before adding a member to a particular >>>group. Alternative group policy models might require changes to GDOI >>>payloads, exchanges, or processing. >>> >> >>Which items in the three bullets might belong in key management? > >Bullet one is ok outside. I always wondered why this would not be mandatory to be outside: The Group Owner tells you which KDC/GCKS to trust. Would you go to the KDC/GCKS and ask "who is the Group Owner that tells me to trust you?" >Bullet two is critical for a joining member to trust the key. It should be >inside. This is an extension of the explicitness principle. If you are >using an attribute certificate (or delegation cert) then this is passed >via an LDAP or certificate payload. In either case the KM protocol needs >to review that certificate and determine the GCKS is authorized. It is >still part of the KM protocol. By virtue of the fact that a member is contacting a KDC/GCKS, it seems that we have resolved the question of who the KDC/GCKS is. What am I missing? How would this identification of policy take place within key management? >Bullet 3 is critical only if the group members are going to be adding data >to the group. The data contributors must be able to review the access >control criteria to determine if their data is protected by that criteria. Would you see this as being necessarily inside of the key management protocol? It might be useful to list the policy items that are inside GSAKMP. >Hey we may agree soon. Then where will the fun be? In making progress. We would make a lot of progress if we could merge GSAKMP and GDOI into one protocol. thanks, Mark >Hugh > > >________________________________________________________ >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 Mon Jul 2 15:46:29 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21726 for ; Mon, 2 Jul 2001 15:46:28 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1317A53548; Mon, 2 Jul 2001 15:46:32 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id CF3EF53545 for ; Mon, 2 Jul 2001 15:44:45 -0400 (EDT) Received: (qmail 35200 invoked by uid 3269); 2 Jul 2001 19:44:45 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 35197 invoked from network); 2 Jul 2001 19:44:45 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by klesh.pair.com with SMTP; 2 Jul 2001 19:44:45 -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.11.3/8.9.1) with ESMTP id f62JiLr04857; Mon, 2 Jul 2001 12:44:21 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-tmp185.cisco.com [10.21.64.185]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADT05552; Mon, 2 Jul 2001 12:44:11 -0700 (PDT) Message-Id: <4.3.2.7.2.20010702115525.0421ec58@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Hugh Harney From: Mark Baugher Subject: Re: [MSEC] msec architecture draft and email flow Cc: msec@securemulticast.org In-Reply-To: <4.2.2.20010702081652.00b39410@pop.columbia.sparta.com> References: <4.3.2.7.2.20010630011412.041eb718@mira-sjc5-6.cisco.com> <4.2.2.20010628143506.00b31dc0@pop.columbia.sparta.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 02 Jul 2001 12:43:40 -0700 Hugh, I'd like it if you would copy msec@securemulticast.org on your responses. That way, others can contribute, correct and learn from the exchange; we'll also have an archive so we don't have to re-discuss these issues in six or nine months, when hopefully we are finalizing standards for secure multicast. At 08:52 AM 7/2/2001 -0400, Hugh Harney wrote: >Mark, > > > >>what if GSAKMP did not incorporate "policy definition and dissemination >>mechanisms?" How would this lead to a reduction in GSAKMP protocol complexity? > >Actually, it would only increases the complexity of one messages by one >payload. Most of the complexity was introduced by the assumption that the >security infrastructure is totally unknown and needs to be discovered. There has been practically no discussion on this list of GSAKMP and little on GDOI. So it's good to examine this difference between the protocols. Is the measure of complexity simply messages and payloads? When you add a new payload, you often need to understand and process the payload in key management. One exception is for data security SAs where key management can simply pass parameters (viz. Appendices in http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-00.txt). But for Cat-1 and Cat-2 SAs ("registration" and re-key SAs, respectively), key management parses and acts on the "one payload" in "one message." That's not necessarily simple. >>If we meant "THE ONLY valid key management protocol for IPsec" then why >>did we write "probably the best solution." Obviously you're reading >>quite a bit into this. > >It is a very strong statement in an overall working group document. Anyone >reading it without a background in the field would look only at GDOI for a >solution. I think both protocols have their place. Working group documents >should either make the case for both or avoid making the case for either. When I write "probably the best" I do not mean "one MUST use." I'm willing to change the offending sentences, but I think it's kinda paranoid to take offense at the sentence. It is true that GSAKMP can key IPsec AH and ESP as well as GDOI can. So it makes no sense to force GDOI on an IPsec implementation; both GSAKMP and GDOI can update the IPsec SAD. GDOI is a 3kloc (thousand lines of code) extension to IKE, however, which allows IPsec to continue to use the same key management protocol implementation, namely IKE running the Group Domain of Interpretation in addition to the Internet Domain of Interpretation. What GDOI can't do, alas, is run over IPsec or TLS/SSL. GSAKMP does that. We have a division of labor between the two group key management protocols. If GSAKMP would adopt an ISAKMP header, we could merge them. >>>nd important work. In fact, I believe policy is critical for MSEC to >>>specify. > >I think MSEC will at least start defining those things that are important >to group policy. The work may be taken up and expanded elsewhere, but the >group building secure groups should state the requirements for the policy >to support those groups. > >Simply stated, my opinion is that a key management protocol that does not >address policy enforcement is not providing security. Keys are only useful >if they represent a trusted enforcement of a policy. Passing mechanisms >and a random field to use as a key is meaningless, unless there is some >sort of policy enforcement. "Providing security" is too vague a term. Group key management could be used in a very secure system, such as a national security application environment. Or it could be used in places where 10% of the members are trying to break the system, such as a television application environment. Let's assume a national security application environment. What policy must key management enforce? Key algorithms, sizes, modes are one thing. It may need to enforce authorization, which means that it will do what an authorization application tells it to do: It will go to a particular KDC/GCKS to request KEKs and/or TEKs for specific groups and data security SAs within those groups when an authorization app tells it to. >Before you ask, yes I have a problem with several implementations of >IPSec. They negotiate to any common configuration without having a >mechanism to review if that configuration is adequate to protect the data. >There are policy enforcement words are in the IPSec architecture, but most >implementations make the SPD and SAD so difficult to configure that users >just make the settings generic. This is being addressed in http://www.ietf.org/html.charters/ipsp-charter.html. I don't expect that we will be incorporating new features into IKE, but I'm not following this group closely. msec policy people should be following it closely, I think. >>>The above represents a boolean expression. IF GDOI restricts it's policy >>>to cryptographic mechanisms, THEN we have to rely on an external >>>infrastructure to provide the services expressed in the second GDOI >>>quote. I believe GDOI can operate securely with this conditional boolean >>>statement. >> >>Yes, I agree with this too. I'll add that we are able to eliminate >>additional parameters and options from GDOI by making this assumption. > >I was clarifying. I'm glad you agree. I also agree that GDOI was able to >gain simplicity by making these assumptions. > > >>>This does not mean that I believe all MSec key management algorithms >>>MUST restrict themselves to only handling policy that refers to >>>cryptographic mechanisms, AND MUST therefor rely on an external policy >>>infrastructure. >> >>uh, why doesn't it? > >If you have mechanisms to pass policy then the protocol can operate with >only a simple PKI. No assumptions being made about an authorization application? Mark >>> >>>A security policy repository having some access protocol may need to be >>>queried prior to key-management session establishment to determine what >>>the initial cryptographic policies are for that establishment. GDOI >>>assumes the existence of such a repository and protocol for GCKS and >>>member policy queries. Thus GDOI requires that group-security policy be >>>represented in a policy repository and accessible using a policy protocol. >>> >>>GDOI assumes that at least the following group-policy information is >>>externally managed. >>> o Group owner, authentication method, and delegation method for >>> identifying a GCKS for the group >>> o Group GCKS, authentication method, and any method used for >>> delegating another GCKS for the group >>> o Group membership rules or list and authentication method >>> >>>There is a team of individuals who are working on group policy within >>>MSEC. This team may develop alternative group policy models that will >>>necessitate update to the way group policy is referenced in GDOI. For >>>example, the current GDOI draft assumes the existence of a group owner >>>or owners who delegate key-distribution authority to a GCKS, which >>>validates a member's credentials before adding a member to a particular >>>group. Alternative group policy models might require changes to GDOI >>>payloads, exchanges, or processing. >>> >> >>Which items in the three bullets might belong in key management? > >Bullet one is ok outside. > >Bullet two is critical for a joining member to trust the key. It should be >inside. This is an extension of the explicitness principle. If you are >using an attribute certificate (or delegation cert) then this is passed >via an LDAP or certificate payload. In either case the KM protocol needs >to review that certificate and determine the GCKS is authorized. It is >still part of the KM protocol. > >Bullet 3 is critical only if the group members are going to be adding data >to the group. The data contributors must be able to review the access >control criteria to determine if their data is protected by that criteria. > >Hey we may agree soon. Then where will the fun be? > >Hugh > > >________________________________________________________ >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 Mon Jul 2 20:34:33 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21882 for ; Mon, 2 Jul 2001 20:34:33 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id EC6A8535E1; Mon, 2 Jul 2001 20:33:25 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id A12575359E for ; Mon, 2 Jul 2001 20:31:34 -0400 (EDT) Received: (qmail 58235 invoked by uid 3269); 3 Jul 2001 00:31:34 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 58232 invoked from network); 3 Jul 2001 00:31:34 -0000 Received: from chmls05.mediaone.net (24.147.1.143) by klesh.pair.com with SMTP; 3 Jul 2001 00:31:34 -0000 Received: from THARDJONO-LAP.mediaone.net (h0010a4c49f9e.ne.mediaone.net [24.128.44.121]) by chmls05.mediaone.net (8.11.1/8.11.1) with ESMTP id f630VSx19678; Mon, 2 Jul 2001 20:31:28 -0400 (EDT) Message-Id: <5.0.0.25.2.20010702121528.0187c678@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: "Sandro Rafaeli" , From: Thomas Hardjono Subject: RE: [MSEC] De-registration protocol? In-Reply-To: <000001c10253$0ff155a0$e92150c2@lancs.ac.uk> References: <4.3.2.7.2.20010630162120.041c91e8@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 02 Jul 2001 12:17:55 -0400 At 7/1/2001||06:27 PM, Sandro Rafaeli wrote: >ps: Thomas proposed "a De-registration-KEK" to authenticate the leaving >member's de-registration command. In order to save that "extra" key, what >would the implication of using the current member's secret key (known only >by himself and KDC) for that purpose? Sandro, This was only a suggestion and illustration as to the complexity of the notion at the key management layer. If that member already shares a secret-key with the KDC, this this extra Deregister-KEK may be redundant. The real issue is not simply the key, but the SA-management surrounding that deregistration key. thomas ------ >| -----Original Message----- >| From: msec-admin@securemulticast.org >| [mailto:msec-admin@securemulticast.org]On Behalf Of Mark Baugher >| Sent: 01 July 2001 00:43 >| To: Ran Canetti >| Cc: canetti@watson.ibm.com; msec@securemulticast.org >| Subject: Re: [MSEC] De-registration protocol? >| >| >| Ran >| I have not heard any support on this list for the >| de-registration protocol >| so I would not rush to say it's a an "integral part of the >| msec protocol >| suite." It's something we're discussing, but I think the >| costs outweigh >| the benefits. >| >| First, it's use is complicated. For example, it is a >| REQUIREMENT that >| you use the de-registration protocol only if you use the >| re-key protocol. >| One might expect that if you do a register, then you might do a >| de-register, but this is a waste of resources unless it is >| possible to >| rekey some member out of the group. >| >| Someone pointed out that the name "register" is a problem since it's >| an overloaded word. It's a metaphor really that conjures up >| a lot of things >| outside the scope of key management. I think we ought to change the >| name of "register" and go back to GSAKMP or GDOI. We called the >| GDOI IKE Phase 2 the GROUPKEY-PULL exchange; GSAKMP uses >| "Group Establishment." I can't help but think the word "register" >| invites a "de-register," which is not meaningful outside of >| the context >| of re-key. >| >| Another problem with de-register is that key management should not >| be re-keying the group on a member's signal. There is an >| authorization >| application that controls the group and not the members. About all >| the de-register protocol will do is to alert the >| authorization app that >| a member claims it has left the group. >| >| There is exactly one benefit to doing de-register: For a >| KDC that has >| a LKH or some other structure to maintain group membership, a >| de-register allows a member to be nice and inform that KDC that >| it can release some memory that is currently allocated for that >| member. How much memory would that be? 128 bits plus some >| metadata I suspect. No very much at all. >| >| I think we should drop the notion of a "de-register" >| operation and take >| up the issue of members announcing that they are leaving groups in >| the re-key protocol work. If it belongs anywhere, that's where it >| belongs. It really has nothing to do with register independent of >| re-key. >| >| Mark > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jul 2 20:36:54 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23348 for ; Mon, 2 Jul 2001 20:36:52 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4F26D535E5; Mon, 2 Jul 2001 20:33:27 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 881745359E for ; Mon, 2 Jul 2001 20:31:36 -0400 (EDT) Received: (qmail 58241 invoked by uid 3269); 3 Jul 2001 00:31:36 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 58238 invoked from network); 3 Jul 2001 00:31:36 -0000 Received: from chmls05.mediaone.net (24.147.1.143) by klesh.pair.com with SMTP; 3 Jul 2001 00:31:36 -0000 Received: from THARDJONO-LAP.mediaone.net (h0010a4c49f9e.ne.mediaone.net [24.128.44.121]) by chmls05.mediaone.net (8.11.1/8.11.1) with ESMTP id f630VTx19688; Mon, 2 Jul 2001 20:31:29 -0400 (EDT) Message-Id: <5.0.0.25.2.20010702135824.02ca6560@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: Ran Canetti , mbaugher@cisco.com, rafaeli@comp.lancs.ac.uk From: Thomas Hardjono Subject: RE: [MSEC] De-registration protocol? Cc: msec@securemulticast.org In-Reply-To: <200107012309.TAA34422@ornavella.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 02 Jul 2001 14:06:11 -0400 At 7/1/2001||07:09 PM, Ran Canetti wrote: >My reason for making the de-registration protocol an (optional) part of the >msec suite is to provide the application with a complete and uniform >interface >of secure group operations. This looks cleaner and better design to me than >forcing the application to take care of securing leave operations by itself. Ran, I understand that we have have a "cleaner" interface, though there is a cost to this cleanliness, namely an increase in the complexity and (possibly) state maintained by the KDC and the client-software. If we over-spec MSEC, then it would be harder/longer for people to implement the spec. Most vendors want to use/implement a simple and practical spec. >In all, I see two options: > >1. We believe that having members sign up only for preset periods >of time is sufficient for now. In this case we can indeed leave >de-registration for later. However, as Sandro noted, in this case there >is much less need in the rekeying mechanism in the first place. Instead we >can use the MARKS mechanism (or simply choose keys for preset periods of >time) and avoid the rekeying messages altogether. > >2. We decide that we need to provide the group controller with the ability >to let members sign up for an unspecified time and then be charge them >according to the actual amount of time used. In this case it is clear that >secure de-registration is necessary. Here I strongly believe that we need to >provide this functionality within msec. We are not arguing about the need of this functionality, but *where* this functionality should reside. I think it is an application layer functionality. thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 3 08:52:38 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07367 for ; Tue, 3 Jul 2001 08:52:37 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0691B5355D; Tue, 3 Jul 2001 08:52:21 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id B0F9053541 for ; Tue, 3 Jul 2001 08:50:32 -0400 (EDT) Received: (qmail 9907 invoked by uid 3269); 3 Jul 2001 12:50:32 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 9904 invoked from network); 3 Jul 2001 12:50:32 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 3 Jul 2001 12:50:32 -0000 Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.24.13]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f63Co8x12631; Tue, 3 Jul 2001 05:50:08 -0700 (PDT) Received: from cisco.com ([171.70.196.154]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id AJR06279 (AUTH mcgrew); Tue, 3 Jul 2001 05:49:58 -0700 (PDT) Message-ID: <3B41C098.17F63A94@cisco.com> From: "David A. McGrew" X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ran Canetti Cc: msec@securemulticast.org Subject: Re: [MSEC] De-registration protocol? References: <200106281948.PAA06318@ornavella.watson.ibm.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: Tue, 03 Jul 2001 08:54:48 -0400 Content-Transfer-Encoding: 7bit Ran, a de-registration mechanism implies a secure channel from each member to the controller, so I can see your point that it is missing from the architecture. I think that it's worth noting that without a secure channel from each member to the controller, reliable multicast/multi-unicast becomes problematic, since the KDC has no (secured) information about the loss rates of its messages to the group members. This supports the contention that those channels belong in the architecture, to my mind anyway. Having read over the chat on this topic, it strikes me that there are varying expectations for the lifetime of a group. Short lived groups have little need for de-registration, while groups that persisted for a year would likely need a de-registration mechanism. A decent analogy may be kerberos tickets, which can't be revoked like a cert but which can be made so short-lived that it hardly matters. I'd venture that the WG is mostly considering short-lived groups. IMHO, there are plenty of good reasons for having long-lived groups (most importantly, to better amortize the registration stage), though I sympathize with the point of view that our protocols should walk before they run. I'd favor noting the possible need for a member-to-controller channel in the architecture, but not spending much short term effort on realizing it. David mcgrew@cisco.com Ran Canetti wrote: > > Folks, > > The GKM architecture draft specifies two components of group key management: > > o Registration protocol - this is a *short-term* unicast protocol between > a registering group member and the KDC (or, GCKS). > > o Rekey protocol - this is a protocol where the KDC sends update messages > to the group members. The communication in this protocol is typically > initiated by the KDC. Furthermore, typically it will be multicasted. > (The should probably be a mechanism within the rekey protocol that allows > members to prompt the KDC in case they did not receive the update data in > time, but this mechanism does not answer my question below.) > > The architecture does not provide a leaving group member any mechanism > to let the KDC/GCKS that it has left the group. I'd like to bring up the > question whether we need to provide such functionality. > > Clearly, in many cases such a "de-registration" protocol will not be > necessary. A leaving member simply sees itself out and there is no need > to let anybody know. > > But there may be cases where de-registration is useful: For instance, when > member pays according to the anount of time it is registered, and this > amount of time is not known in advance. (Say, in a boxing fight where the > payment is by the number of rounds watched). In such a case we need to let > the member *securely* notify the GCKS. This notification will be used to > update the necessary accounts and to cryptographically remove the member > from the group (e.g., by updating the OFT/LKH tree in use). > > One possibility would be to push the burden of doing de-registration to the > application and not deal with it within MSEC. But I think this would be a > mistake - revoking membership of leaving members is patently a security issue > that is within the domain of group membership management. So we should not > leave such "loose ends" to the application. (Also, it seems architecturally > unwise to have the LKH/OFT module receive its leave requests from a different > layer than its join requests.) > > So, it appears like we should be adding an optional de-registration > protocol to the GKM architecture... > > Any opinions? > > Ran > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 3 09:08:01 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17050 for ; Tue, 3 Jul 2001 09:08:00 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9E4635354D; Tue, 3 Jul 2001 09:08:13 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 8E2FE53538 for ; Tue, 3 Jul 2001 09:07:03 -0400 (EDT) Received: (qmail 11564 invoked by uid 3269); 3 Jul 2001 13:07:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 11561 invoked from network); 3 Jul 2001 13:07:02 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by klesh.pair.com with SMTP; 3 Jul 2001 13:07:02 -0000 Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.24.13]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f63D4oH08489; Tue, 3 Jul 2001 06:04:50 -0700 (PDT) Received: from cisco.com ([171.70.196.154]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id AJR06432 (AUTH mcgrew); Tue, 3 Jul 2001 06:06:26 -0700 (PDT) Message-ID: <3B41C472.E4910D3E@cisco.com> From: "David A. McGrew" X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Andrea Colegrove Cc: msec@securemulticast.org Subject: Re: [MSEC] Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt References: <200106271103.HAA26170@ietf.org> <3B3A1837.D95360C0@columbia.sparta.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: Tue, 03 Jul 2001 09:11:14 -0400 Content-Transfer-Encoding: 7bit Andrea, Andrea Colegrove wrote: > 4. In general all the requirements for a group key management protocol refer > to a group security management protocol. For example: Changes in algorithms, > access, etc are changes to POLICY. Policy is _so_ much more than "meta-data > describing the keys." what data do you think should be included in the definition of policy? From GSAKMP Section 4.4: The Policy Token Payload contains group specific information that describes the group security relevant behaviors, access control parameters, and security mechanisms. Is there a more concrete definition of these policy elements in the GSAKMP document, or could you please describe what policy elements that you have in mind? thanks, mcgrew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 3 12:26:58 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11440 for ; Tue, 3 Jul 2001 12:26:56 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A3A8353539; Tue, 3 Jul 2001 12:27:01 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 7BAC653532 for ; Tue, 3 Jul 2001 11:04:40 -0400 (EDT) Received: (qmail 23031 invoked by uid 3269); 3 Jul 2001 15:04:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 23028 invoked from network); 3 Jul 2001 15:04:39 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 3 Jul 2001 15:04:39 -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.11.3/8.9.1) with ESMTP id f63F4Fx23235; Tue, 3 Jul 2001 08:04:15 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-592.cisco.com [10.21.66.80]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADV02553; Tue, 3 Jul 2001 08:04:06 -0700 (PDT) Message-Id: <4.3.2.7.2.20010703074925.04135b98@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "David A. McGrew" From: Mark Baugher Subject: Re: [MSEC] De-registration protocol? Cc: msec@securemulticast.org In-Reply-To: <3B41C098.17F63A94@cisco.com> References: <200106281948.PAA06318@ornavella.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Tue, 03 Jul 2001 08:03:33 -0700 David, Some questions/comments. At 08:54 AM 7/3/2001 -0400, David A. McGrew wrote: >ran, > >a de-registration mechanism implies a secure channel from each member to the >controller, so i can see your point that it is missing from the >architecture. i The Registration protocol is a secure channel between member to controller (which we call KDC in gkmarch and GCKS in SMuG). I don't understand. There is no requirement that this channel be torn down. >think that it's worth noting that without a secure channel from each member to >the controller, reliable multicast/multi-unicast becomes problematic, >since the >kdc has no (secured) information about the loss rates of its messages to the >group members. this supports the contention that those channels belong in the >architecture, to my mind anyway. So your concern is that there is no secure multicast channel between the member and KDC? I think that there may be value of a de-registration function in the context of re-key for membership management since the KDC has some state for each member. Without membership management, the de-registration protocol boils down to the member establishing a computationally-expensive channel with the KDC to say the following: "I am leaving the group; you cannot stop me from using my keys; you cannot tell if I'm using the keys, but take my word for it that I'm leaving the group." Mark >having read over the chat on this topic, it strikes me that there are varying >expectations for the lifetime of a group. short lived groups have little need >for de-registration, while groups that persisted for a year would likely >need a >de-registration mechanism. a decent analogy may be kerberos tickets, which >can't be revoked like a cert but which can be made so short-lived that it >hardly >matters. i'd venture that the wg is mostly considering short-lived groups. >imho, there are plenty of good reasons for having long-lived groups (most >importantly, to better amortize the registration stage), though i sympathize >with the point of view that our protocols should walk before they run. > >i'd favor noting the possible need for a member-to-controller channel in the >architecture, but not spending much short term effort on realizing it. > >david >mcgrew@cisco.com > >ran canetti wrote: > > > > folks, > > > > the gkm architecture draft specifies two components of group key > management: > > > > o registration protocol - this is a *short-term* unicast protocol between > > a registering group member and the kdc (or, gcks). > > > > o rekey protocol - this is a protocol where the kdc sends update messages > > to the group members. the communication in this protocol is typically > > initiated by the kdc. furthermore, typically it will be multicasted. > > (the should probably be a mechanism within the rekey protocol that allows > > members to prompt the kdc in case they did not receive the update data in > > time, but this mechanism does not answer my question below.) > > > > the architecture does not provide a leaving group member any mechanism > > to let the kdc/gcks that it has left the group. i'd like to bring up the > > question whether we need to provide such functionality. > > > > clearly, in many cases such a "de-registration" protocol will not be > > necessary. a leaving member simply sees itself out and there is no need > > to let anybody know. > > > > but there may be cases where de-registration is useful: for instance, when > > member pays according to the anount of time it is registered, and this > > amount of time is not known in advance. (say, in a boxing fight where the > > payment is by the number of rounds watched). in such a case we need to let > > the member *securely* notify the gcks. this notification will be used to > > update the necessary accounts and to cryptographically remove the member > > from the group (e.g., by updating the oft/lkh tree in use). > > > > one possibility would be to push the burden of doing de-registration to the > > application and not deal with it within msec. but i think this would be a > > mistake - revoking membership of leaving members is patently a security > issue > > that is within the domain of group membership management. so we should not > > leave such "loose ends" to the application. (also, it seems architecturally > > unwise to have the lkh/oft module receive its leave requests from a > different > > layer than its join requests.) > > > > so, it appears like we should be adding an optional de-registration > > protocol to the gkm architecture... > > > > any opinions? > > > > ran > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://www.pairlist.net/mailman/listinfo/msec > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 3 13:27:30 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13131 for ; Tue, 3 Jul 2001 13:27:29 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0433953532; Tue, 3 Jul 2001 13:27:41 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id EFDC05352A for ; Tue, 3 Jul 2001 13:24:53 -0400 (EDT) Received: (qmail 40010 invoked by uid 3269); 3 Jul 2001 17:24:53 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 40001 invoked from network); 3 Jul 2001 17:24:52 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 3 Jul 2001 17:24:52 -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.11.3/8.9.1) with ESMTP id f63HOTx26034; Tue, 3 Jul 2001 10:24:29 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-562.cisco.com [10.21.66.50]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADW02553; Tue, 3 Jul 2001 10:24:19 -0700 (PDT) Message-Id: <4.3.2.7.2.20010703102011.04173ea0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "David A. McGrew" From: Mark Baugher Subject: Re: [MSEC] De-registration protocol? Cc: msec@securemulticast.org In-Reply-To: <3B41FC03.84B38818@cisco.com> References: <200106281948.PAA06318@ornavella.watson.ibm.com> <4.3.2.7.2.20010703074925.04135b98@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Tue, 03 Jul 2001 10:23:48 -0700 Hi David, At 01:08 PM 7/3/2001 -0400, David A. McGrew wrote: >Mark, > >Mark Baugher wrote: > > > > David, > > Some questions/comments. > > > > At 08:54 AM 7/3/2001 -0400, David A. McGrew wrote: > > >ran, > > > > > >a de-registration mechanism implies a secure channel from each member > to the > > >controller, so i can see your point that it is missing from the > > >architecture. i > > > > The Registration protocol is a secure channel between member to controller > > (which we call KDC in gkmarch and GCKS in SMuG). I don't understand. > > There is no requirement that this channel be torn down. > >then I stand corrected. > > > > > >think that it's worth noting that without a secure channel from each > member to > > >the controller, reliable multicast/multi-unicast becomes problematic, > > >since the > > >kdc has no (secured) information about the loss rates of its messages > to the > > >group members. this supports the contention that those channels > belong in the > > >architecture, to my mind anyway. > > > > So your concern is that there is no secure multicast channel between the > > member > > and KDC? I think that there may be value of a de-registration function > in the > > context of re-key for membership management since the KDC has some state > > for each member. Without membership management, the de-registration > > protocol boils down to the member establishing a computationally-expensive > > channel with the KDC to say the following: "I am leaving the group; > you cannot > > stop me from using my keys; you cannot tell if I'm using the keys, but take > > my word for it that I'm leaving the group." > >right, I'd assumed that membership management was present (at least >optionally). IMHO, it's a huge gotcha to the implementer to have a protocol that looks symmetric to the registration protocol but which can cause a big performance problem if it is inadvertently used only with the registration protocol. >Off topic: does your mailer automatically convert to lower case when it quotes >nntp messages? I don't know. Why do you ask? Cheers, Mark >thanks, > >David > > > > > Mark > > > > >having read over the chat on this topic, it strikes me that there are > varying > > >expectations for the lifetime of a group. short lived groups have > little need > > >for de-registration, while groups that persisted for a year would likely > > >need a > > >de-registration mechanism. a decent analogy may be kerberos tickets, > which > > >can't be revoked like a cert but which can be made so short-lived that it > > >hardly > > >matters. i'd venture that the wg is mostly considering short-lived > groups. > > >imho, there are plenty of good reasons for having long-lived groups (most > > >importantly, to better amortize the registration stage), though i > sympathize > > >with the point of view that our protocols should walk before they run. > > > > > >i'd favor noting the possible need for a member-to-controller channel > in the > > >architecture, but not spending much short term effort on realizing it. > > > > > >david > > >mcgrew@cisco.com > > > > > >ran canetti wrote: > > > > > > > > folks, > > > > > > > > the gkm architecture draft specifies two components of group key > > > management: > > > > > > > > o registration protocol - this is a *short-term* unicast protocol > between > > > > a registering group member and the kdc (or, gcks). > > > > > > > > o rekey protocol - this is a protocol where the kdc sends update > messages > > > > to the group members. the communication in this protocol is typically > > > > initiated by the kdc. furthermore, typically it will be multicasted. > > > > (the should probably be a mechanism within the rekey protocol > that allows > > > > members to prompt the kdc in case they did not receive the update > data in > > > > time, but this mechanism does not answer my question below.) > > > > > > > > the architecture does not provide a leaving group member any mechanism > > > > to let the kdc/gcks that it has left the group. i'd like to bring > up the > > > > question whether we need to provide such functionality. > > > > > > > > clearly, in many cases such a "de-registration" protocol will not be > > > > necessary. a leaving member simply sees itself out and there is no need > > > > to let anybody know. > > > > > > > > but there may be cases where de-registration is useful: for > instance, when > > > > member pays according to the anount of time it is registered, and this > > > > amount of time is not known in advance. (say, in a boxing fight > where the > > > > payment is by the number of rounds watched). in such a case we need > to let > > > > the member *securely* notify the gcks. this notification will be > used to > > > > update the necessary accounts and to cryptographically remove the > member > > > > from the group (e.g., by updating the oft/lkh tree in use). > > > > > > > > one possibility would be to push the burden of doing > de-registration to the > > > > application and not deal with it within msec. but i think this > would be a > > > > mistake - revoking membership of leaving members is patently a security > > > issue > > > > that is within the domain of group membership management. so we > should not > > > > leave such "loose ends" to the application. (also, it seems > architecturally > > > > unwise to have the lkh/oft module receive its leave requests from a > > > different > > > > layer than its join requests.) > > > > > > > > so, it appears like we should be adding an optional de-registration > > > > protocol to the gkm architecture... > > > > > > > > any opinions? > > > > > > > > ran > > > > > > > > _______________________________________________ > > > > msec mailing list > > > > msec@securemulticast.org > > > > http://www.pairlist.net/mailman/listinfo/msec > > > > > >_______________________________________________ > > >msec mailing list > > >msec@securemulticast.org > > >http://www.pairlist.net/mailman/listinfo/msec > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 3 13:34:28 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13369 for ; Tue, 3 Jul 2001 13:34:27 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id CD81753552; Tue, 3 Jul 2001 13:34:38 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 373E05353D for ; Tue, 3 Jul 2001 13:04:06 -0400 (EDT) Received: (qmail 37778 invoked by uid 3269); 3 Jul 2001 17:04:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 37775 invoked from network); 3 Jul 2001 17:04:05 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 3 Jul 2001 17:04:05 -0000 Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.24.13]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f63H3bx04396; Tue, 3 Jul 2001 10:03:37 -0700 (PDT) Received: from cisco.com ([171.70.196.154]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id AJS02969 (AUTH mcgrew); Tue, 3 Jul 2001 10:03:27 -0700 (PDT) Message-ID: <3B41FC03.84B38818@cisco.com> From: "David A. McGrew" X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] De-registration protocol? References: <200106281948.PAA06318@ornavella.watson.ibm.com> <4.3.2.7.2.20010703074925.04135b98@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: Tue, 03 Jul 2001 13:08:19 -0400 Content-Transfer-Encoding: 7bit Mark, Mark Baugher wrote: > > David, > Some questions/comments. > > At 08:54 AM 7/3/2001 -0400, David A. McGrew wrote: > >ran, > > > >a de-registration mechanism implies a secure channel from each member to the > >controller, so i can see your point that it is missing from the > >architecture. i > > The Registration protocol is a secure channel between member to controller > (which we call KDC in gkmarch and GCKS in SMuG). I don't understand. > There is no requirement that this channel be torn down. then I stand corrected. > > >think that it's worth noting that without a secure channel from each member to > >the controller, reliable multicast/multi-unicast becomes problematic, > >since the > >kdc has no (secured) information about the loss rates of its messages to the > >group members. this supports the contention that those channels belong in the > >architecture, to my mind anyway. > > So your concern is that there is no secure multicast channel between the > member > and KDC? I think that there may be value of a de-registration function in the > context of re-key for membership management since the KDC has some state > for each member. Without membership management, the de-registration > protocol boils down to the member establishing a computationally-expensive > channel with the KDC to say the following: "I am leaving the group; you cannot > stop me from using my keys; you cannot tell if I'm using the keys, but take > my word for it that I'm leaving the group." right, I'd assumed that membership management was present (at least optionally). Off topic: does your mailer automatically convert to lower case when it quotes nntp messages? thanks, David > > Mark > > >having read over the chat on this topic, it strikes me that there are varying > >expectations for the lifetime of a group. short lived groups have little need > >for de-registration, while groups that persisted for a year would likely > >need a > >de-registration mechanism. a decent analogy may be kerberos tickets, which > >can't be revoked like a cert but which can be made so short-lived that it > >hardly > >matters. i'd venture that the wg is mostly considering short-lived groups. > >imho, there are plenty of good reasons for having long-lived groups (most > >importantly, to better amortize the registration stage), though i sympathize > >with the point of view that our protocols should walk before they run. > > > >i'd favor noting the possible need for a member-to-controller channel in the > >architecture, but not spending much short term effort on realizing it. > > > >david > >mcgrew@cisco.com > > > >ran canetti wrote: > > > > > > folks, > > > > > > the gkm architecture draft specifies two components of group key > > management: > > > > > > o registration protocol - this is a *short-term* unicast protocol between > > > a registering group member and the kdc (or, gcks). > > > > > > o rekey protocol - this is a protocol where the kdc sends update messages > > > to the group members. the communication in this protocol is typically > > > initiated by the kdc. furthermore, typically it will be multicasted. > > > (the should probably be a mechanism within the rekey protocol that allows > > > members to prompt the kdc in case they did not receive the update data in > > > time, but this mechanism does not answer my question below.) > > > > > > the architecture does not provide a leaving group member any mechanism > > > to let the kdc/gcks that it has left the group. i'd like to bring up the > > > question whether we need to provide such functionality. > > > > > > clearly, in many cases such a "de-registration" protocol will not be > > > necessary. a leaving member simply sees itself out and there is no need > > > to let anybody know. > > > > > > but there may be cases where de-registration is useful: for instance, when > > > member pays according to the anount of time it is registered, and this > > > amount of time is not known in advance. (say, in a boxing fight where the > > > payment is by the number of rounds watched). in such a case we need to let > > > the member *securely* notify the gcks. this notification will be used to > > > update the necessary accounts and to cryptographically remove the member > > > from the group (e.g., by updating the oft/lkh tree in use). > > > > > > one possibility would be to push the burden of doing de-registration to the > > > application and not deal with it within msec. but i think this would be a > > > mistake - revoking membership of leaving members is patently a security > > issue > > > that is within the domain of group membership management. so we should not > > > leave such "loose ends" to the application. (also, it seems architecturally > > > unwise to have the lkh/oft module receive its leave requests from a > > different > > > layer than its join requests.) > > > > > > so, it appears like we should be adding an optional de-registration > > > protocol to the gkm architecture... > > > > > > any opinions? > > > > > > ran > > > > > > _______________________________________________ > > > msec mailing list > > > msec@securemulticast.org > > > http://www.pairlist.net/mailman/listinfo/msec > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 3 15: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 PAA17362 for ; Tue, 3 Jul 2001 15:44:36 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6BF015352D; Tue, 3 Jul 2001 15:44:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 1364B53573 for ; Tue, 3 Jul 2001 15:42:18 -0400 (EDT) Received: (qmail 52568 invoked by uid 3269); 3 Jul 2001 19:42:17 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 52565 invoked from network); 3 Jul 2001 19:42:17 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by klesh.pair.com with SMTP; 3 Jul 2001 19:42:17 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f63JTLH29173; Tue, 3 Jul 2001 12:37:06 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-562.cisco.com [10.21.66.50]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADW05890; Tue, 3 Jul 2001 12:30:58 -0700 (PDT) Message-Id: <4.3.2.7.2.20010702132938.0202d6c8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Hugh Harney From: Mark Baugher Subject: Re: [MSEC] msec architecture draft and email flow Cc: msec@securemulticast.org In-Reply-To: <4.2.2.20010702112018.00b31ec0@pop.columbia.sparta.com> References: <4.3.2.7.2.20010702080351.04175c60@mira-sjc5-6.cisco.com> <4.2.2.20010702081652.00b39410@pop.columbia.sparta.com> <4.3.2.7.2.20010630011412.041eb718@mira-sjc5-6.cisco.com> <4.2.2.20010628143506.00b31dc0@pop.columbia.sparta.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Tue, 03 Jul 2001 12:30:26 -0700 Hugh I think it's good for msec that we have this discussion on the mailing list. At 11:40 AM 7/2/2001 -0400, Hugh Harney wrote: >Mark, > > >>>>>GDOI assumes that at least the following group-policy information is >>>>>externally managed. >>>>> o Group owner, authentication method, and delegation method >>>>> for identifying a GCKS for the group >>>>> o Group GCKS, authentication method, and any method used for >>>>> delegating another GCKS for the group >>>>> o Group membership rules or list and authentication method >>>>> >>>>>There is a team of individuals who are working on group policy within >>>>>MSEC. This team may develop alternative group policy models that will >>>>>necessitate update to the way group policy is referenced in GDOI. For >>>>>example, the current GDOI draft assumes the existence of a group owner >>>>>or owners who delegate key-distribution authority to a GCKS, which >>>>>validates a member's credentials before adding a member to a >>>>>particular group. Alternative group policy models might require >>>>>changes to GDOI payloads, exchanges, or processing. >>>>> >>>> >>>>Which items in the three bullets might belong in key management? >>> >>>Bullet one is ok outside. >> >>I always wondered why this would not be mandatory to be outside: The >>Group Owner tells you which KDC/GCKS to trust. Would you go to the >>KDC/GCKS and ask "who is the Group Owner that tells me to trust you?" > >Just as the root certificate is self signed, there has to be a core to >start the trust. The group owner is that core. I think Carl's idea of >passing out your business card with your fingerprint on the back is a good >idea. If the group owner is someone you know and they give you their card, >then they can be an owner of a group (in a reasonable domain) and you can >verify it is them. People get involved somewhere. I agree. So "Group Owner" is outside the key management framework. I too like Carl Ellison's ideas, such as there needs to be some personal contact for there to be trust of personal identity. The other two bullets are within key management and in fact they are in IKE as well as GSAKMP and GDOI. >>>Bullet two is critical for a joining member to trust the key. It should >>>be inside. This is an extension of the explicitness principle. If you >>>are using an attribute certificate (or delegation cert) then this is >>>passed via an LDAP or certificate payload. In either case the KM >>>protocol needs to review that certificate and determine the GCKS is >>>authorized. It is still part of the KM protocol. >> >>By virtue of the fact that a member is contacting a KDC/GCKS, it seems >>that we have resolved the question of who the KDC/GCKS is. What am I >>missing? How would this identification of policy take place within key >>management? > >Anyone can reply to a join/registration request. We need to know that >whomever replies is authorized to handout key for the group. Or the member can direct the request to the authorized server based on, say, a secure website or email attachment. There could be a Session Description Protocol (SDP) announcement that gets sent as securely as it needs to be that causes the member to contact the correct GCKS. So this request is often out-of-band from the key management protocol for a lot of interesting applications. >It is critical to the acceptance of the key to know that the GC/KS is >authorized to hand out the key. This is something that has to be enforced >by the joining member. The decision has to be based on some security >policy (singed by the GO) that the member has received. Yes, we can use >attribute/delegation certificates, but the member must enforce the >authorization policy before it can trust the key. And the KDC/GCKS must enforce the policy before it can trust the member. >This is different from IKE or pairwise key management protocols. Peer >protocols are talking to the entity they will be using the key with. They >directly exchange signed certificates with the other side. The >verirfication of the certificate implies authorization to create key for >that party. The know who they are talking to. In groups we are accepting a >key download on behalf of an abstract GSA. "GSA" or "GO?" I don't understand this abstraction. In GDOI, the KDC/GCKS exchanges credentials (performs authorization and authentication) with the member in pairwise key exchange (IKE Phase 1) and then the KDC/GCKS downloads a key on behalf of the group owner (GDOI Phase 2). As you know, the Phase 2 can have an identity with a proof of possession. The identity for the member is a credential that shows authorization from the group owner to get key material (e.g., KEK, TEKs) for the group. The identity for the KDC/GCKS shows authorization from the group owner to give key material to prospective members of the group. This latter credential may be delegated. >>>Bullet 3 is critical only if the group members are going to be adding >>>data to the group. The data contributors must be able to review the >>>access control criteria to determine if their data is protected by that >>>criteria. >> >>Would you see this as being necessarily inside of the key management >>protocol? It might be useful to list the policy items that are inside GSAKMP. > >For multi source groups it is essential to be in the KM protocol. This >again relates to the abstract nature of the group. I'm accepting a key >from an authorized source. That key is to be used to protect my data. >Without the inclusion of this security policy information, all I know is >that I'm authorized to have the key to this group. What I need (as a data >sharing member) is knowledge of how much other members may be trusted. If >they have the key they have access to my data. I say "trusted with what" rather than "how much other members may be trusted." Can they be trusted with the data I might send to this group? Can they be trusted to give me data that I may use? A multi-source group is protected by a data security SA. What goes into this is peculiar to the data security protocol (viz. the Appendices in the GDOI draft). >The example I use is my bank asking me to share my SSN via a group key. I >trust the bank, I trust myself, but I don't know who they gave the key to. >If they tell me that the key is held by the bank, the IRS, and myself I'll >send my SSN. If they tell me the key is held by all customers of the bank >I'd balk. > >The access control rules have to be disclosed to any member risking >personal data on that key. Again, If I'm just listening passively no >problem (then I wouldn't need to know the access rules). Does this need a representation in group key management? >>>Hey we may agree soon. Then where will the fun be? >> >>In making progress. We would make a lot of progress if we could merge >>GSAKMP and GDOI into one protocol. > >Mark this was a joke. Yes convergence of GDOI and GSAKMP would be great. Or at least, we could work towards interoperability if we used the same header. GDOI needs to support an ISAKMP header since it is an IKE DOI. Why can't GSAKMP use an ISAKMP header? thanks, Mark >Hugh >________________________________________________________ >Hugh Harney hh@sparta.com 410-381-9400 x203 >________________________________________________________ > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 3 15:54:06 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17691 for ; Tue, 3 Jul 2001 15:54:05 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 5396A53558; Tue, 3 Jul 2001 15:54:13 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 6B9DB53558 for ; Tue, 3 Jul 2001 15:53:26 -0400 (EDT) Received: (qmail 53400 invoked by uid 3269); 3 Jul 2001 19:53:26 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 53397 invoked from network); 3 Jul 2001 19:53:25 -0000 Received: from m5.sparta.com (root@157.185.61.1) by klesh.pair.com with SMTP; 3 Jul 2001 19:53:25 -0000 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by M5.sparta.com (8.11.0/8.11.0) with ESMTP id f63JrOx26155; Tue, 3 Jul 2001 14:53:24 -0500 Received: from columbia.sparta.com (dhcp-5.columbia.sparta.com [157.185.80.6]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id PAA06820; Tue, 3 Jul 2001 15:53:23 -0400 (EDT) Message-ID: <3B422299.831085CF@columbia.sparta.com> From: Andrea Colegrove X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "David A. McGrew" Cc: "msec@securemulticast.org" Subject: Re: [MSEC] Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt References: <200106271103.HAA26170@ietf.org> <3B3A1837.D95360C0@columbia.sparta.com> <3B41C472.E4910D3E@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: Tue, 03 Jul 2001 15:52:57 -0400 Content-Transfer-Encoding: 7bit David, Group policy is the collection of security rules that the group will adhere to. It can include, as stated in the GSAKMP doc, security association parameters, access control rules, and even host-based properties such as certification. It is what a new member uses to determine if it wants to join (potentially share data with) a group and it is what a GCKS uses to determine if a new member should be given access to the group. Because the policy for groups will vary, the actual policy elements in a specific policy will vary as well. Thus, static policy statements for all groups would probably be inadequate. I am afraid I cannot give a more concrete definition than that. The policy building block touches upon these issues, but last I checked the link from the msec page was broken anyway. We also discuss trust reasoning based upon policy in "Principles of Policy in Secure Groups" presented at NDSS '01. The url is http://www.eecs.umich.edu/~pdmcdan/docs/ndss01.pdf. I hope this answers your question somewhat. Thanks, Andrea "David A. McGrew" wrote: > Andrea, > > Andrea Colegrove wrote: > > 4. In general all the requirements for a group key management protocol refer > > to a group security management protocol. For example: Changes in algorithms, > > access, etc are changes to POLICY. Policy is _so_ much more than "meta-data > > describing the keys." > > what data do you think should be included in the definition of policy? From > GSAKMP Section 4.4: > > The Policy Token Payload contains group specific information that describes > the group security relevant behaviors, access control parameters, and > security mechanisms. > > Is there a more concrete definition of these policy elements in the GSAKMP > document, or could you please describe what policy elements that you have in > mind? > > thanks, > > mcgrew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 3 18:09:11 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01942 for ; Tue, 3 Jul 2001 18:09:09 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B40555357A; Tue, 3 Jul 2001 18:09:22 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 049B75354B for ; Tue, 3 Jul 2001 18:07:29 -0400 (EDT) Received: (qmail 65792 invoked by uid 3269); 3 Jul 2001 22:07:28 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 65789 invoked from network); 3 Jul 2001 22:07:28 -0000 Received: from chmls06.mediaone.net (24.147.1.144) by klesh.pair.com with SMTP; 3 Jul 2001 22:07:28 -0000 Received: from THARDJONO-LAP.mediaone.net (h0010a4c49f9e.ne.mediaone.net [24.128.44.121]) by chmls06.mediaone.net (8.11.1/8.11.1) with ESMTP id f63M7O811463; Tue, 3 Jul 2001 18:07:24 -0400 (EDT) Message-Id: <5.0.0.25.2.20010703154018.029a5ec0@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: Mark Baugher , "David A. McGrew" From: Thomas Hardjono Subject: Re: [MSEC] De-registration protocol? Cc: msec@securemulticast.org In-Reply-To: <4.3.2.7.2.20010703074925.04135b98@mira-sjc5-6.cisco.com> References: <3B41C098.17F63A94@cisco.com> <200106281948.PAA06318@ornavella.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Tue, 03 Jul 2001 15:44:25 -0400 Mark, David, At 7/3/2001||08:03 AM, Mark Baugher wrote: >David, > Some questions/comments. > >At 08:54 AM 7/3/2001 -0400, David A. McGrew wrote: >>ran, >> >>a de-registration mechanism implies a secure channel from each member to the >>controller, so i can see your point that it is missing from the >>architecture. i > >The Registration protocol is a secure channel between member to controller >(which we call KDC in gkmarch and GCKS in SMuG). I don't understand. >There is no requirement that this channel be torn down. Right, so long as your box can handle so many tens-of-thousands of SAs. I agree though, it is not clear when it is better to let the Cat-1 SA die-off or which situation requires the Cat-1 SAs to be around as long as the member is around. (wie. Which is cheaper: to maintain, or to tear-down and then re-establish). Is there's some benefit for the MSEC community to look at the possibility of maintaining "partial" Cat-1 SAs? (ie. avoiding complete new negotations by keeping previous SA state). thomas ------ >>think that it's worth noting that without a secure channel from each >>member to >>the controller, reliable multicast/multi-unicast becomes problematic, >>since the >>kdc has no (secured) information about the loss rates of its messages to the >>group members. this supports the contention that those channels belong >>in the >>architecture, to my mind anyway. > >So your concern is that there is no secure multicast channel between the >member >and KDC? I think that there may be value of a de-registration function in the >context of re-key for membership management since the KDC has some state >for each member. Without membership management, the de-registration >protocol boils down to the member establishing a computationally-expensive >channel with the KDC to say the following: "I am leaving the group; you >cannot >stop me from using my keys; you cannot tell if I'm using the keys, but take >my word for it that I'm leaving the group." > >Mark > > >>having read over the chat on this topic, it strikes me that there are varying >>expectations for the lifetime of a group. short lived groups have little >>need >>for de-registration, while groups that persisted for a year would likely >>need a >>de-registration mechanism. a decent analogy may be kerberos tickets, which >>can't be revoked like a cert but which can be made so short-lived that it >>hardly >>matters. i'd venture that the wg is mostly considering short-lived groups. >>imho, there are plenty of good reasons for having long-lived groups (most >>importantly, to better amortize the registration stage), though i sympathize >>with the point of view that our protocols should walk before they run. >> >>i'd favor noting the possible need for a member-to-controller channel in the >>architecture, but not spending much short term effort on realizing it. >> >>david >>mcgrew@cisco.com >> >>ran canetti wrote: >> > >> > folks, >> > >> > the gkm architecture draft specifies two components of group key >> management: >> > >> > o registration protocol - this is a *short-term* unicast protocol between >> > a registering group member and the kdc (or, gcks). >> > >> > o rekey protocol - this is a protocol where the kdc sends update messages >> > to the group members. the communication in this protocol is typically >> > initiated by the kdc. furthermore, typically it will be multicasted. >> > (the should probably be a mechanism within the rekey protocol that >> allows >> > members to prompt the kdc in case they did not receive the update >> data in >> > time, but this mechanism does not answer my question below.) >> > >> > the architecture does not provide a leaving group member any mechanism >> > to let the kdc/gcks that it has left the group. i'd like to bring up the >> > question whether we need to provide such functionality. >> > >> > clearly, in many cases such a "de-registration" protocol will not be >> > necessary. a leaving member simply sees itself out and there is no need >> > to let anybody know. >> > >> > but there may be cases where de-registration is useful: for instance, when >> > member pays according to the anount of time it is registered, and this >> > amount of time is not known in advance. (say, in a boxing fight where the >> > payment is by the number of rounds watched). in such a case we need to let >> > the member *securely* notify the gcks. this notification will be used to >> > update the necessary accounts and to cryptographically remove the member >> > from the group (e.g., by updating the oft/lkh tree in use). >> > >> > one possibility would be to push the burden of doing de-registration >> to the >> > application and not deal with it within msec. but i think this would be a >> > mistake - revoking membership of leaving members is patently a >> security issue >> > that is within the domain of group membership management. so we should not >> > leave such "loose ends" to the application. (also, it seems >> architecturally >> > unwise to have the lkh/oft module receive its leave requests from a >> different >> > layer than its join requests.) >> > >> > so, it appears like we should be adding an optional de-registration >> > protocol to the gkm architecture... >> > >> > any opinions? >> > >> > ran >> > >> > _______________________________________________ >> > msec mailing list >> > msec@securemulticast.org >> > http://www.pairlist.net/mailman/listinfo/msec >> >>_______________________________________________ >>msec mailing list >>msec@securemulticast.org >>http://www.pairlist.net/mailman/listinfo/msec > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 3 18:09:24 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02125 for ; Tue, 3 Jul 2001 18:09:22 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id CCB235358C; Tue, 3 Jul 2001 18:09:29 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 2294A53534 for ; Tue, 3 Jul 2001 18:07:32 -0400 (EDT) Received: (qmail 65801 invoked by uid 3269); 3 Jul 2001 22:07:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 65796 invoked from network); 3 Jul 2001 22:07:31 -0000 Received: from chmls06.mediaone.net (24.147.1.144) by klesh.pair.com with SMTP; 3 Jul 2001 22:07:31 -0000 Received: from THARDJONO-LAP.mediaone.net (h0010a4c49f9e.ne.mediaone.net [24.128.44.121]) by chmls06.mediaone.net (8.11.1/8.11.1) with ESMTP id f63M7B811178; Tue, 3 Jul 2001 18:07:11 -0400 (EDT) Message-Id: <5.0.0.25.2.20010703153149.01879498@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: "David A. McGrew" From: Thomas Hardjono Subject: Re: [MSEC] De-registration protocol? Cc: msec@securemulticast.org In-Reply-To: <3B41C098.17F63A94@cisco.com> References: <200106281948.PAA06318@ornavella.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Tue, 03 Jul 2001 15:38:07 -0400 David, At 7/3/2001||08:54 AM, you wrote: >I'd favor noting the possible need for a member-to-controller channel in the >architecture, but not spending much short term effort on realizing it. Hmm, this brings-up the (old) issue of how long the Cat-1 SA and secure channel should be around. If we simply want a 1-to-1 secure channel between the member to KDC, then we already have this (namely, the Cat-1 SA or Registration/Initialization). Even if the "secure channel" was SSL or Ran's IPsec-Tunnel, the question of the lifetime of the connection remains still. And you are absolutely correct is stating that the answer depends on the size of the group (which to my mind is application-dependent, and to a some extent depends on the availability of a distributed KDC). I think it is the application that will decide the type of data, speed, capacity or routers/KDCs to hold SAs, etc. thomas ------ >David >mcgrew@cisco.com > >Ran Canetti wrote: > > > > Folks, > > > > The GKM architecture draft specifies two components of group key > management: > > > > o Registration protocol - this is a *short-term* unicast protocol between > > a registering group member and the KDC (or, GCKS). > > > > o Rekey protocol - this is a protocol where the KDC sends update messages > > to the group members. The communication in this protocol is typically > > initiated by the KDC. Furthermore, typically it will be multicasted. > > (The should probably be a mechanism within the rekey protocol that allows > > members to prompt the KDC in case they did not receive the update data in > > time, but this mechanism does not answer my question below.) > > > > The architecture does not provide a leaving group member any mechanism > > to let the KDC/GCKS that it has left the group. I'd like to bring up the > > question whether we need to provide such functionality. > > > > Clearly, in many cases such a "de-registration" protocol will not be > > necessary. A leaving member simply sees itself out and there is no need > > to let anybody know. > > > > But there may be cases where de-registration is useful: For instance, when > > member pays according to the anount of time it is registered, and this > > amount of time is not known in advance. (Say, in a boxing fight where the > > payment is by the number of rounds watched). In such a case we need to let > > the member *securely* notify the GCKS. This notification will be used to > > update the necessary accounts and to cryptographically remove the member > > from the group (e.g., by updating the OFT/LKH tree in use). > > > > One possibility would be to push the burden of doing de-registration to the > > application and not deal with it within MSEC. But I think this would be a > > mistake - revoking membership of leaving members is patently a security > issue > > that is within the domain of group membership management. So we should not > > leave such "loose ends" to the application. (Also, it seems architecturally > > unwise to have the LKH/OFT module receive its leave requests from a > different > > layer than its join requests.) > > > > So, it appears like we should be adding an optional de-registration > > protocol to the GKM architecture... > > > > Any opinions? > > > > Ran > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://www.pairlist.net/mailman/listinfo/msec > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 3 18:11:57 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03736 for ; Tue, 3 Jul 2001 18:11:56 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A26F95356E; Tue, 3 Jul 2001 18:12:09 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 479825359D for ; Tue, 3 Jul 2001 18:10:16 -0400 (EDT) Received: (qmail 66090 invoked by uid 3269); 3 Jul 2001 22:10:15 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 66087 invoked from network); 3 Jul 2001 22:10:15 -0000 Received: from chmls06.mediaone.net (24.147.1.144) by klesh.pair.com with SMTP; 3 Jul 2001 22:10:15 -0000 Received: from THARDJONO-LAP.mediaone.net (h0010a4c49f9e.ne.mediaone.net [24.128.44.121]) by chmls06.mediaone.net (8.11.1/8.11.1) with ESMTP id f63M7M811433; Tue, 3 Jul 2001 18:07:23 -0400 (EDT) Message-Id: <5.0.0.25.2.20010703153839.01879608@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: "David A. McGrew" , Andrea Colegrove From: Thomas Hardjono Subject: Re: [MSEC] Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt Cc: msec@securemulticast.org In-Reply-To: <3B41C472.E4910D3E@cisco.com> References: <200106271103.HAA26170@ietf.org> <3B3A1837.D95360C0@columbia.sparta.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Tue, 03 Jul 2001 15:39:52 -0400 Dave, The Group Security Policy Token (GSPT) draft should hopefully be out before the London IETF. cheers, thomas ------ At 7/3/2001||09:11 AM, David A. McGrew wrote: >Andrea, > >Andrea Colegrove wrote: > > 4. In general all the requirements for a group key management protocol > refer > > to a group security management protocol. For example: Changes in > algorithms, > > access, etc are changes to POLICY. Policy is _so_ much more than > "meta-data > > describing the keys." > >what data do you think should be included in the definition of policy? From >GSAKMP Section 4.4: > >The Policy Token Payload contains group specific information that describes >the group security relevant behaviors, access control parameters, and >security mechanisms. > >Is there a more concrete definition of these policy elements in the GSAKMP >document, or could you please describe what policy elements that you have in >mind? > >thanks, > >mcgrew@cisco.com > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 3 18:35:35 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18773 for ; Tue, 3 Jul 2001 18:35:34 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id AFE2D535F2; Tue, 3 Jul 2001 18:28:16 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id DC82A535E1 for ; Tue, 3 Jul 2001 18:27:31 -0400 (EDT) Received: (qmail 67328 invoked by uid 3269); 3 Jul 2001 22:27:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 67325 invoked from network); 3 Jul 2001 22:27:31 -0000 Received: from chmls06.mediaone.net (24.147.1.144) by klesh.pair.com with SMTP; 3 Jul 2001 22:27:31 -0000 Received: from THARDJONO-LAP.mediaone.net (h0010a4c49f9e.ne.mediaone.net [24.128.44.121]) by chmls06.mediaone.net (8.11.1/8.11.1) with ESMTP id f63MRR824032; Tue, 3 Jul 2001 18:27:27 -0400 (EDT) Message-Id: <5.0.0.25.2.20010703181658.01878a30@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: Andrea Colegrove , "David A. McGrew" From: Thomas Hardjono Subject: Re: [MSEC] Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt Cc: "msec@securemulticast.org" In-Reply-To: <3B422299.831085CF@columbia.sparta.com> References: <200106271103.HAA26170@ietf.org> <3B3A1837.D95360C0@columbia.sparta.com> <3B41C472.E4910D3E@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Tue, 03 Jul 2001 18:27:22 -0400 Andrea, David, I think one of the main issues with Group Policy within MSEC is to define (if possible) the suitable "amount" of policy information that is conveyed within the Group Security Policy Token (GSPT). The problem also is which parts of the GSPT is made public so that newcomers can find-out about the group and the requirements to join. Now, we don't want to end-up saying we need "policy" to say which parts of the GSPT are public and which parts are conveyed after the newcomer has user-authenticated themselves to the KDC (or one of the KDCs). That is, we don't want policies to govern "meta-policies", and so on. Also, one of the things that needs to be identified within the SEC architecture is: (a) which parts of the GSPT is made public, common across all key management protocol instantiations (ie. GSAKMP, GDOI). (b) which parts are downloaded within Cat-1/Registration (if any). eg. GSAKMP pushes it down in the 5th flow (as I recall). So, I see a tight inter-relationship/feedback-loop between the Key Management Architecture draft and the GSPT draft. If the Key Management Architecture draft is decidedly not the place to do this, then we might have to push it up to the umbrella MSEC Architecture document. thomas ------ At 7/3/2001||03:52 PM, Andrea Colegrove wrote: >David, > Group policy is the collection of security rules that the group will > adhere to. >It can include, as stated in the GSAKMP doc, security association >parameters, access >control rules, and even host-based properties such as certification. It >is what a >new member uses to determine if it wants to join (potentially share data >with) a >group and it is what a GCKS uses to determine if a new member should be >given access >to the group. > Because the policy for groups will vary, the actual policy elements in a >specific policy will vary as well. Thus, static policy statements for all >groups >would probably be inadequate. I am afraid I cannot give a more concrete >definition >than that. > The policy building block touches upon these issues, but last I > checked the link >from the msec page was broken anyway. We also discuss trust reasoning >based upon >policy in "Principles of Policy in Secure Groups" presented at NDSS >'01. The url is >http://www.eecs.umich.edu/~pdmcdan/docs/ndss01.pdf. > I hope this answers your question somewhat. > >Thanks, > >Andrea > >"David A. McGrew" wrote: > > > Andrea, > > > > Andrea Colegrove wrote: > > > 4. In general all the requirements for a group key management > protocol refer > > > to a group security management protocol. For example: Changes in > algorithms, > > > access, etc are changes to POLICY. Policy is _so_ much more than > "meta-data > > > describing the keys." > > > > what data do you think should be included in the definition of > policy? From > > GSAKMP Section 4.4: > > > > The Policy Token Payload contains group specific information that describes > > the group security relevant behaviors, access control parameters, and > > security mechanisms. > > > > Is there a more concrete definition of these policy elements in the GSAKMP > > document, or could you please describe what policy elements that you > have in > > mind? > > > > thanks, > > > > mcgrew@cisco.com > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jul 4 12:55:57 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09343 for ; Wed, 4 Jul 2001 12:55:56 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id CC30D536CB; Wed, 4 Jul 2001 12:56:08 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id B4A3F53681 for ; Wed, 4 Jul 2001 12:54:47 -0400 (EDT) Received: (qmail 41922 invoked by uid 3269); 4 Jul 2001 16:54:47 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 41915 invoked from network); 4 Jul 2001 16:54:46 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by klesh.pair.com with SMTP; 4 Jul 2001 16:54:46 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f64GqUH16774; Wed, 4 Jul 2001 09:52:30 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-tmp248.cisco.com [10.21.64.248]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADZ02841; Wed, 4 Jul 2001 09:54:06 -0700 (PDT) Message-Id: <4.3.2.7.2.20010704093401.042286c0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: thardjono@mediaone.net, hh@sparta.com, Brian Weis From: Mark Baugher Cc: msec@securemulticast.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Fwd: Proposed updates to GDOI draft Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Wed, 04 Jul 2001 09:53:33 -0700 Brian did not intend for his note to be forwarded to msec, but I think he did a good job of pre-editing the next version of the GDOI document and I thought it would be helpful to msec to see what we are doing with the next GDOI I-D. I don't think Brian will mind me doing this. Since he's on vacation, I volunteered to edit the document. There will probably need to be a telecon among Hugh, Thomas and me to finalize this revision. So my remarks are for them, first and foremost. I'll list every issue and what I propose to do with it since some issues are controversial, we will need to postpone the update until after Brian returns. I have a couple of issues to add. Note that Brian appended an edited version of the I-D but I removed the appendage from this note because it is quite long. Here are Brian's issues: 1. ISSUE 1: I agree that we make this change. 2. ISSUE 2: ditto 3. ISSUE 3: I don't understand this since we need some value for interoperability testing. 4. ISSUE 4: I agree that we make this change 5. ISSUE 5: I think we should discuss this after the IETF meeting 6. ISSUE 6: I agree wholeheartedly that we always match the Phase 2 DOI the Phase 1 7. ISSUE 7: I agree 8. ISSUE 8: I personally disagree and want to discuss after the IETF meeting 9. ISSUE 9: Thomas, your contact information, please 10. ISSUE 10: I disagree and want to discuss after the IETF meeting 11. ISSUE 11: I strongly disagree and want to discuss after the IETF meeting The other issues that I have are with the front-matter of GDOI revision 00: I think we should remove everything that is redundant to draft-ietf-msec-gkmarch-00.txt and refer to this draft for the model we are using. Mark >Sender: bew@cisco.com >Date: Sat, 30 Jun 2001 11:26:58 -0700 >From: Brian Weis >X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) >X-Accept-Language: en >To: mbaugher@cisco.com, Hugh Harney , > Thomas Hardjono >Subject: Proposed updates to GDOI draft > >Greetings, fellow GDOI draft authors. > >We're about 3 weeks away from the final ID submission date for the >London >IETF. There are a number of issues which should be dealt with so that we >can >submit a -01 version of GDOI for London. > >Having said that, I begin a 2 week vacation on Monday, and won't be in a >location where there is easy Internet access, so I may miss most of the >discussion. :-( I will listen to voice mail occasionally, and will >return phone >calls as best I can. But this is rural N.D., and even though the >telephone >switches have been upgraded from rotary-only, one is still not >guaranteed to >have a touch tone phone available in the house. :-) > >I apologize in advance for not starting this discussion earlier. >However, I have enclosed a list of issues that I've kept since the >last IETF, along with proposed resolutions and text. Also, for >convenience >I've attached a text version of -00 with these changes so you can see >them >inline. Please comment on them, tear my logic and text apart as you >will, etc. > >Please introduce new issues to the discussion as you see fit. Mark has >kindly >agreed to edit the document in my absence. > >I propose that we do not attempt to harmonize with the new GKM Arch. >document >until after the London meeting, since it appears to be a bit >controversial. > >If you all come to agreement before my return and feel the need to >submit the >-01 draft, please do so. Otherwise, I return on 7/16 and will have >until 7/20 >to submit it. It will be on the top of my priority list. > >Thanks, >Brian > >ISSUE 1 >------- >Section 5.4. The SA_TEK payload doesn't really need RESERVED (3) for >alignment. The next field isn't aligned anyway due to the free-form >length of >the ID (which is usually 4 bytes, putting the starting point at the 2nd >byte >of the word). I propose replacing the current bitmap diagram with this: > >======== BEGIN TEXT > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! > ! Next Payload ! RESERVED ! Payload Length ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! > ! Protocol-ID ! TEK Protocol-Specific Payload ~ > +-+-+-+-+-+-+-+-+ ~ > ~ ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! >======== END TEXT > >ISSUE 2 >------- >Format of keys in the KD payload is under-specified, for both encryption >keys >and authentication keys. For example, there could be questions as to >whether >the keys sent bitwise or in an ASCII representation of them, and in the >case >of DES are parity bits included or not. The following sections attempt >to >address these ambiguities. > >For section 5.5.1.1 (encryption keys): > >======== BEGIN TEXT >DES keys will consist of 64 bits (the 56 key bits with parity bits). >Triple DES >keys will be be specified as 64 bit keys in the order that they are to >be used >for encryption (e.g., DES_KEY1, DES_KEY2, DES_KEY3). >======== END TEXT > >Similarly, in section 5.5.1.3 (authentication keys): > >======== BEGIN TEXT >SHA keys will consist of 160 bits, and MD5 keys will consist of 128 >bits. >======== END TEXT > >ISSUE 3 >------- >There's a problem with the DOI number in Section 5.2. It is currently >specified thusly: > > > o DOI (4 octets) - Is the GDOI, which is value 196 pending > > assignment by the IANA. > >We've chosen a value for our DOI, but in fact we should not be >choosing numbers until IANA assigns us one. Thus should say > >======== BEGIN TEXT > o DOI (4 octets) - TBD pending assignment by the IANA. >======== END TEXT > >But IANA won't assign us one until we are further along in the standards >process. We have to choose something in the meantime for interop >testing. > >The right way to do that is to define a new vendor-id payload as part of >Phase 1 which specifies a local context in which to interpret >non-assigned >numbers. I proposed we delay that until the next draft version. Or, we >can >model one after the XAUTH draft now, if you feel it should be done >for this draft. > >ISSUE 4 >------- >Regarding this semantic of the KD payload in section 5.5: > > > If the "Number of Key Packets" is zero, the group member is expected to > > delete all keys associated with the ID. This type of KD payload will > > only be sent by the GCKS when a group is deleted. > >Early on we discussed replacing the following semantic with an IKE >Delete >payload. I would like to do that now. I don't really like having an >implicit >semantic to delete keys; it might be efficient, but it's prone to both >specification and implementation error. The Delete payload is defined in >RFC 2408 section 3.15, and basically sends a list of SPIs to delete. > >I propose removing the text above, and adding a section 4.5. > >======== BEGIN TEXT >4.5 Deletion of SAs > >There are times the GCKS may want to signal to receivers to delete SAs, >for >example at the end of a broadcast when no more data will be sent to the >group. >Deletion of keys may be accomplished by sending an ISAKMP Delete payload >as >part of a GDOI GROUPKEY-PUSH message. >======== END TEXT > >ISSUE 5 >------- >If no KEK is defined, then the SEQ payload is not needed. Today a group >which >doesn't use a KEK is forced to carry the SEQ as unnecessary baggage. > >This could be fixed by making the SEQ payload optional. But then the >implementation has to keep track of whether it needs to send it or not >(i.e., >if it's sending a KEK). Note that the HASH(4) is also changed slightly >if SEQ >is made optional, but HASH(4) already has some optional payloads in it. > >If you believe the extra complexity is worth adding in order to make the >non-KEK case correct, I propose modifying the exchange thusly: > >======== BEGIN TEXT > Initiator (Member) Responder (GCKS) > ------------------ ---------------- > HDR*, HASH(1), Ni, ID --> > <-- HDR*, HASH(2), Nr, SA > HDR*, HASH(3) [, KE_I] --> > [,CERT] [,POP_I] > <-- HDR*, HASH(4), [KE_R,] [SEQ,] > KD [,CERT] [,POP_R] >Hashes are computed as follows: > HASH(1) = prf(SKEYID_a, M-ID | Ni | ID) > HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA) > HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_I ] [ | POP_I ]) > HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_R ] [ | SEQ ] | >KD > [ | POP_R]) >======== END TEXT > >ISSUE 6 >------- >In section 2.4 it should be mentioned that if GDOI sets up the IKE Phase >1, >that the DOI in the IKE Phase 1 SA payload should be the GDOI value (not >the >IPSEC value). I've added the following new sub-section to declare this. > >======== BEGIN TEXT > >2.4.1 IKE Phase 1 SA Payload > >The IKE Phase 1 SA payload has a DOI value. That value should be the >GDOI DOI >value as defined later in this document. >======== END TEXT > >ISSUE 7 >------- >In section 5.4 the Protocol-ID field for the TEK payload is currently >defined >based on the IPSec protocol list (e.g., PROTO_IPSEC_ESP is 4 which >matches >RFC 2407). However, as we want to support other non-IPSec protocols we >can't >re-use the address space. I propose replacing the existing list with the >following new set of identifiers: > >======== BEGIN TEXT > Protocol ID Value > ----------- ----- > RESERVED 0 > GDOI_PROTO_IPSEC_ESP 1 > GDOI_PROTO_MESP 2 > GDOI_PROTO_AMESP 3 > GDOI_PROTO_SRTP 4 > RESERVED 5-127 > PRIVATE USE 128-255 >======== END TEXT > >ISSUE 8 >------- >Steve Kent pointed out at the last IETF that Attribute Certs don't have >a >pubkey in them, so by extension the GROUPKEY-PULL exchange doesn't need >the >POP payload to go with the CERT. I see the following alternatives: > a. Remove the POP. This requires the keypair used for authentication >to be > used for authorization, which is a certain limitation. > b. Require the authorization keypair to be separate. This requires >us to > extend the (CERT, POP) pair in the exchange to be a triple > (AUTHENT_CERT, AUTHOR_CERT, POP) where the AUTHENT_CERT carries >the > pubkey associated with the private key used to sign the POP, and > AUTHOR_CERT is the attribute cert. That's quite a lot of >overhead! > c. Combine the whole mess into a new AUTH payload which can be >defined in > many ways. This would also allow other methods of authorization >which > are not public key based (e.g., send a user entered PIN). > >I favor c. It would modify the GROUPKEY-PULL exchange like this: > >======== BEGIN TEXT > Initiator (Member) Responder (GCKS) > ------------------ ---------------- > HDR*, HASH(1), Ni, ID --> > <-- HDR*, HASH(2), Nr, SA > HDR*, HASH(3) [, KE_I] --> > [,AUTHOR] > <-- HDR*, HASH(4), [KE_R,] [SEQ,] > KD [,AUTHOR] >Hashes are computed as follows: > HASH(1) = prf(SKEYID_a, M-ID | Ni | ID) > HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA) > HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_I ] [ | AUTHOR ]) > HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_R ] [ | SEQ ] | >KD > [ | AUTHOR]) >* Protected by IKE Phase 1 SA, encryption occurs after HDR >======== END TEXT > >The following text defining the Authorization payload replaces section >5.7 "Proof of Possession" which would be no longer needed. (There are >other >edits needed to to remove the POP throughout the document, but I'll omit >those >until there's agreement that this is the right approach.) > >NOTE: I didn't include a SPKI variety of authorization cert because I >think >the authorization is bound in the authentication certificate, so no >separate >AUTHOR cert would be needed. If that is wrong, please add that type and >some >appropriate text. > >======== BEGIN TEXT >5.7 Authorization Payload > >The Authorization Payload (AUTHOR) provides an authorization mechanism >for the >GCKS to verify that a group member is authorized to join a group. It is >also >used by a group member to verify that a GCKS is authorized to serve keys >for a >group. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! > ! Next Payload ! RESERVED ! Payload Length ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Auth Type ! Authorization Payload ~ > +-+-+-+-+-+-+-+-+ ~ > ~ ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! > > The Authorization Payload fields are defined as follows: > > o Next Payload (1 octet) - Identifier for the payload type of the >next payload in the message. If the current payload is the last in the >message, then this field will be zero. > > o RESERVED (1 octet) - Unused, set to zero. > > o Payload Length (2 octets) - Length in octets of the current >payload, including the generic payload header. > > o Auth Type (1 octet) - This field defines the type of authorization >which >is to be used for the group. > > Auth Type Value > --------- ----- > X.509_ATTRIBUTE_CERT 1 > PASSWORD 2 > RESERVED 3-127 > Private Use 128-255 > > o Authorization Payload (varies) - The actual authorization data. >The >following sections define those payloads by type. > >5.7.1 X.509_ATTRIBUTE_CERT > >The authorization payload contains the Attribute Certificate as defined >in [FH] >[NOTE: reference points to draft-ietf-pkix-ac509prof-06.txt]. > >The Attribute Certification must have a critical extension which >declares the group id (format TBD). > >5.7.1 PASSWORD > >The authorization payload contains the following structure: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! > ! Length ! Password ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ > ~ ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! > >The password field structure is defined as follows: > > o Length (2 octets) - Length of the password. > > o Password (variable) - Password Data >======== END TEXT > >ISSUE 9 >------- >Thomas needs to fill in his new contact info. I've start it so it won't >be >forgotten. > >ISSUE 10 >-------- >Dan Harkins was adamant that we don't use the IKE port for GDOI. I >propose the following section to address that. > >======== BEGIN TEXT >2.4.2 GDOI Port > >In order to enable separation of protocol state machines, GDOI should >not use >the port commonly used by IKE (udp port 500). A port must be assigned by >IANA. >======== END TEXT > >ISSUE 11 >-------- >There are two issue with section 3.2.1 (Perfect Forward Secrecy). I >think it >is easiest to consider them separately. > > a. There is some confusion in the naming, as to whether the function > provided by KE payloads is "perfect forward secrecy" or "perfect > backwards secrecy". This should get sorted out. The intended >property > of KE payloads is that if someone discovers the current IKE >protocol > keys (e.g., through cryptanalysis), they should not be able to > automatically get the next set of keys (in this case, the keys >which are > used to protect the TEK and KEK keys in the KD payload). > > If you can sort out the proper term, please fix the section to use >the > appropriate nomenclature. > > b. There is some disagreement as to why we would need KE payloads at >all. I > believe we need them, and propose the following rationale to be >inserted > at the beginning of section 3.2.1 (before the current paragraph). > >======== BEGIN TEXT >PFS may be necessary in some scenarios. The GROUPKEY-PULL exchange is >protected by the IKE Phase 1 encryption keys, as is the IKE Phase 2 >exchange. >It should be noted that in the case of the IKE Phase 2 exchange, no keys >are >ever passed in the exchange -- they are always derived from keying >material that has some secret component (e.g., from a previous DH >exchange). >However, the IPSec working group still saw it necessary that there >should be a >mechanism for refreshing the hidden keying material (through use of the >KE >payloads). > >With PFS protection, the risk to the KEK and TEK keys is far greater for >the >GDOI GROUPKEY-PULL exchange. The keys are passed directly from the GCKS >to the >group member in the KD payload. A passive attacker can store GDOI >GROUPKEY-PULL >packets as well as the data packets and attempt to break the IKE Phase 1 >encryption keys. Once that is done, the attacker has direct access to >the KEK >and TEK keys stored in the KD payload and can then decrypt the stored >content >for as long as the discovered KEK key is used. > >Use of the KD payloads complicates this attack by causing the attacker >to >perform further cryptanalysis to determine the keying derived from the >KD >payload." >======== END TEXT > >ISSUE 12 >-------- >Mark has developed an Appendix which describes how to pass SRTP policy >in >GDOI, just as Appendix A describes how to pass MESP/AMESP policy in >GDOI. >This should be added to this draft. > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jul 5 09:43:52 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12361 for ; Thu, 5 Jul 2001 09:43:51 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1CE6253745; Thu, 5 Jul 2001 09:44:06 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 990705355B for ; Thu, 5 Jul 2001 09:43:10 -0400 (EDT) Received: (qmail 29861 invoked by uid 3269); 5 Jul 2001 13:43:10 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 29858 invoked from network); 5 Jul 2001 13:43:09 -0000 Received: from softdnserror (HELO M5.sparta.com) (root@157.185.61.1) by klesh.pair.com with SMTP; 5 Jul 2001 13:43:09 -0000 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by M5.sparta.com (8.11.0/8.11.0) with ESMTP id f65Dh7x21317; Thu, 5 Jul 2001 08:43:07 -0500 Received: from robin (robin.columbia.sparta.com [157.185.80.228]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id JAA17668; Thu, 5 Jul 2001 09:42:56 -0400 (EDT) Message-Id: <4.2.2.20010705092318.00b35cc0@pop.columbia.sparta.com> X-Sender: hh@pop.columbia.sparta.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 To: Mark Baugher From: Hugh Harney Subject: Re: [MSEC] msec architecture draft and email flow Cc: msec@securemulticast.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1728105430==_.ALT" 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, 05 Jul 2001 09:23:30 -0400 --=====================_1728105430==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Mark, Sorry about the delay. I've been writing and reviewing like mad. >>>>Bullet two is critical for a joining member to trust the key. It should >>>>be inside. This is an extension of the explicitness principle. If you >>>>are using an attribute certificate (or delegation cert) then this is >>>>passed via an LDAP or certificate payload. In either case the KM >>>>protocol needs to review that certificate and determine the GCKS is >>>>authorized. It is still part of the KM protocol. >>> >>>By virtue of the fact that a member is contacting a KDC/GCKS, it seems >>>that we have resolved the question of who the KDC/GCKS is. What am I >>>missing? How would this identification of policy take place within key >>>management? >> >>Anyone can reply to a join/registration request. We need to know that >>whomever replies is authorized to handout key for the group. > >Or the member can direct the request to the authorized server based on, >say, a secure website or email attachment. There could be a Session >Description Protocol (SDP) announcement that gets sent as securely as it >needs to be that causes the member to contact the correct GCKS. So this >request is often out-of-band from the key management protocol for a lot of >interesting applications. There is value in keeping a data structure that explicitly states all relevant security policy for a group. As per my contribution to this section of the GDOI document, I don't mandate the delivery mechanisms to get policy information to ALL policy enforcement agents in the group, but I do believe the policy must be enforced. Essentially, I believe that the group key management entities have to enforce all relevant policy. That policy may be posted, sent in the KM protocol, or known a priori. I don't necessarily mandate in band transmission of policy, but it does make the KM protocol self sufficient. I do see value in having an optional payload for policy information. >>It is critical to the acceptance of the key to know that the GC/KS is >>authorized to hand out the key. This is something that has to be enforced >>by the joining member. The decision has to be based on some security >>policy (singed by the GO) that the member has received. Yes, we can use >>attribute/delegation certificates, but the member must enforce the >>authorization policy before it can trust the key. > >And the KDC/GCKS must enforce the policy before it can trust the member. My point was that GCKS and group members both have policy enforcement roles. >>This is different from IKE or pairwise key management protocols. Peer >>protocols are talking to the entity they will be using the key with. They >>directly exchange signed certificates with the other side. The >>verirfication of the certificate implies authorization to create key for >>that party. The know who they are talking to. In groups we are accepting >>a key download on behalf of an abstract GSA. > >"GSA" or "GO?" I don't understand this abstraction. In GDOI, the >KDC/GCKS exchanges credentials (performs authorization and authentication) >with the member in pairwise key exchange (IKE Phase 1) and then the >KDC/GCKS downloads a key on behalf of the group owner (GDOI Phase 2). As >you know, the Phase 2 can have an identity with a proof of >possession. The identity for the member is a credential that shows >authorization from the group owner to get key material (e.g., KEK, TEKs) >for the group. The identity for the KDC/GCKS shows authorization from the >group owner to give key material to prospective members of the >group. This latter credential may be delegated. I agree with your example for authorization to download key only. However, this does not give the member enough information to determine if the members data should be shared with the group. I think every entity in a group that owns data, must be able to determine if the group is adequate to protect that data. This means that every data owning entity needs to see full group protection mechanisms, full access control rules ... This was all listed in the Group Policy Building Block I-D. The link however has been killed. I think many of my positions on policy enforcement may also be explained in more detail in the following: "Principles of Policy in Secure Groups" presented at NDSS '01. The url is http://www.eecs.umich.edu/~pdmcdan/docs/ndss01.pdf. >>>>Bullet 3 is critical only if the group members are going to be adding >>>>data to the group. The data contributors must be able to review the >>>>access control criteria to determine if their data is protected by that >>>>criteria. >>> >>>Would you see this as being necessarily inside of the key management >>>protocol? It might be useful to list the policy items that are inside GSAKMP. >> >>For multi source groups it is essential to be in the KM protocol. This >>again relates to the abstract nature of the group. I'm accepting a key >>from an authorized source. That key is to be used to protect my data. >>Without the inclusion of this security policy information, all I know is >>that I'm authorized to have the key to this group. What I need (as a data >>sharing member) is knowledge of how much other members may be trusted. If >>they have the key they have access to my data. > >I say "trusted with what" rather than "how much other members may be >trusted." Can they be trusted with the data I might send to this >group? Can they be trusted to give me data that I may use? > >A multi-source group is protected by a data security SA. What goes into >this is peculiar to the data security protocol (viz. the Appendices in the >GDOI draft). I agree that you statement is more precise. How about this for more precision. The security policy must be specific enough for a data owning group member to determine what data I may share with the members of this group, using these mechanisms to protect that data, and with these entities making security relevant management decisions. >>The example I use is my bank asking me to share my SSN via a group key. I >>trust the bank, I trust myself, but I don't know who they gave the key >>to. If they tell me that the key is held by the bank, the IRS, and myself >>I'll send my SSN. If they tell me the key is held by all customers of the >>bank I'd balk. >> >>The access control rules have to be disclosed to any member risking >>personal data on that key. Again, If I'm just listening passively no >>problem (then I wouldn't need to know the access rules). > >Does this need a representation in group key management? In many applications, yes. This is far more tractable if we use access control rules, in stead of a list. >>>>Hey we may agree soon. Then where will the fun be? >>> >>>In making progress. We would make a lot of progress if we could merge >>>GSAKMP and GDOI into one protocol. >> >>Mark this was a joke. Yes convergence of GDOI and GSAKMP would be great. > >Or at least, we could work towards interoperability if we used the same >header. GDOI needs to support an ISAKMP header since it is an IKE >DOI. Why can't GSAKMP use an ISAKMP header? I'm going to release a simpler profile of GSAKMP soon. I think we may be closer to a merged protocol effort than we think. I'm looking into your suggestions. Hugh ________________________________________________________ Hugh Harney hh@sparta.com 410-381-9400 x203 ________________________________________________________ --=====================_1728105430==_.ALT Content-Type: text/html; charset="us-ascii" Mark,

Sorry about the delay. I've been writing and reviewing like mad.
Bullet two is critical for a joining member to trust the key. It should be inside. This is an extension of the explicitness principle. If you are using an attribute certificate (or delegation cert) then this is passed via an LDAP or certificate payload. In either case the KM protocol needs to review that certificate and determine the GCKS is authorized. It is still part of the KM protocol.

By virtue of the fact that a member is contacting a KDC/GCKS, it seems that we have resolved the question of who the KDC/GCKS is.  What am I missing?  How would this identification of policy take place within key management?

Anyone can reply to a join/registration request. We need to know that whomever replies is authorized to handout key for the group.

Or the member can direct the request to the authorized server based on, say, a secure website or email attachment.  There could be a Session Description Protocol (SDP) announcement that gets sent as securely as it needs to be that causes the member to contact the correct GCKS.  So this request is often out-of-band from the key management protocol for a lot of interesting applications.


There is value in keeping a data structure that explicitly states all relevant security policy for a group. As per my contribution to this section of the GDOI document, I don't mandate the delivery mechanisms to get policy information to ALL policy enforcement agents in the group, but I do believe the policy must be enforced.

Essentially, I believe that the group key management entities have to enforce all relevant policy. That policy may be posted, sent in the KM protocol, or known a priori. I don't necessarily mandate in band transmission of policy, but it does make the KM protocol self sufficient. I do see value in having an optional payload for policy information.


It is critical to the acceptance of the key to know that the GC/KS is authorized to hand out the key. This is something that has to be enforced by the joining member. The decision has to be based on some security policy (singed by the GO) that the member has received. Yes, we can use attribute/delegation certificates, but the member must enforce the authorization policy before it can trust the key.

And the KDC/GCKS must enforce the policy before it can trust the member.

My point was that GCKS and group members both have policy enforcement roles.


This is different from IKE or pairwise key management protocols. Peer protocols are talking to the entity they will be using the key with. They directly exchange signed certificates with the other side. The verirfication of the certificate implies authorization to create key for that party. The know who they are talking to. In groups we are accepting a key download on behalf of an abstract GSA.

"GSA" or "GO?"  I don't understand this abstraction.  In GDOI, the KDC/GCKS exchanges credentials (performs authorization and authentication) with the member in pairwise key exchange (IKE Phase 1) and then the KDC/GCKS downloads a key on behalf of the group owner (GDOI Phase 2).  As you know, the Phase 2 can have an identity with a proof of possession.  The identity for the member is a credential that shows authorization from the group owner to get key material (e.g., KEK, TEKs) for the group.  The identity for the KDC/GCKS shows authorization from the group owner to give key material to prospective members of the group.  This latter credential may be delegated.

I agree with your example for authorization to download key only. However, this does not give the member enough information to determine if the members data should be shared with the group.

I think every entity in a group that owns data, must be able to determine if the group is adequate to protect that data. This means that every data owning entity needs to see full group protection mechanisms, full access control rules ... This was all listed in the Group Policy Building Block I-D. The link however has been killed.

I think many of my positions on policy enforcement may also be explained in more detail in the following: "Principles of Policy in Secure Groups" presented at NDSS '01. The url is http://www.eecs.umich.edu/~pdmcdan/docs/ndss01.pdf.

Bullet 3 is critical only if the group members are going to be adding data to the group. The data contributors must be able to review the access control criteria to determine if their data is protected by that criteria.

Would you see this as being necessarily inside of the key management protocol?  It might be useful to list the policy items that are inside GSAKMP.

For multi source groups it is essential to be in the KM protocol. This again relates to the abstract nature of the group. I'm accepting a key from an authorized source. That key is to be used to protect my data. Without the inclusion of this security policy information, all I know is that I'm authorized to have the key to this group. What I need (as a data sharing member) is knowledge of how much other members may be trusted. If they have the key they have access to my data.

I say "trusted with what" rather than "how much other members may be trusted."  Can they be trusted with the data I might send to this group?  Can they be trusted to give me data that I may use?

A multi-source group is protected by a data security SA.  What goes into this is peculiar to the data security protocol (viz. the Appendices in the GDOI draft).

I agree that you statement is more precise. How about this for more precision. The security policy must be specific enough for a data owning group member to determine what data I may share with the members of this group, using these mechanisms to protect that data, and with these entities making security relevant management decisions.


The example I use is my bank asking me to share my SSN via a group key. I trust the bank, I trust myself, but I don't know who they gave the key to. If they tell me that the key is held by the bank, the IRS, and myself I'll send my SSN. If they tell me the key is held by all customers of the bank I'd balk.

The access control rules have to be disclosed to any member risking personal data on that key. Again, If I'm just listening passively no problem (then I wouldn't need to know the access rules).

Does this need a representation in group key management?

In many applications, yes. This is far more tractable if we use access control rules, in stead of a list.



Hey we may agree soon. Then where will the fun be?

In making progress.  We would make a lot of progress if we could merge GSAKMP and GDOI into one protocol.

Mark this was a joke. Yes convergence of GDOI and GSAKMP would be great.

Or at least, we could work towards interoperability if we used the same header.  GDOI needs to support an ISAKMP header since it is an IKE DOI.  Why can't GSAKMP use an ISAKMP header?

I'm going to release a simpler profile of GSAKMP soon. I think we may be closer to a merged protocol effort than we think. I'm looking into your suggestions.

Hugh




________________________________________________________
Hugh Harney             hh@sparta.com           410-381-9400 x203
________________________________________________________ --=====================_1728105430==_.ALT-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jul 5 12:53:03 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19462 for ; Thu, 5 Jul 2001 12:53:02 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A4CDF535A3; Thu, 5 Jul 2001 12:53:15 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 6C05D53556 for ; Thu, 5 Jul 2001 12:50:12 -0400 (EDT) Received: (qmail 48803 invoked by uid 3269); 5 Jul 2001 16:50:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 48794 invoked from network); 5 Jul 2001 16:50:07 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by klesh.pair.com with SMTP; 5 Jul 2001 16:50:07 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f65GlnH03906; Thu, 5 Jul 2001 09:47:50 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-585.cisco.com [10.21.66.73]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AEC00073; Thu, 5 Jul 2001 09:49:21 -0700 (PDT) Message-Id: <4.3.2.7.2.20010705092420.04350448@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Hugh Harney From: Mark Baugher Subject: Re: [MSEC] msec architecture draft and email flow Cc: msec@securemulticast.org In-Reply-To: <4.2.2.20010705092318.00b35cc0@pop.columbia.sparta.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_184941181==_.ALT" 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, 05 Jul 2001 09:48:45 -0700 --=====================_184941181==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hugh I'm taking some time away from editing the next GDOI I-D. The crux of the matter we're discussing IMHO is what gets enforced in key management and what gets enforced in the application that uses/incorporates key management. I did get your point, however, that policy is important for the joining member as it is with the KDC/GCKS that admits the member. With our emphasis on source-specific multicast applications where receiving members dominate, I tend to overlook the needs of the sending member(s), which tend to be specially managed in source-specific multicast applications such as video broadcast. I admit that policy is important for members. The word "policy," however, means much different things in different contexts. For all practical purposes, most policy is outside ISAKMP/IKE where policy definition is restricted to SA/Proposal/Transform payloads (Section 3.6 in http://www.ietf.org/rfc/rfc2408.txt). That's a good thing in at least one way: A variety of applications can use ISAKMP/IKE without having to understand the policies of other applications that use ISAKMP/IKE. In group key management, we have the same diversity because it can be used among a group of four routers, fifteen military conferencers, or millions of TV viewers. It may be that one group key management system cannot support such diverse environments. But if one can, it will make minimal assumptions regarding policy: It may be that collecting the identities of fifteen generals just does not scale to collecting the identities of TV viewers. In fact, I'm sure this is true. Best Regards, Mark At 09:23 AM 7/5/2001 -0400, Hugh Harney wrote: >Mark, > >Sorry about the delay. I've been writing and reviewing like mad. >>>>>Bullet two is critical for a joining member to trust the key. It >>>>>should be inside. This is an extension of the explicitness principle. >>>>>If you are using an attribute certificate (or delegation cert) then >>>>>this is passed via an LDAP or certificate payload. In either case the >>>>>KM protocol needs to review that certificate and determine the GCKS is >>>>>authorized. It is still part of the KM protocol. >>>> >>>>By virtue of the fact that a member is contacting a KDC/GCKS, it seems >>>>that we have resolved the question of who the KDC/GCKS is. What am I >>>>missing? How would this identification of policy take place within key >>>>management? >>> >>>Anyone can reply to a join/registration request. We need to know that >>>whomever replies is authorized to handout key for the group. >> >>Or the member can direct the request to the authorized server based on, >>say, a secure website or email attachment. There could be a Session >>Description Protocol (SDP) announcement that gets sent as securely as it >>needs to be that causes the member to contact the correct GCKS. So this >>request is often out-of-band from the key management protocol for a lot >>of interesting applications. > > >There is value in keeping a data structure that explicitly states all >relevant security policy for a group. As per my contribution to this >section of the GDOI document, I don't mandate the delivery mechanisms to >get policy information to ALL policy enforcement agents in the group, but >I do believe the policy must be enforced. > >Essentially, I believe that the group key management entities have to >enforce all relevant policy. That policy may be posted, sent in the KM >protocol, or known a priori. I don't necessarily mandate in band >transmission of policy, but it does make the KM protocol self sufficient. >I do see value in having an optional payload for policy information. > > >>>It is critical to the acceptance of the key to know that the GC/KS is >>>authorized to hand out the key. This is something that has to be >>>enforced by the joining member. The decision has to be based on some >>>security policy (singed by the GO) that the member has received. Yes, we >>>can use attribute/delegation certificates, but the member must enforce >>>the authorization policy before it can trust the key. >> >>And the KDC/GCKS must enforce the policy before it can trust the member. > >My point was that GCKS and group members both have policy enforcement roles. > > >>>This is different from IKE or pairwise key management protocols. Peer >>>protocols are talking to the entity they will be using the key with. >>>They directly exchange signed certificates with the other side. The >>>verirfication of the certificate implies authorization to create key for >>>that party. The know who they are talking to. In groups we are accepting >>>a key download on behalf of an abstract GSA. >> >>"GSA" or "GO?" I don't understand this abstraction. In GDOI, the >>KDC/GCKS exchanges credentials (performs authorization and >>authentication) with the member in pairwise key exchange (IKE Phase 1) >>and then the KDC/GCKS downloads a key on behalf of the group owner (GDOI >>Phase 2). As you know, the Phase 2 can have an identity with a proof of >>possession. The identity for the member is a credential that shows >>authorization from the group owner to get key material (e.g., KEK, TEKs) >>for the group. The identity for the KDC/GCKS shows authorization from >>the group owner to give key material to prospective members of the >>group. This latter credential may be delegated. > >I agree with your example for authorization to download key only. However, >this does not give the member enough information to determine if the >members data should be shared with the group. > >I think every entity in a group that owns data, must be able to determine >if the group is adequate to protect that data. This means that every data >owning entity needs to see full group protection mechanisms, full access >control rules ... This was all listed in the Group Policy Building Block >I-D. The link however has been killed. > >I think many of my positions on policy enforcement may also be explained >in more detail in the following: "Principles of Policy in Secure Groups" >presented at NDSS '01. The url is >http://www.eecs.umich.edu/~pdmcdan/docs/ndss01.pdf. > >>>>>Bullet 3 is critical only if the group members are going to be adding >>>>>data to the group. The data contributors must be able to review the >>>>>access control criteria to determine if their data is protected by >>>>>that criteria. >>>> >>>>Would you see this as being necessarily inside of the key management >>>>protocol? It might be useful to list the policy items that are inside GSAKMP. >>> >>>For multi source groups it is essential to be in the KM protocol. This >>>again relates to the abstract nature of the group. I'm accepting a key >>>from an authorized source. That key is to be used to protect my data. >>>Without the inclusion of this security policy information, all I know is >>>that I'm authorized to have the key to this group. What I need (as a >>>data sharing member) is knowledge of how much other members may be >>>trusted. If they have the key they have access to my data. >> >>I say "trusted with what" rather than "how much other members may be >>trusted." Can they be trusted with the data I might send to this >>group? Can they be trusted to give me data that I may use? >> >>A multi-source group is protected by a data security SA. What goes into >>this is peculiar to the data security protocol (viz. the Appendices in >>the GDOI draft). > >I agree that you statement is more precise. How about this for more >precision. The security policy must be specific enough for a data owning >group member to determine what data I may share with the members of this >group, using these mechanisms to protect that data, and with these >entities making security relevant management decisions. > > >>>The example I use is my bank asking me to share my SSN via a group key. >>>I trust the bank, I trust myself, but I don't know who they gave the key >>>to. If they tell me that the key is held by the bank, the IRS, and >>>myself I'll send my SSN. If they tell me the key is held by all >>>customers of the bank I'd balk. >>> >>>The access control rules have to be disclosed to any member risking >>>personal data on that key. Again, If I'm just listening passively no >>>problem (then I wouldn't need to know the access rules). >> >>Does this need a representation in group key management? > >In many applications, yes. This is far more tractable if we use access >control rules, in stead of a list. > > > >>>>>Hey we may agree soon. Then where will the fun be? >>>> >>>>In making progress. We would make a lot of progress if we could merge >>>>GSAKMP and GDOI into one protocol. >>> >>>Mark this was a joke. Yes convergence of GDOI and GSAKMP would be great. >> >>Or at least, we could work towards interoperability if we used the same >>header. GDOI needs to support an ISAKMP header since it is an IKE >>DOI. Why can't GSAKMP use an ISAKMP header? > >I'm going to release a simpler profile of GSAKMP soon. I think we may be >closer to a merged protocol effort than we think. I'm looking into your >suggestions. > >Hugh > > > > >________________________________________________________ >Hugh Harney hh@sparta.com 410-381-9400 x203 >________________________________________________________ --=====================_184941181==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hugh
   I'm taking some time away from editing the next GDOI I-D.  The crux of the matter we're discussing IMHO is what gets enforced in key management and what gets enforced in the application that uses/incorporates key management.  I did get your point, however, that policy is important for the joining member as it is with the KDC/GCKS that admits the member.  With our emphasis on source-specific multicast applications where receiving members dominate, I tend to overlook the needs of the sending member(s), which tend to be specially managed in source-specific multicast applications such as video broadcast.  I admit that policy is important for members.

  The word "policy," however, means much different things in different contexts.  For all practical purposes, most policy is outside ISAKMP/IKE where policy definition is restricted to SA/Proposal/Transform payloads (Section 3.6 in http://ww= w.ietf.org/rfc/rfc2408.txt).  That's a good thing in at least one way:  A variety of applications can use ISAKMP/IKE without having to understand the policies of other applications that use ISAKMP/IKE.  In group key management, we have the same diversity because it can be used among a group of four routers, fifteen military conferencers, or millions of TV viewers.  It may be that one group key management system cannot support such diverse environments.  But if one can, it will make minimal assumptions regarding policy:  It may be that collecting the identities of fifteen generals just does not scale to collecting the identities of TV viewers.  In fact, I'm sure this is true.

Best Regards, Mark

At 09:23 AM 7/5/2001 -0400, Hugh Harney wrote:
Mark,

Sorry about the delay. I've been writing and reviewing like mad.
Bullet two is critical for a joining member to trust the key. It should be inside. This is an extension of the explicitness principle. If you are using an attribute certificate (or delegation cert) then this is passed via an LDAP or certificate payload. In either case the KM protocol needs to review that certificate and determine the GCKS is authorized. It is still part of the KM protocol.

By virtue of the fact that a member is contacting a KDC/GCKS, it seems that we have resolved the question of who the KDC/GCKS is.  What am I missing?  How would this identification of policy take place within key management?

Anyone can reply to a join/registration request. We need to know that whomever replies is authorized to handout key for the group.

Or the member can direct the request to the authorized server based on, say, a secure website or email attachment.  There could be a Session Description Protocol (SDP) announcement that gets sent as securely as it needs to be that causes the member to contact the correct GCKS.  So this request is often out-of-band from the key management protocol for a lot of interesting applications.


There is value in keeping a data structure that explicitly states all relevant security policy for a group. As per my contribution to this section of the GDOI document, I don't mandate the delivery mechanisms to get policy information to ALL policy enforcement agents in the group, but I do believe the policy must be enforced.

Essentially, I believe that the group key management entities have to enforce all relevant policy. That policy may be posted, sent in the KM protocol, or known a priori. I don't necessarily mandate in band transmission of policy, but it does make the KM protocol self sufficient. I do see value in having an optional payload for policy=20 information.


It is critical to the acceptance of the key to know that the GC/KS is authorized to hand out the key. This is something that has to be enforced by the joining member. The decision has to be based on some security policy (singed by the GO) that the member has received. Yes, we can use attribute/delegation certificates, but the member must enforce the authorization policy before it can trust the key.

And the KDC/GCKS must enforce the policy before it can trust the member.

My point was that GCKS and group members both have policy enforcement roles.


This is different from IKE or pairwise key management protocols. Peer protocols are talking to the entity they will be using the key with. They directly exchange signed certificates with the other side. The verirfication of the certificate implies authorization to create key for that party. The know who they are talking to. In groups we are accepting a key download on behalf of an abstract GSA.

"GSA" or "GO?"  I don't understand this abstraction.  In GDOI, the KDC/GCKS exchanges credentials (performs authorization and authentication) with the member in pairwise key exchange (IKE Phase 1) and then the KDC/GCKS downloads a key on behalf of the group owner (GDOI Phase 2).  As you know, the Phase 2 can have an identity with a proof of possession.  The identity for the member is a credential that shows authorization from the group owner to get key material (e.g., KEK, TEKs) for the group.  The identity for the KDC/GCKS shows authorization from the group owner to give key material to prospective members of the group.  This latter credential may be delegated.

I agree with your example for authorization to download key only. However, this does not give the member enough information to determine if the members data should be shared with the group.

I think every entity in a group that owns data, must be able to determine if the group is adequate to protect that data. This means that every data owning entity needs to see full group protection mechanisms, full access control rules ... This was all listed in the Group Policy Building Block I-D. The link however has been killed.

I think many of my positions on policy enforcement may also be explained in more detail in the following: "Principles of Policy in Secure Groups" presented at NDSS '01. The url is http://www.eecs.umich.edu/~pdmcdan/docs/ndss01.pdf= .

Bullet 3 is critical only if the group members are going to be adding data to the group. The data contributors must be able to review the access control criteria to determine if their data is protected by that criteria.

Would you see this as being necessarily inside of the key management protocol?  It might be useful to list the policy items that are inside GSAKMP.

For multi source groups it is essential to be in the KM protocol. This again relates to the abstract nature of the group. I'm accepting a key from an authorized source. That key is to be used to protect my data. Without the inclusion of this security policy information, all I know is that I'm authorized to have the key to this group. What I need (as a data sharing member) is knowledge of how much other members may be trusted. If they have the key they have access to my data.

I say "trusted with what" rather than "how much other members may be trusted."  Can they be trusted with the data I might send to this group?  Can they be trusted to give me data that I may use?

A multi-source group is protected by a data security SA.  What goes into this is peculiar to the data security protocol (viz. the Appendices in the GDOI draft).
I agree that you statement is more precise. How about this for more precision. The security policy must be specific enough for a data owning group member to determine what data I may share with the members of this group, using these mechanisms to protect that data, and with these entities making security relevant management decisions.


The example I use is my bank asking me to share my SSN via a group key. I trust the bank, I trust myself, but I don't know who they gave the key to. If they tell me that the key is held by the bank, the IRS, and myself I'll send my SSN. If they tell me the key is held by all customers of the bank I'd balk.

The access control rules have to be disclosed to any member risking personal data on that key. Again, If I'm just listening passively no problem (then I wouldn't need to know the access rules).

Does this need a representation in group key management?

In many applications, yes. This is far more tractable if we use access control rules, in stead of a list.



Hey we may agree soon. Then where will the fun be?

In making progress.  We would make a lot of progress if we could merge GSAKMP and GDOI into one protocol.

Mark this was a joke. Yes convergence of GDOI and GSAKMP would be great.

Or at least, we could work towards interoperability if we used the same header.  GDOI needs to support an ISAKMP header since it is an IKE DOI.  Why can't GSAKMP use an ISAKMP header?
I'm going to release a simpler profile of GSAKMP soon. I think we may be closer to a merged protocol effort than we think. I'm looking into your suggestions.

Hugh




________________________________________________________
Hugh Harney        =      hh@sparta.com   =         410-3= 81-9400 x203
________________________________________________________ --=====================_184941181==_.ALT-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jul 5 15:14:11 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24231 for ; Thu, 5 Jul 2001 15:14:09 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C6ED753565; Thu, 5 Jul 2001 15:14:24 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id C3B375352D for ; Thu, 5 Jul 2001 15:13:36 -0400 (EDT) Received: (qmail 63454 invoked by uid 3269); 5 Jul 2001 19:13:36 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 63451 invoked from network); 5 Jul 2001 19:13:36 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 5 Jul 2001 19:13:36 -0000 Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f65JCqi21610; Thu, 5 Jul 2001 15:12:52 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id PAA48402; Thu, 5 Jul 2001 15:12:52 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id PAA28176; Thu, 5 Jul 2001 15:12:51 -0400 From: Ran Canetti Message-Id: <200107051912.PAA28176@ornavella.watson.ibm.com> To: canetti@watson.ibm.com, mbaugher@cisco.com, rafaeli@comp.lancs.ac.uk Subject: RE: [MSEC] De-registration protocol? Cc: msec@securemulticast.org 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, 5 Jul 2001 15:12:51 -0400 Sandro, you're right that this business model of pay-until-you-say-enough is susceptible to this type of failures. This is indeed something that the application will have to deal with... but this business model seems to be attractive in some cases nonetheless. (one way to mitigate this is to put a cap on the payment amount, on the duration, etc. for instance in a boxing show you never pay more than the full 12 rounds.) Ran > From msec-admin@securemulticast.org Mon Jul 2 06:18:31 2001 > > > Ran, > > Applications are prone to crash when you least expect :(. When that occurs, > paying members may pay much more then they are supposed to for the simple > reason that the de-registration/leave command was never issued. > De-registration/leave command is not enough to control the time a member is > participating in the group... > > Sandro. > > | BTW, Mark, in a model where a member pays acording to the > | time elapsed > | between registration and de-registration, the > | de-registration mechanism > | is not just for being nice. And this is true regardless of how these > | protocols are called... > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jul 5 15:33:47 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24711 for ; Thu, 5 Jul 2001 15:33:47 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6C86D5353E; Thu, 5 Jul 2001 15:34:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 4C8335353E for ; Thu, 5 Jul 2001 15:32:05 -0400 (EDT) Received: (qmail 65059 invoked by uid 3269); 5 Jul 2001 19:32:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 65054 invoked from network); 5 Jul 2001 19:32:04 -0000 Received: from softdnserror (HELO M5.sparta.com) (root@157.185.61.1) by klesh.pair.com with SMTP; 5 Jul 2001 19:32:04 -0000 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by M5.sparta.com (8.11.0/8.11.0) with ESMTP id f65JW3x01032; Thu, 5 Jul 2001 14:32:03 -0500 Received: from [157.185.80.3] (dhcp-2.columbia.sparta.com [157.185.80.3]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id PAA21000; Thu, 5 Jul 2001 15:30:08 -0400 (EDT) Mime-Version: 1.0 X-Sender: cfm@pop.columbia.sparta.com Message-Id: In-Reply-To: <200107051912.PAA28176@ornavella.watson.ibm.com> References: <200107051912.PAA28176@ornavella.watson.ibm.com> To: Ran Canetti , mbaugher@cisco.com, rafaeli@comp.lancs.ac.uk From: "Carl F. Muckenhirn" Subject: RE: [MSEC] De-registration protocol? Cc: msec@securemulticast.org 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: Thu, 5 Jul 2001 15:31:56 -0400 It seems to me that this question of business model has nothing at all to do with key management. One could just as easily saddle the multicast transport system with these requirements. (Seems we are falling into the typical security trap of "well no one else is doing it, why not security!") Ran's comment on mitigations, points the way to a solution, use an application service to manage the billing. One could then effect their service delivery decisions through key management. That seems much more straightforward than trying to effect billing decisions through key management. carl. On 7/5/01 at 3:12 PM -0400, Ran Canetti wrote: >Sandro, you're right that this business model of pay-until-you-say-enough >is susceptible to this type of failures. This is indeed something that the >application will have to deal with... but this business model seems to be >attractive in some cases nonetheless. (one way to mitigate this is to put >a cap on the payment amount, on the duration, etc. for instance in a boxing >show you never pay more than the full 12 rounds.) > >Ran > >> From msec-admin@securemulticast.org Mon Jul 2 06:18:31 2001 >> >> >> Ran, >> >> Applications are prone to crash when you least expect :(. When that occurs, >> paying members may pay much more then they are supposed to for the simple >> reason that the de-registration/leave command was never issued. >> De-registration/leave command is not enough to control the time a member is >> participating in the group... >> >> Sandro. >> >> | BTW, Mark, in a model where a member pays acording to the >> | time elapsed >> | between registration and de-registration, the >> | de-registration mechanism >> | is not just for being nice. And this is true regardless of how these >> | protocols are called... >> >> > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec -- Carl F. Muckenhirn Division Manager SPARTA, Inc. Security Engineering Division 9861 Broken Land Parkway, Suite 300 Columbia, Maryland 21046 410.381.9400 x208 410.381.5559 (fax) _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jul 5 16:11:49 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26015 for ; Thu, 5 Jul 2001 16:11:48 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6B40B5355A; Thu, 5 Jul 2001 16:12:03 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id A7E5D53573 for ; Thu, 5 Jul 2001 16:11:13 -0400 (EDT) Received: (qmail 68863 invoked by uid 3269); 5 Jul 2001 20:11:13 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 68860 invoked from network); 5 Jul 2001 20:11:13 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 5 Jul 2001 20:11:13 -0000 Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f65KATi21696; Thu, 5 Jul 2001 16:10:29 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id QAA90710; Thu, 5 Jul 2001 16:10:29 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id QAA31838; Thu, 5 Jul 2001 16:10:29 -0400 From: Ran Canetti Message-Id: <200107052010.QAA31838@ornavella.watson.ibm.com> To: mcgrew@cisco.com, thardjono@mediaone.net Subject: Re: [MSEC] De-registration protocol? Cc: msec@securemulticast.org 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, 5 Jul 2001 16:10:29 -0400 Thomas, I agree that in some groups it would make sense to maintain a long-lived secure unicast channel between each group member and the GCKS, and in other cases it would make sense to keep only short-term unicast secure channels. This point should probably make it into the gkmarch document. btw, this is another very good reason to keep the de-registration functionality within the scope of msec - to allow this flexibility of design. If we force the application to do de-registration by itself then we lose the ability to use a long-lived msec secure unicast channel for de-registration... Ran > From msec-admin@securemulticast.org Tue Jul 3 18:10:20 2001 > > > David, > > At 7/3/2001||08:54 AM, you wrote: > > > >I'd favor noting the possible need for a member-to-controller channel in the > >architecture, but not spending much short term effort on realizing it. > > > Hmm, this brings-up the (old) issue of how long the Cat-1 SA and secure > channel should be around. > > If we simply want a 1-to-1 secure channel between the member to KDC, > then we already have this (namely, the Cat-1 SA or > Registration/Initialization). > > Even if the "secure channel" was SSL or Ran's IPsec-Tunnel, the question > of the lifetime of the connection remains still. > > And you are absolutely correct is stating that the answer depends > on the size of the group (which to my mind is application-dependent, > and to a some extent depends on the availability of a distributed KDC). > > I think it is the application that will decide the type of data, speed, > capacity or routers/KDCs to hold SAs, etc. > > thomas > ------ > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jul 5 16:27:22 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26577 for ; Thu, 5 Jul 2001 16:27:20 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D54AE5358D; Thu, 5 Jul 2001 16:27:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 49DC15352A for ; Thu, 5 Jul 2001 16:25:45 -0400 (EDT) Received: (qmail 70150 invoked by uid 3269); 5 Jul 2001 20:25:45 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 70144 invoked from network); 5 Jul 2001 20:25:44 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 5 Jul 2001 20:25:44 -0000 Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f65KP7i08876; Thu, 5 Jul 2001 16:25:07 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id QAA02884; Thu, 5 Jul 2001 16:25:06 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id QAA30830; Thu, 5 Jul 2001 16:25:05 -0400 From: Ran Canetti Message-Id: <200107052025.QAA30830@ornavella.watson.ibm.com> To: canetti@watson.ibm.com, mbaugher@cisco.com Subject: RE: [MSEC] De-registration protocol? Cc: msec@securemulticast.org 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, 5 Jul 2001 16:25:05 -0400 David, Thomas, Mark, all, I agree that implementing the de-registration can/should be postponed until we have things working. But I do think that we should keep it in mind as a potential functionality of the msec protocol suite. let me try to summarize the points against leaving it to the application: - It will force the application to set up its own secure channels between each member and the GCKS. This would be done in addition to the msec secure channels, will require its own negotiations, policy, etc. Why burden the application with all that? - It will force us to set up a way for the msec module in the GCKS to receive leave operations from the application module. This will complicate the interface of the msec module inside the GCKS. - It will disallow joining the de-registration operation with other msec operations (such as sending the de-registration message over a long-lived msec secure channel). Best, Ran _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jul 5 16:30:44 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26688 for ; Thu, 5 Jul 2001 16:30:43 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 21B255359C; Thu, 5 Jul 2001 16:30:24 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 2D82B53532 for ; Thu, 5 Jul 2001 16:29:45 -0400 (EDT) Received: (qmail 70486 invoked by uid 3269); 5 Jul 2001 20:29:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 70483 invoked from network); 5 Jul 2001 20:29:44 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 5 Jul 2001 20:29:44 -0000 Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f65KT0i21308; Thu, 5 Jul 2001 16:29:00 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id QAA80190; Thu, 5 Jul 2001 16:29:00 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id QAA31850; Thu, 5 Jul 2001 16:28:59 -0400 From: Ran Canetti Message-Id: <200107052028.QAA31850@ornavella.watson.ibm.com> To: canetti@watson.ibm.com, cfm@sparta.com, mbaugher@cisco.com, rafaeli@comp.lancs.ac.uk Subject: RE: [MSEC] De-registration protocol? Cc: msec@securemulticast.org 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, 5 Jul 2001 16:28:59 -0400 I agree. Ran > From cfm@sparta.com Thu Jul 5 15:32:15 2001 > > It seems to me that this question of business model has nothing at > all to do with key management. One could just as easily saddle the > multicast transport system with these requirements. (Seems we are > falling into the typical security trap of "well no one else is doing > it, why not security!") > > Ran's comment on mitigations, points the way to a solution, use an > application service to manage the billing. One could then effect > their service delivery decisions through key management. That seems > much more straightforward than trying to effect billing decisions > through key management. > > carl. > > On 7/5/01 at 3:12 PM -0400, Ran Canetti wrote: > > > >Sandro, you're right that this business model of pay-until-you-say-enough > >is susceptible to this type of failures. This is indeed something that the > >application will have to deal with... but this business model seems to be > >attractive in some cases nonetheless. (one way to mitigate this is to put > >a cap on the payment amount, on the duration, etc. for instance in a boxing > >show you never pay more than the full 12 rounds.) > > > >Ran > > > >> From msec-admin@securemulticast.org Mon Jul 2 06:18:31 2001 > >> > >> > >> Ran, > >> > >> Applications are prone to crash when you least expect :(. When that occurs, > >> paying members may pay much more then they are supposed to for the simple > >> reason that the de-registration/leave command was never issued. > >> De-registration/leave command is not enough to control the time a member is > >> participating in the group... > >> > >> Sandro. > >> > >> | BTW, Mark, in a model where a member pays acording to the > >> | time elapsed > >> | between registration and de-registration, the > >> | de-registration mechanism > >> | is not just for being nice. And this is true regardless of how these > >> | protocols are called... > >> > >> > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec > > > -- > Carl F. Muckenhirn > Division Manager > SPARTA, Inc. > Security Engineering Division > 9861 Broken Land Parkway, Suite 300 > Columbia, Maryland 21046 > 410.381.9400 x208 > 410.381.5559 (fax) > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jul 5 17:57:48 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28498 for ; Thu, 5 Jul 2001 17:57:47 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8A6975354C; Thu, 5 Jul 2001 17:58:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id A9E4153583 for ; Thu, 5 Jul 2001 17:57:05 -0400 (EDT) Received: (qmail 79568 invoked by uid 3269); 5 Jul 2001 21:57:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 79565 invoked from network); 5 Jul 2001 21:57:05 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 5 Jul 2001 21:57:05 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f65LuWh28700; Thu, 5 Jul 2001 14:56:32 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-585.cisco.com [10.21.66.73]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AEC07252; Thu, 5 Jul 2001 14:56:22 -0700 (PDT) Message-Id: <4.3.2.7.2.20010705145534.0422fee8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Carl F. Muckenhirn" From: Mark Baugher Subject: RE: [MSEC] De-registration protocol? Cc: Ran Canetti , rafaeli@comp.lancs.ac.uk, msec@securemulticast.org In-Reply-To: References: <200107051912.PAA28176@ornavella.watson.ibm.com> <200107051912.PAA28176@ornavella.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Thu, 05 Jul 2001 14:55:48 -0700 I agree. Mark At 03:31 PM 7/5/2001 -0400, Carl F. Muckenhirn wrote: >It seems to me that this question of business model has nothing at all to >do with key management. One could just as easily saddle the multicast >transport system with these requirements. (Seems we are falling into the >typical security trap of "well no one else is doing it, why not security!") > >Ran's comment on mitigations, points the way to a solution, use an >application service to manage the billing. One could then effect their >service delivery decisions through key management. That seems much more >straightforward than trying to effect billing decisions through key management. > >carl. > >On 7/5/01 at 3:12 PM -0400, Ran Canetti wrote: > > >>Sandro, you're right that this business model of pay-until-you-say-enough >>is susceptible to this type of failures. This is indeed something that the >>application will have to deal with... but this business model seems to be >>attractive in some cases nonetheless. (one way to mitigate this is to put >>a cap on the payment amount, on the duration, etc. for instance in a boxing >>show you never pay more than the full 12 rounds.) >> >>Ran >> >>> From msec-admin@securemulticast.org Mon Jul 2 06:18:31 2001 >>> >>> >>> Ran, >>> >>> Applications are prone to crash when you least expect :(. When that >>> occurs, >>> paying members may pay much more then they are supposed to for the simple >>> reason that the de-registration/leave command was never issued. >>> De-registration/leave command is not enough to control the time a >>> member is >>> participating in the group... >>> >>> Sandro. >>> >>> | BTW, Mark, in a model where a member pays acording to the >>> | time elapsed >>> | between registration and de-registration, the >>> | de-registration mechanism >>> | is not just for being nice. And this is true regardless of how these >>> | protocols are called... >>> >> >>_______________________________________________ >>msec mailing list >>msec@securemulticast.org >>http://www.pairlist.net/mailman/listinfo/msec > > >-- >Carl F. Muckenhirn >Division Manager >SPARTA, Inc. >Security Engineering Division >9861 Broken Land Parkway, Suite 300 >Columbia, Maryland 21046 >410.381.9400 x208 >410.381.5559 (fax) _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jul 5 17:57:54 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28509 for ; Thu, 5 Jul 2001 17:57:54 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 92780535A6; Thu, 5 Jul 2001 17:58:05 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 2E4E353545 for ; Thu, 5 Jul 2001 17:57:51 -0400 (EDT) Received: (qmail 79592 invoked by uid 3269); 5 Jul 2001 21:57:50 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 79589 invoked from network); 5 Jul 2001 21:57:50 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 5 Jul 2001 21:57:50 -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.11.3/8.9.1) with ESMTP id f65LvSx02912; Thu, 5 Jul 2001 14:57:28 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-585.cisco.com [10.21.66.73]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AEC07296; Thu, 5 Jul 2001 14:57:19 -0700 (PDT) Message-Id: <4.3.2.7.2.20010705145630.04232f20@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Ran Canetti From: Mark Baugher Subject: Re: [MSEC] De-registration protocol? Cc: mcgrew@cisco.com, thardjono@mediaone.net, msec@securemulticast.org In-Reply-To: <200107052010.QAA31838@ornavella.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Thu, 05 Jul 2001 14:56:45 -0700 At 04:10 PM 7/5/2001 -0400, Ran Canetti wrote: >Thomas, I agree that in some groups it would make sense to maintain a >long-lived secure unicast channel between each group member and the GCKS, >and in other cases it would make sense to keep only short-term unicast >secure channels. > >This point should probably make it into the gkmarch document. I agree. I'll stop here. Mark >btw, this is another very good reason to keep the de-registration >functionality within the scope of msec - to allow this flexibility >of design. If we force the application to do de-registration by itself >then we lose the ability to use a long-lived msec secure unicast channel >for de-registration... > > >Ran > > > > From msec-admin@securemulticast.org Tue Jul 3 18:10:20 2001 > > > > > > David, > > > > At 7/3/2001||08:54 AM, you wrote: > > > > > > >I'd favor noting the possible need for a member-to-controller channel > in the > > >architecture, but not spending much short term effort on realizing it. > > > > > > Hmm, this brings-up the (old) issue of how long the Cat-1 SA and secure > > channel should be around. > > > > If we simply want a 1-to-1 secure channel between the member to KDC, > > then we already have this (namely, the Cat-1 SA or > > Registration/Initialization). > > > > Even if the "secure channel" was SSL or Ran's IPsec-Tunnel, the question > > of the lifetime of the connection remains still. > > > > And you are absolutely correct is stating that the answer depends > > on the size of the group (which to my mind is application-dependent, > > and to a some extent depends on the availability of a distributed KDC). > > > > I think it is the application that will decide the type of data, speed, > > capacity or routers/KDCs to hold SAs, etc. > > > > 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 Jul 5 18:15:56 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28860 for ; Thu, 5 Jul 2001 18:15:53 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9AD5D535BC; Thu, 5 Jul 2001 18:16:09 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 5FE5B5354C for ; Thu, 5 Jul 2001 18:15:59 -0400 (EDT) Received: (qmail 81317 invoked by uid 3269); 5 Jul 2001 22:15:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 81313 invoked from network); 5 Jul 2001 22:15:58 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by klesh.pair.com with SMTP; 5 Jul 2001 22:15:58 -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.11.3/8.9.1) with ESMTP id f65MFZP04878; Thu, 5 Jul 2001 15:15:35 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-585.cisco.com [10.21.66.73]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AEC07837; Thu, 5 Jul 2001 15:15:24 -0700 (PDT) Message-Id: <4.3.2.7.2.20010705150731.04230f98@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Ran Canetti From: Mark Baugher Subject: RE: [MSEC] De-registration protocol? Cc: mcgrew@cisco.com, msec@securemulticast.org In-Reply-To: <200107052025.QAA30830@ornavella.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Thu, 05 Jul 2001 15:14:47 -0700 Ran At 04:25 PM 7/5/2001 -0400, Ran Canetti wrote: >David, Thomas, Mark, all, > >I agree that implementing the de-registration can/should be postponed >until we have things working. But I do think that we should keep it in mind >as a potential functionality of the msec protocol suite. > >let me try to summarize the points against leaving it to the application: > >- It will force the application to set up its own secure channels between >each member and the GCKS. This would be done in addition to the msec secure >channels, will require its own negotiations, policy, etc. Why burden the >application with all that? I think it's unavoidable. It's not that bad since SSL, SET, or other protocols may be better suited to the purpose and, in the case of SSL, it is widely available. This is true for trust (e.g. certificate management) and other services that may be need for some key management applications. >- It will force us to set up a way for the msec module in the GCKS to receive >leave operations from the application module. This will complicate the >interface of the msec module inside the GCKS. What's the "msec module?" In GDOI, there is an authorization interface (as there is in IKE and other key management systems). For GDOI, this interface is where key management gets told to send a Re-key message. There is zero overhead here. >- It will disallow joining the de-registration operation with other msec >operations (such as sending the de-registration message over a long-lived >msec secure channel). There is no de-registration message and there should not be one in my opinion. I think this is the crux of cfm's posting, if I read it right. thanks, Mark >Best, > >Ran _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jul 5 23:10:43 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05222 for ; Thu, 5 Jul 2001 23:10:42 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8E1F45361B; Thu, 5 Jul 2001 23:10:57 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id DB7C2535C8 for ; Thu, 5 Jul 2001 23:09:58 -0400 (EDT) Received: (qmail 99374 invoked by uid 3269); 6 Jul 2001 03:09:58 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 99371 invoked from network); 6 Jul 2001 03:09:58 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 6 Jul 2001 03:09:58 -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.11.3/8.9.1) with ESMTP id f6639Yx17043; Thu, 5 Jul 2001 20:09:34 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-tmp23.cisco.com [10.21.64.23]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AEC13494; Thu, 5 Jul 2001 20:09:24 -0700 (PDT) Message-Id: <4.3.2.7.2.20010705200241.042bc270@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: thardjono@mediaone.net, hh@sparta.com, Brian Weis From: Mark Baugher Cc: msec@securemulticast.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Fwd: Proposed updates to GDOI draft 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, 05 Jul 2001 20:08:50 -0700 Thomas, Hugh, Brian I updated the draft and put an interim version on the web for your review. I made the changes that I said I would make in the appended note: Issues 1, 2, 4, 6, 7, and 9 were added and text was removed that was redundant or inconsistent with the GKM architecture I-D. Issues 3, 5, 8, 10, and 11 remain to be updated. I'm okay with formatting this version for submission next week. The rough-draft text version is at http://www.rdrop.com/users/mbaugher/draft-ietf-msec-gdoi-01v2.txt And the pdf version that highlights the changes are at http://www.rdrop.com/users/mbaugher/draft-ietf-msec-gdoi-01v2.pdf Let me know what you think no later than next Monday. I'm travelling on Tuesday and Wednesday. I plan to submit the draft on Thursday. Mark >Date: Wed, 04 Jul 2001 09:53:33 -0700 >To: thardjono@mediaone.net, hh@sparta.com, Brian Weis >From: Mark Baugher >Subject: Fwd: Proposed updates to GDOI draft >Cc: msec@securemulticast.org > >Brian did not intend for his note to be forwarded to msec, but I think he >did a good job of pre-editing the next version of the GDOI document and I >thought it would be helpful to msec to see what we are doing with the next >GDOI I-D. I don't think Brian will mind me doing this. Since he's on >vacation, I volunteered to edit the document. There will probably need to >be a telecon among Hugh, Thomas and me to finalize this revision. So my >remarks are for them, first and foremost. I'll list every issue and what >I propose to do with it since some issues are controversial, we will need >to postpone the update until after Brian returns. I have a couple of >issues to add. Note that Brian appended an edited version of the I-D but >I removed the appendage from this note because it is quite long. Here are >Brian's issues: > >1. ISSUE 1: I agree that we make this change. >2. ISSUE 2: ditto >3. ISSUE 3: I don't understand this since we need some value for >interoperability testing. >4. ISSUE 4: I agree that we make this change >5. ISSUE 5: I think we should discuss this after the IETF meeting >6. ISSUE 6: I agree wholeheartedly that we always match the Phase 2 DOI >the Phase 1 >7. ISSUE 7: I agree >8. ISSUE 8: I personally disagree and want to discuss after the IETF meeting >9. ISSUE 9: Thomas, your contact information, please >10. ISSUE 10: I disagree and want to discuss after the IETF meeting >11. ISSUE 11: I strongly disagree and want to discuss after the IETF meeting > >The other issues that I have are with the front-matter of GDOI revision >00: I think we should remove everything that is redundant to >draft-ietf-msec-gkmarch-00.txt and refer to this draft for the model we >are using. > >Mark > >>Sender: bew@cisco.com >>Date: Sat, 30 Jun 2001 11:26:58 -0700 >>From: Brian Weis >>X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) >>X-Accept-Language: en >>To: mbaugher@cisco.com, Hugh Harney , >> Thomas Hardjono >>Subject: Proposed updates to GDOI draft >> >>Greetings, fellow GDOI draft authors. >> >>We're about 3 weeks away from the final ID submission date for the >>London >>IETF. There are a number of issues which should be dealt with so that we >>can >>submit a -01 version of GDOI for London. >> >>Having said that, I begin a 2 week vacation on Monday, and won't be in a >>location where there is easy Internet access, so I may miss most of the >>discussion. :-( I will listen to voice mail occasionally, and will >>return phone >>calls as best I can. But this is rural N.D., and even though the >>telephone >>switches have been upgraded from rotary-only, one is still not >>guaranteed to >>have a touch tone phone available in the house. :-) >> >>I apologize in advance for not starting this discussion earlier. >>However, I have enclosed a list of issues that I've kept since the >>last IETF, along with proposed resolutions and text. Also, for >>convenience >>I've attached a text version of -00 with these changes so you can see >>them >>inline. Please comment on them, tear my logic and text apart as you >>will, etc. >> >>Please introduce new issues to the discussion as you see fit. Mark has >>kindly >>agreed to edit the document in my absence. >> >>I propose that we do not attempt to harmonize with the new GKM Arch. >>document >>until after the London meeting, since it appears to be a bit >>controversial. >> >>If you all come to agreement before my return and feel the need to >>submit the >>-01 draft, please do so. Otherwise, I return on 7/16 and will have >>until 7/20 >>to submit it. It will be on the top of my priority list. >> >>Thanks, >>Brian >> >>ISSUE 1 >>------- >>Section 5.4. The SA_TEK payload doesn't really need RESERVED (3) for >>alignment. The next field isn't aligned anyway due to the free-form >>length of >>the ID (which is usually 4 bytes, putting the starting point at the 2nd >>byte >>of the word). I propose replacing the current bitmap diagram with this: >> >>======== BEGIN TEXT >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! >> ! Next Payload ! RESERVED ! Payload Length ! >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! >> ! Protocol-ID ! TEK Protocol-Specific Payload ~ >> +-+-+-+-+-+-+-+-+ ~ >> ~ ~ >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! >>======== END TEXT >> >>ISSUE 2 >>------- >>Format of keys in the KD payload is under-specified, for both encryption >>keys >>and authentication keys. For example, there could be questions as to >>whether >>the keys sent bitwise or in an ASCII representation of them, and in the >>case >>of DES are parity bits included or not. The following sections attempt >>to >>address these ambiguities. >> >>For section 5.5.1.1 (encryption keys): >> >>======== BEGIN TEXT >>DES keys will consist of 64 bits (the 56 key bits with parity bits). >>Triple DES >>keys will be be specified as 64 bit keys in the order that they are to >>be used >>for encryption (e.g., DES_KEY1, DES_KEY2, DES_KEY3). >>======== END TEXT >> >>Similarly, in section 5.5.1.3 (authentication keys): >> >>======== BEGIN TEXT >>SHA keys will consist of 160 bits, and MD5 keys will consist of 128 >>bits. >>======== END TEXT >> >>ISSUE 3 >>------- >>There's a problem with the DOI number in Section 5.2. It is currently >>specified thusly: >> >> > o DOI (4 octets) - Is the GDOI, which is value 196 pending >> > assignment by the IANA. >> >>We've chosen a value for our DOI, but in fact we should not be >>choosing numbers until IANA assigns us one. Thus should say >> >>======== BEGIN TEXT >> o DOI (4 octets) - TBD pending assignment by the IANA. >>======== END TEXT >> >>But IANA won't assign us one until we are further along in the standards >>process. We have to choose something in the meantime for interop >>testing. >> >>The right way to do that is to define a new vendor-id payload as part of >>Phase 1 which specifies a local context in which to interpret >>non-assigned >>numbers. I proposed we delay that until the next draft version. Or, we >>can >>model one after the XAUTH draft now, if you feel it should be done >>for this draft. >> >>ISSUE 4 >>------- >>Regarding this semantic of the KD payload in section 5.5: >> >> > If the "Number of Key Packets" is zero, the group member is expected to >> > delete all keys associated with the ID. This type of KD payload will >> > only be sent by the GCKS when a group is deleted. >> >>Early on we discussed replacing the following semantic with an IKE >>Delete >>payload. I would like to do that now. I don't really like having an >>implicit >>semantic to delete keys; it might be efficient, but it's prone to both >>specification and implementation error. The Delete payload is defined in >>RFC 2408 section 3.15, and basically sends a list of SPIs to delete. >> >>I propose removing the text above, and adding a section 4.5. >> >>======== BEGIN TEXT >>4.5 Deletion of SAs >> >>There are times the GCKS may want to signal to receivers to delete SAs, >>for >>example at the end of a broadcast when no more data will be sent to the >>group. >>Deletion of keys may be accomplished by sending an ISAKMP Delete payload >>as >>part of a GDOI GROUPKEY-PUSH message. >>======== END TEXT >> >>ISSUE 5 >>------- >>If no KEK is defined, then the SEQ payload is not needed. Today a group >>which >>doesn't use a KEK is forced to carry the SEQ as unnecessary baggage. >> >>This could be fixed by making the SEQ payload optional. But then the >>implementation has to keep track of whether it needs to send it or not >>(i.e., >>if it's sending a KEK). Note that the HASH(4) is also changed slightly >>if SEQ >>is made optional, but HASH(4) already has some optional payloads in it. >> >>If you believe the extra complexity is worth adding in order to make the >>non-KEK case correct, I propose modifying the exchange thusly: >> >>======== BEGIN TEXT >> Initiator (Member) Responder (GCKS) >> ------------------ ---------------- >> HDR*, HASH(1), Ni, ID --> >> <-- HDR*, HASH(2), Nr, SA >> HDR*, HASH(3) [, KE_I] --> >> [,CERT] [,POP_I] >> <-- HDR*, HASH(4), [KE_R,] [SEQ,] >> KD [,CERT] [,POP_R] >>Hashes are computed as follows: >> HASH(1) = prf(SKEYID_a, M-ID | Ni | ID) >> HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA) >> HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_I ] [ | POP_I ]) >> HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_R ] [ | SEQ ] | >>KD >> [ | POP_R]) >>======== END TEXT >> >>ISSUE 6 >>------- >>In section 2.4 it should be mentioned that if GDOI sets up the IKE Phase >>1, >>that the DOI in the IKE Phase 1 SA payload should be the GDOI value (not >>the >>IPSEC value). I've added the following new sub-section to declare this. >> >>======== BEGIN TEXT >> >>2.4.1 IKE Phase 1 SA Payload >> >>The IKE Phase 1 SA payload has a DOI value. That value should be the >>GDOI DOI >>value as defined later in this document. >>======== END TEXT >> >>ISSUE 7 >>------- >>In section 5.4 the Protocol-ID field for the TEK payload is currently >>defined >>based on the IPSec protocol list (e.g., PROTO_IPSEC_ESP is 4 which >>matches >>RFC 2407). However, as we want to support other non-IPSec protocols we >>can't >>re-use the address space. I propose replacing the existing list with the >>following new set of identifiers: >> >>======== BEGIN TEXT >> Protocol ID Value >> ----------- ----- >> RESERVED 0 >> GDOI_PROTO_IPSEC_ESP 1 >> GDOI_PROTO_MESP 2 >> GDOI_PROTO_AMESP 3 >> GDOI_PROTO_SRTP 4 >> RESERVED 5-127 >> PRIVATE USE 128-255 >>======== END TEXT >> >>ISSUE 8 >>------- >>Steve Kent pointed out at the last IETF that Attribute Certs don't have >>a >>pubkey in them, so by extension the GROUPKEY-PULL exchange doesn't need >>the >>POP payload to go with the CERT. I see the following alternatives: >> a. Remove the POP. This requires the keypair used for authentication >>to be >> used for authorization, which is a certain limitation. >> b. Require the authorization keypair to be separate. This requires >>us to >> extend the (CERT, POP) pair in the exchange to be a triple >> (AUTHENT_CERT, AUTHOR_CERT, POP) where the AUTHENT_CERT carries >>the >> pubkey associated with the private key used to sign the POP, and >> AUTHOR_CERT is the attribute cert. That's quite a lot of >>overhead! >> c. Combine the whole mess into a new AUTH payload which can be >>defined in >> many ways. This would also allow other methods of authorization >>which >> are not public key based (e.g., send a user entered PIN). >> >>I favor c. It would modify the GROUPKEY-PULL exchange like this: >> >>======== BEGIN TEXT >> Initiator (Member) Responder (GCKS) >> ------------------ ---------------- >> HDR*, HASH(1), Ni, ID --> >> <-- HDR*, HASH(2), Nr, SA >> HDR*, HASH(3) [, KE_I] --> >> [,AUTHOR] >> <-- HDR*, HASH(4), [KE_R,] [SEQ,] >> KD [,AUTHOR] >>Hashes are computed as follows: >> HASH(1) = prf(SKEYID_a, M-ID | Ni | ID) >> HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA) >> HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_I ] [ | AUTHOR ]) >> HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_R ] [ | SEQ ] | >>KD >> [ | AUTHOR]) >>* Protected by IKE Phase 1 SA, encryption occurs after HDR >>======== END TEXT >> >>The following text defining the Authorization payload replaces section >>5.7 "Proof of Possession" which would be no longer needed. (There are >>other >>edits needed to to remove the POP throughout the document, but I'll omit >>those >>until there's agreement that this is the right approach.) >> >>NOTE: I didn't include a SPKI variety of authorization cert because I >>think >>the authorization is bound in the authentication certificate, so no >>separate >>AUTHOR cert would be needed. If that is wrong, please add that type and >>some >>appropriate text. >> >>======== BEGIN TEXT >>5.7 Authorization Payload >> >>The Authorization Payload (AUTHOR) provides an authorization mechanism >>for the >>GCKS to verify that a group member is authorized to join a group. It is >>also >>used by a group member to verify that a GCKS is authorized to serve keys >>for a >>group. >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! >> ! Next Payload ! RESERVED ! Payload Length ! >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> ! Auth Type ! Authorization Payload ~ >> +-+-+-+-+-+-+-+-+ ~ >> ~ ~ >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! >> >> The Authorization Payload fields are defined as follows: >> >> o Next Payload (1 octet) - Identifier for the payload type of the >>next payload in the message. If the current payload is the last in the >>message, then this field will be zero. >> >> o RESERVED (1 octet) - Unused, set to zero. >> >> o Payload Length (2 octets) - Length in octets of the current >>payload, including the generic payload header. >> >> o Auth Type (1 octet) - This field defines the type of authorization >>which >>is to be used for the group. >> >> Auth Type Value >> --------- ----- >> X.509_ATTRIBUTE_CERT 1 >> PASSWORD 2 >> RESERVED 3-127 >> Private Use 128-255 >> >> o Authorization Payload (varies) - The actual authorization data. >>The >>following sections define those payloads by type. >> >>5.7.1 X.509_ATTRIBUTE_CERT >> >>The authorization payload contains the Attribute Certificate as defined >>in [FH] >>[NOTE: reference points to draft-ietf-pkix-ac509prof-06.txt]. >> >>The Attribute Certification must have a critical extension which >>declares the group id (format TBD). >> >>5.7.1 PASSWORD >> >>The authorization payload contains the following structure: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! >> ! Length ! Password ~ >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ >> ~ ~ >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! >> >>The password field structure is defined as follows: >> >> o Length (2 octets) - Length of the password. >> >> o Password (variable) - Password Data >>======== END TEXT >> >>ISSUE 9 >>------- >>Thomas needs to fill in his new contact info. I've start it so it won't >>be >>forgotten. >> >>ISSUE 10 >>-------- >>Dan Harkins was adamant that we don't use the IKE port for GDOI. I >>propose the following section to address that. >> >>======== BEGIN TEXT >>2.4.2 GDOI Port >> >>In order to enable separation of protocol state machines, GDOI should >>not use >>the port commonly used by IKE (udp port 500). A port must be assigned by >>IANA. >>======== END TEXT >> >>ISSUE 11 >>-------- >>There are two issue with section 3.2.1 (Perfect Forward Secrecy). I >>think it >>is easiest to consider them separately. >> >> a. There is some confusion in the naming, as to whether the function >> provided by KE payloads is "perfect forward secrecy" or "perfect >> backwards secrecy". This should get sorted out. The intended >>property >> of KE payloads is that if someone discovers the current IKE >>protocol >> keys (e.g., through cryptanalysis), they should not be able to >> automatically get the next set of keys (in this case, the keys >>which are >> used to protect the TEK and KEK keys in the KD payload). >> >> If you can sort out the proper term, please fix the section to use >>the >> appropriate nomenclature. >> >> b. There is some disagreement as to why we would need KE payloads at >>all. I >> believe we need them, and propose the following rationale to be >>inserted >> at the beginning of section 3.2.1 (before the current paragraph). >> >>======== BEGIN TEXT >>PFS may be necessary in some scenarios. The GROUPKEY-PULL exchange is >>protected by the IKE Phase 1 encryption keys, as is the IKE Phase 2 >>exchange. >>It should be noted that in the case of the IKE Phase 2 exchange, no keys >>are >>ever passed in the exchange -- they are always derived from keying >>material that has some secret component (e.g., from a previous DH >>exchange). >>However, the IPSec working group still saw it necessary that there >>should be a >>mechanism for refreshing the hidden keying material (through use of the >>KE >>payloads). >> >>With PFS protection, the risk to the KEK and TEK keys is far greater for >>the >>GDOI GROUPKEY-PULL exchange. The keys are passed directly from the GCKS >>to the >>group member in the KD payload. A passive attacker can store GDOI >>GROUPKEY-PULL >>packets as well as the data packets and attempt to break the IKE Phase 1 >>encryption keys. Once that is done, the attacker has direct access to >>the KEK >>and TEK keys stored in the KD payload and can then decrypt the stored >>content >>for as long as the discovered KEK key is used. >> >>Use of the KD payloads complicates this attack by causing the attacker >>to >>perform further cryptanalysis to determine the keying derived from the >>KD >>payload." >>======== END TEXT >> >>ISSUE 12 >>-------- >>Mark has developed an Appendix which describes how to pass SRTP policy >>in >>GDOI, just as Appendix A describes how to pass MESP/AMESP policy in >>GDOI. >>This should be added to this draft. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jul 6 00:56:18 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07212 for ; Fri, 6 Jul 2001 00:56:18 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B3CD453656; Fri, 6 Jul 2001 00:56:32 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 671BA535E8 for ; Fri, 6 Jul 2001 00:55:24 -0400 (EDT) Received: (qmail 6892 invoked by uid 3269); 6 Jul 2001 04:55:24 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 6889 invoked from network); 6 Jul 2001 04:55:23 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 6 Jul 2001 04:55:23 -0000 Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f664sri44982 for ; Fri, 6 Jul 2001 00:54:53 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id AAA28138 for ; Fri, 6 Jul 2001 00:54:53 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id AAA36404 for msec@securemulticast.org; Fri, 6 Jul 2001 00:54:52 -0400 From: Ran Canetti Message-Id: <200107060454.AAA36404@ornavella.watson.ibm.com> To: msec@securemulticast.org Subject: RE: [MSEC] De-registration protocol? 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, 6 Jul 2001 00:54:52 -0400 Carl, Mark, I think I was too hasty in agreeing and didnt read Carl's note thoroughly enough. What I agreed to was the idea that the issues brought up by Sandro, i.e., the inherent reliability problems associated with the pay-until-you-say-enough model, are best dealt with by the application. On second reading, however, it seems that you may have meant that the entire de-registration operation is best done at the application layer. Here I beg to differ: It is very true that the de-registration operation is driven by a request of the application *within the group member*. The natural place for this request to go is to the msec "layer" (or, "module") within the member. Then the msec layer within the member will do what is needed, ie, transmit this request securely to the msec layer within the GCKS. The msec layer within the GCKS will then notify the application layer within the GCKS (eg, the billing center) that the member has de-registered. Pictorially, this would look like: GCKS MEMBER |--------| |----------| | | | multicast| | applic.| | applicat.| | | | | |--------| |----------| ^ | | v |--------| |----------| | | de-registration | | | msec | <------------------------ | msec | | | | | |--------| |----------| Ie, the flow of information starts at the top right box and goes clockwise from there. The other suggestion as I understand it is: GCKS MEMBER |--------| |----------| | | de-registration | multicast| | applic.| <------------------------ | applicat.| | | | | |--------| |----------| | | v v |--------| |----------| | | | | | msec | | msec | | | | | |--------| |----------| This seems worse in my eyes, for the reasons I listed in my previous note. Ran > > From canetti@ornavella.watson.ibm.com Thu Jul 5 16:29:01 2001 > > I agree. > > Ran > > > From cfm@sparta.com Thu Jul 5 15:32:15 2001 > > > > It seems to me that this question of business model has nothing at > > all to do with key management. One could just as easily saddle the > > multicast transport system with these requirements. (Seems we are > > falling into the typical security trap of "well no one else is doing > > it, why not security!") > > > > Ran's comment on mitigations, points the way to a solution, use an > > application service to manage the billing. One could then effect > > their service delivery decisions through key management. That seems > > much more straightforward than trying to effect billing decisions > > through key management. > > > > carl. > > > > On 7/5/01 at 3:12 PM -0400, Ran Canetti wrote: > > > > > > >Sandro, you're right that this business model of pay-until-you-say-enough > > >is susceptible to this type of failures. This is indeed something that > > >the > > >application will have to deal with... but this business model seems to be > > >attractive in some cases nonetheless. (one way to mitigate this is to put > > >a cap on the payment amount, on the duration, etc. for instance in a > > >boxing > > >show you never pay more than the full 12 rounds.) > > > > > >Ran > > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jul 6 00:57:47 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07227 for ; Fri, 6 Jul 2001 00:57:47 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4569153607; Fri, 6 Jul 2001 00:58:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 92F2E535E8 for ; Fri, 6 Jul 2001 00:56:50 -0400 (EDT) Received: (qmail 6946 invoked by uid 3269); 6 Jul 2001 04:56:50 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 6943 invoked from network); 6 Jul 2001 04:56:50 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 6 Jul 2001 04:56:50 -0000 Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f664uJi58508 for ; Fri, 6 Jul 2001 00:56:19 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id AAA28148 for ; Fri, 6 Jul 2001 00:56:19 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id AAA32104 for msec@securemulticast.org; Fri, 6 Jul 2001 00:56:19 -0400 From: Ran Canetti Message-Id: <200107060456.AAA32104@ornavella.watson.ibm.com> To: msec@securemulticast.org Subject: RE: [MSEC] De-registration protocol? 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, 6 Jul 2001 00:56:19 -0400 Mark, you wrote: > >I agree that implementing the de-registration can/should be postponed > >until we have things working. But I do think that we should keep it in mind > >as a potential functionality of the msec protocol suite. > > > >let me try to summarize the points against leaving it to the application: > > > >- It will force the application to set up its own secure channels between > >each member and the GCKS. This would be done in addition to the msec secure > >channels, will require its own negotiations, policy, etc. Why burden the > >application with all that? > > I think it's unavoidable. It's not that bad since SSL, SET, or other > protocols > may be better suited to the purpose and, in the case of SSL, it is widely > available. This is true for trust (e.g. certificate management) and other > services that may be need for some key management applications. I disagree. If we design things right then there will be no reason for the member application program to set up a secure connection with the GCKS aside from what msec does. Requiring the application to do this redundant security overhead undermines the usability of msec. If the application has to do security by itself then it has good incentive to bypass msec altogether... > > > >- It will force us to set up a way for the msec module in the GCKS to > >receive > >leave operations from the application module. This will complicate the > >interface of the msec module inside the GCKS. > > What's the "msec module?" In GDOI, there is an authorization interface > (as there is in IKE and other key management systems). For GDOI, > this interface is where key management gets told to send a Re-key > message. There is zero overhead here. If the application prorgam within the member sends a de-registration message to the application program in the GCKS then the latter should notify the msec "layer" (or, "module") that the member has left and should be removed from the LKH/OFT tree. This last notification is part of the interface between the msec module/layer and the outside world. > > > >- It will disallow joining the de-registration operation with other msec > >operations (such as sending the de-registration message over a long-lived > >msec secure channel). > > There is no de-registration message and there should not be one in my > opinion. I think this is the crux of cfm's posting, if I read it right. The premise of this discussion is that we're in the pay-until-you-say-enough model. In this model the member has to somhow notify the GCKS that it has left (otherwise it will keep paying). I call this notification the "de-registration message", in whatever layer it takes place. Ran _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jul 6 08:19:49 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28747 for ; Fri, 6 Jul 2001 08:19:48 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A9A08535ED; Fri, 6 Jul 2001 08:20:03 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 5CCB55356F for ; Fri, 6 Jul 2001 08:18:56 -0400 (EDT) Received: (qmail 36752 invoked by uid 3269); 6 Jul 2001 12:18:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 36749 invoked from network); 6 Jul 2001 12:18:55 -0000 Received: from softdnserror (HELO M5.sparta.com) (root@157.185.61.1) by klesh.pair.com with SMTP; 6 Jul 2001 12:18:55 -0000 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by M5.sparta.com (8.11.0/8.11.0) with ESMTP id f66CIsx15897; Fri, 6 Jul 2001 07:18:54 -0500 Received: from [157.185.80.3] (dhcp-2.columbia.sparta.com [157.185.80.3]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id IAA26689; Fri, 6 Jul 2001 08:18:48 -0400 (EDT) Mime-Version: 1.0 X-Sender: cfm@pop.columbia.sparta.com Message-Id: In-Reply-To: <200107060454.AAA36404@ornavella.watson.ibm.com> References: <200107060454.AAA36404@ornavella.watson.ibm.com> To: Ran Canetti , msec@securemulticast.org From: "Carl F. Muckenhirn" Subject: RE: [MSEC] De-registration protocol? 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, 6 Jul 2001 08:18:49 -0400 Ran, Let me clarify my position. If the purpose of the "De-registration protocol" is to accomplish business requirements, beyond key management, such as suspension of billing or ceasing transmission of content, then I don't think the Key Management System is the appropriate place for it. If the purpose of the "De-registration protocol" is to support the correct or efficient operation of the Key Management System, and use of that protocol supports the business needs of the overall Business Management System, then I would support its inclusion in the Key Management System. Now I'm still agnostic as to whether there is a valid key management reason for members to notify the group (or the group controller) that they are resigning, unless the Key Management System will be doing something about it (such as issuing a compromise recovery event to ensure that the departing member has actually departed). In looking at your description below, are we asking the multicast application to distinguish between "de-registration" and "leaving" the group. For example, if you have an "internet tuner" which can "tune in" to different multicast channels, will moving from "SHOWTIME" to "HBO" cause the local MSEC implementation to "de-register" from SHOWTIME, and register with HBO, or will the application be smart enough (and bother the user enough) to know that changing the channel was not the same as "de-registering"? In the described scenarios, who is actually doing the IGMP join/leave? Has that been added to MSEC, or is it in the application? When we look at the effect of a GKM "resignation" (I think that word is much better than "de-registration"), it only makes sense if it is done in concert with other communications and application actions, otherwise we've just made the system unstable, or non-responsive (things which security applications are too often accused of). carl. On 7/6/01 at 12:54 AM -0400, Ran Canetti wrote: >Carl, Mark, > >I think I was too hasty in agreeing and didnt read Carl's note thoroughly >enough. What I agreed to was the idea that the issues brought up by Sandro, >i.e., the inherent reliability problems associated with the >pay-until-you-say-enough model, are best dealt with by the application. > >On second reading, however, it seems that you may have meant that the entire >de-registration operation is best done at the application layer. Here I beg >to differ: > >It is very true that the de-registration operation is driven by a request >of the application *within the group member*. The natural place for this >request to go is to the msec "layer" (or, "module") within the member. >Then the msec layer within the member will do what is needed, >ie, transmit this request securely to the msec layer within the GCKS. >The msec layer within the GCKS will then notify the application >layer within the GCKS (eg, the billing center) that the member has >de-registered. > >Pictorially, this would look like: > > > > GCKS MEMBER > > |--------| |----------| > | | | multicast| > | applic.| | applicat.| > | | | | > |--------| |----------| > ^ | > | v > |--------| |----------| > | | de-registration | | > | msec | <------------------------ | msec | > | | | | > |--------| |----------| > > >Ie, the flow of information starts at the top right box and goes >clockwise from there. The other suggestion as I understand it is: > > GCKS MEMBER > > |--------| |----------| > | | de-registration | multicast| > | applic.| <------------------------ | applicat.| > | | | | > |--------| |----------| > | | > v v > |--------| |----------| > | | | | > | msec | | msec | > | | | | > |--------| |----------| > > >This seems worse in my eyes, for the reasons I listed in my previous note. > > >Ran > > >> >> From canetti@ornavella.watson.ibm.com Thu Jul 5 16:29:01 2001 >> >> I agree. >> >> Ran >> >> > From cfm@sparta.com Thu Jul 5 15:32:15 2001 >> > >> > It seems to me that this question of business model has nothing at >> > all to do with key management. One could just as easily saddle the >> > multicast transport system with these requirements. (Seems we are >> > falling into the typical security trap of "well no one else is doing >> > it, why not security!") >> > >> > Ran's comment on mitigations, points the way to a solution, use an >> > application service to manage the billing. One could then effect >> > their service delivery decisions through key management. That seems >> > much more straightforward than trying to effect billing decisions >> > through key management. >> > >> > carl. >> > >> > On 7/5/01 at 3:12 PM -0400, Ran Canetti wrote: >> > >> > >> > >Sandro, you're right that this business model of pay-until-you-say-enough >> > >is susceptible to this type of failures. This is indeed something that >> > >the >> > >application will have to deal with... but this business model seems to be >> > >attractive in some cases nonetheless. (one way to mitigate this is to put >> > >a cap on the payment amount, on the duration, etc. for instance in a >> > >boxing >> > >show you never pay more than the full 12 rounds.) >> > > >> > >Ran >> > > > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec -- Carl F. Muckenhirn Division Manager SPARTA, Inc. Security Engineering Division 9861 Broken Land Parkway, Suite 300 Columbia, Maryland 21046 410.381.9400 x208 410.381.5559 (fax) _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jul 6 08:33:58 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29255 for ; Fri, 6 Jul 2001 08:33:57 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id E8AD2535ED; Fri, 6 Jul 2001 08:34:12 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id B642853570 for ; Fri, 6 Jul 2001 08:33:50 -0400 (EDT) Received: (qmail 37711 invoked by uid 3269); 6 Jul 2001 12:33:50 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 37708 invoked from network); 6 Jul 2001 12:33:50 -0000 Received: from m5.sparta.com (root@157.185.61.1) by klesh.pair.com with SMTP; 6 Jul 2001 12:33:50 -0000 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by M5.sparta.com (8.11.0/8.11.0) with ESMTP id f66CXmx16224; Fri, 6 Jul 2001 07:33:48 -0500 Received: from [157.185.80.3] (dhcp-2.columbia.sparta.com [157.185.80.3]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id IAA26825; Fri, 6 Jul 2001 08:33:41 -0400 (EDT) Mime-Version: 1.0 X-Sender: cfm@pop.columbia.sparta.com Message-Id: In-Reply-To: <200107060456.AAA32104@ornavella.watson.ibm.com> References: <200107060456.AAA32104@ornavella.watson.ibm.com> To: Ran Canetti , msec@securemulticast.org From: "Carl F. Muckenhirn" Subject: RE: [MSEC] De-registration protocol? 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, 6 Jul 2001 08:33:40 -0400 Ran, (see in-line comments) On 7/6/01 at 12:56 AM -0400, Ran Canetti wrote: >Mark, > >you wrote: > >> >I agree that implementing the de-registration can/should be postponed >> >until we have things working. But I do think that we should keep it in mind >> >as a potential functionality of the msec protocol suite. >> > >> >let me try to summarize the points against leaving it to the application: >> > >> >- It will force the application to set up its own secure channels between >> >each member and the GCKS. This would be done in addition to the msec secure >> >channels, will require its own negotiations, policy, etc. Why burden the >> >application with all that? >> >> I think it's unavoidable. It's not that bad since SSL, SET, or other >> protocols >> may be better suited to the purpose and, in the case of SSL, it is widely >> available. This is true for trust (e.g. certificate management) and other >> services that may be need for some key management applications. > >I disagree. If we design things right then there will be no reason for the >member application program to set up a secure connection with the GCKS >aside from what msec does. Requiring the application to do this redundant >security overhead undermines the usability of msec. If the application >has to do security by itself then it has good incentive to bypass >msec altogether... Its not clear to me that the member application needs to talk to the GCKS, if the member application no longer wants to receive the content to which he is subscribed, he'll have to leave that multicast group. A vigilant multicast provider, listening to the IGMP all-routers group, will know which hosts have left and can notify the GCKS (if he desires). Since the GCKS is operating on behalf of the content provider/group owner, I don't see any problem with this model. We will have a GCKS to group owner connection in either case; in my scenario originated by the group owner exercising control of the GCKS; in your scenario originated by the GCKS providing membership updates to the group owner. I'm not sure either one is more complicated, though it seems (just seems) to me that what we are trying to do is redundant with other activities necessary for the efficient operation of the multicast system. > > >> >> >- It will force us to set up a way for the msec module in the GCKS to >> >receive >> >leave operations from the application module. This will complicate the >> >interface of the msec module inside the GCKS. >> >> What's the "msec module?" In GDOI, there is an authorization interface >> (as there is in IKE and other key management systems). For GDOI, >> this interface is where key management gets told to send a Re-key >> message. There is zero overhead here. > >If the application prorgam within the member sends a de-registration message >to the application program in the GCKS then the latter should notify the >msec "layer" (or, "module") that the member has left and should be removed >from the LKH/OFT tree. This last notification is part of the interface >between the msec module/layer and the outside world. Having not seen an API for the MSEC module, I can't comment on whether the addition of a resignation interaction is a problem for the user or not. I thought that one aim of the current MSEC approach is to closely follow the IPSEC APIs. I guess we could map a "delete key" to a "resign" at the interface, though "delete key" is local, and "resign" has network traffic implications. Now that I start thinking about it. How are we to deal with a group whose natural life has ended? A content application finishes, and notifies all subscribing members (i.e. broadcasts) that "the broadcast day has ended", will each application issue a "delete key" to the local MSEC, causing a flood of resignations? Is that what we want? > > >> >> >- It will disallow joining the de-registration operation with other msec > > >operations (such as sending the de-registration message over a long-lived > > >msec secure channel). > > > > There is no de-registration message and there should not be one in my > > opinion. I think this is the crux of cfm's posting, if I read it right. > >The premise of this discussion is that we're in the >pay-until-you-say-enough model. In this model the member has to somhow >notify the GCKS that it has left (otherwise it will keep paying). >I call this notification the "de-registration message", in whatever layer it >takes place. In the "pay-until-you-say-enough" model, it should be the using application which notifies the sending application that it's had enough, I would put the burden on the sending application to key-out any folks who it wants to ensure are off the air. Alternatively, as I mention above, if it is monitoring the leaves and joins it can leave the key in place (make it easy for the customer to "tune in" again) and start charging when he sees them re-join the multicast group. >Ran > > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec carl. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jul 6 11:41:50 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08915 for ; Fri, 6 Jul 2001 11:41:49 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6A69A5368E; Fri, 6 Jul 2001 11:42:05 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id E07C8536D6 for ; Fri, 6 Jul 2001 11:40:04 -0400 (EDT) Received: (qmail 54198 invoked by uid 3269); 6 Jul 2001 15:40:04 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 54192 invoked from network); 6 Jul 2001 15:40:04 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 6 Jul 2001 15:40:04 -0000 Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f66FdMi10092; Fri, 6 Jul 2001 11:39:22 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id LAA24076; Fri, 6 Jul 2001 11:39:21 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id LAA28328; Fri, 6 Jul 2001 11:39:21 -0400 From: Ran Canetti Message-Id: <200107061539.LAA28328@ornavella.watson.ibm.com> To: canetti@watson.ibm.com, cfm@sparta.com, msec@securemulticast.org Subject: RE: [MSEC] De-registration protocol? 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, 6 Jul 2001 11:39:21 -0400 Carl, Indeed, you touched upon an important issue, which is probably the crux of this discussion: what should be the API of the msec protocl suite? This is something for us (msec) to decide, and it is indeed a delicate issue... In particular, we have to keep the API in mind when discussing the placement of the de-registration message. As I see it, as far as "leaving a group" goes, the msec API within a member should allow for to different "leave" instructions: 1. "Silent leave". Here the application tells msec that the member wishes to just stop listening to the group. Here there is no need in notifying the GCKS, only to reset local variables. 2. "De-registration" (or whatever better name we'll find for this instruction). Here msec is required to explicitly notify the GCKS that a member has de-registered. This requires communication with the GCKS, in one way or another. Once the msec module inside the GCKS receives such a communication from the msec module inside the member, it will do two things: - update its local state (eg, the LKH/OFT tree) - notify the application that the member has de-registered. This instruction will be useful, for instance, for applications that use pay-until-you-say-enough billing. It is up to the application to decide which of the two instructions to make. Msec should (eventually) be able to deal with both instructions. Ran > From cfm@sparta.com Fri Jul 6 08:18:57 2001 > > Ran, > > Let me clarify my position. > > If the purpose of the "De-registration protocol" is to accomplish > business requirements, beyond key management, such as suspension of > billing or ceasing transmission of content, then I don't think the > Key Management System is the appropriate place for it. If the purpose > of the "De-registration protocol" is to support the correct or > efficient operation of the Key Management System, and use of that > protocol supports the business needs of the overall Business > Management System, then I would support its inclusion in the Key > Management System. > > Now I'm still agnostic as to whether there is a valid key management > reason for members to notify the group (or the group controller) that > they are resigning, unless the Key Management System will be doing > something about it (such as issuing a compromise recovery event to > ensure that the departing member has actually departed). If msec wants to accomodate applications that use pay-until-you-say-enough billing, then it should indeed issue such compromise recovery event when a member leaves. > > In looking at your description below, are we asking the multicast > application to distinguish between "de-registration" and "leaving" > the group. For example, if you have an "internet tuner" which can > "tune in" to different multicast channels, will moving from > "SHOWTIME" to "HBO" cause the local MSEC implementation to > "de-register" from SHOWTIME, and register with HBO, or will the > application be smart enough (and bother the user enough) to know that > changing the channel was not the same as "de-registering"? > > In the described scenarios, who is actually doing the IGMP > join/leave? Has that been added to MSEC, or is it in the application? > When we look at the effect of a GKM "resignation" (I think that word > is much better than "de-registration"), it only makes sense if it is > done in concert with other communications and application actions, > otherwise we've just made the system unstable, or non-responsive > (things which security applications are too often accused of). As I said above, the application should have the choice to either leave silently or to explicitly "resign" or "de-register". IT is up to the application to decide which one to use. Msec should be able to accomodate both. > > carl. > > On 7/6/01 at 12:54 AM -0400, Ran Canetti wrote: > > > >Carl, Mark, > > > >I think I was too hasty in agreeing and didnt read Carl's note thoroughly > >enough. What I agreed to was the idea that the issues brought up by Sandro, > >i.e., the inherent reliability problems associated with the > >pay-until-you-say-enough model, are best dealt with by the application. > > > >On second reading, however, it seems that you may have meant that the entire > >de-registration operation is best done at the application layer. Here I beg > >to differ: > > > >It is very true that the de-registration operation is driven by a request > >of the application *within the group member*. The natural place for this > >request to go is to the msec "layer" (or, "module") within the member. > >Then the msec layer within the member will do what is needed, > >ie, transmit this request securely to the msec layer within the GCKS. > >The msec layer within the GCKS will then notify the application > >layer within the GCKS (eg, the billing center) that the member has > >de-registered. > > > >Pictorially, this would look like: > > > > > > > > GCKS MEMBER > > > > |--------| |----------| > > | | | multicast| > > | applic.| | applicat.| > > | | | | > > |--------| |----------| > > ^ | > > | v > > |--------| |----------| > > | | de-registration | | > > | msec | <------------------------ | msec | > > | | | | > > |--------| |----------| > > > > > >Ie, the flow of information starts at the top right box and goes > >clockwise from there. The other suggestion as I understand it is: > > > > GCKS MEMBER > > > > |--------| |----------| > > | | de-registration | multicast| > > | applic.| <------------------------ | applicat.| > > | | | | > > |--------| |----------| > > | | > > v v > > |--------| |----------| > > | | | | > > | msec | | msec | > > | | | | > > |--------| |----------| > > > > > >This seems worse in my eyes, for the reasons I listed in my previous note. > > > > > >Ran > > > > > >> > >> From canetti@ornavella.watson.ibm.com Thu Jul 5 16:29:01 2001 > >> > >> I agree. > >> > >> Ran > >> > >> > From cfm@sparta.com Thu Jul 5 15:32:15 2001 > >> > > >> > It seems to me that this question of business model has nothing at > >> > all to do with key management. One could just as easily saddle the > >> > multicast transport system with these requirements. (Seems we are > >> > falling into the typical security trap of "well no one else is doing > >> > it, why not security!") > >> > > >> > Ran's comment on mitigations, points the way to a solution, use an > >> > application service to manage the billing. One could then effect > >> > their service delivery decisions through key management. That seems > >> > much more straightforward than trying to effect billing decisions > >> > through key management. > >> > > >> > carl. > >> > > >> > On 7/5/01 at 3:12 PM -0400, Ran Canetti wrote: > >> > > >> > > >> > >Sandro, you're right that this business model of pay-until-you-say-enough > >> > >is susceptible to this type of failures. This is indeed something that > >> > >the > >> > >application will have to deal with... but this business model seems to be > >> > >attractive in some cases nonetheless. (one way to mitigate this is to put > >> > >a cap on the payment amount, on the duration, etc. for instance in a > >> > >boxing > >> > >show you never pay more than the full 12 rounds.) > >> > > > >> > >Ran > >> > > > > > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec > > > -- > Carl F. Muckenhirn > Division Manager > SPARTA, Inc. > Security Engineering Division > 9861 Broken Land Parkway, Suite 300 > Columbia, Maryland 21046 > 410.381.9400 x208 > 410.381.5559 (fax) > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jul 6 11:49:56 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09319 for ; Fri, 6 Jul 2001 11:49:55 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 3ED92536FE; Fri, 6 Jul 2001 11:50:12 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id A336C536B8 for ; Fri, 6 Jul 2001 11:48:41 -0400 (EDT) Received: (qmail 54792 invoked by uid 3269); 6 Jul 2001 15:48:41 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 54789 invoked from network); 6 Jul 2001 15:48:41 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 6 Jul 2001 15:48:41 -0000 Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f66Fm4i21332; Fri, 6 Jul 2001 11:48:04 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id LAA101176; Fri, 6 Jul 2001 11:48:04 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id LAA35692; Fri, 6 Jul 2001 11:48:03 -0400 From: Ran Canetti Message-Id: <200107061548.LAA35692@ornavella.watson.ibm.com> To: canetti@watson.ibm.com, cfm@sparta.com, msec@securemulticast.org Subject: RE: [MSEC] De-registration protocol? 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, 6 Jul 2001 11:48:03 -0400 Carl, > From cfm@sparta.com Fri Jul 6 08:33:52 2001 [...] > > Having not seen an API for the MSEC module, I can't comment on > whether the addition of a resignation interaction is a problem for > the user or not. I thought that one aim of the current MSEC approach > is to closely follow the IPSEC APIs. I guess we could map a "delete > key" to a "resign" at the interface, though "delete key" is local, > and "resign" has network traffic implications. See my previous note... > > Now that I start thinking about it. How are we to deal with a group > whose natural life has ended? A content application finishes, and > notifies all subscribing members (i.e. broadcasts) that "the > broadcast day has ended", will each application issue a "delete key" > to the local MSEC, causing a flood of resignations? Is that what we > want? Good question... has to be taken into consideration when designing the msec API. > > In the "pay-until-you-say-enough" model, it should be the using > application which notifies the sending application that it's had > enough, I would put the burden on the sending application to key-out > any folks who it wants to ensure are off the air. Alternatively, as I > mention above, if it is monitoring the leaves and joins it can leave > the key in place (make it easy for the customer to "tune in" again) > and start charging when he sees them re-join the multicast group. Indeed, the member application should be the one that invokes the instruction to leave. But it should be msec that does the work for the application. How can the sender application key-out people? the sender application has no access to the keys. the keys are part of the msec module. Keying somebody out must be done by msec. Ran _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jul 6 12:01:25 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09848 for ; Fri, 6 Jul 2001 12:01:24 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id ABFCB5364F; Fri, 6 Jul 2001 12:01:40 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 018FC53590 for ; Fri, 6 Jul 2001 11:59:36 -0400 (EDT) Received: (qmail 55728 invoked by uid 3269); 6 Jul 2001 15:59:35 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 55722 invoked from network); 6 Jul 2001 15:59:35 -0000 Received: from softdnserror (HELO M5.sparta.com) (root@157.185.61.1) by klesh.pair.com with SMTP; 6 Jul 2001 15:59:35 -0000 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by M5.sparta.com (8.11.0/8.11.0) with ESMTP id f66FxXx23216; Fri, 6 Jul 2001 10:59:33 -0500 Received: from [157.185.80.3] (dhcp-2.columbia.sparta.com [157.185.80.3]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id LAA29409; Fri, 6 Jul 2001 11:57:57 -0400 (EDT) Mime-Version: 1.0 X-Sender: cfm@pop.columbia.sparta.com Message-Id: In-Reply-To: <200107061539.LAA28328@ornavella.watson.ibm.com> References: <200107061539.LAA28328@ornavella.watson.ibm.com> To: Ran Canetti , msec@securemulticast.org From: "Carl F. Muckenhirn" Subject: RE: [MSEC] De-registration protocol? 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, 6 Jul 2001 11:59:29 -0400 Ran, Yes I see the usefulness in the local host of the two types of API interactions. Now the question is what happens with them. As you note in-line below, a CR event is a valid way to accomplish the providers aim of only providing traffic to paying customers. What I don't want to see happen is for users to resign, and immediately cause a CR event (think of the mischief one can wreak), I really see the resignation being a message from the user's multicast application, to what ever management application is operating the broadcast, that management application would be able to schedule/cause CR events, of his choosing, at times of his choosing (e.g., we've had 100 resignations, lets key them out). Again, I don't see a real need for the member to tell the GCKS that he's out (the GCKS really can't do anything about it), because any action the GCKS takes is now at the bidding of the (potentially) un-trustworthy member rather than the trustworthy group owner. carl. On 7/6/01 at 11:39 AM -0400, Ran Canetti wrote: >Carl, > >Indeed, you touched upon an important issue, which is probably the crux of >this discussion: what should be the API of the msec protocl suite? >This is something for us (msec) to decide, and it is indeed a delicate >issue... In particular, we have to keep the API in mind when discussing the >placement of the de-registration message. > >As I see it, as far as "leaving a group" goes, the msec API within a member >should allow for to different "leave" instructions: > > 1. "Silent leave". Here the application tells msec that the member wishes > to just stop listening to the group. Here there is no need in notifying the > GCKS, only to reset local variables. > > 2. "De-registration" (or whatever better name we'll find for this > instruction). Here msec is required to explicitly notify the GCKS that a > member has de-registered. This requires communication with the GCKS, > in one way or another. > Once the msec module inside the GCKS receives such a communication from > the msec module inside the member, it will do two things: > - update its local state (eg, the LKH/OFT tree) > - notify the application that the member has de-registered. > > This instruction will be useful, for instance, for applications that > use pay-until-you-say-enough billing. > >It is up to the application to decide which of the two instructions to >make. Msec should (eventually) be able to deal with both instructions. > >Ran > > >> From cfm@sparta.com Fri Jul 6 08:18:57 2001 >> >> Ran, >> >> Let me clarify my position. >> >> If the purpose of the "De-registration protocol" is to accomplish >> business requirements, beyond key management, such as suspension of >> billing or ceasing transmission of content, then I don't think the >> Key Management System is the appropriate place for it. If the purpose >> of the "De-registration protocol" is to support the correct or >> efficient operation of the Key Management System, and use of that >> protocol supports the business needs of the overall Business >> Management System, then I would support its inclusion in the Key >> Management System. >> >> Now I'm still agnostic as to whether there is a valid key management > > reason for members to notify the group (or the group controller) that > > they are resigning, unless the Key Management System will be doing > > something about it (such as issuing a compromise recovery event to >> ensure that the departing member has actually departed). > >If msec wants to accomodate applications that use pay-until-you-say-enough >billing, then it should indeed issue such compromise recovery event when >a member leaves. > >> >> In looking at your description below, are we asking the multicast >> application to distinguish between "de-registration" and "leaving" >> the group. For example, if you have an "internet tuner" which can >> "tune in" to different multicast channels, will moving from >> "SHOWTIME" to "HBO" cause the local MSEC implementation to > > "de-register" from SHOWTIME, and register with HBO, or will the >> application be smart enough (and bother the user enough) to know that >> changing the channel was not the same as "de-registering"? >> >> In the described scenarios, who is actually doing the IGMP >> join/leave? Has that been added to MSEC, or is it in the application? >> When we look at the effect of a GKM "resignation" (I think that word >> is much better than "de-registration"), it only makes sense if it is >> done in concert with other communications and application actions, >> otherwise we've just made the system unstable, or non-responsive >> (things which security applications are too often accused of). > >As I said above, the application should have the choice to either leave >silently or to explicitly "resign" or "de-register". IT is up to the >application to decide which one to use. Msec should be able to accomodate >both. > > >> >> carl. >> >> On 7/6/01 at 12:54 AM -0400, Ran Canetti wrote: >> >> >> >Carl, Mark, >> > >> >I think I was too hasty in agreeing and didnt read Carl's note thoroughly >> >enough. What I agreed to was the idea that the issues brought up >>by Sandro, >> >i.e., the inherent reliability problems associated with the >> >pay-until-you-say-enough model, are best dealt with by the application. >> > >> >On second reading, however, it seems that you may have meant that >>the entire >> >de-registration operation is best done at the application layer. Here I beg >> >to differ: >> > >> >It is very true that the de-registration operation is driven by a request >> >of the application *within the group member*. The natural place for this >> >request to go is to the msec "layer" (or, "module") within the member. >> >Then the msec layer within the member will do what is needed, >> >ie, transmit this request securely to the msec layer within the GCKS. >> >The msec layer within the GCKS will then notify the application >> >layer within the GCKS (eg, the billing center) that the member has >> >de-registered. >> > >> >Pictorially, this would look like: >> > >> > >> > >> > GCKS MEMBER >> > >> > |--------| |----------| >> > | | | multicast| >> > | applic.| | applicat.| >> > | | | | >> > |--------| |----------| >> > ^ | >> > | v >> > |--------| |----------| >> > | | de-registration | | >> > | msec | <------------------------ | msec | >> > | | | | >> > |--------| |----------| >> > >> > >> >Ie, the flow of information starts at the top right box and goes >> >clockwise from there. The other suggestion as I understand it is: >> > >> > GCKS MEMBER >> > >> > |--------| |----------| >> > | | de-registration | multicast| >> > | applic.| <------------------------ | applicat.| >> > | | | | >> > |--------| |----------| >> > | | >> > v v >> > |--------| |----------| >> > | | | | >> > | msec | | msec | >> > | | | | >> > |--------| |----------| >> > >> > >> >This seems worse in my eyes, for the reasons I listed in my previous note. >> > >> > >> >Ran >> > >> > >> >> >> >> From canetti@ornavella.watson.ibm.com Thu Jul 5 16:29:01 2001 >> >> >> >> I agree. >> >> >> >> Ran >> >> >> >> > From cfm@sparta.com Thu Jul 5 15:32:15 2001 >> >> > >> >> > It seems to me that this question of business model has nothing at > > >> > all to do with key management. One could just as easily saddle the >> >> > multicast transport system with these requirements. (Seems we are >> >> > falling into the typical security trap of "well no one else is doing >> >> > it, why not security!") >> >> > >> >> > Ran's comment on mitigations, points the way to a solution, use an >> >> > application service to manage the billing. One could then effect >> >> > their service delivery decisions through key management. That seems >> >> > much more straightforward than trying to effect billing decisions >> >> > through key management. >> >> > >> >> > carl. >> >> > >> >> > On 7/5/01 at 3:12 PM -0400, Ran Canetti wrote: >> >> > >> >> > >> >> > >Sandro, you're right that this business model of >>pay-until-you-say-enough >> >> > >is susceptible to this type of failures. This is indeed >>something that >> >> > >the >> >> > >application will have to deal with... but this business >>model seems to be >> >> > >attractive in some cases nonetheless. (one way to mitigate >>this is to put >> >> > >a cap on the payment amount, on the duration, etc. for instance in a >> >> > >boxing >> >> > >show you never pay more than the full 12 rounds.) >> >> > > >> >> > >Ran >> >> > > >> > >> > >> >_______________________________________________ >> >msec mailing list >> >msec@securemulticast.org >> >http://www.pairlist.net/mailman/listinfo/msec >> >> >> -- >> Carl F. Muckenhirn >> Division Manager >> SPARTA, Inc. >> Security Engineering Division >> 9861 Broken Land Parkway, Suite 300 >> Columbia, Maryland 21046 >> 410.381.9400 x208 >> 410.381.5559 (fax) >> >> > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec -- Carl F. Muckenhirn Division Manager SPARTA, Inc. Security Engineering Division 9861 Broken Land Parkway, Suite 300 Columbia, Maryland 21046 410.381.9400 x208 410.381.5559 (fax) _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jul 6 12:08:15 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10292 for ; Fri, 6 Jul 2001 12:08:15 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 879A353717; Fri, 6 Jul 2001 12:06:17 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 1D703536BC for ; Fri, 6 Jul 2001 12:04:42 -0400 (EDT) Received: (qmail 56304 invoked by uid 3269); 6 Jul 2001 16:04:41 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 56299 invoked from network); 6 Jul 2001 16:04:41 -0000 Received: from m5.sparta.com (root@157.185.61.1) by klesh.pair.com with SMTP; 6 Jul 2001 16:04:41 -0000 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by M5.sparta.com (8.11.0/8.11.0) with ESMTP id f66G4ex23562; Fri, 6 Jul 2001 11:04:40 -0500 Received: from [157.185.80.3] (dhcp-2.columbia.sparta.com [157.185.80.3]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id MAA29494; Fri, 6 Jul 2001 12:02:59 -0400 (EDT) Mime-Version: 1.0 X-Sender: cfm@pop.columbia.sparta.com Message-Id: In-Reply-To: <200107061548.LAA35692@ornavella.watson.ibm.com> References: <200107061548.LAA35692@ornavella.watson.ibm.com> To: Ran Canetti , msec@securemulticast.org From: "Carl F. Muckenhirn" Subject: RE: [MSEC] De-registration protocol? 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, 6 Jul 2001 12:04:31 -0400 Ran, see below, On 7/6/01 at 11:48 AM -0400, Ran Canetti wrote: >Carl, > >> From cfm@sparta.com Fri Jul 6 08:33:52 2001 > >[...] > >> >> Having not seen an API for the MSEC module, I can't comment on >> whether the addition of a resignation interaction is a problem for >> the user or not. I thought that one aim of the current MSEC approach >> is to closely follow the IPSEC APIs. I guess we could map a "delete >> key" to a "resign" at the interface, though "delete key" is local, >> and "resign" has network traffic implications. > >See my previous note... > >> >> Now that I start thinking about it. How are we to deal with a group >> whose natural life has ended? A content application finishes, and >> notifies all subscribing members (i.e. broadcasts) that "the >> broadcast day has ended", will each application issue a "delete key" >> to the local MSEC, causing a flood of resignations? Is that what we >> want? > >Good question... has to be taken into consideration when designing the msec >API. > >> >> In the "pay-until-you-say-enough" model, it should be the using >> application which notifies the sending application that it's had >> enough, I would put the burden on the sending application to key-out >> any folks who it wants to ensure are off the air. Alternatively, as I >> mention above, if it is monitoring the leaves and joins it can leave >> the key in place (make it easy for the customer to "tune in" again) >> and start charging when he sees them re-join the multicast group. > >Indeed, the member application should be the one that invokes the >instruction to leave. But it should be msec that does the work for the >application. How can the sender application key-out people? the sender >application has no access to the keys. the keys are part of the msec >module. Keying somebody out must be done by msec. > Actually the GCKS keys the member out, under the direction of the group owner. We may be over using the term MSEC, I see MSEC as the underlying security for the data transport (analogous to IPSEC), the GCKS/KDC plays a role in group management, akin to that provided in IPSEC by ISAKMP/IKE. The GCKS/KDC participates in members setting up their MSEC modules, much like IKE is used to set up IPSEC for use. carl. >Ran -- Carl F. Muckenhirn Division Manager SPARTA, Inc. Security Engineering Division 9861 Broken Land Parkway, Suite 300 Columbia, Maryland 21046 410.381.9400 x208 410.381.5559 (fax) _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jul 6 12:13:10 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10565 for ; Fri, 6 Jul 2001 12:13:09 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 986F553739; Fri, 6 Jul 2001 12:06:41 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id AE4505356F for ; Fri, 6 Jul 2001 12:05:25 -0400 (EDT) Received: (qmail 56361 invoked by uid 3269); 6 Jul 2001 16:05:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 56358 invoked from network); 6 Jul 2001 16:05:24 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 6 Jul 2001 16:05:24 -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.11.3/8.9.1) with ESMTP id f66G4wx06038; Fri, 6 Jul 2001 09:04:58 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-396.cisco.com [10.21.65.140]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AED03225; Fri, 6 Jul 2001 09:04:47 -0700 (PDT) Message-Id: <4.3.2.7.2.20010706084514.042923f8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Ran Canetti From: Mark Baugher Subject: RE: [MSEC] De-registration protocol? Cc: msec@securemulticast.org In-Reply-To: <200107060456.AAA32104@ornavella.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 06 Jul 2001 09:04:13 -0700 Hi Ran At 12:56 AM 7/6/2001 -0400, Ran Canetti wrote: > > > >- It will force the application to set up its own secure channels between > > >each member and the GCKS. This would be done in addition to the msec > secure > > >channels, will require its own negotiations, policy, etc. Why burden the > > >application with all that? > > > > I think it's unavoidable. It's not that bad since SSL, SET, or other > > protocols > > may be better suited to the purpose and, in the case of SSL, it is widely > > available. This is true for trust (e.g. certificate management) and other > > services that may be need for some key management applications. > >I disagree. If we design things right then there will be no reason for the >member application program to set up a secure connection with the GCKS >aside from what msec does. Requiring the application to do this redundant >security overhead undermines the usability of msec. If the application >has to do security by itself then it has good incentive to bypass >msec altogether... We're not talking about setting up a secure connection with the GCKS but with the thing or things that control the group key management - these entities may or may not be co-resident with the GCKS. Figure 2 of http://search.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt draws us a picture. There is a block labelled "AUTHORIZATION" in Figure 2. Hugh pointed out that policy must be enforced at the member so Figure 2 should probably show AUTHORIZATION there as well as at the GCKS. This AUTHORIZATION app acts on behalf of the Group Owner and controls application-specific things like accounting in an IT environment, billing in a commercial environment, clearing for DRM, intrusion detection, etc., as well as group key management. Our concern is with the block labelled "GKM" in Figure 2. Application- specific processing like when a member ceased using a key is outside of GKM, which has no idea what a security protocol implementation is doing with a key that GKM copied into its space. To remove a member, something must tell the GKM to Re-key the group using membership management (LKH) and that's got to be AUTHORIZATION. If there is any need for a member to ask the GCKS to Re-key it out of a group, then this should be considered in conjunction of the Re-key protocol, not the Registration protocol. I think we should move on to discuss the Re-key protocol, which needs to be considered by the WG. With all the talk about policy and de-registration, we have overlooked the most important change proposed in http://search.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt and that is the idea of putting a Re-key protocol specification on a separate standards track. We have probably explored this issue of de-registration to the point where we should agree to disagree - for now. Mark > > > > > > >- It will force us to set up a way for the msec module in the GCKS to > > >receive > > >leave operations from the application module. This will complicate the > > >interface of the msec module inside the GCKS. > > > > What's the "msec module?" In GDOI, there is an authorization interface > > (as there is in IKE and other key management systems). For GDOI, > > this interface is where key management gets told to send a Re-key > > message. There is zero overhead here. > >If the application prorgam within the member sends a de-registration message >to the application program in the GCKS then the latter should notify the >msec "layer" (or, "module") that the member has left and should be removed >from the LKH/OFT tree. This last notification is part of the interface >between the msec module/layer and the outside world. > > > > > > > >- It will disallow joining the de-registration operation with other msec > > >operations (such as sending the de-registration message over a long-lived > > >msec secure channel). > > > > There is no de-registration message and there should not be one in my > > opinion. I think this is the crux of cfm's posting, if I read it right. > >The premise of this discussion is that we're in the >pay-until-you-say-enough model. In this model the member has to somhow >notify the GCKS that it has left (otherwise it will keep paying). >I call this notification the "de-registration message", in whatever layer it >takes place. > >Ran > > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jul 6 12:35:11 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11783 for ; Fri, 6 Jul 2001 12:35:09 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 16164537AA; Fri, 6 Jul 2001 12:14:51 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 5115153702 for ; Fri, 6 Jul 2001 12:12:28 -0400 (EDT) Received: (qmail 57216 invoked by uid 3269); 6 Jul 2001 16:12:28 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 57213 invoked from network); 6 Jul 2001 16:12:27 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 6 Jul 2001 16:12:27 -0000 Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f66GBoi08766; Fri, 6 Jul 2001 12:11:50 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id MAA24296; Fri, 6 Jul 2001 12:11:50 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id MAA28374; Fri, 6 Jul 2001 12:11:50 -0400 From: Ran Canetti Message-Id: <200107061611.MAA28374@ornavella.watson.ibm.com> To: canetti@watson.ibm.com, cfm@sparta.com, msec@securemulticast.org Subject: RE: [MSEC] De-registration protocol? 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, 6 Jul 2001 12:11:50 -0400 Carl, Yes, msec must take caution to implement the API without being susceptible to such attacks as you describe. Your aggregation method is one good solution. Another way is to have periodic rekey message and to aggregate all the membership changes in one rekey message per, say, 2 minutes. Other ways are possible too. In any case in our model it is the GCKS who is responsible for the rekeying, not the sender. (The two may be co-located, but that's a different issue.) > From msec-admin@securemulticast.org Fri Jul 6 12:01:49 2001 > > Ran, > > Yes I see the usefulness in the local host of the two types of API > interactions. Now the question is what happens with them. > > As you note in-line below, a CR event is a valid way to accomplish > the providers aim of only providing traffic to paying customers. What > I don't want to see happen is for users to resign, and immediately > cause a CR event (think of the mischief one can wreak), I really see > the resignation being a message from the user's multicast > application, to what ever management application is operating the > broadcast, that management application would be able to > schedule/cause CR events, of his choosing, at times of his choosing > (e.g., we've had 100 resignations, lets key them out). > > Again, I don't see a real need for the member to tell the GCKS that > he's out (the GCKS really can't do anything about it), because any > action the GCKS takes is now at the bidding of the (potentially) > un-trustworthy member rather than the trustworthy group owner. We may have terminology problems here. the GCKS *is* the group owner. It authenticates members when it talks to them, so there is no issue of trustworthiness. Ran > > carl. > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jul 6 15:15:49 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16584 for ; Fri, 6 Jul 2001 15:15:47 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 93A99536F0; Fri, 6 Jul 2001 15:16:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id A7AE75365A for ; Fri, 6 Jul 2001 15:14:42 -0400 (EDT) Received: (qmail 73449 invoked by uid 3269); 6 Jul 2001 19:14:42 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 73446 invoked from network); 6 Jul 2001 19:14:42 -0000 Received: from chmls06.mediaone.net (24.147.1.144) by klesh.pair.com with SMTP; 6 Jul 2001 19:14:42 -0000 Received: from THARDJONO-LAP.mediaone.net ([63.90.80.227]) by chmls06.mediaone.net (8.11.1/8.11.1) with ESMTP id f66JEd812497; Fri, 6 Jul 2001 15:14:39 -0400 (EDT) Message-Id: <5.0.0.25.2.20010706142710.01fddea8@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: Ran Canetti , msec@securemulticast.org From: Thomas Hardjono Subject: RE: [MSEC] De-registration protocol? In-Reply-To: <200107060456.AAA32104@ornavella.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 06 Jul 2001 14:33:09 -0400 At 7/6/2001||12:56 AM, Ran Canetti wrote: >I disagree. If we design things right then there will be no reason for the >member application program to set up a secure connection with the GCKS >aside from what msec does. Requiring the application to do this redundant >security overhead undermines the usability of msec. If the application >has to do security by itself then it has good incentive to bypass >msec altogether... Ran, Rather than handwaiving "design things right", why don't you write a draft to address the Deregistration SA management and key management. I would be happy to review it once you finish writing the draft. thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jul 6 15:57:51 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17693 for ; Fri, 6 Jul 2001 15:57:49 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2AA2753604; Fri, 6 Jul 2001 15:58:05 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 2B79C535BF for ; Fri, 6 Jul 2001 15:58:00 -0400 (EDT) Received: (qmail 76959 invoked by uid 3269); 6 Jul 2001 19:57:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 76956 invoked from network); 6 Jul 2001 19:57:59 -0000 Received: from chmls20.mediaone.net (24.147.1.156) by klesh.pair.com with SMTP; 6 Jul 2001 19:57:59 -0000 Received: from THARDJONO-LAP.mediaone.net ([63.90.80.227]) by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id f66Jvv628783; Fri, 6 Jul 2001 15:57:57 -0400 (EDT) Message-Id: <5.0.0.25.2.20010706141433.01fddea8@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: "Carl F. Muckenhirn" , msec@securemulticast.org From: Thomas Hardjono Subject: RE: [MSEC] De-registration protocol? In-Reply-To: References: <200107060456.AAA32104@ornavella.watson.ibm.com> <200107060456.AAA32104@ornavella.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 06 Jul 2001 14:26:48 -0400 Carl, At 7/6/2001||08:33 AM, Carl F. Muckenhirn wrote: >Its not clear to me that the member application needs to talk to the GCKS, >if the member application no longer wants to receive the content to which >he is subscribed, he'll have to leave that multicast group. A vigilant >multicast provider, listening to the IGMP all-routers group, will know >which hosts have left and can notify the GCKS (if he desires). This is an interesting question. Do we define "group membership" as IGMP-membership (which in IGMPv2 does not carry any host identity) or as Application-layer membership. I think this notion will best work in IPv6 Neighbour Discovery or in IPv6 MLD. >Since the GCKS is operating on behalf of the content provider/group owner, >I don't see any problem with this model. We will have a GCKS to group >owner connection in either case; in my scenario originated by the group >owner exercising control of the GCKS; in your scenario originated by the >GCKS providing membership updates to the group owner. I'm not sure either >one is more complicated, though it seems (just seems) to me that what we >are trying to do is redundant with other activities necessary for the >efficient operation of the multicast system. As far as I understand it, the GCKS/KDC works at a different (parallel) plane to IGMP. Thus, in fact, the GCKS may not be a member and thus not within the multicast distribution tree. Even if the GCKS was on the multicast distribution tree it will never see anyone's IGMPv2 (or IGMPv3) Report messages, as these are only seen by the subnet (multicast) router and are never propagated upstream. The router only send a "join" or "prune" upstream. thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jul 6 15:59:51 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17764 for ; Fri, 6 Jul 2001 15:59:50 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4D485535BF; Fri, 6 Jul 2001 16:00:06 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 5702A53601 for ; Fri, 6 Jul 2001 15:58:03 -0400 (EDT) Received: (qmail 76984 invoked by uid 3269); 6 Jul 2001 19:58:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 76979 invoked from network); 6 Jul 2001 19:58:02 -0000 Received: from chmls20.mediaone.net (24.147.1.156) by klesh.pair.com with SMTP; 6 Jul 2001 19:58:02 -0000 Received: from THARDJONO-LAP.mediaone.net ([63.90.80.227]) by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id f66Jvu628769; Fri, 6 Jul 2001 15:57:56 -0400 (EDT) Message-Id: <5.0.0.25.2.20010706131538.01fddab8@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: Ran Canetti , msec@securemulticast.org From: Thomas Hardjono Subject: RE: [MSEC] De-registration protocol? In-Reply-To: <200107060454.AAA36404@ornavella.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 06 Jul 2001 15:14:44 -0400 Ran, I will persist on addressing the De-Registration protocol, since I think it will have great impact on the overall key management architecture. At 7/6/2001||12:54 AM, Ran Canetti wrote: >Carl, Mark, > >I think I was too hasty in agreeing and didnt read Carl's note thoroughly >enough. What I agreed to was the idea that the issues brought up by Sandro, >i.e., the inherent reliability problems associated with the >pay-until-you-say-enough model, are best dealt with by the application. > >On second reading, however, it seems that you may have meant that the entire >de-registration operation is best done at the application layer. Here I beg >to differ: > >It is very true that the de-registration operation is driven by a request >of the application *within the group member*. The natural place for this >request to go is to the msec "layer" (or, "module") within the member. >Then the msec layer within the member will do what is needed, >ie, transmit this request securely to the msec layer within the GCKS. >The msec layer within the GCKS will then notify the application >layer within the GCKS (eg, the billing center) that the member has >de-registered. I think you are confusing the concept of a member at the IGMP-level and at the Application-level. At the expense of repeating myself, key management for MSEC would be made extra complex if the KDC is required to maintain (extra) SAs just for a uni-directional "quit" message from a member. Now, if a given Application (eg. PPV) wants to have a Deregister message, then the key management implementation within that Application can *augment* the BASE Msec Key Management protocol with additional keys, SAs and other parameters. Alternatively, the Application-program the member-client can send an Application-layer or Transport-layer "quit" message (digitally signed), directed for processing at the KDC's Application-layer or Transport-layer. This approach is outside msec-key-management, and provides the best flexibility. thomas ------ >Pictorially, this would look like: > > > > GCKS MEMBER > > |--------| |----------| > | | | multicast| > | applic.| | applicat.| > | | | | > |--------| |----------| > ^ | > | v > |--------| |----------| > | | de-registration | | > | msec | <------------------------ | msec | > | | | | > |--------| |----------| > > >Ie, the flow of information starts at the top right box and goes >clockwise from there. The other suggestion as I understand it is: > > GCKS MEMBER > > |--------| |----------| > | | de-registration | multicast| > | applic.| <------------------------ | applicat.| > | | | | > |--------| |----------| > | | > v v > |--------| |----------| > | | | | > | msec | | msec | > | | | | > |--------| |----------| > > >This seems worse in my eyes, for the reasons I listed in my previous note. > > >Ran > > > > > > From canetti@ornavella.watson.ibm.com Thu Jul 5 16:29:01 2001 > > > > I agree. > > > > Ran > > > > > From cfm@sparta.com Thu Jul 5 15:32:15 2001 > > > > > > It seems to me that this question of business model has nothing at > > > all to do with key management. One could just as easily saddle the > > > multicast transport system with these requirements. (Seems we are > > > falling into the typical security trap of "well no one else is doing > > > it, why not security!") > > > > > > Ran's comment on mitigations, points the way to a solution, use an > > > application service to manage the billing. One could then effect > > > their service delivery decisions through key management. That seems > > > much more straightforward than trying to effect billing decisions > > > through key management. > > > > > > carl. > > > > > > On 7/5/01 at 3:12 PM -0400, Ran Canetti wrote: > > > > > > > > > >Sandro, you're right that this business model of > pay-until-you-say-enough > > > >is susceptible to this type of failures. This is indeed something that > > > >the > > > >application will have to deal with... but this business model seems > to be > > > >attractive in some cases nonetheless. (one way to mitigate this is > to put > > > >a cap on the payment amount, on the duration, etc. for instance in a > > > >boxing > > > >show you never pay more than the full 12 rounds.) > > > > > > > >Ran > > > > > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jul 6 23:03:01 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA28234 for ; Fri, 6 Jul 2001 23:02:59 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 109F05382A; Fri, 6 Jul 2001 23:01:34 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id ECBDF535DD for ; Fri, 6 Jul 2001 21:52:46 -0400 (EDT) Received: (qmail 2033 invoked by uid 3269); 7 Jul 2001 01:52:46 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 2030 invoked from network); 7 Jul 2001 01:52:46 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 7 Jul 2001 01:52:46 -0000 Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f671q0M21344; Fri, 6 Jul 2001 21:52:00 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id VAA42596; Fri, 6 Jul 2001 21:52:00 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id VAA34448; Fri, 6 Jul 2001 21:51:59 -0400 From: Ran Canetti Message-Id: <200107070151.VAA34448@ornavella.watson.ibm.com> To: canetti@watson.ibm.com, msec@securemulticast.org, thardjono@mediaone.net Subject: RE: [MSEC] De-registration protocol? 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, 6 Jul 2001 21:51:59 -0400 Thomas, As I said, my impression is that it would end up being both simpler and more secure to handle the de-registration on the msec level rather than leave it to the application. (in particular, this does not require long-lived SA's between the KDC and each member.) Nonetheless, I very much agree with you that the de-registration issue is only part of a larger issue: what functions whould the msec suite provide, and what should the API of msec look like. So let's postpone this doscussion to when we discuss the larger picture of requirements/API. (Cathy Meadows, Paul Syverson and I are currently working on a first draft of an msec requirements document. When its ready the working group will be invited to bite into it and tear it apart...) Ran > > I think you are confusing the concept of a member at the IGMP-level and > at the Application-level. > > At the expense of repeating myself, key management for MSEC would be > made extra complex if the KDC is required to maintain (extra) SAs just > for a uni-directional "quit" message from a member. > > Now, if a given Application (eg. PPV) wants to have a Deregister message, > then the key management implementation within that Application > can *augment* the BASE Msec Key Management protocol with additional > keys, SAs and other parameters. > > Alternatively, the Application-program the member-client can send > an Application-layer or Transport-layer "quit" message (digitally signed), > directed for processing at the KDC's Application-layer or Transport-layer. > This approach is outside msec-key-management, and provides the best > flexibility. > > > thomas _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sat Jul 7 00:45:54 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA29795 for ; Sat, 7 Jul 2001 00:45:52 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id CD01553746; Sat, 7 Jul 2001 00:46:06 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 8385053666 for ; Sat, 7 Jul 2001 00:45:48 -0400 (EDT) Received: (qmail 14170 invoked by uid 3269); 7 Jul 2001 04:45:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 14167 invoked from network); 7 Jul 2001 04:45:47 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 7 Jul 2001 04:45:47 -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.11.3/8.9.1) with ESMTP id f674jLx03754 for ; Fri, 6 Jul 2001 21:45:21 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-tmp196.cisco.com [10.21.64.196]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AEE00469; Fri, 6 Jul 2001 21:45:11 -0700 (PDT) Message-Id: <4.3.2.7.2.20010706213410.0418fe88@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: msec@securemulticast.org From: Mark Baugher Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Re-key as a separate, standards-track protocol specification 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, 06 Jul 2001 21:44:37 -0700 http://search.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt took a surprising turn by introducing Re-key as a separate protocol. David McGrew and Lakshminath Dondeti are working on a Re-key draft. Up to this point, the Re-key message was part of GSAKMP, called "Re-key," and GDOI, called "GROUPKEY-PUSH." Like many things between GSAKMP and GDOI, they have some differences and the latter uses ISAKMP encoding. The authors discussed this at length and agreed to take the route of a separate specification though it is and may remain controversial. There are a couple of ways that we can go here. We could unbundle the key mangement protocol into truly separate protocols that interface through a security association database, as suggested in gkmarch. I expect that GDOI and GSAKMP will continue to offer an integrated solution where the exchanges and messages are bundled into a single protocol. We need to discuss these alternatives and the direction that msec key management will take over the next year. My view is that the separate document should explore the issues such as implosion, member feedback, reliable delivery, and other concerns associated with Re-key, which can be sent either multicast or unicast. It will also define a common encoding for key download and membership management that we will expect the msec key management protocols to adhere to. I don't think we will achieve an identical message format so long as we expect to implement the Re-key message in diverse protocols such as IKE. For this reason, I question whether this can be a standards-track protocol. Mark _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Jul 8 14:36:31 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14771 for ; Sun, 8 Jul 2001 14:36:29 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 700B653907; Sun, 8 Jul 2001 14:34:04 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id EFE5D53974 for ; Sun, 8 Jul 2001 14:33:27 -0400 (EDT) Received: (qmail 59640 invoked by uid 3269); 8 Jul 2001 18:33:27 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 59637 invoked from network); 8 Jul 2001 18:33:27 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by klesh.pair.com with SMTP; 8 Jul 2001 18:33:27 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f68IVEH29268; Sun, 8 Jul 2001 11:31:15 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-tmp48.cisco.com [10.21.64.48]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AEF01501; Sun, 8 Jul 2001 11:32:55 -0700 (PDT) Message-Id: <4.3.2.7.2.20010708111344.01fe7ab8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Ran Canetti From: Mark Baugher Subject: RE: [MSEC] De-registration protocol? Cc: canetti@watson.ibm.com, cfm@sparta.com, msec@securemulticast.org In-Reply-To: <200107061611.MAA28374@ornavella.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Sun, 08 Jul 2001 11:32:19 -0700 Ran, At 12:11 PM 7/6/2001 -0400, Ran Canetti wrote: >We may have terminology problems here. the GCKS *is* the group owner. >It authenticates members when it talks to them, so there is no issue of >trustworthiness. This is not the model of GSAKMP, GDOI, or the GKM architecture. A "policy creation authority" may be used in GSKMP (p.13). A "Group Owner" authorizes a member to join a GDOI group (3.2). In section 3 of GKM architecture, a single group owner is designated as the root of trust. It is true that the GCKS authenticates members. But some other authority authorizes them. You could say that the GCKS is owned and operated by the group owner, and that is a legitimate model. It's also true that the GCKS or its delegate could be co-resident with a sending member. But these are special cases of the more general architecture. For authorization in the more general case, the GCKS acts on behalf of a variety of authorization applications just as the member acts on behalf of a variety of security protocols (viz. Figure 3 in http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt). Mark >Ran > > > > > carl. > > > >_______________________________________________ >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 Sun Jul 8 15:02:25 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14946 for ; Sun, 8 Jul 2001 15:02:25 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8C28453903; Sun, 8 Jul 2001 15:02:44 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id A3973538D7 for ; Sun, 8 Jul 2001 15:01:19 -0400 (EDT) Received: (qmail 61020 invoked by uid 3269); 8 Jul 2001 19:01:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 61017 invoked from network); 8 Jul 2001 19:01:19 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 8 Jul 2001 19:01:19 -0000 Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f68J0UF08914; Sun, 8 Jul 2001 15:00:30 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id PAA86556; Sun, 8 Jul 2001 15:00:31 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id PAA20042; Sun, 8 Jul 2001 15:00:30 -0400 From: Ran Canetti Message-Id: <200107081900.PAA20042@ornavella.watson.ibm.com> To: canetti@watson.ibm.com, mbaugher@cisco.com Subject: RE: [MSEC] De-registration protocol? Cc: cfm@sparta.com, msec@securemulticast.org Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Sun, 8 Jul 2001 15:00:30 -0400 Mark, The question is whether this "authorization module" is going to have its own, independent secure communication with the members (ie, communication that is "out of band" for msec), or if msec handles all the communication between the GCKS/KDC/group-owner/whatever and the members that is relevant to membership in the secure group. It seems to me that the first option is bad security design: -It overburdens the application. now the application has to deal with another type of secure connection, with its own policy issues, subtleties, etc. (also, where will that be specified/standardized?) -This is a wide open hole that simply asks for all kinds of unexpected security weaknesses which result from bad interactions between the msec protocol and the "out of band" communication with the authorization module. When designing a security protocol You dont do "half a job". You provide a complete, well-defined service. Ran > From mbaugher@cisco.com Sun Jul 8 14:33:37 2001 > > Ran, > > At 12:11 PM 7/6/2001 -0400, Ran Canetti wrote: > > >We may have terminology problems here. the GCKS *is* the group owner. > >It authenticates members when it talks to them, so there is no issue of > >trustworthiness. > > This is not the model of GSAKMP, GDOI, or the GKM architecture. A > "policy creation authority" may be used in GSKMP (p.13). A "Group > Owner" authorizes a member to join a GDOI group (3.2). In section > 3 of GKM architecture, a single group owner is designated as the root of trust. > > It is true that the GCKS authenticates members. But some other authority > authorizes them. You could say that the GCKS is owned and operated > by the group owner, and that is a legitimate model. It's also true that the > GCKS or its delegate could be co-resident with a sending member. > But these are special cases of the more general architecture. > > For authorization in the more general case, the GCKS acts on behalf of > a variety of authorization applications just as the member acts on behalf > of a variety of security protocols (viz. Figure 3 in > http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt). > > Mark > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Jul 8 20:14:54 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17111 for ; Sun, 8 Jul 2001 20:14:53 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C68D753917; Sun, 8 Jul 2001 20:15:10 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 5FE74538DF for ; Sun, 8 Jul 2001 16:53:58 -0400 (EDT) Received: (qmail 68376 invoked by uid 3269); 8 Jul 2001 20:53:57 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 68372 invoked from network); 8 Jul 2001 20:53:57 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by klesh.pair.com with SMTP; 8 Jul 2001 20:53:57 -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.11.3/8.9.1) with ESMTP id f68KrWP18775; Sun, 8 Jul 2001 13:53:33 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-tmp48.cisco.com [10.21.64.48]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AEF01890; Sun, 8 Jul 2001 13:53:24 -0700 (PDT) Message-Id: <4.3.2.7.2.20010708134032.01fe1b50@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Ran Canetti From: Mark Baugher Subject: RE: [MSEC] De-registration protocol? Cc: canetti@watson.ibm.com, cfm@sparta.com, msec@securemulticast.org In-Reply-To: <200107081900.PAA20042@ornavella.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Sun, 08 Jul 2001 13:52:48 -0700 Hi Ran I think you are raising an important point. Key management is only one system out of a number of systems that may make up a complete "application" for key management. I would expect, for example, that a service may use a web site for announcement, enrollment of members, payment of services, and other functions. The website will probably use SSL. It probably will not be physically located with the key management server in any installation of any size. But it may be the locus of authorization decisions that tells the GCKS what to do by signing a member's credential, or instructing key management to key the member out of the group. I also expect that an organization may run an accounting system or a commercial service may run a billing system. Secure access to these systems are also needed. Like the website, I don't expect these systems will be run on the GCKS, be physically co-located with the GCKS, or use the same security system as the GCKS. But they may be part of the authorization system that tells the GCKS what to do. The point here is that the member may get authorized in very application-specific ways by interacting with computers other than the GCKS, which authenticates the member and asks for authority to admit the member according to the rules set by an arbitrarily complex external entity. If we want a key management system that is basic enough to support 4 routers, 8 colonels, or a million TV receivers, then we will not incorporate a lot of authorization logic into key management. Mark At 03:00 PM 7/8/2001 -0400, Ran Canetti wrote: >Mark, > >The question is whether this "authorization module" is going to have its >own, independent secure communication with the members (ie, communication >that is "out of band" for msec), or if msec handles all the communication >between the GCKS/KDC/group-owner/whatever and the members that is relevant >to membership in the secure group. > >It seems to me that the first option is bad security design: >-It overburdens the application. now the application has to deal with another >type of secure connection, with its own policy issues, subtleties, etc. >(also, where will that be specified/standardized?) >-This is a wide open hole that simply asks for all kinds of unexpected >security weaknesses which result from bad interactions between the >msec protocol and the "out of band" communication with the authorization >module. When designing a security protocol You dont do "half a job". >You provide a complete, well-defined service. > >Ran > > > > From mbaugher@cisco.com Sun Jul 8 14:33:37 2001 > > > > Ran, > > > > At 12:11 PM 7/6/2001 -0400, Ran Canetti wrote: > > > > >We may have terminology problems here. the GCKS *is* the group owner. > > >It authenticates members when it talks to them, so there is no issue of > > >trustworthiness. > > > > This is not the model of GSAKMP, GDOI, or the GKM architecture. A > > "policy creation authority" may be used in GSKMP (p.13). A "Group > > Owner" authorizes a member to join a GDOI group (3.2). In section > > 3 of GKM architecture, a single group owner is designated as the root > of trust. > > > > It is true that the GCKS authenticates members. But some other authority > > authorizes them. You could say that the GCKS is owned and operated > > by the group owner, and that is a legitimate model. It's also true > that the > > GCKS or its delegate could be co-resident with a sending member. > > But these are special cases of the more general architecture. > > > > For authorization in the more general case, the GCKS acts on behalf of > > a variety of authorization applications just as the member acts on behalf > > of a variety of security protocols (viz. Figure 3 in > > http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt). > > > > Mark > > > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jul 9 13:24:53 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22748 for ; Mon, 9 Jul 2001 13:24:52 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B90E453553; Mon, 9 Jul 2001 13:25:08 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 3911A53541 for ; Mon, 9 Jul 2001 13:23:09 -0400 (EDT) Received: (qmail 80881 invoked by uid 3269); 9 Jul 2001 17:23:08 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 80878 invoked from network); 9 Jul 2001 17:23:07 -0000 Received: from softdnserror (HELO sj-msg-core-3.cisco.com) (171.70.157.152) by klesh.pair.com with SMTP; 9 Jul 2001 17:23:07 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f69HKoH10763 for ; Mon, 9 Jul 2001 10:20:50 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-527.cisco.com [10.21.66.15]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AEK00667; Mon, 9 Jul 2001 10:22:18 -0700 (PDT) Message-Id: <4.3.2.7.2.20010709101858.041d82c8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: msec@securemulticast.org From: Mark Baugher Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] updated gdoi working draft Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 09 Jul 2001 10:20:48 -0700 Thanks to Cathy Meadows for spotting a couple of errors in draft-msec-gdoi-01. New versions are at http://www.rdrop.com/users/mbaugher/draft-ietf-msec-gdoi-01v3.pdf and http://www.rdrop.com/users/mbaugher/draft-ietf-msec-gdoi-01v3.txt Mark _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jul 9 13:58:18 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23981 for ; Mon, 9 Jul 2001 13:58:18 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1FD7C53534; Mon, 9 Jul 2001 13:58:36 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 408B153532 for ; Mon, 9 Jul 2001 13:56:33 -0400 (EDT) Received: (qmail 84114 invoked by uid 3269); 9 Jul 2001 17:56:33 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 84104 invoked from network); 9 Jul 2001 17:56:31 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by klesh.pair.com with SMTP; 9 Jul 2001 17:56:31 -0000 Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.24.13]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f69Hu3P22424; Mon, 9 Jul 2001 10:56:04 -0700 (PDT) Received: from cisco.com ([171.70.196.154]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id ALH01782 (AUTH mcgrew); Mon, 9 Jul 2001 10:55:54 -0700 (PDT) Message-ID: <3B49F153.5B5D1D2E@cisco.com> From: "David A. McGrew" X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Re-key as a separate, standards-track protocol specification References: <4.3.2.7.2.20010706213410.0418fe88@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: Mon, 09 Jul 2001 14:00:51 -0400 Content-Transfer-Encoding: 7bit Mark, Mark Baugher wrote: > > http://search.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt took > a surprising turn by introducing Re-key as a separate protocol. David > McGrew and Lakshminath Dondeti are working on a Re-key draft. Up to this > point, the Re-key message was part of GSAKMP, called "Re-key," and GDOI, > called "GROUPKEY-PUSH." Like many things between GSAKMP and GDOI, they > have some differences and the latter uses ISAKMP encoding. > > The authors discussed this at length and agreed to take the route of a > separate specification though it is and may remain controversial. There > are a couple of ways that we can go here. We could unbundle the key > mangement protocol into truly separate protocols that interface through a > security association database, as suggested in gkmarch. This approach has logical consistency and extensibility on its side. > I expect that GDOI > and GSAKMP will continue to offer an integrated solution where the > exchanges and messages are bundled into a single protocol. This is certainly possible, though I'd hope that the rekey protocol could be easily picked up. > We need to > discuss these alternatives and the direction that msec key management will > take over the next year. > > My view is that the separate document should explore the issues such as > implosion, member feedback, reliable delivery, and other concerns > associated with Re-key, which can be sent either multicast or unicast. My thoughts as well. > It > will also define a common encoding for key download and membership > management that we will expect the msec key management protocols to adhere > to. Perhaps. That depends on the extent to which the group key management is separated from member mangement. For example, if the mapping between LKH leaves and members is defined externally from the rekey protocol, then that protocol is pretty much agnostic about membership management, and can satisfy itself with talking about nodes. > I don't think we will achieve an identical message format so long as > we expect to implement the Re-key message in diverse protocols such as > IKE. For this reason, I question whether this can be a standards-track > protocol. To my mind, there can be a standardized re-key protocol, though the architecture need not mandate the use of that particular protocol. thanks, David > > Mark > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 10 18:48:03 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28158 for ; Tue, 10 Jul 2001 18:48:02 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A999953567; Tue, 10 Jul 2001 18:48:16 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 0CFE853554 for ; Tue, 10 Jul 2001 18:47:35 -0400 (EDT) Received: (qmail 72962 invoked by uid 3269); 10 Jul 2001 22:47:34 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 72959 invoked from network); 10 Jul 2001 22:47:34 -0000 Received: from chmls20.mediaone.net (24.147.1.156) by klesh.pair.com with SMTP; 10 Jul 2001 22:47:34 -0000 Received: from THARDJONO-LAP.mediaone.net (hil-qbu-pth-vty16.as.wcom.net [206.175.104.16]) by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id f6AMlT616032; Tue, 10 Jul 2001 18:47:30 -0400 (EDT) Message-Id: <5.0.0.25.2.20010710104740.018d3668@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: "David A. McGrew" , Mark Baugher From: Thomas Hardjono Subject: Re: [MSEC] Re-key as a separate, standards-track protocol specification Cc: msec@securemulticast.org In-Reply-To: <3B49F153.5B5D1D2E@cisco.com> References: <4.3.2.7.2.20010706213410.0418fe88@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Tue, 10 Jul 2001 11:25:38 -0400 David, At 7/9/2001||02:00 PM, David A. McGrew wrote: >Mark, > >Mark Baugher wrote: > > > > http://search.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt took > > a surprising turn by introducing Re-key as a separate protocol. David > > McGrew and Lakshminath Dondeti are working on a Re-key draft. Up to this > > point, the Re-key message was part of GSAKMP, called "Re-key," and GDOI, > > called "GROUPKEY-PUSH." Like many things between GSAKMP and GDOI, they > > have some differences and the latter uses ISAKMP encoding. > > > > The authors discussed this at length and agreed to take the route of a > > separate specification though it is and may remain controversial. There > > are a couple of ways that we can go here. We could unbundle the key > > mangement protocol into truly separate protocols that interface through a > > security association database, as suggested in gkmarch. > >This approach has logical consistency and extensibility on its side. OK, this is true to some extent. The danger I see is that we end-up with several document-pairs for each group key management protocol: (a) GDOI-Registration and (b) GDOI-Rekey, and (c) GSAKMP-Registration and (d) GSAKMP-Rekey (e) Prot-X-Registration and (f) Prot-X-Rekey It would remain to be seen if (a) can function with (d) or (c) with (b), etc. and the various combinations. > > I expect that GDOI > > and GSAKMP will continue to offer an integrated solution where the > > exchanges and messages are bundled into a single protocol. > >This is certainly possible, though I'd hope that the rekey protocol could be >easily picked up. > > > We need to > > discuss these alternatives and the direction that msec key management will > > take over the next year. > > > > My view is that the separate document should explore the issues such as > > implosion, member feedback, reliable delivery, and other concerns > > associated with Re-key, which can be sent either multicast or unicast. > >My thoughts as well. > > > It > > will also define a common encoding for key download and membership > > management that we will expect the msec key management protocols to adhere > > to. > >Perhaps. That depends on the extent to which the group key management is >separated from member mangement. For example, if the mapping between LKH >leaves >and members is defined externally from the rekey protocol, then that >protocol is >pretty much agnostic about membership management, and can satisfy itself with >talking about nodes. Good point. I think we should look into if membership management is an application-layer issue or wether member data can be managed at layer 3/4 and be accessible by the application. Perhaps a common Membership Management Database (MMD) can be created which contains information such as: - a member's IP address(s) - a member's certificate - the group-IDs of all multicast groups a member is currently joining - the status of a member (eg. active or sleep-mode) - the OFT/LKH tree-ID that a member is employing - the keys of the LKH/OFT key-tree that a member is known to have been given (or perhaps just the key-IDs) - the GCKS designated as the primary GCKS of that member (in anticipation of a distributed GCKS). - IGMP membership information - others (please add) All of these should be at the GCKS/KDC MMD, while some may perhaps reside also at the member/client side MMD. The issue as to *who* decides some of the entry-values, I think, is a Group Policy/Owner matter (at some level). (Not that I'm trying to push the problem under the carpet :) Things like IGMP membership information are available only at group "run time". I think we should define what goes into that MMD and come-up with a simple list. Later we can add more entries to the MMD when we address the broader definition of a group from a layer-3-parameters perspective. That is, later (soon) we will need to address also the notion of "Group" versus "Session" for cases where two or more multicast addresses are used for the same collection of members/hosts (ie. video, audio). If we can see the MMD sitting next to the SAD, then perhaps the MMD is the "interface" (meeting-point) of all of: - IGMP (or IPv6 MLD) -- that may need application-driven membership parameters to carry-out IGMP joins/prunes authentically. - the Rekey Protocol -- that may need parameters to identify tree-IDs, node-key-IDs, member-IDs and Group-IDs - the Application above -- that may set some of these parameters. (Have I confused myself and everyone else :). thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 10 18:48:16 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28173 for ; Tue, 10 Jul 2001 18:48:15 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0E859535F8; Tue, 10 Jul 2001 18:48:28 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 9F46653554 for ; Tue, 10 Jul 2001 18:47:37 -0400 (EDT) Received: (qmail 72967 invoked by uid 3269); 10 Jul 2001 22:47:37 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 72964 invoked from network); 10 Jul 2001 22:47:37 -0000 Received: from chmls20.mediaone.net (24.147.1.156) by klesh.pair.com with SMTP; 10 Jul 2001 22:47:37 -0000 Received: from THARDJONO-LAP.mediaone.net (hil-qbu-pth-vty16.as.wcom.net [206.175.104.16]) by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id f6AMlR616018; Tue, 10 Jul 2001 18:47:27 -0400 (EDT) Message-Id: <5.0.0.25.2.20010710100531.018d37b0@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: Mark Baugher , msec@securemulticast.org From: Thomas Hardjono Subject: Re: [MSEC] Re-key as a separate, standards-track protocol specification In-Reply-To: <4.3.2.7.2.20010706213410.0418fe88@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Tue, 10 Jul 2001 10:47:07 -0400 Mark, At 7/6/2001||09:44 PM, Mark Baugher wrote: >http://search.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt took >a surprising turn by introducing Re-key as a separate protocol. David >McGrew and Lakshminath Dondeti are working on a Re-key draft. Up to this >point, the Re-key message was part of GSAKMP, called "Re-key," and GDOI, >called "GROUPKEY-PUSH." Like many things between GSAKMP and GDOI, they >have some differences and the latter uses ISAKMP encoding. In both GSAKMP and GDOI the "Re-key" message looks deceptively simple, since it is a unidirectional message from the GCKS to the member. Both GSAKMP and GDOI the Rekey message hides much of the details involved with managing the LKH/OFT tree, both on the GCKS side and the member/client side. I am still rather vague about the meaning of "Re-key as a separate protocol", for if we follow what is in GSAKMP and GDOI then the "protocol" would only consist of 2 (control) message types (commands and messages carrying keying material). Initially I sounded the idea of developing (as far as possible) a common payload format for LKH and OFT, so that an implementation could do both without too much differences in code. The understanding was that it would be up to the implementor to implement the mechanics of how to re-shape the key-tree (eg. after a member joins/leaves). >The authors discussed this at length and agreed to take the route of a >separate specification though it is and may remain controversial. There >are a couple of ways that we can go here. We could unbundle the key >mangement protocol into truly separate protocols that interface through a >security association database, as suggested in gkmarch. There are a number of issues that need to be clarified and/or decided upon: - would the Rekey Protocol be unidirectional or would a feedback channel be needed by a member to the GCKS (in the context of rekeying situation/scenario)? - does the Rekey Protocol assume that the Cat-1 SA is still around and does it use it or rely on it in anyway? - does the Rekey Protocol assume reliability of the control channel? - would the Rekey Protocol look different for cases such as ALC and other solutions that embedd rekeying-material in the data stream? Should it try to address these now (or later)? - does the Rekey Protocol manage keys or SAs as well? - if the interface is the SAD, how to delete entries when a rekey occurs and the SAs are "partly" modified (eg. keys changed, but not the other materials, such as the SPI)? etc. >I expect that GDOI and GSAKMP will continue to offer an integrated >solution where the exchanges and messages are bundled into a single >protocol. We need to discuss these alternatives and the direction that >msec key management will take over the next year. - Is the question of bundling a matter of architecture clarity and RFC-readability, or does it go deeper into the fact that the mechanics of the implementation would be simplified if the implementation of Registration and the implementation of the Rekey were truly separated? >My view is that the separate document should explore the issues such as >implosion, member feedback, reliable delivery, and other concerns >associated with Re-key, which can be sent either multicast or unicast. Yes, OK, agree. >It will also define a common encoding for key download and membership >management that we will expect the msec key management protocols to adhere >to. Yes, that was what we set out to at least do, initially. >I don't think we will achieve an identical message format so long as we >expect to implement the Re-key message in diverse protocols such as >IKE. For this reason, I question whether this can be a standards-track >protocol. I think the aim initially was to write an RFC for LKH/OFT so that a developer can easily implement one or both of LKH and OFT. Whether LKH and OFT are so different that this aim cannot be accomplished, must first be studied. If there is sufficient similarities, then perhaps the differences can be put into separate sections/subsections of the document. thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 10 19:41:45 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29974 for ; Tue, 10 Jul 2001 19:41:43 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 74BFB5359B; Tue, 10 Jul 2001 19:42:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 6C4305361D for ; Tue, 10 Jul 2001 19:40:07 -0400 (EDT) Received: (qmail 77077 invoked by uid 3269); 10 Jul 2001 23:40:07 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 77074 invoked from network); 10 Jul 2001 23:40:06 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157) by klesh.pair.com with SMTP; 10 Jul 2001 23:40:06 -0000 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6ANdDb28538 for ; Tue, 10 Jul 2001 19:39:13 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 10 Jul 2001 19:39:12 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3VCZQ6VN; Tue, 10 Jul 2001 19:39:12 -0400 Received: from nortelnetworks.com (LAKSHMINATH1 [47.16.4.71]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3NT9TCM2; Tue, 10 Jul 2001 19:39:12 -0400 Message-ID: <3B4B936A.4E1309BA@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: "Lakshminath Dondeti" Organization: Nortel Networks X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: msec@securemulticast.org Subject: Re: [MSEC] Re-key as a separate, standards-track protocol specification References: <5.0.0.25.2.20010710100531.018d37b0@pop.ne.mediaone.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Tue, 10 Jul 2001 19:44:42 -0400 Content-Transfer-Encoding: 7bit Thomas, Please see inline: Thomas Hardjono wrote: > > Mark, > > At 7/6/2001||09:44 PM, Mark Baugher wrote: > >http://search.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt took > >a surprising turn by introducing Re-key as a separate protocol. David > >McGrew and Lakshminath Dondeti are working on a Re-key draft. Up to this > >point, the Re-key message was part of GSAKMP, called "Re-key," and GDOI, > >called "GROUPKEY-PUSH." Like many things between GSAKMP and GDOI, they > >have some differences and the latter uses ISAKMP encoding. > > In both GSAKMP and GDOI the "Re-key" message looks deceptively simple, since > it is a unidirectional message from the GCKS to the member. > Both GSAKMP and GDOI the Rekey message hides much of the > details involved with managing the LKH/OFT tree, both on the GCKS side > and the member/client side. > > I am still rather vague about the meaning of "Re-key as a separate > protocol", for if we follow what is in GSAKMP and GDOI then > the "protocol" would only consist of 2 (control) message types (commands > and messages carrying keying material). > > Initially I sounded the idea of developing (as far as possible) > a common payload format for LKH and OFT, so that an implementation > could do both without too much differences in code. > The understanding was that it would be up to the implementor > to implement the mechanics of how to re-shape the key-tree (eg. after > a member joins/leaves). We probably can abstract all the messaging requirements of LKH and its cousins. For example, we can say the KDC needs to i) send changes to the key tree, ii)changes in assignment of members to leaf key nodes, and iii)new keys along with their IDs. That information is probably sufficient for a member to figure out which keys it needs to decrypt. I have seen some schemes which work with less information than that. > > >The authors discussed this at length and agreed to take the route of a > >separate specification though it is and may remain controversial. There > >are a couple of ways that we can go here. We could unbundle the key > >mangement protocol into truly separate protocols that interface through a > >security association database, as suggested in gkmarch. > > There are a number of issues that need to be clarified and/or decided > upon: > > - would the Rekey Protocol be unidirectional or would a feedback > channel be needed by a member to the GCKS (in the context of rekeying > situation/scenario)? > > - does the Rekey Protocol assume that the Cat-1 SA is still around > and does it use it or rely on it in anyway? > > - does the Rekey Protocol assume reliability of the control channel? > > - would the Rekey Protocol look different for cases such as ALC > and other solutions that embedd rekeying-material in > the data stream? Should it try to address these now (or later)? > > - does the Rekey Protocol manage keys or SAs as well? > > - if the interface is the SAD, how to delete entries when > a rekey occurs and the SAs are "partly" modified (eg. keys > changed, but not the other materials, such as the SPI)? > etc. Thanks much for this list. David and I are addressing most of the above issues and you might keep us honest :) when you review the rekey I-D. In particular, I believe ALC for reliable transport of rekey messages should be an option in the rekey protocol. > > >I expect that GDOI and GSAKMP will continue to offer an integrated > >solution where the exchanges and messages are bundled into a single > >protocol. We need to discuss these alternatives and the direction that > >msec key management will take over the next year. > > - Is the question of bundling a matter of architecture clarity and > RFC-readability, or does it go deeper into the fact that > the mechanics of the implementation would be simplified > if the implementation of Registration and the implementation > of the Rekey were truly separated? > > >My view is that the separate document should explore the issues such as > >implosion, member feedback, reliable delivery, and other concerns > >associated with Re-key, which can be sent either multicast or unicast. > > Yes, OK, agree. > > >It will also define a common encoding for key download and membership > >management that we will expect the msec key management protocols to adhere > >to. > > Yes, that was what we set out to at least do, initially. > > >I don't think we will achieve an identical message format so long as we > >expect to implement the Re-key message in diverse protocols such as > >IKE. For this reason, I question whether this can be a standards-track > >protocol. > > I think the aim initially was to write an RFC for LKH/OFT so that > a developer can easily implement one or both of LKH and OFT. > Whether LKH and OFT are so different that this aim cannot be accomplished, > must first be studied. If there is sufficient similarities, then > perhaps the differences can be put into separate sections/subsections of > the document. I think the three things (changes to key nodes, changes in member assignment and new keys) I listed earlier are common to LKH/OFC/OFT. best regards, Lakshminath > > 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 Wed Jul 11 00:33:02 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA08948 for ; Wed, 11 Jul 2001 00:33:02 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0376553615; Wed, 11 Jul 2001 00:33:15 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id E7B09535B0 for ; Wed, 11 Jul 2001 00:30:55 -0400 (EDT) Received: (qmail 10546 invoked by uid 3269); 11 Jul 2001 04:30:55 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10542 invoked from network); 11 Jul 2001 04:30:55 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 11 Jul 2001 04:30:55 -0000 Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f6B4UA707712; Wed, 11 Jul 2001 00:30:10 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id AAA24980; Wed, 11 Jul 2001 00:30:10 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id AAA30466; Wed, 11 Jul 2001 00:30:09 -0400 From: Ran Canetti Message-Id: <200107110430.AAA30466@ornavella.watson.ibm.com> To: canetti@watson.ibm.com, mbaugher@cisco.com Subject: RE: [MSEC] De-registration protocol? Cc: cfm@sparta.com, msec@securemulticast.org Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Wed, 11 Jul 2001 00:30:09 -0400 Mark, I think we're very much in agreement here. I agree that the key management is only part of a secure multicast protocol, or service. indeed, msec is chartered to standardize an entire secure multicast protocol suite, of which key management is only a component. It is also clear that the key management protocol should not deal with membership management. There should be different programs/modules that deal with that (including an MMD as Thomas suggested, etc). Nonetheless, the KDC side of the key management protocol should be able to talk with the membership management module. My point was/is that since the membership management module is part of the secure multicast service, msec should provide a standardized way to carry out the communication between the membership management module and a member. This my or may not go through the key management protocol, but it should be taken care of. (As usual, if people want to ignore parts of the standard that's ok. But the standard should provide a complete service.) My feeling is that it may often be convenient to "piggyback" the communication between the member and the MMM (membership management module) on the member-KDC communication (and have the KDC forward the necessary info to the MMM). But this is only an option, as long as the entire service is taken care of. Ran > From msec-admin@securemulticast.org Sun Jul 8 20:15:32 2001 > > Hi Ran > I think you are raising an important point. Key management is only > one system out of a number of systems that may make up a complete > "application" for key management. I would expect, for example, that > a service may use a web site for announcement, enrollment of > members, payment of services, and other functions. The website > will probably use SSL. It probably will not be physically located > with the key management server in any installation of any size. But > it may be the locus of authorization decisions that tells the GCKS > what to do by signing a member's credential, or instructing key > management to key the member out of the group. > > I also expect that an organization may run an accounting system > or a commercial service may run a billing system. Secure access to > these systems are also needed. Like the website, I don't expect > these systems will be run on the GCKS, be physically co-located > with the GCKS, or use the same security system as the GCKS. > But they may be part of the authorization system that tells the > GCKS what to do. > > The point here is that the member may get authorized in very > application-specific ways by interacting with computers other than > the GCKS, which authenticates the member and asks for authority > to admit the member according to the rules set by an arbitrarily > complex external entity. > > If we want a key management system that is basic enough to > support 4 routers, 8 colonels, or a million TV receivers, then we will > not incorporate a lot of authorization logic into key management. > > Mark > At 03:00 PM 7/8/2001 -0400, Ran Canetti wrote: > > >Mark, > > > >The question is whether this "authorization module" is going to have its > >own, independent secure communication with the members (ie, communication > >that is "out of band" for msec), or if msec handles all the communication > >between the GCKS/KDC/group-owner/whatever and the members that is relevant > >to membership in the secure group. > > > >It seems to me that the first option is bad security design: > >-It overburdens the application. now the application has to deal with another > >type of secure connection, with its own policy issues, subtleties, etc. > >(also, where will that be specified/standardized?) > >-This is a wide open hole that simply asks for all kinds of unexpected > >security weaknesses which result from bad interactions between the > >msec protocol and the "out of band" communication with the authorization > >module. When designing a security protocol You dont do "half a job". > >You provide a complete, well-defined service. > > > >Ran > > > > > > > From mbaugher@cisco.com Sun Jul 8 14:33:37 2001 > > > > > > Ran, > > > > > > At 12:11 PM 7/6/2001 -0400, Ran Canetti wrote: > > > > > > >We may have terminology problems here. the GCKS *is* the group owner. > > > >It authenticates members when it talks to them, so there is no issue of > > > >trustworthiness. > > > > > > This is not the model of GSAKMP, GDOI, or the GKM architecture. A > > > "policy creation authority" may be used in GSKMP (p.13). A "Group > > > Owner" authorizes a member to join a GDOI group (3.2). In section > > > 3 of GKM architecture, a single group owner is designated as the root > > of trust. > > > > > > It is true that the GCKS authenticates members. But some other authority > > > authorizes them. You could say that the GCKS is owned and operated > > > by the group owner, and that is a legitimate model. It's also true > > that the > > > GCKS or its delegate could be co-resident with a sending member. > > > But these are special cases of the more general architecture. > > > > > > For authorization in the more general case, the GCKS acts on behalf of > > > a variety of authorization applications just as the member acts on behalf > > > of a variety of security protocols (viz. Figure 3 in > > > http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt). > > > > > > Mark > > > > > > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jul 11 05:46:42 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29142 for ; Wed, 11 Jul 2001 05:46:41 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C76E55360B; Wed, 11 Jul 2001 05:47:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id B5779535C2 for ; Wed, 11 Jul 2001 05:45:35 -0400 (EDT) Received: (qmail 66279 invoked by uid 3269); 11 Jul 2001 09:45:35 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 66276 invoked from network); 11 Jul 2001 09:45:34 -0000 Received: from news.comp.lancs.ac.uk (148.88.152.70) by klesh.pair.com with SMTP; 11 Jul 2001 09:45:34 -0000 Received: from rafaeli (dyn509.dhcp.lancs.ac.uk [148.88.245.9]) by news.comp.lancs.ac.uk (8.11.0/8.11.0) with SMTP id f6B9jS012576 for ; Wed, 11 Jul 2001 10:45:33 +0100 (BST) From: "Sandro Rafaeli" To: Subject: RE: [MSEC] Re-key as a separate, standards-track protocol specification Message-ID: <000001c109ee$266b09a0$09f55894@lancs.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B4B936A.4E1309BA@nortelnetworks.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Wed, 11 Jul 2001 10:44:57 +0100 Content-Transfer-Encoding: 7bit | -----Original Message----- | From: msec-admin@securemulticast.org | [mailto:msec-admin@securemulticast.org]On Behalf Of | Lakshminath Dondeti | Sent: 11 July 2001 00:45 | To: msec@securemulticast.org | Subject: Re: [MSEC] Re-key as a separate, standards-track protocol | specification | | (deleted text) | | We probably can abstract all the messaging requirements of | LKH and its | cousins. For example, we can say the KDC needs to i) send changes | to the key tree, ii)changes in assignment of members to leaf | key nodes, | and iii)new keys along with their IDs. That information is probably | sufficient for a member to figure out which keys it needs to decrypt. | I have seen some schemes which work with less information than that. I wrote a document on an OFT implementation I did in Java. It contains among other things a description of the REKEY protocol I used (message types and formats). It is a very simple protocol, but seems to do the job. After I wrote this document, I implemented another key management protocol (tree-based; very similar to the one of Canetti) and I can use my messages to convey either of them. If anyone is interested in having a look at it I can send you a copy of the document. Regards, Sandro. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jul 11 09:43:46 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03173 for ; Wed, 11 Jul 2001 09:43:45 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A763C53751; Wed, 11 Jul 2001 09:44:05 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 7A8DF536DF for ; Wed, 11 Jul 2001 09:43:22 -0400 (EDT) Received: (qmail 86442 invoked by uid 3269); 11 Jul 2001 13:43:22 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 86439 invoked from network); 11 Jul 2001 13:43:21 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 11 Jul 2001 13:43:21 -0000 Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.24.13]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6BDgrl28666; Wed, 11 Jul 2001 06:42:53 -0700 (PDT) Received: from cisco.com ([171.70.196.154]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id ALT08213 (AUTH mcgrew); Wed, 11 Jul 2001 06:41:31 -0700 (PDT) Message-ID: <3B4C58B8.FA0D396A@cisco.com> From: "David A. McGrew" X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Hardjono Cc: Mark Baugher , msec@securemulticast.org Subject: Re: [MSEC] Re-key as a separate, standards-track protocolspecification References: <4.3.2.7.2.20010706213410.0418fe88@mira-sjc5-6.cisco.com> <5.0.0.25.2.20010710104740.018d3668@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: Wed, 11 Jul 2001 09:46:32 -0400 Content-Transfer-Encoding: 7bit Thomas Hardjono wrote: > > David, > > At 7/9/2001||02:00 PM, David A. McGrew wrote: > >Mark, > > > >Mark Baugher wrote: > > > > > > http://search.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt took > > > a surprising turn by introducing Re-key as a separate protocol. David > > > McGrew and Lakshminath Dondeti are working on a Re-key draft. Up to this > > > point, the Re-key message was part of GSAKMP, called "Re-key," and GDOI, > > > called "GROUPKEY-PUSH." Like many things between GSAKMP and GDOI, they > > > have some differences and the latter uses ISAKMP encoding. > > > > > > The authors discussed this at length and agreed to take the route of a > > > separate specification though it is and may remain controversial. There > > > are a couple of ways that we can go here. We could unbundle the key > > > mangement protocol into truly separate protocols that interface through a > > > security association database, as suggested in gkmarch. > > > >This approach has logical consistency and extensibility on its side. > > OK, this is true to some extent. The danger I see is that we end-up > with several document-pairs for each group key management protocol: > > (a) GDOI-Registration and (b) GDOI-Rekey, and > (c) GSAKMP-Registration and (d) GSAKMP-Rekey > (e) Prot-X-Registration and (f) Prot-X-Rekey > > It would remain to be seen if (a) can function with (d) > or (c) with (b), etc. and the various combinations. I agree that it would probably not be possible to make this method work given two existing protocols. However, I do think that definining the interfaces between the protocols is the appropriate thing for the architecture to do, and is the only way to make the architecture protocol-independent. I'm thinking that what is needed here is a STREAMS architecture for security protocols, in which there are well defined interfaces between each layer, and any module conforming to those interfaces will work in the architecture. I think that the STREAMS analogy is a good one, because one of the major issues that technology deals with is the naming/addressing of endpoints, and interfacing the naming of different protocols is an issue in the crypto architecture. (Please no anti-STREAMS flames! I run BSD all the time!) > > > > I expect that GDOI > > > and GSAKMP will continue to offer an integrated solution where the > > > exchanges and messages are bundled into a single protocol. > > > >This is certainly possible, though I'd hope that the rekey protocol could be > >easily picked up. > > > > > We need to > > > discuss these alternatives and the direction that msec key management will > > > take over the next year. > > > > > > My view is that the separate document should explore the issues such as > > > implosion, member feedback, reliable delivery, and other concerns > > > associated with Re-key, which can be sent either multicast or unicast. > > > >My thoughts as well. > > > > > It > > > will also define a common encoding for key download and membership > > > management that we will expect the msec key management protocols to adhere > > > to. > > > >Perhaps. That depends on the extent to which the group key management is > >separated from member mangement. For example, if the mapping between LKH > >leaves > >and members is defined externally from the rekey protocol, then that > >protocol is > >pretty much agnostic about membership management, and can satisfy itself with > >talking about nodes. > > Good point. I think we should look into if membership management > is an application-layer issue or wether member data can be managed > at layer 3/4 and be accessible by the application. > > Perhaps a common Membership Management Database (MMD) > can be created which contains information such as: > > - a member's IP address(s) > - a member's certificate > - the group-IDs of all multicast groups a member is currently joining > - the status of a member (eg. active or sleep-mode) > - the OFT/LKH tree-ID that a member is employing I think that the node with which a member is associated should be dynamic, so that groups can shrink and grow, so I'd have the initial node assigned in the registration, but the rekey protocol control it once that protocol started. Or did you mean that the MMD exists across both the registration and rekey protocols? > - the keys of the LKH/OFT key-tree that a member is known > to have been given (or perhaps just the key-IDs) > - the GCKS designated as the primary GCKS of that member (in anticipation > of a distributed GCKS). > - IGMP membership information > - others (please add) > > All of these should be at the GCKS/KDC MMD, while > some may perhaps reside also at the member/client side MMD. > > The issue as to *who* decides some of the entry-values, I think, > is a Group Policy/Owner matter (at some level). (Not that I'm trying > to push the problem under the carpet :) > Things like IGMP membership information are available only at > group "run time". > > I think we should define what goes into that MMD and come-up > with a simple list. > > Later we can add more entries to the MMD when we address > the broader definition of a group from a layer-3-parameters perspective. > That is, later (soon) we will need to address > also the notion of "Group" versus "Session" for > cases where two or more multicast addresses are used > for the same collection of members/hosts (ie. video, audio). > > If we can see the MMD sitting next to the SAD, then perhaps > the MMD is the "interface" (meeting-point) of all of: > > - IGMP (or IPv6 MLD) -- that may need application-driven > membership parameters to carry-out IGMP joins/prunes authentically. > > - the Rekey Protocol -- that may need parameters to identify > tree-IDs, node-key-IDs, member-IDs and Group-IDs > > - the Application above -- that may set some of these parameters. > > (Have I confused myself and everyone else :). I don't think so, but you tell me :-) I see the MMD as a set of data which is written and read by the registration and rekey protocols (and perhaps other processes). Presumably there would be an interface defining who writes what when, and what data are allowed to be read when. thanks, David > > thomas > ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jul 11 10:30:12 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05259 for ; Wed, 11 Jul 2001 10:30:11 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 813E25366F; Wed, 11 Jul 2001 10:30:26 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 146D1535FA for ; Wed, 11 Jul 2001 10:28:50 -0400 (EDT) Received: (qmail 92899 invoked by uid 3269); 11 Jul 2001 14:28:49 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 92896 invoked from network); 11 Jul 2001 14:28:49 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 11 Jul 2001 14:28:49 -0000 Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.24.13]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6BESIl03733; Wed, 11 Jul 2001 07:28:19 -0700 (PDT) Received: from cisco.com ([171.70.196.154]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id ALT08735 (AUTH mcgrew); Wed, 11 Jul 2001 07:28:10 -0700 (PDT) Message-ID: <3B4C63A9.1F0B5F93@cisco.com> From: "David A. McGrew" X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Hardjono Cc: Mark Baugher , msec@securemulticast.org Subject: Re: [MSEC] Re-key as a separate, standards-track protocolspecification References: <5.0.0.25.2.20010710100531.018d37b0@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: Wed, 11 Jul 2001 10:33:13 -0400 Content-Transfer-Encoding: 7bit Thomas, good to hear your thoughts, more below: Thomas Hardjono wrote: > > Mark, > > At 7/6/2001||09:44 PM, Mark Baugher wrote: > >http://search.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt took > >a surprising turn by introducing Re-key as a separate protocol. David > >McGrew and Lakshminath Dondeti are working on a Re-key draft. Up to this > >point, the Re-key message was part of GSAKMP, called "Re-key," and GDOI, > >called "GROUPKEY-PUSH." Like many things between GSAKMP and GDOI, they > >have some differences and the latter uses ISAKMP encoding. > > In both GSAKMP and GDOI the "Re-key" message looks deceptively simple, since > it is a unidirectional message from the GCKS to the member. > Both GSAKMP and GDOI the Rekey message hides much of the > details involved with managing the LKH/OFT tree, both on the GCKS side > and the member/client side. > > I am still rather vague about the meaning of "Re-key as a separate > protocol", for if we follow what is in GSAKMP and GDOI then > the "protocol" would only consist of 2 (control) message types (commands > and messages carrying keying material). Does a protocol need to have more than one message to be a protocol? I don't honestly know. Sure, there aren't many messages, but the tree-based keying involves some non-trivial processing. > > Initially I sounded the idea of developing (as far as possible) > a common payload format for LKH and OFT, so that an implementation > could do both without too much differences in code. > The understanding was that it would be up to the implementor > to implement the mechanics of how to re-shape the key-tree (eg. after > a member joins/leaves). And that's exactly what we're working towards. We want the protocol to be independent of the many different design choices that are possible in tree-based keying. For example, the KDC can assign new members anywhere in the tree, can reassign members to different nodes upon deletion or to balance the tree, can create but not assign keys in the tree for future use, and so on. It's clearly best to allow implementations the freedom to make these choices. > > >The authors discussed this at length and agreed to take the route of a > >separate specification though it is and may remain controversial. There > >are a couple of ways that we can go here. We could unbundle the key > >mangement protocol into truly separate protocols that interface through a > >security association database, as suggested in gkmarch. > > There are a number of issues that need to be clarified and/or decided > upon: > > - would the Rekey Protocol be unidirectional or would a feedback > channel be needed by a member to the GCKS (in the context of rekeying > situation/scenario)? We thought that an optional feedback channel (something like RTP's RTCP receiver reports) would be worthwhile, but it's really an open issue. > > - does the Rekey Protocol assume that the Cat-1 SA is still around > and does it use it or rely on it in anyway? This is an important unresolved design decision. > > - does the Rekey Protocol assume reliability of the control channel? No. Our thoughts are that the KDC -> member messages should be idempotent, so that KDC has the option of using repetition to achieve forward error correction. Achieving idempotence is easy enough, and repetition seems to be a sensible way of achieving reliability. > > - would the Rekey Protocol look different for cases such as ALC > and other solutions that embedd rekeying-material in > the data stream? Should it try to address these now (or later)? Sorry, what's ALC? > > - does the Rekey Protocol manage keys or SAs as well? Our thoughts are that it should transport the Data Security SAs, since a change in the group key due to membership changes implies that the keys which it protects should be changed as well. > > - if the interface is the SAD, how to delete entries when > a rekey occurs and the SAs are "partly" modified (eg. keys > changed, but not the other materials, such as the SPI)? Is it possible in MSEC to change the keys for a fixed SPI? thanks, David > etc. > > >I expect that GDOI and GSAKMP will continue to offer an integrated > >solution where the exchanges and messages are bundled into a single > >protocol. We need to discuss these alternatives and the direction that > >msec key management will take over the next year. > > - Is the question of bundling a matter of architecture clarity and > RFC-readability, or does it go deeper into the fact that > the mechanics of the implementation would be simplified > if the implementation of Registration and the implementation > of the Rekey were truly separated? > > >My view is that the separate document should explore the issues such as > >implosion, member feedback, reliable delivery, and other concerns > >associated with Re-key, which can be sent either multicast or unicast. > > Yes, OK, agree. > > >It will also define a common encoding for key download and membership > >management that we will expect the msec key management protocols to adhere > >to. > > Yes, that was what we set out to at least do, initially. > > >I don't think we will achieve an identical message format so long as we > >expect to implement the Re-key message in diverse protocols such as > >IKE. For this reason, I question whether this can be a standards-track > >protocol. > > I think the aim initially was to write an RFC for LKH/OFT so that > a developer can easily implement one or both of LKH and OFT. > Whether LKH and OFT are so different that this aim cannot be accomplished, > must first be studied. If there is sufficient similarities, then > perhaps the differences can be put into separate sections/subsections of > the document. > > 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 Wed Jul 11 11:05:32 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06591 for ; Wed, 11 Jul 2001 11:05:32 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D6FDD537AF; Wed, 11 Jul 2001 11:03:09 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 7836C535EF for ; Wed, 11 Jul 2001 11:01:12 -0400 (EDT) Received: (qmail 96264 invoked by uid 3269); 11 Jul 2001 15:01:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 96259 invoked from network); 11 Jul 2001 15:01:11 -0000 Received: from softdnserror (HELO M5.sparta.com) (root@157.185.61.1) by klesh.pair.com with SMTP; 11 Jul 2001 15:01:11 -0000 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by M5.sparta.com (8.11.0/8.11.0) with ESMTP id f6BF19x24473; Wed, 11 Jul 2001 10:01:10 -0500 Received: from [157.185.80.3] (dhcp-2.columbia.sparta.com [157.185.80.3]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id LAA17588; Wed, 11 Jul 2001 11:01:08 -0400 (EDT) Mime-Version: 1.0 X-Sender: cfm@pop.columbia.sparta.com Message-Id: In-Reply-To: <4.3.2.7.2.20010706213410.0418fe88@mira-sjc5-6.cisco.com> References: <4.3.2.7.2.20010706213410.0418fe88@mira-sjc5-6.cisco.com> To: Mark Baugher , msec@securemulticast.org From: "Carl F. Muckenhirn" Subject: Re: [MSEC] Re-key as a separate, standards-track protocol specification Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Wed, 11 Jul 2001 11:01:06 -0400 On 7/6/01 at 9:44 PM -0700, Mark Baugher wrote: >http://search.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt >took a surprising turn by introducing Re-key as a separate protocol. >David McGrew and Lakshminath Dondeti are working on a Re-key draft. >Up to this point, the Re-key message was part of GSAKMP, called >"Re-key," and GDOI, called "GROUPKEY-PUSH." Like many things >between GSAKMP and GDOI, they have some differences and the latter >uses ISAKMP encoding. > >The authors discussed this at length and agreed to take the route of >a separate specification though it is and may remain controversial. >There are a couple of ways that we can go here. We could unbundle >the key mangement protocol into truly separate protocols that >interface through a security association database, as suggested in >gkmarch. I expect that GDOI and GSAKMP will continue to offer an >integrated solution where the exchanges and messages are bundled >into a single protocol. We need to discuss these alternatives and >the direction that msec key management will take over the next year. In relooking at the gkmarch document, it is unclear that within the document you are consistent. The requirements stated in "2.0 Requirements for a group key management protocol" indicate that a group rekey is part (a function) of the group key management protocol. Requirement 2. "Keys ... will be periodically refreshed." Requirement 3. "Key material must be delivered securely ... and refreshed securely at the end of the key lifetime." Requirement 6. "It must be possible to provide re-key for the group ..." Your description in 3.1 (2) of a "rekey protocol" as optional implies that the requirements above (mandates) will not be met. Your note that there may be other ways of causing members to arrive at a new key, simply states that there are protocols which do not require data transmission, that's ok, its still a protocol. >My view is that the separate document should explore the issues such >as implosion, member feedback, reliable delivery, and other concerns >associated with Re-key, which can be sent either multicast or >unicast. It will also define a common encoding for key download and >membership management that we will expect the msec key management >protocols to adhere to. I don't think we will achieve an identical >message format so long as we expect to implement the Re-key message >in diverse protocols such as IKE. For this reason, I question >whether this can be a standards-track protocol. I think all of these issues are important, but I don't believe that they'll be able to be handled by a "rekey-only" protocol. For example, if we want to work on reliable delivery, what happens when its not delivered, we pop back over to some other protocol. I think it is safer to keep all elements of the group key management protocol together to assure coverage of the features and functions. >Mark > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec carl. -- Carl F. Muckenhirn Division Manager SPARTA, Inc. Security Engineering Division 9861 Broken Land Parkway, Suite 300 Columbia, Maryland 21046 410.381.9400 x208 410.381.5559 (fax) _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jul 11 11:49:43 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08617 for ; Wed, 11 Jul 2001 11:49:42 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 5D7B35358A; Wed, 11 Jul 2001 11:50:04 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 5FC3E5358A for ; Wed, 11 Jul 2001 11:48:36 -0400 (EDT) Received: (qmail 1765 invoked by uid 3269); 11 Jul 2001 15:48:36 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 1760 invoked from network); 11 Jul 2001 15:48:35 -0000 Received: from chmls20.mediaone.net (24.147.1.156) by klesh.pair.com with SMTP; 11 Jul 2001 15:48:35 -0000 Received: from THARDJONO-LAP.mediaone.net (host176-111.cablelabs.com [192.160.73.176]) by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id f6BFmV619306; Wed, 11 Jul 2001 11:48:31 -0400 (EDT) Message-Id: <5.0.0.25.2.20010711102211.018a32a0@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: Ran Canetti From: Thomas Hardjono Subject: RE: [MSEC] De-registration protocol? Cc: mbaugher@cisco.com, msec@securemulticast.org In-Reply-To: <200107110430.AAA30466@ornavella.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Wed, 11 Jul 2001 11:43:02 -0400 Ran, Mark, At 7/11/2001||12:30 AM, Ran Canetti wrote: >Mark, > >I think we're very much in agreement here. > >I agree that the key management is only part of a secure >multicast protocol, or service. indeed, msec is chartered to standardize >an entire secure multicast protocol suite, of which key management is only a >component. > >It is also clear that the key management protocol should not deal with >membership management. There should be different programs/modules that deal >with that (including an MMD as Thomas suggested, etc). Nonetheless, the KDC >side of the key management protocol should be able to talk with the >membership management module. > >My point was/is that since the membership management module is part of >the secure multicast service, msec should provide a standardized way to >carry out the communication between the membership management module >and a member. I am suggesting a simple database (similar to the SAD in functionality) that has a collection of information. It doesn't have to be a complete module (as the term "module" implies). I don't know if we need a standardized way for a member to talk with the MMD. The IPsec/IKE RFCs does not even talk about *how* the SAD is accessed. Its an implementation issue. >This my or may not go through the key management protocol, but >it should be taken care of. (As usual, if people want to ignore parts of >the standard that's ok. But the standard should provide a complete service.) Historically, the IETF tries to to make practical and implementable standards that vendors can implement. This process has a better chance of suceeding if the issue being solved is well defined and does not try to incorporate unncessary componenets/elements. If vendors later want certain things to be included in the MSEC standards, I'm sure they will bring up the issue. We don't want to spend time on parts of MSEC that no one will use, even if it means sacrificing the perception of a "complete service". >My feeling is that it may often be convenient to "piggyback" the >communication between the member and the MMM (membership management module) >on the member-KDC communication (and have the KDC forward the necessary info >to the MMM). But this is only an option, as long as the entire service is >taken care of. Again, I think it is unwise to start talking about communications between the MMD and the member. This may de-focus our current discussion on key management, Rekey-Protocol, and the need of some membership data within the Rekey-Protocol. Ran, I would appreciate if you would not twist the simple MMD into an MMM (whatever MMM may be). Lets just look at the concept of a simple collection of membership information that can be used also by the Registration Prot., Rekey Prot., and IGMP. If it is not needed, then we'll forget about it. Each time I suggest something, you seem to turn it into something else :) thomas ------ >Ran > > > > From msec-admin@securemulticast.org Sun Jul 8 20:15:32 2001 > > > > Hi Ran > > I think you are raising an important point. Key management is only > > one system out of a number of systems that may make up a complete > > "application" for key management. I would expect, for example, that > > a service may use a web site for announcement, enrollment of > > members, payment of services, and other functions. The website > > will probably use SSL. It probably will not be physically located > > with the key management server in any installation of any size. But > > it may be the locus of authorization decisions that tells the GCKS > > what to do by signing a member's credential, or instructing key > > management to key the member out of the group. > > > > I also expect that an organization may run an accounting system > > or a commercial service may run a billing system. Secure access to > > these systems are also needed. Like the website, I don't expect > > these systems will be run on the GCKS, be physically co-located > > with the GCKS, or use the same security system as the GCKS. > > But they may be part of the authorization system that tells the > > GCKS what to do. > > > > The point here is that the member may get authorized in very > > application-specific ways by interacting with computers other than > > the GCKS, which authenticates the member and asks for authority > > to admit the member according to the rules set by an arbitrarily > > complex external entity. > > > > If we want a key management system that is basic enough to > > support 4 routers, 8 colonels, or a million TV receivers, then we will > > not incorporate a lot of authorization logic into key management. > > > > Mark > > At 03:00 PM 7/8/2001 -0400, Ran Canetti wrote: > > > > >Mark, > > > > > >The question is whether this "authorization module" is going to have its > > >own, independent secure communication with the members (ie, communication > > >that is "out of band" for msec), or if msec handles all the communication > > >between the GCKS/KDC/group-owner/whatever and the members that is relevant > > >to membership in the secure group. > > > > > >It seems to me that the first option is bad security design: > > >-It overburdens the application. now the application has to deal with > another > > >type of secure connection, with its own policy issues, subtleties, etc. > > >(also, where will that be specified/standardized?) > > >-This is a wide open hole that simply asks for all kinds of unexpected > > >security weaknesses which result from bad interactions between the > > >msec protocol and the "out of band" communication with the authorization > > >module. When designing a security protocol You dont do "half a job". > > >You provide a complete, well-defined service. > > > > > >Ran > > > > > > > > > > From mbaugher@cisco.com Sun Jul 8 14:33:37 2001 > > > > > > > > Ran, > > > > > > > > At 12:11 PM 7/6/2001 -0400, Ran Canetti wrote: > > > > > > > > >We may have terminology problems here. the GCKS *is* the group owner. > > > > >It authenticates members when it talks to them, so there is no > issue of > > > > >trustworthiness. > > > > > > > > This is not the model of GSAKMP, GDOI, or the GKM architecture. A > > > > "policy creation authority" may be used in GSKMP (p.13). A "Group > > > > Owner" authorizes a member to join a GDOI group (3.2). In section > > > > 3 of GKM architecture, a single group owner is designated as the root > > > of trust. > > > > > > > > It is true that the GCKS authenticates members. But some other > authority > > > > authorizes them. You could say that the GCKS is owned and operated > > > > by the group owner, and that is a legitimate model. It's also true > > > that the > > > > GCKS or its delegate could be co-resident with a sending member. > > > > But these are special cases of the more general architecture. > > > > > > > > For authorization in the more general case, the GCKS acts on behalf of > > > > a variety of authorization applications just as the member acts on > behalf > > > > of a variety of security protocols (viz. Figure 3 in > > > > http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt). > > > > > > > > Mark > > > > > > > > > > > > >_______________________________________________ > > >msec mailing list > > >msec@securemulticast.org > > >http://www.pairlist.net/mailman/listinfo/msec > > > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://www.pairlist.net/mailman/listinfo/msec > > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jul 11 13:05:03 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11524 for ; Wed, 11 Jul 2001 13:05:01 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0310F53635; Wed, 11 Jul 2001 13:04:59 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 78FBD53606 for ; Wed, 11 Jul 2001 13:03:57 -0400 (EDT) Received: (qmail 12875 invoked by uid 3269); 11 Jul 2001 17:03:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 12872 invoked from network); 11 Jul 2001 17:03:56 -0000 Received: from softdnserror (HELO sj-msg-core-4.cisco.com) (171.71.163.10) by klesh.pair.com with SMTP; 11 Jul 2001 17:03:56 -0000 Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.24.13]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6BH3X018034; Wed, 11 Jul 2001 10:03:33 -0700 (PDT) Received: from cisco.com ([171.70.196.154]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id ALU02113 (AUTH mcgrew); Wed, 11 Jul 2001 10:03:21 -0700 (PDT) Message-ID: <3B4C8807.BAA40748@cisco.com> From: "David A. McGrew" X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Sandro Rafaeli Cc: msec@securemulticast.org Subject: Re: [MSEC] Re-key as a separate, standards-track protocol specification References: <000001c109ee$266b09a0$09f55894@lancs.ac.uk> 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: Wed, 11 Jul 2001 13:08:23 -0400 Content-Transfer-Encoding: 7bit Sandro Rafaeli wrote: > > | -----Original Message----- > | From: msec-admin@securemulticast.org > | [mailto:msec-admin@securemulticast.org]On Behalf Of > | Lakshminath Dondeti > | Sent: 11 July 2001 00:45 > | To: msec@securemulticast.org > | Subject: Re: [MSEC] Re-key as a separate, standards-track protocol > | specification > | > | (deleted text) > | > | We probably can abstract all the messaging requirements of > | LKH and its > | cousins. For example, we can say the KDC needs to i) send changes > | to the key tree, ii)changes in assignment of members to leaf > | key nodes, > | and iii)new keys along with their IDs. That information is probably > | sufficient for a member to figure out which keys it needs to decrypt. > | I have seen some schemes which work with less information than that. > > I wrote a document on an OFT implementation I did in Java. It contains among > other things a description of the REKEY protocol I used (message types and > formats). It is a very simple protocol, but seems to do the job. After I > wrote this document, I implemented another key management protocol > (tree-based; very similar to the one of Canetti) and I can use my messages > to convey either of them. If anyone is interested in having a look at it I > can send you a copy of the document. could you please post a pointer to the document to the list, or summarize the message formats for the working group? thanks, David mcgrew@cisco.com > > Regards, > Sandro. > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jul 11 13:33:54 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12750 for ; Wed, 11 Jul 2001 13:33:53 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 70F425353D; Wed, 11 Jul 2001 13:34:11 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 0100E5353A for ; Wed, 11 Jul 2001 13:33:14 -0400 (EDT) Received: (qmail 16784 invoked by uid 3269); 11 Jul 2001 17:33:13 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 16781 invoked from network); 11 Jul 2001 17:33:13 -0000 Received: from news.comp.lancs.ac.uk (148.88.152.70) by klesh.pair.com with SMTP; 11 Jul 2001 17:33:13 -0000 Received: from rafaeli (dyn509.dhcp.lancs.ac.uk [148.88.245.9]) by news.comp.lancs.ac.uk (8.11.0/8.11.0) with SMTP id f6BHX0020772; Wed, 11 Jul 2001 18:33:00 +0100 (BST) From: "Sandro Rafaeli" To: "'David A. McGrew'" Cc: Subject: RE: [MSEC] Re-key as a separate, standards-track protocol specification Message-ID: <002201c10a2f$75761c60$09f55894@lancs.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <3B4C8807.BAA40748@cisco.com> Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Wed, 11 Jul 2001 18:32:28 +0100 Content-Transfer-Encoding: 7bit David, The document can be found at http://www.comp.lancs.ac.uk/computing/users/rafaeli/oft.zip Any comments are welcomed, Sandro. | -----Original Message----- | From: msec-admin@securemulticast.org | [mailto:msec-admin@securemulticast.org]On Behalf Of David A. McGrew | Sent: 11 July 2001 18:08 | To: Sandro Rafaeli | Cc: msec@securemulticast.org | Subject: Re: [MSEC] Re-key as a separate, standards-track protocol | specification | | | Sandro Rafaeli wrote: | > | > | -----Original Message----- | > | From: msec-admin@securemulticast.org | > | [mailto:msec-admin@securemulticast.org]On Behalf Of | > | Lakshminath Dondeti | > | Sent: 11 July 2001 00:45 | > | To: msec@securemulticast.org | > | Subject: Re: [MSEC] Re-key as a separate, | standards-track protocol | > | specification | > | | > | (deleted text) | > | | > | We probably can abstract all the messaging requirements of | > | LKH and its | > | cousins. For example, we can say the KDC needs to i) | send changes | > | to the key tree, ii)changes in assignment of members to leaf | > | key nodes, | > | and iii)new keys along with their IDs. That | information is probably | > | sufficient for a member to figure out which keys it | needs to decrypt. | > | I have seen some schemes which work with less | information than that. | > | > I wrote a document on an OFT implementation I did in Java. | It contains among | > other things a description of the REKEY protocol I used | (message types and | > formats). It is a very simple protocol, but seems to do | the job. After I | > wrote this document, I implemented another key management protocol | > (tree-based; very similar to the one of Canetti) and I can | use my messages | > to convey either of them. If anyone is interested in | having a look at it I | > can send you a copy of the document. | | could you please post a pointer to the document to the list, | or summarize the | message formats for the working group? | | thanks, | | David | mcgrew@cisco.com | | | > | > Regards, | > Sandro. | > | > _______________________________________________ | > msec mailing list | > msec@securemulticast.org | > http://www.pairlist.net/mailman/listinfo/msec | | _______________________________________________ | msec mailing list | msec@securemulticast.org | http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jul 11 13:50:03 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13363 for ; Wed, 11 Jul 2001 13:50:02 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0621C5355C; Wed, 11 Jul 2001 13:50:21 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id D3E8C53548 for ; Wed, 11 Jul 2001 13:48:54 -0400 (EDT) Received: (qmail 18719 invoked by uid 3269); 11 Jul 2001 17:48:54 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 18710 invoked from network); 11 Jul 2001 17:48:49 -0000 Received: from rtp-msg-core-1.cisco.com (161.44.11.97) by klesh.pair.com with SMTP; 11 Jul 2001 17:48:49 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6BHkXn26303; Wed, 11 Jul 2001 13:46:38 -0400 (EDT) Received: from mbaugher-w2k1.cisco.com (dhcp-f-53-165.cisco.com [171.69.53.165]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AEN00772; Wed, 11 Jul 2001 10:44:24 -0700 (PDT) Message-Id: <4.3.2.7.2.20010711103612.02345a70@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Carl F. Muckenhirn" From: Mark Baugher Subject: Re: [MSEC] Re-key as a separate, standards-track protocol specification Cc: msec@securemulticast.org In-Reply-To: References: <4.3.2.7.2.20010706213410.0418fe88@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010706213410.0418fe88@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Wed, 11 Jul 2001 10:43:47 -0700 At 11:01 AM 7/11/2001 -0400, Carl F. Muckenhirn wrote: >On 7/6/01 at 9:44 PM -0700, Mark Baugher wrote: > > >>http://search.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt >>took a surprising turn by introducing Re-key as a separate protocol. >>David McGrew and Lakshminath Dondeti are working on a Re-key draft. Up to >>this point, the Re-key message was part of GSAKMP, called "Re-key," and >>GDOI, called "GROUPKEY-PUSH." Like many things between GSAKMP and GDOI, >>they have some differences and the latter uses ISAKMP encoding. >> >>The authors discussed this at length and agreed to take the route of a >>separate specification though it is and may remain controversial. There >>are a couple of ways that we can go here. We could unbundle the key >>mangement protocol into truly separate protocols that interface through a >>security association database, as suggested in gkmarch. I expect that >>GDOI and GSAKMP will continue to offer an integrated solution where the >>exchanges and messages are bundled into a single protocol. We need to >>discuss these alternatives and the direction that msec key management >>will take over the next year. > >In relooking at the gkmarch document, it is unclear that within the >document you are consistent. The requirements stated in "2.0 Requirements >for a group key management protocol" indicate that a group rekey is part >(a function) of the group key management protocol. > >Requirement 2. "Keys ... will be periodically refreshed." >Requirement 3. "Key material must be delivered securely ... and refreshed >securely at the end of the key lifetime." >Requirement 6. "It must be possible to provide re-key for the group ..." > >Your description in 3.1 (2) of a "rekey protocol" as optional implies that >the requirements above (mandates) will not be met. Your note that there >may be other ways of causing members to arrive at a new key, simply states >that there are protocols which do not require data transmission, that's >ok, its still a protocol. We are not talking about "re-key" in the generic meaning of the word: When a threshold is passed on the lifetime of a key, the member can be programmed to use a new Registration exchange to establish a new SA and thereby "refresh" the key. We are talking about a specific message called the "Re-key protocol message." Maybe it will be multiple messages. >>My view is that the separate document should explore the issues such as >>implosion, member feedback, reliable delivery, and other concerns >>associated with Re-key, which can be sent either multicast or >>unicast. It will also define a common encoding for key download and >>membership management that we will expect the msec key management >>protocols to adhere to. I don't think we will achieve an identical >>message format so long as we expect to implement the Re-key message in >>diverse protocols such as IKE. For this reason, I question whether this >>can be a standards-track protocol. > >I think all of these issues are important, but I don't believe that >they'll be able to be handled by a "rekey-only" protocol. For example, if >we want to work on reliable delivery, what happens when its not delivered, >we pop back over to some other protocol. I think it is safer to keep all >elements of the group key management protocol together to assure coverage >of the features and functions. I agree with your conclusions though I'm a bit shaky on your premises. Mark >>Mark >> >> >>_______________________________________________ >>msec mailing list >>msec@securemulticast.org >>http://www.pairlist.net/mailman/listinfo/msec > >carl. >-- >Carl F. Muckenhirn >Division Manager >SPARTA, Inc. >Security Engineering Division >9861 Broken Land Parkway, Suite 300 >Columbia, Maryland 21046 >410.381.9400 x208 >410.381.5559 (fax) > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jul 11 15:38:59 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17370 for ; Wed, 11 Jul 2001 15:38:59 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 10F1253574; Wed, 11 Jul 2001 15:39:20 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 553F853594 for ; Wed, 11 Jul 2001 15:37:19 -0400 (EDT) Received: (qmail 32135 invoked by uid 3269); 11 Jul 2001 19:37:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 32132 invoked from network); 11 Jul 2001 19:37:18 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by klesh.pair.com with SMTP; 11 Jul 2001 19:37:18 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6BJas008391 for ; Wed, 11 Jul 2001 12:36:54 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (dhcp-f-53-165.cisco.com [171.69.53.165]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AEN04097; Wed, 11 Jul 2001 12:36:45 -0700 (PDT) Message-Id: <4.3.2.7.2.20010711120540.0247be78@agora.rdrop.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: msec@securemulticast.org From: Mark Baugher Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Fwd: I-D ACTION:draft-ietf-msec-gdoi-01.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Wed, 11 Jul 2001 12:35:12 -0700 There is a bug in this document that I noticed last night: The KE payload is not present in the GROUPKEY-PUll operation because I inadvertently deleted it during editing. Mark >To: IETF-Announce: ; >Cc: msec@securemulticast.org >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-ietf-msec-gdoi-01.txt >Date: Wed, 11 Jul 2001 10:23:56 -0400 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Multicast Security Working Group of the IETF. > > Title : The Group Domain of Interpretation > Author(s) : M. Baugher et al. > Filename : draft-ietf-msec-gdoi-01.txt > Pages : 39 > Date : 10-Jul-01 > >This document presents an ISAMKP Domain of Interpretation (DOI) for >group key management to support secure group communications. The >'GDOI' borrows definitions from GSAKMP, incorporates the Phase 1 SA of >the Internet DOI, and proposes new payloads and exchanges according to >the ISAKMP and IKE standards. The GDOI manages group security >associations, which are used by security protocols running at the IP >or application layers. These security associations protect one or >more key-encrypting keys, traffic-encrypting keys, or data shared by >group members. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-01.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-msec-gdoi-01.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-msec-gdoi-01.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20010710154120.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-msec-gdoi-01.txt > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jul 11 18:03:26 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22197 for ; Wed, 11 Jul 2001 18:03:26 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 7E972535E9; Wed, 11 Jul 2001 18:02:59 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id DAFAD53591 for ; Wed, 11 Jul 2001 15:36:51 -0400 (EDT) Received: (qmail 32095 invoked by uid 3269); 11 Jul 2001 19:36:51 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 32092 invoked from network); 11 Jul 2001 19:36:50 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by klesh.pair.com with SMTP; 11 Jul 2001 19:36:50 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f6BJYFx14586 for ; Wed, 11 Jul 2001 12:34:16 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (dhcp-f-53-165.cisco.com [171.69.53.165]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AEN04071; Wed, 11 Jul 2001 12:35:42 -0700 (PDT) Message-Id: <4.3.2.7.2.20010711123458.0248d2c0@agora.rdrop.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: msec@securemulticast.org From: Mark Baugher Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Fwd: I-D ACTION:draft-ietf-msec-gdoi-01.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Wed, 11 Jul 2001 12:35:05 -0700 There is a bug in this document that I noticed last night: The KE payload is not present in the GROUPKEY-PUll operation because I inadvertently deleted it during editing. Mark >To: IETF-Announce: ; >Cc: msec@securemulticast.org >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-ietf-msec-gdoi-01.txt >Date: Wed, 11 Jul 2001 10:23:56 -0400 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Multicast Security Working Group of the IETF. > > Title : The Group Domain of Interpretation > Author(s) : M. Baugher et al. > Filename : draft-ietf-msec-gdoi-01.txt > Pages : 39 > Date : 10-Jul-01 > >This document presents an ISAMKP Domain of Interpretation (DOI) for >group key management to support secure group communications. The >'GDOI' borrows definitions from GSAKMP, incorporates the Phase 1 SA of >the Internet DOI, and proposes new payloads and exchanges according to >the ISAKMP and IKE standards. The GDOI manages group security >associations, which are used by security protocols running at the IP >or application layers. These security associations protect one or >more key-encrypting keys, traffic-encrypting keys, or data shared by >group members. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-01.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-msec-gdoi-01.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-msec-gdoi-01.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20010710154120.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-msec-gdoi-01.txt > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jul 12 00:57:46 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06657 for ; Thu, 12 Jul 2001 00:57:45 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4FB03535C3; Thu, 12 Jul 2001 00:58:04 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id DE29C53553 for ; Thu, 12 Jul 2001 00:57:51 -0400 (EDT) Received: (qmail 89498 invoked by uid 3269); 12 Jul 2001 04:57:51 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 89495 invoked from network); 12 Jul 2001 04:57:51 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 12 Jul 2001 04:57:51 -0000 Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f6C4v1704740; Thu, 12 Jul 2001 00:57:01 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id AAA27664; Thu, 12 Jul 2001 00:57:01 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id AAA27418; Thu, 12 Jul 2001 00:57:01 -0400 From: Ran Canetti Message-Id: <200107120457.AAA27418@ornavella.watson.ibm.com> To: cfm@sparta.com, mbaugher@cisco.com, msec@securemulticast.org Subject: Re: [MSEC] Re-key as a separate, standards-track protocol specification 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, 12 Jul 2001 00:57:01 -0400 Carl, > In relooking at the gkmarch document, it is unclear that within the > document you are consistent. The requirements stated in "2.0 > Requirements for a group key management protocol" indicate that a > group rekey is part (a function) of the group key management protocol. > > Requirement 2. "Keys ... will be periodically refreshed." > Requirement 3. "Key material must be delivered securely ... and > refreshed securely at the end of the key lifetime." > Requirement 6. "It must be possible to provide re-key for the group ..." > > Your description in 3.1 (2) of a "rekey protocol" as optional implies > that the requirements above (mandates) will not be met. Your note > that there may be other ways of causing members to arrive at a new > key, simply states that there are protocols which do not require data > transmission, that's ok, its still a protocol. I tend to agree. So there is always a rekey protocol, just that sometimes it does not involve communication... this does look like a cleaner way to present things. > > >My view is that the separate document should explore the issues such > >as implosion, member feedback, reliable delivery, and other concerns > >associated with Re-key, which can be sent either multicast or > >unicast. It will also define a common encoding for key download and > >membership management that we will expect the msec key management > >protocols to adhere to. I don't think we will achieve an identical > >message format so long as we expect to implement the Re-key message > >in diverse protocols such as IKE. For this reason, I question > >whether this can be a standards-track protocol. > > I think all of these issues are important, but I don't believe that > they'll be able to be handled by a "rekey-only" protocol. For > example, if we want to work on reliable delivery, what happens when > its not delivered, we pop back over to some other protocol. I think > it is safer to keep all elements of the group key management protocol > together to assure coverage of the features and functions. > My understnding is that handling exceptions/errors in rekeying (e.g. expired-keys-with-no-replacement-in-sight) is part of the job of the rekey protocol. (so this protocol may not be all one message.) But lets wait patiently to the rekey draft to come out... Ran _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jul 12 01:27:50 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA12987 for ; Thu, 12 Jul 2001 01:27:49 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 29D0D5366D; Thu, 12 Jul 2001 01:28:09 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 83B0A5359D for ; Thu, 12 Jul 2001 01:27:45 -0400 (EDT) Received: (qmail 91895 invoked by uid 3269); 12 Jul 2001 05:27:45 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 91892 invoked from network); 12 Jul 2001 05:27:45 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 12 Jul 2001 05:27:45 -0000 Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f6C5R2707880; Thu, 12 Jul 2001 01:27:03 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id BAA17328; Thu, 12 Jul 2001 01:27:03 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id BAA17112; Thu, 12 Jul 2001 01:27:02 -0400 From: Ran Canetti Message-Id: <200107120527.BAA17112@ornavella.watson.ibm.com> To: canetti@watson.ibm.com, thardjono@mediaone.net Subject: RE: [MSEC] De-registration protocol? Cc: mbaugher@cisco.com, msec@securemulticast.org 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, 12 Jul 2001 01:27:02 -0400 Thomas, I'm all for simplicity... and all for not getting into the guts of the MMD. > I am suggesting a simple database (similar to the SAD in functionality) > that has a collection of information. It doesn't have to be > a complete module (as the term "module" implies). > > I don't know if we need a standardized way for a member to talk > with the MMD. The IPsec/IKE RFCs does not even talk about *how* > the SAD is accessed. Its an implementation issue. Yes. That's because in IPSEC the SAD is not accessed by protocols that communicate with other parties (other than IPSEC/IKE). So the SAD is rightfully treated as something internal to the peer and not subject to standardization. It would be great to treat the MMD in the same way. But if we allow the MMD to be accessed by external protocols that are not part of msec and have their own communications and security requirements then we may be inviting problems for ourselves - since security flaw/features in these other protocols may adversely affect the security of msec. > >This my or may not go through the key management protocol, but > >it should be taken care of. (As usual, if people want to ignore parts of > >the standard that's ok. But the standard should provide a complete service.) > > > Historically, the IETF tries to to make practical and implementable > standards that vendors can implement. This process has a better > chance of suceeding if the issue being solved is well defined > and does not try to incorporate unncessary componenets/elements. > > If vendors later want certain things to be included in the MSEC standards, > I'm sure they will bring up the issue. > > We don't want to spend time on parts of MSEC that no one will use, > even if it means sacrificing the perception of a "complete service". Agreed. as long as we dont sacrifice security. > > > >My feeling is that it may often be convenient to "piggyback" the > >communication between the member and the MMM (membership management module) > >on the member-KDC communication (and have the KDC forward the necessary info > >to the MMM). But this is only an option, as long as the entire service is > >taken care of. > > > Again, I think it is unwise to start talking about communications > between the MMD and the member. This may de-focus our current > discussion on key management, Rekey-Protocol, and the need of > some membership data within the Rekey-Protocol. Agreed. At this stage we should only interested in the design of the MMD/MMM in as far as it affects the design of the key management protocol. (Recall - this discussion started from the question of whether we want to support an optional de-register protocol in key management.) > > Ran, > > I would appreciate if you would not twist the simple MMD > into an MMM (whatever MMM may be). Lets just look at the concept of > a simple collection of membership information that can be used also > by the Registration Prot., Rekey Prot., and IGMP. > If it is not needed, then we'll forget about it. > > Each time I suggest something, you seem to turn it into something else :) Sorry Thomas, I'll try to concentrate on turning other people's suggestions, at least for a while (until they start complaining)... :) Ran > > thomas > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jul 13 20:02:23 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02789 for ; Fri, 13 Jul 2001 20:02:22 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1FA1C535BA; Fri, 13 Jul 2001 20:02:43 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 2865753555 for ; Fri, 13 Jul 2001 20:01:29 -0400 (EDT) Received: (qmail 97390 invoked by uid 3269); 14 Jul 2001 00:01:28 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 97387 invoked from network); 14 Jul 2001 00:01:28 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 14 Jul 2001 00:01:28 -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.11.3/8.9.1) with ESMTP id f6CFT1k05716; Thu, 12 Jul 2001 08:29:02 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-tmp179.cisco.com [10.21.64.179]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AEN19250; Thu, 12 Jul 2001 08:28:49 -0700 (PDT) Message-Id: <4.3.2.7.2.20010712082222.02358dd0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Ran Canetti From: Mark Baugher Subject: Re: [MSEC] Re-key as a separate, standards-track protocol specification Cc: cfm@sparta.com, msec@securemulticast.org In-Reply-To: <200107120457.AAA27418@ornavella.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Thu, 12 Jul 2001 08:28:12 -0700 Ran At 12:57 AM 7/12/2001 -0400, Ran Canetti wrote: >Carl, > > > In relooking at the gkmarch document, it is unclear that within the > > document you are consistent. The requirements stated in "2.0 > > Requirements for a group key management protocol" indicate that a > > group rekey is part (a function) of the group key management protocol. > > > > Requirement 2. "Keys ... will be periodically refreshed." > > Requirement 3. "Key material must be delivered securely ... and > > refreshed securely at the end of the key lifetime." > > Requirement 6. "It must be possible to provide re-key for the group ..." > > > > Your description in 3.1 (2) of a "rekey protocol" as optional implies > > that the requirements above (mandates) will not be met. Your note > > that there may be other ways of causing members to arrive at a new > > key, simply states that there are protocols which do not require data > > transmission, that's ok, its still a protocol. > >I tend to agree. So there is always a rekey protocol, just that sometimes >it does not involve communication... this does look like a cleaner way to >present things. I think the name misleads people. We arbitrarily called it "Re-key," which might suggest that "this is how we do re-key." In fact, this protocol is used to push new keys to members, refresh keys, and change keys so some former key holders lose access to the group KEK. There is no requirement for our "Re-key Protocol," but there is always a rekey protocol. Mark > > > > >My view is that the separate document should explore the issues such > > >as implosion, member feedback, reliable delivery, and other concerns > > >associated with Re-key, which can be sent either multicast or > > >unicast. It will also define a common encoding for key download and > > >membership management that we will expect the msec key management > > >protocols to adhere to. I don't think we will achieve an identical > > >message format so long as we expect to implement the Re-key message > > >in diverse protocols such as IKE. For this reason, I question > > >whether this can be a standards-track protocol. > > > > I think all of these issues are important, but I don't believe that > > they'll be able to be handled by a "rekey-only" protocol. For > > example, if we want to work on reliable delivery, what happens when > > its not delivered, we pop back over to some other protocol. I think > > it is safer to keep all elements of the group key management protocol > > together to assure coverage of the features and functions. > > > >My understnding is that handling exceptions/errors in rekeying (e.g. >expired-keys-with-no-replacement-in-sight) is part of the job of the >rekey protocol. (so this protocol may not be all one message.) >But lets wait patiently to the rekey draft to come out... > >Ran _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sat Jul 14 15:49:42 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27277 for ; Sat, 14 Jul 2001 15:49:42 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 660FF53568; Sat, 14 Jul 2001 15:50:03 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 8F8D753555 for ; Sat, 14 Jul 2001 15:49:12 -0400 (EDT) Received: (qmail 71388 invoked by uid 3269); 14 Jul 2001 19:49:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 71385 invoked from network); 14 Jul 2001 19:49:11 -0000 Received: from chmls06.mediaone.net (24.147.1.144) by klesh.pair.com with SMTP; 14 Jul 2001 19:49:11 -0000 Received: from THARDJONO-LAP.mediaone.net (h0010a4c49f9e.ne.mediaone.net [24.128.44.121]) by chmls06.mediaone.net (8.11.1/8.11.1) with ESMTP id f6EJnA821245; Sat, 14 Jul 2001 15:49:10 -0400 (EDT) Message-Id: <5.0.0.25.2.20010713191521.0188c798@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: Ran Canetti From: Thomas Hardjono Cc: msec@securemulticast.org In-Reply-To: <200107120527.BAA17112@ornavella.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] MMD or GSAD 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, 13 Jul 2001 19:37:20 -0400 Ran, At 7/12/2001||01:27 AM, Ran Canetti wrote: >Thomas, > >I'm all for simplicity... and all for not getting into the guts of the MMD. Well, perhaps there is no guts to it :) I was wanting only a simple list of items that may make-up a MMD. > > > > I am suggesting a simple database (similar to the SAD in functionality) > > that has a collection of information. It doesn't have to be > > a complete module (as the term "module" implies). > > > > I don't know if we need a standardized way for a member to talk > > with the MMD. The IPsec/IKE RFCs does not even talk about *how* > > the SAD is accessed. Its an implementation issue. > >Yes. That's because in IPSEC the SAD is not accessed by protocols that >communicate with other parties (other than IPSEC/IKE). So the SAD is >rightfully treated as something internal to the peer and not subject to >standardization. > >It would be great to treat the MMD in the same way. But if we allow the MMD >to be accessed by external protocols that are not part of msec and have >their own communications and security requirements then we may be inviting >problems for ourselves - since security flaw/features in these other >protocols may adversely affect the security of msec. My intent with the idea of an MMD is to allow read-access by other protocols (perhaps IGMP, perhaps not) that are related to multicast. Thus, for example,in the case that a group utilizes two multicast addresses (video and audio), then it would convenient for this relationship to be represented somewhere. This will help the Registration protocol to request a join to both addresses through IGMP. I also realize that an RFC that simply pronounces that some state-information belonging to one protocol (eg. IPsec) must not be accessed/modified by other protocols, does not guarantee anything in the implementation. That is, saying X in an RFC does not guarantee the coder will do X. At the most, we can say that if a developer does modify state X, it will result in a "less-secure" implementation. Thus, the documents may say, for example, that IGMP *must not* modify MMD, but can read it. However, a human implementor may make a mistake and in fact corrupt the MMD. This an implementation-quality issue, not a design flaw. Again, if the notion of a collection of group-related state-info is a bad one, we can just throw it away. My feeling is that since multi-party secure communication using a GSA is more complicated that pair-wise secure comms., I would expect that additional state-info (other than the SAD & SPD) will be needed. Perhaps we may end up with a GSAD (Group SAD), which would be an extension of the SAD where the relationship between all three Cat-1/2/3 SAs are coded and stored. > > >This my or may not go through the key management protocol, but > > >it should be taken care of. (As usual, if people want to ignore parts of > > >the standard that's ok. But the standard should provide a complete > service.) > > > > > > Historically, the IETF tries to to make practical and implementable > > standards that vendors can implement. This process has a better > > chance of suceeding if the issue being solved is well defined > > and does not try to incorporate unncessary componenets/elements. > > > > If vendors later want certain things to be included in the MSEC standards, > > I'm sure they will bring up the issue. > > > > We don't want to spend time on parts of MSEC that no one will use, > > even if it means sacrificing the perception of a "complete service". > >Agreed. as long as we dont sacrifice security. Not to be picky, but a "complete service" does not guarantee security either. > > > > > > >My feeling is that it may often be convenient to "piggyback" the > > >communication between the member and the MMM (membership management > module) > > >on the member-KDC communication (and have the KDC forward the > necessary info > > >to the MMM). But this is only an option, as long as the entire service is > > >taken care of. > > > > > > Again, I think it is unwise to start talking about communications > > between the MMD and the member. This may de-focus our current > > discussion on key management, Rekey-Protocol, and the need of > > some membership data within the Rekey-Protocol. > >Agreed. At this stage we should only interested in the design of the >MMD/MMM in as far as it affects the design of the key management protocol. >(Recall - this discussion started from the question of whether we want >to support an optional de-register protocol in key management.) Right. Hence this new thread. Thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sat Jul 14 15:49:51 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27301 for ; Sat, 14 Jul 2001 15:49:51 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0440E536D7; Sat, 14 Jul 2001 15:50:08 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 43EFC53555 for ; Sat, 14 Jul 2001 15:49:15 -0400 (EDT) Received: (qmail 71394 invoked by uid 3269); 14 Jul 2001 19:49:15 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 71391 invoked from network); 14 Jul 2001 19:49:14 -0000 Received: from chmls06.mediaone.net (24.147.1.144) by klesh.pair.com with SMTP; 14 Jul 2001 19:49:14 -0000 Received: from THARDJONO-LAP.mediaone.net (h0010a4c49f9e.ne.mediaone.net [24.128.44.121]) by chmls06.mediaone.net (8.11.1/8.11.1) with ESMTP id f6EJn9821242; Sat, 14 Jul 2001 15:49:09 -0400 (EDT) Message-Id: <5.0.0.25.2.20010713175744.018c9b88@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: Ran Canetti , cfm@sparta.com, mbaugher@cisco.com, msec@securemulticast.org From: Thomas Hardjono Subject: Re: [MSEC] Re-key as a separate, standards-track protocol specification In-Reply-To: <200107120457.AAA27418@ornavella.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Sat, 14 Jul 2001 15:19:45 -0400 Carl, Ran, At 7/12/2001||12:57 AM, Ran Canetti wrote: >Carl, > > > In relooking at the gkmarch document, it is unclear that within the > > document you are consistent. The requirements stated in "2.0 > > Requirements for a group key management protocol" indicate that a > > group rekey is part (a function) of the group key management protocol. > > > > Requirement 2. "Keys ... will be periodically refreshed." > > Requirement 3. "Key material must be delivered securely ... and > > refreshed securely at the end of the key lifetime." > > Requirement 6. "It must be possible to provide re-key for the group ..." > > > > Your description in 3.1 (2) of a "rekey protocol" as optional implies > > that the requirements above (mandates) will not be met. Your note > > that there may be other ways of causing members to arrive at a new > > key, simply states that there are protocols which do not require data > > transmission, that's ok, its still a protocol. > >I tend to agree. So there is always a rekey protocol, just that sometimes >it does not involve communication... this does look like a cleaner way to >present things. Carl, I think the intent of the authors is to accomodate for protocol- instantiations that do not employ multicast to help in rekeying. Thus, any rekeying occurs one-to-one between the member and the GCKS (which may bring us back into the scalability debate :). > > > > >My view is that the separate document should explore the issues such > > >as implosion, member feedback, reliable delivery, and other concerns > > >associated with Re-key, which can be sent either multicast or > > >unicast. It will also define a common encoding for key download and > > >membership management that we will expect the msec key management > > >protocols to adhere to. I don't think we will achieve an identical > > >message format so long as we expect to implement the Re-key message > > >in diverse protocols such as IKE. For this reason, I question > > >whether this can be a standards-track protocol. > > > > I think all of these issues are important, but I don't believe that > > they'll be able to be handled by a "rekey-only" protocol. For > > example, if we want to work on reliable delivery, what happens when > > its not delivered, we pop back over to some other protocol. I think > > it is safer to keep all elements of the group key management protocol > > together to assure coverage of the features and functions. > > The decision taken sometime ago is for then group key management protocol not to rely on reliable transport. Thus, the most basic mechanisms is to do multiple transmissions. Even that approach (assuming Cat-3 SA is an IPsec SA) has problems w.r.t. sequence numbers and the member knowing that multiple copies does not mean that a replay-attack is underway. So, I do agree that the work on the Rekey protocol should begin with the assumption that it does not rely ony any specific (reliable) transport. >My understnding is that handling exceptions/errors in rekeying (e.g. >expired-keys-with-no-replacement-in-sight) is part of the job of the >rekey protocol. (so this protocol may not be all one message.) >But lets wait patiently to the rekey draft to come out... > >Ran Actually, now is the right time to discuss the issues relating to a Rekey protocol. The discussions should help when thinking/writing the draft. The problem of "expired-keys-with-no-replacement-in-sight" is related to the need of the GCKS to be aware of the life-times of key-trees (or key-packs) which it sends-out. The GCKS should maintain its own timer and issue new TEKS (eg. under the current KEK) sometime before the expiration of the current TEK. Alternatively, some algorithm can be devised to allow a member (who is time-aware) to initiate a change in the TEK (independently of other members) in such a way that all members and the GCKS arrive at the same new TEK. Finally, an emergency-mode (backup) TEKs can be installed such that if the GCKS fails to refresh the TEK, the sender switches over of these backup TEK. (OK, I know its crude, but these are just suggestions :). thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sat Jul 14 15:51:41 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27516 for ; Sat, 14 Jul 2001 15:51:41 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0CB34536BB; Sat, 14 Jul 2001 15:52:03 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 99824536D7 for ; Sat, 14 Jul 2001 15:50:08 -0400 (EDT) Received: (qmail 71466 invoked by uid 3269); 14 Jul 2001 19:50:08 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 71463 invoked from network); 14 Jul 2001 19:50:08 -0000 Received: from chmls06.mediaone.net (24.147.1.144) by klesh.pair.com with SMTP; 14 Jul 2001 19:50:08 -0000 Received: from THARDJONO-LAP.mediaone.net (h0010a4c49f9e.ne.mediaone.net [24.128.44.121]) by chmls06.mediaone.net (8.11.1/8.11.1) with ESMTP id f6EJo6821483; Sat, 14 Jul 2001 15:50:06 -0400 (EDT) Message-Id: <5.0.0.25.2.20010713193832.0190e830@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: Ran Canetti From: Thomas Hardjono Cc: msec@securemulticast.org In-Reply-To: <200107120527.BAA17112@ornavella.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Deregister the De-Registration protocol --- RE: [MSEC] De-registration protocol? 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, 14 Jul 2001 15:17:21 -0400 Ran, I have been following the De-Registration Protocol thread, and my reading of the postings on this list is that we do NOT want such a De-Registration Protocol as part of group key management. My suggestion (for better or worse) is for MSEC to drop the topic and focus on the other topics ahead (eg. Rekey issues, announcements, etc). Both our roles are as Co-Chairs to help MSEC meet the deadline, and I think we should take heed of the consensus in the group about this particular topic. We have other more pressing issues. cheers, thomas ------ At 7/12/2001||01:27 AM, Ran Canetti wrote: >Thomas, > >I'm all for simplicity... and all for not getting into the guts of the MMD. > > > I am suggesting a simple database (similar to the SAD in functionality) > > that has a collection of information. It doesn't have to be > > a complete module (as the term "module" implies). > > > > I don't know if we need a standardized way for a member to talk > > with the MMD. The IPsec/IKE RFCs does not even talk about *how* > > the SAD is accessed. Its an implementation issue. > >Yes. That's because in IPSEC the SAD is not accessed by protocols that >communicate with other parties (other than IPSEC/IKE). So the SAD is >rightfully treated as something internal to the peer and not subject to >standardization. > >It would be great to treat the MMD in the same way. But if we allow the MMD >to be accessed by external protocols that are not part of msec and have >their own communications and security requirements then we may be inviting >problems for ourselves - since security flaw/features in these other >protocols may adversely affect the security of msec. > > > >This my or may not go through the key management protocol, but > > >it should be taken care of. (As usual, if people want to ignore parts of > > >the standard that's ok. But the standard should provide a complete > service.) > > > > > > Historically, the IETF tries to to make practical and implementable > > standards that vendors can implement. This process has a better > > chance of suceeding if the issue being solved is well defined > > and does not try to incorporate unncessary componenets/elements. > > > > If vendors later want certain things to be included in the MSEC standards, > > I'm sure they will bring up the issue. > > > > We don't want to spend time on parts of MSEC that no one will use, > > even if it means sacrificing the perception of a "complete service". > >Agreed. as long as we dont sacrifice security. > > > > > > > >My feeling is that it may often be convenient to "piggyback" the > > >communication between the member and the MMM (membership management > module) > > >on the member-KDC communication (and have the KDC forward the > necessary info > > >to the MMM). But this is only an option, as long as the entire service is > > >taken care of. > > > > > > Again, I think it is unwise to start talking about communications > > between the MMD and the member. This may de-focus our current > > discussion on key management, Rekey-Protocol, and the need of > > some membership data within the Rekey-Protocol. > >Agreed. At this stage we should only interested in the design of the >MMD/MMM in as far as it affects the design of the key management protocol. >(Recall - this discussion started from the question of whether we want >to support an optional de-register protocol in key management.) > > > > > Ran, > > > > I would appreciate if you would not twist the simple MMD > > into an MMM (whatever MMM may be). Lets just look at the concept of > > a simple collection of membership information that can be used also > > by the Registration Prot., Rekey Prot., and IGMP. > > If it is not needed, then we'll forget about it. > > > > Each time I suggest something, you seem to turn it into something else :) > >Sorry Thomas, I'll try to concentrate on turning other people's suggestions, >at least for a while (until they start complaining)... :) > >Ran > > > > > 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 Sat Jul 14 16:03:47 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28730 for ; Sat, 14 Jul 2001 16:03:47 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6410F536FB; Sat, 14 Jul 2001 16:04:08 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 594445368D for ; Sat, 14 Jul 2001 16:02:48 -0400 (EDT) Received: (qmail 72863 invoked by uid 3269); 14 Jul 2001 20:02:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 72860 invoked from network); 14 Jul 2001 20:02:47 -0000 Received: from chmls06.mediaone.net (24.147.1.144) by klesh.pair.com with SMTP; 14 Jul 2001 20:02:47 -0000 Received: from THARDJONO-LAP.mediaone.net (h0010a4c49f9e.ne.mediaone.net [24.128.44.121]) by chmls06.mediaone.net (8.11.1/8.11.1) with ESMTP id f6EJn8821238; Sat, 14 Jul 2001 15:49:08 -0400 (EDT) Message-Id: <5.0.0.25.2.20010713173507.018c9798@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: "David A. McGrew" From: Thomas Hardjono Subject: Re: [MSEC] Re-key as a separate, standards-track protocolspecification Cc: Mark Baugher , msec@securemulticast.org In-Reply-To: <3B4C63A9.1F0B5F93@cisco.com> References: <5.0.0.25.2.20010710100531.018d37b0@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: Sat, 14 Jul 2001 15:18:05 -0400 David, At 7/11/2001||10:33 AM, David A. McGrew wrote: >Thomas, > >good to hear your thoughts, more below: > >Thomas Hardjono wrote: > > - would the Rekey Protocol look different for cases such as ALC > > and other solutions that embedd rekeying-material in > > the data stream? Should it try to address these now (or later)? > >Sorry, what's ALC? Sorry David. ALC is the (latest) name for the FEC-based reliable multicast and similar protocols. I should think that from the perception of a Rekeying protocol, FEC/ALC is just a transport mechanism. That is, the determination of how the Tree-Keys is broken-up and sent should not be be transport dependent. > > > > - does the Rekey Protocol manage keys or SAs as well? > >Our thoughts are that it should transport the Data Security SAs, since a >change >in the group key due to membership changes implies that the keys which it >protects should be changed as well. > > > > > - if the interface is the SAD, how to delete entries when > > a rekey occurs and the SAs are "partly" modified (eg. keys > > changed, but not the other materials, such as the SPI)? > >Is it possible in MSEC to change the keys for a fixed SPI? OK, so this is an interesting question :) I think a while ago the question came-up about the definition of SAs and GSAs. So, technically-speaking, if the key is part of the definition of an instance of an SA, then changing it (while keeping other parameters fixed) results in a different SA. Now, is this just "tech-speak" (and we don't really care about this problem) or does swapping to a new key has other implications? For example, if we swap keys for the Cat-3 SA (IPsec), do we need to also modifiy the IPsec sequence numbering (or do we just start with a new sequence number). thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Jul 15 00:43:43 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23735 for ; Sun, 15 Jul 2001 00:43:41 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 3F58453743; Sun, 15 Jul 2001 00:44:03 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 7BEF853593 for ; Sun, 15 Jul 2001 00:43:16 -0400 (EDT) Received: (qmail 39956 invoked by uid 3269); 15 Jul 2001 04:43:16 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 39953 invoked from network); 15 Jul 2001 04:43:15 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 15 Jul 2001 04:43:15 -0000 Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f6F4gi709394; Sun, 15 Jul 2001 00:42:44 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id AAA69638; Sun, 15 Jul 2001 00:42:44 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id AAA31082; Sun, 15 Jul 2001 00:42:43 -0400 From: Ran Canetti Message-Id: <200107150442.AAA31082@ornavella.watson.ibm.com> To: canetti@watson.ibm.com, thardjono@mediaone.net Cc: msec@securemulticast.org Subject: [MSEC] Re: MMD or GSAD Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Sun, 15 Jul 2001 00:42:43 -0400 Thomas, > From thardjono@mediaone.net Sat Jul 14 15:49:12 2001 > [snip] > > I also realize that an RFC that simply pronounces that some > state-information > belonging to one protocol (eg. IPsec) must not be accessed/modified > by other protocols, does not guarantee anything in the implementation. > That is, saying X in an RFC does not guarantee the coder will do X. > At the most, we can say that if a developer does modify state X, > it will result in a "less-secure" implementation. > > Thus, the documents may say, for example, that IGMP *must not* modify MMD, > but can read it. However, a human implementor may make a mistake > and in fact corrupt the MMD. This an implementation-quality issue, > not a design flaw. I think your approach is mistaken. Since our goal is to guarantee also security and not only interoperability, it is the duty of the standard to instruct the implementors on the "do"s and the "dont"s, even when this does not directly relate to interoperability. A standard that leaves behind a spec that invites compliants-yet-insecure implementations by innocent implementors is a bad security standard (even if it can potentially be implemented in a secure way). Similarly, an implementation has the *obligation* to follow the instructions of the standard, even if they do not have to do with interoperability. For instance, an IKE implementation that always chooses a secret exponent 1 for the Diffie-Hellman exchange cannot call itself compliant with the IKE standard, even if it interoperates with all existing implementations. In my mind, this is a central point where security standards differ from other IETF standards. Ran _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jul 16 10:25:28 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18950 for ; Mon, 16 Jul 2001 10:25:27 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1221D53638; Mon, 16 Jul 2001 10:25:51 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 9068E5362F for ; Mon, 16 Jul 2001 10:23:41 -0400 (EDT) Received: (qmail 35108 invoked by uid 3269); 16 Jul 2001 14:23:41 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 35105 invoked from network); 16 Jul 2001 14:23:40 -0000 Received: from chmls06.mediaone.net (24.147.1.144) by klesh.pair.com with SMTP; 16 Jul 2001 14:23:40 -0000 Received: from THARDJONO-LAP.mediaone.net (h0010a4c49f9e.ne.mediaone.net [24.128.44.121]) by chmls06.mediaone.net (8.11.1/8.11.1) with ESMTP id f6GENX812194; Mon, 16 Jul 2001 10:23:33 -0400 (EDT) Message-Id: <5.0.0.25.2.20010716100751.019695f0@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: Ran Canetti From: Thomas Hardjono Cc: msec@securemulticast.org In-Reply-To: <200107150442.AAA31082@ornavella.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Re: MMD or GSAD Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 16 Jul 2001 10:23:26 -0400 At 7/15/2001||12:42 AM, Ran Canetti wrote: >Thomas, > > > > From thardjono@mediaone.net Sat Jul 14 15:49:12 2001 > > >[snip] > > > > I also realize that an RFC that simply pronounces that some > > state-information > > belonging to one protocol (eg. IPsec) must not be accessed/modified > > by other protocols, does not guarantee anything in the implementation. > > That is, saying X in an RFC does not guarantee the coder will do X. > > At the most, we can say that if a developer does modify state X, > > it will result in a "less-secure" implementation. > > > > Thus, the documents may say, for example, that IGMP *must not* modify MMD, > > but can read it. However, a human implementor may make a mistake > > and in fact corrupt the MMD. This an implementation-quality issue, > > not a design flaw. > >I think your approach is mistaken. No Ran, I think you are misunderstanding what I meant. >Since our goal is to guarantee also security and not only interoperability, >it is the duty of the standard to instruct the implementors on the >"do"s and the "dont"s, even when this does not directly relate to >interoperability. Yes, the RFCs can say the "do's" and "don'ts", but that will not guarantee the quality of the implementation (from a security perspective). That's simply my point. >A standard that leaves behind a spec that invites >compliants-yet-insecure implementations by innocent implementors >is a bad security standard (even if it can potentially be implemented >in a secure way). Hmmm, I don't think I said this ...:) My point is that MSEC is not an academic exercise. We have limited time. We cannot worry about everything (especially a "complete" specification, whatever that means :) >Similarly, an implementation has the *obligation* to follow the >instructions of the standard, even if they do not have to do with >interoperability. Obligation to whom? Seriously, the best expected is an interop at bake-offs. Sorry if I sound skeptical. >For instance, an IKE implementation that always chooses a >secret exponent 1 for the Diffie-Hellman exchange cannot call itself >compliant with the IKE standard, even if it interoperates with all existing >implementations. Yes, when it comes to specific self-contained algorithm parameters like DES or DH, it is easy and do-able. When it comes to system designs (like GKM), then things get more complicated :) thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jul 16 11:21:41 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01865 for ; Mon, 16 Jul 2001 11:21:39 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6F53D53607; Mon, 16 Jul 2001 11:22:03 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 5C3D2535D0 for ; Mon, 16 Jul 2001 11:18:06 -0400 (EDT) Received: (qmail 36642 invoked by uid 3269); 16 Jul 2001 15:18:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 36639 invoked from network); 16 Jul 2001 15:18:05 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 16 Jul 2001 15:18:05 -0000 Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f6GFHT704830 for ; Mon, 16 Jul 2001 11:17:29 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id LAA17166 for ; Mon, 16 Jul 2001 11:17:29 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id LAA33070 for msec@securemulticast.org; Mon, 16 Jul 2001 11:17:29 -0400 From: Ran Canetti Message-Id: <200107161517.LAA33070@ornavella.watson.ibm.com> To: msec@securemulticast.org Subject: [MSEC] Call for agenda items at London Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 16 Jul 2001 11:17:29 -0400 Folks, MSec will meet at London on wednesday afternoon, 3:30-5:30pm. Please send proposed agenda items to the list and/or to the chairs. Thanks, Ran and Thomas _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jul 16 17:58:37 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19431 for ; Mon, 16 Jul 2001 17:58:36 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 831F3536AB; Mon, 16 Jul 2001 17:58:30 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id B3B6353670 for ; Mon, 16 Jul 2001 17:56:36 -0400 (EDT) Received: (qmail 65657 invoked by uid 3269); 16 Jul 2001 21:56:36 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 65654 invoked from network); 16 Jul 2001 21:56:36 -0000 Received: from chmls05.mediaone.net (24.147.1.143) by klesh.pair.com with SMTP; 16 Jul 2001 21:56:36 -0000 Received: from THARDJONO-LAP.mediaone.net (h0010a4c49f9e.ne.mediaone.net [24.128.44.121]) by chmls05.mediaone.net (8.11.1/8.11.1) with ESMTP id f6GLuSa23270 for ; Mon, 16 Jul 2001 17:56:29 -0400 (EDT) Message-Id: <5.0.0.25.2.20010716175115.01886b00@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: msec@securemulticast.org From: Thomas Hardjono Subject: Re: [MSEC] Deregister the De-Registration protocol --- RE: [MSEC] De-registration protocol? In-Reply-To: <5.0.0.25.2.20010713193832.0190e830@pop.ne.mediaone.net> References: <200107120527.BAA17112@ornavella.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 16 Jul 2001 17:56:23 -0400 Please re-start the discussion on Deregistration protocol. I received email this morning complaining about my posting below, which was considered to be too harsh and preventing the democratic discussion on this open list. sigh :) thomas ------ At 7/14/2001||03:17 PM, Thomas Hardjono wrote: >Ran, > >I have been following the De-Registration Protocol thread, and my reading >of the postings on this list is that we do NOT want such >a De-Registration Protocol as part of group key management. > >My suggestion (for better or worse) is for MSEC to drop the topic >and focus on the other topics ahead (eg. Rekey issues, announcements, etc). > >Both our roles are as Co-Chairs to help MSEC meet the deadline, and >I think we should take heed of the consensus in the group about >this particular topic. We have other more pressing issues. > >cheers, > >thomas >------ > > > >At 7/12/2001||01:27 AM, Ran Canetti wrote: > >>Thomas, >> >>I'm all for simplicity... and all for not getting into the guts of the MMD. >> >> > I am suggesting a simple database (similar to the SAD in functionality) >> > that has a collection of information. It doesn't have to be >> > a complete module (as the term "module" implies). >> > >> > I don't know if we need a standardized way for a member to talk >> > with the MMD. The IPsec/IKE RFCs does not even talk about *how* >> > the SAD is accessed. Its an implementation issue. >> >>Yes. That's because in IPSEC the SAD is not accessed by protocols that >>communicate with other parties (other than IPSEC/IKE). So the SAD is >>rightfully treated as something internal to the peer and not subject to >>standardization. >> >>It would be great to treat the MMD in the same way. But if we allow the MMD >>to be accessed by external protocols that are not part of msec and have >>their own communications and security requirements then we may be inviting >>problems for ourselves - since security flaw/features in these other >>protocols may adversely affect the security of msec. >> >> > >This my or may not go through the key management protocol, but >> > >it should be taken care of. (As usual, if people want to ignore parts of >> > >the standard that's ok. But the standard should provide a complete >> service.) >> > >> > >> > Historically, the IETF tries to to make practical and implementable >> > standards that vendors can implement. This process has a better >> > chance of suceeding if the issue being solved is well defined >> > and does not try to incorporate unncessary componenets/elements. >> > >> > If vendors later want certain things to be included in the MSEC standards, >> > I'm sure they will bring up the issue. >> > >> > We don't want to spend time on parts of MSEC that no one will use, >> > even if it means sacrificing the perception of a "complete service". >> >>Agreed. as long as we dont sacrifice security. >> >> > >> > >> > >My feeling is that it may often be convenient to "piggyback" the >> > >communication between the member and the MMM (membership management >> module) >> > >on the member-KDC communication (and have the KDC forward the >> necessary info >> > >to the MMM). But this is only an option, as long as the entire service is >> > >taken care of. >> > >> > >> > Again, I think it is unwise to start talking about communications >> > between the MMD and the member. This may de-focus our current >> > discussion on key management, Rekey-Protocol, and the need of >> > some membership data within the Rekey-Protocol. >> >>Agreed. At this stage we should only interested in the design of the >>MMD/MMM in as far as it affects the design of the key management protocol. >>(Recall - this discussion started from the question of whether we want >>to support an optional de-register protocol in key management.) >> >> > >> > Ran, >> > >> > I would appreciate if you would not twist the simple MMD >> > into an MMM (whatever MMM may be). Lets just look at the concept of >> > a simple collection of membership information that can be used also >> > by the Registration Prot., Rekey Prot., and IGMP. >> > If it is not needed, then we'll forget about it. >> > >> > Each time I suggest something, you seem to turn it into something else :) >> >>Sorry Thomas, I'll try to concentrate on turning other people's suggestions, >>at least for a while (until they start complaining)... :) >> >>Ran >> >> > >> > 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 Mon Jul 16 18:57:53 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27718 for ; Mon, 16 Jul 2001 18:57:52 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2A9B7535CE; Mon, 16 Jul 2001 18:58:15 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 44BB953578 for ; Mon, 16 Jul 2001 18:54:45 -0400 (EDT) Received: (qmail 67831 invoked by uid 3269); 16 Jul 2001 22:54:45 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 67827 invoked from network); 16 Jul 2001 22:54:40 -0000 Received: from softdnserror (HELO sj-msg-core-3.cisco.com) (171.70.157.152) by klesh.pair.com with SMTP; 16 Jul 2001 22:54:40 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f6GMqQE13725; Mon, 16 Jul 2001 15:52:26 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn1-58.cisco.com [10.21.96.58]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AES26857; Mon, 16 Jul 2001 15:54:05 -0700 (PDT) Message-Id: <4.3.2.7.2.20010716155148.02438930@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] Deregister the De-Registration protocol --- RE: [MSEC] De-registration protocol? Cc: msec@securemulticast.org In-Reply-To: <5.0.0.25.2.20010716175115.01886b00@pop.ne.mediaone.net> References: <5.0.0.25.2.20010713193832.0190e830@pop.ne.mediaone.net> <200107120527.BAA17112@ornavella.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 16 Jul 2001 15:53:25 -0700 Well, does anyone (else) support the notion of a de-registration protocol? It's gotten a fair amount of airtime already. Mark At 05:56 PM 7/16/2001 -0400, Thomas Hardjono wrote: >Please re-start the discussion on Deregistration protocol. > >I received email this morning complaining about my posting below, >which was considered to be too harsh and preventing the democratic >discussion on this open list. > >sigh :) > >thomas >------ > > >At 7/14/2001||03:17 PM, Thomas Hardjono wrote: > >>Ran, >> >>I have been following the De-Registration Protocol thread, and my reading >>of the postings on this list is that we do NOT want such >>a De-Registration Protocol as part of group key management. >> >>My suggestion (for better or worse) is for MSEC to drop the topic >>and focus on the other topics ahead (eg. Rekey issues, announcements, etc). >> >>Both our roles are as Co-Chairs to help MSEC meet the deadline, and >>I think we should take heed of the consensus in the group about >>this particular topic. We have other more pressing issues. >> >>cheers, >> >>thomas >>------ >> >> >> >>At 7/12/2001||01:27 AM, Ran Canetti wrote: >> >>>Thomas, >>> >>>I'm all for simplicity... and all for not getting into the guts of the MMD. >>> >>> > I am suggesting a simple database (similar to the SAD in functionality) >>> > that has a collection of information. It doesn't have to be >>> > a complete module (as the term "module" implies). >>> > >>> > I don't know if we need a standardized way for a member to talk >>> > with the MMD. The IPsec/IKE RFCs does not even talk about *how* >>> > the SAD is accessed. Its an implementation issue. >>> >>>Yes. That's because in IPSEC the SAD is not accessed by protocols that >>>communicate with other parties (other than IPSEC/IKE). So the SAD is >>>rightfully treated as something internal to the peer and not subject to >>>standardization. >>> >>>It would be great to treat the MMD in the same way. But if we allow the MMD >>>to be accessed by external protocols that are not part of msec and have >>>their own communications and security requirements then we may be inviting >>>problems for ourselves - since security flaw/features in these other >>>protocols may adversely affect the security of msec. >>> >>> > >This my or may not go through the key management protocol, but >>> > >it should be taken care of. (As usual, if people want to ignore parts of >>> > >the standard that's ok. But the standard should provide a complete >>> service.) >>> > >>> > >>> > Historically, the IETF tries to to make practical and implementable >>> > standards that vendors can implement. This process has a better >>> > chance of suceeding if the issue being solved is well defined >>> > and does not try to incorporate unncessary componenets/elements. >>> > >>> > If vendors later want certain things to be included in the MSEC >>> standards, >>> > I'm sure they will bring up the issue. >>> > >>> > We don't want to spend time on parts of MSEC that no one will use, >>> > even if it means sacrificing the perception of a "complete service". >>> >>>Agreed. as long as we dont sacrifice security. >>> >>> > >>> > >>> > >My feeling is that it may often be convenient to "piggyback" the >>> > >communication between the member and the MMM (membership management >>> module) >>> > >on the member-KDC communication (and have the KDC forward the >>> necessary info >>> > >to the MMM). But this is only an option, as long as the entire >>> service is >>> > >taken care of. >>> > >>> > >>> > Again, I think it is unwise to start talking about communications >>> > between the MMD and the member. This may de-focus our current >>> > discussion on key management, Rekey-Protocol, and the need of >>> > some membership data within the Rekey-Protocol. >>> >>>Agreed. At this stage we should only interested in the design of the >>>MMD/MMM in as far as it affects the design of the key management protocol. >>>(Recall - this discussion started from the question of whether we want >>>to support an optional de-register protocol in key management.) >>> >>> > >>> > Ran, >>> > >>> > I would appreciate if you would not twist the simple MMD >>> > into an MMM (whatever MMM may be). Lets just look at the concept of >>> > a simple collection of membership information that can be used also >>> > by the Registration Prot., Rekey Prot., and IGMP. >>> > If it is not needed, then we'll forget about it. >>> > >>> > Each time I suggest something, you seem to turn it into something else :) >>> >>>Sorry Thomas, I'll try to concentrate on turning other people's suggestions, >>>at least for a while (until they start complaining)... :) >>> >>>Ran >>> >>> > >>> > 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 Tue Jul 17 15:04:14 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18293 for ; Tue, 17 Jul 2001 15:04:14 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id F071753533; Tue, 17 Jul 2001 15:04:37 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id DF84A5376F for ; Wed, 11 Jul 2001 10:24:57 -0400 (EDT) Received: (qmail 92408 invoked by uid 3269); 11 Jul 2001 14:24:57 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 92404 invoked from network); 11 Jul 2001 14:24:56 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 11 Jul 2001 14:24:56 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04860; Wed, 11 Jul 2001 10:23:57 -0400 (EDT) Message-Id: <200107111423.KAA04860@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: msec@securemulticast.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [MSEC] I-D ACTION:draft-ietf-msec-gdoi-01.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Wed, 11 Jul 2001 10:23:56 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Security Working Group of the IETF. Title : The Group Domain of Interpretation Author(s) : M. Baugher et al. Filename : draft-ietf-msec-gdoi-01.txt Pages : 39 Date : 10-Jul-01 This document presents an ISAMKP Domain of Interpretation (DOI) for group key management to support secure group communications. The 'GDOI' borrows definitions from GSAKMP, incorporates the Phase 1 SA of the Internet DOI, and proposes new payloads and exchanges according to the ISAKMP and IKE standards. The GDOI manages group security associations, which are used by security protocols running at the IP or application layers. These security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msec-gdoi-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msec-gdoi-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010710154120.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-gdoi-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-gdoi-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010710154120.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 17 15:04:30 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18344 for ; Tue, 17 Jul 2001 15:04:29 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id E816653547; Tue, 17 Jul 2001 15:04:41 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id DE0945355F for ; Wed, 11 Jul 2001 15:08:26 -0400 (EDT) Received: (qmail 26791 invoked by uid 3269); 11 Jul 2001 19:08:26 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 26788 invoked from network); 11 Jul 2001 19:08:25 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by klesh.pair.com with SMTP; 11 Jul 2001 19:08:25 -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.11.3/8.9.1) with ESMTP id f6BJ81009557 for ; Wed, 11 Jul 2001 12:08:01 -0700 (PDT) Received: from mbaugher-w2k1.rdrop.com (dhcp-f-53-165.cisco.com [171.69.53.165]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AEN03214; Wed, 11 Jul 2001 12:07:50 -0700 (PDT) Message-Id: <4.3.2.7.2.20010711120540.0247be78@agora.rdrop.com> X-Sender: mbaugher@agora.rdrop.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: msec@securemulticast.org From: Mark Baugher Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Fwd: I-D ACTION:draft-ietf-msec-gdoi-01.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Wed, 11 Jul 2001 12:07:12 -0700 There is a bug in this document that I noticed last night: The KE payload is not present in the GROUPKEY-PUll operation because I inadvertently deleted it during editing. Mark >To: IETF-Announce: ; >Cc: msec@securemulticast.org >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-ietf-msec-gdoi-01.txt >Date: Wed, 11 Jul 2001 10:23:56 -0400 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Multicast Security Working Group of the IETF. > > Title : The Group Domain of Interpretation > Author(s) : M. Baugher et al. > Filename : draft-ietf-msec-gdoi-01.txt > Pages : 39 > Date : 10-Jul-01 > >This document presents an ISAMKP Domain of Interpretation (DOI) for >group key management to support secure group communications. The >'GDOI' borrows definitions from GSAKMP, incorporates the Phase 1 SA of >the Internet DOI, and proposes new payloads and exchanges according to >the ISAKMP and IKE standards. The GDOI manages group security >associations, which are used by security protocols running at the IP >or application layers. These security associations protect one or >more key-encrypting keys, traffic-encrypting keys, or data shared by >group members. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-01.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-msec-gdoi-01.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-msec-gdoi-01.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20010710154120.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-msec-gdoi-01.txt > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 17 15:05:20 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18532 for ; Tue, 17 Jul 2001 15:05:19 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 413D75354F; Tue, 17 Jul 2001 15:04:46 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id D895A53640 for ; Tue, 17 Jul 2001 13:32:40 -0400 (EDT) Received: (qmail 12359 invoked by uid 3269); 17 Jul 2001 17:32:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 12356 invoked from network); 17 Jul 2001 17:32:40 -0000 Received: from h-135-207-10-122.research.att.com (HELO roam.psg.com) (135.207.10.122) by klesh.pair.com with SMTP; 17 Jul 2001 17:32:40 -0000 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MYb7-0000LK-00; Tue, 17 Jul 2001 13:25:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rsent-To: eos@ops.ietf.org From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group Cc: iesg@ietf.org Message-Id: Subject: [MSEC] Note Well Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Tue, 17 Jul 2001 13:25:25 -0400 Content-Transfer-Encoding: 7bit Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 17 15:09:25 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19394 for ; Tue, 17 Jul 2001 15:09:25 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A836053546; Tue, 17 Jul 2001 15:09:47 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id D2BE053759 for ; Tue, 17 Jul 2001 13:37:07 -0400 (EDT) Received: (qmail 12931 invoked by uid 3269); 17 Jul 2001 17:37:07 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 12928 invoked from network); 17 Jul 2001 17:37:06 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 17 Jul 2001 17:37:06 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23758; Tue, 17 Jul 2001 13:16:53 -0400 (EDT) Message-Id: <200107171716.NAA23758@ietf.org> From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group Cc: iesg@ietf.org Subject: [MSEC] Note Well Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Tue, 17 Jul 2001 13:16:53 -0400 Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jul 19 16:27:23 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08242 for ; Thu, 19 Jul 2001 16:27:17 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A2ACD53532; Thu, 19 Jul 2001 16:27:35 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 20BB65359F for ; Thu, 19 Jul 2001 16:26:24 -0400 (EDT) Received: (qmail 71109 invoked by uid 3269); 19 Jul 2001 20:26:23 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 71106 invoked from network); 19 Jul 2001 20:26:23 -0000 Received: from eagle.verisign.com (208.206.241.105) by klesh.pair.com with SMTP; 19 Jul 2001 20:26:23 -0000 Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id NAA11380; Thu, 19 Jul 2001 13:29:15 -0700 (PDT) Received: from THARDJONO-LAP.verisign.com (192.168.7.3 [192.168.7.3]) by postal-gw2.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 36LQVXQA; Thu, 19 Jul 2001 13:26:16 -0700 Message-Id: <5.0.0.25.2.20010719133331.02732d60@pop.ne.mediaone.net> X-Sender: thardjono@vhqpostal.verisign.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: msec@securemulticast.org From: Thomas Hardjono Cc: amschue@tycho.ncsc.mil Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] GSAKMP-Light draft is on the website Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Thu, 19 Jul 2001 16:26:05 -0400 Folks, There is a new draft that was too late to make the IETF-cutoff date, but is relevant to MSEC and to our next meeting in London. I have put it on the MSEC site: http://www.securemulticast.org/draft-ietf-msec-gsakmp-light-sec-00.txt thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jul 19 16:27:42 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08321 for ; Thu, 19 Jul 2001 16:27:40 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4F119535B8; Thu, 19 Jul 2001 16:27:38 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 1B0E9535B8 for ; Thu, 19 Jul 2001 16:26:31 -0400 (EDT) Received: (qmail 71134 invoked by uid 3269); 19 Jul 2001 20:26:30 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 71126 invoked from network); 19 Jul 2001 20:26:30 -0000 Received: from eagle.verisign.com (208.206.241.105) by klesh.pair.com with SMTP; 19 Jul 2001 20:26:30 -0000 Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id NAA11399; Thu, 19 Jul 2001 13:29:27 -0700 (PDT) Received: from THARDJONO-LAP.verisign.com (192.168.7.3 [192.168.7.3]) by postal-gw2.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 36LQVXQ1; Thu, 19 Jul 2001 13:26:28 -0700 Message-Id: <5.0.0.25.2.20010719134242.018808a0@pop.ne.mediaone.net> X-Sender: thardjono@vhqpostal.verisign.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: msec@securemulticast.org From: Thomas Hardjono Cc: canetti@watson.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Agenda for MSEC WG in London (IETF51) 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, 19 Jul 2001 16:26:20 -0400 Folks, Attached is the tentative agenda for the MSEC WG meeting in London (IETF51). MSEC will be on: WEDNESDAY, August 8, 2001 1530-1730 Afternoon Sessions II Agenda: GKM Arch draft 20min Rekey Issues 20min GSPT 20min GSAKMP-lite 20min GDOI updates 20min Key Management in SRTP 20min The relevant drafts should be available either on the IETF site or on www.securemulticast.org. Please send any corrections/changes to Ran or Thomas. Ran+Thomas ---------- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jul 19 16:56:45 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12367 for ; Thu, 19 Jul 2001 16:56:43 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4F119535B8; Thu, 19 Jul 2001 16:27:38 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 1B0E9535B8 for ; Thu, 19 Jul 2001 16:26:31 -0400 (EDT) Received: (qmail 71134 invoked by uid 3269); 19 Jul 2001 20:26:30 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 71126 invoked from network); 19 Jul 2001 20:26:30 -0000 Received: from eagle.verisign.com (208.206.241.105) by klesh.pair.com with SMTP; 19 Jul 2001 20:26:30 -0000 Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id NAA11399; Thu, 19 Jul 2001 13:29:27 -0700 (PDT) Received: from THARDJONO-LAP.verisign.com (192.168.7.3 [192.168.7.3]) by postal-gw2.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 36LQVXQ1; Thu, 19 Jul 2001 13:26:28 -0700 Message-Id: <5.0.0.25.2.20010719134242.018808a0@pop.ne.mediaone.net> X-Sender: thardjono@vhqpostal.verisign.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: msec@securemulticast.org From: Thomas Hardjono Cc: canetti@watson.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Agenda for MSEC WG in London (IETF51) 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, 19 Jul 2001 16:26:20 -0400 Folks, Attached is the tentative agenda for the MSEC WG meeting in London (IETF51). MSEC will be on: WEDNESDAY, August 8, 2001 1530-1730 Afternoon Sessions II Agenda: GKM Arch draft 20min Rekey Issues 20min GSPT 20min GSAKMP-lite 20min GDOI updates 20min Key Management in SRTP 20min The relevant drafts should be available either on the IETF site or on www.securemulticast.org. Please send any corrections/changes to Ran or Thomas. Ran+Thomas ---------- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jul 26 08:35:38 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08988 for ; Thu, 26 Jul 2001 08:35:37 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D8714535CF; Thu, 26 Jul 2001 08:36:05 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id C8FEE53535 for ; Thu, 26 Jul 2001 08:35:55 -0400 (EDT) Received: (qmail 97763 invoked by uid 3269); 26 Jul 2001 12:35:55 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 97759 invoked from network); 26 Jul 2001 12:35:55 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 26 Jul 2001 12:35:55 -0000 Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.24.13]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6QCZYT07807; Thu, 26 Jul 2001 05:35:35 -0700 (PDT) Received: from cisco.com (ssh-rtp1.cisco.com [161.44.11.166]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id AOU03316 (AUTH mcgrew); Thu, 26 Jul 2001 05:35:17 -0700 (PDT) Message-ID: <3B600FC6.72C3602@cisco.com> From: "David A. McGrew" X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Hugh Harney Cc: msec@securemulticast.org References: <4.2.2.20010628143506.00b31dc0@pop.columbia.sparta.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [MSEC] policy, protocols, and state machines 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, 26 Jul 2001 08:40:38 -0400 Content-Transfer-Encoding: 7bit Hugh, I'm a bit concerned about the "policy" issue, and I'd like to ask for clarification. More below: Hugh Harney wrote in [Re: [MSEC] msec architecture draft and email flow]: > The Group Key Management Archtecture, policy section, states that MSEC will > totally rely on an external policy infrastructure. I believe that this > statement is too narrow. Some applications may rely on external policy > infrastructures, but not all. This is an architecture document for all > applications and solutions. I believe the Policy Building Blocks document > from the SMUG and the new policy work being done for the MSEC working group > is valid and important work. In fact, I believe policy is critical for MSEC > to specify. It seems to me that, for a policy to be meaningful, it must be enforced. This means that there are state machines on the group member's devices which must change state based on the receipt of authenticated policy statements. In order to have a well-defined and robust protocol, it is necessary to limit the scope of these state changes, at the very least so that they don't interfere with the base protocol or extant security associations. One easy way to do this is to mandate that the state machine affected by the policy is independent from the base protocol's state machine. In this case, the base protocol acts as a secure transport mechanism for the policy statements. This is easy to achieve in any security protocol with reasonably short messages by adding a separate field dedicated to policy transport. If this isn't sufficient for policy dissemination, then a separate SA can set up a secure channel for that purpose. In either case, the policy protocol is separate from the base protocol. This separation has strong advantages for specification and implementation. One of the most important benefits is that the development of the key management protocol can proceed independently of the development of policy protocols/state machines. This is especially important given that the policy problem is pretty much unbounded. As Andrea points out, static policy statements for all groups would probably be inadequate, which suggests that extensibility should be built into the system. The separation out of policy state machines is somewhat like the idea of "profiles" of a protocol, as done in RTP (rfc1889). Each profile essentially describes a unidirectional protocol which can use the transport provided by the base protocol. I'd value your thoughts on this subject. Do you know of any policies which can't be implemented as described above? If so, would it be possible to limit the interaction between the policy and the base protocol state machine to a small and well defined interface? thanks, David mcgrew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jul 27 12:40:15 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04974 for ; Fri, 27 Jul 2001 12:40:14 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9B4EA536DB; Fri, 27 Jul 2001 12:40:19 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 0B887535B3 for ; Fri, 27 Jul 2001 12:33:51 -0400 (EDT) Received: (qmail 1907 invoked by uid 3269); 27 Jul 2001 16:33:50 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 1904 invoked from network); 27 Jul 2001 16:33:50 -0000 Received: from chmls16.mediaone.net (24.147.1.151) by klesh.pair.com with SMTP; 27 Jul 2001 16:33:50 -0000 Received: from THARDJONO-LAP.mediaone.net ([63.90.80.227]) by chmls16.mediaone.net (8.11.1/8.11.1) with ESMTP id f6RGXmr03008; Fri, 27 Jul 2001 12:33:48 -0400 (EDT) Message-Id: <5.0.0.25.2.20010727115804.0194b5d8@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: "David A. McGrew" , Hugh Harney From: Thomas Hardjono Subject: Re: [MSEC] policy, protocols, and state machines Cc: msec@securemulticast.org In-Reply-To: <3B600FC6.72C3602@cisco.com> References: <4.2.2.20010628143506.00b31dc0@pop.columbia.sparta.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, 27 Jul 2001 12:19:33 -0400 David, At 7/26/2001||08:40 AM, David A. McGrew wrote: >Hugh, > >I'm a bit concerned about the "policy" issue, and I'd like to ask for >clarification. More below: > >Hugh Harney wrote in [Re: [MSEC] msec architecture draft and email flow]: > > The Group Key Management Archtecture, policy section, states that MSEC will > > totally rely on an external policy infrastructure. I believe that this > > statement is too narrow. Some applications may rely on external policy > > infrastructures, but not all. This is an architecture document for all > > applications and solutions. I believe the Policy Building Blocks document > > from the SMUG and the new policy work being done for the MSEC working group > > is valid and important work. In fact, I believe policy is critical for MSEC > > to specify. > >It seems to me that, for a policy to be meaningful, it must be enforced. This >means that there are state machines on the group member's devices which must >change state based on the receipt of authenticated policy statements. In >order >to have a well-defined and robust protocol, it is necessary to limit the scope >of these state changes, at the very least so that they don't interfere >with the >base protocol or extant security associations. Yes, agree. >One easy way to do this is to mandate that the state machine affected by the >policy is independent from the base protocol's state machine. In this >case, the >base protocol acts as a secure transport mechanism for the policy statements. >This is easy to achieve in any security protocol with reasonably short >messages >by adding a separate field dedicated to policy transport. If this isn't >sufficient for policy dissemination, then a separate SA can set up a secure >channel for that purpose. In either case, the policy protocol is separate >from >the base protocol. My understanding is that even before the Cat-1 SA is established, members should have *some amount* information obtained from the *complete* group policy (ie. represented by the Group Security Policy Token). The first question then becomes whether members need to have the *complete* group policy before beginning to establish the Cat-1. The second question is whether this (ie. the first question) is application-dependent. I do agree, though, that separating policy delivery from key delivery is attractive and provides a cleaner protocol set (as you say below). thomas ------- >This separation has strong advantages for specification and >implementation. One >of the most important benefits is that the development of the key management >protocol can proceed independently of the development of policy >protocols/state >machines. This is especially important given that the policy problem is >pretty >much unbounded. As Andrea points out, static policy statements for all groups >would probably be inadequate, which suggests that extensibility should be >built >into the system. > >The separation out of policy state machines is somewhat like the idea of >"profiles" of a protocol, as done in RTP (rfc1889). Each profile essentially >describes a unidirectional protocol which can use the transport provided >by the >base protocol. > >I'd value your thoughts on this subject. Do you know of any policies which >can't be implemented as described above? If so, would it be possible to limit >the interaction between the policy and the base protocol state machine to a >small and well defined interface? > >thanks, > >David >mcgrew@cisco.com > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 31 11:18:10 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20869 for ; Tue, 31 Jul 2001 11:18:09 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0BE835358B; Tue, 31 Jul 2001 11:18:40 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 5A68153585 for ; Tue, 31 Jul 2001 11:14:24 -0400 (EDT) Received: (qmail 81890 invoked by uid 3269); 31 Jul 2001 15:14:24 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 81883 invoked from network); 31 Jul 2001 15:14:19 -0000 Received: from ccbsd7.csie.nctu.edu.tw (root@140.113.209.67) by klesh.pair.com with SMTP; 31 Jul 2001 15:14:19 -0000 Received: (from leefy@localhost) by ccbsd7.csie.nctu.edu.tw (8.11.4/8.11.2) id f73Ep1r56009 for msec@securemulticast.org; Fri, 3 Aug 2001 22:51:01 +0800 (CST) (envelope-from leefy) From: Lee Fu-yuan To: msec@securemulticast.org Message-ID: <20010803225101.A55652@ccbsd7.csie.nctu.edu.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [MSEC] Loss of key update message ? 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, 3 Aug 2001 22:51:01 +0800 hi all: I am so interested at the key management issues of multicast. After reading some papers, I found that currently proposed mechanisms seldom mentioned about packet loss in their schemes. Is it true that all the currently proposed scheme assume that a reliable multicast system is deployed ? In the KeyStone system which is proposed by Chung Kei Wong, forward error correction is used to reduce the probability of loss of key update message. Are there any other papers that have discussed the impact of packet loss ? Best regards. -- Lee, Fu-Yuan Distributed System and Network Security Lab. Dept. of Comp. Sci. & Info. Eng Nat'l Chiao Tung Univ. Hsinchu, Taiwan 30050, ROC E-Mail: leefy@csie.nctu.edu.tw _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 31 17:59:06 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25494 for ; Tue, 31 Jul 2001 17:59:04 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 93C0D535EA; Tue, 31 Jul 2001 17:56:48 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id DC88A535E9 for ; Tue, 31 Jul 2001 17:55:15 -0400 (EDT) Received: (qmail 26562 invoked by uid 3269); 31 Jul 2001 21:55:15 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 26559 invoked from network); 31 Jul 2001 21:55:15 -0000 Received: from cs.utexas.edu (root@128.83.139.9) by klesh.pair.com with SMTP; 31 Jul 2001 21:55:15 -0000 Received: from toulon.cs.utexas.edu (zxc@toulon.cs.utexas.edu [128.83.120.39]) by cs.utexas.edu (8.11.2/8.11.2) with ESMTP id f6VLtDQ00657; Tue, 31 Jul 2001 16:55:14 -0500 (CDT) Received: (from zxc@localhost) by toulon.cs.utexas.edu (8.11.2/8.11.2) id f6VLtD228167; Tue, 31 Jul 2001 16:55:13 -0500 (CDT) From: Xincheng Zhang To: Lee Fu-yuan Cc: Subject: Re: [MSEC] Loss of key update message ? In-Reply-To: <20010803225101.A55652@ccbsd7.csie.nctu.edu.tw> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Tue, 31 Jul 2001 16:55:13 -0500 (CDT) Hi, maybe you have interests to read the following two papers: Reliable Group Rekeying: A Performance Analysis. Yang Richard Yang, X. Steve Li, X. Brian Zhang and Simon S. Lam. Proceedings of ACM SIGCOMM 2001, San Diego, CA, USA, August 2001. Protocol Design for Scalable and Reliable Group Rekeying. X. Brian Zhang, Simon S. Lam, Dong-Young Lee, and Yang Richard Yang. Proceedings of SPIE Conference on Scalability and Traffic Control in IP Networks, Vol 4526, Denver, CO, USA, August 2001. The two papers have some discussions on group rekey transport. The link is: http://www.cs.utexas.edu/users/zxc/pub/sigcomm01.pdf http://www.cs.utexas.edu/users/zxc/pub/spie01.ps xincheng On Fri, 3 Aug 2001, Lee Fu-yuan wrote: > hi all: > > I am so interested at the key management issues of multicast. > After reading some papers, I found that currently proposed > mechanisms seldom mentioned about packet loss in their schemes. > Is it true that all the currently proposed scheme assume that > a reliable multicast system is deployed ? > In the KeyStone system which is proposed by Chung Kei Wong, forward > error correction is used to reduce the probability of loss of key > update message. Are there any other papers that have discussed the > impact of packet loss ? > > Best regards. > > -- > Lee, Fu-Yuan > Distributed System and Network Security Lab. > Dept. of Comp. Sci. & Info. Eng > Nat'l Chiao Tung Univ. > Hsinchu, Taiwan 30050, ROC > E-Mail: leefy@csie.nctu.edu.tw > > _______________________________________________ > 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