From mailman-bounces@six.pairlist.net Tue Mar 1 05:04:36 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08731 for ; Tue, 1 Mar 2005 05:04:36 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 7AD2E8D462 for ; Tue, 1 Mar 2005 05:04:30 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: securemulticast.org mailing list memberships reminder From: mailman-owner@securemulticast.org To: msec-archive@ietf.org X-No-Archive: yes Message-ID: Date: Tue, 01 Mar 2005 05:02:20 -0500 Precedence: bulk X-BeenThere: mailman@six.pairlist.net X-Mailman-Version: 2.1.5 List-Id: mailman.six.pairlist.net X-List-Administrivia: yes Sender: mailman-bounces@six.pairlist.net Errors-To: mailman-bounces@six.pairlist.net Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your securemulticast.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@securemulticast.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@securemulticast.org. Thanks! Passwords for msec-archive@lists.ietf.org: List Password // URL ---- -------- msec@securemulticast.org ucweat http://six.pairlist.net/mailman/options/msec/msec-archive%40lists.ietf.org From msec-bounces@securemulticast.org Tue Mar 1 17:13:30 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16164 for ; Tue, 1 Mar 2005 17:13:28 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id CAF728D1A4; Tue, 1 Mar 2005 17:13:26 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 8CA9E8D0F5 for ; Tue, 1 Mar 2005 17:13:25 -0500 (EST) Received: (qmail 61047 invoked by uid 3269); 1 Mar 2005 22:13:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 61044 invoked from network); 1 Mar 2005 22:13:25 -0000 Received: from smtp013.mail.yahoo.com (216.136.173.57) by klesh.pair.com with SMTP; 1 Mar 2005 22:13:25 -0000 Received: from unknown (HELO mou1thardjon-l1.yahoo.com) (thardjono@67.161.47.160 with login) by smtp013.mail.yahoo.com with SMTP; 1 Mar 2005 22:13:24 -0000 Message-Id: <6.2.1.2.2.20050301141104.028c2a38@pop.mail.yahoo.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 01 Mar 2005 14:13:09 -0800 To: msec@securemulticast.org From: Thomas Hardjono Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Tentative Agenda items for MSEC at IETF62 (Minneapolis) X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Folks, As of today, MSEC scheduled as follows for Minneapolis: THURSDAY, March 10, 2005 0900-1130 Morning Sessions Salon F SEC msec Multicast Security WG So far we have the following agenda items: - WG Status review (Ran/Lakshminath) - Additional mode of key distribution for MIKEY (D. Ignjatic/L. Dondeti) - MIKEY - using elliptic-curve cryptographic methods (Mitch Blaser/Andy Milne) Please email Ran/myself with additional agenda items. Regards. Ran/thomas ---------- _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Mar 2 13:38:25 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12512 for ; Wed, 2 Mar 2005 13:38:23 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 3EB4B8CFB6; Wed, 2 Mar 2005 13:38:26 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 69A9D8CFA9 for ; Wed, 2 Mar 2005 13:38:25 -0500 (EST) Received: (qmail 25547 invoked by uid 3269); 2 Mar 2005 18:38:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 25544 invoked from network); 2 Mar 2005 18:38:25 -0000 Received: from web30707.mail.mud.yahoo.com (68.142.200.140) by klesh.pair.com with SMTP; 2 Mar 2005 18:38:25 -0000 Received: (qmail 48805 invoked by uid 60001); 2 Mar 2005 18:38:24 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=TXHOuaXLJRD1fuD5TDa6YIqNayTnJSD2ih05plDpw4QCER6W5FJtDy5ibC3CZ6WK87C4P1qRM5LYFfRjj6Mm0BzRxQ8wFHTUVo7bdzD01r3/AzMd68AgZdrjZq69wQU4nbUqqAQ332tPGV/kaXXmCrLFi/naG/Gpg7WFOZwKV/Q= ; Message-ID: <20050302183824.48801.qmail@web30707.mail.mud.yahoo.com> Received: from [65.205.251.51] by web30707.mail.mud.yahoo.com via HTTP; Wed, 02 Mar 2005 10:38:24 PST Date: Wed, 2 Mar 2005 10:38:24 -0800 (PST) From: Thomas Hardjono To: MSEC MSEC MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [MSEC] Tentative Agenda items for MSEC at IETF62 (Minneapolis) X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Folks, As of today, MSEC scheduled as follows for Minneapolis: THURSDAY, March 10, 2005 0900-1130 Morning Sessions Salon F SEC msec Multicast Security WG So far we have the following agenda items: - WG Status review (Ran/Lakshminath) - 2401bis and multicast issues (AD discussion - Russ Housley) - GKDP update (L. Dondeti) - Additional mode of key distribution for MIKEY (D. Ignjatic/L. Dondeti) - MIKEY - using elliptic-curve methods (Mitch Blaser/Andy Milne) Please email Ran/Laksminath/myself with additional agenda items. Regards. Ran/thomas ---------- __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Mar 2 13:42:03 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12737 for ; Wed, 2 Mar 2005 13:42:03 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 6FBDD8C5A1; Wed, 2 Mar 2005 13:42:06 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 6C7948C57E for ; Wed, 2 Mar 2005 13:42:05 -0500 (EST) Received: (qmail 26275 invoked by uid 3269); 2 Mar 2005 18:42:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 26272 invoked from network); 2 Mar 2005 18:42:05 -0000 Received: from web30705.mail.mud.yahoo.com (68.142.200.138) by klesh.pair.com with SMTP; 2 Mar 2005 18:42:05 -0000 Received: (qmail 54043 invoked by uid 60001); 2 Mar 2005 18:42:02 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=W4bRykuSao6qlyQ5o3PwM0AY+pA54bpB9FdL8CxN4wq4jUxfA1lHlhZ2Fp+vIStNzf5F7TPvePkFSpHbE0NrfByafmIbPufJ0AfJoyw2NEJ2wmV46kvQDq0LNUTp5LPyTeXJqrLqPhv1mqKV4VBy81WypmoDv2lmGE9/KgshMqU= ; Message-ID: <20050302184202.54041.qmail@web30705.mail.mud.yahoo.com> Received: from [65.205.251.51] by web30705.mail.mud.yahoo.com via HTTP; Wed, 02 Mar 2005 10:42:02 PST Date: Wed, 2 Mar 2005 10:42:02 -0800 (PST) From: Thomas Hardjono To: MSEC MSEC In-Reply-To: <20050302183824.48801.qmail@web30707.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [MSEC] Correction - Agenda items for MSEC at IETF62 (Minneapolis) X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Folks, As of today, MSEC scheduled as follows for Minneapolis: THURSDAY, March 10, 2005 0900-1130 Morning Sessions Salon F SEC msec Multicast Security WG So far we have the following agenda items: - WG Status review (Ran/Lakshminath) - 2401bis and multicast issues (AD discussion - Russ Housley) - GKDP update (L. Dondeti) - Additional mode of key distribution for MIKEY (D. Ignjatic/L. Dondeti) - MIKEY - using elliptic-curve methods (Mitch Blaser/Andy Milne) - Update on DHHMAC draft (S. Fries) - Bootstrapping TESLA draft (S. Fries) Please email Ran/Laksminath/myself with additional agenda items. Regards. Ran/thomas ---------- __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Mar 7 13:20:58 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16957 for ; Mon, 7 Mar 2005 13:20:58 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id BEAE68C6D0; Mon, 7 Mar 2005 13:21:00 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 0DEF48C15B for ; Mon, 7 Mar 2005 13:21:00 -0500 (EST) Received: (qmail 28746 invoked by uid 3269); 7 Mar 2005 18:20:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 28740 invoked from network); 7 Mar 2005 18:20:59 -0000 Received: from zcars04e.nortelnetworks.com (47.129.242.56) by klesh.pair.com with SMTP; 7 Mar 2005 18:20:59 -0000 Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j27IKu805696 for ; Mon, 7 Mar 2005 13:20:56 -0500 (EST) Received: from [47.140.61.205] (artpt6y5.us.nortel.com [47.140.61.205]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GFJ8FHVY; Mon, 7 Mar 2005 13:20:55 -0500 Message-ID: <422C9B87.2020306@nortel.com> Date: Mon, 07 Mar 2005 13:20:55 -0500 From: "Dondeti, Lakshminath" Organization: Nortel Networks User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MSEC MSEC X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MSEC] Minute takers for the MSEC meeting X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Hi all, I need two volunteers to take minutes at the Thursday meeting. Please respond to me (ldondeti@nortel.com) directly. Thanks in advance. regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Mar 8 09:39:30 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27756 for ; Tue, 8 Mar 2005 09:39:30 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id A52E78C719; Tue, 8 Mar 2005 09:39:31 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id C3B998C70C for ; Tue, 8 Mar 2005 09:39:29 -0500 (EST) Received: (qmail 85541 invoked by uid 3269); 8 Mar 2005 14:39:29 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 85538 invoked from network); 8 Mar 2005 14:39:29 -0000 Received: from m5tmail.m5t.com (66.129.134.18) by klesh.pair.com with SMTP; 8 Mar 2005 14:39:29 -0000 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Mar 2005 09:39:28 -0500 Message-ID: Thread-Topic: Mikey CS ID map type question. Thread-Index: AcUj7KIaRV6FFOKpT5ykvyZzm251HQ== From: "Christian Beaulieu" To: Subject: [MSEC] Mikey CS ID map type question. X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0207719562==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org This is a multi-part message in MIME format. --===============0207719562== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C523EC.A1FCA3F4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C523EC.A1FCA3F4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We are asking ourselves a question here. In the RFC for MIKEY it states that the CS ID map info is 16 bits long, then it goes to state that for SRTP it is variable. =20 What we want to know is when parsing a message that would have a CS Is map type different from SRTP, can we assume that the length of the CS ID map info field will be 16 bits to continue parsing the rest of the message or we should bail out immediately and return an error. =20 Thanks in advance. =20 Christian ------_=_NextPart_001_01C523EC.A1FCA3F4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We are asking ourselves a question here. In the RFC = for MIKEY it states that the CS ID map info is 16 bits long, then it goes to = state that for SRTP it is variable.

 

What we want to know is when parsing a message that = would have a CS Is map type different from SRTP, can we assume that the length = of the CS ID map info field will be 16 bits to continue parsing the rest of the message or we should bail out immediately and return an = error.

 

Thanks in advance.

 

Christian

------_=_NextPart_001_01C523EC.A1FCA3F4-- --===============0207719562== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --===============0207719562==-- From msec-bounces@securemulticast.org Tue Mar 8 10:04:31 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02059 for ; Tue, 8 Mar 2005 10:04:31 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id E094D8C500; Tue, 8 Mar 2005 10:04:32 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 6C9508C3F2 for ; Tue, 8 Mar 2005 10:04:31 -0500 (EST) Received: (qmail 90798 invoked by uid 3269); 8 Mar 2005 15:04:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 90795 invoked from network); 8 Mar 2005 15:04:31 -0000 Received: from albatross.ericsson.se (193.180.251.49) by klesh.pair.com with SMTP; 8 Mar 2005 15:04:31 -0000 Received: from esealmw129.eemea.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j28F3giM002120; Tue, 8 Mar 2005 16:04:29 +0100 (MET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Mar 2005 16:04:17 +0100 Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Mar 2005 16:04:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MSEC] Mikey CS ID map type question. Date: Tue, 8 Mar 2005 16:04:17 +0100 Message-ID: <0CDAE977A7172A40A2A3A1C20C12BD65010A1216@esealmw106.eemea.ericsson.se> Thread-Topic: Mikey CS ID map type question. Thread-index: AcUj7KIaRV6FFOKpT5ykvyZzm251HQAAnLcw From: "Elisabetta Carrara (AL/EAB)" To: "Christian Beaulieu" , X-OriginalArrivalTime: 08 Mar 2005 15:04:17.0670 (UTC) FILETIME=[197D6A60:01C523F0] X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0664948903==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org This is a multi-part message in MIME format. --===============0664948903== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C523F0.193C66C7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C523F0.193C66C7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Christian,=20 thanks for having spotted this. The field is variable size, 16 bits was = a typo :o( =20 cheers /Elisabetta -----Original Message----- From: msec-bounces@securemulticast.org = [mailto:msec-bounces@securemulticast.org]On Behalf Of Christian Beaulieu Sent: den 8 mars 2005 15:39 To: msec@securemulticast.org Subject: [MSEC] Mikey CS ID map type question. We are asking ourselves a question here. In the RFC for MIKEY it states = that the CS ID map info is 16 bits long, then it goes to state that for = SRTP it is variable. =20 What we want to know is when parsing a message that would have a CS Is = map type different from SRTP, can we assume that the length of the CS ID = map info field will be 16 bits to continue parsing the rest of the = message or we should bail out immediately and return an error. =20 Thanks in advance. =20 Christian ------_=_NextPart_001_01C523F0.193C66C7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Christian,
thanks=20 for having spotted this. The field is variable size, 16 bits was a typo=20 :o(
 
cheers
/Elisabetta
-----Original Message-----
From:=20 msec-bounces@securemulticast.org=20 [mailto:msec-bounces@securemulticast.org]On Behalf Of Christian = Beaulieu
Sent: den 8 mars 2005 15:39
To:=20 msec@securemulticast.org
Subject: [MSEC] Mikey CS ID map = type=20 question.

We are asking ourselves = a question=20 here. In the RFC for MIKEY it states that the CS ID map info is 16 = bits long,=20 then it goes to state that for SRTP it is=20 variable.

 

What we want to know is = when=20 parsing a message that would have a CS Is map type different from = SRTP, can we=20 assume that the length of the CS ID map info field will be 16 bits to = continue=20 parsing the rest of the message or we should bail out immediately and = return=20 an error.

 

Thanks in=20 advance.

 

Christian

------_=_NextPart_001_01C523F0.193C66C7-- --===============0664948903== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --===============0664948903==-- From msec-bounces@securemulticast.org Wed Mar 9 16:37:01 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23197 for ; Wed, 9 Mar 2005 16:36:58 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 7986D8CD11; Wed, 9 Mar 2005 16:36:58 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id CBE0B8CCE7 for ; Wed, 9 Mar 2005 16:36:57 -0500 (EST) Received: (qmail 57524 invoked by uid 3269); 9 Mar 2005 21:36:57 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 57521 invoked from network); 9 Mar 2005 21:36:57 -0000 Received: from zcars04f.nortelnetworks.com (47.129.242.57) by klesh.pair.com with SMTP; 9 Mar 2005 21:36:57 -0000 Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j29Lash05987 for ; Wed, 9 Mar 2005 16:36:54 -0500 (EST) Received: from [47.102.185.237] (archt2tw.us.nortel.com [47.102.185.237]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GFJ8HLCA; Wed, 9 Mar 2005 16:36:54 -0500 Message-ID: <422F6C73.80108@nortel.com> Date: Wed, 09 Mar 2005 16:36:51 -0500 From: "Dondeti, Lakshminath" Organization: Nortel Networks User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MSEC MSEC Subject: Re: [MSEC] Minute takers for the MSEC meeting References: <422C9B87.2020306@nortel.com> In-Reply-To: <422C9B87.2020306@nortel.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Folks, We are still looking for volunteers... thanks, Lakshminath Dondeti, Lakshminath [BL60:1A14:EXCH] wrote: > Hi all, > > I need two volunteers to take minutes at the Thursday meeting. Please > respond to me (ldondeti@nortel.com) directly. Thanks in advance. > > regards, > Lakshminath > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Mar 9 16:37:44 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23269 for ; Wed, 9 Mar 2005 16:37:44 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 81D998C927; Wed, 9 Mar 2005 16:37:45 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id F0C148C428 for ; Wed, 9 Mar 2005 16:37:43 -0500 (EST) Received: (qmail 57724 invoked by uid 3269); 9 Mar 2005 21:37:43 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 57719 invoked from network); 9 Mar 2005 21:37:43 -0000 Received: from zcars04f.nortelnetworks.com (47.129.242.57) by klesh.pair.com with SMTP; 9 Mar 2005 21:37:43 -0000 Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j29Lbfh06224; Wed, 9 Mar 2005 16:37:41 -0500 (EST) Received: from [47.102.185.237] (archt2tw.us.nortel.com [47.102.185.237]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GFJ8HLCX; Wed, 9 Mar 2005 16:37:40 -0500 Message-ID: <422F6CA2.3030400@nortel.com> Date: Wed, 09 Mar 2005 16:37:38 -0500 From: "Dondeti, Lakshminath" Organization: Nortel Networks User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MSEC MSEC References: <20050302184202.54041.qmail@web30705.mail.mud.yahoo.com> <422C6EC2.7060004@nortel.com> In-Reply-To: <422C6EC2.7060004@nortel.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Hardjono Subject: [MSEC] Re: Thanking Thomas X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit For some reason this has been stuck in a mail-queue somewhere. Lakshminath Dondeti, Lakshminath wrote: > Hi all, > > I'd like you to join me in thanking Thomas for his service as the MSEC > working group chair for the past 4+ years. Along with Ran, Thomas put > in a great deal of work in the multicast and group security research > work in SMuG, the MSEC BoF and the MSEC working WG for the past 6-7 > years. > > The WG is a success story thanks in large part due to Thomas's efforts > both as an author/editor as well as an RG, BoF and WG co-chair. > > Thomas volunteered to continue to maintain the securemulticast.org > site, and plans to attend MSEC meetings when his schedule allows. > > Thank you Thomas, and we'll look forward to your thoughts on the > mailing list and of course at future meetings. > > best regards, > Lakshminath > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Mar 9 16:46:49 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24180 for ; Wed, 9 Mar 2005 16:46:49 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 48F448C1AB; Wed, 9 Mar 2005 16:46:15 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 852D98C0B5 for ; Wed, 9 Mar 2005 16:46:13 -0500 (EST) Received: (qmail 59205 invoked by uid 3269); 9 Mar 2005 21:46:13 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 59202 invoked from network); 9 Mar 2005 21:46:13 -0000 Received: from zcars04e.nortelnetworks.com (47.129.242.56) by klesh.pair.com with SMTP; 9 Mar 2005 21:46:13 -0000 Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j29LkBn26959 for ; Wed, 9 Mar 2005 16:46:11 -0500 (EST) Received: from [47.102.185.237] (archt2tw.us.nortel.com [47.102.185.237]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GFJ8HLLT; Wed, 9 Mar 2005 16:46:10 -0500 Message-ID: <422F6E9F.2010105@nortel.com> Date: Wed, 09 Mar 2005 16:46:07 -0500 From: "Dondeti, Lakshminath" Organization: Nortel Networks User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MSEC MSEC X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MSEC] Brian Weis will be chairing the meeting in MSP X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Folks, Ran and I cannot make it to the MSEC meeting. The Canetti's are welcoming their second baby this week. Congratulations again Ran! I was in Minneapolis earlier this week, but had to return home to take care of my wife and son as they became severely ill. Turns out they are taking care of me now as I now have what they had been fighting. Brian Weis has kindly accepted to fill in for us. Thanks again Brian. We have a very interesting Agenda for tomorrow: In addition to several new MIKEY related drafts, the interaction between IPsec and MSEC protocols is a topic of discussion at the meeting. Our AD, Russ Housley will lead that discussion. Please see http://securemulticast.org/msec11-IETF62-IPsec_Multicast.pdf for more information. thanks and regards, Lakshminath for Ran Canetti Lakshminath Dondeti _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Mar 9 23:27:39 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28721 for ; Wed, 9 Mar 2005 23:27:36 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id E20168C52D; Wed, 9 Mar 2005 23:27:38 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 8BB5D8C29F for ; Wed, 9 Mar 2005 23:27:37 -0500 (EST) Received: (qmail 29986 invoked by uid 3269); 10 Mar 2005 04:27:37 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 29970 invoked from network); 10 Mar 2005 04:27:33 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 10 Mar 2005 04:27:33 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id j2A4RXP148380 for ; Wed, 9 Mar 2005 23:27:33 -0500 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j2A4RWJ120886 for ; Wed, 9 Mar 2005 23:27:32 -0500 Received: from mgsmtp00 (mgsmtp00.watson.ibm.com [9.2.40.58]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j2A4RV536228 for ; Wed, 9 Mar 2005 23:27:31 -0500 Received: from prf.watson.ibm.com ([9.2.16.112]) by mgsmtp00.watson.ibm.com ID IMFd1110428713.1; Wed, 09 Mar 2005 23:25:13 -0400 Received: from localhost (canetti@localhost) by prf.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id j2A4RU317136; Wed, 9 Mar 2005 23:27:30 -0500 Date: Wed, 9 Mar 2005 23:27:29 -0500 (EST) From: canetti To: "Dondeti, Lakshminath" Subject: Re: [MSEC] Re: Thanking Thomas In-Reply-To: <422F6CA2.3030400@nortel.com> Message-ID: References: <20050302184202.54041.qmail@web30705.mail.mud.yahoo.com> <422C6EC2.7060004@nortel.com> <422F6CA2.3030400@nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Thomas Hardjono , MSEC MSEC X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org I'd like to join Lakshminath in thanking Thomas. MSEC would not have been where it is today without him. Ran On Wed, 9 Mar 2005, Dondeti, Lakshminath wrote: > For some reason this has been stuck in a mail-queue somewhere. > > Lakshminath > > Dondeti, Lakshminath wrote: > > > Hi all, > > > > I'd like you to join me in thanking Thomas for his service as the MSEC > > working group chair for the past 4+ years. Along with Ran, Thomas put > > in a great deal of work in the multicast and group security research > > work in SMuG, the MSEC BoF and the MSEC working WG for the past 6-7 > > years. > > > > The WG is a success story thanks in large part due to Thomas's efforts > > both as an author/editor as well as an RG, BoF and WG co-chair. > > > > Thomas volunteered to continue to maintain the securemulticast.org > > site, and plans to attend MSEC meetings when his schedule allows. > > > > Thank you Thomas, and we'll look forward to your thoughts on the > > mailing list and of course at future meetings. > > > > best regards, > > Lakshminath > > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Mar 15 12:20:12 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24918 for ; Tue, 15 Mar 2005 12:20:10 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id E008A8D11E; Tue, 15 Mar 2005 12:20:09 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id A24C38D041 for ; Tue, 15 Mar 2005 12:20:08 -0500 (EST) Received: (qmail 76302 invoked by uid 3269); 15 Mar 2005 17:20:08 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 76299 invoked from network); 15 Mar 2005 17:20:08 -0000 Received: from web30702.mail.mud.yahoo.com (68.142.200.135) by klesh.pair.com with SMTP; 15 Mar 2005 17:20:08 -0000 Received: (qmail 54820 invoked by uid 60001); 15 Mar 2005 17:20:07 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=W1Ox/yl6jqxZmhOnOBAv2D+LiUNuOSYqJx1OWuqUMWIwoLFmdy+vTS12aCSbBynS7Ub3ka7A9KeUnvJlaLinaR4hEsvUBI1QTcwZ9N5ll274quL4dU2QdB/oohY/+9sU82BregmvjQyC3/MrHrzfOqtKXwoFnpparynCGIwM7iQ= ; Message-ID: <20050315172007.54818.qmail@web30702.mail.mud.yahoo.com> Received: from [65.205.251.51] by web30702.mail.mud.yahoo.com via HTTP; Tue, 15 Mar 2005 09:20:07 PST Date: Tue, 15 Mar 2005 09:20:07 -0800 (PST) From: Thomas Hardjono To: MSEC MSEC MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [MSEC] Slides from IETF62 Minn. are now on the website X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Folks, The slides from IETF62 in Minn. are now on the website. http://securemulticast.org/msec-meetings.htm cheers, thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Mar 17 15:03:04 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13589 for ; Thu, 17 Mar 2005 15:03:03 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 01E058CC9B; Thu, 17 Mar 2005 15:03:05 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 795DB8C4B8 for ; Thu, 17 Mar 2005 15:03:03 -0500 (EST) Received: (qmail 79288 invoked by uid 3269); 17 Mar 2005 20:03:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 79285 invoked from network); 17 Mar 2005 20:03:03 -0000 Received: from rproxy.gmail.com (64.233.170.198) by klesh.pair.com with SMTP; 17 Mar 2005 20:03:03 -0000 Received: by rproxy.gmail.com with SMTP id z35so642147rne for ; Thu, 17 Mar 2005 12:03:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=rurZOwE3shUMXot0VmaHEOtNjlbL8valYWnAldE8IQn/YjsTv7IMw8M0rhHjPAvM6FLvG7JOpAmc7cZleMUDP3giy5kYklZh6CyYFLTMxBHmeQ7/OQjK7sZwjeMK2IOGMckjOMTbVuJ0MCN6+T/BWfbIY0zHO+aqJhx1VCVeYaU= Received: by 10.38.66.45 with SMTP id o45mr2013780rna; Thu, 17 Mar 2005 12:03:03 -0800 (PST) Received: by 10.38.82.69 with HTTP; Thu, 17 Mar 2005 12:03:03 -0800 (PST) Message-ID: <920567a60503171203309864bc@mail.gmail.com> Date: Thu, 17 Mar 2005 15:03:03 -0500 From: Roger Khazan To: msec@securemulticast.org Subject: [MSEC] Re: applications and motivation for mcast and group security Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Roger Khazan List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit A month ago I posted a message about motivation and applications for group security. My original message is included at the bottom. I am still very interested in this topic and would appreciate people responding to my message. So far, I received only two responses. Paul Gilbert and Cesc Santasusana told me about the following applications, respectively: 1. Financial traders, which work together, form groups and supply and receive trade information in these groups. In "large financials you often see thousands of sources (traders) and hundreds of groups (split into servers publishing market data and traders sending)." Currently, this operation is supported by an application from Reuters/Tibco that delivers market data to traders and supports these groups. The application uses IP multicast with best-effort reliability guarantees. Presently there is "no form of security whatsoever for this multicast app." So, this is a good application for group security. It seems that having a central KDS would work here, but the protocols would need to be stateless. Does this make sense? What are the security requirements here? 2. I am still learning the specifics of this one, but it is about supporting decentralized communication in military on-the-move environments. For example, there is a need to support secure voice conferencing among small groups of people. It is reasonable to assume that initializations (e.g., distribution of keying material) are handled by a centralized manager, but "daily operations must be able to work without access to the central service." The environment, scale, and requirements of this application are very different from the first one. It seems that a *non-group* solution would work well here: Use a fresh symmetric key for each voice conference. Tell participants about this key by encrypting the key with each participant's public key. Of course everyone's keys are certified by some recognized authority. Instead of using public keys all the time, we can also establish some long-term symmetric keys. Does this make sense? Maybe it makes sense for groups of upto certain size, but not for larger groups? Can we expect such larger groups in this application? -- Everyone would agree that research in group and multicast security, as any other research, has to be driven by concrete motivation and applications. The information about these is not widely-available or is lacking. Let's pull our collective knowledge together and make a strong case for this research area. Looking forward to hearing your thoughts. Thank you. Roger Khazan MIT Lincoln Laboratory -------------------------------------------------------------------------------- [MSEC] applications and motivation for mcast and group security Roger Khazan rkhazan at gmail.com Fri Feb 18 12:51:47 EST 2005 I've been reading a lot about multicast and group security and I am having hard time finding information about specific applications and motivation, especially for decentralized solutions. One application that comes to mind is group chat and shared collaborative workspace. But there must be others... I am wondering if people could share with me their thoughts and knowledge about *specific* applications that require multicast security and group security. Also, which specific applications require (or can benefit from) *decentralized* key agreement solutions? Which ones assume *centralized* solutions? I am looking for both single-sender and multi-sender applications. Don't limit yourself to collaborative applications; maybe there are some involving sensors or multicast tree management, or some military applications? I am looking for specific descriptions, not just general areas. Are there systems *deployed in the world* today that utilize multicast and group security? Which ones? Which schemes do they use? Are there examples in the past where we did not have group security in place, but we wish we did? I'd like someone to make a compelling case why all this stuff is necessary. If you work on designing group security schemes, which big problem are you fixing? Which prototype systems have been implemented and are available for download and/or purchase? Once I get responses from individual contributors, I will compile this information and either send it to the list or provide it to the individual contributors. Or, you can post your responses to the list. Thank you, Roger Khazan MIT Lincoln Laboratory _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Mar 17 16:27:13 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22180 for ; Thu, 17 Mar 2005 16:27:12 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 79AFA8CD80; Thu, 17 Mar 2005 16:27:14 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 709308C432 for ; Thu, 17 Mar 2005 16:27:13 -0500 (EST) Received: (qmail 93627 invoked by uid 3269); 17 Mar 2005 21:27:13 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 93624 invoked from network); 17 Mar 2005 21:27:13 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by klesh.pair.com with SMTP; 17 Mar 2005 21:27:13 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 17 Mar 2005 13:27:13 -0800 X-IronPort-AV: i="3.91,99,1110182400"; d="scan'208"; a="236868149:sNHT29226668" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2HLR9ZV016132; Thu, 17 Mar 2005 13:27:10 -0800 (PST) Received: from [192.168.0.11] (sjc-vpn6-675.cisco.com [10.21.122.163]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j2HLKEGQ013966; Thu, 17 Mar 2005 13:20:14 -0800 In-Reply-To: <920567a60503171203309864bc@mail.gmail.com> References: <920567a60503171203309864bc@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <14d55e8b34685515a69e66242d1a93c1@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] Re: applications and motivation for mcast and group security Date: Thu, 17 Mar 2005 13:27:09 -0800 To: Roger Khazan X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1111094414.937970"; x:"432200"; a:"rsa-sha1"; b:"nofws:4776"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"LWx4V3e9EoksP3n/scDKerSAIWl9n0BnmOGWky8NV2P6J+Kkkz4kzNAnlm6OBBit5OJ9AY6W" "l8ljxV1C9Njv5HigpWp4Ju2Drtcmn8qGbPqJ9MWM3xKqIP7dp4DB0nHnaaNsTmpJ/V1/Q3lfExS" "SQEhLKSRplpBfpqZwf6NNGYI="; c:"From: Mark Baugher "; c:"Subject: Re: [MSEC] Re: applications and motivation for mcast and gr" "oup security"; c:"Date: Thu, 17 Mar 2005 13:27:09 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Cc: msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Roger There is some work that is product-related that won't be discussed on this list before the products are announced. There are some opportunities in group and multicast applications, but IP multicast is not widely deployed and has been much slower in its adoption than some of us expected eight or ten years ago. The real-world deployments that I am aware of are largely satellite applications run by military and government agencies rather than commercial. But practically speaking, any multicast application is a potential multicast security application. And there are point-to-point applications that involve groups, which may also need group security. A multi-point teleconference, for example, might benefit from a group security model rather than a point-to-point model even if there is a centralized control unit with point-to-point connections with the participants. Mark On Mar 17, 2005, at 12:03 PM, Roger Khazan wrote: > A month ago I posted a message about motivation and applications for > group security. My original message is included at the bottom. > > I am still very interested in this topic and would appreciate people > responding to my message. > > So far, I received only two responses. Paul Gilbert and Cesc > Santasusana told me about the following applications, respectively: > > 1. Financial traders, which work together, form groups and supply and > receive trade information in these groups. In "large financials you > often see thousands of sources (traders) and hundreds of groups (split > into servers publishing market data > and traders sending)." Currently, this operation is supported by an > application from Reuters/Tibco that delivers market data to traders > and supports these groups. The application uses IP multicast with > best-effort reliability guarantees. Presently there is "no form of > security whatsoever for this multicast app." > > So, this is a good application for group security. It seems that > having a central KDS would work here, but the protocols would need to > be stateless. Does this make sense? What are the security requirements > here? > > 2. I am still learning the specifics of this one, but it is about > supporting decentralized communication in military on-the-move > environments. For example, there is a need to support secure voice > conferencing among small groups of people. It is reasonable to assume > that initializations (e.g., distribution of keying material) are > handled by a centralized manager, but "daily operations must be able > to work without access to the central service." > > The environment, scale, and requirements of this application are very > different from the first one. It seems that a *non-group* solution > would work well here: Use a fresh symmetric key for each voice > conference. Tell participants about this key by encrypting the key > with each participant's public key. Of course everyone's keys are > certified by some recognized authority. Instead of using public keys > all the time, we can also establish some long-term symmetric keys. > Does this make sense? Maybe it makes sense for groups of upto certain > size, but not for larger groups? Can we expect such larger groups in > this application? > > -- > Everyone would agree that research in group and multicast security, as > any other research, has to be driven by concrete motivation and > applications. The information about these is not widely-available or > is lacking. Let's pull our collective knowledge together and make a > strong case for this research area. > > Looking forward to hearing your thoughts. Thank you. > > Roger Khazan > MIT Lincoln Laboratory > > ----------------------------------------------------------------------- > --------- > [MSEC] applications and motivation for mcast and group security > Roger Khazan rkhazan at gmail.com > Fri Feb 18 12:51:47 EST 2005 > > I've been reading a lot about multicast and group security and I am > having hard time finding information about specific applications and > motivation, especially for decentralized solutions. One application > that comes to mind is group chat and shared collaborative workspace. > But there must be others... > > I am wondering if people could share with me their thoughts and > knowledge about *specific* applications that require multicast > security and group security. Also, which specific applications require > (or can benefit from) *decentralized* key agreement solutions? Which > ones assume *centralized* solutions? I am looking for both > single-sender and multi-sender applications. Don't limit yourself to > collaborative applications; maybe there are some involving sensors or > multicast tree management, or some military applications? I am looking > for specific descriptions, not just general areas. > > Are there systems *deployed in the world* today that utilize multicast > and group security? Which ones? Which schemes do they use? > > Are there examples in the past where we did not have group security in > place, but we wish we did? I'd like someone to make a compelling case > why all this stuff is necessary. If you work on designing group > security schemes, which big problem are you fixing? > > Which prototype systems have been implemented and are available for > download and/or purchase? > > Once I get responses from individual contributors, I will compile this > information and either send it to the list or provide it to the > individual contributors. Or, you can post your responses to the list. > > Thank you, > > Roger Khazan > MIT Lincoln Laboratory > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Mar 17 16:51:45 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24413 for ; Thu, 17 Mar 2005 16:51:45 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id DD02A8D07B; Thu, 17 Mar 2005 16:50:37 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 3134E8D014 for ; Thu, 17 Mar 2005 16:50:37 -0500 (EST) Received: (qmail 97322 invoked by uid 3269); 17 Mar 2005 21:50:37 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 97319 invoked from network); 17 Mar 2005 21:50:36 -0000 Received: from ranger.electric.net (216.129.90.29) by klesh.pair.com with SMTP; 17 Mar 2005 21:50:36 -0000 Received: from root by ranger.electric.net with emc1-ok (Exim 4.24) id 1DC2t2-0006D3-TB for msec@securemulticast.org; Thu, 17 Mar 2005 13:50:36 -0800 Received: by emcmailer; Thu, Mar 17 2005 13:50:36 -0800 Received: from [64.69.103.254] (helo=mailhost.newtecamerica.com) by ranger.electric.net with esmtp (Exim 4.24) id 1DC2t0-0006CH-Vh for msec@securemulticast.org; Thu, 17 Mar 2005 13:50:34 -0800 Received: from NTA_DOM-MTA by mailhost.newtecamerica.com with Novell_GroupWise; Thu, 17 Mar 2005 16:50:19 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Thu, 17 Mar 2005 15:50:08 -0600 From: "Girish Chandran" To: , Subject: Re: [MSEC] Re: applications and motivation for mcast and groupsecurity Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Status: Scanned by VirusSMART (s) Cc: msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Roger, As Mark mentions below satellite applications are ideally suited for multicast. Satellite broadcasts of say soccer matches (pick your favorite event) are often protected by conditional access keys for individual TV stations / subscribers. For example coverage of Major League Baseball by say Fox ....all Fox TV affiliates in the US could be part of a multicast group. Radio affiliates could be part of another group...etc. A multicast group security model is ideal here. Distance Learning...say over satellite is another app. Transport for these is typically not IP...however there is a lot of activity to move a lot of these types of apps to IP. Girish >>> Mark Baugher 3/17/2005 4:27:09 PM >>> Roger There is some work that is product-related that won't be discussed on this list before the products are announced. There are some opportunities in group and multicast applications, but IP multicast is not widely deployed and has been much slower in its adoption than some of us expected eight or ten years ago. The real-world deployments that I am aware of are largely satellite applications run by military and government agencies rather than commercial. But practically speaking, any multicast application is a potential multicast security application. And there are point-to-point applications that involve groups, which may also need group security. A multi-point teleconference, for example, might benefit from a group security model rather than a point-to-point model even if there is a centralized control unit with point-to-point connections with the participants. Mark On Mar 17, 2005, at 12:03 PM, Roger Khazan wrote: > A month ago I posted a message about motivation and applications for > group security. My original message is included at the bottom. > > I am still very interested in this topic and would appreciate people > responding to my message. > > So far, I received only two responses. Paul Gilbert and Cesc > Santasusana told me about the following applications, respectively: > > 1. Financial traders, which work together, form groups and supply and > receive trade information in these groups. In "large financials you > often see thousands of sources (traders) and hundreds of groups (split > into servers publishing market data > and traders sending)." Currently, this operation is supported by an > application from Reuters/Tibco that delivers market data to traders > and supports these groups. The application uses IP multicast with > best-effort reliability guarantees. Presently there is "no form of > security whatsoever for this multicast app." > > So, this is a good application for group security. It seems that > having a central KDS would work here, but the protocols would need to > be stateless. Does this make sense? What are the security requirements > here? > > 2. I am still learning the specifics of this one, but it is about > supporting decentralized communication in military on-the-move > environments. For example, there is a need to support secure voice > conferencing among small groups of people. It is reasonable to assume > that initializations (e.g., distribution of keying material) are > handled by a centralized manager, but "daily operations must be able > to work without access to the central service." > > The environment, scale, and requirements of this application are very > different from the first one. It seems that a *non-group* solution > would work well here: Use a fresh symmetric key for each voice > conference. Tell participants about this key by encrypting the key > with each participant's public key. Of course everyone's keys are > certified by some recognized authority. Instead of using public keys > all the time, we can also establish some long-term symmetric keys. > Does this make sense? Maybe it makes sense for groups of upto certain > size, but not for larger groups? Can we expect such larger groups in > this application? > > -- > Everyone would agree that research in group and multicast security, as > any other research, has to be driven by concrete motivation and > applications. The information about these is not widely-available or > is lacking. Let's pull our collective knowledge together and make a > strong case for this research area. > > Looking forward to hearing your thoughts. Thank you. > > Roger Khazan > MIT Lincoln Laboratory > > ----------------------------------------------------------------------- > --------- > [MSEC] applications and motivation for mcast and group security > Roger Khazan rkhazan at gmail.com > Fri Feb 18 12:51:47 EST 2005 > > I've been reading a lot about multicast and group security and I am > having hard time finding information about specific applications and > motivation, especially for decentralized solutions. One application > that comes to mind is group chat and shared collaborative workspace. > But there must be others... > > I am wondering if people could share with me their thoughts and > knowledge about *specific* applications that require multicast > security and group security. Also, which specific applications require > (or can benefit from) *decentralized* key agreement solutions? Which > ones assume *centralized* solutions? I am looking for both > single-sender and multi-sender applications. Don't limit yourself to > collaborative applications; maybe there are some involving sensors or > multicast tree management, or some military applications? I am looking > for specific descriptions, not just general areas. > > Are there systems *deployed in the world* today that utilize multicast > and group security? Which ones? Which schemes do they use? > > Are there examples in the past where we did not have group security in > place, but we wish we did? I'd like someone to make a compelling case > why all this stuff is necessary. If you work on designing group > security schemes, which big problem are you fixing? > > Which prototype systems have been implemented and are available for > download and/or purchase? > > Once I get responses from individual contributors, I will compile this > information and either send it to the list or provide it to the > individual contributors. Or, you can post your responses to the list. > > Thank you, > > Roger Khazan > MIT Lincoln Laboratory > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Mar 18 12:37:50 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02318 for ; Fri, 18 Mar 2005 12:37:48 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id A056B8CCD2; Fri, 18 Mar 2005 12:37:50 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 94E348CCC1 for ; Fri, 18 Mar 2005 12:37:49 -0500 (EST) Received: (qmail 96621 invoked by uid 3269); 18 Mar 2005 17:37:49 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 96618 invoked from network); 18 Mar 2005 17:37:49 -0000 Received: from lauga.ssvl.kth.se (HELO coruscant.bilien.org) (192.16.125.77) by klesh.pair.com with SMTP; 18 Mar 2005 17:37:49 -0000 Received: from localhost (localhost [127.0.0.1]) by coruscant.bilien.org (Postfix) with ESMTP id 7A37C92D74 for ; Fri, 18 Mar 2005 18:56:44 +0100 (CET) Received: from coruscant.bilien.org ([127.0.0.1]) by localhost (coruscant [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22349-04 for ; Fri, 18 Mar 2005 18:56:44 +0100 (CET) Received: by coruscant.bilien.org (Postfix, from userid 1000) id 15DC69299D; Fri, 18 Mar 2005 18:56:44 +0100 (CET) Date: Fri, 18 Mar 2005 18:56:43 +0100 From: Johan Bilien To: msec@securemulticast.org Message-ID: <20050318175643.GA22416@via.ecp.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at bilien.org Subject: [MSEC] MIKEY D-H + SIP layer signature X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi, I would like to discuss the possibility of using the Diffie-Hellman scheme in MIKEY with a digital signature at a higher layer (SIP + S/MIME for instance). Having a signature covering the Diffie-Hellman message is necessary to prevent the man-in-the-middle attack. However, having the option to place the signature at a higher layer, thus covering more information, would have several advantages. If we take the example of MIKEY/SDP/SIP: . by using S/MIME or another mechanism (Identity: header...) one can protect the whole SDP. This "glues" the MIKEY message to that SDP (the MIKEY message cannot be picked up from an INVITE and used in another one). It also removes the possibility of a downgrade attack, where someone would replace the SAVP profile with a usual RTP, and remove the MIKEY message. Of courses protecting the SDP has advantages independant of MIKEY, such as preventing the change of the c: field. . From an implementation point of view, having the authentication at the SIP layer also makes sense, since if the authentication fails, a SIP message should be sent back (without having to parse the media part). It also allows the callee to make filtering decision based on the caller's identity, without having to go down to the media layer. Of course one can use the SIP layer signature on top of the signed MIKEY message, but that is a waste of resource, the MIKEY message being signed twice. So I think being able to create unsigned D-H MIKEY messages would be a good thing. Regards, Johan. _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Mar 21 10:34:25 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17102 for ; Mon, 21 Mar 2005 10:34:25 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id CC2918C672; Mon, 21 Mar 2005 10:34:26 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 9FE598C53E for ; Mon, 21 Mar 2005 10:34:25 -0500 (EST) Received: (qmail 35103 invoked by uid 3269); 21 Mar 2005 15:34:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 35100 invoked from network); 21 Mar 2005 15:34:25 -0000 Received: from penguin.ericsson.se (193.180.251.47) by klesh.pair.com with SMTP; 21 Mar 2005 15:34:25 -0000 Received: from esealmw129.eemea.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j2LFXakL011723; Mon, 21 Mar 2005 16:34:23 +0100 (MET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Mar 2005 16:34:15 +0100 Received: from ericsson.com ([147.214.118.190]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Mar 2005 16:34:15 +0100 Message-ID: <423EE976.9010300@ericsson.com> Date: Mon, 21 Mar 2005 16:34:14 +0100 From: =?ISO-8859-1?Q?Mats_N=E4slund?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Johan Bilien Subject: Re: [MSEC] MIKEY D-H + SIP layer signature References: <20050318175643.GA22416@via.ecp.fr> In-Reply-To: <20050318175643.GA22416@via.ecp.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2005 15:34:15.0039 (UTC) FILETIME=[702CE8F0:01C52E2B] Cc: msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Hi Johan, We discussed your proposal among the MIKEY authors, and we have the following comments. Johan Bilien wrote: > I would like to discuss the possibility of using the Diffie-Hellman > scheme in MIKEY with a digital signature at a higher layer (SIP + > S/MIME for instance). > > Having a signature covering the Diffie-Hellman message is necessary to > prevent the man-in-the-middle attack. However, having the option to > place the signature at a higher layer, thus covering more information, > would have several advantages. If we take the example of MIKEY/SDP/SIP: > > . by using S/MIME or another mechanism (Identity: header...) one can > protect the whole SDP. This "glues" the MIKEY message to that SDP > (the MIKEY message cannot be picked up from an INVITE and used > in another one). It also removes the possibility of a downgrade Yes, but such an attack would as far as we see "only" have DoS effects since different keys would be created at Initiator/Responder sides. > attack, where someone would replace the SAVP profile with a usual > RTP, and remove the MIKEY message. Of courses protecting the SDP > has advantages independant of MIKEY, such as preventing the change > of the c: field. The same is possible even with signature at the SIP level: just peel off the signature part, delete the MIKEY line, and change SAVP to AVP. > > . From an implementation point of view, having the authentication at > the SIP layer also makes sense, since if the authentication fails, a > SIP message should be sent back (without having to parse the media > part). It also allows the callee to make filtering decision based on > the caller's identity, without having to go down to the media layer. > > Of course one can use the SIP layer signature on top of the signed MIKEY > message, but that is a waste of resource, the MIKEY message being signed > twice. So I think being able to create unsigned D-H MIKEY messages would > be a good thing. Note though that at the same time, we increase the possibility of (perhaps by misstake) using MIKEY-DH without authentication at all. It seems safer for MIKEY to always take care of its "own" security, not trusting that someone else does it. Cheers, /Mats _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Mar 21 11:03:13 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20236 for ; Mon, 21 Mar 2005 11:03:12 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 5A5428CC0D; Mon, 21 Mar 2005 11:03:14 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 6D6028CC03 for ; Mon, 21 Mar 2005 11:03:12 -0500 (EST) Received: (qmail 40944 invoked by uid 3269); 21 Mar 2005 16:03:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 40941 invoked from network); 21 Mar 2005 16:03:12 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by klesh.pair.com with SMTP; 21 Mar 2005 16:03:12 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 21 Mar 2005 08:03:12 -0800 X-IronPort-AV: i="3.91,107,1110182400"; d="scan'208"; a="238240603:sNHT30640116" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2LG32gE028307; Mon, 21 Mar 2005 08:03:03 -0800 (PST) Received: from [192.168.0.11] (sjc-vpn4-299.cisco.com [10.21.81.43]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j2LFtwDE005472; Mon, 21 Mar 2005 07:55:58 -0800 In-Reply-To: <423EE976.9010300@ericsson.com> References: <20050318175643.GA22416@via.ecp.fr> <423EE976.9010300@ericsson.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Mark Baugher Subject: Re: [MSEC] MIKEY D-H + SIP layer signature Date: Mon, 21 Mar 2005 08:02:06 -0800 To: =?ISO-8859-1?Q?Mats_N=E4slund?= X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1111420558.412573"; x:"432200"; a:"rsa-sha1"; b:"nofws:2237"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"F6QyrwTePITGf1W9h829LwUk4iMfZeH5076HmPb9nuN7ILGfLWnzJ+bK/AnGW3AP9FCn1J9Q" "sT5Lq2r2y27LlNJtzAYEnH2A2qXaCaxYUkmWkZg0Efnisv7mFG8KKdJ6cJXqz/7ychU21rmht3e" "3A2q34gtTi/9hwgfDpa5KdlU="; c:"From: Mark Baugher "; c:"Subject: Re: [MSEC] MIKEY D-H + SIP layer signature"; c:"Date: Mon, 21 Mar 2005 08:02:06 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Cc: msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: quoted-printable hi Mats When I saw Johan's note, it occurred to me that he should use=20 Security Descriptions when SIP with S/MIME is used. I believe that is=20= what is being standardized in the SIP WGs. Mark On Mar 21, 2005, at 7:34 AM, Mats N=E4slund wrote: > Hi Johan, > > We discussed your proposal among the MIKEY authors, and we have > the following comments. > > Johan Bilien wrote: > >> I would like to discuss the possibility of using the Diffie-Hellman >> scheme in MIKEY with a digital signature at a higher layer (SIP + >> S/MIME for instance). >> Having a signature covering the Diffie-Hellman message is necessary = to >> prevent the man-in-the-middle attack. However, having the option to >> place the signature at a higher layer, thus covering more = information, >> would have several advantages. If we take the example of=20 >> MIKEY/SDP/SIP: >> . by using S/MIME or another mechanism (Identity: header...) one = can >> protect the whole SDP. This "glues" the MIKEY message to that SDP >> (the MIKEY message cannot be picked up from an INVITE and used >> in another one). It also removes the possibility of a downgrade > > > Yes, but such an attack would as far as we see "only" have DoS > effects since different keys would be created at Initiator/Responder > sides. > >> attack, where someone would replace the SAVP profile with a usual >> RTP, and remove the MIKEY message. Of courses protecting the SDP >> has advantages independant of MIKEY, such as preventing the = change >> of the c: field. > > > The same is possible even with signature at the SIP level: just peel > off the signature part, delete the MIKEY line, and change SAVP to AVP. > >> . =46rom an implementation point of view, having the authentication = at >> the SIP layer also makes sense, since if the authentication=20 >> fails, a >> SIP message should be sent back (without having to parse the = media >> part). It also allows the callee to make filtering decision based=20= >> on >> the caller's identity, without having to go down to the media=20 >> layer. >> Of course one can use the SIP layer signature on top of the signed=20 >> MIKEY >> message, but that is a waste of resource, the MIKEY message being=20 >> signed >> twice. So I think being able to create unsigned D-H MIKEY messages=20 >> would >> be a good thing. > > Note though that at the same time, we increase the possibility of > (perhaps by misstake) using MIKEY-DH without authentication at all. > It seems safer for MIKEY to always take care of its "own" > security, not trusting that someone else does it. > > Cheers, > > /Mats > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Mar 22 04:20:42 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20465 for ; Tue, 22 Mar 2005 04:20:40 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id EA8578C96D; Tue, 22 Mar 2005 04:20:40 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id BCC168C963 for ; Tue, 22 Mar 2005 04:20:39 -0500 (EST) Received: (qmail 56807 invoked by uid 3269); 22 Mar 2005 09:20:39 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 56799 invoked from network); 22 Mar 2005 09:20:39 -0000 Received: from lauga.ssvl.kth.se (HELO coruscant.bilien.org) (192.16.125.77) by klesh.pair.com with SMTP; 22 Mar 2005 09:20:39 -0000 Received: from localhost (localhost [127.0.0.1]) by coruscant.bilien.org (Postfix) with ESMTP id 0BEAE92D74 for ; Tue, 22 Mar 2005 10:40:06 +0100 (CET) Received: from coruscant.bilien.org ([127.0.0.1]) by localhost (coruscant [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11646-05 for ; Tue, 22 Mar 2005 10:40:06 +0100 (CET) Received: by coruscant.bilien.org (Postfix, from userid 1000) id 85CEB9299D; Tue, 22 Mar 2005 10:40:06 +0100 (CET) Date: Tue, 22 Mar 2005 10:40:06 +0100 From: Johan Bilien To: msec@securemulticast.org Subject: Re: [MSEC] MIKEY D-H + SIP layer signature Message-ID: <20050322094006.GA11689@via.ecp.fr> References: <20050318175643.GA22416@via.ecp.fr> <423EE976.9010300@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <423EE976.9010300@ericsson.com> User-Agent: Mutt/1.3.28i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at bilien.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 8bit On Mon, Mar 21, 2005, Mats Näslund wrote: > We discussed your proposal among the MIKEY authors, and we have > the following comments. Thanks for your answer. > > . by using S/MIME or another mechanism (Identity: header...) one can > > protect the whole SDP. This "glues" the MIKEY message to that SDP > > (the MIKEY message cannot be picked up from an INVITE and used > > in another one). It also removes the possibility of a downgrade > > > Yes, but such an attack would as far as we see "only" have DoS > effects since different keys would be created at Initiator/Responder > sides. Yes, but that means that you cannot rely on the MIKEY message to provide authentication of the SIP message. If you need such an authentication (which you probably want if you care about security enough to use MIKEY + SRTP), then you need an authentication at the SIP layer, and end up having two digital signatures (and possibly two ways of carrying Id/Certificates, which can be the source of interoperability problems). > > attack, where someone would replace the SAVP profile with a usual > > RTP, and remove the MIKEY message. Of courses protecting the SDP > > has advantages independant of MIKEY, such as preventing the change > > of the c: field. > > > The same is possible even with signature at the SIP level: just peel > off the signature part, delete the MIKEY line, and change SAVP to AVP. Agreed. > >Of course one can use the SIP layer signature on top of the signed MIKEY > >message, but that is a waste of resource, the MIKEY message being signed > >twice. So I think being able to create unsigned D-H MIKEY messages would > >be a good thing. > > Note though that at the same time, we increase the possibility of > (perhaps by misstake) using MIKEY-DH without authentication at all. > It seems safer for MIKEY to always take care of its "own" > security, not trusting that someone else does it. But then why, in case of the pre-shared key scheme, do you allow the use of the NULL MAC and encryption algorithms, when "the underlying protocols can guarantee security. The main reason for including this is for specific SIP scenarios, where SDP is protected end-to-end." (section 4.2.4). Why allow to delegate integrity protection to lower layers in the case of PSK, and not for D-H? Best regards, Johan. _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Mar 22 12:26:20 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07768 for ; Tue, 22 Mar 2005 12:26:18 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 034478C4EA; Tue, 22 Mar 2005 12:26:18 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 55DC78C824 for ; Tue, 22 Mar 2005 12:26:16 -0500 (EST) Received: (qmail 46461 invoked by uid 3269); 22 Mar 2005 17:26:16 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 46456 invoked from network); 22 Mar 2005 17:26:15 -0000 Received: from albatross.ericsson.se (193.180.251.49) by klesh.pair.com with SMTP; 22 Mar 2005 17:26:15 -0000 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j2MHQEfm010490; Tue, 22 Mar 2005 18:26:14 +0100 (MET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Mar 2005 18:26:12 +0100 Received: from ericsson.com ([147.214.97.151]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Mar 2005 18:26:11 +0100 Message-ID: <42405534.2070602@ericsson.com> Date: Tue, 22 Mar 2005 18:26:12 +0100 From: =?ISO-8859-1?Q?Mats_N=E4slund?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Johan Bilien Subject: Re: [MSEC] MIKEY D-H + SIP layer signature References: <20050318175643.GA22416@via.ecp.fr> <423EE976.9010300@ericsson.com> <20050322094006.GA11689@via.ecp.fr> In-Reply-To: <20050322094006.GA11689@via.ecp.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 22 Mar 2005 17:26:11.0936 (UTC) FILETIME=[3E2BCE00:01C52F04] Cc: msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 8bit Hi Johan, Johan Bilien wrote: > On Mon, Mar 21, 2005, Mats Näslund wrote: > > We discussed your proposal among the MIKEY authors, and we have > > the following comments. > > Thanks for your answer. > > > > . by using S/MIME or another mechanism (Identity: header...) one can > > > protect the whole SDP. This "glues" the MIKEY message to that SDP > > > (the MIKEY message cannot be picked up from an INVITE and used > > > in another one). It also removes the possibility of a downgrade > > > > > > Yes, but such an attack would as far as we see "only" have DoS > > effects since different keys would be created at Initiator/Responder > > sides. > > Yes, but that means that you cannot rely on the MIKEY message to provide > authentication of the SIP message. If you need such an authentication Indeed. It is outside the scope of MIKEY to protect non-MIKEY things. Conversely, MIKEY should not have to trust that something else takes cares of MIKEY's own security. > (which you probably want if you care about security enough to use MIKEY > + SRTP), then you need an authentication at the SIP layer, and end up > having two digital signatures (and possibly two ways of carrying > Id/Certificates, which can be the source of interoperability problems). First, one should not mix-up the need for end-to-end protection of the media with the required security for the signaling. While end-to-end protection is often desired for the media, end-to-end protection of signaling may not always be possible (as SIP ALGs may need to modify messages for NAT traversal etc). Hop-by-hop protection of SIP using TLS or IPsec will be one solution that we will see. This is why we have not made any assumptions on the SIP signaling (more than that it is reliable). In other words, MIKEY is intended to be an e2e mechanism, but SIP itself may not always be. Secondly, you seem to want to use D-H, which is a really heavy mechanism, but at the same time the application you have in mind seems to have performance trouble with two signatures. Of course, D-H + 2 signatures is more expensive than D-H + one signature, but the difference is not extreme in most cases, and there are other "modes" in MIKEY aimed exactly at constrained applications. We do not see why there would be interop problems: MIKEY specifies how MIKEY is secured, the SIP security (whatever you use) should similarly be well-defined. By creating a dependence between MIKEY and the transport mechanism that carries MIKEY, it could just as well be that interop problems are *created*. > > > > attack, where someone would replace the SAVP profile with a usual > > > RTP, and remove the MIKEY message. Of courses protecting the SDP > > > has advantages independant of MIKEY, such as preventing the change > > > of the c: field. > > > > > > The same is possible even with signature at the SIP level: just peel > > off the signature part, delete the MIKEY line, and change SAVP to AVP. > > Agreed. > > > >Of course one can use the SIP layer signature on top of the signed MIKEY > > >message, but that is a waste of resource, the MIKEY message being signed > > >twice. So I think being able to create unsigned D-H MIKEY messages would > > >be a good thing. > > > > Note though that at the same time, we increase the possibility of > > (perhaps by misstake) using MIKEY-DH without authentication at all. > > It seems safer for MIKEY to always take care of its "own" > > security, not trusting that someone else does it. > > But then why, in case of the pre-shared key scheme, do you allow the use > of the NULL MAC and encryption algorithms, when "the underlying protocols Yes, this is confusing, we agree. See below for an elaboration/clarification. > can guarantee security. The main reason for including this is for > specific SIP scenarios, where SDP is protected end-to-end." (section > 4.2.4). Why allow to delegate integrity protection to lower layers in the > case of PSK, and not for D-H? First of all, the intended use of "pre-shared with NULL" is as follows: Security for multimedia in general, and in particular integration of key mgmt in SIP, is perhaps not yet an "everyday thing". It is therefore likely that developers will want to experiment (inter-op tests etc) with the protocol(s). When you do the first initial tests, you are really mainly concerned that the "communication" works, and you would like to be sure that basic message parsing etc, works before you make things more likely to go wrong by adding cryptography...;-) Therefore, the NULL mechanism's intended use is during testing, where you really don't care if you achieve security or not; you're just happy enough if you get it to work... Now, a "NULL" algorithm is essentially the same, regardless of if it's "pre-shared NULL", or "public-key NULL". We needed a way to signal NULL security for testing, and we made the arbitrary choice of doing that via the pre-shared mode. We could just as well have defined a NULL public-key transform for this purpose. We agree that this is not well documented, and is probably something we should take care of in a future update. As you will see though, we raise strong warning flags against using the NULL options, and we fell uncomfortable about introducing more NULL options: while any non-authentiocated mode probably can be attacked, D-H is notorious for its sensitivity to MITM, so we think that using D-H with NULL authentication (perhaps by mistake) is particularly sensitive to attacks. Hope this provides some rationale. Best, /Mats _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Mar 23 02:51:12 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12790 for ; Wed, 23 Mar 2005 02:51:12 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 3CB228C216; Wed, 23 Mar 2005 02:51:12 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 5EC048C636 for ; Wed, 23 Mar 2005 02:51:10 -0500 (EST) Received: (qmail 30488 invoked by uid 3269); 23 Mar 2005 07:51:10 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 30484 invoked from network); 23 Mar 2005 07:51:09 -0000 Received: from goliath.siemens.de (192.35.17.28) by klesh.pair.com with SMTP; 23 Mar 2005 07:51:09 -0000 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j2N7p7Kd030610; Wed, 23 Mar 2005 08:51:07 +0100 Received: from MCHN070C (MCHN070C.ww002.siemens.net [139.23.204.46] (may be forged)) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j2N7p6Xu013938; Wed, 23 Mar 2005 08:51:07 +0100 From: "Steffen Fries" Organization: Siemens AG To: Johan Bilien , "=?ISO-8859-1?Q?Mats_N=E4slund?=" Date: Wed, 23 Mar 2005 08:51:02 +0100 MIME-Version: 1.0 Subject: Re: [MSEC] MIKEY D-H + SIP layer signature Message-ID: <42412DF6.11984.5621528@localhost> Priority: normal In-reply-to: <42405534.2070602@ericsson.com> References: <20050322094006.GA11689@via.ecp.fr> X-mailer: Pegasus Mail for Windows (4.21c) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: Quoted-printable Content-description: Mail message body Cc: msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: steffen.fries@siemens.com List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: Quoted-printable Hi Johan, additionally to the points from Mats, there is a draft available, which is currently in IESG review, which provides an extension to MIKEY , were the DH is protected using a pre-shared key (draft-ietf-msec-mikey-dhhmac-09.txt). Here basically the MIKEY message is integrity protected using HMAC-SHA1 and the pre-shared key. If you are looking for a solution which is not consuming to much performance (compared to tweo digital signatures) this might be interesting for you. Regards Steffen Date sent: Tue, 22 Mar 2005 18:26:12 +0100 From: Mats N=E4slund To: Johan Bilien Subject: Re: [MSEC] MIKEY D-H + SIP layer signature Copies to: msec@securemulticast.org > Hi Johan, > > Johan Bilien wrote: > > > On Mon, Mar 21, 2005, Mats N=E4slund wrote: > > > We discussed your proposal among the MIKEY authors, and we have > > > the following comments. > > > > Thanks for your answer. > > > > > > . by using S/MIME or another mechanism (Identity: header...) > > > > one can > > > > protect the whole SDP. This "glues" the MIKEY message to > > > > that SDP (the MIKEY message cannot be picked up from an > > > > INVITE and used in another one). It also removes the > > > > possibility of a downgrade > > > > > > > > > Yes, but such an attack would as far as we see "only" have DoS > > > effects since different keys would be created at > > > Initiator/Responder sides. > > > > Yes, but that means that you cannot rely on the MIKEY message to > > provide authentication of the SIP message. If you need such an > > authentication > > Indeed. It is outside the scope of MIKEY to protect non-MIKEY > things. Conversely, MIKEY should not have to trust that something else > takes cares of MIKEY's own security. > > > (which you probably want if you care about security enough to use > > MIKEY > > + SRTP), then you need an authentication at the SIP layer, and end > > + up > > having two digital signatures (and possibly two ways of carrying > > Id/Certificates, which can be the source of interoperability > > problems). > > First, one should not mix-up the need for end-to-end protection of the > media with the required security for the signaling. While end-to-end > protection is often desired for the media, end-to-end protection of > signaling may not always be possible (as SIP ALGs may need to modify > messages for NAT traversal etc). Hop-by-hop protection of SIP using > TLS or IPsec will be one solution that we will see. This is why we > have not made any assumptions on the SIP signaling (more than that it > is reliable). In other words, MIKEY is intended to be an e2e > mechanism, but SIP itself may not always be. > > Secondly, you seem to want to use D-H, which is a really heavy > mechanism, but at the same time the application you have in mind > seems to have performance trouble with two signatures. Of course, D-H > + 2 signatures is more expensive than D-H + one signature, but the > difference is not extreme in most cases, and there are other "modes" > in MIKEY aimed exactly at constrained applications. > > We do not see why there would be interop problems: MIKEY specifies how > MIKEY is secured, the SIP security (whatever you use) should similarly > be well-defined. By creating a dependence between MIKEY and the > transport mechanism that carries MIKEY, it could just as well be that > interop problems are *created*. > > > > > > > > attack, where someone would replace the SAVP profile with a > > > > usual RTP, and remove the MIKEY message. Of courses > > > > protecting the SDP has advantages independant of MIKEY, such > > > > as preventing the change of the c: field. > > > > > > > > > The same is possible even with signature at the SIP level: just > > > peel off the signature part, delete the MIKEY line, and change > > > SAVP to AVP. > > > > Agreed. > > > > > >Of course one can use the SIP layer signature on top of the > > > >signed MIKEY message, but that is a waste of resource, the MIKEY > > > >message being signed twice. So I think being able to create > > > >unsigned D-H MIKEY messages would be a good thing. > > > > > > Note though that at the same time, we increase the possibility of > > > (perhaps by misstake) using MIKEY-DH without authentication at > > > all. It seems safer for MIKEY to always take care of its "own" > > > security, not trusting that someone else does it. > > > > But then why, in case of the pre-shared key scheme, do you allow the > > use of the NULL MAC and encryption algorithms, when "the underlying > > protocols > > Yes, this is confusing, we agree. See below for an > elaboration/clarification. > > > can guarantee security. The main reason for including this is for > > specific SIP scenarios, where SDP is protected end-to-end." (section > > 4.2.4). Why allow to delegate integrity protection to lower layers > > in the case of PSK, and not for D-H? > > First of all, the intended use of "pre-shared with NULL" is as > follows: > > Security for multimedia in general, and in particular integration of > key mgmt in SIP, is perhaps not yet an "everyday thing". It is > therefore likely that developers will want to experiment (inter-op > tests etc) with the protocol(s). When you do the first initial tests, > you are really mainly concerned that the "communication" works, and > you would like to be sure that basic message parsing etc, works before > you make things more likely to go wrong by adding cryptography...;-) > Therefore, the NULL mechanism's intended use is during testing, where > you really don't care if you achieve security or not; you're just > happy enough if you get it to work... > > Now, a "NULL" algorithm is essentially the same, regardless of if it's > "pre-shared NULL", or "public-key NULL". We needed a way to signal > NULL security for testing, and we made the arbitrary choice of doing > that via the pre-shared mode. We could just as well have defined a > NULL public-key transform for this purpose. > > We agree that this is not well documented, and is probably something > we should take care of in a future update. As you will see though, we > raise strong warning flags against using the NULL options, and we fell > uncomfortable about introducing more NULL options: while any > non-authentiocated mode probably can be attacked, D-H is notorious for > its sensitivity to MITM, so we think that using D-H with NULL > authentication (perhaps by mistake) is particularly sensitive to > attacks. > > Hope this provides some rationale. > > Best, > > /Mats > > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec ----------------------------------------------------------- Steffen Fries, Siemens AG, CT IC 3 Otto-Hahn-Ring 6, D-81730 Munich, Germany Phone: (+49) 89 / 636-53403, Fax : (+49) 89 / 636-48000 Email: Steffen.Fries@siemens.com ----------------------------------------------------------- _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Mar 23 05:57:46 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29519 for ; Wed, 23 Mar 2005 05:57:39 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id E47DC8C1D7; Wed, 23 Mar 2005 05:57:40 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id BB4A08C1B1 for ; Wed, 23 Mar 2005 05:57:39 -0500 (EST) Received: (qmail 23718 invoked by uid 3269); 23 Mar 2005 10:57:39 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 23714 invoked from network); 23 Mar 2005 10:57:39 -0000 Received: from lauga.ssvl.kth.se (HELO coruscant.bilien.org) (192.16.125.77) by klesh.pair.com with SMTP; 23 Mar 2005 10:57:39 -0000 Received: from localhost (localhost [127.0.0.1]) by coruscant.bilien.org (Postfix) with ESMTP id E12EF92D74 for ; Wed, 23 Mar 2005 12:17:21 +0100 (CET) Received: from coruscant.bilien.org ([127.0.0.1]) by localhost (coruscant [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18902-08 for ; Wed, 23 Mar 2005 12:17:21 +0100 (CET) Received: by coruscant.bilien.org (Postfix, from userid 1000) id 56C6C9299D; Wed, 23 Mar 2005 12:17:21 +0100 (CET) Date: Wed, 23 Mar 2005 12:17:21 +0100 From: Johan Bilien To: msec@securemulticast.org Subject: Re: [MSEC] MIKEY D-H + SIP layer signature Message-ID: <20050323111720.GA18934@via.ecp.fr> References: <20050318175643.GA22416@via.ecp.fr> <423EE976.9010300@ericsson.com> <20050322094006.GA11689@via.ecp.fr> <42405534.2070602@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <42405534.2070602@ericsson.com> User-Agent: Mutt/1.3.28i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at bilien.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 8bit On Tue, Mar 22, 2005, Mats Näslund wrote: > >Yes, but that means that you cannot rely on the MIKEY message to provide > >authentication of the SIP message. If you need such an authentication > > Indeed. It is outside the scope of MIKEY to protect non-MIKEY > things. Conversely, MIKEY should not have to trust that something > else takes cares of MIKEY's own security. Having each layer provide each own security mechanism can also be a hassle and a waste of resource. > >(which you probably want if you care about security enough to use MIKEY > >+ SRTP), then you need an authentication at the SIP layer, and end up > >having two digital signatures (and possibly two ways of carrying > >Id/Certificates, which can be the source of interoperability problems). > > First, one should not mix-up the need for end-to-end protection of > the media with the required security for the signaling. While end-to-end > protection is often desired for the media, end-to-end protection of > signaling may not always be possible (as SIP ALGs may need to modify > messages for NAT traversal etc). Hop-by-hop protection of SIP using > TLS or IPsec will be one solution that we will see. This is why we > have not made any assumptions on the SIP signaling (more than that it > is reliable). In other words, MIKEY is intended to be an e2e mechanism, > but SIP itself may not always be. I wasn't mixing hop-by-hop encryption of the signaling with end-to-end encryption of the media. By "authentication of the SIP message", I mean end-to-end authentication and integrity protection of the SIP messages, as suggested in RFC3261 section 23, using S/MIME. This kind of end-to-end authentication of the caller to the callee is necessary to prevent voice spam and such. My point is that both MIKEY/D-H, to prevent man-in-the-middle attacks, and SIP, to authenticate the users in a call and to protect the media description (including the MIKEY attribute) from alteration, share the need for a digital signature, so it would make sence to have a common one instead of two. Note that this is not limited to SIP, in any session establishment mechanism where the media session will be secure with MIKEY/SRTP, you probably want to authenticate the session establishment messages as well, and if they carry a MIKEY message you will always end up having authentication over authentication. Therefore I think it would make sense to have an option for MIKEY to delegate its authentication to lower levels. > Secondly, you seem to want to use D-H, which is a really heavy > mechanism, but at the same time the application you have in mind > seems to have performance trouble with two signatures. Of course, > D-H + 2 signatures is more expensive than D-H + one signature, > but the difference is not extreme in most cases, and there are > other "modes" in MIKEY aimed exactly at constrained applications. Oh I was not really considering performance issues. It's more for the sake of making things feel "right" :) Note though that decoding an RSA digital signature isn't completely neglictable when compared to deriving a D-H key (factor 10 or something), see [1]. > We do not see why there would be interop problems: MIKEY specifies > how MIKEY is secured, the SIP security (whatever you use) should > similarly be well-defined. By creating a dependence between MIKEY > and the transport mechanism that carries MIKEY, it could just as > well be that interop problems are *created*. Does that mean that both S/MIME and MIKEY will contain the certificates for example? Shall the IDs always match? In a ideal world, MIKEY would be completely independant of other layers. Unfortunately it is already not the case (just see all the references to SIP in the MIKEY RFC). For instance, if there is an error in the MIKEY message, a SIP error message will be returned. > First of all, the intended use of "pre-shared with NULL" is as follows: > > Security for multimedia in general, and in particular integration of > key mgmt in SIP, is perhaps not yet an "everyday thing". It is therefore > likely that developers will want to experiment (inter-op tests etc) > with the protocol(s). When you do the first initial tests, you are > really mainly concerned that the "communication" works, and you would > like to be sure that basic message parsing etc, works before you make > things more likely to go wrong by adding cryptography...;-) Therefore, > the NULL mechanism's intended use is during testing, where you really > don't care if you achieve security or not; you're just happy > enough if you get it to work... > > Now, a "NULL" algorithm is essentially the same, regardless of if it's > "pre-shared NULL", or "public-key NULL". We needed a way to signal NULL > security for testing, and we made the arbitrary choice of doing that > via the pre-shared mode. We could just as well have defined a NULL > public-key transform for this purpose. > > We agree that this is not well documented, and is probably something we > should take care of in a future update. (...) Indeed :) Thanks a lot for this great feedback. I now understand more your point of view, that MIKEY should be self-contained as much as possible. However I still think that interactions with other layers cannot be avoided, and adding having MIKEY know about the authentication capabilities of lower layers would not be a hassle. Best regards, Johan. [1] http://www.minisip.org/publications/secvoip.pdf _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Mar 23 14:06:57 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20605 for ; Wed, 23 Mar 2005 14:06:55 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id E274F8C466; Wed, 23 Mar 2005 14:06:55 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id B1CBB8C414 for ; Wed, 23 Mar 2005 14:06:54 -0500 (EST) Received: (qmail 19526 invoked by uid 3269); 23 Mar 2005 19:06:54 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 19523 invoked from network); 23 Mar 2005 19:06:54 -0000 Received: from m5tmail.m5t.com (66.129.134.18) by klesh.pair.com with SMTP; 23 Mar 2005 19:06:54 -0000 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Mar 2005 14:06:53 -0500 Message-ID: Thread-Topic: Question regarding public Key padding types. Thread-Index: AcUv23l+g15qxx+iTcusTLWcUyQb0A== From: "Christian Beaulieu" To: Subject: [MSEC] Question regarding public Key padding types. X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1520815473==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org This is a multi-part message in MIME format. --===============1520815473== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52FDB.79E809D7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C52FDB.79E809D7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We are looking at the public key payload at the moment and we are wondering something. =20 In a certificate, from what we have found the public key itself is by default used with PKCS 1 v1.5 padding.=20 =20 In the payload description it states that the algorithm used is implicit from that defined in the certificate. =20 We haven't found a way to specify another padding type for RSA public keys. I believe there must be a way since it specifically states that PKCS OAEP padding can be used or are we just misled. =20 Thank you in advance. =20 Christian. =20 =20 ------_=_NextPart_001_01C52FDB.79E809D7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We are looking at the public key payload at the = moment and we are wondering something.

 

In a certificate, from what we have found the public = key itself is by default used with PKCS 1 v1.5 padding. =

 

In the payload description it states that the = algorithm used is implicit from that defined in the = certificate.

 

We haven’t found a way to specify another = padding type for RSA public keys. I believe there must be a way since it specifically = states that PKCS OAEP padding can be used or are we just = misled.

 

Thank you in advance.

 

Christian.

 

 

------_=_NextPart_001_01C52FDB.79E809D7-- --===============1520815473== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --===============1520815473==-- From msec-bounces@securemulticast.org Mon Mar 28 19:34:27 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00277 for ; Mon, 28 Mar 2005 19:34:24 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 399F88C91E; Mon, 28 Mar 2005 19:34:24 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 933A18C8C4 for ; Mon, 28 Mar 2005 19:34:22 -0500 (EST) Received: (qmail 8799 invoked by uid 3269); 29 Mar 2005 00:34:22 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 8796 invoked from network); 29 Mar 2005 00:34:22 -0000 Received: from sj-iport-2-in.cisco.com (HELO sj-iport-2.cisco.com) (171.71.176.71) by klesh.pair.com with SMTP; 29 Mar 2005 00:34:22 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 28 Mar 2005 16:34:22 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2T0YJDr006561; Mon, 28 Mar 2005 16:34:19 -0800 (PST) Received: from cisco.com (dhcp-128-107-163-98.cisco.com [128.107.163.98]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BDK06095; Mon, 28 Mar 2005 16:34:18 -0800 (PST) Message-ID: <4248A2A5.7000302@cisco.com> Date: Mon, 28 Mar 2005 16:34:45 -0800 From: Brian Weis User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Beaulieu Subject: Re: [MSEC] Question regarding public Key padding types. References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 8bit Hi Christian, Christian Beaulieu wrote: > We are looking at the public key payload at the moment and we are > wondering something. > > In a certificate, from what we have found the public key itself is by > default used with PKCS 1 v1.5 padding. > > In the payload description it states that the algorithm used is > implicit from that defined in the certificate. > > We haven’t found a way to specify another padding type for RSA public > keys. I believe there must be a way since it specifically states that > PKCS OAEP padding can be used or are we just misled. > The latest version of the document (draft-ietf-msec-ipsec-signatures-04.txt) describes the use of PKCS 1 v1.5 padding. However, reviewers have suggested that PKCS PSS padding should be used instead, so you should consider actual padding type to be undecided until the next version is released. Brian > Thank you in advance. > > Christian. > >------------------------------------------------------------------------ > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://six.pairlist.net/mailman/listinfo/msec > > -- Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Mar 29 10:07:06 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05504 for ; Tue, 29 Mar 2005 10:07:02 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 5C5B48CB91; Tue, 29 Mar 2005 10:06:54 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id C83EB8C8EF for ; Tue, 29 Mar 2005 10:06:52 -0500 (EST) Received: (qmail 72652 invoked by uid 3269); 29 Mar 2005 15:06:52 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 72647 invoked from network); 29 Mar 2005 15:06:52 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by klesh.pair.com with SMTP; 29 Mar 2005 15:06:52 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 29 Mar 2005 07:06:51 -0800 X-IronPort-AV: i="3.91,131,1110182400"; d="scan'208"; a="242314936:sNHT39889652" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2TF6kDr024857; Tue, 29 Mar 2005 07:06:46 -0800 (PST) Received: from [192.168.0.10] (sjc-vpn7-393.cisco.com [10.21.145.137]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j2TEx9RD005135; Tue, 29 Mar 2005 06:59:09 -0800 In-Reply-To: <42412DF6.11984.5621528@localhost> References: <20050322094006.GA11689@via.ecp.fr> <42412DF6.11984.5621528@localhost> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <8b88d92736b76f5f521bdeab316b10f9@cisco.com> Content-Transfer-Encoding: quoted-printable From: Mark Baugher Subject: Re: [MSEC] MIKEY D-H + SIP layer signature Date: Tue, 29 Mar 2005 07:06:45 -0800 To: steffen.fries@siemens.com X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1112108350.573601"; x:"432200"; a:"rsa-sha1"; b:"nofws:6260"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"iMrhaCjzWndy3md/1pwDjroY5GhXLjKzGu4PxXMw74OtfSCXPu2B3x2hUq+EUiZFES9b1nLy" "8dUvjjhddBnio4hBWaJa78kq/maU0icyA712kY4DnnV+osDETHzfiXfr7SpRaXydQsTL3ZqpkHc" "idIjJ9aB1mDpmHsWzOBu8m10="; c:"From: Mark Baugher "; c:"Subject: Re: [MSEC] MIKEY D-H + SIP layer signature"; c:"Date: Tue, 29 Mar 2005 07:06:45 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Cc: "David A. McGrew" , wshao@cisco.com, =?ISO-8859-1?Q?Mats_N=E4slund?= , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: quoted-printable hi Steffen, How do you envision the pre-shared key arrangement to be used in=20 practice? How would thousands of enterprise customers' phones be=20 configured to use a pre-shared secret for secure telephony? How do you=20= envision this being used outside the enterprise? Mark On Mar 22, 2005, at 11:51 PM, Steffen Fries wrote: > Hi Johan, > > additionally to the points from Mats, there is a draft > available, which is currently in IESG review, which provides an > extension to MIKEY , were the DH is protected using a pre-shared > key (draft-ietf-msec-mikey-dhhmac-09.txt). Here basically the > MIKEY message is integrity protected using HMAC-SHA1 and the > pre-shared key. If you are looking for a solution which is not > consuming to much performance (compared to tweo digital > signatures) this might be interesting for you. > > Regards > Steffen > > > Date sent: Tue, 22 Mar 2005 18:26:12 +0100 > From: Mats N=E4slund > To: Johan Bilien > Subject: Re: [MSEC] MIKEY D-H + SIP layer signature > Copies to: msec@securemulticast.org > >> Hi Johan, >> >> Johan Bilien wrote: >> >>> On Mon, Mar 21, 2005, Mats N=E4slund wrote: >>>> We discussed your proposal among the MIKEY authors, and we have >>>> the following comments. >>> >>> Thanks for your answer. >>> >>>>> . by using S/MIME or another mechanism (Identity: header...) >>>>> one can >>>>> protect the whole SDP. This "glues" the MIKEY message to >>>>> that SDP (the MIKEY message cannot be picked up from an >>>>> INVITE and used in another one). It also removes the >>>>> possibility of a downgrade >>>> >>>> >>>> Yes, but such an attack would as far as we see "only" have DoS >>>> effects since different keys would be created at >>>> Initiator/Responder sides. >>> >>> Yes, but that means that you cannot rely on the MIKEY message to >>> provide authentication of the SIP message. If you need such an >>> authentication >> >> Indeed. It is outside the scope of MIKEY to protect non-MIKEY >> things. Conversely, MIKEY should not have to trust that something = else >> takes cares of MIKEY's own security. >> >>> (which you probably want if you care about security enough to use >>> MIKEY >>> + SRTP), then you need an authentication at the SIP layer, and end >>> + up >>> having two digital signatures (and possibly two ways of carrying >>> Id/Certificates, which can be the source of interoperability >>> problems). >> >> First, one should not mix-up the need for end-to-end protection of = the >> media with the required security for the signaling. While end-to-end >> protection is often desired for the media, end-to-end protection of >> signaling may not always be possible (as SIP ALGs may need to modify >> messages for NAT traversal etc). Hop-by-hop protection of SIP using >> TLS or IPsec will be one solution that we will see. This is why we >> have not made any assumptions on the SIP signaling (more than that it >> is reliable). In other words, MIKEY is intended to be an e2e >> mechanism, but SIP itself may not always be. >> >> Secondly, you seem to want to use D-H, which is a really heavy >> mechanism, but at the same time the application you have in mind >> seems to have performance trouble with two signatures. Of course, D-H >> + 2 signatures is more expensive than D-H + one signature, but the >> difference is not extreme in most cases, and there are other "modes" >> in MIKEY aimed exactly at constrained applications. >> >> We do not see why there would be interop problems: MIKEY specifies = how >> MIKEY is secured, the SIP security (whatever you use) should = similarly >> be well-defined. By creating a dependence between MIKEY and the >> transport mechanism that carries MIKEY, it could just as well be that >> interop problems are *created*. >> >> >>> >>>>> attack, where someone would replace the SAVP profile with a >>>>> usual RTP, and remove the MIKEY message. Of courses >>>>> protecting the SDP has advantages independant of MIKEY, such >>>>> as preventing the change of the c: field. >>>> >>>> >>>> The same is possible even with signature at the SIP level: just >>>> peel off the signature part, delete the MIKEY line, and change >>>> SAVP to AVP. >>> >>> Agreed. >>> >>>>> Of course one can use the SIP layer signature on top of the >>>>> signed MIKEY message, but that is a waste of resource, the MIKEY >>>>> message being signed twice. So I think being able to create >>>>> unsigned D-H MIKEY messages would be a good thing. >>>> >>>> Note though that at the same time, we increase the possibility of >>>> (perhaps by misstake) using MIKEY-DH without authentication at >>>> all. It seems safer for MIKEY to always take care of its "own" >>>> security, not trusting that someone else does it. >>> >>> But then why, in case of the pre-shared key scheme, do you allow the >>> use of the NULL MAC and encryption algorithms, when "the underlying >>> protocols >> >> Yes, this is confusing, we agree. See below for an >> elaboration/clarification. >> >>> can guarantee security. The main reason for including this is for >>> specific SIP scenarios, where SDP is protected end-to-end." (section >>> 4.2.4). Why allow to delegate integrity protection to lower layers >>> in the case of PSK, and not for D-H? >> >> First of all, the intended use of "pre-shared with NULL" is as >> follows: >> >> Security for multimedia in general, and in particular integration of >> key mgmt in SIP, is perhaps not yet an "everyday thing". It is >> therefore likely that developers will want to experiment (inter-op >> tests etc) with the protocol(s). When you do the first initial tests, >> you are really mainly concerned that the "communication" works, and >> you would like to be sure that basic message parsing etc, works = before >> you make things more likely to go wrong by adding cryptography...;-) >> Therefore, the NULL mechanism's intended use is during testing, where >> you really don't care if you achieve security or not; you're just >> happy enough if you get it to work... >> >> Now, a "NULL" algorithm is essentially the same, regardless of if = it's >> "pre-shared NULL", or "public-key NULL". We needed a way to signal >> NULL security for testing, and we made the arbitrary choice of doing >> that via the pre-shared mode. We could just as well have defined a >> NULL public-key transform for this purpose. >> >> We agree that this is not well documented, and is probably something >> we should take care of in a future update. As you will see though, we >> raise strong warning flags against using the NULL options, and we = fell >> uncomfortable about introducing more NULL options: while any >> non-authentiocated mode probably can be attacked, D-H is notorious = for >> its sensitivity to MITM, so we think that using D-H with NULL >> authentication (perhaps by mistake) is particularly sensitive to >> attacks. >> >> Hope this provides some rationale. >> >> Best, >> >> /Mats >> >> >> >> >> _______________________________________________ >> msec mailing list >> msec@securemulticast.org >> http://six.pairlist.net/mailman/listinfo/msec > > ----------------------------------------------------------- > Steffen Fries, Siemens AG, CT IC 3=09 > Otto-Hahn-Ring 6, D-81730 Munich, Germany > Phone: (+49) 89 / 636-53403, > Fax : (+49) 89 / 636-48000 > Email: Steffen.Fries@siemens.com > ----------------------------------------------------------- > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Mar 29 16:12:46 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25660 for ; Tue, 29 Mar 2005 16:12:44 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id F24638CA95; Tue, 29 Mar 2005 16:12:44 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id AE38F8CA91 for ; Tue, 29 Mar 2005 16:12:43 -0500 (EST) Received: (qmail 88112 invoked by uid 3269); 29 Mar 2005 21:12:43 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 88109 invoked from network); 29 Mar 2005 21:12:43 -0000 Received: from rproxy.gmail.com (64.233.170.202) by klesh.pair.com with SMTP; 29 Mar 2005 21:12:43 -0000 Received: by rproxy.gmail.com with SMTP id 40so123129rnz for ; Tue, 29 Mar 2005 13:12:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=Q9qWgA8gGPgkHWp/tpoucb+Gx8/US8251KcEDzEZ68CTSQU5N+PNKevkNdOnb/xSDly3H9U9b+FQJxH1NZ4qpXMRmbsgyrYO1pP2SjtWQOBaYB/iNzr7R+xfqMtCQ+O+qioGwJPaJwX+kkBCsVxeNRFsw9hLE0GZJDh6zSQLLm0= Received: by 10.38.198.5 with SMTP id v5mr479863rnf; Tue, 29 Mar 2005 13:12:43 -0800 (PST) Received: by 10.38.8.37 with HTTP; Tue, 29 Mar 2005 13:12:43 -0800 (PST) Message-ID: <68c4509005032913124105e76f@mail.gmail.com> Date: Wed, 30 Mar 2005 00:12:43 +0300 From: Carlos Moreno To: msec@securemulticast.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [MSEC] Multicast secure implemented system X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Carlos Moreno List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Hello: I'm a Spanish student in Finland. I'm working in my information technology thesis about msec according to IETF and IRTF standards. Now I am in a street without exit because now I need to compare different implemented msec systems and write conclusions and different features in that. My problem is that I don't find any system that has this standard or others msec systems. I'm searching educational systems that help to make other theses or a simple system to test. I know that comercial systems may be is impossible to obtain without pay. If you could help me an indicate me where I could find systems of msec to follow with my thesis, please, send me a mail. Thank you very much. c. -- Carlos Moreno Losada =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= correo-e: cmoreno8@gmail.com jabber user: c_moreno8@bulmalug.net =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Linux user: #263092 http://counter.li.org _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Mar 29 20:06:08 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17839 for ; Tue, 29 Mar 2005 20:06:06 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 7FF158C9A6; Tue, 29 Mar 2005 20:06:08 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 43C0B8C980 for ; Tue, 29 Mar 2005 20:06:07 -0500 (EST) Received: (qmail 26191 invoked by uid 3269); 30 Mar 2005 01:06:07 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 26188 invoked from network); 30 Mar 2005 01:06:07 -0000 Received: from sj-iport-2-in.cisco.com (HELO sj-iport-2.cisco.com) (171.71.176.71) by klesh.pair.com with SMTP; 30 Mar 2005 01:06:07 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 29 Mar 2005 17:06:07 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2U15sDr019104; Tue, 29 Mar 2005 17:05:55 -0800 (PST) Received: from cisco.com (dhcp-128-107-178-27.cisco.com [128.107.178.27]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BDL23386; Tue, 29 Mar 2005 17:05:56 -0800 (PST) Message-ID: <4249FB92.5030008@cisco.com> Date: Tue, 29 Mar 2005 17:06:26 -0800 From: Brian Weis User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carlos Moreno Subject: Re: [MSEC] Multicast secure implemented system References: <68c4509005032913124105e76f@mail.gmail.com> In-Reply-To: <68c4509005032913124105e76f@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Hi Carlos, A reference implementation of RFC 3547 is available at http://www.vovida.org. Look for "GDOI" in the list of protocols. Hope that helps, Brian Carlos Moreno wrote: >Hello: > >I'm a Spanish student in Finland. I'm working in my information >technology thesis about msec according to IETF and IRTF standards. > >Now I am in a street without exit because now I need to compare >different implemented msec systems and write conclusions and different >features in that. > >My problem is that I don't find any system that has this standard or >others msec systems. I'm searching educational systems that help to >make other theses or a simple system to test. I know that comercial >systems may be is impossible to obtain without pay. > >If you could help me an indicate me where I could find systems of msec >to follow with my thesis, please, send me a mail. > >Thank you very much. > >c. > > > -- Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Mar 30 01:05:52 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14251 for ; Wed, 30 Mar 2005 01:05:50 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 8CA3D8C872; Wed, 30 Mar 2005 01:05:49 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 396C08C85D for ; Wed, 30 Mar 2005 01:05:48 -0500 (EST) Received: (qmail 2502 invoked by uid 3269); 30 Mar 2005 06:05:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 2494 invoked from network); 30 Mar 2005 06:05:47 -0000 Received: from thoth.sbs.de (192.35.17.2) by klesh.pair.com with SMTP; 30 Mar 2005 06:05:47 -0000 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id j2U63SER010404; Wed, 30 Mar 2005 08:03:28 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id j2U63R44015891; Wed, 30 Mar 2005 08:03:27 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 30 Mar 2005 08:03:27 +0200 Message-ID: From: Fries Steffen To: Mark Baugher Subject: RE: [MSEC] MIKEY D-H + SIP layer signature Date: Wed, 30 Mar 2005 08:03:26 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: "David A. McGrew" , wshao@cisco.com, =?iso-8859-1?Q?Mats_N=E4slund?= , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: quoted-printable Hi Mark, the pre-shared case may be usefule in cases, were a shared secret is = either already in place or distributed via other mechanisms.=20 For instance in enterprise environments one may think of a pre-shared secret, which is provided through a central server depending on the registration of clients (could be done by the registering server), = either by the multimedia protocol itself or through additional protocols. This approach does not provide true end-to-end security, as the central = server provides the key applied to MIKEY, but may be sufficient in certain environments. This may be advantageous in situations, in which the multimedia protocols are used without confidentiality protection by = their own (does not apply to DH, but to the pre-shared based encryption = described in MIKEY).=20 An example for pre-shared secret provision through a central entity is described in the direct routed call with gatekeeper model in H.323. In = a nutshell, through the call admission, the gatekeeper provides encrypted token for the caller, which include a shared secret, which is call = related. The caller decrypts the token targeted to him and includes the other = token in his setup message to the callee. The encryption is done with a key derived from the key used during registration.=20 Outside an enterprise such a solution may not be easy deployable, as = all involved parties would have to trust some central entity to provide the pre-shared secret in a secure way. Here, asymmetric methods may be more useful. =20 Regards Steffen > -----Original Message----- > From: Mark Baugher [mailto:mbaugher@cisco.com]=20 > Sent: Tuesday, March 29, 2005 5:07 PM > To: Fries Steffen > Cc: David A. McGrew; Mats N=E4slund; wshao@cisco.com; Johan=20 > Bilien; msec@securemulticast.org > Subject: Re: [MSEC] MIKEY D-H + SIP layer signature >=20 > hi Steffen, > How do you envision the pre-shared key arrangement to be=20 > used in practice? How would thousands of enterprise=20 > customers' phones be configured to use a pre-shared secret=20 > for secure telephony? How do you envision this being used=20 > outside the enterprise? >=20 > Mark > On Mar 22, 2005, at 11:51 PM, Steffen Fries wrote: >=20 > > Hi Johan, > > > > additionally to the points from Mats, there is a draft available,=20 > > which is currently in IESG review, which provides an extension to=20 > > MIKEY , were the DH is protected using a pre-shared key=20 > > (draft-ietf-msec-mikey-dhhmac-09.txt). Here basically the MIKEY=20 > > message is integrity protected using HMAC-SHA1 and the=20 > pre-shared key.=20 > > If you are looking for a solution which is not consuming to much=20 > > performance (compared to tweo digital > > signatures) this might be interesting for you. > > > > Regards > > Steffen > > > > > > Date sent: Tue, 22 Mar 2005 18:26:12 +0100 > > From: Mats N=E4slund > > To: Johan Bilien > > Subject: Re: [MSEC] MIKEY D-H + SIP layer signature > > Copies to: msec@securemulticast.org > > > >> Hi Johan, > >> > >> Johan Bilien wrote: > >> > >>> On Mon, Mar 21, 2005, Mats N=E4slund wrote: > >>>> We discussed your proposal among the MIKEY authors, and=20 > we have the=20 > >>>> following comments. > >>> > >>> Thanks for your answer. > >>> > >>>>> . by using S/MIME or another mechanism (Identity:=20 > header...) one=20 > >>>>> can > >>>>> protect the whole SDP. This "glues" the MIKEY message to > >>>>> that SDP (the MIKEY message cannot be picked up from an > >>>>> INVITE and used in another one). It also removes the > >>>>> possibility of a downgrade > >>>> > >>>> > >>>> Yes, but such an attack would as far as we see "only" have DoS=20 > >>>> effects since different keys would be created at=20 > >>>> Initiator/Responder sides. > >>> > >>> Yes, but that means that you cannot rely on the MIKEY message to=20 > >>> provide authentication of the SIP message. If you need such an=20 > >>> authentication > >> > >> Indeed. It is outside the scope of MIKEY to protect=20 > non-MIKEY things.=20 > >> Conversely, MIKEY should not have to trust that something=20 > else takes=20 > >> cares of MIKEY's own security. > >> > >>> (which you probably want if you care about security enough to use = > >>> MIKEY > >>> + SRTP), then you need an authentication at the SIP=20 > layer, and end=20 > >>> + up > >>> having two digital signatures (and possibly two ways of carrying=20 > >>> Id/Certificates, which can be the source of interoperability=20 > >>> problems). > >> > >> First, one should not mix-up the need for end-to-end protection of = > >> the media with the required security for the signaling. While=20 > >> end-to-end protection is often desired for the media, end-to-end=20 > >> protection of signaling may not always be possible (as SIP=20 > ALGs may=20 > >> need to modify messages for NAT traversal etc). Hop-by-hop=20 > protection=20 > >> of SIP using TLS or IPsec will be one solution that we=20 > will see. This=20 > >> is why we have not made any assumptions on the SIP signaling (more = > >> than that it is reliable). In other words, MIKEY is=20 > intended to be an=20 > >> e2e mechanism, but SIP itself may not always be. > >> > >> Secondly, you seem to want to use D-H, which is a really heavy=20 > >> mechanism, but at the same time the application you have in mind=20 > >> seems to have performance trouble with two signatures. Of=20 > course, D-H > >> + 2 signatures is more expensive than D-H + one signature, but the > >> difference is not extreme in most cases, and there are=20 > other "modes" > >> in MIKEY aimed exactly at constrained applications. > >> > >> We do not see why there would be interop problems: MIKEY specifies = > >> how MIKEY is secured, the SIP security (whatever you use) should=20 > >> similarly be well-defined. By creating a dependence=20 > between MIKEY and=20 > >> the transport mechanism that carries MIKEY, it could just=20 > as well be=20 > >> that interop problems are *created*. > >> > >> > >>> > >>>>> attack, where someone would replace the SAVP profile with a > >>>>> usual RTP, and remove the MIKEY message. Of courses > >>>>> protecting the SDP has advantages independant of MIKEY, such > >>>>> as preventing the change of the c: field. > >>>> > >>>> > >>>> The same is possible even with signature at the SIP level: just=20 > >>>> peel off the signature part, delete the MIKEY line, and=20 > change SAVP=20 > >>>> to AVP. > >>> > >>> Agreed. > >>> > >>>>> Of course one can use the SIP layer signature on top of=20 > the signed=20 > >>>>> MIKEY message, but that is a waste of resource, the=20 > MIKEY message=20 > >>>>> being signed twice. So I think being able to create=20 > unsigned D-H=20 > >>>>> MIKEY messages would be a good thing. > >>>> > >>>> Note though that at the same time, we increase the=20 > possibility of=20 > >>>> (perhaps by misstake) using MIKEY-DH without=20 > authentication at all.=20 > >>>> It seems safer for MIKEY to always take care of its "own" > >>>> security, not trusting that someone else does it. > >>> > >>> But then why, in case of the pre-shared key scheme, do=20 > you allow the=20 > >>> use of the NULL MAC and encryption algorithms, when "the=20 > underlying=20 > >>> protocols > >> > >> Yes, this is confusing, we agree. See below for an=20 > >> elaboration/clarification. > >> > >>> can guarantee security. The main reason for including=20 > this is for=20 > >>> specific SIP scenarios, where SDP is protected=20 > end-to-end." (section=20 > >>> 4.2.4). Why allow to delegate integrity protection to=20 > lower layers=20 > >>> in the case of PSK, and not for D-H? > >> > >> First of all, the intended use of "pre-shared with NULL" is as > >> follows: > >> > >> Security for multimedia in general, and in particular=20 > integration of=20 > >> key mgmt in SIP, is perhaps not yet an "everyday thing". It is=20 > >> therefore likely that developers will want to experiment (inter-op = > >> tests etc) with the protocol(s). When you do the first=20 > initial tests,=20 > >> you are really mainly concerned that the "communication"=20 > works, and=20 > >> you would like to be sure that basic message parsing etc, works=20 > >> before you make things more likely to go wrong by adding=20 > >> cryptography...;-) Therefore, the NULL mechanism's intended use is = > >> during testing, where you really don't care if you achieve=20 > security=20 > >> or not; you're just happy enough if you get it to work... > >> > >> Now, a "NULL" algorithm is essentially the same, regardless of if=20 > >> it's "pre-shared NULL", or "public-key NULL". We needed a way to=20 > >> signal NULL security for testing, and we made the=20 > arbitrary choice of=20 > >> doing that via the pre-shared mode. We could just as well have=20 > >> defined a NULL public-key transform for this purpose. > >> > >> We agree that this is not well documented, and is probably=20 > something=20 > >> we should take care of in a future update. As you will see=20 > though, we=20 > >> raise strong warning flags against using the NULL options, and we=20 > >> fell uncomfortable about introducing more NULL options: while any=20 > >> non-authentiocated mode probably can be attacked, D-H is notorious = > >> for its sensitivity to MITM, so we think that using D-H with NULL=20 > >> authentication (perhaps by mistake) is particularly sensitive to=20 > >> attacks. > >> > >> Hope this provides some rationale. > >> > >> Best, > >> > >> /Mats > >> > >> > >> > >> > >> _______________________________________________ > >> msec mailing list > >> msec@securemulticast.org > >> http://six.pairlist.net/mailman/listinfo/msec > > > > ----------------------------------------------------------- > > Steffen Fries, Siemens AG, CT IC 3=09 > > Otto-Hahn-Ring 6, D-81730 Munich, Germany > > Phone: (+49) 89 / 636-53403, > > Fax : (+49) 89 / 636-48000 > > Email: Steffen.Fries@siemens.com > > ----------------------------------------------------------- > > > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://six.pairlist.net/mailman/listinfo/msec > > >=20 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec