From msec-bounces@securemulticast.org Tue May 02 03:36:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FapNg-0002q3-KV for msec-archive@lists.ietf.org; Tue, 02 May 2006 03:33:12 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FapD9-0003Zx-B7 for msec-archive@lists.ietf.org; Tue, 02 May 2006 03:22:20 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id B8F332C8D4; Tue, 2 May 2006 03:22:14 -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 DAFE12B8CF for ; Tue, 2 May 2006 03:22:12 -0400 (EDT) Received: (qmail 34453 invoked by uid 3269); 2 May 2006 07:22:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 34450 invoked from network); 2 May 2006 07:22:12 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 2 May 2006 07:22:12 -0000 Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) by klesh.pair.com (Postfix) with ESMTP id 52E486836B for ; Tue, 2 May 2006 03:22:12 -0400 (EDT) Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k427M39k023293; Tue, 2 May 2006 09:22:04 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k427M00A004493; Tue, 2 May 2006 09:22:03 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 09:22:01 +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] Fwd: I-D ACTION:draft-dondeti-msec-mikey-genext-oma-00.txt Date: Tue, 2 May 2006 09:22:01 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] Fwd: I-D ACTION:draft-dondeti-msec-mikey-genext-oma-00.txt Thread-Index: AcZrHSqoLXbwG1PJQoiWOz8jx/+E6wCmyKUQ From: "Fries, Steffen" To: "Lakshminath Dondeti" , X-OriginalArrivalTime: 02 May 2006 07:22:01.0055 (UTC) FILETIME=[1AACD6F0:01C66DB9] Cc: 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.2 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Hi Lakshminath, I just read over your draft regarding the OMA extension for MIKEY.=20 It seems okay from my point of view. I will include this information also in the MIKEY applicability draft for completeness. Regards Steffen > -----Original Message----- > From: msec-bounces@securemulticast.org=20 > [mailto:msec-bounces@securemulticast.org] On Behalf Of=20 > Lakshminath Dondeti > Sent: Saturday, April 29, 2006 1:40 AM > To: msec@securemulticast.org > Subject: [MSEC] Fwd: I-D=20 > ACTION:draft-dondeti-msec-mikey-genext-oma-00.txt=20 >=20 > Strictly as an IETF contributor, I am requesting reviews on=20 > this document. This is an IANA registration request of a new=20 > GenExt payload for MIKEY. >=20 > regards, > Lakshminath >=20 >=20 > >To: i-d-announce@ietf.org > >Cc: > >From: Internet-Drafts@ietf.org > >Date: Fri, 28 Apr 2006 15:50:01 -0400 > >X-Spam-Score: -2.6 (--) > >X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 > >Subject: I-D ACTION:draft-dondeti-msec-mikey-genext-oma-00.txt > >X-BeenThere: i-d-announce@ietf.org > >X-Mailman-Version: 2.1.5 > >Reply-To: internet-drafts@ietf.org > >List-Id: i-d-announce.ietf.org > >List-Unsubscribe:=20 > , > > > >List-Archive: > >List-Post: > >List-Help: > >List-Subscribe:=20 > , > > > >X-PMX-Version: 4.7.0.111621 > >X-PMX-Version: 5.1.2.240295, Antispam-Engine: 2.3.0.1, > >Antispam-Data: 2006.4.28.135109 > >X-OriginalArrivalTime: 28 Apr 2006 21:15:10.0229 (UTC)=20 > >FILETIME=3D[D4E47450:01C66B08] > > > >A New Internet-Draft is available from the on-line Internet-Drafts=20 > >directories. > > > > > > Title : OMA BCAST MIKEY General Extension Payload=20 > > Specification > > Author(s) : L. Dondeti, D. Castleford > > Filename : draft-dondeti-msec-mikey-genext-oma-00.txt > > Pages : 7 > > Date : 2006-4-28 > > > > This document specifies a new general extension payload=20 > type for use > > in the Open Mobile Alliance's (OMA) Browser and Content (BAC) > > Broadcast (BCAST) group. OMA BCAST's service and=20 > content protection > > specification uses short term key message (STKM) and=20 > long term key > > message (LTKM) payloads that in certain broadcast distribution > > systems (BDS) are carried in the IETF MIKEY protocol [1]. A new > > MIKEY general extension payload specified in this=20 > document will be > > used for that purpose. > > > > > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-dondeti-msec-mikey- > genext-oma > >-00.txt > > > >To remove yourself from the I-D Announcement list, send a message to=20 > >i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > >the message. > >You can also visit=20 > 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=20 > >username "anonymous" and a password of your e-mail address. After=20 > >logging in, type "cd internet-drafts" and then > > "get draft-dondeti-msec-mikey-genext-oma-00.txt". > > > >A list of Internet-Drafts directories can be found in=20 > >http://www.ietf.org/shadow.html or=20 > >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=20 > /internet-drafts/draft-dondeti-msec-mikey-genext-oma-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=20 > the "FILE" > > command. To decode the response(s), you will need=20 > "munpack" or > > a MIME-compliant mail reader. Different=20 > MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which=20 > have been split > > up into multiple messages), so check your local=20 > documentation on > > how to manipulate these messages. > > > > > >Below is the data which will enable a MIME compliant mail reader=20 > >implementation to automatically retrieve the ASCII version of the=20 > >Internet-Draft. > > > >Content-Type: text/plain > >Content-ID: <2006-4-28135953.I-D@ietf.org> > > > >ENCODING mime > >FILE /internet-drafts/draft-dondeti-msec-mikey-genext-oma-00.txt > > > > > > genext-oma > >-00.txt> _______________________________________________ > >I-D-Announce mailing list > >I-D-Announce@ietf.org > >https://www1.ietf.org/mailman/listinfo/i-d-announce >=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 Tue May 02 04:20:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Faq7r-0005sD-0i for msec-archive@lists.ietf.org; Tue, 02 May 2006 04:20:55 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Faq7p-00067i-JJ for msec-archive@lists.ietf.org; Tue, 02 May 2006 04:20:55 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 6EFB82CB0F; Tue, 2 May 2006 04:20:53 -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 3F3E12CB2F for ; Tue, 2 May 2006 04:20:52 -0400 (EDT) Received: (qmail 42220 invoked by uid 3269); 2 May 2006 08:20:52 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 42217 invoked from network); 2 May 2006 08:20:51 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 2 May 2006 08:20:51 -0000 Received: from hypup4.nagra.com (hypup4.nagra.com [212.249.41.203]) by klesh.pair.com (Postfix) with ESMTP id C6EF968367 for ; Tue, 2 May 2006 04:20:50 -0400 (EDT) Received: from hypup4.nagra.com (localhost [127.0.0.1]) by hypup4.nagra-kudelski.ch (Postfix) with ESMTP id B227A70366 for ; Tue, 2 May 2006 10:20:47 +0200 (CEST) Received: from mercure2.hq.k.grp (mercure2.hq.k.grp [172.31.239.25]) by hypup4.nagra.com (Postfix) with ESMTP id D2B2B7035E for ; Tue, 2 May 2006 10:20:45 +0200 (CEST) Received: from castor.hq.k.grp ([10.0.50.117]) by mercure2.hq.k.grp with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 10:20:45 +0200 Received: from pollux.hq.k.grp ([10.0.50.118]) by castor.hq.k.grp with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 10:20:45 +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: [AVT] RE: [MSEC] draft-lehtovirta-srtp-rcc-01.txt for broadcast use Date: Tue, 2 May 2006 10:20:53 +0200 Message-ID: <93F43D80456A4242A0A62E253B8604A2CB761C@pollux.hq.k.grp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [AVT] RE: [MSEC] draft-lehtovirta-srtp-rcc-01.txt for broadcast use Thread-Index: AcZtwVQfezKOsGB5TbCmZ8ta/pS5wQ== From: "Piron Laurent" To: , X-OriginalArrivalTime: 02 May 2006 08:20:45.0478 (UTC) FILETIME=[4F651C60:01C66DC1] Cc: NDallard@ndsuk.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: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Dear all, Nagravision is an active actor in the broadcast world. We are currently active in the DVB-CBMS and OMA BCAST groups. While DVB-CBMS is considering using the draft-lehtovirta-srtp-rcc-01.txt, OMA BCAST did already make the choice of using it. This solution is also used in 3GPP2 BCMCS and 3GPP MBMS. Thus in order to reach a nice harmonization between specifications and allow sharing of streams between systems, DVB is looking at this draft as other bodies did already made this choice. We consider that the proposition of Nigel is a good addition to the draft: - This draft provides a very nice solution to carry the ROC to a client in a broadcast only system, where there is no return path and where a client can joint at any time and needs the ROC (among other parameters) to properly get access. - Currently authentication is not used in broadcast TV systems. Indeed, no pay-TV systems mandate the use of authentication. Using authentication is an operational decision (as encrypting content is an operational decision in fact). No standard does mandate that content shall be authenticated. - RFC3711 does not require the use of authentication, it is recommended. Thus requiring the authentication to allow carrying the ROC modifies the way this RFC is used, while there is no direct link between the ROC and authentication. Thus, the proposed additional mode only makes a clear distinction between having authentication and carrying the ROC value in-band. Please note that we do not say that authentication is of no need, we just want to see it optional as it is currently in RFC3711 while allowing to carry ROC in-band which is a very useful feature. Best regards Laurent ------------------------------------------ Laurent Piron CTO office - New Technologies Nagravision SA, Case Postale 134 1033 Cheseaux, Switzerland +41 21 732 05 37 > From: Karl Norrman (KI/EAB) [mailto:karl.norrman@ericsson.com] > Sent: 27 April 2006 13:28 > To: Dallard, Nigel > Cc: avt@ietf.org; msec@securemulticast.org > Subject: RE: [MSEC] draft-lehtovirta-srtp-rcc-01.txt for broadcast use >=20 > Hello! >=20 > You have a point in that there are specialized environments=20 > where a NULL-MAC potentially could be acceptable after a=20 > proper threat/risk analysis. >=20 > Do other people on this list consider this a valuable=20 > addition to the draft?=20 >=20 > Regards, > Karl >=20 > -----Original Message----- > From: Dallard, Nigel [mailto:NDallard at ndsuk.com]=20 > Sent: den 27 april 2006 11:33 > To: Karl Norrman (KI/EAB) > Cc: avt at ietf.org; msec at securemulticast.org > Subject: RE: [MSEC] draft-lehtovirta-srtp-rcc-01.txt for broadcast use >=20 > > From: Karl Norrman (KI/EAB) [mailto:karl.norrman at ericsson.com] >=20 > > The ROC needs to be integrity protected to ensure that it is not=20 > > maliciously modified or subject to transmission bit errors=20 > en route. =20 > > If the receiver starts using a ROC that has been modified during=20 > > transmission, the receiver will be out of synch. > > Since in "normal" SRTP operation, the ROC is never transmitted=20 > > in-band, an unprotected transmission of ROC would therefore _add_ a=20 > > vulnerability that is -_not_ present in RFC3711. >=20 > Hi there Karl, >=20 > I accept what you are saying, however, in the particular=20 > application I am concerned about... >=20 > 1. Forward error protection is dealt with at a lower level in=20 > the protocol stack. It should be a very rare occurrence that=20 > an erroneous ROC value reaches the descramber in the ROC. The=20 > worst-case scenario would be that the receiver would be out=20 > of sync for R packets. The broadcaster has the ability to=20 > trade the impact of such loss of sync against bit-rate by=20 > varying the value of R. >=20 > 2. Malicious modification is not necessarily a concern in a=20 > broadcast environment. Your TV does not, today, authenticate=20 > the source of the TV signal. >=20 > I believe that if the system/network operator, having=20 > performed a risk assessment (along the lines of that=20 > described in Section 9 of RFC3711, for example), would prefer=20 > to trade bit-rate against the possibility of loss of ROC sync=20 > or the ability of receivers to authenticate the source of his=20 > signals, he should be able to do so. >=20 > > You are correct when you say that it is necessary to=20 > include the MAC=20 > > on each R:th packet. If one is worried about the bandwidth=20 > > consumption of a MAC of 80 bits per R:th packet, one could put the=20 > > length of the MAC (n_tag parameter in SRTP) to something less, e.g., > > 32 bits. >=20 > Yes, I understand this. I'd like to effectively set n_tag to 0 :-) >=20 > Cheers, >=20 > Nigel >=20 >=20 >=20 > ** Nigel Dallard e-mail: ndallard at ndsuk.com **=20 > ** Senior Member www: http://www.nds.com **=20 > ** of Technical Staff tel: +44 23 8030 7151 **=20 > ** NDS Ltd, Southampton, UK. mobile: +44 7881 913151 **=20 >=20 > This email message and any attachments thereto are intended=20 > only for use by the addressee(s) named above, and may contain=20 > legally privileged and/or confidential information. If the=20 > reader of this message is not the intended recipient, or the=20 > employee or agent responsible to deliver it to the intended=20 > recipient, you are hereby notified that any dissemination,=20 > distribution or copying of this communication is strictly=20 > prohibited. If you have received this communication in error,=20 > please immediately notify the postmaster at nds.com and destroy=20 > the original message >=20 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu May 04 14:45:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbipL-0004O6-30 for msec-archive@lists.ietf.org; Thu, 04 May 2006 14:45:27 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbipJ-0000Ot-NK for msec-archive@lists.ietf.org; Thu, 04 May 2006 14:45:27 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 3F5852C823; Thu, 4 May 2006 14:45:25 -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 182EB2C81C for ; Thu, 4 May 2006 14:45:23 -0400 (EDT) Received: (qmail 74567 invoked by uid 3269); 4 May 2006 18:45:22 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 74564 invoked from network); 4 May 2006 18:45:22 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 4 May 2006 18:45:22 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id 9410068367 for ; Thu, 4 May 2006 14:45:22 -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 k44Ig7ho017623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 4 May 2006 11:42:07 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k44Ig6Ae022734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 May 2006 11:42:06 -0700 (PDT) Message-Id: <6.2.5.6.2.20060504114102.057e9f98@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 04 May 2006 11:42:01 -0700 To: "Vishwas Manral" , "Acee Lindem" From: Lakshminath Dondeti In-Reply-To: <77ead0ec0605040525jd8cead1o346b8e6f1b7b15a0@mail.gmail.com > References: <20060504082605.60358.qmail@web8513.mail.in.yahoo.com> <4459E002.2050103@cisco.com> <77ead0ec0605040525jd8cead1o346b8e6f1b7b15a0@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: rpsec@ietf.org, msec@securemulticast.org Subject: [MSEC] Re: [RPSEC] Re: Using IPSec for Routing Protocols 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: 68ba2b07ef271dba6ee42a93832cfa4c At 05:25 AM 5/4/2006, Vishwas Manral wrote: >Hi Acee, > >One reason we do not use IPsec is that we do not support multicast >well in IPsec. This is news to me and probably to many folks in MSEC. Please take a look at the work underway in that group. regards, Lakshminath > I think the way it is used in OSPFv3 is itself a hack. Also in the > end of it we are still using manual keying as well as only > authentication so still the same as for the rpotocols. > >Stephen Kent would probably have the details of it. > >Thanks, >Vishwas > > >On 5/4/06, Acee Lindem <acee@cisco.com> wrote: >Sandhya, >See inline. >Sandhya Chawla wrote: > > >Hi Stephane, > > > >--- Stephane Bortzmeyer < > bortzmeyer@nic.fr> wrote: > > > > > > > >>On Thu, May 04, 2006 at 05:15:21AM +0100, > >> Sandhya Chawla > <sandhya.chawla@yahoo.co.in > wrote > >> a message of 50 lines which said: > >> > >> > >> > >>>Why are we working on providing security at each routing protocol > >>>(application layer)? Why cant we simply use IPSEC for this? > >>> > >>> > >>Wild guess from a non-expert: because IPsec only provides channel > >>security, not data security. For instance, if I have a BGP connection > >> > >> > > > >We could use ESP will null encryption (null cipher). Using NULL as > we really dont want to provide > >any confidentiality. We only want to authenticate the sender and > want to make sure that no one > >mangles the packet in between. > > > > > > > >>with a peer, I can use IPsec and therefore be sure that the peer is > >>really what it says it is. But what does it buy me when the peer > >>announces a route? How can I be sure that he is entitled to announce > >>this route? > >> > >> > > > >Yes, i understand the need for SO-BGP and S-BGP. What about the > IGPs? We would perhaps not want to > >go in for the complexity of issuing certificates, etc for IGPs. Would we? > > > > >I would hope not. Though there have been experiments in this area. > > >If not, then why cant we simply use IPSEC to protect and auth my IGP data? > > > > >There have been some challenges in using IPSec but the draft should be >published soon. > >http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-08.txt > >Work is underway to provide the IPSec for OSPFv2 as well. > >Acee > > >I understand that IPSEC works best for, and is perhaps currently > defined only for unicast traffic. > >Is this the reason because of which we cant use IPSEC for IGPs (OSPF)? > > > >Regards, > >Sandhya > > > > > > > >>(Analogy: showing me your passport can convince me that you are indeed > >>Sandhya Chawla. But it does not make any difference when you tell me > >>that Om Prakash Chautala is an honest man or not: I still have to > >>check the information.) > >> > >>For the same reason, IPsec does not make the DNS safer and we need > >>DNSsec. > >> > >> > >> > > > > > > > > > >__________________________________________________________ > >Yahoo! India Answers: Share what you know. Learn something new. > >http://in.answers.yahoo.com > > > >_______________________________________________ > >RPSEC mailing list > >RPSEC@ietf.org > >https://www1.ietf.org/mailman/listinfo/rpsec > > > > > > > >_______________________________________________ >RPSEC mailing list >RPSEC@ietf.org >https://www1.ietf.org/mailman/listinfo/rpsec > > >_______________________________________________ >RPSEC mailing list >RPSEC@ietf.org >https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri May 05 10:44:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc1Y5-0001IM-5g for msec-archive@lists.ietf.org; Fri, 05 May 2006 10:44:53 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc1Xv-00072K-FI for msec-archive@lists.ietf.org; Fri, 05 May 2006 10:44:53 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 6D1942C8FD; Fri, 5 May 2006 10:44:36 -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 0EFFB2C97D for ; Fri, 5 May 2006 10:44:35 -0400 (EDT) Received: (qmail 36379 invoked by uid 3269); 5 May 2006 14:44:34 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 36376 invoked from network); 5 May 2006 14:44:34 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 5 May 2006 14:44:34 -0000 Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by klesh.pair.com (Postfix) with ESMTP id 722CC68360 for ; Fri, 5 May 2006 10:44:34 -0400 (EDT) Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 089994E6; Fri, 5 May 2006 16:44:33 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 May 2006 16:44:32 +0200 Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 May 2006 16:44:32 +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] Fwd: I-D ACTION:draft-dondeti-msec-mikey-genext-oma-00.txt Date: Fri, 5 May 2006 16:44:25 +0200 Message-ID: <7A8B56E38F02C44792C3586602027964FCCFE2@esealmw116.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [MSEC] Fwd: I-D ACTION:draft-dondeti-msec-mikey-genext-oma-00.txt Thread-Index: AcZu5jMFYZvDkFJyTr6YMDddmkSSngA5BMVgACGcRoA= From: "Frank Hartung \(AC/EDD\)" To: X-OriginalArrivalTime: 05 May 2006 14:44:32.0343 (UTC) FILETIME=[6BB71E70:01C67052] X-Brightmail-Tracker: AAAAAA== 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.2 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee =20 Dear Laksminath and all, I read your draft with interest. As you know, I am working in the=20 OMA BCAST group and appreciate that you propose this draft. Some detail comments though: - It is not clear to me what the ambition level of the draft is with respect to specifying the parameters to be carried in the payload. I think you should either fully specify in the draft all the parameters and the format how they are carried, or, alternatively, not talk at all about the parameters that shall be carried (and leave it to OMA to specify this). Right now it is a, as I find, bad compromise: it lists=20 the parameters but does not specify how they are formatted/encoded. It is not even specified how to distinguish STKM and LTKM information. - If you decide to keep the list of STKM/LTKM paremeters in section 3 you should clearly refer to the OMA spec [2] in that section - The name of the I-D and the new field seem to imply that this is a generic BCAST extension payload, while it is in fact an STKM/LTKM payload. This seems to be some mismatch that should be clarified. Do you want to keep this open for other use than STKM/LTKM (then it should be said) or restrict to STKM/LTKM (then=20 the title may be too broad and misleading) ? - You talk about=20 - "OMA BCAST MIKEY General Extension Payload " (title) - "OMA General Extension payload" (section 2 and 3) - "MIKEY General Extension Payload " (section 3) - "OMA BCAST's MIKEY General extension payload" (section 5) this should be made uniform - The references maybe should not be against specific versions of 3GPP and OMA=20 specs as those are updated several times a year. Instead they should refer to the=20 plain spec number without the revision info, unless there is a reason to have=20 some specific version. - Some abbreviations need to be explained (maybe twice, once in the abstract and ocne in the body), like BDS and *TKM and MBMS=20 - There is a typo=20 - "specification [1]defines " to "specification [1] defines " If you would like some concrete proposals for changes corresponding to these comments please contact me. Thanks for your consideration and best regards, Frank =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr. Frank Hartung Ericsson Research 52134 Herzogenrath, Germany Frank.Hartung@ericsson.com =20 > > > -----Original Message----- > > > From: msec-bounces@securemulticast.org > > > [mailto:msec-bounces@securemulticast.org] On Behalf Of Lakshminath > > > Dondeti > > > Sent: Saturday, April 29, 2006 1:40 AM > > > To: msec@securemulticast.org > > > Subject: [MSEC] Fwd: I-D > > > ACTION:draft-dondeti-msec-mikey-genext-oma-00.txt > > > > > > Strictly as an IETF contributor, I am requesting reviews on this > > > document. This is an IANA registration request of a new GenExt > > > payload for MIKEY. > > > > > > regards, > > > Lakshminath > > > > > > > > > >To: i-d-announce@ietf.org > > > >Cc: > > > >From: Internet-Drafts@ietf.org > > > >Date: Fri, 28 Apr 2006 15:50:01 -0400 > > > >X-Spam-Score: -2.6 (--) > > > >X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 > > > >Subject: I-D ACTION:draft-dondeti-msec-mikey-genext-oma-00.txt > > > >X-BeenThere: i-d-announce@ietf.org > > > >X-Mailman-Version: 2.1.5 > > > >Reply-To: internet-drafts@ietf.org > > > >List-Id: i-d-announce.ietf.org > > > >List-Unsubscribe: > > > , > > > > =20 > > > > >List-Archive: > > > >List-Post: > > > >List-Help: > > > >List-Subscribe: > > > , > > > > = > > > >X-PMX-Version: 4.7.0.111621 > > > >X-PMX-Version: 5.1.2.240295, Antispam-Engine: 2.3.0.1, > > > >Antispam-Data: 2006.4.28.135109 > > > >X-OriginalArrivalTime: 28 Apr 2006 21:15:10.0229 (UTC) > > > >FILETIME=3D[D4E47450:01C66B08] > > > > > > > >A New Internet-Draft is available from the on-line=20 > Internet-Drafts > > > >directories. > > > > > > > > > > > > Title : OMA BCAST MIKEY General=20 > Extension Payload > > > > Specification > > > > Author(s) : L. Dondeti, D. Castleford > > > > Filename :=20 > draft-dondeti-msec-mikey-genext-oma-00.txt > > > > Pages : 7 > > > > Date : 2006-4-28 > > > > > > > > This document specifies a new general extension payload > > > type for use > > > > in the Open Mobile Alliance's (OMA) Browser and Content (BAC) > > > > Broadcast (BCAST) group. OMA BCAST's service and > > > content protection > > > > specification uses short term key message (STKM) and > > > long term key > > > > message (LTKM) payloads that in certain broadcast=20 > distribution > > > > systems (BDS) are carried in the IETF MIKEY protocol=20 > [1]. A new > > > > MIKEY general extension payload specified in this > > > document will be > > > > used for that purpose. > > > > > > > > > > > > > > > >A URL for this Internet-Draft is: > > > >http://www.ietf.org/internet-drafts/draft-dondeti-msec-mikey- > > > genext-oma > > > >-00.txt > > > > > > > >To remove yourself from the I-D Announcement list, send=20 > 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.=20 > Login with the > > > >username "anonymous" and a password of your e-mail address. After > > > >logging in, type "cd internet-drafts" and then > > > > "get draft-dondeti-msec-mikey-genext-oma-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-dondeti-msec-mikey-genext-oma-00.txt". > > > > > > > >NOTE: The mail server at ietf.org can return the document in > > > > MIME-encoded form by using the "mpack" utility.=20 > To use this > > > > feature, insert the command "ENCODING mime" before > > > the "FILE" > > > > command. To decode the response(s), you will need > > > "munpack" or > > > > a MIME-compliant mail reader. Different > > > MIME-compliant mail readers > > > > exhibit different behavior, especially when dealing with > > > > "multipart" MIME messages (i.e. documents which > > > have been split > > > > up into multiple messages), so check your local > > > documentation on > > > > how to manipulate these messages. > > > > > > > > > > > >Below is the data which will enable a MIME compliant mail reader > > > >implementation to automatically retrieve the ASCII version of the > > > >Internet-Draft. > > > > > > > >Content-Type: text/plain > > > >Content-ID: <2006-4-28135953.I-D@ietf.org> > > > > > > > >ENCODING mime > > > >FILE /internet-drafts/draft-dondeti-msec-mikey-genext-oma-00.txt > > > > > > > > > > >=20 > > genext-oma > > > >-00.txt> _______________________________________________ > > > >I-D-Announce mailing list > > > >I-D-Announce@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri May 05 17:15:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc7eG-000622-Vy for msec-archive@lists.ietf.org; Fri, 05 May 2006 17:15:40 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc7eF-0001i0-Fs for msec-archive@lists.ietf.org; Fri, 05 May 2006 17:15:40 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id E9F382BAD8; Fri, 5 May 2006 17:15: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 1D55C2B9F2 for ; Fri, 5 May 2006 17:15:37 -0400 (EDT) Received: (qmail 23394 invoked by uid 3269); 5 May 2006 21:15:37 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 23391 invoked from network); 5 May 2006 21:15:37 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 5 May 2006 21:15:37 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id B309968369 for ; Fri, 5 May 2006 17:15:36 -0400 (EDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k45LFQOa032376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 5 May 2006 14:15:27 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-64-98.qualcomm.com [10.50.64.98]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k45LFOWc010753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 May 2006 14:15:26 -0700 (PDT) Message-Id: <6.2.5.6.2.20060505134356.05cb5900@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 05 May 2006 14:15:22 -0700 To: "Frank Hartung \(AC/EDD\)" , From: Lakshminath Dondeti Subject: RE: [MSEC] Fwd: I-D ACTION:draft-dondeti-msec-mikey-genext-oma-00.txt In-Reply-To: <7A8B56E38F02C44792C3586602027964FCCFE2@esealmw116.eemea.er icsson.se> References: <7A8B56E38F02C44792C3586602027964FCCFE2@esealmw116.eemea.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: 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.2 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Hi Frank, Thanks for your comments. Please see inline: At 07:44 AM 5/5/2006, Frank Hartung \(AC/EDD\) wrote: > >Dear Laksminath and all, > >I read your draft with interest. As you know, I am working in the >OMA BCAST group and appreciate that you propose this draft. > >Some detail comments though: > >- It is not clear to me what the ambition level of the draft is with >respect > to specifying the parameters to be carried in the payload. > I think you should either fully specify in the draft all the >parameters and > the format how they are carried, or, alternatively, not talk at all > about the parameters that shall be carried (and leave it to OMA to > specify this). Right now it is a, as I find, bad compromise: it lists > the parameters but does not specify how they are formatted/encoded. > It is not even specified how to distinguish STKM and LTKM information. > >- If you decide to keep the list of STKM/LTKM paremeters in section 3 >you > should clearly refer to the OMA spec [2] in that section The intention for the next revision is to remove the list of parameters and instead describe those parameters mainly for informative purposes. The payload is for OMA uses and the listing is to indicate the type of information included in the payload, more importantly the type of protection required for the information therein. We note that the GenExt payload is integrity protected and not encrypted. So, for instance we cannot put keys in that payload :-). I will add the reference to the OMA specification. >- The name of the I-D and the new field seem to imply that this is a >generic > BCAST extension payload, while it is in fact an STKM/LTKM payload. >This seems > to be some mismatch that should be clarified. Do you want to keep this >open for > other use than STKM/LTKM (then it should be said) or restrict to >STKM/LTKM (then > the title may be too broad and misleading) ? I can name it as an OMA TKM payload, but would like to leave the TKM type management to OMA so new TKM types in future OMA BCAST versions can be added without a need to go to IANA. >- You talk about > - "OMA BCAST MIKEY General Extension Payload " (title) > - "OMA General Extension payload" (section 2 and 3) > - "MIKEY General Extension Payload " (section 3) > - "OMA BCAST's MIKEY General extension payload" (section 5) > this should be made uniform Will do. >- The references maybe should not be against specific versions of 3GPP >and OMA > specs as those are updated several times a year. Instead they should >refer to the > plain spec number without the revision info, unless there is a reason >to have > some specific version. Could you send me the correct reference? Thanks. >- Some abbreviations need to be explained (maybe twice, once in the >abstract and > ocne in the body), like BDS and *TKM and MBMS Sure. Thanks for your review Frank. regards, Lakshminath >- There is a typo > - "specification [1]defines " to "specification [1] defines " > >If you would like some concrete proposals for changes corresponding to >these >comments please contact me. > >Thanks for your consideration and best regards, Frank > > >=========================== >Dr. Frank Hartung >Ericsson Research >52134 Herzogenrath, Germany >Frank.Hartung@ericsson.com > > > > > > > > -----Original Message----- > > > > From: msec-bounces@securemulticast.org > > > > [mailto:msec-bounces@securemulticast.org] On Behalf Of Lakshminath > > > > Dondeti > > > > Sent: Saturday, April 29, 2006 1:40 AM > > > > To: msec@securemulticast.org > > > > Subject: [MSEC] Fwd: I-D > > > > ACTION:draft-dondeti-msec-mikey-genext-oma-00.txt > > > > > > > > Strictly as an IETF contributor, I am requesting reviews on this > > > > document. This is an IANA registration request of a new GenExt > > > > payload for MIKEY. > > > > > > > > regards, > > > > Lakshminath > > > > > > > > > > > > >To: i-d-announce@ietf.org > > > > >Cc: > > > > >From: Internet-Drafts@ietf.org > > > > >Date: Fri, 28 Apr 2006 15:50:01 -0400 > > > > >X-Spam-Score: -2.6 (--) > > > > >X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 > > > > >Subject: I-D ACTION:draft-dondeti-msec-mikey-genext-oma-00.txt > > > > >X-BeenThere: i-d-announce@ietf.org > > > > >X-Mailman-Version: 2.1.5 > > > > >Reply-To: internet-drafts@ietf.org > > > > >List-Id: i-d-announce.ietf.org > > > > >List-Unsubscribe: > > > > , > > > > > > > > > > > >List-Archive: > > > > >List-Post: > > > > >List-Help: > > > > >List-Subscribe: > > > > , > > > > > > > > > >X-PMX-Version: 4.7.0.111621 > > > > >X-PMX-Version: 5.1.2.240295, Antispam-Engine: 2.3.0.1, > > > > >Antispam-Data: 2006.4.28.135109 > > > > >X-OriginalArrivalTime: 28 Apr 2006 21:15:10.0229 (UTC) > > > > >FILETIME=[D4E47450:01C66B08] > > > > > > > > > >A New Internet-Draft is available from the on-line > > Internet-Drafts > > > > >directories. > > > > > > > > > > > > > > > Title : OMA BCAST MIKEY General > > Extension Payload > > > > > Specification > > > > > Author(s) : L. Dondeti, D. Castleford > > > > > Filename : > > draft-dondeti-msec-mikey-genext-oma-00.txt > > > > > Pages : 7 > > > > > Date : 2006-4-28 > > > > > > > > > > This document specifies a new general extension payload > > > > type for use > > > > > in the Open Mobile Alliance's (OMA) Browser and Content (BAC) > > > > > Broadcast (BCAST) group. OMA BCAST's service and > > > > content protection > > > > > specification uses short term key message (STKM) and > > > > long term key > > > > > message (LTKM) payloads that in certain broadcast > > distribution > > > > > systems (BDS) are carried in the IETF MIKEY protocol > > [1]. A new > > > > > MIKEY general extension payload specified in this > > > > document will be > > > > > used for that purpose. > > > > > > > > > > > > > > > > > > > >A URL for this Internet-Draft is: > > > > >http://www.ietf.org/internet-drafts/draft-dondeti-msec-mikey- > > > > genext-oma > > > > >-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-dondeti-msec-mikey-genext-oma-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-dondeti-msec-mikey-genext-oma-00.txt". > > > > > > > > > >NOTE: The mail server at ietf.org can return the document in > > > > > MIME-encoded form by using the "mpack" utility. > > To use this > > > > > feature, insert the command "ENCODING mime" before > > > > the "FILE" > > > > > command. To decode the response(s), you will need > > > > "munpack" or > > > > > a MIME-compliant mail reader. Different > > > > MIME-compliant mail readers > > > > > exhibit different behavior, especially when dealing with > > > > > "multipart" MIME messages (i.e. documents which > > > > have been split > > > > > up into multiple messages), so check your local > > > > documentation on > > > > > how to manipulate these messages. > > > > > > > > > > > > > > >Below is the data which will enable a MIME compliant mail reader > > > > >implementation to automatically retrieve the ASCII version of the > > > > >Internet-Draft. > > > > > > > > > >Content-Type: text/plain > > > > >Content-ID: <2006-4-28135953.I-D@ietf.org> > > > > > > > > > >ENCODING mime > > > > >FILE /internet-drafts/draft-dondeti-msec-mikey-genext-oma-00.txt > > > > > > > > > > > > > > > > > genext-oma > > > > >-00.txt> _______________________________________________ > > > > >I-D-Announce mailing list > > > > >I-D-Announce@ietf.org > > > > >https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed May 17 07:33:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgKHa-0003Ja-TS for msec-archive@lists.ietf.org; Wed, 17 May 2006 07:33:38 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgKHZ-00035G-It for msec-archive@lists.ietf.org; Wed, 17 May 2006 07:33:38 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 47AE32C3B7; Wed, 17 May 2006 07:33: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 BCD142BB43 for ; Wed, 17 May 2006 07:33:29 -0400 (EDT) Received: (qmail 46362 invoked by uid 3269); 17 May 2006 11:33:29 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 46359 invoked from network); 17 May 2006 11:33:29 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 17 May 2006 11:33:29 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 724436835D for ; Wed, 17 May 2006 07:33:29 -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 k4HBXRTU015928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 May 2006 04:33:28 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-65-2.qualcomm.com [10.50.65.2]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4HBXN07027364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 17 May 2006 04:33:26 -0700 (PDT) Message-Id: <6.2.5.6.2.20060517043046.0399b2f8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 17 May 2006 04:33:26 -0700 To: Brian Weis From: Lakshminath Dondeti In-Reply-To: <4436F619.5060208@cisco.com> References: <6.2.5.6.2.20060406094758.059a5528@qualcomm.com> <4436F619.5060208@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: msec@securemulticast.org Subject: [MSEC] Re: GDOI update document scoping questions 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: 34d35111647d654d033d58d318c0d21a It looks like I am the only one with some esoteric issues on this, so with the chair hat on I am going to suggest that we ignore my comments for the moment. Let's make this a WG document. Brian and Sheela, I need proposed milestones; planned date for the submission of the revised version, and for LC. Please send those as soon as you can. Thanks. regards, Lakshminath At 04:30 PM 4/7/2006, Brian Weis wrote: >Hi Laksminath, > >Lakshminath Dondeti wrote: >> >>Hi Brian and Sheela, >>I raised a few questions on the scope of the GDOI Update document >>(3547bis?). First, there is the issue of introducing AH support in >>GDOI. I have a few questions here, first I would like the case for >>AH support discussed on the list, so I will ask the question again >>that I asked in Dallas. Why is AH support needed? Is >>ESP-NULL-Encryption not sufficient? > >You're really asking why AH is relevant when ESP-NULL-Encryption >could be used. There *is* a difference between the two, which is >that AH authenticates the IP header whereas ESP does not. The IPsec >community is used to thinking about VPN scenarios where >authentication of the IP addresses seems irrelevant because there >are just two endpoints sharing the keys anyway. However, in some >group applications header authentication is valuable to prove that >the *source* of the IP packet was not changed in transit. GDOI >should support AH for those applications. For example, the >Source-Specific Multicast architecture specification discusses the >risks of spoofed source addresses. > >Another reason to support AH is that, for better or worse, some >specifications dictate support for AH, and they are group >applications. Most notably the PIM family of multicast routing >protocols (PIM-DM, PIM-SM, PIM-Bidir) and OSPFv3. The protocols are >often keyed manually and they deserve to use a dynamic key >management system too! :-) > > > What if any changes are required to the MSEC-IPsec > > extensions document due to the addition of AH support? > >Because RFC 4301 specifies AH as a valid (i.e., not deprecated) >IPsec protocol, the MSEC-IPsec extensions document mentions it as well. > >>Second, what is the scope of the GDOI update document. Or is it >>open ended? I am not really too particular about either approach >>(in moderation of course, we don't want to redesign GDOI, just >>update, hopefully with backward compatibility -- or is this is req >>that you have in mind?). > >The scope we had in mind was 1) deal with hash agility, 2) >clarifications to text based on implementation experience, and 3) >minor additions to the protocol. Backward compatibility was intended >if not explicitly stated. > >With this scope in mind, minor additions in addition to what we >specified in the draft that maintain backward compatibility could be >considered. > >Come to think of it, there's one other area we should add to the >scope. The MSEC-IPsec extension document describes some additional >key management attributes that would be new to GDOI. > >>While I am on topic, do you plan to introduce capabilities like >>sender/receiver indication in GSA download? > >If this can be done without breaking backwards compatibility, it >could make sense. We didn't intend to introduce it ourselves. > >>I think I promised to review the I-D this week, but it looks like >>my schedule won't allow it, but will make it a higher priority next week. > >That'd be great, thanks! >Brian > >>thanks and regards, >>Lakshminath >> > > >-- >Brian Weis >Advanced Security Development, Security Technology Group, Cisco Systems >Telephone: +1 408 526 4796 >Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed May 17 07:47:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgKVF-0006K4-4N for msec-archive@lists.ietf.org; Wed, 17 May 2006 07:47:45 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgKVE-0003ua-Qs for msec-archive@lists.ietf.org; Wed, 17 May 2006 07:47:45 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id B47862C858; Wed, 17 May 2006 07:47:44 -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 0E0A82C7B6 for ; Wed, 17 May 2006 07:47:43 -0400 (EDT) Received: (qmail 49406 invoked by uid 3269); 17 May 2006 11:47:43 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 49403 invoked from network); 17 May 2006 11:47:43 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 17 May 2006 11:47:43 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id B47776838B for ; Wed, 17 May 2006 07:47:42 -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 k4HBlK5U016589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 May 2006 04:47:21 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-65-2.qualcomm.com [10.50.65.2]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4HBl9sX003998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 17 May 2006 04:47:16 -0700 (PDT) Message-Id: <6.2.5.6.2.20060517044413.0397e268@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 17 May 2006 04:47:11 -0700 To: vincent.roca@inrialpes.fr From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: canetti@watson.ibm.com, rmt@ietf.org, msec@securemulticast.org Subject: [MSEC] Fwd: [Rmt] Consensus call: making draft-faurite-rmt-tesla-for-alc-norm-01 an MSEC WG item 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Hi Vincent, We'll call this a WG draft since we've heard no objections. However, we need at least 3 reviewers who are willing to do two reviews: an early review and a last call review (All, please consider this an open call to sign-up as reviewers). We also need a proposed plan for submission of a revised version as a WG draft, and a proposed WGLC date (this is going to be LC'ed in MSEC and RMT WGs). Thank you. best regards, Lakshminath >X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 >Date: Mon, 03 Apr 2006 10:01:39 -0700 >To: msec@securemulticast.org >From: Lakshminath Dondeti >X-Spam-Score: 0.0 (/) >X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 >Cc: rmt@ietf.org >Subject: [Rmt] Consensus call: making draft-faurite-rmt-tesla-for-alc-norm-01 > an MSEC WG item >X-BeenThere: rmt@ietf.org >X-Mailman-Version: 2.1.5 >List-Id: Reliable Multicast Transport >List-Unsubscribe: , > >List-Post: >List-Help: >List-Subscribe: , > >X-PMX-Version: 4.7.0.111621 >X-PMX-Version: 5.1.2.240295, Antispam-Engine: 2.3.0.1, >Antispam-Data: 2006.4.3.94607 >X-OriginalArrivalTime: 03 Apr 2006 17:02:15.0035 (UTC) >FILETIME=[5B71DCB0:01C65740] > >Hi all, > >Please send any objections you might have on making >draft-faurite-rmt-tesla-for-alc-norm-01 >an MSEC WG item. We also need to hear from folks who are interested >in this becoming an RFC and need at least 3 volunteers to review the >document (early and LC reviews). > >regards, >Lakshminath > >_______________________________________________ >Rmt mailing list >Rmt@ietf.org >https://www1.ietf.org/mailman/listinfo/rmt _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu May 18 10:54:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgjtV-0001wW-3v for msec-archive@lists.ietf.org; Thu, 18 May 2006 10:54:29 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgjtS-0006nV-RL for msec-archive@lists.ietf.org; Thu, 18 May 2006 10:54:29 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 84A942C951; Thu, 18 May 2006 10:54:22 -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 BBD4F2C91E for ; Thu, 18 May 2006 10:54:21 -0400 (EDT) Received: (qmail 39010 invoked by uid 3269); 18 May 2006 14:54:21 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 39007 invoked from network); 18 May 2006 14:54:21 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 18 May 2006 14:54:21 -0000 Received: from mx-serv.inrialpes.fr (mx-serv.inrialpes.fr [194.199.18.100]) by klesh.pair.com (Postfix) with ESMTP id 64A2D68362 for ; Thu, 18 May 2006 10:54:21 -0400 (EDT) Received: from vilnius.inrialpes.fr (vilnius.inrialpes.fr [194.199.18.81]) by mx-serv.inrialpes.fr (8.13.6/8.13.0) with ESMTP id k4IEra9R005138; Thu, 18 May 2006 16:53:37 +0200 (MEST) Received: from [194.199.24.102] (demeter.inrialpes.fr [194.199.24.102]) by vilnius.inrialpes.fr (8.13.6/8.11.3/ImagV2) with ESMTP id k4IErY7E015123; Thu, 18 May 2006 16:53:34 +0200 (MEST) Message-ID: <446C8A70.7020908@inrialpes.fr> Date: Thu, 18 May 2006 16:53:36 +0200 From: Vincent Roca User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lakshminath Dondeti Subject: Re: [MSEC] Fwd: [Rmt] Consensus call: making draft-faurite-rmt-tesla-for-alc-norm-01 an MSEC WG item References: <6.2.5.6.2.20060517044413.0397e268@qualcomm.com> In-Reply-To: <6.2.5.6.2.20060517044413.0397e268@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mx-serv.inrialpes.fr [194.199.18.100]); Thu, 18 May 2006 16:53:37 +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, canetti@watson.ibm.com, rmt@ietf.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: 2409bba43e9c8d580670fda8b695204a Hello Lakshminath and all, > We'll call this a WG draft since we've heard no objections. However, > we need at least 3 reviewers who are willing to do two reviews: an > early review and a last call review (All, please consider this an open > call to sign-up as reviewers). We also need a proposed plan for > submission of a revised version as a WG draft, and a proposed WGLC > date (this is going to be LC'ed in MSEC and RMT WGs). Thank you. The revised version will be ready for IETF'66. It will essentially consist in taking into account the feedback from last meeting (in particular the need to make this specification self-sufficient, unlike what I explained during the meeting!). Concerning a possible WGLC date, we'll probably need one extra meetings after this one, so a target date could be after November 2007. But it also depends on the reviewers feedback! Regards, Vincent. _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Sat May 20 23:15:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhePu-0000jY-C4 for msec-archive@lists.ietf.org; Sat, 20 May 2006 23:15:42 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhePs-0002oR-T0 for msec-archive@lists.ietf.org; Sat, 20 May 2006 23:15:42 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 6BF2D2C867; Sat, 20 May 2006 23:15:30 -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 0EE622C697 for ; Sat, 20 May 2006 23:15:29 -0400 (EDT) Received: (qmail 49652 invoked by uid 3269); 21 May 2006 03:15:29 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 49649 invoked from network); 21 May 2006 03:15:28 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 21 May 2006 03:15:28 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id AB2A668369 for ; Sat, 20 May 2006 23:15:28 -0400 (EDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4L3FEqJ032483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 20 May 2006 20:15:15 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-73-218.qualcomm.com [10.50.73.218]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4L3EvDE026469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 20 May 2006 20:15:13 -0700 (PDT) Message-Id: <6.2.5.6.2.20060520184839.054f3a00@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 20 May 2006 19:11:34 -0700 To: Scott W Brim , dignjatic@polycom.com, audet@nortel.com, linping@nortel.com, housley@vigilsec.com, hartmans-ietf@mit.edu, canetti@watson.ibm.com, msec@securemulticast.org, gen-art@ietf.org From: Lakshminath Dondeti In-Reply-To: <20060518205223.GA4520@sbrim-wxp01> References: <20060518205223.GA4520@sbrim-wxp01> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: [MSEC] Re: gen-art review of draft-ietf-msec-mikey-rsa-r-04.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: 0cff8c3ec906d056784362c06f5f88c1 Hi Scott, Many thanks for your review. You make very good points. Some notes and proposed resolutions below. We'll wait for the sec-dir review also and incorporate all the comments in one revision. Dragan, Ping, and Francois, please feel free to correct me or make further clarifications. Thanks. >-----Original Message----- >From: Scott W Brim [mailto:sbrim@cisco.com] >Sent: May 18, 2006 1:52 PM >To: Ignjatic, Dragan; ldondeti@qualcomm.com; audet@nortel.com; >linping@nortel.com; housley@vigilsec.com; hartmans-ietf@mit.edu; >canetti@watson.ibm.com; msec@securemulticast.org; gen-art@ietf.org >Subject: gen-art review of draft-ietf-msec-mikey-rsa-r-04.txt > >I am the assigned Gen-ART reviewer for >draft-ietf-msec-mikey-rsa-r-04.txt. > >For background on Gen-ART, please see the FAQ at >. > >Please resolve these comments along with any other >Last Call comments you may receive. > >This draft is basically ready for publication, but has nits that >should be fixed before publication. > >Here is my review: > >Just before I went through this draft we had been having a discussion >of SHOULD, MUST, etc., and thus I was more aware than usual of their >usage. I found several uses of SHOULD which I believe should be >improved, to make the document clearer for implementors. > >RFC2119 says > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that > there may exist valid reasons in particular circumstances > to ignore a particular item, but the full implications must > be understood and carefully weighed before choosing a > different course. > >To help implementors "understand and carefully weigh" their decision, >SHOULDs actually require more supporting text than MUSTs. > >The draft says: > > The RAND payload SHOULD be included in the I_MESSAGE when > MIKEY-RSA-R mode is used for unicast communication. It SHOULD be > omitted when this mode is used to establish group keys. The reason > for the inclusion of the RAND payload in unicast scenarios is to > allow for the Initiator to contribute entropy to the key derivation > process (in addition to the CSB_ID). > >There are two SHOULDs here. For the first one, under what conditions >would a Initiator not contribute entropy? Should this SHOULD be a >MAY? A MUST? If it should be a SHOULD, please explain the >exceptions. We are RECOMMENDING, but if an Initiator chooses to not contribute randomness, that's ok. It is generally desirable that both parties contribute randomness to key derivation, but MIKEY-RSA doesn't do it and RSA-R doesn't force it either. We can add a note to this effect in the revision. >For the second one ("SHOULD be omitted"), are there any conditions >under which it might be legitimate to include the RAND payload for >group keys? If so those conditions should be listed. If not, it >should be a MUST. For this, I am proposing rephrasing to "A RAND payload MAY be included ... " >There is some discussion down in 5.1 but it doesn't seem to answer >these questions. If 5.1 is meant to do so, then please put more >explicit information there and have these SHOULDs refer to it. >Similarly, if I could find the exceptions in rfc3830 somewhere, could >you give a more specific reference to where? 5.1 I guess could contain notes to the effect of "desirable that both parties contribute and so we added the feature that's absent in MIKEY-RSA." >(One also wonders about the threat model where more entropy is needed >for unicast keys than group keys.) This is a matter of two parties with data to send contributing entropy to derivation of keys that protect the said data. The two parties are interested in protecting their individual streams and so either they can pick their own key (the sdescriptions protocol does this for instance) or the two parties can contribute entropy to key derivation (IKEv2 is an example here). In group communication, the sender cares about the confidentiality of data and so it's in the sender's interest to generate strong keys. >Here is a related SHOULD issue: > > o If a RAND payload is present in the I_MESSAGE, both sides use > that RAND payload as the RAND value in the MIKEY key > computation. In case of multicast, if a RAND payload is present > in the I_MESSAGE, the Responder SHOULD ignore the payload. In > any case, the R_MESSAGE for multicast communication MUST contain > a RAND payload and that RAND payload is used for key > computation. > >So the sender should omit the RAND payload in the multicast case >stated above), and if sent, the receiver SHOULD ignore it. Under what >conditions is it appropriate for the receiver NOT to ignore it? >Should this be a MUST? The responder (group sender or controller) may choose to use the RAND payload to seed it's random number generator, but I don't want to suggest that in the draft, as that is merely a technique not central to the operation of the protocol. I am ok with MUST ignore it. Even with that end systems may choose to use the RAND information, but that does not impact externally observable behavior. >... and then two more, unrelated: > > The Initiator MAY also send security policy (SP) payload(s) > containing all the security policies that it supports. If the > Responder does not support any of the policies included, it SHOULD > reply with an Error message of type "Invalid SPpar" (Error no. 10). 5.1 and 5.1.2 of RFC 3830 suggest SHOULD and we are continuing that here. I guess the intention is to allow silent discarding. Other signaling (SIP for instance) could indicate that the security context establishment did not succeed. We want to allow that. Thoughts? >Under what conditions would the Responder not reply with that error >message? Is this a MAY? > > When used in group scenarios with bi-directional media, the > Responder SHOULD include two TGKs or TEKs in the KEMAC payload. > The first TGK or TEK SHOULD be used for receiving media on the > Initiator's side and the second one to encrypt/authenticate media > originating on the Initiator's side. This allows all the multicast > traffic to be encrypted/authenticated by the same group key, while > keys used for unicast streams from all the group members can still > be independent. > >Again ... when is it appropriate not to include two TGKs or TEKs? >When is it appropriate for the Initiator not to use the first key for >receiving and the second for sending? Should these two SHOULDs be >MUSTs? If not, please make the exceptions clear. So, this is a feature that we contemplated about not specifying in the RSA-R document. The conclusion after a discussion between Dragan and me is that this should be removed from this specification and if there is interest should be specified in the general sense elsewhere. We propose to remove the specification of how to carry multiple TGKs in RSA-R (they can be carried, some notes are in 3830, full details belong elsewhere.). Any objections from anyone (MSEC folks are also recipients of this message)? regards, Lakshminath >Thanks. > >swb _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue May 23 19:21:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FigBe-0006Ur-0p for msec-archive@lists.ietf.org; Tue, 23 May 2006 19:21:14 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FigBc-00020W-IR for msec-archive@lists.ietf.org; Tue, 23 May 2006 19:21:14 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 451252BA50; Tue, 23 May 2006 19:21: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 30E732B8E0 for ; Tue, 23 May 2006 19:21:08 -0400 (EDT) Received: (qmail 51968 invoked by uid 3269); 23 May 2006 23:21:08 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 51965 invoked from network); 23 May 2006 23:21:08 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 23 May 2006 23:21:08 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id BC38C68360 for ; Tue, 23 May 2006 19:21:07 -0400 (EDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4NNKmK1032173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 23 May 2006 16:20:48 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4NNKjeO010609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 May 2006 16:20:46 -0700 (PDT) Message-Id: <6.2.5.6.2.20060523161936.05e9bd30@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 23 May 2006 16:20:34 -0700 To: Scott W Brim , dignjatic@polycom.com, audet@nortel.com, linping@nortel.com, housley@vigilsec.com, hartmans-ietf@mit.edu, canetti@watson.ibm.com, msec@securemulticast.org, gen-art@ietf.org From: Lakshminath Dondeti Subject: Re: [MSEC] Re: gen-art review of draft-ietf-msec-mikey-rsa-r-04.txt In-Reply-To: <6.2.5.6.2.20060520184839.054f3a00@qualcomm.com> References: <20060518205223.GA4520@sbrim-wxp01> <6.2.5.6.2.20060520184839.054f3a00@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: 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: 86f85b2f88b0d50615aed44a7f9e33c7 Hi Scott, We have received all the reviews and are now ready to update the document, once you give the go ahead that the proposed resolutions are ok. Please let us know at your earliest convenience. Thanks. Lakshminath At 07:11 PM 5/20/2006, Lakshminath Dondeti wrote: >Hi Scott, > >Many thanks for your review. You make very good points. Some notes >and proposed resolutions below. We'll wait for the sec-dir review >also and incorporate all the comments in one revision. > >Dragan, Ping, and Francois, please feel free to correct me or make >further clarifications. Thanks. > > >>-----Original Message----- >>From: Scott W Brim [mailto:sbrim@cisco.com] >>Sent: May 18, 2006 1:52 PM >>To: Ignjatic, Dragan; ldondeti@qualcomm.com; audet@nortel.com; >>linping@nortel.com; housley@vigilsec.com; hartmans-ietf@mit.edu; >>canetti@watson.ibm.com; msec@securemulticast.org; gen-art@ietf.org >>Subject: gen-art review of draft-ietf-msec-mikey-rsa-r-04.txt >> >>I am the assigned Gen-ART reviewer for >>draft-ietf-msec-mikey-rsa-r-04.txt. >> >>For background on Gen-ART, please see the FAQ at >>. >> >>Please resolve these comments along with any other >>Last Call comments you may receive. >> >>This draft is basically ready for publication, but has nits that >>should be fixed before publication. >> >>Here is my review: >> >>Just before I went through this draft we had been having a discussion >>of SHOULD, MUST, etc., and thus I was more aware than usual of their >>usage. I found several uses of SHOULD which I believe should be >>improved, to make the document clearer for implementors. >> >>RFC2119 says >> >> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that >> there may exist valid reasons in particular circumstances >> to ignore a particular item, but the full implications must >> be understood and carefully weighed before choosing a >> different course. >> >>To help implementors "understand and carefully weigh" their decision, >>SHOULDs actually require more supporting text than MUSTs. >> >>The draft says: >> >> The RAND payload SHOULD be included in the I_MESSAGE when >> MIKEY-RSA-R mode is used for unicast communication. It SHOULD be >> omitted when this mode is used to establish group keys. The reason >> for the inclusion of the RAND payload in unicast scenarios is to >> allow for the Initiator to contribute entropy to the key derivation >> process (in addition to the CSB_ID). >> >>There are two SHOULDs here. For the first one, under what conditions >>would a Initiator not contribute entropy? Should this SHOULD be a >>MAY? A MUST? If it should be a SHOULD, please explain the >>exceptions. > >We are RECOMMENDING, but if an Initiator chooses to not contribute >randomness, that's ok. It is generally desirable that both parties >contribute randomness to key derivation, but MIKEY-RSA doesn't do it >and RSA-R doesn't force it either. We can add a note to this effect >in the revision. > > >>For the second one ("SHOULD be omitted"), are there any conditions >>under which it might be legitimate to include the RAND payload for >>group keys? If so those conditions should be listed. If not, it >>should be a MUST. > >For this, I am proposing rephrasing to "A RAND payload MAY be included ... " > > >>There is some discussion down in 5.1 but it doesn't seem to answer >>these questions. If 5.1 is meant to do so, then please put more >>explicit information there and have these SHOULDs refer to it. >>Similarly, if I could find the exceptions in rfc3830 somewhere, could >>you give a more specific reference to where? > >5.1 I guess could contain notes to the effect of "desirable that >both parties contribute and so we added the feature that's absent in >MIKEY-RSA." > > >>(One also wonders about the threat model where more entropy is needed >>for unicast keys than group keys.) > >This is a matter of two parties with data to send contributing >entropy to derivation of keys that protect the said data. The two >parties are interested in protecting their individual streams and so >either they can pick their own key (the sdescriptions protocol does >this for instance) or the two parties can contribute entropy to key >derivation (IKEv2 is an example here). In group communication, the >sender cares about the confidentiality of data and so it's in the >sender's interest to generate strong keys. > > >>Here is a related SHOULD issue: >> >> o If a RAND payload is present in the I_MESSAGE, both sides use >> that RAND payload as the RAND value in the MIKEY key >> computation. In case of multicast, if a RAND payload is present >> in the I_MESSAGE, the Responder SHOULD ignore the payload. In >> any case, the R_MESSAGE for multicast communication MUST contain >> a RAND payload and that RAND payload is used for key >> computation. >> >>So the sender should omit the RAND payload in the multicast case >>stated above), and if sent, the receiver SHOULD ignore it. Under what >>conditions is it appropriate for the receiver NOT to ignore it? >>Should this be a MUST? > >The responder (group sender or controller) may choose to use the >RAND payload to seed it's random number generator, but I don't want >to suggest that in the draft, as that is merely a technique not >central to the operation of the protocol. I am ok with MUST ignore >it. Even with that end systems may choose to use the RAND >information, but that does not impact externally observable behavior. > > >>... and then two more, unrelated: >> >> The Initiator MAY also send security policy (SP) payload(s) >> containing all the security policies that it supports. If the >> Responder does not support any of the policies included, it SHOULD >> reply with an Error message of type "Invalid SPpar" (Error no. 10). > >5.1 and 5.1.2 of RFC 3830 suggest SHOULD and we are continuing that >here. I guess the intention is to allow silent discarding. Other >signaling (SIP for instance) could indicate that the security >context establishment did not succeed. We want to allow that. Thoughts? > > >>Under what conditions would the Responder not reply with that error >>message? Is this a MAY? >> >> When used in group scenarios with bi-directional media, the >> Responder SHOULD include two TGKs or TEKs in the KEMAC payload. >> The first TGK or TEK SHOULD be used for receiving media on the >> Initiator's side and the second one to encrypt/authenticate media >> originating on the Initiator's side. This allows all the multicast >> traffic to be encrypted/authenticated by the same group key, while >> keys used for unicast streams from all the group members can still >> be independent. >> >>Again ... when is it appropriate not to include two TGKs or TEKs? >>When is it appropriate for the Initiator not to use the first key for >>receiving and the second for sending? Should these two SHOULDs be >>MUSTs? If not, please make the exceptions clear. > >So, this is a feature that we contemplated about not specifying in >the RSA-R document. The conclusion after a discussion between >Dragan and me is that this should be removed from this specification >and if there is interest should be specified in the general sense >elsewhere. We propose to remove the specification of how to carry >multiple TGKs in RSA-R (they can be carried, some notes are in 3830, >full details belong elsewhere.). Any objections from anyone (MSEC >folks are also recipients of this message)? > >regards, >Lakshminath > >>Thanks. >> >>swb > >_______________________________________________ >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 Sun May 28 20:23:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkVXC-0007wL-Il for msec-archive@lists.ietf.org; Sun, 28 May 2006 20:23:02 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkVXA-0001wu-B6 for msec-archive@lists.ietf.org; Sun, 28 May 2006 20:23:02 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 065C52C848; Sun, 28 May 2006 20:22: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 E105A2C455 for ; Sun, 28 May 2006 20:22:53 -0400 (EDT) Received: (qmail 16854 invoked by uid 3269); 29 May 2006 00:22:53 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 16851 invoked from network); 29 May 2006 00:22:53 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 29 May 2006 00:22:53 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 96B8A6836C for ; Sun, 28 May 2006 20:22:53 -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 k4T0MpKm028319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 28 May 2006 17:22:52 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-64-42.qualcomm.com [10.50.64.42]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4T0MjLx024215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 28 May 2006 17:22:51 -0700 (PDT) Message-Id: <6.2.5.6.2.20060528171347.0417e420@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 28 May 2006 17:22:34 -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 meeting scheduling & Some deadlines around the corner 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: 7d33c50f3756db14428398e2bdedd581 June 5, Monday - Cutoff date for requests to schedule Working Group and BOF meetings at 17:00 ET (21:00 UTC/GMT). Please send me proposals for any face2face discussions in Montreal. Ran and I need to figure out whether we need to request a 1hr or a 2hr meeting. June 12, Monday - Working Group Chair approval for initial document (Version -00) submissions appreciated by 09:00 ET (13:00 UTC/GMT) We have a few of these pending, so I request the authors to do this ASAP. Please send us the proposed titles and we'll get them approved for submission before the -00- deadline. thanks, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec