From msec-admin@securemulticast.org Fri Mar 1 12:20:39 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07748 for ; Fri, 1 Mar 2002 12:20:39 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 91FCC53DD2; Fri, 1 Mar 2002 12:18:04 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 6931753A93 for ; Fri, 1 Mar 2002 12:17:48 -0500 (EST) Received: (qmail 56156 invoked by uid 3269); 1 Mar 2002 17:18:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 56153 invoked from network); 1 Mar 2002 17:18:40 -0000 Received: from zrc2s0jx.nortelnetworks.com (47.103.122.112) by klesh.pair.com with SMTP; 1 Mar 2002 17:18:40 -0000 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g21HHvc23517; Fri, 1 Mar 2002 11:17:57 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Mar 2002 11:17:57 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A0311A175@zrc2c000.us.nortel.com> From: "Peter Barany" To: "'fredrik.lindholm@era.ericsson.se'" , "'jari.arkko@ericsson.com'" , "'elisabetta.carrara@era.ericsson.se'" Cc: "'msec@securemulticast.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C145.07459770" Subject: [MSEC] Question concerning MIKEY Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 1 Mar 2002 11:17:56 -0600 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1C145.07459770 Content-Type: text/plain; charset="iso-8859-1" Hi, I have a quick question concerning the operation of MIKEY v00 with SRTP v02. In section 3.3 of the SRTP I-D v02, it mentions that "Authentication MUST be applied to RTCP as it is the control protocol ... " Also, earlier in the same section of the SRTP I-D v02, it mentions that " ... SRTCP authentication is mandatory. The authentication transforms and related parameters (e.g., key size) shall be the same selected for the protection of the associated SRTP stream(s) (when SRTP is authenticated too)." I am unclear about what authentication algorithm will be used for SRTCP if in the MIKEY SP payload the parameter "auth alg" is set to "NULL" (indicating that the SRTP packets will not be authenticated). Regards, Pete ------_=_NextPart_001_01C1C145.07459770 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Question concerning MIKEY

Hi,

I have a quick question concerning the = operation of MIKEY v00 with SRTP v02.

In section 3.3 of the SRTP I-D v02, it = mentions that "Authentication MUST be applied to RTCP as it is the = control protocol ... "

Also, earlier in the same section of = the SRTP I-D v02, it mentions that " ... SRTCP authentication is = mandatory. The authentication transforms and related parameters (e.g., = key size) shall be the same selected for the protection of the = associated SRTP stream(s) (when SRTP is authenticated = too)."

I am unclear about what authentication = algorithm will be used for SRTCP if in the MIKEY SP payload the = parameter "auth alg" is set to "NULL" (indicating = that the SRTP packets will not be authenticated).

Regards,

Pete

