From msec-bounces@securemulticast.org Fri Jun 02 16:49:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGa3-0001Xw-By for msec-archive@lists.ietf.org; Fri, 02 Jun 2006 16:49:15 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmGa2-0004mg-2R for msec-archive@lists.ietf.org; Fri, 02 Jun 2006 16:49:15 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id A97562C734; Fri, 2 Jun 2006 16:49:13 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 430D12C25A for ; Fri, 2 Jun 2006 16:49:12 -0400 (EDT) Received: (qmail 25980 invoked by uid 3269); 2 Jun 2006 20:49:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 25977 invoked from network); 2 Jun 2006 20:49:12 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 2 Jun 2006 20:49:12 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id ED6606838E for ; Fri, 2 Jun 2006 16:49:11 -0400 (EDT) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k52Kn9VB001650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 2 Jun 2006 13:49:10 -0700 Received: from LDONDETI.qualcomm.com ([10.50.74.8]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k52Kn5Qw005288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 2 Jun 2006 13:49:08 -0700 (PDT) Message-Id: <7.0.1.0.2.20060602134819.04606ec0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 02 Jun 2006 13:49:02 -0700 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] June 7th deadline (Fwd: Approval to Post -00) X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 >To: Working Group Chairs >From: Internet-Drafts Administrator >Date: Fri, 02 Jun 2006 00:00:01 -0400 >X-Spam-Score: -2.6 (--) >X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 >Cc: >Subject: Approval to Post Version -00 Internet-Drafts for the 66th IETF > Meeting in Montreal, Quebec, Canada >X-BeenThere: wgchairs@ietf.org >X-Mailman-Version: 2.1.5 >Precedence: list >List-Id: Working Group Chairs >List-Unsubscribe: , > >List-Post: >List-Help: >List-Subscribe: , > >Errors-To: wgchairs-bounces@ietf.org > > >Dear IETF Working Group Chairs: > >In order to expedite the processing of the many version -00 I-Ds that >the Secretariat receives before an IETF meeting, we ask that you >please notify the Secretariat prior to the initial submission cutoff >date of all version -00 I-Ds that you expect to approve for posting as >WG documents. Please send the filenames of your approved -00 I-Ds to >internet-drafts@ietf.org. We would appreciate receiving your list of >approved drafts five (5) business days prior to the cutoff date for -00 >submissions, or by Monday, June 12th at 9:00 AM ET for the 66th IETF >Meeting. Please include the word "Approved I-Ds" in the "Subject" >field. This procedure will help to ensure that version -00 I-Ds are >posted in a timely manner, allowing more time for review by the public. > >Thank you for your cooperation in this matter. > >The Internet-Drafts Administrator > >FYI: The Internet-Draft cutoff dates as well as other significant dates >for the 66th IETF Meeting can be found at >http://www.ietf.org/meetings/cutoff_dates_66.html. _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Sun Jun 04 11:32:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmua8-0005Nf-Rt for msec-archive@lists.ietf.org; Sun, 04 Jun 2006 11:32:00 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fmua7-0007Gf-JC for msec-archive@lists.ietf.org; Sun, 04 Jun 2006 11:32:00 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 2EE432C7E2; Sun, 4 Jun 2006 11:31:59 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 3F2A32C683 for ; Sun, 4 Jun 2006 11:31:57 -0400 (EDT) Received: (qmail 38524 invoked by uid 3269); 4 Jun 2006 15:31:57 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 38521 invoked from network); 4 Jun 2006 15:31:57 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 4 Jun 2006 15:31:57 -0000 Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by klesh.pair.com (Postfix) with ESMTP id 1C6186835D for ; Sun, 4 Jun 2006 11:31:57 -0400 (EDT) Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C1ABF4F0001; Sun, 4 Jun 2006 17:31:51 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 4 Jun 2006 17:31:51 +0200 Received: from esealmw104.eemea.ericsson.se ([153.88.200.67]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 4 Jun 2006 17:31:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 4 Jun 2006 17:31:49 +0200 Message-ID: <3AD208E1F0D5EB47AC3C5617420BCB0204C7EC54@esealmw104.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-lehtovirta-srtp-rcc-03.txt Thread-Index: AcZq3OTEgv0o9VWfRf6pt36oDy3S8QdDdfeA From: "Karl Norrman \(KI/EAB\)" To: , X-OriginalArrivalTime: 04 Jun 2006 15:31:51.0150 (UTC) FILETIME=[002B30E0:01C687EC] X-Brightmail-Tracker: AAAAAA== Cc: Subject: [MSEC] draft-lehtovirta-srtp-rcc-03.txt X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Hello! An update of the draft is now available at: http://www.ietf.org/internet-drafts/draft-lehtovirta-srtp-rcc-03.txt We are planning to request for it to be published, and Lakshminath has kindly volunteered to help with shepherding. =20 Please provide any further comments within one week. Regards, Karl _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Jun 06 07:01:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnZJo-0005km-9W for msec-archive@lists.ietf.org; Tue, 06 Jun 2006 07:01:52 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnZJm-0001YS-Qf for msec-archive@lists.ietf.org; Tue, 06 Jun 2006 07:01:52 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id B88B02CA70; Tue, 6 Jun 2006 07:01:47 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 735C32CA51 for ; Tue, 6 Jun 2006 07:01:40 -0400 (EDT) Received: (qmail 80305 invoked by uid 3269); 6 Jun 2006 11:01:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 80302 invoked from network); 6 Jun 2006 11:01:40 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 6 Jun 2006 11:01:40 -0000 Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) by klesh.pair.com (Postfix) with ESMTP id 3541F6839A for ; Tue, 6 Jun 2006 07:01:40 -0400 (EDT) Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k56B1cVt013221; Tue, 6 Jun 2006 13:01:38 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k56B1b4L026440; Tue, 6 Jun 2006 13:01:38 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jun 2006 13:01:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] draft-lehtovirta-srtp-rcc-03.txt Date: Tue, 6 Jun 2006 13:01:36 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] draft-lehtovirta-srtp-rcc-03.txt thread-index: AcZq3OTEgv0o9VWfRf6pt36oDy3S8QdDdfeAAFqsWfA= From: "Fries, Steffen" To: "Karl Norrman \(KI/EAB\)" X-OriginalArrivalTime: 06 Jun 2006 11:01:37.0740 (UTC) FILETIME=[950CA8C0:01C68958] Cc: msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Hi Karl, I just read over the updated draft. The only thing that was not quite clear to me was the point three in the introduction. If the receiver gets an "old" packet, would'nt it be recognized by the integrity check (if applied)? Same to point 4, I would have expected, that the mechanism described in RFC3711 works in this scenario (packet loss smaller than 2^15 packets). The increment/decrement of the (local) ROC should only be done after a successful integrity check. Regards Steffen > -----Original Message----- > From: msec-bounces@securemulticast.org=20 > [mailto:msec-bounces@securemulticast.org] On Behalf Of Karl=20 > Norrman (KI/EAB) > Sent: Sunday, June 04, 2006 5:32 PM > To: avt@ietf.org; msec@securemulticast.org > Subject: [MSEC] draft-lehtovirta-srtp-rcc-03.txt >=20 > Hello! >=20 > An update of the draft is now available at: > http://www.ietf.org/internet-drafts/draft-lehtovirta-srtp-rcc-03.txt >=20 > We are planning to request for it to be published, and=20 > Lakshminath has kindly volunteered to help with shepherding. =20 >=20 > Please provide any further comments within one week. >=20 > Regards, > Karl > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec >=20 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Jun 06 17:09:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnioE-0003kA-BZ for msec-archive@lists.ietf.org; Tue, 06 Jun 2006 17:09:54 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnioC-0000h7-SK for msec-archive@lists.ietf.org; Tue, 06 Jun 2006 17:09:54 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 6875D2C72B; Tue, 6 Jun 2006 17:09:52 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id B4E502C415 for ; Tue, 6 Jun 2006 17:09:50 -0400 (EDT) Received: (qmail 55476 invoked by uid 3269); 6 Jun 2006 21:09:50 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 55473 invoked from network); 6 Jun 2006 21:09:50 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 6 Jun 2006 21:09:50 -0000 Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by klesh.pair.com (Postfix) with ESMTP id 5A5E668360 for ; Tue, 6 Jun 2006 17:09:50 -0400 (EDT) Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1D7F65AF; Tue, 6 Jun 2006 23:09:49 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jun 2006 23:09:48 +0200 Received: from esealmw104.eemea.ericsson.se ([153.88.200.67]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jun 2006 23:09:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] draft-lehtovirta-srtp-rcc-03.txt Date: Tue, 6 Jun 2006 23:09:47 +0200 Message-ID: <3AD208E1F0D5EB47AC3C5617420BCB0204CB080A@esealmw104.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] draft-lehtovirta-srtp-rcc-03.txt Thread-Index: AcZq3OTEgv0o9VWfRf6pt36oDy3S8QdDdfeAAFqsWfAAFOwyAA== From: "Karl Norrman \(KI/EAB\)" To: "Fries, Steffen" X-OriginalArrivalTime: 06 Jun 2006 21:09:48.0598 (UTC) FILETIME=[8B4BB560:01C689AD] X-Brightmail-Tracker: AAAAAA== Cc: msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Hello!=20 The problem in 3 and 4 is that the receiver does not yet know what is an "old" packet, i.e., the receiver has not initialized the highest received SEQ (s_l) when the first packet arrives. This figure describes case 3 (assume that the SRTP packet with SEQ =3D 0xffff is delayed and that those with SEQ =3D 0, 1, 2 are lost). Sender Receiver ROC SEQ ROC s_l 0 0xfffe 0 0xffff --+ | 1 0x0000 | =20 | (MIKEY ROC=3D1) 1 0x0001 --|---------------> 1 0x???? |(SRTP SEQ=3D0xffff) 1 0x0002 +---------------> 1 0xffff (SRTP SEQ=3D0x0003) 1 0x0003 ------------------> 2 0x0003=20 If there is no integrity protection, the receiver would deduce that the ROC should be increased by one when receiving the last packet in the figure. As you point out, if there *is* integrity protection, the packet with SEQ =3D 0xffff would be dropped and the ROC would not be = incorrectly increased when the last packet arrives. The mechanism in RFC3711 can unfortunately not be applied in case 3 and 4 since it assumes that the receiver has reasonable guess of the ROC and s_l, and s_l is in these cases not known. BR Karl > -----Original Message----- > From: Fries, Steffen [mailto:steffen.fries@siemens.com]=20 > Sent: den 6 juni 2006 13:02 > To: Karl Norrman (KI/EAB) > Cc: msec@securemulticast.org > Subject: RE: [MSEC] draft-lehtovirta-srtp-rcc-03.txt >=20 > Hi Karl, >=20 > I just read over the updated draft. The only thing that was=20 > not quite clear to me was the point three in the=20 > introduction. If the receiver gets an "old" packet, would'nt=20 > it be recognized by the integrity check (if applied)? Same to=20 > point 4, I would have expected, that the mechanism described=20 > in RFC3711 works in this scenario (packet loss smaller than > 2^15 packets). The increment/decrement of the (local) ROC=20 > should only be done after a successful integrity check. >=20 >=20 > Regards > Steffen >=20 >=20 >=20 > > -----Original Message----- > > From: msec-bounces@securemulticast.org=20 > > [mailto:msec-bounces@securemulticast.org] On Behalf Of Karl Norrman=20 > > (KI/EAB) > > Sent: Sunday, June 04, 2006 5:32 PM > > To: avt@ietf.org; msec@securemulticast.org > > Subject: [MSEC] draft-lehtovirta-srtp-rcc-03.txt > >=20 > > Hello! > >=20 > > An update of the draft is now available at: > > http://www.ietf.org/internet-drafts/draft-lehtovirta-srtp-rcc-03.txt > >=20 > > We are planning to request for it to be published, and=20 > Lakshminath has=20 > > kindly volunteered to help with shepherding. > >=20 > > Please provide any further comments within one week. > >=20 > > Regards, > > Karl > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://six.pairlist.net/mailman/listinfo/msec > >=20 >=20 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Jun 07 02:17:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnrM0-000498-Ci for msec-archive@lists.ietf.org; Wed, 07 Jun 2006 02:17:20 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnrLx-0000EJ-RK for msec-archive@lists.ietf.org; Wed, 07 Jun 2006 02:17:20 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 42D6B2CB41; Wed, 7 Jun 2006 02:17:17 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id BC7A72C854 for ; Wed, 7 Jun 2006 02:17:14 -0400 (EDT) Received: (qmail 31681 invoked by uid 3269); 7 Jun 2006 06:17:14 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 31678 invoked from network); 7 Jun 2006 06:17:14 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 7 Jun 2006 06:17:14 -0000 Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) by klesh.pair.com (Postfix) with ESMTP id E5F5568369 for ; Wed, 7 Jun 2006 02:17:13 -0400 (EDT) Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k576HBX0011411; Wed, 7 Jun 2006 08:17:11 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k576HBen015638; Wed, 7 Jun 2006 08:17:11 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 08:17:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] draft-lehtovirta-srtp-rcc-03.txt Date: Wed, 7 Jun 2006 08:17:10 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] draft-lehtovirta-srtp-rcc-03.txt thread-index: AcZq3OTEgv0o9VWfRf6pt36oDy3S8QdDdfeAAFqsWfAAFOwyAAAT/+jg From: "Fries, Steffen" To: "Karl Norrman \(KI/EAB\)" X-OriginalArrivalTime: 07 Jun 2006 06:17:11.0454 (UTC) FILETIME=[0329D3E0:01C689FA] Cc: msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Hi Karl, thank you for the explanation. That answers my question. I agree, if the receiver has no resonable guess of s_1 he will run into problems. As this was my only question, the draft looks fine from my point of view. Regards Steffen > -----Original Message----- > From: Karl Norrman (KI/EAB) [mailto:karl.norrman@ericsson.com]=20 > Sent: Tuesday, June 06, 2006 11:10 PM > To: Fries, Steffen > Cc: msec@securemulticast.org > Subject: RE: [MSEC] draft-lehtovirta-srtp-rcc-03.txt >=20 > Hello!=20 >=20 > The problem in 3 and 4 is that the receiver does not yet know=20 > what is an "old" packet, i.e., the receiver has not=20 > initialized the highest received SEQ (s_l) when the first=20 > packet arrives. >=20 > This figure describes case 3 (assume that the SRTP packet=20 > with SEQ =3D 0xffff is delayed and that those with SEQ =3D 0, 1,=20 > 2 are lost). >=20 > Sender Receiver > ROC SEQ ROC s_l > 0 0xfffe >=20 > 0 0xffff --+ > | > 1 0x0000 | =20 > | (MIKEY ROC=3D1) > 1 0x0001 --|---------------> 1 0x???? > |(SRTP SEQ=3D0xffff) > 1 0x0002 +---------------> 1 0xffff > (SRTP SEQ=3D0x0003) > 1 0x0003 ------------------> 2 0x0003=20 >=20 >=20 > If there is no integrity protection, the receiver would=20 > deduce that the ROC should be increased by one when receiving=20 > the last packet in the figure. > As you point out, if there *is* integrity protection, the=20 > packet with SEQ =3D 0xffff would be dropped and the ROC would=20 > not be incorrectly increased when the last packet arrives. >=20 > The mechanism in RFC3711 can unfortunately not be applied in=20 > case 3 and 4 since it assumes that the receiver has=20 > reasonable guess of the ROC and s_l, and s_l is in these=20 > cases not known. >=20 > BR > Karl >=20 > > -----Original Message----- > > From: Fries, Steffen [mailto:steffen.fries@siemens.com] > > Sent: den 6 juni 2006 13:02 > > To: Karl Norrman (KI/EAB) > > Cc: msec@securemulticast.org > > Subject: RE: [MSEC] draft-lehtovirta-srtp-rcc-03.txt > >=20 > > Hi Karl, > >=20 > > I just read over the updated draft. The only thing that was=20 > not quite=20 > > clear to me was the point three in the introduction. If the=20 > receiver=20 > > gets an "old" packet, would'nt it be recognized by the=20 > integrity check=20 > > (if applied)? Same to point 4, I would have expected, that the=20 > > mechanism described in RFC3711 works in this scenario (packet loss=20 > > smaller than > > 2^15 packets). The increment/decrement of the (local) ROC=20 > should only=20 > > be done after a successful integrity check. > >=20 > >=20 > > Regards > > Steffen > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: msec-bounces@securemulticast.org=20 > > > [mailto:msec-bounces@securemulticast.org] On Behalf Of=20 > Karl Norrman > > > (KI/EAB) > > > Sent: Sunday, June 04, 2006 5:32 PM > > > To: avt@ietf.org; msec@securemulticast.org > > > Subject: [MSEC] draft-lehtovirta-srtp-rcc-03.txt > > >=20 > > > Hello! > > >=20 > > > An update of the draft is now available at: > > >=20 > http://www.ietf.org/internet-drafts/draft-lehtovirta-srtp-rcc-03.txt > > >=20 > > > We are planning to request for it to be published, and > > Lakshminath has > > > kindly volunteered to help with shepherding. > > >=20 > > > Please provide any further comments within one week. > > >=20 > > > Regards, > > > Karl > > > _______________________________________________ > > > msec mailing list > > > msec@securemulticast.org > > > http://six.pairlist.net/mailman/listinfo/msec > > >=20 > >=20 >=20 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Jun 09 13:40:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FokyW-0002h6-Hw for msec-archive@lists.ietf.org; Fri, 09 Jun 2006 13:40:48 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FokyV-0004B1-5L for msec-archive@lists.ietf.org; Fri, 09 Jun 2006 13:40:48 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id A81922BF24; Fri, 9 Jun 2006 13:40:46 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id A07882BE19 for ; Fri, 9 Jun 2006 13:40:44 -0400 (EDT) Received: (qmail 66761 invoked by uid 3269); 9 Jun 2006 17:40:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 66758 invoked from network); 9 Jun 2006 17:40:44 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 9 Jun 2006 17:40:44 -0000 Received: from smtp-out2.oct.nac.net (smtp-out2.oct.nac.net [209.123.233.212]) by klesh.pair.com (Postfix) with SMTP id 8673068362 for ; Fri, 9 Jun 2006 13:40:44 -0400 (EDT) Received: (qmail 1352 invoked by uid 0); 9 Jun 2006 13:40:43 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 9 Jun 2006 13:40:43 -0400 Received: (qmail 97996 invoked from network); 9 Jun 2006 13:40:43 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 9 Jun 2006 13:40:43 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k59E2vN05808; Fri, 9 Jun 2006 10:02:57 -0400 Date: Fri, 9 Jun 2006 10:02:56 -0400 (EDT) From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: gmgross@nac.net Subject: [MSEC] IPsec composite groups X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Hi, I would like to bring to your attention an Internet Draft announcement yesterday for an individual submission that I have written entitled "Multicast IP Security Composite Cryptographic Groups". The URL for the draft is: http://www.ietf.org/internet-drafts/draft-gross-msec-ipsec-composite-group-00.txt The composite group architectural capability is an outgrowth of the MSEC IPsec extensions draft that Brian Weis, Dragan Ignjatic, and I have been working on. In parallel, there has been an IETF-wide initiative to examine all security protocols, and evaluate their ability to migrate to new cryptographic algorithms. The composite group capability is a candidate solution for easing that migration for large-scale cryptographic groups. Composite groups can also be applied to other use cases wherein a large-scale group straddles two or more hetrogeneous sub-groups. Brian and I have debated the merits of including this capability in the MSEC IPsec extensions draft, and we concluded it is not yet seasoned with enough operational experience to be placed on proposed standards track. That said, I believe it represents a potential solution to this type of problem, and it merits inclusion as an MSEC working group document on the IETF "experimental track". In the long-term, it may gain sufficient support to transition from experimental to standards track, similar as has been seen recently with several RMT working group protocols. Lakshminath & Ran: As we've discussed off list, I'd like to nominate this document as an MSEC document. br, George The Composite Group Internet Draft abstract follows: The Multicast IP Security extension architecture [Weis] implicitly assumes a basic group endpoint population that shares homogeneous cryptographic capabilities and security policies. In practice, large- scale cryptographic groups may contain a heterogeneous endpoint population that can not be accommodated by that basic multicast IPsec architecture. For example, some endpoints may not have been upgraded to handle the successor algorithm for one that is being retired (e.g. SHA1 transition to SHA-ng). This document defines the "composite cryptographic group" IP security architecture capability. A composite cryptographic group allows multicast IPsec applications to transparently interact with the single logical group that is formed by the union of one or more basic cryptographic groups. _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Sun Jun 11 21:55:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpbe0-00069D-HO for msec-archive@lists.ietf.org; Sun, 11 Jun 2006 21:55:08 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpbdy-0007dy-7n for msec-archive@lists.ietf.org; Sun, 11 Jun 2006 21:55:08 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id D94DC2CBAB; Sun, 11 Jun 2006 21:55:05 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 935132CBB9 for ; Sun, 11 Jun 2006 21:55:03 -0400 (EDT) Received: (qmail 66597 invoked by uid 3269); 12 Jun 2006 01:55:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 66594 invoked from network); 12 Jun 2006 01:55:03 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 12 Jun 2006 01:55:03 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 565A16838D for ; Sun, 11 Jun 2006 21:55:03 -0400 (EDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5C1t016027087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 11 Jun 2006 18:55:02 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-77-29.qualcomm.com [10.50.77.29]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5C1st5u013940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 11 Jun 2006 18:54:59 -0700 (PDT) Message-Id: <7.0.1.0.2.20060611185103.04585f60@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 11 Jun 2006 18:54:53 -0700 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: canetti@watson.ibm.com Subject: [MSEC] MSEC call for agenda items X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 MSEC is slated to meet as follows. Please note that this is from the preliminary agenda and it can change to another day or another time. We have 60 minutes of meeting time and we would like to use it for discussions and not necessarily for length updates to drafts. I encourage authors/editors to bring up interesting/contentious topics so we can discuss them at the meeting. We are otherwise progressing well in some cases, and quite poorly in others (we hope to catch up on these). Please send requests for presentations. Thanks. regards, Lakshminath TUESDAY, July 11, 2006 1720-1740 Afternoon Refreshment Break - Foyer 500D 1740-1840 Afternoon Session III Room 513C-FINTmonami6Mobile Nodes and Multiple Interfaces in IPv6 WG Room 515INTmip4Mobility for IPv4 WG Room 515INTpwe3Pseudo Wire Emulation Edge to Edge WG Room 519BOPSopsecOperational Security Capabilities for IP Network Infrastructure WG Room 518ABRAIecritEmergency Context Resolution with Internet Technologies WG Room 513BSECmsecMulticast Security WG Room 519ATSVrohcRobust Header Compression WG _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Jun 13 10:07:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq9Yd-0004qZ-NQ for msec-archive@lists.ietf.org; Tue, 13 Jun 2006 10:07:51 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq9Yc-0007F1-Cn for msec-archive@lists.ietf.org; Tue, 13 Jun 2006 10:07:51 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 2478B2C7FC; Tue, 13 Jun 2006 10:07:48 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 8AFFE2C78D for ; Tue, 13 Jun 2006 10:07:47 -0400 (EDT) Received: (qmail 49080 invoked by uid 3269); 13 Jun 2006 14:07:47 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 49077 invoked from network); 13 Jun 2006 14:07:47 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 13 Jun 2006 14:07:47 -0000 Received: from smtp-out1.oct.nac.net (smtp-out1.oct.nac.net [209.123.233.211]) by klesh.pair.com (Postfix) with SMTP id 6A7E068369 for ; Tue, 13 Jun 2006 10:07:47 -0400 (EDT) Received: (qmail 93623 invoked by uid 0); 13 Jun 2006 10:07:45 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 13 Jun 2006 10:07:45 -0400 Received: (qmail 42230 invoked from network); 13 Jun 2006 10:07:44 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 13 Jun 2006 10:07:44 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k5DATJ416775; Tue, 13 Jun 2006 06:29:19 -0400 Date: Tue, 13 Jun 2006 06:29:19 -0400 (EDT) From: George Gross To: Lakshminath Dondeti Subject: Re: [MSEC] MSEC call for agenda items In-Reply-To: <7.0.1.0.2.20060611185103.04585f60@qualcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: canetti@watson.ibm.com, msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Hi Lakshminath, I would like to have a short slot to present IPsec Composite Groups. Also, though I haven't checked with Brian & Dragan, I imagine we'll need a short slot for the IPsec extensions draft. tia, George On Sun, 11 Jun 2006, Lakshminath Dondeti wrote: > MSEC is slated to meet as follows. Please note that this is from the > preliminary agenda and it can change to another day or another > time. We have 60 minutes of meeting time and we would like to use it > for discussions and not necessarily for length updates to drafts. I > encourage authors/editors to bring up interesting/contentious topics > so we can discuss them at the meeting. > > We are otherwise progressing well in some cases, and quite poorly in > others (we hope to catch up on these). > > Please send requests for presentations. Thanks. > > regards, > Lakshminath > > TUESDAY, July 11, 2006 > > 1720-1740 Afternoon Refreshment Break - Foyer 500D > 1740-1840 Afternoon Session III > Room > 513C-FINTmonami6Mobile > Nodes and Multiple Interfaces in IPv6 WG > Room > 515INTmip4Mobility > for IPv4 WG > Room > 515INTpwe3Pseudo > Wire Emulation Edge to Edge WG > Room > 519BOPSopsecOperational > Security Capabilities for IP Network Infrastructure WG > Room > 518ABRAIecritEmergency > Context Resolution with Internet Technologies WG > Room > 513BSECmsecMulticast > Security WG > Room > 519ATSVrohcRobust > Header Compression WG > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Jun 13 15:16:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqEMw-0005ZT-8r for msec-archive@lists.ietf.org; Tue, 13 Jun 2006 15:16:06 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqEMu-0004Es-Ua for msec-archive@lists.ietf.org; Tue, 13 Jun 2006 15:16:06 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id A70C12C7D1; Tue, 13 Jun 2006 15:16:04 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 5D31E2B984 for ; Tue, 13 Jun 2006 15:16:03 -0400 (EDT) Received: (qmail 47735 invoked by uid 3269); 13 Jun 2006 19:16:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 47731 invoked from network); 13 Jun 2006 19:16:03 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 13 Jun 2006 19:16:03 -0000 Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by klesh.pair.com (Postfix) with ESMTP id 0E2F868362 for ; Tue, 13 Jun 2006 15:16:02 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id l24so1056255nfc for ; Tue, 13 Jun 2006 12:16:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=MqTaDZaPvCVWCDEQdX4ZxluTXtj6J/8m1LWJ5NqwitihMoDN5xyprcL2g+c89RFfjPIsLyR97N9yLKVHCm1ACmbpv/UVH9UA7HRrdZQZx+dZgbpcS1iE9s8Ud3LYqBI1mQf3xHhdWrSJXxMItmIPX2WCO6tt7GOC1gQAeii+TQs= Received: by 10.49.68.20 with SMTP id v20mr102082nfk; Tue, 13 Jun 2006 12:16:01 -0700 (PDT) Received: by 10.49.92.4 with HTTP; Tue, 13 Jun 2006 12:16:01 -0700 (PDT) Message-ID: <4166af450606131216k3d77e25fi1b6af74933851937@mail.gmail.com> Date: Tue, 13 Jun 2006 20:16:01 +0100 From: "Prashant Pillai" To: msec@securemulticast.org MIME-Version: 1.0 Subject: [MSEC] GSAKMP access control X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0715083078==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 --===============0715083078== Content-Type: multipart/alternative; boundary="----=_Part_74331_28440529.1150226161690" ------=_Part_74331_28440529.1150226161690 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, I have some questions related to the access control mechanisms in GSAKMP: 1. What are the access control rules present in the Policy Token? What kind of access control policy does this define? 2. Does the access control rules/policy contain the list of allowed users? What if there are users who were not initially registered to the multicast group but want to join later? 3. How does the GC/KS get the user (GM) credentials to perform the access control? Regards Prashant ------=_Part_74331_28440529.1150226161690 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Hi All,

 

I have some questions related to the access control mechanisms in GSAKMP:

 

1.      What are the access control rules present in the Policy Token? What kind of access control policy does this define?

 

2.      Does the access control rules/policy contain the list of allowed users? What if there are users who were not initially registered to the multicast group but want to join later?

 

3.      How does the GC/KS get the user (GM) credentials to perform the access control?

 

Regards

Prashant  

------=_Part_74331_28440529.1150226161690-- --===============0715083078== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --===============0715083078==-- From msec-bounces@securemulticast.org Wed Jun 14 04:58:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqRCt-0006Fo-30 for msec-archive@lists.ietf.org; Wed, 14 Jun 2006 04:58:35 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqRCq-0007rb-Uw for msec-archive@lists.ietf.org; Wed, 14 Jun 2006 04:58:35 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 1E5B42CBF4; Wed, 14 Jun 2006 04:58:32 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 48FBF2CBDE for ; Wed, 14 Jun 2006 04:58:31 -0400 (EDT) Received: (qmail 73634 invoked by uid 3269); 14 Jun 2006 08:58:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 73631 invoked from network); 14 Jun 2006 08:58:31 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 14 Jun 2006 08:58:31 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id 8BD7368386 for ; Wed, 14 Jun 2006 04:58:30 -0400 (EDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5E8wRxf014474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 14 Jun 2006 01:58:28 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-200.qualcomm.com [10.50.76.200]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5E8wOME006877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Jun 2006 01:58:25 -0700 (PDT) Message-Id: <7.0.1.0.2.20060613184928.069c79a8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 14 Jun 2006 01:58:19 -0700 To: "Fries, Steffen" , "Ignjatic, Dragan" From: Lakshminath Dondeti In-Reply-To: <7.0.1.0.2.20060613184047.06963758@qualcomm.com> References: <7.0.1.0.2.20060613184047.06963758@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: msec@securemulticast.org Subject: [MSEC] Re: Review of draft-ietf-msec-mikey-applicability-00 X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 76319d6f172f4cd0a083860f80065cd1 ******Reviewing as a contributor and NOT as one of the MSEC co-chairs** At 06:44 PM 6/13/2006, you wrote: >MSEC S. Fries >Internet-Draft Siemens >Expires: November 17, 2006 D. Ignjatic > Polycom > May 16, 2006 > > > On the applicability of various MIKEY modes and extensions > draft-ietf-msec-mikey-applicability-00.txt > >Abstract > > Multimedia Internet Keying - MIKEY - is a key management scheme that s/scheme/protocol/ > can be used for real-time applications. In particular, it has been > defined focusing on the support of the Secure Real-time Transport > Protocol. MIKEY itself defines four key distribution schemes. s/schemes/modes/ > Moreover, it is defined to allow extensions of the protocol. As > MIKEY becomes more and more accepted, extensions to the base protocol > arose, especially in terms of additional key distribution schemes, s/schemes/modes >Fries & Ignjatic Expires November 17, 2006 [Page 1] > >Internet-Draft MIKEY modes applicability May 2006 > > but also in terms of payload enhancements. I am not sure whether payload enhancements is the correct way to say this. Extensions to MIKEY through general extension payloads and associated semantics have been introduced. Please wordsmith that as you like. > This document provides an overview about MIKEY in general as well as > the existing extensions in MIKEY, which have been defined or are in > the process of definition. > > >Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 > 3. MIKEY Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 > 3.1. Symmetric key distribution . . . . . . . . . . . . . . . . 6 > 3.2. Asymmetric key distribution . . . . . . . . . . . . . . . 6 > 3.3. Diffie-Hellman key agreement protected with digital > signatures . . . . . . . . . . . . . . . . . . . . . . . . 7 > 3.4. Unprotected key distribution . . . . . . . . . . . . . . . 8 > 4. MIKEY Extensions . . . . . . . . . . . . . . . . . . . . . . . 8 > 4.1. Diffie-Hellman key agreement protected with pre-shared > secrets . . . . . . . . . . . . . . . . . . . . . . . . . 8 > 4.2. SAML assisted DH-key agreement . . . . . . . . . . . . . . 9 > 4.3. Asymmetric key distribution with in-band certificate > exchange . . . . . . . . . . . . . . . . . . . . . . . . . 10 > 4.4. ECC algorithms support . . . . . . . . . . . . . . . . . . 11 > 4.4.1. Elliptic Curve Integrated Encryption Scheme > application in MIKEY . . . . . . . . . . . . . . . . . 12 > 4.4.2. Elliptic Curve Menezes-Qu-Vanstone Scheme > application in MIKEY . . . . . . . . . . . . . . . . . 12 I would use a different kind of organization: specify the various MIKEY modes in one section (so your section 3 and Sections 4.1-4.4 would go there). Within each mode (or subsection) you can provide a reference to where the mode has been specified. > 4.5. New Payload for bootstrapping TESLA . . . . . . . . . . . 12 > 4.6. New Key ID information type . . . . . . . . . . . . . . . 13 > 4.7. Supporting Integrity Transform carrying the Rollover > Counter . . . . . . . . . . . . . . . . . . . . . . . . . 13 RCC doesn't quite belong in the category that I have in mind and that is extensions based on the General Extension payload. Bootstrapping TESLA also does a little bit more than just defining a GenExt payload, but would belong in the GenExt category. My suggestion is to structure the document based on that kind of grouping if at all possible. > 4.8. OMA BCAST MIKEY General Extension Payload Specification . 14 > 5. Selection and interworking of MIKEY modes . . . . . . . . . . 14 > 5.1. MIKEY and Early Media . . . . . . . . . . . . . . . . . . 15 > 5.2. MIKEY and Forking . . . . . . . . . . . . . . . . . . . . 16 > 5.3. MIKEY and Call Transfer . . . . . . . . . . . . . . . . . 16 > 6. Transport of MIKEY messages . . . . . . . . . . . . . . . . . 16 > 7. Summary of MIKEY related IANA Registrations . . . . . . . . . 17 > 8. MIKEY alternatives for SRTP security parameter negotiation . . 17 > 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 > 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 > 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 > 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 > 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 > 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 > Intellectual Property and Copyright Statements . . . . . . . . . . 23 > >Fries & Ignjatic Expires November 17, 2006 [Page 2] > >Internet-Draft MIKEY modes applicability May 2006 > >1. Introduction > > Key distribution describes the process of delivering cryptographic > keys to the required parties. MIKEY [RFC3830], the Multimedia > Internet Keying, has been defined focusing on support for the > establishment of security context for the Secure Real-time Transport > Protocol [RFC3711]. Note that MIKEY is not restricted to be used for > SRTP only, as it features a generic approach and allows for > extensions to the key distribution schemes, but also for the payload > associated with the protocol using the distributed security context. > > MIKEY defines four key distribution schemes as there are: > > o Symmetric key distribution > o Asymmetric key distribution > o Diffie-Hellman key agreement protected by digital signatures > o Unprotected key distribution Again here, I would talk about various modes of MIKEY and not necessarily concentrate on RFC 3830. > There have been scenarios where none of the above schemes fits > perfectly, so extensions have been defined. These extensions > comprise new key distribution schemes, algorithm enhancements, new > payload definitions supporting other protocols than SRTP. The key > distribution scheme extensions are defined in the following > documents: > > o Diffie-Hellman key agreement protected by symmetric pre-shared > keys as defined in [I-D.ietf-msec-mikey-dhhmac] > o SAML assisted Diffie-Hellman key agreement as defined [Reference > to draft-moskowitz-MIKEY-SAML-DH] > o Asymmetric key distribution (based on asymmetric encryption) with > in-band certificate provision as defined in [I-D.ietf-msec-mikey- > rsa-r] > > Algorithm extensions are defined in the following document: > > o ECC algorithms for MIKEY as defined in [I-D.ietf-msec-mikey-ecc] Please see my comments in the ToC. I'd group these into the various modes of MIKEY. > Payload extensions are defined in the following documents: > > o Bootstrapping TESLA, defining a new payload for the Timed > Efficient Stream Loss-tolerant Authentication protocol [RFC4082] > as defined in [RFC4442] > o The Key ID information type for the general extension payload as > defined in [I-D.ietf-msec-newtype-keyid] > o Integrity Transform Carrying Roll-over Counter for SRTP, as > defined in [I-D.lehtovirta-srtp-rcc] Please see my comment on RCC, in the ToC. >Fries & Ignjatic Expires November 17, 2006 [Page 3] >Internet-Draft MIKEY modes applicability May 2006 > > o OMA BCAST MIKEY General Extension Payload Specification, as > defined in [I-D.dondeti-msec-mikey-genext-oma] > > This document provides an overview about MIKEY and the relations to > the different extensions to provide a framework when using MIKEY. It > is intended as additional source of information for developers or > architects to provide more insight in use case scenarios and > motivations as well as advantages and disadvantages for the different > key distribution schemes. > This document may be enhanced as soon as > new extensions to MIKEY appear. It has been seen that enhancing the > overview document requires much less effort than enhancing an > established standard. This is fine now. We will delete this paragraph before publication, right? >2. Terminology and Definitions > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > > The following definitions have mostly been taken from [RFC3830]: If definitions are taken from 3830, please include them here verbatim. I was going to suggest that they don't need to be duplicated, but figured it's ok to include them in this kind of document. > >3. MIKEY Overview > > This section will provide an overview about the MIKEY base document. > The focus lies here on the key distribution schemes as well as the > discussion about advantages and disadvantages of the different > > > >Fries & Ignjatic Expires November 17, 2006 [Page 5] > >Internet-Draft MIKEY modes applicability May 2006 > > > schemes. Note that the MIKEY key distribution schemes rely on > loosely synchronized clocks. Thus should be realized by a secure > network clock synchronization protocol. MIKEY recommends for this > the ISO time synchronization protocol [ISO_sec_time]. The format > applied to the timestamps submitted in the MIKEY have to match the > NTP format described in [RFC1305]. In other cases, such as of a SIP > endpoint clock synchronization by deriving time from a trusted > outbound proxy may be appropriate. The time synchronization aspect probably belongs in a section of its own. >3.1. Symmetric key distribution Why not use the same name as in 3830 for the mode. > >3.2. Asymmetric key distribution > > Using the asymmetric option of the key management, the initiator > generates the key material to be transmitted and sends it encrypted > with the responder's public key. Additionally a so-called envelope > key is transmitted, encrypted with the receiver's public key. This gives the impression that two keys are being sent. Please clarify this. >The > envelope key env-key, which is a random number, is used to derive the > auth-key and the enc-key. Moreover, the envelope key is used to > protect the signaling message and may be used as a pre-shared key to > establish further crypto sessions. The response message is optional > and may be used for mutual authentication or error signaling. > > > >Fries & Ignjatic Expires November 17, 2006 [Page 6] > >Internet-Draft MIKEY modes applicability May 2006 > > > Initiator Responder > > I_MESSAGE = > HDR, T, RAND, [IDi|CERTi], > [IDr], {SP}, KEMAC, [CHASH], > PKE, SIGNi ---> > R_MESSAGE = > [<---] HDR, T, [IDr], V > > An advantage of this approach are that the usage of self-signed > certificates can avoid PKI. Note that using self-signed certificates > may result in limited scalability and complex provisioning. Why is provisioning self-signed certs complex? > The > disadvantages comprise the necessity of a PKI for fully scalability, > the performance of the key generation just by the initiator, and no > provision of perfect forward secrecy. One issue raised about this is the requirement that the initiator know the responder's public key. Is PFS as desirable as say scalable operation? > Furthermore, the verification > of certificates may not be done in real-time. This could be the case > in scenarios where the revocation status of certificates is checked > through a further component. Note, according to [RFC3830] this > option is mandatory to implement. > >3.3. Diffie-Hellman key agreement protected with digital signatures > > The Diffie-Hellman option of the key management enables a shared > secret establishment between initiator and responder in a way where > both parties contribute to the shared secret. The Diffie-Hellman key > agreement is authenticated (and integrity protected) using digital > signatures. > > > Initiator Responder > > I_MESSAGE = > HDR, T, RAND, [IDi|CERTi], > [IDr], {SP}, DHi, SIGNi ---> > R_MESSAGE = > <--- HDR, T, [IDr|CERTr], > IDi, DHr, DHi, SIGNr > > [RFC3830] does not mandate any specific asymmetric algorithm for the > signature calculation. But, what about 6.5. Signature payload (SIGN) RSA/PKCS#1/1.5| 0 | Mandatory, PKCS #1 version 1.5 signature [PSS] >The algorithm used for signature or public > key encryption is rather defined by, and dependent on the certificate > used. Besides the use of X.509v3 certificates it is mandatory to > support the Diffie-Hellmann group "OAKLEY5" [RFC2412]. The > advantages of this approach are a fair, mutual key agreement, perfect Not sure about the fair, but I guess what you mean is that the two parties contribute to the key generation where as in the PSK and RSA modes the Initiator provides the key. > forward secrecy, and the option to use self-signed certificates to > avoid PKI (would result in limited scalability and more complex > provisioning). Negatively to remark is that this approach just > scales to point-to-point groups and depends on PKI for full > > > >Fries & Ignjatic Expires November 17, 2006 [Page 7] > >Internet-Draft MIKEY modes applicability May 2006 > > > scalability. Moreover, it has a limited performance since expensive, > non-real time certificate validation has to be done. What about conferencing support? >3.4. Unprotected key distribution > > MIKEY also supports a mode to provide a key in an unprotected manner. > This is based on the pre-shared key option depicted in Section 3.1 > and may be compared with the plain approach in sdescriptions > [I-D.ietf-mmusic-sdescriptions]. This MIKEY scheme is based on the > symmetric key distribution approach described in Section 3.1, but is > used with the NULL encryption and the NULL authentication algorithm. > It completely relies on the security of the underlying layer, e.g., > provided by TLS This option should be used with caution as it does Missing a period there. > not protect the key management. > > >4. MIKEY Extensions > > This section will provide an overview about the MIKEY extensions for > key distribution schemes, crypto algorithms and payloads which have > been defined in several documents. > >4.1. Diffie-Hellman key agreement protected with pre-shared secrets > > This is an additional option which has been defined in [I-D.ietf- > msec-mikey-dhhmac]. In contrast to the method described in > Section 3.3 here the Diffie-Hellmann key agreement is authenticated > (and integrity protected) using a pre-shared secret and keyed hash > function. > > > Initiator Responder > > I_MESSAGE = > 3D HDR, T, RAND, [IDi], > IDr, {SP}, DHi, KEMAC ---> > R_MESSAGE = > <--- 3D HDR, T,[IDr], IDi, > DHr, DHi, KEMAC > > TGK =3D g^(xi * yi) TGK =3D g^(xi * yi) > > For the integrity protection of the Diffie-Hellman key agreement > [I-D.ietf-msec-mikey-dhhmac] mandates the use of HMAC SHA-1. > Regarding Diffie-Hellman groups [RFC3830] is referenced. Thus, it is > mandatory to support the Diffie-Hellman group "OAKLEY5" [RFC2412]. > This option has also several advantages, as there are the fair mutual Same comment as earlier on the notion of "fair" > key agreement, the perfect forward secrecy, and no dependency on a > > > >Fries & Ignjatic Expires November 17, 2006 [Page 8] > >Internet-Draft MIKEY modes applicability May 2006 > > > PKI and PKI standards. Moreover, this scheme has a sound performance > and reduced bandwidth requirements and provides a simple and > straightforward master key provisioning. The scalability of this > approach just to point-to-point groups is a disadvantage. Point to point communication and not groups, right? > This mode of operation provides an efficient scheme in deployments > where there is a central trusted server that is provisioned with > shared secrets for many clients. Such setups could for example be > enterprise PBXs, service provider proxies, etc. Compare this to the PSK mode. >4.2. SAML assisted DH-key agreement I am not reviewing this part for now. I would like to see the draft before we can include this. AFAIK, the following is the only specification of this mode, other than Bob's presentations. > This document [Reference to draft-moskowitz-MIKEY-SAML-DH] is > targeted to fulfill the general requirements on key management > approaches repeated here: > > 1. Mutual authentication of involved parties > 2. Both parties involved contribute to the session key generation > 3. Provide perfect forward secrecy > 4. Support distribution of group session keys > 5. Provide liveliness tests when involved parties do not have a > reliable clock > 6. Support of limited parties involved > > To fullfill all of the requirements, the document proposes the use of > a classic Diffie-Hellman key agreement protocol for key establishment > in conjunction with UA's SIP server signed element authenticating the > Diffie-Hellman key and the ID using the SAML (Security Association > Markup Language, [SAML_overview]) approach. Here the client's public > Diffie-Hellman-credentials are signed by the server to form a SAML > assertion [CRED], which may be used for later sessions with other > clients. This assertion needs at least to convey the ID, public DH > key, expiry, and the signature from the server. This provides the > involved clients with mutual authentication and message integrity of > the key management messages exchanged. > > > Initiator Responder > > I_MESSAGE = > HDR, T, RAND1, [CREDi], > IDr, {SP} ---> > R_MESSAGE = > <--- HDR, T, [CREDr], IDi, DHr, > RAND2, (SP) > TGK = HMACx(RAND1|RAND2), where x = g^(xi * xr). > > Additionally the document proposes a second roundtrip to avoid the > > > >Fries & Ignjatic Expires November 17, 2006 [Page 9] > >Internet-Draft MIKEY modes applicability May 2006 > > > dependence on synchronized clocks and provide liveliness checks. > This is achieved by exchanging nonces, protected with the session > key. This second roundtrip can also be used for distribution of > group keys or for the leverage of a weak DH key for a stronger > session key. The trigger for the second round trip would be handled > via SP, the Security Policy communicated via MIKEY. > > > Initiator Responder > > I_MESSAGE = > HDR, SIGN(ENC(RAND3)) ---> > R_MESSAGE = > <--- SIGN(ENC(RAND4)) > > Note if group keys are to be provided RAND would be substituted by > that group key. > > With the second roundtrip, this approach also provides an option for > all of the other key distribution methods, when liveliness checks are > needed. The drawback of the second roundtrip is that these messages > need to be integrated into the call flow of the signaling protocol. > In straight forward call one roundtrip may be enough to setup a > session. Thus this second roundtrip would require additional > messages to be exchanged. > >4.3. Asymmetric key distribution with in-band certificate exchange > > This is an additional option which has been defined in [I-D.ietf- > msec-mikey-rsa-r]. It describes the asymmetric key distribution with > optional in-band certificate exchange. > > > Initiator Responder > > I_MESSAGE = > HDR, T, [IDi|CERTi], [IDr], > {SP}, [RAND], SIGNi ---> > R_MESSAGE = > <--- HDR, [GenExt(CSB-ID)], T, > RAND, [IDr|CERTr], [SP], > KEMAC, SIGNr > > This option has some advantages compared to the asymmetric key > distribution stated in Section 3.2. Here, the sender and receiver do > not need to know the certificate of the other peer in advance as it > may be sent in the MIKEY initiator message. Thus, the receiver of > this message can utilize the received key material to encrypt the > > > >Fries & Ignjatic Expires November 17, 2006 [Page 10] > >Internet-Draft MIKEY modes applicability May 2006 > > > session parameter and send them back as part of the MIKEY response > message. The certificate check may be done depending on the signing > authority. If the certificate is signed by an publicly accepted > authority the certificate validation is done on the common base. In > the other case additional steps may be necessary. The disadvantage > is that no perfect forward secrecy is provided. > > This mode is meant to provide a low cost solution when PKI is present > and/or required. I am not sure what low cost means here. > >4.5. New Payload for bootstrapping TESLA > > TESLA [RFC4082] is a protocol for providing source authentication in > multicast scenarios. TESLA is an efficient protocol with low > communication and computation overhead, which scales to large numbers > of receivers, and also tolerates packet loss. TESLA is based on > loose time synchronization between the sender and the receivers. > > > >Fries & Ignjatic Expires November 17, 2006 [Page 12] > >Internet-Draft MIKEY modes applicability May 2006 > > > Source authentication is realized in TESLA by using Message > Authentication Code (MAC) chaining. The use of TESLA within the > Secure Real-time Transport Protocol (SRTP) has been published in > [RFC4383] targeting multicast authentication in scenarios, where SRTP > is applied to protect the multimedia data. This solution assumes > that TESLA parameters are made available by out-of-band mechanisms. > > [RFC4442] specifies payloads for MIKEY to bootstrap TESLA for source > authentication of secure group communications using SRTP. TESLA may > be bootstrapped using one of the MIKEY key management approaches > described above sent via unicast, multicast or broadcast. Do you mean MIKEY messages are sent via unicast, multicast or broadcast? >This > approach provides the necessary parameter payload extensions for the > usage of TESLA in SRTP but is not limited to this. I am not sure about the open-ended statement. What does it mean? >4.6. New Key ID information type I would label it as MBMS extensions to MIKEY or something like that (or a functional title). Let's discuss what's appropriate. Your first paragraph has some ideas for it. > This extension specifies a new Type (the Key ID Information Type) for > the General Extension Payload. This is used in, e.g., the Multimedia > Broadcast/Multicast Service (MBMS) specified in the 3rd Generation > Partnership Project (3GPP). MBMS requires the use of MIKEY to convey > the keys and related security parameters needed to secure the > multimedia that is multicast or broadcast. > > One of the requirements that MBMS puts on security is the possibility > to perform frequent updates of the keys. The rationale behind this > is that it should be inconvenient for subscribers to publish the > decryption keys enabling non-subscribers to view the content. To > implement this, MBMS uses a three level key management, to distribute > group keys to the clients, and be able to re-key by pushing down a > new group key. MBMS has the need to identify, which types of key are > involved in the MIKEY message, and their identity. I think the multi-level key management is not new and does not come due to the frequent updates to the TEK (or MTK to use the MBMS terminology). > [I-D.ietf-msec-newtype-keyid] specifies a new Type for the General > Extension Payload in MIKEY, to identify the type and identity of > involved keys. That draft also describes Multicast transport of MIKEY messages. Furthermore, MBMS has different semantics for the T payload. Do you want to capture those here as well? It would be good to do so. >4.7. Supporting Integrity Transform carrying the Rollover Counter > > The document [I-D.lehtovirta-srtp-rcc] defines a new integrity > transform for SRTP [RFC3711] providing the option to also transmit > the Roll Over Counter (ROC) as part of dedicated SRTP packets. This > extension has been defined for the use in the 3GPP multicast/ > broadcast service. While the communicating parties did agree on a > starting ROC, in some cases the receiver will not be able to > synchronize his ROC with the one used by the sender even if it is > signaled to him out of band. Here the new extension provides the > possibility for the receiver to re-synchronize to the sender's ROC. > To signal the use of the new integrity transform new definitions for > > > >Fries & Ignjatic Expires November 17, 2006 [Page 13] > >Internet-Draft MIKEY modes applicability May 2006 > > > certain MIKEY payloads need to be made. These MIKEY new definition > comprise the integrity transform s and new integrity transform > parameter. Moreover, the document specifies integrity parameter, to > enable the usage of different integrity transforms for SRTP and > SRTCP. Not sure about this description. I might find time to send you an alternative description later. >4.8. OMA BCAST MIKEY General Extension Payload Specification > > The document [I-D.dondeti-msec-mikey-genext-oma] specifies a new > general extension payload type for use in the Open Mobile Alliance's > (OMA) Browser and Content Broadcast (BCAST) group. OMA BCAST's > service and content protection specification uses short term key > message and long term key message payloads that in certain broadcast > distribution systems are carried in MIKEY. The document defines the > payloads for both, short term and long term key messages as part of > the general extension payload. Note, that only a parameter > description is included, but no key information. Actually the intent is to use to ask for an IANA registration for an OMA BCAST payload to be defined in OMA. We won't be defining any payloads. >5. Selection and interworking of MIKEY modes > > While MIKEY and its extensions provide plenty of choice in terms of > modes of operation an implementation may choose to simplify its > behavior. This can be achieved by operating in a single mode of > operation when in Initiator's role. Where PKI is available and/or > required an implementation may choose for example to start all > sessions in RSA-R mode but it would be trivial for it to act as a > Responder in public key mode. If envelope keys are cached it can > then also choose to do re-keying in shared key mode. In general, > modes of operation where the Initiator generates keying material are > useful when two peers are aware of each other before the MIKEY > communication takes place. If an implementation chooses not to > operate in shared key mode its behavior may be identical to a peer > that does but lacks the shared key. Similarly, if a peer chooses not > to operate in the public key mode it may reject the certificate of > the Initiator. The same applies to peers that choose to operate in > one of the DH modes exclusively. Not sure I fully understand the above. I sort of see what you are trying to say, but not sure. Perhaps you can explain how each mode can be used (a list might be better?). And also define which might bootstrap another, etc. I look at it as follows: 1. If the Initiator has a PSK with the Responder, it uses the PSK mode. 1a. If the Initiator has a PSK with the Responder, but needs PFS or knows that the responder has a policy that both parties should provide entropy to the key, then it uses the DH-HMAC mode. 2. If the Initiator has the RSA key of the Responder, it uses the RSA mode to establish the PSK or TGK or both (?). If the PSK is established, then Option 1 would be used in the future. 3. The Initiator uses RSA-R. and so on. > Forward MIKEY modes like public key or shared key mode when used in Are there other "forward" modes? How about a different name or definition of the modes where the key is supplied by the Initiator? > SIP/SDP may lead to complications in some calls scenarios, for > example forking scenarios key derivation material gets distributed to > multiple parties. This may need to analyzed per mode. Can some modes handle forking better than the others? >As mentioned earlier this may be impractical as > some of the destinations may not have the resources to validate the > message and may cause the initiator to drop the session invitation. > Even in the case all parties involved have all the prerequisites for > interpreting the MIKEY message received there is a possible problem > with multiple responders starting media sessions using the same key. > While the SSRCs will be different in most of the cases they are only > > > >Fries & Ignjatic Expires November 17, 2006 [Page 14] > >Internet-Draft MIKEY modes applicability May 2006 > > > sixteen bits long and there is a high probability of a two time pad > problem. >As suggested earlier forward modes are most useful when the > two peers are aware of each other before the communication takes > place (as is the case in key renewal scenarios when costly public key > operations can be avoided by using the envelope key). This is repetition though! > >5.2. MIKEY and Forking > > In SIP forking scenarios a SIP proxy server sends an INVITE request > to more than one location. This means that also the MIKEY payload, > which is part of the SDP is sent to several (different) locations. > MIKEY modes supporting signatures may be used in forking scenarios > (Section 3.3 and Section 4.3) as here the receiver can validate the > signature. There are limitations with the symmetric key encryption > as well as the asymmetric key encryption modes (Section 3.1 and > Section 3.2). This is due to the fact that in symmetric encryption > the recipient needs to possess the symmetric key before handling the > MIKEY data. For asymmetric MIKEY modes, if the sender is aware of > the forking he may not know in advance to which location the INVITE > is forked and thus may not use the right receiver certificate to > encrypt the MIKEY envelope key. Note, the sender may include several > MIKEY containers into the same INVITE message to cope with forking, > but this requires the knowledge of all forking targets in advance and > also requires the possession of the target certificates. It is out > of the scope of MIKEY to specify behavior in such a case. DH modes > or the Section 4.3 do not have this problem. In scenarios, where the > sender is not aware of forking, only the intended receiver is able to > decrypt the MIKEY container. Even in DH modes, there are issues: the initiator would have to process multiple DH responses (which is discussed below). > If forking is combined with early media the situation gets > aggravated. If MIKEY modes requiring full roundtrip are used, like > the signed Diffie-Hellman, multiple responses may overload the end > device. An example is forking to 30 destinations (group pickup), > while MIKEY is used with the signed Diffie-Hellman mode together with > security preconditions. Here, every target would answer with a > provisional response, leading to 30 signature validations and Diffie- > Hellman calculations at the senders site. This may lead to a > prolonged media setup delay. > >5.3. MIKEY and Call Transfer > > In a SIP environment MIKEY exchange is tied to SDP offer/answer and > irrespective of the implementation model used for call transfer the > same properties and limitations of MIKEY modes apply as in a normal > call setup scenarios. Is this a placeholder? >6. Transport of MIKEY messages > > MIKEY defines message formats to transport key information and > security policies between communicating entities. It does not define > the embedding of these messages into the used signaling protocol. > This definition is provided in separate documents, depending on the > used signaling protocol. > >Fries & Ignjatic Expires November 17, 2006 [Page 16] > >Internet-Draft MIKEY modes applicability May 2006 > > Several IETF defined protocols utilize the Session Description > Protocol (SDP, [RFC2327]) to transport the session parameters. > Examples are the Session Initiation Protocol (SIP, [RFC3261] or the > Gateway Control Protocol (GCP, [RFC3525]). The transport of MIKEY > messages as part of SDP is described in [I-D.ietf-mmusic-kmgmt-ext]. > Here, the complete MIKEY message is base64 encoded and transmitted as > part of the SDP part of the signaling protocol message. Note, as > several key distribution messages may be transported within one SDP > container, [I-D.ietf-mmusic-kmgmt-ext] also comprises an integrity > protection regarding all supplied key distribution attempts. Thus, > bidding down attacks will be recognized. > > MIKEY is also applied in ITU-T protocols like H.323, which is used to > establish communication sessions similar to SIP. For H.323 a > security framework exists, which is defined in H.235. Within this > framework H.235.7 [H.235.7] describes the usage of MIKEY and SRTP in > the context of H.323. In contrast to SIP H.323 uses ASN.1 (Abstract > Syntax Notation). Thus there is no need to encode the MIKEY > container as base64. Within H.323 the MIKEY container is binary > encoded. I think there was an allusion to MIKEY transport via multicast/broadcast earlier in the document. 3GPP specifies such transport; perhaps that can be included here? >7. Summary of MIKEY related IANA Registrations > > For MIKEY and the extensions to MIKEY IANA registrations have been > made. Here only a link to the appropriate IANA registration is > provided to avoid inconsistencies. The IANA registrations for MIKEY > payloads can be found under > http://www.iana.org/assignments/mikey-payloads These registrations > comprise the MIKEY base registrations as well as registrations made > by MIKEY extensions regarding the payload. > > The IANA registrations for MIKEY port numbers can be found under > http://www.iana.org/assignments/port-numbers (search for MIKEY). > >8. MIKEY alternatives for SRTP security parameter negotiation Perhaps this is done by other documents and shouldn't be in this document? Finally, thanks again for your work on this. I have high hopes for this document, and so I am being critical in my review. Please continue your good work and please feel free to ask for help. regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Jun 14 09:18:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqVFx-0003OY-7Q for msec-archive@lists.ietf.org; Wed, 14 Jun 2006 09:18:01 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqVFv-0001hw-TB for msec-archive@lists.ietf.org; Wed, 14 Jun 2006 09:18:01 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id A2FB12CBDA; Wed, 14 Jun 2006 09:17:59 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id F264C2CBD1 for ; Wed, 14 Jun 2006 09:17:57 -0400 (EDT) Received: (qmail 51017 invoked by uid 3269); 14 Jun 2006 13:17:57 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 51014 invoked from network); 14 Jun 2006 13:17:57 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 14 Jun 2006 13:17:57 -0000 Received: from smtp-out1.oct.nac.net (smtp-out1.oct.nac.net [209.123.233.211]) by klesh.pair.com (Postfix) with SMTP id 5B1116839A for ; Wed, 14 Jun 2006 09:17:57 -0400 (EDT) Received: (qmail 19146 invoked by uid 0); 14 Jun 2006 09:17:56 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 14 Jun 2006 09:17:56 -0400 Received: (qmail 55913 invoked from network); 14 Jun 2006 09:17:56 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 14 Jun 2006 09:17:56 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k5E9dM719386; Wed, 14 Jun 2006 05:39:22 -0400 Date: Wed, 14 Jun 2006 05:39:22 -0400 (EDT) From: George Gross To: Prashant Pillai Subject: Re: [MSEC] GSAKMP access control In-Reply-To: <4166af450606131216k3d77e25fi1b6af74933851937@mail.gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Hi Prashant, inline below... On Tue, 13 Jun 2006, Prashant Pillai wrote: > Hi All, > > > > I have some questions related to the access control mechanisms in GSAKMP: > > > > 1. What are the access control rules present in the Policy Token? What > kind of access control policy does this define? I would start by taking a look at section B.1.2 within the "Group Security Policy Token v1" specification, the ID file is: draft-ietf-msec-policy-token-sec-06.txt The "AccessControl" construct contains a sequence of include/exclusion rules. The GCKS matchs these rules against the candidate Group Member's identity to decide whether to grant a request to join the group. Other rules in the Policy Token authorize the GCKS and S-GCKS roles. > 2. Does the access control rules/policy contain the list of allowed > users? What if there are users who were not initially registered to the > multicast group but want to join later? The Group Owner decides the group membership policy, then creates a signed Policy Token and hands it off to the GCKS, who then downloads it to new group members as they arrive. When the Group Owner revises that policy, then a fresh Policy Token gets created and distributed. In GSAKMP, the Re-Key Event message multicasts this change in policy to the group membership. Therefore, the membership policy is dynamic. Of course, any of the group members who are authorized by the active Policy Token's AccessControl rules can join the group. > 3. How does the GC/KS get the user (GM) credentials to perform the > access control? The certificate path validation uses either in-band and/or out-of-band methods: 1) Inband: The user appends Certificate payload(s) to their RTJ message. See GSAKMP spec section 7.7. 2) Out of band: The GCKS may have a local certificate cache, or do an LDAP or OCSP query, or some other cert path retrieval/validation method. The Policy Token "UserCAPair" construct specifies the trusted root KeyIdentifier for each user identity. hth, George > > > > Regards > > Prashant > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Jun 14 10:16:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqWAz-00053C-82 for msec-archive@lists.ietf.org; Wed, 14 Jun 2006 10:16:57 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqUkO-00067y-56 for msec-archive@lists.ietf.org; Wed, 14 Jun 2006 08:45:24 -0400 Received: from six.pairlist.net ([209.68.2.254]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqUVp-0001cC-0f for msec-archive@lists.ietf.org; Wed, 14 Jun 2006 08:30:23 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id A67602C737; Wed, 14 Jun 2006 08:30:20 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 6247B2C6FD for ; Wed, 14 Jun 2006 08:30:19 -0400 (EDT) Received: (qmail 21807 invoked by uid 3269); 14 Jun 2006 12:30:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 21804 invoked from network); 14 Jun 2006 12:30:19 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 14 Jun 2006 12:30:19 -0000 Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) by klesh.pair.com (Postfix) with ESMTP id 0C3EF6837D for ; Wed, 14 Jun 2006 08:30:18 -0400 (EDT) Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k5ECUBpP024514; Wed, 14 Jun 2006 14:30:11 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k5ECUAh7026767; Wed, 14 Jun 2006 14:30:10 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 14:30:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] MSEC call for agenda items Date: Wed, 14 Jun 2006 14:30:08 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] MSEC call for agenda items Thread-Index: AcaNwz78j8ffv9FGQqeBiEyDC+prsQB6tgIw From: "Fries, Steffen" To: "Lakshminath Dondeti" , X-OriginalArrivalTime: 14 Jun 2006 12:30:09.0880 (UTC) FILETIME=[46A2E580:01C68FAE] Cc: canetti@watson.ibm.com X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: -2.6 (--) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Hi Laksminath,=20 I can prepare an update of the MIKEY applicability draft.=20 Regards Steffen =20 > -----Original Message----- > From: msec-bounces@securemulticast.org=20 > [mailto:msec-bounces@securemulticast.org] On Behalf Of=20 > Lakshminath Dondeti > Sent: Monday, June 12, 2006 3:55 AM > To: msec@securemulticast.org > Cc: canetti@watson.ibm.com > Subject: [MSEC] MSEC call for agenda items >=20 > MSEC is slated to meet as follows. Please note that this is=20 > from the preliminary agenda and it can change to another day=20 > or another time. We have 60 minutes of meeting time and we=20 > would like to use it for discussions and not necessarily for=20 > length updates to drafts. I encourage authors/editors to=20 > bring up interesting/contentious topics so we can discuss=20 > them at the meeting. >=20 > We are otherwise progressing well in some cases, and quite=20 > poorly in others (we hope to catch up on these). >=20 > Please send requests for presentations. Thanks. >=20 > regards, > Lakshminath >=20 > TUESDAY, July 11, 2006 >=20 > 1720-1740 Afternoon Refreshment Break - Foyer 500D 1740-1840=20 > Afternoon Session III Room=20 > 513C-FINT ml>monami6Mobile > Nodes and Multiple Interfaces in IPv6 WG Room=20 > 515INTmip > 4Mobility > for IPv4 WG > Room > 515INTpwe3Pseudo > Wire Emulation Edge to Edge WG > Room > 519BOPSo > psecOperational > Security Capabilities for IP Network Infrastructure WG Room=20 > 518ABRAI > ecritEmergency > Context Resolution with Internet Technologies WG Room=20 > 513BSECms > ecMulticast > Security WG > Room > 519ATSVrohcRobust > Header Compression WG >=20 > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec >=20 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Jun 15 06:05:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqoiu-0003iq-FN for msec-archive@lists.ietf.org; Thu, 15 Jun 2006 06:05:12 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqois-0001Px-ON for msec-archive@lists.ietf.org; Thu, 15 Jun 2006 06:05:12 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 377AB2C8BF; Thu, 15 Jun 2006 06:05:10 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id DD8422C887 for ; Thu, 15 Jun 2006 06:05:08 -0400 (EDT) Received: (qmail 70097 invoked by uid 3269); 15 Jun 2006 10:05:08 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 70094 invoked from network); 15 Jun 2006 10:05:08 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 15 Jun 2006 10:05:08 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id 3F91B6835D for ; Thu, 15 Jun 2006 06:05:08 -0400 (EDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5FA5258013461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 15 Jun 2006 03:05:03 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-56.qualcomm.com [10.50.76.56]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5FA4wGN029259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Jun 2006 03:05:00 -0700 (PDT) Message-Id: <7.0.1.0.2.20060614183840.03f5e3c0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 15 Jun 2006 03:04:55 -0700 To: Brian Weis , George Gross , "Ignjatic, Dragan" From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: msec@securemulticast.org Subject: [MSEC] Review of draft-ietf-msec-ipsec-extensions-01 X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c07eeb7900970a16fe4056cc74ae9ce2 Hi all, [Disclaimer: Reviewing as an MSEC contributor. Ran or I will have to do a "WG chair" review some time before forwarding this to the IESG.] I reviewed the first 5 sections. You have a lot of stuff on NATs and NATs are boring to me. I will review that some other time. Lakshminath >MSEC Working Group B. Weis >Internet-Draft Cisco Systems >Expires: August, 2006 G. Gross > IdentAware Security > D. Ignjatic > Polycom > February, 2006 > > Multicast Extensions to the Security Architecture for the Internet > Protocol > draft-ietf-msec-ipsec-extensions-01.txt >Abstract > > The Security Architecture for the Internet Protocol [RFC4301] > describes security services for traffic at the IP layer. That > architecture primarily defines services for Internet Protocol (IP) > unicast packets, as well as manually configured IP multicast packets. > This document further defines the security services for IP multicast > packets within that Security Architecture. I think the last sentence needs to be revised. If 4301 supports security services for manually configured IP multicast, perhaps this draft specifies dynamically keyed multicast security services using IPsec? What else? > >Table of Contents > >1.0 Introduction.......................................................2 > 1.1 Scope............................................................3 > 1.2 Terminology......................................................3 >2.0 Overview of IP Multicast Operation.................................5 >3.0 Security Association Modes.........................................5 > 3.1 Tunnel Mode with Address Preservation............................6 >4.0 Security Association...............................................7 > 4.1 Major IPsec Databases............................................7 > 4.1.1 Security Policy Database (SPD)...............................7 > 4.1.2 Security Association Database (SAD)..........................7 > 4.1.3 Peer Authorization Database (PAD)............................8 > 4.1.4 Group Security Association (GSA).............................9 GSA is not a database, is it? Perhaps this belongs in 4.1.2? > 4.2 Data Origin Authentication......................................11 > 4.3 Group SA and Key Management.....................................11 > 4.3.1 Co-Existence of Multiple Key Management Protocols...........11 > 4.3.2 New Security Association Attributes.........................12 >5.0 IP Traffic Processing.............................................12 > 5.1 Outbound IP Multicast Traffic Processing........................12 > 5.2 Inbound IP Multicast Traffic Processing.........................12 >6.0 Networking Issues.................................................12 > 6.1 Network Address Translation.....................................13 > 6.1.1 SPD Losses Synchronization with Internet Layer's State......13 > 6.1.2 Secondary Problems Created by NAT Traversal.................14 > 6.1.3 Avoidance of NAT Using an IPv6 Over IPv4 Network............15 > 6.1.4 GKMP/IPsec Multi-Realm IPv4 NAT Architecture................16 Is NAT the only issue? If so, I suggest moving 6.1 up to 6.0 level. I guess more on this in the actual text. >7.0 Security Considerations...........................................19 >8.0 IANA Considerations...............................................19 >9.0 Acknowledgements..................................................19 >10.0 References.......................................................19 > 10.1 Normative References...........................................19 > 10.2 Informative References.........................................20 >Appendix A - Multicast Application Service Models.....................22 I am not reviewing the Appendix in this round. (Too tired! :) ) > A.1 Unidirectional Multicast Applications...........................22 Is this mcast only? > A.2 Bi-directional Reliable Multicast Applications..................22 Is this mcast, with a reverse channel? > A.3 Any-To-Any Multicast Applications...............................23 Multi-sender mcast? >Author's Address......................................................24 >Intellectual Property Statement.......................................25 >Copyright Statement...................................................25 > >1.0 Introduction > > The Security Architecture for the Internet Protocol [RFC4301] > provides security services for traffic at the IP layer. It describes > > >Weis, et al. Expires August, 2006 [Page 2] > >Internet-Draft Multicast Extensions to RFC 4301 June, 2005 > >Some support for IP > packets with a multicast address in the IP destination field is > supported, but only with manual keying, and only between IPsec > devices acting as hosts. Please rewrite that sentence. The word "support" is repeated. > This document describes extensions to RFC 4301 that further define > the IPsec security architecture for groups of IPsec devices to share > SAs. In particular, it supports SAs with traffic selectors that > include a multicast address in the IP destination field, and results > in an IPsec packet with an IP multicast address in the IP destination > field. It also describes additional semantics for IPsec Group Key > Management Protocol (GKMP) Subsystems. GKMP is RFC 2093. I'd rather we not reuse that acronym. Perhaps IPsec with GSAs or something like that is more generic? >1.1 Scope > > The IPsec extensions described in this document support IPsec > Security Associations that result in IPsec packets with IPv4 or IPv6 > multicast group addresses as the destination address. Both Any-Source > Multicast (ASM) and Source-Specific Multicast (SSM) [RFC3569] > [RFC3376] group addresses are supported. > > These extensions also support Security Associations with IPv4 > Broadcast addresses that result in an IPv4 Broadcast packet, Does this mean link level or subnet level broadcast? Please clarify. > and IPv6 > Anycast addresses [RFC2526]that result in an IPv6 Anycast packet. Really? I am surprised that you are covering anycast. Will look for more details later in the I-D. > These destination address types share many of the same > characteristics of multicast addresses because there may be multiple > receivers of a packet protected by IPsec. > > The IPsec Architecture does not make requirements upon entities not s/Architecture/architecture > participating in IPsec (e.g., network devices between IPsec > endpoints). As such, these multicast extensions do not require > intermediate systems in a multicast enabled network to participate in > IPsec. In particular, no requirements are placed on the use of > multicast routing protocols (e.g., PIM-SM [RFC2362]) or multicast > admission protocols (e.g., IGMP [RFC3376]. > > All implementation models of IPsec (e.g., "bump-in-the-stack", "bump- > in-the-wire") are supported. Nice and limited scope. I like it. (Except for the anycast stuff of course). >1.2 Terminology > > > > >Weis, et al. Expires August, 2006 [Page 3] > >Internet-Draft Multicast Extensions to RFC 4301 June, 2005 > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > > > The following key terms are used throughout this document. > > Any-Source Multicast (ASM) > The Internet Protocol (IP) multicast service model as defined in > RFC 1112 [RFC1112]. In this model one or more senders source > packets to a single IP multicast address. When receivers join the > group, they receive all packets sent to that IP multicast address. > This is known as a (*,G) group. > > Group Controller Key Server (GCKS) > A Group Key Management Protocol (GKMP) server that manages IPsec Could we not use something like "A group key server that ..."? I am trying to get you to delete the use of GKMP and the notion of GKMP as a keyword in this document. > state for a group. A GCKS authenticates and provides the IPsec SA > policy and keying material to GKMP group members. > > Group Key Management Protocol (GKMP) > A key management protocol used by a GCKS to distribute IPsec > Security Association policy and keying material. A GKMP is used > when a group of IPsec devices require the same SAs. For example, > when an IPsec SA describes an IP multicast destination, the sender > and all receivers must have the group SA. Not sure about the latter part of the above para. Access controlled groups would require that all members (or receivers) to join the group via IGMP and request GSA from the GCKS. So, I don't think it really depends on the IP multicast destination (address?) per se. How about something like "members of a secure group?" > Group Key Management Protocol Subsystem > A subsystem in an IPsec device implementing a Group Key Management > Protocol. The GKMP Subsystem provides IPsec SAs to the IPsec > subsystem on the IPsec device. Why not use the notion of GSA with the third SA, the Data security SA, being the IPsec SA? 4046 would be a good guide there. > Group Member > An IPsec device that belongs to a group. A Group Member is > authorized to be a Group Speaker and/or a Group Receiver. I am not too crazy about this definition. Secure group members don't necessarily have to implement IPsec, right? > Group Owner > An administrative entity that chooses the policy for a group. > > Group Security Association (GSA) > A collection of IPsec Security Associations (SAs) and GKMP > Subsystem SAs necessary for a Group Member to receive key updates. > A GSA describes the working policy for a group. GSA is defined in 4046, no? > Group Receiver > A Group Member that is authorized to receive packets sent to a > group by a Group Speaker. > > Group Speaker > A Group Member that is authorized to send packets to a group. > > Tunnel Mode with Address Preservation > A type of IPsec tunnel mode used by security gateway > implementations when encapsulating IP multicast packets such that > they remain IP multicast packets. This mode is necessary for IP > multicast routing to correctly route IP multicast packets > protected by IPsec. This probably deserves more description, perhaps that comes latter? >2.0 Overview of IP Multicast Operation > > IP multicasting is a means of sending a single packet to a "host > group", a set of zero or more hosts identified by a single IP > destination address. IP multicast packets are UDP data packets > delivered to all members of the group with either "best-effort" > [RFC1112], or reliable delivery (e.g., NORM) [RFC3940]. > > A sender to an IP multicast group sets the destination of the packet > to an IP address allocated to be used for IP multicast. Allocated IP > multicast addresses are defined in RFC 3171 [RFC3171]. Potential > receivers of the packet "join" the IP multicast group by registering > with a network routing device, signaling its intent to receive > packets sent to a particular IP multicast group. 4291 IPv6 addressing architecture and 2375 are additional references to include here. > Network routing devices configured to pass IP multicast packets > participate in multicast routing protocols (e.g., PIM-SM) [RFC2362]. > Multicast routing protocols maintain state regarding which devices > have registered to receive packets for a particular IP multicast > group. Your sentence below is more precise than the one above. I think device level information is not kept, instead the presence of absence of receivers (one is as good as a thousand) on an interface basis is maintained. >When a router receives an IP multicast packet, it forwards a > copy of the packet out each interface for which there are known > receivers. > >3.0 Security Association Modes > > IPsec supports two modes of use: transport mode and tunnel mode. In > transport mode, IP Authentication Header (AH) [RFC4302] and IP > Encapsulating Security Payload (ESP) [RFC4303] provide protection > primarily for next layer protocols; in tunnel mode, AH and ESP are > applied to tunneled IP packets. > > A host implementation of IPsec using the multicast extensions MAY use > both transport mode and tunnel mode to encapsulate an IP multicast both or either? > >3.1 Tunnel Mode with Address Preservation I can appreciate the requirement, I think. If I am not mistaken, wouldn't there be three cases here? There could be a sender which cannot IPsec encapsulate and relies on a GW to encrypt and all members/receivers can decapsulate IPsec on their own. In the second case, a GW decapsulates for some or all members. Finally a combination of the two. Would there be implications on the GW to join the multicast in the reception case? It would also be worthwhile to have before and packet headers as in 4302 and 4303. Would header compression be possible, given that the inner and outer headers might be the same? >4.0 Security Association > >4.1 Major IPsec Databases > > The following sections describe the GKMP Subsystem and IPsec > extension interactions with the major IPsec databases. Major IPsec > databases need to be expanded in order to fully support multicast. > >4.1.1 Security Policy Database (SPD) > > SPD entries created by a GCKS may be assigned identical SPIs to SPD > entries created by IKEv2 [RFC4306]. This is not a problem for the > inbound traffic as the appropriate SAs can be matched using the > algorithm State the section number to avoid ambiguity. >described in RFC 4301. In addition, SAs with identical SPI > values but not manually keyed can be differentiated because they > contain a link to their parent SPD entries. However, the outbound > traffic needs to be matched against the SPD selectors so that the > appropriate SA can be created on packet arrival. IPsec > implementations that support multicast SHOULD use the destination Why not MUST? Please state the exceptions to the SHOULD if there are any. > address as the additional selector and match it against the SPD > entries marked "sender only". > >4.1.2 Security Association Database (SAD) > > The Security Association Database (SAD) can support multicast SAs, if > manually configured. An outbound multicast SA has the same structure > >Weis, et al. Expires August, 2006 [Page 7] > >Internet-Draft Multicast Extensions to RFC 4301 June, 2005 > > > as a unicast SA. The source address is that of the sender and the > destination address is the multicast group address. An inbound, > multicast SA must be configured with the source addresses of each > peer authorized to transmit to the multicast SA in question. The SPI > value for a multicast SA is provided by a GCKS, not by the receiver, > as for a unicast SA. This is similar to the unicast case and does not > require changes to SAD. > However, the SPD needs a mechanism for automatic multicast SA > creation. The above text seems like the text in 4301. Is this a placeholder? >4.1.3 Peer Authorization Database (PAD) > > The PAD MUST provide a management interface capability that allows an > administrator to enforce that the scope of a GKMP group's policy > specified SPD/SAD modifications are restricted to only those traffic > data flows that belong to that group. This authorization MUST be > configurable at GKMP group granularity. In the inverse direction, the > PAD management interface MUST provide a mechanism(s) to enforce that > IKEv2 security associations do not negotiate traffic selectors that > conflict or override GKMP group policies. An implementation SHOULD > offer PAD configuration capabilities that authorize the GKMP policy > configuration mechanism to set security policy for other aspects of > an endpoint's SPD/SAD configuration, not confined to its group > security associations. This capability allows the group's policy to > inhibit the creation of back channels that might otherwise leak > confidential group application data. I am not sure about the normative language above. I looked at the PAD stuff in 4301 and normative language was used quite sparingly. We should probably discuss this more. > > > - The Group Speaker's "trailing edge" SA is the oldest security > association in use by the group for that speaker. All authorized > Group Members can receive and decrypt data for this SA, but the > Group Speaker does not transmit new data using the "trailing edge" > SA after it has transitioned to the "leading edge GSA". The > trailing edge SA is deleted by the group's endpoints according to > group policy (e.g., after a defined period has elapsed)" So by this, may I assume that multiple (more than two) IPsec SAs are allowed to exist simultaneously? >Implementations MAY offer a Group > Owner management interface option to enable/disable re-key rollover > continuity for a particular group This specification requires that a Missing a period above. > GKMP/IPsec implementation MUST support at least two concurrent GSA > per Group Speaker and this re-key rollover continuity algorithm. I see that you are mandating the existence of multiple simultaneous IPsec SAs. Please make it a SHOULD. I know of at least one use case where rekeying would involve stopping transmission/reception and restarting after a new SA has been established. >4.2 Data Origin Authentication > > As defined in [RFC3401], data origin authentication is a security > service that verifies the identity of the claimed source of data. > While HMAC authentication methods are often used to provide data > origin authentication, they are not sufficient to provide data origin > authentication for groups. With an HMAC, every group member can use > the HMAC key to create a valid authentication tag whether or not they > are the authentic origin. > > When the property of data origin authentication is required for an > IPsec SA distributed from a GKCS, an authentication transform where > the originator keeps a secret should be used. Two possible algorithms > are TESLA [RFC4082] or RSA [RFC4359]. > > In some cases, (e.g., digital signature authentication transforms) > the processing cost of the algorithm is significantly greater than an > HMAC authentication method. To protect against denial of service > attacks from device that is not authorized to join the group, the > IPsec SA using this algorithm may be encapsulated with an IPsec SA > using an HMAC authentication algorithm. However, doing so requires > the packet to be sent across the IPsec boundary for additional > inbound processing [RFC4301, Section 5.2]. Not sure I understand the last two sentences. Please explain. I can appreciate the use of two auth tags, but not the concept of two IPsec SAs to do so. >4.3 Group SA and Key Management > >4.3.1 Co-Existence of Multiple Key Management Protocols > >4.3.2 New Security Association Attributes > > A number of new security association attributes are defined in this Two, really! > document. Each GKMP supporting this architecture MUST support the > following list of attributes described elsewhere in this document. > > - Address Preservation (Section 3.1). This attribute describes > whether address preservation is to be applied to the SA on the source > address, destination address, or both source and destination > addresses. > > - Direction attribute (Section 4.1.1). This attribute describes > whether the SPD direction is to be symmetric, receiver only, or > sender only. Why are these listed again? >5.0 IP Traffic Processing > > Processing of traffic follows [RFC4301, Section 5], with the > additions described below when these IP multicast extensions are > supported. All of this probably belongs earlier. I have asked earlier about hdr removal when the inner and outer addresses are the same. That was proposed elsewhere and perhaps should be considered here. >6.0 Networking Issues > > > >Weis, et al. Expires August, 2006 [Page 12] > >Internet-Draft Multicast Extensions to RFC 4301 June, 2005 > I ran out of steam here. I will do the rest some other time (may be tomorrow or something). _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Jun 15 09:01:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqrTt-0007ut-Ez for msec-archive@lists.ietf.org; Thu, 15 Jun 2006 09:01:53 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqrTr-0002Ij-L2 for msec-archive@lists.ietf.org; Thu, 15 Jun 2006 09:01:53 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 5434B2CBA2; Thu, 15 Jun 2006 09:01:51 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 99A9A2CB98 for ; Thu, 15 Jun 2006 09:01:48 -0400 (EDT) Received: (qmail 19435 invoked by uid 3269); 15 Jun 2006 13:01:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 19430 invoked from network); 15 Jun 2006 13:01:48 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 15 Jun 2006 13:01:48 -0000 Received: from smtp-out1.oct.nac.net (smtp-out1.oct.nac.net [209.123.233.211]) by klesh.pair.com (Postfix) with SMTP id 67CCF68362 for ; Thu, 15 Jun 2006 09:01:48 -0400 (EDT) Received: (qmail 91113 invoked by uid 0); 15 Jun 2006 09:01:48 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 15 Jun 2006 09:01:48 -0400 Received: (qmail 66237 invoked from network); 15 Jun 2006 09:01:46 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 15 Jun 2006 09:01:46 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k5F9N0V22966; Thu, 15 Jun 2006 05:23:00 -0400 Date: Thu, 15 Jun 2006 05:23:00 -0400 (EDT) From: George Gross To: Lakshminath Dondeti Subject: Re: [MSEC] Review of draft-ietf-msec-ipsec-extensions-01 In-Reply-To: <7.0.1.0.2.20060614183840.03f5e3c0@qualcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: George Gross , Brian Weis , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.1 (/) X-Scan-Signature: d67762704726a1bed57e7f4595960d34 Hi Lakshminath, thank you for taking the time to review the draft. in the interest of clarity, I'd like to suggest that we split our responses into separate threads, each with their own subject line. Brian, Dragan, and I will confer about our replies, and then post to the list. plz stay tuned... br George On Thu, 15 Jun 2006, Lakshminath Dondeti wrote: > Hi all, > > [Disclaimer: Reviewing as an MSEC contributor. Ran or I will have to > do a "WG chair" review some time before forwarding this to the IESG.] > > I reviewed the first 5 sections. You have a lot of stuff on NATs and > NATs are boring to me. I will review that some other time. > > Lakshminath > > >MSEC Working Group B. Weis > >Internet-Draft Cisco Systems > >Expires: August, 2006 G. Gross > > IdentAware Security > > D. Ignjatic > > Polycom > > February, 2006 > > > > Multicast Extensions to the Security Architecture for the Internet > > Protocol > > draft-ietf-msec-ipsec-extensions-01.txt > > > > > >Abstract > > > > The Security Architecture for the Internet Protocol [RFC4301] > > describes security services for traffic at the IP layer. That > > architecture primarily defines services for Internet Protocol (IP) > > unicast packets, as well as manually configured IP multicast packets. > > This document further defines the security services for IP multicast > > packets within that Security Architecture. > > I think the last sentence needs to be revised. If 4301 supports > security services for manually configured IP multicast, perhaps this > draft specifies dynamically keyed multicast security services using > IPsec? What else? > > > > > > >Table of Contents > > > >1.0 Introduction.......................................................2 > > 1.1 Scope............................................................3 > > 1.2 Terminology......................................................3 > >2.0 Overview of IP Multicast Operation.................................5 > >3.0 Security Association Modes.........................................5 > > 3.1 Tunnel Mode with Address Preservation............................6 > >4.0 Security Association...............................................7 > > 4.1 Major IPsec Databases............................................7 > > 4.1.1 Security Policy Database (SPD)...............................7 > > 4.1.2 Security Association Database (SAD)..........................7 > > 4.1.3 Peer Authorization Database (PAD)............................8 > > 4.1.4 Group Security Association (GSA).............................9 > > GSA is not a database, is it? Perhaps this belongs in 4.1.2? > > > 4.2 Data Origin Authentication......................................11 > > 4.3 Group SA and Key Management.....................................11 > > 4.3.1 Co-Existence of Multiple Key Management Protocols...........11 > > 4.3.2 New Security Association Attributes.........................12 > >5.0 IP Traffic Processing.............................................12 > > 5.1 Outbound IP Multicast Traffic Processing........................12 > > 5.2 Inbound IP Multicast Traffic Processing.........................12 > >6.0 Networking Issues.................................................12 > > 6.1 Network Address Translation.....................................13 > > 6.1.1 SPD Losses Synchronization with Internet Layer's State......13 > > 6.1.2 Secondary Problems Created by NAT Traversal.................14 > > 6.1.3 Avoidance of NAT Using an IPv6 Over IPv4 Network............15 > > 6.1.4 GKMP/IPsec Multi-Realm IPv4 NAT Architecture................16 > > Is NAT the only issue? If so, I suggest moving 6.1 up to 6.0 > level. I guess more on this in the actual text. > > >7.0 Security Considerations...........................................19 > >8.0 IANA Considerations...............................................19 > >9.0 Acknowledgements..................................................19 > >10.0 References.......................................................19 > > 10.1 Normative References...........................................19 > > 10.2 Informative References.........................................20 > >Appendix A - Multicast Application Service Models.....................22 > > I am not reviewing the Appendix in this round. (Too tired! :) ) > > > A.1 Unidirectional Multicast Applications...........................22 > > Is this mcast only? > > > A.2 Bi-directional Reliable Multicast Applications..................22 > > Is this mcast, with a reverse channel? > > > A.3 Any-To-Any Multicast Applications...............................23 > > Multi-sender mcast? > > >Author's Address......................................................24 > >Intellectual Property Statement.......................................25 > >Copyright Statement...................................................25 > > > >1.0 Introduction > > > > The Security Architecture for the Internet Protocol [RFC4301] > > provides security services for traffic at the IP layer. It describes > > > > > >Weis, et al. Expires August, 2006 [Page 2] > > > >Internet-Draft Multicast Extensions to RFC 4301 June, 2005 > > > > > >Some support for IP > > packets with a multicast address in the IP destination field is > > supported, but only with manual keying, and only between IPsec > > devices acting as hosts. > > Please rewrite that sentence. The word "support" is repeated. > > > > This document describes extensions to RFC 4301 that further define > > the IPsec security architecture for groups of IPsec devices to share > > SAs. In particular, it supports SAs with traffic selectors that > > include a multicast address in the IP destination field, and results > > in an IPsec packet with an IP multicast address in the IP destination > > field. It also describes additional semantics for IPsec Group Key > > Management Protocol (GKMP) Subsystems. > > GKMP is RFC 2093. I'd rather we not reuse that acronym. > > Perhaps IPsec with GSAs or something like that is more generic? > > > >1.1 Scope > > > > The IPsec extensions described in this document support IPsec > > Security Associations that result in IPsec packets with IPv4 or IPv6 > > multicast group addresses as the destination address. Both Any-Source > > Multicast (ASM) and Source-Specific Multicast (SSM) [RFC3569] > > [RFC3376] group addresses are supported. > > > > These extensions also support Security Associations with IPv4 > > Broadcast addresses that result in an IPv4 Broadcast packet, > > Does this mean link level or subnet level broadcast? Please clarify. > > > and IPv6 > > Anycast addresses [RFC2526]that result in an IPv6 Anycast packet. > > Really? I am surprised that you are covering anycast. Will look for > more details later in the I-D. > > > These destination address types share many of the same > > characteristics of multicast addresses because there may be multiple > > receivers of a packet protected by IPsec. > > > > The IPsec Architecture does not make requirements upon entities not > > s/Architecture/architecture > > > participating in IPsec (e.g., network devices between IPsec > > endpoints). As such, these multicast extensions do not require > > intermediate systems in a multicast enabled network to participate in > > IPsec. In particular, no requirements are placed on the use of > > multicast routing protocols (e.g., PIM-SM [RFC2362]) or multicast > > admission protocols (e.g., IGMP [RFC3376]. > > > > All implementation models of IPsec (e.g., "bump-in-the-stack", "bump- > > in-the-wire") are supported. > > Nice and limited scope. I like it. (Except for the anycast stuff of course). > > > >1.2 Terminology > > > > > > > > > >Weis, et al. Expires August, 2006 [Page 3] > > > >Internet-Draft Multicast Extensions to RFC 4301 June, 2005 > > > > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > > document are to be interpreted as described in RFC 2119 [RFC2119]. > > > > > > The following key terms are used throughout this document. > > > > Any-Source Multicast (ASM) > > The Internet Protocol (IP) multicast service model as defined in > > RFC 1112 [RFC1112]. In this model one or more senders source > > packets to a single IP multicast address. When receivers join the > > group, they receive all packets sent to that IP multicast address. > > This is known as a (*,G) group. > > > > Group Controller Key Server (GCKS) > > A Group Key Management Protocol (GKMP) server that manages IPsec > > Could we not use something like "A group key server that ..."? > > I am trying to get you to delete the use of GKMP and the notion of > GKMP as a keyword in this document. > > > state for a group. A GCKS authenticates and provides the IPsec SA > > policy and keying material to GKMP group members. > > > > Group Key Management Protocol (GKMP) > > A key management protocol used by a GCKS to distribute IPsec > > Security Association policy and keying material. A GKMP is used > > when a group of IPsec devices require the same SAs. For example, > > when an IPsec SA describes an IP multicast destination, the sender > > and all receivers must have the group SA. > > Not sure about the latter part of the above para. Access controlled > groups would require that all members (or receivers) to join the > group via IGMP and request GSA from the GCKS. So, I don't think it > really depends on the IP multicast destination (address?) per > se. How about something like "members of a secure group?" > > > > Group Key Management Protocol Subsystem > > A subsystem in an IPsec device implementing a Group Key Management > > Protocol. The GKMP Subsystem provides IPsec SAs to the IPsec > > subsystem on the IPsec device. > > Why not use the notion of GSA with the third SA, the Data security > SA, being the IPsec SA? 4046 would be a good guide there. > > > > Group Member > > An IPsec device that belongs to a group. A Group Member is > > authorized to be a Group Speaker and/or a Group Receiver. > > I am not too crazy about this definition. Secure group members don't > necessarily have to implement IPsec, right? > > > > Group Owner > > An administrative entity that chooses the policy for a group. > > > > Group Security Association (GSA) > > A collection of IPsec Security Associations (SAs) and GKMP > > Subsystem SAs necessary for a Group Member to receive key updates. > > A GSA describes the working policy for a group. > > GSA is defined in 4046, no? > > > > Group Receiver > > A Group Member that is authorized to receive packets sent to a > > group by a Group Speaker. > > > > Group Speaker > > A Group Member that is authorized to send packets to a group. > > > > > > > Tunnel Mode with Address Preservation > > A type of IPsec tunnel mode used by security gateway > > implementations when encapsulating IP multicast packets such that > > they remain IP multicast packets. This mode is necessary for IP > > multicast routing to correctly route IP multicast packets > > protected by IPsec. > > This probably deserves more description, perhaps that comes latter? > > > >2.0 Overview of IP Multicast Operation > > > > IP multicasting is a means of sending a single packet to a "host > > group", a set of zero or more hosts identified by a single IP > > destination address. IP multicast packets are UDP data packets > > delivered to all members of the group with either "best-effort" > > [RFC1112], or reliable delivery (e.g., NORM) [RFC3940]. > > > > A sender to an IP multicast group sets the destination of the packet > > to an IP address allocated to be used for IP multicast. Allocated IP > > multicast addresses are defined in RFC 3171 [RFC3171]. Potential > > receivers of the packet "join" the IP multicast group by registering > > with a network routing device, signaling its intent to receive > > packets sent to a particular IP multicast group. > > 4291 IPv6 addressing architecture and 2375 are additional references > to include here. > > > > Network routing devices configured to pass IP multicast packets > > participate in multicast routing protocols (e.g., PIM-SM) [RFC2362]. > > Multicast routing protocols maintain state regarding which devices > > have registered to receive packets for a particular IP multicast > > group. > > Your sentence below is more precise than the one above. I think > device level information is not kept, instead the presence of absence > of receivers (one is as good as a thousand) on an interface basis is > maintained. > > >When a router receives an IP multicast packet, it forwards a > > copy of the packet out each interface for which there are known > > receivers. > > > >3.0 Security Association Modes > > > > IPsec supports two modes of use: transport mode and tunnel mode. In > > transport mode, IP Authentication Header (AH) [RFC4302] and IP > > Encapsulating Security Payload (ESP) [RFC4303] provide protection > > primarily for next layer protocols; in tunnel mode, AH and ESP are > > applied to tunneled IP packets. > > > > A host implementation of IPsec using the multicast extensions MAY use > > both transport mode and tunnel mode to encapsulate an IP multicast > > both or either? > > > > > > >3.1 Tunnel Mode with Address Preservation > > I can appreciate the requirement, I think. If I am not mistaken, > wouldn't there be three cases here? There could be a sender which > cannot IPsec encapsulate and relies on a GW to encrypt and all > members/receivers can decapsulate IPsec on their own. In the second > case, a GW decapsulates for some or all members. Finally a > combination of the two. > > Would there be implications on the GW to join the multicast in the > reception case? > > It would also be worthwhile to have before and packet headers as in > 4302 and 4303. > > Would header compression be possible, given that the inner and outer > headers might be the same? > > > >4.0 Security Association > > > >4.1 Major IPsec Databases > > > > The following sections describe the GKMP Subsystem and IPsec > > extension interactions with the major IPsec databases. Major IPsec > > databases need to be expanded in order to fully support multicast. > > > >4.1.1 Security Policy Database (SPD) > > > > > > SPD entries created by a GCKS may be assigned identical SPIs to SPD > > entries created by IKEv2 [RFC4306]. This is not a problem for the > > inbound traffic as the appropriate SAs can be matched using the > > algorithm > > State the section number to avoid ambiguity. > > >described in RFC 4301. In addition, SAs with identical SPI > > values but not manually keyed can be differentiated because they > > contain a link to their parent SPD entries. However, the outbound > > traffic needs to be matched against the SPD selectors so that the > > appropriate SA can be created on packet arrival. IPsec > > implementations that support multicast SHOULD use the destination > > Why not MUST? Please state the exceptions to the SHOULD if there are any. > > > address as the additional selector and match it against the SPD > > entries marked "sender only". > > > >4.1.2 Security Association Database (SAD) > > > > The Security Association Database (SAD) can support multicast SAs, if > > manually configured. An outbound multicast SA has the same structure > > > >Weis, et al. Expires August, 2006 [Page 7] > > > >Internet-Draft Multicast Extensions to RFC 4301 June, 2005 > > > > > > as a unicast SA. The source address is that of the sender and the > > destination address is the multicast group address. An inbound, > > multicast SA must be configured with the source addresses of each > > peer authorized to transmit to the multicast SA in question. The SPI > > value for a multicast SA is provided by a GCKS, not by the receiver, > > as for a unicast SA. This is similar to the unicast case and does not > > require changes to SAD. > > However, the SPD needs a mechanism for automatic multicast SA > > creation. > > The above text seems like the text in 4301. Is this a placeholder? > > > >4.1.3 Peer Authorization Database (PAD) > > > > > > > The PAD MUST provide a management interface capability that allows an > > administrator to enforce that the scope of a GKMP group's policy > > specified SPD/SAD modifications are restricted to only those traffic > > data flows that belong to that group. This authorization MUST be > > configurable at GKMP group granularity. In the inverse direction, the > > PAD management interface MUST provide a mechanism(s) to enforce that > > IKEv2 security associations do not negotiate traffic selectors that > > conflict or override GKMP group policies. An implementation SHOULD > > offer PAD configuration capabilities that authorize the GKMP policy > > configuration mechanism to set security policy for other aspects of > > an endpoint's SPD/SAD configuration, not confined to its group > > security associations. This capability allows the group's policy to > > inhibit the creation of back channels that might otherwise leak > > confidential group application data. > > I am not sure about the normative language above. I looked at the > PAD stuff in 4301 and normative language was used quite > sparingly. We should probably discuss this more. > > > > > > > > - The Group Speaker's "trailing edge" SA is the oldest security > > association in use by the group for that speaker. All authorized > > Group Members can receive and decrypt data for this SA, but the > > Group Speaker does not transmit new data using the "trailing edge" > > SA after it has transitioned to the "leading edge GSA". The > > trailing edge SA is deleted by the group's endpoints according to > > group policy (e.g., after a defined period has elapsed)" > > So by this, may I assume that multiple (more than two) IPsec SAs are > allowed to exist simultaneously? > > > > >Implementations MAY offer a Group > > Owner management interface option to enable/disable re-key rollover > > continuity for a particular group This specification requires that a > > Missing a period above. > > > GKMP/IPsec implementation MUST support at least two concurrent GSA > > per Group Speaker and this re-key rollover continuity algorithm. > > I see that you are mandating the existence of multiple simultaneous > IPsec SAs. Please make it a SHOULD. I know of at least one use case > where rekeying would involve stopping transmission/reception and > restarting after a new SA has been established. > > > > >4.2 Data Origin Authentication > > > > As defined in [RFC3401], data origin authentication is a security > > service that verifies the identity of the claimed source of data. > > While HMAC authentication methods are often used to provide data > > origin authentication, they are not sufficient to provide data origin > > authentication for groups. With an HMAC, every group member can use > > the HMAC key to create a valid authentication tag whether or not they > > are the authentic origin. > > > > When the property of data origin authentication is required for an > > IPsec SA distributed from a GKCS, an authentication transform where > > the originator keeps a secret should be used. Two possible algorithms > > are TESLA [RFC4082] or RSA [RFC4359]. > > > > In some cases, (e.g., digital signature authentication transforms) > > the processing cost of the algorithm is significantly greater than an > > HMAC authentication method. To protect against denial of service > > attacks from device that is not authorized to join the group, the > > IPsec SA using this algorithm may be encapsulated with an IPsec SA > > using an HMAC authentication algorithm. However, doing so requires > > the packet to be sent across the IPsec boundary for additional > > inbound processing [RFC4301, Section 5.2]. > > Not sure I understand the last two sentences. Please explain. I can > appreciate the use of two auth tags, but not the concept of two IPsec > SAs to do so. > > > >4.3 Group SA and Key Management > > > >4.3.1 Co-Existence of Multiple Key Management Protocols > > > > > > >4.3.2 New Security Association Attributes > > > > A number of new security association attributes are defined in this > > Two, really! > > > document. Each GKMP supporting this architecture MUST support the > > following list of attributes described elsewhere in this document. > > > > - Address Preservation (Section 3.1). This attribute describes > > whether address preservation is to be applied to the SA on the source > > address, destination address, or both source and destination > > addresses. > > > > - Direction attribute (Section 4.1.1). This attribute describes > > whether the SPD direction is to be symmetric, receiver only, or > > sender only. > > Why are these listed again? > > > >5.0 IP Traffic Processing > > > > Processing of traffic follows [RFC4301, Section 5], with the > > additions described below when these IP multicast extensions are > > supported. > > All of this probably belongs earlier. I have asked earlier about hdr > removal when the inner and outer addresses are the same. That was > proposed elsewhere and perhaps should be considered here. > > > > >6.0 Networking Issues > > > > > > > >Weis, et al. Expires August, 2006 [Page 12] > > > >Internet-Draft Multicast Extensions to RFC 4301 June, 2005 > > > > I ran out of steam here. I will do the rest some other time (may be > tomorrow or something). > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Jun 15 14:15:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqwNp-0001S7-JF for msec-archive@lists.ietf.org; Thu, 15 Jun 2006 14:15:57 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqwNo-0002ov-Ag for msec-archive@lists.ietf.org; Thu, 15 Jun 2006 14:15:57 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 18A0E2C8EB; Thu, 15 Jun 2006 14:15:56 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id A9AA12C8AA for ; Thu, 15 Jun 2006 14:15:54 -0400 (EDT) Received: (qmail 12566 invoked by uid 3269); 15 Jun 2006 18:15:54 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 12563 invoked from network); 15 Jun 2006 18:15:54 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 15 Jun 2006 18:15:54 -0000 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by klesh.pair.com (Postfix) with ESMTP id 60960683B7 for ; Thu, 15 Jun 2006 14:15:54 -0400 (EDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 15 Jun 2006 11:15:53 -0700 X-IronPort-AV: i="4.06,137,1149490800"; d="scan'208"; a="1826384968:sNHT30094280" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k5FIFrRW026170; Thu, 15 Jun 2006 11:15:53 -0700 Received: from [128.107.163.63] (dhcp-128-107-163-63.cisco.com [128.107.163.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5FIFqCU007212; Thu, 15 Jun 2006 11:15:52 -0700 (PDT) Message-ID: <4491A3DD.9090303@cisco.com> Date: Thu, 15 Jun 2006 11:15:57 -0700 From: Brian Weis User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lakshminath Dondeti References: <7.0.1.0.2.20060614183840.03f5e3c0@qualcomm.com> In-Reply-To: <7.0.1.0.2.20060614183840.03f5e3c0@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=616; t=1150395353; x=1151259353; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bew@cisco.com; z=From:Brian=20Weis=20 |Subject:Re=3A=20Review=20of=20draft-ietf-msec-ipsec-extensions-01; X=v=3Dcisco.com=3B=20h=3DIeMpQ5zji7XPc3yvc3Q8qRyqsPY=3D; b=trtgYxCj5dpO6Bbsx7gd0wJMgdFR4Jc00/eu3hJKLPGztafd62Wl27IdYfSBsUUclCYm749j oYOT4wbRjvdlGAMnmKhNwvYgtBLfw2+H0hN7L2xazafj+jnfBZ2aulN7; Authentication-Results: sj-dkim-4.cisco.com; header.From=bew@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: George Gross , msec@securemulticast.org Subject: [MSEC] Re: Review of draft-ietf-msec-ipsec-extensions-01 X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hi Lakshminath, Thanks for the detailed review! I'll do a quick pass over them and we'll come up with answers ASAP. Quick comment on the GKMP acronym -- I don't think we knew it referred to a particular protocol and can easily change it I imagine. Thanks, Brian Lakshminath Dondeti wrote: > Hi all, > > [Disclaimer: Reviewing as an MSEC contributor. Ran or I will have to do > a "WG chair" review some time before forwarding this to the IESG.] > > I reviewed the first 5 sections. You have a lot of stuff on NATs and > NATs are boring to me. I will review that some other time. > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Jun 15 16:52:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqyox-0001wk-O4 for msec-archive@lists.ietf.org; Thu, 15 Jun 2006 16:52:07 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqyou-00024k-DQ for msec-archive@lists.ietf.org; Thu, 15 Jun 2006 16:52:07 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 2A6212C169; Thu, 15 Jun 2006 16:52:04 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 254292C163 for ; Thu, 15 Jun 2006 16:52:03 -0400 (EDT) Received: (qmail 51843 invoked by uid 3269); 15 Jun 2006 20:52:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 51840 invoked from network); 15 Jun 2006 20:52:03 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 15 Jun 2006 20:52:03 -0000 Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by klesh.pair.com (Postfix) with ESMTP id EE4BB68352 for ; Thu, 15 Jun 2006 16:52:02 -0400 (EDT) Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.12.11.20060308/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id k5FKpJHY009903; Thu, 15 Jun 2006 16:51:30 -0400 Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id k5FKoid444556; Thu, 15 Jun 2006 16:50:44 -0400 Received: from mgsmtp00.watson.ibm.com (mgsmtp00.watson.ibm.com [9.2.40.58]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id k5FKohA444554; Thu, 15 Jun 2006 16:50:43 -0400 Received: from sibylla.watson.ibm.com (sibylla.watson.ibm.com [9.2.16.101]) by mgsmtp00.watson.ibm.com (8.12.11/8.12.11/2005/09/01) with ESMTP id k5FLhfGe009292; Thu, 15 Jun 2006 17:43:41 -0400 Received: from localhost (canetti@localhost) by sibylla.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id k5FKoUu30936; Thu, 15 Jun 2006 16:50:40 -0400 Date: Thu, 15 Jun 2006 16:50:30 -0400 (EDT) From: canetti To: Vincent Roca In-Reply-To: <44914238.9000508@inrialpes.fr> Message-ID: References: <44914238.9000508@inrialpes.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: lorenzo@cisco.com, msec@securemulticast.org, canetti@csail.mit.edu, faurite@lcpc.fr Subject: [MSEC] Re: draft-ietf-msec-tesla-for-alc-norm-00.txt submission X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: canetti@csail.mit.edu List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Vincent, Overall the draft looks very good! Here are some remarks: -First line: Should say msec, not rmt. section 3.1: To avoid confusion, its probably good to say here too that the synchronization message from sender to receiver is to be signed, and the signature should be verified. 4.3.1: which fields are to be covered by the signature in the bootstrap message? regarding whether to force rejection of packets where the authentication failed (editor note on page 30). I'd try to poll the list on this issue, and perhaps reach a rough consensus. security considerations: it's perhaps worthwhile to discuss dos issues which are specific to ALC - eg, the fact that even a single corrupted packet can ruin an entire encoded stream. this also may be an argument in the discussion on the previous issue. best, Ran On Thu, 15 Jun 2006, Vincent Roca wrote: > Hello, > > I have attached to this email an update of version 00 of the MSEC WG I-D: > > The Use of TESLA in the ALC and NORM Protocols > draft-ietf-msec-tesla-for-alc-norm-00.txt > > Thanks a lot. > Regards, > > Vincent / Aurelien / Sebastien > > ------------------------------- http://planete.inrialpes.fr/~roca/ > INRIA Rhone-Alpes - projet planete vincent.roca@inrialpes.fr > Zirst; 655 av. de l'Europe; Montbonnot phone (+33) 4.76.61.52.16 > 38334 ST ISMIER cedex - France fax (+33) 4.76.61.52.52 > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Sat Jun 17 10:35:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrbtG-0004cP-Di for msec-archive@lists.ietf.org; Sat, 17 Jun 2006 10:35:10 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrZou-00020o-BB for msec-archive@lists.ietf.org; Sat, 17 Jun 2006 08:22:32 -0400 Received: from six.pairlist.net ([209.68.2.254]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FrZdd-0003Ew-DG for msec-archive@lists.ietf.org; Sat, 17 Jun 2006 08:10:56 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 4E5742C96E; Sat, 17 Jun 2006 08:10:47 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id E0BA22B807 for ; Sat, 17 Jun 2006 08:01:54 -0400 (EDT) Received: (qmail 89359 invoked by uid 3269); 17 Jun 2006 12:01:54 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 89356 invoked from network); 17 Jun 2006 12:01:54 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 17 Jun 2006 12:01:54 -0000 Received: from ozonline.com.au (mx.ozonline.com.au [203.4.248.45]) by klesh.pair.com (Postfix) with ESMTP id 86EF168382 for ; Sat, 17 Jun 2006 08:01:53 -0400 (EDT) Received: from IBM3600A6A6AC6 (adsl-syd-2-198.ozonline.com.au [202.173.193.198]) by ozonline.com.au (8.13.4/8.12.11) with SMTP id k5HC0phQ026274; Sat, 17 Jun 2006 22:00:59 +1000 Message-ID: <008a01c69205$b8042910$6401a8c0@IBM3600A6A6AC6> From: "Dan Bernardo" To: "Brian Weis" , "George Gross" , "Ignjatic, Dragan" , "Lakshminath Dondeti" References: <7.0.1.0.2.20060614183840.03f5e3c0@qualcomm.com> Subject: Re: [MSEC] Review of draft-ietf-msec-ipsec-extensions-01 Date: Sat, 17 Jun 2006 22:01:04 +1000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Cc: msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: -2.6 (--) X-Scan-Signature: d4673ea769cc9931269061744af205ce Hi, My company is in the process of implementing mltcast, but am not sure what the security issues/limitations around it. I am following this draft closely, but could not find the org draft. Can someone point/send me the org draft, relating to security issues in running multicast? Regards, Dan ----- Original Message ----- From: "Lakshminath Dondeti" To: "Brian Weis" ; "George Gross" ; "Ignjatic, Dragan" Cc: Sent: Thursday, June 15, 2006 8:04 PM Subject: [MSEC] Review of draft-ietf-msec-ipsec-extensions-01 > Hi all, > > [Disclaimer: Reviewing as an MSEC contributor. Ran or I will have to do a > "WG chair" review some time before forwarding this to the IESG.] > > I reviewed the first 5 sections. You have a lot of stuff on NATs and NATs > are boring to me. I will review that some other time. > > Lakshminath > >>MSEC Working Group B. Weis >>Internet-Draft Cisco Systems >>Expires: August, 2006 G. Gross >> IdentAware Security >> D. Ignjatic >> Polycom >> February, 2006 >> >> Multicast Extensions to the Security Architecture for the Internet >> Protocol >> draft-ietf-msec-ipsec-extensions-01.txt > > > > >>Abstract >> >> The Security Architecture for the Internet Protocol [RFC4301] >> describes security services for traffic at the IP layer. That >> architecture primarily defines services for Internet Protocol (IP) >> unicast packets, as well as manually configured IP multicast packets. >> This document further defines the security services for IP multicast >> packets within that Security Architecture. > > I think the last sentence needs to be revised. If 4301 supports security > services for manually configured IP multicast, perhaps this draft > specifies dynamically keyed multicast security services using IPsec? What > else? > >> > > >>Table of Contents >> >>1.0 Introduction.......................................................2 >> 1.1 Scope............................................................3 >> 1.2 Terminology......................................................3 >>2.0 Overview of IP Multicast Operation.................................5 >>3.0 Security Association Modes.........................................5 >> 3.1 Tunnel Mode with Address Preservation............................6 >>4.0 Security Association...............................................7 >> 4.1 Major IPsec Databases............................................7 >> 4.1.1 Security Policy Database (SPD)...............................7 >> 4.1.2 Security Association Database (SAD)..........................7 >> 4.1.3 Peer Authorization Database (PAD)............................8 >> 4.1.4 Group Security Association (GSA).............................9 > > GSA is not a database, is it? Perhaps this belongs in 4.1.2? > >> 4.2 Data Origin Authentication......................................11 >> 4.3 Group SA and Key Management.....................................11 >> 4.3.1 Co-Existence of Multiple Key Management Protocols...........11 >> 4.3.2 New Security Association Attributes.........................12 >>5.0 IP Traffic Processing.............................................12 >> 5.1 Outbound IP Multicast Traffic Processing........................12 >> 5.2 Inbound IP Multicast Traffic Processing.........................12 >>6.0 Networking Issues.................................................12 >> 6.1 Network Address Translation.....................................13 >> 6.1.1 SPD Losses Synchronization with Internet Layer's State......13 >> 6.1.2 Secondary Problems Created by NAT Traversal.................14 >> 6.1.3 Avoidance of NAT Using an IPv6 Over IPv4 Network............15 >> 6.1.4 GKMP/IPsec Multi-Realm IPv4 NAT Architecture................16 > > Is NAT the only issue? If so, I suggest moving 6.1 up to 6.0 level. I > guess more on this in the actual text. > >>7.0 Security Considerations...........................................19 >>8.0 IANA Considerations...............................................19 >>9.0 Acknowledgements..................................................19 >>10.0 References.......................................................19 >> 10.1 Normative References...........................................19 >> 10.2 Informative References.........................................20 >>Appendix A - Multicast Application Service Models.....................22 > > I am not reviewing the Appendix in this round. (Too tired! :) ) > >> A.1 Unidirectional Multicast Applications...........................22 > > Is this mcast only? > >> A.2 Bi-directional Reliable Multicast Applications..................22 > > Is this mcast, with a reverse channel? > >> A.3 Any-To-Any Multicast Applications...............................23 > > Multi-sender mcast? > >>Author's Address......................................................24 >>Intellectual Property Statement.......................................25 >>Copyright Statement...................................................25 >> >>1.0 Introduction >> >> The Security Architecture for the Internet Protocol [RFC4301] >> provides security services for traffic at the IP layer. It describes >> >> >>Weis, et al. Expires August, 2006 [Page 2] >> >>Internet-Draft Multicast Extensions to RFC 4301 June, 2005 > >> > >>Some support for IP >> packets with a multicast address in the IP destination field is >> supported, but only with manual keying, and only between IPsec >> devices acting as hosts. > > Please rewrite that sentence. The word "support" is repeated. > > >> This document describes extensions to RFC 4301 that further define >> the IPsec security architecture for groups of IPsec devices to share >> SAs. In particular, it supports SAs with traffic selectors that >> include a multicast address in the IP destination field, and results >> in an IPsec packet with an IP multicast address in the IP destination >> field. It also describes additional semantics for IPsec Group Key >> Management Protocol (GKMP) Subsystems. > > GKMP is RFC 2093. I'd rather we not reuse that acronym. > > Perhaps IPsec with GSAs or something like that is more generic? > > >>1.1 Scope >> >> The IPsec extensions described in this document support IPsec >> Security Associations that result in IPsec packets with IPv4 or IPv6 >> multicast group addresses as the destination address. Both Any-Source >> Multicast (ASM) and Source-Specific Multicast (SSM) [RFC3569] >> [RFC3376] group addresses are supported. >> >> These extensions also support Security Associations with IPv4 >> Broadcast addresses that result in an IPv4 Broadcast packet, > > Does this mean link level or subnet level broadcast? Please clarify. > >> and IPv6 >> Anycast addresses [RFC2526]that result in an IPv6 Anycast packet. > > Really? I am surprised that you are covering anycast. Will look for more > details later in the I-D. > >> These destination address types share many of the same >> characteristics of multicast addresses because there may be multiple >> receivers of a packet protected by IPsec. >> >> The IPsec Architecture does not make requirements upon entities not > > s/Architecture/architecture > >> participating in IPsec (e.g., network devices between IPsec >> endpoints). As such, these multicast extensions do not require >> intermediate systems in a multicast enabled network to participate in >> IPsec. In particular, no requirements are placed on the use of >> multicast routing protocols (e.g., PIM-SM [RFC2362]) or multicast >> admission protocols (e.g., IGMP [RFC3376]. >> >> All implementation models of IPsec (e.g., "bump-in-the-stack", "bump- >> in-the-wire") are supported. > > Nice and limited scope. I like it. (Except for the anycast stuff of > course). > > >>1.2 Terminology >> >> >> >> >>Weis, et al. Expires August, 2006 [Page 3] >> >>Internet-Draft Multicast Extensions to RFC 4301 June, 2005 >> >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> document are to be interpreted as described in RFC 2119 [RFC2119]. >> >> >> The following key terms are used throughout this document. >> >> Any-Source Multicast (ASM) >> The Internet Protocol (IP) multicast service model as defined in >> RFC 1112 [RFC1112]. In this model one or more senders source >> packets to a single IP multicast address. When receivers join the >> group, they receive all packets sent to that IP multicast address. >> This is known as a (*,G) group. >> >> Group Controller Key Server (GCKS) >> A Group Key Management Protocol (GKMP) server that manages IPsec > > Could we not use something like "A group key server that ..."? > > I am trying to get you to delete the use of GKMP and the notion of GKMP as > a keyword in this document. > >> state for a group. A GCKS authenticates and provides the IPsec SA >> policy and keying material to GKMP group members. >> >> Group Key Management Protocol (GKMP) >> A key management protocol used by a GCKS to distribute IPsec >> Security Association policy and keying material. A GKMP is used >> when a group of IPsec devices require the same SAs. For example, >> when an IPsec SA describes an IP multicast destination, the sender >> and all receivers must have the group SA. > > Not sure about the latter part of the above para. Access controlled > groups would require that all members (or receivers) to join the group via > IGMP and request GSA from the GCKS. So, I don't think it really depends > on the IP multicast destination (address?) per se. How about something > like "members of a secure group?" > > >> Group Key Management Protocol Subsystem >> A subsystem in an IPsec device implementing a Group Key Management >> Protocol. The GKMP Subsystem provides IPsec SAs to the IPsec >> subsystem on the IPsec device. > > Why not use the notion of GSA with the third SA, the Data security SA, > being the IPsec SA? 4046 would be a good guide there. > > >> Group Member >> An IPsec device that belongs to a group. A Group Member is >> authorized to be a Group Speaker and/or a Group Receiver. > > I am not too crazy about this definition. Secure group members don't > necessarily have to implement IPsec, right? > > >> Group Owner >> An administrative entity that chooses the policy for a group. >> >> Group Security Association (GSA) >> A collection of IPsec Security Associations (SAs) and GKMP >> Subsystem SAs necessary for a Group Member to receive key updates. >> A GSA describes the working policy for a group. > > GSA is defined in 4046, no? > > >> Group Receiver >> A Group Member that is authorized to receive packets sent to a >> group by a Group Speaker. >> >> Group Speaker >> A Group Member that is authorized to send packets to a group. > >> > > >> Tunnel Mode with Address Preservation >> A type of IPsec tunnel mode used by security gateway >> implementations when encapsulating IP multicast packets such that >> they remain IP multicast packets. This mode is necessary for IP >> multicast routing to correctly route IP multicast packets >> protected by IPsec. > > This probably deserves more description, perhaps that comes latter? > > >>2.0 Overview of IP Multicast Operation >> >> IP multicasting is a means of sending a single packet to a "host >> group", a set of zero or more hosts identified by a single IP >> destination address. IP multicast packets are UDP data packets >> delivered to all members of the group with either "best-effort" >> [RFC1112], or reliable delivery (e.g., NORM) [RFC3940]. >> >> A sender to an IP multicast group sets the destination of the packet >> to an IP address allocated to be used for IP multicast. Allocated IP >> multicast addresses are defined in RFC 3171 [RFC3171]. Potential >> receivers of the packet "join" the IP multicast group by registering >> with a network routing device, signaling its intent to receive >> packets sent to a particular IP multicast group. > > 4291 IPv6 addressing architecture and 2375 are additional references to > include here. > > >> Network routing devices configured to pass IP multicast packets >> participate in multicast routing protocols (e.g., PIM-SM) [RFC2362]. >> Multicast routing protocols maintain state regarding which devices >> have registered to receive packets for a particular IP multicast >> group. > > Your sentence below is more precise than the one above. I think device > level information is not kept, instead the presence of absence of > receivers (one is as good as a thousand) on an interface basis is > maintained. > >>When a router receives an IP multicast packet, it forwards a >> copy of the packet out each interface for which there are known >> receivers. >> >>3.0 Security Association Modes >> >> IPsec supports two modes of use: transport mode and tunnel mode. In >> transport mode, IP Authentication Header (AH) [RFC4302] and IP >> Encapsulating Security Payload (ESP) [RFC4303] provide protection >> primarily for next layer protocols; in tunnel mode, AH and ESP are >> applied to tunneled IP packets. >> >> A host implementation of IPsec using the multicast extensions MAY use >> both transport mode and tunnel mode to encapsulate an IP multicast > > both or either? > >> > > >>3.1 Tunnel Mode with Address Preservation > > I can appreciate the requirement, I think. If I am not mistaken, wouldn't > there be three cases here? There could be a sender which cannot IPsec > encapsulate and relies on a GW to encrypt and all members/receivers can > decapsulate IPsec on their own. In the second case, a GW decapsulates for > some or all members. Finally a combination of the two. > > Would there be implications on the GW to join the multicast in the > reception case? > > It would also be worthwhile to have before and packet headers as in 4302 > and 4303. > > Would header compression be possible, given that the inner and outer > headers might be the same? > > >>4.0 Security Association >> >>4.1 Major IPsec Databases >> >> The following sections describe the GKMP Subsystem and IPsec >> extension interactions with the major IPsec databases. Major IPsec >> databases need to be expanded in order to fully support multicast. >> >>4.1.1 Security Policy Database (SPD) > >> > >> SPD entries created by a GCKS may be assigned identical SPIs to SPD >> entries created by IKEv2 [RFC4306]. This is not a problem for the >> inbound traffic as the appropriate SAs can be matched using the >> algorithm > > State the section number to avoid ambiguity. > >>described in RFC 4301. In addition, SAs with identical SPI >> values but not manually keyed can be differentiated because they >> contain a link to their parent SPD entries. However, the outbound >> traffic needs to be matched against the SPD selectors so that the >> appropriate SA can be created on packet arrival. IPsec >> implementations that support multicast SHOULD use the destination > > Why not MUST? Please state the exceptions to the SHOULD if there are any. > >> address as the additional selector and match it against the SPD >> entries marked "sender only". >> >>4.1.2 Security Association Database (SAD) >> >> The Security Association Database (SAD) can support multicast SAs, if >> manually configured. An outbound multicast SA has the same structure >> >>Weis, et al. Expires August, 2006 [Page 7] >> >>Internet-Draft Multicast Extensions to RFC 4301 June, 2005 >> >> >> as a unicast SA. The source address is that of the sender and the >> destination address is the multicast group address. An inbound, >> multicast SA must be configured with the source addresses of each >> peer authorized to transmit to the multicast SA in question. The SPI >> value for a multicast SA is provided by a GCKS, not by the receiver, >> as for a unicast SA. This is similar to the unicast case and does not >> require changes to SAD. >> However, the SPD needs a mechanism for automatic multicast SA >> creation. > > The above text seems like the text in 4301. Is this a placeholder? > > >>4.1.3 Peer Authorization Database (PAD) > >> > > >> The PAD MUST provide a management interface capability that allows an >> administrator to enforce that the scope of a GKMP group's policy >> specified SPD/SAD modifications are restricted to only those traffic >> data flows that belong to that group. This authorization MUST be >> configurable at GKMP group granularity. In the inverse direction, the >> PAD management interface MUST provide a mechanism(s) to enforce that >> IKEv2 security associations do not negotiate traffic selectors that >> conflict or override GKMP group policies. An implementation SHOULD >> offer PAD configuration capabilities that authorize the GKMP policy >> configuration mechanism to set security policy for other aspects of >> an endpoint's SPD/SAD configuration, not confined to its group >> security associations. This capability allows the group's policy to >> inhibit the creation of back channels that might otherwise leak >> confidential group application data. > > I am not sure about the normative language above. I looked at the PAD > stuff in 4301 and normative language was used quite sparingly. We should > probably discuss this more. > > >> >> >> - The Group Speaker's "trailing edge" SA is the oldest security >> association in use by the group for that speaker. All authorized >> Group Members can receive and decrypt data for this SA, but the >> Group Speaker does not transmit new data using the "trailing edge" >> SA after it has transitioned to the "leading edge GSA". The >> trailing edge SA is deleted by the group's endpoints according to >> group policy (e.g., after a defined period has elapsed)" > > So by this, may I assume that multiple (more than two) IPsec SAs are > allowed to exist simultaneously? > > > >>Implementations MAY offer a Group >> Owner management interface option to enable/disable re-key rollover >> continuity for a particular group This specification requires that a > > Missing a period above. > >> GKMP/IPsec implementation MUST support at least two concurrent GSA >> per Group Speaker and this re-key rollover continuity algorithm. > > I see that you are mandating the existence of multiple simultaneous IPsec > SAs. Please make it a SHOULD. I know of at least one use case where > rekeying would involve stopping transmission/reception and restarting > after a new SA has been established. > > > >>4.2 Data Origin Authentication >> >> As defined in [RFC3401], data origin authentication is a security >> service that verifies the identity of the claimed source of data. >> While HMAC authentication methods are often used to provide data >> origin authentication, they are not sufficient to provide data origin >> authentication for groups. With an HMAC, every group member can use >> the HMAC key to create a valid authentication tag whether or not they >> are the authentic origin. >> >> When the property of data origin authentication is required for an >> IPsec SA distributed from a GKCS, an authentication transform where >> the originator keeps a secret should be used. Two possible algorithms >> are TESLA [RFC4082] or RSA [RFC4359]. >> >> In some cases, (e.g., digital signature authentication transforms) >> the processing cost of the algorithm is significantly greater than an >> HMAC authentication method. To protect against denial of service >> attacks from device that is not authorized to join the group, the >> IPsec SA using this algorithm may be encapsulated with an IPsec SA >> using an HMAC authentication algorithm. However, doing so requires >> the packet to be sent across the IPsec boundary for additional >> inbound processing [RFC4301, Section 5.2]. > > Not sure I understand the last two sentences. Please explain. I can > appreciate the use of two auth tags, but not the concept of two IPsec SAs > to do so. > > >>4.3 Group SA and Key Management >> >>4.3.1 Co-Existence of Multiple Key Management Protocols > >> > > >>4.3.2 New Security Association Attributes >> >> A number of new security association attributes are defined in this > > Two, really! > >> document. Each GKMP supporting this architecture MUST support the >> following list of attributes described elsewhere in this document. >> >> - Address Preservation (Section 3.1). This attribute describes >> whether address preservation is to be applied to the SA on the source >> address, destination address, or both source and destination >> addresses. >> >> - Direction attribute (Section 4.1.1). This attribute describes >> whether the SPD direction is to be symmetric, receiver only, or >> sender only. > > Why are these listed again? > > >>5.0 IP Traffic Processing >> >> Processing of traffic follows [RFC4301, Section 5], with the >> additions described below when these IP multicast extensions are >> supported. > > All of this probably belongs earlier. I have asked earlier about hdr > removal when the inner and outer addresses are the same. That was > proposed elsewhere and perhaps should be considered here. > > > >>6.0 Networking Issues >> >> >> >>Weis, et al. Expires August, 2006 [Page 12] >> >>Internet-Draft Multicast Extensions to RFC 4301 June, 2005 >> > > I ran out of steam here. I will do the rest some other time (may be > tomorrow or something). > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > > _____________________________________________________ > This mail has been virus scanned by Australia On Line > see http://www.australiaonline.net.au/mailscanning > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From brown_4_bbc@yahoo.co.jp Sun Jun 18 21:18:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fs8PS-00054p-UZ for msec-archive@megatron.ietf.org; Sun, 18 Jun 2006 21:18:34 -0400 Received: from [221.122.131.224] (helo=megatron.ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fs8PR-0001Yp-7I for msec-archive@megatron.ietf.org; Sun, 18 Jun 2006 21:18:34 -0400 To: From: =?iso-2022-jp?B?cXFx?= Subject: =?iso-2022-jp?B?GyRCISFCZ0pRJCpCVCQ/JDskJCQ/JDckXiQ3JD8bKEI=?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.9 (+++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d $B9b5iIX?M$H$NL5NA$N=P2q$$$rDs6!$7$F$^$9!#(B $B=w@-$OEPO?NA(B3$BK|1_!"CK@-$OL5NA$H$J$C$F$^$9$N$G!"??7u$J=w@-$7(B $B$+$*$j$^$;$s!#(B $B$9$Y$F$N%;%l%V$,4i2hA|$rE:$($F%a%k%"%I$b:\$;$F$*BT$A$G$9!#(B $B$*6b$O$"$k$,0&$K7C$^$l$J$$=w@-C#$r?HBN$GL~$7$F$"$2$F$/$@$5$$!#(B $B7n(B1$B!A(B3$B2s$N%G!<%H$G7n(B30$B$N5U%5%]$,:GDc8B$N%i%$%s$J$N$G!"(B $B=w@-$K$h$C$F$O$=$l0J>e$N5U%5%]$,4|BT$G$-$^$9$h(B(o^-') $B!!(B $B!!(Bhttp://rrnj.com?plll $B$5$i$K!"??7u$J8r:]$r4uK>$5$l$kJ}$N$?$a$K!"L5NA$G5.J}$N$*=;$^(B $B$$$N6a$/$N=w@-%;%l%V$rL5NA$G8!:w$9$k?7$7$$$4>R2p%5!<%S%9$rDs(B $B6!$$$?$7$^$9!#(B $B!!(B $B!!(Bhttp://rrnj.com?plll $B:#$J$i2q0wHq!&G/2qHqEy0l@ZL5NA!*(B $B$5$i$K(B6,500$B1_J,$NL5NA%]%$%s%H$r%W%l%<%s%H!*(B $B$*; Mon, 19 Jun 2006 05:42:34 -0400 (EDT) Received: (qmail 16167 invoked by uid 3269); 19 Jun 2006 09:42:34 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 16164 invoked from network); 19 Jun 2006 09:42:34 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 19 Jun 2006 09:42:34 -0000 Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by klesh.pair.com (Postfix) with ESMTP id 4DC166836B for ; Mon, 19 Jun 2006 05:42:34 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id l24so1107102nfc for ; Mon, 19 Jun 2006 02:42:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=OaGzA6wtj6OxvYZQmwmhYq1bCilVTtPfARlXc9MHcA7oBXQUddAI4ndjRm0gLQW2LG8T5ozdaM6FXU7VDSWi0YWfLxMcwkHi9FWTh/4VVSOoPIGFHFjti8Xc4BcORqfpzBD6k6Es/2LEvP4xYYgGTrV25Z6jkZXk+AsGUd2W/wI= Received: by 10.48.222.12 with SMTP id u12mr4390901nfg; Mon, 19 Jun 2006 02:42:33 -0700 (PDT) Received: by 10.49.92.4 with HTTP; Mon, 19 Jun 2006 02:42:33 -0700 (PDT) Message-ID: <4166af450606190242u5e0e6446p904b0b4240e398ae@mail.gmail.com> Date: Mon, 19 Jun 2006 10:42:33 +0100 From: "Prashant Pillai" To: "George Gross" Subject: Re: [MSEC] GSAKMP access control In-Reply-To: MIME-Version: 1.0 References: <4166af450606131216k3d77e25fi1b6af74933851937@mail.gmail.com> Cc: msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1385877401==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 --===============1385877401== Content-Type: multipart/alternative; boundary="----=_Part_132536_26811532.1150710153041" ------=_Part_132536_26811532.1150710153041 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi George, Thanx for your reply. Some more doubts. see inline On 6/14/06, George Gross wrote: > > Hi Prashant, > > inline below... > > On Tue, 13 Jun 2006, Prashant Pillai wrote: > > > Hi All, > > > > > > > > I have some questions related to the access control mechanisms in > GSAKMP: > > > > > > > > 1. What are the access control rules present in the Policy Token? > What > > kind of access control policy does this define? > > I would start by taking a look at section B.1.2 within the "Group Security > Policy Token v1" specification, the ID file is: > > draft-ietf-msec-policy-token-sec-06.txt > > The "AccessControl" construct contains a sequence of include/exclusion > rules. The GCKS matchs these rules against the candidate Group Member's > identity to decide whether to grant a request to join the group. > > Other rules in the Policy Token authorize the GCKS and S-GCKS roles. I have read this section. But what does the permissions rules signify? Also regarding the accessrule, which is a sequence of UserCApairs, what is this GSAKMPID (which denotes the groupentity)? Who assigns this? CA is the certifying authority..right? > 2. Does the access control rules/policy contain the list of allowed > > users? What if there are users who were not initially registered to the > > multicast group but want to join later? > > The Group Owner decides the group membership policy, then creates a signed > Policy Token and hands it off to the GCKS, This (the GO passing the policy to the GCKS) is not done using GSAKMP message..right? who then downloads it to new > group members as they arrive. When the Group Owner revises that policy, > then a fresh Policy Token gets created and distributed. In GSAKMP, the > Re-Key Event message multicasts this change in policy to the group > membership. Therefore, the membership policy is dynamic. The rey-key is even os only from GC/KS to GM and not from GO(as in the previous question)? Of course, any of the group members who are authorized by the active > Policy Token's AccessControl rules can join the group. > > > > 3. How does the GC/KS get the user (GM) credentials to perform the > > access control? > > The certificate path validation uses either in-band and/or out-of-band > methods: > > 1) Inband: The user appends Certificate payload(s) to their RTJ message. > See GSAKMP spec section 7.7. > > 2) Out of band: The GCKS may have a local certificate cache, or do an LDAP > or OCSP query, or some other cert path retrieval/validation method. > > The Policy Token "UserCAPair" construct specifies the trusted root > KeyIdentifier for each user identity. > > hth, > George > > > > > > > > > Regards > > > > Prashant > > > > Regards Prashant Pillai ------=_Part_132536_26811532.1150710153041 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi George,
 
Thanx for your reply.
 
Some more doubts. see inline

 
On 6/14/06, George Gross <gmgross@nac.net> wrote:
Hi Prashant,

inline below...

On Tue, 13 Jun 2006, Prashant Pillai wrote:

> Hi All,
>
>
>
> I have some questions related to the access control mechanisms in GSAKMP:
>
>
>
> 1.      What are the access control rules present in the Policy Token? What
> kind of access control policy does this define?

I would start by taking a look at section B.1.2 within the "Group Security
Policy Token v1"  specification, the ID file is:

draft-ietf-msec-policy-token-sec-06.txt

The "AccessControl" construct contains a sequence of include/exclusion
rules. The GCKS matchs these rules against the candidate Group Member's
identity to decide whether to grant a request to join the group.

Other rules in the Policy Token authorize the GCKS and S-GCKS roles.
 
I have read this section. But what does the permissions rules signify? Also regarding the accessrule, which is a sequence of UserCApairs, what is this GSAKMPID (which denotes the groupentity)? Who assigns this? CA is the certifying authority..right?

> 2.      Does the access control rules/policy contain the list of allowed
> users? What if there are users who were not initially registered to the
> multicast group but want to join later?

The Group Owner decides the group membership policy, then creates a signed
Policy Token and hands it off to the GCKS,
 
This (the GO passing the policy to the GCKS) is not done using GSAKMP message..right?

who then downloads it to new
group members as they arrive. When the Group Owner revises that policy,
then a fresh Policy Token gets created and distributed. In GSAKMP, the
Re-Key Event message multicasts this change in policy to the group
membership. Therefore, the membership policy is dynamic.
 
The rey-key is even os only from GC/KS to GM and not from GO(as in the previous question)?

Of course, any of the group members who are authorized by the active
Policy Token's AccessControl rules can join the group.


> 3.      How does the GC/KS get the user (GM) credentials to perform the
> access control?

The certificate path validation uses either in-band and/or out-of-band
methods:

1) Inband: The user appends Certificate payload(s) to their RTJ message.
See GSAKMP spec section 7.7.

2) Out of band: The GCKS may have a local certificate cache, or do an LDAP
or OCSP query, or some other cert path retrieval/validation method.

The Policy Token "UserCAPair" construct specifies the trusted root
KeyIdentifier for each user identity.

hth,
       George

>
>
>
> Regards
>
> Prashant
>

 
 
Regards
 
Prashant Pillai
 
------=_Part_132536_26811532.1150710153041-- --===============1385877401== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --===============1385877401==-- From msec-bounces@securemulticast.org Mon Jun 19 12:30:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsMdn-0007rJ-Hp for msec-archive@lists.ietf.org; Mon, 19 Jun 2006 12:30:19 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsMdl-0000bi-4B for msec-archive@lists.ietf.org; Mon, 19 Jun 2006 12:30:19 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id B03AB2C55B; Mon, 19 Jun 2006 12:30:16 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 25D362C3C3 for ; Mon, 19 Jun 2006 12:30:15 -0400 (EDT) Received: (qmail 36728 invoked by uid 3269); 19 Jun 2006 16:30:15 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 36725 invoked from network); 19 Jun 2006 16:30:14 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 19 Jun 2006 16:30:14 -0000 Received: from smtp-out2.oct.nac.net (smtp-out2.oct.nac.net [209.123.233.212]) by klesh.pair.com (Postfix) with SMTP id B6348683B3 for ; Mon, 19 Jun 2006 12:30:14 -0400 (EDT) Received: (qmail 25448 invoked by uid 0); 19 Jun 2006 12:30:11 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 19 Jun 2006 12:30:11 -0400 Received: (qmail 96265 invoked from network); 19 Jun 2006 12:30:11 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 19 Jun 2006 12:30:11 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k5JCojc02400; Mon, 19 Jun 2006 08:50:45 -0400 Date: Mon, 19 Jun 2006 08:50:44 -0400 (EDT) From: George Gross To: Prashant Pillai Subject: Re: [MSEC] GSAKMP access control In-Reply-To: <4166af450606190242u5e0e6446p904b0b4240e398ae@mail.gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: George Gross , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Hi Prashant, inline below.... On Mon, 19 Jun 2006, Prashant Pillai wrote: > > The "AccessControl" construct contains a sequence of include/exclusion > > rules. The GCKS matchs these rules against the candidate Group Member's > > identity to decide whether to grant a request to join the group. > > > > Other rules in the Policy Token authorize the GCKS and S-GCKS roles. > > > I have read this section. But what does the permissions rules signify? The interpretation of the permission rules is application-specific, and would be specified in a profile on the GSAKMP framework. Some applications may disregard the permissions entirely, others might evaluate a RTJ Notify Payload's request for a particular type of group data access versus the permissions. > Also > regarding the accessrule, which is a sequence of UserCApairs, what is this > GSAKMPID (which denotes the groupentity)? The GSAKMPID refers to the identity asserted in the Signature Payload, as described in the GSAKMP specification section 7.8. A GSAKMPID is a 2-tuple of the form {identification type, identification value}. Take a look at the GSAKMP spec's Table 19 for the list of the identification types. > Who assigns this? Not sure what you meant by "this". The Group Owner decides on the set of UserCApairs to put into the Policy Token. The GSAKMPID identification value usually matchs either the Subject field or one of the SubjectAlternativeNames fields within a GM's end-entity public key certificate. > CA is the > certifying authority..right? Yes. > > > 2. Does the access control rules/policy contain the list of allowed > > > users? What if there are users who were not initially registered to the > > > multicast group but want to join later? > > > > The Group Owner decides the group membership policy, then creates a signed > > Policy Token and hands it off to the GCKS, > > > This (the GO passing the policy to the GCKS) is not done using GSAKMP > message..right? Correct, the transfer of the PT from GO to GCKS is through an implementation-specific trusted interface outside the scope of the standard. > > who then downloads it to new > > group members as they arrive. When the Group Owner revises that policy, > > then a fresh Policy Token gets created and distributed. In GSAKMP, the > > Re-Key Event message multicasts this change in policy to the group > > membership. Therefore, the membership policy is dynamic. > > > The rey-key is even os only from GC/KS to GM and not from GO(as in the > previous question)? The GCKS has responsibility for generating the group's key and then distributing it via the Re-Key Event multicast message. If the GCKS has a revised Policy Token from the GO, then it will include that Policy Token in the Re-Key Event message as a Policy Token payload. br, George _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Jun 19 12:37:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsMlC-0002Yl-Ec for msec-archive@lists.ietf.org; Mon, 19 Jun 2006 12:37:58 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsMlA-0001CW-Jp for msec-archive@lists.ietf.org; Mon, 19 Jun 2006 12:37:58 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 534092C93F; Mon, 19 Jun 2006 12:37:56 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 6CF6C2C606 for ; Mon, 19 Jun 2006 12:37:53 -0400 (EDT) Received: (qmail 39828 invoked by uid 3269); 19 Jun 2006 16:37:51 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 39819 invoked from network); 19 Jun 2006 16:37:50 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 19 Jun 2006 16:37:50 -0000 Received: from smtp-out1.oct.nac.net (smtp-out1.oct.nac.net [209.123.233.211]) by klesh.pair.com (Postfix) with SMTP id 062E56838D for ; Mon, 19 Jun 2006 12:37:50 -0400 (EDT) Received: (qmail 49904 invoked by uid 0); 19 Jun 2006 12:37:49 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 19 Jun 2006 12:37:49 -0400 Received: (qmail 681 invoked from network); 19 Jun 2006 12:37:47 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 19 Jun 2006 12:37:47 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k5JCwKM02411; Mon, 19 Jun 2006 08:58:20 -0400 Date: Mon, 19 Jun 2006 08:58:20 -0400 (EDT) From: George Gross To: Dan Bernardo Subject: Re: [MSEC] Review of draft-ietf-msec-ipsec-extensions-01 In-Reply-To: <008a01c69205$b8042910$6401a8c0@IBM3600A6A6AC6> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: George Gross , Brian Weis , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 2d1100b36d83fed07afbc292d8848e10 Hi Dan, inline below... On Sat, 17 Jun 2006, Dan Bernardo wrote: > Hi, > My company is in the process of implementing mltcast, but am not sure what > the security issues/limitations around it. > I am following this draft closely, but could not find the org draft. I'm not sure I know what you mean by "org draft" ;o( > Can someone point/send me the org draft, relating to security issues in > running multicast? For an overview of the secure multicast architecture, I'd suggest RFC3740. To better understand group key management, please take a look at RFC4046. If you'd like to get background on IP security, then RFC4301 and its kindred documents. To rumage through all of the prior IETF MSEC and IRTF GSEC presentations and to get other links, I'd recommend www.securemulticast.org. hth, George > > Regards, > Dan > ----- Original Message ----- > From: "Lakshminath Dondeti" > To: "Brian Weis" ; "George Gross" ; > "Ignjatic, Dragan" > Cc: > Sent: Thursday, June 15, 2006 8:04 PM > Subject: [MSEC] Review of draft-ietf-msec-ipsec-extensions-01 > > > > Hi all, > > > > [Disclaimer: Reviewing as an MSEC contributor. Ran or I will have to do a > > "WG chair" review some time before forwarding this to the IESG.] > > > > I reviewed the first 5 sections. You have a lot of stuff on NATs and NATs > > are boring to me. I will review that some other time. > > > > Lakshminath > > > >>MSEC Working Group B. Weis > >>Internet-Draft Cisco Systems > >>Expires: August, 2006 G. Gross > >> IdentAware Security > >> D. Ignjatic > >> Polycom > >> February, 2006 > >> > >> Multicast Extensions to the Security Architecture for the Internet > >> Protocol > >> draft-ietf-msec-ipsec-extensions-01.txt > > > > > > > > > >>Abstract > >> > >> The Security Architecture for the Internet Protocol [RFC4301] > >> describes security services for traffic at the IP layer. That > >> architecture primarily defines services for Internet Protocol (IP) > >> unicast packets, as well as manually configured IP multicast packets. > >> This document further defines the security services for IP multicast > >> packets within that Security Architecture. > > > > I think the last sentence needs to be revised. If 4301 supports security > > services for manually configured IP multicast, perhaps this draft > > specifies dynamically keyed multicast security services using IPsec? What > > else? > > > >> > > > > > >>Table of Contents > >> > >>1.0 Introduction.......................................................2 > >> 1.1 Scope............................................................3 > >> 1.2 Terminology......................................................3 > >>2.0 Overview of IP Multicast Operation.................................5 > >>3.0 Security Association Modes.........................................5 > >> 3.1 Tunnel Mode with Address Preservation............................6 > >>4.0 Security Association...............................................7 > >> 4.1 Major IPsec Databases............................................7 > >> 4.1.1 Security Policy Database (SPD)...............................7 > >> 4.1.2 Security Association Database (SAD)..........................7 > >> 4.1.3 Peer Authorization Database (PAD)............................8 > >> 4.1.4 Group Security Association (GSA).............................9 > > > > GSA is not a database, is it? Perhaps this belongs in 4.1.2? > > > >> 4.2 Data Origin Authentication......................................11 > >> 4.3 Group SA and Key Management.....................................11 > >> 4.3.1 Co-Existence of Multiple Key Management Protocols...........11 > >> 4.3.2 New Security Association Attributes.........................12 > >>5.0 IP Traffic Processing.............................................12 > >> 5.1 Outbound IP Multicast Traffic Processing........................12 > >> 5.2 Inbound IP Multicast Traffic Processing.........................12 > >>6.0 Networking Issues.................................................12 > >> 6.1 Network Address Translation.....................................13 > >> 6.1.1 SPD Losses Synchronization with Internet Layer's State......13 > >> 6.1.2 Secondary Problems Created by NAT Traversal.................14 > >> 6.1.3 Avoidance of NAT Using an IPv6 Over IPv4 Network............15 > >> 6.1.4 GKMP/IPsec Multi-Realm IPv4 NAT Architecture................16 > > > > Is NAT the only issue? If so, I suggest moving 6.1 up to 6.0 level. I > > guess more on this in the actual text. > > > >>7.0 Security Considerations...........................................19 > >>8.0 IANA Considerations...............................................19 > >>9.0 Acknowledgements..................................................19 > >>10.0 References.......................................................19 > >> 10.1 Normative References...........................................19 > >> 10.2 Informative References.........................................20 > >>Appendix A - Multicast Application Service Models.....................22 > > > > I am not reviewing the Appendix in this round. (Too tired! :) ) > > > >> A.1 Unidirectional Multicast Applications...........................22 > > > > Is this mcast only? > > > >> A.2 Bi-directional Reliable Multicast Applications..................22 > > > > Is this mcast, with a reverse channel? > > > >> A.3 Any-To-Any Multicast Applications...............................23 > > > > Multi-sender mcast? > > > >>Author's Address......................................................24 > >>Intellectual Property Statement.......................................25 > >>Copyright Statement...................................................25 > >> > >>1.0 Introduction > >> > >> The Security Architecture for the Internet Protocol [RFC4301] > >> provides security services for traffic at the IP layer. It describes > >> > >> > >>Weis, et al. Expires August, 2006 [Page 2] > >> > >>Internet-Draft Multicast Extensions to RFC 4301 June, 2005 > > > >> > > > >>Some support for IP > >> packets with a multicast address in the IP destination field is > >> supported, but only with manual keying, and only between IPsec > >> devices acting as hosts. > > > > Please rewrite that sentence. The word "support" is repeated. > > > > > >> This document describes extensions to RFC 4301 that further define > >> the IPsec security architecture for groups of IPsec devices to share > >> SAs. In particular, it supports SAs with traffic selectors that > >> include a multicast address in the IP destination field, and results > >> in an IPsec packet with an IP multicast address in the IP destination > >> field. It also describes additional semantics for IPsec Group Key > >> Management Protocol (GKMP) Subsystems. > > > > GKMP is RFC 2093. I'd rather we not reuse that acronym. > > > > Perhaps IPsec with GSAs or something like that is more generic? > > > > > >>1.1 Scope > >> > >> The IPsec extensions described in this document support IPsec > >> Security Associations that result in IPsec packets with IPv4 or IPv6 > >> multicast group addresses as the destination address. Both Any-Source > >> Multicast (ASM) and Source-Specific Multicast (SSM) [RFC3569] > >> [RFC3376] group addresses are supported. > >> > >> These extensions also support Security Associations with IPv4 > >> Broadcast addresses that result in an IPv4 Broadcast packet, > > > > Does this mean link level or subnet level broadcast? Please clarify. > > > >> and IPv6 > >> Anycast addresses [RFC2526]that result in an IPv6 Anycast packet. > > > > Really? I am surprised that you are covering anycast. Will look for more > > details later in the I-D. > > > >> These destination address types share many of the same > >> characteristics of multicast addresses because there may be multiple > >> receivers of a packet protected by IPsec. > >> > >> The IPsec Architecture does not make requirements upon entities not > > > > s/Architecture/architecture > > > >> participating in IPsec (e.g., network devices between IPsec > >> endpoints). As such, these multicast extensions do not require > >> intermediate systems in a multicast enabled network to participate in > >> IPsec. In particular, no requirements are placed on the use of > >> multicast routing protocols (e.g., PIM-SM [RFC2362]) or multicast > >> admission protocols (e.g., IGMP [RFC3376]. > >> > >> All implementation models of IPsec (e.g., "bump-in-the-stack", "bump- > >> in-the-wire") are supported. > > > > Nice and limited scope. I like it. (Except for the anycast stuff of > > course). > > > > > >>1.2 Terminology > >> > >> > >> > >> > >>Weis, et al. Expires August, 2006 [Page 3] > >> > >>Internet-Draft Multicast Extensions to RFC 4301 June, 2005 > >> > >> > >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > >> document are to be interpreted as described in RFC 2119 [RFC2119]. > >> > >> > >> The following key terms are used throughout this document. > >> > >> Any-Source Multicast (ASM) > >> The Internet Protocol (IP) multicast service model as defined in > >> RFC 1112 [RFC1112]. In this model one or more senders source > >> packets to a single IP multicast address. When receivers join the > >> group, they receive all packets sent to that IP multicast address. > >> This is known as a (*,G) group. > >> > >> Group Controller Key Server (GCKS) > >> A Group Key Management Protocol (GKMP) server that manages IPsec > > > > Could we not use something like "A group key server that ..."? > > > > I am trying to get you to delete the use of GKMP and the notion of GKMP as > > a keyword in this document. > > > >> state for a group. A GCKS authenticates and provides the IPsec SA > >> policy and keying material to GKMP group members. > >> > >> Group Key Management Protocol (GKMP) > >> A key management protocol used by a GCKS to distribute IPsec > >> Security Association policy and keying material. A GKMP is used > >> when a group of IPsec devices require the same SAs. For example, > >> when an IPsec SA describes an IP multicast destination, the sender > >> and all receivers must have the group SA. > > > > Not sure about the latter part of the above para. Access controlled > > groups would require that all members (or receivers) to join the group via > > IGMP and request GSA from the GCKS. So, I don't think it really depends > > on the IP multicast destination (address?) per se. How about something > > like "members of a secure group?" > > > > > >> Group Key Management Protocol Subsystem > >> A subsystem in an IPsec device implementing a Group Key Management > >> Protocol. The GKMP Subsystem provides IPsec SAs to the IPsec > >> subsystem on the IPsec device. > > > > Why not use the notion of GSA with the third SA, the Data security SA, > > being the IPsec SA? 4046 would be a good guide there. > > > > > >> Group Member > >> An IPsec device that belongs to a group. A Group Member is > >> authorized to be a Group Speaker and/or a Group Receiver. > > > > I am not too crazy about this definition. Secure group members don't > > necessarily have to implement IPsec, right? > > > > > >> Group Owner > >> An administrative entity that chooses the policy for a group. > >> > >> Group Security Association (GSA) > >> A collection of IPsec Security Associations (SAs) and GKMP > >> Subsystem SAs necessary for a Group Member to receive key updates. > >> A GSA describes the working policy for a group. > > > > GSA is defined in 4046, no? > > > > > >> Group Receiver > >> A Group Member that is authorized to receive packets sent to a > >> group by a Group Speaker. > >> > >> Group Speaker > >> A Group Member that is authorized to send packets to a group. > > > >> > > > > > >> Tunnel Mode with Address Preservation > >> A type of IPsec tunnel mode used by security gateway > >> implementations when encapsulating IP multicast packets such that > >> they remain IP multicast packets. This mode is necessary for IP > >> multicast routing to correctly route IP multicast packets > >> protected by IPsec. > > > > This probably deserves more description, perhaps that comes latter? > > > > > >>2.0 Overview of IP Multicast Operation > >> > >> IP multicasting is a means of sending a single packet to a "host > >> group", a set of zero or more hosts identified by a single IP > >> destination address. IP multicast packets are UDP data packets > >> delivered to all members of the group with either "best-effort" > >> [RFC1112], or reliable delivery (e.g., NORM) [RFC3940]. > >> > >> A sender to an IP multicast group sets the destination of the packet > >> to an IP address allocated to be used for IP multicast. Allocated IP > >> multicast addresses are defined in RFC 3171 [RFC3171]. Potential > >> receivers of the packet "join" the IP multicast group by registering > >> with a network routing device, signaling its intent to receive > >> packets sent to a particular IP multicast group. > > > > 4291 IPv6 addressing architecture and 2375 are additional references to > > include here. > > > > > >> Network routing devices configured to pass IP multicast packets > >> participate in multicast routing protocols (e.g., PIM-SM) [RFC2362]. > >> Multicast routing protocols maintain state regarding which devices > >> have registered to receive packets for a particular IP multicast > >> group. > > > > Your sentence below is more precise than the one above. I think device > > level information is not kept, instead the presence of absence of > > receivers (one is as good as a thousand) on an interface basis is > > maintained. > > > >>When a router receives an IP multicast packet, it forwards a > >> copy of the packet out each interface for which there are known > >> receivers. > >> > >>3.0 Security Association Modes > >> > >> IPsec supports two modes of use: transport mode and tunnel mode. In > >> transport mode, IP Authentication Header (AH) [RFC4302] and IP > >> Encapsulating Security Payload (ESP) [RFC4303] provide protection > >> primarily for next layer protocols; in tunnel mode, AH and ESP are > >> applied to tunneled IP packets. > >> > >> A host implementation of IPsec using the multicast extensions MAY use > >> both transport mode and tunnel mode to encapsulate an IP multicast > > > > both or either? > > > >> > > > > > >>3.1 Tunnel Mode with Address Preservation > > > > I can appreciate the requirement, I think. If I am not mistaken, wouldn't > > there be three cases here? There could be a sender which cannot IPsec > > encapsulate and relies on a GW to encrypt and all members/receivers can > > decapsulate IPsec on their own. In the second case, a GW decapsulates for > > some or all members. Finally a combination of the two. > > > > Would there be implications on the GW to join the multicast in the > > reception case? > > > > It would also be worthwhile to have before and packet headers as in 4302 > > and 4303. > > > > Would header compression be possible, given that the inner and outer > > headers might be the same? > > > > > >>4.0 Security Association > >> > >>4.1 Major IPsec Databases > >> > >> The following sections describe the GKMP Subsystem and IPsec > >> extension interactions with the major IPsec databases. Major IPsec > >> databases need to be expanded in order to fully support multicast. > >> > >>4.1.1 Security Policy Database (SPD) > > > >> > > > >> SPD entries created by a GCKS may be assigned identical SPIs to SPD > >> entries created by IKEv2 [RFC4306]. This is not a problem for the > >> inbound traffic as the appropriate SAs can be matched using the > >> algorithm > > > > State the section number to avoid ambiguity. > > > >>described in RFC 4301. In addition, SAs with identical SPI > >> values but not manually keyed can be differentiated because they > >> contain a link to their parent SPD entries. However, the outbound > >> traffic needs to be matched against the SPD selectors so that the > >> appropriate SA can be created on packet arrival. IPsec > >> implementations that support multicast SHOULD use the destination > > > > Why not MUST? Please state the exceptions to the SHOULD if there are any. > > > >> address as the additional selector and match it against the SPD > >> entries marked "sender only". > >> > >>4.1.2 Security Association Database (SAD) > >> > >> The Security Association Database (SAD) can support multicast SAs, if > >> manually configured. An outbound multicast SA has the same structure > >> > >>Weis, et al. Expires August, 2006 [Page 7] > >> > >>Internet-Draft Multicast Extensions to RFC 4301 June, 2005 > >> > >> > >> as a unicast SA. The source address is that of the sender and the > >> destination address is the multicast group address. An inbound, > >> multicast SA must be configured with the source addresses of each > >> peer authorized to transmit to the multicast SA in question. The SPI > >> value for a multicast SA is provided by a GCKS, not by the receiver, > >> as for a unicast SA. This is similar to the unicast case and does not > >> require changes to SAD. > >> However, the SPD needs a mechanism for automatic multicast SA > >> creation. > > > > The above text seems like the text in 4301. Is this a placeholder? > > > > > >>4.1.3 Peer Authorization Database (PAD) > > > >> > > > > > >> The PAD MUST provide a management interface capability that allows an > >> administrator to enforce that the scope of a GKMP group's policy > >> specified SPD/SAD modifications are restricted to only those traffic > >> data flows that belong to that group. This authorization MUST be > >> configurable at GKMP group granularity. In the inverse direction, the > >> PAD management interface MUST provide a mechanism(s) to enforce that > >> IKEv2 security associations do not negotiate traffic selectors that > >> conflict or override GKMP group policies. An implementation SHOULD > >> offer PAD configuration capabilities that authorize the GKMP policy > >> configuration mechanism to set security policy for other aspects of > >> an endpoint's SPD/SAD configuration, not confined to its group > >> security associations. This capability allows the group's policy to > >> inhibit the creation of back channels that might otherwise leak > >> confidential group application data. > > > > I am not sure about the normative language above. I looked at the PAD > > stuff in 4301 and normative language was used quite sparingly. We should > > probably discuss this more. > > > > > >> > >> > >> - The Group Speaker's "trailing edge" SA is the oldest security > >> association in use by the group for that speaker. All authorized > >> Group Members can receive and decrypt data for this SA, but the > >> Group Speaker does not transmit new data using the "trailing edge" > >> SA after it has transitioned to the "leading edge GSA". The > >> trailing edge SA is deleted by the group's endpoints according to > >> group policy (e.g., after a defined period has elapsed)" > > > > So by this, may I assume that multiple (more than two) IPsec SAs are > > allowed to exist simultaneously? > > > > > > > >>Implementations MAY offer a Group > >> Owner management interface option to enable/disable re-key rollover > >> continuity for a particular group This specification requires that a > > > > Missing a period above. > > > >> GKMP/IPsec implementation MUST support at least two concurrent GSA > >> per Group Speaker and this re-key rollover continuity algorithm. > > > > I see that you are mandating the existence of multiple simultaneous IPsec > > SAs. Please make it a SHOULD. I know of at least one use case where > > rekeying would involve stopping transmission/reception and restarting > > after a new SA has been established. > > > > > > > >>4.2 Data Origin Authentication > >> > >> As defined in [RFC3401], data origin authentication is a security > >> service that verifies the identity of the claimed source of data. > >> While HMAC authentication methods are often used to provide data > >> origin authentication, they are not sufficient to provide data origin > >> authentication for groups. With an HMAC, every group member can use > >> the HMAC key to create a valid authentication tag whether or not they > >> are the authentic origin. > >> > >> When the property of data origin authentication is required for an > >> IPsec SA distributed from a GKCS, an authentication transform where > >> the originator keeps a secret should be used. Two possible algorithms > >> are TESLA [RFC4082] or RSA [RFC4359]. > >> > >> In some cases, (e.g., digital signature authentication transforms) > >> the processing cost of the algorithm is significantly greater than an > >> HMAC authentication method. To protect against denial of service > >> attacks from device that is not authorized to join the group, the > >> IPsec SA using this algorithm may be encapsulated with an IPsec SA > >> using an HMAC authentication algorithm. However, doing so requires > >> the packet to be sent across the IPsec boundary for additional > >> inbound processing [RFC4301, Section 5.2]. > > > > Not sure I understand the last two sentences. Please explain. I can > > appreciate the use of two auth tags, but not the concept of two IPsec SAs > > to do so. > > > > > >>4.3 Group SA and Key Management > >> > >>4.3.1 Co-Existence of Multiple Key Management Protocols > > > >> > > > > > >>4.3.2 New Security Association Attributes > >> > >> A number of new security association attributes are defined in this > > > > Two, really! > > > >> document. Each GKMP supporting this architecture MUST support the > >> following list of attributes described elsewhere in this document. > >> > >> - Address Preservation (Section 3.1). This attribute describes > >> whether address preservation is to be applied to the SA on the source > >> address, destination address, or both source and destination > >> addresses. > >> > >> - Direction attribute (Section 4.1.1). This attribute describes > >> whether the SPD direction is to be symmetric, receiver only, or > >> sender only. > > > > Why are these listed again? > > > > > >>5.0 IP Traffic Processing > >> > >> Processing of traffic follows [RFC4301, Section 5], with the > >> additions described below when these IP multicast extensions are > >> supported. > > > > All of this probably belongs earlier. I have asked earlier about hdr > > removal when the inner and outer addresses are the same. That was > > proposed elsewhere and perhaps should be considered here. > > > > > > > >>6.0 Networking Issues > >> > >> > >> > >>Weis, et al. Expires August, 2006 [Page 12] > >> > >>Internet-Draft Multicast Extensions to RFC 4301 June, 2005 > >> > > > > I ran out of steam here. I will do the rest some other time (may be > > tomorrow or something). > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://six.pairlist.net/mailman/listinfo/msec > > > > _____________________________________________________ > > This mail has been virus scanned by Australia On Line > > see http://www.australiaonline.net.au/mailscanning > > > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Jun 19 15:38:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsPZX-00017d-80 for msec-archive@lists.ietf.org; Mon, 19 Jun 2006 15:38:07 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsPZV-0007O7-Vg for msec-archive@lists.ietf.org; Mon, 19 Jun 2006 15:38:07 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 5FBF92C1AC; Mon, 19 Jun 2006 15:38:05 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id B422E2BA92 for ; Mon, 19 Jun 2006 15:38:04 -0400 (EDT) Received: (qmail 2790 invoked by uid 3269); 19 Jun 2006 19:38:04 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 2786 invoked from network); 19 Jun 2006 19:38:04 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 19 Jun 2006 19:38:04 -0000 Received: from smtp-out1.oct.nac.net (smtp-out1.oct.nac.net [209.123.233.211]) by klesh.pair.com (Postfix) with SMTP id 724BD68386 for ; Mon, 19 Jun 2006 15:38:04 -0400 (EDT) Received: (qmail 20533 invoked by uid 0); 19 Jun 2006 15:38:03 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 19 Jun 2006 15:38:03 -0400 Received: (qmail 10322 invoked from network); 19 Jun 2006 15:38:02 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 19 Jun 2006 15:38:02 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k5JFwYS02947; Mon, 19 Jun 2006 11:58:34 -0400 Date: Mon, 19 Jun 2006 11:58:34 -0400 (EDT) From: George Gross To: Lakshminath Dondeti Subject: GKMP acronym, was Re: [MSEC] Review of draft-ietf-msec-ipsec-extensions-01 In-Reply-To: <7.0.1.0.2.20060614183840.03f5e3c0@qualcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: George Gross , Brian Weis , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hi Lakshminath, this e-mail focuses on your comment regarding the GKMP acronym. future e-mails will respond wrt/ to other your comments. inline below.... On Thu, 15 Jun 2006, Lakshminath Dondeti wrote: > > This document describes extensions to RFC 4301 that further define > > the IPsec security architecture for groups of IPsec devices to share > > SAs. In particular, it supports SAs with traffic selectors that > > include a multicast address in the IP destination field, and results > > in an IPsec packet with an IP multicast address in the IP destination > > field. It also describes additional semantics for IPsec Group Key > > Management Protocol (GKMP) Subsystems. > > GKMP is RFC 2093. I'd rather we not reuse that acronym. > > Perhaps IPsec with GSAs or something like that is more generic? To align with RFC4046, we will edit the MSEC IPsec extensions document to use either the term "GKM protocol" or "GKM subsystem" as appropriate. Note that RFC4046 defines the acronym "GKM" in its section 1. We will also add a qualifying sentence to say that "GKM protocol" is a generic term, not intended to refer to any particular group key management protocol. br, George _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Jun 19 17:54:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsRh2-0006r7-Rw for msec-archive@lists.ietf.org; Mon, 19 Jun 2006 17:54:00 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsRgx-0004Tw-TO for msec-archive@lists.ietf.org; Mon, 19 Jun 2006 17:54:00 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 4E0D72CBC2; Mon, 19 Jun 2006 17:53:55 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 6B08D2CB8D for ; Mon, 19 Jun 2006 17:53:53 -0400 (EDT) Received: (qmail 39298 invoked by uid 3269); 19 Jun 2006 21:53:53 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 39295 invoked from network); 19 Jun 2006 21:53:53 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 19 Jun 2006 21:53:53 -0000 Received: from ozonline.com.au (smtp.ozonline.com.au [203.4.248.46]) by klesh.pair.com (Postfix) with ESMTP id C38696836C for ; Mon, 19 Jun 2006 17:53:51 -0400 (EDT) Received: from IBM3600A6A6AC6 (adsl-syd-2-31.ozonline.com.au [202.173.193.31]) by ozonline.com.au (8.13.4/8.12.11) with SMTP id k5JLqiof002213; Tue, 20 Jun 2006 07:52:54 +1000 Message-ID: <002301c693ea$b4f80020$6401a8c0@IBM3600A6A6AC6> From: "Dan Bernardo" To: "George Gross" References: Subject: Re: [MSEC] Review of draft-ietf-msec-ipsec-extensions-01 Date: Tue, 20 Jun 2006 07:52:44 +1000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Cc: George Gross , Brian Weis , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5655aae64318292c42757ebeb53e54ce Thanks George,,, org draft = original draft ;-) Will check out the RFC's recommended. ta Dan ----- Original Message ----- From: "George Gross" To: "Dan Bernardo" Cc: "Brian Weis" ; "George Gross" ; "Ignjatic, Dragan" ; "Lakshminath Dondeti" ; Sent: Monday, June 19, 2006 10:58 PM Subject: Re: [MSEC] Review of draft-ietf-msec-ipsec-extensions-01 > Hi Dan, > > inline below... > > On Sat, 17 Jun 2006, Dan Bernardo wrote: > >> Hi, >> My company is in the process of implementing mltcast, but am not sure >> what >> the security issues/limitations around it. >> I am following this draft closely, but could not find the org draft. > > I'm not sure I know what you mean by "org draft" ;o( > >> Can someone point/send me the org draft, relating to security issues in >> running multicast? > > For an overview of the secure multicast architecture, I'd suggest RFC3740. > > To better understand group key management, please take a look at RFC4046. > > If you'd like to get background on IP security, then RFC4301 and its > kindred documents. > > To rumage through all of the prior IETF MSEC and IRTF GSEC presentations > and to get other links, I'd recommend www.securemulticast.org. > > hth, > George > >> >> Regards, >> Dan >> ----- Original Message ----- >> From: "Lakshminath Dondeti" >> To: "Brian Weis" ; "George Gross" ; >> "Ignjatic, Dragan" >> Cc: >> Sent: Thursday, June 15, 2006 8:04 PM >> Subject: [MSEC] Review of draft-ietf-msec-ipsec-extensions-01 >> >> >> > Hi all, >> > >> > [Disclaimer: Reviewing as an MSEC contributor. Ran or I will have to >> > do a >> > "WG chair" review some time before forwarding this to the IESG.] >> > >> > I reviewed the first 5 sections. You have a lot of stuff on NATs and >> > NATs >> > are boring to me. I will review that some other time. >> > >> > Lakshminath >> > >> >>MSEC Working Group B. Weis >> >>Internet-Draft Cisco Systems >> >>Expires: August, 2006 G. Gross >> >> IdentAware >> >> Security >> >> D. >> >> Ignjatic >> >> >> >> Polycom >> >> February, >> >> 2006 >> >> >> >> Multicast Extensions to the Security Architecture for the Internet >> >> Protocol >> >> draft-ietf-msec-ipsec-extensions-01.txt >> > >> > >> > >> > >> >>Abstract >> >> >> >> The Security Architecture for the Internet Protocol [RFC4301] >> >> describes security services for traffic at the IP layer. That >> >> architecture primarily defines services for Internet Protocol (IP) >> >> unicast packets, as well as manually configured IP multicast >> >> packets. >> >> This document further defines the security services for IP >> >> multicast >> >> packets within that Security Architecture. >> > >> > I think the last sentence needs to be revised. If 4301 supports >> > security >> > services for manually configured IP multicast, perhaps this draft >> > specifies dynamically keyed multicast security services using IPsec? >> > What >> > else? >> > >> >> >> > >> > >> >>Table of Contents >> >> >> >>1.0 >> >>Introduction.......................................................2 >> >> 1.1 >> >> Scope............................................................3 >> >> 1.2 >> >> Terminology......................................................3 >> >>2.0 Overview of IP Multicast >> >>Operation.................................5 >> >>3.0 Security Association >> >>Modes.........................................5 >> >> 3.1 Tunnel Mode with Address >> >> Preservation............................6 >> >>4.0 Security >> >>Association...............................................7 >> >> 4.1 Major IPsec >> >> Databases............................................7 >> >> 4.1.1 Security Policy Database >> >> (SPD)...............................7 >> >> 4.1.2 Security Association Database >> >> (SAD)..........................7 >> >> 4.1.3 Peer Authorization Database >> >> (PAD)............................8 >> >> 4.1.4 Group Security Association >> >> (GSA).............................9 >> > >> > GSA is not a database, is it? Perhaps this belongs in 4.1.2? >> > >> >> 4.2 Data Origin >> >> Authentication......................................11 >> >> 4.3 Group SA and Key >> >> Management.....................................11 >> >> 4.3.1 Co-Existence of Multiple Key Management >> >> Protocols...........11 >> >> 4.3.2 New Security Association >> >> Attributes.........................12 >> >>5.0 IP Traffic >> >>Processing.............................................12 >> >> 5.1 Outbound IP Multicast Traffic >> >> Processing........................12 >> >> 5.2 Inbound IP Multicast Traffic >> >> Processing.........................12 >> >>6.0 Networking >> >>Issues.................................................12 >> >> 6.1 Network Address >> >> Translation.....................................13 >> >> 6.1.1 SPD Losses Synchronization with Internet Layer's >> >> State......13 >> >> 6.1.2 Secondary Problems Created by NAT >> >> Traversal.................14 >> >> 6.1.3 Avoidance of NAT Using an IPv6 Over IPv4 >> >> Network............15 >> >> 6.1.4 GKMP/IPsec Multi-Realm IPv4 NAT >> >> Architecture................16 >> > >> > Is NAT the only issue? If so, I suggest moving 6.1 up to 6.0 level. I >> > guess more on this in the actual text. >> > >> >>7.0 Security >> >>Considerations...........................................19 >> >>8.0 IANA >> >>Considerations...............................................19 >> >>9.0 >> >>Acknowledgements..................................................19 >> >>10.0 >> >>References.......................................................19 >> >> 10.1 Normative >> >> References...........................................19 >> >> 10.2 Informative >> >> References.........................................20 >> >>Appendix A - Multicast Application Service >> >>Models.....................22 >> > >> > I am not reviewing the Appendix in this round. (Too tired! :) ) >> > >> >> A.1 Unidirectional Multicast >> >> Applications...........................22 >> > >> > Is this mcast only? >> > >> >> A.2 Bi-directional Reliable Multicast >> >> Applications..................22 >> > >> > Is this mcast, with a reverse channel? >> > >> >> A.3 Any-To-Any Multicast >> >> Applications...............................23 >> > >> > Multi-sender mcast? >> > >> >>Author's >> >>Address......................................................24 >> >>Intellectual Property >> >>Statement.......................................25 >> >>Copyright >> >>Statement...................................................25 >> >> >> >>1.0 Introduction >> >> >> >> The Security Architecture for the Internet Protocol [RFC4301] >> >> provides security services for traffic at the IP layer. It >> >> describes >> >> >> >> >> >>Weis, et al. Expires August, 2006 [Page 2] >> >> >> >>Internet-Draft Multicast Extensions to RFC 4301 June, 2005 >> > >> >> >> > >> >>Some support for IP >> >> packets with a multicast address in the IP destination field is >> >> supported, but only with manual keying, and only between IPsec >> >> devices acting as hosts. >> > >> > Please rewrite that sentence. The word "support" is repeated. >> > >> > >> >> This document describes extensions to RFC 4301 that further define >> >> the IPsec security architecture for groups of IPsec devices to >> >> share >> >> SAs. In particular, it supports SAs with traffic selectors that >> >> include a multicast address in the IP destination field, and >> >> results >> >> in an IPsec packet with an IP multicast address in the IP >> >> destination >> >> field. It also describes additional semantics for IPsec Group Key >> >> Management Protocol (GKMP) Subsystems. >> > >> > GKMP is RFC 2093. I'd rather we not reuse that acronym. >> > >> > Perhaps IPsec with GSAs or something like that is more generic? >> > >> > >> >>1.1 Scope >> >> >> >> The IPsec extensions described in this document support IPsec >> >> Security Associations that result in IPsec packets with IPv4 or >> >> IPv6 >> >> multicast group addresses as the destination address. Both >> >> Any-Source >> >> Multicast (ASM) and Source-Specific Multicast (SSM) [RFC3569] >> >> [RFC3376] group addresses are supported. >> >> >> >> These extensions also support Security Associations with IPv4 >> >> Broadcast addresses that result in an IPv4 Broadcast packet, >> > >> > Does this mean link level or subnet level broadcast? Please clarify. >> > >> >> and IPv6 >> >> Anycast addresses [RFC2526]that result in an IPv6 Anycast packet. >> > >> > Really? I am surprised that you are covering anycast. Will look for >> > more >> > details later in the I-D. >> > >> >> These destination address types share many of the same >> >> characteristics of multicast addresses because there may be >> >> multiple >> >> receivers of a packet protected by IPsec. >> >> >> >> The IPsec Architecture does not make requirements upon entities not >> > >> > s/Architecture/architecture >> > >> >> participating in IPsec (e.g., network devices between IPsec >> >> endpoints). As such, these multicast extensions do not require >> >> intermediate systems in a multicast enabled network to participate >> >> in >> >> IPsec. In particular, no requirements are placed on the use of >> >> multicast routing protocols (e.g., PIM-SM [RFC2362]) or multicast >> >> admission protocols (e.g., IGMP [RFC3376]. >> >> >> >> All implementation models of IPsec (e.g., "bump-in-the-stack", >> >> "bump- >> >> in-the-wire") are supported. >> > >> > Nice and limited scope. I like it. (Except for the anycast stuff of >> > course). >> > >> > >> >>1.2 Terminology >> >> >> >> >> >> >> >> >> >>Weis, et al. Expires August, 2006 [Page 3] >> >> >> >>Internet-Draft Multicast Extensions to RFC 4301 June, 2005 >> >> >> >> >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in >> >> this >> >> document are to be interpreted as described in RFC 2119 [RFC2119]. >> >> >> >> >> >> The following key terms are used throughout this document. >> >> >> >> Any-Source Multicast (ASM) >> >> The Internet Protocol (IP) multicast service model as defined in >> >> RFC 1112 [RFC1112]. In this model one or more senders source >> >> packets to a single IP multicast address. When receivers join >> >> the >> >> group, they receive all packets sent to that IP multicast >> >> address. >> >> This is known as a (*,G) group. >> >> >> >> Group Controller Key Server (GCKS) >> >> A Group Key Management Protocol (GKMP) server that manages IPsec >> > >> > Could we not use something like "A group key server that ..."? >> > >> > I am trying to get you to delete the use of GKMP and the notion of GKMP >> > as >> > a keyword in this document. >> > >> >> state for a group. A GCKS authenticates and provides the IPsec >> >> SA >> >> policy and keying material to GKMP group members. >> >> >> >> Group Key Management Protocol (GKMP) >> >> A key management protocol used by a GCKS to distribute IPsec >> >> Security Association policy and keying material. A GKMP is used >> >> when a group of IPsec devices require the same SAs. For example, >> >> when an IPsec SA describes an IP multicast destination, the >> >> sender >> >> and all receivers must have the group SA. >> > >> > Not sure about the latter part of the above para. Access controlled >> > groups would require that all members (or receivers) to join the group >> > via >> > IGMP and request GSA from the GCKS. So, I don't think it really >> > depends >> > on the IP multicast destination (address?) per se. How about something >> > like "members of a secure group?" >> > >> > >> >> Group Key Management Protocol Subsystem >> >> A subsystem in an IPsec device implementing a Group Key >> >> Management >> >> Protocol. The GKMP Subsystem provides IPsec SAs to the IPsec >> >> subsystem on the IPsec device. >> > >> > Why not use the notion of GSA with the third SA, the Data security SA, >> > being the IPsec SA? 4046 would be a good guide there. >> > >> > >> >> Group Member >> >> An IPsec device that belongs to a group. A Group Member is >> >> authorized to be a Group Speaker and/or a Group Receiver. >> > >> > I am not too crazy about this definition. Secure group members don't >> > necessarily have to implement IPsec, right? >> > >> > >> >> Group Owner >> >> An administrative entity that chooses the policy for a group. >> >> >> >> Group Security Association (GSA) >> >> A collection of IPsec Security Associations (SAs) and GKMP >> >> Subsystem SAs necessary for a Group Member to receive key >> >> updates. >> >> A GSA describes the working policy for a group. >> > >> > GSA is defined in 4046, no? >> > >> > >> >> Group Receiver >> >> A Group Member that is authorized to receive packets sent to a >> >> group by a Group Speaker. >> >> >> >> Group Speaker >> >> A Group Member that is authorized to send packets to a group. >> > >> >> >> > >> > >> >> Tunnel Mode with Address Preservation >> >> A type of IPsec tunnel mode used by security gateway >> >> implementations when encapsulating IP multicast packets such >> >> that >> >> they remain IP multicast packets. This mode is necessary for IP >> >> multicast routing to correctly route IP multicast packets >> >> protected by IPsec. >> > >> > This probably deserves more description, perhaps that comes latter? >> > >> > >> >>2.0 Overview of IP Multicast Operation >> >> >> >> IP multicasting is a means of sending a single packet to a "host >> >> group", a set of zero or more hosts identified by a single IP >> >> destination address. IP multicast packets are UDP data packets >> >> delivered to all members of the group with either "best-effort" >> >> [RFC1112], or reliable delivery (e.g., NORM) [RFC3940]. >> >> >> >> A sender to an IP multicast group sets the destination of the >> >> packet >> >> to an IP address allocated to be used for IP multicast. Allocated >> >> IP >> >> multicast addresses are defined in RFC 3171 [RFC3171]. Potential >> >> receivers of the packet "join" the IP multicast group by >> >> registering >> >> with a network routing device, signaling its intent to receive >> >> packets sent to a particular IP multicast group. >> > >> > 4291 IPv6 addressing architecture and 2375 are additional references to >> > include here. >> > >> > >> >> Network routing devices configured to pass IP multicast packets >> >> participate in multicast routing protocols (e.g., PIM-SM) >> >> [RFC2362]. >> >> Multicast routing protocols maintain state regarding which devices >> >> have registered to receive packets for a particular IP multicast >> >> group. >> > >> > Your sentence below is more precise than the one above. I think device >> > level information is not kept, instead the presence of absence of >> > receivers (one is as good as a thousand) on an interface basis is >> > maintained. >> > >> >>When a router receives an IP multicast packet, it forwards a >> >> copy of the packet out each interface for which there are known >> >> receivers. >> >> >> >>3.0 Security Association Modes >> >> >> >> IPsec supports two modes of use: transport mode and tunnel mode. >> >> In >> >> transport mode, IP Authentication Header (AH) [RFC4302] and IP >> >> Encapsulating Security Payload (ESP) [RFC4303] provide protection >> >> primarily for next layer protocols; in tunnel mode, AH and ESP are >> >> applied to tunneled IP packets. >> >> >> >> A host implementation of IPsec using the multicast extensions MAY >> >> use >> >> both transport mode and tunnel mode to encapsulate an IP multicast >> > >> > both or either? >> > >> >> >> > >> > >> >>3.1 Tunnel Mode with Address Preservation >> > >> > I can appreciate the requirement, I think. If I am not mistaken, >> > wouldn't >> > there be three cases here? There could be a sender which cannot IPsec >> > encapsulate and relies on a GW to encrypt and all members/receivers can >> > decapsulate IPsec on their own. In the second case, a GW decapsulates >> > for >> > some or all members. Finally a combination of the two. >> > >> > Would there be implications on the GW to join the multicast in the >> > reception case? >> > >> > It would also be worthwhile to have before and packet headers as in >> > 4302 >> > and 4303. >> > >> > Would header compression be possible, given that the inner and outer >> > headers might be the same? >> > >> > >> >>4.0 Security Association >> >> >> >>4.1 Major IPsec Databases >> >> >> >> The following sections describe the GKMP Subsystem and IPsec >> >> extension interactions with the major IPsec databases. Major IPsec >> >> databases need to be expanded in order to fully support multicast. >> >> >> >>4.1.1 Security Policy Database (SPD) >> > >> >> >> > >> >> SPD entries created by a GCKS may be assigned identical SPIs to SPD >> >> entries created by IKEv2 [RFC4306]. This is not a problem for the >> >> inbound traffic as the appropriate SAs can be matched using the >> >> algorithm >> > >> > State the section number to avoid ambiguity. >> > >> >>described in RFC 4301. In addition, SAs with identical SPI >> >> values but not manually keyed can be differentiated because they >> >> contain a link to their parent SPD entries. However, the outbound >> >> traffic needs to be matched against the SPD selectors so that the >> >> appropriate SA can be created on packet arrival. IPsec >> >> implementations that support multicast SHOULD use the destination >> > >> > Why not MUST? Please state the exceptions to the SHOULD if there are >> > any. >> > >> >> address as the additional selector and match it against the SPD >> >> entries marked "sender only". >> >> >> >>4.1.2 Security Association Database (SAD) >> >> >> >> The Security Association Database (SAD) can support multicast SAs, >> >> if >> >> manually configured. An outbound multicast SA has the same >> >> structure >> >> >> >>Weis, et al. Expires August, 2006 [Page 7] >> >> >> >>Internet-Draft Multicast Extensions to RFC 4301 June, 2005 >> >> >> >> >> >> as a unicast SA. The source address is that of the sender and the >> >> destination address is the multicast group address. An inbound, >> >> multicast SA must be configured with the source addresses of each >> >> peer authorized to transmit to the multicast SA in question. The >> >> SPI >> >> value for a multicast SA is provided by a GCKS, not by the >> >> receiver, >> >> as for a unicast SA. This is similar to the unicast case and does >> >> not >> >> require changes to SAD. >> >> However, the SPD needs a mechanism for automatic multicast SA >> >> creation. >> > >> > The above text seems like the text in 4301. Is this a placeholder? >> > >> > >> >>4.1.3 Peer Authorization Database (PAD) >> > >> >> >> > >> > >> >> The PAD MUST provide a management interface capability that allows >> >> an >> >> administrator to enforce that the scope of a GKMP group's policy >> >> specified SPD/SAD modifications are restricted to only those >> >> traffic >> >> data flows that belong to that group. This authorization MUST be >> >> configurable at GKMP group granularity. In the inverse direction, >> >> the >> >> PAD management interface MUST provide a mechanism(s) to enforce >> >> that >> >> IKEv2 security associations do not negotiate traffic selectors that >> >> conflict or override GKMP group policies. An implementation SHOULD >> >> offer PAD configuration capabilities that authorize the GKMP policy >> >> configuration mechanism to set security policy for other aspects of >> >> an endpoint's SPD/SAD configuration, not confined to its group >> >> security associations. This capability allows the group's policy to >> >> inhibit the creation of back channels that might otherwise leak >> >> confidential group application data. >> > >> > I am not sure about the normative language above. I looked at the PAD >> > stuff in 4301 and normative language was used quite sparingly. We >> > should >> > probably discuss this more. >> > >> > >> >> >> >> >> >> - The Group Speaker's "trailing edge" SA is the oldest security >> >> association in use by the group for that speaker. All authorized >> >> Group Members can receive and decrypt data for this SA, but the >> >> Group Speaker does not transmit new data using the "trailing >> >> edge" >> >> SA after it has transitioned to the "leading edge GSA". The >> >> trailing edge SA is deleted by the group's endpoints according to >> >> group policy (e.g., after a defined period has elapsed)" >> > >> > So by this, may I assume that multiple (more than two) IPsec SAs are >> > allowed to exist simultaneously? >> > >> > >> > >> >>Implementations MAY offer a Group >> >> Owner management interface option to enable/disable re-key rollover >> >> continuity for a particular group This specification requires that >> >> a >> > >> > Missing a period above. >> > >> >> GKMP/IPsec implementation MUST support at least two concurrent GSA >> >> per Group Speaker and this re-key rollover continuity algorithm. >> > >> > I see that you are mandating the existence of multiple simultaneous >> > IPsec >> > SAs. Please make it a SHOULD. I know of at least one use case where >> > rekeying would involve stopping transmission/reception and restarting >> > after a new SA has been established. >> > >> > >> > >> >>4.2 Data Origin Authentication >> >> >> >> As defined in [RFC3401], data origin authentication is a security >> >> service that verifies the identity of the claimed source of data. >> >> While HMAC authentication methods are often used to provide data >> >> origin authentication, they are not sufficient to provide data >> >> origin >> >> authentication for groups. With an HMAC, every group member can use >> >> the HMAC key to create a valid authentication tag whether or not >> >> they >> >> are the authentic origin. >> >> >> >> When the property of data origin authentication is required for an >> >> IPsec SA distributed from a GKCS, an authentication transform where >> >> the originator keeps a secret should be used. Two possible >> >> algorithms >> >> are TESLA [RFC4082] or RSA [RFC4359]. >> >> >> >> In some cases, (e.g., digital signature authentication transforms) >> >> the processing cost of the algorithm is significantly greater than >> >> an >> >> HMAC authentication method. To protect against denial of service >> >> attacks from device that is not authorized to join the group, the >> >> IPsec SA using this algorithm may be encapsulated with an IPsec SA >> >> using an HMAC authentication algorithm. However, doing so requires >> >> the packet to be sent across the IPsec boundary for additional >> >> inbound processing [RFC4301, Section 5.2]. >> > >> > Not sure I understand the last two sentences. Please explain. I can >> > appreciate the use of two auth tags, but not the concept of two IPsec >> > SAs >> > to do so. >> > >> > >> >>4.3 Group SA and Key Management >> >> >> >>4.3.1 Co-Existence of Multiple Key Management Protocols >> > >> >> >> > >> > >> >>4.3.2 New Security Association Attributes >> >> >> >> A number of new security association attributes are defined in this >> > >> > Two, really! >> > >> >> document. Each GKMP supporting this architecture MUST support the >> >> following list of attributes described elsewhere in this document. >> >> >> >> - Address Preservation (Section 3.1). This attribute describes >> >> whether address preservation is to be applied to the SA on the >> >> source >> >> address, destination address, or both source and destination >> >> addresses. >> >> >> >> - Direction attribute (Section 4.1.1). This attribute describes >> >> whether the SPD direction is to be symmetric, receiver only, or >> >> sender only. >> > >> > Why are these listed again? >> > >> > >> >>5.0 IP Traffic Processing >> >> >> >> Processing of traffic follows [RFC4301, Section 5], with the >> >> additions described below when these IP multicast extensions are >> >> supported. >> > >> > All of this probably belongs earlier. I have asked earlier about hdr >> > removal when the inner and outer addresses are the same. That was >> > proposed elsewhere and perhaps should be considered here. >> > >> > >> > >> >>6.0 Networking Issues >> >> >> >> >> >> >> >>Weis, et al. Expires August, 2006 [Page 12] >> >> >> >>Internet-Draft Multicast Extensions to RFC 4301 June, 2005 >> >> >> > >> > I ran out of steam here. I will do the rest some other time (may be >> > tomorrow or something). >> > _______________________________________________ >> > msec mailing list >> > msec@securemulticast.org >> > http://six.pairlist.net/mailman/listinfo/msec >> > >> > _____________________________________________________ >> > This mail has been virus scanned by Australia On Line >> > see http://www.australiaonline.net.au/mailscanning >> > >> >> > > _____________________________________________________ > This mail has been virus scanned by Australia On Line > see http://www.australiaonline.net.au/mailscanning > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Jun 19 18:22:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsS8v-0002ji-TJ for msec-archive@lists.ietf.org; Mon, 19 Jun 2006 18:22:49 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsS8u-0007s6-Gp for msec-archive@lists.ietf.org; Mon, 19 Jun 2006 18:22:49 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 6D6E82CC0D; Mon, 19 Jun 2006 18:22:48 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 3BB052CBDA for ; Mon, 19 Jun 2006 18:22:46 -0400 (EDT) Received: (qmail 48463 invoked by uid 3269); 19 Jun 2006 22:22:46 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 48460 invoked from network); 19 Jun 2006 22:22:46 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 19 Jun 2006 22:22:46 -0000 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by klesh.pair.com (Postfix) with ESMTP id CB783683B1 for ; Mon, 19 Jun 2006 18:22:45 -0400 (EDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 19 Jun 2006 15:22:44 -0700 X-IronPort-AV: i="4.06,153,1149490800"; d="txt'208?scan'208,208"; a="297409040:sNHT87001180" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k5JMMi6N030093 for ; Mon, 19 Jun 2006 15:22:44 -0700 Received: from [10.32.195.27] ([10.32.195.27]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5JMMike021554 for ; Mon, 19 Jun 2006 15:22:44 -0700 (PDT) Message-ID: <449723BC.9040400@cisco.com> Date: Mon, 19 Jun 2006 15:22:52 -0700 From: Brian Weis User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec Content-Type: multipart/mixed; boundary="------------030101020905060200050803" DKIM-Signature: a=rsa-sha1; q=dns; l=3190; t=1150755764; x=1151619764; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bew@cisco.com; z=From:Brian=20Weis=20 |Subject:[Fwd=3A=20I-D=20ACTION=3Adraft-ietf-msec-gdoi-update-00.txt]; X=v=3Dcisco.com=3B=20h=3DS+MkaypgdxfVKpCA6VOKfiqeZF4=3D; b=lxGN8tu+n/VmRvAh0tCvO7l9zGYQrPW1hBoL0JUkV1F1CQpu2aPDyImt0Qu80RXiXZNXklY2 dEo1VfrNFSf5QcddB8/xg0QZp9YWJuaateTQ5vp0Az89T62qZEjtKWd3; Authentication-Results: sj-dkim-4.cisco.com; header.From=bew@cisco.com; dkim=pass ( 46 extraneous bytes; sig from cisco.com verified; ); Subject: [MSEC] [Fwd: I-D ACTION:draft-ietf-msec-gdoi-update-00.txt] X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 This is a multi-part message in MIME format. --------------030101020905060200050803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Greetings, A new version of the GDOI update draft has been published. Comments and/or questions requested. Thanks, Brian -------- Original Message -------- Subject: I-D ACTION:draft-ietf-msec-gdoi-update-00.txt Date: Mon, 19 Jun 2006 19:52:33 GMT From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org Organization: Cisco Newsgroups: cisco.external.ietf.announce 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 : Updates to the Group Domain of Interpretation (GDOI) Author(s) : B. Weis, S. Rowles Filename : draft-ietf-msec-gdoi-update-00.txt Pages : 21 Date : 2006-6-19 This memo describes updates to the Group Domain of Interpretation (GDOI) [RFC3547]. It provides clarification where the original text is unclear. It also includes a discussion of algorithm agility within GDOI, and proposes several new algorithm attribute values. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-update-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msec-gdoi-update-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-gdoi-update-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. --------------030101020905060200050803 Content-Type: message/external-body; x-mac-type="0"; x-mac-creator="0"; name="draft-ietf-msec-gdoi-update-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-msec-gdoi-update-00.txt" Content-Type: text/plain Content-ID: <2006-6-19145435.I-D@ietf.org> --------------030101020905060200050803 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --------------030101020905060200050803-- From msec-bounces@securemulticast.org Tue Jun 20 10:15:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsh15-0005cc-6V for msec-archive@lists.ietf.org; Tue, 20 Jun 2006 10:15:43 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsh13-0004Ux-To for msec-archive@lists.ietf.org; Tue, 20 Jun 2006 10:15:43 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 9C57B2C864; Tue, 20 Jun 2006 10:15:41 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 061762C863 for ; Tue, 20 Jun 2006 10:15:41 -0400 (EDT) Received: (qmail 23602 invoked by uid 3269); 20 Jun 2006 14:15:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 23599 invoked from network); 20 Jun 2006 14:15:40 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 20 Jun 2006 14:15:40 -0000 Received: from mx-serv.inrialpes.fr (mx-serv.inrialpes.fr [194.199.18.100]) by klesh.pair.com (Postfix) with ESMTP id E6DAA683AE for ; Tue, 20 Jun 2006 10:15:39 -0400 (EDT) Received: from dwimmerlaik.inrialpes.fr (dwimmerlaik.inrialpes.fr [194.199.18.72]) by mx-serv.inrialpes.fr (8.13.6/8.13.0) with ESMTP id k5KEF8Ml003022; Tue, 20 Jun 2006 16:15:08 +0200 (MEST) Received: from [194.199.24.100] (iseran.inrialpes.fr [194.199.24.100]) by dwimmerlaik.inrialpes.fr (8.13.6/8.11.3/ImagV2) with ESMTP id k5KEF9Dx026707; Tue, 20 Jun 2006 16:15:10 +0200 (MEST) Message-ID: <449802EC.40707@inrialpes.fr> Date: Tue, 20 Jun 2006 16:15:08 +0200 From: Vincent Roca User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: canetti@csail.mit.edu References: <44914238.9000508@inrialpes.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mx-serv.inrialpes.fr [194.199.18.100]); Tue, 20 Jun 2006 16:15:09 +0200 (MEST) X-mx-serv-inrialpes-fr-MailScanner-Information: Please contact postmaster@inrialpes.fr for more information X-mx-serv-inrialpes-fr-MailScanner: Found to be clean X-mx-serv-inrialpes-fr-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=0, requis 6) X-mx-serv-inrialpes-fr-MailScanner-From: vincent.roca@inrialpes.fr X-Spam-Status: No Cc: msec@securemulticast.org, lorenzo@cisco.com, faurite@lcpc.fr Subject: [MSEC] Re: draft-ietf-msec-tesla-for-alc-norm-00.txt submission X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Hello Ran, > Overall the draft looks very good! > Here are some remarks: > > -First line: Should say msec, not rmt. > Corrected! > section 3.1: To avoid confusion, its probably good to say here too that > the synchronization message from sender to receiver is to be signed, and > the signature should be verified. > Well, this is already said in the 2nd and 3rd bullets. Or do you have in mind another section? > 4.3.1: which fields are to be covered by the signature in the bootstrap > message? > Good point. I'll clarify it. > regarding whether to force rejection of packets where the authentication > failed (editor note on page 30). I'd try to poll the list on this issue, > and perhaps reach a rough consensus. > Yes. RFC4082, Section 3.5 (bullets 1, 3 and 4) says that these unsafe packets __should__ be discarded. We say in the current I-D version that they __MUST__ be discarded. If there are situations where accepting unsafe/unauthenticated makes sense, then "SHOULD" is the right keyword. Otherwise "MUST" is more appropriate. We can also add a sentence explaining that using TESLA is anyway not mandatory, and that a receiver can at any time decide to move to an unsafe mode by ignoring all TESLA extensions. But this is done intentionally. > security considerations: it's perhaps worthwhile to discuss dos issues > which are specific to ALC - eg, the fact that even a single corrupted > packet can ruin an entire encoded stream. this also may be an argument in > the discussion on the previous issue. > Yes, we need to finalize Section 7. "Security Considerations". Thanks a lot for your comments! Regards, Vincent _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Jun 20 12:08:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsily-0005Yn-Vc for msec-archive@lists.ietf.org; Tue, 20 Jun 2006 12:08:14 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsijS-0001yR-Lr for msec-archive@lists.ietf.org; Tue, 20 Jun 2006 12:05:39 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 581AD2CB94; Tue, 20 Jun 2006 12:05:38 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 2B98B2CA22 for ; Tue, 20 Jun 2006 12:05:37 -0400 (EDT) Received: (qmail 48639 invoked by uid 3269); 20 Jun 2006 15:53:39 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 48636 invoked from network); 20 Jun 2006 15:53:39 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 20 Jun 2006 15:53:39 -0000 Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by klesh.pair.com (Postfix) with ESMTP id F2EBC6837D for ; Tue, 20 Jun 2006 11:53:38 -0400 (EDT) Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.12.11.20060308/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id k5KFrm73029762; Tue, 20 Jun 2006 11:53:58 -0400 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id k5KFrBK15026; Tue, 20 Jun 2006 11:53:11 -0400 Received: from mgsmtp00.watson.ibm.com (mgsmtp00.watson.ibm.com [9.2.40.58]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id k5KFrAF21788; Tue, 20 Jun 2006 11:53:10 -0400 Received: from sibylla.watson.ibm.com (sibylla.watson.ibm.com [9.2.16.101]) by mgsmtp00.watson.ibm.com (8.12.11/8.12.11/2005/09/01) with ESMTP id k5KGjsWD013524; Tue, 20 Jun 2006 12:45:55 -0400 Received: from localhost (canetti@localhost) by sibylla.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id k5KFr7l26748; Tue, 20 Jun 2006 11:53:09 -0400 Date: Tue, 20 Jun 2006 11:53:07 -0400 (EDT) From: canetti To: Vincent Roca Subject: Re: [MSEC] Re: draft-ietf-msec-tesla-for-alc-norm-00.txt submission In-Reply-To: <449802EC.40707@inrialpes.fr> Message-ID: References: <44914238.9000508@inrialpes.fr> <449802EC.40707@inrialpes.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: lorenzo@cisco.com, msec@securemulticast.org, faurite@lcpc.fr, canetti@csail.mit.edu X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: canetti@csail.mit.edu List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Vincent, On Tue, 20 Jun 2006, Vincent Roca wrote: > > section 3.1: To avoid confusion, its probably good to say here too that > > the synchronization message from sender to receiver is to be signed, and > > the signature should be verified. > > > Well, this is already said in the 2nd and 3rd bullets. Or do you have in > mind > another section? OK. missed that. it's probably good as is. > > regarding whether to force rejection of packets where the authentication > > failed (editor note on page 30). I'd try to poll the list on this issue, > > and perhaps reach a rough consensus. > > > Yes. RFC4082, Section 3.5 (bullets 1, 3 and 4) says that these unsafe > packets > __should__ be discarded. We say in the current I-D version that they > __MUST__ be discarded. If there are situations where accepting > unsafe/unauthenticated makes sense, then "SHOULD" is the right keyword. > Otherwise "MUST" is more appropriate. > > We can also add a sentence explaining that using TESLA is anyway not > mandatory, and that a receiver can at any time decide to move to an unsafe > mode by ignoring all TESLA extensions. But this is done intentionally. this is fine with me. I seem to recall that some people had reservations about forcing a discard. If someone wants to object, then this is the time... Ran _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Jun 26 10:51:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FusRK-0005oy-Ba for msec-archive@lists.ietf.org; Mon, 26 Jun 2006 10:51:50 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FusRI-0007l0-2J for msec-archive@lists.ietf.org; Mon, 26 Jun 2006 10:51:50 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id D0D1E2C063; Mon, 26 Jun 2006 10:51:47 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id CAE0C2BE05 for ; Mon, 26 Jun 2006 10:51:45 -0400 (EDT) Received: (qmail 68475 invoked by uid 3269); 26 Jun 2006 14:51:45 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 68472 invoked from network); 26 Jun 2006 14:51:45 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 26 Jun 2006 14:51:45 -0000 Received: from smtp-out2.oct.nac.net (smtp-out2.oct.nac.net [209.123.233.212]) by klesh.pair.com (Postfix) with SMTP id 64C3D6836B for ; Mon, 26 Jun 2006 10:51:45 -0400 (EDT) Received: (qmail 71463 invoked by uid 0); 26 Jun 2006 10:51:44 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 26 Jun 2006 10:51:44 -0400 Received: (qmail 66828 invoked from network); 26 Jun 2006 10:51:43 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 26 Jun 2006 10:51:43 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k5QBB7o00874; Mon, 26 Jun 2006 07:11:07 -0400 Date: Mon, 26 Jun 2006 07:11:07 -0400 (EDT) From: George Gross To: Lakshminath Dondeti Subject: Re: [MSEC] Review of draft-ietf-msec-ipsec-extensions-01 In-Reply-To: <7.0.1.0.2.20060614183840.03f5e3c0@qualcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: George Gross , Brian Weis , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Hi Laksminath, Brian, Dragan, and I have worked off-list the last week to accomodate many of your comments and also some issues that we detected as co-authors. we have issued a v02 of the ID that will publish shortly. although we felt we could revise the text to reflect your feedback in most cases, there were some instances where we need to follow up with discussion or clarifying questions. for these, we could introduce any additional revisions in v03 after the Montreal IETF. I will spin off a few e-mails shortly for those of your comments that we have a need to discuss/clarify.... br, George _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Jun 26 11:21:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FusuM-0002KG-Ie for msec-archive@lists.ietf.org; Mon, 26 Jun 2006 11:21:50 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FusuL-0001Bc-9i for msec-archive@lists.ietf.org; Mon, 26 Jun 2006 11:21:50 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id AAE152C817; Mon, 26 Jun 2006 11:21:48 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 7C2682C7C2 for ; Mon, 26 Jun 2006 11:21:47 -0400 (EDT) Received: (qmail 78930 invoked by uid 3269); 26 Jun 2006 15:21:47 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 78927 invoked from network); 26 Jun 2006 15:21:47 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 26 Jun 2006 15:21:47 -0000 Received: from smtp-out2.oct.nac.net (smtp-out2.oct.nac.net [209.123.233.212]) by klesh.pair.com (Postfix) with SMTP id 6C47768368 for ; Mon, 26 Jun 2006 11:21:47 -0400 (EDT) Received: (qmail 84628 invoked by uid 0); 26 Jun 2006 11:21:47 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 26 Jun 2006 11:21:46 -0400 Received: (qmail 86816 invoked from network); 26 Jun 2006 11:21:46 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 26 Jun 2006 11:21:46 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k5QBf9700915; Mon, 26 Jun 2006 07:41:09 -0400 Date: Mon, 26 Jun 2006 07:41:08 -0400 (EDT) From: George Gross To: Lakshminath Dondeti In-Reply-To: <7.0.1.0.2.20060614183840.03f5e3c0@qualcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: George Gross , Brian Weis , msec@securemulticast.org Subject: [MSEC] tunnel mode w/ address preservation use cases, was Review of draft-ietf-msec-ipsec-extensions-01 X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Hi Lakshminath, as promised, the first of several topic specific e-mails... On Thu, 15 Jun 2006, Lakshminath Dondeti wrote: > >3.1 Tunnel Mode with Address Preservation > > I can appreciate the requirement, I think. If I am not mistaken, > wouldn't there be three cases here? There could be a sender which > cannot IPsec encapsulate and relies on a GW to encrypt and all > members/receivers can decapsulate IPsec on their own. In the second > case, a GW decapsulates for some or all members. Finally a > combination of the two. We could easily get tangled up in explaining the many use cases. This section really should only define the semantics, not the use cases. If you think the use cases need to be identified, I would suggest that you prepare some text that we can put into an appendix. > > Would there be implications on the GW to join the multicast in the > reception case? Clearly, the decapsulating security gateway has to be either a multicast router or IGMP proxy or multicast leaf node for the multicast group in order to receive the data stream. are you saying we should explicitly say that? > > It would also be worthwhile to have before and packet headers as in > 4302 and 4303. maybe we can add this into v03. > Would header compression be possible, given that the inner and outer > headers might be the same? Compression was identified as an SA attribute in RFC2407, but RFC4301 only briefly mentions compression in section 3.1. Does the compression that you are talking about resemble Nikander's proposed BEET mode? In any case, there is nothing in RFC4301 that would stop a GKM protocol from negotiating tunnel mode header compression, but that would be a separate and future specification from this one. br, George _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Jun 26 12:42:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuuAQ-0000Cy-FJ for msec-archive@lists.ietf.org; Mon, 26 Jun 2006 12:42:30 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Futbe-00048Y-Gy for msec-archive@lists.ietf.org; Mon, 26 Jun 2006 12:06:34 -0400 Received: from six.pairlist.net ([209.68.2.254]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FutR7-0000TJ-H9 for msec-archive@lists.ietf.org; Mon, 26 Jun 2006 11:55:43 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 0199C2B8FF; Mon, 26 Jun 2006 11:55:31 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id AC5762B820 for ; Mon, 26 Jun 2006 11:55:29 -0400 (EDT) Received: (qmail 87482 invoked by uid 3269); 26 Jun 2006 15:55:29 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 87479 invoked from network); 26 Jun 2006 15:55:29 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 26 Jun 2006 15:55:29 -0000 Received: from smtp-out1.oct.nac.net (smtp-out1.oct.nac.net [209.123.233.211]) by klesh.pair.com (Postfix) with SMTP id 9266068367 for ; Mon, 26 Jun 2006 11:55:29 -0400 (EDT) Received: (qmail 8645 invoked by uid 0); 26 Jun 2006 11:55:28 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 26 Jun 2006 11:55:28 -0400 Received: (qmail 8860 invoked from network); 26 Jun 2006 11:55:28 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 26 Jun 2006 11:55:28 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k5QCEpX00998; Mon, 26 Jun 2006 08:14:51 -0400 Date: Mon, 26 Jun 2006 08:14:51 -0400 (EDT) From: George Gross To: Lakshminath Dondeti In-Reply-To: <7.0.1.0.2.20060614183840.03f5e3c0@qualcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: George Gross , Brian Weis , msec@securemulticast.org Subject: [MSEC] multiple IPsec SA in support of rekey rollover X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: -2.6 (--) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Hi Lakshminath, On Thu, 15 Jun 2006, Lakshminath Dondeti wrote: > > association in use by the group for that speaker. All authorized > > Group Members can receive and decrypt data for this SA, but the > > Group Speaker does not transmit new data using the "trailing edge" > > SA after it has transitioned to the "leading edge GSA". The > > trailing edge SA is deleted by the group's endpoints according to > > group policy (e.g., after a defined period has elapsed)" > > So by this, may I assume that multiple (more than two) IPsec SAs are > allowed to exist simultaneously? Yes. > > > >Implementations MAY offer a Group > > Owner management interface option to enable/disable re-key rollover > > continuity for a particular group This specification requires that a > > Missing a period above. ok. > > > GKMP/IPsec implementation MUST support at least two concurrent GSA > > per Group Speaker and this re-key rollover continuity algorithm. > > I see that you are mandating the existence of multiple simultaneous > IPsec SAs. Please make it a SHOULD. I know of at least one use case > where rekeying would involve stopping transmission/reception and > restarting after a new SA has been established. The rekey rollover algorithm is a fairly fundemental MSEC inter-op requirement. Unlike a pair-wise unicast SA that negotiate policies, we are constrained to support only homogeneous groups (unless you consider moving composite groups back into the MSEC IPsec draft). If even one endpoint does not implement the rekey rollover algorithm, then the performance of the whole group is degraded because we are forced to either saddle the group with the handicap of the least common denominator or else exclude those candidate members who don't implement the SHOULD. The use case you cite is at odds with the major motivation for MSEC IPsec service, continous reliable real-time delivery of secured content. Interrupting that delivery by dropping packets or stopping packet transmission for the duration of a rekey operation would preclude multi-vendor support of the reliable real-time service objective. br, George _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec