From msec-admin@securemulticast.org Tue Jun 12 17:48:59 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25276 for ; Tue, 12 Jun 2001 17:48:57 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id CF8045355A; Tue, 12 Jun 2001 17:48: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 15DD65355B for ; Tue, 12 Jun 2001 17:48:00 -0400 (EDT) Received: (qmail 94314 invoked by uid 3269); 12 Jun 2001 21:47:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 94310 invoked from network); 12 Jun 2001 21:47:59 -0000 Received: from softdnserror (HELO sj-msg-core-1.cisco.com) (171.71.163.11) by klesh.pair.com with SMTP; 12 Jun 2001 21:47:59 -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 f5CLlV923633; Tue, 12 Jun 2001 14:47:31 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-tmp39.cisco.com [10.21.64.39]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ACP22827; Tue, 12 Jun 2001 14:47:25 -0700 (PDT) Message-Id: <4.3.2.7.2.20010612144347.04300ab8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: brakta From: Mark Baugher Cc: ipsec@lists.tislabs.com, msec@securemulticast.org In-Reply-To: <3B265142.F95D6D4A@loria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Re: mluticast authentication using AH 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, 12 Jun 2001 14:46:01 -0700 Hi I'm not sure what you are asking but I think it's more appropriate to address the msec WG with this question. I'm confused because AH does not support authentication by digital signature but uses a message authentication code. Mark At 07:28 PM 6/12/2001 +0200, brakta wrote: >Hello, >For multicast communication authentication,communicationone-way >hash,algorithms combined with asymmetric signature algorithms >are,appropriate.,What is solution of pulic key distribution problem > in 1-N model. > >regards >------------------------------------------ > Saber.BRAKTA > LORIA - UHP NANCY I > CAMPUS SCIENTIFIQUE B.P.239 > 54506 VANDOEUVRE-LES-NANCY CEDEX > E-mail : brakta@loria.fr >------------------------------------------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jun 12 18:37:20 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26171 for ; Tue, 12 Jun 2001 18:37:19 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id E838A53538; Tue, 12 Jun 2001 18:37: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 478F75352D for ; Tue, 12 Jun 2001 18:34:58 -0400 (EDT) Received: (qmail 98246 invoked by uid 3269); 12 Jun 2001 22:34:58 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 98243 invoked from network); 12 Jun 2001 22:34:57 -0000 Received: from prv-mail20.provo.novell.com (137.65.81.122) by klesh.pair.com with SMTP; 12 Jun 2001 22:34:57 -0000 Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 12 Jun 2001 16:34:11 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 From: "Hilarie Orman" To: , Cc: , Subject: [MSEC] Re: mluticast authentication using AH Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline 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, 12 Jun 2001 16:34:12 -0600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA26171 AH SHOULD HAVE supported authentication with digital signatures. Hilarie >>> Mark Baugher 06/12/01 03:46PM >>> Hi I'm not sure what you are asking but I think it's more appropriate to address the msec WG with this question. I'm confused because AH does not support authentication by digital signature but uses a message authentication code. Mark At 07:28 PM 6/12/2001 +0200, brakta wrote: >Hello, >For multicast communication authentication,communicationone-way >hash,algorithms combined with asymmetric signature algorithms >are,appropriate.,What is solution of pulic key distribution problem > in 1-N model. > >regards >------------------------------------------ > Saber.BRAKTA > LORIA - UHP NANCY I > CAMPUS SCIENTIFIQUE B.P.239 > 54506 VANDOEUVRE-LES-NANCY CEDEX > E-mail : brakta@loria.fr >------------------------------------------ _______________________________________________ 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 Jun 13 10:17:40 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23625 for ; Wed, 13 Jun 2001 10:17:38 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 726D353557; Wed, 13 Jun 2001 10:17:39 -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 BA64D53533 for ; Wed, 13 Jun 2001 10:10:43 -0400 (EDT) Received: (qmail 88718 invoked by uid 3269); 13 Jun 2001 14:10:43 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 88713 invoked from network); 13 Jun 2001 14:10:42 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 13 Jun 2001 14:10:42 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5DEAHU10408; Wed, 13 Jun 2001 07:10:17 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-tmp71.cisco.com [10.21.64.71]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ACP32914; Wed, 13 Jun 2001 07:10:09 -0700 (PDT) Message-Id: <4.3.2.7.2.20010613070758.042d0d10@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Dan McDonald From: Mark Baugher Subject: Re: [MSEC] Re: mluticast authentication using AH Cc: ipsec@lists.tislabs.com, msec@securemulticast.org In-Reply-To: <200106131333.f5DDXJY23927@kebe.east.sun.com> References: 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, 13 Jun 2001 07:08:45 -0700 > > AH SHOULD HAVE supported authentication with digital signatures. > >There's nothing, I believe, about AH that prevents digital signatures from >being used. > >The Authentication Data area can be made up to 1016 bytes (just shy of >8kbits) per 2402. That should be plenty of room for a digital signature. > >Dan How is this signalled? Mark _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 13 10:31:50 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23959 for ; Wed, 13 Jun 2001 10:31:49 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 928DF53551; Wed, 13 Jun 2001 10:31: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 7416C5353A for ; Wed, 13 Jun 2001 10:22:14 -0400 (EDT) Received: (qmail 89788 invoked by uid 3269); 13 Jun 2001 14:22:14 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 89784 invoked from network); 13 Jun 2001 14:22:13 -0000 Received: from lorraine.loria.fr (152.81.1.17) by klesh.pair.com with SMTP; 13 Jun 2001 14:22:13 -0000 Received: from loria.fr (pcscanner3.loria.fr [152.81.11.94]) by lorraine.loria.fr (8.9.3/8.9.3/8.9.3/JCG-DG) with ESMTP id QAA14235; Wed, 13 Jun 2001 16:22:07 +0200 (MET DST) Message-ID: <3B27777F.B50C8FB3@loria.fr> From: brakta Organization: LORIA X-Mailer: Mozilla 4.7 [fr]C-CCK-MCD (WinNT; I) X-Accept-Language: fr, en MIME-Version: 1.0 To: msec@securemulticast.org, ipsec@lists.tislabs.com Content-Type: multipart/mixed; boundary="------------80E2285FC057F651A21F5F76" Subject: [MSEC] The use HMAC 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, 13 Jun 2001 16:23:59 +0200 Il s'agit d'un message multivolet au format MIME. --------------80E2285FC057F651A21F5F76 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, Mechanisms that provide such integrity check based on a secret key are usually called "message authentication codes" (MAC). Typically, message authentication codes are used between (two parties) that share a secret key in order to validate information transmitted between these parties. Can i use "message authentification codes" between more than two parties, i mean in multicast application, specially 1- N mode ? -- ------------------------------------------ Saber.BRAKTA LORIA - UHP NANCY I CAMPUS SCIENTIFIQUE B.P.239 54506 VANDOEUVRE-LES-NANCY CEDEX E-mail : brakta@loria.fr ------------------------------------------ --------------80E2285FC057F651A21F5F76 Content-Type: text/x-vcard; charset=us-ascii; name="brakta.vcf" Content-Description: Carte pour brakta Content-Disposition: attachment; filename="brakta.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; x-mozilla-html:FALSE adr:;;;;;; version:2.1 end:vcard --------------80E2285FC057F651A21F5F76-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 13 15:10:11 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29612 for ; Wed, 13 Jun 2001 15:10:10 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 7079453569; Wed, 13 Jun 2001 15:10: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 1572953568 for ; Wed, 13 Jun 2001 15:08:51 -0400 (EDT) Received: (qmail 22103 invoked by uid 3269); 13 Jun 2001 19:08:50 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 22099 invoked from network); 13 Jun 2001 19:08:50 -0000 Received: from relay.eecs.berkeley.edu (169.229.34.228) by klesh.pair.com with SMTP; 13 Jun 2001 19:08:50 -0000 Received: from gateway.EECS.Berkeley.EDU (nsmail@gateway.EECS.Berkeley.EDU [169.229.60.73]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id MAA16368 for ; Wed, 13 Jun 2001 12:08:48 -0700 (PDT) Received: from acm.org (nat-209-219-233-6.webfountain.com [209.219.233.6]) by gateway.EECS.Berkeley.EDU (Netscape Messaging Server 4.15) with ESMTP id GEVUIM00.SEF; Wed, 13 Jun 2001 12:08:46 -0700 Message-ID: <3B27BB9D.755C314D@acm.org> From: Adrian Perrig X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.10 i686) X-Accept-Language: en MIME-Version: 1.0 To: brakta Cc: msec@securemulticast.org, ipsec@lists.tislabs.com Subject: Re: [MSEC] The use HMAC References: <3B27777F.B50C8FB3@loria.fr> 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, 13 Jun 2001 12:14:37 -0700 Content-Transfer-Encoding: 7bit > Mechanisms that provide such integrity check based on a secret key are > usually called "message authentication codes" (MAC). Typically, message > authentication codes are used between (two parties) that share a secret > key in order to validate information transmitted between these parties. > Can i use "message authentification codes" between more than two > parties, i mean in multicast application, specially 1- N mode ? Using a simple MAC for authenticating the sender in a broadcast is unfortunately insecure if the receivers do not trust each other. Since any one of the receivers knows the MAC key, it could impersonate the sender and send forged messages to other receivers. This is why we designed the TESLA protocol. TESLA provides efficient authentication, at the cost of about one MAC computation per packet, perfect robustness to packet loss, and requires loose time synchronization between the sender and the receivers. The authentication in TESLA is delayed, but we proposed an extension that allows the receivers to immediately authenticate data (which works well in environments with low packet loss). The IETF draft is available at: http://www.ietf.org/internet-drafts/draft-irtf-smug-tesla-00.txt Papers on TESLA are available at: http://paris.cs.berkeley.edu/%7Eperrig/projects.html#TESLA Let me know if you have further questions on this, Adrian _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 13 16:49:10 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01365 for ; Wed, 13 Jun 2001 16:49:09 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A1E995361A; Wed, 13 Jun 2001 16:48:31 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 4FA5653535 for ; Wed, 13 Jun 2001 16:47:09 -0400 (EDT) Received: (qmail 38945 invoked by uid 3269); 13 Jun 2001 20:47:09 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 38941 invoked from network); 13 Jun 2001 20:47:08 -0000 Received: from prv-mail20.provo.novell.com (137.65.81.122) by klesh.pair.com with SMTP; 13 Jun 2001 20:47:08 -0000 Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 13 Jun 2001 14:46:21 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 From: "Hilarie Orman" To: , Cc: , Subject: Re: [MSEC] Re: multicast authentication using AH Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline 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, 13 Jun 2001 14:46:14 -0600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA01365 Might also want to encode an ident somewhere. Should there be an option for attaching a cert to the message, or would you see that being done solely by key mgmt (group mgr would multicast sender certs to the group)? Maintaining many certs does complicate SA mgmt, it's like having many keys/SA. Hilarie >>> Dan McDonald 06/13/01 08:14AM >>> > > > AH SHOULD HAVE supported authentication with digital signatures. > > > >There's nothing, I believe, about AH that prevents digital signatures from > >being used. > > > >The Authentication Data area can be made up to 1016 bytes (just shy of > >8kbits) per 2402. That should be plenty of room for a digital signature. > > > >Dan > > How is this signalled? It's part of the IPsec Security Association data. Per 2401, an SA is indexed by the tuple . When you add the appropriate SA, you get all sorts of data, including the algorithm. All one would need to do is write a new "algorithm document" for using a digital signature with AH. It shouldn't be tough, and if I had cycles (HAH!) I could easily prototype one in Solaris. Dan _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 13 17:03:26 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01619 for ; Wed, 13 Jun 2001 17:03:24 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id E21435366D; Wed, 13 Jun 2001 17:02: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 3AAD653559 for ; Wed, 13 Jun 2001 17:00:58 -0400 (EDT) Received: (qmail 41500 invoked by uid 3269); 13 Jun 2001 21:00:57 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 41496 invoked from network); 13 Jun 2001 21:00:57 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 13 Jun 2001 21:00:57 -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 f5DKwoU13595; Wed, 13 Jun 2001 13:58:51 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-416.cisco.com [10.21.65.160]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ACP41886; Wed, 13 Jun 2001 13:58:43 -0700 (PDT) Message-Id: <4.3.2.7.2.20010613134800.043b1968@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: brakta From: Mark Baugher Subject: Re: [MSEC] The use HMAC Cc: msec@securemulticast.org, ipsec@lists.tislabs.com In-Reply-To: <3B27777F.B50C8FB3@loria.fr> 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, 13 Jun 2001 13:57:19 -0700 Hi At 04:23 PM 6/13/2001 +0200, brakta wrote: >Hello, > Mechanisms that provide such integrity check based on a secret key are >usually called "message authentication codes" (MAC). Typically, message >authentication codes are used between (two parties) that share a secret >key in order to validate information transmitted between these parties. >Can i use "message authentification codes" between more than two >parties, i mean in multicast application, specially 1- N mode ? >-- Yes you can with Adrian's caveat that a rogue member of the group is able to impersonate a sender if you cannot uniquely authenticate the sender. And you can't uniquely authenticate the sender using "group authentication" with a MAC. But you can using digital signatures, the cost of which can be amortized over many packets using tesla or similar algorithms. Mark >------------------------------------------ > Saber.BRAKTA > LORIA - UHP NANCY I > CAMPUS SCIENTIFIQUE B.P.239 > 54506 VANDOEUVRE-LES-NANCY CEDEX > E-mail : brakta@loria.fr >------------------------------------------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jun 14 18:31:52 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10840 for ; Thu, 14 Jun 2001 18:31:49 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 796B25380F; Thu, 14 Jun 2001 18:30: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 F389553745 for ; Thu, 14 Jun 2001 18:29:32 -0400 (EDT) Received: (qmail 86156 invoked by uid 3269); 14 Jun 2001 22:29:32 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 86153 invoked from network); 14 Jun 2001 22:29:32 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 14 Jun 2001 22:29:32 -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 f5EMT1U14689; Thu, 14 Jun 2001 15:29:01 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-535.cisco.com [10.21.66.23]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ACP64655; Thu, 14 Jun 2001 15:28:54 -0700 (PDT) Message-Id: <4.3.2.7.2.20010614143654.04147d48@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Hilarie Orman" From: Mark Baugher Subject: Re: [MSEC] Re: multicast authentication using AH Cc: , , In-Reply-To: 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, 14 Jun 2001 15:27:29 -0700 So it might not be a no brainer to put digital signatures in ESP or AH. At 02:46 PM 6/13/2001 -0600, Hilarie Orman wrote: >Might also want to encode an ident somewhere. GDOI does this in its Phase 2. >Should there be an option for attaching a cert to the message, >or would you see that being done solely by key mgmt (group mgr >would multicast sender certs to the group)? GDOI does this as part of its key management over pairwise and multicast connections. >Maintaining many certs does complicate SA mgmt, it's like having >many keys/SA. I don't think having multiple authorizations, such as to belong to multiple groups, requires having a unique signature key for each authorization. Mark >Hilarie > > >>> Dan McDonald 06/13/01 08:14AM >>> > > > > AH SHOULD HAVE supported authentication with digital signatures. > > > > > >There's nothing, I believe, about AH that prevents digital signatures from > > >being used. > > > > > >The Authentication Data area can be made up to 1016 bytes (just shy of > > >8kbits) per 2402. That should be plenty of room for a digital signature. > > > > > >Dan > > > > How is this signalled? > >It's part of the IPsec Security Association data. Per 2401, an SA is indexed >by the tuple . When you add the appropriate >SA, you get all sorts of data, including the algorithm. > >All one would need to do is write a new "algorithm document" for using a >digital signature with AH. It shouldn't be tough, and if I had cycles (HAH!) >I could easily prototype one in Solaris. > >Dan _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jun 14 18:43:36 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10890 for ; Thu, 14 Jun 2001 18:43:35 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 7DD2153814; Thu, 14 Jun 2001 18:43: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 EB21B53836 for ; Thu, 14 Jun 2001 18:39:56 -0400 (EDT) Received: (qmail 86689 invoked by uid 3269); 14 Jun 2001 22:39:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 86686 invoked from network); 14 Jun 2001 22:39:56 -0000 Received: from prv-mail20.provo.novell.com (137.65.81.122) by klesh.pair.com with SMTP; 14 Jun 2001 22:39:56 -0000 Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 14 Jun 2001 16:39:15 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 From: "Hilarie Orman" To: Cc: , Subject: Re: [MSEC] Re: multicast authentication using AH Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline 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, 14 Jun 2001 16:39:05 -0600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA10890 Well, maybe a small-brainer. If there are multiple senders, then a recipient needs a cert from each of them. Thus, the single SA with multiple keys. Hilarie >>> Mark Baugher 06/14/01 04:27PM >>> So it might not be a no brainer to put digital signatures in ESP or AH. At 02:46 PM 6/13/2001 -0600, Hilarie Orman wrote: >Might also want to encode an ident somewhere. GDOI does this in its Phase 2. >Should there be an option for attaching a cert to the message, >or would you see that being done solely by key mgmt (group mgr >would multicast sender certs to the group)? GDOI does this as part of its key management over pairwise and multicast connections. >Maintaining many certs does complicate SA mgmt, it's like having >many keys/SA. I don't think having multiple authorizations, such as to belong to multiple groups, requires having a unique signature key for each authorization. Mark >Hilarie > > >>> Dan McDonald 06/13/01 08:14AM >>> > > > > AH SHOULD HAVE supported authentication with digital signatures. > > > > > >There's nothing, I believe, about AH that prevents digital signatures from > > >being used. > > > > > >The Authentication Data area can be made up to 1016 bytes (just shy of > > >8kbits) per 2402. That should be plenty of room for a digital signature. > > > > > >Dan > > > > How is this signalled? > >It's part of the IPsec Security Association data. Per 2401, an SA is indexed >by the tuple . When you add the appropriate >SA, you get all sorts of data, including the algorithm. > >All one would need to do is write a new "algorithm document" for using a >digital signature with AH. It shouldn't be tough, and if I had cycles (HAH!) >I could easily prototype one in Solaris. > >Dan _______________________________________________ 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 Jun 14 19:24:22 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11176 for ; Thu, 14 Jun 2001 19:24:21 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0C5E253694; Thu, 14 Jun 2001 19:24:23 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 5BB1D535D6 for ; Thu, 14 Jun 2001 19:23:45 -0400 (EDT) Received: (qmail 89830 invoked by uid 3269); 14 Jun 2001 23:23:45 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 89827 invoked from network); 14 Jun 2001 23:23:44 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 14 Jun 2001 23:23:44 -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 f5ENNH900322; Thu, 14 Jun 2001 16:23:17 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-535.cisco.com [10.21.66.23]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ACP65936; Thu, 14 Jun 2001 16:23:10 -0700 (PDT) Message-Id: <4.3.2.7.2.20010614162130.020e9c70@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Hilarie Orman" From: Mark Baugher Subject: Re: [MSEC] Re: multicast authentication using AH Cc: ipsec@lists.tislabs.com, msec@securemulticast.org 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, 14 Jun 2001 16:21:45 -0700 At 04:39 PM 6/14/2001 -0600, you wrote: >Well, maybe a small-brainer. A new DOI for IKE? >If there are multiple senders, then a recipient needs a cert from each >of them. Thus, the single SA with multiple keys. I see. Mark >Hilarie > > >>> Mark Baugher 06/14/01 04:27PM >>> >So it might not be a no brainer to put digital signatures in ESP or AH. > >At 02:46 PM 6/13/2001 -0600, Hilarie Orman wrote: > >Might also want to encode an ident somewhere. > >GDOI does this in its Phase 2. > > > >Should there be an option for attaching a cert to the message, > >or would you see that being done solely by key mgmt (group mgr > >would multicast sender certs to the group)? > >GDOI does this as part of its key management over pairwise and >multicast connections. > > > >Maintaining many certs does complicate SA mgmt, it's like having > >many keys/SA. > >I don't think having multiple authorizations, such as to belong to >multiple groups, requires having a unique signature key for each >authorization. > >Mark > > > >Hilarie > > > > >>> Dan McDonald 06/13/01 08:14AM >>> > > > > > AH SHOULD HAVE supported authentication with digital signatures. > > > > > > > >There's nothing, I believe, about AH that prevents digital > signatures from > > > >being used. > > > > > > > >The Authentication Data area can be made up to 1016 bytes (just shy of > > > >8kbits) per 2402. That should be plenty of room for a digital > signature. > > > > > > > >Dan > > > > > > How is this signalled? > > > >It's part of the IPsec Security Association data. Per 2401, an SA is > indexed > >by the tuple . When you add the > appropriate > >SA, you get all sorts of data, including the algorithm. > > > >All one would need to do is write a new "algorithm document" for using a > >digital signature with AH. It shouldn't be tough, and if I had cycles > (HAH!) > >I could easily prototype one in Solaris. > > > >Dan > > >_______________________________________________ >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 Jun 27 17:21:53 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13640 for ; Wed, 27 Jun 2001 17:21:52 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C779353551; Wed, 27 Jun 2001 17: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 754D853545 for ; Wed, 27 Jun 2001 17:21:01 -0400 (EDT) Received: (qmail 88868 invoked by uid 3269); 27 Jun 2001 21:21:01 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 88865 invoked from network); 27 Jun 2001 21:21:00 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by klesh.pair.com with SMTP; 27 Jun 2001 21:21:00 -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 f5RLJnN20107; Wed, 27 Jun 2001 14:19:59 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-615.cisco.com [10.21.66.103]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ACW20289; Wed, 27 Jun 2001 14:19:38 -0700 (PDT) Message-Id: <4.3.2.7.2.20010627140639.04301090@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Andrea Colegrove From: Mark Baugher Cc: msec@securemulticast.org, ipsec@lists.tislabs.com In-Reply-To: <3B3A1A8F.719CC71A@columbia.sparta.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Re: [Fwd: I-D ACTION:draft-ietf-msec-gkmarch-00.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, 27 Jun 2001 14:19:06 -0700 Andrea I respond to your first point in this note. At 01:40 PM 6/27/2001 -0400, Andrea Colegrove wrote: >X-Mozilla-Status2: 00000000 >Message-ID: <3B3A1837.D95360C0@columbia.sparta.com> >Date: Wed, 27 Jun 2001 13:30:31 -0400 >From: Andrea Colegrove >X-Mailer: Mozilla 4.75 [en] (Win98; U) >X-Accept-Language: en >MIME-Version: 1.0 >To: msec@securemulticast.org >Subject: Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt >References: <200106271103.HAA26170@ietf.org> >Content-Type: multipart/alternative; > boundary="------------E7B7F4EE607BF84BF270BC1C" > >Mark, etal, >Initial comments on the architecture -- > >1. Section 1. -- >> >>Extensions to IKE, however, are probably the best solution for IPsec >>protocols over IP multicast services [GDOI]. >The architecture document is not an appropriate place for blatant >editorialisms. It is not as you say it is. I'll ignore the rudeness of this sentence and focus on the issue: It makes no sense to force AH and ESP to select a key management application based on whether it has a unicast or a multicast destination address in the packet it is processing. One may want to do that, but extensions to IKE are probably the best solution for IPsec protocols over IP multicast services. This is an architectural issue for it involves multiple functional blocks (data security protocols and key management protocol) , and it is why msec will likely standardize an IKE-based specification in addition to a something like GSAKMP (at least the key management protocol of it once that's separated out). I'll spare ipsec my comments on the rest of your points and post only to msec. Mark >2. >> >>A "secure group" is a collection of principals, >>called "members," who may be senders, receivers or both receivers and >>senders to other members of the group. (Note that group membership may >>vary over time.) A "group key management protocol" ensures that only >>members of a secure group gain access to group data (by gaining access >>to group keys) and can authenticate group data. >A secure group is a group in which access to data is restricted to >particular entities. This access can be of read and/or write access. In >other words, a group may only have write restrictions and no read >restrictions. While this access may be enforced with group keys, it is >mandated by a policy that claims data will only be accepted from >particular entities, which could also be enforced with signature keys. A >key distribution protocol alone does not define a secure group. This >really demands a _security management_ protocol that can manage keys and >policy. > >3. >> >>4. The key-management protocol must be secure against man-in-the- >> middle, connection-hijacking, and reflection/replay attacks; it must >> use best-known practices to thwart denial-of-service attacks. > > >And type attacks. And attacks resulting from lack of explicitness >(mis-routed, mis-interpreted). And interleaved with other protocols >(protocol-oracle), etc. Perhaps it would be better to generalize this >statement. > >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." > >5. Re: video on demand example. The example shows a pre-existing group >of all possible members subject to pre-broadcast rekey. One broadcast >would destroy this property. > >6. >> >>A centralized >>group controller (or KDC) that is used in this architecture may not be >>the best design for small, interactive groups. But for large, single- >>source multicast groups, it is generally undesirable to distribute key >>management functions among group members: Unlike small, interactive >>groups, large single-source multicast groups generally need a >>specialized KDC to support large numbers of group members. Large >>distributed simulations, moreover, may combine the need for large-grou >>operation with many senders. >Large groups require distributed initial key distribution! Large dynamic >groups cannot rely upon a centralized KDC. This does not scale. This is >highly inflexible. The VoD example demonstrates this. > >While the interactions with distributed rekey entities is more >complicated, this functionality may be needed in composite multicast >groups of limited scope. > >7. >> >>It may be that no >>single key management protocol can satisfy the scalability requirements >>of all group-security applications. This is for further study. >It may be that the security protocols protecting group communications data >cannot satisfy each of the possible sender/receiver profiles. This is >less of a security management problem. > >8. >> >>This design is based upon a "group controller" model >>[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group >>owner as the root-of-trust. The group owner designates a key >>distribution center for member registration and re-key. >As was originally envisioned, the group owner CAN (and for large or sparse >groups SHOULD) designate multiple key servers. > >9. Section 3.2 -- The term TEK is inappropriately specific. The group >may not have encryption requirements, but only authentication. > >10. >> >>Only one SA is optional and that is the Re-key >>SA. > > >Actually, one policy for the Re-Key SA is that there is none. It is >null. Explicitly stating this prevents confusion between missing SA info >and optional SA info. Likewise, the registration protocol may involve >manual methods. > >11. >> >>The KDC, moreover, can be delegated when the >>trust infrastructure supports delegation to permit distributed >>operation of the KDC. >This statement, while correct, seems to conflict with the statement quoted >in Comment #6. > >12. >> >>MSEC assumes that at least the following group-policy information is >>externally managed. >> o Group owner, authentication method, and delegation method for >> identifying a KDC for the group >> o Group KDC, authentication method, and any method used for >> delegating other KDCs for the group >> o Group membership rules or list and authentication method > > >These assumptions are unnecessary as was shown by GSAKMP. > I. While the group owner may be published externally, the group > owner can also be disclosed during the registration protocol. It can be > decided during this time whether the owner is acceptable prior to > completion of registration. Once this occurs, authenticated group policy > can be conveyed to the new member using traditional mechanisms such as > digital signatures tied to a PKI. > II. The delegation can be stated (authorized) through the > authenticated policy statement as was done with GSAKMP. > III. Ditto for membership rules and lists > IV. The security association characteristics of the registration > protocol can be determined early in the registration exchange or in > almost all protocols (TLS, IPSec, GSAKMP, etc.) can be restricted by what > properties the Key Server will accept using cipher suite restrictions, > SPD constraints, etc. > > External management of these can be done, but should not be assumed > in the architecture document. > >13. In general, this document contains very little new information. The >framework for the architecture was already provided by the building block >documents with the category 1,2, and 3 SAs. The architecture document >should work toward providing interoperable solutions. > >--- Andrea Colegrove > > > >Internet-Drafts@ietf.org wrote: >>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 : Group Key Management Architecture >> Author(s) : M. Baugher, R. Canetti, L. Dondeti >> Filename : draft-ietf-msec-gkmarch-00.txt >> Pages : 22 >> Date : 26-Jun-01 >> >>This document presents a group key-management architecture for MSEC. >>The purpose of this document is to define the common architecture for >>MSEC group key-management protocols that support a variety of >>application, transport, and internetwork security protocols. To >>address these diverse uses, MSEC may need to standardize two or more >>group key management protocols that have common requirements, >>abstractions, overall design, and messages. The framework and >>guidelines in this document allow for a modular and flexible design of >>group key management protocols for a variety different settings that >>are specialized to application needs. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.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-gkmarch-00.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-gkmarch-00.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: <20010626132202.I-D@ietf.org> _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 27 18:48:52 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11495 for ; Wed, 27 Jun 2001 18:48:50 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A338153608; Wed, 27 Jun 2001 18:48: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 DAA935359E for ; Wed, 13 Jun 2001 09:33:33 -0400 (EDT) Received: (qmail 84309 invoked by uid 3269); 13 Jun 2001 13:33:33 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 84306 invoked from network); 13 Jun 2001 13:33:33 -0000 Received: from patan.sun.com (192.18.98.43) by klesh.pair.com with SMTP; 13 Jun 2001 13:33:33 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17681; Wed, 13 Jun 2001 07:33:22 -0600 (MDT) Received: from kebe.east.sun.com (kebe.East.Sun.COM [129.148.176.81]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24271; Wed, 13 Jun 2001 09:33:18 -0400 (EDT) Received: (from danmcd@localhost) by kebe.east.sun.com (8.11.4+Sun/8.11.3) id f5DDXJY23927; Wed, 13 Jun 2001 09:33:19 -0400 (EDT) Message-Id: <200106131333.f5DDXJY23927@kebe.east.sun.com> Subject: Re: [MSEC] Re: mluticast authentication using AH In-Reply-To: from Hilarie Orman at "Jun 12, 2001 04:34:12 pm" To: Hilarie Orman Cc: mbaugher@cisco.com, Saber.Brakta@loria.fr, ipsec@lists.tislabs.com, msec@securemulticast.org From: Dan McDonald Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 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, 13 Jun 2001 09:33:19 -0400 (EDT) Content-Transfer-Encoding: 7bit > AH SHOULD HAVE supported authentication with digital signatures. There's nothing, I believe, about AH that prevents digital signatures from being used. The Authentication Data area can be made up to 1016 bytes (just shy of 8kbits) per 2402. That should be plenty of room for a digital signature. Dan _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 27 18:51:06 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13368 for ; Wed, 27 Jun 2001 18:51:03 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 5161C53618; Wed, 27 Jun 2001 18:48: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 BC27B53537 for ; Wed, 13 Jun 2001 10:14:30 -0400 (EDT) Received: (qmail 89150 invoked by uid 3269); 13 Jun 2001 14:14:30 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 89142 invoked from network); 13 Jun 2001 14:14:29 -0000 Received: from patan.sun.com (192.18.98.43) by klesh.pair.com with SMTP; 13 Jun 2001 14:14:29 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20176; Wed, 13 Jun 2001 08:14:24 -0600 (MDT) Received: from kebe.east.sun.com (kebe.East.Sun.COM [129.148.176.81]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA04352; Wed, 13 Jun 2001 10:14:24 -0400 (EDT) Received: (from danmcd@localhost) by kebe.east.sun.com (8.11.4+Sun/8.11.3) id f5DEEOo24149; Wed, 13 Jun 2001 10:14:24 -0400 (EDT) Message-Id: <200106131414.f5DEEOo24149@kebe.east.sun.com> Subject: Re: [MSEC] Re: mluticast authentication using AH In-Reply-To: <4.3.2.7.2.20010613070758.042d0d10@mira-sjc5-6.cisco.com> from Mark Baugher at "Jun 13, 2001 07:08:45 am" To: Mark Baugher Cc: Dan McDonald , ipsec@lists.tislabs.com, msec@securemulticast.org From: Dan McDonald Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 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, 13 Jun 2001 10:14:24 -0400 (EDT) Content-Transfer-Encoding: 7bit > > > AH SHOULD HAVE supported authentication with digital signatures. > > > >There's nothing, I believe, about AH that prevents digital signatures from > >being used. > > > >The Authentication Data area can be made up to 1016 bytes (just shy of > >8kbits) per 2402. That should be plenty of room for a digital signature. > > > >Dan > > How is this signalled? It's part of the IPsec Security Association data. Per 2401, an SA is indexed by the tuple . When you add the appropriate SA, you get all sorts of data, including the algorithm. All one would need to do is write a new "algorithm document" for using a digital signature with AH. It shouldn't be tough, and if I had cycles (HAH!) I could easily prototype one in Solaris. Dan _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 27 18:52:57 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14924 for ; Wed, 27 Jun 2001 18:52:55 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 98C055361C; Wed, 27 Jun 2001 18:48: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 B366453689 for ; Wed, 13 Jun 2001 11:36:32 -0400 (EDT) Received: (qmail 97480 invoked by uid 3269); 13 Jun 2001 15:36:32 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 97477 invoked from network); 13 Jun 2001 15:36:32 -0000 Received: from patan.sun.com (192.18.98.43) by klesh.pair.com with SMTP; 13 Jun 2001 15:36:32 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02991; Wed, 13 Jun 2001 09:36:25 -0600 (MDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.89.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id IAA00615; Wed, 13 Jun 2001 08:37:30 -0700 (PDT) Received: from baton.eng.sun.com (stillson.Eng.Sun.COM [129.146.85.64]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5DFaNG266269; Wed, 13 Jun 2001 08:36:23 -0700 (PDT) From: chris stillson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15143.34760.816323.352672@gargle.gargle.HOWL> To: Dan McDonald Cc: Mark Baugher , Dan McDonald , ipsec@lists.tislabs.com, msec@securemulticast.org Subject: Re: [MSEC] Re: mluticast authentication using AH In-Reply-To: <200106131414.f5DEEOo24149@kebe.east.sun.com> References: <4.3.2.7.2.20010613070758.042d0d10@mira-sjc5-6.cisco.com> <200106131414.f5DEEOo24149@kebe.east.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 3) "Acadia" XEmacs Lucid X-Face: ;>?o+t66!z`OvpX.6T'j.4l4Gi+L*?8ZnU3L[G/^R,ELl3.Stln=12L+t|hsa*<{/D<{OS( ybD%5 List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Wed, 13 Jun 2001 08:33:28 -0700 (PDT) Content-Transfer-Encoding: 7bit Dan McDonald writes: > > > > AH SHOULD HAVE supported authentication with digital signatures. > > > > > >There's nothing, I believe, about AH that prevents digital signatures from > > >being used. > > > > > >The Authentication Data area can be made up to 1016 bytes (just shy of > > >8kbits) per 2402. That should be plenty of room for a digital signature. > > > > > >Dan > > > > How is this signalled? > > It's part of the IPsec Security Association data. Per 2401, an SA is indexed > by the tuple . When you add the appropriate > SA, you get all sorts of data, including the algorithm. > > All one would need to do is write a new "algorithm document" for using a > digital signature with AH. It shouldn't be tough, and if I had cycles (HAH!) > I could easily prototype one in Solaris. Yep. This is doable. But, I would advise against it. It would require some kind of higher math (bignum, ecc, etc) on every packet. Someone could very easily start forging packets and bring pretty much any machine ever made to a halt. But, it would make key exchange unnecessary, so it could be worth trying. chris stillson IPSEC crypto monkey x82477 Note: Preceding comments written by an engineer. There is nothing to read into them. He really has no hidden motives or agendas. 1.Right Understanding 2.Right Thoughts 3.Right Speech 4.Right Action 5.Right Livelihood 6.Right Effort 7.Right Mindfulness 8.Right Concentration --Please inform author if he has forgotten about any of these _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 27 18:54:49 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16271 for ; Wed, 27 Jun 2001 18:54:49 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id EDF0553620; Wed, 27 Jun 2001 18:48:07 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 4A0A1535BD for ; Wed, 27 Jun 2001 07:03:59 -0400 (EDT) Received: (qmail 20032 invoked by uid 3269); 27 Jun 2001 11:03:58 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 20026 invoked from network); 27 Jun 2001 11:03:58 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 27 Jun 2001 11:03:58 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26170; Wed, 27 Jun 2001 07:03:11 -0400 (EDT) Message-Id: <200106271103.HAA26170@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: msec@securemulticast.org, ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [MSEC] I-D ACTION:draft-ietf-msec-gkmarch-00.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, 27 Jun 2001 07:03:10 -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 : Group Key Management Architecture Author(s) : M. Baugher, R. Canetti, L. Dondeti Filename : draft-ietf-msec-gkmarch-00.txt Pages : 22 Date : 26-Jun-01 This document presents a group key-management architecture for MSEC. The purpose of this document is to define the common architecture for MSEC group key-management protocols that support a variety of application, transport, and internetwork security protocols. To address these diverse uses, MSEC may need to standardize two or more group key management protocols that have common requirements, abstractions, overall design, and messages. The framework and guidelines in this document allow for a modular and flexible design of group key management protocols for a variety different settings that are specialized to application needs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.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-gkmarch-00.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-gkmarch-00.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: <20010626132202.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-gkmarch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-gkmarch-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010626132202.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 27 18:56:21 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17403 for ; Wed, 27 Jun 2001 18:56:20 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C754953624; Wed, 27 Jun 2001 18:48: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 0F53753582 for ; Wed, 27 Jun 2001 13:30:47 -0400 (EDT) Received: (qmail 61898 invoked by uid 3269); 27 Jun 2001 17:30:46 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 61893 invoked from network); 27 Jun 2001 17:30:46 -0000 Received: from softdnserror (HELO M5.sparta.com) (root@157.185.61.1) by klesh.pair.com with SMTP; 27 Jun 2001 17:30:46 -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 f5RHUiJ28168 for ; Wed, 27 Jun 2001 12:30:44 -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 NAA14881 for ; Wed, 27 Jun 2001 13:30:36 -0400 (EDT) Message-ID: <3B3A1837.D95360C0@columbia.sparta.com> From: Andrea Colegrove X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: msec@securemulticast.org References: <200106271103.HAA26170@ietf.org> Content-Type: multipart/alternative; boundary="------------E7B7F4EE607BF84BF270BC1C" Subject: [MSEC] Re: I-D ACTION:draft-ietf-msec-gkmarch-00.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, 27 Jun 2001 13:30:31 -0400 --------------E7B7F4EE607BF84BF270BC1C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark, etal, Initial comments on the architecture -- 1. Section 1. -- > Extensions to IKE, however, are probably the best solution for IPsec > protocols over IP multicast services [GDOI]. > The architecture document is not an appropriate place for blatant editorialisms. 2. > A "secure group" is a collection of principals, > called "members," who may be senders, receivers or both receivers and > senders to other members of the group. (Note that group membership may > vary over time.) A "group key management protocol" ensures that only > members of a secure group gain access to group data (by gaining access > to group keys) and can authenticate group data. > A secure group is a group in which access to data is restricted to particular entities. This access can be of read and/or write access. In other words, a group may only have write restrictions and no read restrictions. While this access may be enforced with group keys, it is mandated by a policy that claims data will only be accepted from particular entities, which could also be enforced with signature keys. A key distribution protocol alone does not define a secure group. This really demands a _security management_ protocol that can manage keys and policy. 3. > 4. The key-management protocol must be secure against man-in-the- > middle, connection-hijacking, and reflection/replay attacks; it must > use best-known practices to thwart denial-of-service attacks. > And type attacks. And attacks resulting from lack of explicitness (mis-routed, mis-interpreted). And interleaved with other protocols (protocol-oracle), etc. Perhaps it would be better to generalize this statement. 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." 5. Re: video on demand example. The example shows a pre-existing group of all possible members subject to pre-broadcast rekey. One broadcast would destroy this property. 6. > A centralized > group controller (or KDC) that is used in this architecture may not be > the best design for small, interactive groups. But for large, single- > source multicast groups, it is generally undesirable to distribute key > management functions among group members: Unlike small, interactive > groups, large single-source multicast groups generally need a > specialized KDC to support large numbers of group members. Large > distributed simulations, moreover, may combine the need for large-grou > operation with many senders. > Large groups require distributed initial key distribution! Large dynamic groups cannot rely upon a centralized KDC. This does not scale. This is highly inflexible. The VoD example demonstrates this. While the interactions with distributed rekey entities is more complicated, this functionality may be needed in composite multicast groups of limited scope. 7. > It may be that no > single key management protocol can satisfy the scalability requirements > of all group-security applications. This is for further study. > It may be that the security protocols protecting group communications data cannot satisfy each of the possible sender/receiver profiles. This is less of a security management problem. 8. > This design is based upon a "group controller" model > [RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group > owner as the root-of-trust. The group owner designates a key > distribution center for member registration and re-key. > As was originally envisioned, the group owner CAN (and for large or sparse groups SHOULD) designate multiple key servers. 9. Section 3.2 -- The term TEK is inappropriately specific. The group may not have encryption requirements, but only authentication. 10. > Only one SA is optional and that is the Re-key > SA. > Actually, one policy for the Re-Key SA is that there is none. It is null. Explicitly stating this prevents confusion between missing SA info and optional SA info. Likewise, the registration protocol may involve manual methods. 11. > The KDC, moreover, can be delegated when the > trust infrastructure supports delegation to permit distributed > operation of the KDC. > This statement, while correct, seems to conflict with the statement quoted in Comment #6. 12. > MSEC assumes that at least the following group-policy information is > externally managed. > o Group owner, authentication method, and delegation method for > identifying a KDC for the group > o Group KDC, authentication method, and any method used for > delegating other KDCs for the group > o Group membership rules or list and authentication method > These assumptions are unnecessary as was shown by GSAKMP. I. While the group owner may be published externally, the group owner can also be disclosed during the registration protocol. It can be decided during this time whether the owner is acceptable prior to completion of registration. Once this occurs, authenticated group policy can be conveyed to the new member using traditional mechanisms such as digital signatures tied to a PKI. II. The delegation can be stated (authorized) through the authenticated policy statement as was done with GSAKMP. III. Ditto for membership rules and lists IV. The security association characteristics of the registration protocol can be determined early in the registration exchange or in almost all protocols (TLS, IPSec, GSAKMP, etc.) can be restricted by what properties the Key Server will accept using cipher suite restrictions, SPD constraints, etc. External management of these can be done, but should not be assumed in the architecture document. 13. In general, this document contains very little new information. The framework for the architecture was already provided by the building block documents with the category 1,2, and 3 SAs. The architecture document should work toward providing interoperable solutions. --- Andrea Colegrove Internet-Drafts@ietf.org wrote: > 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 : Group Key Management Architecture > Author(s) : M. Baugher, R. Canetti, L. Dondeti > Filename : draft-ietf-msec-gkmarch-00.txt > Pages : 22 > Date : 26-Jun-01 > > This document presents a group key-management architecture for MSEC. > The purpose of this document is to define the common architecture for > MSEC group key-management protocols that support a variety of > application, transport, and internetwork security protocols. To > address these diverse uses, MSEC may need to standardize two or more > group key management protocols that have common requirements, > abstractions, overall design, and messages. The framework and > guidelines in this document allow for a modular and flexible design of > group key management protocols for a variety different settings that > are specialized to application needs. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.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-gkmarch-00.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-gkmarch-00.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: <20010626132202.I-D@ietf.org> --------------E7B7F4EE607BF84BF270BC1C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Mark, etal,
Initial comments on the architecture --

1.  Section 1. -- 

Extensions to IKE, however, are probably the best solution for IPsec 
protocols over IP multicast services [GDOI].
The architecture document is not an appropriate place for blatant editorialisms.

2. 

A "secure group" is a collection of principals, 
called "members," who may be senders, receivers or both receivers and 
senders to other members of the group. (Note that group membership may 
vary over time.) A "group key management protocol" ensures that only 
members of a secure group gain access to group data (by gaining access 
to group keys) and can authenticate group data.
A secure group is a group in which access to data is restricted to particular entities.  This access can be of read and/or write access.  In other words, a group may only have write restrictions and no read restrictions.  While this access may be enforced with group keys, it is mandated by a policy that claims data will only be accepted from particular entities, which could also be enforced with signature keys.  A key distribution protocol alone does not define a secure group.  This really demands a _security management_ protocol that can manage keys and policy.

3. 

4. The key-management protocol must be secure against man-in-the-
   middle, connection-hijacking, and reflection/replay attacks; it must
   use best-known practices to thwart denial-of-service attacks.


And type attacks.  And attacks resulting from lack of explicitness (mis-routed, mis-interpreted).  And interleaved with other protocols (protocol-oracle), etc.  Perhaps it would be better to generalize this statement.

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."

5.  Re:  video on demand example.   The example shows a pre-existing group of all possible members subject to pre-broadcast rekey.  One broadcast would destroy this property.

6. 

A centralized
group controller (or KDC) that is used in this architecture may not be 
the best design for small, interactive groups.  But for large, single-
source multicast groups, it is generally undesirable to distribute key 
management functions among group members: Unlike small, interactive 
groups, large single-source multicast groups generally need a 
specialized KDC to support large numbers of group members.  Large 
distributed simulations, moreover, may combine the need for large-grou 
operation with many senders.
Large groups require distributed initial key distribution!  Large dynamic groups cannot rely upon a centralized KDC.  This does not scale.  This is highly inflexible.  The VoD example demonstrates this.

While the interactions with distributed rekey entities is more complicated, this functionality may be needed in composite multicast groups of limited scope.

7. 

It may be that no 
single key management protocol can satisfy the scalability requirements
of all group-security applications.  This is for further study.
It may be that the security protocols protecting group communications data cannot satisfy each of the possible sender/receiver profiles.  This is less of a security management problem.

8. 

This design is based upon a "group controller" model 
[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group 
owner as the root-of-trust.  The group owner designates a key 
distribution center for member registration and re-key.
As was originally envisioned, the group owner CAN (and for large or sparse groups SHOULD) designate multiple key servers.

9.  Section 3.2 -- The term TEK is inappropriately specific.  The group may not have encryption requirements, but only authentication.

10. 

Only one SA is optional and that is the Re-key 
SA.


Actually, one policy for the Re-Key SA is that there is none.  It is null.  Explicitly stating this prevents confusion between missing SA info and optional SA info.  Likewise, the registration protocol may involve manual methods.

11. 

The KDC, moreover, can be delegated when the 
trust infrastructure supports delegation to permit distributed 
operation of the KDC.
This statement, while correct, seems to conflict with the statement quoted in Comment #6.

12. 

MSEC assumes that at least the following group-policy information is
externally managed.
  o Group owner, authentication method, and delegation method for 
    identifying a KDC for the group
  o Group KDC, authentication method, and any method used for
    delegating other KDCs for the group
  o Group membership rules or list and authentication method


These assumptions are unnecessary as was shown by GSAKMP.
    I.  While the group owner may be published externally, the group owner can also be disclosed during the registration protocol.  It can be decided during this time whether the owner is acceptable prior to completion of registration.  Once this occurs, authenticated group policy can be conveyed to the new member using traditional mechanisms such as digital signatures tied to a PKI.
    II.  The delegation can be stated (authorized) through the authenticated policy statement as was done with GSAKMP.
    III.  Ditto for membership rules and lists
    IV.  The security association characteristics of the registration protocol can be determined early in the registration exchange or in almost all protocols (TLS, IPSec, GSAKMP, etc.) can be restricted by what properties the Key Server will accept using cipher suite restrictions, SPD constraints, etc.

    External management of these can be done, but should not be assumed in the architecture document.

13.  In general, this document contains very little new information.  The framework for the architecture was already provided by the building block documents with the category 1,2, and 3 SAs.  The architecture document should work toward providing interoperable solutions.

--- Andrea Colegrove
 
 

Internet-Drafts@ietf.org wrote:

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           : Group Key Management Architecture
        Author(s)       : M. Baugher, R. Canetti, L. Dondeti
        Filename        : draft-ietf-msec-gkmarch-00.txt
        Pages           : 22
        Date            : 26-Jun-01

This document presents a group key-management architecture for MSEC.
The purpose of this document is to define the common architecture for
MSEC group key-management protocols that support a variety of
application, transport, and internetwork security protocols.  To
address these diverse uses, MSEC may need to standardize two or more
group key management protocols that have common requirements,
abstractions, overall design, and messages. The framework and
guidelines in this document allow for a modular and flexible design of
group key management protocols for a variety different settings that
are specialized to application needs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.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-gkmarch-00.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-gkmarch-00.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:     <20010626132202.I-D@ietf.org>

--------------E7B7F4EE607BF84BF270BC1C-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 27 18:57:56 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18522 for ; Wed, 27 Jun 2001 18:57:55 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 13A7253628; Wed, 27 Jun 2001 18:48: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 31683535B0 for ; Wed, 27 Jun 2001 18:47:31 -0400 (EDT) Received: (qmail 99492 invoked by uid 3269); 27 Jun 2001 22:47:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 99489 invoked from network); 27 Jun 2001 22:47:30 -0000 Received: from chmls06.mediaone.net (24.147.1.144) by klesh.pair.com with SMTP; 27 Jun 2001 22:47:30 -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 f5RMlT802354 for ; Wed, 27 Jun 2001 18:47:29 -0400 (EDT) Message-Id: <5.0.0.25.2.20010627184709.019388d0@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: msec@securemulticast.org From: Thomas Hardjono Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] test - ignore 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, 27 Jun 2001 18:47:21 -0400 test - ignore _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 27 19:04:37 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23281 for ; Wed, 27 Jun 2001 19:04:37 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4988D53646; Wed, 27 Jun 2001 19:04:07 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id DA39C535DD for ; Wed, 27 Jun 2001 19:02:00 -0400 (EDT) Received: (qmail 786 invoked by uid 3269); 27 Jun 2001 23:02:00 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 783 invoked from network); 27 Jun 2001 23:02:00 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by klesh.pair.com with SMTP; 27 Jun 2001 23:02:00 -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 f5RN1WN27651; Wed, 27 Jun 2001 16:01:32 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-615.cisco.com [10.21.66.103]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ACW22954; Wed, 27 Jun 2001 16:01:23 -0700 (PDT) Message-Id: <4.3.2.7.2.20010627153746.042fef90@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Andrea Colegrove From: Mark Baugher Cc: msec@securemulticast.org In-Reply-To: <3B3A1A8F.719CC71A@columbia.sparta.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Re: [Fwd: I-D ACTION:draft-ietf-msec-gkmarch-00.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, 27 Jun 2001 16:00:51 -0700 Andrea I comment on your second point in this note. At 01:40 PM 6/27/2001 -0400, Andrea Colegrove wrote: >X-Mozilla-Status2: 00000000 >Message-ID: <3B3A1837.D95360C0@columbia.sparta.com> >Date: Wed, 27 Jun 2001 13:30:31 -0400 >From: Andrea Colegrove >X-Mailer: Mozilla 4.75 [en] (Win98; U) >X-Accept-Language: en >MIME-Version: 1.0 >To: msec@securemulticast.org >Subject: Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt >References: <200106271103.HAA26170@ietf.org> >Content-Type: multipart/alternative; > boundary="------------E7B7F4EE607BF84BF270BC1C" > >Mark, etal, >Initial comments on the architecture -- > >1. Section 1. -- >> >>Extensions to IKE, however, are probably the best solution for IPsec >>protocols over IP multicast services [GDOI]. >The architecture document is not an appropriate place for blatant >editorialisms. Answered in previous posting. >2. >> >>A "secure group" is a collection of principals, >>called "members," who may be senders, receivers or both receivers and >>senders to other members of the group. (Note that group membership may >>vary over time.) A "group key management protocol" ensures that only >>members of a secure group gain access to group data (by gaining access >>to group keys) and can authenticate group data. >A secure group is a group in which access to data is restricted to >particular entities. This access can be of read and/or write access. In >other words, a group may only have write restrictions and no read >restrictions. While this access may be enforced with group keys, it is >mandated by a policy that claims data will only be accepted from >particular entities, which could also be enforced with signature keys. A >key distribution protocol alone does not define a secure group. This >really demands a _security management_ protocol that can manage keys and >policy. There is nothing that you have written that is inconsistent with what we wrote except that you really cannot implement the stuff about read or write access when a symmetric key is used. A group member who receives encrypted data can send it. There could be some policy processing at a host-member to throw away messages based on authenticating sources and we address this in the key management architecture. You write above that it "...could also be enforced by signature keys" when in fact that's the only way it can be enforced (though TESLA-like solutions can reduce the costs of asymmetric crypto on a packet-by-packet basis). You assert that a "key distribution protocol alone does not define a secure group" but this is a straw man: The draft does not say it does. Mark >3. >> >>4. The key-management protocol must be secure against man-in-the- >> middle, connection-hijacking, and reflection/replay attacks; it must >> use best-known practices to thwart denial-of-service attacks. > > >And type attacks. And attacks resulting from lack of explicitness >(mis-routed, mis-interpreted). And interleaved with other protocols >(protocol-oracle), etc. Perhaps it would be better to generalize this >statement. > >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." > >5. Re: video on demand example. The example shows a pre-existing group >of all possible members subject to pre-broadcast rekey. One broadcast >would destroy this property. > >6. >> >>A centralized >>group controller (or KDC) that is used in this architecture may not be >>the best design for small, interactive groups. But for large, single- >>source multicast groups, it is generally undesirable to distribute key >>management functions among group members: Unlike small, interactive >>groups, large single-source multicast groups generally need a >>specialized KDC to support large numbers of group members. Large >>distributed simulations, moreover, may combine the need for large-grou >>operation with many senders. >Large groups require distributed initial key distribution! Large dynamic >groups cannot rely upon a centralized KDC. This does not scale. This is >highly inflexible. The VoD example demonstrates this. > >While the interactions with distributed rekey entities is more >complicated, this functionality may be needed in composite multicast >groups of limited scope. > >7. >> >>It may be that no >>single key management protocol can satisfy the scalability requirements >>of all group-security applications. This is for further study. >It may be that the security protocols protecting group communications data >cannot satisfy each of the possible sender/receiver profiles. This is >less of a security management problem. > >8. >> >>This design is based upon a "group controller" model >>[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group >>owner as the root-of-trust. The group owner designates a key >>distribution center for member registration and re-key. >As was originally envisioned, the group owner CAN (and for large or sparse >groups SHOULD) designate multiple key servers. > >9. Section 3.2 -- The term TEK is inappropriately specific. The group >may not have encryption requirements, but only authentication. > >10. >> >>Only one SA is optional and that is the Re-key >>SA. > > >Actually, one policy for the Re-Key SA is that there is none. It is >null. Explicitly stating this prevents confusion between missing SA info >and optional SA info. Likewise, the registration protocol may involve >manual methods. > >11. >> >>The KDC, moreover, can be delegated when the >>trust infrastructure supports delegation to permit distributed >>operation of the KDC. >This statement, while correct, seems to conflict with the statement quoted >in Comment #6. > >12. >> >>MSEC assumes that at least the following group-policy information is >>externally managed. >> o Group owner, authentication method, and delegation method for >> identifying a KDC for the group >> o Group KDC, authentication method, and any method used for >> delegating other KDCs for the group >> o Group membership rules or list and authentication method > > >These assumptions are unnecessary as was shown by GSAKMP. > I. While the group owner may be published externally, the group > owner can also be disclosed during the registration protocol. It can be > decided during this time whether the owner is acceptable prior to > completion of registration. Once this occurs, authenticated group policy > can be conveyed to the new member using traditional mechanisms such as > digital signatures tied to a PKI. > II. The delegation can be stated (authorized) through the > authenticated policy statement as was done with GSAKMP. > III. Ditto for membership rules and lists > IV. The security association characteristics of the registration > protocol can be determined early in the registration exchange or in > almost all protocols (TLS, IPSec, GSAKMP, etc.) can be restricted by what > properties the Key Server will accept using cipher suite restrictions, > SPD constraints, etc. > > External management of these can be done, but should not be assumed > in the architecture document. > >13. In general, this document contains very little new information. The >framework for the architecture was already provided by the building block >documents with the category 1,2, and 3 SAs. The architecture document >should work toward providing interoperable solutions. > >--- Andrea Colegrove > > > >Internet-Drafts@ietf.org wrote: >>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 : Group Key Management Architecture >> Author(s) : M. Baugher, R. Canetti, L. Dondeti >> Filename : draft-ietf-msec-gkmarch-00.txt >> Pages : 22 >> Date : 26-Jun-01 >> >>This document presents a group key-management architecture for MSEC. >>The purpose of this document is to define the common architecture for >>MSEC group key-management protocols that support a variety of >>application, transport, and internetwork security protocols. To >>address these diverse uses, MSEC may need to standardize two or more >>group key management protocols that have common requirements, >>abstractions, overall design, and messages. The framework and >>guidelines in this document allow for a modular and flexible design of >>group key management protocols for a variety different settings that >>are specialized to application needs. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.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-gkmarch-00.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-gkmarch-00.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: <20010626132202.I-D@ietf.org> _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 27 19:32:57 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10833 for ; Wed, 27 Jun 2001 19:32:56 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A402153554; Wed, 27 Jun 2001 19:33: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 398AA53552 for ; Wed, 27 Jun 2001 19:31:55 -0400 (EDT) Received: (qmail 5689 invoked by uid 3269); 27 Jun 2001 23:31:54 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 5686 invoked from network); 27 Jun 2001 23:31:54 -0000 Received: from softdnserror (HELO M5.sparta.com) (root@157.185.61.1) by klesh.pair.com with SMTP; 27 Jun 2001 23:31:54 -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 f5RNVpJ08146; Wed, 27 Jun 2001 18:31:52 -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 TAA17802; Wed, 27 Jun 2001 19:31:50 -0400 (EDT) Message-ID: <3B3A6CDE.A29BA9A6@columbia.sparta.com> From: Andrea Colegrove X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Baugher Cc: msec@securemulticast.org, ipsec@lists.tislabs.com References: <4.3.2.7.2.20010627140639.04301090@mira-sjc5-6.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MSEC] Re: [Fwd: I-D ACTION:draft-ietf-msec-gkmarch-00.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, 27 Jun 2001 19:31:42 -0400 Content-Transfer-Encoding: 7bit Mark, Since you are the primary author (editor?) of GDOI I am sure that you feel GDOI is best. The architecture document, however, is not the place to promote your solution. Many feel that modifications to a standard to support multicast is not a good solution. IKE is designed with certain assumptions which hold for pairwise paradigms but not necessarily groups. Also, because SPD and SAD values for a group cannot be completely determined in advance and are more likely distributed as part of the Join/Registration process, IKE will not likely be automatically fired off anyway (analogous to PPKs). Regardless of how you feel on this issue, it is inappropriate to state that GDOI is probably the best solution at this point in general and certainly not in the architecture document. Wrt GSAKMP and separating out the "key management protocol": key management involves more than distribution. --- Andrea Mark Baugher wrote: > Andrea > I respond to your first point in this note. > > At 01:40 PM 6/27/2001 -0400, Andrea Colegrove wrote: > > >X-Mozilla-Status2: 00000000 > >Message-ID: <3B3A1837.D95360C0@columbia.sparta.com> > >Date: Wed, 27 Jun 2001 13:30:31 -0400 > >From: Andrea Colegrove > >X-Mailer: Mozilla 4.75 [en] (Win98; U) > >X-Accept-Language: en > >MIME-Version: 1.0 > >To: msec@securemulticast.org > >Subject: Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt > >References: <200106271103.HAA26170@ietf.org> > >Content-Type: multipart/alternative; > > boundary="------------E7B7F4EE607BF84BF270BC1C" > > > >Mark, etal, > >Initial comments on the architecture -- > > > >1. Section 1. -- > >> > >>Extensions to IKE, however, are probably the best solution for IPsec > >>protocols over IP multicast services [GDOI]. > >The architecture document is not an appropriate place for blatant > >editorialisms. > > It is not as you say it is. I'll ignore the rudeness of this sentence and > focus > on the issue: It makes no sense to force AH and ESP to select a key management > application based on whether it has a unicast or a multicast destination > address in > the packet it is processing. One may want to do that, but extensions to > IKE are probably > the best solution for IPsec protocols over IP multicast services. This is > an architectural > issue for it involves multiple functional blocks (data security protocols > and key > management protocol) , and it is why msec will likely standardize an IKE-based > specification in addition to a something like GSAKMP (at least the key > management > protocol of it once that's separated out). > > I'll spare ipsec my comments on the rest of your points and post only to msec. > > Mark > > >2. > >> > >>A "secure group" is a collection of principals, > >>called "members," who may be senders, receivers or both receivers and > >>senders to other members of the group. (Note that group membership may > >>vary over time.) A "group key management protocol" ensures that only > >>members of a secure group gain access to group data (by gaining access > >>to group keys) and can authenticate group data. > >A secure group is a group in which access to data is restricted to > >particular entities. This access can be of read and/or write access. In > >other words, a group may only have write restrictions and no read > >restrictions. While this access may be enforced with group keys, it is > >mandated by a policy that claims data will only be accepted from > >particular entities, which could also be enforced with signature keys. A > >key distribution protocol alone does not define a secure group. This > >really demands a _security management_ protocol that can manage keys and > >policy. > > > >3. > >> > >>4. The key-management protocol must be secure against man-in-the- > >> middle, connection-hijacking, and reflection/replay attacks; it must > >> use best-known practices to thwart denial-of-service attacks. > > > > > >And type attacks. And attacks resulting from lack of explicitness > >(mis-routed, mis-interpreted). And interleaved with other protocols > >(protocol-oracle), etc. Perhaps it would be better to generalize this > >statement. > > > >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." > > > >5. Re: video on demand example. The example shows a pre-existing group > >of all possible members subject to pre-broadcast rekey. One broadcast > >would destroy this property. > > > >6. > >> > >>A centralized > >>group controller (or KDC) that is used in this architecture may not be > >>the best design for small, interactive groups. But for large, single- > >>source multicast groups, it is generally undesirable to distribute key > >>management functions among group members: Unlike small, interactive > >>groups, large single-source multicast groups generally need a > >>specialized KDC to support large numbers of group members. Large > >>distributed simulations, moreover, may combine the need for large-grou > >>operation with many senders. > >Large groups require distributed initial key distribution! Large dynamic > >groups cannot rely upon a centralized KDC. This does not scale. This is > >highly inflexible. The VoD example demonstrates this. > > > >While the interactions with distributed rekey entities is more > >complicated, this functionality may be needed in composite multicast > >groups of limited scope. > > > >7. > >> > >>It may be that no > >>single key management protocol can satisfy the scalability requirements > >>of all group-security applications. This is for further study. > >It may be that the security protocols protecting group communications data > >cannot satisfy each of the possible sender/receiver profiles. This is > >less of a security management problem. > > > >8. > >> > >>This design is based upon a "group controller" model > >>[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group > >>owner as the root-of-trust. The group owner designates a key > >>distribution center for member registration and re-key. > >As was originally envisioned, the group owner CAN (and for large or sparse > >groups SHOULD) designate multiple key servers. > > > >9. Section 3.2 -- The term TEK is inappropriately specific. The group > >may not have encryption requirements, but only authentication. > > > >10. > >> > >>Only one SA is optional and that is the Re-key > >>SA. > > > > > >Actually, one policy for the Re-Key SA is that there is none. It is > >null. Explicitly stating this prevents confusion between missing SA info > >and optional SA info. Likewise, the registration protocol may involve > >manual methods. > > > >11. > >> > >>The KDC, moreover, can be delegated when the > >>trust infrastructure supports delegation to permit distributed > >>operation of the KDC. > >This statement, while correct, seems to conflict with the statement quoted > >in Comment #6. > > > >12. > >> > >>MSEC assumes that at least the following group-policy information is > >>externally managed. > >> o Group owner, authentication method, and delegation method for > >> identifying a KDC for the group > >> o Group KDC, authentication method, and any method used for > >> delegating other KDCs for the group > >> o Group membership rules or list and authentication method > > > > > >These assumptions are unnecessary as was shown by GSAKMP. > > I. While the group owner may be published externally, the group > > owner can also be disclosed during the registration protocol. It can be > > decided during this time whether the owner is acceptable prior to > > completion of registration. Once this occurs, authenticated group policy > > can be conveyed to the new member using traditional mechanisms such as > > digital signatures tied to a PKI. > > II. The delegation can be stated (authorized) through the > > authenticated policy statement as was done with GSAKMP. > > III. Ditto for membership rules and lists > > IV. The security association characteristics of the registration > > protocol can be determined early in the registration exchange or in > > almost all protocols (TLS, IPSec, GSAKMP, etc.) can be restricted by what > > properties the Key Server will accept using cipher suite restrictions, > > SPD constraints, etc. > > > > External management of these can be done, but should not be assumed > > in the architecture document. > > > >13. In general, this document contains very little new information. The > >framework for the architecture was already provided by the building block > >documents with the category 1,2, and 3 SAs. The architecture document > >should work toward providing interoperable solutions. > > > >--- Andrea Colegrove > > > > > > > >Internet-Drafts@ietf.org wrote: > >>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 : Group Key Management Architecture > >> Author(s) : M. Baugher, R. Canetti, L. Dondeti > >> Filename : draft-ietf-msec-gkmarch-00.txt > >> Pages : 22 > >> Date : 26-Jun-01 > >> > >>This document presents a group key-management architecture for MSEC. > >>The purpose of this document is to define the common architecture for > >>MSEC group key-management protocols that support a variety of > >>application, transport, and internetwork security protocols. To > >>address these diverse uses, MSEC may need to standardize two or more > >>group key management protocols that have common requirements, > >>abstractions, overall design, and messages. The framework and > >>guidelines in this document allow for a modular and flexible design of > >>group key management protocols for a variety different settings that > >>are specialized to application needs. > >> > >>A URL for this Internet-Draft is: > >>http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.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-gkmarch-00.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-gkmarch-00.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: <20010626132202.I-D@ietf.org> _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 27 19:45:53 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19609 for ; Wed, 27 Jun 2001 19:45:51 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 3CBCC53554; Wed, 27 Jun 2001 19:46: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 EE17453554 for ; Wed, 27 Jun 2001 19:42:46 -0400 (EDT) Received: (qmail 7992 invoked by uid 3269); 27 Jun 2001 23:42:46 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 7989 invoked from network); 27 Jun 2001 23:42:46 -0000 Received: from m5.sparta.com (root@157.185.61.1) by klesh.pair.com with SMTP; 27 Jun 2001 23:42:46 -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 f5RNgjJ08350; Wed, 27 Jun 2001 18:42:45 -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 TAA17888; Wed, 27 Jun 2001 19:42:43 -0400 (EDT) Message-ID: <3B3A6F6B.86E65004@columbia.sparta.com> From: Andrea Colegrove X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Baugher Cc: msec@securemulticast.org References: <4.3.2.7.2.20010627153746.042fef90@mira-sjc5-6.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MSEC] Re: [Fwd: I-D ACTION:draft-ietf-msec-gkmarch-00.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, 27 Jun 2001 19:42:35 -0400 Content-Transfer-Encoding: 7bit Mark, Clearly sending and writing are different. To write info to a group, possession of a symmetric authentication key may be required. Yes, anyone can read it (if it isn't encrypted) and send it on, but only group members can generate authentic data and have it be accepted by other group members. I would have been clearer had I said "a key management protocol alone does not grow secure groups -- security management is needed because the issues needing management are larger than just the keys." --- Andrea Mark Baugher wrote: > Andrea > I comment on your second point in this note. > > At 01:40 PM 6/27/2001 -0400, Andrea Colegrove wrote: > > >X-Mozilla-Status2: 00000000 > >Message-ID: <3B3A1837.D95360C0@columbia.sparta.com> > >Date: Wed, 27 Jun 2001 13:30:31 -0400 > >From: Andrea Colegrove > >X-Mailer: Mozilla 4.75 [en] (Win98; U) > >X-Accept-Language: en > >MIME-Version: 1.0 > >To: msec@securemulticast.org > >Subject: Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt > >References: <200106271103.HAA26170@ietf.org> > >Content-Type: multipart/alternative; > > boundary="------------E7B7F4EE607BF84BF270BC1C" > > > >Mark, etal, > >Initial comments on the architecture -- > > > >1. Section 1. -- > >> > >>Extensions to IKE, however, are probably the best solution for IPsec > >>protocols over IP multicast services [GDOI]. > >The architecture document is not an appropriate place for blatant > >editorialisms. > > Answered in previous posting. > > >2. > >> > >>A "secure group" is a collection of principals, > >>called "members," who may be senders, receivers or both receivers and > >>senders to other members of the group. (Note that group membership may > >>vary over time.) A "group key management protocol" ensures that only > >>members of a secure group gain access to group data (by gaining access > >>to group keys) and can authenticate group data. > >A secure group is a group in which access to data is restricted to > >particular entities. This access can be of read and/or write access. In > >other words, a group may only have write restrictions and no read > >restrictions. While this access may be enforced with group keys, it is > >mandated by a policy that claims data will only be accepted from > >particular entities, which could also be enforced with signature keys. A > >key distribution protocol alone does not define a secure group. This > >really demands a _security management_ protocol that can manage keys and > >policy. > > There is nothing that you have written that is inconsistent with what we > wrote except that you really cannot implement the stuff about read or write > access when a symmetric key is used. A group member who receives encrypted > data can send it. There could be some policy processing at a host-member > to throw away messages based on authenticating sources and we address this > in the key management architecture. You write above that it "...could also > be enforced by signature keys" when in fact that's the only way it can be > enforced (though TESLA-like solutions can reduce the costs of asymmetric > crypto on a packet-by-packet basis). > > You assert that a "key distribution protocol alone does not define a secure > group" but this is a straw man: The draft does not say it does. > > Mark > > >3. > >> > >>4. The key-management protocol must be secure against man-in-the- > >> middle, connection-hijacking, and reflection/replay attacks; it must > >> use best-known practices to thwart denial-of-service attacks. > > > > > >And type attacks. And attacks resulting from lack of explicitness > >(mis-routed, mis-interpreted). And interleaved with other protocols > >(protocol-oracle), etc. Perhaps it would be better to generalize this > >statement. > > > >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." > > > >5. Re: video on demand example. The example shows a pre-existing group > >of all possible members subject to pre-broadcast rekey. One broadcast > >would destroy this property. > > > >6. > >> > >>A centralized > >>group controller (or KDC) that is used in this architecture may not be > >>the best design for small, interactive groups. But for large, single- > >>source multicast groups, it is generally undesirable to distribute key > >>management functions among group members: Unlike small, interactive > >>groups, large single-source multicast groups generally need a > >>specialized KDC to support large numbers of group members. Large > >>distributed simulations, moreover, may combine the need for large-grou > >>operation with many senders. > >Large groups require distributed initial key distribution! Large dynamic > >groups cannot rely upon a centralized KDC. This does not scale. This is > >highly inflexible. The VoD example demonstrates this. > > > >While the interactions with distributed rekey entities is more > >complicated, this functionality may be needed in composite multicast > >groups of limited scope. > > > >7. > >> > >>It may be that no > >>single key management protocol can satisfy the scalability requirements > >>of all group-security applications. This is for further study. > >It may be that the security protocols protecting group communications data > >cannot satisfy each of the possible sender/receiver profiles. This is > >less of a security management problem. > > > >8. > >> > >>This design is based upon a "group controller" model > >>[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group > >>owner as the root-of-trust. The group owner designates a key > >>distribution center for member registration and re-key. > >As was originally envisioned, the group owner CAN (and for large or sparse > >groups SHOULD) designate multiple key servers. > > > >9. Section 3.2 -- The term TEK is inappropriately specific. The group > >may not have encryption requirements, but only authentication. > > > >10. > >> > >>Only one SA is optional and that is the Re-key > >>SA. > > > > > >Actually, one policy for the Re-Key SA is that there is none. It is > >null. Explicitly stating this prevents confusion between missing SA info > >and optional SA info. Likewise, the registration protocol may involve > >manual methods. > > > >11. > >> > >>The KDC, moreover, can be delegated when the > >>trust infrastructure supports delegation to permit distributed > >>operation of the KDC. > >This statement, while correct, seems to conflict with the statement quoted > >in Comment #6. > > > >12. > >> > >>MSEC assumes that at least the following group-policy information is > >>externally managed. > >> o Group owner, authentication method, and delegation method for > >> identifying a KDC for the group > >> o Group KDC, authentication method, and any method used for > >> delegating other KDCs for the group > >> o Group membership rules or list and authentication method > > > > > >These assumptions are unnecessary as was shown by GSAKMP. > > I. While the group owner may be published externally, the group > > owner can also be disclosed during the registration protocol. It can be > > decided during this time whether the owner is acceptable prior to > > completion of registration. Once this occurs, authenticated group policy > > can be conveyed to the new member using traditional mechanisms such as > > digital signatures tied to a PKI. > > II. The delegation can be stated (authorized) through the > > authenticated policy statement as was done with GSAKMP. > > III. Ditto for membership rules and lists > > IV. The security association characteristics of the registration > > protocol can be determined early in the registration exchange or in > > almost all protocols (TLS, IPSec, GSAKMP, etc.) can be restricted by what > > properties the Key Server will accept using cipher suite restrictions, > > SPD constraints, etc. > > > > External management of these can be done, but should not be assumed > > in the architecture document. > > > >13. In general, this document contains very little new information. The > >framework for the architecture was already provided by the building block > >documents with the category 1,2, and 3 SAs. The architecture document > >should work toward providing interoperable solutions. > > > >--- Andrea Colegrove > > > > > > > >Internet-Drafts@ietf.org wrote: > >>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 : Group Key Management Architecture > >> Author(s) : M. Baugher, R. Canetti, L. Dondeti > >> Filename : draft-ietf-msec-gkmarch-00.txt > >> Pages : 22 > >> Date : 26-Jun-01 > >> > >>This document presents a group key-management architecture for MSEC. > >>The purpose of this document is to define the common architecture for > >>MSEC group key-management protocols that support a variety of > >>application, transport, and internetwork security protocols. To > >>address these diverse uses, MSEC may need to standardize two or more > >>group key management protocols that have common requirements, > >>abstractions, overall design, and messages. The framework and > >>guidelines in this document allow for a modular and flexible design of > >>group key management protocols for a variety different settings that > >>are specialized to application needs. > >> > >>A URL for this Internet-Draft is: > >>http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.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-gkmarch-00.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-gkmarch-00.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: <20010626132202.I-D@ietf.org> _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 27 21:06:31 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15674 for ; Wed, 27 Jun 2001 21:06:31 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6E02F53578; Wed, 27 Jun 2001 21:06: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 54F6453546 for ; Wed, 27 Jun 2001 21:05:56 -0400 (EDT) Received: (qmail 19123 invoked by uid 3269); 28 Jun 2001 01:05:55 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 19120 invoked from network); 28 Jun 2001 01:05:55 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 28 Jun 2001 01:05:55 -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 f5S14nh24845; Wed, 27 Jun 2001 18:04:49 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-615.cisco.com [10.21.66.103]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADG01339; Wed, 27 Jun 2001 18:04:48 -0700 (PDT) Message-Id: <4.3.2.7.2.20010627174400.0422be38@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Andrea Colegrove From: Mark Baugher Cc: msec@securemulticast.org, ipsec@lists.tislabs.com In-Reply-To: <3B3A6CDE.A29BA9A6@columbia.sparta.com> References: <4.3.2.7.2.20010627140639.04301090@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Re: [Fwd: I-D ACTION:draft-ietf-msec-gkmarch-00.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, 27 Jun 2001 18:04:18 -0700 Andrea I am a co-author of the GDOI spec and have written part of the spec. My co-authors have not given me any additional titles. I gave you a technical argument and you give me back an ad hominem when you state that my concerns are merely to promote another specification through the architecture document. I'm telling you that is not the case and we'll do well to keep focused on the technical issues and not pretend to be omniscient with respect to others' intentions. You should ask for your refund from the Mind Reading Institute. When an IETF working group is promoting two specifications that do the same function, then an explanation is in order. When the function is key management, then the key management architecture document is an appropriate place to do the explaining. The sentence that upsets you so much is the rationale for doing GDOI. We are doing GDOI because a majority of the working group want a solution that is consistent with IKE, or else find out why we cannot have that. We are doing GSAKMP because the working group also wants a solution that will work over security transports such as IPsec or SSL. So far, our experience with GDOI (third-party analysis and implementation experience) leads us to believe that modifications to the IKE standard to support group key management is a good solution. Mark At 07:31 PM 6/27/2001 -0400, Andrea Colegrove wrote: >Mark, > Since you are the primary author (editor?) of GDOI I am sure that you > feel GDOI is best. The architecture document, however, is not the >place to promote your solution. > Many feel that modifications to a standard to support multicast is > not a good solution. IKE is designed with certain assumptions which >hold for pairwise paradigms but not necessarily groups. > Also, because SPD and SAD values for a group cannot be completely > determined in advance and are more likely distributed as part of the >Join/Registration process, IKE will not likely be automatically fired off >anyway (analogous to PPKs). > Regardless of how you feel on this issue, it is inappropriate to > state that GDOI is probably the best solution at this point in general >and certainly not in the architecture document. > Wrt GSAKMP and separating out the "key management protocol": key > management involves more than distribution. > >--- Andrea > > > >Mark Baugher wrote: > > > Andrea > > I respond to your first point in this note. > > > > At 01:40 PM 6/27/2001 -0400, Andrea Colegrove wrote: > > > > >X-Mozilla-Status2: 00000000 > > >Message-ID: <3B3A1837.D95360C0@columbia.sparta.com> > > >Date: Wed, 27 Jun 2001 13:30:31 -0400 > > >From: Andrea Colegrove > > >X-Mailer: Mozilla 4.75 [en] (Win98; U) > > >X-Accept-Language: en > > >MIME-Version: 1.0 > > >To: msec@securemulticast.org > > >Subject: Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt > > >References: <200106271103.HAA26170@ietf.org> > > >Content-Type: multipart/alternative; > > > boundary="------------E7B7F4EE607BF84BF270BC1C" > > > > > >Mark, etal, > > >Initial comments on the architecture -- > > > > > >1. Section 1. -- > > >> > > >>Extensions to IKE, however, are probably the best solution for IPsec > > >>protocols over IP multicast services [GDOI]. > > >The architecture document is not an appropriate place for blatant > > >editorialisms. > > > > It is not as you say it is. I'll ignore the rudeness of this sentence and > > focus > > on the issue: It makes no sense to force AH and ESP to select a key > management > > application based on whether it has a unicast or a multicast destination > > address in > > the packet it is processing. One may want to do that, but extensions to > > IKE are probably > > the best solution for IPsec protocols over IP multicast services. This is > > an architectural > > issue for it involves multiple functional blocks (data security protocols > > and key > > management protocol) , and it is why msec will likely standardize an > IKE-based > > specification in addition to a something like GSAKMP (at least the key > > management > > protocol of it once that's separated out). > > > > I'll spare ipsec my comments on the rest of your points and post only > to msec. > > > > Mark > > > > >2. > > >> > > >>A "secure group" is a collection of principals, > > >>called "members," who may be senders, receivers or both receivers and > > >>senders to other members of the group. (Note that group membership may > > >>vary over time.) A "group key management protocol" ensures that only > > >>members of a secure group gain access to group data (by gaining access > > >>to group keys) and can authenticate group data. > > >A secure group is a group in which access to data is restricted to > > >particular entities. This access can be of read and/or write access. In > > >other words, a group may only have write restrictions and no read > > >restrictions. While this access may be enforced with group keys, it is > > >mandated by a policy that claims data will only be accepted from > > >particular entities, which could also be enforced with signature keys. A > > >key distribution protocol alone does not define a secure group. This > > >really demands a _security management_ protocol that can manage keys and > > >policy. > > > > > >3. > > >> > > >>4. The key-management protocol must be secure against man-in-the- > > >> middle, connection-hijacking, and reflection/replay attacks; it must > > >> use best-known practices to thwart denial-of-service attacks. > > > > > > > > >And type attacks. And attacks resulting from lack of explicitness > > >(mis-routed, mis-interpreted). And interleaved with other protocols > > >(protocol-oracle), etc. Perhaps it would be better to generalize this > > >statement. > > > > > >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." > > > > > >5. Re: video on demand example. The example shows a pre-existing group > > >of all possible members subject to pre-broadcast rekey. One broadcast > > >would destroy this property. > > > > > >6. > > >> > > >>A centralized > > >>group controller (or KDC) that is used in this architecture may not be > > >>the best design for small, interactive groups. But for large, single- > > >>source multicast groups, it is generally undesirable to distribute key > > >>management functions among group members: Unlike small, interactive > > >>groups, large single-source multicast groups generally need a > > >>specialized KDC to support large numbers of group members. Large > > >>distributed simulations, moreover, may combine the need for large-grou > > >>operation with many senders. > > >Large groups require distributed initial key distribution! Large dynamic > > >groups cannot rely upon a centralized KDC. This does not scale. This is > > >highly inflexible. The VoD example demonstrates this. > > > > > >While the interactions with distributed rekey entities is more > > >complicated, this functionality may be needed in composite multicast > > >groups of limited scope. > > > > > >7. > > >> > > >>It may be that no > > >>single key management protocol can satisfy the scalability requirements > > >>of all group-security applications. This is for further study. > > >It may be that the security protocols protecting group communications data > > >cannot satisfy each of the possible sender/receiver profiles. This is > > >less of a security management problem. > > > > > >8. > > >> > > >>This design is based upon a "group controller" model > > >>[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group > > >>owner as the root-of-trust. The group owner designates a key > > >>distribution center for member registration and re-key. > > >As was originally envisioned, the group owner CAN (and for large or sparse > > >groups SHOULD) designate multiple key servers. > > > > > >9. Section 3.2 -- The term TEK is inappropriately specific. The group > > >may not have encryption requirements, but only authentication. > > > > > >10. > > >> > > >>Only one SA is optional and that is the Re-key > > >>SA. > > > > > > > > >Actually, one policy for the Re-Key SA is that there is none. It is > > >null. Explicitly stating this prevents confusion between missing SA info > > >and optional SA info. Likewise, the registration protocol may involve > > >manual methods. > > > > > >11. > > >> > > >>The KDC, moreover, can be delegated when the > > >>trust infrastructure supports delegation to permit distributed > > >>operation of the KDC. > > >This statement, while correct, seems to conflict with the statement quoted > > >in Comment #6. > > > > > >12. > > >> > > >>MSEC assumes that at least the following group-policy information is > > >>externally managed. > > >> o Group owner, authentication method, and delegation method for > > >> identifying a KDC for the group > > >> o Group KDC, authentication method, and any method used for > > >> delegating other KDCs for the group > > >> o Group membership rules or list and authentication method > > > > > > > > >These assumptions are unnecessary as was shown by GSAKMP. > > > I. While the group owner may be published externally, the group > > > owner can also be disclosed during the registration protocol. It can be > > > decided during this time whether the owner is acceptable prior to > > > completion of registration. Once this occurs, authenticated group policy > > > can be conveyed to the new member using traditional mechanisms such as > > > digital signatures tied to a PKI. > > > II. The delegation can be stated (authorized) through the > > > authenticated policy statement as was done with GSAKMP. > > > III. Ditto for membership rules and lists > > > IV. The security association characteristics of the registration > > > protocol can be determined early in the registration exchange or in > > > almost all protocols (TLS, IPSec, GSAKMP, etc.) can be restricted by what > > > properties the Key Server will accept using cipher suite restrictions, > > > SPD constraints, etc. > > > > > > External management of these can be done, but should not be assumed > > > in the architecture document. > > > > > >13. In general, this document contains very little new information. The > > >framework for the architecture was already provided by the building block > > >documents with the category 1,2, and 3 SAs. The architecture document > > >should work toward providing interoperable solutions. > > > > > >--- Andrea Colegrove > > > > > > > > > > > >Internet-Drafts@ietf.org wrote: > > >>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 : Group Key Management Architecture > > >> Author(s) : M. Baugher, R. Canetti, L. Dondeti > > >> Filename : draft-ietf-msec-gkmarch-00.txt > > >> Pages : 22 > > >> Date : 26-Jun-01 > > >> > > >>This document presents a group key-management architecture for MSEC. > > >>The purpose of this document is to define the common architecture for > > >>MSEC group key-management protocols that support a variety of > > >>application, transport, and internetwork security protocols. To > > >>address these diverse uses, MSEC may need to standardize two or more > > >>group key management protocols that have common requirements, > > >>abstractions, overall design, and messages. The framework and > > >>guidelines in this document allow for a modular and flexible design of > > >>group key management protocols for a variety different settings that > > >>are specialized to application needs. > > >> > > >>A URL for this Internet-Draft is: > > >>ht > tp://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.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-gkmarch-00.txt". > > >> > > >>A list of Internet-Drafts directories can be found in > > >>http://www.ietf.org/shadow.html > > >>or > > >>ftp://ftp.ietf.org/ietf/1sh > adow-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-gkmarch-00.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: <20010626132202.I-D@ietf.org> _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 27 23:21:18 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20628 for ; Wed, 27 Jun 2001 23:21:18 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A91C35367D; Wed, 27 Jun 2001 23:20: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 1F2105367C for ; Wed, 27 Jun 2001 23:19:23 -0400 (EDT) Received: (qmail 32217 invoked by uid 3269); 28 Jun 2001 03:19:22 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 32214 invoked from network); 28 Jun 2001 03:19:22 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 28 Jun 2001 03:19:22 -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 f5S3Itx26873; Wed, 27 Jun 2001 20:18:55 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-615.cisco.com [10.21.66.103]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADG03122; Wed, 27 Jun 2001 20:18:45 -0700 (PDT) Message-Id: <4.3.2.7.2.20010627200947.042e3ae0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Andrea Colegrove From: Mark Baugher Cc: msec@securemulticast.org In-Reply-To: <3B3A6F6B.86E65004@columbia.sparta.com> References: <4.3.2.7.2.20010627153746.042fef90@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Re: [Fwd: I-D ACTION:draft-ietf-msec-gkmarch-00.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, 27 Jun 2001 20:18:15 -0700 At 07:42 PM 6/27/2001 -0400, Andrea Colegrove wrote: >Mark, > Clearly sending and writing are different. To write info to a group, > possession of a symmetric authentication key may be required. >Yes, anyone can read it (if it isn't encrypted) and send it on, but only >group members can generate authentic data and have it be accepted >by other group members. > I would have been clearer had I said "a key management protocol alone > does not grow secure groups -- security management is needed >because the issues needing management are larger than just the keys." That's a very good point. I don't know what to do with it, however, since it's a point about something called "security management." We're discussing key management in the I-D, not security management. If someone were to write an I-D about "group security management," then I'd take the time to read it. Mark >--- Andrea > >Mark Baugher wrote: > > > Andrea > > I comment on your second point in this note. > > > > At 01:40 PM 6/27/2001 -0400, Andrea Colegrove wrote: > > > > >X-Mozilla-Status2: 00000000 > > >Message-ID: <3B3A1837.D95360C0@columbia.sparta.com> > > >Date: Wed, 27 Jun 2001 13:30:31 -0400 > > >From: Andrea Colegrove > > >X-Mailer: Mozilla 4.75 [en] (Win98; U) > > >X-Accept-Language: en > > >MIME-Version: 1.0 > > >To: msec@securemulticast.org > > >Subject: Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt > > >References: <200106271103.HAA26170@ietf.org> > > >Content-Type: multipart/alternative; > > > boundary="------------E7B7F4EE607BF84BF270BC1C" > > > > > >Mark, etal, > > >Initial comments on the architecture -- > > > > > >1. Section 1. -- > > >> > > >>Extensions to IKE, however, are probably the best solution for IPsec > > >>protocols over IP multicast services [GDOI]. > > >The architecture document is not an appropriate place for blatant > > >editorialisms. > > > > Answered in previous posting. > > > > >2. > > >> > > >>A "secure group" is a collection of principals, > > >>called "members," who may be senders, receivers or both receivers and > > >>senders to other members of the group. (Note that group membership may > > >>vary over time.) A "group key management protocol" ensures that only > > >>members of a secure group gain access to group data (by gaining access > > >>to group keys) and can authenticate group data. > > >A secure group is a group in which access to data is restricted to > > >particular entities. This access can be of read and/or write access. In > > >other words, a group may only have write restrictions and no read > > >restrictions. While this access may be enforced with group keys, it is > > >mandated by a policy that claims data will only be accepted from > > >particular entities, which could also be enforced with signature keys. A > > >key distribution protocol alone does not define a secure group. This > > >really demands a _security management_ protocol that can manage keys and > > >policy. > > > > There is nothing that you have written that is inconsistent with what we > > wrote except that you really cannot implement the stuff about read or write > > access when a symmetric key is used. A group member who receives encrypted > > data can send it. There could be some policy processing at a host-member > > to throw away messages based on authenticating sources and we address this > > in the key management architecture. You write above that it "...could also > > be enforced by signature keys" when in fact that's the only way it can be > > enforced (though TESLA-like solutions can reduce the costs of asymmetric > > crypto on a packet-by-packet basis). > > > > You assert that a "key distribution protocol alone does not define a secure > > group" but this is a straw man: The draft does not say it does. > > > > Mark > > > > >3. > > >> > > >>4. The key-management protocol must be secure against man-in-the- > > >> middle, connection-hijacking, and reflection/replay attacks; it must > > >> use best-known practices to thwart denial-of-service attacks. > > > > > > > > >And type attacks. And attacks resulting from lack of explicitness > > >(mis-routed, mis-interpreted). And interleaved with other protocols > > >(protocol-oracle), etc. Perhaps it would be better to generalize this > > >statement. > > > > > >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." > > > > > >5. Re: video on demand example. The example shows a pre-existing group > > >of all possible members subject to pre-broadcast rekey. One broadcast > > >would destroy this property. > > > > > >6. > > >> > > >>A centralized > > >>group controller (or KDC) that is used in this architecture may not be > > >>the best design for small, interactive groups. But for large, single- > > >>source multicast groups, it is generally undesirable to distribute key > > >>management functions among group members: Unlike small, interactive > > >>groups, large single-source multicast groups generally need a > > >>specialized KDC to support large numbers of group members. Large > > >>distributed simulations, moreover, may combine the need for large-grou > > >>operation with many senders. > > >Large groups require distributed initial key distribution! Large dynamic > > >groups cannot rely upon a centralized KDC. This does not scale. This is > > >highly inflexible. The VoD example demonstrates this. > > > > > >While the interactions with distributed rekey entities is more > > >complicated, this functionality may be needed in composite multicast > > >groups of limited scope. > > > > > >7. > > >> > > >>It may be that no > > >>single key management protocol can satisfy the scalability requirements > > >>of all group-security applications. This is for further study. > > >It may be that the security protocols protecting group communications data > > >cannot satisfy each of the possible sender/receiver profiles. This is > > >less of a security management problem. > > > > > >8. > > >> > > >>This design is based upon a "group controller" model > > >>[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group > > >>owner as the root-of-trust. The group owner designates a key > > >>distribution center for member registration and re-key. > > >As was originally envisioned, the group owner CAN (and for large or sparse > > >groups SHOULD) designate multiple key servers. > > > > > >9. Section 3.2 -- The term TEK is inappropriately specific. The group > > >may not have encryption requirements, but only authentication. > > > > > >10. > > >> > > >>Only one SA is optional and that is the Re-key > > >>SA. > > > > > > > > >Actually, one policy for the Re-Key SA is that there is none. It is > > >null. Explicitly stating this prevents confusion between missing SA info > > >and optional SA info. Likewise, the registration protocol may involve > > >manual methods. > > > > > >11. > > >> > > >>The KDC, moreover, can be delegated when the > > >>trust infrastructure supports delegation to permit distributed > > >>operation of the KDC. > > >This statement, while correct, seems to conflict with the statement quoted > > >in Comment #6. > > > > > >12. > > >> > > >>MSEC assumes that at least the following group-policy information is > > >>externally managed. > > >> o Group owner, authentication method, and delegation method for > > >> identifying a KDC for the group > > >> o Group KDC, authentication method, and any method used for > > >> delegating other KDCs for the group > > >> o Group membership rules or list and authentication method > > > > > > > > >These assumptions are unnecessary as was shown by GSAKMP. > > > I. While the group owner may be published externally, the group > > > owner can also be disclosed during the registration protocol. It can be > > > decided during this time whether the owner is acceptable prior to > > > completion of registration. Once this occurs, authenticated group policy > > > can be conveyed to the new member using traditional mechanisms such as > > > digital signatures tied to a PKI. > > > II. The delegation can be stated (authorized) through the > > > authenticated policy statement as was done with GSAKMP. > > > III. Ditto for membership rules and lists > > > IV. The security association characteristics of the registration > > > protocol can be determined early in the registration exchange or in > > > almost all protocols (TLS, IPSec, GSAKMP, etc.) can be restricted by what > > > properties the Key Server will accept using cipher suite restrictions, > > > SPD constraints, etc. > > > > > > External management of these can be done, but should not be assumed > > > in the architecture document. > > > > > >13. In general, this document contains very little new information. The > > >framework for the architecture was already provided by the building block > > >documents with the category 1,2, and 3 SAs. The architecture document > > >should work toward providing interoperable solutions. > > > > > >--- Andrea Colegrove > > > > > > > > > > > >Internet-Drafts@ietf.org wrote: > > >>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 : Group Key Management Architecture > > >> Author(s) : M. Baugher, R. Canetti, L. Dondeti > > >> Filename : draft-ietf-msec-gkmarch-00.txt > > >> Pages : 22 > > >> Date : 26-Jun-01 > > >> > > >>This document presents a group key-management architecture for MSEC. > > >>The purpose of this document is to define the common architecture for > > >>MSEC group key-management protocols that support a variety of > > >>application, transport, and internetwork security protocols. To > > >>address these diverse uses, MSEC may need to standardize two or more > > >>group key management protocols that have common requirements, > > >>abstractions, overall design, and messages. The framework and > > >>guidelines in this document allow for a modular and flexible design of > > >>group key management protocols for a variety different settings that > > >>are specialized to application needs. > > >> > > >>A URL for this Internet-Draft is: > > >>ht > tp://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.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-gkmarch-00.txt". > > >> > > >>A list of Internet-Drafts directories can be found in > > >>http://www.ietf.org/shadow.html > > >>or > > >>ftp://ftp.ietf.org/ietf/1sh > adow-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-gkmarch-00.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: <20010626132202.I-D@ietf.org> _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jun 28 01:19:53 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23580 for ; Thu, 28 Jun 2001 01:19:52 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 5BCAB53665; Thu, 28 Jun 2001 01:20: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 DB64053566 for ; Thu, 28 Jun 2001 01:18:11 -0400 (EDT) Received: (qmail 42105 invoked by uid 3269); 28 Jun 2001 05:18:11 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 42102 invoked from network); 28 Jun 2001 05:18:10 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 28 Jun 2001 05:18:10 -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 f5S5Hhx09252; Wed, 27 Jun 2001 22:17:43 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-615.cisco.com [10.21.66.103]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADG04023; Wed, 27 Jun 2001 22:17:33 -0700 (PDT) Message-Id: <4.3.2.7.2.20010627202552.0433d4c8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Andrea Colegrove From: Mark Baugher Subject: Re: [MSEC] Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt Cc: msec@securemulticast.org In-Reply-To: <3B3A1837.D95360C0@columbia.sparta.com> References: <200106271103.HAA26170@ietf.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_52608076==_.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: Wed, 27 Jun 2001 22:17:01 -0700 --=====================_52608076==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Andrea I'll work through the points and suggest possible compromises to address your concerns. At 01:30 PM 6/27/2001 -0400, Andrea Colegrove wrote: >Mark, etal, >Initial comments on the architecture -- > >1. Section 1. -- >> >> >>Extensions to IKE, however, are probably the best solution for IPsec >>protocols over IP multicast services [GDOI]. >The architecture document is not an appropriate place for blatant >editorialisms. How about if we change the offending paragraph as follows: security services. For these reasons, application, transport, and internetwork-layer security protocols such as SRTP, IPsec, and AMESP may benefit from using different group key management systems [GSAKMP, GDOI]. Extensions to IKE, however, are probably the best solution for IPsec protocols over IP multicast services [GDOI]. The purpose of this >2. >> >> >>A "secure group" is a collection of principals, >>called "members," who may be senders, receivers or both receivers and >>senders to other members of the group. (Note that group membership may >>vary over time.) A "group key management protocol" ensures that only >>members of a secure group gain access to group data (by gaining access >>to group keys) and can authenticate group data. >A secure group is a group in which access to data is restricted to >particular entities. This access can be of read and/or write access. In >other words, a group may only have write restrictions and no read >restrictions. While this access may be enforced with group keys, it is >mandated by a policy that claims data will only be accepted from >particular entities, which could also be enforced with signature keys. A >key distribution protocol alone does not define a secure group. This >really demands a _security management_ protocol that can manage keys and >policy. I'm looking forward to the I-D on security management protocols and prefer to stick to key management protocols in this I-D >3. >> >> >>4. The key-management protocol must be secure against man-in-the- >> middle, connection-hijacking, and reflection/replay attacks; it must >> use best-known practices to thwart denial-of-service attacks. > > >And type attacks. And attacks resulting from lack of explicitness >(mis-routed, mis-interpreted). And interleaved with other protocols >(protocol-oracle), etc. Perhaps it would be better to generalize this >statement. Would you please provide references for these attacks? >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." Not in IKE it isn't. Again, I await the I-D on the security management protocol. >5. Re: video on demand example. The example shows a pre-existing group >of all possible members subject to pre-broadcast rekey. One broadcast >would destroy this property. What is the property that would be destroyed? What exactly is the problem? >6. >> >> >>A centralized >>group controller (or KDC) that is used in this architecture may not be >>the best design for small, interactive groups. But for large, single- >>source multicast groups, it is generally undesirable to distribute key >>management functions among group members: Unlike small, interactive >>groups, large single-source multicast groups generally need a >>specialized KDC to support large numbers of group members. Large >>distributed simulations, moreover, may combine the need for large-grou >>operation with many senders. >Large groups require distributed initial key distribution! Large dynamic >groups cannot rely upon a centralized KDC. This does not scale. This is >highly inflexible. The VoD example demonstrates this. Please refer to the following sections of draft-ietf-msec-gkmarch-00.txt: Section 3.2, Detailed Design, where we discuss delegation; Section 3.3, Properties of the Design; Section 3.4, first paragraph where the word "delegation" appears; 4.1, Predistributed Group Policy where we discuss delegation; and Section 5.0, Scalability Considerations. You are citing the Requirements discussion and not the Design features proposed in our draft. >While the interactions with distributed rekey entities is more >complicated, this functionality may be needed in composite multicast >groups of limited scope. This is discussed in the I-D under Section 5.0. >7. >> >> >>It may be that no >>single key management protocol can satisfy the scalability requirements >>of all group-security applications. This is for further study. >It may be that the security protocols protecting group communications data >cannot satisfy each of the possible sender/receiver profiles. This is >less of a security management problem. > >8. >> >> >>This design is based upon a "group controller" model >>[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group >>owner as the root-of-trust. The group owner designates a key >>distribution center for member registration and re-key. >As was originally envisioned, the group owner CAN (and for large or sparse >groups SHOULD) designate multiple key servers. The architecture recommends that this be done by allowing any key server to serve keys that is authorized to do so by the group owner. The most straightforward way to do this is to use SPKI or X.509 delegation. That's what we are recommending rather than coding this up in the key management protocol. >9. Section 3.2 -- The term TEK is inappropriately specific. The group >may not have encryption requirements, but only authentication. TEK has a long history in the group key management literature. But you have a point, it may not be needed for authentication. We need to review this. >10. >> >> >>Only one SA is optional and that is the Re-key >>SA. > > >Actually, one policy for the Re-Key SA is that there is none. It is >null. Explicitly stating this prevents confusion between missing SA info >and optional SA info. Likewise, the registration protocol may involve >manual methods. That sounds okay to me. >11. >> >> >>The KDC, moreover, can be delegated when the >>trust infrastructure supports delegation to permit distributed >>operation of the KDC. >This statement, while correct, seems to conflict with the statement quoted >in Comment #6. Comment #6 was citing a requirements discussion. now we are into design. There are ways to load balance, get high-availability, and get fault tolerance for a server without inventing distributed key server protocols (such as a leader election algorithm, inter-KDC protocols). >12. >> >> >>MSEC assumes that at least the following group-policy information is >>externally managed. >> o Group owner, authentication method, and delegation method for >> identifying a KDC for the group >> o Group KDC, authentication method, and any method used for >> delegating other KDCs for the group >> o Group membership rules or list and authentication method > > >These assumptions are unnecessary as was shown by GSAKMP. These assumptions were put into the GDOI draft at Hugh's behest and it helped clarify our thinking on how to minimize group policy functions in key management. I recommended to Ran and Lakshminath that we consider including these assumptions in the GKM architecture I-D. They agreed and Lakshminath did that. If we don't do that, then we will encumber the key management specification with a lot of policy issues that the working group has agreed belonged in a policy draft. You may not agree with everything the WG decides to do. WGs are like that. > I. While the group owner may be published externally, the group > owner can also be disclosed during the registration protocol. It can be > decided during this time whether the owner is acceptable prior to > completion of registration. Once this occurs, authenticated group policy > can be conveyed to the new member using traditional mechanisms such as > digital signatures tied to a PKI. > II. The delegation can be stated (authorized) through the > authenticated policy statement as was done with GSAKMP. > III. Ditto for membership rules and lists > IV. The security association characteristics of the registration > protocol can be determined early in the registration exchange or in > almost all protocols (TLS, IPSec, GSAKMP, etc.) can be restricted by what > properties the Key Server will accept using cipher suite restrictions, > SPD constraints, etc. > > External management of these can be done, but should not be assumed > in the architecture document. > >13. In general, this document contains very little new information. The >framework for the architecture was already provided by the building block >documents with the category 1,2, and 3 SAs. The architecture document >should work toward providing interoperable solutions. We're not shooting for novelty here. Quite the contrary. The I-D is to progress as a product of the msec WG in order to bring two or more key management protocols to address common requirements, use common abstractions, and messages. These two or more protocols cannot interoperate unless they at least use a common header. GDOI uses an ISAKMP header for obvious reasons. GSAKMP does not use an ISAKMP header. If they could interoperate, then we would not go to the trouble of specifying two or more key management protocols. Mark >--- Andrea Colegrove > > > >Internet-Drafts@ietf.org wrote: >>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 : Group Key Management Architecture >> Author(s) : M. Baugher, R. Canetti, L. Dondeti >> Filename : draft-ietf-msec-gkmarch-00.txt >> Pages : 22 >> Date : 26-Jun-01 >> >>This document presents a group key-management architecture for MSEC. >>The purpose of this document is to define the common architecture for >>MSEC group key-management protocols that support a variety of >>application, transport, and internetwork security protocols. To >>address these diverse uses, MSEC may need to standardize two or more >>group key management protocols that have common requirements, >>abstractions, overall design, and messages. The framework and >>guidelines in this document allow for a modular and flexible design of >>group key management protocols for a variety different settings that >>are specialized to application needs. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.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-gkmarch-00.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-gkmarch-00.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: <20010626132202.I-D@ietf.org> --=====================_52608076==_.ALT Content-Type: text/html; charset="us-ascii" Andrea
   I'll work through the points and suggest possible compromises to address your concerns.

At 01:30 PM 6/27/2001 -0400, Andrea Colegrove wrote:
Mark, etal,
Initial comments on the architecture --

1.  Section 1. -- 


Extensions to IKE, however, are probably the best solution for IPsec 
protocols over IP multicast services
[GDOI].
The architecture document is not an appropriate place for blatant editorialisms.

How about if we change the offending paragraph as follows:
security services.  For these reasons, application, transport, and internetwork-layer security protocols such as SRTP, IPsec, and AMESP may benefit from using different group key management systems [GSAKMP, GDOI]. Extensions to IKE, however, are probably the best solution for IPsec protocols over IP multicast services [GDOI].  The purpose of this


2. 


A "secure group" is a collection of principals, 
called "members," who may be senders, receivers or both
receivers and 
senders to other members of the group. (Note that group membership may 
vary over time.) A "group key management protocol" ensures that
only 
members of a secure group gain access to group data (by gaining access 
to group keys) and can authenticate group
data.
A secure group is a group in which access to data is restricted to particular entities.  This access can be of read and/or write access.  In other words, a group may only have write restrictions and no read restrictions.  While this access may be enforced with group keys, it is mandated by a policy that claims data will only be accepted from particular entities, which could also be enforced with signature keys.  A key distribution protocol alone does not define a secure group.  This really demands a _security management_ protocol that can manage keys and policy.

I'm looking forward to the I-D on security management protocols and prefer to stick to key management protocols in this I-D


3. 


4. The key-management protocol must be secure against man-in-the-
   middle, connection-hijacking, and reflection/replay attacks;
it must
   use best-known practices to thwart denial-of-service
attacks.


And type attacks.  And attacks resulting from lack of explicitness (mis-routed, mis-interpreted).  And interleaved with other protocols (protocol-oracle), etc.  Perhaps it would be better to generalize this statement.

Would you please provide references for these attacks?


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."

Not in IKE it isn't.  Again, I await the I-D on the security management protocol.


5.  Re:  video on demand example.   The example shows a pre-existing group of all possible members subject to pre-broadcast rekey.  One broadcast would destroy this property.

What is the property that would be destroyed?  What exactly is the problem?


6. 


A centralized
group controller (or KDC) that is used in this architecture may not be 
the best design for small, interactive groups.  But for large,
single-
source multicast groups, it is generally undesirable to distribute key 
management functions among group members: Unlike small, interactive 
groups, large single-source multicast groups generally need a 
specialized KDC to support large numbers of group members.  Large 
distributed simulations, moreover, may combine the need for large-grou 
operation with many
senders.
Large groups require distributed initial key distribution!  Large dynamic groups cannot rely upon a centralized KDC.  This does not scale.  This is highly inflexible.  The VoD example demonstrates this.

Please refer to the following sections of draft-ietf-msec-gkmarch-00.txt: Section 3.2, Detailed Design, where we discuss delegation; Section 3.3, Properties of the Design; Section 3.4, first paragraph where the word "delegation" appears; 4.1, Predistributed Group Policy where we discuss delegation;  and Section 5.0, Scalability Considerations.  You are citing the Requirements discussion and not the Design features proposed in our draft.


While the interactions with distributed rekey entities is more complicated, this functionality may be needed in composite multicast groups of limited scope.

This is discussed in the I-D under Section 5.0.


7. 


It may be that no 
single key management protocol can satisfy the scalability requirements
of all group-security applications.  This is for further
study.
It may be that the security protocols protecting group communications data cannot satisfy each of the possible sender/receiver profiles.  This is less of a security management problem.

8. 


This design is based upon a "group controller" model 
[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group 
owner as the root-of-trust.  The group owner designates a key 
distribution center for member registration and
re-key.
As was originally envisioned, the group owner CAN (and for large or sparse groups SHOULD) designate multiple key servers.

The architecture recommends that this be done by allowing any key server to serve keys that is authorized to do so by the group owner.  The most straightforward way to do this is to use SPKI or X.509 delegation.  That's what we are recommending rather than coding this up in the key management protocol.


9.  Section 3.2 -- The term TEK is inappropriately specific.  The group may not have encryption requirements, but only authentication.

TEK has a long history in the group key management literature.  But you have a point, it may not be needed for authentication.  We need to review this. 


10. 


Only one SA is optional and that is the Re-key 
SA.


Actually, one policy for the Re-Key SA is that there is none.  It is null.  Explicitly stating this prevents confusion between missing SA info and optional SA info.  Likewise, the registration protocol may involve manual methods.

That sounds okay to me.


11. 


The KDC, moreover, can be delegated when the 
trust infrastructure supports delegation to permit distributed 
operation of the
KDC.
This statement, while correct, seems to conflict with the statement quoted in Comment #6.

Comment #6 was citing a requirements discussion.  now we are into design.  There are ways to load balance, get high-availability, and get fault tolerance for a server without inventing distributed key server protocols (such as a leader election algorithm, inter-KDC protocols).


12. 


MSEC assumes that at least the following group-policy information
is
externally managed.
  o Group owner, authentication method, and delegation method for 
    identifying a KDC for the group
  o Group KDC, authentication method, and any method used for
    delegating other KDCs for the group
  o Group membership rules or list and authentication
method


These assumptions are unnecessary as was shown by GSAKMP.

These assumptions were put into the GDOI draft at Hugh's behest and it helped clarify our thinking on how to minimize group policy functions in key management.   I recommended to Ran and Lakshminath that we consider including these assumptions in the GKM architecture I-D.  They agreed and Lakshminath did that.  If we don't do that, then we will encumber the key management specification with a lot of policy issues that the working group has agreed belonged in a policy draft.  You may not agree with everything the WG decides to do.  WGs are like that.

    I.  While the group owner may be published externally, the group owner can also be disclosed during the registration protocol.  It can be decided during this time whether the owner is acceptable prior to completion of registration.  Once this occurs, authenticated group policy can be conveyed to the new member using traditional mechanisms such as digital signatures tied to a PKI.
    II.  The delegation can be stated (authorized) through the authenticated policy statement as was done with GSAKMP.
    III.  Ditto for membership rules and lists
    IV.  The security association characteristics of the registration protocol can be determined early in the registration exchange or in almost all protocols (TLS, IPSec, GSAKMP, etc.) can be restricted by what properties the Key Server will accept using cipher suite restrictions, SPD constraints, etc.

    External management of these can be done, but should not be assumed in the architecture document.

13.  In general, this document contains very little new information.  The framework for the architecture was already provided by the building block documents with the category 1,2, and 3 SAs.  The architecture document should work toward providing interoperable solutions.

We're not shooting for novelty here.  Quite the contrary.  The I-D is to progress as a product of the msec WG in order to bring two or more key management protocols to address common requirements, use common abstractions, and messages.  These two or more protocols cannot interoperate unless they at least use a common header.  GDOI uses an ISAKMP header for obvious reasons.  GSAKMP does not use an ISAKMP header. If they could interoperate, then we would not go to the trouble of specifying two or more key management protocols.

Mark


--- Andrea Colegrove
 
 

Internet-Drafts@ietf.org wrote:
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           : Group Key Management Architecture
        Author(s)       : M. Baugher, R. Canetti, L. Dondeti
        Filename        : draft-ietf-msec-gkmarch-00.txt
        Pages           : 22
        Date            : 26-Jun-01

This document presents a group key-management architecture for MSEC.
The purpose of this document is to define the common architecture for
MSEC group key-management protocols that support a variety of
application, transport, and internetwork security protocols.  To
address these diverse uses, MSEC may need to standardize two or more
group key management protocols that have common requirements,
abstractions, overall design, and messages. The framework and
guidelines in this document allow for a modular and flexible design of
group key management protocols for a variety different settings that
are specialized to application needs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.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-gkmarch-00.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-gkmarch-00.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:     <20010626132202.I-D@ietf.org>
--=====================_52608076==_.ALT-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jun 28 13:35:34 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22269 for ; Thu, 28 Jun 2001 13:35:33 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4DFF653622; Thu, 28 Jun 2001 13:35: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 C9A7153599 for ; Thu, 28 Jun 2001 13:06:22 -0400 (EDT) Received: (qmail 40646 invoked by uid 3269); 28 Jun 2001 17:06:22 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 40643 invoked from network); 28 Jun 2001 17:06:21 -0000 Received: from m5.sparta.com (root@157.185.61.1) by klesh.pair.com with SMTP; 28 Jun 2001 17:06:21 -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 f5SH6Kx30296 for ; Thu, 28 Jun 2001 12:06:20 -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 NAA25934 for ; Thu, 28 Jun 2001 13:06:19 -0400 (EDT) Message-ID: <3B3B63FE.D14F0098@columbia.sparta.com> From: Andrea Colegrove X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: multipart/mixed; boundary="------------BB03ADFFEF41DC8ADE2FEB6F" Subject: [MSEC] [Fwd: [Fwd: I-D ACTION:draft-ietf-msec-gkmarch-00.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: Thu, 28 Jun 2001 13:06:06 -0400 This is a multi-part message in MIME format. --------------BB03ADFFEF41DC8ADE2FEB6F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------BB03ADFFEF41DC8ADE2FEB6F Content-Type: message/rfc822 Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <3B3B628F.6808C25C@columbia.sparta.com> Date: Thu, 28 Jun 2001 12:59:59 -0400 From: Andrea Colegrove X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Baugher Subject: Re: [Fwd: I-D ACTION:draft-ietf-msec-gkmarch-00.txt] References: <4.3.2.7.2.20010627140639.04301090@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010627174400.0422be38@mira-sjc5-6.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark, The architecture document is for specification and discussion of technical issues -- not opinion -- that is the issue at hand. The document has been written as a summary of the BBs with additional constraints and assumptions that are not necessary except that GDOI seems to make these assumptions. This is a fairness issue. The "title" of editor sometimes seems more appropriate as the specifications that are on standards track should reflect the combined interests of the working group -- it is not intended to be honorary or to detract, but merely a reflection of the responsibilities of the writers of the documents. I, too, gave technical arguments as to why GDOI may not be the perfect fit. It is not a bad solution, but let us also leave room for the ACME Group Security Management Protocol which Joe Schmo has yet to specify. --- Andrea Mark Baugher wrote: > Andrea > I am a co-author of the GDOI spec and have written part of the spec. My > co-authors have not given me any additional titles. > > I gave you a technical argument and you give me back an ad hominem when > you state that my concerns are merely to promote another specification > through the architecture document. I'm telling you that is not the case > and we'll do well to keep focused on the technical issues and not pretend > to be omniscient with respect to others' intentions. You should ask for > your refund from the Mind Reading Institute. > > When an IETF working group is promoting two specifications that do the > same function, then an explanation is in order. When the function is key > management, then the key management architecture document is an appropriate > place to do the explaining. The sentence that upsets you so much is the > rationale for doing GDOI. We are doing GDOI because a majority of the > working group want a solution that is consistent with IKE, or else find out > why we cannot have that. We are doing GSAKMP because the working group > also wants a solution that will work over security transports such as IPsec > or SSL. So far, our experience with GDOI (third-party analysis and > implementation experience) leads us to believe that modifications to the > IKE standard to support group key management is a good solution. > > Mark > > At 07:31 PM 6/27/2001 -0400, Andrea Colegrove wrote: > >Mark, > > Since you are the primary author (editor?) of GDOI I am sure that you > > feel GDOI is best. The architecture document, however, is not the > >place to promote your solution. > > Many feel that modifications to a standard to support multicast is > > not a good solution. IKE is designed with certain assumptions which > >hold for pairwise paradigms but not necessarily groups. > > Also, because SPD and SAD values for a group cannot be completely > > determined in advance and are more likely distributed as part of the > >Join/Registration process, IKE will not likely be automatically fired off > >anyway (analogous to PPKs). > > Regardless of how you feel on this issue, it is inappropriate to > > state that GDOI is probably the best solution at this point in general > >and certainly not in the architecture document. > > Wrt GSAKMP and separating out the "key management protocol": key > > management involves more than distribution. > > > >--- Andrea > > > > > > > >Mark Baugher wrote: > > > > > Andrea > > > I respond to your first point in this note. > > > > > > At 01:40 PM 6/27/2001 -0400, Andrea Colegrove wrote: > > > > > > >X-Mozilla-Status2: 00000000 > > > >Message-ID: <3B3A1837.D95360C0@columbia.sparta.com> > > > >Date: Wed, 27 Jun 2001 13:30:31 -0400 > > > >From: Andrea Colegrove > > > >X-Mailer: Mozilla 4.75 [en] (Win98; U) > > > >X-Accept-Language: en > > > >MIME-Version: 1.0 > > > >To: msec@securemulticast.org > > > >Subject: Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt > > > >References: <200106271103.HAA26170@ietf.org> > > > >Content-Type: multipart/alternative; > > > > boundary="------------E7B7F4EE607BF84BF270BC1C" > > > > > > > >Mark, etal, > > > >Initial comments on the architecture -- > > > > > > > >1. Section 1. -- > > > >> > > > >>Extensions to IKE, however, are probably the best solution for IPsec > > > >>protocols over IP multicast services [GDOI]. > > > >The architecture document is not an appropriate place for blatant > > > >editorialisms. > > > > > > It is not as you say it is. I'll ignore the rudeness of this sentence and > > > focus > > > on the issue: It makes no sense to force AH and ESP to select a key > > management > > > application based on whether it has a unicast or a multicast destination > > > address in > > > the packet it is processing. One may want to do that, but extensions to > > > IKE are probably > > > the best solution for IPsec protocols over IP multicast services. This is > > > an architectural > > > issue for it involves multiple functional blocks (data security protocols > > > and key > > > management protocol) , and it is why msec will likely standardize an > > IKE-based > > > specification in addition to a something like GSAKMP (at least the key > > > management > > > protocol of it once that's separated out). > > > > > > I'll spare ipsec my comments on the rest of your points and post only > > to msec. > > > > > > Mark > > > > > > >2. > > > >> > > > >>A "secure group" is a collection of principals, > > > >>called "members," who may be senders, receivers or both receivers and > > > >>senders to other members of the group. (Note that group membership may > > > >>vary over time.) A "group key management protocol" ensures that only > > > >>members of a secure group gain access to group data (by gaining access > > > >>to group keys) and can authenticate group data. > > > >A secure group is a group in which access to data is restricted to > > > >particular entities. This access can be of read and/or write access. In > > > >other words, a group may only have write restrictions and no read > > > >restrictions. While this access may be enforced with group keys, it is > > > >mandated by a policy that claims data will only be accepted from > > > >particular entities, which could also be enforced with signature keys. A > > > >key distribution protocol alone does not define a secure group. This > > > >really demands a _security management_ protocol that can manage keys and > > > >policy. > > > > > > > >3. > > > >> > > > >>4. The key-management protocol must be secure against man-in-the- > > > >> middle, connection-hijacking, and reflection/replay attacks; it must > > > >> use best-known practices to thwart denial-of-service attacks. > > > > > > > > > > > >And type attacks. And attacks resulting from lack of explicitness > > > >(mis-routed, mis-interpreted). And interleaved with other protocols > > > >(protocol-oracle), etc. Perhaps it would be better to generalize this > > > >statement. > > > > > > > >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." > > > > > > > >5. Re: video on demand example. The example shows a pre-existing group > > > >of all possible members subject to pre-broadcast rekey. One broadcast > > > >would destroy this property. > > > > > > > >6. > > > >> > > > >>A centralized > > > >>group controller (or KDC) that is used in this architecture may not be > > > >>the best design for small, interactive groups. But for large, single- > > > >>source multicast groups, it is generally undesirable to distribute key > > > >>management functions among group members: Unlike small, interactive > > > >>groups, large single-source multicast groups generally need a > > > >>specialized KDC to support large numbers of group members. Large > > > >>distributed simulations, moreover, may combine the need for large-grou > > > >>operation with many senders. > > > >Large groups require distributed initial key distribution! Large dynamic > > > >groups cannot rely upon a centralized KDC. This does not scale. This is > > > >highly inflexible. The VoD example demonstrates this. > > > > > > > >While the interactions with distributed rekey entities is more > > > >complicated, this functionality may be needed in composite multicast > > > >groups of limited scope. > > > > > > > >7. > > > >> > > > >>It may be that no > > > >>single key management protocol can satisfy the scalability requirements > > > >>of all group-security applications. This is for further study. > > > >It may be that the security protocols protecting group communications data > > > >cannot satisfy each of the possible sender/receiver profiles. This is > > > >less of a security management problem. > > > > > > > >8. > > > >> > > > >>This design is based upon a "group controller" model > > > >>[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group > > > >>owner as the root-of-trust. The group owner designates a key > > > >>distribution center for member registration and re-key. > > > >As was originally envisioned, the group owner CAN (and for large or sparse > > > >groups SHOULD) designate multiple key servers. > > > > > > > >9. Section 3.2 -- The term TEK is inappropriately specific. The group > > > >may not have encryption requirements, but only authentication. > > > > > > > >10. > > > >> > > > >>Only one SA is optional and that is the Re-key > > > >>SA. > > > > > > > > > > > >Actually, one policy for the Re-Key SA is that there is none. It is > > > >null. Explicitly stating this prevents confusion between missing SA info > > > >and optional SA info. Likewise, the registration protocol may involve > > > >manual methods. > > > > > > > >11. > > > >> > > > >>The KDC, moreover, can be delegated when the > > > >>trust infrastructure supports delegation to permit distributed > > > >>operation of the KDC. > > > >This statement, while correct, seems to conflict with the statement quoted > > > >in Comment #6. > > > > > > > >12. > > > >> > > > >>MSEC assumes that at least the following group-policy information is > > > >>externally managed. > > > >> o Group owner, authentication method, and delegation method for > > > >> identifying a KDC for the group > > > >> o Group KDC, authentication method, and any method used for > > > >> delegating other KDCs for the group > > > >> o Group membership rules or list and authentication method > > > > > > > > > > > >These assumptions are unnecessary as was shown by GSAKMP. > > > > I. While the group owner may be published externally, the group > > > > owner can also be disclosed during the registration protocol. It can be > > > > decided during this time whether the owner is acceptable prior to > > > > completion of registration. Once this occurs, authenticated group policy > > > > can be conveyed to the new member using traditional mechanisms such as > > > > digital signatures tied to a PKI. > > > > II. The delegation can be stated (authorized) through the > > > > authenticated policy statement as was done with GSAKMP. > > > > III. Ditto for membership rules and lists > > > > IV. The security association characteristics of the registration > > > > protocol can be determined early in the registration exchange or in > > > > almost all protocols (TLS, IPSec, GSAKMP, etc.) can be restricted by what > > > > properties the Key Server will accept using cipher suite restrictions, > > > > SPD constraints, etc. > > > > > > > > External management of these can be done, but should not be assumed > > > > in the architecture document. > > > > > > > >13. In general, this document contains very little new information. The > > > >framework for the architecture was already provided by the building block > > > >documents with the category 1,2, and 3 SAs. The architecture document > > > >should work toward providing interoperable solutions. > > > > > > > >--- Andrea Colegrove > > > > > > > > > > > > > > > >Internet-Drafts@ietf.org wrote: > > > >>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 : Group Key Management Architecture > > > >> Author(s) : M. Baugher, R. Canetti, L. Dondeti > > > >> Filename : draft-ietf-msec-gkmarch-00.txt > > > >> Pages : 22 > > > >> Date : 26-Jun-01 > > > >> > > > >>This document presents a group key-management architecture for MSEC. > > > >>The purpose of this document is to define the common architecture for > > > >>MSEC group key-management protocols that support a variety of > > > >>application, transport, and internetwork security protocols. To > > > >>address these diverse uses, MSEC may need to standardize two or more > > > >>group key management protocols that have common requirements, > > > >>abstractions, overall design, and messages. The framework and > > > >>guidelines in this document allow for a modular and flexible design of > > > >>group key management protocols for a variety different settings that > > > >>are specialized to application needs. > > > >> > > > >>A URL for this Internet-Draft is: > > > >>ht > > tp://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.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-gkmarch-00.txt". > > > >> > > > >>A list of Internet-Drafts directories can be found in > > > >>http://www.ietf.org/shadow.html > > > >>or > > > >>ftp://ftp.ietf.org/ietf/1sh > > adow-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-gkmarch-00.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: <20010626132202.I-D@ietf.org> --------------BB03ADFFEF41DC8ADE2FEB6F-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jun 28 14:00:39 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10483 for ; Thu, 28 Jun 2001 14:00:38 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D8B6253688; Thu, 28 Jun 2001 14:00: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 E313E5366E for ; Thu, 28 Jun 2001 13:59:08 -0400 (EDT) Received: (qmail 46801 invoked by uid 3269); 28 Jun 2001 17:59:08 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 46796 invoked from network); 28 Jun 2001 17:59:08 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 28 Jun 2001 17:59:08 -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 f5SHwXh12811; Thu, 28 Jun 2001 10:58:33 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-449.cisco.com [10.21.65.193]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADG11180; Thu, 28 Jun 2001 10:58:27 -0700 (PDT) Message-Id: <4.3.2.7.2.20010628105027.04262ef8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Andrea Colegrove From: Mark Baugher Subject: Re: [MSEC] [Fwd: [Fwd: I-D ACTION:draft-ietf-msec-gkmarch-00.txt]] Cc: msec@securemulticast.org In-Reply-To: <3B3B63FE.D14F0098@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: Thu, 28 Jun 2001 10:57:57 -0700 At 01:06 PM 6/28/2001 -0400, Andrea Colegrove wrote: > > > Many feel that modifications to a standard to support multicast is > > > not a good solution. IKE is designed with certain assumptions which > > >hold for pairwise paradigms but not necessarily groups. Please tell me the assumptions we violate by adding a DOI as specified in the Internet Standard? > > > Also, because SPD and SAD values for a group cannot be completely > > > determined in advance and are more likely distributed as part of the > > >Join/Registration process, IKE will not likely be automatically fired off > > >anyway (analogous to PPKs). Why not? Remember, this is a new DOI running here. IPsec might kick off IKE according to the three conditions in RFC 2401: Throw the packet away, let it pass, apply security processing. The Internet DOI would bring up a Phase 1 with the sender in response to the "apply security processing" case. The Group DOI might do something different, e.g. "Join and receive Re-key messages associated with this multicast address" Mark _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jun 28 14:05:24 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13972 for ; Thu, 28 Jun 2001 14:05:23 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id E27EE536F2; Thu, 28 Jun 2001 14:05: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 E3B02536F7 for ; Thu, 28 Jun 2001 14:02:11 -0400 (EDT) Received: (qmail 47101 invoked by uid 3269); 28 Jun 2001 18:02:11 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 47098 invoked from network); 28 Jun 2001 18:02:11 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 28 Jun 2001 18:02:11 -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 f5SI1P821754; Thu, 28 Jun 2001 14:01:25 -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 OAA18298; Thu, 28 Jun 2001 14:01:25 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id OAA08228; Thu, 28 Jun 2001 14:01:25 -0400 From: Ran Canetti Message-Id: <200106281801.OAA08228@ornavella.watson.ibm.com> To: acc@columbia.sparta.com, msec@securemulticast.org Subject: Re: [MSEC] [Fwd: [Fwd: I-D ACTION:draft-ietf-msec-gkmarch-00.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: Thu, 28 Jun 2001 14:01:25 -0400 Andrea, Regarding the "offending sentence" in the intro of the new architecture draft: > Extensions to IKE, however, are probably the best solution for IPsec > protocols over IP multicast services [GDOI]. I agree with you that the sentence is poorly phrased and invites misinterpretation. It should be rewreitten. Our meaning was to say that That one of the requirements of the architecture is to enable a GKM protocol that allows ESP/AH to work within the MSEC protocol suite without any changes. This is an important requirement. The reference to GDOI is there since GDOI took it up as an explcit goal to provide this functionality, so the meaning was to give it as an example. But GDOI is certainly not the only example. In particular, I am certain that a resolution of GSAKMP with IPSEC for the registration protocol would be able to provide the same functionality. Do you agree with this view of things? Regarding your note below, I think you're missing some salient points in the new draft. (And this ofcourse immediately reflects on the authors, who apparently did a poor job of explaining these points.) In particular, it is NOT compatible with the current GDOI draft, and GDOI will have to change to fit this document. I'll try to provide more details later today or to morrow. So please hold your fire... Ran > From: Andrea Colegrove > > Mark, > The architecture document is for specification and discussion of technical > issues -- not opinion -- that is the issue at hand. The document has been written > as a summary of the BBs with additional constraints and assumptions that are not > necessary except that GDOI seems to make these assumptions. This is a fairness > issue. > The "title" of editor sometimes seems more appropriate as the specifications > that are on standards track should reflect the combined interests of the working > group -- it is not intended to be honorary or to detract, but merely a reflection > of the responsibilities of the writers of the documents. > I, too, gave technical arguments as to why GDOI may not be the perfect fit. It > is not a bad solution, but let us also leave room for the ACME Group Security > Management Protocol which Joe Schmo has yet to specify. > > --- Andrea > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jun 28 14:17:40 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22780 for ; Thu, 28 Jun 2001 14:17:40 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 063E7536F6; Thu, 28 Jun 2001 14:17: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 1AA2453696 for ; Thu, 28 Jun 2001 14:15:48 -0400 (EDT) Received: (qmail 49021 invoked by uid 3269); 28 Jun 2001 18:15:47 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 49018 invoked from network); 28 Jun 2001 18:15:47 -0000 Received: from chmls05.mediaone.net (24.147.1.143) by klesh.pair.com with SMTP; 28 Jun 2001 18:15:47 -0000 Received: from THARDJONO-LAP.mediaone.net ([63.90.80.227]) by chmls05.mediaone.net (8.11.1/8.11.1) with ESMTP id f5SIFWx00563; Thu, 28 Jun 2001 14:15:32 -0400 (EDT) Message-Id: <5.0.0.25.2.20010628135522.02177618@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: Andrea Colegrove , Mark Baugher From: Thomas Hardjono Subject: Re: [MSEC] Re: [Fwd: I-D ACTION:draft-ietf-msec-gkmarch-00.txt] Cc: msec@securemulticast.org In-Reply-To: <3B3A6CDE.A29BA9A6@columbia.sparta.com> References: <4.3.2.7.2.20010627140639.04301090@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: Thu, 28 Jun 2001 14:12:56 -0400 Hi, I'd like to respond particulalry to Andrea's valid point: At 6/27/2001||07:31 PM, Andrea Colegrove wrote: > Also, because SPD and SAD values for a group cannot be completely > determined in advance and are more likely distributed as part of the > Join/Registration process, IKE will not likely be automatically fired off > anyway (analogous to PPKs). I have brought-up this point several times, namely, that if a newcomer wishes to join a group, how does he/she find out about the necessary parameters to talk to the GCKS or Key Server. GDOI assumes that this information is outside GDOI itself (say within a Group Security Policy Token). GSAKMP pushes the Token down to the newcomer after the newcomer has been authenticated and a secure channel has been estabslished between the two. Now, if we are talikng about Cat-1 SA (unicast) between a newcomer and a member, then Andrea's statement is true (ie. SPD and SAD values for a group cannot be completely determined in advance). This is in fact the whole point of the Cat-1, as we all agree that there no practical way to boot-up a group other than for each member to establish a pairwise secure channel with the GCKS. However, if we are talking about the Cat-2 SA (Key Update) and Cat-3 SA (Data Security) -- both being IPsec SAs -- then Andera's statement is not quite correct. The IPsec Arch document "hints" (within a couple of paragrahps) that for multicast the parameters must be pre-determined. thomas ------ At 6/27/2001||07:31 PM, Andrea Colegrove wrote: >Mark, > Since you are the primary author (editor?) of GDOI I am sure that you > feel GDOI is best. The architecture document, however, is not the >place to promote your solution. > Many feel that modifications to a standard to support multicast is > not a good solution. IKE is designed with certain assumptions which >hold for pairwise paradigms but not necessarily groups. > Also, because SPD and SAD values for a group cannot be completely > determined in advance and are more likely distributed as part of the >Join/Registration process, IKE will not likely be automatically fired off >anyway (analogous to PPKs). > Regardless of how you feel on this issue, it is inappropriate to > state that GDOI is probably the best solution at this point in general >and certainly not in the architecture document. > Wrt GSAKMP and separating out the "key management protocol": key > management involves more than distribution. > >--- Andrea > > > >Mark Baugher wrote: > > > Andrea > > I respond to your first point in this note. > > > > At 01:40 PM 6/27/2001 -0400, Andrea Colegrove wrote: > > > > >X-Mozilla-Status2: 00000000 > > >Message-ID: <3B3A1837.D95360C0@columbia.sparta.com> > > >Date: Wed, 27 Jun 2001 13:30:31 -0400 > > >From: Andrea Colegrove > > >X-Mailer: Mozilla 4.75 [en] (Win98; U) > > >X-Accept-Language: en > > >MIME-Version: 1.0 > > >To: msec@securemulticast.org > > >Subject: Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt > > >References: <200106271103.HAA26170@ietf.org> > > >Content-Type: multipart/alternative; > > > boundary="------------E7B7F4EE607BF84BF270BC1C" > > > > > >Mark, etal, > > >Initial comments on the architecture -- > > > > > >1. Section 1. -- > > >> > > >>Extensions to IKE, however, are probably the best solution for IPsec > > >>protocols over IP multicast services [GDOI]. > > >The architecture document is not an appropriate place for blatant > > >editorialisms. > > > > It is not as you say it is. I'll ignore the rudeness of this sentence and > > focus > > on the issue: It makes no sense to force AH and ESP to select a key > management > > application based on whether it has a unicast or a multicast destination > > address in > > the packet it is processing. One may want to do that, but extensions to > > IKE are probably > > the best solution for IPsec protocols over IP multicast services. This is > > an architectural > > issue for it involves multiple functional blocks (data security protocols > > and key > > management protocol) , and it is why msec will likely standardize an > IKE-based > > specification in addition to a something like GSAKMP (at least the key > > management > > protocol of it once that's separated out). > > > > I'll spare ipsec my comments on the rest of your points and post only > to msec. > > > > Mark > > > > >2. > > >> > > >>A "secure group" is a collection of principals, > > >>called "members," who may be senders, receivers or both receivers and > > >>senders to other members of the group. (Note that group membership may > > >>vary over time.) A "group key management protocol" ensures that only > > >>members of a secure group gain access to group data (by gaining access > > >>to group keys) and can authenticate group data. > > >A secure group is a group in which access to data is restricted to > > >particular entities. This access can be of read and/or write access. In > > >other words, a group may only have write restrictions and no read > > >restrictions. While this access may be enforced with group keys, it is > > >mandated by a policy that claims data will only be accepted from > > >particular entities, which could also be enforced with signature keys. A > > >key distribution protocol alone does not define a secure group. This > > >really demands a _security management_ protocol that can manage keys and > > >policy. > > > > > >3. > > >> > > >>4. The key-management protocol must be secure against man-in-the- > > >> middle, connection-hijacking, and reflection/replay attacks; it must > > >> use best-known practices to thwart denial-of-service attacks. > > > > > > > > >And type attacks. And attacks resulting from lack of explicitness > > >(mis-routed, mis-interpreted). And interleaved with other protocols > > >(protocol-oracle), etc. Perhaps it would be better to generalize this > > >statement. > > > > > >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." > > > > > >5. Re: video on demand example. The example shows a pre-existing group > > >of all possible members subject to pre-broadcast rekey. One broadcast > > >would destroy this property. > > > > > >6. > > >> > > >>A centralized > > >>group controller (or KDC) that is used in this architecture may not be > > >>the best design for small, interactive groups. But for large, single- > > >>source multicast groups, it is generally undesirable to distribute key > > >>management functions among group members: Unlike small, interactive > > >>groups, large single-source multicast groups generally need a > > >>specialized KDC to support large numbers of group members. Large > > >>distributed simulations, moreover, may combine the need for large-grou > > >>operation with many senders. > > >Large groups require distributed initial key distribution! Large dynamic > > >groups cannot rely upon a centralized KDC. This does not scale. This is > > >highly inflexible. The VoD example demonstrates this. > > > > > >While the interactions with distributed rekey entities is more > > >complicated, this functionality may be needed in composite multicast > > >groups of limited scope. > > > > > >7. > > >> > > >>It may be that no > > >>single key management protocol can satisfy the scalability requirements > > >>of all group-security applications. This is for further study. > > >It may be that the security protocols protecting group communications data > > >cannot satisfy each of the possible sender/receiver profiles. This is > > >less of a security management problem. > > > > > >8. > > >> > > >>This design is based upon a "group controller" model > > >>[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group > > >>owner as the root-of-trust. The group owner designates a key > > >>distribution center for member registration and re-key. > > >As was originally envisioned, the group owner CAN (and for large or sparse > > >groups SHOULD) designate multiple key servers. > > > > > >9. Section 3.2 -- The term TEK is inappropriately specific. The group > > >may not have encryption requirements, but only authentication. > > > > > >10. > > >> > > >>Only one SA is optional and that is the Re-key > > >>SA. > > > > > > > > >Actually, one policy for the Re-Key SA is that there is none. It is > > >null. Explicitly stating this prevents confusion between missing SA info > > >and optional SA info. Likewise, the registration protocol may involve > > >manual methods. > > > > > >11. > > >> > > >>The KDC, moreover, can be delegated when the > > >>trust infrastructure supports delegation to permit distributed > > >>operation of the KDC. > > >This statement, while correct, seems to conflict with the statement quoted > > >in Comment #6. > > > > > >12. > > >> > > >>MSEC assumes that at least the following group-policy information is > > >>externally managed. > > >> o Group owner, authentication method, and delegation method for > > >> identifying a KDC for the group > > >> o Group KDC, authentication method, and any method used for > > >> delegating other KDCs for the group > > >> o Group membership rules or list and authentication method > > > > > > > > >These assumptions are unnecessary as was shown by GSAKMP. > > > I. While the group owner may be published externally, the group > > > owner can also be disclosed during the registration protocol. It can be > > > decided during this time whether the owner is acceptable prior to > > > completion of registration. Once this occurs, authenticated group policy > > > can be conveyed to the new member using traditional mechanisms such as > > > digital signatures tied to a PKI. > > > II. The delegation can be stated (authorized) through the > > > authenticated policy statement as was done with GSAKMP. > > > III. Ditto for membership rules and lists > > > IV. The security association characteristics of the registration > > > protocol can be determined early in the registration exchange or in > > > almost all protocols (TLS, IPSec, GSAKMP, etc.) can be restricted by what > > > properties the Key Server will accept using cipher suite restrictions, > > > SPD constraints, etc. > > > > > > External management of these can be done, but should not be assumed > > > in the architecture document. > > > > > >13. In general, this document contains very little new information. The > > >framework for the architecture was already provided by the building block > > >documents with the category 1,2, and 3 SAs. The architecture document > > >should work toward providing interoperable solutions. > > > > > >--- Andrea Colegrove > > > > > > > > > > > >Internet-Drafts@ietf.org wrote: > > >>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 : Group Key Management Architecture > > >> Author(s) : M. Baugher, R. Canetti, L. Dondeti > > >> Filename : draft-ietf-msec-gkmarch-00.txt > > >> Pages : 22 > > >> Date : 26-Jun-01 > > >> > > >>This document presents a group key-management architecture for MSEC. > > >>The purpose of this document is to define the common architecture for > > >>MSEC group key-management protocols that support a variety of > > >>application, transport, and internetwork security protocols. To > > >>address these diverse uses, MSEC may need to standardize two or more > > >>group key management protocols that have common requirements, > > >>abstractions, overall design, and messages. The framework and > > >>guidelines in this document allow for a modular and flexible design of > > >>group key management protocols for a variety different settings that > > >>are specialized to application needs. > > >> > > >>A URL for this Internet-Draft is: > > >>ht > tp://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.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-gkmarch-00.txt". > > >> > > >>A list of Internet-Drafts directories can be found in > > >>http://www.ietf.org/shadow.html > > >>or > > >>ftp://ftp.ietf.org/ietf/1sh > adow-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-gkmarch-00.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: <20010626132202.I-D@ietf.org> > > >_______________________________________________ >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 Jun 28 14:50:13 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15510 for ; Thu, 28 Jun 2001 14:50:12 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4F3395364D; Thu, 28 Jun 2001 14:50:23 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 864325353F for ; Thu, 28 Jun 2001 14:48:26 -0400 (EDT) Received: (qmail 52898 invoked by uid 3269); 28 Jun 2001 18:48:26 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 52895 invoked from network); 28 Jun 2001 18:48:25 -0000 Received: from chmls05.mediaone.net (24.147.1.143) by klesh.pair.com with SMTP; 28 Jun 2001 18:48:25 -0000 Received: from THARDJONO-LAP.mediaone.net ([63.90.80.227]) by chmls05.mediaone.net (8.11.1/8.11.1) with ESMTP id f5SImLx17433; Thu, 28 Jun 2001 14:48:21 -0400 (EDT) Message-Id: <5.0.0.25.2.20010628144028.0245e470@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: Mark Baugher From: Thomas Hardjono Subject: Re: [MSEC] Re: [Fwd: I-D ACTION:draft-ietf-msec-gkmarch-00.txt] Cc: msec@securemulticast.org In-Reply-To: <4.3.2.7.2.20010628112110.0422eda0@mira-sjc5-6.cisco.com> References: <5.0.0.25.2.20010628135522.02177618@pop.ne.mediaone.net> <3B3A6CDE.A29BA9A6@columbia.sparta.com> <4.3.2.7.2.20010627140639.04301090@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: Thu, 28 Jun 2001 14:47:45 -0400 At 6/28/2001||11:31 AM, Mark Baugher wrote: >Thomas, > >At 02:12 PM 6/28/2001 -0400, Thomas Hardjono wrote: >>Hi, >> >>I'd like to respond particulalry to Andrea's valid point: >> >>At 6/27/2001||07:31 PM, Andrea Colegrove wrote: >> > Also, because SPD and SAD values for a group cannot be completely >> > determined in advance and are more likely distributed as part of the >> > Join/Registration process, IKE will not likely be automatically >> fired off >> > anyway (analogous to PPKs). >> >>I have brought-up this point several times, namely, that if a newcomer >>wishes to join a group, how does he/she find out about the necessary >>parameters to talk to the GCKS or Key Server. >> >>GDOI assumes that this information is outside GDOI itself (say within >>a Group Security Policy Token). GSAKMP pushes the Token down to the >>newcomer after the newcomer has been authenticated and a secure channel >>has been estabslished between the two. >> >>Now, if we are talikng about Cat-1 SA (unicast) between a newcomer >>and a member, then Andrea's statement is true (ie. SPD and SAD values >>for a group cannot be completely determined in advance). >>This is in fact the whole point of the Cat-1, as we all agree that >>there no practical way to boot-up a group other than for each member >>to establish a pairwise secure channel with the GCKS. > >Consider a group of four members who trust each other not to >impersonate another member. When an IPsec ESP message is >sent multicast from one to all of the members, each one could >perform a Registration exchange (protected by a Cat-1 SA) >with the sender if they don't already have an AH SA. This may >initialize a Rekey (Cat-2) SA for Re-key messages (indeed, >all of this could have been initiated by the receipt of a Re-key >message). Or it might not use Re-key. > >Now, if the group is much larger than four... This is why some group-policy information is needed (and a draft on this is being worked-on now). Also, in order to boot-strap the group, I cannot think of any other way than to use certificates for initial user-authentication with the GCKS. I think GSAKMP does this, and IKE and so GDOI) allows for this. For small groups, then an ACL might work, but once the group gets into the thousands, then ACLs may be too cumbersome. >>However, if we are talking about the Cat-2 SA (Key Update) and >>Cat-3 SA (Data Security) -- both being IPsec SAs -- then >>Andera's statement is not quite correct. The IPsec Arch document "hints" >>(within a couple of paragrahps) that for multicast the parameters >>must be pre-determined. > >It doesn't matter whether the Cat-2 SA (Re-key not Key Update) is >IPsec or not - it could be ISAKMP - we would not want to initiate >a pairwise SA on receipt of a multicast message sent to a large >group because that could cause implosion. A better course >might be to listen to the Re-key multicast address for the >particular group and pick up the SA for the multicast message >received. No change is required to IPsec it is all done in >IKE GDOI. OK, I'm confused :) Why would we want a newcomer to contact a GCKS upon receiving a multicast message? How does the newcomer pick-up the SA when that SA is either not in the multicast message or is encrypted within the multicast message? thomas ------ >How to do this is something I expect will be answered in the >Policy draft. > >Best Regards, Mark > > >>thomas >>------ >> >> >>At 6/27/2001||07:31 PM, Andrea Colegrove wrote: >>>Mark, >>> Since you are the primary author (editor?) of GDOI I am sure that >>> you feel GDOI is best. The architecture document, however, is not the >>>place to promote your solution. >>> Many feel that modifications to a standard to support multicast is >>> not a good solution. IKE is designed with certain assumptions which >>>hold for pairwise paradigms but not necessarily groups. >>> Also, because SPD and SAD values for a group cannot be completely >>> determined in advance and are more likely distributed as part of the >>>Join/Registration process, IKE will not likely be automatically fired >>>off anyway (analogous to PPKs). >>> Regardless of how you feel on this issue, it is inappropriate to >>> state that GDOI is probably the best solution at this point in general >>>and certainly not in the architecture document. >>> Wrt GSAKMP and separating out the "key management protocol": key >>> management involves more than distribution. >>> >>>--- Andrea >>> >>> >>> >>>Mark Baugher wrote: >>> >>> > Andrea >>> > I respond to your first point in this note. >>> > >>> > At 01:40 PM 6/27/2001 -0400, Andrea Colegrove wrote: >>> > >>> > >X-Mozilla-Status2: 00000000 >>> > >Message-ID: <3B3A1837.D95360C0@columbia.sparta.com> >>> > >Date: Wed, 27 Jun 2001 13:30:31 -0400 >>> > >From: Andrea Colegrove >>> > >X-Mailer: Mozilla 4.75 [en] (Win98; U) >>> > >X-Accept-Language: en >>> > >MIME-Version: 1.0 >>> > >To: msec@securemulticast.org >>> > >Subject: Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt >>> > >References: <200106271103.HAA26170@ietf.org> >>> > >Content-Type: multipart/alternative; >>> > > boundary="------------E7B7F4EE607BF84BF270BC1C" >>> > > >>> > >Mark, etal, >>> > >Initial comments on the architecture -- >>> > > >>> > >1. Section 1. -- >>> > >> >>> > >>Extensions to IKE, however, are probably the best solution for IPsec >>> > >>protocols over IP multicast services [GDOI]. >>> > >The architecture document is not an appropriate place for blatant >>> > >editorialisms. >>> > >>> > It is not as you say it is. I'll ignore the rudeness of this >>> sentence and >>> > focus >>> > on the issue: It makes no sense to force AH and ESP to select a key >>> management >>> > application based on whether it has a unicast or a multicast destination >>> > address in >>> > the packet it is processing. One may want to do that, but extensions to >>> > IKE are probably >>> > the best solution for IPsec protocols over IP multicast >>> services. This is >>> > an architectural >>> > issue for it involves multiple functional blocks (data security protocols >>> > and key >>> > management protocol) , and it is why msec will likely standardize an >>> IKE-based >>> > specification in addition to a something like GSAKMP (at least the key >>> > management >>> > protocol of it once that's separated out). >>> > >>> > I'll spare ipsec my comments on the rest of your points and post only >>> to msec. >>> > >>> > Mark >>> > >>> > >2. >>> > >> >>> > >>A "secure group" is a collection of principals, >>> > >>called "members," who may be senders, receivers or both receivers and >>> > >>senders to other members of the group. (Note that group membership may >>> > >>vary over time.) A "group key management protocol" ensures that only >>> > >>members of a secure group gain access to group data (by gaining access >>> > >>to group keys) and can authenticate group data. >>> > >A secure group is a group in which access to data is restricted to >>> > >particular entities. This access can be of read and/or write >>> access. In >>> > >other words, a group may only have write restrictions and no read >>> > >restrictions. While this access may be enforced with group keys, it is >>> > >mandated by a policy that claims data will only be accepted from >>> > >particular entities, which could also be enforced with signature >>> keys. A >>> > >key distribution protocol alone does not define a secure group. This >>> > >really demands a _security management_ protocol that can manage keys and >>> > >policy. >>> > > >>> > >3. >>> > >> >>> > >>4. The key-management protocol must be secure against man-in-the- >>> > >> middle, connection-hijacking, and reflection/replay attacks; it >>> must >>> > >> use best-known practices to thwart denial-of-service attacks. >>> > > >>> > > >>> > >And type attacks. And attacks resulting from lack of explicitness >>> > >(mis-routed, mis-interpreted). And interleaved with other protocols >>> > >(protocol-oracle), etc. Perhaps it would be better to generalize this >>> > >statement. >>> > > >>> > >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." >>> > > >>> > >5. Re: video on demand example. The example shows a pre-existing >>> group >>> > >of all possible members subject to pre-broadcast rekey. One broadcast >>> > >would destroy this property. >>> > > >>> > >6. >>> > >> >>> > >>A centralized >>> > >>group controller (or KDC) that is used in this architecture may not be >>> > >>the best design for small, interactive groups. But for large, single- >>> > >>source multicast groups, it is generally undesirable to distribute key >>> > >>management functions among group members: Unlike small, interactive >>> > >>groups, large single-source multicast groups generally need a >>> > >>specialized KDC to support large numbers of group members. Large >>> > >>distributed simulations, moreover, may combine the need for large-grou >>> > >>operation with many senders. >>> > >Large groups require distributed initial key distribution! Large >>> dynamic >>> > >groups cannot rely upon a centralized KDC. This does not >>> scale. This is >>> > >highly inflexible. The VoD example demonstrates this. >>> > > >>> > >While the interactions with distributed rekey entities is more >>> > >complicated, this functionality may be needed in composite multicast >>> > >groups of limited scope. >>> > > >>> > >7. >>> > >> >>> > >>It may be that no >>> > >>single key management protocol can satisfy the scalability requirements >>> > >>of all group-security applications. This is for further study. >>> > >It may be that the security protocols protecting group >>> communications data >>> > >cannot satisfy each of the possible sender/receiver profiles. This is >>> > >less of a security management problem. >>> > > >>> > >8. >>> > >> >>> > >>This design is based upon a "group controller" model >>> > >>[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group >>> > >>owner as the root-of-trust. The group owner designates a key >>> > >>distribution center for member registration and re-key. >>> > >As was originally envisioned, the group owner CAN (and for large or >>> sparse >>> > >groups SHOULD) designate multiple key servers. >>> > > >>> > >9. Section 3.2 -- The term TEK is inappropriately specific. The group >>> > >may not have encryption requirements, but only authentication. >>> > > >>> > >10. >>> > >> >>> > >>Only one SA is optional and that is the Re-key >>> > >>SA. >>> > > >>> > > >>> > >Actually, one policy for the Re-Key SA is that there is none. It is >>> > >null. Explicitly stating this prevents confusion between missing SA >>> info >>> > >and optional SA info. Likewise, the registration protocol may involve >>> > >manual methods. >>> > > >>> > >11. >>> > >> >>> > >>The KDC, moreover, can be delegated when the >>> > >>trust infrastructure supports delegation to permit distributed >>> > >>operation of the KDC. >>> > >This statement, while correct, seems to conflict with the statement >>> quoted >>> > >in Comment #6. >>> > > >>> > >12. >>> > >> >>> > >>MSEC assumes that at least the following group-policy information is >>> > >>externally managed. >>> > >> o Group owner, authentication method, and delegation method for >>> > >> identifying a KDC for the group >>> > >> o Group KDC, authentication method, and any method used for >>> > >> delegating other KDCs for the group >>> > >> o Group membership rules or list and authentication method >>> > > >>> > > >>> > >These assumptions are unnecessary as was shown by GSAKMP. >>> > > I. While the group owner may be published externally, the group >>> > > owner can also be disclosed during the registration protocol. It >>> can be >>> > > decided during this time whether the owner is acceptable prior to >>> > > completion of registration. Once this occurs, authenticated group >>> policy >>> > > can be conveyed to the new member using traditional mechanisms such as >>> > > digital signatures tied to a PKI. >>> > > II. The delegation can be stated (authorized) through the >>> > > authenticated policy statement as was done with GSAKMP. >>> > > III. Ditto for membership rules and lists >>> > > IV. The security association characteristics of the registration >>> > > protocol can be determined early in the registration exchange or in >>> > > almost all protocols (TLS, IPSec, GSAKMP, etc.) can be restricted >>> by what >>> > > properties the Key Server will accept using cipher suite restrictions, >>> > > SPD constraints, etc. >>> > > >>> > > External management of these can be done, but should not be assumed >>> > > in the architecture document. >>> > > >>> > >13. In general, this document contains very little new >>> information. The >>> > >framework for the architecture was already provided by the building >>> block >>> > >documents with the category 1,2, and 3 SAs. The architecture document >>> > >should work toward providing interoperable solutions. >>> > > >>> > >--- Andrea Colegrove >>> > > >>> > > >>> > > >>> > >Internet-Drafts@ietf.org wrote: >>> > >>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 : Group Key Management Architecture >>> > >> Author(s) : M. Baugher, R. Canetti, L. Dondeti >>> > >> Filename : draft-ietf-msec-gkmarch-00.txt >>> > >> Pages : 22 >>> > >> Date : 26-Jun-01 >>> > >> >>> > >>This document presents a group key-management architecture for MSEC. >>> > >>The purpose of this document is to define the common architecture for >>> > >>MSEC group key-management protocols that support a variety of >>> > >>application, transport, and internetwork security protocols. To >>> > >>address these diverse uses, MSEC may need to standardize two or more >>> > >>group key management protocols that have common requirements, >>> > >>abstractions, overall design, and messages. The framework and >>> > >>guidelines in this document allow for a modular and flexible design of >>> > >>group key management protocols for a variety different settings that >>> > >>are specialized to application needs. >>> > >> >>> > >>A URL for this Internet-Draft is: >>> > >> >>> h t tp://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.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-gkmarch-00.txt". >>> > >> >>> > >>A list of Internet-Drafts directories can be found in >>> > >>http://www.ietf.org/shadow.html >>> > >>or >>> > >>ftp://ftp.ietf.org/ietf/1 >>> s h adow-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-gkmarch-00.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: <20010626132202.I-D@ietf.org> >>> >>> >>>_______________________________________________ >>>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 Thu Jun 28 14:56:13 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20002 for ; Thu, 28 Jun 2001 14:56:12 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6DD76535AC; Thu, 28 Jun 2001 14:56:23 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 807D85353F for ; Thu, 28 Jun 2001 14:55:26 -0400 (EDT) Received: (qmail 53630 invoked by uid 3269); 28 Jun 2001 18:55:26 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 53624 invoked from network); 28 Jun 2001 18:55:25 -0000 Received: from m5.sparta.com (root@157.185.61.1) by klesh.pair.com with SMTP; 28 Jun 2001 18:55: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 f5SItKx02142 for ; Thu, 28 Jun 2001 13:55:21 -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 OAA26858 for ; Thu, 28 Jun 2001 14:55:18 -0400 (EDT) Message-Id: <4.2.2.20010628143506.00b31dc0@pop.columbia.sparta.com> X-Sender: hh@pop.columbia.sparta.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 To: msec@securemulticast.org From: Hugh Harney Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] msec architecture draft and email flow 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, 28 Jun 2001 14:41:17 -0400 All, I think I need to clarify my position on both GDOI and GSAKMP. I think this is necessary because I'm being referenced. I'm also an author of both protocols. I believe they both have valid Internet requirements they are trying to address. GDOI is specifically aimed at centralized key distribution for IPSec, ESP and AH. It is aimed at applications with some of the following characteristics. First, the data is owned by a single entity. Second, it was decided during an authors meeting that GDOI would rely on an external security policy infrastructure (left undefined in the document). I think there are perfectly valid applications for this architecture. GSAKMP is aimed at non centralized key distribution (although it can support a centralized architecture). It also has incorporated the mechanisms needed to support applications with multiple sources of data and multiple data ownership issues. To support these applications it incorporates policy definition and dissemination mechanisms. Unfortunately, flexibility in architectures leads to complexity in protocols. I believe the statement "Extensions to IKE, however, are probably the best solution for IPSec protocols over IP multicast services [GDOI]" in the introduction leads the reader to a conclusion that GDOI is THE ONLY valid key management protocol for IPSec. I believe it is a valid protocol given some constraints on the application. (see above) 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. The position of GDOI is as stated in the document "As is done in IKE, GDOI defines and conveys only cryptographic policies, which are contained in the SA KEK and SA TEK payloads. " Given the above condition, I suggested the following be added to the GDOI Internet Draft. This second GDOI quote (below) constitutes a criteria I believe could make the above GDOI assumption work in a secure system. 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. 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. 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. Note: Read words written in capital letters as Boolean. I believe MSec security policy is important to key management. I believe that internal or external means can supply that policy to the group. I don't believe the MSec architecture should exclude key management approaches that provide policy mechanisms internal to the key management protocols. 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 Thu Jun 28 15:20:29 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06844 for ; Thu, 28 Jun 2001 15:20:28 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C7C075361F; Thu, 28 Jun 2001 15:20:23 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 1795153630 for ; Thu, 28 Jun 2001 15:16:51 -0400 (EDT) Received: (qmail 55624 invoked by uid 3269); 28 Jun 2001 19:16:50 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 55621 invoked from network); 28 Jun 2001 19:16:50 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157) by klesh.pair.com with SMTP; 28 Jun 2001 19:16:50 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5SJG0022407 for ; Thu, 28 Jun 2001 15:16:00 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.ca.nortel.com; Thu, 28 Jun 2001 15:16:04 -0400 Received: from zbl6c016.corpeast.baynetworks.com ([132.245.205.66]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N43SN14L; Thu, 28 Jun 2001 15:16:01 -0400 Received: from nortelnetworks.com (arc.engeast.baynetworks.com [192.32.137.28]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KBYWGWFH; Thu, 28 Jun 2001 15:16:02 -0400 Message-ID: <3B3B838F.F8C6C8C1@nortelnetworks.com> From: "Lakshminath Dondeti" X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: msec@securemulticast.org Subject: Re: [MSEC] Re: [Fwd: I-D ACTION:draft-ietf-msec-gkmarch-00.txt] References: <4.3.2.7.2.20010627140639.04301090@mira-sjc5-6.cisco.com> <5.0.0.25.2.20010628135522.02177618@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: Thu, 28 Jun 2001 15:20:47 -0400 Content-Transfer-Encoding: 7bit Some of the SAD or SPD information is pre-distributed and the rest is sent via the registration protocol (some of it may be sent or updated via the rekey protocol). The group owner decides (depending on the application) on which parts to pre-distribute. We went further and gave examples of pre-distributed information. It goes without saying that if there is a problem about a specific item in that list of pre-distributed information, please let us know. Thanks. best regards, Lakshminath Thomas Hardjono wrote: > > Hi, > > I'd like to respond particulalry to Andrea's valid point: > > At 6/27/2001||07:31 PM, Andrea Colegrove wrote: > > Also, because SPD and SAD values for a group cannot be completely > > determined in advance and are more likely distributed as part of the > > Join/Registration process, IKE will not likely be automatically fired > off > > anyway (analogous to PPKs). > > I have brought-up this point several times, namely, that if a newcomer > wishes to join a group, how does he/she find out about the necessary > parameters to talk to the GCKS or Key Server. > > GDOI assumes that this information is outside GDOI itself (say within > a Group Security Policy Token). GSAKMP pushes the Token down to the > newcomer after the newcomer has been authenticated and a secure channel > has been estabslished between the two. > > Now, if we are talikng about Cat-1 SA (unicast) between a newcomer > and a member, then Andrea's statement is true (ie. SPD and SAD values > for a group cannot be completely determined in advance). > This is in fact the whole point of the Cat-1, as we all agree that > there no practical way to boot-up a group other than for each member > to establish a pairwise secure channel with the GCKS. > > However, if we are talking about the Cat-2 SA (Key Update) and > Cat-3 SA (Data Security) -- both being IPsec SAs -- then > Andera's statement is not quite correct. The IPsec Arch document "hints" > (within a couple of paragrahps) that for multicast the parameters > must be pre-determined. > > thomas > ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jun 28 15:28:13 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12685 for ; Thu, 28 Jun 2001 15:28:12 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8579C53643; Thu, 28 Jun 2001 15:28:23 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 6958653643 for ; Thu, 28 Jun 2001 15:26:41 -0400 (EDT) Received: (qmail 56537 invoked by uid 3269); 28 Jun 2001 19:26:41 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 56534 invoked from network); 28 Jun 2001 19:26:40 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 28 Jun 2001 19:26:40 -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 f5SJQGx19318; Thu, 28 Jun 2001 12:26:16 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-449.cisco.com [10.21.65.193]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADG13648; Thu, 28 Jun 2001 12:24:53 -0700 (PDT) Message-Id: <4.3.2.7.2.20010628120941.041f83c0@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] Re: [Fwd: I-D ACTION:draft-ietf-msec-gkmarch-00.txt] Cc: msec@securemulticast.org In-Reply-To: <5.0.0.25.2.20010628144028.0245e470@pop.ne.mediaone.net> References: <4.3.2.7.2.20010628112110.0422eda0@mira-sjc5-6.cisco.com> <5.0.0.25.2.20010628135522.02177618@pop.ne.mediaone.net> <3B3A6CDE.A29BA9A6@columbia.sparta.com> <4.3.2.7.2.20010627140639.04301090@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: Thu, 28 Jun 2001 12:24:22 -0700 At 02:47 PM 6/28/2001 -0400, Thomas Hardjono wrote: >At 6/28/2001||11:31 AM, Mark Baugher wrote: >>It doesn't matter whether the Cat-2 SA (Re-key not Key Update) is >>IPsec or not - it could be ISAKMP - we would not want to initiate >>a pairwise SA on receipt of a multicast message sent to a large >>group because that could cause implosion. A better course >>might be to listen to the Re-key multicast address for the >>particular group and pick up the SA for the multicast message >>received. No change is required to IPsec it is all done in >>IKE GDOI. > > >OK, I'm confused :) Why would we want a newcomer to contact a GCKS >upon receiving a multicast message? How does the newcomer pick-up >the SA when that SA is either not in the multicast message or is encrypted >within the multicast message? I wrote that the member would listen for Re-key messages. I didn't say anything about contacting the GCKS. Here is a scenario: A Quicktime media server multicasts a stream of packets to group A, which shares KEK K. That stream of packets is protected by TEK k. While the Quicktime server sends the packets to one multicast transport address, it periodically sends to another address the Re-key messages that are protected by K and which contain k. So the Quicktime server in this example can periodically send K{k} with additional parameters such as a cert that is signed by the GCKS authorizing it to send on behalf of the GCKS (i.e., the GCKS issues a delegate cert to the Quicktime server and the GCKS is authorized to do such delegation by the Group Owner). Mark >thomas >------ > > > > >>How to do this is something I expect will be answered in the >>Policy draft. >> >>Best Regards, Mark >> >> >>>thomas >>>------ >>> >>> >>>At 6/27/2001||07:31 PM, Andrea Colegrove wrote: >>>>Mark, >>>> Since you are the primary author (editor?) of GDOI I am sure that >>>> you feel GDOI is best. The architecture document, however, is not the >>>>place to promote your solution. >>>> Many feel that modifications to a standard to support multicast is >>>> not a good solution. IKE is designed with certain assumptions which >>>>hold for pairwise paradigms but not necessarily groups. >>>> Also, because SPD and SAD values for a group cannot be completely >>>> determined in advance and are more likely distributed as part of the >>>>Join/Registration process, IKE will not likely be automatically fired >>>>off anyway (analogous to PPKs). >>>> Regardless of how you feel on this issue, it is inappropriate to >>>> state that GDOI is probably the best solution at this point in general >>>>and certainly not in the architecture document. >>>> Wrt GSAKMP and separating out the "key management protocol": key >>>> management involves more than distribution. >>>> >>>>--- Andrea >>>> >>>> >>>> >>>>Mark Baugher wrote: >>>> >>>> > Andrea >>>> > I respond to your first point in this note. >>>> > >>>> > At 01:40 PM 6/27/2001 -0400, Andrea Colegrove wrote: >>>> > >>>> > >X-Mozilla-Status2: 00000000 >>>> > >Message-ID: <3B3A1837.D95360C0@columbia.sparta.com> >>>> > >Date: Wed, 27 Jun 2001 13:30:31 -0400 >>>> > >From: Andrea Colegrove >>>> > >X-Mailer: Mozilla 4.75 [en] (Win98; U) >>>> > >X-Accept-Language: en >>>> > >MIME-Version: 1.0 >>>> > >To: msec@securemulticast.org >>>> > >Subject: Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt >>>> > >References: <200106271103.HAA26170@ietf.org> >>>> > >Content-Type: multipart/alternative; >>>> > > boundary="------------E7B7F4EE607BF84BF270BC1C" >>>> > > >>>> > >Mark, etal, >>>> > >Initial comments on the architecture -- >>>> > > >>>> > >1. Section 1. -- >>>> > >> >>>> > >>Extensions to IKE, however, are probably the best solution for IPsec >>>> > >>protocols over IP multicast services [GDOI]. >>>> > >The architecture document is not an appropriate place for blatant >>>> > >editorialisms. >>>> > >>>> > It is not as you say it is. I'll ignore the rudeness of this >>>> sentence and >>>> > focus >>>> > on the issue: It makes no sense to force AH and ESP to select a key >>>> management >>>> > application based on whether it has a unicast or a multicast destination >>>> > address in >>>> > the packet it is processing. One may want to do that, but extensions to >>>> > IKE are probably >>>> > the best solution for IPsec protocols over IP multicast >>>> services. This is >>>> > an architectural >>>> > issue for it involves multiple functional blocks (data security >>>> protocols >>>> > and key >>>> > management protocol) , and it is why msec will likely standardize an >>>> IKE-based >>>> > specification in addition to a something like GSAKMP (at least the key >>>> > management >>>> > protocol of it once that's separated out). >>>> > >>>> > I'll spare ipsec my comments on the rest of your points and post >>>> only to msec. >>>> > >>>> > Mark >>>> > >>>> > >2. >>>> > >> >>>> > >>A "secure group" is a collection of principals, >>>> > >>called "members," who may be senders, receivers or both receivers and >>>> > >>senders to other members of the group. (Note that group membership may >>>> > >>vary over time.) A "group key management protocol" ensures that only >>>> > >>members of a secure group gain access to group data (by gaining access >>>> > >>to group keys) and can authenticate group data. >>>> > >A secure group is a group in which access to data is restricted to >>>> > >particular entities. This access can be of read and/or write >>>> access. In >>>> > >other words, a group may only have write restrictions and no read >>>> > >restrictions. While this access may be enforced with group keys, it is >>>> > >mandated by a policy that claims data will only be accepted from >>>> > >particular entities, which could also be enforced with signature >>>> keys. A >>>> > >key distribution protocol alone does not define a secure group. This >>>> > >really demands a _security management_ protocol that can manage >>>> keys and >>>> > >policy. >>>> > > >>>> > >3. >>>> > >> >>>> > >>4. The key-management protocol must be secure against man-in-the- >>>> > >> middle, connection-hijacking, and reflection/replay attacks; >>>> it must >>>> > >> use best-known practices to thwart denial-of-service attacks. >>>> > > >>>> > > >>>> > >And type attacks. And attacks resulting from lack of explicitness >>>> > >(mis-routed, mis-interpreted). And interleaved with other protocols >>>> > >(protocol-oracle), etc. Perhaps it would be better to generalize this >>>> > >statement. >>>> > > >>>> > >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." >>>> > > >>>> > >5. Re: video on demand example. The example shows a >>>> pre-existing group >>>> > >of all possible members subject to pre-broadcast rekey. One broadcast >>>> > >would destroy this property. >>>> > > >>>> > >6. >>>> > >> >>>> > >>A centralized >>>> > >>group controller (or KDC) that is used in this architecture may not be >>>> > >>the best design for small, interactive groups. But for large, single- >>>> > >>source multicast groups, it is generally undesirable to distribute key >>>> > >>management functions among group members: Unlike small, interactive >>>> > >>groups, large single-source multicast groups generally need a >>>> > >>specialized KDC to support large numbers of group members. Large >>>> > >>distributed simulations, moreover, may combine the need for large-grou >>>> > >>operation with many senders. >>>> > >Large groups require distributed initial key distribution! Large >>>> dynamic >>>> > >groups cannot rely upon a centralized KDC. This does not >>>> scale. This is >>>> > >highly inflexible. The VoD example demonstrates this. >>>> > > >>>> > >While the interactions with distributed rekey entities is more >>>> > >complicated, this functionality may be needed in composite multicast >>>> > >groups of limited scope. >>>> > > >>>> > >7. >>>> > >> >>>> > >>It may be that no >>>> > >>single key management protocol can satisfy the scalability >>>> requirements >>>> > >>of all group-security applications. This is for further study. >>>> > >It may be that the security protocols protecting group >>>> communications data >>>> > >cannot satisfy each of the possible sender/receiver profiles. This is >>>> > >less of a security management problem. >>>> > > >>>> > >8. >>>> > >> >>>> > >>This design is based upon a "group controller" model >>>> > >>[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group >>>> > >>owner as the root-of-trust. The group owner designates a key >>>> > >>distribution center for member registration and re-key. >>>> > >As was originally envisioned, the group owner CAN (and for large or >>>> sparse >>>> > >groups SHOULD) designate multiple key servers. >>>> > > >>>> > >9. Section 3.2 -- The term TEK is inappropriately specific. The group >>>> > >may not have encryption requirements, but only authentication. >>>> > > >>>> > >10. >>>> > >> >>>> > >>Only one SA is optional and that is the Re-key >>>> > >>SA. >>>> > > >>>> > > >>>> > >Actually, one policy for the Re-Key SA is that there is none. It is >>>> > >null. Explicitly stating this prevents confusion between missing >>>> SA info >>>> > >and optional SA info. Likewise, the registration protocol may involve >>>> > >manual methods. >>>> > > >>>> > >11. >>>> > >> >>>> > >>The KDC, moreover, can be delegated when the >>>> > >>trust infrastructure supports delegation to permit distributed >>>> > >>operation of the KDC. >>>> > >This statement, while correct, seems to conflict with the statement >>>> quoted >>>> > >in Comment #6. >>>> > > >>>> > >12. >>>> > >> >>>> > >>MSEC assumes that at least the following group-policy information is >>>> > >>externally managed. >>>> > >> o Group owner, authentication method, and delegation method for >>>> > >> identifying a KDC for the group >>>> > >> o Group KDC, authentication method, and any method used for >>>> > >> delegating other KDCs for the group >>>> > >> o Group membership rules or list and authentication method >>>> > > >>>> > > >>>> > >These assumptions are unnecessary as was shown by GSAKMP. >>>> > > I. While the group owner may be published externally, the group >>>> > > owner can also be disclosed during the registration protocol. It >>>> can be >>>> > > decided during this time whether the owner is acceptable prior to >>>> > > completion of registration. Once this occurs, authenticated group >>>> policy >>>> > > can be conveyed to the new member using traditional mechanisms such as >>>> > > digital signatures tied to a PKI. >>>> > > II. The delegation can be stated (authorized) through the >>>> > > authenticated policy statement as was done with GSAKMP. >>>> > > III. Ditto for membership rules and lists >>>> > > IV. The security association characteristics of the registration >>>> > > protocol can be determined early in the registration exchange or in >>>> > > almost all protocols (TLS, IPSec, GSAKMP, etc.) can be restricted >>>> by what >>>> > > properties the Key Server will accept using cipher suite restrictions, >>>> > > SPD constraints, etc. >>>> > > >>>> > > External management of these can be done, but should not be >>>> assumed >>>> > > in the architecture document. >>>> > > >>>> > >13. In general, this document contains very little new >>>> information. The >>>> > >framework for the architecture was already provided by the building >>>> block >>>> > >documents with the category 1,2, and 3 SAs. The architecture document >>>> > >should work toward providing interoperable solutions. >>>> > > >>>> > >--- Andrea Colegrove >>>> > > >>>> > > >>>> > > >>>> > >Internet-Drafts@ietf.org wrote: >>>> > >>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 : Group Key Management Architecture >>>> > >> Author(s) : M. Baugher, R. Canetti, L. Dondeti >>>> > >> Filename : draft-ietf-msec-gkmarch-00.txt >>>> > >> Pages : 22 >>>> > >> Date : 26-Jun-01 >>>> > >> >>>> > >>This document presents a group key-management architecture for MSEC. >>>> > >>The purpose of this document is to define the common architecture for >>>> > >>MSEC group key-management protocols that support a variety of >>>> > >>application, transport, and internetwork security protocols. To >>>> > >>address these diverse uses, MSEC may need to standardize two or more >>>> > >>group key management protocols that have common requirements, >>>> > >>abstractions, overall design, and messages. The framework and >>>> > >>guidelines in this document allow for a modular and flexible design of >>>> > >>group key management protocols for a variety different settings that >>>> > >>are specialized to application needs. >>>> > >> >>>> > >>A URL for this Internet-Draft is: >>>> > >>>>> > h t tp://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.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-gkmarch-00.txt". >>>> > >> >>>> > >>A list of Internet-Drafts directories can be found in >>>> > >>http://www.ietf.org/shadow.html >>>> > >>or >>>> > >>ftp://ftp.ietf.org/ietf/ >>>> 1 s h adow-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-gkmarch-00.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: <20010626132202.I-D@ietf.org> >>>> >>>> >>>>_______________________________________________ >>>>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 Thu Jun 28 15:43:25 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23184 for ; Thu, 28 Jun 2001 15:43:24 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6D5C3536F9; Thu, 28 Jun 2001 15:42: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 2FA6F53555 for ; Thu, 28 Jun 2001 15:40:28 -0400 (EDT) Received: (qmail 57931 invoked by uid 3269); 28 Jun 2001 19:40:27 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 57928 invoked from network); 28 Jun 2001 19:40:27 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 28 Jun 2001 19:40:27 -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 f5SJdwx28118; Thu, 28 Jun 2001 12:40:03 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-449.cisco.com [10.21.65.193]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADG13946; Thu, 28 Jun 2001 12:39:49 -0700 (PDT) Message-Id: <4.3.2.7.2.20010628122635.041f70b8@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.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: Thu, 28 Jun 2001 12:39:19 -0700 Hugh, At 02:41 PM 6/28/2001 -0400, Hugh Harney wrote: >Given the above condition, I suggested the following be added to the GDOI >Internet Draft. This second GDOI quote (below) constitutes a criteria I >believe could make the above GDOI assumption work in a secure system. For those who have not read GDOI, the quote below IS from the current GDOI I-D. > >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. > > >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. > >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. There is ALWAYS an external policy infrastructure. And there will always be some policy in key management. I'd prefer to limit that to items that are directly pertinent to key management operation. There are policy issues outside of key management that are important such as "who are the members of this group?" or "what's this member's USPO zipcode?" that might play a crucial role for some participant receiving or sending to a particular group, but which SHOULD NOT be handled through the key management protocol in my opinion. Similarly, the policy issue such as "you must encrypt all communications with the GCKS with AES" is something that CANNOT be handled through the key management protocol. gkmarch states this in 4.1. Best Regards, Mark >Note: Read words written in capital letters as Boolean. > >I believe MSec security policy is important to key management. I believe >that internal or external means can supply that policy to the group. I >don't believe the MSec architecture should exclude key management >approaches that provide policy mechanisms internal to the key management >protocols. > >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 Thu Jun 28 15:47:19 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25803 for ; Thu, 28 Jun 2001 15:47:18 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1C031535D8; Thu, 28 Jun 2001 15:47: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 3A4DB53599 for ; Thu, 28 Jun 2001 15:45:54 -0400 (EDT) Received: (qmail 58447 invoked by uid 3269); 28 Jun 2001 19:45:53 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 58444 invoked from network); 28 Jun 2001 19:45:53 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 28 Jun 2001 19:45:53 -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 f5SJjH814860; Thu, 28 Jun 2001 15:45:17 -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 PAA26660; Thu, 28 Jun 2001 15:45:15 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id PAA08258; Thu, 28 Jun 2001 15:45:15 -0400 From: Ran Canetti Message-Id: <200106281945.PAA08258@ornavella.watson.ibm.com> To: acc@columbia.sparta.com, msec@securemulticast.org Subject: Re: [MSEC] Re: I-D ACTION:draft-ietf-msec-gkmarch-00.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: Thu, 28 Jun 2001 15:45:15 -0400 Andrea, this is indeed an unfortunate typo. Please replace the word "MSEC" with "The GKM protocol". Indeed, the GKM protocol does not handle policy negotiations and assumes that the policy is already set when the protocol runs, or alternatively policy is "downloaded" from the KDC to the members in an apporpriate policy token. Policy determination will be described, I hope, in the upcoming policy architecture draft. Ran > > 12. > > > MSEC assumes that at least the following group-policy information is > > externally managed. > > o Group owner, authentication method, and delegation method for > > identifying a KDC for the group > > o Group KDC, authentication method, and any method used for > > delegating other KDCs for the group > > o Group membership rules or list and authentication method > > > > These assumptions are unnecessary as was shown by GSAKMP. > I. While the group owner may be published externally, the group owner can also > be disclosed during the registration protocol. It can be decided during this time > whether the owner is acceptable prior to completion of registration. Once this > occurs, authenticated group policy can be conveyed to the new member using > traditional mechanisms such as digital signatures tied to a PKI. > II. The delegation can be stated (authorized) through the authenticated policy > statement as was done with GSAKMP. > III. Ditto for membership rules and lists > IV. The security association characteristics of the registration protocol can > be determined early in the registration exchange or in almost all protocols (TLS, > IPSec, GSAKMP, etc.) can be restricted by what properties the Key Server will > accept using cipher suite restrictions, SPD constraints, etc. > > External management of these can be done, but should not be assumed in the > architecture document. > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jun 28 15:51:21 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28766 for ; Thu, 28 Jun 2001 15:51:20 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 89EDA536FF; Thu, 28 Jun 2001 15:51:31 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 8C4C1536F9 for ; Thu, 28 Jun 2001 15:48:47 -0400 (EDT) Received: (qmail 58749 invoked by uid 3269); 28 Jun 2001 19:48:47 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 58745 invoked from network); 28 Jun 2001 19:48:46 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 28 Jun 2001 19:48:46 -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 f5SJmG819648 for ; Thu, 28 Jun 2001 15:48:16 -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 PAA26692 for ; Thu, 28 Jun 2001 15:48:16 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id PAA06318 for msec@securemulticast.org; Thu, 28 Jun 2001 15:48:15 -0400 From: Ran Canetti Message-Id: <200106281948.PAA06318@ornavella.watson.ibm.com> To: msec@securemulticast.org Subject: [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: Thu, 28 Jun 2001 15:48:15 -0400 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 From msec-admin@securemulticast.org Thu Jun 28 15:56:21 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA02159 for ; Thu, 28 Jun 2001 15:56:20 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 88AF65369A; Thu, 28 Jun 2001 15:56: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 B758F53617 for ; Thu, 28 Jun 2001 15:54:45 -0400 (EDT) Received: (qmail 59531 invoked by uid 3269); 28 Jun 2001 19:54:45 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 59528 invoked from network); 28 Jun 2001 19:54:45 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 28 Jun 2001 19:54:45 -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 f5SJsE818902 for ; Thu, 28 Jun 2001 15:54:14 -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 PAA23834 for ; Thu, 28 Jun 2001 15:54:14 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id PAA34686 for msec@securemulticast.org; Thu, 28 Jun 2001 15:54:14 -0400 From: Ran Canetti Message-Id: <200106281954.PAA34686@ornavella.watson.ibm.com> To: msec@securemulticast.org Subject: [MSEC] The new GKM architecture 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, 28 Jun 2001 15:54:14 -0400 *my apology for the potential double posting - my previous posting of this note seems to have gotten lost somewhere... * Folks, [For the purpose of this discussion I am taking my "co-chair hat" off, and writing as a document editor.] I had planned this mail to precede the publication of the GKM architecture draft, but did not make it in time. My apologies. The goal of this draft is to provide a common framework for various key management protocols (including GDOI, GSAKMP with its many options, and potentially others). The main thesis of this architecture is to separate between the the following two components of group key management: o The "registration protocol" (ie, the unicast protocol between a joining member and the KDC). o The "rekey protocol" (ie, the protocol in which the KDC sends update messages to current group members). The draft states that the two protocols can be separate and need not be "bundles up". This allows for greater flexibility: Once can decide whether to do IKE/IPSEC/TLS-based registration without changing the rekey protocol. Similarly, one can decide on different rekey protocols (OFE/LKH/Others, or to not rekey at all, as [MARKS] does), again without affecting the registration protocol. The obvious issue here is how will the necessary information will be communicated from the registration protocol to the rekey protocol to the data-security protocol. This will be done via the following security associations (which are regarded as databases sitting inside each member): o The "rekey SA". This SA is potentially initialized by the registration protocol and is used and updated by the rekey protocol. o The "data SA". This SA is potentially initialized by the registration protocol, is updated by the rekey protocol, and is used by the data security protocol. This is the main framework of the suggested architecture. There are many more details; please see the draft. When reading, please keep in mind that this is a preliminary draft, and post any remarks you have to the list. We will update it accordingly. Best, Ran Some remarks: 1. Note that the rekey SA is not mandatory - if the policy does not use rekeys then this SA is redundant. 2. Note that the data SA need not necessarily be initialized by the registration protocol. One can think of a scenario where a member registers in advance to actually joining the group, and the actual initialization of the dat SA is done at a later time by the rekey protocol. 3. Note that the "cat 1 SA" (or, registration SA) does not appear in the above description at all. Indeed, this SA is internal to the registration protocol and therefore does not need to be specified/dicussed in this architectural document. It is up to the registration protocol. 4. A word on the issue of distributed versus centralized KDC. It seems to me that the distinction between the two cases is to a large extent "transparent" for the GKM architecture draft. Indeed, the draft specifies two protocols (registration and rekey). These protocols would remain unchanged regarless of whether all members run the protocol with the same KDC or alternatively different members talk to different KDC's. Same goes for the rekey protocol. So, in other words, the decision of whether to have a distribued or centralized KDC architecture is up to the group manager and is "transparent" to the KGM architecture and to the group members. 5. Neither of the current proposals for key management - GDOI and GSAKMP - are compatible with this architecture, since they bundle the rekey protocol within the registration protocol. Both will need to be modified accordingly if this architecture is to be accepted by msec. The big benefit is that both protocols will be able to co-exist within one framework. 6. A separate draft on the rekey protocol is currently being written by Lakshminath Dondeti and David Mcgrew. Hopefully it will be available soon. 7. There is another issue which I wanted to bring up - a possible "de-registration" protocol. We discussed this issue among the authors of this draft and decided to bring it up to the list. But I'll defer this issue to a differnt message. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jun 28 16:06:12 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09165 for ; Thu, 28 Jun 2001 16:06:11 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id EC4C153617; Thu, 28 Jun 2001 16:06: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 609C753616 for ; Thu, 28 Jun 2001 16:04:24 -0400 (EDT) Received: (qmail 60443 invoked by uid 3269); 28 Jun 2001 20:04:24 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 60436 invoked from network); 28 Jun 2001 20:04:23 -0000 Received: from m5.sparta.com (root@157.185.61.1) by klesh.pair.com with SMTP; 28 Jun 2001 20:04:23 -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 f5SK4Mx04759; Thu, 28 Jun 2001 15:04:22 -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 QAA27653; Thu, 28 Jun 2001 16:04:20 -0400 (EDT) Message-Id: <4.2.2.20010628153600.00b245d0@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.20010628122635.041f70b8@mira-sjc5-6.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: Thu, 28 Jun 2001 15:50:17 -0400 Mark, >There is ALWAYS an external policy infrastructure. And there will always >be some policy in key management. I'd prefer to limit that to items that >are directly pertinent to key management operation. There are policy >issues outside of key management that are important such as "who are the >members of this group?" or "what's this member's USPO zipcode?" that might >play a crucial role for some participant receiving or sending to a >particular group, but which SHOULD NOT be handled through the key >management protocol in my opinion. Similarly, the policy issue such as >"you must encrypt all communications with the GCKS with AES" is something >that CANNOT be handled through the key management protocol. gkmarch >states this in 4.1. Your correct there is always a certificate infrastructure at the bare minimum. I think our only difference of opinion is what policy information is relevant to key management. My opinion is that policy should be considered relevant to the key management protocol, if omission of that policy would lead to a security attack on the key management system. Stated another way, security policy for key management must be sufficient to ensure verifiably secure key is available for data encryption/authorization. I do not imply how that policy information is verified or disseminated. In the key management protocol or via a trusted infrastructure outside of the key management protocol. I guess the challenge ahead of us is figuring out which policy items are important for key management. I look forward to working these issues through with you in the future. We should probably write a document together, I'd also include Patrick McDaniel, and or Pete Dinsmore. Figuring out which data is important is the first step. Then we can figure out how to deal with that data and the security requirements on key management protocols and/or trusted policy infrastructures. I've had ample input to the policy document that is coming out soon. Perhaps you can review that document and it can serve as a spring board for a joint effort. Unfortunately, the security policy data that is relevant to a key management protocol is highly dependant on the architecture that protocol exists in and the application that protocol supports. Ultimately, our job is to provide verifiably good key to algorithms for protection of data. Any document we write must also define the architecture and the application assumed. 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 Thu Jun 28 16:18:24 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17638 for ; Thu, 28 Jun 2001 16:18:23 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A921A53622; Thu, 28 Jun 2001 16:18: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 3037853622 for ; Thu, 28 Jun 2001 16:15:45 -0400 (EDT) Received: (qmail 61830 invoked by uid 3269); 28 Jun 2001 20:15:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 61825 invoked from network); 28 Jun 2001 20:15:44 -0000 Received: from softdnserror (HELO M5.sparta.com) (root@157.185.61.1) by klesh.pair.com with SMTP; 28 Jun 2001 20:15:44 -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 f5SKFex05200 for ; Thu, 28 Jun 2001 15:15:40 -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 QAA27744 for ; Thu, 28 Jun 2001 16:15:36 -0400 (EDT) Message-ID: <3B3B905A.57F5DC4F@columbia.sparta.com> From: Andrea Colegrove X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: msec@securemulticast.org Subject: [Fwd: [MSEC] Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt] Content-Type: multipart/mixed; boundary="------------86F4EADB39B9849F02F79FA7" 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, 28 Jun 2001 16:15:22 -0400 This is a multi-part message in MIME format. --------------86F4EADB39B9849F02F79FA7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------86F4EADB39B9849F02F79FA7 Content-Type: message/rfc822 Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <3B3B902A.2DBED04B@columbia.sparta.com> Date: Thu, 28 Jun 2001 16:14:35 -0400 From: Andrea Colegrove X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Baugher Subject: Re: [MSEC] Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt References: <200106271103.HAA26170@ietf.org> <4.3.2.7.2.20010627202552.0433d4c8@mira-sjc5-6.cisco.com> Content-Type: multipart/alternative; boundary="------------4844BFE6773BF532BA370061" --------------4844BFE6773BF532BA370061 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark, > How about if we change the offending paragraph as follows: > security services. For these reasons, application, transport, and > internetwork-layer security protocols such as SRTP, IPsec, and AMESP > may benefit from using different group key management systems [GSAKMP, > GDOI]. Extensions to IKE, however, are probably the best solution for > IPsec protocols over IP multicast services [GDOI]. The purpose of > this > Yes there is definitely the "one size fits all" vs. the per-security application approach. It is appropriate to state this in the intro. Please just remove the opinion of what you feel is the best solution for IPSec. Group and multicast applications have diverse requirements in IP networks [CP00]. Their key-management requirements, which are briefly reviewed below (see "Requirements"), include support for internetwork, transport, and application-layer protocols. In particular, while Internet-standard ISAKMP and IKE protocols purport to manage keys for any and all services in a host, some applications may achieve simpler operation by running key-management messaging over TLS or IPsec security services. For these reasons, application, transport, and internetwork-layer security protocols such as SRTP, IPsec, and AMESP may benefit from using different group key management systems. The purpose of this document is to define a common architecture and design for these different group key-management protocols. > A "group key management protocol" ensures that > only > members of a secure group gain access to group data (by gaining access > to group keys) and can authenticate group > data. > > I'm looking forward to the I-D on security management protocols and prefer to stick to key management protocols in this I-D > The statement above is incorrect however. It is only though key management in conjuction with security association management, access control, and authorization (i.e., security management) that ensures this property. (KM is probably necessary but not sufficient, etc, etc.) >> > 4. The key-management protocol must be secure against man-in-the- >> > middle, connection-hijacking, and reflection/replay attacks; >> > it must >> > use best-known practices to thwart denial-of-service >> > attacks. >> > >> And type attacks. And attacks resulting from lack of explicitness >> (mis-routed, mis-interpreted). And interleaved with other protocols >> (protocol-oracle), etc. Perhaps it would be better to generalize >> this statement. > > > Would you please provide references for these attacks? > Sure. For starters check Clark and Jacob's "Security Protocols: An Annotated Bibliography", Abadi and Needham's"Prudent Engineering Practice for Cryptographic Protocol", Ulf Carlsen's "Cryptographic Protocol Flaws." Ross Anderson also has a good paper that applies to public key protocols and Schneier (and Wagner?) have one on multiprotocol attacks. My point was only that it might be better to generalize than to list. >> 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." > > > Not in IKE it isn't. Again, I await the I-D on the security > management protocol. > IKE says: A security association (SA) is a set of policy and key(s) used to protect information. The ISAKMP SA is the shared policy and key(s) used by the negotiating peers in this protocol to protect their communication. Access control and delegation are two of the assumptions that pairwise communication does not need to consider: You know who you are going to talk to (your peer), you will only communicate if both your policies (SPDs) allow it, and you figure that they are authorized to negotiate on behalf of themselves. There is a lot of policy involved in IKE. The rest of the security association is certainly not just meta-data describing the keys. >> 5. Re: video on demand example. The example shows a pre-existing >> group of all possible members subject to pre-broadcast rekey. One >> broadcast would destroy this property. > > > What is the property that would be destroyed? What exactly is the > problem? > > The example wasn't clear to me but it appeared that you were stating that the potential audience was a group and requirement 6 (rekey) supported the access control to video broadcasts. If this is what you meant, then each time some of the members were excluded from a broadcast, a smaller potential audience resulted for the next one. > > >> 6. >> >> > >> > >> > >> > A centralized >> > group controller (or KDC) that is used in this architecture may not be >> > the best design for small, interactive groups. But for large, >> > single- >> > source multicast groups, it is generally undesirable to distribute key >> > management functions among group members: Unlike small, interactive >> > groups, large single-source multicast groups generally need a >> > specialized KDC to support large numbers of group members. Large >> > distributed simulations, moreover, may combine the need for large-grou >> > operation with many >> > senders. >> > >> Large groups require distributed initial key distribution! Large >> dynamic groups cannot rely upon a centralized KDC. This does not >> scale. This is highly inflexible. The VoD example demonstrates >> this. > "But for large, single- source multicast groups, it is generally undesirable to distribute key management functions among group members" Please support this with evidence. Also, wouldn't it be best to just discuss the requirements and design constraints but not suggest solutions here? >> 8. >> >> > >> > >> > >> > This design is based upon a "group controller" model >> > [RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group >> > owner as the root-of-trust. The group owner designates a key >> > distribution center for member registration and >> > re-key. >> > >> As was originally envisioned, the group owner CAN (and for large or >> sparse groups SHOULD) designate multiple key servers. > > > The architecture recommends that this be done by allowing any key > server to serve keys that is authorized to do so by the group owner. > The most straightforward way to do this is to use SPKI or X.509 > delegation. That's what we are recommending rather than coding this > up in the key management protocol. > It is fair to say that the key server must provide proof of delegation. I _believe_ SPKI (SDSI) delegation is not widely used, but cannot support this. X. 509 attributes is a fair way of doing this, but is only one way. Whether it is more straightforward is a matter of opinion. >> 9. Section 3.2 -- The term TEK is inappropriately specific. The >> group may not have encryption requirements, but only authentication. > > > TEK has a long history in the group key management literature. But > you have a point, it may not be needed for authentication. We need to > review this. > TEK = Traffic ENCRYPTION Key. And yes, this term goes back way before open literature even. >> 11. >> >> > >> > >> > >> > The KDC, moreover, can be delegated when the >> > trust infrastructure supports delegation to permit distributed >> > operation of the >> > KDC. >> > >> This statement, while correct, seems to conflict with the statement >> quoted in Comment #6. > > > Comment #6 was citing a requirements discussion. now we are into > design. There are ways to load balance, get high-availability, and > get fault tolerance for a server without inventing distributed key > server protocols (such as a leader election algorithm, inter-KDC > protocols). > > Okay. The design is inconsistent with the requirement? Load sharing is certainly different than delegation -- I am not sure what your point is. > > >> 12. >> >> > >> > >> > >> > MSEC assumes that at least the following group-policy information >> > is >> > externally managed. >> > o Group owner, authentication method, and delegation method for >> > identifying a KDC for the group >> > o Group KDC, authentication method, and any method used for >> > delegating other KDCs for the group >> > o Group membership rules or list and authentication >> > method >> > >> These assumptions are unnecessary as was shown by GSAKMP. > > > These assumptions were put into the GDOI draft at Hugh's behest and it > helped clarify our thinking on how to minimize group policy functions > in key management. I recommended to Ran and Lakshminath that we > consider including these assumptions in the GKM architecture I-D. > They agreed and Lakshminath did that. If we don't do that, then we > will encumber the key management specification with a lot of policy > issues that the working group has agreed belonged in a policy draft. > You may not agree with everything the WG decides to do. WGs are like > that. > Oh are you the working group? Just because it is an appropriate assumption for GDOI does make it appropriate for all. > > >> I. While the group owner may be published externally, the group >> owner can also be disclosed during the registration protocol. It >> can be decided during this time whether the owner is acceptable >> prior to completion of registration. Once this occurs, >> authenticated group policy can be conveyed to the new member using >> traditional mechanisms such as digital signatures tied to a PKI. >> II. The delegation can be stated (authorized) through the >> authenticated policy statement as was done with GSAKMP. >> III. Ditto for membership rules and lists >> IV. The security association characteristics of the >> registration protocol can be determined early in the registration >> exchange or in almost all protocols (TLS, IPSec, GSAKMP, etc.) can >> be restricted by what properties the Key Server will accept using >> cipher suite restrictions, SPD constraints, etc. >> >> External management of these can be done, but should not be >> assumed in the architecture document. >> >> 13. In general, this document contains very little new >> information. The framework for the architecture was already >> provided by the building block documents with the category 1,2, and >> 3 SAs. The architecture document should work toward providing >> interoperable solutions. > > > We're not shooting for novelty here. Quite the contrary. The I-D is > to progress as a product of the msec WG in order to bring two or more > key management protocols to address common requirements, use common > abstractions, and messages. These two or more protocols cannot > interoperate unless they at least use a common header. GDOI uses an > ISAKMP header for obvious reasons. GSAKMP does not use an ISAKMP > header. If they could interoperate, then we would not go to the > trouble of specifying two or more key management protocols. > The requirements need to drive the protocol selection not the other way around. Common abstractions are good, common messages imply a common protocol. --- Andrea --------------4844BFE6773BF532BA370061 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Mark,
How about if we change the offending paragraph as follows:
security services.  For these reasons, application, transport, and internetwork-layer security protocols such as SRTP, IPsec, and AMESP may benefit from using different group key management systems [GSAKMP, GDOI]. Extensions to IKE, however, are probably the best solution for IPsec protocols over IP multicast services [GDOI].  The purpose of this
 
Yes there is definitely the "one size fits all" vs. the per-security application approach.  It is appropriate to state this in the intro.  Please just remove the opinion of what you feel is the best solution for IPSec.

Group and multicast applications have diverse requirements in IP
networks [CP00].  Their key-management requirements, which are briefly
reviewed below (see "Requirements"), include support for internetwork,
transport, and application-layer protocols.  In particular, while
Internet-standard ISAKMP and IKE protocols purport to manage keys for
any and all services in a host, some applications may achieve simpler
operation by running key-management messaging over TLS or IPsec
security services.  For these reasons, application, transport, and
internetwork-layer security protocols such as SRTP, IPsec, and AMESP
may benefit from using different group key management systems. The purpose of this document is to define a common architecture and design for these different group key-management protocols. 

 A "group key management protocol" ensures that
    only 
    members of a secure group gain access to group data (by gaining access 
    to group keys) and can authenticate group
    data.
I'm looking forward to the I-D on security management protocols and prefer to stick to key management protocols in this I-D
The statement above is incorrect however.  It is only though key management in conjuction with security association management, access control, and authorization (i.e., security management) that ensures this property.  (KM is probably necessary but not sufficient, etc, etc.) 
4. The key-management protocol must be secure against man-in-the-
   middle, connection-hijacking, and reflection/replay attacks;
it must
   use best-known practices to thwart denial-of-service
attacks.
And type attacks.  And attacks resulting from lack of explicitness (mis-routed, mis-interpreted).  And interleaved with other protocols (protocol-oracle), etc.  Perhaps it would be better to generalize this statement.


Would you please provide references for these attacks?
 

Sure.  For starters check Clark and Jacob's "Security Protocols:  An Annotated Bibliography", Abadi and Needham's"Prudent Engineering Practice for Cryptographic Protocol", Ulf Carlsen's "Cryptographic Protocol Flaws."  Ross Anderson also has a good paper that applies to public key protocols and Schneier (and Wagner?) have one on multiprotocol attacks.

My point was only that it might be better to generalize than to list.

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."


Not in IKE it isn't.  Again, I await the I-D on the security management protocol.
 

IKE says:
A security association (SA) is a set of policy and key(s) used to protect information. The ISAKMP
    SA is the shared policy and key(s) used by the negotiating peers in this protocol to protect their
    communication.

Access control and delegation are two of the assumptions that pairwise communication does not need to consider:  You know who you are going to talk to (your peer), you will only communicate if both your policies (SPDs) allow it, and you figure that they are authorized to negotiate on behalf of themselves.

There is a lot of policy involved in IKE.  The rest of the security association is certainly not just meta-data describing the keys.

5.  Re:  video on demand example.   The example shows a pre-existing group of all possible members subject to pre-broadcast rekey.  One broadcast would destroy this property.


What is the property that would be destroyed?  What exactly is the problem?
 
 

The example wasn't clear to me but it appeared that you were stating that the potential audience was a group and requirement 6 (rekey) supported the access control to video broadcasts.  If this is what you meant, then each time some of the members were excluded from a broadcast, a smaller potential audience resulted for the next one.
 
6.
 
  
A centralized
group controller (or KDC) that is used in this architecture may not be 
the best design for small, interactive groups.  But for large,
single-
source multicast groups, it is generally undesirable to distribute key 
management functions among group members: Unlike small, interactive 
groups, large single-source multicast groups generally need a 
specialized KDC to support large numbers of group members.  Large 
distributed simulations, moreover, may combine the need for large-grou 
operation with many
senders.
Large groups require distributed initial key distribution!  Large dynamic groups cannot rely upon a centralized KDC.  This does not scale.  This is highly inflexible.  The VoD example demonstrates this.
"But for large,
single-
source multicast groups, it is generally undesirable to distribute key 
management functions among group members"

Please support this with evidence.  Also, wouldn't it be best to just discuss the requirements and design constraints but not suggest solutions here?

8.
 
  
This design is based upon a "group controller" model 
[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group 
owner as the root-of-trust.  The group owner designates a key 
distribution center for member registration and
re-key.
As was originally envisioned, the group owner CAN (and for large or sparse groups SHOULD) designate multiple key servers.


The architecture recommends that this be done by allowing any key server to serve keys that is authorized to do so by the group owner.  The most straightforward way to do this is to use SPKI or X.509 delegation.  That's what we are recommending rather than coding this up in the key management protocol.
 

It is fair to say that the key server must provide proof of delegation.  I _believe_ SPKI (SDSI) delegation is not widely used, but cannot support this.  X. 509 attributes is a fair way of doing this, but is only one way.  Whether it is more straightforward is a matter of opinion.
9.  Section 3.2 -- The term TEK is inappropriately specific.  The group may not have encryption requirements, but only authentication.


TEK has a long history in the group key management literature.  But you have a point, it may not be needed for authentication.  We need to review this.
 

TEK = Traffic ENCRYPTION Key.  And yes, this term goes back way before open literature even.
11.
 
  
The KDC, moreover, can be delegated when the 
trust infrastructure supports delegation to permit distributed 
operation of the
KDC.
This statement, while correct, seems to conflict with the statement quoted in Comment #6.


Comment #6 was citing a requirements discussion.  now we are into design.  There are ways to load balance, get high-availability, and get fault tolerance for a server without inventing distributed key server protocols (such as a leader election algorithm, inter-KDC protocols).
 
 

Okay.  The design is inconsistent with the requirement?
Load sharing is certainly different than delegation -- I am not sure what your point is.
 
12.
 
  
MSEC assumes that at least the following group-policy information
is
externally managed.
  o Group owner, authentication method, and delegation method for 
    identifying a KDC for the group
  o Group KDC, authentication method, and any method used for
    delegating other KDCs for the group
  o Group membership rules or list and authentication
method
These assumptions are unnecessary as was shown by GSAKMP.


These assumptions were put into the GDOI draft at Hugh's behest and it helped clarify our thinking on how to minimize group policy functions in key management.   I recommended to Ran and Lakshminath that we consider including these assumptions in the GKM architecture I-D.  They agreed and Lakshminath did that.  If we don't do that, then we will encumber the key management specification with a lot of policy issues that the working group has agreed belonged in a policy draft.  You may not agree with everything the WG decides to do.  WGs are like that.
 

Oh are you the working group?
Just because it is an appropriate assumption for GDOI does make it appropriate for all.
 
    I.  While the group owner may be published externally, the group owner can also be disclosed during the registration protocol.  It can be decided during this time whether the owner is acceptable prior to completion of registration.  Once this occurs, authenticated group policy can be conveyed to the new member using traditional mechanisms such as digital signatures tied to a PKI.
    II.  The delegation can be stated (authorized) through the authenticated policy statement as was done with GSAKMP.
    III.  Ditto for membership rules and lists
    IV.  The security association characteristics of the registration protocol can be determined early in the registration exchange or in almost all protocols (TLS, IPSec, GSAKMP, etc.) can be restricted by what properties the Key Server will accept using cipher suite restrictions, SPD constraints, etc.

    External management of these can be done, but should not be assumed in the architecture document.

13.  In general, this document contains very little new information.  The framework for the architecture was already provided by the building block documents with the category 1,2, and 3 SAs.  The architecture document should work toward providing interoperable solutions.


We're not shooting for novelty here.  Quite the contrary.  The I-D is to progress as a product of the msec WG in order to bring two or more key management protocols to address common requirements, use common abstractions, and messages.  These two or more protocols cannot interoperate unless they at least use a common header.  GDOI uses an ISAKMP header for obvious reasons.  GSAKMP does not use an ISAKMP header. If they could interoperate, then we would not go to the trouble of specifying two or more key management protocols.
 

The requirements need to drive the protocol selection not the other way around.
Common abstractions are good, common messages imply a common protocol.

--- Andrea --------------4844BFE6773BF532BA370061-- --------------86F4EADB39B9849F02F79FA7-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jun 28 16:43:34 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05314 for ; Thu, 28 Jun 2001 16:43:33 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8F03E5371B; Thu, 28 Jun 2001 16:39: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 454B953639 for ; Thu, 28 Jun 2001 15:12:02 -0400 (EDT) Received: (qmail 55232 invoked by uid 3269); 28 Jun 2001 19:12:02 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 55229 invoked from network); 28 Jun 2001 19:12:01 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 28 Jun 2001 19:12:01 -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 f5SJBU815068 for ; Thu, 28 Jun 2001 15:11: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 PAA18180 for ; Thu, 28 Jun 2001 15:11:31 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id PAA32920 for msec@securemulticast.org; Thu, 28 Jun 2001 15:11:30 -0400 From: Ran Canetti Message-Id: <200106281911.PAA32920@ornavella.watson.ibm.com> To: msec@securemulticast.org Subject: [MSEC] The new GKM architecture 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, 28 Jun 2001 15:11:30 -0400 Folks, [For the purpose of this discussion I am taking my "co-chair hat" off, and writing as a document editor.] I had planned this mail to precede the publication of the GKM architecture draft, but did not make it in time. My apologies. The goal of this draft is to provide a common framework for various key management protocols (including GDOI, GSAKMP with its many options, and potentially others). The main thesis of this architecture is to separate between the the following two components of group key management: o The "registration protocol" (ie, the unicast protocol between a joining member and the KDC). o The "rekey protocol" (ie, the protocol in which the KDC sends update messages to current group members). The draft states that the two protocols can be separate and need not be "bundles up". This allows for greater flexibility: Once can decide whether to do IKE/IPSEC/TLS-based registration without changing the rekey protocol. Similarly, one can decide on different rekey protocols (OFE/LKH/Others, or to not rekey at all, as [MARKS] does), again without affecting the registration protocol. The obvious issue here is how will the necessary information will be communicated from the registration protocol to the rekey protocol to the data-security protocol. This will be done via the following security associations (which are regarded as databases sitting inside each member): o The "rekey SA". This SA is potentially initialized by the registration protocol and is used and updated by the rekey protocol. o The "data SA". This SA is potentially initialized by the registration protocol, is updated by the rekey protocol, and is used by the data security protocol. This is the main framework of the suggested architecture. There are many more details; please see the draft. When reading, please keep in mind that this is a preliminary draft, and post any remarks you have to the list. We will update it accordingly. Best, Ran Some remarks: 1. Note that the rekey SA is not mandatory - if the policy does not use rekeys then this SA is redundant. 2. Note that the data SA need not necessarily be initialized by the registration protocol. One can think of a scenario where a member registers in advance to actually joining the group, and the actual initialization of the dat SA is done at a later time by the rekey protocol. 3. Note that the "cat 1 SA" (or, registration SA) does not appear in the above description at all. Indeed, this SA is internal to the registration protocol and therefore does not need to be specified/dicussed in this architectural document. It is up to the registration protocol. 4. A word on the issue of distributed versus centralized KDC. It seems to me that the distinction between the two cases is to a large extent "transparent" for the GKM architecture draft. Indeed, the draft specifies two protocols (registration and rekey). These protocols would remain unchanged regarless of whether all members run the protocol with the same KDC or alternatively different members talk to different KDC's. Same goes for the rekey protocol. So, in other words, the decision of whether to have a distribued or centralized KDC architecture is up to the group manager and is "transparent" to the KGM architecture and to the group members. 5. Neither of the current proposals for key management - GDOI and GSAKMP - are compatible with this architecture, since they bundle the rekey protocol within the registration protocol. Both will need to be modified accordingly if this architecture is to be accepted by msec. The big benefit is that both protocols will be able to co-exist within one framework. 6. A separate draft on the rekey protocol is currently being written by Lakshminath Dondeti and David Mcgrew. Hopefully it will be available soon. 7. There is another issue which I wanted to bring up - a possible "de-registration" protocol. We discussed this issue among the authors of this draft and decided to bring it up to the list. But I'll defer this issue to a differnt message. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jun 28 16:48:25 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08737 for ; Thu, 28 Jun 2001 16:48:24 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1807B5368D; Thu, 28 Jun 2001 16:46:14 -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 2956853735 for ; Thu, 28 Jun 2001 16:42:21 -0400 (EDT) Received: (qmail 64287 invoked by uid 3269); 28 Jun 2001 20:42:20 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 64284 invoked from network); 28 Jun 2001 20:42:20 -0000 Received: from m5.sparta.com (root@157.185.61.1) by klesh.pair.com with SMTP; 28 Jun 2001 20:42:20 -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 f5SKgJx06070; Thu, 28 Jun 2001 15:42:19 -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 QAA27939; Thu, 28 Jun 2001 16:42:17 -0400 (EDT) Message-ID: <3B3B969B.DD17C361@columbia.sparta.com> From: Andrea Colegrove X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ran Canetti , msec@securemulticast.org Subject: Re: [MSEC] [Fwd: [Fwd: I-D ACTION:draft-ietf-msec-gkmarch-00.txt]] References: <200106281801.OAA08228@ornavella.watson.ibm.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: Thu, 28 Jun 2001 16:42:03 -0400 Content-Transfer-Encoding: 7bit Hi, Ran, Yes I agree that GDOI works well with IPSec and as far as I am aware, GDOI is the only extension to IKE for groups right now (although you can argue the GSAKMP is an extension to ISAKMP). If it is a requirement that ESP/AH be serviced without modification to IPSec that would probably be suitable for the requirements section without reference I think to either GSAKMP or to GDOI -- once again leaving room for the ACME protocol ;-) Many of the assumptions in the document are rather GDOI-specific, especially the policy assumptions. It will be a difficult process for the WG as a whole to create an independent document that will not limit new protocols unnecessarily. Hopefully, we are now on our way :-) --- Andrea Ran Canetti wrote: > Andrea, > > Regarding the "offending sentence" in the intro of the new architecture draft: > > > Extensions to IKE, however, are probably the best solution for IPsec > > protocols over IP multicast services [GDOI]. > > I agree with you that the sentence is poorly phrased and invites > misinterpretation. It should be rewreitten. Our meaning was to say that > That one of the requirements of the architecture is to enable a GKM protocol > that allows ESP/AH to work within the MSEC protocol suite without any changes. > This is an important requirement. The reference to GDOI is there since GDOI > took it up as an explcit goal to provide this functionality, so the meaning was to > give it as an example. But GDOI is certainly not the only example. In particular, > I am certain that a resolution of GSAKMP with IPSEC for the registration protocol > would be able to provide the same functionality. > Do you agree with this view of things? > > Regarding your note below, I think you're missing some salient points in the new > draft. (And this ofcourse immediately reflects on the authors, who apparently did > a poor job of explaining these points.) In particular, it is NOT compatible with > the current GDOI draft, and GDOI will have to change to fit this document. I'll > try to provide more details later today or to morrow. So please hold your fire... > > Ran > > > From: Andrea Colegrove > > > > Mark, > > The architecture document is for specification and discussion of technical > > issues -- not opinion -- that is the issue at hand. The document has been written > > as a summary of the BBs with additional constraints and assumptions that are not > > necessary except that GDOI seems to make these assumptions. This is a fairness > > issue. > > The "title" of editor sometimes seems more appropriate as the specifications > > that are on standards track should reflect the combined interests of the working > > group -- it is not intended to be honorary or to detract, but merely a reflection > > of the responsibilities of the writers of the documents. > > I, too, gave technical arguments as to why GDOI may not be the perfect fit. It > > is not a bad solution, but let us also leave room for the ACME Group Security > > Management Protocol which Joe Schmo has yet to specify. > > > > --- Andrea > > > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jun 28 16:52:40 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11685 for ; Thu, 28 Jun 2001 16:52:39 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B7BAA53577; Thu, 28 Jun 2001 16:52: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 976F653578 for ; Thu, 28 Jun 2001 16:51:03 -0400 (EDT) Received: (qmail 65086 invoked by uid 3269); 28 Jun 2001 20:51:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 65083 invoked from network); 28 Jun 2001 20:51:02 -0000 Received: from m5.sparta.com (root@157.185.61.1) by klesh.pair.com with SMTP; 28 Jun 2001 20:51:02 -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 f5SKp0x06371; Thu, 28 Jun 2001 15:51:01 -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 QAA28033; Thu, 28 Jun 2001 16:50:58 -0400 (EDT) Message-ID: <3B3B98A4.B76BE201@columbia.sparta.com> From: Andrea Colegrove X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Hardjono , msec@securemulticast.org Subject: Re: [MSEC] Re: [Fwd: I-D ACTION:draft-ietf-msec-gkmarch-00.txt] References: <4.3.2.7.2.20010627140639.04301090@mira-sjc5-6.cisco.com> <5.0.0.25.2.20010628135522.02177618@pop.ne.mediaone.net> 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: Thu, 28 Jun 2001 16:50:44 -0400 Content-Transfer-Encoding: 7bit Hi, Thomas, > > > At 6/27/2001||07:31 PM, Andrea Colegrove wrote: > > Also, because SPD and SAD values for a group cannot be completely > > determined in advance and are more likely distributed as part of the > > Join/Registration process, IKE will not likely be automatically fired > off > > anyway (analogous to PPKs). > > I have brought-up this point several times, namely, that if a newcomer > wishes to join a group, how does he/she find out about the necessary > parameters to talk to the GCKS or Key Server. > The info can be in the announcement, it can be held generically in the IPSec SPD (SAD values would need to be determined within the join/registration protocol, it can be held by a future "policy server" or it can be strictly enforced by the GCKS values in the SPD. > > GDOI assumes that this information is outside GDOI itself (say within > a Group Security Policy Token). GSAKMP pushes the Token down to the > newcomer after the newcomer has been authenticated and a secure channel > has been estabslished between the two. > > Now, if we are talikng about Cat-1 SA (unicast) between a newcomer > and a member, then Andrea's statement is true (ie. SPD and SAD values > for a group cannot be completely determined in advance). > This is in fact the whole point of the Cat-1, as we all agree that > there no practical way to boot-up a group other than for each member > to establish a pairwise secure channel with the GCKS. > > However, if we are talking about the Cat-2 SA (Key Update) and > Cat-3 SA (Data Security) -- both being IPsec SAs -- then > Andera's statement is not quite correct. The IPsec Arch document "hints" > (within a couple of paragrahps) that for multicast the parameters > must be pre-determined. > Right. These values can be passed down in the join process. They must be determined before the group is grown, however, (SPI values, keys, etc.) Or am I misunderstanding you? Sorry. --- Andrea _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jun 28 17:06:58 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21878 for ; Thu, 28 Jun 2001 17:06:57 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1716753717; Thu, 28 Jun 2001 17:07: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 ED00353577 for ; Thu, 28 Jun 2001 17:04:34 -0400 (EDT) Received: (qmail 66266 invoked by uid 3269); 28 Jun 2001 21:04:34 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 66263 invoked from network); 28 Jun 2001 21:04:33 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 28 Jun 2001 21:04:33 -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 f5SL45x25972; Thu, 28 Jun 2001 14:04:05 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-449.cisco.com [10.21.65.193]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADG16022; Thu, 28 Jun 2001 14:03:53 -0700 (PDT) Message-Id: <4.3.2.7.2.20010628135533.041f8048@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Andrea Colegrove From: Mark Baugher Subject: Re: [MSEC] Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt Cc: msec@securemulticast.org In-Reply-To: <3B3B902A.2DBED04B@columbia.sparta.com> References: <200106271103.HAA26170@ietf.org> <4.3.2.7.2.20010627202552.0433d4c8@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_26946336==_.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, 28 Jun 2001 14:03:13 -0700 --=====================_26946336==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 04:14 PM 6/28/2001 -0400, Andrea Colegrove wrote: >Mark, >>How about if we change the offending paragraph as follows: >>security services. For these reasons, application, transport, and >>internetwork-layer security protocols such as SRTP, IPsec, and AMESP may >>benefit from using different group key management systems [GSAKMP, GDOI]. >>Extensions to IKE, however, are probably the best solution for IPsec >>protocols over IP multicast services [GDOI]. The purpose of this >> >Yes there is definitely the "one size fits all" vs. the per-security >application approach. It is appropriate to state this in the >intro. Please just remove the opinion of what you feel is the best >solution for IPSec. I'd like to hear what others from msec have to say about this first because I can think of a few reasons why a WG would standardize two or more protocols that do the same thing. 1. We are muddleheads 2. We are in a political stalemate and making compromises 3. We have specific uses in mind for each I like to think that we're in point 3 space and should state what the specific uses are. At the grossest level, GSAKMP runs over IPsec or other data security protocol and GDOI is strictly an extension to IKE. So if you want to use a single key-management protocol implementation for IPsec, then GDOI is probably the best solution. If you want to run over IPsec or SSL, then GSAKMP is the solution. This is why we are working to standardize two things rather than one. It might be that neither GSAKMP or GDOI are suitable for certain group security applications such as VoIP and we may end up doing a third. The paragraph above says something about the msec group key management protocols that we are developing. Mark >Group and multicast applications have diverse requirements in IP >networks [CP00]. Their key-management requirements, which are briefly >reviewed below (see "Requirements"), include support for internetwork, >transport, and application-layer protocols. In particular, while >Internet-standard ISAKMP and IKE protocols purport to manage keys for >any and all services in a host, some applications may achieve simpler >operation by running key-management messaging over TLS or IPsec >security services. For these reasons, application, transport, and >internetwork-layer security protocols such as SRTP, IPsec, and AMESP >may benefit from using different group key management systems. The purpose >of this document is to define a common architecture and design for these >different group key-management protocols. >> >> A "group key management protocol" ensures that >> only >> members of a secure group gain access to group data (by gaining access >> to group keys) and can authenticate group >> data. >>I'm looking forward to the I-D on security management protocols and >>prefer to stick to key management protocols in this I-D >The statement above is incorrect however. It is only though key >management in conjuction with security association management, access >control, and authorization (i.e., security management) that ensures this >property. (KM is probably necessary but not sufficient, etc, etc.) >>>> >>>>4. The key-management protocol must be secure against man-in-the- >>>> middle, connection-hijacking, and reflection/replay attacks; >>>>it must >>>> use best-known practices to thwart denial-of-service >>>>attacks. >>>And type attacks. And attacks resulting from lack of explicitness >>>(mis-routed, mis-interpreted). And interleaved with other protocols >>>(protocol-oracle), etc. Perhaps it would be better to generalize this >>>statement. >> >> >>Would you please provide references for these attacks? >> >Sure. For starters check Clark and Jacob's "Security Protocols: An >Annotated Bibliography", Abadi and Needham's"Prudent Engineering Practice >for Cryptographic Protocol", Ulf Carlsen's "Cryptographic Protocol >Flaws." Ross Anderson also has a good paper that applies to public key >protocols and Schneier (and Wagner?) have one on multiprotocol attacks. > >My point was only that it might be better to generalize than to list. >>>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." >> >> >>Not in IKE it isn't. Again, I await the I-D on the security management >>protocol. >> >IKE says: >A security association (SA) is a set of policy and key(s) used to protect >information. The ISAKMP > SA is the shared policy and key(s) used by the negotiating peers in > this protocol to protect their > communication. > >Access control and delegation are two of the assumptions that pairwise >communication does not need to consider: You know who you are going to >talk to (your peer), you will only communicate if both your policies >(SPDs) allow it, and you figure that they are authorized to negotiate on >behalf of themselves. > >There is a lot of policy involved in IKE. The rest of the security >association is certainly not just meta-data describing the keys. >>>5. Re: video on demand example. The example shows a pre-existing >>>group of all possible members subject to pre-broadcast rekey. One >>>broadcast would destroy this property. >> >> >>What is the property that would be destroyed? What exactly is the problem? >> >> >The example wasn't clear to me but it appeared that you were stating that >the potential audience was a group and requirement 6 (rekey) supported the >access control to video broadcasts. If this is what you meant, then each >time some of the members were excluded from a broadcast, a smaller >potential audience resulted for the next one. >> >>>6. >>>> >>>> >>>>A centralized >>>>group controller (or KDC) that is used in this architecture may not be >>>>the best design for small, interactive groups. But for large, >>>>single- >>>>source multicast groups, it is generally undesirable to distribute key >>>>management functions among group members: Unlike small, interactive >>>>groups, large single-source multicast groups generally need a >>>>specialized KDC to support large numbers of group members. Large >>>>distributed simulations, moreover, may combine the need for large-grou >>>>operation with many >>>>senders. >>>Large groups require distributed initial key distribution! Large >>>dynamic groups cannot rely upon a centralized KDC. This does not >>>scale. This is highly inflexible. The VoD example demonstrates this. >"But for large, >single- >source multicast groups, it is generally undesirable to distribute key >management functions among group members" > >Please support this with evidence. Also, wouldn't it be best to just >discuss the requirements and design constraints but not suggest solutions >here? >>>8. >>>> >>>> >>>>This design is based upon a "group controller" model >>>>[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group >>>>owner as the root-of-trust. The group owner designates a key >>>>distribution center for member registration and >>>>re-key. >>>As was originally envisioned, the group owner CAN (and for large or >>>sparse groups SHOULD) designate multiple key servers. >> >> >>The architecture recommends that this be done by allowing any key server >>to serve keys that is authorized to do so by the group owner. The most >>straightforward way to do this is to use SPKI or X.509 >>delegation. That's what we are recommending rather than coding this up >>in the key management protocol. >> >It is fair to say that the key server must provide proof of delegation. I >_believe_ SPKI (SDSI) delegation is not widely used, but cannot support >this. X. 509 attributes is a fair way of doing this, but is only one >way. Whether it is more straightforward is a matter of opinion. >>>9. Section 3.2 -- The term TEK is inappropriately specific. The group >>>may not have encryption requirements, but only authentication. >> >> >>TEK has a long history in the group key management literature. But you >>have a point, it may not be needed for authentication. We need to review >>this. >> >TEK = Traffic ENCRYPTION Key. And yes, this term goes back way before >open literature even. >>>11. >>>> >>>> >>>>The KDC, moreover, can be delegated when the >>>>trust infrastructure supports delegation to permit distributed >>>>operation of the >>>>KDC. >>>This statement, while correct, seems to conflict with the statement >>>quoted in Comment #6. >> >> >>Comment #6 was citing a requirements discussion. now we are into >>design. There are ways to load balance, get high-availability, and get >>fault tolerance for a server without inventing distributed key server >>protocols (such as a leader election algorithm, inter-KDC protocols). >> >> >Okay. The design is inconsistent with the requirement? >Load sharing is certainly different than delegation -- I am not sure what >your point is. >> >>>12. >>>> >>>> >>>>MSEC assumes that at least the following group-policy information >>>>is >>>>externally managed. >>>> o Group owner, authentication method, and delegation method for >>>> identifying a KDC for the group >>>> o Group KDC, authentication method, and any method used for >>>> delegating other KDCs for the group >>>> o Group membership rules or list and authentication >>>>method >>>These assumptions are unnecessary as was shown by GSAKMP. >> >> >>These assumptions were put into the GDOI draft at Hugh's behest and it >>helped clarify our thinking on how to minimize group policy functions in >>key management. I recommended to Ran and Lakshminath that we consider >>including these assumptions in the GKM architecture I-D. They agreed and >>Lakshminath did that. If we don't do that, then we will encumber the key >>management specification with a lot of policy issues that the working >>group has agreed belonged in a policy draft. You may not agree with >>everything the WG decides to do. WGs are like that. >> >Oh are you the working group? >Just because it is an appropriate assumption for GDOI does make it >appropriate for all. >> >>> I. While the group owner may be published externally, the group >>> owner can also be disclosed during the registration protocol. It can >>> be decided during this time whether the owner is acceptable prior to >>> completion of registration. Once this occurs, authenticated group >>> policy can be conveyed to the new member using traditional mechanisms >>> such as digital signatures tied to a PKI. >>> II. The delegation can be stated (authorized) through the >>> authenticated policy statement as was done with GSAKMP. >>> III. Ditto for membership rules and lists >>> IV. The security association characteristics of the registration >>> protocol can be determined early in the registration exchange or in >>> almost all protocols (TLS, IPSec, GSAKMP, etc.) can be restricted by >>> what properties the Key Server will accept using cipher suite >>> restrictions, SPD constraints, etc. >>> >>> External management of these can be done, but should not be assumed >>> in the architecture document. >>> >>>13. In general, this document contains very little new >>>information. The framework for the architecture was already provided by >>>the building block documents with the category 1,2, and 3 SAs. The >>>architecture document should work toward providing interoperable solutions. >> >> >>We're not shooting for novelty here. Quite the contrary. The I-D is to >>progress as a product of the msec WG in order to bring two or more key >>management protocols to address common requirements, use common >>abstractions, and messages. These two or more protocols cannot >>interoperate unless they at least use a common header. GDOI uses an >>ISAKMP header for obvious reasons. GSAKMP does not use an ISAKMP header. >>If they could interoperate, then we would not go to the trouble of >>specifying two or more key management protocols. >> >The requirements need to drive the protocol selection not the other way >around. >Common abstractions are good, common messages imply a common protocol. > >--- Andrea --=====================_26946336==_.ALT Content-Type: text/html; charset="us-ascii" At 04:14 PM 6/28/2001 -0400, Andrea Colegrove wrote:

Mark,
How about if we change the offending paragraph as follows:
security services.  For these reasons, application, transport, and internetwork-layer security protocols such as SRTP, IPsec, and AMESP may benefit from using different group key management systems [GSAKMP, GDOI]. Extensions to IKE, however, are probably the best solution for IPsec protocols over IP multicast services [GDOI].  The purpose of this
 
Yes there is definitely the "one size fits all" vs. the per-security application approach.  It is appropriate to state this in the intro.  Please just remove the opinion of what you feel is the best solution for IPSec.

I'd like to hear what others from msec have to say about this first because I
can think of a few reasons why a WG would standardize two or more
protocols that do the same thing.

1. We are muddleheads
2. We are in a political stalemate and making compromises
3. We have specific uses in mind for each

I like to think that we're in point 3 space and should state what the specific
uses are.  At the grossest level, GSAKMP runs over IPsec or other data
security protocol and GDOI is strictly an extension to IKE.  So if you
want to use a single key-management protocol implementation for
IPsec, then GDOI is probably the best solution.  If you want to run over
IPsec or SSL, then GSAKMP is the solution. This is why we are
working to standardize two things rather than one.  It might be that
neither GSAKMP or GDOI are suitable for certain group security
applications such as VoIP and we may end up doing a third.
The paragraph above says something about the msec group key
management protocols that we are developing.

Mark


Group and multicast applications have diverse requirements in IP
networks [CP00].  Their key-management requirements, which are briefly
reviewed below (see "Requirements"), include support for internetwork,
transport, and application-layer protocols.  In particular, while
Internet-standard ISAKMP and IKE protocols purport to manage keys for
any and all services in a host, some applications may achieve simpler
operation by running key-management messaging over TLS or IPsec
security services.  For these reasons, application, transport, and
internetwork-layer security protocols such as SRTP, IPsec, and AMESP
may benefit from using different group key management systems. The purpose of this document is to define a common architecture and design for these different group key-management protocols. 

 A "group key management protocol" ensures that
    only 
    members of a secure group gain access to group data
(by gaining access 
    to group keys) and can authenticate group
   
data.

I'm looking forward to the I-D on security management protocols and
prefer to stick to key management protocols in this
I-D
The statement above is incorrect however.  It is only though key management in conjuction with security association management, access control, and authorization (i.e., security management) that ensures this property.  (KM is probably necessary but not sufficient, etc, etc.) 

4. The key-management protocol must be secure against man-in-the-
   middle, connection-hijacking, and reflection/replay
attacks;
it must
   use best-known practices to thwart denial-of-service
attacks.
And type attacks.  And attacks resulting from lack of explicitness (mis-routed, mis-interpreted).  And interleaved with other protocols (protocol-oracle), etc.  Perhaps it would be better to generalize this statement.


Would you please provide references for these attacks?
 
Sure.  For starters check Clark and Jacob's "Security Protocols:  An Annotated Bibliography", Abadi and Needham's"Prudent Engineering Practice for Cryptographic Protocol", Ulf Carlsen's "Cryptographic Protocol Flaws."  Ross Anderson also has a good paper that applies to public key protocols and Schneier (and Wagner?) have one on multiprotocol attacks.

My point was only that it might be better to generalize than to list.
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."


Not in IKE it isn't.  Again, I await the I-D on the security management protocol.
 
IKE says:
A security association (SA) is a set of policy and key(s) used to protect information. The ISAKMP
    SA is the shared policy and key(s) used by the negotiating peers in this protocol to protect their
    communication.

Access control and delegation are two of the assumptions that pairwise communication does not need to consider:  You know who you are going to talk to (your peer), you will only communicate if both your policies (SPDs) allow it, and you figure that they are authorized to negotiate on behalf of themselves.

There is a lot of policy involved in IKE.  The rest of the security association is certainly not just meta-data describing the keys.
5.  Re:  video on demand example.   The example shows a pre-existing group of all possible members subject to pre-broadcast rekey.  One broadcast would destroy this property.


What is the property that would be destroyed?  What exactly is the problem?
 
 
The example wasn't clear to me but it appeared that you were stating that the potential audience was a group and requirement 6 (rekey) supported the access control to video broadcasts.  If this is what you meant, then each time some of the members were excluded from a broadcast, a smaller potential audience resulted for the next one.
 
6.
 
  
A centralized
group controller (or KDC) that is used in this architecture may not be 
the best design for small, interactive groups.  But for large,
single-
source multicast groups, it is generally undesirable to distribute key 
management functions among group members: Unlike small, interactive 
groups, large single-source multicast groups generally need a 
specialized KDC to support large numbers of group members.  Large 
distributed simulations, moreover, may combine the need for large-grou 
operation with many
senders.
Large groups require distributed initial key distribution!  Large dynamic groups cannot rely upon a centralized KDC.  This does not scale.  This is highly inflexible.  The VoD example demonstrates this.
"But for large,
single-
source multicast groups, it is generally undesirable to distribute key
management functions among group members"

Please support this with evidence.  Also, wouldn't it be best to just discuss the requirements and design constraints but not suggest solutions here?
8.
 
  
This design is based upon a "group controller" model 
[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group 
owner as the root-of-trust.  The group owner designates a key 
distribution center for member registration and
re-key.
As was originally envisioned, the group owner CAN (and for large or sparse groups SHOULD) designate multiple key servers.


The architecture recommends that this be done by allowing any key server to serve keys that is authorized to do so by the group owner.  The most straightforward way to do this is to use SPKI or X.509 delegation.  That's what we are recommending rather than coding this up in the key management protocol.
 
It is fair to say that the key server must provide proof of delegation.  I _believe_ SPKI (SDSI) delegation is not widely used, but cannot support this.  X. 509 attributes is a fair way of doing this, but is only one way.  Whether it is more straightforward is a matter of opinion.
9.  Section 3.2 -- The term TEK is inappropriately specific.  The group may not have encryption requirements, but only authentication.


TEK has a long history in the group key management literature.  But you have a point, it may not be needed for authentication.  We need to review this.
 
TEK = Traffic ENCRYPTION Key.  And yes, this term goes back way before open literature even.
11.
 
  
The KDC, moreover, can be delegated when the 
trust infrastructure supports delegation to permit distributed 
operation of the
KDC.
This statement, while correct, seems to conflict with the statement quoted in Comment #6.


Comment #6 was citing a requirements discussion.  now we are into design.  There are ways to load balance, get high-availability, and get fault tolerance for a server without inventing distributed key server protocols (such as a leader election algorithm, inter-KDC protocols).
 
 
Okay.  The design is inconsistent with the requirement?
Load sharing is certainly different than delegation -- I am not sure what your point is.
 
12.
 
  
MSEC assumes that at least the following group-policy information
is
externally managed.
  o Group owner, authentication method, and delegation method for 
    identifying a KDC for the group
  o Group KDC, authentication method, and any method used for
    delegating other KDCs for the group
  o Group membership rules or list and authentication
method
These assumptions are unnecessary as was shown by GSAKMP.


These assumptions were put into the GDOI draft at Hugh's behest and it helped clarify our thinking on how to minimize group policy functions in key management.   I recommended to Ran and Lakshminath that we consider including these assumptions in the GKM architecture I-D.  They agreed and Lakshminath did that.  If we don't do that, then we will encumber the key management specification with a lot of policy issues that the working group has agreed belonged in a policy draft.  You may not agree with everything the WG decides to do.  WGs are like that.
 
Oh are you the working group?
Just because it is an appropriate assumption for GDOI does make it appropriate for all.
 
    I.  While the group owner may be published externally, the group owner can also be disclosed during the registration protocol.  It can be decided during this time whether the owner is acceptable prior to completion of registration.  Once this occurs, authenticated group policy can be conveyed to the new member using traditional mechanisms such as digital signatures tied to a PKI.
    II.  The delegation can be stated (authorized) through the authenticated policy statement as was done with GSAKMP.
    III.  Ditto for membership rules and lists
    IV.  The security association characteristics of the registration protocol can be determined early in the registration exchange or in almost all protocols (TLS, IPSec, GSAKMP, etc.) can be restricted by what properties the Key Server will accept using cipher suite restrictions, SPD constraints, etc.

    External management of these can be done, but should not be assumed in the architecture document.

13.  In general, this document contains very little new information.  The framework for the architecture was already provided by the building block documents with the category 1,2, and 3 SAs.  The architecture document should work toward providing interoperable solutions.


We're not shooting for novelty here.  Quite the contrary.  The I-D is to progress as a product of the msec WG in order to bring two or more key management protocols to address common requirements, use common abstractions, and messages.  These two or more protocols cannot interoperate unless they at least use a common header.  GDOI uses an ISAKMP header for obvious reasons.  GSAKMP does not use an ISAKMP header. If they could interoperate, then we would not go to the trouble of specifying two or more key management protocols.
 
The requirements need to drive the protocol selection not the other way around.
Common abstractions are good, common messages imply a common protocol.

--- Andrea
--=====================_26946336==_.ALT-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jun 28 17:08:03 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22525 for ; Thu, 28 Jun 2001 17:08:03 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id E87B053707; Thu, 28 Jun 2001 17:08:14 -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 F05E553707 for ; Thu, 28 Jun 2001 17:07:00 -0400 (EDT) Received: (qmail 66450 invoked by uid 3269); 28 Jun 2001 21:07:00 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 66440 invoked from network); 28 Jun 2001 21:07:00 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 28 Jun 2001 21:07:00 -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 f5SL6Xh07271; Thu, 28 Jun 2001 14:06:33 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-449.cisco.com [10.21.65.193]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADG16084; Thu, 28 Jun 2001 14:06:27 -0700 (PDT) Message-Id: <4.3.2.7.2.20010628140412.0205d4f0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Andrea Colegrove From: Mark Baugher Subject: Re: [MSEC] [Fwd: [Fwd: I-D ACTION:draft-ietf-msec-gkmarch-00.txt]] Cc: Ran Canetti , msec@securemulticast.org In-Reply-To: <3B3B969B.DD17C361@columbia.sparta.com> References: <200106281801.OAA08228@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, 28 Jun 2001 14:05:57 -0700 At 04:42 PM 6/28/2001 -0400, Andrea Colegrove wrote: >Hi, Ran, > Yes I agree that GDOI works well with IPSec and as far as I am aware, > GDOI is the >only extension to IKE for groups right now (although you can argue the >GSAKMP is an >extension to ISAKMP). An extension to a protocol would at least use the header to that protocol and for this reason, GSAKMP is no extension to ISAKMP. If we used the same header then we might be able to find a way to interoperate. Mark > If it is a requirement that ESP/AH be serviced without modification > to IPSec that >would probably be suitable for the requirements section without reference >I think to >either GSAKMP or to GDOI -- once again leaving room for the ACME protocol ;-) > > Many of the assumptions in the document are rather GDOI-specific, > especially the >policy assumptions. It will be a difficult process for the WG as a whole >to create an >independent document that will not limit new protocols >unnecessarily. Hopefully, we are >now on our way :-) > >--- Andrea > > >Ran Canetti wrote: > > > Andrea, > > > > Regarding the "offending sentence" in the intro of the new architecture > draft: > > > > > Extensions to IKE, however, are probably the best solution for IPsec > > > protocols over IP multicast services [GDOI]. > > > > I agree with you that the sentence is poorly phrased and invites > > misinterpretation. It should be rewreitten. Our meaning was to say that > > That one of the requirements of the architecture is to enable a GKM > protocol > > that allows ESP/AH to work within the MSEC protocol suite without any > changes. > > This is an important requirement. The reference to GDOI is there since GDOI > > took it up as an explcit goal to provide this functionality, so the > meaning was to > > give it as an example. But GDOI is certainly not the only example. In > particular, > > I am certain that a resolution of GSAKMP with IPSEC for the > registration protocol > > would be able to provide the same functionality. > > Do you agree with this view of things? > > > > Regarding your note below, I think you're missing some salient points > in the new > > draft. (And this ofcourse immediately reflects on the authors, who > apparently did > > a poor job of explaining these points.) In particular, it is NOT > compatible with > > the current GDOI draft, and GDOI will have to change to fit this > document. I'll > > try to provide more details later today or to morrow. So please hold > your fire... > > > > Ran > > > > > From: Andrea Colegrove > > > > > > Mark, > > > The architecture document is for specification and discussion of > technical > > > issues -- not opinion -- that is the issue at hand. The document has > been written > > > as a summary of the BBs with additional constraints and assumptions > that are not > > > necessary except that GDOI seems to make these assumptions. This is > a fairness > > > issue. > > > The "title" of editor sometimes seems more appropriate as the > specifications > > > that are on standards track should reflect the combined interests of > the working > > > group -- it is not intended to be honorary or to detract, but merely > a reflection > > > of the responsibilities of the writers of the documents. > > > I, too, gave technical arguments as to why GDOI may not be the > perfect fit. It > > > is not a bad solution, but let us also leave room for the ACME Group > Security > > > Management Protocol which Joe Schmo has yet to specify. > > > > > > --- Andrea > > > > > > > > >_______________________________________________ >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 Jun 28 17:15:33 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27566 for ; Thu, 28 Jun 2001 17:15:32 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0F36953730; Thu, 28 Jun 2001 17:15: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 14C1A53730 for ; Thu, 28 Jun 2001 17:13:25 -0400 (EDT) Received: (qmail 67426 invoked by uid 3269); 28 Jun 2001 21:13:24 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 67423 invoked from network); 28 Jun 2001 21:13:24 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 28 Jun 2001 21:13: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 f5SLD0x01867; Thu, 28 Jun 2001 14:13:00 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-449.cisco.com [10.21.65.193]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADG16276; Thu, 28 Jun 2001 14:12:50 -0700 (PDT) Message-Id: <4.3.2.7.2.20010628140622.0422e588@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.20010628153600.00b245d0@pop.columbia.sparta.com> References: <4.3.2.7.2.20010628122635.041f70b8@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: Thu, 28 Jun 2001 14:12:21 -0700 Hi Hugh At 03:50 PM 6/28/2001 -0400, Hugh Harney wrote: >Mark, > >>There is ALWAYS an external policy infrastructure. And there will always >>be some policy in key management. I'd prefer to limit that to items that >>are directly pertinent to key management operation. There are policy >>issues outside of key management that are important such as "who are the >>members of this group?" or "what's this member's USPO zipcode?" that >>might play a crucial role for some participant receiving or sending to a >>particular group, but which SHOULD NOT be handled through the key >>management protocol in my opinion. Similarly, the policy issue such as >>"you must encrypt all communications with the GCKS with AES" is something >>that CANNOT be handled through the key management protocol. gkmarch >>states this in 4.1. > >Your correct there is always a certificate infrastructure at the bare minimum. I think pre-shared key is much more of a bare minimum than a PKI. >I think our only difference of opinion is what policy information is >relevant to key management. My opinion is that policy should be considered >relevant to the key management protocol, if omission of that policy would >lead to a security attack on the key management system. Stated another >way, security policy for key management must be sufficient to ensure >verifiably secure key is available for data encryption/authorization. Yes. I think this is our only real difference. How should we proceed in resolving it? >I do not imply how that policy information is verified or disseminated. In >the key management protocol or via a trusted infrastructure outside of the >key management protocol. > >I guess the challenge ahead of us is figuring out which policy items are >important for key management. I look forward to working these issues >through with you in the future. We should probably write a document >together, I'd also include Patrick McDaniel, Thanks, but I still have my hands full from my last document-writing assignment :-) We developed a list of policy items for GDOI - I think that you and Andrea actually helped write the text. The gkmarch authors reworked it and put it into gkmarch. While it's true that certain things were taken from the GDOI document and put in gkmarch, it's also true that things were taken from the GSAKMP and GKMBB documents and put into GDOI. Would it be useful to go through the list - in section 4.1 of gkmarch - and identify things that might be in the key management protocol rather than outside of it? Best Regards, Mark >and or Pete Dinsmore. Figuring out which data is important is the first >step. Then we can figure out how to deal with that data and the security >requirements on key management protocols and/or trusted policy >infrastructures. I've had ample input to the policy document that is >coming out soon. Perhaps you can review that document and it can serve as >a spring board for a joint effort. > >Unfortunately, the security policy data that is relevant to a key >management protocol is highly dependant on the architecture that protocol >exists in and the application that protocol supports. Ultimately, our job >is to provide verifiably good key to algorithms for protection of data. >Any document we write must also define the architecture and the >application assumed. > > > >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 Thu Jun 28 17:23:21 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02877 for ; Thu, 28 Jun 2001 17:23:20 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 7C6EA53734; Thu, 28 Jun 2001 17:23: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 1A7D253705 for ; Thu, 28 Jun 2001 14:32:49 -0400 (EDT) Received: (qmail 51008 invoked by uid 3269); 28 Jun 2001 18:32:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 51003 invoked from network); 28 Jun 2001 18:32:47 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 28 Jun 2001 18:32:47 -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 f5SIWHh13082; Thu, 28 Jun 2001 11:32:17 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-449.cisco.com [10.21.65.193]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADG12233; Thu, 28 Jun 2001 11:32:15 -0700 (PDT) Message-Id: <4.3.2.7.2.20010628112110.0422eda0@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] Re: [Fwd: I-D ACTION:draft-ietf-msec-gkmarch-00.txt] Cc: Andrea Colegrove , msec@securemulticast.org In-Reply-To: <5.0.0.25.2.20010628135522.02177618@pop.ne.mediaone.net> References: <3B3A6CDE.A29BA9A6@columbia.sparta.com> <4.3.2.7.2.20010627140639.04301090@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: Thu, 28 Jun 2001 11:31:45 -0700 Thomas, At 02:12 PM 6/28/2001 -0400, Thomas Hardjono wrote: >Hi, > >I'd like to respond particulalry to Andrea's valid point: > >At 6/27/2001||07:31 PM, Andrea Colegrove wrote: > > Also, because SPD and SAD values for a group cannot be completely > > determined in advance and are more likely distributed as part of the > > Join/Registration process, IKE will not likely be automatically fired off > > anyway (analogous to PPKs). > >I have brought-up this point several times, namely, that if a newcomer >wishes to join a group, how does he/she find out about the necessary >parameters to talk to the GCKS or Key Server. > >GDOI assumes that this information is outside GDOI itself (say within >a Group Security Policy Token). GSAKMP pushes the Token down to the >newcomer after the newcomer has been authenticated and a secure channel >has been estabslished between the two. > >Now, if we are talikng about Cat-1 SA (unicast) between a newcomer >and a member, then Andrea's statement is true (ie. SPD and SAD values >for a group cannot be completely determined in advance). >This is in fact the whole point of the Cat-1, as we all agree that >there no practical way to boot-up a group other than for each member >to establish a pairwise secure channel with the GCKS. Consider a group of four members who trust each other not to impersonate another member. When an IPsec ESP message is sent multicast from one to all of the members, each one could perform a Registration exchange (protected by a Cat-1 SA) with the sender if they don't already have an AH SA. This may initialize a Rekey (Cat-2) SA for Re-key messages (indeed, all of this could have been initiated by the receipt of a Re-key message). Or it might not use Re-key. Now, if the group is much larger than four... >However, if we are talking about the Cat-2 SA (Key Update) and >Cat-3 SA (Data Security) -- both being IPsec SAs -- then >Andera's statement is not quite correct. The IPsec Arch document "hints" >(within a couple of paragrahps) that for multicast the parameters >must be pre-determined. It doesn't matter whether the Cat-2 SA (Re-key not Key Update) is IPsec or not - it could be ISAKMP - we would not want to initiate a pairwise SA on receipt of a multicast message sent to a large group because that could cause implosion. A better course might be to listen to the Re-key multicast address for the particular group and pick up the SA for the multicast message received. No change is required to IPsec it is all done in IKE GDOI. How to do this is something I expect will be answered in the Policy draft. Best Regards, Mark >thomas >------ > > >At 6/27/2001||07:31 PM, Andrea Colegrove wrote: >>Mark, >> Since you are the primary author (editor?) of GDOI I am sure that >> you feel GDOI is best. The architecture document, however, is not the >>place to promote your solution. >> Many feel that modifications to a standard to support multicast is >> not a good solution. IKE is designed with certain assumptions which >>hold for pairwise paradigms but not necessarily groups. >> Also, because SPD and SAD values for a group cannot be completely >> determined in advance and are more likely distributed as part of the >>Join/Registration process, IKE will not likely be automatically fired off >>anyway (analogous to PPKs). >> Regardless of how you feel on this issue, it is inappropriate to >> state that GDOI is probably the best solution at this point in general >>and certainly not in the architecture document. >> Wrt GSAKMP and separating out the "key management protocol": key >> management involves more than distribution. >> >>--- Andrea >> >> >> >>Mark Baugher wrote: >> >> > Andrea >> > I respond to your first point in this note. >> > >> > At 01:40 PM 6/27/2001 -0400, Andrea Colegrove wrote: >> > >> > >X-Mozilla-Status2: 00000000 >> > >Message-ID: <3B3A1837.D95360C0@columbia.sparta.com> >> > >Date: Wed, 27 Jun 2001 13:30:31 -0400 >> > >From: Andrea Colegrove >> > >X-Mailer: Mozilla 4.75 [en] (Win98; U) >> > >X-Accept-Language: en >> > >MIME-Version: 1.0 >> > >To: msec@securemulticast.org >> > >Subject: Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt >> > >References: <200106271103.HAA26170@ietf.org> >> > >Content-Type: multipart/alternative; >> > > boundary="------------E7B7F4EE607BF84BF270BC1C" >> > > >> > >Mark, etal, >> > >Initial comments on the architecture -- >> > > >> > >1. Section 1. -- >> > >> >> > >>Extensions to IKE, however, are probably the best solution for IPsec >> > >>protocols over IP multicast services [GDOI]. >> > >The architecture document is not an appropriate place for blatant >> > >editorialisms. >> > >> > It is not as you say it is. I'll ignore the rudeness of this sentence and >> > focus >> > on the issue: It makes no sense to force AH and ESP to select a key >> management >> > application based on whether it has a unicast or a multicast destination >> > address in >> > the packet it is processing. One may want to do that, but extensions to >> > IKE are probably >> > the best solution for IPsec protocols over IP multicast services. This is >> > an architectural >> > issue for it involves multiple functional blocks (data security protocols >> > and key >> > management protocol) , and it is why msec will likely standardize an >> IKE-based >> > specification in addition to a something like GSAKMP (at least the key >> > management >> > protocol of it once that's separated out). >> > >> > I'll spare ipsec my comments on the rest of your points and post only >> to msec. >> > >> > Mark >> > >> > >2. >> > >> >> > >>A "secure group" is a collection of principals, >> > >>called "members," who may be senders, receivers or both receivers and >> > >>senders to other members of the group. (Note that group membership may >> > >>vary over time.) A "group key management protocol" ensures that only >> > >>members of a secure group gain access to group data (by gaining access >> > >>to group keys) and can authenticate group data. >> > >A secure group is a group in which access to data is restricted to >> > >particular entities. This access can be of read and/or write access. In >> > >other words, a group may only have write restrictions and no read >> > >restrictions. While this access may be enforced with group keys, it is >> > >mandated by a policy that claims data will only be accepted from >> > >particular entities, which could also be enforced with signature keys. A >> > >key distribution protocol alone does not define a secure group. This >> > >really demands a _security management_ protocol that can manage keys and >> > >policy. >> > > >> > >3. >> > >> >> > >>4. The key-management protocol must be secure against man-in-the- >> > >> middle, connection-hijacking, and reflection/replay attacks; it must >> > >> use best-known practices to thwart denial-of-service attacks. >> > > >> > > >> > >And type attacks. And attacks resulting from lack of explicitness >> > >(mis-routed, mis-interpreted). And interleaved with other protocols >> > >(protocol-oracle), etc. Perhaps it would be better to generalize this >> > >statement. >> > > >> > >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." >> > > >> > >5. Re: video on demand example. The example shows a pre-existing >> group >> > >of all possible members subject to pre-broadcast rekey. One broadcast >> > >would destroy this property. >> > > >> > >6. >> > >> >> > >>A centralized >> > >>group controller (or KDC) that is used in this architecture may not be >> > >>the best design for small, interactive groups. But for large, single- >> > >>source multicast groups, it is generally undesirable to distribute key >> > >>management functions among group members: Unlike small, interactive >> > >>groups, large single-source multicast groups generally need a >> > >>specialized KDC to support large numbers of group members. Large >> > >>distributed simulations, moreover, may combine the need for large-grou >> > >>operation with many senders. >> > >Large groups require distributed initial key distribution! Large dynamic >> > >groups cannot rely upon a centralized KDC. This does not scale. This is >> > >highly inflexible. The VoD example demonstrates this. >> > > >> > >While the interactions with distributed rekey entities is more >> > >complicated, this functionality may be needed in composite multicast >> > >groups of limited scope. >> > > >> > >7. >> > >> >> > >>It may be that no >> > >>single key management protocol can satisfy the scalability requirements >> > >>of all group-security applications. This is for further study. >> > >It may be that the security protocols protecting group communications >> data >> > >cannot satisfy each of the possible sender/receiver profiles. This is >> > >less of a security management problem. >> > > >> > >8. >> > >> >> > >>This design is based upon a "group controller" model >> > >>[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group >> > >>owner as the root-of-trust. The group owner designates a key >> > >>distribution center for member registration and re-key. >> > >As was originally envisioned, the group owner CAN (and for large or >> sparse >> > >groups SHOULD) designate multiple key servers. >> > > >> > >9. Section 3.2 -- The term TEK is inappropriately specific. The group >> > >may not have encryption requirements, but only authentication. >> > > >> > >10. >> > >> >> > >>Only one SA is optional and that is the Re-key >> > >>SA. >> > > >> > > >> > >Actually, one policy for the Re-Key SA is that there is none. It is >> > >null. Explicitly stating this prevents confusion between missing SA info >> > >and optional SA info. Likewise, the registration protocol may involve >> > >manual methods. >> > > >> > >11. >> > >> >> > >>The KDC, moreover, can be delegated when the >> > >>trust infrastructure supports delegation to permit distributed >> > >>operation of the KDC. >> > >This statement, while correct, seems to conflict with the statement >> quoted >> > >in Comment #6. >> > > >> > >12. >> > >> >> > >>MSEC assumes that at least the following group-policy information is >> > >>externally managed. >> > >> o Group owner, authentication method, and delegation method for >> > >> identifying a KDC for the group >> > >> o Group KDC, authentication method, and any method used for >> > >> delegating other KDCs for the group >> > >> o Group membership rules or list and authentication method >> > > >> > > >> > >These assumptions are unnecessary as was shown by GSAKMP. >> > > I. While the group owner may be published externally, the group >> > > owner can also be disclosed during the registration protocol. It can be >> > > decided during this time whether the owner is acceptable prior to >> > > completion of registration. Once this occurs, authenticated group >> policy >> > > can be conveyed to the new member using traditional mechanisms such as >> > > digital signatures tied to a PKI. >> > > II. The delegation can be stated (authorized) through the >> > > authenticated policy statement as was done with GSAKMP. >> > > III. Ditto for membership rules and lists >> > > IV. The security association characteristics of the registration >> > > protocol can be determined early in the registration exchange or in >> > > almost all protocols (TLS, IPSec, GSAKMP, etc.) can be restricted by >> what >> > > properties the Key Server will accept using cipher suite restrictions, >> > > SPD constraints, etc. >> > > >> > > External management of these can be done, but should not be assumed >> > > in the architecture document. >> > > >> > >13. In general, this document contains very little new information. The >> > >framework for the architecture was already provided by the building block >> > >documents with the category 1,2, and 3 SAs. The architecture document >> > >should work toward providing interoperable solutions. >> > > >> > >--- Andrea Colegrove >> > > >> > > >> > > >> > >Internet-Drafts@ietf.org wrote: >> > >>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 : Group Key Management Architecture >> > >> Author(s) : M. Baugher, R. Canetti, L. Dondeti >> > >> Filename : draft-ietf-msec-gkmarch-00.txt >> > >> Pages : 22 >> > >> Date : 26-Jun-01 >> > >> >> > >>This document presents a group key-management architecture for MSEC. >> > >>The purpose of this document is to define the common architecture for >> > >>MSEC group key-management protocols that support a variety of >> > >>application, transport, and internetwork security protocols. To >> > >>address these diverse uses, MSEC may need to standardize two or more >> > >>group key management protocols that have common requirements, >> > >>abstractions, overall design, and messages. The framework and >> > >>guidelines in this document allow for a modular and flexible design of >> > >>group key management protocols for a variety different settings that >> > >>are specialized to application needs. >> > >> >> > >>A URL for this Internet-Draft is: >> > >>h >> t tp://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.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-gkmarch-00.txt". >> > >> >> > >>A list of Internet-Drafts directories can be found in >> > >>http://www.ietf.org/shadow.html >> > >>or >> > >>ftp://ftp.ietf.org/ietf/1s >> h adow-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-gkmarch-00.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: <20010626132202.I-D@ietf.org> >> >> >>_______________________________________________ >>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 Thu Jun 28 17:24:15 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03290 for ; Thu, 28 Jun 2001 17:24:14 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C52F353769; Thu, 28 Jun 2001 17:23: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 1D9E0535D5 for ; Thu, 28 Jun 2001 15:50:11 -0400 (EDT) Received: (qmail 58889 invoked by uid 3269); 28 Jun 2001 19:50:10 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 58886 invoked from network); 28 Jun 2001 19:50:10 -0000 Received: from chmls20.mediaone.net (24.147.1.156) by klesh.pair.com with SMTP; 28 Jun 2001 19:50:10 -0000 Received: from THARDJONO-LAP.mediaone.net ([63.90.80.227]) by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id f5SJo7626620; Thu, 28 Jun 2001 15:50:08 -0400 (EDT) Message-Id: <5.0.0.25.2.20010628154551.01875ab8@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: Mark Baugher From: Thomas Hardjono Subject: Re: [MSEC] Re: [Fwd: I-D ACTION:draft-ietf-msec-gkmarch-00.txt] Cc: msec@securemulticast.org In-Reply-To: <4.3.2.7.2.20010628120941.041f83c0@mira-sjc5-6.cisco.com> References: <5.0.0.25.2.20010628144028.0245e470@pop.ne.mediaone.net> <4.3.2.7.2.20010628112110.0422eda0@mira-sjc5-6.cisco.com> <5.0.0.25.2.20010628135522.02177618@pop.ne.mediaone.net> <3B3A6CDE.A29BA9A6@columbia.sparta.com> <4.3.2.7.2.20010627140639.04301090@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: Thu, 28 Jun 2001 15:48:04 -0400 Mark, Apologies. I was referring to the bootstrap stage, in which case the newcomer has no KEK, nor TEK. Yes, once a member knows the KEK, it can listen to the Re-Key messages and obtain new keying material (which is the purpose of Cat-2). thomas ------ At 6/28/2001||12:24 PM, Mark Baugher wrote: >At 02:47 PM 6/28/2001 -0400, Thomas Hardjono wrote: >>At 6/28/2001||11:31 AM, Mark Baugher wrote: > > > >>>It doesn't matter whether the Cat-2 SA (Re-key not Key Update) is >>>IPsec or not - it could be ISAKMP - we would not want to initiate >>>a pairwise SA on receipt of a multicast message sent to a large >>>group because that could cause implosion. A better course >>>might be to listen to the Re-key multicast address for the >>>particular group and pick up the SA for the multicast message >>>received. No change is required to IPsec it is all done in >>>IKE GDOI. >> >> >>OK, I'm confused :) Why would we want a newcomer to contact a GCKS >>upon receiving a multicast message? How does the newcomer pick-up >>the SA when that SA is either not in the multicast message or is >>encrypted within the multicast message? > >I wrote that the member would listen for Re-key messages. I didn't >say anything about contacting the GCKS. Here is a scenario: >A Quicktime media server multicasts a stream of packets to group A, >which shares KEK K. That stream of packets is protected by TEK k. >While the Quicktime server sends the packets to one multicast transport >address, it periodically sends to another address the Re-key messages that >are protected by K and which contain k. So the Quicktime server in this >example can periodically send K{k} with additional parameters such as >a cert that is signed by the GCKS authorizing it to send on behalf of >the GCKS (i.e., the GCKS issues a delegate cert to the Quicktime >server and the GCKS is authorized to do such delegation by the >Group Owner). > >Mark > > >>thomas >>------ >> >> >> >> >>>How to do this is something I expect will be answered in the >>>Policy draft. >>> >>>Best Regards, Mark >>> >>> >>>>thomas >>>>------ >>>> >>>> >>>>At 6/27/2001||07:31 PM, Andrea Colegrove wrote: >>>>>Mark, >>>>> Since you are the primary author (editor?) of GDOI I am sure that >>>>> you feel GDOI is best. The architecture document, however, is not the >>>>>place to promote your solution. >>>>> Many feel that modifications to a standard to support multicast >>>>> is not a good solution. IKE is designed with certain assumptions which >>>>>hold for pairwise paradigms but not necessarily groups. >>>>> Also, because SPD and SAD values for a group cannot be completely >>>>> determined in advance and are more likely distributed as part of the >>>>>Join/Registration process, IKE will not likely be automatically fired >>>>>off anyway (analogous to PPKs). >>>>> Regardless of how you feel on this issue, it is inappropriate to >>>>> state that GDOI is probably the best solution at this point in general >>>>>and certainly not in the architecture document. >>>>> Wrt GSAKMP and separating out the "key management protocol": key >>>>> management involves more than distribution. >>>>> >>>>>--- Andrea >>>>> >>>>> >>>>> >>>>>Mark Baugher wrote: >>>>> >>>>> > Andrea >>>>> > I respond to your first point in this note. >>>>> > >>>>> > At 01:40 PM 6/27/2001 -0400, Andrea Colegrove wrote: >>>>> > >>>>> > >X-Mozilla-Status2: 00000000 >>>>> > >Message-ID: <3B3A1837.D95360C0@columbia.sparta.com> >>>>> > >Date: Wed, 27 Jun 2001 13:30:31 -0400 >>>>> > >From: Andrea Colegrove >>>>> > >X-Mailer: Mozilla 4.75 [en] (Win98; U) >>>>> > >X-Accept-Language: en >>>>> > >MIME-Version: 1.0 >>>>> > >To: msec@securemulticast.org >>>>> > >Subject: Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt >>>>> > >References: <200106271103.HAA26170@ietf.org> >>>>> > >Content-Type: multipart/alternative; >>>>> > > boundary="------------E7B7F4EE607BF84BF270BC1C" >>>>> > > >>>>> > >Mark, etal, >>>>> > >Initial comments on the architecture -- >>>>> > > >>>>> > >1. Section 1. -- >>>>> > >> >>>>> > >>Extensions to IKE, however, are probably the best solution for IPsec >>>>> > >>protocols over IP multicast services [GDOI]. >>>>> > >The architecture document is not an appropriate place for blatant >>>>> > >editorialisms. >>>>> > >>>>> > It is not as you say it is. I'll ignore the rudeness of this >>>>> sentence and >>>>> > focus >>>>> > on the issue: It makes no sense to force AH and ESP to select a >>>>> key management >>>>> > application based on whether it has a unicast or a multicast >>>>> destination >>>>> > address in >>>>> > the packet it is processing. One may want to do that, but >>>>> extensions to >>>>> > IKE are probably >>>>> > the best solution for IPsec protocols over IP multicast >>>>> services. This is >>>>> > an architectural >>>>> > issue for it involves multiple functional blocks (data security >>>>> protocols >>>>> > and key >>>>> > management protocol) , and it is why msec will likely standardize >>>>> an IKE-based >>>>> > specification in addition to a something like GSAKMP (at least the key >>>>> > management >>>>> > protocol of it once that's separated out). >>>>> > >>>>> > I'll spare ipsec my comments on the rest of your points and post >>>>> only to msec. >>>>> > >>>>> > Mark >>>>> > >>>>> > >2. >>>>> > >> >>>>> > >>A "secure group" is a collection of principals, >>>>> > >>called "members," who may be senders, receivers or both receivers and >>>>> > >>senders to other members of the group. (Note that group >>>>> membership may >>>>> > >>vary over time.) A "group key management protocol" ensures that only >>>>> > >>members of a secure group gain access to group data (by gaining >>>>> access >>>>> > >>to group keys) and can authenticate group data. >>>>> > >A secure group is a group in which access to data is restricted to >>>>> > >particular entities. This access can be of read and/or write >>>>> access. In >>>>> > >other words, a group may only have write restrictions and no read >>>>> > >restrictions. While this access may be enforced with group keys, >>>>> it is >>>>> > >mandated by a policy that claims data will only be accepted from >>>>> > >particular entities, which could also be enforced with signature >>>>> keys. A >>>>> > >key distribution protocol alone does not define a secure group. This >>>>> > >really demands a _security management_ protocol that can manage >>>>> keys and >>>>> > >policy. >>>>> > > >>>>> > >3. >>>>> > >> >>>>> > >>4. The key-management protocol must be secure against man-in-the- >>>>> > >> middle, connection-hijacking, and reflection/replay attacks; >>>>> it must >>>>> > >> use best-known practices to thwart denial-of-service attacks. >>>>> > > >>>>> > > >>>>> > >And type attacks. And attacks resulting from lack of explicitness >>>>> > >(mis-routed, mis-interpreted). And interleaved with other protocols >>>>> > >(protocol-oracle), etc. Perhaps it would be better to generalize this >>>>> > >statement. >>>>> > > >>>>> > >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." >>>>> > > >>>>> > >5. Re: video on demand example. The example shows a >>>>> pre-existing group >>>>> > >of all possible members subject to pre-broadcast rekey. One broadcast >>>>> > >would destroy this property. >>>>> > > >>>>> > >6. >>>>> > >> >>>>> > >>A centralized >>>>> > >>group controller (or KDC) that is used in this architecture may >>>>> not be >>>>> > >>the best design for small, interactive groups. But for large, >>>>> single- >>>>> > >>source multicast groups, it is generally undesirable to >>>>> distribute key >>>>> > >>management functions among group members: Unlike small, interactive >>>>> > >>groups, large single-source multicast groups generally need a >>>>> > >>specialized KDC to support large numbers of group members. Large >>>>> > >>distributed simulations, moreover, may combine the need for >>>>> large-grou >>>>> > >>operation with many senders. >>>>> > >Large groups require distributed initial key distribution! Large >>>>> dynamic >>>>> > >groups cannot rely upon a centralized KDC. This does not >>>>> scale. This is >>>>> > >highly inflexible. The VoD example demonstrates this. >>>>> > > >>>>> > >While the interactions with distributed rekey entities is more >>>>> > >complicated, this functionality may be needed in composite multicast >>>>> > >groups of limited scope. >>>>> > > >>>>> > >7. >>>>> > >> >>>>> > >>It may be that no >>>>> > >>single key management protocol can satisfy the scalability >>>>> requirements >>>>> > >>of all group-security applications. This is for further study. >>>>> > >It may be that the security protocols protecting group >>>>> communications data >>>>> > >cannot satisfy each of the possible sender/receiver profiles. This is >>>>> > >less of a security management problem. >>>>> > > >>>>> > >8. >>>>> > >> >>>>> > >>This design is based upon a "group controller" model >>>>> > >>[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group >>>>> > >>owner as the root-of-trust. The group owner designates a key >>>>> > >>distribution center for member registration and re-key. >>>>> > >As was originally envisioned, the group owner CAN (and for large >>>>> or sparse >>>>> > >groups SHOULD) designate multiple key servers. >>>>> > > >>>>> > >9. Section 3.2 -- The term TEK is inappropriately specific. The >>>>> group >>>>> > >may not have encryption requirements, but only authentication. >>>>> > > >>>>> > >10. >>>>> > >> >>>>> > >>Only one SA is optional and that is the Re-key >>>>> > >>SA. >>>>> > > >>>>> > > >>>>> > >Actually, one policy for the Re-Key SA is that there is none. It is >>>>> > >null. Explicitly stating this prevents confusion between missing >>>>> SA info >>>>> > >and optional SA info. Likewise, the registration protocol may involve >>>>> > >manual methods. >>>>> > > >>>>> > >11. >>>>> > >> >>>>> > >>The KDC, moreover, can be delegated when the >>>>> > >>trust infrastructure supports delegation to permit distributed >>>>> > >>operation of the KDC. >>>>> > >This statement, while correct, seems to conflict with the >>>>> statement quoted >>>>> > >in Comment #6. >>>>> > > >>>>> > >12. >>>>> > >> >>>>> > >>MSEC assumes that at least the following group-policy information is >>>>> > >>externally managed. >>>>> > >> o Group owner, authentication method, and delegation method for >>>>> > >> identifying a KDC for the group >>>>> > >> o Group KDC, authentication method, and any method used for >>>>> > >> delegating other KDCs for the group >>>>> > >> o Group membership rules or list and authentication method >>>>> > > >>>>> > > >>>>> > >These assumptions are unnecessary as was shown by GSAKMP. >>>>> > > I. While the group owner may be published externally, the group >>>>> > > owner can also be disclosed during the registration protocol. It >>>>> can be >>>>> > > decided during this time whether the owner is acceptable prior to >>>>> > > completion of registration. Once this occurs, authenticated >>>>> group policy >>>>> > > can be conveyed to the new member using traditional mechanisms >>>>> such as >>>>> > > digital signatures tied to a PKI. >>>>> > > II. The delegation can be stated (authorized) through the >>>>> > > authenticated policy statement as was done with GSAKMP. >>>>> > > III. Ditto for membership rules and lists >>>>> > > IV. The security association characteristics of the registration >>>>> > > protocol can be determined early in the registration exchange or in >>>>> > > almost all protocols (TLS, IPSec, GSAKMP, etc.) can be restricted >>>>> by what >>>>> > > properties the Key Server will accept using cipher suite >>>>> restrictions, >>>>> > > SPD constraints, etc. >>>>> > > >>>>> > > External management of these can be done, but should not be >>>>> assumed >>>>> > > in the architecture document. >>>>> > > >>>>> > >13. In general, this document contains very little new >>>>> information. The >>>>> > >framework for the architecture was already provided by the >>>>> building block >>>>> > >documents with the category 1,2, and 3 SAs. The architecture document >>>>> > >should work toward providing interoperable solutions. >>>>> > > >>>>> > >--- Andrea Colegrove >>>>> > > >>>>> > > >>>>> > > >>>>> > >Internet-Drafts@ietf.org wrote: >>>>> > >>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 : Group Key Management Architecture >>>>> > >> Author(s) : M. Baugher, R. Canetti, L. Dondeti >>>>> > >> Filename : draft-ietf-msec-gkmarch-00.txt >>>>> > >> Pages : 22 >>>>> > >> Date : 26-Jun-01 >>>>> > >> >>>>> > >>This document presents a group key-management architecture for MSEC. >>>>> > >>The purpose of this document is to define the common architecture for >>>>> > >>MSEC group key-management protocols that support a variety of >>>>> > >>application, transport, and internetwork security protocols. To >>>>> > >>address these diverse uses, MSEC may need to standardize two or more >>>>> > >>group key management protocols that have common requirements, >>>>> > >>abstractions, overall design, and messages. The framework and >>>>> > >>guidelines in this document allow for a modular and flexible >>>>> design of >>>>> > >>group key management protocols for a variety different settings that >>>>> > >>are specialized to application needs. >>>>> > >> >>>>> > >>A URL for this Internet-Draft is: >>>>> > >>>>>> >>>> > h t >>>>> tp://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.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-gkmarch-00.txt". >>>>> > >> >>>>> > >>A list of Internet-Drafts directories can be found in >>>>> > >>http://www.ietf.org/shadow.html >>>>> > >>or >>>>> > >>ftp://ftp.ietf.org/ietf >>>>> / 1 s h adow-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-gkmarch-00.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: <20010626132202.I-D@ietf.org> >>>>> >>>>> >>>>>_______________________________________________ >>>>>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 Thu Jun 28 17:25:44 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03895 for ; Thu, 28 Jun 2001 17:25:43 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0E88153733; Thu, 28 Jun 2001 17:25: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 7A4895375F for ; Thu, 28 Jun 2001 17:23:37 -0400 (EDT) Received: (qmail 68203 invoked by uid 3269); 28 Jun 2001 21:23:37 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 68200 invoked from network); 28 Jun 2001 21:23:36 -0000 Received: from m5.sparta.com (root@157.185.61.1) by klesh.pair.com with SMTP; 28 Jun 2001 21:23:36 -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 f5SLNZx07532; Thu, 28 Jun 2001 16:23:35 -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 RAA28378; Thu, 28 Jun 2001 17:23:34 -0400 (EDT) Message-ID: <3B3BA047.86596F68@columbia.sparta.com> From: Andrea Colegrove X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Baugher Cc: Ran Canetti , msec@securemulticast.org Subject: Re: [MSEC] [Fwd: [Fwd: I-DACTION:draft-ietf-msec-gkmarch-00.txt]] References: <200106281801.OAA08228@ornavella.watson.ibm.com> <4.3.2.7.2.20010628140412.0205d4f0@mira-sjc5-6.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: Thu, 28 Jun 2001 17:23:19 -0400 Content-Transfer-Encoding: 7bit Mark, Yes. Which is why I stated it the way I did -- arguably. And if we all were willing to take on the complexity, we would all be extensions to ISAKMP -- IKE, GDOI, and ISAKMP, where ISAKMP is the protocol and the rest are just switches off of it, as it was originally designed! --- Andrea Mark Baugher wrote: > At 04:42 PM 6/28/2001 -0400, Andrea Colegrove wrote: > >Hi, Ran, > > Yes I agree that GDOI works well with IPSec and as far as I am aware, > > GDOI is the > >only extension to IKE for groups right now (although you can argue the > >GSAKMP is an > >extension to ISAKMP). > > An extension to a protocol would at least use the header to that protocol > and for this > reason, GSAKMP is no extension to ISAKMP. If we used the same header then > we might be able to find a way to interoperate. > > Mark > > > If it is a requirement that ESP/AH be serviced without modification > > to IPSec that > >would probably be suitable for the requirements section without reference > >I think to > >either GSAKMP or to GDOI -- once again leaving room for the ACME protocol ;-) > > > > Many of the assumptions in the document are rather GDOI-specific, > > especially the > >policy assumptions. It will be a difficult process for the WG as a whole > >to create an > >independent document that will not limit new protocols > >unnecessarily. Hopefully, we are > >now on our way :-) > > > >--- Andrea > > > > > >Ran Canetti wrote: > > > > > Andrea, > > > > > > Regarding the "offending sentence" in the intro of the new architecture > > draft: > > > > > > > Extensions to IKE, however, are probably the best solution for IPsec > > > > protocols over IP multicast services [GDOI]. > > > > > > I agree with you that the sentence is poorly phrased and invites > > > misinterpretation. It should be rewreitten. Our meaning was to say that > > > That one of the requirements of the architecture is to enable a GKM > > protocol > > > that allows ESP/AH to work within the MSEC protocol suite without any > > changes. > > > This is an important requirement. The reference to GDOI is there since GDOI > > > took it up as an explcit goal to provide this functionality, so the > > meaning was to > > > give it as an example. But GDOI is certainly not the only example. In > > particular, > > > I am certain that a resolution of GSAKMP with IPSEC for the > > registration protocol > > > would be able to provide the same functionality. > > > Do you agree with this view of things? > > > > > > Regarding your note below, I think you're missing some salient points > > in the new > > > draft. (And this ofcourse immediately reflects on the authors, who > > apparently did > > > a poor job of explaining these points.) In particular, it is NOT > > compatible with > > > the current GDOI draft, and GDOI will have to change to fit this > > document. I'll > > > try to provide more details later today or to morrow. So please hold > > your fire... > > > > > > Ran > > > > > > > From: Andrea Colegrove > > > > > > > > Mark, > > > > The architecture document is for specification and discussion of > > technical > > > > issues -- not opinion -- that is the issue at hand. The document has > > been written > > > > as a summary of the BBs with additional constraints and assumptions > > that are not > > > > necessary except that GDOI seems to make these assumptions. This is > > a fairness > > > > issue. > > > > The "title" of editor sometimes seems more appropriate as the > > specifications > > > > that are on standards track should reflect the combined interests of > > the working > > > > group -- it is not intended to be honorary or to detract, but merely > > a reflection > > > > of the responsibilities of the writers of the documents. > > > > I, too, gave technical arguments as to why GDOI may not be the > > perfect fit. It > > > > is not a bad solution, but let us also leave room for the ACME Group > > Security > > > > Management Protocol which Joe Schmo has yet to specify. > > > > > > > > --- Andrea > > > > > > > > > > > > > >_______________________________________________ > >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 Jun 28 17:36:34 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04477 for ; Thu, 28 Jun 2001 17:36:33 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9DDDE536F8; Thu, 28 Jun 2001 17:36: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 6F612536FF for ; Thu, 28 Jun 2001 17:32:59 -0400 (EDT) Received: (qmail 68996 invoked by uid 3269); 28 Jun 2001 21:32:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 68993 invoked from network); 28 Jun 2001 21:32:58 -0000 Received: from m5.sparta.com (root@157.185.61.1) by klesh.pair.com with SMTP; 28 Jun 2001 21:32:58 -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 f5SLWvx07829 for ; Thu, 28 Jun 2001 16:32:57 -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 RAA28486 for ; Thu, 28 Jun 2001 17:32:56 -0400 (EDT) Message-ID: <3B3BA27A.1687F3A8@columbia.sparta.com> From: Andrea Colegrove X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: msec@securemulticast.org Subject: Re: [MSEC] [Fwd: [Fwd: I-DACTION:draft-ietf-msec-gkmarch-00.txt]] References: <200106281801.OAA08228@ornavella.watson.ibm.com> <4.3.2.7.2.20010628140412.0205d4f0@mira-sjc5-6.cisco.com> <3B3BA047.86596F68@columbia.sparta.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: Thu, 28 Jun 2001 17:32:42 -0400 Content-Transfer-Encoding: 7bit That is -- IKE, GDOI, and GSAKMP -- sorry. Andrea Colegrove wrote: > Mark, > Yes. Which is why I stated it the way I did -- arguably. > > And if we all were willing to take on the complexity, we would all be > extensions to ISAKMP -- IKE, GDOI, and ISAKMP, where ISAKMP is the protocol and the > rest are just switches off of it, as it was originally designed! > > --- Andrea > > Mark Baugher wrote: > > > At 04:42 PM 6/28/2001 -0400, Andrea Colegrove wrote: > > >Hi, Ran, > > > Yes I agree that GDOI works well with IPSec and as far as I am aware, > > > GDOI is the > > >only extension to IKE for groups right now (although you can argue the > > >GSAKMP is an > > >extension to ISAKMP). > > > > An extension to a protocol would at least use the header to that protocol > > and for this > > reason, GSAKMP is no extension to ISAKMP. If we used the same header then > > we might be able to find a way to interoperate. > > > > Mark > > > > > If it is a requirement that ESP/AH be serviced without modification > > > to IPSec that > > >would probably be suitable for the requirements section without reference > > >I think to > > >either GSAKMP or to GDOI -- once again leaving room for the ACME protocol ;-) > > > > > > Many of the assumptions in the document are rather GDOI-specific, > > > especially the > > >policy assumptions. It will be a difficult process for the WG as a whole > > >to create an > > >independent document that will not limit new protocols > > >unnecessarily. Hopefully, we are > > >now on our way :-) > > > > > >--- Andrea > > > > > > > > >Ran Canetti wrote: > > > > > > > Andrea, > > > > > > > > Regarding the "offending sentence" in the intro of the new architecture > > > draft: > > > > > > > > > Extensions to IKE, however, are probably the best solution for IPsec > > > > > protocols over IP multicast services [GDOI]. > > > > > > > > I agree with you that the sentence is poorly phrased and invites > > > > misinterpretation. It should be rewreitten. Our meaning was to say that > > > > That one of the requirements of the architecture is to enable a GKM > > > protocol > > > > that allows ESP/AH to work within the MSEC protocol suite without any > > > changes. > > > > This is an important requirement. The reference to GDOI is there since GDOI > > > > took it up as an explcit goal to provide this functionality, so the > > > meaning was to > > > > give it as an example. But GDOI is certainly not the only example. In > > > particular, > > > > I am certain that a resolution of GSAKMP with IPSEC for the > > > registration protocol > > > > would be able to provide the same functionality. > > > > Do you agree with this view of things? > > > > > > > > Regarding your note below, I think you're missing some salient points > > > in the new > > > > draft. (And this ofcourse immediately reflects on the authors, who > > > apparently did > > > > a poor job of explaining these points.) In particular, it is NOT > > > compatible with > > > > the current GDOI draft, and GDOI will have to change to fit this > > > document. I'll > > > > try to provide more details later today or to morrow. So please hold > > > your fire... > > > > > > > > Ran > > > > > > > > > From: Andrea Colegrove > > > > > > > > > > Mark, > > > > > The architecture document is for specification and discussion of > > > technical > > > > > issues -- not opinion -- that is the issue at hand. The document has > > > been written > > > > > as a summary of the BBs with additional constraints and assumptions > > > that are not > > > > > necessary except that GDOI seems to make these assumptions. This is > > > a fairness > > > > > issue. > > > > > The "title" of editor sometimes seems more appropriate as the > > > specifications > > > > > that are on standards track should reflect the combined interests of > > > the working > > > > > group -- it is not intended to be honorary or to detract, but merely > > > a reflection > > > > > of the responsibilities of the writers of the documents. > > > > > I, too, gave technical arguments as to why GDOI may not be the > > > perfect fit. It > > > > > is not a bad solution, but let us also leave room for the ACME Group > > > Security > > > > > Management Protocol which Joe Schmo has yet to specify. > > > > > > > > > > --- Andrea > > > > > > > > > > > > > > > > > > >_______________________________________________ > > >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 Thu Jun 28 17:44:39 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05477 for ; Thu, 28 Jun 2001 17:44:38 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D10405371B; Thu, 28 Jun 2001 17:44: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 0398353730 for ; Thu, 28 Jun 2001 17:42:46 -0400 (EDT) Received: (qmail 69797 invoked by uid 3269); 28 Jun 2001 21:42:45 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 69794 invoked from network); 28 Jun 2001 21:42:45 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by klesh.pair.com with SMTP; 28 Jun 2001 21:42: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 f5SLgHN19947; Thu, 28 Jun 2001 14:42:18 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-449.cisco.com [10.21.65.193]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADG17006; Thu, 28 Jun 2001 14:42:07 -0700 (PDT) Message-Id: <4.3.2.7.2.20010628141335.042f1da0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Andrea Colegrove From: Mark Baugher Subject: Re: [MSEC] Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt Cc: msec@securemulticast.org In-Reply-To: <3B3B902A.2DBED04B@columbia.sparta.com> References: <200106271103.HAA26170@ietf.org> <4.3.2.7.2.20010627202552.0433d4c8@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_29248917==_.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, 28 Jun 2001 14:41:35 -0700 --=====================_29248917==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Andrea Still working through your points... At 04:14 PM 6/28/2001 -0400, Andrea Colegrove wrote: >Mark, >>How about if we change the offending paragraph as follows: >>security services. For these reasons, application, transport, and >>internetwork-layer security protocols such as SRTP, IPsec, and AMESP may >>benefit from using different group key management systems [GSAKMP, GDOI]. >>Extensions to IKE, however, are probably the best solution for IPsec >>protocols over IP multicast services [GDOI]. The purpose of this >> >Yes there is definitely the "one size fits all" vs. the per-security >application approach. It is appropriate to state this in the >intro. Please just remove the opinion of what you feel is the best >solution for IPSec. > >Group and multicast applications have diverse requirements in IP >networks [CP00]. Their key-management requirements, which are briefly >reviewed below (see "Requirements"), include support for internetwork, >transport, and application-layer protocols. In particular, while >Internet-standard ISAKMP and IKE protocols purport to manage keys for >any and all services in a host, some applications may achieve simpler >operation by running key-management messaging over TLS or IPsec >security services. For these reasons, application, transport, and >internetwork-layer security protocols such as SRTP, IPsec, and AMESP >may benefit from using different group key management systems. The purpose >of this document is to define a common architecture and design for these >different group key-management protocols. >> >> A "group key management protocol" ensures that >> only >> members of a secure group gain access to group data (by gaining access >> to group keys) and can authenticate group >> data. >>I'm looking forward to the I-D on security management protocols and >>prefer to stick to key management protocols in this I-D >The statement above is incorrect however. It is only though key >management in conjuction with security association management, access >control, and authorization (i.e., security management) that ensures this >property. (KM is probably necessary but not sufficient, etc, etc.) Like I said, you are invoking something that is not defined in the msec context: Please write an I-D on security management or security association management so we have something to discuss here. Writing "etc, etc" isn't much help, either. >>>>4. The key-management protocol must be secure against man-in-the- >>>> middle, connection-hijacking, and reflection/replay attacks; >>>>it must >>>> use best-known practices to thwart denial-of-service >>>>attacks. >>>And type attacks. And attacks resulting from lack of explicitness >>>(mis-routed, mis-interpreted). And interleaved with other protocols >>>(protocol-oracle), etc. Perhaps it would be better to generalize this >>>statement. >> >> >>Would you please provide references for these attacks? >> >Sure. For starters check Clark and Jacob's "Security Protocols: An >Annotated Bibliography", Abadi and Needham's"Prudent Engineering Practice >for Cryptographic Protocol", Ulf Carlsen's "Cryptographic Protocol >Flaws." Ross Anderson also has a good paper that applies to public key >protocols and Schneier (and Wagner?) have one on multiprotocol attacks. > >My point was only that it might be better to generalize than to list. thanks. I took this from the IKE, ISAKMP, Photuris, and STS papers as being the basic protections needed for key management and each are generalized types of attacks, like man-in-the-middle since there are a number of things that a man-in-the-middle might do. >>>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." >> >> >>Not in IKE it isn't. Again, I await the I-D on the security management >>protocol. >> >IKE says: >A security association (SA) is a set of policy and key(s) used to protect >information. The ISAKMP > SA is the shared policy and key(s) used by the negotiating peers in > this protocol to protect their > communication. That's right and the policy is carried in the SA payload. >Access control and delegation are two of the assumptions that pairwise >communication does not need to consider: You know who you are going to >talk to (your peer), you will only communicate if both your policies >(SPDs) allow it, and you figure that they are authorized to negotiate on >behalf of themselves. What's the point? >There is a lot of policy involved in IKE. The rest of the security >association is certainly not just meta-data describing the keys. >>>5. Re: video on demand example. The example shows a pre-existing >>>group of all possible members subject to pre-broadcast rekey. One >>>broadcast would destroy this property. >> >> >>What is the property that would be destroyed? What exactly is the problem? >> >> >The example wasn't clear to me but it appeared that you were stating that >the potential audience was a group and requirement 6 (rekey) supported the >access control to video broadcasts. If this is what you meant, then each >time some of the members were excluded from a broadcast, a smaller >potential audience resulted for the next one. I don't understand. >> >>>6. >>>> >>>> >>>>A centralized >>>>group controller (or KDC) that is used in this architecture may not be >>>>the best design for small, interactive groups. But for large, >>>>single- >>>>source multicast groups, it is generally undesirable to distribute key >>>>management functions among group members: Unlike small, interactive >>>>groups, large single-source multicast groups generally need a >>>>specialized KDC to support large numbers of group members. Large >>>>distributed simulations, moreover, may combine the need for large-grou >>>>operation with many >>>>senders. >>>Large groups require distributed initial key distribution! Large >>>dynamic groups cannot rely upon a centralized KDC. This does not >>>scale. This is highly inflexible. The VoD example demonstrates this. >"But for large, >single- >source multicast groups, it is generally undesirable to distribute key >management functions among group members" > >Please support this with evidence. Also, wouldn't it be best to just >discuss the requirements and design constraints but not suggest solutions >here? DirecTV is a good example. TV conditional access systems don't allow STBs to become group controllers. The need to support large numbers of receivers, or to quickly remove members, or to have very short latency in joining or re-keying a group are the requirements and design constraints. We have commercial systems that optimize for a subset of these constraints and some of the others listed in Section 2. >>>8. >>>> >>>> >>>>This design is based upon a "group controller" model >>>>[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group >>>>owner as the root-of-trust. The group owner designates a key >>>>distribution center for member registration and >>>>re-key. >>>As was originally envisioned, the group owner CAN (and for large or >>>sparse groups SHOULD) designate multiple key servers. >> >> >>The architecture recommends that this be done by allowing any key server >>to serve keys that is authorized to do so by the group owner. The most >>straightforward way to do this is to use SPKI or X.509 >>delegation. That's what we are recommending rather than coding this up >>in the key management protocol. >> >It is fair to say that the key server must provide proof of delegation. I >_believe_ SPKI (SDSI) delegation is not widely used, but cannot support >this. X. 509 attributes is a fair way of doing this, but is only one >way. Whether it is more straightforward is a matter of opinion. Please tell me why SPKI delegation will not do this. I believe it can. If we need to fix something in the trust infrastructure, I would not build the solution into the key management protocol but fix the trust infrastructure. Otherwise the key management protocol will end up having all sorts of strange and inappropriate features that make it difficult to implement and impossible to test. >>>9. Section 3.2 -- The term TEK is inappropriately specific. The group >>>may not have encryption requirements, but only authentication. >> >>TEK has a long history in the group key management literature. But you >>have a point, it may not be needed for authentication. We need to review >>this. >> >TEK = Traffic ENCRYPTION Key. And yes, this term goes back way before >open literature even. >>>11. >>>> >>>> >>>>The KDC, moreover, can be delegated when the >>>>trust infrastructure supports delegation to permit distributed >>>>operation of the >>>>KDC. >>>This statement, while correct, seems to conflict with the statement >>>quoted in Comment #6. >> >> >>Comment #6 was citing a requirements discussion. now we are into >>design. There are ways to load balance, get high-availability, and get >>fault tolerance for a server without inventing distributed key server >>protocols (such as a leader election algorithm, inter-KDC protocols). >> >> >Okay. The design is inconsistent with the requirement? >Load sharing is certainly different than delegation -- I am not sure what >your point is. Section 2, requirements, referred to a general taxonomy or framework and past work such as RFC2627 and OFT. We gathered and summarized the requirements in section 2. The design is to be measured against the very general requirement and we said, first and foremost, that we must support source-specific multicast. Developing a "distributed design" where each member could be a controller is not necessary for the basic requirement of source-specific multicast. But we must support large-scale operation. There are ways such as load balancing, high-availability, and fault-tolerant methods to do that but we still do not have a distributed key server in my opinion but a load-balanced or highly-available or fault-tolerant centralized server. On the other hand, there is delegation and this allows other device to source keys on behalf of the key server. I particularly like the idea of allowing the media server to be delegated to send out keys (SAs) for data-security protocols on behalf of the key server. But we still do not have a distributed key server in that not all members need to have the capability to be key servers. Section 5 of the I-D also notes that the fly-in-the-ointment might be the need to develop an inter-KDC protocol to make this work. I don't think it is necessary, but we need to look closely at this assumption. >> >>>12. >>>> >>>> >>>>MSEC assumes that at least the following group-policy information >>>>is >>>>externally managed. >>>> o Group owner, authentication method, and delegation method for >>>> identifying a KDC for the group >>>> o Group KDC, authentication method, and any method used for >>>> delegating other KDCs for the group >>>> o Group membership rules or list and authentication >>>>method >>>These assumptions are unnecessary as was shown by GSAKMP. >> >> >>These assumptions were put into the GDOI draft at Hugh's behest and it >>helped clarify our thinking on how to minimize group policy functions in >>key management. I recommended to Ran and Lakshminath that we consider >>including these assumptions in the GKM architecture I-D. They agreed and >>Lakshminath did that. If we don't do that, then we will encumber the key >>management specification with a lot of policy issues that the working >>group has agreed belonged in a policy draft. You may not agree with >>everything the WG decides to do. WGs are like that. >> >Oh are you the working group? There you go again. We hold meetings and post minutes. Please refer to them. >Just because it is an appropriate assumption for GDOI does make it >appropriate for all. >> >>> I. While the group owner may be published externally, the group >>> owner can also be disclosed during the registration protocol. It can >>> be decided during this time whether the owner is acceptable prior to >>> completion of registration. Once this occurs, authenticated group >>> policy can be conveyed to the new member using traditional mechanisms >>> such as digital signatures tied to a PKI. >>> II. The delegation can be stated (authorized) through the >>> authenticated policy statement as was done with GSAKMP. >>> III. Ditto for membership rules and lists >>> IV. The security association characteristics of the registration >>> protocol can be determined early in the registration exchange or in >>> almost all protocols (TLS, IPSec, GSAKMP, etc.) can be restricted by >>> what properties the Key Server will accept using cipher suite >>> restrictions, SPD constraints, etc. >>> >>> External management of these can be done, but should not be assumed >>> in the architecture document. >>> >>>13. In general, this document contains very little new >>>information. The framework for the architecture was already provided by >>>the building block documents with the category 1,2, and 3 SAs. The >>>architecture document should work toward providing interoperable solutions. >> >> >>We're not shooting for novelty here. Quite the contrary. The I-D is to >>progress as a product of the msec WG in order to bring two or more key >>management protocols to address common requirements, use common >>abstractions, and messages. These two or more protocols cannot >>interoperate unless they at least use a common header. GDOI uses an >>ISAKMP header for obvious reasons. GSAKMP does not use an ISAKMP header. >>If they could interoperate, then we would not go to the trouble of >>specifying two or more key management protocols. >> >The requirements need to drive the protocol selection not the other way >around. >Common abstractions are good, common messages imply a common protocol. Not if you want GSAKMP to use a non-standard header. We can specify common messages for the Re-key protocol up to the header. At that point GSAKMP and GDOI part ways. Mark >--- Andrea --=====================_29248917==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Andrea
  Still working through your points...

At 04:14 PM 6/28/2001 -0400, Andrea Colegrove wrote:
Mark,
How about if we change the offending paragraph as follows:
security services.  For these reasons, application, transport, and internetwork-layer security protocols such as SRTP, IPsec, and AMESP may benefit from using different group key management systems [GSAKMP, GDOI]. Extensions to IKE, however, are probably the best solution for IPsec protocols over IP multicast services [GDOI].  The purpose of this
 
Yes there is definitely the "one size fits all" vs. the per-security application approach.  It is appropriate to state this in the intro.  Please just remove the opinion of what you feel is the best solution for IPSec.

Group and multicast applications have diverse requirements in IP
networks [CP00].  Their key-management requirements, which are briefly
reviewed below (see "Requirements"), include support for internetwork,
transport, and application-layer protocols.  In particular, while
Internet-standard ISAKMP and IKE protocols purport to manage keys for
any and all services in a host, some applications may achieve simpler
operation by running key-management messaging over TLS or IPsec
security services.  For these reasons, application, transport, and
internetwork-layer security protocols such as SRTP, IPsec, and AMESP
may benefit from using different group key management systems. The purpose of this document is to define a common architecture and design for these different group key-management protocols. 

 A "group key management protocol" ensures that
    only=20
    members of a secure group gain access to group data
(by gaining access=20
    to group keys) and can authenticate group
   
data.

I'm looking forward to the I-D on security management protocols and
prefer to stick to key management protocols in this
I-D
The statement above is incorrect however.  It is only though key management in conjuction with security association management, access control, and authorization (i.e., security management) that ensures this property.  (KM is probably necessary but not sufficient, etc, etc.)

Like I said, you are invoking something that is not defined in the msec context:  Please write an I-D on security management or security association management so we have something to discuss here.  Writing "etc, etc" isn't much help, either.


4.
The key-management protocol must be secure against man-in-the-
   middle, connection-hijacking, and reflection/replay
attacks;
it must
   use best-known practices to thwart denial-of-service
attacks.
And type attacks.  And attacks resulting from lack of explicitness (mis-routed, mis-interpreted).  And interleaved with other protocols (protocol-oracle), etc.  Perhaps it would be better to generalize this statement.


Would you please provide references for these attacks?
 
Sure.  For starters check Clark and Jacob's "Security Protocols:  An Annotated Bibliography", Abadi and Needham's"Prudent Engineering Practice for Cryptographic Protocol", Ulf Carlsen's "Cryptographic Protocol Flaws."  Ross Anderson also has a good paper that applies to public key protocols and Schneier (and Wagner?) have one on multiprotocol attacks.

My point was only that it might be better to generalize than to list.
thanks.  I took this from the IKE, ISAKMP, Photuris, and STS papers as being the basic protections needed for key management and each are generalized types of attacks, like man-in-the-middle since there are a number of things that a man-in-the-middle might do.


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."


Not in IKE it isn't.  Again, I await the I-D on the security management protocol.
 
IKE says:
A security association (SA) is a set of policy and key(s) used to protect information. The ISAKMP
    SA is the shared policy and key(s) used by the negotiating peers in this protocol to protect their
    communication.
That's right and the policy is carried in the SA payload.


Access control and delegation are two of the assumptions that pairwise communication does not need to consider:  You know who you are going to talk to (your peer), you will only communicate if both your policies (SPDs) allow it, and you figure that they are authorized to negotiate on behalf of themselves.

What's the point?


There is a lot of policy involved in IKE.  The rest of the security association is certainly not just meta-data describing the keys.
5.  Re:  video on demand example.   The example shows a pre-existing group of all possible members subject to pre-broadcast rekey.  One broadcast would destroy this property.


What is the property that would be destroyed?  What exactly is the problem?
 
 
The example wasn't clear to me but it appeared that you were stating that the potential audience was a group and requirement 6 (rekey) supported the access control to video broadcasts.  If this is what you meant, then each time some of the members were excluded from a broadcast, a smaller potential audience resulted for the next one.

I don't understand.

 
6.
 
  
A centralized
group controller (or KDC) that is used in this architecture may not be=20
the best design for small, interactive groups.  But for large,
single-
source multicast groups, it is generally undesirable to distribute key=20
management functions among group members: Unlike small, interactive=20
groups, large single-source multicast groups generally need a=20
specialized KDC to support large numbers of group members.  Large=20
distributed simulations, moreover, may combine the need for large-grou=20
operation with many
senders.
Large groups require distributed initial key distribution!  Large dynamic groups cannot rely upon a centralized KDC.  This does not scale.  This is highly inflexible.  The VoD example demonstrates this.
"But for large,
single-
source multicast groups, it is generally undesirable to distribute key
management functions among group members"

Please support this with evidence.  Also, wouldn't it be best to just discuss the requirements and design constraints but not suggest solutions here?

DirecTV is a good example. TV conditional access systems don't allow STBs to become group controllers.  The need to support large numbers of receivers, or to quickly remove members, or to have very short latency in joining or re-keying a group are the requirements and design constraints.  We have commercial systems that optimize for a subset of these constraints and some of the others listed in Section 2.

8.
 
  
This design is based upon a "group controller" model=20
[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group=20
owner as the root-of-trust.  The group owner designates a key=20
distribution center for member registration and
re-key.
As was originally envisioned, the group owner CAN (and for large or sparse groups SHOULD) designate multiple key servers.


The architecture recommends that this be done by allowing any key server to serve keys that is authorized to do so by the group owner.  The most straightforward way to do this is to use SPKI or X.509 delegation.  That's what we are recommending rather than coding this up in the key management protocol.
 
It is fair to say that the key server must provide proof of delegation.  I _believe_ SPKI (SDSI) delegation is not widely used, but cannot support this.  X. 509 attributes is a fair way of doing this, but is only one way.  Whether it is more straightforward is a matter of opinion.
Please tell me why SPKI delegation will not do this.  I believe it can.  If we need to fix something in the trust infrastructure, I would not build the solution into the key management protocol but fix the trust infrastructure.  Otherwise the key management protocol will end up having all sorts of strange and inappropriate features that make it difficult to implement and impossible to test.

9.  Section 3.2 -- The term TEK is inappropriately specific.  The group may not have encryption requirements, but only authentication.

TEK has a long history in the group key management literature.  But you have a point, it may not be needed for authentication.  We need to review this.
 
TEK =3D Traffic ENCRYPTION Key.  And yes, this term goes back way before open literature even.
11.
 
  
The KDC, moreover, can be delegated when the=20
trust infrastructure supports delegation to permit distributed=20
operation of the
KDC.
This statement, while correct, seems to conflict with the statement quoted in Comment #6.


Comment #6 was citing a requirements discussion.  now we are into design.  There are ways to load balance, get high-availability, and get fault tolerance for a server without inventing distributed key server protocols (such as a leader election algorithm, inter-KDC protocols).
 
 
Okay.  The design is inconsistent with the requirement?
Load sharing is certainly different than delegation -- I am not sure what your point is.
Section 2, requirements, referred to a general taxonomy or framework and past work such as RFC2627 and OFT.  We gathered and summarized the requirements in section 2.  The design is to be measured against the very general requirement and we said, first and foremost, that we must support source-specific multicast.  Developing a "distributed design" where each member could be a controller is not necessary for the basic requirement of source-specific multicast.  But we must support large-scale operation.  There are ways such as load balancing, high-availability, and fault-tolerant methods to do that but we still do not have a distributed key server in my opinion but a load-balanced or highly-available or fault-tolerant centralized server.  On the other hand, there is delegation and this allows other device to source keys on behalf of the key server.  I particularly like the idea of allowing the media server to be delegated to send out keys (SAs) for data-security protocols on behalf of the key server.  But we still do not have a distributed key server in that not all members need to have the capability to be key servers.  Section 5 of the I-D also notes that the fly-in-the-ointment might be the need to develop an inter-KDC protocol to make this work.  I don't think it is necessary, but we need to look closely at this assumption.

 
12.
 
  
MSEC assumes that at least the following group-policy information
is
externally managed.
  o Group owner, authentication method, and delegation method for=20
    identifying a KDC for the group
  o Group KDC, authentication method, and any method used for
    delegating other KDCs for the group
  o Group membership rules or list and authentication
method
These assumptions are unnecessary as was shown by GSAKMP.


These assumptions were put into the GDOI draft at Hugh's behest and it helped clarify our thinking on how to minimize group policy functions in key management.   I recommended to Ran and Lakshminath that we consider including these assumptions in the GKM architecture I-D.  They agreed and Lakshminath did that.  If we don't do that, then we will encumber the key management specification with a lot of policy issues that the working group has agreed belonged in a policy draft.  You may not agree with everything the WG decides to do.  WGs are like that.
 
Oh are you the working group?

There you go again.  We hold meetings and post minutes.  Please refer to them.

Just because it is an appropriate assumption for GDOI does make it appropriate for all.
 
    I.  While the group owner may be published externally, the group owner can also be disclosed during the registration protocol.  It can be decided during this time whether the owner is acceptable prior to completion of registration.  Once this occurs, authenticated group policy can be conveyed to the new member using traditional mechanisms such as digital signatures tied to a PKI.
    II.  The delegation can be stated (authorized) through the authenticated policy statement as was done with GSAKMP.=20
    III.  Ditto for membership rules and lists
    IV.  The security association characteristics of the registration protocol can be determined early in the registration exchange or in almost all protocols (TLS, IPSec, GSAKMP, etc.) can be restricted by what properties the Key Server will accept using cipher suite restrictions, SPD constraints, etc.

    External management of these can be done, but should not be assumed in the architecture document.

13.  In general, this document contains very little new information.  The framework for the architecture was already provided by the building block documents with the category 1,2, and 3 SAs.  The architecture document should work toward providing interoperable solutions.


We're not shooting for novelty here.  Quite the contrary.  The I-D is to progress as a product of the msec WG in order to bring two or more key management protocols to address common requirements, use common abstractions, and messages.  These two or more protocols cannot interoperate unless they at least use a common header.  GDOI uses an ISAKMP header for obvious reasons.  GSAKMP does not use an ISAKMP header. If they could interoperate, then we would not go to the trouble of specifying two or more key management protocols.
 
The requirements need to drive the protocol selection not the other way around.
Common abstractions are good, common messages imply a common protocol.

Not if you want GSAKMP to use a non-standard header.  We can specify common messages for the Re-key protocol up to the header.  At that point GSAKMP and GDOI part ways.

Mark


--- Andrea
--=====================_29248917==_.ALT-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jun 28 18:44:46 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17133 for ; Thu, 28 Jun 2001 18:44:45 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 5300953742; Thu, 28 Jun 2001 18:44: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 D1F225365F for ; Thu, 28 Jun 2001 18:43:19 -0400 (EDT) Received: (qmail 74472 invoked by uid 3269); 28 Jun 2001 22:43:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 74469 invoked from network); 28 Jun 2001 22:43:19 -0000 Received: from m5.sparta.com (root@157.185.61.1) by klesh.pair.com with SMTP; 28 Jun 2001 22:43:19 -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 f5SMhGx09759; Thu, 28 Jun 2001 17:43:17 -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 SAA29038; Thu, 28 Jun 2001 18:43:15 -0400 (EDT) Message-ID: <3B3BB2F4.7CE260F6@columbia.sparta.com> From: Andrea Colegrove X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Baugher , msec@securemulticast.org Subject: Re: [MSEC] Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt References: <200106271103.HAA26170@ietf.org> <4.3.2.7.2.20010627202552.0433d4c8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010628141335.042f1da0@mira-sjc5-6.cisco.com> Content-Type: multipart/alternative; boundary="------------D097C38E72E04603FDF62745" 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, 28 Jun 2001 18:43:00 -0400 --------------D097C38E72E04603FDF62745 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark, >> > >> > >> > A "group key management protocol" ensures that >> > only >> > members of a secure group gain access to group data >> > (by gaining access >> > to group keys) and can authenticate group >> > >> > data. >> > >> > >> >> > >> > >> > I'm looking forward to the I-D on security management protocols and >> > prefer to stick to key management protocols in this >> > I-D >> > >> The statement above is incorrect however. It is only though key >> management in conjuction with security association management, >> access control, and authorization (i.e., security management) that >> ensures this property. (KM is probably necessary but not >> sufficient, etc, etc.) > > > Like I said, you are invoking something that is not defined in the > msec context: Please write an I-D on security management or security > association management so we have something to discuss here. Writing > "etc, etc" isn't much help, either. How about "A group key management protocol helps to ensure that only members of a secure group gain access to group data (by gaining access to group keys) and can authenticate group data." What you have currently is wrong. Key management is a necessary but not sufficient service. Is this clearer? > > > >> >> > 4. >> >> > The key-management protocol must be secure against man-in-the- >> >> > middle, connection-hijacking, and reflection/replay >> >> > attacks; >> >> > it must >> >> > use best-known practices to thwart denial-of-service >> >> > attacks. >> >> > >> >> And type attacks. And attacks resulting from lack of >> >> explicitness (mis-routed, mis-interpreted). And interleaved with >> >> other protocols (protocol-oracle), etc. Perhaps it would be >> >> better to generalize this statement. >> > >> > Would you please provide references for these attacks? >> >> Sure. For starters check Clark and Jacob's "Security Protocols: An >> Annotated Bibliography", Abadi and Needham's"Prudent Engineering >> Practice for Cryptographic Protocol", Ulf Carlsen's "Cryptographic >> Protocol Flaws." Ross Anderson also has a good paper that applies >> to public key protocols and Schneier (and Wagner?) have one on >> multiprotocol attacks. >> >> My point was only that it might be better to generalize than to >> list. > > > thanks. I took this from the IKE, ISAKMP, Photuris, and STS papers as > being the basic protections needed for key management and each are > generalized types of attacks, like man-in-the-middle since there are a > number of things that a man-in-the-middle might do. > > I understand -- there are others that cannot be generalized quite as well, such as protocol-oracle which is not really a man-in-the-middle and not really a replay since it is used in another protocol. We just don't want one to slip through the requirements cracks. How about "The key management protocols must be secure against protocol attacks against the provided security services and must use best ..." > > >> >> 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." >> > >> > Not in IKE it isn't. Again, I await the I-D on the security >> > management protocol. >> >> IKE says: >> A security association (SA) is a set of policy and key(s) used to >> protect information. The ISAKMP >> SA is the shared policy and key(s) used by the negotiating peers >> in this protocol to protect their >> communication. > > > That's right and the policy is carried in the SA payload. > so? > > > >> Access control and delegation are two of the assumptions that >> pairwise communication does not need to consider: You know who you >> are going to talk to (your peer), you will only communicate if both >> your policies (SPDs) allow it, and you figure that they are >> authorized to negotiate on behalf of themselves. > > > What's the point? > > > >> There is a lot of policy involved in IKE. The rest of the security >> association is certainly not just meta-data describing the keys. > The point is "There is a lot of policy involved in IKE. The rest of the security association is certainly not just meta-data describing the keys. " >> >> >> >> 5. Re: video on demand example. The example shows a >> >> pre-existing group of all possible members subject to >> >> pre-broadcast rekey. One broadcast would destroy this property. >> > >> > What is the property that would be destroyed? What exactly is the >> > problem? >> > >> >> The example wasn't clear to me but it appeared that you were stating >> that the potential audience was a group and requirement 6 (rekey) >> supported the access control to video broadcasts. If this is what >> you meant, then each time some of the members were excluded from a >> broadcast, a smaller potential audience resulted for the next one. > > > I don't understand. I am trying to restate what I think you said and you don't understand. Could you restate the example so that we can determine whether there is a limitation or not? Thanks. > > >> > >> > >> >> 6. >> >> >> >> > >> >> > >> >> > >> >> > A centralized >> >> > group controller (or KDC) that is used in this architecture may not be >> >> > the best design for small, interactive groups. But for large, >> >> > single- >> >> > source multicast groups, it is generally undesirable to distribute key >> >> > management functions among group members: Unlike small, interactive >> >> > groups, large single-source multicast groups generally need a >> >> > specialized KDC to support large numbers of group members. Large >> >> > distributed simulations, moreover, may combine the need for large-grou >> >> > operation with many >> >> > senders. >> >> > >> >> Large groups require distributed initial key distribution! Large >> >> dynamic groups cannot rely upon a centralized KDC. This does not >> >> scale. This is highly inflexible. The VoD example demonstrates >> >> this. >> > >> "But for large, >> single- >> source multicast groups, it is generally undesirable to distribute >> key >> management functions among group members" >> >> Please support this with evidence. Also, wouldn't it be best to >> just discuss the requirements and design constraints but not suggest >> solutions here? > > > DirecTV is a good example. TV conditional access systems don't allow > STBs to become group controllers. The need to support large numbers > of receivers, or to quickly remove members, or to have very short > latency in joining or re-keying a group are the requirements and > design constraints. We have commercial systems that optimize for a > subset of these constraints and some of the others listed in Section > 2. > I don't think that this is a general example. If this were for the internet, what is wrong with saying address a.b.c.d or a.b.c.e or a.b.c.f can serve you? (Any key server that "sees" unencrypted keys is by default a member.) > > >> >> 8. >> >> >> >> > >> >> > >> >> > >> >> > This design is based upon a "group controller" model >> >> > [RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group >> >> > owner as the root-of-trust. The group owner designates a key >> >> > distribution center for member registration and >> >> > re-key. >> >> > >> >> As was originally envisioned, the group owner CAN (and for large >> >> or sparse groups SHOULD) designate multiple key servers. >> > >> > The architecture recommends that this be done by allowing any key >> > server to serve keys that is authorized to do so by the group >> > owner. The most straightforward way to do this is to use SPKI or >> > X.509 delegation. That's what we are recommending rather than >> > coding this up in the key management protocol. >> >> It is fair to say that the key server must provide proof of >> delegation. I _believe_ SPKI (SDSI) delegation is not widely used, >> but cannot support this. X. 509 attributes is a fair way of doing >> this, but is only one way. Whether it is more straightforward is a >> matter of opinion. > > > Please tell me why SPKI delegation will not do this. I believe it > can. If we need to fix something in the trust infrastructure, I would > not build the solution into the key management protocol but fix the > trust infrastructure. Otherwise the key management protocol will end > up having all sorts of strange and inappropriate features that make it > difficult to implement and impossible to test. > My typo again. SPKI delegation is not widely used but can support this. The X.509 is available. It is a mechanism that provides some proof of authorization. For example in GSAKMP, it can be one of the certificates passed with the INVITATION message with the token containing the rule for key server of "attribute certificate signed by root x". Or alternatively, not using attribute certificates, it can just be a key server rule that says it must have an "identity cert signed by root y where the identity conforms to the rule name = a.b.c.?". I don't think that this is a strange and inappropriate feature. >> >> > The KDC, moreover, can be delegated when the >> >> > trust infrastructure supports delegation to permit distributed >> >> > operation of the >> >> > KDC. >> >> > >> >> This statement, while correct, seems to conflict with the >> >> statement quoted in Comment #6. >> > >> > Comment #6 was citing a requirements discussion. now we are into >> > design. There are ways to load balance, get high-availability, and >> > get fault tolerance for a server without inventing distributed key >> > server protocols (such as a leader election algorithm, inter-KDC >> > protocols). >> > >> >> Okay. The design is inconsistent with the requirement? >> Load sharing is certainly different than delegation -- I am not sure >> what your point is. > > > Section 2, requirements, referred to a general taxonomy or framework > and past work such as RFC2627 and OFT. We gathered and summarized the > requirements in section 2. The design is to be measured against the > very general requirement and we said, first and foremost, that we must > support source-specific multicast. Developing a "distributed design" > where each member could be a controller is not necessary for the basic > requirement of source-specific multicast. But we must support > large-scale operation. There are ways such as load balancing, > high-availability, and fault-tolerant methods to do that but we still > do not have a distributed key server in my opinion but a load-balanced > or highly-available or fault-tolerant centralized server. On the > other hand, there is delegation and this allows other device to source > keys on behalf of the key server. I particularly like the idea of > allowing the media server to be delegated to send out keys (SAs) for > data-security protocols on behalf of the key server. But we still do > not have a distributed key server in that not all members need to have > the capability to be key servers. Section 5 of the I-D also notes > that the fly-in-the-ointment might be the need to develop an inter-KDC > protocol to make this work. I don't think it is necessary, but we > need to look closely at this assumption. > I don't think distributed means all members need to have the capability to be key servers. "Developing a "distributed design" where each member could be a controller is not necessary for the basic requirement of source-specific multicast. " is not the same as "it is generally undesirable to distribute key management functions among group members". Don't make distributed key management functions a requirement, but certainly do not preclude it or discourage it. > > >> > >> > >> >> 12. >> >> >> >> > >> >> > >> >> > >> >> > MSEC assumes that at least the following group-policy information >> >> > is >> >> > externally managed. >> >> > o Group owner, authentication method, and delegation method for >> >> > identifying a KDC for the group >> >> > o Group KDC, authentication method, and any method used for >> >> > delegating other KDCs for the group >> >> > o Group membership rules or list and authentication >> >> > method >> >> > >> >> These assumptions are unnecessary as was shown by GSAKMP. >> > >> > These assumptions were put into the GDOI draft at Hugh's behest and >> > it helped clarify our thinking on how to minimize group policy >> > functions in key management. I recommended to Ran and Lakshminath >> > that we consider including these assumptions in the GKM >> > architecture I-D. They agreed and Lakshminath did that. If we >> > don't do that, then we will encumber the key management >> > specification with a lot of policy issues that the working group >> > has agreed belonged in a policy draft. You may not agree with >> > everything the WG decides to do. WGs are like that. >> >> Oh are you the working group? > > > There you go again. We hold meetings and post minutes. Please refer > to them. > Believe me I do. Separating policy specifics into a separate draft is very different from saying that the list of policy elements above is assumed to be managed externally from the key management protocol. Distribution is a part of management. Policy elements MAY be managed externally. Please stop twisting the issues. >> > We're not shooting for novelty here. Quite the contrary. The I-D >> > is to progress as a product of the msec WG in order to bring two or >> > more key management protocols to address common requirements, use >> > common abstractions, and messages. These two or more protocols >> > cannot interoperate unless they at least use a common header. GDOI >> > uses an ISAKMP header for obvious reasons. GSAKMP does not use an >> > ISAKMP header. If they could interoperate, then we would not go to >> > the trouble of specifying two or more key management protocols. >> >> The requirements need to drive the protocol selection not the other >> way around. >> Common abstractions are good, common messages imply a common >> protocol. > > > Not if you want GSAKMP to use a non-standard header. We can specify > common messages for the Re-key protocol up to the header. At that > point GSAKMP and GDOI part ways. You missed my point. Different protocols use different messages. I think Ran's message was pretty clear about the requirements and abstractions. Why would the messages be the same? --- Andrea > > > Mark > > > >> --- Andrea > --------------D097C38E72E04603FDF62745 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Mark,
  
 A "group key management protocol" ensures that
    only 
    members of a secure group gain access to group data
(by gaining access 
    to group keys) and can authenticate group
   
data.
 
  
I'm looking forward to the I-D on security management protocols and
prefer to stick to key management protocols in this
I-D
The statement above is incorrect however.  It is only though key management in conjuction with security association management, access control, and authorization (i.e., security management) that ensures this property.  (KM is probably necessary but not sufficient, etc, etc.)


Like I said, you are invoking something that is not defined in the msec context:  Please write an I-D on security management or security association management so we have something to discuss here.  Writing "etc, etc" isn't much help, either.

How about
"A group key management protocol helps to ensure that only members of a secure group
gain access to group data (by gaining access to group keys) and can authenticate
group data."
What you have currently is wrong.  Key management is a necessary but not sufficient
service.  Is this clearer?
 
  
4.
The key-management protocol must be secure against man-in-the-
   middle, connection-hijacking, and reflection/replay
attacks;
it must
   use best-known practices to thwart denial-of-service
attacks.
And type attacks.  And attacks resulting from lack of explicitness (mis-routed, mis-interpreted).  And interleaved with other protocols (protocol-oracle), etc.  Perhaps it would be better to generalize this statement.

Would you please provide references for these attacks?

Sure.  For starters check Clark and Jacob's "Security Protocols:  An Annotated Bibliography", Abadi and Needham's"Prudent Engineering Practice for Cryptographic Protocol", Ulf Carlsen's "Cryptographic Protocol Flaws."  Ross Anderson also has a good paper that applies to public key protocols and Schneier (and Wagner?) have one on multiprotocol attacks.

My point was only that it might be better to generalize than to list.


thanks.  I took this from the IKE, ISAKMP, Photuris, and STS papers as being the basic protections needed for key management and each are generalized types of attacks, like man-in-the-middle since there are a number of things that a man-in-the-middle might do.
 
 

I understand -- there are others that cannot be generalized quite as well, such as protocol-oracle which is not really a man-in-the-middle and not really a replay since it is used in another protocol.  We just don't want one to slip through the requirements cracks.  How about "The key management protocols must be secure against protocol attacks against the provided security services and must use best ..."
 
 
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."

Not in IKE it isn't.  Again, I await the I-D on the security management protocol.

IKE says:
A security association (SA) is a set of policy and key(s) used to protect information. The ISAKMP
    SA is the shared policy and key(s) used by the negotiating peers in this protocol to protect their
    communication.


That's right and the policy is carried in the SA payload.
 

so?
 
 
Access control and delegation are two of the assumptions that pairwise communication does not need to consider:  You know who you are going to talk to (your peer), you will only communicate if both your policies (SPDs) allow it, and you figure that they are authorized to negotiate on behalf of themselves.


What's the point?
 
 

There is a lot of policy involved in IKE.  The rest of the security association is certainly not just meta-data describing the keys.


The point is "There is a lot of policy involved in IKE.  The rest of the security association is certainly not just meta-data describing the keys. "

 
5.  Re:  video on demand example.   The example shows a pre-existing group of all possible members subject to pre-broadcast rekey.  One broadcast would destroy this property.

What is the property that would be destroyed?  What exactly is the problem?
 

The example wasn't clear to me but it appeared that you were stating that the potential audience was a group and requirement 6 (rekey) supported the access control to video broadcasts.  If this is what you meant, then each time some of the members were excluded from a broadcast, a smaller potential audience resulted for the next one.


I don't understand.

I am trying to restate what I think you said and you don't understand.  Could you restate the example so that we can determine whether there is a limitation or not?  Thanks.
 
 
6.
 
  
A centralized
group controller (or KDC) that is used in this architecture may not be 
the best design for small, interactive groups.  But for large,
single-
source multicast groups, it is generally undesirable to distribute key 
management functions among group members: Unlike small, interactive 
groups, large single-source multicast groups generally need a 
specialized KDC to support large numbers of group members.  Large 
distributed simulations, moreover, may combine the need for large-grou 
operation with many
senders.
Large groups require distributed initial key distribution!  Large dynamic groups cannot rely upon a centralized KDC.  This does not scale.  This is highly inflexible.  The VoD example demonstrates this.
"But for large,
single-
source multicast groups, it is generally undesirable to distribute key
management functions among group members"

Please support this with evidence.  Also, wouldn't it be best to just discuss the requirements and design constraints but not suggest solutions here?


DirecTV is a good example. TV conditional access systems don't allow STBs to become group controllers.  The need to support large numbers of receivers, or to quickly remove members, or to have very short latency in joining or re-keying a group are the requirements and design constraints.  We have commercial systems that optimize for a subset of these constraints and some of the others listed in Section 2.
 

I don't think that this is a general example.  If this were for the internet, what is wrong with saying address a.b.c.d or a.b.c.e or a.b.c.f can serve you?  (Any key server that "sees" unencrypted keys is by default a member.)
 
8.
 
  
This design is based upon a "group controller" model 
[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group 
owner as the root-of-trust.  The group owner designates a key 
distribution center for member registration and
re-key.
As was originally envisioned, the group owner CAN (and for large or sparse groups SHOULD) designate multiple key servers.

The architecture recommends that this be done by allowing any key server to serve keys that is authorized to do so by the group owner.  The most straightforward way to do this is to use SPKI or X.509 delegation.  That's what we are recommending rather than coding this up in the key management protocol.

It is fair to say that the key server must provide proof of delegation.  I _believe_ SPKI (SDSI) delegation is not widely used, but cannot support this.  X. 509 attributes is a fair way of doing this, but is only one way.  Whether it is more straightforward is a matter of opinion.


Please tell me why SPKI delegation will not do this.  I believe it can.  If we need to fix something in the trust infrastructure, I would not build the solution into the key management protocol but fix the trust infrastructure.  Otherwise the key management protocol will end up having all sorts of strange and inappropriate features that make it difficult to implement and impossible to test.
 

My typo again.  SPKI delegation is not widely used but can support this.  The X.509 is available.  It is a mechanism that provides some proof of authorization.  For example in GSAKMP, it can be one of the certificates passed with the INVITATION message with the token containing the rule for key server of "attribute certificate signed by root x".  Or alternatively, not using attribute certificates, it can just be a key server rule that says it must have an "identity cert signed by root y where the identity conforms to the rule name = a.b.c.?".  I don't think that this is a strange and inappropriate feature. 
The KDC, moreover, can be delegated when the 
trust infrastructure supports delegation to permit distributed 
operation of the
KDC.
This statement, while correct, seems to conflict with the statement quoted in Comment #6.

Comment #6 was citing a requirements discussion.  now we are into design.  There are ways to load balance, get high-availability, and get fault tolerance for a server without inventing distributed key server protocols (such as a leader election algorithm, inter-KDC protocols).
 

Okay.  The design is inconsistent with the requirement?
Load sharing is certainly different than delegation -- I am not sure what your point is.


Section 2, requirements, referred to a general taxonomy or framework and past work such as RFC2627 and OFT.  We gathered and summarized the requirements in section 2.  The design is to be measured against the very general requirement and we said, first and foremost, that we must support source-specific multicast.  Developing a "distributed design" where each member could be a controller is not necessary for the basic requirement of source-specific multicast.  But we must support large-scale operation.  There are ways such as load balancing, high-availability, and fault-tolerant methods to do that but we still do not have a distributed key server in my opinion but a load-balanced or highly-available or fault-tolerant centralized server.  On the other hand, there is delegation and this allows other device to source keys on behalf of the key server.  I particularly like the idea of allowing the media server to be delegated to send out keys (SAs) for data-security protocols on behalf of the key server.  But we still do not have a distributed key server in that not all members need to have the capability to be key servers.  Section 5 of the I-D also notes that the fly-in-the-ointment might be the need to develop an inter-KDC protocol to make this work.  I don't think it is necessary, but we need to look closely at this assumption.
 

I don't think distributed means all members need to have the capability to be key servers.

"Developing a "distributed design" where each member could be a controller is not necessary for the basic requirement of source-specific multicast. " is not the same as "it is generally undesirable to distribute key management functions among group members".

Don't make distributed key management functions a requirement, but certainly do not preclude it or discourage it.

 
 
12.
 
  
MSEC assumes that at least the following group-policy information
is
externally managed.
  o Group owner, authentication method, and delegation method for 
    identifying a KDC for the group
  o Group KDC, authentication method, and any method used for
    delegating other KDCs for the group
  o Group membership rules or list and authentication
method
These assumptions are unnecessary as was shown by GSAKMP.

These assumptions were put into the GDOI draft at Hugh's behest and it helped clarify our thinking on how to minimize group policy functions in key management.   I recommended to Ran and Lakshminath that we consider including these assumptions in the GKM architecture I-D.  They agreed and Lakshminath did that.  If we don't do that, then we will encumber the key management specification with a lot of policy issues that the working group has agreed belonged in a policy draft.  You may not agree with everything the WG decides to do.  WGs are like that.

Oh are you the working group?


There you go again.  We hold meetings and post minutes.  Please refer to them.
 

Believe me I do.

Separating policy specifics into a separate draft is very different from saying that the list of policy elements above is assumed to be managed externally from the key management protocol.  Distribution is a part of management.  Policy elements MAY be managed externally.  Please stop twisting the issues.

We're not shooting for novelty here.  Quite the contrary.  The I-D is to progress as a product of the msec WG in order to bring two or more key management protocols to address common requirements, use common abstractions, and messages.  These two or more protocols cannot interoperate unless they at least use a common header.  GDOI uses an ISAKMP header for obvious reasons.  GSAKMP does not use an ISAKMP header. If they could interoperate, then we would not go to the trouble of specifying two or more key management protocols.
The requirements need to drive the protocol selection not the other way around.
Common abstractions are good, common messages imply a common protocol.


Not if you want GSAKMP to use a non-standard header.  We can specify common messages for the Re-key protocol up to the header.  At that point GSAKMP and GDOI part ways.

You missed my point.  Different protocols use different messages.

I think Ran's message was pretty clear about the requirements and abstractions.  Why would the messages be the same?

--- Andrea

 

Mark
 
 

--- Andrea
--------------D097C38E72E04603FDF62745-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jun 28 20:44:16 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08376 for ; Thu, 28 Jun 2001 20:44:15 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id DF93953638; Thu, 28 Jun 2001 20:44: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 33F1B53638 for ; Thu, 28 Jun 2001 20:42:35 -0400 (EDT) Received: (qmail 87175 invoked by uid 3269); 29 Jun 2001 00:42:34 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 87169 invoked from network); 29 Jun 2001 00:42:34 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 29 Jun 2001 00:42:34 -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 f5T0gAx29246; Thu, 28 Jun 2001 17:42:10 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-308.cisco.com [10.21.65.52]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADH00955; Thu, 28 Jun 2001 17:41:58 -0700 (PDT) Message-Id: <4.3.2.7.2.20010628173845.041273e0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Andrea Colegrove From: Mark Baugher Subject: Re: [MSEC] Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt Cc: msec@securemulticast.org In-Reply-To: <3B3BB2F4.7CE260F6@columbia.sparta.com> References: <200106271103.HAA26170@ietf.org> <4.3.2.7.2.20010627202552.0433d4c8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010628141335.042f1da0@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_40041146==_.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, 28 Jun 2001 17:41:27 -0700 --=====================_40041146==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 06:43 PM 6/28/2001 -0400, Andrea Colegrove wrote: >Mark, >>>> >>>> A "group key management protocol" ensures that >>>> only >>>> members of a secure group gain access to group data >>>>(by gaining access >>>> to group keys) and can authenticate group >>>> >>>>data. >>>> >>>>I'm looking forward to the I-D on security management protocols and >>>>prefer to stick to key management protocols in this >>>>I-D >>>The statement above is incorrect however. It is only though key >>>management in conjuction with security association management, access >>>control, and authorization (i.e., security management) that ensures this >>>property. (KM is probably necessary but not sufficient, etc, etc.) >> >> >>Like I said, you are invoking something that is not defined in the msec >>context: Please write an I-D on security management or security >>association management so we have something to discuss here. Writing >>"etc, etc" isn't much help, either. > >How about >"A group key management protocol helps to ensure that only members of a >secure group >gain access to group data (by gaining access to group keys) and can >authenticate >group data." Fine. I'm okay making this change to the next version of the draft. >What you have currently is wrong. Key management is a necessary but not >sufficient >service. Is this clearer? I've developed product for this market and I disagree that what we said is wrong, but it's not worth debating. I'll address the rest of this note later tonight or tomorrow. Mark >> >> >>>>>> >>>>>>4. >>>>>>The key-management protocol must be secure against man-in-the- >>>>>> middle, connection-hijacking, and reflection/replay >>>>>>attacks; >>>>>>it must >>>>>> use best-known practices to thwart denial-of-service >>>>>>attacks. >>>>>And type attacks. And attacks resulting from lack of explicitness >>>>>(mis-routed, mis-interpreted). And interleaved with other protocols >>>>>(protocol-oracle), etc. Perhaps it would be better to generalize this >>>>>statement. >>>> >>>>Would you please provide references for these attacks? >>>Sure. For starters check Clark and Jacob's "Security Protocols: An >>>Annotated Bibliography", Abadi and Needham's"Prudent Engineering >>>Practice for Cryptographic Protocol", Ulf Carlsen's "Cryptographic >>>Protocol Flaws." Ross Anderson also has a good paper that applies to >>>public key protocols and Schneier (and Wagner?) have one on >>>multiprotocol attacks. >>> >>>My point was only that it might be better to generalize than to list. >> >> >>thanks. I took this from the IKE, ISAKMP, Photuris, and STS papers as >>being the basic protections needed for key management and each are >>generalized types of attacks, like man-in-the-middle since there are a >>number of things that a man-in-the-middle might do. >> >> >I understand -- there are others that cannot be generalized quite as well, >such as protocol-oracle which is not really a man-in-the-middle and not >really a replay since it is used in another protocol. We just don't want >one to slip through the requirements cracks. How about "The key >management protocols must be secure against protocol attacks against the >provided security services and must use best ..." > >> >>>>>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." >>>> >>>>Not in IKE it isn't. Again, I await the I-D on the security management >>>>protocol. >>>IKE says: >>>A security association (SA) is a set of policy and key(s) used to >>>protect information. The ISAKMP >>> SA is the shared policy and key(s) used by the negotiating peers in >>> this protocol to protect their >>> communication. >> >> >>That's right and the policy is carried in the SA payload. >> >so? >> >> >>>Access control and delegation are two of the assumptions that pairwise >>>communication does not need to consider: You know who you are going to >>>talk to (your peer), you will only communicate if both your policies >>>(SPDs) allow it, and you figure that they are authorized to negotiate on >>>behalf of themselves. >> >> >>What's the point? >> >> >>>There is a lot of policy involved in IKE. The rest of the security >>>association is certainly not just meta-data describing the keys. > > >The point is "There is a lot of policy involved in IKE. The rest of the >security association is certainly not just meta-data describing the keys. " >>> >>>>>5. Re: video on demand example. The example shows a pre-existing >>>>>group of all possible members subject to pre-broadcast rekey. One >>>>>broadcast would destroy this property. >>>> >>>>What is the property that would be destroyed? What exactly is the >>>>problem? >>>> >>>The example wasn't clear to me but it appeared that you were stating >>>that the potential audience was a group and requirement 6 (rekey) >>>supported the access control to video broadcasts. If this is what you >>>meant, then each time some of the members were excluded from a >>>broadcast, a smaller potential audience resulted for the next one. >> >> >>I don't understand. >I am trying to restate what I think you said and you don't >understand. Could you restate the example so that we can determine >whether there is a limitation or not? Thanks. >> >>>> >>>>>6. >>>>>> >>>>>> >>>>>>A centralized >>>>>>group controller (or KDC) that is used in this architecture may not be >>>>>>the best design for small, interactive groups. But for large, >>>>>>single- >>>>>>source multicast groups, it is generally undesirable to distribute key >>>>>>management functions among group members: Unlike small, interactive >>>>>>groups, large single-source multicast groups generally need a >>>>>>specialized KDC to support large numbers of group members. Large >>>>>>distributed simulations, moreover, may combine the need for large-grou >>>>>>operation with many >>>>>>senders. >>>>>Large groups require distributed initial key distribution! Large >>>>>dynamic groups cannot rely upon a centralized KDC. This does not >>>>>scale. This is highly inflexible. The VoD example demonstrates this. >>>"But for large, >>>single- >>>source multicast groups, it is generally undesirable to distribute key >>>management functions among group members" >>> >>>Please support this with evidence. Also, wouldn't it be best to just >>>discuss the requirements and design constraints but not suggest solutions here? >> >> >>DirecTV is a good example. TV conditional access systems don't allow STBs >>to become group controllers. The need to support large numbers of >>receivers, or to quickly remove members, or to have very short latency in >>joining or re-keying a group are the requirements and design >>constraints. We have commercial systems that optimize for a subset of >>these constraints and some of the others listed in Section 2. >> >I don't think that this is a general example. If this were for the >internet, what is wrong with saying address a.b.c.d or a.b.c.e or a.b.c.f >can serve you? (Any key server that "sees" unencrypted keys is by default >a member.) >> >>>>>8. >>>>>> >>>>>> >>>>>>This design is based upon a "group controller" model >>>>>>[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group >>>>>>owner as the root-of-trust. The group owner designates a key >>>>>>distribution center for member registration and >>>>>>re-key. >>>>>As was originally envisioned, the group owner CAN (and for large or >>>>>sparse groups SHOULD) designate multiple key servers. >>>> >>>>The architecture recommends that this be done by allowing any key >>>>server to serve keys that is authorized to do so by the group >>>>owner. The most straightforward way to do this is to use SPKI or X.509 >>>>delegation. That's what we are recommending rather than coding this up >>>>in the key management protocol. >>>It is fair to say that the key server must provide proof of >>>delegation. I _believe_ SPKI (SDSI) delegation is not widely used, but >>>cannot support this. X. 509 attributes is a fair way of doing this, but >>>is only one way. Whether it is more straightforward is a matter of opinion. >> >> >>Please tell me why SPKI delegation will not do this. I believe it >>can. If we need to fix something in the trust infrastructure, I would >>not build the solution into the key management protocol but fix the trust >>infrastructure. Otherwise the key management protocol will end up having >>all sorts of strange and inappropriate features that make it difficult to >>implement and impossible to test. >> >My typo again. SPKI delegation is not widely used but can support >this. The X.509 is available. It is a mechanism that provides some proof >of authorization. For example in GSAKMP, it can be one of the >certificates passed with the INVITATION message with the token containing >the rule for key server of "attribute certificate signed by root x". Or >alternatively, not using attribute certificates, it can just be a key >server rule that says it must have an "identity cert signed by root y >where the identity conforms to the rule name = a.b.c.?". I don't think >that this is a strange and inappropriate feature. >>>>>> >>>>>>The KDC, moreover, can be delegated when the >>>>>>trust infrastructure supports delegation to permit distributed >>>>>>operation of the >>>>>>KDC. >>>>>This statement, while correct, seems to conflict with the statement >>>>>quoted in Comment #6. >>>> >>>>Comment #6 was citing a requirements discussion. now we are into >>>>design. There are ways to load balance, get high-availability, and get >>>>fault tolerance for a server without inventing distributed key server >>>>protocols (such as a leader election algorithm, inter-KDC protocols). >>>> >>>Okay. The design is inconsistent with the requirement? >>>Load sharing is certainly different than delegation -- I am not sure >>>what your point is. >> >> >>Section 2, requirements, referred to a general taxonomy or framework and >>past work such as RFC2627 and OFT. We gathered and summarized the >>requirements in section 2. The design is to be measured against the very >>general requirement and we said, first and foremost, that we must support >>source-specific multicast. Developing a "distributed design" where each >>member could be a controller is not necessary for the basic requirement >>of source-specific multicast. But we must support large-scale >>operation. There are ways such as load balancing, high-availability, and >>fault-tolerant methods to do that but we still do not have a distributed >>key server in my opinion but a load-balanced or highly-available or >>fault-tolerant centralized server. On the other hand, there is >>delegation and this allows other device to source keys on behalf of the >>key server. I particularly like the idea of allowing the media server to >>be delegated to send out keys (SAs) for data-security protocols on behalf >>of the key server. But we still do not have a distributed key server in >>that not all members need to have the capability to be key >>servers. Section 5 of the I-D also notes that the fly-in-the-ointment >>might be the need to develop an inter-KDC protocol to make this work. I >>don't think it is necessary, but we need to look closely at this assumption. >> >I don't think distributed means all members need to have the capability to >be key servers. > >"Developing a "distributed design" where each member could be a controller >is not necessary for the basic requirement of source-specific multicast. " >is not the same as "it is generally undesirable to distribute key >management functions among group members". > >Don't make distributed key management functions a requirement, but >certainly do not preclude it or discourage it. >> >>>> >>>>>12. >>>>>> >>>>>> >>>>>>MSEC assumes that at least the following group-policy information >>>>>>is >>>>>>externally managed. >>>>>> o Group owner, authentication method, and delegation method for >>>>>> identifying a KDC for the group >>>>>> o Group KDC, authentication method, and any method used for >>>>>> delegating other KDCs for the group >>>>>> o Group membership rules or list and authentication >>>>>>method >>>>>These assumptions are unnecessary as was shown by GSAKMP. >>>> >>>>These assumptions were put into the GDOI draft at Hugh's behest and it >>>>helped clarify our thinking on how to minimize group policy functions >>>>in key management. I recommended to Ran and Lakshminath that we >>>>consider including these assumptions in the GKM architecture I-D. They >>>>agreed and Lakshminath did that. If we don't do that, then we will >>>>encumber the key management specification with a lot of policy issues >>>>that the working group has agreed belonged in a policy draft. You may >>>>not agree with everything the WG decides to do. WGs are like that. >>>Oh are you the working group? >> >> >>There you go again. We hold meetings and post minutes. Please refer to >>them. >> >Believe me I do. > >Separating policy specifics into a separate draft is very different from >saying that the list of policy elements above is assumed to be managed >externally from the key management protocol. Distribution is a part of >management. Policy elements MAY be managed externally. Please stop >twisting the issues. >>>>We're not shooting for novelty here. Quite the contrary. The I-D is >>>>to progress as a product of the msec WG in order to bring two or more >>>>key management protocols to address common requirements, use common >>>>abstractions, and messages. These two or more protocols cannot >>>>interoperate unless they at least use a common header. GDOI uses an >>>>ISAKMP header for obvious reasons. GSAKMP does not use an ISAKMP >>>>header. If they could interoperate, then we would not go to the trouble >>>>of specifying two or more key management protocols. >>>The requirements need to drive the protocol selection not the other way >>>around. >>>Common abstractions are good, common messages imply a common protocol. >> >> >>Not if you want GSAKMP to use a non-standard header. We can specify >>common messages for the Re-key protocol up to the header. At that point >>GSAKMP and GDOI part ways. >You missed my point. Different protocols use different messages. > >I think Ran's message was pretty clear about the requirements and >abstractions. Why would the messages be the same? > >--- Andrea >> >> >>Mark >> >> >>>--- Andrea --=====================_40041146==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 06:43 PM 6/28/2001 -0400, Andrea Colegrove wrote:
Mark,
  
 A "group key management protocol" ensures that
    only=20
    members of a secure group gain access to group data
(by gaining access=20
    to group keys) and can authenticate group
  =20
data.
 
  
I'm looking forward to the I-D on security management protocols=20
and
prefer to stick to key management protocols in this
I-D
The statement above is incorrect however.  It is only though key management in conjuction with security association management, access control, and authorization (i.e., security management) that ensures this property.  (KM is probably necessary but not sufficient, etc, etc.)


Like I said, you are invoking something that is not defined in the msec context:  Please write an I-D on security management or security association management so we have something to discuss here.  Writing "etc, etc" isn't much help, either.

How about

"A group key management protocol helps to ensure that only
members of a secure
group

gain access to group data (by gaining access to group keys) and can
authenticate

group data."

Fine.  I'm okay making this change to the next version of the draft.


What you have currently is wrong. 
Key management is a necessary but not
sufficient

service.  Is this clearer?

I've developed product for this market and I disagree that what we said is wrong, but it's not worth debating.

I'll address the rest of this note later tonight or tomorrow.

Mark

 
  

4.
The key-management protocol must be secure against man-in-the-
   middle, connection-hijacking, and reflection/replay
attacks;
it must
   use best-known practices to thwart denial-of-service
attacks.
And type attacks.  And attacks resulting from lack of explicitness (mis-routed, mis-interpreted).  And interleaved with other protocols (protocol-oracle), etc.  Perhaps it would be better to generalize this statement.

Would you please provide references for these attacks?
Sure.  For starters check Clark and Jacob's "Security Protocols:  An Annotated Bibliography", Abadi and Needham's"Prudent Engineering Practice for Cryptographic Protocol", Ulf Carlsen's "Cryptographic Protocol Flaws."  Ross Anderson also has a good paper that applies to public key protocols and Schneier (and Wagner?) have one on multiprotocol attacks.

My point was only that it might be better to generalize than to list.


thanks.  I took this from the IKE, ISAKMP, Photuris, and STS papers as being the basic protections needed for key management and each are generalized types of attacks, like man-in-the-middle since there are a number of things that a man-in-the-middle might do.
 
 
I understand -- there are others that cannot be generalized quite as well, such as protocol-oracle which is not really a man-in-the-middle and not really a replay since it is used in another protocol.  We just don't want one to slip through the requirements cracks.  How about "The key management protocols must be secure against protocol attacks against the provided security services and must use best ..."
 
 
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."

Not in IKE it isn't.  Again, I await the I-D on the security management protocol.
IKE says:
A security association (SA) is a set of policy and key(s) used to protect information. The ISAKMP
    SA is the shared policy and key(s) used by the negotiating peers in this protocol to protect their
    communication.


That's right and the policy is carried in the SA payload.
 so?
 
 
Access control and delegation are two of the assumptions that pairwise communication does not need to consider:  You know who you are going to talk to (your peer), you will only communicate if both your policies (SPDs) allow it, and you figure that they are authorized to negotiate on behalf of themselves.


What's the point?
 
 
There is a lot of policy involved in IKE.  The rest of the security association is certainly not just meta-data describing the keys.


The point is "There is a lot of policy involved in IKE.  The rest of the security association is certainly not just meta-data describing the keys. "
 
5.  Re:  video on demand example.   The example shows a pre-existing group of all possible members subject to pre-broadcast rekey.  One broadcast would destroy this property.

What is the property that would be destroyed?  What exactly is the problem?
 
The example wasn't clear to me but it appeared that you were stating that the potential audience was a group and requirement 6 (rekey) supported the access control to video broadcasts.  If this is what you meant, then each time some of the members were excluded from a broadcast, a smaller potential audience resulted for the next one.


I don't understand.
I am trying to restate what I think you said and you don't understand.  Could you restate the example so that we can determine whether there is a limitation or not?  Thanks.
 
 
6.
 
  
A centralized
group controller (or KDC) that is used in this architecture may not be=20
the best design for small, interactive groups.  But for large,
single-
source multicast groups, it is generally undesirable to distribute key=20
management functions among group members: Unlike small, interactive=20
groups, large single-source multicast groups generally need a=20
specialized KDC to support large numbers of group members.  Large=20
distributed simulations, moreover, may combine the need for large-grou=20
operation with many
senders.
Large groups require distributed initial key distribution!  Large dynamic groups cannot rely upon a centralized KDC.  This does not scale.  This is highly inflexible.  The VoD example demonstrates this.
"But for large,
single-
source multicast groups, it is generally undesirable to distribute key
management functions among group members"

Please support this with evidence.  Also, wouldn't it be best to just discuss the requirements and design constraints but not suggest solutions here?


DirecTV is a good example. TV conditional access systems don't allow STBs to become group controllers.  The need to support large numbers of receivers, or to quickly remove members, or to have very short latency in joining or re-keying a group are the requirements and design constraints.  We have commercial systems that optimize for a subset of these constraints and some of the others listed in Section 2.
 
I don't think that this is a general example.  If this were for the internet, what is wrong with saying address a.b.c.d or a.b.c.e or a.b.c.f can serve you?  (Any key server that "sees" unencrypted keys is by default a member.)
 
8.
 
  
This design is based upon a "group controller" model=20
[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group=20
owner as the root-of-trust.  The group owner designates a key=20
distribution center for member registration and
re-key.
As was originally envisioned, the group owner CAN (and for large or sparse groups SHOULD) designate multiple key servers.

The architecture recommends that this be done by allowing any key server to serve keys that is authorized to do so by the group owner.  The most straightforward way to do this is to use SPKI or X.509 delegation.  That's what we are recommending rather than coding this up in the key management protocol.
It is fair to say that the key server must provide proof of delegation.  I _believe_ SPKI (SDSI) delegation is not widely used, but cannot support this.  X. 509 attributes is a fair way of doing this, but is only one way.  Whether it is more straightforward is a matter of opinion.


Please tell me why SPKI delegation will not do this.  I believe it can.  If we need to fix something in the trust infrastructure, I would not build the solution into the key management protocol but fix the trust infrastructure.  Otherwise the key management protocol will end up having all sorts of strange and inappropriate features that make it difficult to implement and impossible to test.
 My typo again.  SPKI delegation is not widely used but can support this.  The X.509 is available.  It is a mechanism that provides some proof of authorization.  For example in GSAKMP, it can be one of the certificates passed with the INVITATION message with the token containing the rule for key server of "attribute certificate signed by root x".  Or alternatively, not using attribute certificates, it can just be a key server rule that says it must have an "identity cert signed by root y where the identity conforms to the rule name =3D a.b.c.?".  I don't think that this is a strange and inappropriate feature. 

The KDC, moreover, can be delegated when the=20
trust infrastructure supports delegation to permit distributed=20
operation of the
KDC.
This statement, while correct, seems to conflict with the statement quoted in Comment #6.

Comment #6 was citing a requirements discussion.  now we are into design.  There are ways to load balance, get high-availability, and get fault tolerance for a server without inventing distributed key server protocols (such as a leader election algorithm, inter-KDC protocols).
 
Okay.  The design is inconsistent with the requirement?
Load sharing is certainly different than delegation -- I am not sure what your point is.


Section 2, requirements, referred to a general taxonomy or framework and past work such as RFC2627 and OFT.  We gathered and summarized the requirements in section 2.  The design is to be measured against the very general requirement and we said, first and foremost, that we must support source-specific multicast.  Developing a "distributed design" where each member could be a controller is not necessary for the basic requirement of source-specific multicast.  But we must support large-scale operation.  There are ways such as load balancing, high-availability, and fault-tolerant methods to do that but we still do not have a distributed key server in my opinion but a load-balanced or highly-available or fault-tolerant centralized server.  On the other hand, there is delegation and this allows other device to source keys on behalf of the key server.  I particularly like the idea of allowing the media server to be delegated to send out keys (SAs) for data-security protocols on behalf of the key server.  But we still do not have a distributed key server in that not all members need to have the capability to be key servers.  Section 5 of the I-D also notes that the fly-in-the-ointment might be the need to develop an inter-KDC protocol to make this work.  I don't think it is necessary, but we need to look closely at this assumption.
 I don't think distributed means all members need to have the capability to be key servers.

"Developing a "distributed design" where each member could be a controller is not necessary for the basic requirement of source-specific multicast. " is not the same as "it is generally undesirable to distribute key management functions among group members".

Don't make distributed key management functions a requirement, but certainly do not preclude it or discourage it.
 
 
12.
 
  
MSEC assumes that at least the following group-policy information
is
externally managed.
  o Group owner, authentication method, and delegation method for=20
    identifying a KDC for the group
  o Group KDC, authentication method, and any method used for
    delegating other KDCs for the group
  o Group membership rules or list and authentication
method
These assumptions are unnecessary as was shown by GSAKMP.

These assumptions were put into the GDOI draft at Hugh's behest and it helped clarify our thinking on how to minimize group policy functions in key management.   I recommended to Ran and Lakshminath that we consider including these assumptions in the GKM architecture I-D.  They agreed and Lakshminath did that.  If we don't do that, then we will encumber the key management specification with a lot of policy issues that the working group has agreed belonged in a policy draft.  You may not agree with everything the WG decides to do.  WGs are like that.
Oh are you the working group?


There you go again.  We hold meetings and post minutes.  Please refer to them.
 
Believe me I do.

Separating policy specifics into a separate draft is very different from saying that the list of policy elements above is assumed to be managed externally from the key management protocol.  Distribution is a part of management.  Policy elements MAY be managed externally.  Please stop twisting the issues.
We're not shooting for novelty here.  Quite the contrary.  The I-D is to progress as a product of the msec WG in order to bring two or more key management protocols to address common requirements, use common abstractions, and messages.  These two or more protocols cannot interoperate unless they at least use a common header.  GDOI uses an ISAKMP header for obvious reasons.  GSAKMP does not use an ISAKMP header. If they could interoperate, then we would not go to the trouble of specifying two or more key management protocols.
The requirements need to drive the protocol selection not the other way around.
Common abstractions are good, common messages imply a common protocol.


Not if you want GSAKMP to use a non-standard header.  We can specify common messages for the Re-key protocol up to the header.  At that point GSAKMP and GDOI part ways.You missed my point.  Different protocols use different messages.

I think Ran's message was pretty clear about the requirements and abstractions.  Why would the messages be the same?

--- Andrea
 

Mark
 
 
--- Andrea
--=====================_40041146==_.ALT-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 29 08:48:34 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07827 for ; Fri, 29 Jun 2001 08:48:34 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 917FF5372B; Fri, 29 Jun 2001 08:48: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 F37BE536C6 for ; Fri, 29 Jun 2001 08:46:24 -0400 (EDT) Received: (qmail 49245 invoked by uid 3269); 29 Jun 2001 12:46:24 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 49242 invoked from network); 29 Jun 2001 12:46:24 -0000 Received: from chmls05.mediaone.net (24.147.1.143) by klesh.pair.com with SMTP; 29 Jun 2001 12:46:24 -0000 Received: from THARDJONO-LAP.mediaone.net ([63.90.80.227]) by chmls05.mediaone.net (8.11.1/8.11.1) with ESMTP id f5TCkMx28737; Fri, 29 Jun 2001 08:46:22 -0400 (EDT) Message-Id: <5.0.0.25.2.20010629084249.018802c0@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: <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: Fri, 29 Jun 2001 08:46:15 -0400 Ran, Here are some comments on the notion of de-registration in the context of the key management work in MSEC. Please do read them (and possibly respond). At 6/28/2001||03:48 PM, you 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. Most of the applications I have come across want to make use of single-source multicast to deliver content in a Pay-Per-View model where the unit of content or time is pre-programmed in advance by the content provider. Thus, in this common model, the content provider leaves it up to the user/customer to decide the unit of content to buy and to purchase additional units when needed. Thus the burden is on the user. Citing the CableTV example, from a revenue perspective the content provider would like the user to pay for an entire unit of content (eg. whole movie) even when the user does not consume all of it. We've all had the experience buying a lousy movie in a hotel :) >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). The example you quote seems contradictory. If a user is unsure about the number of rounds he needs to watch (to complete the entire match), the he/she can buy the programme one-round-at-a-time. If the user fails to pay for the next round of programme, then the user is left out. It matters little (to the system) if the user says good-by before the completion of the match or of the paid unit. If anything, it is the other way around: the system reminds the user that the user only has X minutes left before the unit of content is over, and for the user to pay some more. >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.) Again, this depends on the application model (ie. system-initiated or user-initiated membership-termination). I don't think it is a mistake to leave it to the application. In fact, it makes more sense to let the application-area decide which model to follow (system-initiated or user-initiated). In the specific case of MSEC key management, requiring the member to specifically de-register has the following implications: - How is the member going to de-register (ie. what mechanisms): If the member has to send a de-register message through the Cat-1 SA, then that Cat-1 SA has to be around as long as the member is registered. Now, this is an unresolved issue: Do we keep a Cat-1 SA around just so that the member can send one message (de-register) to the GCKS? This causes a lot of state to have to be maintained at the GCKS. Do we let the initial Cat-1 SA die, and establish a new Cat-1 SA just for the member to send one message (de-register)? This is a lot of negotiations and cycles just for one message. - Authentication of de-register message: Clearly this de-register message has to be source-authentic, otherwise any member can de-register other members. This points to the need of the members to have certificates (which they do anyway, in order to register in the first place, both in GSAKMP and GDOI). Since we assume that the Application triggered the initial Register message (digitally signed), then it make it makes sense to let the Application decide (and send) the final de-register message (with a digital signature). - Reliability: In SMuG and MSEC we all concluded that reliability of key management messages should not have to be dealt by the key-management-protocol. Now, if you insist that the de-register message must be part of the key management protocol, then you also must provide it with reliability. Simply saying that "some layer above" will provide it with reliability is really insufficient (circular argument). However, it makes sense to say that the Application (or a transport-layer mechanism) will provide/assume reliability. Which, again, points to appropriateness of the de-register message at the Application layer. thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 29 09:57:52 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22328 for ; Fri, 29 Jun 2001 09:57:50 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1AC8553694; Fri, 29 Jun 2001 09: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 CC1C753694 for ; Fri, 29 Jun 2001 09:56:27 -0400 (EDT) Received: (qmail 57544 invoked by uid 3269); 29 Jun 2001 13:56:27 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 57541 invoked from network); 29 Jun 2001 13:56:27 -0000 Received: from news.comp.lancs.ac.uk (148.88.152.70) by klesh.pair.com with SMTP; 29 Jun 2001 13:56:27 -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 f5TDuK026625 for ; Fri, 29 Jun 2001 14:56:21 +0100 (BST) From: "Sandro Rafaeli" To: Subject: RE: [MSEC] De-registration protocol? Message-ID: <000001c100a3$35627a00$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: <5.0.0.25.2.20010629084249.018802c0@pop.ne.mediaone.net> 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: Fri, 29 Jun 2001 14:55:50 +0100 Content-Transfer-Encoding: 7bit Hello everyone, I'd like to introduce myself: I am Sandro Rafaeli and I am a 3rd-year PhD student at Lancaster University, UK. My research topic is secure group communication. First of all, I apologise for my intrusion! I agree with Thomas, when he says that a KDC using MARKS does not need to know whether the member, which has paid to watch an event, is really watching it or not. This will not change the key value for a given time slot. In MARKS, membership changes do not force key changes. But, what happens with a KDC using OFT/LKH? If a KDC has at some time 10 thousand *registered* members, and 5 thousand of those members leave, and after that other 5 thousand join the group. If there is no *leave* protocol, it seems to me that the KDC will be holding 15 thousand member nodes... Bottom line: When is the OFT/LKH database cleaned up? As I see the architecture at the client-side, there is an application that requires secure communication and there is the GKM-module that uses a GKM-protocol to get the required keys from the KDC. It seems to me that it is the application that requests to the GKM-module to register with the KDC (the module cannot decide it by itself). The same occurs when the application is being shutdown: it should request to the GKM-module to de-register from the KDC. As Thomas has noted, this raises the issue of how to actually send the authenticated *leave* command to the KDC, since the Cat-1 SA has already been closed... Then, again, what happens if the application is not properly shutdown (it may stall or the machine is turned off). How does the KDC clean up its key database? Sandro. | -----Original Message----- | From: msec-admin@securemulticast.org | [mailto:msec-admin@securemulticast.org]On Behalf Of Thomas Hardjono | Sent: 29 June 2001 13:46 | To: Ran Canetti; msec@securemulticast.org | Subject: Re: [MSEC] De-registration protocol? | | | | | Ran, | | Here are some comments on the notion of de-registration | in the context of the key management work in MSEC. | Please do read them (and possibly respond). | | | At 6/28/2001||03:48 PM, you 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. | | Most of the applications I have come across want to make use | of single-source multicast to deliver content in a Pay-Per-View | model where the unit of content or time is pre-programmed in advance | by the content provider. | | Thus, in this common model, the content provider leaves it up to the | user/customer to decide the unit of content to buy and to purchase | additional units when needed. Thus the burden is on the user. | | Citing the CableTV example, from a revenue perspective the | content provider | would like the user to pay for an entire unit of content | (eg. whole movie) | even when the user does not consume all of it. We've all had the | experience buying a lousy movie in a hotel :) | | | | >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). | | The example you quote seems contradictory. If a user is unsure about | the number of rounds he needs to watch (to complete the | entire match), | the he/she can buy the programme one-round-at-a-time. | | If the user fails to pay for the next round of programme, | then the user | is left out. It matters little (to the system) if the user | says good-by | before the completion of the match or of the paid unit. | | If anything, it is the other way around: the system reminds the user | that the user only has X minutes left before the unit of | content is over, | and for the user to pay some more. | | | | >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.) | | Again, this depends on the application model (ie. system-initiated or | user-initiated membership-termination). | | I don't think it is a mistake to leave it to the application. | In fact, it makes more sense to let the application-area decide which | model to follow (system-initiated or user-initiated). | | In the specific case of MSEC key management, requiring the member | to specifically de-register has the following implications: | | - How is the member going to de-register (ie. what mechanisms): | | If the member has to send a de-register message through | the Cat-1 SA, | then that Cat-1 SA has to be around as long as the | member is registered. | Now, this is an unresolved issue: | | Do we keep a Cat-1 SA around just so that the member can send | one message (de-register) to the GCKS? | This causes a lot of state to have to be maintained at | the GCKS. | | Do we let the initial Cat-1 SA die, and establish a | new Cat-1 SA | just for the member to send one message (de-register)? | This is a lot of negotiations and cycles just for one message. | | | - Authentication of de-register message: | | Clearly this de-register message has to be | source-authentic, otherwise | any member can de-register other members. | | This points to the need of the members to have | certificates (which | they do anyway, in order to register in the first place, both | in GSAKMP and GDOI). | | Since we assume that the Application triggered the | initial Register | message (digitally signed), then it make it makes sense to let | the Application decide (and send) the final de-register | message (with | a digital signature). | | | - Reliability: | | In SMuG and MSEC we all concluded that reliability of | key management | messages should not have to be dealt by the | key-management-protocol. | | Now, if you insist that the de-register message must be part of | the key management protocol, then you also must provide it | with reliability. | | Simply saying that "some layer above" will provide it | with reliability | is really insufficient (circular argument). | | However, it makes sense to say that the Application (or | a transport-layer | mechanism) will provide/assume reliability. Which, again, points | to appropriateness of the de-register message at the | Application layer. | | | thomas | ------ | | | | | _______________________________________________ | msec mailing list | msec@securemulticast.org | http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 29 10:41:54 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20197 for ; Fri, 29 Jun 2001 10:41:53 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4E5C353738; Fri, 29 Jun 2001 10: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 584A7537BB for ; Fri, 29 Jun 2001 10:40:59 -0400 (EDT) Received: (qmail 62036 invoked by uid 3269); 29 Jun 2001 14:40:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 62033 invoked from network); 29 Jun 2001 14:40:58 -0000 Received: from chmls20.mediaone.net (24.147.1.156) by klesh.pair.com with SMTP; 29 Jun 2001 14:40:58 -0000 Received: from THARDJONO-LAP.mediaone.net ([63.90.80.227]) by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id f5TEew615732 for ; Fri, 29 Jun 2001 10:40:58 -0400 (EDT) Message-Id: <5.0.0.25.2.20010629095436.0188ecf0@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: Scalability of key management -- Re: [MSEC] Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt In-Reply-To: <3B3A1837.D95360C0@columbia.sparta.com> References: <200106271103.HAA26170@ietf.org> 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, 29 Jun 2001 10:10:45 -0400 Hi, I'm going to respond to one issue at a time. At 6/27/2001||01:30 PM, Andrea Colegrove wrote: >Mark, etal, >Initial comments on the architecture -- > >6. >> >>A centralized >>group controller (or KDC) that is used in this architecture may not be >>the best design for small, interactive groups. But for large, single- >>source multicast groups, it is generally undesirable to distribute key >>management functions among group members: Unlike small, interactive >>groups, large single-source multicast groups generally need a >>specialized KDC to support large numbers of group members. Large >>distributed simulations, moreover, may combine the need for large-grou >>operation with many senders. >Large groups require distributed initial key distribution! Large dynamic >groups cannot rely upon a centralized KDC. This does not scale. This is >highly inflexible. The VoD example demonstrates this. > >While the interactions with distributed rekey entities is more >complicated, this functionality may be needed in composite multicast >groups of limited scope. The paragraph about the scalability of key management in the arch-document is rather unclear. We definitely need more than one GCKS in order for key management to scale. This is what my earlier draft (draft-ietf-ipsec-gkmframework-03.txt) was about, namely having a two-layer set of GCKSs. The issue is whether a Remote GCKS is : (a) a "permanent" GCKS (ie. a full-time configured key server) that is functionally identical to the "root" GCKS and is *NOT* a group member, or (b) a member that is loaded with a GCKS-functionality, and that can be called-up for duty when scalability/reliability needs arise. Now, (a) is a natural usage of multiple GCKS. The two-tiered architecture of Key Servers (as described in draft-ietf-ipsec-gkmframework-03.txt) follows other 2-tiered services in the Internet. Option (b) is a more dynamic approach, which requires a member to be trusted and have a high-degree of security against attacks. This issue has to be clarified as clearly 1 GCKS is not going to scale, and a member-convertible-to-GCKS is not a attainable today in the vendor market. thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 29 10:45:53 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22578 for ; Fri, 29 Jun 2001 10:45:51 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 75301536F1; Fri, 29 Jun 2001 10:46: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 CE9175365D for ; Fri, 29 Jun 2001 10:45:26 -0400 (EDT) Received: (qmail 62415 invoked by uid 3269); 29 Jun 2001 14:45:26 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 62411 invoked from network); 29 Jun 2001 14:45:26 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by klesh.pair.com with SMTP; 29 Jun 2001 14:45:26 -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 f5TEhBH06428; Fri, 29 Jun 2001 07:43:11 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-649.cisco.com [10.21.66.137]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADH10720; Fri, 29 Jun 2001 07:44:45 -0700 (PDT) Message-Id: <4.3.2.7.2.20010629072014.04183e80@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Andrea Colegrove From: Mark Baugher Subject: Re: [MSEC] Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt Cc: msec@securemulticast.org In-Reply-To: <3B3BB2F4.7CE260F6@columbia.sparta.com> References: <200106271103.HAA26170@ietf.org> <4.3.2.7.2.20010627202552.0433d4c8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010628141335.042f1da0@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_90608107==_.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: Fri, 29 Jun 2001 07:44:11 -0700 --=====================_90608107==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed > > >The point is "There is a lot of policy involved in IKE. The rest of the >security association is certainly not just meta-data describing the keys. " No, I'd say most of the policy in IKE is crypto policy. Now, one of us is going to have to list all the policy in IKE and debate the topic. Or we could just drop it. >>> >>>>>5. Re: video on demand example. The example shows a pre-existing >>>>>group of all possible members subject to pre-broadcast rekey. One >>>>>broadcast would destroy this property. >>>> >>>>What is the property that would be destroyed? What exactly is the >>>>problem? >>>> >>>The example wasn't clear to me but it appeared that you were stating >>>that the potential audience was a group and requirement 6 (rekey) >>>supported the access control to video broadcasts. If this is what you >>>meant, then each time some of the members were excluded from a >>>broadcast, a smaller potential audience resulted for the next one. >> >> >>I don't understand. >I am trying to restate what I think you said and you don't >understand. Could you restate the example so that we can determine >whether there is a limitation or not? Thanks. There is a group that can receive video on demand (VOD) content where each member contacts the VOD server to get a file or stream. It is not a broadcast; it is on demand. The VOD server is authorized to source Re-key messages on behalf of the GCKS. So when the member gets the file or stream data, it can get the key to decipher the file or stream from the VOD server. >> >>>> >>>>>6. >>>>>> >>>>>> >>>>>>A centralized >>>>>>group controller (or KDC) that is used in this architecture may not be >>>>>>the best design for small, interactive groups. But for large, >>>>>>single- >>>>>>source multicast groups, it is generally undesirable to distribute key >>>>>>management functions among group members: Unlike small, interactive >>>>>>groups, large single-source multicast groups generally need a >>>>>>specialized KDC to support large numbers of group members. Large >>>>>>distributed simulations, moreover, may combine the need for large-grou >>>>>>operation with many >>>>>>senders. >>>>>Large groups require distributed initial key distribution! Large >>>>>dynamic groups cannot rely upon a centralized KDC. This does not >>>>>scale. This is highly inflexible. The VoD example demonstrates this. >>>"But for large, >>>single- >>>source multicast groups, it is generally undesirable to distribute key >>>management functions among group members" >>> >>>Please support this with evidence. Also, wouldn't it be best to just >>>discuss the requirements and design constraints but not suggest solutions here? >> >> >>DirecTV is a good example. TV conditional access systems don't allow STBs >>to become group controllers. The need to support large numbers of >>receivers, or to quickly remove members, or to have very short latency in >>joining or re-keying a group are the requirements and design >>constraints. We have commercial systems that optimize for a subset of >>these constraints and some of the others listed in Section 2. >> >I don't think that this is a general example. If this were for the >internet, what is wrong with saying address a.b.c.d or a.b.c.e or a.b.c.f >can serve you? (Any key server that "sees" unencrypted keys is by default >a member.) I'm sorry you don't like my example. >> >>>>>8. >>>>>> >>>>>> >>>>>>This design is based upon a "group controller" model >>>>>>[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group >>>>>>owner as the root-of-trust. The group owner designates a key >>>>>>distribution center for member registration and >>>>>>re-key. >>>>>As was originally envisioned, the group owner CAN (and for large or >>>>>sparse groups SHOULD) designate multiple key servers. >>>> >>>>The architecture recommends that this be done by allowing any key >>>>server to serve keys that is authorized to do so by the group >>>>owner. The most straightforward way to do this is to use SPKI or X.509 >>>>delegation. That's what we are recommending rather than coding this up >>>>in the key management protocol. >>>It is fair to say that the key server must provide proof of >>>delegation. I _believe_ SPKI (SDSI) delegation is not widely used, but >>>cannot support this. X. 509 attributes is a fair way of doing this, but >>>is only one way. Whether it is more straightforward is a matter of opinion. >> >> >>Please tell me why SPKI delegation will not do this. I believe it >>can. If we need to fix something in the trust infrastructure, I would >>not build the solution into the key management protocol but fix the trust >>infrastructure. Otherwise the key management protocol will end up having >>all sorts of strange and inappropriate features that make it difficult to >>implement and impossible to test. >> >My typo again. SPKI delegation is not widely used but can support >this. The X.509 is available. It is a mechanism that provides some proof >of authorization. For example in GSAKMP, it can be one of the >certificates passed with the INVITATION message with the token containing >the rule for key server of "attribute certificate signed by root x". Or >alternatively, not using attribute certificates, it can just be a key >server rule that says it must have an "identity cert signed by root y >where the identity conforms to the rule name = a.b.c.?". I don't think >that this is a strange and inappropriate feature. Why put the feature in key management when it is done somewhere else? >>>>>>The KDC, moreover, can be delegated when the >>>>>>trust infrastructure supports delegation to permit distributed >>>>>>operation of the >>>>>>KDC. >>>>>This statement, while correct, seems to conflict with the statement >>>>>quoted in Comment #6. >>>> >>>>Comment #6 was citing a requirements discussion. now we are into >>>>design. There are ways to load balance, get high-availability, and get >>>>fault tolerance for a server without inventing distributed key server >>>>protocols (such as a leader election algorithm, inter-KDC protocols). >>>> >>>Okay. The design is inconsistent with the requirement? >>>Load sharing is certainly different than delegation -- I am not sure >>>what your point is. >> >> >>Section 2, requirements, referred to a general taxonomy or framework and >>past work such as RFC2627 and OFT. We gathered and summarized the >>requirements in section 2. The design is to be measured against the very >>general requirement and we said, first and foremost, that we must support >>source-specific multicast. Developing a "distributed design" where each >>member could be a controller is not necessary for the basic requirement >>of source-specific multicast. But we must support large-scale >>operation. There are ways such as load balancing, high-availability, and >>fault-tolerant methods to do that but we still do not have a distributed >>key server in my opinion but a load-balanced or highly-available or >>fault-tolerant centralized server. On the other hand, there is >>delegation and this allows other device to source keys on behalf of the >>key server. I particularly like the idea of allowing the media server to >>be delegated to send out keys (SAs) for data-security protocols on behalf >>of the key server. But we still do not have a distributed key server in >>that not all members need to have the capability to be key >>servers. Section 5 of the I-D also notes that the fly-in-the-ointment >>might be the need to develop an inter-KDC protocol to make this work. I >>don't think it is necessary, but we need to look closely at this assumption. >> >I don't think distributed means all members need to have the capability to >be key servers. > >"Developing a "distributed design" where each member could be a controller >is not necessary for the basic requirement of source-specific multicast. " >is not the same as "it is generally undesirable to distribute key >management functions among group members". > >Don't make distributed key management functions a requirement, but >certainly do not preclude it or discourage it. I agree. I think we should re-work the parts on centralized and distributed key management in the I-D. >> >>>> >>>>>12. >>>>>> >>>>>> >>>>>>MSEC assumes that at least the following group-policy information >>>>>>is >>>>>>externally managed. >>>>>> o Group owner, authentication method, and delegation method for >>>>>> identifying a KDC for the group >>>>>> o Group KDC, authentication method, and any method used for >>>>>> delegating other KDCs for the group >>>>>> o Group membership rules or list and authentication >>>>>>method >>>>>These assumptions are unnecessary as was shown by GSAKMP. >>>> >>>>These assumptions were put into the GDOI draft at Hugh's behest and it >>>>helped clarify our thinking on how to minimize group policy functions >>>>in key management. I recommended to Ran and Lakshminath that we >>>>consider including these assumptions in the GKM architecture I-D. They >>>>agreed and Lakshminath did that. If we don't do that, then we will >>>>encumber the key management specification with a lot of policy issues >>>>that the working group has agreed belonged in a policy draft. You may >>>>not agree with everything the WG decides to do. WGs are like that. >>>Oh are you the working group? >> >> >>There you go again. We hold meetings and post minutes. Please refer to >>them. >> >Believe me I do. > >Separating policy specifics into a separate draft is very different from >saying that the list of policy elements above is assumed to be managed >externally from the key management protocol. Distribution is a part of >management. Policy elements MAY be managed externally. Please stop >twisting the issues. >>>>We're not shooting for novelty here. Quite the contrary. The I-D is >>>>to progress as a product of the msec WG in order to bring two or more >>>>key management protocols to address common requirements, use common >>>>abstractions, and messages. These two or more protocols cannot >>>>interoperate unless they at least use a common header. GDOI uses an >>>>ISAKMP header for obvious reasons. GSAKMP does not use an ISAKMP >>>>header. If they could interoperate, then we would not go to the trouble >>>>of specifying two or more key management protocols. >>>The requirements need to drive the protocol selection not the other way >>>around. >>>Common abstractions are good, common messages imply a common protocol. >> >> >>Not if you want GSAKMP to use a non-standard header. We can specify >>common messages for the Re-key protocol up to the header. At that point >>GSAKMP and GDOI part ways. >You missed my point. Different protocols use different messages. > >I think Ran's message was pretty clear about the requirements and >abstractions. Why would the messages be the same? I did not say they were the same. Mark >--- Andrea >> >> >>Mark >> >> >>>--- Andrea --=====================_90608107==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


The point is "There is a lot of policy involved in IKE.  The rest of the security association is certainly not just meta-data describing the keys. "
No, I'd say most of the policy in IKE is crypto policy.  Now, one of us is going to have to list all the policy in IKE and debate the topic.  Or we could just drop it.

 
5.  Re:  video on demand example.   The example shows a pre-existing group of all possible members subject to pre-broadcast rekey.  One broadcast would destroy this property.

What is the property that would be destroyed?  What exactly is the problem?
 
The example wasn't clear to me but it appeared that you were stating that the potential audience was a group and requirement 6 (rekey) supported the access control to video broadcasts.  If this is what you meant, then each time some of the members were excluded from a broadcast, a smaller potential audience resulted for the next one.


I don't understand.
I am trying to restate what I think you said and you don't understand.  Could you restate the example so that we can determine whether there is a limitation or not?  Thanks.
There is a group that can receive video on demand (VOD) content where each member contacts the VOD server to get a file or stream.  It is not a broadcast; it is on demand.  The VOD server is authorized to source Re-key messages on behalf of the GCKS.  So when the member gets the file or stream data, it can get the key to decipher the file or stream from the VOD server.

 
 
6.
 
  
A centralized
group controller (or KDC) that is used in this architecture may not be=20
the best design for small, interactive groups.  But for large,
single-
source multicast groups, it is generally undesirable to distribute key=20
management functions among group members: Unlike small, interactive=20
groups, large single-source multicast groups generally need a=20
specialized KDC to support large numbers of group members.  Large=20
distributed simulations, moreover, may combine the need for large-grou=20
operation with many
senders.
Large groups require distributed initial key distribution!  Large dynamic groups cannot rely upon a centralized KDC.  This does not scale.  This is highly inflexible.  The VoD example demonstrates this.
"But for large,
single-
source multicast groups, it is generally undesirable to distribute key
management functions among group members"

Please support this with evidence.  Also, wouldn't it be best to just discuss the requirements and design constraints but not suggest solutions here?


DirecTV is a good example. TV conditional access systems don't allow STBs to become group controllers.  The need to support large numbers of receivers, or to quickly remove members, or to have very short latency in joining or re-keying a group are the requirements and design constraints.  We have commercial systems that optimize for a subset of these constraints and some of the others listed in Section 2.
 
I don't think that this is a general example.  If this were for the internet, what is wrong with saying address a.b.c.d or a.b.c.e or a.b.c.f can serve you?  (Any key server that "sees" unencrypted keys is by default a member.)

I'm sorry you don't like my example.

 
8.
 
  
This design is based upon a "group controller" model=20
[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group=20
owner as the root-of-trust.  The group owner designates a key=20
distribution center for member registration and
re-key.
As was originally envisioned, the group owner CAN (and for large or sparse groups SHOULD) designate multiple key servers.

The architecture recommends that this be done by allowing any key server to serve keys that is authorized to do so by the group owner.  The most straightforward way to do this is to use SPKI or X.509 delegation.  That's what we are recommending rather than coding this up in the key management protocol.
It is fair to say that the key server must provide proof of delegation.  I _believe_ SPKI (SDSI) delegation is not widely used, but cannot support this.  X. 509 attributes is a fair way of doing this, but is only one way.  Whether it is more straightforward is a matter of opinion.


Please tell me why SPKI delegation will not do this.  I believe it can.  If we need to fix something in the trust infrastructure, I would not build the solution into the key management protocol but fix the trust infrastructure.  Otherwise the key management protocol will end up having all sorts of strange and inappropriate features that make it difficult to implement and impossible to test.
 
My typo again.  SPKI delegation is not widely used but can support this.  The X.509 is available.  It is a mechanism that provides some proof of authorization.  For example in GSAKMP, it can be one of the certificates passed with the INVITATION message with the token containing the rule for key server of "attribute certificate signed by root x".  Or alternatively, not using attribute certificates, it can just be a key server rule that says it must have an "identity cert signed by root y where the identity conforms to the rule name =3D a.b.c.?".  I don't think that this is a strange and inappropriate feature.
Why put the feature in key management when it is done somewhere else?


The
KDC, moreover, can be delegated when the=20
trust infrastructure supports delegation to permit distributed=20
operation of the
KDC.
This statement, while correct, seems to conflict with the statement quoted in Comment #6.

Comment #6 was citing a requirements discussion.  now we are into design.  There are ways to load balance, get high-availability, and get fault tolerance for a server without inventing distributed key server protocols (such as a leader election algorithm, inter-KDC protocols).
 
Okay.  The design is inconsistent with the requirement?
Load sharing is certainly different than delegation -- I am not sure what your point is.


Section 2, requirements, referred to a general taxonomy or framework and past work such as RFC2627 and OFT.  We gathered and summarized the requirements in section 2.  The design is to be measured against the very general requirement and we said, first and foremost, that we must support source-specific multicast.  Developing a "distributed design" where each member could be a controller is not necessary for the basic requirement of source-specific multicast.  But we must support large-scale operation.  There are ways such as load balancing, high-availability, and fault-tolerant methods to do that but we still do not have a distributed key server in my opinion but a load-balanced or highly-available or fault-tolerant centralized server.  On the other hand, there is delegation and this allows other device to source keys on behalf of the key server.  I particularly like the idea of allowing the media server to be delegated to send out keys (SAs) for data-security protocols on behalf of the key server.  But we still do not have a distributed key server in that not all members need to have the capability to be key servers.  Section 5 of the I-D also notes that the fly-in-the-ointment might be the need to develop an inter-KDC protocol to make this work.  I don't think it is necessary, but we need to look closely at this assumption.
 
I don't think distributed means all members need to have the capability to be key servers.

"Developing a "distributed design" where each member could be a controller is not necessary for the basic requirement of source-specific multicast. " is not the same as "it is generally undesirable to distribute key management functions among group members".

Don't make distributed key management functions a requirement, but certainly do not preclude it or discourage it.
I agree.  I think we should re-work the parts on centralized and distributed key management in the I-D.

 
 
12.
 
  
MSEC assumes that at least the following group-policy information
is
externally managed.
  o Group owner, authentication method, and delegation method for=20
    identifying a KDC for the group
  o Group KDC, authentication method, and any method used for
    delegating other KDCs for the group
  o Group membership rules or list and authentication
method
These assumptions are unnecessary as was shown by GSAKMP.

These assumptions were put into the GDOI draft at Hugh's behest and it helped clarify our thinking on how to minimize group policy functions in key management.   I recommended to Ran and Lakshminath that we consider including these assumptions in the GKM architecture I-D.  They agreed and Lakshminath did that.  If we don't do that, then we will encumber the key management specification with a lot of policy issues that the working group has agreed belonged in a policy draft.  You may not agree with everything the WG decides to do.  WGs are like that.
Oh are you the working group?


There you go again.  We hold meetings and post minutes.  Please refer to them.
 
Believe me I do.

Separating policy specifics into a separate draft is very different from saying that the list of policy elements above is assumed to be managed externally from the key management protocol.  Distribution is a part of management.  Policy elements MAY be managed externally.  Please stop twisting the issues.
We're not shooting for novelty here.  Quite the contrary.  The I-D is to progress as a product of the msec WG in order to bring two or more key management protocols to address common requirements, use common abstractions, and messages.  These two or more protocols cannot interoperate unless they at least use a common header.  GDOI uses an ISAKMP header for obvious reasons.  GSAKMP does not use an ISAKMP header. If they could interoperate, then we would not go to the trouble of specifying two or more key management protocols.
The requirements need to drive the protocol selection not the other way around.
Common abstractions are good, common messages imply a common protocol.


Not if you want GSAKMP to use a non-standard header.  We can specify common messages for the Re-key protocol up to the header.  At that point GSAKMP and GDOI part ways.
You missed my point.  Different protocols use different messages.

I think Ran's message was pretty clear about the requirements and abstractions.  Why would the messages be the same?
I did not say they were the same.

Mark


--- Andrea
 

Mark
 
 
--- Andrea
--=====================_90608107==_.ALT-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 29 11:12:30 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09257 for ; Fri, 29 Jun 2001 11:12:29 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8FFCF537CB; Fri, 29 Jun 2001 10:56: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 7B915535FA for ; Fri, 29 Jun 2001 10:55:00 -0400 (EDT) Received: (qmail 63194 invoked by uid 3269); 29 Jun 2001 14:54:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 63191 invoked from network); 29 Jun 2001 14:54:59 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by klesh.pair.com with SMTP; 29 Jun 2001 14:54:59 -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 f5TEqYH10734; Fri, 29 Jun 2001 07:52:36 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-649.cisco.com [10.21.66.137]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADH10834; Fri, 29 Jun 2001 07:54:10 -0700 (PDT) Message-Id: <4.3.2.7.2.20010629074740.04283e18@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: Scalability of key management -- Re: [MSEC] Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt Cc: msec@securemulticast.org In-Reply-To: <5.0.0.25.2.20010629095436.0188ecf0@pop.ne.mediaone.net> References: <3B3A1837.D95360C0@columbia.sparta.com> <200106271103.HAA26170@ietf.org> 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, 29 Jun 2001 07:53:41 -0700 Thomas, At 10:10 AM 6/29/2001 -0400, Thomas Hardjono wrote: >Hi, > >I'm going to respond to one issue at a time. > > >At 6/27/2001||01:30 PM, Andrea Colegrove wrote: >>Mark, etal, >>Initial comments on the architecture -- >> >>6. >>> >>>A centralized >>>group controller (or KDC) that is used in this architecture may not be >>>the best design for small, interactive groups. But for large, single- >>>source multicast groups, it is generally undesirable to distribute key >>>management functions among group members: Unlike small, interactive >>>groups, large single-source multicast groups generally need a >>>specialized KDC to support large numbers of group members. Large >>>distributed simulations, moreover, may combine the need for large-grou >>>operation with many senders. >>Large groups require distributed initial key distribution! Large dynamic >>groups cannot rely upon a centralized KDC. This does not scale. This is >>highly inflexible. The VoD example demonstrates this. >> >>While the interactions with distributed rekey entities is more >>complicated, this functionality may be needed in composite multicast >>groups of limited scope. > > >The paragraph about the scalability of key management in the arch-document is >rather unclear. > >We definitely need more than one GCKS in order for key management to scale. >This is what my earlier draft (draft-ietf-ipsec-gkmframework-03.txt) was >about, namely having a two-layer set of GCKSs. > >The issue is whether a Remote GCKS is : > >(a) a "permanent" GCKS (ie. a full-time configured key server) that is > functionally identical to the "root" GCKS and is *NOT* a group member, > >or > >(b) a member that is loaded with a GCKS-functionality, and that can be > called-up for duty when scalability/reliability needs arise. > > >Now, (a) is a natural usage of multiple GCKS. The two-tiered architecture >of Key Servers (as described in draft-ietf-ipsec-gkmframework-03.txt) >follows other 2-tiered services in the Internet. > >Option (b) is a more dynamic approach, which requires a member to be trusted >and have a high-degree of security against attacks. > > >This issue has to be clarified as clearly 1 GCKS is not going to scale, >and a member-convertible-to-GCKS is not a attainable today >in the vendor market. I didn't say that a centralized configuration has only one GCKS. There could be many servers sharing a single address behind a load balancer. The discussion on large-scale operation in the I-D did not equate "centralized" with "one." Mark >thomas >------ > > > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 29 11:23:13 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14645 for ; Fri, 29 Jun 2001 11:23:12 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id E5306537FD; Fri, 29 Jun 2001 11:23:23 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id B10DB53840 for ; Fri, 29 Jun 2001 11:20:03 -0400 (EDT) Received: (qmail 65563 invoked by uid 3269); 29 Jun 2001 15:20:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 65560 invoked from network); 29 Jun 2001 15:20:03 -0000 Received: from softdnserror (HELO M5.sparta.com) (root@157.185.61.1) by klesh.pair.com with SMTP; 29 Jun 2001 15:20:03 -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 f5TFK1x26010; Fri, 29 Jun 2001 10:20:01 -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 LAA04767; Fri, 29 Jun 2001 11:19:59 -0400 (EDT) Message-ID: <3B3C9C8C.79142782@columbia.sparta.com> From: Andrea Colegrove X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt References: <200106271103.HAA26170@ietf.org> <4.3.2.7.2.20010627202552.0433d4c8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010628141335.042f1da0@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010629072014.04183e80@mira-sjc5-6.cisco.com> Content-Type: multipart/alternative; boundary="------------4911CAD7BFF0FC40CF2B1488" 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, 29 Jun 2001 11:19:40 -0400 --------------4911CAD7BFF0FC40CF2B1488 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark, We are not going to agree whether or not crypto policy is meta-data or not. Fine. My reason for pointing out that most of the requirements listed involved more than just key management was to show that you are well on your way to providing a security management internet draft. >> >> >> 5. Re: video on demand example. The example shows a >> >> >> pre-existing group of all possible members subject to >> >> >> pre-broadcast rekey. One broadcast would destroy this >> >> >> property. >> >> > >> >> > >> >> > What is the property that would be destroyed? What exactly is >> >> > the problem? >> >> >> >> The example wasn't clear to me but it appeared that you were >> >> stating that the potential audience was a group and requirement 6 >> >> (rekey) supported the access control to video broadcasts. If >> >> this is what you meant, then each time some of the members were >> >> excluded from a broadcast, a smaller potential audience resulted >> >> for the next one. >> > >> > I don't understand. >> >> I am trying to restate what I think you said and you don't >> understand. Could you restate the example so that we can determine >> whether there is a limitation or not? Thanks. > > > There is a group that can receive video on demand (VOD) content where > each member contacts the VOD server to get a file or stream. It is > not a broadcast; it is on demand. The VOD server is authorized to > source Re-key messages on behalf of the GCKS. So when the member gets > the file or stream data, it can get the key to decipher the file or > stream from the VOD server. > Okay. So far I understand. Could you please fill in the details because I don't see the rekey aspect? The member, before requesting the video is initialized with what? Are all members initialized to the same values? Is the stream encrypted per-member or per-group? > > >> > >> > >> >> > >> >> > >> >> >> 6. >> >> >> >> >> >> > >> >> >> > >> >> >> > >> >> >> > A centralized >> >> >> > group controller (or KDC) that is used in this architecture may not be >> >> >> > the best design for small, interactive groups. But for large, >> >> >> > single- >> >> >> > source multicast groups, it is generally undesirable to distribute key >> >> >> > management functions among group members: Unlike small, interactive >> >> >> > groups, large single-source multicast groups generally need a >> >> >> > specialized KDC to support large numbers of group members. Large >> >> >> > distributed simulations, moreover, may combine the need for large-grou >> >> >> > operation with many >> >> >> > senders. >> >> >> > >> >> >> Large groups require distributed initial key distribution! >> >> >> Large dynamic groups cannot rely upon a centralized KDC. This >> >> >> does not scale. This is highly inflexible. The VoD example >> >> >> demonstrates this. >> >> > >> >> "But for large, >> >> single- >> >> source multicast groups, it is generally undesirable to >> >> distribute key >> >> management functions among group members" >> >> >> >> Please support this with evidence. Also, wouldn't it be best to >> >> just discuss the requirements and design constraints but not >> >> suggest solutions here? >> > >> > DirecTV is a good example. TV conditional access systems don't >> > allow STBs to become group controllers. The need to support large >> > numbers of receivers, or to quickly remove members, or to have very >> > short latency in joining or re-keying a group are the requirements >> > and design constraints. We have commercial systems that optimize >> > for a subset of these constraints and some of the others listed in >> > Section 2. >> >> I don't think that this is a general example. If this were for the >> internet, what is wrong with saying address a.b.c.d or a.b.c.e or >> a.b.c.f can serve you? (Any key server that "sees" unencrypted keys >> is by default a member.) > > > I'm sorry you don't like my example. > Once again this isn't the point. There are examples in which it may be specifically inadvisable to distribute key management functions down, but why is it GENERALLY inadvisable to distribute key management functions down? > > >> > >> > >> >> >> 8. >> >> >> >> >> >> > >> >> >> > >> >> >> > >> >> >> > This design is based upon a "group controller" model >> >> >> > [RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group >> >> >> > owner as the root-of-trust. The group owner designates a key >> >> >> > distribution center for member registration and >> >> >> > re-key. >> >> >> > >> >> >> As was originally envisioned, the group owner CAN (and for >> >> >> large or sparse groups SHOULD) designate multiple key servers. >> >> > >> >> > >> >> > The architecture recommends that this be done by allowing any >> >> > key server to serve keys that is authorized to do so by the >> >> > group owner. The most straightforward way to do this is to use >> >> > SPKI or X.509 delegation. That's what we are recommending >> >> > rather than coding this up in the key management protocol. >> >> >> >> It is fair to say that the key server must provide proof of >> >> delegation. I _believe_ SPKI (SDSI) delegation is not widely >> >> used, but cannot support this. X. 509 attributes is a fair way >> >> of doing this, but is only one way. Whether it is more >> >> straightforward is a matter of opinion. >> > >> > Please tell me why SPKI delegation will not do this. I believe it >> > can. If we need to fix something in the trust infrastructure, I >> > would not build the solution into the key management protocol but >> > fix the trust infrastructure. Otherwise the key management >> > protocol will end up having all sorts of strange and inappropriate >> > features that make it difficult to implement and impossible to >> > test. >> >> My typo again. SPKI delegation is not widely used but can support >> this. The X.509 is available. It is a mechanism that provides some >> proof of authorization. For example in GSAKMP, it can be one of the >> certificates passed with the INVITATION message with the token >> containing the rule for key server of "attribute certificate signed >> by root x". Or alternatively, not using attribute certificates, it >> can just be a key server rule that says it must have an "identity >> cert signed by root y where the identity conforms to the rule name = >> a.b.c.?". I don't think that this is a strange and inappropriate >> feature. > > > Why put the feature in key management when it is done somewhere else? > > Just as the details of certificates are not specified in key management protocols, the details of of policy do not need to by specified here. However, certificates are needed to make many of the protocols secure. So, too, with policy. It may be (it is) necessary to deal with policy in order to make the km protocol secure. Thus, it does need to be dealt with to some extent. The actual form that the policy takes -- policy tokens, attribute certs, whatever -- is not critical here. It is a choice of the individual protocols. Saying that the architecture ASSUMES everything is obtained externally is inappropriate. It does not have to be. Imposing unnecessary requirements and assumptions unduly restricts protocol design. What is important though, is that each of the protocols is given the info that it needs to operate securely. Somehow, from somewhere. --- Andrea --------------4911CAD7BFF0FC40CF2B1488 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Mark,
    We are not going to agree whether or not crypto policy is meta-data or not.  Fine.  My reason for pointing out that most of the requirements listed involved more than just key management was to show that you are well on your way to providing a security management internet draft.
5.  Re:  video on demand example.   The example shows a pre-existing group of all possible members subject to pre-broadcast rekey.  One broadcast would destroy this property.


What is the property that would be destroyed?  What exactly is the problem?

The example wasn't clear to me but it appeared that you were stating that the potential audience was a group and requirement 6 (rekey) supported the access control to video broadcasts.  If this is what you meant, then each time some of the members were excluded from a broadcast, a smaller potential audience resulted for the next one.

I don't understand.

I am trying to restate what I think you said and you don't understand.  Could you restate the example so that we can determine whether there is a limitation or not?  Thanks.


There is a group that can receive video on demand (VOD) content where each member contacts the VOD server to get a file or stream.  It is not a broadcast; it is on demand.  The VOD server is authorized to source Re-key messages on behalf of the GCKS.  So when the member gets the file or stream data, it can get the key to decipher the file or stream from the VOD server.
 

Okay.  So far I understand.  Could you please fill in the details because I don't see the rekey aspect?
The member, before requesting the video is initialized with what?
Are all members initialized to the same values?
Is the stream encrypted per-member or per-group?
 
 
 
6.
 
  
A centralized
group controller (or KDC) that is used in this architecture may not be 
the best design for small, interactive groups.  But for large,
single-
source multicast groups, it is generally undesirable to distribute key 
management functions among group members: Unlike small, interactive 
groups, large single-source multicast groups generally need a 
specialized KDC to support large numbers of group members.  Large 
distributed simulations, moreover, may combine the need for large-grou 
operation with many
senders.
Large groups require distributed initial key distribution!  Large dynamic groups cannot rely upon a centralized KDC.  This does not scale.  This is highly inflexible.  The VoD example demonstrates this.
"But for large,
single-
source multicast groups, it is generally undesirable to distribute key
management functions among group members"

Please support this with evidence.  Also, wouldn't it be best to just discuss the requirements and design constraints but not suggest solutions here?

DirecTV is a good example. TV conditional access systems don't allow STBs to become group controllers.  The need to support large numbers of receivers, or to quickly remove members, or to have very short latency in joining or re-keying a group are the requirements and design constraints.  We have commercial systems that optimize for a subset of these constraints and some of the others listed in Section 2.

I don't think that this is a general example.  If this were for the internet, what is wrong with saying address a.b.c.d or a.b.c.e or a.b.c.f can serve you?  (Any key server that "sees" unencrypted keys is by default a member.)


I'm sorry you don't like my example.
 

Once again this isn't the point.  There are examples in which it may be specifically inadvisable to distribute key management functions down, but why is it GENERALLY inadvisable to distribute key management functions down?
 
 
8.
 
  
This design is based upon a "group controller" model 
[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group 
owner as the root-of-trust.  The group owner designates a key 
distribution center for member registration and
re-key.
As was originally envisioned, the group owner CAN (and for large or sparse groups SHOULD) designate multiple key servers.


The architecture recommends that this be done by allowing any key server to serve keys that is authorized to do so by the group owner.  The most straightforward way to do this is to use SPKI or X.509 delegation.  That's what we are recommending rather than coding this up in the key management protocol.

It is fair to say that the key server must provide proof of delegation.  I _believe_ SPKI (SDSI) delegation is not widely used, but cannot support this.  X. 509 attributes is a fair way of doing this, but is only one way.  Whether it is more straightforward is a matter of opinion.

Please tell me why SPKI delegation will not do this.  I believe it can.  If we need to fix something in the trust infrastructure, I would not build the solution into the key management protocol but fix the trust infrastructure.  Otherwise the key management protocol will end up having all sorts of strange and inappropriate features that make it difficult to implement and impossible to test.

My typo again.  SPKI delegation is not widely used but can support this.  The X.509 is available.  It is a mechanism that provides some proof of authorization.  For example in GSAKMP, it can be one of the certificates passed with the INVITATION message with the token containing the rule for key server of "attribute certificate signed by root x".  Or alternatively, not using attribute certificates, it can just be a key server rule that says it must have an "identity cert signed by root y where the identity conforms to the rule name = a.b.c.?".  I don't think that this is a strange and inappropriate feature.


Why put the feature in key management when it is done somewhere else?
 
 

Just as the details of certificates are not specified in key management protocols, the details of of policy do not need to by specified here.  However, certificates are needed to make many of the protocols secure.  So, too, with policy.  It may be (it is) necessary to deal with policy in order to make the km protocol secure.  Thus, it does need to be dealt with to some extent.

The actual form that the policy takes -- policy tokens, attribute certs, whatever -- is not critical here.  It is a choice of the individual protocols.  Saying that the architecture ASSUMES everything is obtained externally is inappropriate. It does not have to be.  Imposing unnecessary requirements and assumptions unduly restricts protocol design.

What is important though, is that each of the protocols is given the info that it needs to operate securely.  Somehow, from somewhere.
 

--- Andrea --------------4911CAD7BFF0FC40CF2B1488-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 29 11:25:56 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14958 for ; Fri, 29 Jun 2001 11:25:54 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 5965653878; Fri, 29 Jun 2001 11:26: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 BA36953881 for ; Fri, 29 Jun 2001 11:24:31 -0400 (EDT) Received: (qmail 66015 invoked by uid 3269); 29 Jun 2001 15:24:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 66012 invoked from network); 29 Jun 2001 15:24:31 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 29 Jun 2001 15:24:31 -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 f5TFNf819546; Fri, 29 Jun 2001 11:23:41 -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 LAA29480; Fri, 29 Jun 2001 11:23:41 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id LAA06168; Fri, 29 Jun 2001 11:23:40 -0400 From: Ran Canetti Message-Id: <200106291523.LAA06168@ornavella.watson.ibm.com> To: msec@securemulticast.org, thardjono@mediaone.net Subject: Re: Scalability of key management -- Re: [MSEC] Re: I-D ACTION:draft-ietf-msec-gkmarch-00.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: Fri, 29 Jun 2001 11:23:40 -0400 Regarding the scalability issue, and whether there should be centralized or distributed key servers, and whether the key servers should double up as group members: The current GKM architecture defines registration and rekey protocols (and possibly deregistration in the future). How does the question of centralized/distributed design affect these protocols, if at all? My impression is that the registration/rekey/deregistration protocols are to a large extent agnostic to whether there is a distributed or centralized design. And this is very good news: it means that msec does not need to decide between centralized/distributed designs - our protocols can live with either design, and we can leave it to the future system architects to decide how to organize their application. Ran _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 29 11:30:08 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15083 for ; Fri, 29 Jun 2001 11:30:07 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id BED4253890; Fri, 29 Jun 2001 11:28:55 -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 F401F53878 for ; Fri, 29 Jun 2001 11:27:20 -0400 (EDT) Received: (qmail 66271 invoked by uid 3269); 29 Jun 2001 15:27:20 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 66268 invoked from network); 29 Jun 2001 15:27:20 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 29 Jun 2001 15:27:20 -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 f5TFQn821586; Fri, 29 Jun 2001 11:26:49 -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 LAA25028; Fri, 29 Jun 2001 11:26:49 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id LAA32906; Fri, 29 Jun 2001 11:26:49 -0400 From: Ran Canetti Message-Id: <200106291526.LAA32906@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, 29 Jun 2001 11:26:49 -0400 Thomas, I agree with you that in most cases de-registration is not necessary, since a member joins for a predetermined amount of time. But there is certainly an added value to the ability to not have to keep paying for each additional minute/round/episode/whatever - but rather decide to leave when you want. The question is whether we want to totally exclude the possibility of doing this using msec? Note that the de-registration protocol will be optional. we may also make it optional to implement. so the complexity hit on systems that do not support it will be minimal. In any case, as Andrea and Sandro said, in case that we decide that de-registration is necessary, it definitely should be handled by msec. (ie, the application will make a de-registration request which msec will carry out.) Regarding the "how", this indeed has to be dealt with. I tend to think that setting up a new "de-registration SA" is the better/more flexible way to go (in spite of the added overhead) but I'm open to arguments... user authentiation and non-repudiation are indeed important concerns here. Ran > From thardjono@mediaone.net Fri Jun 29 08:46:25 2001 > > > Ran, > > Here are some comments on the notion of de-registration > in the context of the key management work in MSEC. > Please do read them (and possibly respond). > > > At 6/28/2001||03:48 PM, you 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. > > Most of the applications I have come across want to make use > of single-source multicast to deliver content in a Pay-Per-View > model where the unit of content or time is pre-programmed in advance > by the content provider. > > Thus, in this common model, the content provider leaves it up to the > user/customer to decide the unit of content to buy and to purchase > additional units when needed. Thus the burden is on the user. > > Citing the CableTV example, from a revenue perspective the content provider > would like the user to pay for an entire unit of content (eg. whole movie) > even when the user does not consume all of it. We've all had the > experience buying a lousy movie in a hotel :) > > > > >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). > > The example you quote seems contradictory. If a user is unsure about > the number of rounds he needs to watch (to complete the entire match), > the he/she can buy the programme one-round-at-a-time. > > If the user fails to pay for the next round of programme, then the user > is left out. It matters little (to the system) if the user says good-by > before the completion of the match or of the paid unit. > > If anything, it is the other way around: the system reminds the user > that the user only has X minutes left before the unit of content is over, > and for the user to pay some more. > > > > >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.) > > Again, this depends on the application model (ie. system-initiated or > user-initiated membership-termination). > > I don't think it is a mistake to leave it to the application. > In fact, it makes more sense to let the application-area decide which > model to follow (system-initiated or user-initiated). > > In the specific case of MSEC key management, requiring the member > to specifically de-register has the following implications: > > - How is the member going to de-register (ie. what mechanisms): > > If the member has to send a de-register message through the Cat-1 SA, > then that Cat-1 SA has to be around as long as the member is registered. > Now, this is an unresolved issue: > > Do we keep a Cat-1 SA around just so that the member can send > one message (de-register) to the GCKS? > This causes a lot of state to have to be maintained at the GCKS. > > Do we let the initial Cat-1 SA die, and establish a new Cat-1 SA > just for the member to send one message (de-register)? > This is a lot of negotiations and cycles just for one message. > > > - Authentication of de-register message: > > Clearly this de-register message has to be source-authentic, otherwise > any member can de-register other members. > > This points to the need of the members to have certificates (which > they do anyway, in order to register in the first place, both > in GSAKMP and GDOI). > > Since we assume that the Application triggered the initial Register > message (digitally signed), then it make it makes sense to let > the Application decide (and send) the final de-register message (with > a digital signature). > > > - Reliability: > > In SMuG and MSEC we all concluded that reliability of key management > messages should not have to be dealt by the key-management-protocol. > > Now, if you insist that the de-register message must be part of > the key management protocol, then you also must provide it > with reliability. > > Simply saying that "some layer above" will provide it with reliability > is really insufficient (circular argument). > > However, it makes sense to say that the Application (or a transport-layer > mechanism) will provide/assume reliability. Which, again, points > to appropriateness of the de-register message at the Application layer. > > > thomas > ------ > > > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 29 11:33:53 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15214 for ; Fri, 29 Jun 2001 11:33:52 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 083FF53884; Fri, 29 Jun 2001 11: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 17E6453878 for ; Fri, 29 Jun 2001 11:32:45 -0400 (EDT) Received: (qmail 66734 invoked by uid 3269); 29 Jun 2001 15:32:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 66731 invoked from network); 29 Jun 2001 15:32:44 -0000 Received: from chmls20.mediaone.net (24.147.1.156) by klesh.pair.com with SMTP; 29 Jun 2001 15:32:44 -0000 Received: from THARDJONO-LAP.mediaone.net ([63.90.80.227]) by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id f5TFWc613892; Fri, 29 Jun 2001 11:32:38 -0400 (EDT) Message-Id: <5.0.0.25.2.20010629111415.018761a0@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: Optionality of Re-Key "protocol" --- Re: [MSEC] The new GKM architecture draft Cc: mbaugher@cisco.com In-Reply-To: <200106281911.PAA32920@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, 29 Jun 2001 11:32:28 -0400 Mark, Ran, I have a *real* problem with the optionality of the Re-Key Protocol (pages 6 and 7). We have moved from a single model (as decribed in the GKMBB draft and Reference [HBH01] in the arch-doc), to having 2 separate protocols (possibly 3 if we include de-registration), and now to the possibility of excluding multicast itself to aid the scalability of key management. If indeed the Re-Key protocol is optional, and that Cat-2 SA is thus also optional, then really the keywords "SHOULD" that appears twice on page-7 of the document is redundant. Also, if we are trying to avoid the implosion problem, then clearly systems that use only Cat-1 SA (and nothing else) are not very useful and perhaps not worth addressing here (ie. just use pair-wise SSL or IPsec tunnels for joins and re-keys). My May posting (http://www.pairlist.net/pipermail/msec/2001-May/000123.html) was not meant to be an exercise in essay-writing, but to remind people that we are trying to stay with one model. I think the whole concept of "Registration" is incorrect, and that it is an Application-layer function. That is, a user is able to register to a website and download suitable parameters (and even code/puggins) to join the group. The user's Application then uses the parameters to join the group. At layer-3 and layer-4, a software does not register to the GCKS. When the software contacts the GCKS, it already knows: - the address/ports of the GCKS - the expected security mechanisms to talk to the GCKS - the key-management functions expected by the GCKS Perhaps in trying to accomodate all sorts of scenarios (ie. MARKS, ALC, etc), we are forgetting the primary means of key updates: multicast itself. thomas ------ ps. More comments to come as I read along. At 6/28/2001||03:11 PM, Ran Canetti wrote: >1. Note that the rekey SA is not mandatory - if the policy does not use >rekeys then this SA is redundant. > >2. Note that the data SA need not necessarily be initialized by the >registration protocol. One can think of a scenario where a member registers >in advance to actually joining the group, and the actual initialization of >the dat SA is done at a later time by the rekey protocol. > >3. Note that the "cat 1 SA" (or, registration SA) does not appear in the >above description at all. Indeed, this SA is internal to the registration >protocol and therefore does not need to be specified/dicussed in this >architectural document. It is up to the registration protocol. > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 29 11:41:20 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15463 for ; Fri, 29 Jun 2001 11:41:19 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id DE047537CB; Fri, 29 Jun 2001 11:38: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 B828D53878 for ; Fri, 29 Jun 2001 11:36:04 -0400 (EDT) Received: (qmail 67078 invoked by uid 3269); 29 Jun 2001 15:36:04 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 67074 invoked from network); 29 Jun 2001 15:36:04 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157) by klesh.pair.com with SMTP; 29 Jun 2001 15:36:04 -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 f5TFZA002531 for ; Fri, 29 Jun 2001 11:35:11 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 29 Jun 2001 11:35:10 -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 N4CSKJ51; Fri, 29 Jun 2001 11:35:12 -0400 Received: from nortelnetworks.com (LAKSHMINATH1 [47.16.4.201]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N4RCSAM4; Fri, 29 Jun 2001 11:35:10 -0400 Message-ID: <3B3CA138.FFBBBAA5@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: Scalability of key management -- Re: [MSEC] Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt References: <3B3A1837.D95360C0@columbia.sparta.com> <200106271103.HAA26170@ietf.org> <4.3.2.7.2.20010629074740.04283e18@mira-sjc5-6.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 29 Jun 2001 11:39:36 -0400 Content-Transfer-Encoding: 7bit During our discussions the following also came up: 1. We could have several registration "servers" and a prospective member could go to any one of them for registration. (I believe this has been mentioned in the literature) 2. Rekey servers could be different from registration servers and may be replicated. Of course, there are issues in synchronizing SA information between these servers. But, I believe this models the real world in some sense (people go to box offices across the country to buy tickets for sporting events etc.). cheers, Lakshminath Mark Baugher wrote: > > Thomas, > > At 10:10 AM 6/29/2001 -0400, Thomas Hardjono wrote: > > >Hi, > > > >I'm going to respond to one issue at a time. > > > > > >At 6/27/2001||01:30 PM, Andrea Colegrove wrote: > >>Mark, etal, > >>Initial comments on the architecture -- > >> > >>6. > >>> > >>>A centralized > >>>group controller (or KDC) that is used in this architecture may not be > >>>the best design for small, interactive groups. But for large, single- > >>>source multicast groups, it is generally undesirable to distribute key > >>>management functions among group members: Unlike small, interactive > >>>groups, large single-source multicast groups generally need a > >>>specialized KDC to support large numbers of group members. Large > >>>distributed simulations, moreover, may combine the need for large-grou > >>>operation with many senders. > >>Large groups require distributed initial key distribution! Large dynamic > >>groups cannot rely upon a centralized KDC. This does not scale. This is > >>highly inflexible. The VoD example demonstrates this. > >> > >>While the interactions with distributed rekey entities is more > >>complicated, this functionality may be needed in composite multicast > >>groups of limited scope. > > > > > >The paragraph about the scalability of key management in the arch-document is > >rather unclear. > > > >We definitely need more than one GCKS in order for key management to scale. > >This is what my earlier draft (draft-ietf-ipsec-gkmframework-03.txt) was > >about, namely having a two-layer set of GCKSs. > > > >The issue is whether a Remote GCKS is : > > > >(a) a "permanent" GCKS (ie. a full-time configured key server) that is > > functionally identical to the "root" GCKS and is *NOT* a group member, > > > >or > > > >(b) a member that is loaded with a GCKS-functionality, and that can be > > called-up for duty when scalability/reliability needs arise. > > > > > >Now, (a) is a natural usage of multiple GCKS. The two-tiered architecture > >of Key Servers (as described in draft-ietf-ipsec-gkmframework-03.txt) > >follows other 2-tiered services in the Internet. > > > >Option (b) is a more dynamic approach, which requires a member to be trusted > >and have a high-degree of security against attacks. > > > > > >This issue has to be clarified as clearly 1 GCKS is not going to scale, > >and a member-convertible-to-GCKS is not a attainable today > >in the vendor market. > > I didn't say that a centralized configuration has only one GCKS. > There could be many servers sharing a single address behind a load > balancer. The discussion on large-scale operation in the I-D > did not equate "centralized" with "one." > > Mark > > >thomas > >------ > > > > > > > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 29 12:10:29 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16772 for ; Fri, 29 Jun 2001 12:10:29 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 01D6F537DC; Fri, 29 Jun 2001 12:08: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 53D9C53820 for ; Fri, 29 Jun 2001 12:06:18 -0400 (EDT) Received: (qmail 69735 invoked by uid 3269); 29 Jun 2001 16:06:18 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 69732 invoked from network); 29 Jun 2001 16:06:17 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by klesh.pair.com with SMTP; 29 Jun 2001 16:06:17 -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 f5TG5mr23255; Fri, 29 Jun 2001 09:05:48 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-649.cisco.com [10.21.66.137]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADH11929; Fri, 29 Jun 2001 09:05:40 -0700 (PDT) Message-Id: <4.3.2.7.2.20010629084644.04283ce0@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: Optionality of Re-Key "protocol" --- Re: [MSEC] The new GKM architecture draft Cc: msec@securemulticast.org In-Reply-To: <5.0.0.25.2.20010629111415.018761a0@pop.ne.mediaone.net> References: <200106281911.PAA32920@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, 29 Jun 2001 09:05:11 -0700 Thomas At 11:32 AM 6/29/2001 -0400, Thomas Hardjono wrote: >Mark, Ran, > >I have a *real* problem with the optionality of the Re-Key Protocol >(pages 6 and 7). If an application does not need it, then why should they use it? >We have moved from a single model (as decribed in the GKMBB draft >and Reference [HBH01] in the arch-doc), to having 2 separate >protocols (possibly 3 if we include de-registration), >and now to the possibility of excluding multicast itself to aid >the scalability of key management. Scalability goes in two directions: We want to be able to scale down as well as scale up. For very small groups, I see no reason to require that Re-key be used. I have seen group security applications where there are few members in a group and each member can contact the sender via the unicast exchange of the Registration protocol to get key material. Once that's done, there is no reason for Re-key. When the key expires, another run of the Registration protocol is performed. >If indeed the Re-Key protocol is optional, and that Cat-2 SA is thus >also optional, then really the keywords "SHOULD" that appears twice >on page-7 of the document is redundant. Also, if we are trying >to avoid the implosion problem, then clearly systems that use >only Cat-1 SA (and nothing else) are not very useful and perhaps >not worth addressing here (ie. just use pair-wise SSL or IPsec tunnels >for joins and re-keys). Yes, there's no need for a Cat-2 SA (Re-key SA) if there is to be no Re-key operations for the group. The SHOULD refers to the case when Re-key operations are used for the group. There is no implosion problem to avoid if the group has only a few members. So the Registration protocol has the option of delivering TEKs (Data Security SAs) but no KEK (Re-key SA). SSL or IPsec still won't work even when there is no Re-key operation since the TEK needs to be common to a group. >My May posting (http://www.pairlist.net/pipermail/msec/2001-May/000123.html) >was not meant to be an exercise in essay-writing, but to remind >people that we are trying to stay with one model. I agree with that. I believe the motivation for the architecture is to define what that model is rather than having two or three specifications define their own models. I guess it won't be painless, either. If the model allows the Re-key operation to not be used when it is not needed (sounds reasonable, doesn't it), then this is an option within a single model. >I think the whole concept of "Registration" is incorrect, and that >it is an Application-layer function. That is, a user is able to register >to a website and download suitable parameters (and even code/puggins) >to join the group. The user's Application then uses the parameters >to join the group. Registration is the same as the GROUPKEY-PULL of GDOI, although changes will be needed in the latter to conform to the former. When you say "register at a website," this sounds vague to me. Are you doing everything over http, ssl, or does the website run the registration protocol? Key management is usually an application-layer function. I really don't understand your point here. >At layer-3 and layer-4, a software does not register to the GCKS. >When the software contacts the GCKS, it already knows: > - the address/ports of the GCKS > - the expected security mechanisms to talk to the GCKS > - the key-management functions expected by the GCKS I agree. >Perhaps in trying to accomodate all sorts of scenarios (ie. MARKS, >ALC, etc), we are forgetting the primary means of >key updates: multicast itself. You're going off the deep end here. The optional Re-key protocol is not that much different than the optional GROUPKEY-PUSH message in GDOI. Both can be sent using multicast or unicast. Mark >thomas >------ >ps. More comments to come as I read along. > > >At 6/28/2001||03:11 PM, Ran Canetti wrote: > > >>1. Note that the rekey SA is not mandatory - if the policy does not use >>rekeys then this SA is redundant. >> >>2. Note that the data SA need not necessarily be initialized by the >>registration protocol. One can think of a scenario where a member registers >>in advance to actually joining the group, and the actual initialization of >>the dat SA is done at a later time by the rekey protocol. >> >>3. Note that the "cat 1 SA" (or, registration SA) does not appear in the >>above description at all. Indeed, this SA is internal to the registration >>protocol and therefore does not need to be specified/dicussed in this >>architectural document. It is up to the registration protocol. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 29 12:25:41 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17460 for ; Fri, 29 Jun 2001 12:25:39 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A5E1753845; Fri, 29 Jun 2001 12:24: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 00B0C53822 for ; Fri, 29 Jun 2001 12:22:34 -0400 (EDT) Received: (qmail 71497 invoked by uid 3269); 29 Jun 2001 16:22:33 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 71494 invoked from network); 29 Jun 2001 16:22:33 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 29 Jun 2001 16:22:33 -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 f5TGM5x11686; Fri, 29 Jun 2001 09:22:06 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-649.cisco.com [10.21.66.137]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADH12223; Fri, 29 Jun 2001 09:21:53 -0700 (PDT) Message-Id: <4.3.2.7.2.20010629090643.0418a258@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Andrea Colegrove From: Mark Baugher Subject: Re: [MSEC] Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt Cc: msec@securemulticast.org In-Reply-To: <3B3C9C8C.79142782@columbia.sparta.com> References: <200106271103.HAA26170@ietf.org> <4.3.2.7.2.20010627202552.0433d4c8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010628141335.042f1da0@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010629072014.04183e80@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_96436207==_.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: Fri, 29 Jun 2001 09:21:23 -0700 --=====================_96436207==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Andrea, At 11:19 AM 6/29/2001 -0400, Andrea Colegrove wrote: >Mark, > We are not going to agree whether or not crypto policy is meta-data > or not. Fine. My reason for pointing out that most of the requirements > listed involved more than just key management was to show that you are > well on your way to providing a security management internet draft. We don't have anything called a "security management draft" on the roadmap. If I felt as strongly about this as you do, I would commence working on the draft. The first thing you need to do is define what it is. But holding up a key management I-D and criticizing it for not being a security management draft, which is right now only a buzz-phrase and nothing else, is not helpful. Here is my understanding of what consensus the WG has reached. The WG is to do a multicast security architecture draft, a group key management architecture draft, probably two key management protocols (one for IKE and one for IPsec), a data transforms draft, and a policy draft. The latter will then cause us to consider changes or additions that need to be made in other drafts to accommodate policy, which is the least well defined thing we are doing. >>>>>>>5. Re: video on demand example. The example shows a pre-existing >>>>>>>group of all possible members subject to pre-broadcast rekey. One >>>>>>>broadcast would destroy this property. >>>>>> >>>>>> >>>>>>What is the property that would be destroyed? What exactly is the >>>>>>problem? >>>>>The example wasn't clear to me but it appeared that you were stating >>>>>that the potential audience was a group and requirement 6 (rekey) >>>>>supported the access control to video broadcasts. If this is what you >>>>>meant, then each time some of the members were excluded from a >>>>>broadcast, a smaller potential audience resulted for the next one. >>>> >>>>I don't understand. >>>I am trying to restate what I think you said and you don't >>>understand. Could you restate the example so that we can determine >>>whether there is a limitation or not? Thanks. >> >> >>There is a group that can receive video on demand (VOD) content where >>each member contacts the VOD server to get a file or stream. It is not a >>broadcast; it is on demand. The VOD server is authorized to source >>Re-key messages on behalf of the GCKS. So when the member gets the file >>or stream data, it can get the key to decipher the file or stream from >>the VOD server. >> >Okay. So far I understand. Could you please fill in the details because >I don't see the rekey aspect? >The member, before requesting the video is initialized with what? >Are all members initialized to the same values? >Is the stream encrypted per-member or per-group? Each member of the particular VOD service has gotten the group KEK as a Re-key SA. This answers your first two questions. The stream is encrypted with a TEK for a data security SA in this particular example; the TEK with data security SA is sent in RE-key messages to the member. It is not per-member. The point here is that group keys are used for unicast streams or file download. >> >>>> >>>>>> >>>>>>>6. >>>>>>>> >>>>>>>> >>>>>>>>A centralized >>>>>>>>group controller (or KDC) that is used in this architecture may not be >>>>>>>>the best design for small, interactive groups. But for large, >>>>>>>>single- >>>>>>>>source multicast groups, it is generally undesirable to distribute key >>>>>>>>management functions among group members: Unlike small, interactive >>>>>>>>groups, large single-source multicast groups generally need a >>>>>>>>specialized KDC to support large numbers of group members. Large >>>>>>>>distributed simulations, moreover, may combine the need for large-grou >>>>>>>>operation with many >>>>>>>>senders. >>>>>>>Large groups require distributed initial key distribution! Large >>>>>>>dynamic groups cannot rely upon a centralized KDC. This does not >>>>>>>scale. This is highly inflexible. The VoD example demonstrates this. >>>>>"But for large, >>>>>single- >>>>>source multicast groups, it is generally undesirable to distribute key >>>>>management functions among group members" >>>>> >>>>>Please support this with evidence. Also, wouldn't it be best to just >>>>>discuss the requirements and design constraints but not suggest solutions here? >>>> >>>>DirecTV is a good example. TV conditional access systems don't allow >>>>STBs to become group controllers. The need to support large numbers of >>>>receivers, or to quickly remove members, or to have very short latency >>>>in joining or re-keying a group are the requirements and design >>>>constraints. We have commercial systems that optimize for a subset of >>>>these constraints and some of the others listed in Section 2. >>>I don't think that this is a general example. If this were for the >>>internet, what is wrong with saying address a.b.c.d or a.b.c.e or >>>a.b.c.f can serve you? (Any key server that "sees" unencrypted keys is >>>by default a member.) >> >> >>I'm sorry you don't like my example. >> >Once again this isn't the point. There are examples in which it may be >specifically inadvisable to distribute key management functions down, but >why is it GENERALLY inadvisable to distribute key management functions down? I don't know what "distribute key management functions down" means. >> >>>> >>>>>>>8. >>>>>>>> >>>>>>>> >>>>>>>>This design is based upon a "group controller" model >>>>>>>>[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group >>>>>>>>owner as the root-of-trust. The group owner designates a key >>>>>>>>distribution center for member registration and >>>>>>>>re-key. >>>>>>>As was originally envisioned, the group owner CAN (and for large or >>>>>>>sparse groups SHOULD) designate multiple key servers. >>>>>> >>>>>> >>>>>>The architecture recommends that this be done by allowing any key >>>>>>server to serve keys that is authorized to do so by the group >>>>>>owner. The most straightforward way to do this is to use SPKI or >>>>>>X.509 delegation. That's what we are recommending rather than coding >>>>>>this up in the key management protocol. >>>>>It is fair to say that the key server must provide proof of >>>>>delegation. I _believe_ SPKI (SDSI) delegation is not widely used, >>>>>but cannot support this. X. 509 attributes is a fair way of doing >>>>>this, but is only one way. Whether it is more straightforward is a >>>>>matter of opinion. >>>> >>>>Please tell me why SPKI delegation will not do this. I believe it >>>>can. If we need to fix something in the trust infrastructure, I would >>>>not build the solution into the key management protocol but fix the >>>>trust infrastructure. Otherwise the key management protocol will end >>>>up having all sorts of strange and inappropriate features that make it >>>>difficult to implement and impossible to test. >>>My typo again. SPKI delegation is not widely used but can support >>>this. The X.509 is available. It is a mechanism that provides some >>>proof of authorization. For example in GSAKMP, it can be one of the >>>certificates passed with the INVITATION message with the token >>>containing the rule for key server of "attribute certificate signed by >>>root x". Or alternatively, not using attribute certificates, it can >>>just be a key server rule that says it must have an "identity cert >>>signed by root y where the identity conforms to the rule name = >>>a.b.c.?". I don't think that this is a strange and inappropriate feature. >> >> >>Why put the feature in key management when it is done somewhere else? >> >> >Just as the details of certificates are not specified in key management >protocols, the details of of policy do not need to by specified >here. However, certificates are needed to make many of the protocols >secure. So, too, with policy. It may be (it is) necessary to deal with >policy in order to make the km protocol secure. Thus, it does need to be >dealt with to some extent. > >The actual form that the policy takes -- policy tokens, attribute certs, >whatever -- is not critical here. It is a choice of the individual >protocols. Saying that the architecture ASSUMES everything is obtained >externally is inappropriate. It does not have to be. Imposing unnecessary >requirements and assumptions unduly restricts protocol design. > >What is important though, is that each of the protocols is given the info >that it needs to operate securely. Somehow, from somewhere. I think I agree with this. Mark > > >--- Andrea --=====================_96436207==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Andrea,

At 11:19 AM 6/29/2001 -0400, Andrea Colegrove wrote:

Mark,
    We are not going to agree whether or not crypto policy is meta-data or not.  Fine.  My reason for pointing out that most of the requirements listed involved more than just key management was to show that you are well on your way to providing a security management internet draft.

We don't have anything called a "security management draft" on the roadmap.   If I felt as strongly about this as you do, I would commence working on the draft.  The first thing you need to do is define what it is.  But holding up a key management I-D and criticizing it for not being a security management draft, which is right now only a buzz-phrase and nothing else, is not helpful.

Here is my understanding of what consensus the WG has reached.  The WG is to do a multicast security architecture draft, a group key management architecture draft, probably two key management protocols (one for IKE and one for IPsec), a data transforms draft, and a policy draft.  The latter will then cause us to consider changes or additions that need to be made in other drafts to accommodate policy, which is the least well defined thing we are doing.

5.  Re:  video on demand example.   The example shows a pre-existing group of all possible members subject to pre-broadcast rekey.  One broadcast would destroy this=20 property.


What is the property that would be destroyed?  What exactly is the problem?
The example wasn't clear to me but it appeared that you were stating that the potential audience was a group and requirement 6 (rekey) supported the access control to video broadcasts.  If this is what you meant, then each time some of the members were excluded from a broadcast, a smaller potential audience resulted for the next one.

I don't understand.
I am trying to restate what I think you said and you don't understand.  Could you restate the example so that we can determine whether there is a limitation or not?  Thanks.


There is a group that can receive video on demand (VOD) content where each member contacts the VOD server to get a file or stream.  It is not a broadcast; it is on demand.  The VOD server is authorized to source Re-key messages on behalf of the GCKS.  So when the member gets the file or stream data, it can get the key to decipher the file or stream from the VOD server.
 
Okay.  So far I understand.  Could you please fill in the details because I don't see the rekey aspect?
The member, before requesting the video is initialized with what?
Are all members initialized to the same values?
Is the stream encrypted per-member or per-group?
Each member of the particular VOD service has gotten the group KEK as a Re-key SA.  This answers your first two questions.  The stream is encrypted with a TEK for a data security SA in this particular example; the TEK with data security SA is sent in RE-key messages to the member.  It is not per-member.  The point here is that group keys are used for unicast streams or file download.

 
 
 
6.
 
  
A centralized
group controller (or KDC) that is used in this architecture may not be=20
the best design for small, interactive groups.  But for large,
single-
source multicast groups, it is generally undesirable to distribute key=20
management functions among group members: Unlike small, interactive=20
groups, large single-source multicast groups generally need a=20
specialized KDC to support large numbers of group members.  Large=20
distributed simulations, moreover, may combine the need for large-grou=20
operation with many
senders.
Large groups require distributed initial key distribution!  Large dynamic groups cannot rely upon a centralized KDC.  This does not scale.  This is highly inflexible.  The VoD example demonstrates this.
"But for large,
single-
source multicast groups, it is generally undesirable to distribute key
management functions among group members"

Please support this with evidence.  Also, wouldn't it be best to just discuss the requirements and design constraints but not suggest solutions here?

DirecTV is a good example. TV conditional access systems don't allow STBs to become group controllers.  The need to support large numbers of receivers, or to quickly remove members, or to have very short latency in joining or re-keying a group are the requirements and design constraints.  We have commercial systems that optimize for a subset of these constraints and some of the others listed in Section 2.
I don't think that this is a general example.  If this were for the internet, what is wrong with saying address a.b.c.d or a.b.c.e or a.b.c.f can serve you?  (Any key server that "sees" unencrypted keys is by default a member.)


I'm sorry you don't like my example.
 
Once again this isn't the point.  There are examples in which it may be specifically inadvisable to distribute key management functions down, but why is it GENERALLY inadvisable to distribute key management functions down?

I don't know what "distribute key management functions down" means.

 
 
8.
 
  
This design is based upon a "group controller" model=20
[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group=20
owner as the root-of-trust.  The group owner designates a key=20
distribution center for member registration and
re-key.
As was originally envisioned, the group owner CAN (and for large or sparse groups SHOULD) designate multiple key servers.


The architecture recommends that this be done by allowing any key server to serve keys that is authorized to do so by the group owner.  The most straightforward way to do this is to use SPKI or X.509 delegation.  That's what we are recommending rather than coding this up in the key management protocol.
It is fair to say that the key server must provide proof of delegation.  I _believe_ SPKI (SDSI) delegation is not widely used, but cannot support this.  X. 509 attributes is a fair way of doing this, but is only one way.  Whether it is more straightforward is a matter of opinion.

Please tell me why SPKI delegation will not do this.  I believe it can.  If we need to fix something in the trust infrastructure, I would not build the solution into the key management protocol but fix the trust infrastructure.  Otherwise the key management protocol will end up having all sorts of strange and inappropriate features that make it difficult to implement and impossible to test.
My typo again.  SPKI delegation is not widely used but can support this.  The X.509 is available.  It is a mechanism that provides some proof of authorization.  For example in GSAKMP, it can be one of the certificates passed with the INVITATION message with the token containing the rule for key server of "attribute certificate signed by root x".  Or alternatively, not using attribute certificates, it can just be a key server rule that says it must have an "identity cert signed by root y where the identity conforms to the rule name =3D a.b.c.?".  I don't think that this is a strange and inappropriate feature.


Why put the feature in key management when it is done somewhere else?
 
 
Just as the details of certificates are not specified in key management protocols, the details of of policy do not need to by specified here.  However, certificates are needed to make many of the protocols secure.  So, too, with policy.  It may be (it is) necessary to deal with policy in order to make the km protocol secure.  Thus, it does need to be dealt with to some extent.

The actual form that the policy takes -- policy tokens, attribute certs, whatever -- is not critical here.  It is a choice of the individual protocols.  Saying that the architecture ASSUMES everything is obtained externally is inappropriate. It does not have to be.  Imposing unnecessary requirements and assumptions unduly restricts protocol design.

What is important though, is that each of the protocols is given the info that it needs to operate securely.  Somehow, from somewhere.
I think I agree with this.

Mark

 

--- Andrea
--=====================_96436207==_.ALT-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 29 12:39:00 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18185 for ; Fri, 29 Jun 2001 12:38:59 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 441D653787; Fri, 29 Jun 2001 12:39:07 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 0756D53787 for ; Fri, 29 Jun 2001 12:36:46 -0400 (EDT) Received: (qmail 72772 invoked by uid 3269); 29 Jun 2001 16:36:45 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 72769 invoked from network); 29 Jun 2001 16:36:45 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 29 Jun 2001 16:36:45 -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 f5TGaMx21925; Fri, 29 Jun 2001 09:36:22 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-649.cisco.com [10.21.66.137]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADH12524; Fri, 29 Jun 2001 09:36:12 -0700 (PDT) Message-Id: <4.3.2.7.2.20010629093131.0428fc98@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: Scalability of key management -- Re: [MSEC] Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt Cc: msec@securemulticast.org In-Reply-To: <200106291523.LAA06168@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, 29 Jun 2001 09:35:43 -0700 Ran At 11:23 AM 6/29/2001 -0400, Ran Canetti wrote: >Regarding the scalability issue, and whether there should be centralized >or distributed key servers, and whether the key servers should double up >as group members: > >The current GKM architecture defines registration and rekey protocols >(and possibly deregistration in the future). How does the question of >centralized/distributed design affect these protocols, if at all? > >My impression is that the registration/rekey/deregistration protocols >are to a large extent agnostic to whether there is a distributed or >centralized design. And this is very good news: it means that msec does >not need to decide between centralized/distributed designs - our protocols >can live with either design, and we can leave it to the future system >architects to decide how to organize their application. I agree. It's an architecture question, however, whether the protocols are sufficient to allow large-scale operation for source-specific multicast: Do we need to have a inter-GCKS protocol, for example? So while what you say is true, the question remains as to whether we are missing something. I don't think we are, but the gkm architecture needs to consider this. I am fine with removing the centralized versus distributed key management issues from the I-D since this leads to long discussions and lots of disagreement on what centralized means and what distributed means. Mark >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 Jun 29 13:17:15 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19599 for ; Fri, 29 Jun 2001 13:17:14 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2A9D653553; Fri, 29 Jun 2001 13:16: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 C8EE853530 for ; Fri, 29 Jun 2001 13:12:38 -0400 (EDT) Received: (qmail 78788 invoked by uid 3269); 29 Jun 2001 17:12:38 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 78785 invoked from network); 29 Jun 2001 17:12:38 -0000 Received: from m5.sparta.com (root@157.185.61.1) by klesh.pair.com with SMTP; 29 Jun 2001 17:12:38 -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 f5THCax29818; Fri, 29 Jun 2001 12:12:36 -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 NAA06163; Fri, 29 Jun 2001 13:12:34 -0400 (EDT) Message-ID: <3B3CB6EE.6FCCBDE1@columbia.sparta.com> From: Andrea Colegrove X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt References: <200106271103.HAA26170@ietf.org> <4.3.2.7.2.20010627202552.0433d4c8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010628141335.042f1da0@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010629072014.04183e80@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010629090643.0418a258@mira-sjc5-6.cisco.com> Content-Type: multipart/alternative; boundary="------------DAEA7C035BD100E6260E99B1" 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, 29 Jun 2001 13:12:14 -0400 --------------DAEA7C035BD100E6260E99B1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark, People who have been working in security for a while do not consider "security management" to be just a buzz word. --- Andrea Mark Baugher wrote: > Andrea, > > At 11:19 AM 6/29/2001 -0400, Andrea Colegrove wrote: > >> Mark, >> We are not going to agree whether or not crypto policy is >> meta-data or not. Fine. My reason for pointing out that most of >> the requirements listed involved more than just key management was >> to show that you are well on your way to providing a security >> management internet draft. > > > We don't have anything called a "security management draft" on the > roadmap. If I felt as strongly about this as you do, I would > commence working on the draft. The first thing you need to do is > define what it is. But holding up a key management I-D and > criticizing it for not being a security management draft, which is > right now only a buzz-phrase and nothing else, is not helpful. > > Here is my understanding of what consensus the WG has reached. The WG > is to do a multicast security architecture draft, a group key > management architecture draft, probably two key management protocols > (one for IKE and one for IPsec), a data transforms draft, and a policy > draft. The latter will then cause us to consider changes or additions > that need to be made in other drafts to accommodate policy, which is > the least well defined thing we are doing. > > >> >> >> > > 5. Re: video on demand example. The example shows a >> >> >> > > pre-existing group of all possible members subject to >> >> >> > > pre-broadcast rekey. One broadcast would destroy this >> >> >> > > property. >> >> >> > >> >> >> > What is the property that would be destroyed? What exactly >> >> >> > is the problem? >> >> >> >> >> >> The example wasn't clear to me but it appeared that you were >> >> >> stating that the potential audience was a group and >> >> >> requirement 6 (rekey) supported the access control to video >> >> >> broadcasts. If this is what you meant, then each time some of >> >> >> the members were excluded from a broadcast, a smaller >> >> >> potential audience resulted for the next one. >> >> > >> >> > >> >> > I don't understand. >> >> >> >> I am trying to restate what I think you said and you don't >> >> understand. Could you restate the example so that we can >> >> determine whether there is a limitation or not? Thanks. >> > >> > There is a group that can receive video on demand (VOD) content >> > where each member contacts the VOD server to get a file or stream. >> > It is not a broadcast; it is on demand. The VOD server is >> > authorized to source Re-key messages on behalf of the GCKS. So >> > when the member gets the file or stream data, it can get the key to >> > decipher the file or stream from the VOD server. >> >> Okay. So far I understand. Could you please fill in the details >> because I don't see the rekey aspect? >> The member, before requesting the video is initialized with what? >> Are all members initialized to the same values? >> Is the stream encrypted per-member or per-group? > > > Each member of the particular VOD service has gotten the group KEK as > a Re-key SA. This answers your first two questions. The stream is > encrypted with a TEK for a data security SA in this particular > example; the TEK with data security SA is sent in RE-key messages to > the member. It is not per-member. The point here is that group keys > are used for unicast streams or file download. > > >> > >> > >> >> > >> >> > >> >> >> > >> >> >> > >> >> >> > > 6. >> >> >> > > >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> A centralized >> >> >> > >> group controller (or KDC) that is used in this architecture may not be >> >> >> > >> the best design for small, interactive groups. But for large, >> >> >> > >> single- >> >> >> > >> source multicast groups, it is generally undesirable to distribute key >> >> >> > >> management functions among group members: Unlike small, interactive >> >> >> > >> groups, large single-source multicast groups generally need a >> >> >> > >> specialized KDC to support large numbers of group members. Large >> >> >> > >> distributed simulations, moreover, may combine the need for large-grou >> >> >> > >> operation with many >> >> >> > >> senders. >> >> >> > >> >> >> >> > > Large groups require distributed initial key distribution! >> >> >> > > Large dynamic groups cannot rely upon a centralized KDC. >> >> >> > > This does not scale. This is highly inflexible. The VoD >> >> >> > > example demonstrates this. >> >> >> > >> >> >> "But for large, >> >> >> single- >> >> >> source multicast groups, it is generally undesirable to >> >> >> distribute key >> >> >> management functions among group members" >> >> >> >> >> >> Please support this with evidence. Also, wouldn't it be best >> >> >> to just discuss the requirements and design constraints but >> >> >> not suggest solutions here? >> >> > >> >> > >> >> > DirecTV is a good example. TV conditional access systems don't >> >> > allow STBs to become group controllers. The need to support >> >> > large numbers of receivers, or to quickly remove members, or to >> >> > have very short latency in joining or re-keying a group are the >> >> > requirements and design constraints. We have commercial >> >> > systems that optimize for a subset of these constraints and >> >> > some of the others listed in Section 2. >> >> >> >> I don't think that this is a general example. If this were for >> >> the internet, what is wrong with saying address a.b.c.d or >> >> a.b.c.e or a.b.c.f can serve you? (Any key server that "sees" >> >> unencrypted keys is by default a member.) >> > >> > I'm sorry you don't like my example. >> >> Once again this isn't the point. There are examples in which it may >> be specifically inadvisable to distribute key management functions >> down, but why is it GENERALLY inadvisable to distribute key >> management functions down? > > > I don't know what "distribute key management functions down" means. > > >> > >> > >> >> > >> >> > >> >> >> > > 8. >> >> >> > > >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> This design is based upon a "group controller" model >> >> >> > >> [RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group >> >> >> > >> owner as the root-of-trust. The group owner designates a key >> >> >> > >> distribution center for member registration and >> >> >> > >> re-key. >> >> >> > >> >> >> >> > > As was originally envisioned, the group owner CAN (and for >> >> >> > > large or sparse groups SHOULD) designate multiple key >> >> >> > > servers. >> >> >> > >> >> >> > The architecture recommends that this be done by allowing >> >> >> > any key server to serve keys that is authorized to do so by >> >> >> > the group owner. The most straightforward way to do this is >> >> >> > to use SPKI or X.509 delegation. That's what we are >> >> >> > recommending rather than coding this up in the key >> >> >> > management protocol. >> >> >> >> >> >> It is fair to say that the key server must provide proof of >> >> >> delegation. I _believe_ SPKI (SDSI) delegation is not widely >> >> >> used, but cannot support this. X. 509 attributes is a fair >> >> >> way of doing this, but is only one way. Whether it is more >> >> >> straightforward is a matter of opinion. >> >> > >> >> > >> >> > Please tell me why SPKI delegation will not do this. I believe >> >> > it can. If we need to fix something in the trust >> >> > infrastructure, I would not build the solution into the key >> >> > management protocol but fix the trust infrastructure. >> >> > Otherwise the key management protocol will end up having all >> >> > sorts of strange and inappropriate features that make it >> >> > difficult to implement and impossible to test. >> >> >> >> My typo again. SPKI delegation is not widely used but can >> >> support this. The X.509 is available. It is a mechanism that >> >> provides some proof of authorization. For example in GSAKMP, it >> >> can be one of the certificates passed with the INVITATION message >> >> with the token containing the rule for key server of "attribute >> >> certificate signed by root x". Or alternatively, not using >> >> attribute certificates, it can just be a key server rule that >> >> says it must have an "identity cert signed by root y where the >> >> identity conforms to the rule name = a.b.c.?". I don't think >> >> that this is a strange and inappropriate feature. >> > >> > Why put the feature in key management when it is done somewhere >> > else? >> > >> >> Just as the details of certificates are not specified in key >> management protocols, the details of of policy do not need to by >> specified here. However, certificates are needed to make many of >> the protocols secure. So, too, with policy. It may be (it is) >> necessary to deal with policy in order to make the km protocol >> secure. Thus, it does need to be dealt with to some extent. >> >> The actual form that the policy takes -- policy tokens, attribute >> certs, whatever -- is not critical here. It is a choice of the >> individual protocols. Saying that the architecture ASSUMES >> everything is obtained externally is inappropriate. It does not have >> to be. Imposing unnecessary requirements and assumptions unduly >> restricts protocol design. >> >> What is important though, is that each of the protocols is given the >> info that it needs to operate securely. Somehow, from somewhere. > > > I think I agree with this. > > Mark > > >> >> >> --- Andrea > --------------DAEA7C035BD100E6260E99B1 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Mark,
    People who have been working in security for a while do not consider "security management" to be just a buzz word.
 

--- Andrea

Mark Baugher wrote:

 Andrea,

At 11:19 AM 6/29/2001 -0400, Andrea Colegrove wrote:

Mark,
    We are not going to agree whether or not crypto policy is meta-data or not.  Fine.  My reason for pointing out that most of the requirements listed involved more than just key management was to show that you are well on your way to providing a security management internet draft.


We don't have anything called a "security management draft" on the roadmap.   If I felt as strongly about this as you do, I would commence working on the draft.  The first thing you need to do is define what it is.  But holding up a key management I-D and criticizing it for not being a security management draft, which is right now only a buzz-phrase and nothing else, is not helpful.

Here is my understanding of what consensus the WG has reached.  The WG is to do a multicast security architecture draft, a group key management architecture draft, probably two key management protocols (one for IKE and one for IPsec), a data transforms draft, and a policy draft.  The latter will then cause us to consider changes or additions that need to be made in other drafts to accommodate policy, which is the least well defined thing we are doing.
 

5.  Re:  video on demand example.   The example shows a pre-existing group of all possible members subject to pre-broadcast rekey.  One broadcast would destroy this property.

What is the property that would be destroyed?  What exactly is the problem?

The example wasn't clear to me but it appeared that you were stating that the potential audience was a group and requirement 6 (rekey) supported the access control to video broadcasts.  If this is what you meant, then each time some of the members were excluded from a broadcast, a smaller potential audience resulted for the next one.


I don't understand.

I am trying to restate what I think you said and you don't understand.  Could you restate the example so that we can determine whether there is a limitation or not?  Thanks.

There is a group that can receive video on demand (VOD) content where each member contacts the VOD server to get a file or stream.  It is not a broadcast; it is on demand.  The VOD server is authorized to source Re-key messages on behalf of the GCKS.  So when the member gets the file or stream data, it can get the key to decipher the file or stream from the VOD server.

Okay.  So far I understand.  Could you please fill in the details because I don't see the rekey aspect?
The member, before requesting the video is initialized with what?
Are all members initialized to the same values?
Is the stream encrypted per-member or per-group?


Each member of the particular VOD service has gotten the group KEK as a Re-key SA.  This answers your first two questions.  The stream is encrypted with a TEK for a data security SA in this particular example; the TEK with data security SA is sent in RE-key messages to the member.  It is not per-member.  The point here is that group keys are used for unicast streams or file download.
 

 
 
 
6.
 
  
A centralized
group controller (or KDC) that is used in this architecture may not be 
the best design for small, interactive groups.  But for large,
single-
source multicast groups, it is generally undesirable to distribute key 
management functions among group members: Unlike small, interactive 
groups, large single-source multicast groups generally need a 
specialized KDC to support large numbers of group members.  Large 
distributed simulations, moreover, may combine the need for large-grou 
operation with many
senders.
Large groups require distributed initial key distribution!  Large dynamic groups cannot rely upon a centralized KDC.  This does not scale.  This is highly inflexible.  The VoD example demonstrates this.
"But for large,
single-
source multicast groups, it is generally undesirable to distribute key
management functions among group members"

Please support this with evidence.  Also, wouldn't it be best to just discuss the requirements and design constraints but not suggest solutions here?


DirecTV is a good example. TV conditional access systems don't allow STBs to become group controllers.  The need to support large numbers of receivers, or to quickly remove members, or to have very short latency in joining or re-keying a group are the requirements and design constraints.  We have commercial systems that optimize for a subset of these constraints and some of the others listed in Section 2.

I don't think that this is a general example.  If this were for the internet, what is wrong with saying address a.b.c.d or a.b.c.e or a.b.c.f can serve you?  (Any key server that "sees" unencrypted keys is by default a member.)

I'm sorry you don't like my example.

Once again this isn't the point.  There are examples in which it may be specifically inadvisable to distribute key management functions down, but why is it GENERALLY inadvisable to distribute key management functions down?


I don't know what "distribute key management functions down" means.
 

 
 
8.
 
  
This design is based upon a "group controller" model 
[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group 
owner as the root-of-trust.  The group owner designates a key 
distribution center for member registration and
re-key.
As was originally envisioned, the group owner CAN (and for large or sparse groups SHOULD) designate multiple key servers.

The architecture recommends that this be done by allowing any key server to serve keys that is authorized to do so by the group owner.  The most straightforward way to do this is to use SPKI or X.509 delegation.  That's what we are recommending rather than coding this up in the key management protocol.

It is fair to say that the key server must provide proof of delegation.  I _believe_ SPKI (SDSI) delegation is not widely used, but cannot support this.  X. 509 attributes is a fair way of doing this, but is only one way.  Whether it is more straightforward is a matter of opinion.


Please tell me why SPKI delegation will not do this.  I believe it can.  If we need to fix something in the trust infrastructure, I would not build the solution into the key management protocol but fix the trust infrastructure.  Otherwise the key management protocol will end up having all sorts of strange and inappropriate features that make it difficult to implement and impossible to test.

My typo again.  SPKI delegation is not widely used but can support this.  The X.509 is available.  It is a mechanism that provides some proof of authorization.  For example in GSAKMP, it can be one of the certificates passed with the INVITATION message with the token containing the rule for key server of "attribute certificate signed by root x".  Or alternatively, not using attribute certificates, it can just be a key server rule that says it must have an "identity cert signed by root y where the identity conforms to the rule name = a.b.c.?".  I don't think that this is a strange and inappropriate feature.

Why put the feature in key management when it is done somewhere else?
 

Just as the details of certificates are not specified in key management protocols, the details of of policy do not need to by specified here.  However, certificates are needed to make many of the protocols secure.  So, too, with policy.  It may be (it is) necessary to deal with policy in order to make the km protocol secure.  Thus, it does need to be dealt with to some extent.

The actual form that the policy takes -- policy tokens, attribute certs, whatever -- is not critical here.  It is a choice of the individual protocols.  Saying that the architecture ASSUMES everything is obtained externally is inappropriate. It does not have to be.  Imposing unnecessary requirements and assumptions unduly restricts protocol design.

What is important though, is that each of the protocols is given the info that it needs to operate securely.  Somehow, from somewhere.


I think I agree with this.

Mark
 

 

--- Andrea

--------------DAEA7C035BD100E6260E99B1-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 29 13:44:19 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20539 for ; Fri, 29 Jun 2001 13:44:19 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 59BDD53550; Fri, 29 Jun 2001 13:44: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 1FA5F53546 for ; Fri, 29 Jun 2001 13:40:46 -0400 (EDT) Received: (qmail 84783 invoked by uid 3269); 29 Jun 2001 17:40:45 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 84780 invoked from network); 29 Jun 2001 17:40:45 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by klesh.pair.com with SMTP; 29 Jun 2001 17:40: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 f5THeLr08663; Fri, 29 Jun 2001 10:40:21 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-649.cisco.com [10.21.66.137]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADH14348; Fri, 29 Jun 2001 10:40:11 -0700 (PDT) Message-Id: <4.3.2.7.2.20010629102938.0429ac70@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Andrea Colegrove From: Mark Baugher Subject: Re: [MSEC] Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt Cc: msec@securemulticast.org In-Reply-To: <3B3CB6EE.6FCCBDE1@columbia.sparta.com> References: <200106271103.HAA26170@ietf.org> <4.3.2.7.2.20010627202552.0433d4c8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010628141335.042f1da0@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010629072014.04183e80@mira-sjc5-6.cisco.com> <4.3.2.7.2.20010629090643.0418a258@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_101134103==_.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: Fri, 29 Jun 2001 10:39:41 -0700 --=====================_101134103==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Andrea I don't know how Thomas and Ran feel about this, but I hope you give msec the benefit of your experience by writing a security management architecture I-D for msec - if you feel it's ready for the IETF standards process. thanks, Mark At 01:12 PM 6/29/2001 -0400, Andrea Colegrove wrote: >Mark, > People who have been working in security for a while do not consider > "security management" to be just a buzz word. > > >--- Andrea > >Mark Baugher wrote: >> Andrea, >> >>At 11:19 AM 6/29/2001 -0400, Andrea Colegrove wrote: >>>Mark, >>> We are not going to agree whether or not crypto policy is meta-data >>> or not. Fine. My reason for pointing out that most of the >>> requirements listed involved more than just key management was to show >>> that you are well on your way to providing a security management >>> internet draft. >> >> >>We don't have anything called a "security management draft" on the >>roadmap. If I felt as strongly about this as you do, I would commence >>working on the draft. The first thing you need to do is define what it >>is. But holding up a key management I-D and criticizing it for not being >>a security management draft, which is right now only a buzz-phrase and >>nothing else, is not helpful. >> >>Here is my understanding of what consensus the WG has reached. The WG is >>to do a multicast security architecture draft, a group key management >>architecture draft, probably two key management protocols (one for IKE >>and one for IPsec), a data transforms draft, and a policy draft. The >>latter will then cause us to consider changes or additions that need to >>be made in other drafts to accommodate policy, which is the least well >>defined thing we are doing. >> >>>>>>>>>5. Re: video on demand example. The example shows a >>>>>>>>>pre-existing group of all possible members subject to >>>>>>>>>pre-broadcast rekey. One broadcast would destroy this property. >>>>>>>> >>>>>>>>What is the property that would be destroyed? What exactly is the >>>>>>>>problem? >>>>>>>The example wasn't clear to me but it appeared that you were stating >>>>>>>that the potential audience was a group and requirement 6 (rekey) >>>>>>>supported the access control to video broadcasts. If this is what >>>>>>>you meant, then each time some of the members were excluded from a >>>>>>>broadcast, a smaller potential audience resulted for the next one. >>>>>> >>>>>> >>>>>>I don't understand. >>>>>I am trying to restate what I think you said and you don't >>>>>understand. Could you restate the example so that we can determine >>>>>whether there is a limitation or not? Thanks. >>>> >>>>There is a group that can receive video on demand (VOD) content where >>>>each member contacts the VOD server to get a file or stream. It is not >>>>a broadcast; it is on demand. The VOD server is authorized to source >>>>Re-key messages on behalf of the GCKS. So when the member gets the >>>>file or stream data, it can get the key to decipher the file or stream >>>>from the VOD server. >>>Okay. So far I understand. Could you please fill in the details >>>because I don't see the rekey aspect? >>>The member, before requesting the video is initialized with what? >>>Are all members initialized to the same values? >>>Is the stream encrypted per-member or per-group? >> >> >>Each member of the particular VOD service has gotten the group KEK as a >>Re-key SA. This answers your first two questions. The stream is >>encrypted with a TEK for a data security SA in this particular example; >>the TEK with data security SA is sent in RE-key messages to the >>member. It is not per-member. The point here is that group keys are >>used for unicast streams or file download. >> >>>> >>>>>> >>>>>>>> >>>>>>>>>6. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>A centralized >>>>>>>>>>group controller (or KDC) that is used in this architecture may >>>>>>>>>>not be >>>>>>>>>>the best design for small, interactive groups. But for large, >>>>>>>>>>single- >>>>>>>>>>source multicast groups, it is generally undesirable to >>>>>>>>>>distribute key >>>>>>>>>>management functions among group members: Unlike small, interactive >>>>>>>>>>groups, large single-source multicast groups generally need a >>>>>>>>>>specialized KDC to support large numbers of group members. Large >>>>>>>>>>distributed simulations, moreover, may combine the need for >>>>>>>>>>large-grou >>>>>>>>>>operation with many >>>>>>>>>>senders. >>>>>>>>>Large groups require distributed initial key distribution! Large >>>>>>>>>dynamic groups cannot rely upon a centralized KDC. This does not >>>>>>>>>scale. This is highly inflexible. The VoD example demonstrates this. >>>>>>>"But for large, >>>>>>>single- >>>>>>>source multicast groups, it is generally undesirable to distribute key >>>>>>>management functions among group members" >>>>>>> >>>>>>>Please support this with evidence. Also, wouldn't it be best to >>>>>>>just discuss the requirements and design constraints but not suggest >>>>>>>solutions here? >>>>>> >>>>>> >>>>>>DirecTV is a good example. TV conditional access systems don't allow >>>>>>STBs to become group controllers. The need to support large numbers >>>>>>of receivers, or to quickly remove members, or to have very short >>>>>>latency in joining or re-keying a group are the requirements and >>>>>>design constraints. We have commercial systems that optimize for a >>>>>>subset of these constraints and some of the others listed in Section 2. >>>>>I don't think that this is a general example. If this were for the >>>>>internet, what is wrong with saying address a.b.c.d or a.b.c.e or >>>>>a.b.c.f can serve you? (Any key server that "sees" unencrypted keys >>>>>is by default a member.) >>>> >>>>I'm sorry you don't like my example. >>>Once again this isn't the point. There are examples in which it may be >>>specifically inadvisable to distribute key management functions down, >>>but why is it GENERALLY inadvisable to distribute key management >>>functions down? >> >> >>I don't know what "distribute key management functions down" means. >> >>>> >>>>>> >>>>>>>>>8. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>This design is based upon a "group controller" model >>>>>>>>>>[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group >>>>>>>>>>owner as the root-of-trust. The group owner designates a key >>>>>>>>>>distribution center for member registration and >>>>>>>>>>re-key. >>>>>>>>>As was originally envisioned, the group owner CAN (and for large >>>>>>>>>or sparse groups SHOULD) designate multiple key servers. >>>>>>>> >>>>>>>>The architecture recommends that this be done by allowing any key >>>>>>>>server to serve keys that is authorized to do so by the group >>>>>>>>owner. The most straightforward way to do this is to use SPKI or >>>>>>>>X.509 delegation. That's what we are recommending rather than >>>>>>>>coding this up in the key management protocol. >>>>>>>It is fair to say that the key server must provide proof of >>>>>>>delegation. I _believe_ SPKI (SDSI) delegation is not widely used, >>>>>>>but cannot support this. X. 509 attributes is a fair way of doing >>>>>>>this, but is only one way. Whether it is more straightforward is a >>>>>>>matter of opinion. >>>>>> >>>>>> >>>>>>Please tell me why SPKI delegation will not do this. I believe it >>>>>>can. If we need to fix something in the trust infrastructure, I >>>>>>would not build the solution into the key management protocol but fix >>>>>>the trust infrastructure. Otherwise the key management protocol will >>>>>>end up having all sorts of strange and inappropriate features that >>>>>>make it difficult to implement and impossible to test. >>>>>My typo again. SPKI delegation is not widely used but can support >>>>>this. The X.509 is available. It is a mechanism that provides some >>>>>proof of authorization. For example in GSAKMP, it can be one of the >>>>>certificates passed with the INVITATION message with the token >>>>>containing the rule for key server of "attribute certificate signed by >>>>>root x". Or alternatively, not using attribute certificates, it can >>>>>just be a key server rule that says it must have an "identity cert >>>>>signed by root y where the identity conforms to the rule name = >>>>>a.b.c.?". I don't think that this is a strange and inappropriate feature. >>>> >>>>Why put the feature in key management when it is done somewhere else? >>>> >>>Just as the details of certificates are not specified in key management >>>protocols, the details of of policy do not need to by specified >>>here. However, certificates are needed to make many of the protocols >>>secure. So, too, with policy. It may be (it is) necessary to deal with >>>policy in order to make the km protocol secure. Thus, it does need to >>>be dealt with to some extent. >>> >>>The actual form that the policy takes -- policy tokens, attribute certs, >>>whatever -- is not critical here. It is a choice of the individual >>>protocols. Saying that the architecture ASSUMES everything is obtained >>>externally is inappropriate. It does not have to be. Imposing >>>unnecessary requirements and assumptions unduly restricts protocol design. >>> >>>What is important though, is that each of the protocols is given the >>>info that it needs to operate securely. Somehow, from somewhere. >> >> >>I think I agree with this. >> >>Mark >> >>> >>> >>>--- Andrea --=====================_101134103==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Andrea
   I don't know how Thomas and Ran feel about this, but I hope you give msec the benefit of your experience by writing a security management architecture I-D for msec - if you feel it's ready for the IETF standards process.

thanks, Mark
At 01:12 PM 6/29/2001 -0400, Andrea Colegrove wrote:
Mark,
    People who have been working in security for a while do not consider "security management" to be just a buzz word.
 

--- Andrea

Mark Baugher wrote:
 Andrea,

At 11:19 AM 6/29/2001 -0400, Andrea Colegrove wrote:
Mark,
    We are not going to agree whether or not crypto policy is meta-data or not.  Fine.  My reason for pointing out that most of the requirements listed involved more than just key management was to show that you are well on your way to providing a security management internet draft.


We don't have anything called a "security management draft" on the roadmap.   If I felt as strongly about this as you do, I would commence working on the draft.  The first thing you need to do is define what it is.  But holding up a key management I-D and criticizing it for not being a security management draft, which is right now only a buzz-phrase and nothing else, is not helpful.

Here is my understanding of what consensus the WG has reached.  The WG is to do a multicast security architecture draft, a group key management architecture draft, probably two key management protocols (one for IKE and one for IPsec), a data transforms draft, and a policy draft.  The latter will then cause us to consider changes or additions that need to be made in other drafts to accommodate policy, which is the least well defined thing we are doing.
 
5.  Re:  video on demand example.   The example shows a pre-existing group of all possible members subject to pre-broadcast rekey.  One broadcast would destroy this=20 property.

What is the property that would be destroyed?  What exactly is the problem?
The example wasn't clear to me but it appeared that you were stating that the potential audience was a group and requirement 6 (rekey) supported the access control to video broadcasts.  If this is what you meant, then each time some of the members were excluded from a broadcast, a smaller potential audience resulted for the next one.


I don't understand.
I am trying to restate what I think you said and you don't understand.  Could you restate the example so that we can determine whether there is a limitation or not?  Thanks.

There is a group that can receive video on demand (VOD) content where each member contacts the VOD server to get a file or stream.  It is not a broadcast; it is on demand.  The VOD server is authorized to source Re-key messages on behalf of the GCKS.  So when the member gets the file or stream data, it can get the key to decipher the file or stream from the VOD server.
Okay.  So far I understand.  Could you please fill in the details because I don't see the rekey aspect?
The member, before requesting the video is initialized with what?
Are all members initialized to the same values?
Is the stream encrypted per-member or per-group?


Each member of the particular VOD service has gotten the group KEK as a Re-key SA.  This answers your first two questions.  The stream is encrypted with a TEK for a data security SA in this particular example; the TEK with data security SA is sent in RE-key messages to the member.  It is not per-member.  The point here is that group keys are used for unicast streams or file download.
 
 
 
 
6.
 
  
A centralized
group controller (or KDC) that is used in this architecture may not be=20
the best design for small, interactive groups.  But for large,
single-
source multicast groups, it is generally undesirable to distribute key=20
management functions among group members: Unlike small, interactive=20
groups, large single-source multicast groups generally need a=20
specialized KDC to support large numbers of group members.  Large=20
distributed simulations, moreover, may combine the need for large-grou=20
operation with many
senders.
Large groups require distributed initial key distribution!  Large dynamic groups cannot rely upon a centralized KDC.  This does not scale.  This is highly inflexible.  The VoD example demonstrates this.
"But for large,
single-
source multicast groups, it is generally undesirable to distribute key
management functions among group members"

Please support this with evidence.  Also, wouldn't it be best to just discuss the requirements and design constraints but not suggest solutions here?


DirecTV is a good example. TV conditional access systems don't allow STBs to become group controllers.  The need to support large numbers of receivers, or to quickly remove members, or to have very short latency in joining or re-keying a group are the requirements and design constraints.  We have commercial systems that optimize for a subset of these constraints and some of the others listed in Section 2.
I don't think that this is a general example.  If this were for the internet, what is wrong with saying address a.b.c.d or a.b.c.e or a.b.c.f can serve you?  (Any key server that "sees" unencrypted keys is by default a member.)

I'm sorry you don't like my example.
Once again this isn't the point.  There are examples in which it may be specifically inadvisable to distribute key management functions down, but why is it GENERALLY inadvisable to distribute key management functions down?


I don't know what "distribute key management functions down" means.
 
 
 
8.
 
  
This design is based upon a "group controller" model=20
[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group=20
owner as the root-of-trust.  The group owner designates a key=20
distribution center for member registration and
re-key.
As was originally envisioned, the group owner CAN (and for large or sparse groups SHOULD) designate multiple key servers.

The architecture recommends that this be done by allowing any key server to serve keys that is authorized to do so by the group owner.  The most straightforward way to do this is to use SPKI or X.509 delegation.  That's what we are recommending rather than coding this up in the key management protocol.
It is fair to say that the key server must provide proof of delegation.  I _believe_ SPKI (SDSI) delegation is not widely used, but cannot support this.  X. 509 attributes is a fair way of doing this, but is only one way.  Whether it is more straightforward is a matter of opinion.


Please tell me why SPKI delegation will not do this.  I believe it can.  If we need to fix something in the trust infrastructure, I would not build the solution into the key management protocol but fix the trust infrastructure.  Otherwise the key management protocol will end up having all sorts of strange and inappropriate features that make it difficult to implement and impossible to test.
My typo again.  SPKI delegation is not widely used but can support this.  The X.509 is available.  It is a mechanism that provides some proof of authorization.  For example in GSAKMP, it can be one of the certificates passed with the INVITATION message with the token containing the rule for key server of "attribute certificate signed by root x".  Or alternatively, not using attribute certificates, it can just be a key server rule that says it must have an "identity cert signed by root y where the identity conforms to the rule name =3D a.b.c.?".  I don't think that this is a strange and inappropriate feature.

Why put the feature in key management when it is done somewhere else?
 
Just as the details of certificates are not specified in key management protocols, the details of of policy do not need to by specified here.  However, certificates are needed to make many of the protocols secure.  So, too, with policy.  It may be (it is) necessary to deal with policy in order to make the km protocol secure.  Thus, it does need to be dealt with to some extent.

The actual form that the policy takes -- policy tokens, attribute certs, whatever -- is not critical here.  It is a choice of the individual protocols.  Saying that the architecture ASSUMES everything is obtained externally is inappropriate. It does not have to be.  Imposing unnecessary requirements and assumptions unduly restricts protocol design.

What is important though, is that each of the protocols is given the info that it needs to operate securely.  Somehow, from somewhere.


I think I agree with this.

Mark
 
 

--- Andrea
--=====================_101134103==_.ALT-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 29 13:48:34 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20697 for ; Fri, 29 Jun 2001 13:48:32 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9DCF453554; Fri, 29 Jun 2001 13:48: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 8AD8F53530 for ; Fri, 29 Jun 2001 13:47:31 -0400 (EDT) Received: (qmail 85256 invoked by uid 3269); 29 Jun 2001 17:47:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 85252 invoked from network); 29 Jun 2001 17:47:30 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 29 Jun 2001 17:47:30 -0000 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5THkwh22922; Fri, 29 Jun 2001 10:46:59 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f5THks618675; Fri, 29 Jun 2001 10:46:55 -0700 (PDT) Received: from cisco.com (IDENT:bew@dhcp-128-107-143-60.cisco.com [128.107.143.60]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id KAA27501; Fri, 29 Jun 2001 10:46:52 -0700 (PDT) Message-ID: <3B3CBF0C.363847A4@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: Ran Canetti Cc: msec@securemulticast.org, thardjono@mediaone.net Subject: Re: [MSEC] De-registration protocol? References: <200106291526.LAA32906@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: Fri, 29 Jun 2001 10:46:52 -0700 Content-Transfer-Encoding: 7bit Hi Ran, Ran Canetti wrote: > > Thomas, > > I agree with you that in most cases de-registration is not necessary, > since a member joins for a predetermined amount of time. But there is > certainly an added value to the ability to not have to keep paying for > each additional minute/round/episode/whatever - but rather decide to leave > when you want. The question is whether we want to totally exclude the > possibility of doing this using msec? As you've pointed out, a de-registration protocol may make sense in some cases, but it does seem to be a limited set of cases (i.e., as Thomas pointed out, not in the current multicast uage models). Rather than specifying it now, the arch. doc could mention it as a possible protocol but not leave the specification of it until a later work. > Note that the de-registration protocol will be optional. we may also > make it optional to implement. so the complexity hit on systems that do not > support it will be minimal. > > In any case, as Andrea and Sandro said, in case that we decide that > de-registration is necessary, it definitely should be handled by msec. > (ie, the application will make a de-registration request which msec will > carry out.) As Sando pointed out, there is an issue with pruning LKH trees. But this is an issue that should be addressed (in some forum, not necessarily the arch. document) regardless of whether there is a de-registration protocol since the GCKS can't be guaranteed to know when members leave the group (or simply stop listening without leaving the group). > Regarding the "how", this indeed has to be dealt with. I tend to think > that setting up a new "de-registration SA" is the better/more flexible > way to go (in spite of the added overhead) but I'm open to arguments... > user authentiation and non-repudiation are indeed important concerns here. I'm concerned about MSEC biting off yet another protocol at this point in time -- we've got a number of specifications to resolve as it is. As you point out, there are non-trivial concern on how to specify the de-registration protocol. Brian > > Ran > > > From thardjono@mediaone.net Fri Jun 29 08:46:25 2001 > > > > > > Ran, > > > > Here are some comments on the notion of de-registration > > in the context of the key management work in MSEC. > > Please do read them (and possibly respond). > > > > > > At 6/28/2001||03:48 PM, you 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. > > > > Most of the applications I have come across want to make use > > of single-source multicast to deliver content in a Pay-Per-View > > model where the unit of content or time is pre-programmed in advance > > by the content provider. > > > > Thus, in this common model, the content provider leaves it up to the > > user/customer to decide the unit of content to buy and to purchase > > additional units when needed. Thus the burden is on the user. > > > > Citing the CableTV example, from a revenue perspective the content provider > > would like the user to pay for an entire unit of content (eg. whole movie) > > even when the user does not consume all of it. We've all had the > > experience buying a lousy movie in a hotel :) > > > > > > > > >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). > > > > The example you quote seems contradictory. If a user is unsure about > > the number of rounds he needs to watch (to complete the entire match), > > the he/she can buy the programme one-round-at-a-time. > > > > If the user fails to pay for the next round of programme, then the user > > is left out. It matters little (to the system) if the user says good-by > > before the completion of the match or of the paid unit. > > > > If anything, it is the other way around: the system reminds the user > > that the user only has X minutes left before the unit of content is over, > > and for the user to pay some more. > > > > > > > > >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.) > > > > Again, this depends on the application model (ie. system-initiated or > > user-initiated membership-termination). > > > > I don't think it is a mistake to leave it to the application. > > In fact, it makes more sense to let the application-area decide which > > model to follow (system-initiated or user-initiated). > > > > In the specific case of MSEC key management, requiring the member > > to specifically de-register has the following implications: > > > > - How is the member going to de-register (ie. what mechanisms): > > > > If the member has to send a de-register message through the Cat-1 SA, > > then that Cat-1 SA has to be around as long as the member is registered. > > Now, this is an unresolved issue: > > > > Do we keep a Cat-1 SA around just so that the member can send > > one message (de-register) to the GCKS? > > This causes a lot of state to have to be maintained at the GCKS. > > > > Do we let the initial Cat-1 SA die, and establish a new Cat-1 SA > > just for the member to send one message (de-register)? > > This is a lot of negotiations and cycles just for one message. > > > > > > - Authentication of de-register message: > > > > Clearly this de-register message has to be source-authentic, otherwise > > any member can de-register other members. > > > > This points to the need of the members to have certificates (which > > they do anyway, in order to register in the first place, both > > in GSAKMP and GDOI). > > > > Since we assume that the Application triggered the initial Register > > message (digitally signed), then it make it makes sense to let > > the Application decide (and send) the final de-register message (with > > a digital signature). > > > > > > - Reliability: > > > > In SMuG and MSEC we all concluded that reliability of key management > > messages should not have to be dealt by the key-management-protocol. > > > > Now, if you insist that the de-register message must be part of > > the key management protocol, then you also must provide it > > with reliability. > > > > Simply saying that "some layer above" will provide it with reliability > > is really insufficient (circular argument). > > > > However, it makes sense to say that the Application (or a transport-layer > > mechanism) will provide/assume reliability. Which, again, points > > to appropriateness of the de-register message at the Application layer. > > > > > > thomas > > ------ > > > > > > > > > > _______________________________________________ > 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 Fri Jun 29 15:03:56 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23166 for ; Fri, 29 Jun 2001 15:03:54 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0AF565356C; Fri, 29 Jun 2001 15:04: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 2751653577 for ; Fri, 29 Jun 2001 15:02:14 -0400 (EDT) Received: (qmail 91836 invoked by uid 3269); 29 Jun 2001 19:02:13 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 91833 invoked from network); 29 Jun 2001 19:02:13 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by klesh.pair.com with SMTP; 29 Jun 2001 19:02:13 -0000 Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f5TIxgH05105 for ; Fri, 29 Jun 2001 12:00:03 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f5TJ1AF23691 for ; Fri, 29 Jun 2001 12:01:11 -0700 (PDT) Received: from cisco.com (IDENT:bew@dhcp-128-107-143-60.cisco.com [128.107.143.60]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id MAA01852 for ; Fri, 29 Jun 2001 12:01:02 -0700 (PDT) Message-ID: <3B3CD06D.48827BDD@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: msec@securemulticast.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [MSEC] Comments on draft-ietf-msec-gkmarch-00.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: Fri, 29 Jun 2001 12:01:01 -0700 Content-Transfer-Encoding: 7bit Here are a couple of minor comments on this draft which suggest some rewording. 1. From section 3.2: > The KDC presents a credential to the Group member that is > signed by the Group Owner so the member can check the KDC's > authorization. This statement is too strong -- a system might do authorization via a means other than a credential (e.g., ACL). It should say "may present a credential". 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. b. This should also state the obvious, which is the Re-key message is optional because rekey may be necessary in some scenarios. 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." 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 From msec-admin@securemulticast.org Fri Jun 29 15:27:53 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23763 for ; Fri, 29 Jun 2001 15:27:52 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 671F653575; Fri, 29 Jun 2001 15:28: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 19D2253575 for ; Fri, 29 Jun 2001 15:26:05 -0400 (EDT) Received: (qmail 93979 invoked by uid 3269); 29 Jun 2001 19:26:04 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 93976 invoked from network); 29 Jun 2001 19:26:04 -0000 Received: from chmls20.mediaone.net (24.147.1.156) by klesh.pair.com with SMTP; 29 Jun 2001 19:26:04 -0000 Received: from THARDJONO-LAP.mediaone.net ([63.90.80.227]) by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id f5TJQ3610267; Fri, 29 Jun 2001 15:26:03 -0400 (EDT) Message-Id: <5.0.0.25.2.20010629151138.01876600@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: canetti@watson.ibm.com, msec@securemulticast.org From: Thomas Hardjono Subject: Re: [MSEC] De-registration protocol? Cc: bew@cisco.com In-Reply-To: <200106291526.LAA32906@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, 29 Jun 2001 15:25:22 -0400 At 6/29/2001||11:26 AM, Ran Canetti wrote: >Regarding the "how", this indeed has to be dealt with. I tend to think >that setting up a new "de-registration SA" is the better/more flexible >way to go (in spite of the added overhead) but I'm open to arguments... >user authentiation and non-repudiation are indeed important concerns here. > >Ran > Ran, Both Laksminath and myself thought of this problem some time ago. We can introduce a De-registration-KEK that is delivered initially in the Registration/Initialization stage. The unique KEK is then used to hash (or encrypt) the Deregister-message. Since only the GCKS and the member know that Deregister-KEK, then the GCKS can be assured of its source-authenticity. The issue is when there is 100 members sharing a symmetric KEK key, it brings about the Many-to-1 SA management problem. That is, the GCKS must know from which member the Deregister-command came. It can hold 100 SAs specially for Deregistrations, or it can maintain just one (1) SA for the whole 100 members. If we want to use digital-signatures, then perhaps its better to do it at the Apps layer. As Brian mentions, we are still coming to terms with the Registration/Initialization protocol and the Key-update protocol. So introducing another protocol may just confuses things. Better to crawl first. thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 29 15:51:02 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24297 for ; Fri, 29 Jun 2001 15:51:01 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 46E195354E; Fri, 29 Jun 2001 15:50: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 F29175352A for ; Fri, 29 Jun 2001 15:49:44 -0400 (EDT) Received: (qmail 95612 invoked by uid 3269); 29 Jun 2001 19:49:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 95609 invoked from network); 29 Jun 2001 19:49:44 -0000 Received: from chmls06.mediaone.net (24.147.1.144) by klesh.pair.com with SMTP; 29 Jun 2001 19:49:44 -0000 Received: from THARDJONO-LAP.mediaone.net ([63.90.80.227]) by chmls06.mediaone.net (8.11.1/8.11.1) with ESMTP id f5TJnf807245; Fri, 29 Jun 2001 15:49:41 -0400 (EDT) Message-Id: <5.0.0.25.2.20010629153820.02496260@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: Mark Baugher From: Thomas Hardjono Subject: Re: Optionality of Re-Key "protocol" --- Re: [MSEC] The new GKM architecture draft Cc: msec@securemulticast.org In-Reply-To: <4.3.2.7.2.20010629084644.04283ce0@mira-sjc5-6.cisco.com> References: <5.0.0.25.2.20010629111415.018761a0@pop.ne.mediaone.net> <200106281911.PAA32920@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, 29 Jun 2001 15:48:39 -0400 Mark, At 6/29/2001||09:05 AM, Mark Baugher wrote: >Yes, there's no need for a Cat-2 SA (Re-key SA) if there is to be >no Re-key operations for the group. The SHOULD refers to the case >when Re-key operations are used for the group. There is no implosion >problem to avoid if the group has only a few members. So the >Registration protocol has the option of delivering TEKs (Data Security >SAs) but no KEK (Re-key SA). SSL or IPsec still won't work even >when there is no Re-key operation since the TEK needs to be >common to a group. OK, I'll accept this argument. >>My May posting (http://www.pairlist.net/pipermail/msec/2001-May/000123.html) >>was not meant to be an exercise in essay-writing, but to remind >>people that we are trying to stay with one model. > >I agree with that. I believe the motivation for the architecture is to >define what that model is rather than having two or three specifications >define their own models. I guess it won't be painless, either. >If the model allows the Re-key operation to not be used when it is >not needed (sounds reasonable, doesn't it), then this is an option >within a single model. > > >>I think the whole concept of "Registration" is incorrect, and that >>it is an Application-layer function. That is, a user is able to register >>to a website and download suitable parameters (and even code/puggins) >>to join the group. The user's Application then uses the parameters >>to join the group. > >Registration is the same as the GROUPKEY-PULL of GDOI, although >changes will be needed in the latter to conform to the former. >When you say "register at a website," this sounds vague to me. >Are you doing everything over http, ssl, or does the website run the >registration protocol? Key management is usually an application-layer >function. I really don't understand your point here. When I used the term "Registration" in our discussions last year, it was for a process/protocol that was outside GDOI. Meaning that a user would need to "Register" his/her name (say to a website), pay and dowload pluggings/policy-info/etc. Ran insisted on using IPsec tunnels instead of modified-IKE-phase-2, and started talking about a separate "registration" protocol to achieve his end. OK, I accept the mix-and-match argument (ie. using differing protocols at diferent layers) to achieve Cat-1 and Cat-2. However, I think when it comes to implementations, the two will be so closely linked that in reality we cannot easily mix-and-match. To get back to my point, perhaps calling it an "Initialization" protocol would be better since we are in fact initializing all the members. thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 29 16:44:32 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24969 for ; Fri, 29 Jun 2001 16:44:31 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B598153558; Fri, 29 Jun 2001 16:44:14 -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 D2DFC53534 for ; Fri, 29 Jun 2001 16:43:49 -0400 (EDT) Received: (qmail 1410 invoked by uid 3269); 29 Jun 2001 20:43:49 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 1404 invoked from network); 29 Jun 2001 20:43:49 -0000 Received: from news.comp.lancs.ac.uk (148.88.152.70) by klesh.pair.com with SMTP; 29 Jun 2001 20:43:49 -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 f5TKhf002300 for ; Fri, 29 Jun 2001 21:43:41 +0100 (BST) From: "Sandro Rafaeli" To: Subject: RE: [MSEC] I-D ACTION:draft-ietf-msec-gkmarch-00.txt Message-ID: <000801c100dc$1e619000$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: <200106271103.HAA26170@ietf.org> 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: Fri, 29 Jun 2001 21:43:13 +0100 Content-Transfer-Encoding: 7bit I'd like to make some comments on the gkmarch I-D: -- requirement 6 states: "It must be possible to provide re-key for the group without requiring unicast exchange between a key distribution center (KDC) and individual members, which would overwhelm a KDC when the group is large." It sounds to me as if unicast messages during rekey must be avoided at all costs!! Several HBT protocols employ a unicast message to update single members during join operations. This is later noted in section 3.1 ((2) Re-key protocol): "The Re-key messages can be sent multicast to group members or unicast from the KDC to a particular group member.". -- page 7 second paragraph "The Re-key protocol SHOULD ensure that all members receive the re-key information in a timely manner....": I undestand that the key management protocol does not have to provide reliability itself, so I think that this phrase is erroneous. Wouldn't it be more correct to say: "The Re-key protocol SHOULD be run over a reliable transport protocol to ensure that all members receive the re-key..."? -- page 7 "o If the KDC uses Re-key messages, then the admitted member receives the Group KEK; if it uses a membership management algorithm, then the member receives a set of KEKs according to the particular algorithm." I am not familiar with MSEC's terminology, but I understand that membership management algorithms also use "Rekey messages" to rekey members. In this paragraph, the term "re-key messages" gave me the impression that those messages only convey a single Group KEK. In addition, the acronym GCKS was never defined in that document! I founf the definition in the GDOI draft :) Regards, Sandro. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 29 16:57:12 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25102 for ; Fri, 29 Jun 2001 16:57:10 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 5C80153566; Fri, 29 Jun 2001 16:56:56 -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 F338E53566 for ; Fri, 29 Jun 2001 16:55:03 -0400 (EDT) Received: (qmail 2346 invoked by uid 3269); 29 Jun 2001 20:55:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 2342 invoked from network); 29 Jun 2001 20:55:03 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by klesh.pair.com with SMTP; 29 Jun 2001 20:55:03 -0000 Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f5TKSUH16990; Fri, 29 Jun 2001 13:51:35 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f5TKUBw10851; Fri, 29 Jun 2001 13:30:11 -0700 (PDT) Received: from cisco.com (IDENT:bew@dhcp-128-107-143-60.cisco.com [128.107.143.60]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id NAA04680; Fri, 29 Jun 2001 13:30:04 -0700 (PDT) Message-ID: <3B3CE54B.A733293E@cisco.com> From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Hardjono Cc: Mark Baugher , msec@securemulticast.org Subject: Re: Optionality of Re-Key "protocol" --- Re: [MSEC] The newGKM architecture draft References: <5.0.0.25.2.20010629111415.018761a0@pop.ne.mediaone.net> <200106281911.PAA32920@ornavella.watson.ibm.com> <5.0.0.25.2.20010629153820.02496260@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: Fri, 29 Jun 2001 13:30:03 -0700 Content-Transfer-Encoding: 7bit There are some benefits and problems to the mix-and-match protocol approach. It's a nice property that different Registration protocols could be used in a large group (perhaps based on receiver capabilities or network topology), but they could all be pushed the KEK and KEK policy for a single Re-Key message. However, as Thomas points out below, that does increase the complexity of any system which implements just one registration protocol and a Re-key message. For simplicity they'd want the protocol formatting of the two to be similar, and also the policy & key representation to be similar. That's not likely to happen with protocols which are derived independently. I'm just wondering we'll ultimately end up with a Re-key protocol per Registration protocol. Brian Thomas Hardjono wrote: > > OK, I accept the mix-and-match argument (ie. using differing > protocols at diferent layers) to achieve Cat-1 and Cat-2. > However, I think when it comes to implementations, the two will > be so closely linked that in reality we cannot easily mix-and-match. > > To get back to my point, perhaps calling it an "Initialization" > protocol would be better since we are in fact initializing > all the members. > > thomas > ------ > > _______________________________________________ > 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 Fri Jun 29 17:12:45 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25395 for ; Fri, 29 Jun 2001 17:12:44 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 5E9435354E; Fri, 29 Jun 2001 17:12: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 D1DFB5355E for ; Fri, 29 Jun 2001 17:11:25 -0400 (EDT) Received: (qmail 4860 invoked by uid 3269); 29 Jun 2001 21:11:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 4857 invoked from network); 29 Jun 2001 21:11:25 -0000 Received: from chmls20.mediaone.net (24.147.1.156) by klesh.pair.com with SMTP; 29 Jun 2001 21:11:25 -0000 Received: from THARDJONO-LAP.mediaone.net ([63.90.80.227]) by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id f5TLBI605306; Fri, 29 Jun 2001 17:11:18 -0400 (EDT) Message-Id: <5.0.0.25.2.20010629170355.01876fc0@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: Brian Weis , msec@securemulticast.org From: Thomas Hardjono Subject: Re: Optionality of Re-Key "protocol" --- Re: [MSEC] The newGKM architecture draft In-Reply-To: <3B3CE54B.A733293E@cisco.com> References: <5.0.0.25.2.20010629111415.018761a0@pop.ne.mediaone.net> <200106281911.PAA32920@ornavella.watson.ibm.com> <5.0.0.25.2.20010629153820.02496260@pop.ne.mediaone.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 29 Jun 2001 17:10:17 -0400 Brian, At 6/29/2001||01:30 PM, Brian Weis wrote: >I'm just wondering we'll ultimately end up with a Re-key protocol per >Registration protocol. > >Brian Yes, actually this is what I'm rather concerned about. But perhaps we can just wait and see. thomas ------ >Thomas Hardjono wrote: > > > > OK, I accept the mix-and-match argument (ie. using differing > > protocols at diferent layers) to achieve Cat-1 and Cat-2. > > However, I think when it comes to implementations, the two will > > be so closely linked that in reality we cannot easily mix-and-match. > > > > To get back to my point, perhaps calling it an "Initialization" > > protocol would be better since we are in fact initializing > > all the members. > > > > thomas > > ------ > > > > _______________________________________________ > > 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 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 29 17:14:45 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25427 for ; Fri, 29 Jun 2001 17:14:44 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 666B753555; Fri, 29 Jun 2001 17:14: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 AF3CD53539 for ; Fri, 29 Jun 2001 17:12:42 -0400 (EDT) Received: (qmail 4931 invoked by uid 3269); 29 Jun 2001 21:12:42 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 4928 invoked from network); 29 Jun 2001 21:12:42 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157) by klesh.pair.com with SMTP; 29 Jun 2001 21:12:42 -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 f5TLBm010645 for ; Fri, 29 Jun 2001 17:11:50 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Fri, 29 Jun 2001 17:11:38 -0400 Received: from zbl6c016.corpeast.baynetworks.com ([132.245.205.66]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N43SNGDV; Fri, 29 Jun 2001 17:11:38 -0400 Received: from nortelnetworks.com (arc.engeast.baynetworks.com [192.32.137.28]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KBYWGW6L; Fri, 29 Jun 2001 17:11:38 -0400 Message-ID: <3B3CF027.6671B4D6@nortelnetworks.com> From: "Lakshminath Dondeti" X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Sandro Rafaeli Cc: msec , "Lakshminath Dondeti" Subject: Re: [MSEC] I-D ACTION:draft-ietf-msec-gkmarch-00.txt References: <000801c100dc$1e619000$09f55894@lancs.ac.uk> 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: Fri, 29 Jun 2001 17:16:23 -0400 Content-Transfer-Encoding: 7bit Hi, Thanks for your comments. Please see inline: Sandro Rafaeli wrote: > > I'd like to make some comments on the gkmarch I-D: > > -- requirement 6 states: > "It must be possible to provide re-key for the group without > requiring unicast exchange between a key distribution center (KDC) > and individual members, which would overwhelm a KDC when the group > is large." > > It sounds to me as if unicast messages during rekey must be avoided at all > costs!! Several HBT protocols employ a unicast message to update single > members during join operations. This is later noted in section 3.1 ((2) > Re-key protocol): "The Re-key messages can be sent multicast to group > members or unicast from the KDC to a particular group member.". > -- page 7 second paragraph "The Re-key protocol SHOULD ensure that all > members receive the re-key information in a timely manner....": > > I undestand that the key management protocol does not have to provide > reliability itself, so I think that this phrase is erroneous. Wouldn't it be > more correct to say: "The Re-key protocol SHOULD be run over a reliable > transport protocol to ensure that all members receive the re-key..."? In fact, it should be possible to do both, i.e., sending rekey messages over a reliable channel or use FEC or other techniques for built in reliability. > > -- page 7 "o If the KDC uses Re-key messages, then the admitted member > receives the Group KEK; if it uses a membership management algorithm, then > the member receives a set of KEKs according to the particular algorithm." > > I am not familiar with MSEC's terminology, but I understand that membership > management algorithms also use "Rekey messages" to rekey members. In this > paragraph, the term "re-key messages" gave me the impression that those > messages only convey a single Group KEK. We will rewrite this! > > In addition, the acronym GCKS was never defined in that document! I founf > the definition in the GDOI draft :) We tried hard to avoid the word GCKS and instead use KDC. You found the only occurrence :) Thanks again. regards, Lakshminath > > 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 Fri Jun 29 17:17:52 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25470 for ; Fri, 29 Jun 2001 17:17:51 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A228753549; Fri, 29 Jun 2001 17:18: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 CF4B35354A for ; Fri, 29 Jun 2001 17:16:25 -0400 (EDT) Received: (qmail 5387 invoked by uid 3269); 29 Jun 2001 21:16:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 5383 invoked from network); 29 Jun 2001 21:16:25 -0000 Received: from chmls05.mediaone.net (24.147.1.143) by klesh.pair.com with SMTP; 29 Jun 2001 21:16:25 -0000 Received: from THARDJONO-LAP.mediaone.net ([63.90.80.227]) by chmls05.mediaone.net (8.11.1/8.11.1) with ESMTP id f5TLGLx01300; Fri, 29 Jun 2001 17:16:21 -0400 (EDT) Message-Id: <5.0.0.25.2.20010629171058.018773b0@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] I-D ACTION:draft-ietf-msec-gkmarch-00.txt In-Reply-To: <000801c100dc$1e619000$09f55894@lancs.ac.uk> References: <200106271103.HAA26170@ietf.org> 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, 29 Jun 2001 17:15:19 -0400 Sandro, At 6/29/2001||09:43 PM, Sandro Rafaeli wrote: >In addition, the acronym GCKS was never defined in that document! I founf >the definition in the GDOI draft :) > >Regards, >Sandro. There is some history to the term GCKS. The initial SMuG Reference Framework distinguished between a Group-Owner/Controller and the Key-Server, since it was thought that the Content Distributor or Content Provider would "legally own" the Class D address. Due to some comments from a "prominent" person in the IETF, we merged the two boxes into one and called it GCKS. Unfortunately, that prominent person never showed-up again at SMuG :) thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 29 18:14:15 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26260 for ; Fri, 29 Jun 2001 18:14:14 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 638635356F; Fri, 29 Jun 2001 18:14: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 87B5953540 for ; Fri, 29 Jun 2001 18:12:47 -0400 (EDT) Received: (qmail 10057 invoked by uid 3269); 29 Jun 2001 22:12:47 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10054 invoked from network); 29 Jun 2001 22:12:46 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by klesh.pair.com with SMTP; 29 Jun 2001 22:12:46 -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 f5TMCNr13909; Fri, 29 Jun 2001 15:12:23 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-350.cisco.com [10.21.65.94]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADH21381; Fri, 29 Jun 2001 15:12:15 -0700 (PDT) Message-Id: <4.3.2.7.2.20010629145559.02049e70@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] I-D ACTION:draft-ietf-msec-gkmarch-00.txt Cc: In-Reply-To: <000801c100dc$1e619000$09f55894@lancs.ac.uk> References: <200106271103.HAA26170@ietf.org> 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, 29 Jun 2001 15:11:45 -0700 Hi At 09:43 PM 6/29/2001 +0100, Sandro Rafaeli wrote: >I'd like to make some comments on the gkmarch I-D: > >-- requirement 6 states: > "It must be possible to provide re-key for the group without > requiring unicast exchange between a key distribution center (KDC) > and individual members, which would overwhelm a KDC when the group > is large." > >It sounds to me as if unicast messages during rekey must be avoided at all >costs!! Several HBT protocols employ a unicast message to update single >members during join operations. This is later noted in section 3.1 ((2) >Re-key protocol): "The Re-key messages can be sent multicast to group >members or unicast from the KDC to a particular group member.". The requirement is for "unicast exchange" not "unicast message," as you implied in the first sentence of the paragraph above. A unicast message can be sent with or without public-key or Diffie-Hellman operations on the KDC (GCKS in IRTF SMuG terminology - maybe we should stick to GCKS but it does sound odd to me). A unicast exchange in the context of the I-D is a Registration protocol exchange, which establishes an IKE Phase 1, IPsec, or SSL connection. >-- page 7 second paragraph "The Re-key protocol SHOULD ensure that all >members receive the re-key information in a timely manner....": > >I undestand that the key management protocol does not have to provide >reliability itself, so I think that this phrase is erroneous. Wouldn't it be >more correct to say: "The Re-key protocol SHOULD be run over a reliable >transport protocol to ensure that all members receive the re-key..."? Good point. We've been discussing this for years in IRTF SMuG. The I-D recommends "packet-level FEC," which is our way of saying "send the message periodically over some interval of time." >-- page 7 "o If the KDC uses Re-key messages, then the admitted member >receives the Group KEK; if it uses a membership management algorithm, then >the member receives a set of KEKs according to the particular algorithm." > >I am not familiar with MSEC's terminology, but I understand that membership >management algorithms also use "Rekey messages" to rekey members. In this Membership management algorithms leave rekey messages as an exercise to the reader. GSAKMP did an encoding. GDOI did an encoding not much different from GSAKMP's. If this working group decides to proceed with a separate specification for re-key, then we will get the canonical encoding for msec. >paragraph, the term "re-key messages" gave me the impression that those >messages only convey a single Group KEK. No, Section 4 defines it otherwise: See 4.0 "Case 2." >In addition, the acronym GCKS was never defined in that document! I founf >the definition in the GDOI draft :) I discussed this problem with the I-D in the first paragraph of my note. There is one place where "GCKS" is used in the I-D and this is a type. I don't care what we call it though I notice that many people often don't readily recognize it for what it is. Mark >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 Fri Jun 29 18:31:29 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26560 for ; Fri, 29 Jun 2001 18:31:28 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C7F5953575; Fri, 29 Jun 2001 18:31: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 959D853540 for ; Fri, 29 Jun 2001 18:27:53 -0400 (EDT) Received: (qmail 10963 invoked by uid 3269); 29 Jun 2001 22:27:53 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10960 invoked from network); 29 Jun 2001 22:27:53 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 29 Jun 2001 22:27:53 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5TMRLh11921; Fri, 29 Jun 2001 15:27:22 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-350.cisco.com [10.21.65.94]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADH21779; Fri, 29 Jun 2001 15:27:19 -0700 (PDT) Message-Id: <4.3.2.7.2.20010629152514.042333a0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Brian Weis From: Mark Baugher Subject: Re: Optionality of Re-Key "protocol" --- Re: [MSEC] The newGKM architecture draft Cc: msec@securemulticast.org In-Reply-To: <3B3CE54B.A733293E@cisco.com> References: <5.0.0.25.2.20010629111415.018761a0@pop.ne.mediaone.net> <200106281911.PAA32920@ornavella.watson.ibm.com> <5.0.0.25.2.20010629153820.02496260@pop.ne.mediaone.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 29 Jun 2001 15:26:50 -0700 At 01:30 PM 6/29/2001 -0700, Brian Weis wrote: >There are some benefits and problems to the mix-and-match protocol >approach. It's a nice property that different Registration protocols >could be used in a large group (perhaps based on receiver capabilities >or network topology), but they could all be pushed the KEK and KEK >policy for a single Re-Key message. > >However, as Thomas points out below, that does increase the complexity >of any system which implements just one registration protocol and a >Re-key message. For simplicity they'd want the protocol formatting of >the two to be similar, and also the policy & key representation to be >similar. That's not likely to happen with protocols which are derived >independently. > >I'm just wondering we'll ultimately end up with a Re-key protocol per >Registration protocol. That's what we have today with GDOI and GSAKMP. GDOI uses an IKE Phase 1 for protecting the Registration protocol exchange (which is an IKE Phase 2 in GDOI). GSAKMP does not use an IKE Phase 2. cheers, Mark >Brian > >Thomas Hardjono wrote: > > > > OK, I accept the mix-and-match argument (ie. using differing > > protocols at diferent layers) to achieve Cat-1 and Cat-2. > > However, I think when it comes to implementations, the two will > > be so closely linked that in reality we cannot easily mix-and-match. > > > > To get back to my point, perhaps calling it an "Initialization" > > protocol would be better since we are in fact initializing > > all the members. > > > > thomas > > ------ > > > > _______________________________________________ > > 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 Fri Jun 29 19:18:55 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27078 for ; Fri, 29 Jun 2001 19:18:54 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 924A453582; Fri, 29 Jun 2001 19:19: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 E32045356F for ; Fri, 29 Jun 2001 19:16:59 -0400 (EDT) Received: (qmail 18055 invoked by uid 3269); 29 Jun 2001 23:16:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 18052 invoked from network); 29 Jun 2001 23:16:59 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 29 Jun 2001 23:16:59 -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 f5TNGSh09893; Fri, 29 Jun 2001 16:16:28 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-350.cisco.com [10.21.65.94]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADI00677; Fri, 29 Jun 2001 16:16:27 -0700 (PDT) Message-Id: <4.3.2.7.2.20010629155622.04274f38@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: <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: Fri, 29 Jun 2001 16:15:57 -0700 Ran Why wouldn't the service operator use a secure electronic transaction protocol? A group key management protocol operation would only be meaningful if it was a rekey-me-out-of-this-group operation. I don't know why a member would not just delete its keys and leave the group that way. This is how we want them to do it for large-scale source-specific multicast applications, isn't it? If the member's group key management performs a rekey-me-out-of-this-group, it does not mean that the member has destroyed the keys. It does not mean that the member is not continuing to use the keys. It is just a notification from the member to the KDC that the KDC can re-key the member out of the group. The KDC might then run LKH or some other membership management algorithm over Re-key messages to change everyone's key except the member that sent the rekey-me-out-of-this-group request to the KDC. That's the only way to remove access to key material (e.g. future TEKs) encrypted in the group KEK. There is no way to remove access to data security TEKs that were disseminated prior to the rekey-me-out-of-this-group request. De-registration protocol has questionable use as a a mechanism to trigger an LKH message removing the member from the group. A key-management protocol is not needed to do this, in my experience, an application-programming interface to the KDC can allow an ecommerce/authorization application to do this. If some vendors ask for this, I think we should revisit the idea of doing a deregistration/rekey-me-out-of-this-group protocol message. Otherwise, msec key management has enough on its plate: Simple systems are more secure than complex ones. Best Regards, Mark At 03:48 PM 6/28/2001 -0400, 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 Fri Jun 29 19:27:54 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27256 for ; Fri, 29 Jun 2001 19:27:53 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2D8355356F; Fri, 29 Jun 2001 19:28:04 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 9D2E553556 for ; Fri, 29 Jun 2001 19:26:32 -0400 (EDT) Received: (qmail 18603 invoked by uid 3269); 29 Jun 2001 23:26:32 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 18600 invoked from network); 29 Jun 2001 23:26:31 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 29 Jun 2001 23:26:31 -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 f5TNQ1h14292; Fri, 29 Jun 2001 16:26:01 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-350.cisco.com [10.21.65.94]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADI00899; Fri, 29 Jun 2001 16:26:00 -0700 (PDT) Message-Id: <4.3.2.7.2.20010629162159.04298ef8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Brian Weis From: Mark Baugher Subject: Re: [MSEC] Comments on draft-ietf-msec-gkmarch-00.txt Cc: msec@securemulticast.org In-Reply-To: <3B3CD06D.48827BDD@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 29 Jun 2001 16:25:30 -0700 Thanks, Brian. See my comments below. At 12:01 PM 6/29/2001 -0700, Brian Weis wrote: >Here are a couple of minor comments on this draft which suggest some >rewording. > >1. From section 3.2: > > The KDC presents a credential to the Group member that is > > signed by the Group Owner so the member can check the KDC's > > authorization. > >This statement is too strong -- a system might do authorization via a >means other than a credential (e.g., ACL). It should say "may present a >credential". I agree. >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. >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? 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 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sat Jun 30 00:27:54 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA03784 for ; Sat, 30 Jun 2001 00:27:53 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 13CA053576; Sat, 30 Jun 2001 00:28:04 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id CC71653560 for ; Sat, 30 Jun 2001 00:26:01 -0400 (EDT) Received: (qmail 49450 invoked by uid 3269); 30 Jun 2001 04:26:01 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 49447 invoked from network); 30 Jun 2001 04:26:01 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 30 Jun 2001 04:26:01 -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 f5U4PI813424; Sat, 30 Jun 2001 00:25:18 -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 AAA03494; Sat, 30 Jun 2001 00:25:18 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id AAA34010; Sat, 30 Jun 2001 00:25:18 -0400 From: Ran Canetti Message-Id: <200106300425.AAA34010@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: Sat, 30 Jun 2001 00:25:18 -0400 Mark, The purpose of the de-registration protocol is to allow a member to notify the GCKS that he is no longer interested in being a member. This would be important in the scenarios i described where members dont know in advance whn they'll leave and pay relative to membership time. if a de-registration functionality is necessary then it should be done within msec, just like the registration, since it has security implication on the group. this is because the de-registration would typically involve updating databases that are under msec control (such as LKH/OFT). That said, I agree with you and Brian that we can leave the detailed specification and implementation of the de-registration protocol to a later time (unless people feel that it is important to specify it at this time). Still, I would add language to the GKM architecture document regarding the role of this protocol. Ran The question is what functionality we want msec to provide. if we want msec to support groups where > From mbaugher@cisco.com Fri Jun 29 19:17:05 2001 > > Ran > Why wouldn't the service operator use a secure electronic transaction > protocol? A group key management protocol operation would only > be meaningful if it was a rekey-me-out-of-this-group operation. I > don't know why a member would not just delete its keys and > leave the group that way. This is how we want them to do it for > large-scale source-specific multicast applications, isn't it? If the > member's group key management performs a rekey-me-out-of-this-group, > it does not mean that the member has destroyed the keys. It does > not mean that the member is not continuing to use the keys. It is > just a notification from the member to the KDC that the KDC can > re-key the member out of the group. The KDC might then run LKH > or some other membership management algorithm over Re-key > messages to change everyone's key except the member that sent > the rekey-me-out-of-this-group request to the KDC. That's the only > way to remove access to key material (e.g. future TEKs) encrypted in the > group KEK. There is no way to remove access to data security TEKs > that were disseminated prior to the rekey-me-out-of-this-group request. > > De-registration protocol has questionable use as a > a mechanism to trigger an LKH message removing the member > from the group. A key-management protocol is not needed to do this, > in my experience, an application-programming interface to the > KDC can allow an ecommerce/authorization application to do this. > > If some vendors ask for this, I think we should revisit the idea of > doing a deregistration/rekey-me-out-of-this-group protocol message. > Otherwise, msec key management has enough on its plate: > Simple systems are more secure than complex ones. > > Best Regards, Mark > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sat Jun 30 01:48:27 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06895 for ; Sat, 30 Jun 2001 01:48:26 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A4E205356F; Sat, 30 Jun 2001 01:24: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 67BBA53560 for ; Sat, 30 Jun 2001 01:22:46 -0400 (EDT) Received: (qmail 53032 invoked by uid 3269); 30 Jun 2001 05:22:46 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 53027 invoked from network); 30 Jun 2001 05:22:45 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by klesh.pair.com with SMTP; 30 Jun 2001 05:22:45 -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 f5U5KaH03230; Fri, 29 Jun 2001 22:20:36 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-290.cisco.com [10.21.65.34]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADL01217; Fri, 29 Jun 2001 22:22:13 -0700 (PDT) Message-Id: <4.3.2.7.2.20010629221558.0417d718@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: <200106300425.AAA34010@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, 29 Jun 2001 22:21:42 -0700 Ran At 12:25 AM 6/30/2001 -0400, Ran Canetti wrote: >Mark, > >The purpose of the de-registration protocol is to allow a member to notify >the GCKS that he is no longer interested in being a member. Yes it is. But what we don't know is if the leaving member is going to continue to use its keys. The GCKS can only assume that it is and rekey the group. >This would be important in the scenarios i described where members dont know >in advance whn they'll leave and pay relative to membership time. This sounds like a secure electronic transaction to me and not a key management protocol operation. >if a de-registration functionality is necessary then it should be done >within msec, just like the registration, since it has security implication >on the group. this is because the de-registration would typically involve >updating databases that are under msec control (such as LKH/OFT). This is where rekey comes into play, as I mentioned above. >That said, I agree with you and Brian that we can leave the detailed >specification and implementation of the de-registration protocol to a >later time (unless people feel that it is important to specify it at this >time). Still, I would add language to the GKM architecture document >regarding the role of this protocol. I'm not sure what Brian is recommending. I recommend leaving the decision to a later time. I think we have not decided to do a Registration protocol as a WG. Best Regards, Mark >Ran > > > > >The question is what functionality we want msec to provide. if we want msec >to support groups where > > From mbaugher@cisco.com Fri Jun 29 19:17:05 2001 > > > > Ran > > Why wouldn't the service operator use a secure electronic transaction > > protocol? A group key management protocol operation would only > > be meaningful if it was a rekey-me-out-of-this-group operation. I > > don't know why a member would not just delete its keys and > > leave the group that way. This is how we want them to do it for > > large-scale source-specific multicast applications, isn't it? If the > > member's group key management performs a rekey-me-out-of-this-group, > > it does not mean that the member has destroyed the keys. It does > > not mean that the member is not continuing to use the keys. It is > > just a notification from the member to the KDC that the KDC can > > re-key the member out of the group. The KDC might then run LKH > > or some other membership management algorithm over Re-key > > messages to change everyone's key except the member that sent > > the rekey-me-out-of-this-group request to the KDC. That's the only > > way to remove access to key material (e.g. future TEKs) encrypted in the > > group KEK. There is no way to remove access to data security TEKs > > that were disseminated prior to the rekey-me-out-of-this-group request. > > > > De-registration protocol has questionable use as a > > a mechanism to trigger an LKH message removing the member > > from the group. A key-management protocol is not needed to do this, > > in my experience, an application-programming interface to the > > KDC can allow an ecommerce/authorization application to do this. > > > > If some vendors ask for this, I think we should revisit the idea of > > doing a deregistration/rekey-me-out-of-this-group protocol message. > > Otherwise, msec key management has enough on its plate: > > Simple systems are more secure than complex ones. > > > > Best Regards, 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 Sat Jun 30 04:29:55 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA20380 for ; Sat, 30 Jun 2001 04:29:54 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0F6BC5357D; Sat, 30 Jun 2001 04:30: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 29E6E5355D for ; Sat, 30 Jun 2001 04:28:41 -0400 (EDT) Received: (qmail 69267 invoked by uid 3269); 30 Jun 2001 08:28:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 69262 invoked from network); 30 Jun 2001 08:28:39 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by klesh.pair.com with SMTP; 30 Jun 2001 08:28:39 -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 f5U8SFr15062; Sat, 30 Jun 2001 01:28:15 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-290.cisco.com [10.21.65.34]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADL01673; Sat, 30 Jun 2001 01:28:06 -0700 (PDT) Message-Id: <4.3.2.7.2.20010630011412.041eb718@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.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: Sat, 30 Jun 2001 01:27:36 -0700 Hugh, At 02:41 PM 6/28/2001 -0400, Hugh Harney wrote: >All, > >I think I need to clarify my position on both GDOI and GSAKMP. I think >this is necessary because I'm being referenced. I'm also an author of both >protocols. I believe they both have valid Internet requirements they are >trying to address. > >GDOI is specifically aimed at centralized key distribution for IPSec, ESP >and AH. It is aimed at applications with some of the following >characteristics. First, the data is owned by a single entity. Second, it >was decided during an authors meeting that GDOI would rely on an external >security policy infrastructure (left undefined in the document). I think >there are perfectly valid applications for this architecture. > >GSAKMP is aimed at non centralized key distribution (although it can >support a centralized architecture). It also has incorporated the >mechanisms needed to support applications with multiple sources of data >and multiple data ownership issues. To support these applications it >incorporates policy definition and dissemination mechanisms. >Unfortunately, flexibility in architectures leads to complexity in protocols. what if GSAKMP did not incorporate "policy definition and dissemination mechanisms?" How would this lead to a reduction in GSAKMP protocol complexity? >Architecture document as posted. Note: they are editorial because they >express my opinion and have not been voted upon by the MSEC group.> > >I believe the statement "Extensions to IKE, however, are probably the best >solution for IPSec >protocols over IP multicast services [GDOI]" in the introduction leads the >reader to a conclusion that GDOI is THE ONLY valid key management protocol >for IPSec. I believe it is a valid protocol given some constraints on the >application. (see above) 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. >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. I too believe that policy is critical for msec to specify. >infrastructure issue.> > >The position of GDOI is as stated in the document "As is done in IKE, GDOI >defines and conveys only cryptographic policies, which are contained in >the SA KEK and SA TEK payloads. " > >Given the above condition, I suggested the following be added to the GDOI >Internet Draft. This second GDOI quote (below) constitutes a criteria I >believe could make the above GDOI assumption work in a secure system. > > >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. > > >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. >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? >Note: Read words written in capital letters as Boolean. > >I believe MSec security policy is important to key management. I believe >that internal or external means can supply that policy to the group. I >don't believe the MSec architecture should exclude key management >approaches that provide policy mechanisms internal to the key management >protocols. I think it should. How do we resolve this. For one thing, let's refer to some of your suggestions that were added to the GDOI spec. > >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? 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 Sat Jun 30 10:09:52 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22871 for ; Sat, 30 Jun 2001 10:09:51 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 56EEC53556; Sat, 30 Jun 2001 10:10: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 57232535E1 for ; Sat, 30 Jun 2001 10:08:36 -0400 (EDT) Received: (qmail 91056 invoked by uid 3269); 30 Jun 2001 14:08:36 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 91053 invoked from network); 30 Jun 2001 14:08:35 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 30 Jun 2001 14:08:35 -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 f5UE7w819452; Sat, 30 Jun 2001 10:07:58 -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 KAA24802; Sat, 30 Jun 2001 10:07:57 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id KAA34236; Sat, 30 Jun 2001 10:07:57 -0400 From: Ran Canetti Message-Id: <200106301407.KAA34236@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: Sat, 30 Jun 2001 10:07:57 -0400 Mark, > >The purpose of the de-registration protocol is to allow a member to notify > >the GCKS that he is no longer interested in being a member. > > Yes it is. But what we don't know is if the leaving member is going to > continue to use its keys. The GCKS can only assume that it is and rekey > the group. That's exactly the point: The de-registration message will typically prompt some action by the GCKS to make sure that the leaving member indeed loses access to the group communication. (This may take the form of updating the LKH/OFT tree or doing whatever is necessary.) That's why the de-registration message is an integral part of the msec protocol suite, if it used. > > >This would be important in the scenarios i described where members dont > >know > >in advance whn they'll leave and pay relative to membership time. > > This sounds like a secure electronic transaction to me and not a key > management protocol operation. It is no more (and no less) a set than the registration protocol. in both cases, there are: - financial/accounting consequences, with the usual authentication an non-repudiation requirements. - group key management consequences (eg, updating the LKH/OFT tree, and/or downloading keys+policy token). > >if a de-registration functionality is necessary then it should be done > >within msec, just like the registration, since it has security implication > >on the group. this is because the de-registration would typically involve > >updating databases that are under msec control (such as LKH/OFT). > > This is where rekey comes into play, as I mentioned above. Rekey is where the updated tree is manifested. But we need some way to prompt the GCKS to update its tree. This will be done by the de-registration protocol. > >That said, I agree with you and Brian that we can leave the detailed > >specification and implementation of the de-registration protocol to a > >later time (unless people feel that it is important to specify it at this > >time). Still, I would add language to the GKM architecture document > >regarding the role of this protocol. > > I'm not sure what Brian is recommending. I recommend leaving the > decision to a later time. I think we have not decided to do a Registration > protocol as a WG. No, it is under discussion. Ran > > Best Regards, Mark > > ? > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sat Jun 30 14:34:39 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24518 for ; Sat, 30 Jun 2001 14:34:38 -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 Sat Jun 30 15:08:33 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24740 for ; Sat, 30 Jun 2001 15:08:33 -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 Sat Jun 30 15:58:33 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25109 for ; Sat, 30 Jun 2001 15:58:32 -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 Sat Jun 30 16:45:51 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25451 for ; Sat, 30 Jun 2001 16:45:50 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 357855367E; Sat, 30 Jun 2001 16:46: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 56EFE5353D for ; Sat, 30 Jun 2001 16:44:29 -0400 (EDT) Received: (qmail 17979 invoked by uid 3269); 30 Jun 2001 20:44:29 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 17976 invoked from network); 30 Jun 2001 20:44:28 -0000 Received: from chmls06.mediaone.net (24.147.1.144) by klesh.pair.com with SMTP; 30 Jun 2001 20:44: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 f5UKiR814790 for ; Sat, 30 Jun 2001 16:44:27 -0400 (EDT) Message-Id: <5.0.0.25.2.20010630163334.02cdfe78@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] De-registration protocol? In-Reply-To: <200106300425.AAA34010@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, 30 Jun 2001 16:44:21 -0400 Ran, I still think that the notion of De-registration and Registration are NOT symmetric. This asymmetricity is due to the fact that in the architecture, *control* is not symmetric or shared. That is, a group member cannot decide when to re-key the group (that's the KDC's decision). A member can wish it could effect a re-key (by sending a quit message), but the decision is still the KDC's (and is a function of the application area). It may be the case that it would be cheaper to ignore a member's quit-message, and wait until the next periodic-rekey. A group key management protocol will not function without a Registration process, though it will function without De-registration. This is true for GDOI and GSAKMP as they stand today. If we are going to add text to the architecture-doc about de-registration, I would also like to insist that the text mentions De-Registration as being very likely an Applicationlayer function. (I'm having difficulty with this "chair-hat-on/hat-off" business :) cheers, thomas ------ At 6/30/2001||12:25 AM, Ran Canetti wrote: >Mark, > >The purpose of the de-registration protocol is to allow a member to notify >the GCKS that he is no longer interested in being a member. >This would be important in the scenarios i described where members dont know >in advance whn they'll leave and pay relative to membership time. > >if a de-registration functionality is necessary then it should be done >within msec, just like the registration, since it has security implication >on the group. this is because the de-registration would typically involve >updating databases that are under msec control (such as LKH/OFT). > >That said, I agree with you and Brian that we can leave the detailed >specification and implementation of the de-registration protocol to a >later time (unless people feel that it is important to specify it at this >time). Still, I would add language to the GKM architecture document >regarding the role of this protocol. > >Ran > > > > >The question is what functionality we want msec to provide. if we want msec >to support groups where > > From mbaugher@cisco.com Fri Jun 29 19:17:05 2001 > > > > Ran > > Why wouldn't the service operator use a secure electronic transaction > > protocol? A group key management protocol operation would only > > be meaningful if it was a rekey-me-out-of-this-group operation. I > > don't know why a member would not just delete its keys and > > leave the group that way. This is how we want them to do it for > > large-scale source-specific multicast applications, isn't it? If the > > member's group key management performs a rekey-me-out-of-this-group, > > it does not mean that the member has destroyed the keys. It does > > not mean that the member is not continuing to use the keys. It is > > just a notification from the member to the KDC that the KDC can > > re-key the member out of the group. The KDC might then run LKH > > or some other membership management algorithm over Re-key > > messages to change everyone's key except the member that sent > > the rekey-me-out-of-this-group request to the KDC. That's the only > > way to remove access to key material (e.g. future TEKs) encrypted in the > > group KEK. There is no way to remove access to data security TEKs > > that were disseminated prior to the rekey-me-out-of-this-group request. > > > > De-registration protocol has questionable use as a > > a mechanism to trigger an LKH message removing the member > > from the group. A key-management protocol is not needed to do this, > > in my experience, an application-programming interface to the > > KDC can allow an ecommerce/authorization application to do this. > > > > If some vendors ask for this, I think we should revisit the idea of > > doing a deregistration/rekey-me-out-of-this-group protocol message. > > Otherwise, msec key management has enough on its plate: > > Simple systems are more secure than complex ones. > > > > Best Regards, 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 Sat Jun 30 17:21:49 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25694 for ; Sat, 30 Jun 2001 17: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 Sat Jun 30 18: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 SAA26120 for ; Sat, 30 Jun 2001 18: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 Sat Jun 30 19:46:37 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26666 for ; Sat, 30 Jun 2001 19:46:36 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 88F8A5361A; Sat, 30 Jun 2001 19:46: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 1785F53563 for ; Sat, 30 Jun 2001 19:44:10 -0400 (EDT) Received: (qmail 32258 invoked by uid 3269); 30 Jun 2001 23:44:09 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 32255 invoked from network); 30 Jun 2001 23:44:09 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by klesh.pair.com with SMTP; 30 Jun 2001 23:44:09 -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 f5UNfxH29035; Sat, 30 Jun 2001 16:41:59 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-311.cisco.com [10.21.65.55]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ADL03931; Sat, 30 Jun 2001 16:43:35 -0700 (PDT) Message-Id: <4.3.2.7.2.20010630162120.041c91e8@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, msec@securemulticast.org In-Reply-To: <200106301407.KAA34236@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, 30 Jun 2001 16:43:04 -0700 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 At 10:07 AM 6/30/2001 -0400, Ran Canetti wrote: >Mark, > > > >The purpose of the de-registration protocol is to allow a member to notify > > >the GCKS that he is no longer interested in being a member. > > > > Yes it is. But what we don't know is if the leaving member is going to > > continue to use its keys. The GCKS can only assume that it is and rekey > > the group. > >That's exactly the point: The de-registration message will typically >prompt some action by the GCKS to make sure that the leaving member >indeed loses access to the group communication. (This may take the form of >updating the LKH/OFT tree or doing whatever is necessary.) >That's why the de-registration message is an integral part of the >msec protocol suite, if it used. > > > > > >This would be important in the scenarios i described where members dont > > >know > > >in advance whn they'll leave and pay relative to membership time. > > > > This sounds like a secure electronic transaction to me and not a key > > management protocol operation. > >It is no more (and no less) a set than the registration protocol. >in both cases, there are: >- financial/accounting consequences, with the usual authentication an > non-repudiation requirements. >- group key management consequences (eg, updating the LKH/OFT tree, and/or > downloading keys+policy token). > > > >if a de-registration functionality is necessary then it should be done > > >within msec, just like the registration, since it has security implication > > >on the group. this is because the de-registration would typically involve > > >updating databases that are under msec control (such as LKH/OFT). > > > > This is where rekey comes into play, as I mentioned above. > >Rekey is where the updated tree is manifested. But we need some way to >prompt the GCKS to update its tree. This will be done by the de-registration >protocol. > > > >That said, I agree with you and Brian that we can leave the detailed > > >specification and implementation of the de-registration protocol to a > > >later time (unless people feel that it is important to specify it at this > > >time). Still, I would add language to the GKM architecture document > > >regarding the role of this protocol. > > > > I'm not sure what Brian is recommending. I recommend leaving the > > decision to a later time. I think we have not decided to do a Registration > > protocol as a WG. > >No, it is under discussion. > > >Ran > > > > > Best Regards, 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 Sat Jun 30 20:08:26 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26857 for ; Sat, 30 Jun 2001 20:08: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 Sat Jun 30 21: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 VAA27403 for ; Sat, 30 Jun 2001 21:31: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 Sat Jun 30 22:55:10 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29705 for ; Sat, 30 Jun 2001 22:55:06 -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