------_=_NextPart_001_01C1C145.07459770-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Mar 1 13:06:22 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10905 for ; Fri, 1 Mar 2002 13:06:21 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6109A53E32; Fri, 1 Mar 2002 13:01:11 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 2973D53DE9 for ; Fri, 1 Mar 2002 13:00:21 -0500 (EST) Received: (qmail 62264 invoked by uid 3269); 1 Mar 2002 18:01:13 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 62261 invoked from network); 1 Mar 2002 18:01:13 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 1 Mar 2002 18:01:13 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g21I0Wx22166; Fri, 1 Mar 2002 10:00:32 -0800 (PST) Received: from mbaugher-w2k1.cisco.com ([10.34.251.94]) by mira-sjc5-6.cisco.com (Mirapoint) with SMTP id AAZ58642; Fri, 1 Mar 2002 09:58:52 -0800 (PST) Message-Id: <4.3.2.7.2.20020301095653.04a66798@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Peter Barany" From: Mark Baugher Subject: Re: [MSEC] Question concerning MIKEY Cc: "'fredrik.lindholm@era.ericsson.se'" , "'jari.arkko@ericsson.com'" , "'elisabetta.carrara@era.ericsson.se'" , "'msec@securemulticast.org'" In-Reply-To: <1B54FA3A2709D51195C800508BF9386A0311A175@zrc2c000.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 01 Mar 2002 09:58:05 -0800 At 11:17 AM 3/1/2002 -0600, Peter Barany wrote: >Hi, > >I have a quick question concerning the operation of MIKEY v00 with SRTP v02. > >In section 3.3 of the SRTP I-D v02, it mentions that "Authentication MUST >be applied to RTCP as it is the control protocol ... " > >Also, earlier in the same section of the SRTP I-D v02, it mentions that " >... SRTCP authentication is mandatory. The authentication transforms and >related parameters (e.g., key size) shall be the same selected for the >protection of the associated SRTP stream(s) (when SRTP is authenticated too)." > >I am unclear about what authentication algorithm will be used for SRTCP if >in the MIKEY SP payload the parameter "auth alg" is set to "NULL" >(indicating that the SRTP packets will not be authenticated). SRTP defaults to HMAC-SHA1. Mark >Regards, > >Pete _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sat Mar 2 05:51:24 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27386 for ; Sat, 2 Mar 2002 05:51:23 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 20B1D53BD5; Sat, 2 Mar 2002 05:50:02 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 9451253579 for ; Sat, 2 Mar 2002 05:49:50 -0500 (EST) Received: (qmail 25511 invoked by uid 3269); 2 Mar 2002 10:50:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 25508 invoked from network); 2 Mar 2002 10:50:44 -0000 Received: from albatross-ext.wise.edt.ericsson.se (HELO albatross.wise.edt.ericsson.se) (193.180.251.46) by klesh.pair.com with SMTP; 2 Mar 2002 10:50:44 -0000 Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g22AobZc023978; Sat, 2 Mar 2002 11:50:37 +0100 (MET) Received: from e00d05937ed1e by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id LAA05505; Sat, 2 Mar 2002 11:50:37 +0100 Message-ID: <003a01c1c1d8$07382020$0300a8c0@e00d05937ed1e.telia.com> From: "Fredrik Lindholm" To: "Peter Barany" , Cc: , MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Subject: [MSEC] Re: Question concerning MIKEY Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Sat, 2 Mar 2002 11:50:11 +0100 Content-Transfer-Encoding: 7bit Hi Peter, this has been fixed in the -01 version of MIKEY (i.e. it is possible to set the SRTCP parameters independent of the SRTP). I submitted a new version of MIKEY this Thursday. Until it is available in the archives you may fetch it at: http://standards.ericsson.net/fli/draft-ietf-msec-mikey-01.txt (note also that a new SRTP version was also submitted this week). Except from normal editorial changes, the main changes are due to the support of multiple TEKs and the support of a Re-key SA (and KEK). Some of the most notable changes from the -00 draft: * Support for Re-key SA including KEK transport for all methods. * PK: Envelope approach for encryption of keys (as the size may exceed the limit that can be encrypted with one public-key operation). * Message processing updated * SDP, SIP and RTSP considerations updated * Group section updated * The use of Rand (instead of require a large and random MCS ID) * (SRTP) policies updated * Payload update (to support the above changes) Comments and questions on the new draft are very welcome! Cheers, Fredrik -----Original Message----- From: Peter Barany To: 'fredrik.lindholm@era.ericsson.se' ; 'jari.arkko@ericsson.com' ; 'elisabetta.carrara@era.ericsson.se' Cc: 'msec@securemulticast.org' Date: den 1 mars 2002 18:16 Subject: Question concerning MIKEY >Hi, > >I have a quick question concerning the operation of MIKEY v00 with SRTP >v02. > >In section 3.3 of the SRTP I-D v02, it mentions that "Authentication >MUST be applied to RTCP as it is the control protocol ... " > >Also, earlier in the same section of the SRTP I-D v02, it mentions that >" ... SRTCP authentication is mandatory. The authentication transforms >and related parameters (e.g., key size) shall be the same selected for >the protection of the associated SRTP stream(s) (when SRTP is >authenticated too)." > >I am unclear about what authentication algorithm will be used for SRTCP >if in the MIKEY SP payload the parameter "auth alg" is set to "NULL" >(indicating that the SRTP packets will not be authenticated). > >Regards, > >Pete > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sat Mar 2 10:13:40 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01384 for ; Sat, 2 Mar 2002 10:13:39 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 03E7353747; Sat, 2 Mar 2002 10:09:02 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 815EE536CA for ; Sat, 2 Mar 2002 10:08:06 -0500 (EST) Received: (qmail 48034 invoked by uid 3269); 2 Mar 2002 15:09:01 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 48031 invoked from network); 2 Mar 2002 15:09:00 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 2 Mar 2002 15:09:00 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g22F8T709252 for ; Sat, 2 Mar 2002 10:08:29 -0500 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g22F8TM43552 for ; Sat, 2 Mar 2002 10:08:29 -0500 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id KAA31612 for msec@securemulticast.org; Sat, 2 Mar 2002 10:08:29 -0500 From: Ran Canetti Message-Id: <200203021508.KAA31612@ornavella.watson.ibm.com> To: msec@securemulticast.org Subject: [MSEC] new TESLA draft Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Sat, 2 Mar 2002 10:08:29 -0500 [Co-chair hat off] Folks, Please take a look at the following new I-D: http://search.ietf.org/internet-drafts/draft-perrig-msec-tesla-intro-00.txt It provides a general algorithmic/informational presentation of the TESLA source authentication mechanism. (This is an updated version of the irtf-smug draft from a year ago.) While you read, please keep in mind the following issue. Our planned next step is to write a standards-track draft describing how to implement TESLA in a specific scenario. The question is: how to go about it? In particular, should we first implement TESLA in the application layer or in the IP layer? There are advantages to each option (they are discussed in the draft). We would like to get the WG feedback on the draft in general and on this question in particular. Thanks, Ran _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Mar 5 04:07:52 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21453 for ; Tue, 5 Mar 2002 04:07:52 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id BCE09544DD; Tue, 5 Mar 2002 03:49:32 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id F25B453761 for ; Tue, 5 Mar 2002 02:53:03 -0500 (EST) Received: (qmail 73698 invoked by uid 3269); 5 Mar 2002 07:54:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 73677 invoked from network); 5 Mar 2002 07:54:02 -0000 Received: from albatross-ext.wise.edt.ericsson.se (HELO albatross.wise.edt.ericsson.se) (193.180.251.46) by klesh.pair.com with SMTP; 5 Mar 2002 07:54:02 -0000 Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g257rtZc029429 for ; Tue, 5 Mar 2002 08:53:55 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Mar 05 08:53:28 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Mar 2002 08:53:29 +0100 Message-ID: <0DAEDF148988D411BB980008C7E65D2E04FE40C4@esealnt416> From: "Fredrik Lindholm (ERA)" To: msec@securemulticast.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MSEC] new MIKEY draft Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Tue, 5 Mar 2002 08:47:09 +0100 The new version of MIKEY is now available. Please take a look at it. Questions and comments are very welcome. http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-01.txt Thanks, Fredrik _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Mar 5 04:35:32 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21866 for ; Tue, 5 Mar 2002 04:35:31 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 17AB753761; Tue, 5 Mar 2002 04:34:03 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id DB4645353A for ; Tue, 5 Mar 2002 04:33:30 -0500 (EST) Received: (qmail 84745 invoked by uid 3269); 5 Mar 2002 09:34:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 84739 invoked from network); 5 Mar 2002 09:34:31 -0000 Received: from beamer.mchh.siemens.de (194.138.158.163) by klesh.pair.com with SMTP; 5 Mar 2002 09:34:31 -0000 Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA04877; Tue, 5 Mar 2002 10:34:19 +0100 (MET) Received: from mchh159e.mch4.siemens.de ([139.21.130.171]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA13460; Tue, 5 Mar 2002 10:34:09 +0100 (MET) Received: by mchh159e.mch.pn.siemens.de with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Mar 2002 10:34:27 +0100 Message-ID: From: Euchner Martin ICN M SR 3 To: "'Fredrik Lindholm (ERA)'" , msec@securemulticast.org, Euchner Martin ICN M SR 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MSEC] RE: FW: new draft draft-euchner-MIKEY-DHHMAC-00.txt "HMAC-authent i cat ed Diffie-Hellman for MIKEY" Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Tue, 5 Mar 2002 10:34:20 +0100 Fredik, I've inlined my response and comments below. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur Q.G/SG16 | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 47713 | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/cs27/topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Fredrik Lindholm (ERA) [mailto:Fredrik.Lindholm@era.ericsson.se] Sent: Thursday, February 28, 2002 1:31 PM To: Euchner Martin ICN M SR 3; msec@securemulticast.org Cc: Fredrik Lindholm (ERA) Subject: RE:FW: new draft draft-euchner-MIKEY-DHHMAC-00.txt "HMAC-authenti cat ed Diffie-Hellman for MIKEY" Hi, Some comments on the proposal. I had an off-line discussion with Martin, a few weeks ago. Some of these comments were raised then as well. The primary intention of DHHMAC is not to depend on a PKI (or the use of certificates). By introducing pre-shared keys, a PKI will of course not be needed. However, I personally don't see that MIKEY requires a PKI which is stated in DHHMAC (it is only stated that a PKI may be needed for scalability). There are no requirements in MIKEY that the public-keys must be distributed in a specific way. Of course, I see a few very obvious ways to distribute the public keys: meu> There is nothing wrong with using a PKI of course and I would not want to raise the impression that I dislike PKI at all. It should be obvious that PKI is probably one of the very few security infrastructures which support full, global scalability. If secure group communication has such requirements then PKI is the only viable solution, shared keys would not work then. However, this comes at a tremendous price: availability of a PKI infrastructure, certificate enrolement and certificate distribution mechanisms, revocation mechanisms, certificate management and other tasks. Each of those tasks is already complex and involves quite some effort in terms of implementation. This is among the reasons, why PKI applications and support in systems is still low today and might continue to be so. However, my understanding of the MIKEY scenario is, that there is also a case for small sized groups. Such small sized groups would not need the full flexibility as global large scale groups. They should not require availability of a PKI. And for simplicity, dependency on PKI and certificate management standards should also be minimized. This is the sub-case where the password and shared secret has its strengths and where the symmetric shared secret or the DH-HMAC have their applicability statement (may be this should be made more clear in the drafts). Remember how easy it is to subscribe with a password or to provision and securely distribute a password/shared secret? This is the most widely deployed technique in so many systems. Nearly no implementation overhead is necessary for this (a phone call, a snail mail envelope, an SSL web link etc) is just sufficient for this. I should clarify the dependency on PKI and reword this in my draft. 1) using a "full-fledge" PKI solution (with well defined distribution channels) meu> This is good for the public-key distribution and DH-SIGN methods. As far as real-time certificate validation and revocation is feasible (how should this actually be done???) and if available, I do not see meaningful usage for the symmetric key distribution nor the DH-HMAC either. 2) using self-signed certificates (which will lead to different requirements on the distribution) meu:> This is a valid method how to use the public-key based key distribution without availability of a full-fledged PKI. However, it requires implementation of PKI-based protocols and methods such a certificates, RSA X.509 digital signatures etc. And such protocols are non-trivial to implement interoperable. 3) ignore certificates and share the public-keys in whatever way you like (e.g. manually inserting the key in the user key database like a pre-shared key). The implication of this would be that the public keys would be just like pre-shared keys. In MIKEY, it is not specified how the user key database is built up (as this is viewed as implementation specific), e.g. if it is built only on certificates or if it may contain "hard coded" public keys. Meu:> Right, the configuration is an implementation issue. Let me just say, that many system configuration and management systems can easily handle shared keys and passwords but are will have trouble when it comes to configuring certificates and private/public key pairs. Another comment concerns the scenarios addressed. The DHHMAC will not work for some of these scenarios it will only work in a one-to-one scenario, not in small-size groups as stated. MEU:> The DH-HMAC addresses exactly the same scenario as the symmetric-key distribution variant: peer-to-peer such as in simple-one-to-many (MIKEY-00 section 9.1) or in small-sized groups (MIKEY-00 section 9.2). Thus, I do not see a case where DH-HMAC would not work. Obviously, DH-HMAC (and symmetric key distribution too) does not solve the general, much harder problem of truly scalable group-key management. Both variants address just a very specific sub-case. A comment concerning the HMAC. The HMAC in DHHMAC may be used with either SHA-1 or a truncated SHA-1. Using HMAC with a truncated hash, rather than truncated HMAC with full hash, is highly non-standard. In particular, what are the security effects of truncating the 'inner' hash in the HMAC? It seems that, e.g., under heuristic assumptions on the keying and the use of the padding strings in HMAC, the collision probability (hence also forgery probability), appears to increase by a factor of two. meu:> The truncated HMAC serves the purpose of reduced bandwidth. The computation procedure is according to RFC2104 and is applied in IPSEC as described in RFC 2404 "The Use of HMAC-SHA-1-96 within ESP and AH": >> HMAC-SHA-1-96 produces a 160-bit authenticator value. This 160-bit value can be truncated as described in RFC2104.<< Thus, the (outer) truncated HMAC of 96 bits is conveyed in the DH-HMAC message; there is no truncation on the inner parts of the HMAC function. While I could agree that truncated HMAC increases the collision probability the general assumption and belief is that this would not significantly lower the security, there might even be increased security gains by truncation as pointed out below and as stated in section 5 of RFC 2104: >> A well-known practice with message authentication codes is to truncate the output of the MAC and output only part of the bits (e.g., [MM, ANSI]). Preneel and van Oorschot [PV] show some analytical advantages of truncating the output of hash-based MAC functions. The results in this area are not absolute as for the overall security advantages of truncation. It has advantages (less information on the hash result available to an attacker) and disadvantages (less bits to predict for the attacker). Applications of HMAC can choose to truncate the output of HMAC by outputting the t leftmost bits of the HMAC computation for some parameter t (namely, the computation is carried in the normal way as defined in section 2 above but the end result is truncated to t bits). We recommend that the output length t be not less than half the length of the hash output (to match the birthday attack bound) and not less than 80 bits (a suitable lower bound on the number of bits that need to be predicted by an attacker). We propose denoting a realization of HMAC that uses a hash function H with t bits of output as HMAC-H-t. For example, HMAC-SHA1-80 denotes HMAC computed using the SHA-1 function and with the output truncated to 80 bits. (If the parameter t is not specified, e.g. HMAC-MD5, then it is assumed that all the bits of the hash are output.)<< As such, the truncated HMAC is offered as an option in DH-HMAC in the case where bandwidth is of concern and the security provided is acceptable. So my personal opinion is that the DHHMAC will solve a problem that already can be solved by MIKEY. By using the HMAC instead of signatures will of course decrease the overall computational workload. However, due to the DH computations needed, I don't think a new method can be motivated from an efficiency point of view either. MEU:> In some sense DH-HMAC addresses the same problem as the other MIKEY key management schemes (see above). It is also true, that DH-HMAC provides a simple solution for that key management problem with - fair, mutual key agreement - provisions perfect forward secrecy - without any dependency on a PKI or need to implement public-key based standards - sound performance and reduced bandwidth (in particular with the truncated HMAC) - simple and straight-forward master key provisioning possible. To summarize, none of the other 3 MIKEY methods is able to provide these beneficial properties altogether. This is sufficient motivation for DH-HMAC as an additional key management method in MIKEY. Let me conclude, that each of the four key management variants has its subtle strength and weaknesses, and no single method alone is able to subsume all the features and strengths of the other methods. Best Regards, Fredrik > -----Original Message----- > From: Euchner Martin ICN M SR 3 [mailto:Martin.Euchner@icn.siemens.de] > Sent: den 30 januari 2002 16:57 > To: msec@securemulticast.org > Subject: [MSEC] FW: new draft draft-euchner-MIKEY-DHHMAC-00.txt > "HMAC-authenticat ed Diffie-Hellman for MIKEY" > > > > > > -----Original Message----- > -From: Euchner Martin ICN M SR 3 > Sent: Monday, January 28, 2002 10:36 AM > To: 'Thomas Hardjono'; Euchner Martin ICN M SR 3 > Subject: new draft draft-euchner-MIKEY-DHHMAC-00.txt > "HMAC-authenticated Diffie-Hellman for MIKEY" > Thomas, > > as indicated at the past IETF MSEC WG meeting, I see reasons > for a fourth > key management protocol variant in MIKEY. Please find attached my > corresponding Internet Draft with a proposed specification of > such a scheme. > However, before submitting my ID to the IETF secretariat, I > would like to > consult with you how to best handle this issue. > Please let me hear your advice on whether to make this an > MSEC WG draft or > keep it as an individual draft for the time being? Of course, > I appreciate > any other feedback as well. > > <> > > With kind regards > > Martin Euchner. > -------------------------------------------------------------- > --------- > | Dipl.-Inf. Phone: +49 89 722 55790 > | Martin Euchner Fax : +49 89 722 47713 > | Siemens AG > | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de > | mailto:martin.euchner@ties.itu.int > | Hofmannstr. 51 Intranet: > http://intranet.icn.siemens.de/marketing/sr/pages/122/122_euchner.htm > | D-81359 Muenchen Internet: http://www.siemens.de/ > | __________________ > | Germany > -------------------------------------------------------------- > --------- > > -----Original Message----- > -From: Thomas Hardjono [mailto:thardjono@mediaone.net] > Sent: Monday, January 14, 2002 11:19 PM > To: Euchner Martin ICN M SR 3 > Subject: RE: [MSEC] Draft of minutes from IETF52 Salt Lake City > > Thanks Martin. > cheers, > thomas > ------ > > At 1/14/2002||10:43 AM, you wrote: > >Thomas, > > > >In your meeting report you mentioned the following statement: > > > >Another person (?) mentioned that he has a fourth key > establishment scheme > >in mind. Will write an I-D and post to the mailing list. > > > > > >Actually, it was me myself who made that true statement. > Thus, you can > >frankly substitute my name there. > > > >To be honest, I had not yet time to start writing such an > ID as desired, > but > >I hope, I will find some time and be productive until the > next meeting. > >Watch out" > > > >With kind regards > > > >Martin Euchner. > > >------------------------------------------------------------- > ---------- > >| Dipl.-Inf. Phone: +49 89 722 55790 > >| Martin Euchner Fax : +49 89 722 47713 > >| Siemens AG > >| ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de >| mailto:martin.euchner@ties.itu.int >| Hofmannstr. 51 Intranet: >http://intranet.icn.siemens.de/marketing/sr/pages/122/122_euchner.htm >| D-81359 Muenchen Internet: http://www.siemens.de/ >| __________________ >| Germany >----------------------------------------------------------------------- > > -----Original Message----- >From: Thomas Hardjono [mailto:thardjono@mediaone.net] >Sent: Friday, January 11, 2002 11:42 PM >To: msec@securemulticast.org >Cc: canetti@watson.ibm.com >Subject: [MSEC] Draft of minutes from IETF52 Salt Lake City > > << File: msec52_minutes-draft1.txt >> >Folks, > >Attached is the draft of the minutes from the MSEC WG meeting >at IETF52 in Salt Lake City. > >My apologies for being late. > >Please look at it and comment a.s.a.p. This was my effort at merging >the two pieces of the minutes (Thanks to Dennis and Lakshminath for >consecutively taking the minutes). > >If there are no major objections I might try to include it with the slides >for submission to the formal IETF52 Proceedings (deadline Jan/14). > >All the slides are now on the website, and only this minutes-file >is missing/late. > >cheers, > >thomas >------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Mar 5 08:01:25 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27228 for ; Tue, 5 Mar 2002 08:01:19 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1EDF954377; Tue, 5 Mar 2002 07:59:47 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 72DBD53C20 for ; Tue, 5 Mar 2002 07:57:10 -0500 (EST) Received: (qmail 6593 invoked by uid 3269); 5 Mar 2002 12:58:07 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 6590 invoked from network); 5 Mar 2002 12:58:07 -0000 Received: from penguin-ext.wise.edt.ericsson.se (193.180.251.34) by klesh.pair.com with SMTP; 5 Mar 2002 12:58:07 -0000 Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g25Cw6B23677 for ; Tue, 5 Mar 2002 13:58:06 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Mar 05 13:57:08 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Mar 2002 13:57:08 +0100 Message-ID: <0DAEDF148988D411BB980008C7E65D2E04FE40C8@esealnt416> From: "Fredrik Lindholm (ERA)" To: "'Euchner Martin ICN M SR 3'" , msec@securemulticast.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MSEC] RE: FW: new draft draft-euchner-MIKEY-DHHMAC-00.txt "HMAC-authent i cat ed Diffie-Hellman for MIKEY" Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Tue, 5 Mar 2002 13:56:39 +0100 Hi Martin! (only some small comments inline) >> 3) ignore certificates and share the public-keys in whatever >> way you like (e.g. manually inserting the key in the user >> key database like a pre-shared key). The implication of this >> would be that the public keys would be just like pre-shared >> keys. In MIKEY, it is not specified how the user key database >> is built up (as this is viewed as implementation specific), >> e.g. if it is built only on certificates or if it may >> contain "hard coded" public keys. > > Meu:> Right, the configuration is an implementation issue. > Let me just say, > that many system configuration and management systems can > easily handle > shared keys and passwords but are will have trouble when it comes to > configuring certificates and private/public key pairs. > I still see no difference in sharing a pre-shared key and sharing a public key, except the size. But there is a big step if you introduce passwords (as these are generally memorable). However, if you try to introduce passwords, you will lower the security quite drastically in DH-HMAC. The MAC can be used by an attacker to verify whether the guessed password is correct. So, I think you should point out security implications etc. if you intend to use passwords. >> Another comment concerns the scenarios addressed. The DHHMAC >> will not work for some of these scenarios it will only work >> in a one-to-one scenario, not in small-size groups as stated. > > MEU:> The DH-HMAC addresses exactly the same scenario as the > symmetric-key > distribution variant: peer-to-peer such as in > simple-one-to-many (MIKEY-00 > section 9.1) or in small-sized groups (MIKEY-00 section 9.2). > Thus, I do not > see a case where DH-HMAC would not work. > Obviously, DH-HMAC (and symmetric key distribution too) does > not solve the > general, much harder problem of truly scalable group-key > management. Both > variants address just a very specific sub-case. No, DH-HMAC does not solve the same scenarios as the symmetric-key distribution. Assume we have three parties A, B, and C. A would like to invite B and C to a group communication (i.e. they will share the same TEK) and where A will choose the group key. In the symmetric-key distribution A chooses the PMK key and sends this to the both parties. Both B and C will obtain the same PMK and can derive the same TEK. No problems. In the DH-HMAC we will have the following: A B C to B g^x -------> <------- g^y (A and B will use PMK = g^(xy)) g^a ---------------------------> <--------------------------- g^b (A and C will use PMK = g^(ab)) i.e. this will create completely different PMKs for the communication between A and B, and A and C. This is valid for all groups where the number of members are equal or greater than 3. There are solutions of using DH to create group keys. But that is not something MIKEY is using. > >> A comment concerning the HMAC. The HMAC in DHHMAC may be used >> with either SHA-1 or a truncated SHA-1. Using HMAC with a >> truncated hash, rather than truncated HMAC with full hash, is >> highly non-standard. In particular, what are the security >> effects of truncating the 'inner' hash in the HMAC? It seems >> that, e.g., under heuristic assumptions on the keying and the >> use of the padding strings in HMAC, the collision probability >> (hence also forgery probability), appears to increase by a >> factor of two. > > meu:> The truncated HMAC serves the purpose of reduced bandwidth. The > computation procedure is according to RFC2104 and is applied > in IPSEC as > described in RFC 2404 "The Use of HMAC-SHA-1-96 within ESP and AH": Sorry, I must have misunderstood you. I guess this was due to: "SHA-1-96 produces a slightly shorter HMAC result where the SHA-1 result SHALL be truncated to the 96 leftmost bits when represented in network byte order". I think it would be good to explicitly state that it is not the SHA-1s that are truncated, but the result of the final HMAC. Cheers, Fredrik _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Mar 5 09:21:43 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01083 for ; Tue, 5 Mar 2002 09:21:41 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 48C32536D8; Tue, 5 Mar 2002 09:20:12 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 8345E53C2E for ; Tue, 5 Mar 2002 09:18:18 -0500 (EST) Received: (qmail 15558 invoked by uid 3269); 5 Mar 2002 14:19:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 15555 invoked from network); 5 Mar 2002 14:19:19 -0000 Received: from gorilla.mchh.siemens.de (194.138.158.18) by klesh.pair.com with SMTP; 5 Mar 2002 14:19:19 -0000 Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA13235; Tue, 5 Mar 2002 15:19:10 +0100 (MET) Received: from mchh159e.mch4.siemens.de ([139.21.130.171]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id PAA08143; Tue, 5 Mar 2002 15:18:59 +0100 (MET) Received: by mchh159e.mch.pn.siemens.de with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Mar 2002 15:19:17 +0100 Message-ID: From: Euchner Martin ICN M SR 3 To: "'Fredrik Lindholm (ERA)'" , msec@securemulticast.org, Euchner Martin ICN M SR 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MSEC] RE: FW: new draft draft-euchner-MIKEY-DHHMAC-00.txt "HMAC-authent i cat ed Diffie-Hellman for MIKEY" Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Tue, 5 Mar 2002 15:19:09 +0100 Fredrik Again thank for your comments. You may find my response below. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur Q.G/SG16 | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 47713 | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/cs27/topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Fredrik Lindholm (ERA) [mailto:Fredrik.Lindholm@era.ericsson.se] Sent: Tuesday, March 05, 2002 1:57 PM To: Euchner Martin ICN M SR 3; msec@securemulticast.org Subject: RE: FW: new draft draft-euchner-MIKEY-DHHMAC-00.txt "HMAC-authent i cat ed Diffie-Hellman for MIKEY" Hi Martin! (only some small comments inline) >> 3) ignore certificates and share the public-keys in whatever >> way you like (e.g. manually inserting the key in the user >> key database like a pre-shared key). The implication of this >> would be that the public keys would be just like pre-shared >> keys. In MIKEY, it is not specified how the user key database >> is built up (as this is viewed as implementation specific), >> e.g. if it is built only on certificates or if it may >> contain "hard coded" public keys. > > Meu:> Right, the configuration is an implementation issue. > Let me just say, > that many system configuration and management systems can > easily handle > shared keys and passwords but are will have trouble when it comes to > configuring certificates and private/public key pairs. > I still see no difference in sharing a pre-shared key and sharing a public key, except the size. But there is a big step if you introduce passwords (as these are generally memorable). However, if you try to introduce passwords, you will lower the security quite drastically in DH-HMAC. The MAC can be used by an attacker to verify whether the guessed password is correct. So, I think you should point out security implications etc. if you intend to use passwords. Meu:> It is true and well known, that passwords and static shared secrets introduce a security risk. This was so obvious, that I probably forgot to mention this in my security considerations section (you see, there is more to add...). Of course, there are many security issues related just to password usage and maintenance of shared secrets. You are right, in that passwords of short lengths but also non-random shared secrets are susceptible to systematic attacks where an attackers looks at the MAC. However, MIKEY doesn't say anything about the nature of the shared key such as whether it stems from a password. As things are at the moment (not having looked at MIKEY-01 yet), the issue of passwords is outside of MIKEY. I'm not intending to introduce a password into MIKEY, the password was merely an example in my argumentation. But the question is if this is really user-friendly just to work with some clumsy shared secret bit string rather than a somewhat longer but more readable pass phrase perhaps? The more I'm thinking on this and am debating with you on this issue in general, the more I see the need to address the management, configuration and provisioning issues at least in the security considerations section in both drafts. Another issue related to that should be how often to change the shared secret and how to update it. If our solutions would depend on "real-time" provisioning, then we somehow missed our goal. Yet, assuming the shared secret is sufficiently long, random etc, the systematic guessing and probing attack on the MAC is possible in theory for the symmetric key distribution and the DH-HMAC variant, but probably neglectable in practice (this could also be addressed in both security consideration sections). >> Another comment concerns the scenarios addressed. The DHHMAC >> will not work for some of these scenarios it will only work >> in a one-to-one scenario, not in small-size groups as stated. > > MEU:> The DH-HMAC addresses exactly the same scenario as the > symmetric-key > distribution variant: peer-to-peer such as in > simple-one-to-many (MIKEY-00 > section 9.1) or in small-sized groups (MIKEY-00 section 9.2). > Thus, I do not > see a case where DH-HMAC would not work. > Obviously, DH-HMAC (and symmetric key distribution too) does > not solve the > general, much harder problem of truly scalable group-key > management. Both > variants address just a very specific sub-case. No, DH-HMAC does not solve the same scenarios as the symmetric-key distribution. Assume we have three parties A, B, and C. A would like to invite B and C to a group communication (i.e. they will share the same TEK) and where A will choose the group key. In the symmetric-key distribution A chooses the PMK key and sends this to the both parties. Both B and C will obtain the same PMK and can derive the same TEK. No problems. In the DH-HMAC we will have the following: A B C to B g^x -------> <------- g^y (A and B will use PMK = g^(xy)) g^a ---------------------------> <--------------------------- g^b (A and C will use PMK = g^(ab)) i.e. this will create completely different PMKs for the communication between A and B, and A and C. This is valid for all groups where the number of members are equal or greater than 3. Meu:> Frederick, you are absolutely right here. It was my oversight. Of course Diffie-Hellman as we use it, works only point-to-point and not multipoint. Thus, I should rather say that DH-HMAC works in the same scenario as DH_SIGN, namely point-to-point. Am I right to consider a sender-receiver group with two members as a very special case of a small-group? There are solutions of using DH to create group keys. But that is not something MIKEY is using. MEU:> Yes there is a generalized DH scheme with a nice theory, but I doubt on whether this is a practical scheme (not speaking about real-time at all). > >> A comment concerning the HMAC. The HMAC in DHHMAC may be used >> with either SHA-1 or a truncated SHA-1. Using HMAC with a >> truncated hash, rather than truncated HMAC with full hash, is >> highly non-standard. In particular, what are the security >> effects of truncating the 'inner' hash in the HMAC? It seems >> that, e.g., under heuristic assumptions on the keying and the >> use of the padding strings in HMAC, the collision probability >> (hence also forgery probability), appears to increase by a >> factor of two. > > meu:> The truncated HMAC serves the purpose of reduced bandwidth. The > computation procedure is according to RFC2104 and is applied > in IPSEC as > described in RFC 2404 "The Use of HMAC-SHA-1-96 within ESP and AH": Sorry, I must have misunderstood you. I guess this was due to: "SHA-1-96 produces a slightly shorter HMAC result where the SHA-1 result SHALL be truncated to the 96 leftmost bits when represented in network byte order". I think it would be good to explicitly state that it is not the SHA-1s that are truncated, but the result of the final HMAC. MEU:> Ok, I can clarify this issues in a next version of DH-HMAC. Cheers, Fredrik _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Mar 7 05:46:10 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16281 for ; Thu, 7 Mar 2002 05:46:09 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B5B40536DD; Thu, 7 Mar 2002 05:43:12 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 253FF53584 for ; Thu, 7 Mar 2002 05:41:45 -0500 (EST) Received: (qmail 35748 invoked by uid 3269); 7 Mar 2002 10:42:50 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 35739 invoked from network); 7 Mar 2002 10:42:49 -0000 Received: from alc119.alcatel.be (HELO relay1.alcatel.be) (195.207.101.119) by klesh.pair.com with SMTP; 7 Mar 2002 10:42:49 -0000 Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g27Ag0D23294; Thu, 7 Mar 2002 11:42:00 +0100 (MET) From: annelies.van_moffaert@alcatel.be Subject: Re: [MSEC] new TESLA draft To: Ran Canetti Cc: msec@securemulticast.org Message-ID: X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/07/2002 11:42:15 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Thu, 7 Mar 2002 11:41:56 +0100 Ran, The option to use multiple sets of authentication keys corresponding to different disclosure delays such that receivers with very different RTTs can use different disclosure delays (which I saw in a previous version) is not discussed anymore. Is there a reason to leave this out of the draft or will it be in the technical draft? Isn't there a DoS threat by buffer overflow at the receiver? In the previous draft there was a solution proposed to cope with this which turned the receiver buffering into sender buffereing, providing immediate authentication for the receiver. Apparently this isn't anymore in the latest version of your draft? Do you mean by implementing TESLA in the IP layer, modifying IPsec to support TESLA? Kind regards, Annelies Van Moffaert. Ran Canetti on 02/03/2002 16:08:29 To: msec@securemulticast.org cc: (bcc: Annelies VAN MOFFAERT/BE/ALCATEL) Subject: [MSEC] new TESLA draft [Co-chair hat off] Folks, Please take a look at the following new I-D: http://search.ietf.org/internet-drafts/draft-perrig-msec-tesla-intro-00.txt It provides a general algorithmic/informational presentation of the TESLA source authentication mechanism. (This is an updated version of the irtf-smug draft from a year ago.) While you read, please keep in mind the following issue. Our planned next step is to write a standards-track draft describing how to implement TESLA in a specific scenario. The question is: how to go about it? In particular, should we first implement TESLA in the application layer or in the IP layer? There are advantages to each option (they are discussed in the draft). We would like to get the WG feedback on the draft in general and on this question in particular. Thanks, Ran _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Mar 8 15:51:13 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03042 for ; Fri, 8 Mar 2002 15:51:12 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 195495372C; Fri, 8 Mar 2002 15:49:01 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id D11B25372C for ; Fri, 8 Mar 2002 15:47:03 -0500 (EST) Received: (qmail 23686 invoked by uid 3269); 8 Mar 2002 20:48:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 23683 invoked from network); 8 Mar 2002 20:48:12 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 8 Mar 2002 20:48:12 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g28KlOG08236; Fri, 8 Mar 2002 15:47:24 -0500 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g28KlNM45054; Fri, 8 Mar 2002 15:47:24 -0500 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id PAA28952; Fri, 8 Mar 2002 15:47:22 -0500 From: Ran Canetti Message-Id: <200203082047.PAA28952@ornavella.watson.ibm.com> To: annelies.van_moffaert@alcatel.be, canetti@watson.ibm.com Subject: Re: [MSEC] new TESLA draft Cc: msec@securemulticast.org Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 8 Mar 2002 15:47:22 -0500 Annelies, Thanks for the comments! > From annelies.van_moffaert@alcatel.be Thu Mar 7 05:42:45 2002 > > Ran, > > The option to use multiple sets of authentication keys corresponding to > different disclosure delays such that receivers with very different RTTs > can use different disclosure delays (which I saw in a previous version) is > not discussed anymore. Is there a reason to leave this out of the draft or > will it be in the technical draft? > Isn't there a DoS threat by buffer overflow at the receiver? In the > previous draft there was a solution proposed to cope with this which turned > the receiver buffering into sender buffereing, providing immediate > authentication for the receiver. Apparently this isn't anymore in the > latest version of your draft? Indeed, in a second thought the two features you mentioned (multiple keys for different RTTs, and buffering at the sender) should appear also in the general algorithmic document and not only in the implementation draft(s). Will do. > > Do you mean by implementing TESLA in the IP layer, modifying IPsec to > support TESLA? Basically, yes. More specifically, modify ESP to support TESLA authentication (along the lines of MESP, if you're familiar with the SMUG draft.) Ran > > Kind regards, > Annelies Van Moffaert. > > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Mar 11 05:59:44 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04107 for ; Mon, 11 Mar 2002 05:59:43 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 637C3535AC; Mon, 11 Mar 2002 05:58:02 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id AE1C653597 for ; Mon, 11 Mar 2002 05:57:29 -0500 (EST) Received: (qmail 10532 invoked by uid 3269); 11 Mar 2002 10:58:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10529 invoked from network); 11 Mar 2002 10:58:43 -0000 Received: from beamer.mchh.siemens.de (194.138.158.163) by klesh.pair.com with SMTP; 11 Mar 2002 10:58:43 -0000 Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA19158; Mon, 11 Mar 2002 11:58:31 +0100 (MET) Received: from mchh159e.mch4.siemens.de ([139.21.130.171]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA07954; Mon, 11 Mar 2002 11:58:19 +0100 (MET) Received: by mchh159e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Mar 2002 11:58:36 +0100 Message-ID: From: Euchner Martin ICN M SR 3 To: "'Fredrik Lindholm (ERA)'" , msec@securemulticast.org, "'jari.arkko@ericsson.com'" , "'elisabetta.carrara@era.ericsson.se'" , "'karl.norrman@era.ericsson.se'" , Euchner Martin ICN M SR 3 Subject: RE: [MSEC] new MIKEY draft - Questions and Comments MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 11 Mar 2002 11:58:34 +0100 Dear MIKEY editors, By comparing MIKEY-01 against the previous version, I'm convinced that this new version is indeed a significant improvement. Below I have compiled several questions and comments upon MIKEY that I came across during my review. I've named each question with a number, showed the reference to MIKEY-01.txt with section number and mostly also a short quote >> ...<< from the text. Q.1) Reference: section 1.2. I'm still struggling hard to understand if MIKEY uses the same terminology as SRTP; I'm not yet convinced since the definitions sound differently and the mapping is not obvious. I guess that MIKEY-crypto session corresponds to an SRTP session, but the MIKEY "uni. or bi-directional" notion lets me wonder. Here is my rough guess, how the situation might be: MIKEY SRTP ---------------------------------------------------------------------------- -- Crypto session SRTP session Multimedia crypto session (MCS) RTP session ? ??? cryptographic context Security Association (SA) (MKI) ??? Data SA ??? Re-key SA ??? Pre-Master Key master key Traffic-encrypting key session key/master key? Key Encryption key ??? PMK re-keying key derivation? SPI MKI TMMH-16 TMMH version 2/2 word tag ... ... It might be the case that some of the terms are just local within a document, but certainly several terms affect the key management interface. So I see need to harmonize the terminology across SRTP and MIKEY and to ascertain that the definitions are exactly identical. Q.2) Reference: section 3 >> The signature/MAC is then computed over the entire message (not only the specific values that are shown in the protocol definition).<< I would add "MIKEY payload" in order to avoid the impression that the signature/MAC would be computed over a surrounding SIP or SDP message. Thus the sentence would read: " The signature/MAC is then computed over the entire MIKEY payload message (not only the specific values that are shown in the protocol definition)." Q.3) Reference: sections 3.1, 3.2 and 3.3 All the key management protocols include the ID of the initiator. However, the ISO/IEC 9798-2,3,4 key management protocols that are quite similar to the MIKEY protocols also include the ID of the recipient in the protected exchange. The purpose is to counter reflection attacks. This should be considered for MIKEY too! In any way, a formal security protocol analysis of MIKEY is required to find out whether there are weaknesses in it and whether the protocols fulfils all the stated (and non-stated) security goals. This is not trivial anymore, since the protocols become more and more complex and use quite substantial amount of protected information in the payloads. Q.4) Reference: section 4.1.2, section 4.2.1 My understanding of function P is that the HMAC is actually an HMAC_H(args) where the parameter H refers to the possible hash functions such as SHA1, MD5, SHA256/384/512. Q.5) Reference: section 4.2.1 >> 4.2.1 Hash functions" In order to avoid confusion with the hash functions used for the payload digest and in certificates, let me propose to title section 4.2.1 as "PRF hash functions" and change the sentence to: "MIKEY PRF SHALL use one of the following hash functions: SHA-1 (see [SHA1], MD5 (see [MD5]), SHA256, SHA384, or SHA512 (see [SHA256] for the last three). SHA-1 is default and the only mandatory to implement and support."" Q.6) Reference: section 4.5 >> A problem that then MAY occur is to synchronize the re-keying if an SPI is not used. << The general question related to MIKEY re-keying is how the new TEK is synched-into the SRTP media stream? Some considerations should be given to the following problems: - What should sender and receiver do when the new TEK arrives too late? (continue sending/ receiving, stopping/discarding, queuing). - What should the receiver do when the sender already uses a new TEK but the new TEK has not yet arrived at the receiver (the receiver might not even expect a new TEK)? The synchronization problem is also an issue for SRTP to address. Q.7) Reference: section 5.1.1 and section A.10 >> The initiator tries to guess the responder's capabilities in terms of security algorithms etc.<< My understanding of the new draft is that the initiator actually is able to indicate the used and applied security parameters as part of the conveyed security profile payload. I would describe this method as security parameter/profile indication rather than pure guessing. If that is true, then it appears appropriate to refer to section A.10. Q.8) Reference: section 5.1.2 >> The Initiator SHOULD therefore always be prepared to receive such message back from the responder.<< and section A.1 >> R: flag to indicate whether a response is expected or not (this has only meaning when it is set by the Initiator).<< From reading both parts together, a certain contradiction arises. I guess the situation should be like this: In case the Initiator has set the flag indicating an expected response, he should be always be prepared to receive such message (error or V confirmation message) back from the responder. Otherwise, when the flag was not set, the initiator may expect a response (error message). The other question is how long should the initiator wait for a potential error message returned? And what should the initiator do, when the error message arrives very late, such that the initiator started already sending encrypted media streams (abort?)? Q.9) Reference: section 5.2 >> Create a master payload starting... Concatenate necessary payloads to the master payload...<< I find the notion of master payload slightly confusing since it is not clear if the master payload remains a master payload when adding payloads to it. If the word "master" would be replaced by "MIKEY" the sense would be much clearer. Q.10) Reference: section 6.2 >> It is recommended to use the same identity for both SIP and MIKEY.<< Which SIP identity are you actually referring to? Q.11) Reference: section 6.4 >> Therefore, the interface between MIKEY and these protocols MUST provide certain functionality (however, exactly how the interface looks like is very implementation dependent).<< I believe that this section merely has the notion of an Application Programming interface (API) in mind, rather than a protocol interface. Q.12) Reference: section 7 This section currently does not describe peer-to-peer groups and the application statement for the MIKEY key management protocols. A new section 9.3 could point out the use cases for the Diffie-Hellman protocol but also the applicability of the other 2 protocols and the relation-ship with SIP point-to-point sessions. Q.13) Reference: section 8.6 It could be noted that MIKEY (and SRTP) does not provide any countermeasure against untrusted receivers that are forwarding the decrypted media streams to a 3rd party. Q.14) Reference: section 12 It would be nice to separate out the references into normative ones and informative ones as done in SRTP document. Q.15) Reference: section A.1 >> MIKEY-1 | 0 | Mandatory, Default (see Section 4.1.2-3.)<< The referred section should probably be 4.2.1? Q.16) Reference: section A.2 >> If the transport method used is the pre-shared key method, this Key data transport payload MUST be the last payload in the message (note that the Next payload field MUST be set to Last payload).<< Basically, a situation must be avoided in where a MIKEY message holds several key management payloads one after the other. This does not make sense at all and must be clearly deprecated and considered as an error. More general, similar situations could arise where multiple other payloads might occur in the message that are not defined to coexist according to this draft. Q.17) Reference: section A.7 The third table shows certificate types for X.509, X.509 URL, X.509 Sign and X.509 Encr. It is not fully clear what those types actually refer to and what the meaning is. I could guess that the X.509 URL type would mean that the ID/Certificate field holds an URL pointing to the X.509 certificate. If that is the intention the question is, is this URL plain ASCII or somehow encoded (ISO character set etc)? Further, it is not specified in which encoding format to include the certificate data (base64, plain octet string with ASN.1, ....)? Thus some explanations appear necessary. Q.18) Reference: section A.10.1 >> This policy specifies the policy for SRTP and SRTCP. All defined transform applies to both SRTP and (if used) SRTCP.<< It is my understanding that SRTCP authentication/integrity is always used; thus, the sentence is a bit irritating. Q.19) Reference: section A.10.1 >> TMMH-16 | 1 | Mandatory<< My understanding of SRTP is that TMMH is not mandatory, it is just an option. For clarity, I recommend to add "2 word tag" in the comment column. Q.20) Reference: section A.10.1 >> HMAC-SHA1 | 2 | Mandatory<< Since this HMAC is actually a 32-bit truncated variant I would suggest phrasing it as "HMAC-SHA1-32". Q.21) Reference: section A.14 >> Note that for SRTP usage, the key validity period for a PMK should be specified with either an interval, where the VF/VT length is equal to 6 bytes, or with an SPI (in SRTP denoted as a Master Key Identifier, MKI).<< I guess that it is meant to include here the concatenated values of the sequence number and the timestamp from the RTP header (SEQN || timestamp)? A little more explanation might be useful thus. Q.22) Reference: section Appendix B >> These messages may be included to authenticate the error message. However, before the other peer has been correctly authenticated, it is not recommended that the error messages are sent authenticated (as this would open up for DoS attacks).<< This is true. On the other hand, if error messages are not authenticated, then DoS attacks become a risk as well where false error messages can be injected! This is somehow a no-win situation unfortunately and I do not know how to get out of this without any trade-off. I'm looking forward to your response. In any way, we could discuss these things at length also in Minneapolis... With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur Q.G/SG16 | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 47713 | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/cs27/topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Fredrik Lindholm (ERA) [mailto:Fredrik.Lindholm@era.ericsson.se] Sent: Tuesday, March 05, 2002 8:47 AM To: msec@securemulticast.org Subject: [MSEC] new MIKEY draft The new version of MIKEY is now available. Please take a look at it. Questions and comments are very welcome. http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-01.txt Thanks, Fredrik _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Mar 11 11:19:50 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13250 for ; Mon, 11 Mar 2002 11:19:50 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8B2EC53725; Mon, 11 Mar 2002 11:15:04 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 684D6535F7 for ; Mon, 11 Mar 2002 11:00:32 -0500 (EST) Received: (qmail 54198 invoked by uid 3269); 11 Mar 2002 16:01:47 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 54193 invoked from network); 11 Mar 2002 16:01:46 -0000 Received: from albatross-ext.wise.edt.ericsson.se (HELO albatross.wise.edt.ericsson.se) (193.180.251.46) by klesh.pair.com with SMTP; 11 Mar 2002 16:01:46 -0000 Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2BG1bZc002135 for ; Mon, 11 Mar 2002 17:01:37 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Mon Mar 11 16:40:10 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Mar 2002 16:41:40 +0100 Message-ID: <0DAEDF148988D411BB980008C7E65D2E04FE40E6@esealnt416> From: "Fredrik Lindholm (ERA)" To: "'Euchner Martin ICN M SR 3'" , msec@securemulticast.org Cc: "'jari.arkko@ericsson.com'" , "Elisabetta Carrara (ERA)" , "Karl Norrman (ERA)" , "Fredrik Lindholm (ERA)" Subject: RE: [MSEC] new MIKEY draft - Questions and Comments MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 11 Mar 2002 16:41:00 +0100 Hi, thanks for the thorough review. As you can see, we cut a few of your comments to be able to reduce the size of this message (you can assume that the answer/comment would be yes/ok/correct). > Q.1) Reference: section 1.2. > > I'm still struggling hard to understand if MIKEY uses the > same terminology > as SRTP; I'm not yet convinced since the definitions sound > differently and > the mapping is not obvious. We do not use the same terminology. As MIKEY is part of the MSEC architecture, we have also tried to align the terminology to this (see e.g. GKMARCH draft). > MIKEY SRTP > -------------------------------------------------------------- > -------------- > -- > Crypto session SRTP session correct > Multimedia crypto session (MCS) RTP session ? No. MCS = A set of SRTP sessions (like the multimedia sessions in the RTP sense) > ??? cryptographic context > Security Association (SA) (MKI) ??? > Data SA ??? The Data SA is the input to the security protocol (in this case SRTP). It contains a TEK and the security protocol parameters. SRTP will use the TEK as its Master key. The MKI can be used by SRTP as an SPI to index the MIKEY PMK. The cryptographic context is an internal state in SRTP to store things like the current master key, replay lists, algorithms etc > Re-key SA ??? No direct relation to SRTP. See e.g. GKMARCH. > Pre-Master Key master key No, the PMK is used to derive one or more TEKs (i.e. SRTP Master keys). One TEK = Master key > Traffic-encrypting key session key/master key? TEK = Master key in SRTP. > Key Encryption key ??? No relation to SRTP (used for the Re-key SA, see above). > PMK re-keying key derivation? No relation to SRTP. > SPI MKI No. MKI is a pointer to the TEK only. The support of SPIs in MIKEY is for other security protocols or re-key protocols. > TMMH-16 TMMH version 2/2 word tag yes > ... ... not sure ;-) > > It might be the case that some of the terms are just local within a > document, but certainly several terms affect the key > management interface. > > So I see need to harmonize the terminology across SRTP and > MIKEY and to > ascertain that the definitions are exactly identical. We have chosen to harmonize MIKEY with the rest of the MSEC. So we will not use the same terminology. However, it looks like it might be a good idea to put a small "terminology relation" section in the next version of MIKEY. > Q.3) Reference: sections 3.1, 3.2 and 3.3 > > All the key management protocols include the ID of the > initiator. However, > the ISO/IEC 9798-2,3,4 key management protocols that are > quite similar to > the MIKEY protocols also include the ID of the recipient in > the protected > exchange. The purpose is to counter reflection attacks. This should be > considered for MIKEY too! > > In any way, a formal security protocol analysis of MIKEY is > required to find > out whether there are weaknesses in it and whether the > protocols fulfils all > the stated (and non-stated) security goals. This is not > trivial anymore, > since the protocols become more and more complex and use > quite substantial > amount of protected information in the payloads. Well, it is always good (and necessary) to have security protocols analyzed by several people (and not only by the authors). > Q.6) Reference: section 4.5 >> A problem that then MAY occur is to > synchronize the re-keying if an SPI is not used. << > > The general question related to MIKEY re-keying is how the new TEK is > synched-into the SRTP media stream? See SRTP for more information. But what is recommended is that SRTP uses the MKI (which is a pointer to the master key) or the SRTP index itself for the synchronization, but refer to SRTP. >Some considerations > should be given to > the following problems: > > - What should sender and receiver do when the new TEK arrives > too late? This is not a key management issue. This is something for the security protocol to worry about. MIKEY will not know what is "too late". > - What should the receiver do when the sender already uses a > new TEK but the > new TEK has not yet arrived at the receiver (the receiver > might not even > expect a new TEK)? see above. > The synchronization problem is also an issue for SRTP to address. Indeed. > Q.8) Reference: section 5.1.2 >> The Initiator SHOULD > therefore always be > prepared to receive such message back from the responder.<< > and section A.1 >> R: flag to indicate whether a response is > expected or not > (this has only meaning when it is set by the Initiator).<< Response = Verification message > > From reading both parts together, a certain contradiction arises. > > I guess the situation should be like this: > > In case the Initiator has set the flag indicating an expected > response, he > should be always be prepared to receive such message (error or V > confirmation message) back from the responder. Otherwise, > when the flag was > not set, the initiator may expect a response (error message). > > The other question is how long should the initiator wait for > a potential > error message returned? And what should the initiator do, > when the error > message arrives very late, such that the initiator started > already sending > encrypted media streams (abort?)? In the case of SIP, the error/response message (if any) must be sent back in the SIP response (it is not like the responder can wait with parsing of the message etc. and send back the result when he feels like it). If MIKEY is not used with SIP or RTSP then the reliability etc. should be handled according to Section 5.5. > Q.10) Reference: section 6.2 >> It is recommended to use the > same identity > for both SIP and MIKEY.<< > > Which SIP identity are you actually referring to? The one used in the To/From field. > Q.18) Reference: section A.10.1 >> This policy specifies the > policy for SRTP > and SRTCP. All defined transform applies to both SRTP and (if > used) SRTCP.<< > > It is my understanding that SRTCP authentication/integrity is > always used; > thus, the sentence is a bit irritating. Please read the disclaimer in MIKEY: "NOTE: SRTP was not finalized by the date for this draft's submission. Therefore, these parameters might be an issue for update!" As the issue of whether SRTCP integrity protection should be mandatory or not was not set by the date of the MIKEY submission, this is one of the few inconsistencies that exist. > Q.21) Reference: section A.14 >> Note that for SRTP usage, > the key validity > period for a PMK should be specified with either an interval, > where the > VF/VT length is equal to 6 bytes, or with an SPI (in SRTP denoted as a > Master Key Identifier, MKI).<< > > I guess that it is meant to include here the concatenated > values of the > sequence number and the timestamp from the RTP header (SEQN > || timestamp)? A > little more explanation might be useful thus. No, the 6 bytes (48 bits) denotes the SRTP Index (i.e. ROC and seq nr). Many of your concerns were in relation to SRTP. As you know, SRTP is still a draft, which also have been changed. Therefore, some updating and fixing in MIKEY will be needed. However, SRTP is now in Last Call. After the LC we could probably expect SRTP be stable enough so that we can update the MIKEY draft. Thanks, Fredrik & Elisabetta _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Mar 11 11:56:34 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14623 for ; Mon, 11 Mar 2002 11:56:34 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D51B753794; Mon, 11 Mar 2002 11:54:38 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 6FA02535A0 for ; Mon, 11 Mar 2002 11:53:06 -0500 (EST) Received: (qmail 61306 invoked by uid 3269); 11 Mar 2002 16:54:21 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 61301 invoked from network); 11 Mar 2002 16:54:20 -0000 Received: from beamer.mchh.siemens.de (194.138.158.163) by klesh.pair.com with SMTP; 11 Mar 2002 16:54:20 -0000 Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA21977; Mon, 11 Mar 2002 17:54:11 +0100 (MET) Received: from mchh159e.mch4.siemens.de ([139.21.130.171]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA06730; Mon, 11 Mar 2002 17:53:59 +0100 (MET) Received: by mchh159e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Mar 2002 17:54:15 +0100 Message-ID: From: Euchner Martin ICN M SR 3 To: "'Fredrik Lindholm (ERA)'" , msec@securemulticast.org, Euchner Martin ICN M SR 3 Cc: "'jari.arkko@ericsson.com'" , "Elisabetta Carrara (ERA)" , "Karl Norrman (ERA)" , "Fredrik Lindholm (ERA)" Subject: RE: [MSEC] new MIKEY draft - Questions and Comments MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 11 Mar 2002 17:54:14 +0100 Fredrik and Elisabetta, thanks a lot for your fast response. For all the cut issues may I safely assume that you consider them as editorial and address them in a new draft as appropriate? I have two remarks as shown below. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur Q.G/SG16 | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 47713 | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/cs27/topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Fredrik Lindholm (ERA) [mailto:Fredrik.Lindholm@era.ericsson.se] Sent: Monday, March 11, 2002 4:41 PM To: Euchner Martin ICN M SR 3; msec@securemulticast.org Cc: 'jari.arkko@ericsson.com'; Elisabetta Carrara (ERA); Karl Norrman (ERA); Fredrik Lindholm (ERA) Subject: RE: [MSEC] new MIKEY draft - Questions and Comments > Q.1) Reference: section 1.2. > > I'm still struggling hard to understand if MIKEY uses the > same terminology > as SRTP; I'm not yet convinced since the definitions sound > differently and > the mapping is not obvious. [...] We have chosen to harmonize MIKEY with the rest of the MSEC. So we will not use the same terminology. However, it looks like it might be a good idea to put a small "terminology relation" section in the next version of MIKEY. Meu:> I consider such explanation very helpful indeed, especially for those readers who are not that familiar with MSEC group terminology but try to understand the relationship how MIKEY terms maps to SRTP terms. I would pretty much like to see that section to address the SRTP relationship of terms addressed. I'm open as to whether that would appear in the MIKEY or in the SRTP document finally. > Q.3) Reference: sections 3.1, 3.2 and 3.3 > > All the key management protocols include the ID of the > initiator. However, > the ISO/IEC 9798-2,3,4 key management protocols that are > quite similar to > the MIKEY protocols also include the ID of the recipient in > the protected > exchange. The purpose is to counter reflection attacks. This should be > considered for MIKEY too! > MEU:> I consider this issue really serious. My stomach tells me that there is an issue quite likely, but I would like to see this confirmed or disproved however. Thanks, Fredrik & Elisabetta _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Mar 12 10:22:56 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24287 for ; Tue, 12 Mar 2002 10:22:56 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 5CDF0538FF; Tue, 12 Mar 2002 10:20:23 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id A965D53575 for ; Tue, 12 Mar 2002 10:17:15 -0500 (EST) Received: (qmail 47727 invoked by uid 3269); 12 Mar 2002 15:18:32 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 47724 invoked from network); 12 Mar 2002 15:18:32 -0000 Received: from penguin-ext.wise.edt.ericsson.se (193.180.251.34) by klesh.pair.com with SMTP; 12 Mar 2002 15:18:32 -0000 Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g2CFIUB01759 for ; Tue, 12 Mar 2002 16:18:30 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Tue Mar 12 16:17:26 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Mar 2002 16:17:26 +0100 Message-ID: <0DAEDF148988D411BB980008C7E65D2E04FE40ED@esealnt416> From: "Fredrik Lindholm (ERA)" To: "'Euchner Martin ICN M SR 3'" , msec@securemulticast.org Cc: "'jari.arkko@ericsson.com'" , "Elisabetta Carrara (ERA)" , "Karl Norrman (ERA)" , =?iso-8859-1?Q?=27Mats_N=E4slund=27?= Subject: RE: [MSEC] new MIKEY draft - Questions and Comments MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Tue, 12 Mar 2002 16:16:48 +0100 Hi Martin, > Fredrik and Elisabetta, > > thanks a lot for your fast response. For all the cut issues > may I safely > assume that you consider them as editorial and address them > in a new draft > as appropriate? yes >>> Q.3) Reference: sections 3.1, 3.2 and 3.3 >>> >>> All the key management protocols include the ID of the >>> initiator. However, >>> the ISO/IEC 9798-2,3,4 key management protocols that are >>> quite similar to >>> the MIKEY protocols also include the ID of the recipient in >>> the protected >>> exchange. The purpose is to counter reflection attacks. This should be >>> considered for MIKEY too! > > MEU:> I consider this issue really serious. My stomach tells me that there > is an issue quite likely, but I would like to see this confirmed or > disproved however. Reflection attacks are typically used at challenge-response authentication protocols. Even *if* it would be possible to fool the initiator about the identity of the responder (which we don't think is possible, see below), the "bad guy" would still not end up with any secret information that could be used in any way that we see. Let's assume a reflection attack on the pre-shared key method. What will happen? Alice sends a new MIKEY message, M, to Bob. Carol intercepts the message M and initiates a new connection towards Alice. In a normal reflection attack, Carol tries to use the message in a way so that Alice will wrongly authenticate Carol as Bob. Note that the message M is integrity protected (where Alice and Bob uniquely define the key used for the MAC). The message will also contain the MCS ID and the timestamp. Alice will not accept the message M from Carol because: * if Alice own ID is in M, the authentication of the message will fail as Alice probably don't share a secret with her self (and even if she did, it should be different from the secret shared with Bob). * even if Alice thinks the message is from Bob, extracting the MCS ID, will make Alice to expect a verification or error message from Bob (due to the internal state). Therefore, Alice will not accept the message M. Let's get even more extreme. Assume that the implementation has a flaw, so Alice accepts the message M and creates a verification message V=MAC(auth_key,IDb||IDa||T). Alice sends V to Carol. However, Carol has no use of it. If Carol tries to send this back as a response to the message sent by Alice to Bob. Alice will not accept this as she expects MAC(auth_key,IDa||IDb||T) from Bob. Similar arguments apply to the PK and DH case. Fredrik _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Mar 12 17:24:36 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10335 for ; Tue, 12 Mar 2002 17:24:35 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id ED4C353A68; Tue, 12 Mar 2002 17:18:17 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id C6F3853616 for ; Tue, 12 Mar 2002 17:10:22 -0500 (EST) Received: (qmail 6016 invoked by uid 3269); 12 Mar 2002 22:11:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 6013 invoked from network); 12 Mar 2002 22:11:39 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 12 Mar 2002 22:11:39 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g2CMB3G04812; Tue, 12 Mar 2002 17:11:03 -0500 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g2CMB3M22272; Tue, 12 Mar 2002 17:11:03 -0500 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id RAA30494; Tue, 12 Mar 2002 17:11:03 -0500 From: Ran Canetti Message-Id: <200203122211.RAA30494@ornavella.watson.ibm.com> To: msec@securemulticast.org Cc: canetti@watson.ibm.com, thardjono@mediaone.net Subject: [MSEC] Agenda for MSEC meeting Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Tue, 12 Mar 2002 17:11:03 -0500 Below is a tentative agenda for the MSEC session at the upcoming IETF meet. We'll meet at the Salon G room, 9-11:30 AM, Monday March 18th. See you there, Ran and Thomas 5' Agenda bashing 15' MIKEY update: Fredrik Lindholm, Ericsson 10' discussion 15' Diffie-Hellman for MIKEY: Martin Euchner, Siemens 10' discussion 15' TESLA draft: Ran Canetti, IBM 10' discussion 15' Key-Management Architecture update: Lakshminath Dondeti, Nortel 10' discussion 15' GDOI Update: Brian Weis, Cisco 5' discussion 15' GSEC update (whither IGMP security): Mark Baugher, Cisco 10' discussion Open Mike _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Mar 13 23:03:38 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01098 for ; Wed, 13 Mar 2002 23:03:37 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 097F753A44; Wed, 13 Mar 2002 23:01:17 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 3F3D053AB8 for ; Wed, 13 Mar 2002 23:00:15 -0500 (EST) Received: (qmail 29699 invoked by uid 3269); 14 Mar 2002 04:01:35 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 29696 invoked from network); 14 Mar 2002 04:01:35 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 14 Mar 2002 04:01:35 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g2E40xG09926 for ; Wed, 13 Mar 2002 23:00:59 -0500 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g2E40xM40400 for ; Wed, 13 Mar 2002 23:00:59 -0500 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id XAA36688 for msec@securemulticast.org; Wed, 13 Mar 2002 23:00:55 -0500 From: Ran Canetti Message-Id: <200203140400.XAA36688@ornavella.watson.ibm.com> To: msec@securemulticast.org Subject: [MSEC] MSEC session to be multicasted Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Wed, 13 Mar 2002 23:00:55 -0500 - Following a request from some folks, the upcoming MSEC session (3/18, 9-11:30 US Central time, 15-17:30 GMT) will be multicasted on Channel 1. See http://www.ietf.org/meetings/multicast_53.html for details. Best, Ran _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Mar 14 17:15:30 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02775 for ; Thu, 14 Mar 2002 17:15:30 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id F260D53DE8; Thu, 14 Mar 2002 17:06:38 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 471B253570 for ; Thu, 14 Mar 2002 14:28:58 -0500 (EST) Received: (qmail 52094 invoked by uid 3269); 14 Mar 2002 19:30:20 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 52091 invoked from network); 14 Mar 2002 19:30:18 -0000 Received: from aardvark.icir.org (192.150.187.20) by klesh.pair.com with SMTP; 14 Mar 2002 19:30:18 -0000 Received: from aardvark.icir.org (localhost [127.0.0.1]) by aardvark.icir.org (8.11.6/8.11.3) with ESMTP id g2EJUAd01729; Thu, 14 Mar 2002 11:30:10 -0800 (PST) (envelope-from mjh@aardvark.icir.org) From: Mark Handley X-Organisation: ACIRI To: msec@securemulticast.org Cc: pim@catarina.usc.edu Message-ID: <1727.1016134210@aardvark.icir.org> Subject: [MSEC] PIM-SM Security Discussion Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Thu, 14 Mar 2002 11:30:10 -0800 In the PIM WG meeting (Tuesday 5pm-6pm) we plan to discuss PIM-SM security, and in particular, possible workarounds to the problems with using IPsec AH replay protection for multicast packets. Most of these issues were raised in draft-irtf-gsec-pim-sm-security-issues-01.txt. We could really do with having some security-savvy people present so we converge on something that might actually be viable. Cheers, Mark _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Mar 14 17:51:17 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03552 for ; Thu, 14 Mar 2002 17:51:16 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id EAD3A53BF0; Thu, 14 Mar 2002 17:47:05 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 053B853D50 for ; Thu, 14 Mar 2002 17:29:32 -0500 (EST) Received: (qmail 80744 invoked by uid 3269); 14 Mar 2002 22:30:54 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 80741 invoked from network); 14 Mar 2002 22:30:54 -0000 Received: from lennon.multicasttech.com (HELO multicasttech.com) (root@63.105.122.7) by klesh.pair.com with SMTP; 14 Mar 2002 22:30:54 -0000 Received: from [63.105.122.248] (account ) by multicasttech.com (CommuniGate Pro WebUser 3.4.8) with HTTP id 1281247; Thu, 14 Mar 2002 17:30:53 -0500 From: "Marshall Eubanks" Subject: Re: [MSEC] PIM-SM Security Discussion To: Mark Handley , msec@securemulticast.org Cc: pim@catarina.usc.edu X-Mailer: CommuniGate Pro Web Mailer v.3.4.8 Message-ID: In-Reply-To: <1727.1016134210@aardvark.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Thu, 14 Mar 2002 17:30:53 -0500 Content-Transfer-Encoding: 8bit On Thu, 14 Mar 2002 11:30:10 -0800 Mark Handley wrote: > > In the PIM WG meeting (Tuesday 5pm-6pm) we plan to > discuss PIM-SM > security, and in particular, possible workarounds to the > problems with > using IPsec AH replay protection for multicast packets. > Most of these > issues were raised in draft-irtf-gsec-pim-sm-security-issues-01.txt. > Where can I find this ? It does not seem to be in either msec or at the IRTF... Marshall > We could really do with having some security-savvy people > present so > we converge on something that might actually be viable. > > Cheers, > Mark > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Mar 14 18:03:55 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03786 for ; Thu, 14 Mar 2002 18:03:55 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 591F753915; Thu, 14 Mar 2002 18:00:21 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 9F05F53D1D for ; Thu, 14 Mar 2002 17:57:25 -0500 (EST) Received: (qmail 83871 invoked by uid 3269); 14 Mar 2002 22:58:47 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 83868 invoked from network); 14 Mar 2002 22:58:47 -0000 Received: from aardvark.icir.org (192.150.187.20) by klesh.pair.com with SMTP; 14 Mar 2002 22:58:47 -0000 Received: from aardvark.icir.org (localhost [127.0.0.1]) by aardvark.icir.org (8.11.6/8.11.3) with ESMTP id g2EMwbd04043; Thu, 14 Mar 2002 14:58:37 -0800 (PST) (envelope-from mjh@aardvark.icir.org) From: Mark Handley X-Organisation: ACIRI To: "Marshall Eubanks" Cc: msec@securemulticast.org, pim@catarina.usc.edu Subject: Re: [MSEC] PIM-SM Security Discussion In-reply-to: Your message of "Thu, 14 Mar 2002 17:30:53 EST." Message-ID: <4041.1016146717@aardvark.icir.org> Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Thu, 14 Mar 2002 14:58:37 -0800 >On Thu, 14 Mar 2002 11:30:10 -0800 > Mark Handley wrote: >> >> In the PIM WG meeting (Tuesday 5pm-6pm) we plan to >> discuss PIM-SM >> security, and in particular, possible workarounds to the >> problems with >> using IPsec AH replay protection for multicast packets. >> Most of these >> issues were raised in draft-irtf-gsec-pim-sm-security-issues-01.txt. >> > >Where can I find this ? It does not seem to be in either >msec or at the IRTF... http://www.ietf.org/internet-drafts/draft-irtf-gsec-pim-sm-security-issues-01.txt or any of the other internet-draft archive sites. - Mark _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Mar 28 04:45:44 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20098 for ; Thu, 28 Mar 2002 04:45:44 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0E5005384C; Thu, 28 Mar 2002 04:42:16 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 1C31653786 for ; Thu, 28 Mar 2002 04:41:00 -0500 (EST) Received: (qmail 90794 invoked by uid 3269); 28 Mar 2002 09:42:52 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 90791 invoked from network); 28 Mar 2002 09:42:52 -0000 Received: from p-mail2.rd.francetelecom.com (193.49.124.32) by klesh.pair.com with SMTP; 28 Mar 2002 09:42:52 -0000 Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2655.55) id ; Thu, 28 Mar 2002 10:26:48 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D82024A2528@lat3721.rd.francetelecom.fr> From: LANIEPCE Sylvie FTRD/DMI/CAE To: "'Ran Canetti'" , msec@securemulticast.org Subject: RE: [MSEC] new TESLA draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-deab5d54-4227-11d6-b1e9-00508b69ab48" Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Thu, 28 Mar 2002 10:27:01 +0100 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-deab5d54-4227-11d6-b1e9-00508b69ab48 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D63A.B72E8110" ------_=_NextPart_001_01C1D63A.B72E8110 Content-Type: text/plain Ran, I would have some questions : Paragraph 4.4 : P_j={M_j||MAC(K'_i,M_j||K_{i-d}} Sorry, I do not understand why the interval i is not explicitely included in P_j. To my understanding, the receiver NEED to know i to match P_j with a given interval i (at least to check the security condition x RE: [MSEC] new TESLA draft

Ran,

I would have some questions :

Paragraph 4.4 : = P_j=3D{M_j||MAC(K'_i,M_j||K_{i-d}}
Sorry, I do not understand why the interval i is not = explicitely included in P_j. To my understanding, the receiver NEED to = know i to match P_j with a given interval i (at least to check the = security condition x<i-d), right ?

I do not understand why there is no more need for the = second security condition defined in the TESLA SMUG draft (check that i = is not an interval in the future, i.e. = i<floor((t_j-t_0)/T_int))

Could you please add some comments about F(k)=3Df_k = (0), F'(k)=3Df'_k(1) : 0 ? 1 ?


And also some minor comments :

"synchronisation" erroneously repeated 2 = times in the second paragraph section 4.3

Paragraph 4.5, does c stand for something in t_c = ?

Section 4.5, I felt a bit confused with the sentence = "when the receiver receives packet P_j sent in interval i at local = time t_c...". Could "when the receiver receives at local time = t_c packet P_j sent in interval i..." avoid a possible confusion = (at least, this was MY confusion...) : local time t_c related to the = receiving or to the sending ?


Kind regards
Sylvie Laniepce

-----Message d'origine-----
De : Ran Canetti [mailto:canetti@watson.ibm.com= ]
Envoye : samedi 2 mars 2002 16:08
A : msec@securemulticast.org
Objet : [MSEC] new TESLA draft




[Co-chair hat off]

Folks,

Please take a look at the following new I-D:

http://search.ietf.org/internet-drafts/draft-perrig-ms= ec-tesla-intro-00.txt

It provides a general algorithmic/informational = presentation of the TESLA
source authentication mechanism. (This is an updated = version of the
irtf-smug draft from a year ago.)

While you read, please keep in mind the following = issue. Our planned next
step is to write a standards-track draft describing = how to implement
TESLA in a specific scenario. The question is: how = to go about it?
In particular, should we first implement TESLA in = the application layer
or in the IP layer? There are advantages to each = option (they are discussed
in the draft). We would like to get the WG feedback = on the draft in general
and on this question in particular.

Thanks,

Ran


_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec

------_=_NextPart_001_01C1D63A.B72E8110-- ------=_NextPartTM-000-deab5d54-4227-11d6-b1e9-00508b69ab48-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec