From mailman-bounces@six.pairlist.net Fri Oct 1 05:03:37 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08109 for ; Fri, 1 Oct 2004 05:03:37 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 2B5E38CA38 for ; Fri, 1 Oct 2004 05:03:36 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: securemulticast.org mailing list memberships reminder From: mailman-owner@securemulticast.org To: msec-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Oct 2004 05:01:31 -0400 Precedence: bulk X-BeenThere: mailman@six.pairlist.net X-Mailman-Version: 2.1.5 List-Id: mailman.six.pairlist.net X-List-Administrivia: yes Sender: mailman-bounces@six.pairlist.net Errors-To: mailman-bounces@six.pairlist.net Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your securemulticast.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@securemulticast.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@securemulticast.org. Thanks! Passwords for msec-archive@lists.ietf.org: List Password // URL ---- -------- msec@securemulticast.org ucweat http://six.pairlist.net/mailman/options/msec/msec-archive%40lists.ietf.org From msec-bounces@securemulticast.org Mon Oct 4 16:18:01 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12612 for ; Mon, 4 Oct 2004 16:18:00 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 01B138DA11; Mon, 4 Oct 2004 16:18:00 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 8B0578D3BB for ; Mon, 4 Oct 2004 16:17:58 -0400 (EDT) Received: (qmail 42951 invoked by uid 3269); 4 Oct 2004 20:17:58 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 42948 invoked from network); 4 Oct 2004 20:17:58 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by klesh.pair.com with SMTP; 4 Oct 2004 20:17:58 -0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i94KHvF01162 for ; Mon, 4 Oct 2004 23:17:57 +0300 (EET DST) X-Scanned: Mon, 4 Oct 2004 23:17:47 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i94KHlH0019445 for ; Mon, 4 Oct 2004 23:17:47 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00gUuhTL; Mon, 04 Oct 2004 23:17:45 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i94KHjS11195 for ; Mon, 4 Oct 2004 23:17:45 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 4 Oct 2004 15:17:18 -0500 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 4 Oct 2004 16:17:16 -0400 Message-ID: Thread-Topic: Basic MIKEY/SRTP question thread-index: AcSqTyQsmQrnYQIHTIimkit/FbbPYw== From: To: X-OriginalArrivalTime: 04 Oct 2004 20:17:18.0055 (UTC) FILETIME=[25717F70:01C4AA4F] Subject: [MSEC] Basic MIKEY/SRTP question 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 Content-Transfer-Encoding: quoted-printable Hi all, I am new to MIKEY, was reading the RFC and have the following basic = questions.=20 Let say for a peer-to-peer voice call using SIP, suppose the peers want = to protect the audio using SRTP. So, my question is 1. There are two SRTP streams, one in each direction, is that right? 2. I assume the above, so MIKEY is used to set up two crypto contexts = for the two streams? or they share the same crypto contexts? 3. Is this achieved by having the initiator putting two crypto session = IDs in the "CS ID map info" (Section 6.1.1 SRTP ID). Is it true that the = initiator will put his/her SSRC and ROC in one of the map info, and = responder filling the other?=20 Just want to clarify these. Any help is much appreciated. P.S. Page 34, CS ID map info is said to have 16 bits, should it be = "variable"? and for SRTP, should it be multiples of (8+32+32) bits? Or = am I misunderstanding something? Thanks! - Tat _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Oct 5 10:43:46 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04479 for ; Tue, 5 Oct 2004 10:43:46 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 7D9708CD7E; Tue, 5 Oct 2004 10:43:47 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 182728CD76 for ; Tue, 5 Oct 2004 10:43:46 -0400 (EDT) Received: (qmail 60257 invoked by uid 3269); 5 Oct 2004 14:43:45 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 60254 invoked from network); 5 Oct 2004 14:43:45 -0000 Received: from eagle.ericsson.se (193.180.251.53) by klesh.pair.com with SMTP; 5 Oct 2004 14:43:45 -0000 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i95EhiRU002019 for ; Tue, 5 Oct 2004 16:43:44 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 5 Oct 2004 16:43:44 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <4J5FD2WP>; Tue, 5 Oct 2004 16:43:44 +0200 Message-ID: <4E85E49D1F0CBF4F96EA08E335750D7D0C3BC847@Esealnt877.al.sw.ericsson.se> From: "Elisabetta Carrara (KI/EAB)" To: "'Tat.Chan@nokia.com'" Subject: RE: [MSEC] Basic MIKEY/SRTP question Date: Tue, 5 Oct 2004 16:37:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 05 Oct 2004 14:43:44.0370 (UTC) FILETIME=[B6C54520:01C4AAE9] 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 Hi Tat! > > Let say for a peer-to-peer voice call using SIP, suppose the > peers want to protect the audio using SRTP. So, my question is > > 1. There are two SRTP streams, one in each direction, is that right? yes > 2. I assume the above, so MIKEY is used to set up two crypto > contexts for the two streams? or they share the same crypto contexts? the "SRTP crypto context" are different as there are things in them that are stream-dependent, e.g. the replay list. You mean security parameters and keys from MIKEY. They will be typically different, and I'm thinking about the keys mainly. Please give a look at section 6.1 in draft-ietf-mmusic-kmgmt-ext-11.txt, for the use within SDP. > 3. Is this achieved by having the initiator putting two > crypto session IDs in the "CS ID map info" (Section 6.1.1 > SRTP ID). Is it true that the initiator will put his/her SSRC > and ROC in one of the map info, and responder filling the other? yes, for example > > Just want to clarify these. Any help is much appreciated. > > P.S. Page 34, CS ID map info is said to have 16 bits, should > it be "variable"? and for SRTP, should it be multiples of > (8+32+32) bits? Or am I misunderstanding something? you are right. Thanks for spotting it! Cheers /E > > Thanks! > > - Tat > _______________________________________________ > 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 Oct 11 11:39:03 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15655 for ; Mon, 11 Oct 2004 11:39:03 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id DA65A8CF8A; Mon, 11 Oct 2004 11:39:02 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id EC0968CC7A for ; Mon, 11 Oct 2004 11:39:01 -0400 (EDT) Received: (qmail 95695 invoked by uid 3269); 11 Oct 2004 15:39:01 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 95692 invoked from network); 11 Oct 2004 15:39:01 -0000 Received: from sj-iport-4.cisco.com (171.68.10.86) by klesh.pair.com with SMTP; 11 Oct 2004 15:39:01 -0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 11 Oct 2004 08:40:22 -0700 X-BrightmailFiltered: true Received: from cisco.com (stealth-10-32-244-212.cisco.com [10.32.244.212]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id i9BFcwmQ017996 for ; Mon, 11 Oct 2004 08:38:59 -0700 (PDT) Message-ID: <416AA917.7060606@cisco.com> Date: Mon, 11 Oct 2004 08:39:03 -0700 From: Brian Weis User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MSEC] draft-ietf-msec-ipsec-signatures-02.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 Content-Transfer-Encoding: 7bit Thanks to all who had comments on the IPsec signatures draft during the WG last call. The next version of the draft has just been posted to the I-D repository. Please take a look to see if the changes adequately reflect the discussion. http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-signatures-02.txt Here's a summary of changes: - Various grammar fixes and updating of references - Section 2: Clarification on key lifetimes, and the use of ephemeral key pairs. - Section 3: Correction of the minimum key size (to match the stated minimum in section 2) - Section 3: Addition of the note that a low-exponent RSA (e.g., 3) may increase performance, and there are no known attacks on low-exponent RSA with this usage. (At least, I couldn't find any in the literature and when I posted a query to the CFRG mailing list no one responded with a known attack.) - Section 5: Added clarification text as to why it is not recommended that this transform be used with pair-wise SAs. - Section 6: Added a paragraph noting that non-repudiation is not claimed by this draft, and explaining why. - Section 6.7: Clarified that the anti-DoS mitigation of encapsulating the IPsec transform with another transform using an HMAC is not effective against attackers that are part of the group. Thanks, Brian -- 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 Sat Oct 16 13:02:26 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03065 for ; Sat, 16 Oct 2004 13:02:26 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id BA9008DB56; Sat, 16 Oct 2004 13:02:28 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 7F08D8DB52 for ; Sat, 16 Oct 2004 13:02:27 -0400 (EDT) Received: (qmail 94802 invoked by uid 3269); 16 Oct 2004 17:02:27 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 94799 invoked from network); 16 Oct 2004 17:02:27 -0000 Received: from smtp101.mail.sc5.yahoo.com (216.136.174.139) by klesh.pair.com with SMTP; 16 Oct 2004 17:02:27 -0000 Received: from unknown (HELO mou1thardjon-L2.yahoo.com) (thardjono@67.161.47.160 with login) by smtp101.mail.sc5.yahoo.com with SMTP; 16 Oct 2004 17:02:26 -0000 Message-Id: <6.1.0.6.2.20041016095940.03deda28@pop.mail.yahoo.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Sat, 16 Oct 2004 10:02:25 -0700 To: msec@securemulticast.org From: Thomas Hardjono In-Reply-To: <20040709004728.91819.qmail@web12502.mail.yahoo.com> References: <20040709004728.91819.qmail@web12502.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: canetti@watson.ibm.com Subject: [MSEC] Call for Agenda items for MSEC at IETF61, Washington, DC 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 Folks, Please email Ran/myself with items for the agenda. Currently, MSEC is scheduled for: MONDAY, November 8, 2004 1930-2200 Evening Sessions SEC msec Multicast Security WG Regards. Ran/thomas ---------- _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Oct 19 11:07:30 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04965 for ; Tue, 19 Oct 2004 11:07:30 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 4E40D8CD43; Tue, 19 Oct 2004 11:07:31 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 118AE8CC37 for ; Tue, 19 Oct 2004 11:07:30 -0400 (EDT) Received: (qmail 52503 invoked by uid 3269); 19 Oct 2004 15:07:30 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 52499 invoked from network); 19 Oct 2004 15:07:29 -0000 Received: from zcars04f.nortelnetworks.com (47.129.242.57) by klesh.pair.com with SMTP; 19 Oct 2004 15:07:29 -0000 Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9JF7QU26747; Tue, 19 Oct 2004 11:07:26 -0400 (EDT) Received: from [47.16.67.20] (atices-1.us.nortel.com [47.16.67.20]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 4QKDGJC5; Tue, 19 Oct 2004 11:07:25 -0400 Message-ID: <41752DAD.5040406@nortelnetworks.com> Date: Tue, 19 Oct 2004 11:07:25 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Dondeti, Lakshminath" Organization: Nortel Networks User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org, gsec@lists.tislabs.com Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pete_Dinsmore@McAfee.com Subject: [MSEC] [Fwd: [GSEC] Meeting in D.C.?] 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 Content-Transfer-Encoding: 7bit Trying again. Please let Pete and I know if there is interest in a GSEC meeting in D.C. regards, Lakshminath -------- Original Message -------- Subject: [GSEC] Meeting in D.C.? Date: Fri, 15 Oct 2004 17:31:04 -0400 From: Dondeti, Lakshminath [BL60:1A14:EXCH] To: gsec@lists.tislabs.com Hi all, I was wondering if there is any interest in a GSEC meeting in D.C. Please send proposals to present your latest work in multicast or group security protocols. regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Oct 20 02:43:03 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04418 for ; Wed, 20 Oct 2004 02:43:03 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 5C0848C99B; Wed, 20 Oct 2004 02:43:04 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 98AC28C77D for ; Wed, 20 Oct 2004 02:43:03 -0400 (EDT) Received: (qmail 35177 invoked by uid 3269); 20 Oct 2004 06:43:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 35174 invoked from network); 20 Oct 2004 06:43:03 -0000 Received: from david.siemens.de (192.35.17.14) by klesh.pair.com with SMTP; 20 Oct 2004 06:43:03 -0000 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id i9K6h2BO004220; Wed, 20 Oct 2004 08:43:02 +0200 Received: from mchn070c (mhpaba5c.mchp.siemens.de [139.23.204.46]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id i9K6h1ma007531; Wed, 20 Oct 2004 08:43:01 +0200 From: "Steffen Fries" Organization: Siemens AG To: msec@securemulticast.org Date: Wed, 20 Oct 2004 08:42:57 +0200 MIME-Version: 1.0 Message-ID: <41762511.18921.19C5E4A7@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (4.21c) Content-description: Mail message body Cc: canetti@watson.ibm.com, thardjono@verisign.com, hannes Tschofenig Subject: [MSEC] new draft avaialable for bootstrapping TESLA X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: steffen.fries@siemens.com List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2062819554==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org --===============2062819554== Content-type: text/html; charset=US-ASCII Content-description: Mail message body Content-Transfer-Encoding: 7BIT
Hi,

please find the Internet draft in the attachment or at the given URL. We would like to discuss this approach on the mailing list. Please sent comments!

Title

  Bootstrapping TESLA

Abstract

  With the Timed Efficient Stream Loss-tolerant Authentication
  protocol (TESLA) a protocol for providing source authentication
  in multicast scenarios was introduced.  A mapping for TESLA to
  the Secure Real-time Transport Protocol (SRTP) has been
  published which assumes that some TESLA parameters are made
  available by out-of-band mechanisms.  This document describes
  payloads for bootstrapping these parameters with the help of
  the Multimedia Internet KEYing (MIKEY)

Authors:

  S. Fries
  H. Tschofenig

URL:

  http://www.tschofenig.com/drafts/draft-fries-msec- bootstrapping-tesla-00.txt
  http://www.tschofenig.com/drafts/draft-fries-msec- bootstrapping-tesla-00.html

Best Regards,
Steffen Fries
--===============2062819554== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --===============2062819554==-- From msec-bounces@securemulticast.org Wed Oct 20 16:16:13 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21454 for ; Wed, 20 Oct 2004 16:16:12 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id E80B88CD87; Wed, 20 Oct 2004 16:16:12 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id C9ED18C3FA for ; Wed, 20 Oct 2004 16:16:11 -0400 (EDT) Received: (qmail 68043 invoked by uid 3269); 20 Oct 2004 20:16:11 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 68034 invoked from network); 20 Oct 2004 20:16:11 -0000 Received: from sj-iport-4.cisco.com (171.68.10.86) by klesh.pair.com with SMTP; 20 Oct 2004 20:16:11 -0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 20 Oct 2004 13:16:40 -0700 X-BrightmailFiltered: true Received: from [192.168.0.10] (sjc-vpn4-863.cisco.com [10.21.83.94]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i9KKG7Hn002714; Wed, 20 Oct 2004 13:16:07 -0700 (PDT) In-Reply-To: <41762511.18921.19C5E4A7@localhost> References: <41762511.18921.19C5E4A7@localhost> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Mark Baugher Subject: Re: [MSEC] new draft avaialable for bootstrapping TESLA Date: Wed, 20 Oct 2004 13:15:57 -0700 To: steffen.fries@siemens.com X-Mailer: Apple Mail (2.619) Cc: "Elisabetta Carrara (KI/EAB)" , canetti , hannes Tschofenig , Thomas Hardjono , 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 Content-Transfer-Encoding: quoted-printable This looks cool. Why don't we merge this into the TESLA I-D and I'll=20 add a section on sdescriptions? Mark On Oct 19, 2004, at 11:42 PM, Steffen Fries wrote: > Hi, > > > please find the Internet draft in the attachment or at the given URL.=20= > We would like to discuss this approach on the mailing list. Please=20 > sent comments! > > > Title > > > =A0 Bootstrapping TESLA > > > Abstract > > > =A0 With the Timed Efficient Stream Loss-tolerant Authentication > =A0 protocol (TESLA) a protocol for providing source authentication > =A0 in multicast scenarios was introduced.=A0 A mapping for TESLA to > =A0 the Secure Real-time Transport Protocol (SRTP) has been > =A0 published which assumes that some TESLA parameters are made > =A0 available by out-of-band mechanisms.=A0 This document describes > =A0 payloads for bootstrapping these parameters with the help of > =A0 the Multimedia Internet KEYing (MIKEY) > > > Authors: > > > =A0 S. Fries > =A0 H. Tschofenig > > > URL: > > > =A0 http://www.tschofenig.com/drafts/draft-fries-msec-=20 > bootstrapping-tesla-00.txt > =A0 http://www.tschofenig.com/drafts/draft-fries-msec-=20 > bootstrapping-tesla-00.html > > > Best Regards, > Steffen Fries > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Oct 21 06:20:39 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26082 for ; Thu, 21 Oct 2004 06:20:38 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 36DA48D610; Thu, 21 Oct 2004 06:20:31 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 4439A8CCAC for ; Thu, 21 Oct 2004 06:20:30 -0400 (EDT) Received: (qmail 28319 invoked by uid 3269); 21 Oct 2004 10:20:30 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 28316 invoked from network); 21 Oct 2004 10:20:29 -0000 Received: from smtp107.mail.sc5.yahoo.com (66.163.169.227) by klesh.pair.com with SMTP; 21 Oct 2004 10:20:29 -0000 Received: from unknown (HELO mou1thardjon-L2.yahoo.com) (thardjono@67.161.47.160 with login) by smtp107.mail.sc5.yahoo.com with SMTP; 21 Oct 2004 10:20:29 -0000 Message-Id: <6.1.0.6.2.20041018101902.0380ba08@pop.mail.yahoo.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Thu, 21 Oct 2004 03:20:29 -0700 To: msec@securemulticast.org From: Thomas Hardjono Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Tentative MSEC Agenda for IETF-61 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 Folks, Here is the MSEC Agenda for IETF-61 in DC as of today. Note that currently MSEC is scheduled for the Monday evening. MSEC WG Agenda IETF-60 San Diego: --------------------------------- - Status report, and Future of MSEC (Thomas Hardjono/Ran Canetti) - TESLA in SRTP Update (Elisabetta Carrara) - General Payload Type in MIKEY (Elisabetta Carrara) - DHHMAC-MIKEY Update (Martin Euchner/Steffen Fries) - Flat multicast key exchange (S. Josset/L.Duquerroy) Please email Ran/Thomas for corrections/additions. Note that at the moment MSEC will meet on: MONDAY, November 8, 2004 1930-2200 Evening Sessions SEC msec Multicast Security WG Regards, Thomas/Ran ---------- _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Oct 21 06:22:36 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26431 for ; Thu, 21 Oct 2004 06:22:36 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C7ED78C337; Thu, 21 Oct 2004 06:22:04 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 3002F8C208 for ; Thu, 21 Oct 2004 06:22:03 -0400 (EDT) Received: (qmail 28524 invoked by uid 3269); 21 Oct 2004 10:22:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 28517 invoked from network); 21 Oct 2004 10:22:02 -0000 Received: from smtp104.mail.sc5.yahoo.com (66.163.169.223) by klesh.pair.com with SMTP; 21 Oct 2004 10:22:02 -0000 Received: from unknown (HELO mou1thardjon-L2.yahoo.com) (thardjono@67.161.47.160 with login) by smtp104.mail.sc5.yahoo.com with SMTP; 21 Oct 2004 10:22:02 -0000 Message-Id: <6.1.0.6.2.20041021032101.04120ec0@pop.mail.yahoo.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Thu, 21 Oct 2004 03:22:03 -0700 To: msec@securemulticast.org From: Thomas Hardjono Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Correction: Tentative MSEC Agenda for IETF-61 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 Folks, Here is the MSEC Agenda for IETF-61 in DC as of today. Note that currently MSEC is scheduled for the Monday evening. MSEC WG Agenda: --------------- - Status report (Thomas Hardjono/Ran Canetti) - TESLA in SRTP Update (Elisabetta Carrara) - General Payload Type in MIKEY (Elisabetta Carrara) - DHHMAC-MIKEY Update (Martin Euchner/Steffen Fries) - Flat multicast key exchange (S. Josset/L.Duquerroy) Please email Ran/Thomas for corrections/additions. Note that at the moment MSEC will meet on: MONDAY, November 8, 2004 1930-2200 Evening Sessions SEC msec Multicast Security WG Regards, Thomas/Ran ---------- _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Oct 22 08:27:09 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27977 for ; Fri, 22 Oct 2004 08:27:09 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id DA4598D44E; Fri, 22 Oct 2004 08:27:08 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id F2F008D0BF for ; Fri, 22 Oct 2004 08:27:07 -0400 (EDT) Received: (qmail 5473 invoked by uid 3269); 22 Oct 2004 12:27:07 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 5470 invoked from network); 22 Oct 2004 12:27:07 -0000 Received: from goliath.siemens.de (192.35.17.28) by klesh.pair.com with SMTP; 22 Oct 2004 12:27:07 -0000 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id i9MCPwP6028005; Fri, 22 Oct 2004 14:25:58 +0200 Received: from mchn070c (mhpaba5c.mchp.siemens.de [139.23.204.46]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id i9MCPvBO003905; Fri, 22 Oct 2004 14:25:57 +0200 From: "Steffen Fries" Organization: Siemens AG To: Mark Baugher Date: Fri, 22 Oct 2004 14:25:57 +0200 MIME-Version: 1.0 Subject: Re: [MSEC] new draft avaialable for bootstrapping TESLA Message-ID: <41791875.15687.19C755@localhost> Priority: normal In-reply-to: References: <41762511.18921.19C5E4A7@localhost> X-mailer: Pegasus Mail for Windows (4.21c) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: Quoted-printable Content-description: Mail message body Cc: "Elisabetta Carrara (KI/EAB)" , canetti , hannes Tschofenig , Thomas Hardjono , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: steffen.fries@siemens.com 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 Content-Transfer-Encoding: Quoted-printable Hi Mark, sorry for the dely. Hm, merging it with the TESLA ID would bind the applicability to SRTP only. Wouldn't it make more sense to have it stand alone to be able to use it also for scenarios, were TESLA is used without SRTP? Ciao Steffen Copies to: Thomas Hardjono , msec@securemult= icast.org, canetti , hannes Tschofenig , Elisabetta Carrara (KI/EAB) From: Mark Baugher Subject: Re: [MSEC] new draft avaialable for bootstrapping TESLA Date sent: Wed, 20 Oct 2004 13:15:57 -0700 To: steffen.fries@siemens.com > This looks cool. Why don't we merge this into the TESLA I-D and I'll > add a section on sdescriptions? > > Mark > On Oct 19, 2004, at 11:42 PM, Steffen Fries wrote: > > > Hi, > > > > > > please find the Internet draft in the attachment or at the given > > URL. We would like to discuss this approach on the mailing list. > > Please sent comments! > > > > > > Title > > > > > > =A0 Bootstrapping TESLA > > > > > > Abstract > > > > > > =A0 With the Timed Efficient Stream Loss-tolerant Authentication =A0 > > protocol (TESLA) a protocol for providing source authentication =A0 > > in multicast scenarios was introduced.=A0 A mapping for TESLA to =A0 > > the Secure Real-time Transport Protocol (SRTP) has been =A0 published > > which assumes that some TESLA parameters are made =A0 available by > > out-of-band mechanisms.=A0 This document describes =A0 payloads for > > bootstrapping these parameters with the help of =A0 the Multimedia > > Internet KEYing (MIKEY) > > > > > > Authors: > > > > > > =A0 S. Fries > > =A0 H. Tschofenig > > > > > > URL: > > > > > > =A0 http://www.tschofenig.com/drafts/draft-fries-msec- > > bootstrapping-tesla-00.txt > > =A0 http://www.tschofenig.com/drafts/draft-fries-msec- > > bootstrapping-tesla-00.html > > > > > > Best Regards, > > Steffen Fries > > _______________________________________________ > > 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 Oct 22 09:53:14 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04524 for ; Fri, 22 Oct 2004 09:53:13 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id A889F8C4DF; Fri, 22 Oct 2004 09:52:26 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 6D3D38C4B9 for ; Fri, 22 Oct 2004 09:52:25 -0400 (EDT) Received: (qmail 18667 invoked by uid 3269); 22 Oct 2004 13:52:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 18664 invoked from network); 22 Oct 2004 13:52:25 -0000 Received: from david.siemens.de (192.35.17.14) by klesh.pair.com with SMTP; 22 Oct 2004 13:52:25 -0000 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id i9MDqNBO017821; Fri, 22 Oct 2004 15:52:24 +0200 Received: from mchn070c (mhpaba5c.mchp.siemens.de [139.23.204.46]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id i9MDqMYO000080; Fri, 22 Oct 2004 15:52:22 +0200 From: "Steffen Fries" Organization: Siemens AG To: msec@securemulticast.org, Thomas Hardjono Date: Fri, 22 Oct 2004 15:52:22 +0200 MIME-Version: 1.0 Subject: Re: [MSEC] Correction: Tentative MSEC Agenda for IETF-61 Message-ID: <41792CB6.5998.89B8F@localhost> Priority: normal In-reply-to: <6.1.0.6.2.20041021032101.04120ec0@pop.mail.yahoo.com> X-mailer: Pegasus Mail for Windows (4.21c) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: steffen.fries@siemens.com 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 Content-Transfer-Encoding: 7BIT Hi Thomas, short question, the presentation regarding Bootstrapping TESLA is missing in the agenda. Ran was asking for it, as I just submitted the draft. Regards Steffen Date sent: Thu, 21 Oct 2004 03:22:03 -0700 To: msec@securemulticast.org From: Thomas Hardjono Subject: [MSEC] Correction: Tentative MSEC Agenda for IETF-61 > > > Folks, > > Here is the MSEC Agenda for IETF-61 in DC as of today. > Note that currently MSEC is scheduled for the Monday evening. > > > MSEC WG Agenda: > --------------- > - Status report (Thomas Hardjono/Ran Canetti) > - TESLA in SRTP Update (Elisabetta Carrara) > - General Payload Type in MIKEY (Elisabetta Carrara) > - DHHMAC-MIKEY Update (Martin Euchner/Steffen Fries) > - Flat multicast key exchange (S. Josset/L.Duquerroy) > > > > Please email Ran/Thomas for corrections/additions. > > Note that at the moment MSEC will meet on: > > MONDAY, November 8, 2004 > 1930-2200 Evening Sessions > SEC msec Multicast Security WG > > > Regards, > > Thomas/Ran > ---------- > > > > _______________________________________________ > 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 Oct 22 12:03:18 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16613 for ; Fri, 22 Oct 2004 12:03:18 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id B26698D22F; Fri, 22 Oct 2004 12:03:18 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id ED1838D0A5 for ; Fri, 22 Oct 2004 12:03:16 -0400 (EDT) Received: (qmail 43165 invoked by uid 3269); 22 Oct 2004 16:03:16 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 43162 invoked from network); 22 Oct 2004 16:03:16 -0000 Received: from sj-iport-4.cisco.com (171.68.10.86) by klesh.pair.com with SMTP; 22 Oct 2004 16:03:16 -0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 22 Oct 2004 09:04:05 -0700 X-BrightmailFiltered: true Received: from [192.168.0.10] (sjc-vpn5-1338.cisco.com [10.21.93.58]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i9MG3C9b015558; Fri, 22 Oct 2004 09:03:12 -0700 (PDT) In-Reply-To: <41791875.15687.19C755@localhost> References: <41762511.18921.19C5E4A7@localhost> <41791875.15687.19C755@localhost> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Mark Baugher Subject: Re: [MSEC] new draft avaialable for bootstrapping TESLA Date: Fri, 22 Oct 2004 09:03:01 -0700 To: steffen.fries@siemens.com X-Mailer: Apple Mail (2.619) Cc: "Elisabetta Carrara (KI/EAB)" , canetti , hannes Tschofenig , Thomas Hardjono , 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 Content-Transfer-Encoding: quoted-printable hi Steffen That's true, it _might_ be more modular if it stands alone as a=20 separate document. It is also possible that different security=20 protocols will have different parameters for TESLA. I don't think it's=20= necessary and don't think that would be a good thing, but we have=20 approached SRTP TESLA as if we were free to invent new parameters or=20 reuse existing parameters such as the RTP timestamp (which turned out=20 to be infeasible). This question comes up repeatedly and there is a tradeoff between=20 giving the implementer a single document to use versus having several=20 that are general purpose. Dan Harkins thought this was a big problem=20 with IKE v1. I have heard complaints about GDOI, which assumes=20 knowledge of a few other documents (GDOI uses an IKE v1 phase 1=20 exchange, for example). At present, there is only one TESLA protocol that would use MIKEY,=20 the ESP variant would use IKE v2, I expect. I would like to see one=20 comprehensive document for SRTP TESLA. I'd also like to see some=20 cooperative work on getting an SRTP TESLA prototype, which presumably=20 would include signaling and key management. Mark On Oct 22, 2004, at 5:25 AM, Steffen Fries wrote: > Hi Mark, > > sorry for the dely. > > Hm, merging it with the TESLA ID would bind the applicability > to SRTP only. Wouldn't it make more sense to have it stand > alone to be able to use it also for scenarios, were TESLA is > used without SRTP? > > Ciao > Steffen > > > Copies to: Thomas Hardjono ,=20 > msec@securemulticast.org, > canetti , > hannes Tschofenig , > Elisabetta Carrara (KI/EAB) = > From: Mark Baugher > Subject: Re: [MSEC] new draft avaialable for = bootstrapping=20 > TESLA > Date sent: Wed, 20 Oct 2004 13:15:57 -0700 > To: steffen.fries@siemens.com > >> This looks cool. Why don't we merge this into the TESLA I-D and I'll >> add a section on sdescriptions? >> >> Mark >> On Oct 19, 2004, at 11:42 PM, Steffen Fries wrote: >> >>> Hi, >>> >>> >>> please find the Internet draft in the attachment or at the given >>> URL. We would like to discuss this approach on the mailing list. >>> Please sent comments! >>> >>> >>> Title >>> >>> >>> =A0 Bootstrapping TESLA >>> >>> >>> Abstract >>> >>> >>> =A0 With the Timed Efficient Stream Loss-tolerant Authentication =A0 >>> protocol (TESLA) a protocol for providing source authentication =A0 >>> in multicast scenarios was introduced.=A0 A mapping for TESLA to =A0 >>> the Secure Real-time Transport Protocol (SRTP) has been =A0 = published >>> which assumes that some TESLA parameters are made =A0 available by >>> out-of-band mechanisms.=A0 This document describes =A0 payloads for >>> bootstrapping these parameters with the help of =A0 the Multimedia >>> Internet KEYing (MIKEY) >>> >>> >>> Authors: >>> >>> >>> =A0 S. Fries >>> =A0 H. Tschofenig >>> >>> >>> URL: >>> >>> >>> =A0 http://www.tschofenig.com/drafts/draft-fries-msec- >>> bootstrapping-tesla-00.txt >>> =A0 http://www.tschofenig.com/drafts/draft-fries-msec- >>> bootstrapping-tesla-00.html >>> >>> >>> Best Regards, >>> Steffen Fries >>> _______________________________________________ >>> 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 Sat Oct 23 23:18:23 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11719 for ; Sat, 23 Oct 2004 23:18:20 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 720718CD48; Sat, 23 Oct 2004 23:18:22 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id C61A18CBD1 for ; Sat, 23 Oct 2004 23:18:20 -0400 (EDT) Received: (qmail 78846 invoked by uid 3269); 24 Oct 2004 03:18:20 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 78843 invoked from network); 24 Oct 2004 03:18:20 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 24 Oct 2004 03:18:20 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i9O3ID938244; Sat, 23 Oct 2004 23:18:13 -0400 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id i9O3ICb145970; Sat, 23 Oct 2004 23:18:12 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id i9O3IBx145968; Sat, 23 Oct 2004 23:18:11 -0400 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id i9O3IA226198; Sat, 23 Oct 2004 23:18:10 -0400 Date: Sat, 23 Oct 2004 23:18:10 -0400 (EDT) From: canetti To: Mark Baugher Subject: Re: [MSEC] new draft avaialable for bootstrapping TESLA In-Reply-To: Message-ID: References: <41762511.18921.19C5E4A7@localhost> <41791875.15687.19C755@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Elisabetta Carrara , hannes Tschofenig , Thomas Hardjono , steffen.fries@siemens.com, msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: QUOTED-PRINTABLE I can certainly see arguments both ways regarding whether to join the new draft with the current tesla-srtp or not. This would be something to discuss and decide in DC. I wanted to relate to another issue in the new draft. In fact, the issue is relevant also to tesla-srtp: The draft misses one important parameter: before the receiver can do anything, it must have a bound on the time difference its local clock and the senders's clock. (This value is denoted D_t in the tesla-intro draft.) Setting this value could be tricky - it may need a roundtrip receiver->sender->receiver. Looking again at the tesla-srtp draft, I didn't find this parameter there either. this parameter is necessary for determining the cutoff time for a packet, and in particular in determining if the packet is safe or did it arrive too late. Ran On Fri, 22 Oct 2004, Mark Baugher wrote: > hi Steffen > That's true, it _might_ be more modular if it stands alone as a > separate document. It is also possible that different security > protocols will have different parameters for TESLA. I don't think it's > necessary and don't think that would be a good thing, but we have > approached SRTP TESLA as if we were free to invent new parameters or > reuse existing parameters such as the RTP timestamp (which turned out > to be infeasible). > > This question comes up repeatedly and there is a tradeoff between > giving the implementer a single document to use versus having several > that are general purpose. Dan Harkins thought this was a big problem > with IKE v1. I have heard complaints about GDOI, which assumes > knowledge of a few other documents (GDOI uses an IKE v1 phase 1 > exchange, for example). > > At present, there is only one TESLA protocol that would use MIKEY, > the ESP variant would use IKE v2, I expect. I would like to see one > comprehensive document for SRTP TESLA. I'd also like to see some > cooperative work on getting an SRTP TESLA prototype, which presumably > would include signaling and key management. > > Mark > On Oct 22, 2004, at 5:25 AM, Steffen Fries wrote: > > > Hi Mark, > > > > sorry for the dely. > > > > Hm, merging it with the TESLA ID would bind the applicability > > to SRTP only. Wouldn't it make more sense to have it stand > > alone to be able to use it also for scenarios, were TESLA is > > used without SRTP? > > > > Ciao > > Steffen > > > > > > Copies to: =09Thomas Hardjono , > > msec@securemulticast.org, > > =09canetti , > > =09hannes Tschofenig , > > =09Elisabetta Carrara (KI/EAB) > > From: =09Mark Baugher > > Subject: =09Re: [MSEC] new draft avaialable for bootstrapping > > TESLA > > Date sent: =09Wed, 20 Oct 2004 13:15:57 -0700 > > To: =09steffen.fries@siemens.com > > > >> This looks cool. Why don't we merge this into the TESLA I-D and I'll > >> add a section on sdescriptions? > >> > >> Mark > >> On Oct 19, 2004, at 11:42 PM, Steffen Fries wrote: > >> > >>> Hi, > >>> > >>> > >>> please find the Internet draft in the attachment or at the given > >>> URL. We would like to discuss this approach on the mailing list. > >>> Please sent comments! > >>> > >>> > >>> Title > >>> > >>> > >>> =A0 Bootstrapping TESLA > >>> > >>> > >>> Abstract > >>> > >>> > >>> =A0 With the Timed Efficient Stream Loss-tolerant Authentication =A0 > >>> protocol (TESLA) a protocol for providing source authentication =A0 > >>> in multicast scenarios was introduced.=A0 A mapping for TESLA to =A0 > >>> the Secure Real-time Transport Protocol (SRTP) has been =A0 publishe= d > >>> which assumes that some TESLA parameters are made =A0 available by > >>> out-of-band mechanisms.=A0 This document describes =A0 payloads for > >>> bootstrapping these parameters with the help of =A0 the Multimedia > >>> Internet KEYing (MIKEY) > >>> > >>> > >>> Authors: > >>> > >>> > >>> =A0 S. Fries > >>> =A0 H. Tschofenig > >>> > >>> > >>> URL: > >>> > >>> > >>> =A0 http://www.tschofenig.com/drafts/draft-fries-msec- > >>> bootstrapping-tesla-00.txt > >>> =A0 http://www.tschofenig.com/drafts/draft-fries-msec- > >>> bootstrapping-tesla-00.html > >>> > >>> > >>> Best Regards, > >>> Steffen Fries > >>> _______________________________________________ > >>> 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 Oct 25 06:13:33 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09888 for ; Mon, 25 Oct 2004 06:13:32 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 457738CA39; Mon, 25 Oct 2004 06:12:13 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 1ADD18C9F7 for ; Mon, 25 Oct 2004 06:12:11 -0400 (EDT) Received: (qmail 4134 invoked by uid 3269); 25 Oct 2004 10:12:11 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 4131 invoked from network); 25 Oct 2004 10:12:10 -0000 Received: from david.siemens.de (192.35.17.14) by klesh.pair.com with SMTP; 25 Oct 2004 10:12:10 -0000 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id i9PAC6BO006184; Mon, 25 Oct 2004 12:12:06 +0200 Received: from mchn070c (mhpaba5c.mchp.siemens.de [139.23.204.46]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id i9PAC5YO009733; Mon, 25 Oct 2004 12:12:05 +0200 From: "Steffen Fries" Organization: Siemens AG To: Mark Baugher , canetti Date: Mon, 25 Oct 2004 12:12:05 +0200 MIME-Version: 1.0 Subject: Re: [MSEC] new draft avaialable for bootstrapping TESLA Message-ID: <417CED95.3123.AD56DC@localhost> Priority: normal In-reply-to: References: X-mailer: Pegasus Mail for Windows (4.21c) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: Quoted-printable Content-description: Mail message body Cc: Elisabetta Carrara , hannes Tschofenig , Thomas Hardjono , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: steffen.fries@siemens.com 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 Content-Transfer-Encoding: Quoted-printable Hi Ran, okay, I see your point. MIKEY already provides timestamps as part of the MIKEY payload, which is used in the context of MIKEY to detect replay. This also requires a loosly time synchronization. I thought that this is also sufficient for TESLA. Do you think it would be enough to add a section explaining this? Regards Steffen Date sent: Sat, 23 Oct 2004 23:18:10 -0400 (EDT) From: canetti To: Mark Baugher Copies to: steffen.fries@siemens.com, Thomas Hardjono , msec@securemulticast.org, hannes Tschofenig , Elisabetta Carrara Subject: Re: [MSEC] new draft avaialable for bootstrapping TESLA > > I can certainly see arguments both ways regarding whether to join the > new draft with the current tesla-srtp or not. This would be something > to discuss and decide in DC. > > I wanted to relate to another issue in the new draft. In fact, the > issue is relevant also to tesla-srtp: The draft misses one important > parameter: before the receiver can do anything, it must have a bound > on the time difference its local clock and the senders's clock. (This > value is denoted D_t in the tesla-intro draft.) Setting this value > could be tricky - it may need a roundtrip receiver->sender->receiver. > > Looking again at the tesla-srtp draft, I didn't find this parameter > there either. this parameter is necessary for determining the cutoff > time for a packet, and in particular in determining if the packet is > safe or did it arrive too late. > > Ran > > > On Fri, 22 Oct 2004, Mark Baugher wrote: > > > hi Steffen > > That's true, it _might_ be more modular if it stands alone as a > > separate document. It is also possible that different security > > protocols will have different parameters for TESLA. I don't think > > it's necessary and don't think that would be a good thing, but we > > have approached SRTP TESLA as if we were free to invent new > > parameters or reuse existing parameters such as the RTP timestamp > > (which turned out to be infeasible). > > > > This question comes up repeatedly and there is a tradeoff between > > giving the implementer a single document to use versus having > > several that are general purpose. Dan Harkins thought this was a > > big problem with IKE v1. I have heard complaints about GDOI, which > > assumes knowledge of a few other documents (GDOI uses an IKE v1 > > phase 1 exchange, for example). > > > > At present, there is only one TESLA protocol that would use > > MIKEY, > > the ESP variant would use IKE v2, I expect. I would like to see one > > comprehensive document for SRTP TESLA. I'd also like to see some > > cooperative work on getting an SRTP TESLA prototype, which > > presumably would include signaling and key management. > > > > Mark > > On Oct 22, 2004, at 5:25 AM, Steffen Fries wrote: > > > > > Hi Mark, > > > > > > sorry for the dely. > > > > > > Hm, merging it with the TESLA ID would bind the applicability to > > > SRTP only. Wouldn't it make more sense to have it stand alone to > > > be able to use it also for scenarios, were TESLA is used without > > > SRTP? > > > > > > Ciao > > > Steffen > > > > > > > > > Copies to: Thomas Hardjono , > > > msec@securemulticast.org, > > > canetti , > > > hannes Tschofenig , > > > Elisabetta Carrara (KI/EAB) > > > > > > From: Mark Baugher > > > Subject: Re: [MSEC] new draft avaialable for bootstrapping > > > TESLA Date sent: Wed, 20 Oct 2004 13:15:57 -0700 To: > > > steffen.fries@siemens.com > > > > > >> This looks cool. Why don't we merge this into the TESLA I-D and > > >> I'll add a section on sdescriptions? > > >> > > >> Mark > > >> On Oct 19, 2004, at 11:42 PM, Steffen Fries wrote: > > >> > > >>> Hi, > > >>> > > >>> > > >>> please find the Internet draft in the attachment or at the given > > >>> URL. We would like to discuss this approach on the mailing list. > > >>> Please sent comments! > > >>> > > >>> > > >>> Title > > >>> > > >>> > > >>> =A0 Bootstrapping TESLA > > >>> > > >>> > > >>> Abstract > > >>> > > >>> > > >>> =A0 With the Timed Efficient Stream Loss-tolerant Authentication > > >>> =A0 protocol (TESLA) a protocol for providing source > > >>> authentication =A0 in multicast scenarios was introduced.=A0 A > > >>> mapping for TESLA to =A0 the Secure Real-time Transport Protocol > > >>> (SRTP) has been =A0 published which assumes that some TESLA > > >>> parameters are made =A0 available by out-of-band mechanisms.=A0 > > >>> This document describes =A0 payloads for bootstrapping these > > >>> parameters with the help of =A0 the Multimedia Internet KEYing > > >>> (MIKEY) > > >>> > > >>> > > >>> Authors: > > >>> > > >>> > > >>> =A0 S. Fries > > >>> =A0 H. Tschofenig > > >>> > > >>> > > >>> URL: > > >>> > > >>> > > >>> =A0 http://www.tschofenig.com/drafts/draft-fries-msec- > > >>> bootstrapping-tesla-00.txt > > >>> =A0 http://www.tschofenig.com/drafts/draft-fries-msec- > > >>> bootstrapping-tesla-00.html > > >>> > > >>> > > >>> Best Regards, > > >>> Steffen Fries > > >>> _______________________________________________ > > >>> msec mailing list > > >>> msec@securemulticast.org > > >>> http://six.pairlist.net/mailman/listinfo/msec > > >> > > > > > > > > > > > > ----------------------------------------------------------- Steffen Fries, Siemens AG, CT IC 3 Otto-Hahn-Ring 6, D-81730 Munich, Germany Phone: (+49) 89 / 636-53403, Fax : (+49) 89 / 636-48000 Email: Steffen.Fries@siemens.com ----------------------------------------------------------- _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Oct 25 15:40:52 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27390 for ; Mon, 25 Oct 2004 15:40:51 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 374608C66A; Mon, 25 Oct 2004 15:40:53 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 7F5F58C2C1 for ; Mon, 25 Oct 2004 15:40:51 -0400 (EDT) Received: (qmail 39602 invoked by uid 3269); 25 Oct 2004 19:40:51 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 39599 invoked from network); 25 Oct 2004 19:40:51 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 25 Oct 2004 19:40:51 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i9PJdi9181342; Mon, 25 Oct 2004 15:39:45 -0400 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id i9PJdhb144508; Mon, 25 Oct 2004 15:39:43 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id i9PJdhx148280; Mon, 25 Oct 2004 15:39:43 -0400 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id i9PJdgf27882; Mon, 25 Oct 2004 15:39:42 -0400 Date: Mon, 25 Oct 2004 15:39:39 -0400 (EDT) From: canetti To: Steffen Fries Subject: Re: [MSEC] new draft avaialable for bootstrapping TESLA In-Reply-To: <417CED95.3123.AD56DC@localhost> Message-ID: References: <417CED95.3123.AD56DC@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Elisabetta Carrara , msec@securemulticast.org, hannes Tschofenig , Mark Baugher , Thomas Hardjono 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 Content-Transfer-Encoding: QUOTED-PRINTABLE Steffen, I dont think that a simple MIKEY timestamp would suffice here. The MIKEY timestamp only records the local time at the sender at the time of sending. In contrast, what the receiver needs for TESLA is an upper bound on the difference (sender's local time - receiver's local time). That is, the receiver needs to know that if its local time is T then the sender's local time is at MOST T+D_t. In order to get an upper bound on D_t there needs to be some communication from the receiver to the sender. Alternatively, if a GCKS is used, then it's ok to have a communication from the receiver to the GCKS. I can think of two things we can do: 1. assume that the value D_t is computed using means external to MIKEY and MIKEY only communicates the already-known value. (This would make sense if, say, there was already some interaction between the sender and receiver, or between a GCKS and the sender.) 2. use the interactive (two-message) variant of MIKEY, and piggyback an exchange of timing messages on the two MIKEY messages. Any other ideas? Ran On Mon, 25 Oct 2004, Steffen Fries wrote: > Hi Ran, > > okay, I see your point. > > MIKEY already provides timestamps as part of the MIKEY payload, > which is used in the context of MIKEY to detect replay. This > also requires a loosly time synchronization. I thought that this > is also sufficient for TESLA. > Do you think it would be enough to add a section explaining > this? > > Regards > =09Steffen > > > > Date sent: =09Sat, 23 Oct 2004 23:18:10 -0400 (EDT) > From: =09canetti > To: =09Mark Baugher > Copies to: =09steffen.fries@siemens.com, Thomas Hardjono , > =09msec@securemulticast.org, > =09hannes Tschofenig , > =09Elisabetta Carrara > Subject: =09Re: [MSEC] new draft avaialable for bootstrapping TESL= A > > > > > I can certainly see arguments both ways regarding whether to join the > > new draft with the current tesla-srtp or not. This would be something > > to discuss and decide in DC. > > > > I wanted to relate to another issue in the new draft. In fact, the > > issue is relevant also to tesla-srtp: The draft misses one important > > parameter: before the receiver can do anything, it must have a bound > > on the time difference its local clock and the senders's clock. (This > > value is denoted D_t in the tesla-intro draft.) Setting this value > > could be tricky - it may need a roundtrip receiver->sender->receiver. > > > > Looking again at the tesla-srtp draft, I didn't find this parameter > > there either. this parameter is necessary for determining the cutoff > > time for a packet, and in particular in determining if the packet is > > safe or did it arrive too late. > > > > Ran > > > > > > On Fri, 22 Oct 2004, Mark Baugher wrote: > > > > > hi Steffen > > > That's true, it _might_ be more modular if it stands alone as a > > > separate document. It is also possible that different security > > > protocols will have different parameters for TESLA. I don't think > > > it's necessary and don't think that would be a good thing, but we > > > have approached SRTP TESLA as if we were free to invent new > > > parameters or reuse existing parameters such as the RTP timestamp > > > (which turned out to be infeasible). > > > > > > This question comes up repeatedly and there is a tradeoff between > > > giving the implementer a single document to use versus having > > > several that are general purpose. Dan Harkins thought this was a > > > big problem with IKE v1. I have heard complaints about GDOI, which > > > assumes knowledge of a few other documents (GDOI uses an IKE v1 > > > phase 1 exchange, for example). > > > > > > At present, there is only one TESLA protocol that would use > > > MIKEY, > > > the ESP variant would use IKE v2, I expect. I would like to see one > > > comprehensive document for SRTP TESLA. I'd also like to see some > > > cooperative work on getting an SRTP TESLA prototype, which > > > presumably would include signaling and key management. > > > > > > Mark > > > On Oct 22, 2004, at 5:25 AM, Steffen Fries wrote: > > > > > > > Hi Mark, > > > > > > > > sorry for the dely. > > > > > > > > Hm, merging it with the TESLA ID would bind the applicability to > > > > SRTP only. Wouldn't it make more sense to have it stand alone to > > > > be able to use it also for scenarios, were TESLA is used without > > > > SRTP? > > > > > > > > Ciao > > > > Steffen > > > > > > > > > > > > Copies to: =09Thomas Hardjono , > > > > msec@securemulticast.org, > > > > =09canetti , > > > > =09hannes Tschofenig , > > > > =09Elisabetta Carrara (KI/EAB) > > > > > > > > From: =09Mark Baugher > > > > Subject: =09Re: [MSEC] new draft avaialable for bootstrappin= g > > > > TESLA Date sent: =09Wed, 20 Oct 2004 13:15:57 -0700 To: > > > > =09steffen.fries@siemens.com > > > > > > > >> This looks cool. Why don't we merge this into the TESLA I-D and > > > >> I'll add a section on sdescriptions? > > > >> > > > >> Mark > > > >> On Oct 19, 2004, at 11:42 PM, Steffen Fries wrote: > > > >> > > > >>> Hi, > > > >>> > > > >>> > > > >>> please find the Internet draft in the attachment or at the given > > > >>> URL. We would like to discuss this approach on the mailing list. > > > >>> Please sent comments! > > > >>> > > > >>> > > > >>> Title > > > >>> > > > >>> > > > >>> =A0 Bootstrapping TESLA > > > >>> > > > >>> > > > >>> Abstract > > > >>> > > > >>> > > > >>> =A0 With the Timed Efficient Stream Loss-tolerant Authentication > > > >>> =A0 protocol (TESLA) a protocol for providing source > > > >>> authentication =A0 in multicast scenarios was introduced.=A0 A > > > >>> mapping for TESLA to =A0 the Secure Real-time Transport Protocol > > > >>> (SRTP) has been =A0 published which assumes that some TESLA > > > >>> parameters are made =A0 available by out-of-band mechanisms.=A0 > > > >>> This document describes =A0 payloads for bootstrapping these > > > >>> parameters with the help of =A0 the Multimedia Internet KEYing > > > >>> (MIKEY) > > > >>> > > > >>> > > > >>> Authors: > > > >>> > > > >>> > > > >>> =A0 S. Fries > > > >>> =A0 H. Tschofenig > > > >>> > > > >>> > > > >>> URL: > > > >>> > > > >>> > > > >>> =A0 http://www.tschofenig.com/drafts/draft-fries-msec- > > > >>> bootstrapping-tesla-00.txt > > > >>> =A0 http://www.tschofenig.com/drafts/draft-fries-msec- > > > >>> bootstrapping-tesla-00.html > > > >>> > > > >>> > > > >>> Best Regards, > > > >>> Steffen Fries > > > >>> _______________________________________________ > > > >>> msec mailing list > > > >>> msec@securemulticast.org > > > >>> http://six.pairlist.net/mailman/listinfo/msec > > > >> > > > > > > > > > > > > > > > > > > > ----------------------------------------------------------- > Steffen Fries, Siemens AG, CT IC 3 > Otto-Hahn-Ring 6, D-81730 Munich, Germany > Phone: (+49) 89 / 636-53403, > Fax : (+49) 89 / 636-48000 > Email: Steffen.Fries@siemens.com > ----------------------------------------------------------- > > > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Oct 25 18:34:57 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02604 for ; Mon, 25 Oct 2004 18:34:55 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id D905B8CDA6; Mon, 25 Oct 2004 18:34:55 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 6B5D28C7A0 for ; Mon, 25 Oct 2004 18:34:54 -0400 (EDT) Received: (qmail 67556 invoked by uid 3269); 25 Oct 2004 22:34:54 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 67553 invoked from network); 25 Oct 2004 22:34:54 -0000 Received: from smtp108.mail.sc5.yahoo.com (66.163.170.6) by klesh.pair.com with SMTP; 25 Oct 2004 22:34:54 -0000 Received: from unknown (HELO mou1thardjon-L2.yahoo.com) (thardjono@67.161.47.160 with login) by smtp108.mail.sc5.yahoo.com with SMTP; 25 Oct 2004 22:34:53 -0000 Message-Id: <6.1.0.6.2.20041025153037.03be96f8@pop.mail.yahoo.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Mon, 25 Oct 2004 15:34:06 -0700 To: msec@securemulticast.org From: Thomas Hardjono Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Tentative MSEC agenda for IETF61 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 Folks, Here is the MSEC Agenda for IETF-61 in DC as of today. MSEC WG Agenda: --------------- - Status report (Thomas Hardjono/Ran Canetti) - TESLA in SRTP Update (Elisabetta Carrara) - General Payload Type in MIKEY (Elisabetta Carrara) - DHHMAC-MIKEY Update (Martin Euchner/Steffen Fries) - Flat multicast key exchange (S. Josset/L.Duquerroy) - Bootstrapping TESLA (Steffen Fries) Currently MSEC is listed as meeting on: MONDAY, November 8, 2004 1930-2200 Evening Sessions SEC msec Multicast Security WG Please email Ran/Thomas for corrections/additions. Regards, Thomas/Ran ---------- _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Oct 26 07:06:30 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23535 for ; Tue, 26 Oct 2004 07:06:28 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 8A8F68CBA7; Tue, 26 Oct 2004 07:06:26 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 0CA8C8CB3A for ; Tue, 26 Oct 2004 07:06:25 -0400 (EDT) Received: (qmail 9981 invoked by uid 3269); 26 Oct 2004 11:06:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 9978 invoked from network); 26 Oct 2004 11:06:24 -0000 Received: from albatross.ericsson.se (193.180.251.49) by klesh.pair.com with SMTP; 26 Oct 2004 11:06:24 -0000 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9QB6NWR006125 for ; Tue, 26 Oct 2004 13:06:23 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Oct 2004 13:06:23 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 26 Oct 2004 13:06:19 +0200 Message-ID: <4E85E49D1F0CBF4F96EA08E335750D7D0C3BCBA6@Esealnt877.al.sw.ericsson.se> From: "Elisabetta Carrara (KI/EAB)" To: "'msec@securemulticast.org'" Date: Tue, 26 Oct 2004 12:59:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 26 Oct 2004 11:06:23.0446 (UTC) FILETIME=[D472EF60:01C4BB4B] Subject: [MSEC] FW: I-D ACTION:draft-carrara-newtype-keyid-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 Hi! I'm sending a pointer to a new draft that defines a new type for the General Extension Payload in MIKEY. This is on the msec agenda that Thomas sent out. Cheers /E -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: den 21 oktober 2004 21:50 To: i-d-announce@ietf.org Subject: I-D ACTION:draft-carrara-newtype-keyid-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Key ID Information Type for the General Extension Payload in MIKEY Author(s) : E. Carrara Filename : draft-carrara-newtype-keyid-00.txt Pages : 6 Date : 2004-10-21 This memo specifies a new Type (the Key ID Information Type) for the General Extension Payload in the Multimedia Internet KEYing Protocol. This is used in the Multimedia Broadcast/Multicast Service specified in the 3rd Generation Partnership Project. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-carrara-newtype-keyid-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-carrara-newtype-keyid-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-carrara-newtype-keyid-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Oct 26 12:14:36 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19296 for ; Tue, 26 Oct 2004 12:14:35 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 7215B8C58B; Tue, 26 Oct 2004 12:12:36 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 0D6F78C38B for ; Tue, 26 Oct 2004 09:33:03 -0400 (EDT) Received: (qmail 33510 invoked by uid 3269); 26 Oct 2004 13:33:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 33502 invoked from network); 26 Oct 2004 13:33:02 -0000 Received: from goliath.siemens.de (192.35.17.28) by klesh.pair.com with SMTP; 26 Oct 2004 13:33:02 -0000 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id i9QDWwP6015732; Tue, 26 Oct 2004 15:32:58 +0200 Received: from mchn070c (mhpaba5c.mchp.siemens.de [139.23.204.46]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id i9QDWuma006918; Tue, 26 Oct 2004 15:32:57 +0200 From: "Steffen Fries" Organization: Siemens AG To: canetti Date: Tue, 26 Oct 2004 15:32:55 +0200 MIME-Version: 1.0 Subject: Re: [MSEC] new draft avaialable for bootstrapping TESLA Message-ID: <417E6E27.13924.F5B7C5@localhost> Priority: normal In-reply-to: References: <417CED95.3123.AD56DC@localhost> X-mailer: Pegasus Mail for Windows (4.21c) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: Quoted-printable Content-description: Mail message body Cc: Elisabetta Carrara , msec@securemulticast.org, hannes Tschofenig , Mark Baugher , Thomas Hardjono X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: steffen.fries@siemens.com 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 Content-Transfer-Encoding: Quoted-printable Hi Ran MIKEY also recommends using NTP for time synchronization. This could be done in group based communication scenarios via a GCKS as you pointed out in option 1. Providing a piggyback mechanism on top of MIKEY may not be work for every case as MIKEY runs with two messages at most. Imagine that a client opens a media session with the a media data provider and acts as MIKEY initiator. In this case both could piggyback the timestamps as described in section 3.3.1 in the TESLA intro draft. After receiving the MIKEY responder message the client would be able to calculate D_t. If on the other hand the media data provider acts as a MIKEY initiator the client would not be able to follow the example from section 3.3.1, without receiving an additional message (carrying t_s, t_r). I would suggest going with option 1 using out of band mechanisms like NTP or SNTP as MIKEY already needs to solve the problem of time synchronization too. Regards Steffen Date sent: Mon, 25 Oct 2004 15:39:39 -0400 (EDT) From: canetti To: Steffen Fries Copies to: Mark Baugher , Thomas Hardjono , msec@securemulticast.org= , hannes Tschofenig , Elisabetta Carrara Subject: Re: [MSEC] new draft avaialable for bootstrapping TESLA > > Steffen, > > I dont think that a simple MIKEY timestamp would suffice here. > The MIKEY timestamp only records the local time at the sender at the > time of sending. In contrast, what the receiver needs for TESLA is an > upper bound on the difference (sender's local time - receiver's local > time). That is, the receiver needs to know that if its local time is T > then the sender's local time is at MOST T+D_t. > > In order to get an upper bound on D_t there needs to be some > communication from the receiver to the sender. Alternatively, if a > GCKS is used, then it's ok to have a communication from the receiver > to the GCKS. > > I can think of two things we can do: > > 1. assume that the value D_t is computed using means external to MIKEY > and MIKEY only communicates the already-known value. (This would make > sense if, say, there was already some interaction between the sender > and receiver, or between a GCKS and the sender.) 2. use the > interactive (two-message) variant of MIKEY, and piggyback an exchange > of timing messages on the two MIKEY messages. > > Any other ideas? > > Ran > > On Mon, 25 Oct 2004, Steffen Fries wrote: > > > Hi Ran, > > > > okay, I see your point. > > > > MIKEY already provides timestamps as part of the MIKEY payload, > > which is used in the context of MIKEY to detect replay. This also > > requires a loosly time synchronization. I thought that this is also > > sufficient for TESLA. Do you think it would be enough to add a > > section explaining this? > > > > Regards > > Steffen > > > > > > > > Date sent: Sat, 23 Oct 2004 23:18:10 -0400 (EDT) > > From: canetti > > To: Mark Baugher > > Copies to: steffen.fries@siemens.com, Thomas Hardjono > > , > > msec@securemulticast.org, > > hannes Tschofenig , > > Elisabetta Carrara > > Subject: Re: [MSEC] new draft avaialable for bootstrapping > > TESLA > > > > > > > > I can certainly see arguments both ways regarding whether to join > > > the new draft with the current tesla-srtp or not. This would be > > > something to discuss and decide in DC. > > > > > > I wanted to relate to another issue in the new draft. In fact, the > > > issue is relevant also to tesla-srtp: The draft misses one > > > important parameter: before the receiver can do anything, it must > > > have a bound on the time difference its local clock and the > > > senders's clock. (This value is denoted D_t in the tesla-intro > > > draft.) Setting this value could be tricky - it may need a > > > roundtrip receiver->sender->receiver. > > > > > > Looking again at the tesla-srtp draft, I didn't find this > > > parameter there either. this parameter is necessary for > > > determining the cutoff time for a packet, and in particular in > > > determining if the packet is safe or did it arrive too late. > > > > > > Ran > > > > > > > > > On Fri, 22 Oct 2004, Mark Baugher wrote: > > > > > > > hi Steffen > > > > That's true, it _might_ be more modular if it stands alone as > > > > a > > > > separate document. It is also possible that different security > > > > protocols will have different parameters for TESLA. I don't > > > > think it's necessary and don't think that would be a good thing, > > > > but we have approached SRTP TESLA as if we were free to invent > > > > new parameters or reuse existing parameters such as the RTP > > > > timestamp (which turned out to be infeasible). > > > > > > > > This question comes up repeatedly and there is a tradeoff > > > > between > > > > giving the implementer a single document to use versus having > > > > several that are general purpose. Dan Harkins thought this was > > > > a big problem with IKE v1. I have heard complaints about GDOI, > > > > which assumes knowledge of a few other documents (GDOI uses an > > > > IKE v1 phase 1 exchange, for example). > > > > > > > > At present, there is only one TESLA protocol that would use > > > > MIKEY, > > > > the ESP variant would use IKE v2, I expect. I would like to see > > > > one comprehensive document for SRTP TESLA. I'd also like to see > > > > some cooperative work on getting an SRTP TESLA prototype, which > > > > presumably would include signaling and key management. > > > > > > > > Mark > > > > On Oct 22, 2004, at 5:25 AM, Steffen Fries wrote: > > > > > > > > > Hi Mark, > > > > > > > > > > sorry for the dely. > > > > > > > > > > Hm, merging it with the TESLA ID would bind the applicability > > > > > to SRTP only. Wouldn't it make more sense to have it stand > > > > > alone to be able to use it also for scenarios, were TESLA is > > > > > used without SRTP? > > > > > > > > > > Ciao > > > > > Steffen > > > > > > > > > > > > > > > Copies to: Thomas Hardjono , > > > > > msec@securemulticast.org, > > > > > canetti , > > > > > hannes Tschofenig , > > > > > Elisabetta Carrara (KI/EAB) > > > > > > > > > > From: Mark Baugher > > > > > Subject: Re: [MSEC] new draft avaialable for > > > > > bootstrapping TESLA Date sent: Wed, 20 Oct 2004 13:15:57 > > > > > -0700 To: > > > > > steffen.fries@siemens.com > > > > > > > > > >> This looks cool. Why don't we merge this into the TESLA I-D > > > > >> and I'll add a section on sdescriptions? > > > > >> > > > > >> Mark > > > > >> On Oct 19, 2004, at 11:42 PM, Steffen Fries wrote: > > > > >> > > > > >>> Hi, > > > > >>> > > > > >>> > > > > >>> please find the Internet draft in the attachment or at the > > > > >>> given URL. We would like to discuss this approach on the > > > > >>> mailing list. Please sent comments! > > > > >>> > > > > >>> > > > > >>> Title > > > > >>> > > > > >>> > > > > >>> =A0 Bootstrapping TESLA > > > > >>> > > > > >>> > > > > >>> Abstract > > > > >>> > > > > >>> > > > > >>> =A0 With the Timed Efficient Stream Loss-tolerant > > > > >>> Authentication =A0 protocol (TESLA) a protocol for providing > > > > >>> source authentication =A0 in multicast scenarios was > > > > >>> introduced.=A0 A mapping for TESLA to =A0 the Secure Real-tim= e > > > > >>> Transport Protocol (SRTP) has been =A0 published which > > > > >>> assumes that some TESLA parameters are made =A0 available by > > > > >>> out-of-band mechanisms.=A0 This document describes =A0 payloa= ds > > > > >>> for bootstrapping these parameters with the help of =A0 the > > > > >>> Multimedia Internet KEYing (MIKEY) > > > > >>> > > > > >>> > > > > >>> Authors: > > > > >>> > > > > >>> > > > > >>> =A0 S. Fries > > > > >>> =A0 H. Tschofenig > > > > >>> > > > > >>> > > > > >>> URL: > > > > >>> > > > > >>> > > > > >>> =A0 http://www.tschofenig.com/drafts/draft-fries-msec- > > > > >>> bootstrapping-tesla-00.txt > > > > >>> =A0 http://www.tschofenig.com/drafts/draft-fries-msec- > > > > >>> bootstrapping-tesla-00.html > > > > >>> > > > > >>> > > > > >>> Best Regards, > > > > >>> Steffen Fries > > > > >>> _______________________________________________ > > > > >>> msec mailing list > > > > >>> msec@securemulticast.org > > > > >>> http://six.pairlist.net/mailman/listinfo/msec > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > ----------------------------------------------------------- > > Steffen Fries, Siemens AG, CT IC 3 > > Otto-Hahn-Ring 6, D-81730 Munich, Germany > > Phone: (+49) 89 / 636-53403, > > Fax : (+49) 89 / 636-48000 > > Email: Steffen.Fries@siemens.com > > ----------------------------------------------------------- > > > > > > > > ----------------------------------------------------------- Steffen Fries, Siemens AG, CT IC 3 Otto-Hahn-Ring 6, D-81730 Munich, Germany Phone: (+49) 89 / 636-53403, Fax : (+49) 89 / 636-48000 Email: Steffen.Fries@siemens.com ----------------------------------------------------------- _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Oct 26 13:10:23 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24312 for ; Tue, 26 Oct 2004 13:10:23 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id AFD6B8D245; Tue, 26 Oct 2004 13:10:25 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id DB79E8D145 for ; Tue, 26 Oct 2004 13:10:23 -0400 (EDT) Received: (qmail 76192 invoked by uid 3269); 26 Oct 2004 17:10:23 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 76188 invoked from network); 26 Oct 2004 17:10:23 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 26 Oct 2004 17:10:23 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i9QH9v959352; Tue, 26 Oct 2004 13:09:57 -0400 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id i9QH9ub97104; Tue, 26 Oct 2004 13:09:56 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id i9QH9ux142042; Tue, 26 Oct 2004 13:09:56 -0400 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id i9QH9tZ26014; Tue, 26 Oct 2004 13:09:55 -0400 Date: Tue, 26 Oct 2004 13:09:54 -0400 (EDT) From: canetti To: Steffen Fries Subject: Re: [MSEC] new draft avaialable for bootstrapping TESLA In-Reply-To: <417E6E27.13924.F5B7C5@localhost> Message-ID: References: <417CED95.3123.AD56DC@localhost> <417E6E27.13924.F5B7C5@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Elisabetta Carrara , msec@securemulticast.org, hannes Tschofenig , Mark Baugher , Thomas Hardjono 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 Content-Transfer-Encoding: QUOTED-PRINTABLE Steffen, Perhaps you can discuss both options. Option 2 requires a light surgery to MIKEY (specifying exactly how the piggybacking is done.) In general, MIKEY makes a somewhat milder use of timestamping than TESLA. MIKEY only uses the timestamping to avoid replay, and thus it does not need a flow from the receiver to the sender. TESLA needs this back flow to get t= he upper bound on the time difference. Ran On Tue, 26 Oct 2004, Steffen Fries wrote: > Hi Ran > > MIKEY also recommends using NTP for time synchronization. This > could be done in group based communication scenarios via a GCKS > as you pointed out in option 1. > > Providing a piggyback mechanism on top of MIKEY may not be work > for every case as MIKEY runs with two messages at most. Imagine > that a client opens a media session with the a media data > provider and acts as MIKEY initiator. In this case both could > piggyback the timestamps as described in section 3.3.1 in the > TESLA intro draft. After receiving the MIKEY responder message > the client would be able to calculate D_t. > If on the other hand the media data provider acts as a MIKEY > initiator the client would not be able to follow the example > from section 3.3.1, without receiving an additional message > (carrying t_s, t_r). > > I would suggest going with option 1 using out of band mechanisms > like NTP or SNTP as MIKEY already needs to solve the problem of > time synchronization too. > > Regards > =09Steffen > > > > Date sent: =09Mon, 25 Oct 2004 15:39:39 -0400 (EDT) > From: =09canetti > To: =09Steffen Fries > Copies to: =09Mark Baugher , > =09Thomas Hardjono , msec@securemulticast.= org, > =09hannes Tschofenig , > =09Elisabetta Carrara > Subject: =09Re: [MSEC] new draft avaialable for bootstrapping TESL= A > > > > > Steffen, > > > > I dont think that a simple MIKEY timestamp would suffice here. > > The MIKEY timestamp only records the local time at the sender at the > > time of sending. In contrast, what the receiver needs for TESLA is an > > upper bound on the difference (sender's local time - receiver's local > > time). That is, the receiver needs to know that if its local time is T > > then the sender's local time is at MOST T+D_t. > > > > In order to get an upper bound on D_t there needs to be some > > communication from the receiver to the sender. Alternatively, if a > > GCKS is used, then it's ok to have a communication from the receiver > > to the GCKS. > > > > I can think of two things we can do: > > > > 1. assume that the value D_t is computed using means external to MIKEY > > and MIKEY only communicates the already-known value. (This would make > > sense if, say, there was already some interaction between the sender > > and receiver, or between a GCKS and the sender.) 2. use the > > interactive (two-message) variant of MIKEY, and piggyback an exchange > > of timing messages on the two MIKEY messages. > > > > Any other ideas? > > > > Ran > > > > On Mon, 25 Oct 2004, Steffen Fries wrote: > > > > > Hi Ran, > > > > > > okay, I see your point. > > > > > > MIKEY already provides timestamps as part of the MIKEY payload, > > > which is used in the context of MIKEY to detect replay. This also > > > requires a loosly time synchronization. I thought that this is also > > > sufficient for TESLA. Do you think it would be enough to add a > > > section explaining this? > > > > > > Regards > > > =09Steffen > > > > > > > > > > > > Date sent: =09Sat, 23 Oct 2004 23:18:10 -0400 (EDT) > > > From: =09canetti > > > To: =09Mark Baugher > > > Copies to: =09steffen.fries@siemens.com, Thomas Hardjono > > > , > > > =09msec@securemulticast.org, > > > =09hannes Tschofenig , > > > =09Elisabetta Carrara > > > Subject: =09Re: [MSEC] new draft avaialable for bootstrapping > > > TESLA > > > > > > > > > > > I can certainly see arguments both ways regarding whether to join > > > > the new draft with the current tesla-srtp or not. This would be > > > > something to discuss and decide in DC. > > > > > > > > I wanted to relate to another issue in the new draft. In fact, the > > > > issue is relevant also to tesla-srtp: The draft misses one > > > > important parameter: before the receiver can do anything, it must > > > > have a bound on the time difference its local clock and the > > > > senders's clock. (This value is denoted D_t in the tesla-intro > > > > draft.) Setting this value could be tricky - it may need a > > > > roundtrip receiver->sender->receiver. > > > > > > > > Looking again at the tesla-srtp draft, I didn't find this > > > > parameter there either. this parameter is necessary for > > > > determining the cutoff time for a packet, and in particular in > > > > determining if the packet is safe or did it arrive too late. > > > > > > > > Ran > > > > > > > > > > > > On Fri, 22 Oct 2004, Mark Baugher wrote: > > > > > > > > > hi Steffen > > > > > That's true, it _might_ be more modular if it stands alone as > > > > > a > > > > > separate document. It is also possible that different security > > > > > protocols will have different parameters for TESLA. I don't > > > > > think it's necessary and don't think that would be a good thing, > > > > > but we have approached SRTP TESLA as if we were free to invent > > > > > new parameters or reuse existing parameters such as the RTP > > > > > timestamp (which turned out to be infeasible). > > > > > > > > > > This question comes up repeatedly and there is a tradeoff > > > > > between > > > > > giving the implementer a single document to use versus having > > > > > several that are general purpose. Dan Harkins thought this was > > > > > a big problem with IKE v1. I have heard complaints about GDOI, > > > > > which assumes knowledge of a few other documents (GDOI uses an > > > > > IKE v1 phase 1 exchange, for example). > > > > > > > > > > At present, there is only one TESLA protocol that would use > > > > > MIKEY, > > > > > the ESP variant would use IKE v2, I expect. I would like to see > > > > > one comprehensive document for SRTP TESLA. I'd also like to see > > > > > some cooperative work on getting an SRTP TESLA prototype, which > > > > > presumably would include signaling and key management. > > > > > > > > > > Mark > > > > > On Oct 22, 2004, at 5:25 AM, Steffen Fries wrote: > > > > > > > > > > > Hi Mark, > > > > > > > > > > > > sorry for the dely. > > > > > > > > > > > > Hm, merging it with the TESLA ID would bind the applicability > > > > > > to SRTP only. Wouldn't it make more sense to have it stand > > > > > > alone to be able to use it also for scenarios, were TESLA is > > > > > > used without SRTP? > > > > > > > > > > > > Ciao > > > > > > Steffen > > > > > > > > > > > > > > > > > > Copies to: =09Thomas Hardjono , > > > > > > msec@securemulticast.org, > > > > > > =09canetti , > > > > > > =09hannes Tschofenig , > > > > > > =09Elisabetta Carrara (KI/EAB) > > > > > > > > > > > > From: =09Mark Baugher > > > > > > Subject: =09Re: [MSEC] new draft avaialable for > > > > > > bootstrapping TESLA Date sent: =09Wed, 20 Oct 2004 13:15:5= 7 > > > > > > -0700 To: > > > > > > =09steffen.fries@siemens.com > > > > > > > > > > > >> This looks cool. Why don't we merge this into the TESLA I-D > > > > > >> and I'll add a section on sdescriptions? > > > > > >> > > > > > >> Mark > > > > > >> On Oct 19, 2004, at 11:42 PM, Steffen Fries wrote: > > > > > >> > > > > > >>> Hi, > > > > > >>> > > > > > >>> > > > > > >>> please find the Internet draft in the attachment or at the > > > > > >>> given URL. We would like to discuss this approach on the > > > > > >>> mailing list. Please sent comments! > > > > > >>> > > > > > >>> > > > > > >>> Title > > > > > >>> > > > > > >>> > > > > > >>> =A0 Bootstrapping TESLA > > > > > >>> > > > > > >>> > > > > > >>> Abstract > > > > > >>> > > > > > >>> > > > > > >>> =A0 With the Timed Efficient Stream Loss-tolerant > > > > > >>> Authentication =A0 protocol (TESLA) a protocol for providing > > > > > >>> source authentication =A0 in multicast scenarios was > > > > > >>> introduced.=A0 A mapping for TESLA to =A0 the Secure Real-ti= me > > > > > >>> Transport Protocol (SRTP) has been =A0 published which > > > > > >>> assumes that some TESLA parameters are made =A0 available by > > > > > >>> out-of-band mechanisms.=A0 This document describes =A0 paylo= ads > > > > > >>> for bootstrapping these parameters with the help of =A0 the > > > > > >>> Multimedia Internet KEYing (MIKEY) > > > > > >>> > > > > > >>> > > > > > >>> Authors: > > > > > >>> > > > > > >>> > > > > > >>> =A0 S. Fries > > > > > >>> =A0 H. Tschofenig > > > > > >>> > > > > > >>> > > > > > >>> URL: > > > > > >>> > > > > > >>> > > > > > >>> =A0 http://www.tschofenig.com/drafts/draft-fries-msec- > > > > > >>> bootstrapping-tesla-00.txt > > > > > >>> =A0 http://www.tschofenig.com/drafts/draft-fries-msec- > > > > > >>> bootstrapping-tesla-00.html > > > > > >>> > > > > > >>> > > > > > >>> Best Regards, > > > > > >>> Steffen Fries > > > > > >>> _______________________________________________ > > > > > >>> msec mailing list > > > > > >>> msec@securemulticast.org > > > > > >>> http://six.pairlist.net/mailman/listinfo/msec > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----------------------------------------------------------- > > > Steffen Fries, Siemens AG, CT IC 3 > > > Otto-Hahn-Ring 6, D-81730 Munich, Germany > > > Phone: (+49) 89 / 636-53403, > > > Fax : (+49) 89 / 636-48000 > > > Email: Steffen.Fries@siemens.com > > > ----------------------------------------------------------- > > > > > > > > > > > > > > ----------------------------------------------------------- > Steffen Fries, Siemens AG, CT IC 3 > Otto-Hahn-Ring 6, D-81730 Munich, Germany > Phone: (+49) 89 / 636-53403, > Fax : (+49) 89 / 636-48000 > Email: Steffen.Fries@siemens.com > ----------------------------------------------------------- > > > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Oct 26 17:45:57 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29934 for ; Tue, 26 Oct 2004 17:45:56 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id A6D038C911; Tue, 26 Oct 2004 17:45:35 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 508F28C90E for ; Tue, 26 Oct 2004 17:45:35 -0400 (EDT) Received: (qmail 26058 invoked by uid 3269); 26 Oct 2004 21:45:35 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 26055 invoked from network); 26 Oct 2004 21:45:35 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by klesh.pair.com with SMTP; 26 Oct 2004 21:45:35 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 26 Oct 2004 15:04:28 +0000 X-BrightmailFiltered: true Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9QLjTk2003915; Tue, 26 Oct 2004 14:45:30 -0700 (PDT) Received: from [192.168.0.10] (sjc-vpn5-464.cisco.com [10.21.89.208]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id i9QLl9BO026631; Tue, 26 Oct 2004 14:47:09 -0700 In-Reply-To: References: <41762511.18921.19C5E4A7@localhost> <41791875.15687.19C755@localhost> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <5A556B98-2798-11D9-9229-000A95DC10F2@cisco.com> Content-Transfer-Encoding: quoted-printable From: Mark Baugher Subject: Re: [MSEC] new draft avaialable for bootstrapping TESLA Date: Tue, 26 Oct 2004 14:45:28 -0700 To: canetti X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1098827230.277785"; x:"432200"; a:"rsa-sha1"; b:"nofws:5055"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"l2LW5sA0k72zYHufgCkYbZzLhbpSaUzwc9LOeBTUkBILjOs/h4DwfrP94gtv6" "1fYnAB0hCq2ZHH1Uui7F1Uru0cIT+CywpAuKnKBuCXRcswHFqxi1OMOi5eBjh" "FmfWjbBcYJuH0A0n4mmDhewHlgZCTI32Zv1WVJexh74CfGDaA="; c:"From: Mark Baugher "; c:"Subject: Re: [MSEC] new draft avaialable for bootstrapping TESLA"; c:"Date: Tue, 26 Oct 2004 14:45:28 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Cc: Elisabetta Carrara , 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 Content-Transfer-Encoding: quoted-printable On Oct 23, 2004, at 8:18 PM, canetti wrote: > > I can certainly see arguments both ways regarding whether to join the=20= > new > draft with the current tesla-srtp or not. This would be something to > discuss and decide in DC. > > I wanted to relate to another issue in the new draft. In fact, the=20 > issue > is relevant also to tesla-srtp: The draft misses one important=20 > parameter: > before the receiver can do anything, it must have a bound on the time > difference its local clock and the senders's clock. (This value is=20 > denoted > D_t in the tesla-intro draft.) Setting this value could be tricky - it=20= > may > need a roundtrip receiver->sender->receiver. > > Looking again at the tesla-srtp draft, I didn't find this parameter=20 > there > either. this parameter is necessary for determining the cutoff time=20 > for a > packet, and in particular in determining if the packet is safe or did=20= > it > arrive too late. I think we're missing that parameter Mark > > Ran > > > On Fri, 22 Oct 2004, Mark Baugher wrote: > >> hi Steffen >> That's true, it _might_ be more modular if it stands alone as a >> separate document. It is also possible that different security >> protocols will have different parameters for TESLA. I don't think=20 >> it's >> necessary and don't think that would be a good thing, but we have >> approached SRTP TESLA as if we were free to invent new parameters or >> reuse existing parameters such as the RTP timestamp (which turned out >> to be infeasible). >> >> This question comes up repeatedly and there is a tradeoff between >> giving the implementer a single document to use versus having several >> that are general purpose. Dan Harkins thought this was a big problem >> with IKE v1. I have heard complaints about GDOI, which assumes >> knowledge of a few other documents (GDOI uses an IKE v1 phase 1 >> exchange, for example). >> >> At present, there is only one TESLA protocol that would use MIKEY, >> the ESP variant would use IKE v2, I expect. I would like to see one >> comprehensive document for SRTP TESLA. I'd also like to see some >> cooperative work on getting an SRTP TESLA prototype, which presumably >> would include signaling and key management. >> >> Mark >> On Oct 22, 2004, at 5:25 AM, Steffen Fries wrote: >> >>> Hi Mark, >>> >>> sorry for the dely. >>> >>> Hm, merging it with the TESLA ID would bind the applicability >>> to SRTP only. Wouldn't it make more sense to have it stand >>> alone to be able to use it also for scenarios, were TESLA is >>> used without SRTP? >>> >>> Ciao >>> Steffen >>> >>> >>> Copies to: Thomas Hardjono , >>> msec@securemulticast.org, >>> canetti , >>> hannes Tschofenig , >>> Elisabetta Carrara (KI/EAB) = >>> From: Mark Baugher >>> Subject: Re: [MSEC] new draft avaialable for = bootstrapping >>> TESLA >>> Date sent: Wed, 20 Oct 2004 13:15:57 -0700 >>> To: steffen.fries@siemens.com >>> >>>> This looks cool. Why don't we merge this into the TESLA I-D and=20 >>>> I'll >>>> add a section on sdescriptions? >>>> >>>> Mark >>>> On Oct 19, 2004, at 11:42 PM, Steffen Fries wrote: >>>> >>>>> Hi, >>>>> >>>>> >>>>> please find the Internet draft in the attachment or at the given >>>>> URL. We would like to discuss this approach on the mailing list. >>>>> Please sent comments! >>>>> >>>>> >>>>> Title >>>>> >>>>> >>>>> =A0 Bootstrapping TESLA >>>>> >>>>> >>>>> Abstract >>>>> >>>>> >>>>> =A0 With the Timed Efficient Stream Loss-tolerant Authentication = =A0 >>>>> protocol (TESLA) a protocol for providing source authentication =A0= >>>>> in multicast scenarios was introduced.=A0 A mapping for TESLA to = =A0 >>>>> the Secure Real-time Transport Protocol (SRTP) has been =A0=20 >>>>> published >>>>> which assumes that some TESLA parameters are made =A0 available = by >>>>> out-of-band mechanisms.=A0 This document describes =A0 payloads = for >>>>> bootstrapping these parameters with the help of =A0 the = Multimedia >>>>> Internet KEYing (MIKEY) >>>>> >>>>> >>>>> Authors: >>>>> >>>>> >>>>> =A0 S. Fries >>>>> =A0 H. Tschofenig >>>>> >>>>> >>>>> URL: >>>>> >>>>> >>>>> =A0 http://www.tschofenig.com/drafts/draft-fries-msec- >>>>> bootstrapping-tesla-00.txt >>>>> =A0 http://www.tschofenig.com/drafts/draft-fries-msec- >>>>> bootstrapping-tesla-00.html >>>>> >>>>> >>>>> Best Regards, >>>>> Steffen Fries >>>>> _______________________________________________ >>>>> 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 Wed Oct 27 02:33:10 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08500 for ; Wed, 27 Oct 2004 02:33:10 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 5DA708CB12; Wed, 27 Oct 2004 02:33:11 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 0E78E8C9A4 for ; Wed, 27 Oct 2004 02:33:10 -0400 (EDT) Received: (qmail 34865 invoked by uid 3269); 27 Oct 2004 06:33:09 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 34862 invoked from network); 27 Oct 2004 06:33:09 -0000 Received: from penguin.ericsson.se (193.180.251.47) by klesh.pair.com with SMTP; 27 Oct 2004 06:33:09 -0000 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9R6X8fM016747 for ; Wed, 27 Oct 2004 08:33:08 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Oct 2004 08:33:08 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 27 Oct 2004 08:33:08 +0200 Message-ID: <4E85E49D1F0CBF4F96EA08E335750D7D0C3BCBC7@Esealnt877.al.sw.ericsson.se> From: "Elisabetta Carrara (KI/EAB)" To: "'Mark Baugher'" , canetti Subject: RE: [MSEC] new draft avaialable for bootstrapping TESLA Date: Wed, 27 Oct 2004 08:26:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 27 Oct 2004 06:33:08.0236 (UTC) FILETIME=[D28E2CC0:01C4BBEE] 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 Ran pointed out to me in San Diego that the parameter was missing, so the new version has it. /E >-----Original Message----- >From: Mark Baugher [mailto:mbaugher@cisco.com] >Sent: den 26 oktober 2004 23:45 >To: canetti >Cc: Elisabetta Carrara (KI/EAB); msec@securemulticast.org >Subject: Re: [MSEC] new draft avaialable for bootstrapping TESLA > > > >On Oct 23, 2004, at 8:18 PM, canetti wrote: > >> >> I can certainly see arguments both ways regarding whether to >join the >> new >> draft with the current tesla-srtp or not. This would be something to >> discuss and decide in DC. >> >> I wanted to relate to another issue in the new draft. In fact, the >> issue >> is relevant also to tesla-srtp: The draft misses one important >> parameter: >> before the receiver can do anything, it must have a bound on the time >> difference its local clock and the senders's clock. (This value is >> denoted >> D_t in the tesla-intro draft.) Setting this value could be >tricky - it >> may >> need a roundtrip receiver->sender->receiver. >> >> Looking again at the tesla-srtp draft, I didn't find this parameter >> there >> either. this parameter is necessary for determining the cutoff time >> for a >> packet, and in particular in determining if the packet is >safe or did >> it >> arrive too late. > >I think we're missing that parameter > >Mark >> >> Ran >> >> >> On Fri, 22 Oct 2004, Mark Baugher wrote: >> >>> hi Steffen >>> That's true, it _might_ be more modular if it stands alone as a >>> separate document. It is also possible that different security >>> protocols will have different parameters for TESLA. I don't think >>> it's >>> necessary and don't think that would be a good thing, but we have >>> approached SRTP TESLA as if we were free to invent new parameters or >>> reuse existing parameters such as the RTP timestamp (which >turned out >>> to be infeasible). >>> >>> This question comes up repeatedly and there is a tradeoff between >>> giving the implementer a single document to use versus >having several >>> that are general purpose. Dan Harkins thought this was a >big problem >>> with IKE v1. I have heard complaints about GDOI, which assumes >>> knowledge of a few other documents (GDOI uses an IKE v1 phase 1 >>> exchange, for example). >>> >>> At present, there is only one TESLA protocol that would >use MIKEY, >>> the ESP variant would use IKE v2, I expect. I would like to see one >>> comprehensive document for SRTP TESLA. I'd also like to see some >>> cooperative work on getting an SRTP TESLA prototype, which >presumably >>> would include signaling and key management. >>> >>> Mark >>> On Oct 22, 2004, at 5:25 AM, Steffen Fries wrote: >>> >>>> Hi Mark, >>>> >>>> sorry for the dely. >>>> >>>> Hm, merging it with the TESLA ID would bind the applicability >>>> to SRTP only. Wouldn't it make more sense to have it stand >>>> alone to be able to use it also for scenarios, were TESLA is >>>> used without SRTP? >>>> >>>> Ciao >>>> Steffen >>>> >>>> >>>> Copies to: Thomas Hardjono , >>>> msec@securemulticast.org, >>>> canetti , >>>> hannes Tschofenig , >>>> Elisabetta Carrara (KI/EAB) > >>>> From: Mark Baugher >>>> Subject: Re: [MSEC] new draft avaialable for >bootstrapping >>>> TESLA >>>> Date sent: Wed, 20 Oct 2004 13:15:57 -0700 >>>> To: steffen.fries@siemens.com >>>> >>>>> This looks cool. Why don't we merge this into the TESLA I-D and >>>>> I'll >>>>> add a section on sdescriptions? >>>>> >>>>> Mark >>>>> On Oct 19, 2004, at 11:42 PM, Steffen Fries wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> please find the Internet draft in the attachment or at the given >>>>>> URL. We would like to discuss this approach on the mailing list. >>>>>> Please sent comments! >>>>>> >>>>>> >>>>>> Title >>>>>> >>>>>> >>>>>>   Bootstrapping TESLA >>>>>> >>>>>> >>>>>> Abstract >>>>>> >>>>>> >>>>>>   With the Timed Efficient Stream Loss-tolerant Authentication   >>>>>> protocol (TESLA) a protocol for providing source >authentication   >>>>>> in multicast scenarios was introduced.  A mapping for TESLA to   >>>>>> the Secure Real-time Transport Protocol (SRTP) has been   >>>>>> published >>>>>> which assumes that some TESLA parameters are made   available by >>>>>> out-of-band mechanisms.  This document describes   payloads for >>>>>> bootstrapping these parameters with the help of   the Multimedia >>>>>> Internet KEYing (MIKEY) >>>>>> >>>>>> >>>>>> Authors: >>>>>> >>>>>> >>>>>>   S. Fries >>>>>>   H. Tschofenig >>>>>> >>>>>> >>>>>> URL: >>>>>> >>>>>> >>>>>>   http://www.tschofenig.com/drafts/draft-fries-msec- >>>>>> bootstrapping-tesla-00.txt >>>>>>   http://www.tschofenig.com/drafts/draft-fries-msec- >>>>>> bootstrapping-tesla-00.html >>>>>> >>>>>> >>>>>> Best Regards, >>>>>> Steffen Fries >>>>>> _______________________________________________ >>>>>> 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 Wed Oct 27 03:17:40 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11938 for ; Wed, 27 Oct 2004 03:17:40 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 600B38CC43; Wed, 27 Oct 2004 03:17:41 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id BCCEC8CC3B for ; Wed, 27 Oct 2004 03:17:39 -0400 (EDT) Received: (qmail 41060 invoked by uid 3269); 27 Oct 2004 07:17:39 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 41057 invoked from network); 27 Oct 2004 07:17:39 -0000 Received: from thoth.sbs.de (192.35.17.2) by klesh.pair.com with SMTP; 27 Oct 2004 07:17:39 -0000 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id i9R7HUfO031958; Wed, 27 Oct 2004 09:17:30 +0200 Received: from mchn070c (mhpaba5c.mchp.siemens.de [139.23.204.46]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id i9R7HTYO009131; Wed, 27 Oct 2004 09:17:29 +0200 From: "Steffen Fries" Organization: Siemens AG To: canetti Date: Wed, 27 Oct 2004 09:17:25 +0200 MIME-Version: 1.0 Subject: Re: [MSEC] new draft avaialable for bootstrapping TESLA Message-ID: <417F67A5.28897.4C44A83@localhost> Priority: normal In-reply-to: References: <417E6E27.13924.F5B7C5@localhost> X-mailer: Pegasus Mail for Windows (4.21c) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: Quoted-printable Content-description: Mail message body Cc: Elisabetta Carrara , msec@securemulticast.org, hannes Tschofenig , Mark Baugher , Thomas Hardjono X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: steffen.fries@siemens.com 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 Content-Transfer-Encoding: Quoted-printable Hi Ran, yes, discussing both options is fine I think. I will include it in the next version of the draft. Regards Steffen Date sent: Tue, 26 Oct 2004 13:09:54 -0400 (EDT) From: canetti To: Steffen Fries Copies to: Mark Baugher , Thomas Hardjono , msec@securemulticast.org= , hannes Tschofenig , Elisabetta Carrara Subject: Re: [MSEC] new draft avaialable for bootstrapping TESLA > > Steffen, > > Perhaps you can discuss both options. Option 2 requires a light > surgery to MIKEY (specifying exactly how the piggybacking is done.) > > In general, MIKEY makes a somewhat milder use of timestamping than > TESLA. MIKEY only uses the timestamping to avoid replay, and thus it > does not need a flow from the receiver to the sender. TESLA needs this > back flow to get the upper bound on the time difference. > > Ran > > > > > On Tue, 26 Oct 2004, Steffen Fries wrote: > > > Hi Ran > > > > MIKEY also recommends using NTP for time synchronization. This > > could be done in group based communication scenarios via a GCKS as > > you pointed out in option 1. > > > > Providing a piggyback mechanism on top of MIKEY may not be work for > > every case as MIKEY runs with two messages at most. Imagine that a > > client opens a media session with the a media data provider and acts > > as MIKEY initiator. In this case both could piggyback the timestamps > > as described in section 3.3.1 in the TESLA intro draft. After > > receiving the MIKEY responder message the client would be able to > > calculate D_t. If on the other hand the media data provider acts as > > a MIKEY initiator the client would not be able to follow the example > > from section 3.3.1, without receiving an additional message > > (carrying t_s, t_r). > > > > I would suggest going with option 1 using out of band mechanisms > > like NTP or SNTP as MIKEY already needs to solve the problem of time > > synchronization too. > > > > Regards > > Steffen > > > > > > > > Date sent: Mon, 25 Oct 2004 15:39:39 -0400 (EDT) > > From: canetti > > To: Steffen Fries > > Copies to: Mark Baugher , > > Thomas Hardjono , > > msec@securemulticast.org, hannes Tschofenig > > , Elisabetta Carrara > > > > Subject: Re: [MSEC] new draft avaialable for bootstrapping > > TESLA > > > > > > > > Steffen, > > > > > > I dont think that a simple MIKEY timestamp would suffice here. The > > > MIKEY timestamp only records the local time at the sender at the > > > time of sending. In contrast, what the receiver needs for TESLA is > > > an upper bound on the difference (sender's local time - receiver's > > > local time). That is, the receiver needs to know that if its local > > > time is T then the sender's local time is at MOST T+D_t. > > > > > > In order to get an upper bound on D_t there needs to be some > > > communication from the receiver to the sender. Alternatively, if a > > > GCKS is used, then it's ok to have a communication from the > > > receiver to the GCKS. > > > > > > I can think of two things we can do: > > > > > > 1. assume that the value D_t is computed using means external to > > > MIKEY and MIKEY only communicates the already-known value. (This > > > would make sense if, say, there was already some interaction > > > between the sender and receiver, or between a GCKS and the > > > sender.) 2. use the interactive (two-message) variant of MIKEY, > > > and piggyback an exchange of timing messages on the two MIKEY > > > messages. > > > > > > Any other ideas? > > > > > > Ran > > > > > > On Mon, 25 Oct 2004, Steffen Fries wrote: > > > > > > > Hi Ran, > > > > > > > > okay, I see your point. > > > > > > > > MIKEY already provides timestamps as part of the MIKEY payload, > > > > which is used in the context of MIKEY to detect replay. This > > > > also requires a loosly time synchronization. I thought that this > > > > is also sufficient for TESLA. Do you think it would be enough to > > > > add a section explaining this? > > > > > > > > Regards > > > > Steffen > > > > > > > > > > > > > > > > Date sent: Sat, 23 Oct 2004 23:18:10 -0400 (EDT) > > > > From: canetti > > > > To: Mark Baugher > > > > Copies to: steffen.fries@siemens.com, Thomas Hardjono > > > > , > > > > msec@securemulticast.org, > > > > hannes Tschofenig , > > > > Elisabetta Carrara > > > > Subject: Re: [MSEC] new draft avaialable for > > > > bootstrapping TESLA > > > > > > > > > > > > > > I can certainly see arguments both ways regarding whether to > > > > > join the new draft with the current tesla-srtp or not. This > > > > > would be something to discuss and decide in DC. > > > > > > > > > > I wanted to relate to another issue in the new draft. In fact, > > > > > the issue is relevant also to tesla-srtp: The draft misses one > > > > > important parameter: before the receiver can do anything, it > > > > > must have a bound on the time difference its local clock and > > > > > the senders's clock. (This value is denoted D_t in the > > > > > tesla-intro draft.) Setting this value could be tricky - it > > > > > may need a roundtrip receiver->sender->receiver. > > > > > > > > > > Looking again at the tesla-srtp draft, I didn't find this > > > > > parameter there either. this parameter is necessary for > > > > > determining the cutoff time for a packet, and in particular in > > > > > determining if the packet is safe or did it arrive too late. > > > > > > > > > > Ran > > > > > > > > > > > > > > > On Fri, 22 Oct 2004, Mark Baugher wrote: > > > > > > > > > > > hi Steffen > > > > > > That's true, it _might_ be more modular if it stands > > > > > > alone as a > > > > > > separate document. It is also possible that different > > > > > > security protocols will have different parameters for TESLA. > > > > > > I don't think it's necessary and don't think that would be > > > > > > a good thing, but we have approached SRTP TESLA as if we > > > > > > were free to invent new parameters or reuse existing > > > > > > parameters such as the RTP timestamp (which turned out to be > > > > > > infeasible). > > > > > > > > > > > > This question comes up repeatedly and there is a tradeoff > > > > > > between > > > > > > giving the implementer a single document to use versus > > > > > > having several that are general purpose. Dan Harkins > > > > > > thought this was a big problem with IKE v1. I have heard > > > > > > complaints about GDOI, which assumes knowledge of a few > > > > > > other documents (GDOI uses an IKE v1 phase 1 exchange, for > > > > > > example). > > > > > > > > > > > > At present, there is only one TESLA protocol that would > > > > > > use MIKEY, > > > > > > the ESP variant would use IKE v2, I expect. I would like to > > > > > > see one comprehensive document for SRTP TESLA. I'd also > > > > > > like to see some cooperative work on getting an SRTP TESLA > > > > > > prototype, which presumably would include signaling and key > > > > > > management. > > > > > > > > > > > > Mark > > > > > > On Oct 22, 2004, at 5:25 AM, Steffen Fries wrote: > > > > > > > > > > > > > Hi Mark, > > > > > > > > > > > > > > sorry for the dely. > > > > > > > > > > > > > > Hm, merging it with the TESLA ID would bind the > > > > > > > applicability to SRTP only. Wouldn't it make more sense to > > > > > > > have it stand alone to be able to use it also for > > > > > > > scenarios, were TESLA is used without SRTP? > > > > > > > > > > > > > > Ciao > > > > > > > Steffen > > > > > > > > > > > > > > > > > > > > > Copies to: Thomas Hardjono , > > > > > > > msec@securemulticast.org, > > > > > > > canetti , > > > > > > > hannes Tschofenig , > > > > > > > Elisabetta Carrara (KI/EAB) > > > > > > > > > > > > > > From: Mark Baugher > > > > > > > Subject: Re: [MSEC] new draft avaialable for > > > > > > > bootstrapping TESLA Date sent: Wed, 20 Oct 2004 > > > > > > > 13:15:57 -0700 To: > > > > > > > steffen.fries@siemens.com > > > > > > > > > > > > > >> This looks cool. Why don't we merge this into the TESLA > > > > > > >> I-D and I'll add a section on sdescriptions? > > > > > > >> > > > > > > >> Mark > > > > > > >> On Oct 19, 2004, at 11:42 PM, Steffen Fries wrote: > > > > > > >> > > > > > > >>> Hi, > > > > > > >>> > > > > > > >>> > > > > > > >>> please find the Internet draft in the attachment or at > > > > > > >>> the given URL. We would like to discuss this approach on > > > > > > >>> the mailing list. Please sent comments! > > > > > > >>> > > > > > > >>> > > > > > > >>> Title > > > > > > >>> > > > > > > >>> > > > > > > >>> =A0 Bootstrapping TESLA > > > > > > >>> > > > > > > >>> > > > > > > >>> Abstract > > > > > > >>> > > > > > > >>> > > > > > > >>> =A0 With the Timed Efficient Stream Loss-tolerant > > > > > > >>> Authentication =A0 protocol (TESLA) a protocol for > > > > > > >>> providing source authentication =A0 in multicast > > > > > > >>> scenarios was introduced.=A0 A mapping for TESLA to =A0 t= he > > > > > > >>> Secure Real-time Transport Protocol (SRTP) has been =A0 > > > > > > >>> published which assumes that some TESLA parameters are > > > > > > >>> made =A0 available by out-of-band mechanisms.=A0 This > > > > > > >>> document describes =A0 payloads for bootstrapping these > > > > > > >>> parameters with the help of =A0 the Multimedia Internet > > > > > > >>> KEYing (MIKEY) > > > > > > >>> > > > > > > >>> > > > > > > >>> Authors: > > > > > > >>> > > > > > > >>> > > > > > > >>> =A0 S. Fries > > > > > > >>> =A0 H. Tschofenig > > > > > > >>> > > > > > > >>> > > > > > > >>> URL: > > > > > > >>> > > > > > > >>> > > > > > > >>> =A0 http://www.tschofenig.com/drafts/draft-fries-msec- > > > > > > >>> bootstrapping-tesla-00.txt > > > > > > >>> =A0 http://www.tschofenig.com/drafts/draft-fries-msec- > > > > > > >>> bootstrapping-tesla-00.html > > > > > > >>> > > > > > > >>> > > > > > > >>> Best Regards, > > > > > > >>> Steffen Fries > > > > > > >>> _______________________________________________ > > > > > > >>> msec mailing list > > > > > > >>> msec@securemulticast.org > > > > > > >>> http://six.pairlist.net/mailman/listinfo/msec > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----------------------------------------------------------- > > > > Steffen Fries, Siemens AG, CT IC 3 > > > > Otto-Hahn-Ring 6, D-81730 Munich, Germany > > > > Phone: (+49) 89 / 636-53403, > > > > Fax : (+49) 89 / 636-48000 > > > > Email: Steffen.Fries@siemens.com > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > ----------------------------------------------------------- > > Steffen Fries, Siemens AG, CT IC 3 > > Otto-Hahn-Ring 6, D-81730 Munich, Germany > > Phone: (+49) 89 / 636-53403, > > Fax : (+49) 89 / 636-48000 > > Email: Steffen.Fries@siemens.com > > ----------------------------------------------------------- > > > > > > > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec