From msec-bounces@securemulticast.org Wed Mar 01 02:26:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FELjG-0007r3-Ln for msec-archive@lists.ietf.org; Wed, 01 Mar 2006 02:26:34 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FELWK-0000Qz-I8 for msec-archive@lists.ietf.org; Wed, 01 Mar 2006 02:13:18 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id E9A862C488; Wed, 1 Mar 2006 02:13:11 -0500 (EST) 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 C75042BBCE for ; Wed, 1 Mar 2006 02:13:10 -0500 (EST) Received: (qmail 56669 invoked by uid 3269); 1 Mar 2006 07:13:10 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 56665 invoked from network); 1 Mar 2006 07:13:10 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 1 Mar 2006 07:13:10 -0000 Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) by klesh.pair.com (Postfix) with ESMTP id 56B7168386 for ; Wed, 1 Mar 2006 02:13:10 -0500 (EST) Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k217D775013433; Wed, 1 Mar 2006 08:13:07 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k217D55p002293; Wed, 1 Mar 2006 08:13:07 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Mar 2006 08:13:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C63CFF.93BF65C7" Date: Wed, 1 Mar 2006 08:13:01 +0100 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-fries-msec-mikey-applicability-00.txt thread-index: AcY8rMSTm0JWcYeNRXeIXWu/vRHz1QAUm5Og From: "Fries, Steffen" To: X-OriginalArrivalTime: 01 Mar 2006 07:13:06.0143 (UTC) FILETIME=[963B3EF0:01C63CFF] Cc: Subject: [MSEC] FW: I-D ACTION:draft-fries-msec-mikey-applicability-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: 37af5f8fbf6f013c5b771388e24b09e7 This is a multi-part message in MIME format. ------_=_NextPart_001_01C63CFF.93BF65C7 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi all, the draft just appeared on the reflector.=20 During the last IETF meeting we discussed about a document providing an overview about MIKEY and the extentions. This is targeted by this ID.=20 Regards Steffen -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Tuesday, February 28, 2006 9:50 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-fries-msec-mikey-applicability-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : On the applicability of various MIKEY modes and extensions Author(s) : S. Fries, D. Ignjatic Filename : draft-fries-msec-mikey-applicability-00.txt Pages : 20 Date : 2006-2-28 =09 Multimedia Internet Keying - MIKEY - is a key management scheme that 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. 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, but also in terms of payload enhancements. 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fries-msec-mikey-applicability -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. =20 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-fries-msec-mikey-applicability-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-fries-msec-mikey-applicability-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C63CFF.93BF65C7 Content-Type: application/octet-stream; name="draft-fries-msec-mikey-applicability-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-fries-msec-mikey-applicability-00.URL Content-Disposition: attachment; filename="draft-fries-msec-mikey-applicability-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1mcmllcy1tc2VjLW1pa2V5LWFwcGxpY2FiaWxpdHktMDAudHh0DQo= ------_=_NextPart_001_01C63CFF.93BF65C7 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 ------_=_NextPart_001_01C63CFF.93BF65C7-- From msec-bounces@securemulticast.org Wed Mar 01 09:24:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FESFk-000250-Bn for msec-archive@lists.ietf.org; Wed, 01 Mar 2006 09:24:32 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FESFj-0007fj-3n for msec-archive@lists.ietf.org; Wed, 01 Mar 2006 09:24:32 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 32E6C2CD94; Wed, 1 Mar 2006 09:24:30 -0500 (EST) 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 31F082CD3F for ; Wed, 1 Mar 2006 09:24:28 -0500 (EST) Received: (qmail 73171 invoked by uid 3269); 1 Mar 2006 14:24:28 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 73168 invoked from network); 1 Mar 2006 14:24:28 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 1 Mar 2006 14:24:28 -0000 Received: from mx-serv.inrialpes.fr (mx-serv.inrialpes.fr [194.199.18.100]) by klesh.pair.com (Postfix) with ESMTP id E86FE6837D for ; Wed, 1 Mar 2006 09:24:27 -0500 (EST) Received: from dwimmerlaik.inrialpes.fr (dwimmerlaik.inrialpes.fr [194.199.18.72]) by mx-serv.inrialpes.fr (8.13.0/8.13.0) with ESMTP id k21EOJ1P007012; Wed, 1 Mar 2006 15:24:19 +0100 (MET) Received: from [194.199.24.102] (demeter.inrialpes.fr [194.199.24.102]) by dwimmerlaik.inrialpes.fr (8.13.4/8.11.3/ImagV2) with ESMTP id k21EOIIi023036; Wed, 1 Mar 2006 15:24:18 +0100 (MET) Message-ID: <4405AE93.4030606@inrialpes.fr> Date: Wed, 01 Mar 2006 15:24:19 +0100 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: rmt@ietf.org, msec@securemulticast.org 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]); Wed, 01 Mar 2006 15:24:20 +0100 (MET) X-SMAUG-MailScanner: Found to be clean X-SMAUG-MailScanner-From: vincent.roca@inrialpes.fr Cc: Vincent Roca , Sebastien Faurite Subject: [MSEC] New version of "TESLA for ALC/NORM" available 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: 08170828343bcf1325e4a0fb4584481c Hello everybody, A new version of the following I-D is now available: The Use of TESLA in the ALC and NORM Protocols http://www.ietf.org/internet-drafts/draft-faurite-rmt-tesla-for-alc-norm-01.txt As explained before, this document will be presented in both groups (MSEC/RMT) at next IETF. Cheers, The authors. _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Mar 03 04:36:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF6hy-0002Oy-V7 for msec-archive@lists.ietf.org; Fri, 03 Mar 2006 04:36:22 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF6hx-0004rX-Ji for msec-archive@lists.ietf.org; Fri, 03 Mar 2006 04:36:22 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 283B22C8A1; Fri, 3 Mar 2006 04:36:21 -0500 (EST) 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 9E2BB2C4C1 for ; Fri, 3 Mar 2006 04:36:19 -0500 (EST) Received: (qmail 10533 invoked by uid 3269); 3 Mar 2006 09:36:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10530 invoked from network); 3 Mar 2006 09:36:18 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 3 Mar 2006 09:36:18 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 36BF768388 for ; Fri, 3 Mar 2006 04:36:17 -0500 (EST) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k239a8Ms017947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 3 Mar 2006 01:36:09 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-77-12.qualcomm.com [10.50.77.12]) by sabrina.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k239a5aM002497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Mar 2006 01:36:06 -0800 (PST) Message-Id: <6.2.5.6.2.20060303005208.055e50a0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 03 Mar 2006 01:36:03 -0800 To: "Vesa Lehtovirta (JO/LMF)" , "Ignjatic, Dragan" , From: Lakshminath Dondeti Subject: Re: [MSEC] Comments to draft draft-ietf-msec-mikey-rsa-r-02.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ld@qualcomm.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: 29dc808194f5fb921c09d0040806d6eb Hi Vesa, Many thanks for your comments. I apologize for the delay in my response. Dragan and I were I guess hoping the other would respond and he noted he will be commenting tomorrow. I will try to address your comments below: At 01:25 AM 2/24/2006, Vesa Lehtovirta \(JO/LMF\) wrote: >Hi all, > >Here are some comments, and also questions, to the >draft-ietf-msec-mikey-rsa-r-02.txt. > >In general the draft is well written and an interesting approach. > >Best regards, > > Vesa > >- Issue: Abstract says that >"The Multimedia Internet Keying (MIKEY) specification describes >several modes of key distribution to setup Secure Real-time Rransport >Protocol (SRTP) sessions..." > >Comment: The draft generally gives the impression that MIKEY is used >solely for setting up keys for SRTP. However, MIKEY is not >restricted to SRTP only, although certain parameters have been >specified already for SRTP in MIKEY RFC3830. MIKEY is extensible to >be used with other security protocols also but this may require that >needed parameters can be specified also for other security >protocols. Therefore, it would be good to mention SRTP as one >possible security protocol and not the only possible one. Or is it >the intention that this would be used only with SRTP? I appreciate the distinction you are making. We'll address this by rewording that paragraph. >- Issue: One of the main points in the draft is that the Initiator >may not know the Responder's ID and in 3.2 it is said for the I_MESSAGE: > >"If the Responder has multiple Identities, the Initiator MAY also >include the specific ID, IDr, of the Responder that it wants to >communicate with." > >Comment: The question is, if the IDr is not indicated in the >I_MESSAGE, how can the message be routed to the correct responder? >If this is assumed to be done in some other layer, e.g. SIP, how can >the initiator know the SIP layer identity if it does not know the >MIKEY layer identity? Or is it assumed then that e.g. the SIP layer >identity may be known even though the MIKEY layer identity is not known? Yes. But, I guess that MAY can be clarified further. If the Initiator knows the specific Responder's ID it wants to communicate with and specifies it, what happens if due to forking or redirect or something it goes to a different place. W.r.t. routing the message though, my understanding is that's all SIP level and not up to MIKEY. We can only specify how MIKEY messages are to be processed if and when they go to an unintended entity. >- Issue: In 3.2 it is said that "The Initiator MAY indicate the >number of CSs supported,.." but in 3.2 it is said that "The >Responder MUST fill in the number of CSs" >Comment: Why is it differently? Should both be MUST? I think this is ok. If the Responder is a sending to a group (or a group key server), then the Initiator does not need to fill in the CS information. In either case, it is ok to have the Responder fill in the information. Are you suggesting that for the unicast case, the MAY ought to be a SHOULD? >- Issue: In 5 (last para) it is said that "Unicast and multicast >keys have different >security properties and should not be derived from the same pool." Ok, that's vague. We'll clarify further. >Comment: Usually we can trust to one-way key derivation functions to >provide key separation. Is there a reason why we cannot assume it here? > >- Issue: In 5 (last para) it is said that >"The authors believe that multiple TGK payloads can be used for this >purpose but the exact method is not specified in MIKEY." Right, we talked a lot about this and we thought it is under specified or something, but decided that it is out of scope for RSA-R. But that statement might best be removed or further clarified. >Comment: When checking this seems to be specified in 6.2 and 6.13 of >RFC 3830. > >- Smaller stuff: In 3.3 (page 7): What is "complete CS map"? Is it >"CS ID map info"? We'll rewrite that. Thanks for catching this. >- Smaller stuff: In 3.4.1, 3.4.2 and 3.4.3 it could be indicated >what is new information. Will do. >- Finally some comments on some "extra" messages on the proposed >procedure: The current draft proposes a solution where the Initiator >prompts the Responder to send the TGK key. I wonder if the procedure >could be extended with a Verification message to know that the key >has been delivered (as in current MIKEY): > >Init Resp >----- ---- >I_MSG[CERTi] --> > <-- R_MSG(TGK)[CERTr] >I_MSG[Verif] --> > >Also, the current draft does not allow the Initiator to choose the >TGK. I wonder if the procedure could be also extended with a new >message in the beginning of the procedure where the Init could ask >the Resp to request the key from Init. I guess you have thought of >this since this case has been shortly discussed in 4.1 but then you >have abandobed it as too complex?: "For instance, A might ask C to >contact B or itself to get the TGK, in effect initiating a 3-way exchange. " > >Init Resp >----- ---- >I_MSG[CERTi] --> > <-- R_MSG[CERTr] >I_MSG(TGK) --> > That would be a 3-way exchange and my take is no. :-). Thanks Vesa for a very thoughtful and thorough review. We'll address your comments in the next rev. best regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Mar 03 10:29:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFCDE-0001M3-B6 for msec-archive@lists.ietf.org; Fri, 03 Mar 2006 10:29:00 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFCDD-00019f-1O for msec-archive@lists.ietf.org; Fri, 03 Mar 2006 10:29:00 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id D37692CB64; Fri, 3 Mar 2006 10:28:58 -0500 (EST) 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 C83692CA88 for ; Fri, 3 Mar 2006 10:28:56 -0500 (EST) Received: (qmail 71332 invoked by uid 3269); 3 Mar 2006 15:28:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 71329 invoked from network); 3 Mar 2006 15:28:56 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 3 Mar 2006 15:28:56 -0000 Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) by klesh.pair.com (Postfix) with ESMTP id D27496838B for ; Fri, 3 Mar 2006 10:28:55 -0500 (EST) Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k23FSqc8004200; Fri, 3 Mar 2006 16:28:52 +0100 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 k23FSpc7015033; Fri, 3 Mar 2006 16:28:51 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 16:28:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] FW: Submission of draft-lehtovirta-srtp-rcc-01.txt Date: Fri, 3 Mar 2006 16:28:48 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] FW: Submission of draft-lehtovirta-srtp-rcc-01.txt thread-index: AcW0qYr7c8BcuLafRzyrTBuXzRPoch8DFfbQAAAmn+AALxrvUANYjg1Q From: "Fries, Steffen" To: "Vesa Lehtovirta (JO/LMF)" , , X-OriginalArrivalTime: 03 Mar 2006 15:28:51.0540 (UTC) FILETIME=[2CB22140:01C63ED7] Cc: "Jerichow, Anja" , "Rauschenbach, Uwe" 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: 0a7aa2e6e558383d84476dc338324fab Hi Vesa, I just read your draft regarding the SRTP/MIKEY extension. It is a good = enhancement to transmit the ROC in parts pof the SRTP payload.=20 Nevertheless, I have a comment/question to the transform described in = section 2. It is stated that TAG =3D ROC_sender || MAC. What is the = reason that the TAG is constructed in that way, rather than TAG =3D MAC = || ROC_sender? >From my point of view there is an advantage for the latter case. This = approach would provide a better backward compatibility for terminals = which are not aware of the SRTP extension you are describing. If they = get the ROC information by other means (e.g., seperate messages) there = still would be able to handle the MAC verification correctly, as the MAC = starts at the same position as described in RFC3711. When inserting the = ROC before the MAC in the packet, older terminaly would take a part of = the ROC as MAC, which would lead to errors in the MAC verification. Would it influence the security in any way by choosing the TAG =3D MAC = || ROC_sender? Regards Steffen > -----Original Message----- > From: msec-bounces@securemulticast.org=20 > [mailto:msec-bounces@securemulticast.org] On Behalf Of Vesa=20 > Lehtovirta (JO/LMF) > Sent: Tuesday, February 14, 2006 3:31 PM > To: msec@securemulticast.org; avt@ietf.org > Cc: Magnus Westerlund (KI/EAB) > Subject: [MSEC] FW: Submission of draft-lehtovirta-srtp-rcc-01.txt >=20 > Dear all, >=20 > Forwarding on behalf of Karl. >=20 > -----Original Message----- > From: Karl Norrman (KI/EAB) > Sent: 13. helmikuuta 2006 18:04 > To: internet-drafts@ietf.org > Cc: Vesa Lehtovirta (JO/LMF); Mats N=E4slund (KI/EAB) > Subject: Submission of draft-lehtovirta-srtp-rcc-01.txt >=20 > Dear Editor, >=20 > Please submit the new version of draft-lehtovirta-srtp-rcc-01.txt. >=20 > Best Regards, > Karl Norrman > Ericsson >=20 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Mar 03 19:43:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFK7o-0005dI-Go for msec-archive@lists.ietf.org; Fri, 03 Mar 2006 18:55:57 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFK7m-00055E-5L for msec-archive@lists.ietf.org; Fri, 03 Mar 2006 18:55:56 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id A726E2BDDF; Fri, 3 Mar 2006 18:55:53 -0500 (EST) 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 A6D782BA5E for ; Fri, 3 Mar 2006 18:55:52 -0500 (EST) Received: (qmail 76374 invoked by uid 3269); 3 Mar 2006 23:55:52 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 76371 invoked from network); 3 Mar 2006 23:55:52 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 3 Mar 2006 23:55:52 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 3DAEF6837D for ; Fri, 3 Mar 2006 18:55:52 -0500 (EST) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k23NtiMs029401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 3 Mar 2006 15:55:45 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-167.qualcomm.com [10.50.76.167]) by crowley.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k23NsSSw002543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Mar 2006 15:55:37 -0800 (PST) Message-Id: <6.2.5.6.2.20060303154246.054a2610@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 03 Mar 2006 15:54:27 -0800 To: "Fries, Steffen" , "Vesa Lehtovirta (JO/LMF)" , , From: Lakshminath Dondeti Subject: RE: [MSEC] FW: Submission of draft-lehtovirta-srtp-rcc-01.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "Jerichow, Anja" , "Rauschenbach, Uwe" 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: a87a9cdae4ac5d3fbeee75cd0026d632 Hi Steffen, Just some thoughts on this as WG contributor: RCC would be signalled as a new MAC algorithm=20 anyway and that would imply that receivers that=20 don't understand the new MAC construction would=20 need to decide against joining the secure=20 group. Furthermore, if I recall the semantics=20 correctly, the received ROC and not the stored=20 ROC would be used in the MAC verification process. For those reasons, I don't think the proposed=20 construction is a problem. Your proposal is also=20 ok. I guess one way to look at it is if R is=20 sufficiently high (i.e., RCC packets are=20 infrequent), receivers that don't support the new=20 extension can also listen in as long as the key=20 management semantics are revised to allow that. That said, once again if memory serves me the=20 reason for the current design of RCC is to have=20 the MAC at the end. The EKT work adds new payloads at the end, however. In conclusion, I think if the RCC extension is to=20 support what you propose, we may need to specify=20 the RCC extension to keep the MAC algorithm the=20 same and signal the extension differently. regards, Lakshminath At 07:28 AM 3/3/2006, Fries, Steffen wrote: > Hi Vesa, > >I just read your draft regarding the SRTP/MIKEY=20 >extension. It is a good enhancement to transmit=20 >the ROC in parts pof the SRTP payload. >Nevertheless, I have a comment/question to the=20 >transform described in section 2. It is stated=20 >that TAG =3D ROC_sender || MAC. What is the reason=20 >that the TAG is constructed in that way, rather than TAG =3D MAC ||= ROC_sender? > > >From my point of view there is an advantage=20 > for the latter case. This approach would=20 > provide a better backward compatibility for=20 > terminals which are not aware of the SRTP=20 > extension you are describing. If they get the=20 > ROC information by other means (e.g., seperate=20 > messages) there still would be able to handle=20 > the MAC verification correctly, as the MAC=20 > starts at the same position as described in=20 > RFC3711. When inserting the ROC before the MAC=20 > in the packet, older terminaly would take a=20 > part of the ROC as MAC, which would lead to errors in the MAC= verification. > >Would it influence the security in any way by=20 >choosing the TAG =3D MAC || ROC_sender? > >Regards > Steffen > > > > > > -----Original Message----- > > From: msec-bounces@securemulticast.org > > [mailto:msec-bounces@securemulticast.org] On Behalf Of Vesa > > Lehtovirta (JO/LMF) > > Sent: Tuesday, February 14, 2006 3:31 PM > > To: msec@securemulticast.org; avt@ietf.org > > Cc: Magnus Westerlund (KI/EAB) > > Subject: [MSEC] FW: Submission of draft-lehtovirta-srtp-rcc-01.txt > > > > Dear all, > > > > Forwarding on behalf of Karl. > > > > -----Original Message----- > > From: Karl Norrman (KI/EAB) > > Sent: 13. helmikuuta 2006 18:04 > > To: internet-drafts@ietf.org > > Cc: Vesa Lehtovirta (JO/LMF); Mats N=E4slund (KI/EAB) > > Subject: Submission of draft-lehtovirta-srtp-rcc-01.txt > > > > Dear Editor, > > > > Please submit the new version of draft-lehtovirta-srtp-rcc-01.txt. > > > > Best Regards, > > Karl Norrman > > Ericsson > > >_______________________________________________ >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 Fri Mar 03 21:08:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFMBt-0005TF-0h for msec-archive@lists.ietf.org; Fri, 03 Mar 2006 21:08:17 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFMBq-0005UK-Bs for msec-archive@lists.ietf.org; Fri, 03 Mar 2006 21:08:17 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 01CAE2C189; Fri, 3 Mar 2006 21:08:14 -0500 (EST) 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 77D8E2BF45 for ; Fri, 3 Mar 2006 21:08:12 -0500 (EST) Received: (qmail 18702 invoked by uid 3269); 4 Mar 2006 02:08:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 18699 invoked from network); 4 Mar 2006 02:08:12 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 4 Mar 2006 02:08:12 -0000 Received: from milpmailbhs.milpitas.polycom.com (milpmailbhs.milpitas.polycom.com [140.242.16.3]) by klesh.pair.com (Postfix) with ESMTP id 244B06838B for ; Fri, 3 Mar 2006 21:08:12 -0500 (EST) Received: from vanmail01.vancouver.polycom.com ([172.16.1.119]) by milpmailbhs.milpitas.polycom.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 18:08:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MSEC] Comments to draft draft-ietf-msec-mikey-rsa-r-02.txt Date: Fri, 3 Mar 2006 18:08:11 -0800 Message-ID: <4280DB4085C0FC4BAA41AB503C1024D0DE69C6@vanmail01.vancouver.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] Comments to draft draft-ietf-msec-mikey-rsa-r-02.txt Thread-Index: AcY+pfl2Wy96MgoXQRi4hsgntR2IRQAh07D/ References: <6.2.5.6.2.20060303005208.055e50a0@qualcomm.com> From: "Ignjatic, Dragan" To: "Lakshminath Dondeti" , "Vesa Lehtovirta (JO/LMF)" , X-OriginalArrivalTime: 04 Mar 2006 02:08:11.0384 (UTC) FILETIME=[7CF1CF80:01C63F30] Cc: ld@qualcomm.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: , Content-Type: multipart/mixed; boundary="===============1793639252==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 14278aea5bdd1edf35ec09ffb7b61f9d This is a multi-part message in MIME format. --===============1793639252== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63F30.7CC91949" This is a multi-part message in MIME format. ------_=_NextPart_001_01C63F30.7CC91949 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Vesa, Many thanks for the review. I tried to clarify some of Lakshminath's = points. =20 Best regards, Dragan ________________________________ From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] Sent: Fri 3/3/2006 1:36 AM To: Vesa Lehtovirta (JO/LMF); Ignjatic, Dragan; msec@securemulticast.org Cc: ld@qualcomm.com Subject: Re: [MSEC] Comments to draft draft-ietf-msec-mikey-rsa-r-02.txt Hi Vesa, Many thanks for your comments. I apologize for the delay in my response. Dragan and I were I guess hoping the other would respond and he noted he will be commenting tomorrow. I will try to address your comments below: At 01:25 AM 2/24/2006, Vesa Lehtovirta \(JO/LMF\) wrote: >Hi all, > >Here are some comments, and also questions, to the >draft-ietf-msec-mikey-rsa-r-02.txt. > >In general the draft is well written and an interesting approach. > >Best regards, > > Vesa > >- Issue: Abstract says that >"The Multimedia Internet Keying (MIKEY) specification describes >several modes of key distribution to setup Secure Real-time Rransport >Protocol (SRTP) sessions..." > >Comment: The draft generally gives the impression that MIKEY is used >solely for setting up keys for SRTP. However, MIKEY is not >restricted to SRTP only, although certain parameters have been >specified already for SRTP in MIKEY RFC3830. MIKEY is extensible to >be used with other security protocols also but this may require that >needed parameters can be specified also for other security >protocols. Therefore, it would be good to mention SRTP as one >possible security protocol and not the only possible one. Or is it >the intention that this would be used only with SRTP? I appreciate the distinction you are making. We'll address this by rewording that paragraph. >- Issue: One of the main points in the draft is that the Initiator >may not know the Responder's ID and in 3.2 it is said for the = I_MESSAGE: > >"If the Responder has multiple Identities, the Initiator MAY also >include the specific ID, IDr, of the Responder that it wants to >communicate with." > >Comment: The question is, if the IDr is not indicated in the >I_MESSAGE, how can the message be routed to the correct responder? >If this is assumed to be done in some other layer, e.g. SIP, how can >the initiator know the SIP layer identity if it does not know the >MIKEY layer identity? Or is it assumed then that e.g. the SIP layer >identity may be known even though the MIKEY layer identity is not = known? Yes. But, I guess that MAY can be clarified further. If the Initiator knows the specific Responder's ID it wants to communicate with and specifies it, what happens if due to forking or redirect or something it goes to a different place. W.r.t. routing the message though, my understanding is that's all SIP level and not up to MIKEY. We can only specify how MIKEY messages are to be processed if and when they go to an unintended entity. >- Issue: In 3.2 it is said that "The Initiator MAY indicate the >number of CSs supported,.." but in 3.2 it is said that "The >Responder MUST fill in the number of CSs" >Comment: Why is it differently? Should both be MUST? I think this is ok. If the Responder is a sending to a group (or a group key server), then the Initiator does not need to fill in the CS information. In either case, it is ok to have the Responder fill in the information. Are you suggesting that for the unicast case, the MAY ought to be a = SHOULD? [D.I.]: This depends on whether we want to allow multiple different = (unicast/multicast) streams to use the same keying material.=20 >- Issue: In 5 (last para) it is said that "Unicast and multicast >keys have different >security properties and should not be derived from the same pool." Ok, that's vague. We'll clarify further. [D.I.]: We will clarify in the draft. This only means that the same = keying material should not be used for both multicast and unicast = streams as it may introduce two time pad problems with multiple unicast = sources that pick their own SSRC's. >Comment: Usually we can trust to one-way key derivation functions to >provide key separation. Is there a reason why we cannot assume it here? > >- Issue: In 5 (last para) it is said that >"The authors believe that multiple TGK payloads can be used for this >purpose but the exact method is not specified in MIKEY." Right, we talked a lot about this and we thought it is under specified or something, but decided that it is out of scope for RSA-R. But that statement might best be removed or further clarified. [D.I.]: I believe what is lacking is a good mapping mechanism between = TGKs and sessions and again decided RSA-R is not the way to introduce = it. >Comment: When checking this seems to be specified in 6.2 and 6.13 of >RFC 3830. > >- Smaller stuff: In 3.3 (page 7): What is "complete CS map"? Is it >"CS ID map info"? We'll rewrite that. Thanks for catching this. >- Smaller stuff: In 3.4.1, 3.4.2 and 3.4.3 it could be indicated >what is new information. Will do. >- Finally some comments on some "extra" messages on the proposed >procedure: The current draft proposes a solution where the Initiator >prompts the Responder to send the TGK key. I wonder if the procedure >could be extended with a Verification message to know that the key >has been delivered (as in current MIKEY): > >Init Resp >----- ---- >I_MSG[CERTi] --> > <-- R_MSG(TGK)[CERTr] >I_MSG[Verif] --> > >Also, the current draft does not allow the Initiator to choose the >TGK. I wonder if the procedure could be also extended with a new >message in the beginning of the procedure where the Init could ask >the Resp to request the key from Init. I guess you have thought of >this since this case has been shortly discussed in 4.1 but then you >have abandobed it as too complex?: "For instance, A might ask C to >contact B or itself to get the TGK, in effect initiating a 3-way = exchange. " > >Init Resp >----- ---- >I_MSG[CERTi] --> > <-- R_MSG[CERTr] >I_MSG(TGK) --> > That would be a 3-way exchange and my take is no. :-). Thanks Vesa for a very thoughtful and thorough review. We'll address your comments in the next rev. [D.I.]: Right, even if the three way handshake can be justified I don't = think RSA-R work should introduce it. best regards, Lakshminath ------_=_NextPart_001_01C63F30.7CC91949 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [MSEC] Comments to draft = draft-ietf-msec-mikey-rsa-r-02.txt=0A= =0A= =0A=
=0A=
Hi = Vesa,
=0A=
Many thanks for the review. = I tried to =0A= clarify some of Lakshminath's points.
=0A=
 
=0A=
Best regards,
=0A=
Dragan
=0A=

=0A=
=0A= From: Lakshminath Dondeti =0A= [mailto:ldondeti@qualcomm.com]
Sent: Fri 3/3/2006 1:36 =0A= AM
To: Vesa Lehtovirta (JO/LMF); Ignjatic, Dragan; =0A= msec@securemulticast.org
Cc: = ld@qualcomm.com
Subject: Re: =0A= [MSEC] Comments to draft = draft-ietf-msec-mikey-rsa-r-02.txt

=0A=
=0A=

Hi Vesa,

Many thanks for your comments.  I = apologize =0A= for the delay in my
response.  Dragan and I were I guess hoping = the =0A= other would respond
and he noted he will be commenting = tomorrow.

I =0A= will try to address your comments below:

At 01:25 AM 2/24/2006, = Vesa =0A= Lehtovirta \(JO/LMF\) wrote:

>Hi all,
>
>Here are = some =0A= comments, and also questions, to =0A= the
>draft-ietf-msec-mikey-rsa-r-02.txt.
>
>In general = the =0A= draft is well written and an interesting approach.
>
>Best =0A= regards,
>
>    Vesa
>
>- Issue: = Abstract =0A= says that
>"The Multimedia Internet Keying (MIKEY) specification =0A= describes
>several modes of key distribution to setup Secure = Real-time =0A= Rransport
>Protocol (SRTP) sessions..."
>
>Comment: = The draft =0A= generally gives the impression that MIKEY is used
>solely for = setting up =0A= keys for SRTP. However, MIKEY is not
>restricted to SRTP only, = although =0A= certain parameters have been
>specified already for SRTP in MIKEY = RFC3830. =0A= MIKEY is extensible to
>be used with other security protocols also = but =0A= this may require that
>needed parameters can be specified also for = other =0A= security
>protocols. Therefore, it would be good to mention SRTP = as =0A= one
>possible security protocol and not the only possible one. Or = is =0A= it
>the intention that this would be used only with SRTP?

I =0A= appreciate the distinction you are making.  We'll address this =0A= by
rewording that paragraph.


>- Issue: One of the main = points =0A= in the draft is that the Initiator
>may not know the Responder's = ID and in =0A= 3.2 it is said for the I_MESSAGE:
>
>"If the Responder has = multiple =0A= Identities, the Initiator MAY also
>include the specific ID, IDr, = of the =0A= Responder that it wants to
>communicate = with."
>
>Comment: The =0A= question is, if the IDr is not indicated in the
>I_MESSAGE, how = can the =0A= message be routed to the correct responder?
>If this is assumed to = be done =0A= in some other layer, e.g. SIP, how can
>the initiator know the SIP = layer =0A= identity if it does not know the
>MIKEY layer identity? Or is it = assumed =0A= then that e.g. the SIP layer
>identity may be known even though = the MIKEY =0A= layer identity is not known?

Yes.  But, I guess that MAY can = be =0A= clarified further.  If the
Initiator knows the specific = Responder's ID =0A= it wants to communicate
with and specifies it, what happens if due to = forking =0A= or redirect or
something it goes to a different place.

W.r.t. = routing =0A= the message though, my understanding is that's all SIP
level and not = up to =0A= MIKEY.  We can only specify how MIKEY messages
are to be = processed if =0A= and when they go to an unintended entity.


>- Issue: In 3.2 = it is =0A= said that "The Initiator MAY indicate the
>number of CSs = supported,.." but =0A= in 3.2 it is said that "The
>Responder MUST fill in the number of =0A= CSs"
>Comment: Why is it differently? Should both be = MUST?

I think =0A= this is ok.  If the Responder is a sending to a group (or = a
group key =0A= server), then the Initiator does not need to fill in the =0A= CS
information.  In either case, it is ok to have the Responder = fill =0A= in
the information.

Are you suggesting that for the unicast = case, the =0A= MAY ought to be a SHOULD?

=0A=

[D.I.]: This depends on whether = we want to =0A= allow multiple different (unicast/multicast) streams to use the same = keying =0A= material.

=0A=

>- Issue: In 5 (last para) it is said that "Unicast and =0A= multicast
>keys have different
>security properties and = should not =0A= be derived from the same pool."

Ok, that's vague.  We'll = clarify =0A= further.

=0A=

[D.I.]: We will clarify in the draft. This only means that the same = keying =0A= material should not be used for both multicast and unicast streams as it = may =0A= introduce two time pad problems with multiple unicast sources that pick = their =0A= own SSRC's.

>Comment: Usually we can trust to one-way key = derivation =0A= functions to
>provide key separation. Is there a reason why we = cannot =0A= assume it here?
>
>- Issue: In 5 (last para) it is said =0A= that
>"The authors believe that multiple TGK payloads can be used = for =0A= this
>purpose but the exact method is not specified in =0A= MIKEY."

Right, we talked a lot about this and we thought it is =0A= under
specified or something, but decided that it is out of scope =0A= for
RSA-R.  But that statement might best be removed or further =0A= clarified.

=0A=

[D.I.]: I believe what is lacking is a good mapping =0A= mechanism between TGKs and sessions and again decided RSA-R is = not the =0A= way to introduce it.

>Comment: When checking this seems to be =0A= specified in 6.2 and 6.13 of
>RFC 3830.
>
>- Smaller = stuff: In =0A= 3.3 (page 7): What is "complete CS map"? Is it
>"CS ID map =0A= info"?

We'll rewrite that.  Thanks for catching =0A= this.


>- Smaller stuff: In 3.4.1, 3.4.2 and 3.4.3 it could = be =0A= indicated
>what is new information.

Will = do.


>- =0A= Finally some comments on some "extra" messages on the = proposed
>procedure: =0A= The current draft proposes a solution where the Initiator
>prompts = the =0A= Responder to send the TGK key. I wonder if the procedure
>could be =0A= extended with a Verification message to know that the key
>has = been =0A= delivered (as in current =0A= MIKEY):
>
>Init       &nbs= p;     =0A= Resp
>-----         &n= bsp;  =0A= ----
>I_MSG[CERTi]  =0A= -->
>        <-- =0A= R_MSG(TGK)[CERTr]
>I_MSG[Verif] -->
>
>Also, the = current =0A= draft does not allow the Initiator to choose the
>TGK. I wonder if = the =0A= procedure could be also extended with a new
>message in the = beginning of =0A= the procedure where the Init could ask
>the Resp to request the = key from =0A= Init. I guess you have thought of
>this since this case has been = shortly =0A= discussed in 4.1 but then you
>have abandobed it as too complex?: = "For =0A= instance, A might ask C to
>contact B or itself to get the TGK, in = effect =0A= initiating a 3-way exchange. =0A= "
>
>Init        &nbs= p;    =0A= Resp
>-----         &n= bsp;  =0A= ----
>I_MSG[CERTi] =0A= -->
>        <-- =0A= R_MSG[CERTr]
>I_MSG(TGK) -->
>
That would be a 3-way = exchange =0A= and my take is no.  :-).

Thanks Vesa for a very thoughtful = and =0A= thorough review.  We'll address
your comments in the next = rev.

=0A=

[D.I.]: Right, even if the three way handshake can be = justified I =0A= don't think RSA-R work should introduce it.

best =0A= regards,
Lakshminath

=0A= =0A= =0A= ------_=_NextPart_001_01C63F30.7CC91949-- --===============1793639252== 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 --===============1793639252==-- From msec-bounces@securemulticast.org Sun Mar 05 20:19:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG4Nr-0008UB-2Y for msec-archive@lists.ietf.org; Sun, 05 Mar 2006 20:19:35 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FG4Np-0001Hn-RX for msec-archive@lists.ietf.org; Sun, 05 Mar 2006 20:19:35 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 66A512C71B; Sun, 5 Mar 2006 20:19:33 -0500 (EST) 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 473C02C1C3 for ; Sun, 5 Mar 2006 20:19:31 -0500 (EST) Received: (qmail 19873 invoked by uid 3269); 6 Mar 2006 01:19:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 19870 invoked from network); 6 Mar 2006 01:19:31 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 6 Mar 2006 01:19:31 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id CB7E768377 for ; Sun, 5 Mar 2006 20:19:30 -0500 (EST) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k261JSFT019243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 5 Mar 2006 17:19:28 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-14.qualcomm.com [10.50.76.14]) by neophyte.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k261JE7P017446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 5 Mar 2006 17:19:23 -0800 (PST) Message-Id: <6.2.5.6.2.20060305171539.052502a8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 05 Mar 2006 17:19:10 +0900 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: canetti , Russ Housley Subject: [MSEC] SHA-1 analyses of MSEC 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: 856eb5f76e7a34990d1d457d8e8e5b7f Hi all, Soon after the Vancouver meeting, we have had a pretty active discussion (a combination of MSEC list discussions and some off-line ones) on Russ' action to all SEC area WGs to analyze hash function agility. I was wondering if people can provide a summary of what they have done. I guess I can collect some of these from various emails and draft updates, but if you are so kind to write a quick note to the list, it will save me some time :-). I appreciate it very much. thanks and regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Sun Mar 05 21:57:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG5ut-0005nn-Sx for msec-archive@lists.ietf.org; Sun, 05 Mar 2006 21:57:47 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FG5ur-0003uS-JJ for msec-archive@lists.ietf.org; Sun, 05 Mar 2006 21:57:47 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 45B3C2C714; Sun, 5 Mar 2006 21:57:45 -0500 (EST) 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 9AEAA2C089 for ; Sun, 5 Mar 2006 21:57:44 -0500 (EST) Received: (qmail 44305 invoked by uid 3269); 6 Mar 2006 02:57:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 44302 invoked from network); 6 Mar 2006 02:57:44 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 6 Mar 2006 02:57:44 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id A241B68377 for ; Sun, 5 Mar 2006 21:57:43 -0500 (EST) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k262vcMs028146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 5 Mar 2006 18:57:39 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-14.qualcomm.com [10.50.76.14]) by crowley.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k262vZZ5007319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 5 Mar 2006 18:57:37 -0800 (PST) Message-Id: <6.2.5.6.2.20060305184409.03ae8bd8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 05 Mar 2006 18:57:33 +0900 To: Cullen Jennings , , From: Lakshminath Dondeti Subject: Re: [AVT] RE: [MSEC] FW: Submission of draft-lehtovirta-srtp-rcc-01.txt In-Reply-To: References: <6.2.5.6.2.20060303154246.054a2610@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: David A McGrew 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: 8b431ad66d60be2d47c7bfeb879db82c Hi Cullen, MKI use in different ways is a known problem that folks in OMA BCAST have been working to resolve for a few months now. 3GPP MBMS MKI field is defined as (MSK ID || MTK ID). MSK = MBMS Service key (long term key) and MTK = MBMS Traffic key (short term key) In 3GPP2 BCMCS, MKI field was/is defined as (4-bit Reserved||4-bit BAK_ID||32-bit ROC||32-bit SK_RAND). BAK is the long term key and SK_RAND is used to compute the short term key. I have worked with my colleagues in 3GPP2 recently to have that changed to (4-bit Reserved||4-bit BAK_ID||32-bit SK_RAND), and send the ROC as part of the auth_tag as defined in the RCC I-D. My recollection is DVB sends TEK ID in the MKI (not sure about that, so please cross-check). As you note this leads to interop problems, for instance, a broadcaster (OMA context) will have to prepare multiple SRTP streams for multiple broadcast distribution systems (e.g., BCMCS, MBMS, etc.,) and people are now trying to resolve that. I will have an update on this later this week (we are meeting in Seoul in part to resolve some of this), if you care. All of this is in the context of broadcast though. Is that what you have in mind? Or, are you looking for information on unicast SRTP usage? regards, Lakshminath At 04:16 AM 3/6/2006, Cullen Jennings wrote: >You mention how 3GPP is using the MKI. Could you provide any more details or >references on this? Do you foresee interop problems if an 3GPP device was >talking to a devices that was using MKI more the way that SRTP specified it? > > >>> > >>> Please submit the new version of draft-lehtovirta-srtp-rcc-01.txt. > >>> > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Mar 06 04:43:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGCFm-00023x-I5 for msec-archive@lists.ietf.org; Mon, 06 Mar 2006 04:43:46 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGCFk-0000gb-5S for msec-archive@lists.ietf.org; Mon, 06 Mar 2006 04:43:46 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id A7C922B9C9; Mon, 6 Mar 2006 04:43:43 -0500 (EST) 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 E0D5F2C774 for ; Mon, 6 Mar 2006 04:43:41 -0500 (EST) Received: (qmail 58008 invoked by uid 3269); 6 Mar 2006 09:43:41 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 58005 invoked from network); 6 Mar 2006 09:43:41 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 6 Mar 2006 09:43:41 -0000 Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) by klesh.pair.com (Postfix) with ESMTP id 4DBD368377 for ; Mon, 6 Mar 2006 04:43:41 -0500 (EST) Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k269hN1n009865; Mon, 6 Mar 2006 10:43:23 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k269hLEG003506; Mon, 6 Mar 2006 10:43:22 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 10:43:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] FW: Submission of draft-lehtovirta-srtp-rcc-01.txt Date: Mon, 6 Mar 2006 10:43:20 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] FW: Submission of draft-lehtovirta-srtp-rcc-01.txt thread-index: AcY/HgOPEnrlfmfZSuig5BazaX/pNgB0ZJUQ From: "Fries, Steffen" To: "Lakshminath Dondeti" , "Vesa Lehtovirta (JO/LMF)" , , X-OriginalArrivalTime: 06 Mar 2006 09:43:21.0472 (UTC) FILETIME=[67DA0800:01C64102] Cc: "Jerichow, Anja" , "Rauschenbach, Uwe" 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: 36b1f8810cb91289d885dc8ab4fc8172 Hi Lakshminath, the reason for asking that question is the following scenario. (It stems = from discusssions regarding OMA and DVB). If you have a device, that = currently supports SRTP and gets the session parameter by other means = (other than MIKEY od sedescriptions) you may break backward = compatibility with those devices while changing the MAC position.=20 If one can ensure that the device gets the right ROC (the righ one is = the one, which would be submitted in the RCC packet) by other means, and = the device does not now about the new integrity transform (because it is = a parameter which is fixed), then the device could verify the MAC even = so it is not aware of a new integrity transform. As far as I understood = the scenario it would keep current DVB devices working. On the other hand, this approach would assume that all "legacy" = terminals use the same algorithm to find the MAC in the message. In the = scenario described above, it would make a difference if one starts from = the beginning or the end of a packet to search for the MAC. But as you = said, the same problem would arise for the legacy terminals when using = EKT, as it adds after the MAC. Hm, it seams that backward compatibility is getting tough ... maybe it = is worth to ask SRTP implementers, what the most used algorithm for = finding the MAC is.=20 Regards Steffen > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20 > Sent: Saturday, March 04, 2006 12:54 AM > To: Fries, Steffen; Vesa Lehtovirta (JO/LMF);=20 > msec@securemulticast.org; avt@ietf.org > Cc: Jerichow, Anja; Rauschenbach, Uwe > Subject: RE: [MSEC] FW: Submission of draft-lehtovirta-srtp-rcc-01.txt >=20 > Hi Steffen, >=20 > Just some thoughts on this as WG contributor: >=20 > RCC would be signalled as a new MAC algorithm anyway and that=20 > would imply that receivers that don't understand the new MAC=20 > construction would need to decide against joining the secure=20 > group. Furthermore, if I recall the semantics correctly, the=20 > received ROC and not the stored ROC would be used in the MAC=20 > verification process. >=20 > For those reasons, I don't think the proposed construction is=20 > a problem. Your proposal is also ok. I guess one way to=20 > look at it is if R is sufficiently high (i.e., RCC packets=20 > are infrequent), receivers that don't support the new=20 > extension can also listen in as long as the key management=20 > semantics are revised to allow that. >=20 > That said, once again if memory serves me the reason for the=20 > current design of RCC is to have the MAC at the end. The EKT=20 > work adds new payloads at the end, however. >=20 > In conclusion, I think if the RCC extension is to support=20 > what you propose, we may need to specify the RCC extension to=20 > keep the MAC algorithm the same and signal the extension differently. >=20 > regards, > Lakshminath >=20 > At 07:28 AM 3/3/2006, Fries, Steffen wrote: > > Hi Vesa, > > > >I just read your draft regarding the SRTP/MIKEY extension.=20 > It is a good=20 > >enhancement to transmit the ROC in parts pof the SRTP payload. > >Nevertheless, I have a comment/question to the transform=20 > described in=20 > >section 2. It is stated that TAG =3D ROC_sender || MAC. What is the=20 > >reason that the TAG is constructed in that way, rather than=20 > TAG =3D MAC=20 > >|| ROC_sender? > > > > >From my point of view there is an advantage > > for the latter case. This approach would provide a better backward=20 > > compatibility for terminals which are not aware of the SRTP=20 > extension=20 > > you are describing. If they get the ROC information by other means=20 > > (e.g., seperate > > messages) there still would be able to handle the MAC verification=20 > > correctly, as the MAC starts at the same position as described in=20 > > RFC3711. When inserting the ROC before the MAC in the packet, older=20 > > terminaly would take a part of the ROC as MAC, which would lead to=20 > > errors in the MAC verification. > > > >Would it influence the security in any way by choosing the=20 > TAG =3D MAC ||=20 > >ROC_sender? > > > >Regards > > Steffen > > > > > > > > > > > -----Original Message----- > > > From: msec-bounces@securemulticast.org=20 > > > [mailto:msec-bounces@securemulticast.org] On Behalf Of Vesa=20 > > > Lehtovirta (JO/LMF) > > > Sent: Tuesday, February 14, 2006 3:31 PM > > > To: msec@securemulticast.org; avt@ietf.org > > > Cc: Magnus Westerlund (KI/EAB) > > > Subject: [MSEC] FW: Submission of draft-lehtovirta-srtp-rcc-01.txt > > > > > > Dear all, > > > > > > Forwarding on behalf of Karl. > > > > > > -----Original Message----- > > > From: Karl Norrman (KI/EAB) > > > Sent: 13. helmikuuta 2006 18:04 > > > To: internet-drafts@ietf.org > > > Cc: Vesa Lehtovirta (JO/LMF); Mats N=E4slund (KI/EAB) > > > Subject: Submission of draft-lehtovirta-srtp-rcc-01.txt > > > > > > Dear Editor, > > > > > > Please submit the new version of draft-lehtovirta-srtp-rcc-01.txt. > > > > > > Best Regards, > > > Karl Norrman > > > Ericsson > > > > >_______________________________________________ > >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 Mon Mar 06 09:46:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGGyO-0000up-A3 for msec-archive@lists.ietf.org; Mon, 06 Mar 2006 09:46:08 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGGyN-0004iP-Sp for msec-archive@lists.ietf.org; Mon, 06 Mar 2006 09:46:08 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 970C22C78E; Mon, 6 Mar 2006 09:46:07 -0500 (EST) 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 9407C2C796 for ; Mon, 6 Mar 2006 09:46:06 -0500 (EST) Received: (qmail 10501 invoked by uid 3269); 6 Mar 2006 14:46:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10492 invoked from network); 6 Mar 2006 14:46:06 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 6 Mar 2006 14:46:06 -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 9FACC683A2 for ; Mon, 6 Mar 2006 09:46:05 -0500 (EST) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 06 Mar 2006 06:46:04 -0800 X-IronPort-AV: i="4.02,168,1139212800"; d="scan'208"; a="259766028:sNHT1778250308" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k26Ek37T020156; Mon, 6 Mar 2006 06:46:03 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Mar 2006 06:46:02 -0800 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Mar 2006 06:46:01 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <7D7EEAA5-CB70-4B3F-A810-FEAEFFC7C50B@cisco.com> Content-Transfer-Encoding: quoted-printable From: David McGrew Subject: Re: [MSEC] FW: Submission of draft-lehtovirta-srtp-rcc-01.txt Date: Mon, 6 Mar 2006 06:45:58 -0800 To: "Fries, Steffen" X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 06 Mar 2006 14:46:01.0933 (UTC) FILETIME=[B05477D0:01C6412C] Cc: avt@ietf.org, "Rauschenbach, Uwe" , "Vesa Lehtovirta (JO/LMF)" , "Jerichow, Anja" , 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: 0e9ebc0cbd700a87c0637ad0e2c91610 Hi Steffen, On Mar 6, 2006, at 1:43 AM, Fries, Steffen wrote: > Hi Lakshminath, > > the reason for asking that question is the following scenario. (It =20 > stems from discusssions regarding OMA and DVB). If you have a =20 > device, that currently supports SRTP and gets the session parameter =20= > by other means (other than MIKEY od sedescriptions) you may break =20 > backward compatibility with those devices while changing the MAC =20 > position. > > If one can ensure that the device gets the right ROC (the righ one =20 > is the one, which would be submitted in the RCC packet) by other =20 > means, and the device does not now about the new integrity =20 > transform (because it is a parameter which is fixed), then the =20 > device could verify the MAC even so it is not aware of a new =20 > integrity transform. As far as I understood the scenario it would =20 > keep current DVB devices working. > > On the other hand, this approach would assume that all "legacy" =20 > terminals use the same algorithm to find the MAC in the message. In =20= > the scenario described above, it would make a difference if one =20 > starts from the beginning or the end of a packet to search for the =20 > MAC. But as you said, the same problem would arise for the legacy =20 > terminals when using EKT, as it adds after the MAC. > > Hm, it seams that backward compatibility is getting tough ... maybe =20= > it is worth to ask SRTP implementers, what the most used algorithm =20 > for finding the MAC is. I suspect that they do it like this: auth_tag =3D (uint8_t *)hdr + *pkt_octet_len - tag_len; where auth_tag is the initial octet of the tag, hdr is a pointer to =20 the start of the RTP header, *pkt_octet_len is the length of the RTP =20 packet in bytes, and tag_len is the expected tag length for that =20 packet (which is predictable because the particular MAC that is being =20= used is determined by the SSRC and the session particulars). I'm a bit confused on how RCC could ever achieve backwards =20 compatibility, though. A "legacy" SRTP implementation would need to =20 know how to correctly verify the MAC and would need to know to =20 discard the ROC value rather than to pass it to the RTP layer. =20 Alternately, the RTP layer could discard the ROC value, but legacy =20 RTP implementations won't do this. Also, there is the major issue =20 that in RCC only selected packets will be authenticated; I don't see =20 any way to make that work. David > > Regards > Steffen > >> -----Original Message----- >> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] >> Sent: Saturday, March 04, 2006 12:54 AM >> To: Fries, Steffen; Vesa Lehtovirta (JO/LMF); >> msec@securemulticast.org; avt@ietf.org >> Cc: Jerichow, Anja; Rauschenbach, Uwe >> Subject: RE: [MSEC] FW: Submission of draft-lehtovirta-srtp-=20 >> rcc-01.txt >> >> Hi Steffen, >> >> Just some thoughts on this as WG contributor: >> >> RCC would be signalled as a new MAC algorithm anyway and that >> would imply that receivers that don't understand the new MAC >> construction would need to decide against joining the secure >> group. Furthermore, if I recall the semantics correctly, the >> received ROC and not the stored ROC would be used in the MAC >> verification process. >> >> For those reasons, I don't think the proposed construction is >> a problem. Your proposal is also ok. I guess one way to >> look at it is if R is sufficiently high (i.e., RCC packets >> are infrequent), receivers that don't support the new >> extension can also listen in as long as the key management >> semantics are revised to allow that. >> >> That said, once again if memory serves me the reason for the >> current design of RCC is to have the MAC at the end. The EKT >> work adds new payloads at the end, however. >> >> In conclusion, I think if the RCC extension is to support >> what you propose, we may need to specify the RCC extension to >> keep the MAC algorithm the same and signal the extension differently. >> >> regards, >> Lakshminath >> >> At 07:28 AM 3/3/2006, Fries, Steffen wrote: >>> Hi Vesa, >>> >>> I just read your draft regarding the SRTP/MIKEY extension. >> It is a good >>> enhancement to transmit the ROC in parts pof the SRTP payload. >>> Nevertheless, I have a comment/question to the transform >> described in >>> section 2. It is stated that TAG =3D ROC_sender || MAC. What is the >>> reason that the TAG is constructed in that way, rather than >> TAG =3D MAC >>> || ROC_sender? >>> >>>> =46rom my point of view there is an advantage >>> for the latter case. This approach would provide a better backward >>> compatibility for terminals which are not aware of the SRTP >> extension >>> you are describing. If they get the ROC information by other means >>> (e.g., seperate >>> messages) there still would be able to handle the MAC verification >>> correctly, as the MAC starts at the same position as described in >>> RFC3711. When inserting the ROC before the MAC in the packet, older >>> terminaly would take a part of the ROC as MAC, which would lead to >>> errors in the MAC verification. >>> >>> Would it influence the security in any way by choosing the >> TAG =3D MAC || >>> ROC_sender? >>> >>> Regards >>> Steffen >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: msec-bounces@securemulticast.org >>>> [mailto:msec-bounces@securemulticast.org] On Behalf Of Vesa >>>> Lehtovirta (JO/LMF) >>>> Sent: Tuesday, February 14, 2006 3:31 PM >>>> To: msec@securemulticast.org; avt@ietf.org >>>> Cc: Magnus Westerlund (KI/EAB) >>>> Subject: [MSEC] FW: Submission of draft-lehtovirta-srtp-rcc-01.txt >>>> >>>> Dear all, >>>> >>>> Forwarding on behalf of Karl. >>>> >>>> -----Original Message----- >>>> From: Karl Norrman (KI/EAB) >>>> Sent: 13. helmikuuta 2006 18:04 >>>> To: internet-drafts@ietf.org >>>> Cc: Vesa Lehtovirta (JO/LMF); Mats N=E4slund (KI/EAB) >>>> Subject: Submission of draft-lehtovirta-srtp-rcc-01.txt >>>> >>>> Dear Editor, >>>> >>>> Please submit the new version of draft-lehtovirta-srtp-rcc-01.txt. >>>> >>>> Best Regards, >>>> Karl Norrman >>>> Ericsson >>>> >>> _______________________________________________ >>> 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 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Mar 06 09:57:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGH9e-000123-Fk for msec-archive@lists.ietf.org; Mon, 06 Mar 2006 09:57:46 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGH9e-0005FF-0q for msec-archive@lists.ietf.org; Mon, 06 Mar 2006 09:57:46 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 422AA2C7D7; Mon, 6 Mar 2006 09:57:41 -0500 (EST) 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 95CD22C7B4 for ; Mon, 6 Mar 2006 09:57:39 -0500 (EST) Received: (qmail 12367 invoked by uid 3269); 6 Mar 2006 14:57:39 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 12364 invoked from network); 6 Mar 2006 14:57:39 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 6 Mar 2006 14:57:39 -0000 Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) by klesh.pair.com (Postfix) with ESMTP id 0E077683A9 for ; Mon, 6 Mar 2006 09:57:38 -0500 (EST) Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k26EvXGc003894; Mon, 6 Mar 2006 15:57:33 +0100 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 k26EvXNb016079; Mon, 6 Mar 2006 15:57:33 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 15:57:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] FW: Submission of draft-lehtovirta-srtp-rcc-01.txt Date: Mon, 6 Mar 2006 15:57:32 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] FW: Submission of draft-lehtovirta-srtp-rcc-01.txt thread-index: AcZBLMu7AJsu7SzsS8Oau/u/Dq1K+gAAC/zg From: "Fries, Steffen" To: "David McGrew" X-OriginalArrivalTime: 06 Mar 2006 14:57:33.0272 (UTC) FILETIME=[4C666D80:01C6412E] Cc: "Jerichow, Anja" , msec@securemulticast.org, avt@ietf.org, "Vesa Lehtovirta (JO/LMF)" , "Rauschenbach, Uwe" 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: 76c7db407a166e4c39f35d8215d8dd32 Hi David, aggreed, backward compatibility would be hard if not impossible. The assumption was (as far as I understood the DVB scenario), that there = is some out of band means to provide the ROC information. The assumption = was further that this ROC would be accepted by SRTP for processing. = According to the draft the MAC calculation itself is the same as in = RFC3711, so this should not pose a problem. The only thing would be the = acceptance of the new ROC. Regards Steffen = =20 > -----Original Message----- > From: msec-bounces@securemulticast.org=20 > [mailto:msec-bounces@securemulticast.org] On Behalf Of David McGrew > Sent: Monday, March 06, 2006 3:46 PM > To: Fries, Steffen > Cc: avt@ietf.org; Rauschenbach, Uwe; Vesa Lehtovirta=20 > (JO/LMF); Jerichow, Anja; msec@securemulticast.org > Subject: Re: [MSEC] FW: Submission of draft-lehtovirta-srtp-rcc-01.txt >=20 > Hi Steffen, >=20 > On Mar 6, 2006, at 1:43 AM, Fries, Steffen wrote: >=20 > > Hi Lakshminath, > > > > the reason for asking that question is the following scenario. (It=20 > > stems from discusssions regarding OMA and DVB). If you have=20 > a device,=20 > > that currently supports SRTP and gets the session parameter=20 > by other=20 > > means (other than MIKEY od sedescriptions) you may break backward=20 > > compatibility with those devices while changing the MAC position. > > > > If one can ensure that the device gets the right ROC (the=20 > righ one is=20 > > the one, which would be submitted in the RCC packet) by=20 > other means,=20 > > and the device does not now about the new integrity=20 > transform (because=20 > > it is a parameter which is fixed), then the device could verify the=20 > > MAC even so it is not aware of a new integrity transform.=20 > As far as I=20 > > understood the scenario it would keep current DVB devices working. > > > > On the other hand, this approach would assume that all "legacy" =20 > > terminals use the same algorithm to find the MAC in the message. In=20 > > the scenario described above, it would make a difference if=20 > one starts=20 > > from the beginning or the end of a packet to search for the=20 > MAC. But=20 > > as you said, the same problem would arise for the legacy terminals=20 > > when using EKT, as it adds after the MAC. > > > > Hm, it seams that backward compatibility is getting tough=20 > ... maybe it=20 > > is worth to ask SRTP implementers, what the most used algorithm for=20 > > finding the MAC is. >=20 > I suspect that they do it like this: >=20 > auth_tag =3D (uint8_t *)hdr + *pkt_octet_len - tag_len; >=20 > where auth_tag is the initial octet of the tag, hdr is a=20 > pointer to the start of the RTP header, *pkt_octet_len is the=20 > length of the RTP packet in bytes, and tag_len is the=20 > expected tag length for that packet (which is predictable=20 > because the particular MAC that is being used is determined=20 > by the SSRC and the session particulars). >=20 > I'm a bit confused on how RCC could ever achieve backwards=20 > compatibility, though. A "legacy" SRTP implementation would=20 > need to know how to correctly verify the MAC and would need=20 > to know to =20 > discard the ROC value rather than to pass it to the RTP layer. =20 > Alternately, the RTP layer could discard the ROC value, but=20 > legacy RTP implementations won't do this. Also, there is the=20 > major issue that in RCC only selected packets will be=20 > authenticated; I don't see any way to make that work. >=20 > David >=20 > > > > Regards > > Steffen > > > >> -----Original Message----- > >> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > >> Sent: Saturday, March 04, 2006 12:54 AM > >> To: Fries, Steffen; Vesa Lehtovirta (JO/LMF);=20 > >> msec@securemulticast.org; avt@ietf.org > >> Cc: Jerichow, Anja; Rauschenbach, Uwe > >> Subject: RE: [MSEC] FW: Submission of draft-lehtovirta-srtp-=20 > >> rcc-01.txt > >> > >> Hi Steffen, > >> > >> Just some thoughts on this as WG contributor: > >> > >> RCC would be signalled as a new MAC algorithm anyway and=20 > that would=20 > >> imply that receivers that don't understand the new MAC=20 > construction=20 > >> would need to decide against joining the secure group. =20 > Furthermore,=20 > >> if I recall the semantics correctly, the received ROC and not the=20 > >> stored ROC would be used in the MAC verification process. > >> > >> For those reasons, I don't think the proposed construction is a=20 > >> problem. Your proposal is also ok. I guess one way to=20 > look at it is=20 > >> if R is sufficiently high (i.e., RCC packets are infrequent),=20 > >> receivers that don't support the new extension can also=20 > listen in as=20 > >> long as the key management semantics are revised to allow that. > >> > >> That said, once again if memory serves me the reason for=20 > the current=20 > >> design of RCC is to have the MAC at the end. The EKT work=20 > adds new=20 > >> payloads at the end, however. > >> > >> In conclusion, I think if the RCC extension is to support what you=20 > >> propose, we may need to specify the RCC extension to keep the MAC=20 > >> algorithm the same and signal the extension differently. > >> > >> regards, > >> Lakshminath > >> > >> At 07:28 AM 3/3/2006, Fries, Steffen wrote: > >>> Hi Vesa, > >>> > >>> I just read your draft regarding the SRTP/MIKEY extension. > >> It is a good > >>> enhancement to transmit the ROC in parts pof the SRTP payload. > >>> Nevertheless, I have a comment/question to the transform > >> described in > >>> section 2. It is stated that TAG =3D ROC_sender || MAC. What is = the=20 > >>> reason that the TAG is constructed in that way, rather than > >> TAG =3D MAC > >>> || ROC_sender? > >>> > >>>> From my point of view there is an advantage > >>> for the latter case. This approach would provide a better=20 > backward=20 > >>> compatibility for terminals which are not aware of the SRTP > >> extension > >>> you are describing. If they get the ROC information by=20 > other means=20 > >>> (e.g., seperate > >>> messages) there still would be able to handle the MAC=20 > verification=20 > >>> correctly, as the MAC starts at the same position as described in=20 > >>> RFC3711. When inserting the ROC before the MAC in the=20 > packet, older=20 > >>> terminaly would take a part of the ROC as MAC, which=20 > would lead to=20 > >>> errors in the MAC verification. > >>> > >>> Would it influence the security in any way by choosing the > >> TAG =3D MAC || > >>> ROC_sender? > >>> > >>> Regards > >>> Steffen > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: msec-bounces@securemulticast.org=20 > >>>> [mailto:msec-bounces@securemulticast.org] On Behalf Of Vesa=20 > >>>> Lehtovirta (JO/LMF) > >>>> Sent: Tuesday, February 14, 2006 3:31 PM > >>>> To: msec@securemulticast.org; avt@ietf.org > >>>> Cc: Magnus Westerlund (KI/EAB) > >>>> Subject: [MSEC] FW: Submission of=20 > draft-lehtovirta-srtp-rcc-01.txt > >>>> > >>>> Dear all, > >>>> > >>>> Forwarding on behalf of Karl. > >>>> > >>>> -----Original Message----- > >>>> From: Karl Norrman (KI/EAB) > >>>> Sent: 13. helmikuuta 2006 18:04 > >>>> To: internet-drafts@ietf.org > >>>> Cc: Vesa Lehtovirta (JO/LMF); Mats N=E4slund (KI/EAB) > >>>> Subject: Submission of draft-lehtovirta-srtp-rcc-01.txt > >>>> > >>>> Dear Editor, > >>>> > >>>> Please submit the new version of=20 > draft-lehtovirta-srtp-rcc-01.txt. > >>>> > >>>> Best Regards, > >>>> Karl Norrman > >>>> Ericsson > >>>> > >>> _______________________________________________ > >>> 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 > _______________________________________________ > 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 Mon Mar 06 12:54:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGJuL-0007H5-OQ for msec-archive@lists.ietf.org; Mon, 06 Mar 2006 12:54:09 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGJuK-0003JD-Aa for msec-archive@lists.ietf.org; Mon, 06 Mar 2006 12:54:09 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 0A2842C8EA; Mon, 6 Mar 2006 12:54:08 -0500 (EST) 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 DF61F2C8A1 for ; Mon, 6 Mar 2006 12:54:06 -0500 (EST) Received: (qmail 45902 invoked by uid 3269); 6 Mar 2006 17:54:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 45899 invoked from network); 6 Mar 2006 17:54:06 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 6 Mar 2006 17:54:06 -0000 Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by klesh.pair.com (Postfix) with ESMTP id 86BC268388 for ; Mon, 6 Mar 2006 12:54:06 -0500 (EST) Received: from mail2.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id k26HrwmH002478; Mon, 6 Mar 2006 18:53:58 +0100 Received: from mhpahx0c.ww002.siemens.net (mhpahx0c.ww002.siemens.net [139.25.165.42]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id k26Hru7H010921; Mon, 6 Mar 2006 18:53:57 +0100 Received: from MCHP7R5A.ww002.siemens.net ([139.25.131.163]) by mhpahx0c.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 18:53:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] SHA-1 analyses of MSEC protocols Date: Mon, 6 Mar 2006 18:53:56 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] SHA-1 analyses of MSEC protocols Thread-Index: AcZAvAntgtIa/Eq2QCe1xJQ6FJIFAQAig9wA From: "Euchner, Martin" To: "Lakshminath Dondeti" , , "Euchner, Martin" X-OriginalArrivalTime: 06 Mar 2006 17:53:56.0551 (UTC) FILETIME=[F086A570:01C64146] Cc: canetti , Russ Housley 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: 082a9cbf4d599f360ac7f815372a6a15 Lakshminath, Not too long ago, I provided some analysis of MIKEY-DHHMAC w.r.t. to = SHA-1. The analysis was discussed on the MSEC mailing list and was = agreed with slight editorial corrections. The analysis will be = incorporated into the final published version of the yet to be published = RFC. The major findings are: It is believed that MIKEY DHHMAC should be considered secure enough for = the time being. Thus, there is no need to change the underlying security = mechanism within the MIKEY DHHMAC protocol. With kind regards Martin Euchner. --------------------------------------------------------------------- | Dipl.-Inf. =20 | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 62366 | COM GCM PS 3 mailto:Martin.Euchner@siemens.com | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: = http://ietf.icn.siemens.de/sr3/Standardisation_Topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany =20 --------------------------------------------------------------------- -----Original Message----- From: msec-bounces@securemulticast.org = [mailto:msec-bounces@securemulticast.org] On Behalf Of Lakshminath = Dondeti Sent: Sonntag, 5. M=E4rz 2006 09:19 To: msec@securemulticast.org Cc: canetti; Russ Housley Subject: [MSEC] SHA-1 analyses of MSEC protocols Hi all, Soon after the Vancouver meeting, we have had a pretty active=20 discussion (a combination of MSEC list discussions and some off-line=20 ones) on Russ' action to all SEC area WGs to analyze hash function = agility. I was wondering if people can provide a summary of what they have=20 done. I guess I can collect some of these from various emails and=20 draft updates, but if you are so kind to write a quick note to the=20 list, it will save me some time :-). I appreciate it very much. thanks and regards, Lakshminath _______________________________________________ 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 Mon Mar 06 14:24:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGLJp-0004fy-5v for msec-archive@lists.ietf.org; Mon, 06 Mar 2006 14:24:33 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGLJn-0006dS-Sl for msec-archive@lists.ietf.org; Mon, 06 Mar 2006 14:24:33 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 615EF2B8A4; Mon, 6 Mar 2006 14:24:20 -0500 (EST) 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 1D5562C9F2 for ; Mon, 6 Mar 2006 14:24:19 -0500 (EST) Received: (qmail 65888 invoked by uid 3269); 6 Mar 2006 19:24:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 65885 invoked from network); 6 Mar 2006 19:24:19 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 6 Mar 2006 19:24:19 -0000 Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by klesh.pair.com (Postfix) with ESMTP id 5B8DB68388 for ; Mon, 6 Mar 2006 14:24:18 -0500 (EST) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 06 Mar 2006 11:24:18 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k26JOHGv021530; Mon, 6 Mar 2006 11:24:17 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Mar 2006 11:24:17 -0800 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Mar 2006 11:24:16 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0285D58A-C483-4288-A5FC-9C5985DE6193@cisco.com> Content-Transfer-Encoding: 7bit From: David McGrew Date: Mon, 6 Mar 2006 11:24:13 -0800 To: "Fries, Steffen" X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 06 Mar 2006 19:24:16.0589 (UTC) FILETIME=[8F1ECFD0:01C64153] Cc: "Jerichow, Anja" , msec@securemulticast.org, avt@ietf.org, "Vesa Lehtovirta (JO/LMF)" , "Rauschenbach, Uwe" Subject: [MSEC] SRTP ROC synchronization methods 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: 97adf591118a232206bdb5a27b217034 Hi Steffen, On Mar 6, 2006, at 6:57 AM, Fries, Steffen wrote: > Hi David, > > aggreed, backward compatibility would be hard if not impossible. > > The assumption was (as far as I understood the DVB scenario), that > there is some out of band means to provide the ROC information. The > assumption was further that this ROC would be accepted by SRTP for > processing. According to the draft the MAC calculation itself is > the same as in RFC3711, so this should not pose a problem. The only > thing would be the acceptance of the new ROC. > I'm not familiar with the specifics of the DVB scenario, but I do like the idea of using heuristic methods to estimate the ROC (at least whenever there is some way for the receiver to discern good guesses from bad guesses). I've just finished writing up my thoughts on ROC synchronization methods, which I've put online at http://www.mindspring.com/~dmcgrew/ roc.txt. It includes a few recommendations centered around the use of heuristics. I'd be interested to hear your thoughts. Best regards, David _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Mar 07 07:31:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGbLg-0004gC-3e for msec-archive@lists.ietf.org; Tue, 07 Mar 2006 07:31:32 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGbLf-0000kN-KE for msec-archive@lists.ietf.org; Tue, 07 Mar 2006 07:31:32 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 253DD2BC09; Tue, 7 Mar 2006 07:31:31 -0500 (EST) 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 5A68A2BA12 for ; Tue, 7 Mar 2006 07:31:29 -0500 (EST) Received: (qmail 7791 invoked by uid 3269); 7 Mar 2006 12:31:29 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 7788 invoked from network); 7 Mar 2006 12:31:29 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 7 Mar 2006 12:31:29 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id F03E46838B for ; Tue, 7 Mar 2006 07:31:28 -0500 (EST) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k27CVGFT026334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 7 Mar 2006 04:31:17 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-216.qualcomm.com [10.50.76.216]) by neophyte.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k27CVC7s009254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Mar 2006 04:31:14 -0800 (PST) Message-Id: <6.2.5.6.2.20060307042738.055db118@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 07 Mar 2006 04:31:09 -0800 To: "Fries, Steffen" , "David McGrew" From: Lakshminath Dondeti Subject: RE: [MSEC] FW: Submission of draft-lehtovirta-srtp-rcc-01.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "Jerichow, Anja" , "Rauschenbach, Uwe" , avt@ietf.org, "Vesa Lehtovirta (JO/LMF)" , 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: c2e58d9873012c90703822e287241385 At 06:57 AM 3/6/2006, Fries, Steffen wrote: >Hi David, > >aggreed, backward compatibility would be hard if not impossible. > >The assumption was (as far as I understood the=20 >DVB scenario), that there is some out of band=20 >means to provide the ROC information. The=20 >assumption was further that this ROC would be=20 >accepted by SRTP for processing. According to=20 >the draft the MAC calculation itself is the same=20 >as in RFC3711, so this should not pose a=20 >problem. The only thing would be the acceptance of the new ROC. Hi Steffen, A couple of notes. First, as I noted before I=20 share the backward compatibility issues that=20 David raised. It might be worthwhile to see if=20 there is a way to signal things to help legacy terminals. Next, the RCC draft does specify a different way=20 of computing the MAC. 3711 refers to using the=20 locally maintained ROC to compute the MAC. In=20 RCC and in EKT there is a "trial" phase where the=20 received ROC is used to derive the integrity key=20 and that key is used for MAC verification. If=20 that succeeds, the received ROC replaces the=20 local ROC and everything proceeds from there. If=20 the verification fails of course, the received=20 ROC and the packet are discarded. regards, Lakshminath >Regards > Steffen >=20 > > > > -----Original Message----- > > From: msec-bounces@securemulticast.org > > [mailto:msec-bounces@securemulticast.org] On Behalf Of David McGrew > > Sent: Monday, March 06, 2006 3:46 PM > > To: Fries, Steffen > > Cc: avt@ietf.org; Rauschenbach, Uwe; Vesa Lehtovirta > > (JO/LMF); Jerichow, Anja; msec@securemulticast.org > > Subject: Re: [MSEC] FW: Submission of draft-lehtovirta-srtp-rcc-01.txt > > > > Hi Steffen, > > > > On Mar 6, 2006, at 1:43 AM, Fries, Steffen wrote: > > > > > Hi Lakshminath, > > > > > > the reason for asking that question is the following scenario. (It > > > stems from discusssions regarding OMA and DVB). If you have > > a device, > > > that currently supports SRTP and gets the session parameter > > by other > > > means (other than MIKEY od sedescriptions) you may break backward > > > compatibility with those devices while changing the MAC position. > > > > > > If one can ensure that the device gets the right ROC (the > > righ one is > > > the one, which would be submitted in the RCC packet) by > > other means, > > > and the device does not now about the new integrity > > transform (because > > > it is a parameter which is fixed), then the device could verify the > > > MAC even so it is not aware of a new integrity transform. > > As far as I > > > understood the scenario it would keep current DVB devices working. > > > > > > On the other hand, this approach would assume that all "legacy" > > > terminals use the same algorithm to find the MAC in the message. In > > > the scenario described above, it would make a difference if > > one starts > > > from the beginning or the end of a packet to search for the > > MAC. But > > > as you said, the same problem would arise for the legacy terminals > > > when using EKT, as it adds after the MAC. > > > > > > Hm, it seams that backward compatibility is getting tough > > ... maybe it > > > is worth to ask SRTP implementers, what the most used algorithm for > > > finding the MAC is. > > > > I suspect that they do it like this: > > > > auth_tag =3D (uint8_t *)hdr + *pkt_octet_len - tag_len; > > > > where auth_tag is the initial octet of the tag, hdr is a > > pointer to the start of the RTP header, *pkt_octet_len is the > > length of the RTP packet in bytes, and tag_len is the > > expected tag length for that packet (which is predictable > > because the particular MAC that is being used is determined > > by the SSRC and the session particulars). > > > > I'm a bit confused on how RCC could ever achieve backwards > > compatibility, though. A "legacy" SRTP implementation would > > need to know how to correctly verify the MAC and would need > > to know to > > discard the ROC value rather than to pass it to the RTP layer. > > Alternately, the RTP layer could discard the ROC value, but > > legacy RTP implementations won't do this. Also, there is the > > major issue that in RCC only selected packets will be > > authenticated; I don't see any way to make that work. > > > > David > > > > > > > > Regards > > > Steffen > > > > > >> -----Original Message----- > > >> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > > >> Sent: Saturday, March 04, 2006 12:54 AM > > >> To: Fries, Steffen; Vesa Lehtovirta (JO/LMF); > > >> msec@securemulticast.org; avt@ietf.org > > >> Cc: Jerichow, Anja; Rauschenbach, Uwe > > >> Subject: RE: [MSEC] FW: Submission of draft-lehtovirta-srtp- > > >> rcc-01.txt > > >> > > >> Hi Steffen, > > >> > > >> Just some thoughts on this as WG contributor: > > >> > > >> RCC would be signalled as a new MAC algorithm anyway and > > that would > > >> imply that receivers that don't understand the new MAC > > construction > > >> would need to decide against joining the secure group. > > Furthermore, > > >> if I recall the semantics correctly, the received ROC and not the > > >> stored ROC would be used in the MAC verification process. > > >> > > >> For those reasons, I don't think the proposed construction is a > > >> problem. Your proposal is also ok. I guess one way to > > look at it is > > >> if R is sufficiently high (i.e., RCC packets are infrequent), > > >> receivers that don't support the new extension can also > > listen in as > > >> long as the key management semantics are revised to allow that. > > >> > > >> That said, once again if memory serves me the reason for > > the current > > >> design of RCC is to have the MAC at the end. The EKT work > > adds new > > >> payloads at the end, however. > > >> > > >> In conclusion, I think if the RCC extension is to support what you > > >> propose, we may need to specify the RCC extension to keep the MAC > > >> algorithm the same and signal the extension differently. > > >> > > >> regards, > > >> Lakshminath > > >> > > >> At 07:28 AM 3/3/2006, Fries, Steffen wrote: > > >>> Hi Vesa, > > >>> > > >>> I just read your draft regarding the SRTP/MIKEY extension. > > >> It is a good > > >>> enhancement to transmit the ROC in parts pof the SRTP payload. > > >>> Nevertheless, I have a comment/question to the transform > > >> described in > > >>> section 2. It is stated that TAG =3D ROC_sender || MAC. What is the > > >>> reason that the TAG is constructed in that way, rather than > > >> TAG =3D MAC > > >>> || ROC_sender? > > >>> > > >>>> From my point of view there is an advantage > > >>> for the latter case. This approach would provide a better > > backward > > >>> compatibility for terminals which are not aware of the SRTP > > >> extension > > >>> you are describing. If they get the ROC information by > > other means > > >>> (e.g., seperate > > >>> messages) there still would be able to handle the MAC > > verification > > >>> correctly, as the MAC starts at the same position as described in > > >>> RFC3711. When inserting the ROC before the MAC in the > > packet, older > > >>> terminaly would take a part of the ROC as MAC, which > > would lead to > > >>> errors in the MAC verification. > > >>> > > >>> Would it influence the security in any way by choosing the > > >> TAG =3D MAC || > > >>> ROC_sender? > > >>> > > >>> Regards > > >>> Steffen > > >>> > > >>> > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: msec-bounces@securemulticast.org > > >>>> [mailto:msec-bounces@securemulticast.org] On Behalf Of Vesa > > >>>> Lehtovirta (JO/LMF) > > >>>> Sent: Tuesday, February 14, 2006 3:31 PM > > >>>> To: msec@securemulticast.org; avt@ietf.org > > >>>> Cc: Magnus Westerlund (KI/EAB) > > >>>> Subject: [MSEC] FW: Submission of > > draft-lehtovirta-srtp-rcc-01.txt > > >>>> > > >>>> Dear all, > > >>>> > > >>>> Forwarding on behalf of Karl. > > >>>> > > >>>> -----Original Message----- > > >>>> From: Karl Norrman (KI/EAB) > > >>>> Sent: 13. helmikuuta 2006 18:04 > > >>>> To: internet-drafts@ietf.org > > >>>> Cc: Vesa Lehtovirta (JO/LMF); Mats N=E4slund (KI/EAB) > > >>>> Subject: Submission of draft-lehtovirta-srtp-rcc-01.txt > > >>>> > > >>>> Dear Editor, > > >>>> > > >>>> Please submit the new version of > > draft-lehtovirta-srtp-rcc-01.txt. > > >>>> > > >>>> Best Regards, > > >>>> Karl Norrman > > >>>> Ericsson > > >>>> > > >>> _______________________________________________ > > >>> 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 > > _______________________________________________ > > 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 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Mar 07 07:34:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGbOh-0008Ga-KM for msec-archive@lists.ietf.org; Tue, 07 Mar 2006 07:34:39 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGbOh-0000mx-BQ for msec-archive@lists.ietf.org; Tue, 07 Mar 2006 07:34:39 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 3225C2C939; Tue, 7 Mar 2006 07:34:39 -0500 (EST) 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 AFD6B2C8F1 for ; Tue, 7 Mar 2006 07:34:38 -0500 (EST) Received: (qmail 8260 invoked by uid 3269); 7 Mar 2006 12:34:38 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 8257 invoked from network); 7 Mar 2006 12:34:38 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 7 Mar 2006 12:34:38 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id 82D436838B for ; Tue, 7 Mar 2006 07:34:38 -0500 (EST) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k27CYWFT026600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 7 Mar 2006 04:34:33 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-216.qualcomm.com [10.50.76.216]) by sabrina.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k27CYSg0016043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Mar 2006 04:34:30 -0800 (PST) Message-Id: <6.2.5.6.2.20060307043150.03931ea0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 07 Mar 2006 04:34:27 -0800 To: David McGrew , "Fries, Steffen" From: Lakshminath Dondeti In-Reply-To: <0285D58A-C483-4288-A5FC-9C5985DE6193@cisco.com> References: <0285D58A-C483-4288-A5FC-9C5985DE6193@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Jerichow, Anja" , "Rauschenbach, Uwe" , avt@ietf.org, "Vesa Lehtovirta (JO/LMF)" , msec@securemulticast.org Subject: [MSEC] Re: [AVT] SRTP ROC synchronization methods 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: 8b30eb7682a596edff707698f4a80f7d Hi David, I had a chance to quickly read your paper on ROC synchronization. You've talked about some of the techniques before, but I see some more new ideas there and they seem very interesting. Your note about effective MAC strength when multiple ROC values are tried out is interesting. Does that apply even if the receiver doesn't report on whether the verification succeeded or failed? Does it apply if an adversary has no way of knowing how many values a receiver might try? Thanks again for sharing your analysis and new ideas on this. best, Lakshminath At 11:24 AM 3/6/2006, David McGrew wrote: >I've just finished writing up my thoughts on ROC synchronization >methods, which I've put online at >http://www.mindspring.com/~dmcgrew/ roc.txt. It includes a few >recommendations centered around the use >of heuristics. I'd be interested to hear your thoughts. > >Best regards, > >David > > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Mar 07 08:16:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGc3P-0007nf-5j for msec-archive@lists.ietf.org; Tue, 07 Mar 2006 08:16:43 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGbtf-0001Lu-Be for msec-archive@lists.ietf.org; Tue, 07 Mar 2006 08:06:41 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 3476C2C771; Tue, 7 Mar 2006 08:06:39 -0500 (EST) 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 84A262C638 for ; Tue, 7 Mar 2006 08:06:37 -0500 (EST) Received: (qmail 16083 invoked by uid 3269); 7 Mar 2006 13:06:37 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 16080 invoked from network); 7 Mar 2006 13:06:37 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 7 Mar 2006 13:06:37 -0000 Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by klesh.pair.com (Postfix) with ESMTP id B28D66838E for ; Tue, 7 Mar 2006 08:06:36 -0500 (EST) Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8DF27CB2; Tue, 7 Mar 2006 14:06:35 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 14:06:35 +0100 Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 14:06:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MSEC] Comments to draft draft-ietf-msec-mikey-rsa-r-02.txt Date: Tue, 7 Mar 2006 14:06:34 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] Comments to draft draft-ietf-msec-mikey-rsa-r-02.txt thread-index: AcY+pfl2Wy96MgoXQRi4hsgntR2IRQAh07D/AK38thA= From: "Vesa Lehtovirta (JO/LMF)" To: "Ignjatic, Dragan" , "Lakshminath Dondeti" , X-OriginalArrivalTime: 07 Mar 2006 13:06:34.0799 (UTC) FILETIME=[F60DD3F0:01C641E7] X-Brightmail-Tracker: AAAAAA== Cc: ld@qualcomm.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: , Content-Type: multipart/mixed; boundary="===============0084979287==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.1 (/) X-Scan-Signature: b656e85d4d33f5403d96bac6146425d9 This is a multi-part message in MIME format. --===============0084979287== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C641E7.F59738DA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C641E7.F59738DA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Thanks for your responses to my comments and sorry for my delayed response.=20 I have just two further comments: =20 - w.r.t. the clarification you are making to the Abstract about using MIKEY also with other security protocols and not only with SRTP, I think this may need to to be clarified also in some other places in the draft where SRTP is mentioned.=20 =20 - the second comment: >>- Issue: In 3.2 it is said that "The Initiator MAY indicate the >>number of CSs supported,.." but in 3.2 it is said that "The >>Responder MUST fill in the number of CSs" >>Comment: Why is it differently? Should both be MUST? > >I think this is ok. If the Responder is a sending to a group (or a >group key server), then the Initiator does not need to fill in the CS >information. In either case, it is ok to have the Responder fill in >the information. > >Are you suggesting that for the unicast case, the MAY ought to be a SHOULD? >[D.I.]: This depends on whether we want to allow multiple different (unicast/multicast) streams to use the same keying material.=20 For my understanding, could you elaborate further, when is the same keying material used and when different?=20 Best regards, Vesa ________________________________ From: msec-bounces@securemulticast.org [mailto:msec-bounces@securemulticast.org] On Behalf Of Ignjatic, Dragan Sent: 4. maaliskuuta 2006 4:08 To: Lakshminath Dondeti; Vesa Lehtovirta (JO/LMF); msec@securemulticast.org Cc: ld@qualcomm.com Subject: RE: [MSEC] Comments to draft draft-ietf-msec-mikey-rsa-r-02.txt =09 =09 Hi Vesa, Many thanks for the review. I tried to clarify some of Lakshminath's points. =20 Best regards, Dragan ________________________________ From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] Sent: Fri 3/3/2006 1:36 AM To: Vesa Lehtovirta (JO/LMF); Ignjatic, Dragan; msec@securemulticast.org Cc: ld@qualcomm.com Subject: Re: [MSEC] Comments to draft draft-ietf-msec-mikey-rsa-r-02.txt =09 =09 Hi Vesa, =09 Many thanks for your comments. I apologize for the delay in my response. Dragan and I were I guess hoping the other would respond and he noted he will be commenting tomorrow. =09 I will try to address your comments below: =09 At 01:25 AM 2/24/2006, Vesa Lehtovirta \(JO/LMF\) wrote: =09 >Hi all, > >Here are some comments, and also questions, to the >draft-ietf-msec-mikey-rsa-r-02.txt. > >In general the draft is well written and an interesting approach. > >Best regards, > > Vesa > >- Issue: Abstract says that >"The Multimedia Internet Keying (MIKEY) specification describes >several modes of key distribution to setup Secure Real-time Rransport >Protocol (SRTP) sessions..." > >Comment: The draft generally gives the impression that MIKEY is used >solely for setting up keys for SRTP. However, MIKEY is not >restricted to SRTP only, although certain parameters have been >specified already for SRTP in MIKEY RFC3830. MIKEY is extensible to >be used with other security protocols also but this may require that >needed parameters can be specified also for other security >protocols. Therefore, it would be good to mention SRTP as one >possible security protocol and not the only possible one. Or is it >the intention that this would be used only with SRTP? =09 I appreciate the distinction you are making. We'll address this by rewording that paragraph. =09 =09 >- Issue: One of the main points in the draft is that the Initiator >may not know the Responder's ID and in 3.2 it is said for the I_MESSAGE: > >"If the Responder has multiple Identities, the Initiator MAY also >include the specific ID, IDr, of the Responder that it wants to >communicate with." > >Comment: The question is, if the IDr is not indicated in the >I_MESSAGE, how can the message be routed to the correct responder? >If this is assumed to be done in some other layer, e.g. SIP, how can >the initiator know the SIP layer identity if it does not know the >MIKEY layer identity? Or is it assumed then that e.g. the SIP layer >identity may be known even though the MIKEY layer identity is not known? =09 Yes. But, I guess that MAY can be clarified further. If the Initiator knows the specific Responder's ID it wants to communicate with and specifies it, what happens if due to forking or redirect or something it goes to a different place. =09 W.r.t. routing the message though, my understanding is that's all SIP level and not up to MIKEY. We can only specify how MIKEY messages are to be processed if and when they go to an unintended entity. =09 =09 >- Issue: In 3.2 it is said that "The Initiator MAY indicate the >number of CSs supported,.." but in 3.2 it is said that "The >Responder MUST fill in the number of CSs" >Comment: Why is it differently? Should both be MUST? =09 I think this is ok. If the Responder is a sending to a group (or a group key server), then the Initiator does not need to fill in the CS information. In either case, it is ok to have the Responder fill in the information. =09 Are you suggesting that for the unicast case, the MAY ought to be a SHOULD? [D.I.]: This depends on whether we want to allow multiple different (unicast/multicast) streams to use the same keying material.=20 >- Issue: In 5 (last para) it is said that "Unicast and multicast >keys have different >security properties and should not be derived from the same pool." =09 Ok, that's vague. We'll clarify further. [D.I.]: We will clarify in the draft. This only means that the same keying material should not be used for both multicast and unicast streams as it may introduce two time pad problems with multiple unicast sources that pick their own SSRC's. =09 >Comment: Usually we can trust to one-way key derivation functions to >provide key separation. Is there a reason why we cannot assume it here? > >- Issue: In 5 (last para) it is said that >"The authors believe that multiple TGK payloads can be used for this >purpose but the exact method is not specified in MIKEY." =09 Right, we talked a lot about this and we thought it is under specified or something, but decided that it is out of scope for RSA-R. But that statement might best be removed or further clarified. =09 [D.I.]: I believe what is lacking is a good mapping mechanism between TGKs and sessions and again decided RSA-R is not the way to introduce it. =09 >Comment: When checking this seems to be specified in 6.2 and 6.13 of >RFC 3830. > >- Smaller stuff: In 3.3 (page 7): What is "complete CS map"? Is it >"CS ID map info"? =09 We'll rewrite that. Thanks for catching this. =09 =09 >- Smaller stuff: In 3.4.1, 3.4.2 and 3.4.3 it could be indicated >what is new information. =09 Will do. =09 =09 >- Finally some comments on some "extra" messages on the proposed >procedure: The current draft proposes a solution where the Initiator >prompts the Responder to send the TGK key. I wonder if the procedure >could be extended with a Verification message to know that the key >has been delivered (as in current MIKEY): > >Init Resp >----- ---- >I_MSG[CERTi] --> > <-- R_MSG(TGK)[CERTr] >I_MSG[Verif] --> > >Also, the current draft does not allow the Initiator to choose the >TGK. I wonder if the procedure could be also extended with a new >message in the beginning of the procedure where the Init could ask >the Resp to request the key from Init. I guess you have thought of >this since this case has been shortly discussed in 4.1 but then you >have abandobed it as too complex?: "For instance, A might ask C to >contact B or itself to get the TGK, in effect initiating a 3-way exchange. " > >Init Resp >----- ---- >I_MSG[CERTi] --> > <-- R_MSG[CERTr] >I_MSG(TGK) --> > That would be a 3-way exchange and my take is no. :-). =09 Thanks Vesa for a very thoughtful and thorough review. We'll address your comments in the next rev. [D.I.]: Right, even if the three way handshake can be justified I don't think RSA-R work should introduce it. =09 best regards, Lakshminath =09 =09 ------_=_NextPart_001_01C641E7.F59738DA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [MSEC] Comments to draft = draft-ietf-msec-mikey-rsa-r-02.txt
Hi,
 
Thanks=20 for your responses to my comments and sorry for my delayed response.=20
I have=20 just two further comments:
 
-=20 w.r.t. the clarification you are making to the Abstract about = using MIKEY=20 also with other security protocols and not only with SRTP, I think this = may need=20 to to be clarified also in some other places in the draft where SRTP is=20 mentioned.
 
- the second = comment:
>>- Issue: In 3.2 it is said that "The = Initiator MAY=20 indicate the
>>number of CSs supported,.." but in 3.2 it is = said that=20 "The
>>Responder MUST fill in the number of = CSs"
>>Comment:=20 Why is it differently? Should both be MUST?
>
>I think this = is=20 ok.  If the Responder is a sending to a group (or a
>group = key=20 server), then the Initiator does not need to fill in the=20 CS
>information.  In either case, it is ok to have the = Responder fill=20 in
>the information.
>
>Are you suggesting that for = the=20 unicast case, the MAY ought to be a SHOULD?

>[D.I.]: This depends on whether we = want to=20 allow multiple different (unicast/multicast) streams to use the same = keying=20 material.

For my understanding, could you = elaborate=20 further, when is the same keying material used and when different?=20

Best=20 regards,

 =20 Vesa

From: msec-bounces@securemulticast.org=20 [mailto:msec-bounces@securemulticast.org] On Behalf Of = Ignjatic,=20 Dragan
Sent: 4. maaliskuuta 2006 4:08
To: = Lakshminath=20 Dondeti; Vesa Lehtovirta (JO/LMF); = msec@securemulticast.org
Cc:=20 ld@qualcomm.com
Subject: RE: [MSEC] Comments to draft=20 draft-ietf-msec-mikey-rsa-r-02.txt

Hi = Vesa,
Many thanks for the review. = I tried=20 to clarify some of Lakshminath's points.
 
Best regards,
Dragan

From: Lakshminath Dondeti=20 [mailto:ldondeti@qualcomm.com]
Sent: Fri 3/3/2006 1:36=20 AM
To: Vesa Lehtovirta (JO/LMF); Ignjatic, Dragan;=20 msec@securemulticast.org
Cc: = ld@qualcomm.com
Subject: Re:=20 [MSEC] Comments to draft=20 draft-ietf-msec-mikey-rsa-r-02.txt

Hi Vesa,

Many thanks for your comments.  = I=20 apologize for the delay in my
response.  Dragan and I were I = guess=20 hoping the other would respond
and he noted he will be commenting=20 tomorrow.

I will try to address your comments below:

At = 01:25 AM=20 2/24/2006, Vesa Lehtovirta \(JO/LMF\) wrote:

>Hi=20 all,
>
>Here are some comments, and also questions, to=20 the
>draft-ietf-msec-mikey-rsa-r-02.txt.
>
>In = general the=20 draft is well written and an interesting approach.
>
>Best = regards,
>
>    Vesa
>
>- = Issue:=20 Abstract says that
>"The Multimedia Internet Keying (MIKEY)=20 specification describes
>several modes of key distribution to = setup=20 Secure Real-time Rransport
>Protocol (SRTP)=20 sessions..."
>
>Comment: The draft generally gives the = impression=20 that MIKEY is used
>solely for setting up keys for SRTP. = However, MIKEY=20 is not
>restricted to SRTP only, although certain parameters = have=20 been
>specified already for SRTP in MIKEY RFC3830. MIKEY is = extensible=20 to
>be used with other security protocols also but this may = require=20 that
>needed parameters can be specified also for other=20 security
>protocols. Therefore, it would be good to mention SRTP = as=20 one
>possible security protocol and not the only possible one. = Or is=20 it
>the intention that this would be used only with = SRTP?

I=20 appreciate the distinction you are making.  We'll address this=20 by
rewording that paragraph.


>- Issue: One of the = main points=20 in the draft is that the Initiator
>may not know the Responder's = ID and=20 in 3.2 it is said for the I_MESSAGE:
>
>"If the Responder = has=20 multiple Identities, the Initiator MAY also
>include the = specific ID,=20 IDr, of the Responder that it wants to
>communicate=20 with."
>
>Comment: The question is, if the IDr is not = indicated in=20 the
>I_MESSAGE, how can the message be routed to the correct=20 responder?
>If this is assumed to be done in some other layer, = e.g. SIP,=20 how can
>the initiator know the SIP layer identity if it does = not know=20 the
>MIKEY layer identity? Or is it assumed then that e.g. the = SIP=20 layer
>identity may be known even though the MIKEY layer = identity is not=20 known?

Yes.  But, I guess that MAY can be clarified = further. =20 If the
Initiator knows the specific Responder's ID it wants to=20 communicate
with and specifies it, what happens if due to forking = or=20 redirect or
something it goes to a different place.

W.r.t. = routing=20 the message though, my understanding is that's all SIP
level and = not up to=20 MIKEY.  We can only specify how MIKEY messages
are to be = processed if=20 and when they go to an unintended entity.


>- Issue: In = 3.2 it is=20 said that "The Initiator MAY indicate the
>number of CSs = supported,.."=20 but in 3.2 it is said that "The
>Responder MUST fill in the = number of=20 CSs"
>Comment: Why is it differently? Should both be = MUST?

I=20 think this is ok.  If the Responder is a sending to a group (or=20 a
group key server), then the Initiator does not need to fill in = the=20 CS
information.  In either case, it is ok to have the = Responder fill=20 in
the information.

Are you suggesting that for the unicast = case,=20 the MAY ought to be a SHOULD?

[D.I.]: This depends on = whether we want to=20 allow multiple different (unicast/multicast) streams to use the same = keying=20 material.

>- Issue: In 5 (last para) it is said that "Unicast and=20 multicast
>keys have different
>security properties and = should not=20 be derived from the same pool."

Ok, that's vague.  We'll = clarify=20 further.

[D.I.]: We will clarify in the draft. This only means that the same = keying=20 material should not be used for both multicast and unicast streams as = it may=20 introduce two time pad problems with multiple unicast sources that = pick their=20 own SSRC's.

>Comment: Usually we can trust to one-way key = derivation=20 functions to
>provide key separation. Is there a reason why we = cannot=20 assume it here?
>
>- Issue: In 5 (last para) it is said=20 that
>"The authors believe that multiple TGK payloads can be = used for=20 this
>purpose but the exact method is not specified in=20 MIKEY."

Right, we talked a lot about this and we thought it is=20 under
specified or something, but decided that it is out of scope=20 for
RSA-R.  But that statement might best be removed or = further=20 clarified.

[D.I.]: I believe what is lacking is a good mapping=20 mechanism between TGKs and sessions and again decided RSA-R = is not=20 the way to introduce it.

>Comment: When checking this seems = to be=20 specified in 6.2 and 6.13 of
>RFC 3830.
>
>- Smaller = stuff:=20 In 3.3 (page 7): What is "complete CS map"? Is it
>"CS ID map=20 info"?

We'll rewrite that.  Thanks for catching=20 this.


>- Smaller stuff: In 3.4.1, 3.4.2 and 3.4.3 it = could be=20 indicated
>what is new information.

Will = do.


>-=20 Finally some comments on some "extra" messages on the=20 proposed
>procedure: The current draft proposes a solution where = the=20 Initiator
>prompts the Responder to send the TGK key. I wonder = if the=20 procedure
>could be extended with a Verification message to know = that=20 the key
>has been delivered (as in current=20 = MIKEY):
>
>Init       &nbs= p;    =20 = Resp
>-----         &n= bsp; =20 ----
>I_MSG[CERTi] =20 -->
>        <--=20 R_MSG(TGK)[CERTr]
>I_MSG[Verif] -->
>
>Also, the = current=20 draft does not allow the Initiator to choose the
>TGK. I wonder = if the=20 procedure could be also extended with a new
>message in the = beginning of=20 the procedure where the Init could ask
>the Resp to request the = key from=20 Init. I guess you have thought of
>this since this case has been = shortly=20 discussed in 4.1 but then you
>have abandobed it as too = complex?: "For=20 instance, A might ask C to
>contact B or itself to get the TGK, = in=20 effect initiating a 3-way exchange.=20 = "
>
>Init        &nbs= p;   =20 = Resp
>-----         &n= bsp; =20 ----
>I_MSG[CERTi]=20 -->
>        <--=20 R_MSG[CERTr]
>I_MSG(TGK) -->
>
That would be a 3-way = exchange and my take is no.  :-).

Thanks Vesa for a very=20 thoughtful and thorough review.  We'll address
your comments = in the=20 next rev.

[D.I.]: Right, even if the three way handshake can be = justified I=20 don't think RSA-R work should introduce it.

best=20 = regards,
Lakshminath

------_=_NextPart_001_01C641E7.F59738DA-- --===============0084979287== 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 --===============0084979287==-- From msec-bounces@securemulticast.org Tue Mar 07 14:25:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGhnz-000747-SS for msec-archive@lists.ietf.org; Tue, 07 Mar 2006 14:25:11 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGhny-0007zb-Dx for msec-archive@lists.ietf.org; Tue, 07 Mar 2006 14:25:11 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 074F62C9C5; Tue, 7 Mar 2006 14:25:10 -0500 (EST) 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 4A7962C7A5 for ; Tue, 7 Mar 2006 14:25:09 -0500 (EST) Received: (qmail 28924 invoked by uid 3269); 7 Mar 2006 19:25:09 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 28921 invoked from network); 7 Mar 2006 19:25:09 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 7 Mar 2006 19:25:09 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id BA03768382 for ; Tue, 7 Mar 2006 14:25:08 -0500 (EST) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k27JOxFT000410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 7 Mar 2006 11:25:00 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-141.qualcomm.com [10.50.76.141]) by sabrina.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k27JOrVr010916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Mar 2006 11:24:56 -0800 (PST) Message-Id: <6.2.5.6.2.20060307112027.0405a490@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 07 Mar 2006 11:24:49 -0800 To: "Vesa Lehtovirta (JO/LMF)" , "Ignjatic, Dragan" , From: Lakshminath Dondeti Subject: RE: [MSEC] Comments to draft draft-ietf-msec-mikey-rsa-r-02.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ld@qualcomm.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: 7698d1420ecbbce1995432e99bb6d1a1 At 05:06 AM 3/7/2006, Vesa Lehtovirta \(JO/LMF\) wrote: >Hi, > >Thanks for your responses to my comments and sorry for my delayed response. >I have just two further comments: > >- w.r.t. the clarification you are making to the Abstract about >using MIKEY also with other security protocols and not only with >SRTP, I think this may need to to be clarified also in some other >places in the draft where SRTP is mentioned. I caught most if not all of them. We submitted an -03- based on Steffen's and your reviews and the ensuing discussions. Dragan and I went back and forth on allowing certain things and those influenced the MUST/SHOULDs a bit more, but we clarified all of that with follow-up explanatory text. Please look at the diffs when the I-D shows up in the repository. More in line. > >- the second comment: > >>- Issue: In 3.2 it is said that "The Initiator MAY indicate the > >>number of CSs supported,.." but in 3.2 it is said that "The > >>Responder MUST fill in the number of CSs" > >>Comment: Why is it differently? Should both be MUST? > > > >I think this is ok. If the Responder is a sending to a group (or a > >group key server), then the Initiator does not need to fill in the CS > >information. In either case, it is ok to have the Responder fill in > >the information. > > > >Are you suggesting that for the unicast case, the MAY ought to be a SHOULD? > > >[D.I.]: This depends on whether we want to allow multiple > different (unicast/multicast) streams to use the same keying material. > >For my understanding, could you elaborate further, when is the same >keying material used and when different? So there is a case for one side to pick all the parameters especially SSRC and RAND to avoid collisions (e.g., MIKEY-RSA and MIKEY-PSK with the 1 message case already allow this model). We are just trying to keep all the features intact, especially to allow collision-free operation in group communication (note: it is of course possible to continue to use RTP's random SSRC selection algm). regards, Lakshminath >Best regards, > > Vesa > >---------- >From: msec-bounces@securemulticast.org >[mailto:msec-bounces@securemulticast.org] On Behalf Of Ignjatic, Dragan >Sent: 4. maaliskuuta 2006 4:08 >To: Lakshminath Dondeti; Vesa Lehtovirta (JO/LMF); msec@securemulticast.org >Cc: ld@qualcomm.com >Subject: RE: [MSEC] Comments to draft draft-ietf-msec-mikey-rsa-r-02.txt > >Hi Vesa, >Many thanks for the review. I tried to clarify some of Lakshminath's points. > >Best regards, >Dragan > > >---------- >From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] >Sent: Fri 3/3/2006 1:36 AM >To: Vesa Lehtovirta (JO/LMF); Ignjatic, Dragan; msec@securemulticast.org >Cc: ld@qualcomm.com >Subject: Re: [MSEC] Comments to draft draft-ietf-msec-mikey-rsa-r-02.txt > >Hi Vesa, > >Many thanks for your comments. I apologize for the delay in my >response. Dragan and I were I guess hoping the other would respond >and he noted he will be commenting tomorrow. > >I will try to address your comments below: > >At 01:25 AM 2/24/2006, Vesa Lehtovirta \(JO/LMF\) wrote: > > >Hi all, > > > >Here are some comments, and also questions, to the > >draft-ietf-msec-mikey-rsa-r-02.txt. > > > >In general the draft is well written and an interesting approach. > > > >Best regards, > > > > Vesa > > > >- Issue: Abstract says that > >"The Multimedia Internet Keying (MIKEY) specification describes > >several modes of key distribution to setup Secure Real-time Rransport > >Protocol (SRTP) sessions..." > > > >Comment: The draft generally gives the impression that MIKEY is used > >solely for setting up keys for SRTP. However, MIKEY is not > >restricted to SRTP only, although certain parameters have been > >specified already for SRTP in MIKEY RFC3830. MIKEY is extensible to > >be used with other security protocols also but this may require that > >needed parameters can be specified also for other security > >protocols. Therefore, it would be good to mention SRTP as one > >possible security protocol and not the only possible one. Or is it > >the intention that this would be used only with SRTP? > >I appreciate the distinction you are making. We'll address this by >rewording that paragraph. > > > >- Issue: One of the main points in the draft is that the Initiator > >may not know the Responder's ID and in 3.2 it is said for the I_MESSAGE: > > > >"If the Responder has multiple Identities, the Initiator MAY also > >include the specific ID, IDr, of the Responder that it wants to > >communicate with." > > > >Comment: The question is, if the IDr is not indicated in the > >I_MESSAGE, how can the message be routed to the correct responder? > >If this is assumed to be done in some other layer, e.g. SIP, how can > >the initiator know the SIP layer identity if it does not know the > >MIKEY layer identity? Or is it assumed then that e.g. the SIP layer > >identity may be known even though the MIKEY layer identity is not known? > >Yes. But, I guess that MAY can be clarified further. If the >Initiator knows the specific Responder's ID it wants to communicate >with and specifies it, what happens if due to forking or redirect or >something it goes to a different place. > >W.r.t. routing the message though, my understanding is that's all SIP >level and not up to MIKEY. We can only specify how MIKEY messages >are to be processed if and when they go to an unintended entity. > > > >- Issue: In 3.2 it is said that "The Initiator MAY indicate the > >number of CSs supported,.." but in 3.2 it is said that "The > >Responder MUST fill in the number of CSs" > >Comment: Why is it differently? Should both be MUST? > >I think this is ok. If the Responder is a sending to a group (or a >group key server), then the Initiator does not need to fill in the CS >information. In either case, it is ok to have the Responder fill in >the information. > >Are you suggesting that for the unicast case, the MAY ought to be a SHOULD? > >[D.I.]: This depends on whether we want to allow multiple different >(unicast/multicast) streams to use the same keying material. > > >- Issue: In 5 (last para) it is said that "Unicast and multicast > >keys have different > >security properties and should not be derived from the same pool." > >Ok, that's vague. We'll clarify further. > >[D.I.]: We will clarify in the draft. This only means that the same >keying material should not be used for both multicast and unicast >streams as it may introduce two time pad problems with multiple >unicast sources that pick their own SSRC's. > > >Comment: Usually we can trust to one-way key derivation functions to > >provide key separation. Is there a reason why we cannot assume it here? > > > >- Issue: In 5 (last para) it is said that > >"The authors believe that multiple TGK payloads can be used for this > >purpose but the exact method is not specified in MIKEY." > >Right, we talked a lot about this and we thought it is under >specified or something, but decided that it is out of scope for >RSA-R. But that statement might best be removed or further clarified. > >[D.I.]: I believe what is lacking is a good mapping mechanism >between TGKs and sessions and again decided RSA-R is not the way to >introduce it. > > >Comment: When checking this seems to be specified in 6.2 and 6.13 of > >RFC 3830. > > > >- Smaller stuff: In 3.3 (page 7): What is "complete CS map"? Is it > >"CS ID map info"? > >We'll rewrite that. Thanks for catching this. > > > >- Smaller stuff: In 3.4.1, 3.4.2 and 3.4.3 it could be indicated > >what is new information. > >Will do. > > > >- Finally some comments on some "extra" messages on the proposed > >procedure: The current draft proposes a solution where the Initiator > >prompts the Responder to send the TGK key. I wonder if the procedure > >could be extended with a Verification message to know that the key > >has been delivered (as in current MIKEY): > > > >Init Resp > >----- ---- > >I_MSG[CERTi] --> > > <-- R_MSG(TGK)[CERTr] > >I_MSG[Verif] --> > > > >Also, the current draft does not allow the Initiator to choose the > >TGK. I wonder if the procedure could be also extended with a new > >message in the beginning of the procedure where the Init could ask > >the Resp to request the key from Init. I guess you have thought of > >this since this case has been shortly discussed in 4.1 but then you > >have abandobed it as too complex?: "For instance, A might ask C to > >contact B or itself to get the TGK, in effect initiating a 3-way exchange. " > > > >Init Resp > >----- ---- > >I_MSG[CERTi] --> > > <-- R_MSG[CERTr] > >I_MSG(TGK) --> > > >That would be a 3-way exchange and my take is no. :-). > >Thanks Vesa for a very thoughtful and thorough review. We'll address >your comments in the next rev. > >[D.I.]: Right, even if the three way handshake can be justified I >don't think RSA-R work should introduce it. > >best regards, >Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Mar 08 02:06:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGskK-00043I-Pl for msec-archive@lists.ietf.org; Wed, 08 Mar 2006 02:06:08 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGskJ-0000LJ-Gw for msec-archive@lists.ietf.org; Wed, 08 Mar 2006 02:06:08 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id E322C2C0A0; Wed, 8 Mar 2006 02:06:06 -0500 (EST) 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 7D8B22BC49 for ; Wed, 8 Mar 2006 02:06:05 -0500 (EST) Received: (qmail 18910 invoked by uid 3269); 8 Mar 2006 07:06:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 18907 invoked from network); 8 Mar 2006 07:06:05 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 8 Mar 2006 07:06:05 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id 01B38683AF for ; Wed, 8 Mar 2006 02:06:04 -0500 (EST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k28762FT032632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 7 Mar 2006 23:06:03 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-68-87.qualcomm.com [10.50.68.87]) by magus.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2875ow1003462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 7 Mar 2006 23:05:59 -0800 (PST) Message-Id: <6.2.5.6.2.20060307230441.038dcec0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 07 Mar 2006 23:05:46 -0800 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Tentative agenda for review 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 all, Below is the MSEC agenda based on the requests received so far, and draft updates. Please review and let us know if an agenda item is missing or if you are listed as a speaker if you need more/less time. Thanks. I'd like to post this in the next 24-36 hours. Also, if you are speaker, please prepare slides ASAP so we can upload them say a week before the meeting. regards, Ran & Lakshminath MSEC status summary 10 Ran & Lakshminath AD advise on the quality of MSEC specifications 15 Sam Update on Russ's action item on hash function agility 15 Lakshminath & Ran GDOI Update 10 Brian & Sheela GKDP 10 Sheela, Lakshminath, & Jing MSEC IPsec extensions 15 Brian, Dragan, George MIKEY-Applicability discussion 15 Steffen and Dragan MIKEY Updates 10 Bob M, and others ALC/NORM TESLA 10 Vincent _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Mar 08 03:36:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGu9O-0006sh-Pj for msec-archive@lists.ietf.org; Wed, 08 Mar 2006 03:36:06 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGu9M-00074E-Dt for msec-archive@lists.ietf.org; Wed, 08 Mar 2006 03:36:06 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id DA32D2C72E; Wed, 8 Mar 2006 03:36:03 -0500 (EST) 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 DC3F52C70E for ; Wed, 8 Mar 2006 03:36:01 -0500 (EST) Received: (qmail 38387 invoked by uid 3269); 8 Mar 2006 08:36:00 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 38377 invoked from network); 8 Mar 2006 08:35:59 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 8 Mar 2006 08:35:59 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 7F40168388 for ; Wed, 8 Mar 2006 03:35:59 -0500 (EST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k288ZsMs011871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 8 Mar 2006 00:35:55 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-68-87.qualcomm.com [10.50.68.87]) by magus.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k288ZeIM022828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Mar 2006 00:35:50 -0800 (PST) Message-Id: <6.2.5.6.2.20060308003215.055917b8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 08 Mar 2006 00:35:37 -0800 To: Cullen Jennings , , From: Lakshminath Dondeti Subject: Re: [AVT] RE: [MSEC] FW: Submission of draft-lehtovirta-srtp-rcc-01.txt In-Reply-To: References: <6.2.5.6.2.20060305184409.03ae8bd8@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: David A McGrew 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: d0bdc596f8dd1c226c458f0b4df27a88 Cullen, To give you a quick answer, I don't know. From what I can tell, OMA and 3GPP2 don't use SRTP for unicast. I don't know about 3GPP. Folks from Ericsson might have some insight into that. I will also check. cheers, Lakshminath At 07:44 PM 3/7/2006, Cullen Jennings wrote: >Thanks - yes, that was type of info I was looking for. Do you know if 3GPP, >OMA, others, are using MKI when doing unicast stuff? and if so, how do they >use it? > > >On 3/5/06 4:57 AM, "Lakshminath Dondeti" wrote: > > > Hi Cullen, > > > > MKI use in different ways is a known problem that folks in OMA BCAST > > have been working to resolve for a few months now. > > > > 3GPP MBMS MKI field is defined as (MSK ID || MTK ID). MSK = MBMS > > Service key (long term key) and MTK = MBMS Traffic key (short term key) > > > > In 3GPP2 BCMCS, MKI field was/is defined as (4-bit Reserved||4-bit > > BAK_ID||32-bit ROC||32-bit SK_RAND). BAK is the long term key and > > SK_RAND is used to compute the short term key. > > > > I have worked with my colleagues in 3GPP2 recently to have that > > changed to (4-bit Reserved||4-bit BAK_ID||32-bit SK_RAND), and send > > the ROC as part of the auth_tag as defined in the RCC I-D. > > > > My recollection is DVB sends TEK ID in the MKI (not sure about that, > > so please cross-check). > > > > As you note this leads to interop problems, for instance, a > > broadcaster (OMA context) will have to prepare multiple SRTP streams > > for multiple broadcast distribution systems (e.g., BCMCS, MBMS, > > etc.,) and people are now trying to resolve that. I will have an > > update on this later this week (we are meeting in Seoul in part to > > resolve some of this), if you care. > > > > All of this is in the context of broadcast though. Is that what you > > have in mind? Or, are you looking for information on unicast SRTP usage? > > > > regards, > > Lakshminath > > > > At 04:16 AM 3/6/2006, Cullen Jennings wrote: > > > >> You mention how 3GPP is using the MKI. Could you provide any > more details or > >> references on this? Do you foresee interop problems if an 3GPP device was > >> talking to a devices that was using MKI more the way that SRTP > specified it? > >> > >>>>> > >>>>> Please submit the new version of draft-lehtovirta-srtp-rcc-01.txt. > >>>>> > >> > >> _______________________________________________ > >> Audio/Video Transport Working Group > >> avt@ietf.org > >> https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Mar 08 16:08:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH5t1-0001oM-1p for msec-archive@lists.ietf.org; Wed, 08 Mar 2006 16:07:59 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH5sz-0005Bo-Fx for msec-archive@lists.ietf.org; Wed, 08 Mar 2006 16:07:58 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 85C582CC9B; Wed, 8 Mar 2006 16:07:43 -0500 (EST) 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 41D4E2CC8A for ; Wed, 8 Mar 2006 16:07:42 -0500 (EST) Received: (qmail 94968 invoked by uid 3269); 8 Mar 2006 21:07:41 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 94959 invoked from network); 8 Mar 2006 21:07:40 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 8 Mar 2006 21:07:40 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id 886BF683AC for ; Wed, 8 Mar 2006 16:07:40 -0500 (EST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k28L7ZFT009983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 8 Mar 2006 13:07:35 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-77-14.qualcomm.com [10.50.77.14]) by magus.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k28L7VwY018704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Mar 2006 13:07:33 -0800 (PST) Message-Id: <6.2.5.6.2.20060308125804.0576c9a8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 08 Mar 2006 13:07:31 -0800 To: David McGrew From: Lakshminath Dondeti In-Reply-To: <24ACEE04-EE67-4916-851D-D8B1B4F0652B@cisco.com> References: <0285D58A-C483-4288-A5FC-9C5985DE6193@cisco.com> <6.2.5.6.2.20060307043150.03931ea0@qualcomm.com> <24ACEE04-EE67-4916-851D-D8B1B4F0652B@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: avt@ietf.org, msec@securemulticast.org Subject: [MSEC] Re: [AVT] SRTP ROC synchronization methods 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: f4c2cf0bccc868e4cc88dace71fb3f44 David, Just on the ROC synchronization topic: Taking the DTLS stuff into account, we might call it a long IV maintenance based on a short IV or something like that. :-) In any event, point being, IIRC, one of the DTLS specs suggests trying out as many sequence numbers that a replay window allows. I may have misinterpreted that (waiting for clarifications, Eric is working on responding soon). If indeed that's the case, a 64-bit window could reduce the MAC strength by 6 bits. (they have other issues due to the authenticate and then encrypt nature of TLS encapsulation, but that's another story). regards, Lakshminath At 12:52 PM 3/8/2006, David McGrew wrote: >Lakshminath, > >I didn't do a whole lot of analysis about this case because I favor >the "try one ROC value for each packet" approach (it's easy to >implement on an embedded system that uses a bounded number of cycles >to process each packet). I think that the effective MAC strength >holds in the cases that you mention, but if someone is really >interested in pursuing that approach, let's do a more detailed analysis. > >David > >> >>Thanks again for sharing your analysis and new ideas on this. >> >>best, >>Lakshminath >> >>At 11:24 AM 3/6/2006, David McGrew wrote: >> >> >>>I've just finished writing up my thoughts on ROC synchronization >>>methods, which I've put online at http://www.mindspring.com/ >>>~dmcgrew/ roc.txt. It includes a few recommendations centered >>>around the use >>>of heuristics. I'd be interested to hear your thoughts. >>> >>>Best regards, >>> >>>David >>> >>> >>>_______________________________________________ >>>Audio/Video Transport Working Group >>>avt@ietf.org >>>https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Mar 08 16:50:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH6YQ-0006yT-IF for msec-archive@lists.ietf.org; Wed, 08 Mar 2006 16:50:46 -0500 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 1FH5r5-0004WY-BC for msec-archive@lists.ietf.org; Wed, 08 Mar 2006 16:05:59 -0500 Received: from six.pairlist.net ([209.68.2.254]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FH5dz-0004jr-IL for msec-archive@lists.ietf.org; Wed, 08 Mar 2006 15:52:33 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 152512C16B; Wed, 8 Mar 2006 15:52:27 -0500 (EST) 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 A2FDD2BDD4 for ; Wed, 8 Mar 2006 15:52:25 -0500 (EST) Received: (qmail 92210 invoked by uid 3269); 8 Mar 2006 20:52:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 92207 invoked from network); 8 Mar 2006 20:52:25 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 8 Mar 2006 20:52:25 -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 6AE266838E for ; Wed, 8 Mar 2006 15:52:25 -0500 (EST) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 08 Mar 2006 12:52:22 -0800 X-IronPort-AV: i="4.02,176,1139212800"; d="scan'208"; a="1783184190:sNHT32637868" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k28KqLw1009673; Wed, 8 Mar 2006 12:52:21 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 12:52:20 -0800 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 12:52:19 -0800 In-Reply-To: <6.2.5.6.2.20060307043150.03931ea0@qualcomm.com> References: <0285D58A-C483-4288-A5FC-9C5985DE6193@cisco.com> <6.2.5.6.2.20060307043150.03931ea0@qualcomm.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <24ACEE04-EE67-4916-851D-D8B1B4F0652B@cisco.com> Content-Transfer-Encoding: 7bit From: David McGrew Date: Wed, 8 Mar 2006 12:52:16 -0800 To: Lakshminath Dondeti X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 08 Mar 2006 20:52:19.0988 (UTC) FILETIME=[31190540:01C642F2] Cc: avt@ietf.org, "Rauschenbach, Uwe" , "Vesa Lehtovirta (JO/LMF)" , "Jerichow, Anja" , msec@securemulticast.org, "Fries, Steffen" Subject: [MSEC] Re: [AVT] SRTP ROC synchronization methods 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: 3e15cc4fdc61d7bce84032741d11c8e5 Lakshminath, On Mar 7, 2006, at 4:34 AM, Lakshminath Dondeti wrote: > Hi David, > > I had a chance to quickly read your paper on ROC synchronization. > You've talked about some of the techniques before, but I see some > more new ideas there and they seem very interesting. thanks. > Your note about effective MAC strength when multiple ROC values are > tried out is interesting. Does that apply even if the receiver > doesn't report on whether the verification succeeded or failed? > Does it apply if an adversary has no way of knowing how many values > a receiver might try? I didn't do a whole lot of analysis about this case because I favor the "try one ROC value for each packet" approach (it's easy to implement on an embedded system that uses a bounded number of cycles to process each packet). I think that the effective MAC strength holds in the cases that you mention, but if someone is really interested in pursuing that approach, let's do a more detailed analysis. David > > Thanks again for sharing your analysis and new ideas on this. > > best, > Lakshminath > > At 11:24 AM 3/6/2006, David McGrew wrote: > > >> I've just finished writing up my thoughts on ROC synchronization >> methods, which I've put online at http://www.mindspring.com/ >> ~dmcgrew/ roc.txt. It includes a few recommendations centered >> around the use >> of heuristics. I'd be interested to hear your thoughts. >> >> Best regards, >> >> David >> >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Mar 09 02:54:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHFyi-0006Lc-67 for msec-archive@lists.ietf.org; Thu, 09 Mar 2006 02:54:32 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHFye-0007l3-SX for msec-archive@lists.ietf.org; Thu, 09 Mar 2006 02:54:32 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 664DD2C841; Thu, 9 Mar 2006 02:54:28 -0500 (EST) 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 9CF0D2B9F8 for ; Thu, 9 Mar 2006 02:54:26 -0500 (EST) Received: (qmail 43960 invoked by uid 3269); 9 Mar 2006 07:54:26 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 43957 invoked from network); 9 Mar 2006 07:54:26 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 9 Mar 2006 07:54:26 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id 28E2F68388 for ; Thu, 9 Mar 2006 02:54:26 -0500 (EST) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k297sLFT030762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 8 Mar 2006 23:54:21 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-68-141.qualcomm.com [10.50.68.141]) by crowley.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k297sAID016783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Mar 2006 23:54:16 -0800 (PST) Message-Id: <6.2.5.6.2.20060308233148.041274c0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 08 Mar 2006 23:54:09 -0800 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Russ Housley , canetti , Sam Hartman Subject: [MSEC] Agenda, with an update 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: 4b800b1eab964a31702fa68f1ff0e955 Hi all, I have added the SRTP-EKT draft to the end of the agenda. At this point we have a full-length agenda (120 mins). There may still be a little bit of wiggle room here and there, but any additions will come at the expense of shortening the other discussions. Let Ran and me know if you have any suggestions for changes to the agenda. I plan to upload it 12 hrs from now (this has been up for review for the past 24 hrs, and we received one new request). If you are presenting, please prepare your slides as soon as you can (preferably in the next 2-4 days) and send them to me. I will upload them for general access. Next, if you have any drafts with open issues that you want opinions on, I encourage posting them to the list so we can start discussions. (On a personal level) I will try and post my reviews early next week. thanks and regards, Lakshminath ++++++++++++++++ * MSEC status summary 10 Ran & Lakshminath * AD advise on the quality of MSEC specifications 15 Sam * Update on Russ's action item on hash function agility 15 Lakshminath & Ran * GDOI Update 10 Brian & Sheela draft-weis-gdoi-update * GKDP 10 Sheela, Lakshminath, & Jing draft-ietf-msec-gkdp-01 * MSEC IPsec extensions 15 Brian, Dragan, & George draft-ietf-msec-ipsec-extensions-01 * MIKEY-Applicability discussion 15 Steffen & Dragan draft-fries-msec-mikey-applicability-00 * MIKEY Updates 10 Bob M, & others * ALC/NORM TESLA 10 Vincent draft-faurite-rmt-tesla-for-alc-norm-01 * SRTP-EKT 10 David, Flemming, & Lakshminath draft-mcgrew-srtp-ekt _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Mar 09 03:26:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHGS4-00017s-AS for msec-archive@lists.ietf.org; Thu, 09 Mar 2006 03:24:52 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHGR1-0000dE-S9 for msec-archive@lists.ietf.org; Thu, 09 Mar 2006 03:23:49 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 8D0C82C8EB; Thu, 9 Mar 2006 03:23:47 -0500 (EST) 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 530CC2B914 for ; Thu, 9 Mar 2006 03:23:46 -0500 (EST) Received: (qmail 48739 invoked by uid 3269); 9 Mar 2006 08:23:43 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 48709 invoked from network); 9 Mar 2006 08:23:32 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 9 Mar 2006 08:23:32 -0000 Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) by klesh.pair.com (Postfix) with ESMTP id CE29B6838B for ; Thu, 9 Mar 2006 03:23:27 -0500 (EST) Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k298NDs5025328; Thu, 9 Mar 2006 09:23:13 +0100 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 k298NChF013179; Thu, 9 Mar 2006 09:23:12 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 09:23:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] FW: Submission of draft-lehtovirta-srtp-rcc-01.txt Date: Thu, 9 Mar 2006 09:23:08 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] FW: Submission of draft-lehtovirta-srtp-rcc-01.txt thread-index: AcZB4ycD5XnxkhnGQky0lU4eKpYrMgBbFDUQ From: "Fries, Steffen" To: "Lakshminath Dondeti" , "David McGrew" X-OriginalArrivalTime: 09 Mar 2006 08:23:10.0135 (UTC) FILETIME=[B34F8470:01C64352] Cc: "Blommaert, Marc" , avt@ietf.org, msec@securemulticast.org, "Vesa Lehtovirta (JO/LMF)" , "Jerichow, Anja" , "Rauschenbach, Uwe" 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: 2b3349545af520ba354ccdc9e1a03fc1 Hi Lakshminath, hi Dave, okay, to summarize my thoughts: In a scenario were RCC is used and within a message were SEQ is equal to = 0 modulo some non-zero integer constant R the ROC is transmitted as = ROC_sender || ROC, there may be problems with legacy terminals even if = they get the actual ROC value on a different channel. (Let's assume you = have another channel over which the ROC can be sent. Let's further = assume you can force the legacy terminal to accept and use the received = ROC). The legacy terminal may not be able verify the MAC as it does not use = the correct ROC value for calculation. Even if it has the correct ROC = value available, there are problems as: - if TAG =3D MAC || ROC_sender will lead to the case that the teriminal = will (with a high propability) search for the MAC from the end, thus = interpreting the ROC_sender and a part of the MAC as the actual MAC. The = result will be different than the transmitted MAC. - if TAG =3D ROC_sender || MAC would be fine in finding the MAC from the = end BUT, in both cases, the terminal would calculate the MAC value according = to the RFC3711 integrity transform using the authenticated portion || = local ROC value. The authenticated portion would comprise more than the = data actually expected for the integrity transform. Thus, in both of the = above cases the terminal would calculate the wrong MAC for this = dedicated message.=20 After that packet failed all further packets should be verified = correctly, until the nect RCC packet is received. Does this match your = point of view as well? David, I read you document regarding the ROC synchronization. I like the = idea of the heuristic approach as I think the method is easy to = implement and may also have acceptable influence on speech clipping. The = method itself may be succeptable to some kind of DoS atacks, were an = adversary sends forged packets to the RTP port, were SRTP data is = expected to be received. As the receiver is not able to verify the = received packets without having the right ROC, it may stay = desynchronized, when the ROC iteration is done just once per packet. But = even if ROC iteration is done on a single packet, it may be the one = received from the adversary. (I'm not sure about the applicability of = this attack.) Regards Steffen > -----Original Message----- > From: msec-bounces@securemulticast.org=20 > [mailto:msec-bounces@securemulticast.org] On Behalf Of=20 > Lakshminath Dondeti > Sent: Tuesday, March 07, 2006 1:31 PM > To: Fries, Steffen; David McGrew > Cc: Jerichow, Anja; Rauschenbach, Uwe; avt@ietf.org; Vesa=20 > Lehtovirta (JO/LMF); msec@securemulticast.org > Subject: RE: [MSEC] FW: Submission of draft-lehtovirta-srtp-rcc-01.txt >=20 > At 06:57 AM 3/6/2006, Fries, Steffen wrote: > >Hi David, > > > >aggreed, backward compatibility would be hard if not impossible. > > > >The assumption was (as far as I understood the DVB scenario), that=20 > >there is some out of band means to provide the ROC information. The=20 > >assumption was further that this ROC would be accepted by SRTP for=20 > >processing. According to the draft the MAC calculation itself is the=20 > >same as in RFC3711, so this should not pose a problem. The=20 > only thing=20 > >would be the acceptance of the new ROC. >=20 > Hi Steffen, >=20 > A couple of notes. First, as I noted before I share the=20 > backward compatibility issues that David raised. It might be=20 > worthwhile to see if there is a way to signal things to help=20 > legacy terminals. >=20 > Next, the RCC draft does specify a different way of computing=20 > the MAC. 3711 refers to using the locally maintained ROC to=20 > compute the MAC. In RCC and in EKT there is a "trial" phase=20 > where the received ROC is used to derive the integrity key=20 > and that key is used for MAC verification. If that succeeds,=20 > the received ROC replaces the local ROC and everything=20 > proceeds from there. If the verification fails of course,=20 > the received ROC and the packet are discarded. >=20 > regards, > Lakshminath >=20 >=20 > >Regards > > Steffen > >=20 > > > > > > > -----Original Message----- > > > From: msec-bounces@securemulticast.org > > > [mailto:msec-bounces@securemulticast.org] On Behalf Of=20 > David McGrew > > > Sent: Monday, March 06, 2006 3:46 PM > > > To: Fries, Steffen > > > Cc: avt@ietf.org; Rauschenbach, Uwe; Vesa Lehtovirta > > > (JO/LMF); Jerichow, Anja; msec@securemulticast.org > > > Subject: Re: [MSEC] FW: Submission of=20 > draft-lehtovirta-srtp-rcc-01.txt > > > > > > Hi Steffen, > > > > > > On Mar 6, 2006, at 1:43 AM, Fries, Steffen wrote: > > > > > > > Hi Lakshminath, > > > > > > > > the reason for asking that question is the following=20 > scenario. (It > > > > stems from discusssions regarding OMA and DVB). If you have > > > a device, > > > > that currently supports SRTP and gets the session parameter > > > by other > > > > means (other than MIKEY od sedescriptions) you may=20 > break backward > > > > compatibility with those devices while changing the MAC=20 > position. > > > > > > > > If one can ensure that the device gets the right ROC (the > > > righ one is > > > > the one, which would be submitted in the RCC packet) by > > > other means, > > > > and the device does not now about the new integrity > > > transform (because > > > > it is a parameter which is fixed), then the device=20 > could verify the > > > > MAC even so it is not aware of a new integrity transform. > > > As far as I > > > > understood the scenario it would keep current DVB=20 > devices working. > > > > > > > > On the other hand, this approach would assume that all "legacy" > > > > terminals use the same algorithm to find the MAC in the=20 > message. In > > > > the scenario described above, it would make a difference if > > > one starts > > > > from the beginning or the end of a packet to search for the > > > MAC. But > > > > as you said, the same problem would arise for the=20 > legacy terminals > > > > when using EKT, as it adds after the MAC. > > > > > > > > Hm, it seams that backward compatibility is getting tough > > > ... maybe it > > > > is worth to ask SRTP implementers, what the most used=20 > algorithm for > > > > finding the MAC is. > > > > > > I suspect that they do it like this: > > > > > > auth_tag =3D (uint8_t *)hdr + *pkt_octet_len - tag_len; > > > > > > where auth_tag is the initial octet of the tag, hdr is a > > > pointer to the start of the RTP header, *pkt_octet_len is the > > > length of the RTP packet in bytes, and tag_len is the > > > expected tag length for that packet (which is predictable > > > because the particular MAC that is being used is determined > > > by the SSRC and the session particulars). > > > > > > I'm a bit confused on how RCC could ever achieve backwards > > > compatibility, though. A "legacy" SRTP implementation would > > > need to know how to correctly verify the MAC and would need > > > to know to > > > discard the ROC value rather than to pass it to the RTP layer. > > > Alternately, the RTP layer could discard the ROC value, but > > > legacy RTP implementations won't do this. Also, there is the > > > major issue that in RCC only selected packets will be > > > authenticated; I don't see any way to make that work. > > > > > > David > > > > > > > > > > > Regards > > > > Steffen > > > > > > > >> -----Original Message----- > > > >> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > > > >> Sent: Saturday, March 04, 2006 12:54 AM > > > >> To: Fries, Steffen; Vesa Lehtovirta (JO/LMF); > > > >> msec@securemulticast.org; avt@ietf.org > > > >> Cc: Jerichow, Anja; Rauschenbach, Uwe > > > >> Subject: RE: [MSEC] FW: Submission of draft-lehtovirta-srtp- > > > >> rcc-01.txt > > > >> > > > >> Hi Steffen, > > > >> > > > >> Just some thoughts on this as WG contributor: > > > >> > > > >> RCC would be signalled as a new MAC algorithm anyway and > > > that would > > > >> imply that receivers that don't understand the new MAC > > > construction > > > >> would need to decide against joining the secure group. > > > Furthermore, > > > >> if I recall the semantics correctly, the received ROC=20 > and not the > > > >> stored ROC would be used in the MAC verification process. > > > >> > > > >> For those reasons, I don't think the proposed construction is a > > > >> problem. Your proposal is also ok. I guess one way to > > > look at it is > > > >> if R is sufficiently high (i.e., RCC packets are infrequent), > > > >> receivers that don't support the new extension can also > > > listen in as > > > >> long as the key management semantics are revised to allow that. > > > >> > > > >> That said, once again if memory serves me the reason for > > > the current > > > >> design of RCC is to have the MAC at the end. The EKT work > > > adds new > > > >> payloads at the end, however. > > > >> > > > >> In conclusion, I think if the RCC extension is to=20 > support what you > > > >> propose, we may need to specify the RCC extension to=20 > keep the MAC > > > >> algorithm the same and signal the extension differently. > > > >> > > > >> regards, > > > >> Lakshminath > > > >> > > > >> At 07:28 AM 3/3/2006, Fries, Steffen wrote: > > > >>> Hi Vesa, > > > >>> > > > >>> I just read your draft regarding the SRTP/MIKEY extension. > > > >> It is a good > > > >>> enhancement to transmit the ROC in parts pof the SRTP payload. > > > >>> Nevertheless, I have a comment/question to the transform > > > >> described in > > > >>> section 2. It is stated that TAG =3D ROC_sender || MAC.=20 > What is the > > > >>> reason that the TAG is constructed in that way, rather than > > > >> TAG =3D MAC > > > >>> || ROC_sender? > > > >>> > > > >>>> From my point of view there is an advantage > > > >>> for the latter case. This approach would provide a better > > > backward > > > >>> compatibility for terminals which are not aware of the SRTP > > > >> extension > > > >>> you are describing. If they get the ROC information by > > > other means > > > >>> (e.g., seperate > > > >>> messages) there still would be able to handle the MAC > > > verification > > > >>> correctly, as the MAC starts at the same position as=20 > described in > > > >>> RFC3711. When inserting the ROC before the MAC in the > > > packet, older > > > >>> terminaly would take a part of the ROC as MAC, which > > > would lead to > > > >>> errors in the MAC verification. > > > >>> > > > >>> Would it influence the security in any way by choosing the > > > >> TAG =3D MAC || > > > >>> ROC_sender? > > > >>> > > > >>> Regards > > > >>> Steffen > > > >>> > > > >>> > > > >>> > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: msec-bounces@securemulticast.org > > > >>>> [mailto:msec-bounces@securemulticast.org] On Behalf Of Vesa > > > >>>> Lehtovirta (JO/LMF) > > > >>>> Sent: Tuesday, February 14, 2006 3:31 PM > > > >>>> To: msec@securemulticast.org; avt@ietf.org > > > >>>> Cc: Magnus Westerlund (KI/EAB) > > > >>>> Subject: [MSEC] FW: Submission of > > > draft-lehtovirta-srtp-rcc-01.txt > > > >>>> > > > >>>> Dear all, > > > >>>> > > > >>>> Forwarding on behalf of Karl. > > > >>>> > > > >>>> -----Original Message----- > > > >>>> From: Karl Norrman (KI/EAB) > > > >>>> Sent: 13. helmikuuta 2006 18:04 > > > >>>> To: internet-drafts@ietf.org > > > >>>> Cc: Vesa Lehtovirta (JO/LMF); Mats N=E4slund (KI/EAB) > > > >>>> Subject: Submission of draft-lehtovirta-srtp-rcc-01.txt > > > >>>> > > > >>>> Dear Editor, > > > >>>> > > > >>>> Please submit the new version of > > > draft-lehtovirta-srtp-rcc-01.txt. > > > >>>> > > > >>>> Best Regards, > > > >>>> Karl Norrman > > > >>>> Ericsson > > > >>>> > > > >>> _______________________________________________ > > > >>> 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 > > > _______________________________________________ > > > 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 >=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 Mar 09 17:03:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHTDr-0001BX-04 for msec-archive@lists.ietf.org; Thu, 09 Mar 2006 17:03:03 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHTDp-0000tc-KL for msec-archive@lists.ietf.org; Thu, 09 Mar 2006 17:03:02 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C34DB2CA5E; Thu, 9 Mar 2006 17:03:00 -0500 (EST) 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 26AB82CA55 for ; Thu, 9 Mar 2006 17:03:00 -0500 (EST) Received: (qmail 32602 invoked by uid 3269); 9 Mar 2006 22:03:00 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 32599 invoked from network); 9 Mar 2006 22:03:00 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 9 Mar 2006 22:03:00 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id D17E868377 for ; Thu, 9 Mar 2006 17:02:59 -0500 (EST) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k29M2uIM010989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 9 Mar 2006 14:02:58 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-77-222.qualcomm.com [10.50.77.222]) by sabrina.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k29M2qOR024074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 9 Mar 2006 14:02:55 -0800 (PST) Message-Id: <6.2.5.6.2.20060309140013.03bd5b98@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 09 Mar 2006 14:02:57 -0800 To: msec@securemulticast.org From: Lakshminath Dondeti In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Re: I-D ACTION:draft-ietf-msec-gkdp-01.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: 10d3e4e3c32e363f129e380e644649be Folks, FYI. The GKDP I-D is still a *major* work in progress. We hope to make available a cleaned up version some time next week. So, please hold off any reviews until you see that version. Thanks for your patience. best regards, Lakshminath At 12:50 PM 3/9/2006, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Multicast Security Working Group of the IETF. > > Title : GKDP: Group Key Distribution Protocol > Author(s) : L. Dondeti, et al. > Filename : draft-ietf-msec-gkdp-01.txt > Pages : 16 > Date : 2006-3-9 > >This document specifies a group key distribution protocol (GKDP) > based on IKEv2, the IPsec key management protocol; the new protocol > is similar to IKEv2 in message and payload formats, and message > semantics to a large extent. The protocol in conformance with MSEC > key management architecture contains two components: member > registration and group rekeying, and downloads a group security > association from the GCKS to a member. This protocol is independent > of IKEv2 except in its likeness. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-msec-gkdp-01.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-gkdp-01.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-msec-gkdp-01.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > >Content-Type: text/plain >Content-ID: <2006-3-9141558.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-msec-gkdp-01.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 Mar 10 16:52:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHpWr-0002yP-4B for msec-archive@lists.ietf.org; Fri, 10 Mar 2006 16:52:09 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHpWp-0000ki-ST for msec-archive@lists.ietf.org; Fri, 10 Mar 2006 16:52:09 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 9BD162C432; Fri, 10 Mar 2006 16:52:07 -0500 (EST) 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 E027B2C345 for ; Fri, 10 Mar 2006 16:52:06 -0500 (EST) Received: (qmail 17718 invoked by uid 3269); 10 Mar 2006 21:52:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 17715 invoked from network); 10 Mar 2006 21:52:06 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 10 Mar 2006 21:52:06 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id 7944068388 for ; Fri, 10 Mar 2006 16:52:06 -0500 (EST) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k2ALq4IM003651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 10 Mar 2006 13:52:04 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-77-51.qualcomm.com [10.50.77.51]) by sabrina.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2ALq1nl009491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 10 Mar 2006 13:52:03 -0800 (PST) Message-Id: <6.2.5.6.2.20060310134916.03dfb500@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 10 Mar 2006 13:51:59 -0800 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Agenda and a few presentations uploaded 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: 856eb5f76e7a34990d1d457d8e8e5b7f Hi all, Please visit the meeting materials page of IETF-65 https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65 I have uploaded the agenda and Steffen's and Vincent's presentations on MIKEY applicability and TESLA for ALC and NORM. Thanks Steffen and Vincent for being the early birds :-). Please keep the presentations coming. thanks and regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Mar 13 11:53:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIqIZ-0005aZ-Tl for msec-archive@lists.ietf.org; Mon, 13 Mar 2006 11:53:35 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIqIY-0004U3-Hm for msec-archive@lists.ietf.org; Mon, 13 Mar 2006 11:53:35 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 267302C800; Mon, 13 Mar 2006 11:53:34 -0500 (EST) 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 414CD2C7CA for ; Mon, 13 Mar 2006 11:53:32 -0500 (EST) Received: (qmail 25765 invoked by uid 3269); 13 Mar 2006 16:53:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 25762 invoked from network); 13 Mar 2006 16:53:31 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 13 Mar 2006 16:53:31 -0000 Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.197]) by klesh.pair.com (Postfix) with ESMTP id 0BA9668377 for ; Mon, 13 Mar 2006 11:53:30 -0500 (EST) Received: by nproxy.gmail.com with SMTP id k26so253714nfc for ; Mon, 13 Mar 2006 08:53:26 -0800 (PST) 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=HXZN/N9rAmLsHO/GdORxfw3I/mY0OaaZqhSOYFqcWxXwO8VKf5KtilseA02ifCzjSVkYBGQqsQ4Pt0r6+OjYYW8zxIKVHYK4144zVd4aSzS4wm9Axe1NrpmEf1i6pNvnZx4wC+nsUOL+kuod6glhdsZgUPvAE2rntG6rnx+3ows= Received: by 10.48.242.20 with SMTP id p20mr1031338nfh; Mon, 13 Mar 2006 08:53:26 -0800 (PST) Received: by 10.49.57.16 with HTTP; Mon, 13 Mar 2006 08:53:26 -0800 (PST) Message-ID: <4166af450603130853x10537671x4ae64a1b95a3b6b@mail.gmail.com> Date: Mon, 13 Mar 2006 16:53:26 +0000 From: "Prashant Pilllai" To: msec@securemulticast.org MIME-Version: 1.0 Subject: [MSEC] MSEC and IGMP 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="===============0951773035==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.5 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 --===============0951773035== Content-Type: multipart/alternative; boundary="----=_Part_3085_32190454.1142268806386" ------=_Part_3085_32190454.1142268806386 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi All I would be grateful if someone could please clear some of my doubts. - What is the trigger for GDOI or GSAKMP? - As far as I can understand the documents, these protocols do not interact with IGMP at all. So basically a user can still send an IGMP join to connec= t to the multicast session, and the router will forward all the multicast traffic to thi user. But this user will have to first get the keys for this sesion so will have to use GDOI/GSAKMP to authenticate itself to the GCKS t= o get valid keys to actually decode the traffic. Am I correct in saying this? - So MSEC does not really offer any mechanism to provide network access control. - Can GDOI be used in a distributes architecture? What protocol is used fo= r multiple GCKS to interact with each other? Regards Prashant Pillai ------=_Part_3085_32190454.1142268806386 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi All
 
I would be grateful if someone could please clear some of my doubts.
 
- What is the trigger for GDOI or GSAKMP?
 
- As far as I can understand the documents, these protocols do not int= eract with IGMP at all. So basically a user can still send an IGMP joi= n to connect to the multicast session, and the router will forward all the = multicast traffic to thi user. But this user will have to first get the key= s for this sesion so will have to use GDOI/GSAKMP to authenticate itself to= the GCKS to get valid keys to actually decode the traffic. Am I corre= ct in saying this? =20
 
- So MSEC does not really offer any mechanism to provide network acces= s control.
 
- Can GDOI  be used in a distributes architecture? What protocol = is used for multiple GCKS to interact with each other?
 
 
Regards
Prashant Pillai
------=_Part_3085_32190454.1142268806386-- --===============0951773035== 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 --===============0951773035==-- From msec-bounces@securemulticast.org Mon Mar 13 12:11:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIqZX-0001mT-2w for msec-archive@lists.ietf.org; Mon, 13 Mar 2006 12:11:07 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIqZV-0005Gn-MZ for msec-archive@lists.ietf.org; Mon, 13 Mar 2006 12:11:07 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 6F0032C77C; Mon, 13 Mar 2006 12:11:05 -0500 (EST) 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 AD4702C747 for ; Mon, 13 Mar 2006 12:11:03 -0500 (EST) Received: (qmail 32054 invoked by uid 3269); 13 Mar 2006 17:11:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 32051 invoked from network); 13 Mar 2006 17:11:03 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 13 Mar 2006 17:11:03 -0000 Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by klesh.pair.com (Postfix) with ESMTP id 3C76368377 for ; Mon, 13 Mar 2006 12:11:03 -0500 (EST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id k2DHB0Pu031622; Mon, 13 Mar 2006 11:11:00 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id k2DHAxvS010567; Mon, 13 Mar 2006 11:11:00 -0600 Received: from [157.185.81.177] ([157.185.81.177]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Mar 2006 12:10:59 -0500 In-Reply-To: <4166af450603130853x10537671x4ae64a1b95a3b6b@mail.gmail.com> References: <4166af450603130853x10537671x4ae64a1b95a3b6b@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <5a4323b9f1a549756d1a5d5c4cac70c7@sparta.com> Content-Transfer-Encoding: quoted-printable From: Hugh Harney Subject: Re: [MSEC] MSEC and IGMP Date: Mon, 13 Mar 2006 12:11:04 -0500 To: "Prashant Pilllai" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 13 Mar 2006 17:10:59.0714 (UTC) FILETIME=[1980C620:01C646C1] 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: f607d15ccc2bc4eaf3ade8ffa8af02a0 Hi Prashant, GSAKMP was designed to work in a distributed control architecture. It=20 does not provide network access control as you pointed out. It does=20 supply key to support various uses, one of which could be network=20 access control. GSAKMP uses notification messages to communicate state information=20 within a group. We did not provide any protocol to communicate between=20= groups. Hugh On Mar 13, 2006, at 11:53 AM, Prashant Pilllai wrote: > Hi All > =A0 > I would be grateful if someone could please clear some of my doubts. > =A0 > - What is the trigger for=A0GDOI or GSAKMP? > =A0 > - As far as I can understand the documents, these protocols do not=20 > interact with IGMP at all. So basically a user can still send an=A0IGMP=20= > join to connect to the multicast session, and the router will forward=20= > all the multicast traffic to thi user. But this user will have to=20 > first get the keys for this sesion so will have to use GDOI/GSAKMP to=20= > authenticate itself to the GCKS to get valid keys to actually decode=20= > the traffic.=A0Am I correct in saying this?=A0 > =A0 > - So MSEC does not really offer any mechanism to provide network=20 > access control. > =A0 > - Can GDOI=A0 be used in a distributes architecture? What protocol is=20= > used for multiple GCKS to interact with each other? > =A0 > =A0 > Regards > Prashant Pillai_______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > Hugh Harney Sparta, = Inc. hh@sparta.com 7075 Samuel = Morse Drive (410) 872-1515 x203 Columbia, MD, = 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Mar 13 13:08:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIrSm-0008Pg-Px for msec-archive@lists.ietf.org; Mon, 13 Mar 2006 13:08:12 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIrSl-0007Rz-Gu for msec-archive@lists.ietf.org; Mon, 13 Mar 2006 13:08:12 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 31C252BCE5; Mon, 13 Mar 2006 13:08:11 -0500 (EST) 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 4DA352BBA9 for ; Mon, 13 Mar 2006 13:08:10 -0500 (EST) Received: (qmail 45878 invoked by uid 3269); 13 Mar 2006 18:08:10 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 45875 invoked from network); 13 Mar 2006 18:08:10 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 13 Mar 2006 18:08:10 -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 78E786839D for ; Mon, 13 Mar 2006 13:08:09 -0500 (EST) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 13 Mar 2006 10:08:10 -0800 X-IronPort-AV: i="4.02,187,1139212800"; d="scan'208"; a="1784472502:sNHT31980016" Received: from [10.32.244.214] (stealth-10-32-244-214.cisco.com [10.32.244.214]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2DI871j026703; Mon, 13 Mar 2006 10:08:08 -0800 (PST) Message-ID: <4415B50A.2070306@cisco.com> Date: Mon, 13 Mar 2006 10:08:10 -0800 From: Brian Weis User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Prashant Pilllai Subject: Re: [MSEC] MSEC and IGMP References: <4166af450603130853x10537671x4ae64a1b95a3b6b@mail.gmail.com> In-Reply-To: <4166af450603130853x10537671x4ae64a1b95a3b6b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 41c17b4b16d1eedaa8395c26e9a251c4 Hi Prashant, Prashant Pilllai wrote: > Hi All > > I would be grateful if someone could please clear some of my doubts. > > - What is the trigger for GDOI or GSAKMP? The trigger is implementation specific. If could be a static policy defined on the group members, or it could be the result of receiving an SDP advertisement or some other more dynamic method. (Note that no standard method of describing how a device should contact a key server has been defined in the MSEC WG.) > - As far as I can understand the documents, these protocols do not > interact with IGMP at all. So basically a user can still send an IGMP > join to connect to the multicast session, and the router will forward > all the multicast traffic to thi user. But this user will have to first > get the keys for this sesion so will have to use GDOI/GSAKMP to > authenticate itself to the GCKS to get valid keys to actually decode the > traffic. Am I correct in saying this? That is correct, and it was done intentionally. The MSEC Architecture (RFC 3740) describes a method of securing IP multicast data packets only. It does not have any dependency on a network admission protocol (e.g., IGMP) or multicast routing protocol (e.g., PIM) outside of their normal functions. > - So MSEC does not really offer any mechanism to provide network access > control. That is correct. There has been a lot of debate in the IETF over whether the network admission protocol is the right protocol to enforce joining a secured group. IGMP is a L3 protocol by which a host asks to join a L3 multicast group. Mechanisms to "control" that network admission process due to user credentials (which is what people usually want to do) using higher level protocols is seen by many as a layer violation. > - Can GDOI be used in a distributes architecture? What protocol is used > for multiple GCKS to interact with each other? It could be used in a distributed architecture, but no such protocol has been defined in the MSEC WG. Brian > Regards > Prashant Pillai > > > ------------------------------------------------------------------------ > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec -- 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 Tue Mar 14 06:23:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ7co-0003tm-Qj for msec-archive@lists.ietf.org; Tue, 14 Mar 2006 06:23:38 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ7cn-0005zT-Eo for msec-archive@lists.ietf.org; Tue, 14 Mar 2006 06:23:38 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 02AFB2C7C2; Tue, 14 Mar 2006 06:23:37 -0500 (EST) 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 6953E2BB20 for ; Tue, 14 Mar 2006 06:23:35 -0500 (EST) Received: (qmail 11887 invoked by uid 3269); 14 Mar 2006 11:23:35 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 11884 invoked from network); 14 Mar 2006 11:23:35 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 14 Mar 2006 11:23:35 -0000 Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by klesh.pair.com (Postfix) with ESMTP id 254196837D for ; Tue, 14 Mar 2006 06:23:35 -0500 (EST) Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k2EBd2mu022160; Tue, 14 Mar 2006 04:39:02 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k2EBcgVZ023853; Tue, 14 Mar 2006 05:38:42 -0600 (CST) Received: from [10.161.201.67] (zfr01-2067.crm.mot.com [10.161.201.67]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 5F614865980; Tue, 14 Mar 2006 12:23:23 +0100 (CET) Message-ID: <4416A7AA.3030207@motorola.com> Date: Tue, 14 Mar 2006 12:23:22 +0100 From: Mounir Kellil User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lakshminath Dondeti Subject: Re: [MSEC] Re: I-D ACTION:draft-ietf-msec-gkdp-01.txt References: <6.2.5.6.2.20060309140013.03bd5b98@qualcomm.com> In-Reply-To: <6.2.5.6.2.20060309140013.03bd5b98@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE 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: ff03b0075c3fc728d7d60a15b4ee1ad2 Hi Lakshminath and all, I read the draft, and I have no major comments :-) . Yet, I would like to ask a few general questions regarding some features of the protocol. First, I have noticed that there will be two distinct specifications: GKDP and GDOIv2. So, what would be the key differences between these protocols? Also, is it expected to have a decentralized scheme in GKDP (e.g., extending GSA_Auth_Exch messages, GCKS function delegation through certificates, etc) ? In section 3.2.1, do you expect to address the reliable key delivery (or key recovery) problem for multicast rekeying messages? Finally, would the GCKS discovery problem be handled by GKDP? Some typos: Page 4: GCCKS--> GCKS Page 5: a a random --> a random Page 11: whichTraffic Selector --> which Traffic Selector Regards Mounir Lakshminath Dondeti wrote: > Folks, > > FYI. The GKDP I-D is still a *major* work in progress. We hope to > make available a cleaned up version some time next week. So, please > hold off any reviews until you see that version. Thanks for your > patience. > > best regards, > Lakshminath > > At 12:50 PM 3/9/2006, Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Multicast Security Working Group of >> the IETF. >> >> Title : GKDP: Group Key Distribution Protocol >> Author(s) : L. Dondeti, et al. >> Filename : draft-ietf-msec-gkdp-01.txt >> Pages : 16 >> Date : 2006-3-9 >> >> This document specifies a group key distribution protocol (GKDP) >> based on IKEv2, the IPsec key management protocol; the new protocol >> is similar to IKEv2 in message and payload formats, and message >> semantics to a large extent. The protocol in conformance with MSEC >> key management architecture contains two components: member >> registration and group rekeying, and downloads a group security >> association from the GCKS to a member. This protocol is independent >> of IKEv2 except in its likeness. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-msec-gkdp-01.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-gkdp-01.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-msec-gkdp-01.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail >> readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> Content-Type: text/plain >> Content-ID: <2006-3-9141558.I-D@ietf.org> >> >> ENCODING mime >> FILE /internet-drafts/draft-ietf-msec-gkdp-01.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 > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Mar 15 10:33:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJY05-00072R-1t for msec-archive@lists.ietf.org; Wed, 15 Mar 2006 10:33:25 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJY03-000500-Ig for msec-archive@lists.ietf.org; Wed, 15 Mar 2006 10:33:25 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 543AF2C954; Wed, 15 Mar 2006 10:33:20 -0500 (EST) 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 2A7092C94C for ; Wed, 15 Mar 2006 10:33:19 -0500 (EST) Received: (qmail 65582 invoked by uid 3269); 15 Mar 2006 15:33:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 65579 invoked from network); 15 Mar 2006 15:33:18 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 15 Mar 2006 15:33:18 -0000 Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.205]) by klesh.pair.com (Postfix) with ESMTP id 9DBBF68382 for ; Wed, 15 Mar 2006 10:33:18 -0500 (EST) Received: by nproxy.gmail.com with SMTP id n15so96721nfc for ; Wed, 15 Mar 2006 07:33:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=ffGScyXVzZmn4Be2kEwZWwWPwCkz+pJzvzVoAwdGNVXksXbTm1G8VccflD83IVXdYtJdeWOOkUQvzAHn6cm5FPtuil62X6Meei7riGkCwp8J0oUOzoPZ/cHSUaDI9qzxlx6gwillGaxpnhANVuPHUqwoGgeUiHGY6XljSsyaocw= Received: by 10.48.108.20 with SMTP id g20mr302647nfc; Wed, 15 Mar 2006 07:33:16 -0800 (PST) Received: by 10.49.57.16 with HTTP; Wed, 15 Mar 2006 07:33:16 -0800 (PST) Message-ID: <4166af450603150733m15358f32i93c96b6c061ec52c@mail.gmail.com> Date: Wed, 15 Mar 2006 15:33:16 +0000 From: "Prashant Pillai" To: msec@securemulticast.org Subject: Re: [MSEC] MSEC and IGMP In-Reply-To: <4415B50A.2070306@cisco.com> MIME-Version: 1.0 References: <4166af450603130853x10537671x4ae64a1b95a3b6b@mail.gmail.com> <4415B50A.2070306@cisco.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: , Content-Type: multipart/mixed; boundary="===============1993156150==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 --===============1993156150== Content-Type: multipart/alternative; boundary="----=_Part_5326_16625900.1142436796041" ------=_Part_5326_16625900.1142436796041 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Thanx a lot for answering my previous questions. On reading the different drafts/ and RFC of this WG I am getting really confused with the following: What is the need for so many different protocols (GDOI/ GSAKMP/ MIKEY/ GKDP= ) for securing multicast traffic? They all seem to be doing similar things if not the same. For authors and active members of the group I think it is easy to know, but for people like me who are new to the group or want to adopt a protocol for implementation purposes would not actually know what is used for what? I would be really very grateful if someone could please explain me the differences between these protocols. Prashant Pillai On 3/13/06, Brian Weis wrote: > > Hi Prashant, > > Prashant Pilllai wrote: > > Hi All > > > > I would be grateful if someone could please clear some of my doubts. > > > > - What is the trigger for GDOI or GSAKMP? > > The trigger is implementation specific. If could be a static policy > defined on the group members, or it could be the result of receiving an > SDP advertisement or some other more dynamic method. (Note that no > standard method of describing how a device should contact a key server > has been defined in the MSEC WG.) > > > - As far as I can understand the documents, these protocols do not > > interact with IGMP at all. So basically a user can still send an IGMP > > join to connect to the multicast session, and the router will forward > > all the multicast traffic to thi user. But this user will have to first > > get the keys for this sesion so will have to use GDOI/GSAKMP to > > authenticate itself to the GCKS to get valid keys to actually decode th= e > > traffic. Am I correct in saying this? > > That is correct, and it was done intentionally. The MSEC Architecture > (RFC 3740) describes a method of securing IP multicast data packets > only. It does not have any dependency on a network admission protocol > (e.g., IGMP) or multicast routing protocol (e.g., PIM) outside of their > normal functions. > > > - So MSEC does not really offer any mechanism to provide network access > > control. > > That is correct. There has been a lot of debate in the IETF over whether > the network admission protocol is the right protocol to enforce > joining a secured group. IGMP is a L3 protocol by which a host asks to > join a L3 multicast group. Mechanisms to "control" that network > admission process due to user credentials (which is what people usually > want to do) using higher level protocols is seen by many as a layer > violation. > > > - Can GDOI be used in a distributes architecture? What protocol is use= d > > for multiple GCKS to interact with each other? > > It could be used in a distributed architecture, but no such protocol has > been defined in the MSEC WG. > > Brian > > > Regards > > Prashant Pillai > > > > > > -----------------------------------------------------------------------= - > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://six.pairlist.net/mailman/listinfo/msec > > > -- > Brian Weis > Advanced Security Development, Security Technology Group, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com > ------=_Part_5326_16625900.1142436796041 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi
 
Thanx a lot for answering my previous questions.
 
On reading the different drafts/ and RFC of this WG I am getting = really confused with the following:
 
What is the need for so many different protocols (GDOI/ GSAKMP/ MIKEY/= GKDP) for securing multicast traffic?
 
They all seem to be doing similar things if not the same. For aut= hors and active members of the group I think it is easy to know, but for pe= ople like me who are new to the group or want to adopt a protocol for imple= mentation purposes would not actually know what is used for what?=20
 
I would be really very grateful if someone could please explain me the= differences between these protocols.
 
Prashant Pillai

 
On 3/13/06, = Brian Weis <bew@cisco.com> w= rote:
Hi Prashant,

Prashant Pil= llai wrote:
> Hi All
>
> I would be grateful if someone c= ould please clear some of my doubts.
>
> - What is the trigger for GDOI or GSAKMP?

The trigg= er is implementation specific. If could be a static policy
defined on th= e group members, or it could be the result of receiving an
SDP advertise= ment or some other more dynamic method. (Note that no
standard method of describing how a device should contact a key server<= br>has been defined in the MSEC WG.)

> - As far as I can understa= nd the documents, these protocols do not
> interact with IGMP at all.= So basically a user can still send an IGMP
> join to connect to the multicast session, and the router will forw= ard
> all the multicast traffic to thi user. But this user will have = to first
> get the keys for this sesion so will have to use GDOI/GSAK= MP to
> authenticate itself to the GCKS to get valid keys to actually deco= de the
> traffic. Am I correct in saying this?

That is correct= , and it was done intentionally. The MSEC Architecture
(RFC 3740) descri= bes a method of securing IP multicast data packets
only. It does not have any dependency on a network admission protocol(e.g., IGMP) or multicast routing protocol (e.g., PIM) outside of theirnormal functions.

> - So MSEC does not really offer any mechani= sm to provide network access
> control.

That is correct. There has been a lot of debate in= the IETF over whether
the network admission protocol is the right proto= col to enforce
joining a secured group. IGMP is a L3 protocol by which a= host asks to
join a L3 multicast group. Mechanisms to "control" that netwo= rk
admission process due to user credentials (which is what people usual= ly
want to do) using higher level protocols is seen by many as a layer
violation.

> - Can GDOI  be used in a distributes a= rchitecture? What protocol is used
> for multiple GCKS to interact wi= th each other?

It could be used in a distributed architecture, but n= o such protocol has
been defined in the MSEC WG.

Brian

> Regards
> P= rashant Pillai
>
>
> ------------------------------------= ------------------------------------
>
> ______________________= _________________________
> msec mailing list
> msec@securemulticast.org
> http://six.pairlist.net/mailman/listinfo/msec

--
Brian Weis
Advanced Security Development, Security Technol= ogy Group, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@cisco.com

------=_Part_5326_16625900.1142436796041-- --===============1993156150== 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 --===============1993156150==-- From msec-bounces@securemulticast.org Wed Mar 15 10:47:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJYDR-0005Pp-Dz for msec-archive@lists.ietf.org; Wed, 15 Mar 2006 10:47:13 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJYDQ-0005TE-Q1 for msec-archive@lists.ietf.org; Wed, 15 Mar 2006 10:47:13 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id AB3ED2BB71; Wed, 15 Mar 2006 10:47:12 -0500 (EST) 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 CEEA62B891 for ; Wed, 15 Mar 2006 10:47:11 -0500 (EST) Received: (qmail 68858 invoked by uid 3269); 15 Mar 2006 15:47:11 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 68855 invoked from network); 15 Mar 2006 15:47:11 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 15 Mar 2006 15:47:11 -0000 Received: from 126.com (m5-142.126.com [202.108.5.142]) by klesh.pair.com (Postfix) with SMTP id CBAE468386 for ; Wed, 15 Mar 2006 10:47:10 -0500 (EST) Received: from D8738AFD1B55476 (unknown [202.115.30.191]) by smtp4 (Coremail) with SMTP id wKgAoSfApwf+NhhETefFAA==.4611S2; Wed, 15 Mar 2006 23:47:11 +0800 (CST) Date: Wed, 15 Mar 2006 23:47:18 +0800 From: "Qin Ke" To: "msec" Subject: Re: [MSEC] MSEC and IGMP Organization: UESTC X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-Id: <441836FF.0A22E7.00494> 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="===============0167686828==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 2.3 (++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 --===============0167686828== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksUHJhc2hhbnQgUGlsbGFpOg0KDQpJIGhhdmUgYXNrZWQgdGhlIHNhbWUgcXVlc3Rpb24gYW5k IGZvbGxvd2luZyBpcyBNYXJrIEJhdWdoZXIncyBleHBsYWluOiANCg0KIkdLTVAgaXMgdGhlIGFu Y2VzdG9yIG9mIElFVEYgZ3JvdXAga2V5IG1hbmFnZW1lbnQgcHJvdG9jb2xzLCB3aGljaCBJICAN CnRoaW5rIEh1Z2ggYW5kIG90aGVycyB3b3VsZCBzYXkgaGFzIGJlZW4gc3VwZXJzZWRlZCBieSBH U0FLTVAuICBUaGVyZSAgDQphcmUgYSBudW1iZXIgb2YgZGlmZmVyZW5jZXMsIGJ1dCB0byBtZSBv bmUgb2YgdGhlIG1vc3QgaW1wb3J0YW50ICANCmRpZmZlcmVuY2UgaXMgdGhhdCBHU0FLTVAgc3Vw cG9ydHMgZWZmaWNpZW50IHJldm9jYXRpb24gb2YgcmVjZWl2ZXJzICANCndobyBsZWF2ZSBvciBh cmUgcmVtb3ZlZCBmcm9tIHRoZSBzZWN1cmUgZ3JvdXAuICBHRE9JIGhhcyBhIHN1YnNldCBvZiAg DQp0aGUgZmVhdHVyZXMgb2YgR1NBS01QIGFuZCBpcyBkaXN0aW5ndWlzaGVkIGJ5IHRoZSBmYWN0 IHRoYXQgaXQgdXNlcyAgDQpJU0FLTVAgaGVhZGVycyBhbmQgZXh0ZW5kcyBJS0UgZm9yIGdyb3Vw IHNlY3VyaXR5LiAgIFRoZSBJU0FLTVAgYW5kICANCklLRXYxIHNwZWNpZmljYXRpb25zIGJvdGgg c2FpZCB0aGF0IHRoZWlyIHByb3RvY29scyB3b3VsZCBzdXBwb3J0ICANCmV4dGVuc2lvbiBieSBt ZWFucyBvZiBhICJEb21haW4gb2YgSW50ZXJwcmV0YXRpb24sIiAgaGVuY2UgdGhlIG5hbWUgIA0K Ikdyb3VwIERPSS4iICBQZXJzb25hbGx5LCBJIHRob3VnaHQgSUtFdjEgd2FzIHJlYWxseSBhbiBJ U0FNS1AgRE9JIGFzICANCmlzIEdET0kuICAoSUtFIHYyIGFiYW5kb25lZCB0aGUgRE9JIGNvbmNl cHQuKSAgSSBhbHNvIHRoaW5rIHRoYXQgR0RPSSAgDQphbmQgR1NBS01QIGFyZSBiZXR0ZXIgc3Vp dGVkIHRvIGxhcmdlLXNjYWxlIGJyb2FkY2FzdCwgbXVsdGljYXN0LCBhbmQgIA0KbXVsdGktdW5p Y2FzdDsgYnkgImxhcmdlIHNjYWxlLCIgSSBtZWFuIGh1bmRyZWRzIG9yIG1vcmUuICBMaWtlIHRo ZSAgDQpvdGhlciB0d28sIE1JS0VZIHB1c2hlcyBhIGtleSBhbmQgY2FuIGJlIHVzZWQgZm9yIGdy b3VwcywgYnV0IE1JS0VZICANCmlzIG9wdGltaXplZCAoaS5lLiBtYWtlcyBzZWN1cml0eSB0cmFk ZW9mZnMpIHRvIG1pbmltaXplIHRoZSBtZXNzYWdlICANCmV4Y2hhbmdlIHRvIG9uZSwgdHdvIG9y IHRocmVlIG1lc3NhZ2VzLCB3aGljaCBpcyBjb25zaWRlcmVkIHRvIGJlIGEgIA0KcmVxdWlyZW1l bnQgZm9yIHRlbGVjb25mZXJlbmNpbmcuICBJJ2Qgc2F5IHRoYXQgTUlLRVkgaXMgc3VpdGVkIHRv ICANCnNtYWxsZXIgZ3JvdXBzIHN1Y2ggYXMgYSB0ZWxlY29uZmVyZW5jaW5nIHNlc3Npb24gYXMg b3Bwb3NlZCB0byBhICANCnZpZGVvIGJyb2FkY2FzdC4iCQ0KIA0KoaEJoaGhoaGhoaGhoaGhoaFR aW4gS2UNCqGhoaGhoaGhoaGhoaGhoaF5dXh1YW5xa0AxMjYuY29tDQqhoaGhoaGhoaGhoaGhoaGh oaGhoTIwMDYtMDMtMTUNCg== --===============0167686828== 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 --===============0167686828==-- From msec-bounces@securemulticast.org Wed Mar 15 14:12:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJbQ8-0006RM-22 for msec-archive@lists.ietf.org; Wed, 15 Mar 2006 14:12:32 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJbQ5-0003yI-GI for msec-archive@lists.ietf.org; Wed, 15 Mar 2006 14:12:32 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 184802C79A; Wed, 15 Mar 2006 14:12:29 -0500 (EST) 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 B12EA2C70D for ; Wed, 15 Mar 2006 14:12:27 -0500 (EST) Received: (qmail 8327 invoked by uid 3269); 15 Mar 2006 19:12:27 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 8324 invoked from network); 15 Mar 2006 19:12:27 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 15 Mar 2006 19:12:27 -0000 Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by klesh.pair.com (Postfix) with ESMTP id 5FD356838B for ; Wed, 15 Mar 2006 14:12:26 -0500 (EST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id k2FJCMuJ011927; Wed, 15 Mar 2006 13:12:23 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id k2FJCIix030657; Wed, 15 Mar 2006 13:12:19 -0600 Received: from [157.185.81.177] ([157.185.81.177]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 14:12:17 -0500 In-Reply-To: <4166af450603150733m15358f32i93c96b6c061ec52c@mail.gmail.com> References: <4166af450603130853x10537671x4ae64a1b95a3b6b@mail.gmail.com> <4415B50A.2070306@cisco.com> <4166af450603150733m15358f32i93c96b6c061ec52c@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v623) Message-Id: From: Hugh Harney Subject: Re: [MSEC] MSEC and IGMP Date: Wed, 15 Mar 2006 14:12:16 -0500 To: "Prashant Pillai" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 15 Mar 2006 19:12:17.0680 (UTC) FILETIME=[6055C100:01C64864] 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="===============1864715333==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 55503977758b6a5197d8a2b5141eae86 --===============1864715333== Content-Type: multipart/alternative; boundary=Apple-Mail-2-933979797 --Apple-Mail-2-933979797 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed GSAKMP provides key and cryptographic policy management services for =20 groups, including Many to Many interactions. GSAKMP also provides =20 distributed operation to support global and local management of GMs. On Mar 15, 2006, at 10:33 AM, Prashant Pillai wrote: > Hi > =A0 > Thanx a lot for answering my previous questions. > =A0 > On reading the different drafts/ and RFC of this WG=A0I am getting =20 > really confused with the following: > =A0 > What is the need for so many different protocols (GDOI/ GSAKMP/ MIKEY/ = =20 > GKDP) for securing multicast traffic? > =A0 > They all seem to be doing similar things if not the same. For=A0authors = =20 > and active members of the group I think it is easy to know, but for =20= > people like me who are new to the group or want to adopt a protocol =20= > for implementation purposes would not actually know what is used for =20= > what? > =A0 > I would be really very grateful if someone could please explain me the = =20 > differences between these protocols. > =A0 > Prashant Pillai > > =A0 > On 3/13/06, Brian Weis wrote: Hi Prashant, >> >> Prashant Pilllai wrote: >> > Hi All >> > >> > I would be grateful if someone could please clear some of my = doubts. >> > >> > - What is the trigger for GDOI or GSAKMP? >> >> The trigger is implementation specific. If could be a static policy >> defined on the group members, or it could be the result of receiving =20= >> an >> SDP advertisement or some other more dynamic method. (Note that no >> standard method of describing how a device should contact a key = server >> has been defined in the MSEC WG.) >> >> > - As far as I can understand the documents, these protocols do not >> > interact with IGMP at all. So basically a user can still send an =20= >> IGMP >> > join to connect to the multicast session, and the router will =20 >> forward >> > all the multicast traffic to thi user. But this user will have to =20= >> first >> > get the keys for this sesion so will have to use GDOI/GSAKMP to >> > authenticate itself to the GCKS to get valid keys to actually =20 >> decode the >> > traffic. Am I correct in saying this? >> >> That is correct, and it was done intentionally. The MSEC Architecture >> (RFC 3740) describes a method of securing IP multicast data packets >> only. It does not have any dependency on a network admission protocol >> (e.g., IGMP) or multicast routing protocol (e.g., PIM) outside of =20 >> their >> normal functions. >> >> > - So MSEC does not really offer any mechanism to provide network =20= >> access >> > control. >> >> That is correct. There has been a lot of debate in the IETF over =20 >> whether >> the network admission protocol is the right protocol to enforce >> joining a secured group. IGMP is a L3 protocol by which a host asks = to >> join a L3 multicast group. Mechanisms to "control" that network >> admission process due to user credentials (which is what people =20 >> usually >> want to do) using higher level protocols is seen by many as a layer >> violation. >> >> > - Can GDOI=A0=A0be used in a distributes architecture? What = protocol is =20 >> used >> > for multiple GCKS to interact with each other? >> >> It could be used in a distributed architecture, but no such protocol =20= >> has >> been defined in the MSEC WG. >> >> Brian >> >> > Regards >> > Prashant Pillai >> > >> > >> > =20 >> = ----------------------------------------------------------------------=20= >> -- >> > >> > _______________________________________________ >> > msec mailing list >> > msec@securemulticast.org >> > http://six.pairlist.net/mailman/listinfo/msec >> >> >> -- >> Brian Weis >> Advanced Security Development, Security Technology Group, Cisco =20 >> Systems >> Telephone: +1 408 526 4796 >> Email: bew@cisco.com > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > Hugh Harney Sparta, = Inc. hh@sparta.com 7075 Samuel = Morse Drive (410) 872-1515 x203 Columbia, MD, = 21046 --Apple-Mail-2-933979797 Content-Transfer-Encoding: quoted-printable Content-Type: text/enriched; charset=ISO-8859-1 GSAKMP provides key and cryptographic policy management services for groups, including Many to Many interactions. GSAKMP also provides distributed operation to support global and local management of GMs. On Mar 15, 2006, at 10:33 AM, Prashant Pillai wrote: Hi =A0 Thanx a lot for answering my previous questions. =A0 On reading the different drafts/ and RFC of this WG=A0I am getting really confused with the following: =A0 What is the need for so many different protocols (GDOI/ GSAKMP/ MIKEY/ GKDP) for securing multicast traffic? =A0 They all seem to be doing similar things if not the same. For=A0authors and active members of the group I think it is easy to know, but for people like me who are new to the group or want to adopt a protocol for implementation purposes would not actually know what is used for what? =A0 I would be really very grateful if someone could please explain me the differences between these protocols. =A0 Prashant Pillai =A0 On 3/13/06, Brian Weis <<0000,0000,EEEEbew@cisco.com> wrote: Hi Prashant, Prashant Pilllai wrote: > Hi All > > I would be grateful if someone could please clear some of my doubts.=20= > > - What is the trigger for GDOI or GSAKMP? The trigger is implementation specific. If could be a static policy defined on the group members, or it could be the result of receiving an SDP advertisement or some other more dynamic method. (Note that no=20 standard method of describing how a device should contact a key server has been defined in the MSEC WG.) > - As far as I can understand the documents, these protocols do not > interact with IGMP at all. So basically a user can still send an IGMP=20 > join to connect to the multicast session, and the router will forward > all the multicast traffic to thi user. But this user will have to first > get the keys for this sesion so will have to use GDOI/GSAKMP to=20 > authenticate itself to the GCKS to get valid keys to actually decode the > traffic. Am I correct in saying this? That is correct, and it was done intentionally. The MSEC Architecture (RFC 3740) describes a method of securing IP multicast data packets=20 only. It does not have any dependency on a network admission protocol (e.g., IGMP) or multicast routing protocol (e.g., PIM) outside of their normal functions. > - So MSEC does not really offer any mechanism to provide network access=20 > control. That is correct. There has been a lot of debate in the IETF over whether the network admission protocol is the right protocol to enforce joining a secured group. IGMP is a L3 protocol by which a host asks to=20= join a L3 multicast group. Mechanisms to "control" that network admission process due to user credentials (which is what people usually want to do) using higher level protocols is seen by many as a layer=20 violation. > - Can GDOI=A0=A0be used in a distributes architecture? What protocol = is used > for multiple GCKS to interact with each other? It could be used in a distributed architecture, but no such protocol has=20 been defined in the MSEC WG. Brian > Regards > Prashant Pillai > > > ------------------------------------------------------------------------ > > _______________________________________________ > msec mailing list > 0000,0000,EEEEmsec@securemulticast.org > = 0000,0000,EEEEhttp://six.pairlist.net/mailman/listin= fo/msec -- Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: 0000,0000,EEEEbew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec Hugh Harney = Sparta, Inc. hh@sparta.com 7075 Samuel = Morse Drive (410) 872-1515 x203 Columbia, MD, = 21046 --Apple-Mail-2-933979797-- --===============1864715333== 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 --===============1864715333==-- From msec-bounces@securemulticast.org Thu Mar 16 17:26:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0vX-0004qP-K5 for msec-archive@lists.ietf.org; Thu, 16 Mar 2006 17:26:39 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK0vV-00040N-CM for msec-archive@lists.ietf.org; Thu, 16 Mar 2006 17:26:39 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 297272C9FB; Thu, 16 Mar 2006 17:26:37 -0500 (EST) 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 D476B2C984 for ; Thu, 16 Mar 2006 17:26:35 -0500 (EST) Received: (qmail 73204 invoked by uid 3269); 16 Mar 2006 22:26:35 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 73201 invoked from network); 16 Mar 2006 22:26:35 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 16 Mar 2006 22:26:35 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 40C466837D for ; Thu, 16 Mar 2006 17:26:35 -0500 (EST) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k2GMQWcA018702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 16 Mar 2006 14:26:33 -0800 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by sabrina.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2GMQV5v014699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 16 Mar 2006 14:26:32 -0800 (PST) Message-Id: <6.2.5.6.2.20060316142543.05407b30@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 16 Mar 2006 14:26:30 -0800 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Fwd: Slides for GDOI Update Draft 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: 7bac9cb154eb5790ae3b2913587a40de GDOI update slides have been uploaded to the IETF agenda pages. regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Sat Mar 18 18:16:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKkeT-0007X6-1e for msec-archive@lists.ietf.org; Sat, 18 Mar 2006 18:16:05 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKkeR-0003eP-Pc for msec-archive@lists.ietf.org; Sat, 18 Mar 2006 18:16:05 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 862652C8F1; Sat, 18 Mar 2006 18:16:03 -0500 (EST) 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 6B15E2BB9C for ; Sat, 18 Mar 2006 18:16:02 -0500 (EST) Received: (qmail 40199 invoked by uid 3269); 18 Mar 2006 23:16:02 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 40196 invoked from network); 18 Mar 2006 23:16:02 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 18 Mar 2006 23:16:02 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 24A4F68382 for ; Sat, 18 Mar 2006 18:16:02 -0500 (EST) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k2INFncA001157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 18 Mar 2006 15:15:49 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-68-73.qualcomm.com [10.50.68.73]) by crowley.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2INFlZb029523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 18 Mar 2006 15:15:48 -0800 (PST) Message-Id: <6.2.5.6.2.20060318150634.0396d350@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 X-Priority: 1 (Highest) Date: Sat, 18 Mar 2006 15:15:46 -0800 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Russ Housley , canetti , Sam Hartman Subject: [MSEC] MSEC agenda (proposed revision) 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: fb6060cb60c0cea16e3f7219e40a0a81 Hi all, I am proposing a revision to the agenda so that folks interested in MIKEY and SRTP can participate in the discussion at the RAIarea meeting. I have asked the ADs to move that discussion to the end of the RAIarea meeting so MSEC can plan to finish in about 90 minutes and interested folks can go to the other room! Please review and comment ASAP. I would like to upload the revised version in the next 12-18 hours. thanks and regards, Lakshminath * MSEC status summary 5 (down from 10) Ran & Lakshminath * AD advise on the quality of MSEC specifications 10 (down from 15) Sam * Update on Russ's action item on hash function agility 10 (down from 15) Lakshminath & Ran * GDOI Update 10 Brian & Sheela draft-weis-gdoi-update * GKDP 10 Sheela, Lakshminath, & Jing draft-ietf-msec-gkdp-01 * MSEC IPsec extensions 15 Brian, Dragan, & George draft-ietf-msec-ipsec-extensions-01 * MIKEY-Applicability discussion 10 (down from 15, since the discussion at the RAIarea will also cover this) Steffen & Dragan draft-fries-msec-mikey-applicability-00 * MIKEY Updates 5 (down from 10, same reason as above) Bob M, & others * ALC/NORM TESLA 10 Vincent draft-faurite-rmt-tesla-for-alc-norm-01 * SRTP-EKT 5-10 (this is going to be discussed at the RAIarea and AVT, will talk to David about this) David, Flemming, & Lakshminath draft-mcgrew-srtp-ekt About 90-95 min in all, so folks can catch the tail end of the SRTP-MIKEY discussion in the RAIarea meeting. _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Sun Mar 19 11:20:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL0dQ-0001UG-3C for msec-archive@lists.ietf.org; Sun, 19 Mar 2006 11:20:04 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL0dO-00085w-S2 for msec-archive@lists.ietf.org; Sun, 19 Mar 2006 11:20:04 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 854312C2BC; Sun, 19 Mar 2006 11:20:02 -0500 (EST) 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 9B0A12C253 for ; Sun, 19 Mar 2006 11:20:00 -0500 (EST) Received: (qmail 23027 invoked by uid 3269); 19 Mar 2006 16:20:00 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 23024 invoked from network); 19 Mar 2006 16:20:00 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 19 Mar 2006 16:20:00 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id EB83768377 for ; Sun, 19 Mar 2006 11:19:59 -0500 (EST) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k2JGJscA028853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 19 Mar 2006 08:19:54 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-68-78.qualcomm.com [10.50.68.78]) by crowley.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2JGJmbT007229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 19 Mar 2006 08:19:53 -0800 (PST) Message-Id: <6.2.5.6.2.20060319081755.03ba1530@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 19 Mar 2006 08:19:47 -0800 To: msec@securemulticast.org From: Lakshminath Dondeti In-Reply-To: References: <6.2.5.6.2.20060318150634.0396d350@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Sam Hartman , canetti , Russ Housley Subject: [MSEC] Re: MSEC agenda (proposed revision) 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 Folks, The agenda has been updated based on the comments received so far. Please see the IETF agenda page. Presenters, please send your slides ASAP (that applies to me as well :-))! See you in Dallas. regards, Lakshminath At 07:24 AM 3/19/2006, Sam Hartman wrote: >Please drop my item completely. I can handle it on the mailing list >and there is enough going on I will not have it done in time this >week. _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Mar 20 14:19:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLPuQ-00036B-Ef for msec-archive@lists.ietf.org; Mon, 20 Mar 2006 14:19:18 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLPuP-00079r-7c for msec-archive@lists.ietf.org; Mon, 20 Mar 2006 14:19:18 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C9EA62C743; Mon, 20 Mar 2006 14:19:16 -0500 (EST) 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 664DD2C726 for ; Mon, 20 Mar 2006 14:19:15 -0500 (EST) Received: (qmail 62429 invoked by uid 3269); 20 Mar 2006 19:19:15 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 62426 invoked from network); 20 Mar 2006 19:19:15 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 20 Mar 2006 19:19:15 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id D1AAE683A3 for ; Mon, 20 Mar 2006 14:19:14 -0500 (EST) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k2KJJCex031721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 20 Mar 2006 11:19:12 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-68-225.qualcomm.com [10.50.68.225]) by sabrina.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2KJJ8h1019218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 20 Mar 2006 11:19:11 -0800 (PST) Message-Id: <6.2.5.6.2.20060320111836.03d6a300@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 20 Mar 2006 11:19:10 -0800 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Need note takes for the meeting tomorrow 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: d17f825e43c9aed4fd65b7edddddec89 Hi all, We need two volunteers to take notes at the MSEC meeting tomorrow. thanks and regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Mar 21 10:28:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLimO-000612-Dq for msec-archive@lists.ietf.org; Tue, 21 Mar 2006 10:28:16 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLimN-0003ze-6D for msec-archive@lists.ietf.org; Tue, 21 Mar 2006 10:28:16 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C93802C9AB; Tue, 21 Mar 2006 10:28:13 -0500 (EST) 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 33DDB2C951 for ; Tue, 21 Mar 2006 10:28:02 -0500 (EST) Received: (qmail 3815 invoked by uid 3269); 21 Mar 2006 15:28:02 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 3812 invoked from network); 21 Mar 2006 15:28:02 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 21 Mar 2006 15:28:02 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id 938EB6839D for ; Tue, 21 Mar 2006 10:28:01 -0500 (EST) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k2LFRwpF001585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 21 Mar 2006 07:27:59 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-69-32.qualcomm.com [10.50.69.32]) by neophyte.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2LFRtnw005518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 21 Mar 2006 07:27:57 -0800 (PST) Message-Id: <6.2.5.6.2.20060321072629.03bddd68@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 21 Mar 2006 07:27:55 -0800 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] MSEC status slides are now available 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: de4f315c9369b71d7dd5909b42224370 Folks, I have been swamped with non-MSEC work this meeting and wasn't able to upload the MSEC status slides until just a little while ago. Please review and provide any comments, if you want to see the slides updated before the meeting. Thanks for your patience. regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Mar 21 18:01:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpqp-0008HI-Lb for msec-archive@lists.ietf.org; Tue, 21 Mar 2006 18:01:19 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLpqm-0008SX-Bj for msec-archive@lists.ietf.org; Tue, 21 Mar 2006 18:01:19 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id E4A512C882; Tue, 21 Mar 2006 18:01:15 -0500 (EST) 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 8462C2C7FE for ; Tue, 21 Mar 2006 18:01:14 -0500 (EST) Received: (qmail 91559 invoked by uid 3269); 21 Mar 2006 23:01:14 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 91556 invoked from network); 21 Mar 2006 23:01:14 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 21 Mar 2006 23:01:14 -0000 Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210]) by klesh.pair.com (Postfix) with SMTP id 3657268377 for ; Tue, 21 Mar 2006 18:01:14 -0500 (EST) Received: from nc4010.htt-consult.com ([65.84.78.209]) by htt-consult.com ; Tue, 21 Mar 2006 18:01:45 -0500 Message-Id: <7.0.1.0.2.20060321165652.01f95af0@htt-consult.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 21 Mar 2006 17:01:07 -0600 To: msec@securemulticast.org From: Robert Moskowitz In-Reply-To: <6.2.5.6.2.20060319081755.03ba1530@qualcomm.com> References: <6.2.5.6.2.20060318150634.0396d350@qualcomm.com> <6.2.5.6.2.20060319081755.03ba1530@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Rcpt-To: Subject: [MSEC] A followup thought on my D-H Mikey SRTP proposal 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: 93238566e09e6e262849b4f805833007 There is no reason that this cannot go through the media path. It is just how is validation done. It could be by presenting the SAML certs to the SIP server for validation: SIP1 UA1 UA2 SIP2 <----- MIKEY w SAML/DH ---------> <------UA2 SAML - - UA1 SAML-----------------> --------Valid Y/N -> <------ Valid Y/N ------------ Gee that looks a bit like OCSP..... Robert Moskowitz ICSAlabs/A Division of TruSecure Corporation Security Interest EMail: rgm-sec@htt-consult.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Mar 21 19:14:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLqzc-0004CW-Ar for msec-archive@lists.ietf.org; Tue, 21 Mar 2006 19:14:28 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLqxP-00036C-50 for msec-archive@lists.ietf.org; Tue, 21 Mar 2006 19:12:12 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 9AE162C956; Tue, 21 Mar 2006 19:12:10 -0500 (EST) 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 F088F2C836 for ; Tue, 21 Mar 2006 19:12:08 -0500 (EST) Received: (qmail 3441 invoked by uid 3269); 22 Mar 2006 00:12:09 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 3438 invoked from network); 22 Mar 2006 00:12:09 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 22 Mar 2006 00:12:09 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id BFEE56837D for ; Tue, 21 Mar 2006 19:12:07 -0500 (EST) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k2M0C2ET011027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 21 Mar 2006 16:12:02 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-68-184.qualcomm.com [10.50.68.184]) by sabrina.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2M0Bs6u029209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 21 Mar 2006 16:12:00 -0800 (PST) Message-Id: <6.2.5.6.2.20060321161113.0507f608@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 21 Mar 2006 16:11:54 -0800 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] All presentations are now online 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: d17f825e43c9aed4fd65b7edddddec89 Folks, FYI: the presentations are all online now. regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Mar 23 01:07:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMIyY-00041d-Oo for msec-archive@lists.ietf.org; Thu, 23 Mar 2006 01:07:14 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMIyX-0000ZT-Dg for msec-archive@lists.ietf.org; Thu, 23 Mar 2006 01:07:14 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 827692C6FE; Thu, 23 Mar 2006 01:07:12 -0500 (EST) 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 3374F2C6C1 for ; Thu, 23 Mar 2006 01:07:11 -0500 (EST) Received: (qmail 34546 invoked by uid 3269); 23 Mar 2006 06:07:11 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 34543 invoked from network); 23 Mar 2006 06:07:11 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 23 Mar 2006 06:07:11 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id E101468386 for ; Thu, 23 Mar 2006 01:07:10 -0500 (EST) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k2N678pF023307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 22 Mar 2006 22:07:09 -0800 Received: from LDONDETI.qualcomm.com ([10.50.74.6]) by neophyte.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2N676xg019058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 22 Mar 2006 22:07:08 -0800 (PST) Message-Id: <6.2.5.6.2.20060322220535.03b8c550@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 22 Mar 2006 22:07:02 -0800 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_566706520==_" Subject: [MSEC] Rough draft of minutes from MSEC meeting 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: 32b73d73e8047ed17386f9799119ce43 --=====================_566706520==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Folks, Please review the minutes and send additional notes or revisions to my notes. I'd like to upload them late tomorrow. thanks and regards, Lakshminath --=====================_566706520==_ Content-Type: application/octet-stream; name="msec-ietf-65-minutes.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="msec-ietf-65-minutes.txt" SUVURi02NQpNU0VDIG1lZXRpbmcKTWFyIDIxLCAyMDA2CgpNaW51dGVzIHRha2VuIGJ5OiBMYWtz aG1pbmF0aCBEb25kZXRpCgpHRE9JIFVwZGF0ZSAKLS0tLS0tLS0tLS0KVGhyZWUgcHVycG9zZXM6 IGNsYXJpZmljYXRpb25zLCBhbGdtIGFnaWxpdHkgYW5kIHNlY3VyaXR5IGZpeCAoQ2F0aHkKTWVh ZG93cydzIE1pVE0gYXR0YWNrIG9uIFBPUCBzaWduaW5nKQoKV2UnbGwgaGF2ZSBhIDM1NDdiaXMs IGl0IHNlZW1zIGxpa2UuCgpSYW46IElzIGFsZ20gc2VsZWN0aW9uIGNvbnNpc3RlbnQgKG9yIGlu aGVyaXRlZCkgYmV0d2VlbiBwaGFzZXM/CgpTaGVlbGE6IFllcyB0aGF0J3MgY29ycmVjdC4KClNv bWUgY2hhbmdlcyB0byBTRVEgbnVtYmVycy4gIFNFUSA9MCBmb3IgUGhhc2UgMSBhbmQgU0VRID0g MSBmb3IgUGhhc2UKMiBhbmQgcmVzZXQgdG8gMSBhZnRlciByZWtleQoKVGhlcmUgd2FzIGEgbm90 ZSBhYm91dCBrZXkgZGVyaXZhdGlvbiBhbmQgYSBtaXhpbmcgZnVuY3Rpb24KClJ1c3M6IEZvciBr ZXkgZGVsaXZlcnksIGRvIHlvdSBwbGFuIHRvIHVzZSBBRVMtS1c/ICAKQmVjYXVzZSwgaWYgdGhl IHRoaW5nIHRoYXQncyBlbmNyeXB0ZWQgaXMgYmlnZ2VyIHRoYW4gYSBibG9jayB0aGVyZSdzCmEg cHJvYmxlbQoKQnJpYW4gbGlzdHMgdGhlIEtFSyBhbGdvcml0aG0gY2hvaWNlcyBpbiAzNTQ3LiBL VyBpcyBub3QgY3VycmVudGx5IGEKY2hvaWNlLiAKCiogT24gdGhlIE1lYWRvd3MgYXR0YWNrCgpG aXhlcyBmb3IgTWlUTSBvbiBQT1Agc2lnbmluZyBoYXZlIGJlZW4gYWRkZWQuClRoZSBzb2x1dGlv biBpcyBkaWZmZXJlbnQgZnJvbSB0aGF0IHByb3Bvc2VkIGluIENhdGh5J3MgcGFwZXIuClRoZXJl IGFyZSB0d28gcGFydHMgdG8gdGhlIHByb3Bvc2VkIHNvbHV0aW9uOgpUaGUgZmlyc3QgaXMgYSBt ZW1iZXJzaGlwIHBvbGljeSBjaGVjayBhbmQgdGhlIHNlY29uZCBpcyBhIG1vZGlmaWVkClBPUCBj b25zdHJ1Y3Rpb24uCgpMYWtzaG1pbmF0aDogV2h5IGlzIHRoaXMgZGlmZmVyZW50IGZyb20gd2hh dCdzIGluIENhdGh5J3MgcGFwZXI/CkJyaWFuOiA8bm90ZSB0YWtlciBzdW1tYXJpemluZz4gVG8g a2VlcCB0aGluZ3MgY29uc2lzdGVudCB3aXRoIHRoZQpvcmlnaW5hbCBzaWduYXR1cmUgc3RydWN0 dXJlLgoKTGFrc2htaW5hdGggKGFzIGNvLWNoYWlyKTogUmVxOiBQbGVhc2UgZ2V0IHRoaXMgcmV2 aWV3ZWQgYnkgQ2F0aHkuICBPZgpjb3Vyc2Ugb3RoZXJzIHNob3VsZCByZXZpZXcgdG9vLgoKKiBB ZGRpbmcgQUggc3VwcG9ydC4KCkxha3NobWluYXRoOiBXaHkgaXMgdGhpcyBuZWVkZWQ/CkJyaWFu OiA8c3VtbWFyaXppbmcsIGFmdGVyIGNvbnNpZGVyaW5nLCBFU1AtTlVMTCBldGMuLCBhbmQgcG9s aWN5CmJhc2VkIGNoZWNrcz4gUElNIHNheXMgQUggaXMgYSBNVVNUIGFuZCByZWNhbGwgdGhhdCB3 ZSB1c2UgdHJhbnNwb3J0Cm1vZGUKTGFrc2htaW5hdGggKGFzIGNvLWNoYWlyKTogQ2hlY2sgb24g dGhlIFBJTSByZXF1aXJlbWVudCwgZXNwZWNpYWxseSB0bwpzZWUgaWYgdGhlcmUgYXJlIHBsYW5z IHRvIGNoYW5nZSBpdCBldGMuCgpHS0RQOgotLS0tLQoKdXBkYXRlIGZyb20gTGFrc2htaW5hdGg6 Ck1hZGUgc29tZSBlZmZvcnQgdG8gZmluaXNoIHRoZSB3b3JrIHdpdGggYXV0aG9yIGNvbmYgY2Fs bHMgZXRjLiwgYnV0CndhcyBzdGlsbCB1bmFibGUgdG8gbWFrZSBzaWduaWZpY2FudCBwcm9ncmVz cyAoZmV3ZXIgY3ljbGVzIGZvciB0aGlzCmZvciBMYWtzaG1pbmF0aCkKClNoZWVsYSBwcm92aWRl cyBhbiB1cGRhdGUgb24gUmVrZXkgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBhbmQgRGVsZXRlCm1l c3NhZ2Ugc3BlY2lmaWNhdGlvbi4KClRoZSBhdXRob3JzIHRvIG1ha2UgYSBtb3JlIGNvbmNlcnRl ZCBlZmZvcnQgdG8gbWVldCB0aGUgSnVseQpkZWFkbGluZS4gCgpNU0VDIElQc2VjIGV4dGVuc2lv bnM6Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KU2NvcGluZyBpc3N1ZXMgaGF2ZSBiZWVuIHJlc29s dmVkLgpBZGRpdGlvbnMgdG8gNDMwMTogU0EgZGlyZWN0aW9uYWxpdHkuCkRlZmluaW5nIHJvbGVz IG9mIHRoZSBncm91cCBtZW1iZXJzOiBzZW5kZXIsIEdDS1MgYW5kIHJlY2VpdmVyL21lbWJlcgoK TGFrc2htaW5hdGg6IERvZXMga2V5IG1hbmFnZW1lbnQgbmVlZCB0byBzcGVhayBhYm91dCB0aGlz PwoKSXMgdGhpcyBhIE1VU1Q/ICBXaHkgaXMgaXQgKm5lZWRlZD8gYW5kIHdoeSBjYW4ndCB3ZSBz YXkgU0hPVUxELgoKVGhlIHJlZmVyZW5jZSB0byBjb21wb3NpdGUgZ3JvdXBzIGNhbWUgdXAuCgpS dXNzIG5vdGVzOiBJIGhvcGUgbm90IQoKTGFrc2htaW5hdGggdGhpbmtzIHRoYXQgdGhpcyBzaG91 bGQgYmUgYSBtYWlsaW5nIGxpc3QgZGlzY3Vzc2lvbi4KClRoZSBuZXh0IGlzc3VlIGlzIHdoZW4g dG8gdGFrZSB0aGlzIElQU0VDIG1haWxpbmcgbGlzdAoKQ29uY2x1c2lvbjogUmVzb2x2ZSBvcGVu IGlzc3VlczogQUggYW5kIGRpcmVjdGlvbmFsaXR5CkRvIGEgcXVpY2sgcmV2aXNpb24gYW5kIHNl bmQgdG8gSVBTRUMgbGlzdCBmb3IgcmV2aWV3LgoKUnVzczogVGhhbmtzIHRvIHRoZSBhdXRob3Jz IGZvciBmb2xsb3dpbmcgdXAgb24gbXkgcmVxdWVzdC4KCk1JS0VZIGV4dGVuc2lvbnM6Ci0tLS0t LS0tLS0tLS0tLS0tCgpUaGlzIGRyYWZ0IGRlc2NyaWJlcyB0aGUgdmFyaW91cyBNSUtFWSBtb2Rl cyBhbmQgdXNlIGNhc2VzLiAgVXNlIGNhc2VzCndvcmsgaXMgcGVuZGluZyBzdGlsbCBhbmQgU3Rl ZmZlbiByZXF1ZXN0cyBmb2xrcyB0byBzZW5kIHRoZWlyIHVzZQpjYXNlcy4KCiogTm8gb2JqZWN0 aW9ucyB0byBtYWtpbmcgdGhpcyBhIFdHIGl0ZW0gYXQgdGhlIG1lZXRpbmcuCldlJ2xsIGFzayB0 aGUgcXVlc3Rpb24gb24gdGhlIGxpc3QgYW5kIGNvbmZpcm0uCgpSYW46IHBvc3QgdGhpcyB0byBS QUksIEFWVCBhbmQgTU1VU0lDLgoKTUlLRVktU0FNTDoKLS0tLS0tLS0tLS0KCldoYXQncyBuZXh0 IG9uIHRoaXM/CgpXZSBuZWVkIHRvIHNlZSB0aGUgZHJhZnQgb24gd2hhdCdzIGludm9sdmVkCkJv YiBNIG5vdGVzIHRoYXQgaWYgdGhlcmUgaXMgaW50ZXJlc3QsIHdpbGwgd29yayBvbiBhIGRyYWZ0 LgoKTGFrc2htaW5hdGg6IHdlIG5lZWQgdG8gc2VlIHdoeSB0aGlzIGlzIGJldHRlciB0aGFuIE1J S0VZLURIOyBXZSByZWFsaXplCnRoYXQgdGhpcyB0YWxrcyBhYm91dCBvcGVyYXRpb25hbCBkZXRh aWxzIGV0Yy4KCmFueXdheSwgZW5jb3VyYWdpbmcgQm9iIHRvIHdyaXRlIHRoZSBzcGVjIHRvIGZs ZXNoIG91dCB0aGUgZGV0YWlscy4KCkFMQy9OT1JNLVRFU0xBOgotLS0tLS0tLS0tLS0tLS0KCkJy aWFuIFE6IElzIHRoaXMgbGlrZSBTUlRQLVRFU0xBIGFuZCBJUHNlYy1URVNMQT8KUmFuOiBZZXMK ClE6IGFueSBvYmplY3Rpb24gdG8gZG8gdGhlIHdvcmsgaGVyZQpWaW5jZW50IG5vdGVzIHRoYXQg Uk1UIGhhcyBjb25zZW5zdXMuCgpUb0RvOgpDaGVjayB3aXRoIFJNVCBXRyAKQ2hlY2sgb24gdGhl IGxpc3QgZm9yIGFueSBvYmplY3Rpb25zCgoKCg== --=====================_566706520==_ 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 --=====================_566706520==_-- From msec-bounces@securemulticast.org Thu Mar 23 02:14:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMK1g-0002Xx-Or for msec-archive@lists.ietf.org; Thu, 23 Mar 2006 02:14:32 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMK1f-0003Nz-Fq for msec-archive@lists.ietf.org; Thu, 23 Mar 2006 02:14:32 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 380A52CA10; Thu, 23 Mar 2006 02:14:31 -0500 (EST) 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 801062C9A9 for ; Thu, 23 Mar 2006 02:14:29 -0500 (EST) Received: (qmail 43653 invoked by uid 3269); 23 Mar 2006 07:14:29 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 43650 invoked from network); 23 Mar 2006 07:14:29 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 23 Mar 2006 07:14:29 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id 4187568389 for ; Thu, 23 Mar 2006 02:14:29 -0500 (EST) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k2N7EQpF027559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 22 Mar 2006 23:14:27 -0800 Received: from LDONDETI.qualcomm.com ([10.50.74.6]) by crowley.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2N7EM0N023017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 22 Mar 2006 23:14:25 -0800 (PST) Message-Id: <6.2.5.6.2.20060322221031.03cee5b8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 22 Mar 2006 23:14:32 -0800 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [MSEC] MSEC summary, SAAG report (for review) 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 has done the following since the Vancouver meeting: RFC Published: =96draft-ietf-msec-bootstrapping-tesla (RFC 4442) RFC Ed queue: =96draft-ietf-msec-policy-token-sec -draft-ietf-msec-newtype-keyid WGLC, in progress: -draft-ietf-msec-mikey-rsa-r Want to take this opportunity to thank Russ for=20 being very proactive and being on top of things=20 in helping us move our documents along. On=20 behalf of the MSEC contributors, I appreciate that very much. Meeting update: ----------------- * MSEC IPsec extensions work is almost ready for=20 IPSEC mailing list review. Stay tuned for that. * GDOI (RFC 3547) is being revised. Focused=20 PSrev for algorithm agility, for providing=20 clarifications, to fix a security hole and finally to introduce AH support. * Hash function analysis half-way done. GDOI,=20 TESLA, some MIKEY mode related work is=20 completed. GDOI requires a PSrev and that's=20 being done. GSAKMP and MIKEY reviews are pending. * MIKEY applicability draft is being written to=20 explain the various MIKEY modes and to provide=20 guidance on what modes might be applicable in various use cases. * Some new TESLA related work is being taken up,=20 and the chairs plan to write MSEC roadmap document. * We plan to meet in Montreal and at the next=20 meeting also, and try to finish everything by the end of year. _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Mar 28 05:03:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOB33-0001n4-GJ for msec-archive@lists.ietf.org; Tue, 28 Mar 2006 05:03:37 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOB32-0002Hm-8w for msec-archive@lists.ietf.org; Tue, 28 Mar 2006 05:03:37 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 70CC62C7D0; Tue, 28 Mar 2006 05:03:35 -0500 (EST) 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 D00FA2BAAC for ; Tue, 28 Mar 2006 05:03:33 -0500 (EST) Received: (qmail 66359 invoked by uid 3269); 28 Mar 2006 10:03:33 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 66356 invoked from network); 28 Mar 2006 10:03:33 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 28 Mar 2006 10:03:33 -0000 Received: from lnxos.staff.proxad.net (lnxos.staff.proxad.net [213.228.1.83]) by klesh.pair.com (Postfix) with ESMTP id 8D1EB68367 for ; Tue, 28 Mar 2006 05:03:33 -0500 (EST) Received: from lnxos (lnxos [127.0.0.1]) by lnxos.staff.proxad.net (8.13.4/8.12.10) with ESMTP id k2SA3crS018514 for ; Tue, 28 Mar 2006 12:03:38 +0200 From: Alexandre Cassen To: msec@securemulticast.org Content-Type: text/plain Date: Tue, 28 Mar 2006 12:03:38 +0200 Message-Id: <1143540218.3033.98.camel@lnxos> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit Subject: [MSEC] l-D: Access Right Distribution Protocol (ARDP) 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 Dear msec WG, After advices from IETF members, I would like to pop up msec with a protocol we are currently running on our national TVoDSL backbone. The scope of the document is : This document describes a protocol to securely distribute channel access rights to TVoDSL customers using multicast over a national backbone. The protocol typically runs on DSLAM or any other piece of equipments to locally store owned customers TV channel access right. This design provides access control at edge level. http://www.ietf.org/internet-drafts/draft-cassen-access-right-distribution-protocol-00.txt All comments are welcome. Best regards, Alexandre Cassen Free.fr R&D Lab _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Mar 28 11:13:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOGp4-0002nJ-5M for msec-archive@lists.ietf.org; Tue, 28 Mar 2006 11:13:34 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOGp2-000159-Pz for msec-archive@lists.ietf.org; Tue, 28 Mar 2006 11:13:34 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 363232C9EC; Tue, 28 Mar 2006 11:13:32 -0500 (EST) 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 753842C9B0 for ; Tue, 28 Mar 2006 11:13:30 -0500 (EST) Received: (qmail 32472 invoked by uid 3269); 28 Mar 2006 16:13:30 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 32469 invoked from network); 28 Mar 2006 16:13:30 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 28 Mar 2006 16:13:30 -0000 Received: from ns1.cpanel.btnaccess.com (ns1.cpanel.btnaccess.com [205.177.121.2]) by klesh.pair.com (Postfix) with ESMTP id 4B0176835C for ; Tue, 28 Mar 2006 11:13:30 -0500 (EST) Received: from [65.213.193.6] (helo=ISODELL001) by ns1.cpanel.btnaccess.com with esmtp (Exim 4.52) id 1FOGoy-0001kf-4n for msec@securemulticast.org; Tue, 28 Mar 2006 11:13:28 -0500 From: "Robert Holliday" To: Date: Tue, 28 Mar 2006 11:13:19 -0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcZSgobeRIZ/f8byRUOosNVfUIJf0A== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - securemulticast.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20060328161330.4B0176835C@klesh.pair.com> Subject: [MSEC] ICNS 2006: Early Registration Ends April 1 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="===============1397985999==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 This is a multi-part message in MIME format. --===============1397985999== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01C65258.9FCFC030" This is a multi-part message in MIME format. ------=_NextPart_000_0036_01C65258.9FCFC030 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The International Conference on Network Security 2006, April 17-19, Reston, Virginia Only a few days remain to take advantage of Early Bird Specials when registering for ICNS2006. All those registering before April 1 receive will receive a $200 dollar discount. Don't miss out on the chance to interact with industry leaders in a personal setting and unique format. Technical Program: http://www.isocore.com/networksecurity2006/program.htm Registration: http://www.isocore.com/networksecurity2006/onlineregis.htm Website: http://www.networksecurity2006.com ------=_NextPart_000_0036_01C65258.9FCFC030 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The International Conference on Network Security 2006, April = 17-19, Reston, Virginia

 

Only a few days remain to = take advantage of Early Bird Specials when registering for ICNS2006.  = All those registering before April 1 receive will receive a $200 dollar = discount.  Don’t miss out on the chance to interact with industry leaders in a personal = setting and unique format.

 

Technical = Program: http://ww= w.isocore.com/networksecurity2006/program.htm

 

Registration= : http:= //www.isocore.com/networksecurity2006/onlineregis.htm

 

Website: http://www.networksecurity20= 06.com

 

------=_NextPart_000_0036_01C65258.9FCFC030-- --===============1397985999== 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 --===============1397985999==-- From msec-bounces@securemulticast.org Thu Mar 30 00:07:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOpN6-0007PX-LD for msec-archive@lists.ietf.org; Thu, 30 Mar 2006 00:07:00 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOpN4-0005iR-75 for msec-archive@lists.ietf.org; Thu, 30 Mar 2006 00:07:00 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id CED082CC43; Thu, 30 Mar 2006 00:06:57 -0500 (EST) 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 277E92CC20 for ; Thu, 30 Mar 2006 00:06:56 -0500 (EST) Received: (qmail 83576 invoked by uid 3269); 30 Mar 2006 05:06:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 83571 invoked from network); 30 Mar 2006 05:06:55 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 30 Mar 2006 05:06:55 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id B74FC6835B for ; Thu, 30 Mar 2006 00:06:55 -0500 (EST) 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 k2U56sGX029623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 29 Mar 2006 21:06:54 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-68-219.qualcomm.com [10.50.68.219]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k2U56qxa000661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 29 Mar 2006 21:06:53 -0800 (PST) Message-Id: <6.2.5.6.2.20060329210047.0520eaa0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 29 Mar 2006 21:06:53 -0800 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Fwd: I-D ACTION:draft-ietf-msec-mikey-rsa-r-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: 3a4bc66230659131057bb68ed51598f8 Vesa and Steffen and others, Dragan and I incorporated the changes you requested (please do a diff; I find the tools at tools.ietf.org/wg/msec useful) http://tools.ietf.org/wg/msec/draft-ietf-msec-mikey-rsa-r/draft-ietf-msec-mikey-rsa-r-03-from-02.diff.html Please let us know if the new version is satisfactory. thanks and regards, Lakshminath >To: i-d-announce@ietf.org >From: Internet-Drafts@ietf.org >Date: Wed, 29 Mar 2006 18:50:02 -0500 >X-Spam-Score: 0.3 (/) >X-Scan-Signature: 386e0819b1192672467565a524848168 >Cc: msec@securemulticast.org >Subject: I-D ACTION:draft-ietf-msec-mikey-rsa-r-03.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-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.3.29.153608 >X-OriginalArrivalTime: 29 Mar 2006 23:51:09.0900 (UTC) >FILETIME=[A74C68C0:01C6538B] > >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 : An additional mode of key distribution in > MIKEY: MIKEY-RSA-R > Author(s) : D. Ignjatic, et al. > Filename : draft-ietf-msec-mikey-rsa-r-03.txt > Pages : 17 > Date : 2006-3-29 > >The Multimedia Internet Keying (MIKEY) specification describes >several modes of key distribution solution that addresses multimedia >scenarios (e.g., SIP calls and RTSP sessions) -- using pre-shared >keys, public keys, and optionally a Diffie-Hellman key exchange. In >the public-key mode, the Initiator encrypts a random key with the >Responder's public key and sends it to the Responder. In many >communication scenarios, the Initiator may not know the Responder's >public key, or in some cases the Responder's ID (e.g., call >forwarding) in advance. We propose a new MIKEY mode that works well >in such scenarios. This mode also enhances the group key management >support in MIKEY; it supports member-initiated group key download (in >contrast to group manager pushing the group keys to all members). > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-rsa-r-03.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-mikey-rsa-r-03.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-mikey-rsa-r-03.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-3-29153405.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-msec-mikey-rsa-r-03.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 Thu Mar 30 01:49:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOqy2-0005tY-M9 for msec-archive@lists.ietf.org; Thu, 30 Mar 2006 01:49:14 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOqxa-00029A-Ie for msec-archive@lists.ietf.org; Thu, 30 Mar 2006 01:48:51 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 295AB2CC56; Thu, 30 Mar 2006 01:48:46 -0500 (EST) 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 77CC52CC35 for ; Thu, 30 Mar 2006 01:48:44 -0500 (EST) Received: (qmail 18179 invoked by uid 3269); 30 Mar 2006 06:48:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 18176 invoked from network); 30 Mar 2006 06:48:44 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 30 Mar 2006 06:48:44 -0000 Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) by klesh.pair.com (Postfix) with ESMTP id 040446835C for ; Thu, 30 Mar 2006 01:48:43 -0500 (EST) Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k2U6mXkQ024076; Thu, 30 Mar 2006 08:48:33 +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 k2U6mVrp028410; Thu, 30 Mar 2006 08:48:31 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Mar 2006 08:48:29 +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-ietf-msec-mikey-rsa-r-03.txt Date: Thu, 30 Mar 2006 08:48:28 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] Fwd: I-D ACTION:draft-ietf-msec-mikey-rsa-r-03.txt Thread-Index: AcZTt8mtdxQc0BpCQOOOyhUMH8VALAADGOYg From: "Fries, Steffen" To: "Lakshminath Dondeti" , X-OriginalArrivalTime: 30 Mar 2006 06:48:29.0477 (UTC) FILETIME=[F40CA550:01C653C5] 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: 1449ead51a2ff026dcb23465f5379250 Hi Lakshminath, I just read through the changes. They are fine with me, the draft looks pretty stable now. The adpoption of SHOULD in section 3.2 for " ...The Initiator SHOULD indicate the number of CSs supported, and SHOULD fill in the CS ID map type and CS ID info fields for the RTP/RTCP streams it originates. " is also fine. The resonning is clear now (I suggested MUST originally, but it becomes clear now that a also the responder can chose the SSRC, so SHOUL is okay). Regards Steffen > -----Original Message----- > From: msec-bounces@securemulticast.org=20 > [mailto:msec-bounces@securemulticast.org] On Behalf Of=20 > Lakshminath Dondeti > Sent: Thursday, March 30, 2006 7:07 AM > To: msec@securemulticast.org > Subject: [MSEC] Fwd: I-D ACTION:draft-ietf-msec-mikey-rsa-r-03.txt=20 >=20 > Vesa and Steffen and others, >=20 > Dragan and I incorporated the changes you requested (please=20 > do a diff; I find the tools at tools.ietf.org/wg/msec useful)=20 > http://tools.ietf.org/wg/msec/draft-ietf-msec-mikey-rsa-r/draf > t-ietf-msec-mikey-rsa-r-03-from-02.diff.html >=20 > Please let us know if the new version is satisfactory. >=20 > thanks and regards, > Lakshminath >=20 >=20 > >To: i-d-announce@ietf.org > >From: Internet-Drafts@ietf.org > >Date: Wed, 29 Mar 2006 18:50:02 -0500 > >X-Spam-Score: 0.3 (/) > >X-Scan-Signature: 386e0819b1192672467565a524848168 > >Cc: msec@securemulticast.org > >Subject: I-D ACTION:draft-ietf-msec-mikey-rsa-r-03.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-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.3.29.153608 > >X-OriginalArrivalTime: 29 Mar 2006 23:51:09.0900 (UTC)=20 > >FILETIME=3D[A74C68C0:01C6538B] > > > >A New Internet-Draft is available from the on-line Internet-Drafts=20 > >directories. > >This draft is a work item of the Multicast Security Working=20 > Group of the IETF. > > > > Title : An additional mode of key distribution in=20 > > MIKEY: MIKEY-RSA-R > > Author(s) : D. Ignjatic, et al. > > Filename : draft-ietf-msec-mikey-rsa-r-03.txt > > Pages : 17 > > Date : 2006-3-29 > > > >The Multimedia Internet Keying (MIKEY) specification=20 > describes several=20 > >modes of key distribution solution that addresses multimedia=20 > scenarios=20 > >(e.g., SIP calls and RTSP sessions) -- using pre-shared keys, public=20 > >keys, and optionally a Diffie-Hellman key exchange. In the=20 > public-key=20 > >mode, the Initiator encrypts a random key with the=20 > Responder's public=20 > >key and sends it to the Responder. In many communication scenarios,=20 > >the Initiator may not know the Responder's public key, or in=20 > some cases=20 > >the Responder's ID (e.g., call > >forwarding) in advance. We propose a new MIKEY mode that=20 > works well in=20 > >such scenarios. This mode also enhances the group key management=20 > >support in MIKEY; it supports member-initiated group key=20 > download (in=20 > >contrast to group manager pushing the group keys to all members). > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-rsa > -r-03.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-ietf-msec-mikey-rsa-r-03.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 /internet-drafts/draft-ietf-msec-mikey-rsa-r-03.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-3-29153405.I-D@ietf.org> > > > >ENCODING mime > >FILE /internet-drafts/draft-ietf-msec-mikey-rsa-r-03.txt > > > > > > -r-03.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 Thu Mar 30 10:18:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOyv6-0004Et-Q1 for msec-archive@lists.ietf.org; Thu, 30 Mar 2006 10:18:44 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOyv4-00014I-Bs for msec-archive@lists.ietf.org; Thu, 30 Mar 2006 10:18:44 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 493382CD62; Thu, 30 Mar 2006 10:16:40 -0500 (EST) 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 9AAA62CD1C for ; Thu, 30 Mar 2006 10:16:39 -0500 (EST) Received: (qmail 75377 invoked by uid 3269); 30 Mar 2006 15:16:39 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 75374 invoked from network); 30 Mar 2006 15:16:39 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 30 Mar 2006 15:16:39 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id 2580868389 for ; Thu, 30 Mar 2006 10:16:39 -0500 (EST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k2UFGbYA010784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Mar 2006 07:16:38 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-68-152.qualcomm.com [10.50.68.152]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k2UFGZpH013070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Mar 2006 07:16:36 -0800 (PST) Message-Id: <6.2.5.6.2.20060330071457.04fe9308@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 30 Mar 2006 07:16:34 -0800 To: "Fries, Steffen" , From: Lakshminath Dondeti Subject: RE: [MSEC] Fwd: I-D ACTION:draft-ietf-msec-mikey-rsa-r-03.txt In-Reply-To: References: 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: 202a3ece0492a8c7e7c8672d5214398f Steffen, Yes, indeed we debated the suggestions and finally decided on what's right and provided explanation for the choice (e.g., the MUST vs. SHOULD below). I am glad you interpreted the changes as intended :-). Thanks for your considered review. best regards, Lakshminath At 10:48 PM 3/29/2006, Fries, Steffen wrote: > Hi Lakshminath, > >I just read through the changes. They are fine with me, the draft looks >pretty stable now. >The adpoption of SHOULD in section 3.2 for >" ...The Initiator SHOULD indicate the number of CSs supported, and >SHOULD fill in the CS ID map type and CS ID info fields for the >RTP/RTCP streams it originates. " >is also fine. The resonning is clear now (I suggested MUST originally, >but it becomes clear now that a also the responder can chose the SSRC, >so SHOUL is okay). > >Regards > Steffen > > > -----Original Message----- > > From: msec-bounces@securemulticast.org > > [mailto:msec-bounces@securemulticast.org] On Behalf Of > > Lakshminath Dondeti > > Sent: Thursday, March 30, 2006 7:07 AM > > To: msec@securemulticast.org > > Subject: [MSEC] Fwd: I-D ACTION:draft-ietf-msec-mikey-rsa-r-03.txt > > > > Vesa and Steffen and others, > > > > Dragan and I incorporated the changes you requested (please > > do a diff; I find the tools at tools.ietf.org/wg/msec useful) > > http://tools.ietf.org/wg/msec/draft-ietf-msec-mikey-rsa-r/draf > > t-ietf-msec-mikey-rsa-r-03-from-02.diff.html > > > > Please let us know if the new version is satisfactory. > > > > thanks and regards, > > Lakshminath > > > > > > >To: i-d-announce@ietf.org > > >From: Internet-Drafts@ietf.org > > >Date: Wed, 29 Mar 2006 18:50:02 -0500 > > >X-Spam-Score: 0.3 (/) > > >X-Scan-Signature: 386e0819b1192672467565a524848168 > > >Cc: msec@securemulticast.org > > >Subject: I-D ACTION:draft-ietf-msec-mikey-rsa-r-03.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-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.3.29.153608 > > >X-OriginalArrivalTime: 29 Mar 2006 23:51:09.0900 (UTC) > > >FILETIME=[A74C68C0:01C6538B] > > > > > >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 : An additional mode of key distribution in > > > MIKEY: MIKEY-RSA-R > > > Author(s) : D. Ignjatic, et al. > > > Filename : draft-ietf-msec-mikey-rsa-r-03.txt > > > Pages : 17 > > > Date : 2006-3-29 > > > > > >The Multimedia Internet Keying (MIKEY) specification > > describes several > > >modes of key distribution solution that addresses multimedia > > scenarios > > >(e.g., SIP calls and RTSP sessions) -- using pre-shared keys, public > > >keys, and optionally a Diffie-Hellman key exchange. In the > > public-key > > >mode, the Initiator encrypts a random key with the > > Responder's public > > >key and sends it to the Responder. In many communication scenarios, > > >the Initiator may not know the Responder's public key, or in > > some cases > > >the Responder's ID (e.g., call > > >forwarding) in advance. We propose a new MIKEY mode that > > works well in > > >such scenarios. This mode also enhances the group key management > > >support in MIKEY; it supports member-initiated group key > > download (in > > >contrast to group manager pushing the group keys to all members). > > > > > >A URL for this Internet-Draft is: > > >http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-rsa > > -r-03.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-mikey-rsa-r-03.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-mikey-rsa-r-03.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-3-29153405.I-D@ietf.org> > > > > > >ENCODING mime > > >FILE /internet-drafts/draft-ietf-msec-mikey-rsa-r-03.txt > > > > > > > > > -r-03.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 > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec