From mailman-bounces@six.pairlist.net Sun May 1 05:05: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 FAA05860 for ; Sun, 1 May 2005 05:05:45 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id D4B078CC6F for ; Sun, 1 May 2005 05:05:45 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: securemulticast.org mailing list memberships reminder From: mailman-owner@securemulticast.org To: msec-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sun, 01 May 2005 05:03:08 -0400 Precedence: bulk X-BeenThere: mailman@six.pairlist.net X-Mailman-Version: 2.1.5 List-Id: mailman.six.pairlist.net X-List-Administrivia: yes Sender: mailman-bounces@six.pairlist.net Errors-To: mailman-bounces@six.pairlist.net Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your securemulticast.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@securemulticast.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@securemulticast.org. Thanks! Passwords for msec-archive@lists.ietf.org: List Password // URL ---- -------- msec@securemulticast.org ucweat http://six.pairlist.net/mailman/options/msec/msec-archive%40lists.ietf.org From msec-bounces@securemulticast.org Mon May 9 06:21: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 GAA24535 for ; Mon, 9 May 2005 06:21:30 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 133B28C744; Mon, 9 May 2005 06:21:32 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id E867E8C724 for ; Mon, 9 May 2005 06:21:30 -0400 (EDT) Received: (qmail 52702 invoked by uid 3269); 9 May 2005 10:21:30 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 52699 invoked from network); 9 May 2005 10:21:30 -0000 Received: from mailing.unile.it (193.204.77.251) by klesh.pair.com with SMTP; 9 May 2005 10:21:30 -0000 Received: from elena (pc86170.unile.it [193.204.86.170]) by mailing.unile.it (Postfix) with SMTP id 70CE2104B3F for ; Mon, 9 May 2005 12:21:29 +0200 (CEST) Message-ID: <00d001c55480$da383170$aa56ccc1@elena> From: "Elena Scialpi" To: Date: Mon, 9 May 2005 12:21:23 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [MSEC] Hi all - Information 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="===============1240895734==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org This is a multi-part message in MIME format. --===============1240895734== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CD_01C55491.9D3A6C50" This is a multi-part message in MIME format. ------=_NextPart_000_00CD_01C55491.9D3A6C50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I'm an Italian student and I'm a lot interested to Multicast Security. I want to know if there are implementation for the protocols in this = Working Group . Hoping in your answers. Best regards Elena ------=_NextPart_000_00CD_01C55491.9D3A6C50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
I'm an Italian student and I'm a lot interested = to=20 Multicast Security.
I want to know if there are implementation for = the=20 protocols in this Working Group .
 
 
Hoping in your answers.
Best=20 regards
Elena
 
 
------=_NextPart_000_00CD_01C55491.9D3A6C50-- --===============1240895734== 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 --===============1240895734==-- From msec-bounces@securemulticast.org Mon May 9 08:29: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 IAA05532 for ; Mon, 9 May 2005 08:29:02 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 4919F8C4F6; Mon, 9 May 2005 08:29:03 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id E1DDB8C3CF for ; Mon, 9 May 2005 08:29:01 -0400 (EDT) Received: (qmail 76815 invoked by uid 3269); 9 May 2005 12:29:01 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 76801 invoked from network); 9 May 2005 12:29:01 -0000 Received: from ithilien.qualcomm.com (129.46.51.59) by klesh.pair.com with SMTP; 9 May 2005 12:29:01 -0000 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j49CStdv022047; Mon, 9 May 2005 05:28:55 -0700 (PDT) Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j49CSpl9008842; Mon, 9 May 2005 05:28:52 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 May 2005 05:28:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MSEC] Hi all - Information Date: Mon, 9 May 2005 05:28:51 -0700 Message-ID: Thread-Topic: [MSEC] Hi all - Information Thread-Index: AcVUgOt3HQ4ZXdtdS8WB2TxY3Q1/RgAENpqW From: "Dondeti, Lakshminath" To: "Elena Scialpi" , X-OriginalArrivalTime: 09 May 2005 12:28:51.0597 (UTC) FILETIME=[A8541BD0:01C55492] X-PMX-Version: 4.7.0.111621 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="===============1933915241==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org This is a multi-part message in MIME format. --===============1933915241== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55492.A84F99C0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C55492.A84F99C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Elena, Definitely. Brian Weis's GDOI implemenation = (http://www.vovida.org/protocols/downloads/gdoi/), and Hugh Harney's = team's GSAKMP implementation are available publicly. There are also = several MIKEY implmentations; however, none of them AFAIK are public. cheers, Lakshminath -----Original Message----- From: msec-bounces@securemulticast.org on behalf of Elena Scialpi Sent: Mon 5/9/2005 3:21 AM To: msec@securemulticast.org Subject: [MSEC] Hi all - Information =20 Hi all, I'm an Italian student and I'm a lot interested to Multicast Security. I want to know if there are implementation for the protocols in this = Working Group . Hoping in your answers. Best regards Elena ------_=_NextPart_001_01C55492.A84F99C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MSEC] Hi all - Information

Hi Elena,

Definitely.  Brian Weis's GDOI implemenation (http://www.vovid= a.org/protocols/downloads/gdoi/), and Hugh Harney's team's GSAKMP = implementation are available publicly.  There are also several = MIKEY implmentations; however, none of them AFAIK are public.

cheers,
Lakshminath


-----Original Message-----
From: msec-bounces@securemulticast.org on behalf of Elena Scialpi
Sent: Mon 5/9/2005 3:21 AM
To: msec@securemulticast.org
Subject: [MSEC] Hi all - Information

Hi all,
I'm an Italian student and I'm a lot interested to Multicast = Security.
I want to know if there are implementation for the protocols in this = Working Group .


Hoping in your answers.
Best regards
Elena

------_=_NextPart_001_01C55492.A84F99C0-- --===============1933915241== 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 --===============1933915241==-- From msec-bounces@securemulticast.org Tue May 10 02:26:22 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 CAA18518 for ; Tue, 10 May 2005 02:26:22 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 984A68C35F; Tue, 10 May 2005 02:26:22 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 0F3DE8C1C5 for ; Tue, 10 May 2005 02:26:21 -0400 (EDT) Received: (qmail 8101 invoked by uid 3269); 10 May 2005 06:26:20 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 8098 invoked from network); 10 May 2005 06:26:20 -0000 Received: from david.siemens.de (192.35.17.14) by klesh.pair.com with SMTP; 10 May 2005 06:26:20 -0000 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id j4A6QF2F008260; Tue, 10 May 2005 08:26:15 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j4A6QEjB023437; Tue, 10 May 2005 08:26:14 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 10 May 2005 08:26:14 +0200 Message-ID: From: Fries Steffen To: "Dondeti, Lakshminath" , Elena Scialpi , msec@securemulticast.org Subject: RE: [MSEC] Hi all - Information Date: Tue, 10 May 2005 08:26:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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="===============1010884120==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1010884120== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55529.297D8603" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C55529.297D8603 Content-Type: text/plain Hi, there are two MIKEY implementations publicly available AFAIK, one from Ericsson), available under http://standards.ericsson.net/fli/ and another implementation is available from the KTH under www.minisip.org Regards Steffen _____ From: msec-bounces@securemulticast.org [mailto:msec-bounces@securemulticast.org] On Behalf Of Dondeti, Lakshminath Sent: Monday, May 09, 2005 2:29 PM To: Elena Scialpi; msec@securemulticast.org Subject: RE: [MSEC] Hi all - Information Hi Elena, Definitely. Brian Weis's GDOI implemenation (http://www.vovida.org/protocols/downloads/gdoi/ ), and Hugh Harney's team's GSAKMP implementation are available publicly. There are also several MIKEY implmentations; however, none of them AFAIK are public. cheers, Lakshminath -----Original Message----- From: msec-bounces@securemulticast.org on behalf of Elena Scialpi Sent: Mon 5/9/2005 3:21 AM To: msec@securemulticast.org Subject: [MSEC] Hi all - Information Hi all, I'm an Italian student and I'm a lot interested to Multicast Security. I want to know if there are implementation for the protocols in this Working Group . Hoping in your answers. Best regards Elena ------_=_NextPart_001_01C55529.297D8603 Content-Type: text/html RE: [MSEC] Hi all - Information
Hi,
 
there are two MIKEY implementations publicly available AFAIK, one from Ericsson), available under http://standards.ericsson.net/fli/ and another implementation is available from the KTH under www.minisip.org
 
Regards
    Steffen
 

From: msec-bounces@securemulticast.org [mailto:msec-bounces@securemulticast.org] On Behalf Of Dondeti, Lakshminath
Sent: Monday, May 09, 2005 2:29 PM
To: Elena Scialpi; msec@securemulticast.org
Subject: RE: [MSEC] Hi all - Information

Hi Elena,

Definitely.  Brian Weis's GDOI implemenation (http://www.vovida.org/protocols/downloads/gdoi/), and Hugh Harney's team's GSAKMP implementation are available publicly.  There are also several MIKEY implmentations; however, none of them AFAIK are public.

cheers,
Lakshminath


-----Original Message-----
From: msec-bounces@securemulticast.org on behalf of Elena Scialpi
Sent: Mon 5/9/2005 3:21 AM
To: msec@securemulticast.org
Subject: [MSEC] Hi all - Information

Hi all,
I'm an Italian student and I'm a lot interested to Multicast Security.
I want to know if there are implementation for the protocols in this Working Group .


Hoping in your answers.
Best regards
Elena



------_=_NextPart_001_01C55529.297D8603-- --===============1010884120== 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 --===============1010884120==-- From msec-bounces@securemulticast.org Tue May 10 06:32:14 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 GAA05768 for ; Tue, 10 May 2005 06:32:12 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 11A7A8C677; Tue, 10 May 2005 06:32:14 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 6E82B8C656 for ; Tue, 10 May 2005 06:32:12 -0400 (EDT) Received: (qmail 52822 invoked by uid 3269); 10 May 2005 10:32:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 52818 invoked from network); 10 May 2005 10:32: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; 10 May 2005 10:32:12 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 10 May 2005 03:32:11 -0700 X-IronPort-AV: i="3.92,171,1112598000"; d="scan'208"; a="262858811:sNHT30076132" 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 j4AAW8O3009154; Tue, 10 May 2005 03:32:09 -0700 (PDT) Received: from [10.1.4.189] (sjc-vpn7-4.cisco.com [10.21.144.4]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j4AALuL6031381; Tue, 10 May 2005 03:21:57 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <1da188e21e5d93bae49bb7fe94b64d2d@cisco.com> Content-Transfer-Encoding: quoted-printable From: Mark Baugher Subject: Re: [MSEC] Hi all - Information Date: Tue, 10 May 2005 03:32:05 -0700 To: Fries Steffen X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1115720518.377254"; x:"432200"; a:"rsa-sha1"; b:"nofws:1491"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"gPd483YcGn9VYDslrKBY5bqdWDValZZj8ESaQYBsoTsrNd2ACjnlO1ByP0nKno2vNYTW7QRK" "aoY2QD0RJVkryzzxfmZNJQVXIIqrIj+V9UWwJq3ZKPKyByhb8tt3TBhOzSfCVx4itBhZMQMgWdl" "C+ORyH/YEh8V0Qn1j8g6gXck="; c:"From: Mark Baugher "; c:"Subject: Re: [MSEC] Hi all - Information"; c:"Date: Tue, 10 May 2005 03:32:05 -0700" 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 I should also mention to Elena that we are in need of an SRTP reference=20= implementation that supports TESLA=20 (http://www.ietf.org/internet-drafts/draft-ietf-msec-srtp-tesla-03.txt) Mark On May 9, 2005, at 11:26 PM, Fries Steffen wrote: > Hi, > =A0 > there are two MIKEY implementations publicly available AFAIK, one from=20= > Ericsson), available under http://standards.ericsson.net/fli/=A0and=20 > another=A0implementation=A0is=A0available=A0from the KTH under = www.minisip.org > =A0 > Regards > =A0=A0=A0 Steffen > =A0 > >> From: msec-bounces@securemulticast.org=20 >> [mailto:msec-bounces@securemulticast.org] On Behalf Of Dondeti,=20 >> Lakshminath >> Sent: Monday, May 09, 2005 2:29 PM >> To: Elena Scialpi; msec@securemulticast.org >> Subject: RE: [MSEC] Hi all - Information >> >> >> Hi Elena, >> >> Definitely.=A0 Brian Weis's GDOI implemenation=20 >> (http://www.vovida.org/protocols/downloads/gdoi/), and Hugh Harney's=20= >> team's GSAKMP implementation are available publicly.=A0 There are = also=20 >> several MIKEY implmentations; however, none of them AFAIK are public. >> >> cheers, >> Lakshminath >> >> >> -----Original Message----- >> From: msec-bounces@securemulticast.org on behalf of Elena Scialpi >> Sent: Mon 5/9/2005 3:21 AM >> To: msec@securemulticast.org >> Subject: [MSEC] Hi all - Information >> >> Hi all, >> I'm an Italian student and I'm a lot interested to Multicast = Security. >> I want to know if there are implementation for the protocols in this=20= >> Working Group . >> >> >> Hoping in your answers. >> Best regards >> Elena >> >> >> > _______________________________________________ > 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 May 17 09:29:02 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 JAA21984 for ; Tue, 17 May 2005 09:29:01 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 22E468CA5A; Tue, 17 May 2005 09:29:01 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 06FE58CA48 for ; Tue, 17 May 2005 09:29:00 -0400 (EDT) Received: (qmail 75659 invoked by uid 3269); 17 May 2005 13:29:00 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 75655 invoked from network); 17 May 2005 13:28:59 -0000 Received: from rproxy.gmail.com (64.233.170.200) by klesh.pair.com with SMTP; 17 May 2005 13:28:59 -0000 Received: by rproxy.gmail.com with SMTP id 40so14775rnz for ; Tue, 17 May 2005 06:28:59 -0700 (PDT) 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:content-disposition; b=r0IVKkLSL2HUiZqOpUGbnpNVDv8n/XNPf9LAqs+SoB7o2ImZJQF08gSUcMbt37r6v4V05eZXAhbcC5XSVAh06EzZ9466uQdijr2yFEiTz35btTORlSWgaWmL6LNPx9CVp7QnU4d1iP9W9zNofP5N+84nqsp94wftvT65y+EhwLA= Received: by 10.38.6.14 with SMTP id 14mr11881rnf; Tue, 17 May 2005 06:28:59 -0700 (PDT) Received: by 10.38.8.3 with HTTP; Tue, 17 May 2005 06:28:59 -0700 (PDT) Message-ID: <68c4509005051706281bae0756@mail.gmail.com> Date: Tue, 17 May 2005 16:28:59 +0300 From: Carlos Moreno To: msec@securemulticast.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: [MSEC] Roadmap 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: quoted-printable Hello: I have read a lot of RFC, drafts and documents about MSEC, but now I have a little mess in my head ... Do you know if exist any "roadmap" or explanation that indicates prerequisites and knowledge before every document? For instance, when I read RFC3740 (MSEC-Architecture) after I can know which is the place of GDOI, TESLA, etc. Yes, I know that the references are for this reason, but sometimes I read documents and always I need to know explanations of another documents backwards. Thanks. c. --=20 Carlos Moreno Losada =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D correo-e: cmoreno8@gmail.com jabber user: c_moreno8@bulmalug.net =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D 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 May 17 09:46:23 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 JAA24256 for ; Tue, 17 May 2005 09:46:22 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id A6EA28C9DB; Tue, 17 May 2005 09:46:24 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id E228E8C9C7 for ; Tue, 17 May 2005 09:46:22 -0400 (EDT) Received: (qmail 79854 invoked by uid 3269); 17 May 2005 13:46:22 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 79851 invoked from network); 17 May 2005 13:46: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; 17 May 2005 13:46:22 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 17 May 2005 06:46:22 -0700 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 j4HDkGO3007308; Tue, 17 May 2005 06:46:16 -0700 (PDT) Received: from [192.168.0.10] (sjc-vpn1-507.cisco.com [10.21.97.251]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j4HDZgfn025237; Tue, 17 May 2005 06:35:43 -0700 In-Reply-To: <68c4509005051706281bae0756@mail.gmail.com> References: <68c4509005051706281bae0756@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <452c0195a7750f6db1214e390cf19a08@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] Roadmap Date: Tue, 17 May 2005 06:46:16 -0700 To: Carlos Moreno X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1116336943.344369"; x:"432200"; a:"rsa-sha1"; b:"nofws:1062"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"NBpqq6N7RAUtRWHbcbEVzGO7CYksSaqTn2HIZr6gXnVLp6M4TzVTpHAf8Ne1xuCn40WfkfQD" "ThiEwXkH6R/ctVdkB4u1yWsGhHOwmFoBQeKb7qv2KCo9RWfpwE7CsSMP35wDZdAm+xqrgzslBlR" "tqGjKh128frVDeh2oaJDNPWc="; c:"From: Mark Baugher "; c:"Subject: Re: [MSEC] Roadmap"; c:"Date: Tue, 17 May 2005 06:46:16 -0700" 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 Carlos, The MSEC roadmap is defined by its current charter. The MSEC security architecture (RFC3740) and MSEC group key management architecture (RFC 4046) are merely deliverables from earlier versions of the charter. But these documents pretty much span most of the work that is being done in MSEC these days. Mark On May 17, 2005, at 6:28 AM, Carlos Moreno wrote: > Hello: > > I have read a lot of RFC, drafts and documents about MSEC, but now I > have a little mess in my head ... > > Do you know if exist any "roadmap" or explanation that indicates > prerequisites and knowledge before every document? > > For instance, when I read RFC3740 (MSEC-Architecture) after I can know > which is the place of GDOI, TESLA, etc. > > Yes, I know that the references are for this reason, but sometimes I > read documents and always I need to know explanations of another > documents backwards. > > Thanks. > > 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 > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue May 17 09:51:34 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 JAA24786 for ; Tue, 17 May 2005 09:51:34 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 9C70C8CA6B; Tue, 17 May 2005 09:51:21 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id B21658CA53 for ; Tue, 17 May 2005 09:51:20 -0400 (EDT) Received: (qmail 80838 invoked by uid 3269); 17 May 2005 13:51:20 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 80834 invoked from network); 17 May 2005 13:51:20 -0000 Received: from numenor.qualcomm.com (129.46.51.58) by klesh.pair.com with SMTP; 17 May 2005 13:51:20 -0000 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4HDpECK023140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 May 2005 06:51:14 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4HDpAlF008152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 May 2005 06:51:11 -0700 (PDT) Message-ID: <4289F6CD.8020507@qualcomm.com> Date: Tue, 17 May 2005 09:51:09 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carlos Moreno Subject: Re: [MSEC] Roadmap References: <68c4509005051706281bae0756@mail.gmail.com> In-Reply-To: <68c4509005051706281bae0756@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Hi Carlos, In addition to Mark's notes, here is an older version of RFC 4046 with a "roadmap" picture (near the end of the document) that if I recall correctly, Mark drew several years ago :-). http://ietfreport.isoc.org/all-ids/draft-ietf-msec-gkmarch-02.txt regards, Lakshminath Carlos Moreno wrote: >Hello: > >I have read a lot of RFC, drafts and documents about MSEC, but now I >have a little mess in my head ... > >Do you know if exist any "roadmap" or explanation that indicates >prerequisites and knowledge before every document? > >For instance, when I read RFC3740 (MSEC-Architecture) after I can know >which is the place of GDOI, TESLA, etc. > >Yes, I know that the references are for this reason, but sometimes I >read documents and always I need to know explanations of another >documents backwards. > >Thanks. > >c. > > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue May 17 16:05:17 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 QAA07090 for ; Tue, 17 May 2005 16:05:17 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id EFD418CB4C; Tue, 17 May 2005 16:05:18 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 9AD258CB47 for ; Tue, 17 May 2005 16:05:17 -0400 (EDT) Received: (qmail 60392 invoked by uid 3269); 17 May 2005 20:05:17 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 60389 invoked from network); 17 May 2005 20:05:17 -0000 Received: from rproxy.gmail.com (64.233.170.192) by klesh.pair.com with SMTP; 17 May 2005 20:05:17 -0000 Received: by rproxy.gmail.com with SMTP id 40so27595rnz for ; Tue, 17 May 2005 13:05:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lIlQNpYqByeaN94u/8J3BUKXQlkw2g13a/+8TuUiawYU3KYHMNBa4n5yau0B1ryE6Gw2KvTMQWoNXgTWWtJiMWfxrkTBc8IlCjyJYFKQswB5Hle6jITfMpq2pMfP5ToMfxYdlWoZP+PnAqRIaq83j8xoR6V3DAASa8HR3ouJmfQ= Received: by 10.38.8.8 with SMTP id 8mr21358rnh; Tue, 17 May 2005 13:05:16 -0700 (PDT) Received: by 10.38.8.3 with HTTP; Tue, 17 May 2005 13:05:16 -0700 (PDT) Message-ID: <68c450900505171305673df8eb@mail.gmail.com> Date: Tue, 17 May 2005 23:05:16 +0300 From: Carlos Moreno To: ldondeti@qualcomm.com Subject: Re: [MSEC] Roadmap In-Reply-To: <4289F6CD.8020507@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <68c4509005051706281bae0756@mail.gmail.com> <4289F6CD.8020507@qualcomm.com> Cc: msec@securemulticast.org 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: quoted-printable Hello: Thank you very much. I read the RFC 4046 of April 2005 and this roadmap is not there. :( Thanks. c. 2005/5/17, Lakshminath Dondeti : > Hi Carlos, >=20 > In addition to Mark's notes, here is an older version of RFC 4046 with a > "roadmap" picture (near the end of the document) that if I recall > correctly, Mark drew several years ago :-). >=20 > http://ietfreport.isoc.org/all-ids/draft-ietf-msec-gkmarch-02.txt >=20 > regards, > Lakshminath >=20 > Carlos Moreno wrote: >=20 > >Hello: > > > >I have read a lot of RFC, drafts and documents about MSEC, but now I > >have a little mess in my head ... > > > >Do you know if exist any "roadmap" or explanation that indicates > >prerequisites and knowledge before every document? > > > >For instance, when I read RFC3740 (MSEC-Architecture) after I can know > >which is the place of GDOI, TESLA, etc. > > > >Yes, I know that the references are for this reason, but sometimes I > >read documents and always I need to know explanations of another > >documents backwards. > > > >Thanks. > > > >c. > > > > > > >=20 --=20 Carlos Moreno Losada =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D correo-e: cmoreno8@gmail.com jabber user: c_moreno8@bulmalug.net =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D 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 Thu May 19 14:16:28 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 OAA02145 for ; Thu, 19 May 2005 14:16:26 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 5B18E8CBA4; Thu, 19 May 2005 14:16:26 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 461CB8CB06 for ; Thu, 19 May 2005 14:16:25 -0400 (EDT) Received: (qmail 1873 invoked by uid 3269); 19 May 2005 18:16:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 1870 invoked from network); 19 May 2005 18:16:24 -0000 Received: from ithilien.qualcomm.com (129.46.51.59) by klesh.pair.com with SMTP; 19 May 2005 18:16:24 -0000 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4JIGLdv008447 for ; Thu, 19 May 2005 11:16:22 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4JIGHuZ008129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 19 May 2005 11:16:18 -0700 (PDT) Message-ID: <428CD7F0.7010909@qualcomm.com> Date: Thu, 19 May 2005 14:16:16 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MSEC] MSEC WG Last Call: draft-ietf-msec-policy-token-sec-02.txt (closing June 10, 2005) X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com, ran canetti , andrea Colegrove , hugh Harney , msec@securemulticast.org 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, This is an MSEC WG last call for comments on http://www.ietf.org/internet-drafts/draft-ietf-msec-policy-token-sec-02.txt closing on June 10, 2005 AOE. Track: Standards Track, Proposed Standard If you have questions or if you think the draft is not ready to move forward, please send your comments to the list. If you think that it looks ready to be forwarded to the IESG, we want to hear from you also. If you don't care, we want to know that as well :-). Note that the Policy Token is generic and can be used with GDOI as well as other key management protocols in addition to GSAKMP. So, please take some time to review this. We would also like to hear about any implementations of the policy token spec (Andrea, do you know of any implementations?). regards, Lakshminath Draft details: Title: Group Policy Token V1 with Application to GSAKMP Authors: A. Colegrove and H. Harney Abstract: The Policy Token is a structure used to specify the security policy and configurable parameters for a cryptographic group, such as a secure multicast group. This document specifies the structure of such a token in order to securely bind system-level security to protocols supporting the management of cryptographic groups. _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu May 19 14:39:10 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 OAA04476 for ; Thu, 19 May 2005 14:39:09 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id E99878C597; Thu, 19 May 2005 14:39:09 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 44EC58C5A2 for ; Thu, 19 May 2005 14:39:09 -0400 (EDT) Received: (qmail 6732 invoked by uid 3269); 19 May 2005 18:39:08 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 6723 invoked from network); 19 May 2005 18:39:07 -0000 Received: from numenor.qualcomm.com (129.46.51.58) by klesh.pair.com with SMTP; 19 May 2005 18:39:07 -0000 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4JId4CK021232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 19 May 2005 11:39:04 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4JId0J9003341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 19 May 2005 11:39:01 -0700 (PDT) Message-ID: <428CDD43.4030908@qualcomm.com> Date: Thu, 19 May 2005 14:38:59 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MSEC] Request for interest in the Paris-IETF meeting X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com, ran canetti 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, WG scheduling is now open, so I want to get an initial idea on * potential number of attendees (at the MSP meeting we were at ~30; I don't want to ask for a small room if a number of you are planning to attend, so let us know if you were not in MSP, but will be in Paris) and * topics for discussion: + updates to current work items and + introduction of new items # we have one already: the Multicast SPD architecture work that Brian Weis and Dragan Ignjatic will be working on Once I get an idea on the amount of time required and the expected level of participation, I will send the request for a meeting slot (please respond within the next 2 weeks; I would like to send the request early in June). Also, please feel free to note if there are conflicts that you want the MSEC meeting to avoid (if you are planning to present, your input gets extra weight :-)). thanks and regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon May 23 21:26: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 VAA20806 for ; Mon, 23 May 2005 21:26:50 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 89D128CB76; Mon, 23 May 2005 21:26:50 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 5EF1F8CB4F for ; Mon, 23 May 2005 21:26:49 -0400 (EDT) Received: (qmail 12553 invoked by uid 3269); 24 May 2005 01:26:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 12547 invoked from network); 24 May 2005 01:26:47 -0000 Received: from numenor.qualcomm.com (129.46.51.58) by klesh.pair.com with SMTP; 24 May 2005 01:26:47 -0000 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4O1QdCK011204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 23 May 2005 18:26:40 -0700 (PDT) Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4O1PTDf023929; Mon, 23 May 2005 18:26:37 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 18:26:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MSEC] Followup to 2401bis in the MSEC WG Date: Mon, 23 May 2005 18:26:21 -0700 Message-ID: Thread-Topic: [MSEC] Followup to 2401bis in the MSEC WG Thread-Index: AcVf57PkrHWPmMWlTXi6JadrMULZ5QAFwPOp From: "Dondeti, Lakshminath" To: "Brian Weis" X-OriginalArrivalTime: 24 May 2005 01:26:36.0631 (UTC) FILETIME=[A0A3B670:01C55FFF] Cc: George Gross , ran canetti , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1554966040==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org This is a multi-part message in MIME format. --===============1554966040== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55FFF.97A112C0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C55FFF.97A112C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian, I posted from my recollection and therefore could be wrong. In any = event, I am glad that you have George on board already. Between Dragan, = George and you, we have an excellent team of authors/editors to work on = this. Once we have a first version (or one that you guys are comfortable with: = please let Ran and I know your preference), we will post it to the IPSEC = list to get wider feedback and also in order to avoid problems later on. best wishes, Lakshminath =20 +++Brian's message +++++++ That's great. Also, I thought that I had mentioned that George Gross=20 also volunteered to co-author. My apologies to you and George if that=20 didn't happen. ------_=_NextPart_001_01C55FFF.97A112C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MSEC] Followup to 2401bis in the MSEC WG

Brian,

I posted from my recollection and therefore could be wrong.  In any = event, I am glad that you have George on board already.  Between = Dragan, George and you, we have an excellent team of authors/editors to = work on this.

Once we have a first version (or one that you guys are comfortable with: = please let Ran and I know your preference), we will post it to the IPSEC = list to get wider feedback and also in order to avoid problems later = on.

best wishes,
Lakshminath


+++Brian's message +++++++
That's great. Also, I thought that I had mentioned that George Gross
also volunteered to co-author. My apologies to you and George if = that
didn't happen.

------_=_NextPart_001_01C55FFF.97A112C0-- --===============1554966040== 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 --===============1554966040==-- From msec-bounces@securemulticast.org Fri May 27 08:02:51 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 IAA04013 for ; Fri, 27 May 2005 08:02:50 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 54F388CB27; Fri, 27 May 2005 08:02:50 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 931E68CB05 for ; Fri, 27 May 2005 08:02:49 -0400 (EDT) Received: (qmail 76332 invoked by uid 3269); 27 May 2005 12:02:49 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 76328 invoked from network); 27 May 2005 12:02:49 -0000 Received: from gecko.sbs.de (194.138.37.40) by klesh.pair.com with SMTP; 27 May 2005 12:02:49 -0000 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j4RC29g7008923; Fri, 27 May 2005 14:02:09 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j4RC28oF018718; Fri, 27 May 2005 14:02:08 +0200 Received: from mchp72za.ww002.siemens.net ([139.25.164.49]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 May 2005 14:05:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 May 2005 14:02:05 +0200 Message-ID: Thread-Topic: Please comment on changes to TESLA-INTRO: (Section 3.7 to be deleted) Thread-Index: AcVgeo0sEtgPLJZ+RcmCPjkrYAzkbwCOHthw From: "Fries, Steffen" To: , , "Mark Baugher" , "Elisabetta Carrara" , "Tschofenig, Hannes" X-OriginalArrivalTime: 27 May 2005 12:05:22.0406 (UTC) FILETIME=[5BD22060:01C562B4] Cc: tygar@cs.berkeley.edu, dawnsong@cmu.edu, canetti@watson.ibm.com, Russ Housley , bob.briscoe@bt.com, Sam Hartman , Adrian Perrig Subject: [MSEC] RE: Please comment on changes to TESLA-INTRO: (Section 3.7 to be deleted) 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 Lakshminath, I just checked section 3.7. From my point of view the removal of this section would not influence the bootstrapping TESLA draft. On the other hand, you mentioned it already, Adrian may perhaps elaborate on the potential attack, as I'm not sure if I understand his scenario completely. As the index would still be contained in the packets, the receiver could associate the appropriate key with the packet. Regards=09 Steffen > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20 > Sent: Tuesday, May 24, 2005 6:05 PM > To: msec@securemulticast.org; Mark Baugher; Elisabetta=20 > Carrara; Tschofenig, Hannes; Fries, Steffen > Cc: Russ Housley; Adrian Perrig; canetti@watson.ibm.com;=20 > dawnsong@cmu.edu; tygar@cs.berkeley.edu; bob.briscoe@bt.com;=20 > Sam Hartman > Subject: Please comment on changes to TESLA-INTRO: (Section=20 > 3.7 to be deleted) >=20 > Hi all, >=20 > **Please note that this document is in RFC Editor Auth-48=20 > stage, so please respond as soon as you can.** >=20 > Adrian suggests that Section 3.7 from > http://www.ietf.org/internet-drafts/draft-ietf-msec-tesla-intro-04.txt > be deleted (please see Adrian's note below). >=20 > I have several requests: >=20 > * I-D authors referring to this document: please check to=20 > see if this impacts your documents. > * All WG members: please comment on whether you are ok=20 > with removing=20 > Section 3.7. > * Adrian: please elaborate on the vulnerability (or post a=20 > link to a=20 > reference that does). >=20 > Note: This is to be an informational RFC. >=20 > thanks and regards, > Lakshminath >=20 >=20 > Russ Housley wrote: >=20 > > Adrian: > > > > This is a fairly large change at this stage. Since this is=20 > a MSEC WG=20 > > document, it should be coordinated with the WG. > > > > MSEC WG Chairs: > > > > Please confirm that this change does not impact consensus. > > > > Russ > > > > At 07:27 PM 5/23/2005, Adrian Perrig wrote: > > > >> Section 3.7: > >> The entire section must be deleted. Dynamically=20 > changing time=20 > >> intervals introduces a security vulnerability and TESLA loses the=20 > >> resilience to packet loss property. > > > > > > >=20 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri May 27 09:15: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 JAA09350 for ; Fri, 27 May 2005 09:15:07 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 55FFF8C7BE; Fri, 27 May 2005 09:15:08 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id E94738C6B1 for ; Fri, 27 May 2005 09:15:06 -0400 (EDT) Received: (qmail 51604 invoked by uid 3269); 27 May 2005 13:15:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 51601 invoked from network); 27 May 2005 13:15:06 -0000 Received: from bache.ece.cmu.edu (128.2.129.23) by klesh.pair.com with SMTP; 27 May 2005 13:15:06 -0000 Received: from FINCH.ECE.CMU.EDU (FINCH.ECE.CMU.EDU [128.2.134.43]) by bache.ece.cmu.edu (Postfix) with ESMTP id B066B7A; Fri, 27 May 2005 09:15:05 -0400 (EDT) Date: Fri, 27 May 2005 09:15:05 -0400 (EDT) From: Adrian Perrig To: Lakshminath Dondeti In-Reply-To: <429350A3.2000808@qualcomm.com> Message-ID: References: <20050518231230.GQ2760@isi.edu> <429266E7.6080302@ece.cmu.edu> <6.2.1.2.2.20050524114414.03c82de0@mail.binhost.com> <429350A3.2000808@qualcomm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: tygar@cs.berkeley.edu, tschofenig Hannes , dawnsong@cmu.edu, canetti@watson.ibm.com, Russ Housley , bob.briscoe@bt.com, msec@securemulticast.org, Elisabetta Carrara , Mark Baugher , Sam Hartman , Fries Steffen Subject: [MSEC] Re: Please comment on changes to TESLA-INTRO: (Section 3.7 to be deleted) 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, Allowing a sender to dynamically alter the disclosure schedule of keys is very dangerous, and removes the property of TESLA to be robust to packet loss. Consider the following example. In packet P_i, a sender would announce that K_j that was supposed to be published after time T_j is now going to be published earlier. If a receiver misses this packet, the receiver will still believe that K_j is published after time T_j, so an attacker can forge packets for that receiver when obtaining K_j before time T_j. This example illustrates that it is dangerous to alter a disclosure schedule and that is why I suggested removing Section 3.7. This section was supposed to be removed earlier, but maybe due to version control issues it has somehow survived. Adrian > Hi all, > > **Please note that this document is in RFC Editor Auth-48 stage, so > please respond as soon as you can.** > > Adrian suggests that Section 3.7 from > http://www.ietf.org/internet-drafts/draft-ietf-msec-tesla-intro-04.txt > be deleted (please see Adrian's note below). > > I have several requests: > > * I-D authors referring to this document: please check to see if this > impacts your documents. > * All WG members: please comment on whether you are ok with removing > Section 3.7. > * Adrian: please elaborate on the vulnerability (or post a link to a > reference that does). > > Note: This is to be an informational RFC. > > thanks and regards, > Lakshminath > > > Russ Housley wrote: > > > Adrian: > > > > This is a fairly large change at this stage. Since this is a MSEC WG > > document, it should be coordinated with the WG. > > > > MSEC WG Chairs: > > > > Please confirm that this change does not impact consensus. > > > > Russ > > > > At 07:27 PM 5/23/2005, Adrian Perrig wrote: > > > >> Section 3.7: > >> The entire section must be deleted. Dynamically changing time > >> intervals introduces a security vulnerability and TESLA loses the > >> resilience to packet loss property. > > > > > > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri May 27 10:03: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 KAA13305 for ; Fri, 27 May 2005 10:03:30 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id B4DC18CB08; Fri, 27 May 2005 10:03:29 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 4433B8C41A for ; Fri, 27 May 2005 10:02:52 -0400 (EDT) Received: (qmail 60122 invoked by uid 3269); 27 May 2005 14:02:52 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 60118 invoked from network); 27 May 2005 14:02:51 -0000 Received: from numenor.qualcomm.com (129.46.51.58) by klesh.pair.com with SMTP; 27 May 2005 14:02:51 -0000 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4RE2QCK011040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 27 May 2005 07:02:27 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4RE2KJ9020726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 May 2005 07:02:21 -0700 (PDT) Message-ID: <4297286C.9050802@qualcomm.com> Date: Fri, 27 May 2005 10:02:20 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Perrig References: <20050518231230.GQ2760@isi.edu> <429266E7.6080302@ece.cmu.edu> <6.2.1.2.2.20050524114414.03c82de0@mail.binhost.com> <429350A3.2000808@qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tygar@cs.berkeley.edu, tschofenig Hannes , dawnsong@cmu.edu, canetti@watson.ibm.com, Russ Housley , bob.briscoe@bt.com, msec@securemulticast.org, Elisabetta Carrara , Mark Baugher , Sam Hartman , Fries Steffen Subject: [MSEC] Re: Please comment on changes to TESLA-INTRO: (Section 3.7 to be deleted) X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Adrian, Thanks. As Steffen notes, if the receiver receives any legitimate packet after the disclosure delay change, then it would know that the delay has changed, right? (Of course there is the threat of an adversary acting as a MiTM after a disclosure delay reduction and modify all pertinent information to continue to fool the victim). Furthermore, isn't increasing the disclosure delay ok? I am thinking perhaps Section 3.7 could remain but with appropriate modifications to reflect your notes below and perhaps answering some of the questions above. (As a side note, that will allow all references to Section 3.7 to remain, and the reader -- this is an Informational RFC -- would have information on whether or not dynamically changing disclosure delay is ok). Thoughts? regards, Lakshminath NOT as co-chair of the group Adrian Perrig wrote: >Hi, > >Allowing a sender to dynamically alter the disclosure schedule of keys >is very dangerous, and removes the property of TESLA to be robust to >packet loss. Consider the following example. In packet P_i, a sender >would announce that K_j that was supposed to be published after time >T_j is now going to be published earlier. If a receiver misses this >packet, the receiver will still believe that K_j is published after >time T_j, so an attacker can forge packets for that receiver when >obtaining K_j before time T_j. > >This example illustrates that it is dangerous to alter a disclosure >schedule and that is why I suggested removing Section 3.7. This >section was supposed to be removed earlier, but maybe due to version >control issues it has somehow survived. > Adrian > > > >>Hi all, > >>**Please note that this document is in RFC Editor Auth-48 stage, so >>please respond as soon as you can.** >> >>Adrian suggests that Section 3.7 from >>http://www.ietf.org/internet-drafts/draft-ietf-msec-tesla-intro-04.txt >>be deleted (please see Adrian's note below). >> >>I have several requests: >> >>* I-D authors referring to this document: please check to see if this >>impacts your documents. >>* All WG members: please comment on whether you are ok with removing >>Section 3.7. >>* Adrian: please elaborate on the vulnerability (or post a link to a >>reference that does). >> >>Note: This is to be an informational RFC. >> >>thanks and regards, >>Lakshminath >> >> >>Russ Housley wrote: >> >> >> >>>Adrian: >>> >>>This is a fairly large change at this stage. Since this is a MSEC WG >>>document, it should be coordinated with the WG. >>> >>>MSEC WG Chairs: >>> >>>Please confirm that this change does not impact consensus. >>> >>>Russ >>> >>>At 07:27 PM 5/23/2005, Adrian Perrig wrote: >>> >>> >>> >>>>Section 3.7: >>>> The entire section must be deleted. Dynamically changing time >>>>intervals introduces a security vulnerability and TESLA loses the >>>>resilience to packet loss property. >>>> >>>> >>> >>> >>> > > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri May 27 13:54:48 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 NAA06690 for ; Fri, 27 May 2005 13:54:48 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 2A0F08CC55; Fri, 27 May 2005 13:54:48 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id E347B8CBC3 for ; Fri, 27 May 2005 13:54:46 -0400 (EDT) Received: (qmail 8836 invoked by uid 3269); 27 May 2005 17:54:46 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 8832 invoked from network); 27 May 2005 17:54:46 -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; 27 May 2005 17:54:46 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 27 May 2005 10:54:46 -0700 X-IronPort-AV: i="3.93,144,1115017200"; d="scan'208"; a="270589623:sNHT34375988" 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 j4RHsgbw016042; Fri, 27 May 2005 10:54:42 -0700 (PDT) Received: from [192.168.0.10] (sjc-vpn5-480.cisco.com [10.21.89.224]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j4RHhRx2015290; Fri, 27 May 2005 10:43:27 -0700 In-Reply-To: <4297286C.9050802@qualcomm.com> References: <20050518231230.GQ2760@isi.edu> <429266E7.6080302@ece.cmu.edu> <6.2.1.2.2.20050524114414.03c82de0@mail.binhost.com> <429350A3.2000808@qualcomm.com> <4297286C.9050802@qualcomm.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <425c417e57be178d968105723ab2a260@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Date: Fri, 27 May 2005 10:54:39 -0700 To: ldondeti@qualcomm.com X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1117215808.789794"; x:"432200"; a:"rsa-sha1"; b:"nofws:2615"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"buINEBlfWPtNnErkUXApXnf7X+dcJjp60XRmq1/PD4B8GVI20aCh6zYWo3vCq6OaqY8D481E" "mDvWSSXBLUtVXG9oqTcZaBYT/C4PaRLVJr1f1hhvEvVA/ZiTXNQbq/X3SqMuBLwUsQeIckriR82" "j1FWZOTsHmOTpThG97UfN/Jg="; c:"From: Mark Baugher "; c:"Subject: Re: Please comment on changes to TESLA-INTRO: (Section 3.7 " "to be deleted)"; c:"Date: Fri, 27 May 2005 10:54:39 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Cc: tygar@cs.berkeley.edu, tschofenig Hannes , dawnsong@cmu.edu, canetti@watson.ibm.com, Russ Housley , bob.briscoe@bt.com, msec@securemulticast.org, Elisabetta Carrara , Sam Hartman , Fries Steffen , Adrian Perrig Subject: [MSEC] Re: Please comment on changes to TESLA-INTRO: (Section 3.7 to be deleted) 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 Lakshminath, I don't see any value to altering the disclosure delay. Mark On May 27, 2005, at 7:02 AM, Lakshminath Dondeti wrote: > Adrian, > > Thanks. As Steffen notes, if the receiver receives any legitimate > packet after the disclosure delay change, then it would know that the > delay has changed, right? (Of course there is the threat of an > adversary acting as a MiTM after a disclosure delay reduction and > modify all pertinent information to continue to fool the victim). > Furthermore, isn't increasing the disclosure delay ok? > > I am thinking perhaps Section 3.7 could remain but with appropriate > modifications to reflect your notes below and perhaps answering some > of the questions above. (As a side note, that will allow all > references to Section 3.7 to remain, and the reader -- this is an > Informational RFC -- would have information on whether or not > dynamically changing disclosure delay is ok). > > Thoughts? > > regards, > Lakshminath > NOT as co-chair of the group > > > Adrian Perrig wrote: > >> Hi, >> >> Allowing a sender to dynamically alter the disclosure schedule of keys >> is very dangerous, and removes the property of TESLA to be robust to >> packet loss. Consider the following example. In packet P_i, a sender >> would announce that K_j that was supposed to be published after time >> T_j is now going to be published earlier. If a receiver misses this >> packet, the receiver will still believe that K_j is published after >> time T_j, so an attacker can forge packets for that receiver when >> obtaining K_j before time T_j. >> >> This example illustrates that it is dangerous to alter a disclosure >> schedule and that is why I suggested removing Section 3.7. This >> section was supposed to be removed earlier, but maybe due to version >> control issues it has somehow survived. >> Adrian >> >> >>> Hi all, > >>> **Please note that this document is in RFC Editor Auth-48 stage, so >>> please respond as soon as you can.** >>> >>> Adrian suggests that Section 3.7 from >>> http://www.ietf.org/internet-drafts/draft-ietf-msec-tesla-intro >>> -04.txt >>> be deleted (please see Adrian's note below). >>> >>> I have several requests: >>> >>> * I-D authors referring to this document: please check to see if >>> this >>> impacts your documents. >>> * All WG members: please comment on whether you are ok with >>> removing >>> Section 3.7. >>> * Adrian: please elaborate on the vulnerability (or post a link to >>> a >>> reference that does). >>> >>> Note: This is to be an informational RFC. >>> >>> thanks and regards, >>> Lakshminath >>> >>> >>> Russ Housley wrote: >>> >>> >>>> Adrian: >>>> >>>> This is a fairly large change at this stage. Since this is a MSEC >>>> WG >>>> document, it should be coordinated with the WG. >>>> >>>> MSEC WG Chairs: >>>> >>>> Please confirm that this change does not impact consensus. >>>> >>>> Russ >>>> >>>> At 07:27 PM 5/23/2005, Adrian Perrig wrote: >>>> >>>> >>>>> Section 3.7: >>>>> The entire section must be deleted. Dynamically changing >>>>> time >>>>> intervals introduces a security vulnerability and TESLA loses the >>>>> resilience to packet loss property. >>>>> >>>> >>>> >> >> > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri May 27 14:05:51 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 OAA07681 for ; Fri, 27 May 2005 14:05:51 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id BCABA8CB2B; Fri, 27 May 2005 14:05:51 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 8C3708C169 for ; Fri, 27 May 2005 14:05:49 -0400 (EDT) Received: (qmail 11356 invoked by uid 3269); 27 May 2005 18:05:49 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 11351 invoked from network); 27 May 2005 18:05:49 -0000 Received: from numenor.qualcomm.com (129.46.51.58) by klesh.pair.com with SMTP; 27 May 2005 18:05:49 -0000 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4RI5OCK005607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 27 May 2005 11:05:25 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4RI5IuZ007810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 May 2005 11:05:19 -0700 (PDT) Message-ID: <42976154.5000803@qualcomm.com> Date: Fri, 27 May 2005 14:05:08 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Baugher References: <20050518231230.GQ2760@isi.edu> <429266E7.6080302@ece.cmu.edu> <6.2.1.2.2.20050524114414.03c82de0@mail.binhost.com> <429350A3.2000808@qualcomm.com> <4297286C.9050802@qualcomm.com> <425c417e57be178d968105723ab2a260@cisco.com> In-Reply-To: <425c417e57be178d968105723ab2a260@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tygar@cs.berkeley.edu, tschofenig Hannes , dawnsong@cmu.edu, canetti@watson.ibm.com, Russ Housley , bob.briscoe@bt.com, msec@securemulticast.org, Elisabetta Carrara , Sam Hartman , Fries Steffen , Adrian Perrig Subject: [MSEC] Re: Please comment on changes to TESLA-INTRO: (Section 3.7 to be deleted) X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Mark, Thanks for sharing your thoughts on this. I don't have a specific use case in mind for this feature. However, given where we are in the process, and also considering that this is an informational RFC, my inclination is to suggest providing information on the proverbial "what happens if we do this vs. that" in the soon to be RFC. Deleting the section and all references to that section is certainly an option too. I am proposing that providing that information would be useful (a record of the discussion so to speak). When it comes to TESLA-SPEC, perhaps I will agree with a SHOULD NOT for changing the disclosure delay within a TESLA session. Of course that goes along with a security considerations section that contains a summary of this discussion on what happens if the disclosure delay were to be changed. best regards, Lakshminath (NOT as MSEC co-chair) Mark Baugher wrote: > Lakshminath, > I don't see any value to altering the disclosure delay. > > Mark > On May 27, 2005, at 7:02 AM, Lakshminath Dondeti wrote: > >> Adrian, >> >> Thanks. As Steffen notes, if the receiver receives any legitimate >> packet after the disclosure delay change, then it would know that >> the delay has changed, right? (Of course there is the threat of an >> adversary acting as a MiTM after a disclosure delay reduction and >> modify all pertinent information to continue to fool the victim). >> Furthermore, isn't increasing the disclosure delay ok? >> >> I am thinking perhaps Section 3.7 could remain but with appropriate >> modifications to reflect your notes below and perhaps answering some >> of the questions above. (As a side note, that will allow all >> references to Section 3.7 to remain, and the reader -- this is an >> Informational RFC -- would have information on whether or not >> dynamically changing disclosure delay is ok). >> >> Thoughts? >> >> regards, >> Lakshminath >> NOT as co-chair of the group >> >> >> Adrian Perrig wrote: >> >>> Hi, >>> >>> Allowing a sender to dynamically alter the disclosure schedule of keys >>> is very dangerous, and removes the property of TESLA to be robust to >>> packet loss. Consider the following example. In packet P_i, a sender >>> would announce that K_j that was supposed to be published after time >>> T_j is now going to be published earlier. If a receiver misses this >>> packet, the receiver will still believe that K_j is published after >>> time T_j, so an attacker can forge packets for that receiver when >>> obtaining K_j before time T_j. >>> >>> This example illustrates that it is dangerous to alter a disclosure >>> schedule and that is why I suggested removing Section 3.7. This >>> section was supposed to be removed earlier, but maybe due to version >>> control issues it has somehow survived. >>> Adrian >>> >>> >>>> Hi all, > >>>> **Please note that this document is in RFC Editor Auth-48 stage, so >>>> please respond as soon as you can.** >>>> >>>> Adrian suggests that Section 3.7 from >>>> http://www.ietf.org/internet-drafts/draft-ietf-msec-tesla-intro >>>> -04.txt >>>> be deleted (please see Adrian's note below). >>>> >>>> I have several requests: >>>> >>>> * I-D authors referring to this document: please check to see if >>>> this >>>> impacts your documents. >>>> * All WG members: please comment on whether you are ok with >>>> removing >>>> Section 3.7. >>>> * Adrian: please elaborate on the vulnerability (or post a link >>>> to a >>>> reference that does). >>>> >>>> Note: This is to be an informational RFC. >>>> >>>> thanks and regards, >>>> Lakshminath >>>> >>>> >>>> Russ Housley wrote: >>>> >>>> >>>>> Adrian: >>>>> >>>>> This is a fairly large change at this stage. Since this is a >>>>> MSEC WG >>>>> document, it should be coordinated with the WG. >>>>> >>>>> MSEC WG Chairs: >>>>> >>>>> Please confirm that this change does not impact consensus. >>>>> >>>>> Russ >>>>> >>>>> At 07:27 PM 5/23/2005, Adrian Perrig wrote: >>>>> >>>>> >>>>>> Section 3.7: >>>>>> The entire section must be deleted. Dynamically changing >>>>>> time >>>>>> intervals introduces a security vulnerability and TESLA loses the >>>>>> resilience to packet loss property. >>>>>> >>>>> >>>>> >>> >>> >> > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From nwankwo_phillip@mixmail.com Fri May 27 22:19:17 2005 Received: from relay.mixmail.com (relay03.mixmail.com [62.151.8.32]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23503 for ; Fri, 27 May 2005 22:19:16 -0400 (EDT) Received: from [172.30.8.72] (helo=web02) by relay.mixmail.com with smtp id 1Dbqur-0003ww-00; Sat, 28 May 2005 04:19:09 +0200 Date: Sat, 28 May 2005 03:19:09 +0100 From: "phillip Phillip Nwankwo" Reply-To: nwankwo_phillip@mixmail.com To: "nwankwo_phillip@mixmail.com" Subject: Investment /Assistance CEO !! Xmailer: Mixmail Server 3.0 X-Priority: 3 MIME-Version: 1.0 Content-type: text/plain Content-Transfer-Encoding: quoted-printable Message-Id: Content-Transfer-Encoding: quoted-printable Attn: Dear, THIS MESSAGE REQUEST IS URGENT CONFIDENTIAL RELATIONSHIP FOR TRANSFERING OF US$35.5M AMERICAN DOLLARS INTO YOU COMPANY ACCOUNT. I am Barrister Nwankw Phillip, A Personal attorney in this Office,And After due deliberation with my colleagues, I decided to forward to you this business proposal. We want a reliable person who could assist us to transfer the sum of Thirty-Five Million, five Hundred Thousand U.S. Dollars ($35.5m) into his account.The sum resulted from an over-invoice bill from a contract awarded by us over the budget allocation to my ministry and the bill was approved for payment by the concerned ministries. The contract was executed, commission and the contractor was paid actual cost of the contract. We are left with balance of $35.5 as the over-invoice amount we have deliberately over estimated for our use. But under our protocol division, civi servant are forbidden to operate or own foreign account. This is why icontact you for assistance. We have agreed to share the money as follows: 1 60% for us ( the officials) 2 30% for your (Account Owner) 3 10% for Expenses (External and internal) As you may want to know, i got your address from our Chamber of Commerce and Industry. I am a top official in the Oil Company and the chairman, contract Award committee). This transaction is very free from all sort of risk, hence the business was carefully planned before it was successfully excuted. We the officials involved in this deal have put in many years in service to our various ministries. We have been exercising patience for this opportunity for so long and for most of us, this is a life time opportunity we can't afford to miss. To get this fund paid into your private account, we have to present an international business outfit and consequent upon your agreement, you are require to send the following document/information through the above e-mail nwankwo_phillip@yahoo.com These information/documents will enable us seek/apply for the relevant payment approvals of the fund to the concern ministries/esterblishment. You may be require to sign the fund released authority/documents in our CBN Bank. Three officials will come to your country to arrange for our share. All these will only take us 14 working days to transfer this fund into your account right from the day we receive the requirements and Let honesty be our watch word throughout this transaction and your prompt and continous reply will be appreciated through the above e-mail nwankwo_phillip@yahoo.com Best regards, Barr.Nwankwo Phillip Email: nwankwo_phillip@yahoo.com --------------------------------------------------------- Presentamos la nueva fórmula para hacerse millonario: Especial Vagos http://sorteos.ya.com ADSL + Llamadas 24 horas: desde 28,95 €/mes + IVA. Navega y habla de forma ilimitada. Sin compromiso de permanencia. http://acceso.ya.com/ADSLllamadas/ From msec-bounces@securemulticast.org Mon May 30 09:50: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 JAA15296 for ; Mon, 30 May 2005 09:50:31 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id EF8D08CD53; Mon, 30 May 2005 09:45:00 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id F1D2A8D096 for ; Mon, 30 May 2005 09:44:08 -0400 (EDT) Received: (qmail 48332 invoked by uid 3269); 30 May 2005 13:44:08 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 48329 invoked from network); 30 May 2005 13:44:08 -0000 Received: from bache.ece.cmu.edu (128.2.129.23) by klesh.pair.com with SMTP; 30 May 2005 13:44:08 -0000 Received: from ece.cmu.edu (VPN92.ECE.CMU.EDU [128.2.138.92]) by bache.ece.cmu.edu (Postfix) with ESMTP id A308682; Mon, 30 May 2005 09:43:51 -0400 (EDT) Message-ID: <429B1188.8090301@ece.cmu.edu> Date: Mon, 30 May 2005 06:13:44 -0700 From: Adrian Perrig User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ldondeti@qualcomm.com References: <20050518231230.GQ2760@isi.edu> <429266E7.6080302@ece.cmu.edu> <6.2.1.2.2.20050524114414.03c82de0@mail.binhost.com> <429350A3.2000808@qualcomm.com> <4297286C.9050802@qualcomm.com> <425c417e57be178d968105723ab2a260@cisco.com> <42976154.5000803@qualcomm.com> In-Reply-To: <42976154.5000803@qualcomm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: tygar@cs.berkeley.edu, tschofenig Hannes , dawnsong@cmu.edu, canetti@watson.ibm.com, Russ Housley , bob.briscoe@bt.com, msec@securemulticast.org, Elisabetta Carrara , Mark Baugher , Sam Hartman , Fries Steffen Subject: [MSEC] Re: Please comment on changes to TESLA-INTRO: (Section 3.7 to be deleted) 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, Given the limited usefulness of dynamically altering the disclosure delay and the security vulnerability that is created by dynamically shortening the disclosure delay, I vote to remove this section. For the argument that "it's good to keep it to discuss potential implementation errors," we would need to add a lot of other potential errors as well. Best, Adrian > Mark, > > Thanks for sharing your thoughts on this. > > I don't have a specific use case in mind for this feature. However, > given where we are in the process, and also considering that this is an > informational RFC, my inclination is to suggest providing information on > the proverbial "what happens if we do this vs. that" in the soon to be > RFC. Deleting the section and all references to that section is > certainly an option too. I am proposing that providing that information > would be useful (a record of the discussion so to speak). > > When it comes to TESLA-SPEC, perhaps I will agree with a SHOULD NOT for > changing the disclosure delay within a TESLA session. Of course that > goes along with a security considerations section that contains a > summary of this discussion on what happens if the disclosure delay were > to be changed. > > best regards, > Lakshminath > (NOT as MSEC co-chair) > > Mark Baugher wrote: > >> Lakshminath, >> I don't see any value to altering the disclosure delay. >> >> Mark >> On May 27, 2005, at 7:02 AM, Lakshminath Dondeti wrote: >> >>> Adrian, >>> >>> Thanks. As Steffen notes, if the receiver receives any legitimate >>> packet after the disclosure delay change, then it would know that >>> the delay has changed, right? (Of course there is the threat of an >>> adversary acting as a MiTM after a disclosure delay reduction and >>> modify all pertinent information to continue to fool the victim). >>> Furthermore, isn't increasing the disclosure delay ok? >>> >>> I am thinking perhaps Section 3.7 could remain but with appropriate >>> modifications to reflect your notes below and perhaps answering some >>> of the questions above. (As a side note, that will allow all >>> references to Section 3.7 to remain, and the reader -- this is an >>> Informational RFC -- would have information on whether or not >>> dynamically changing disclosure delay is ok). >>> >>> Thoughts? >>> >>> regards, >>> Lakshminath >>> NOT as co-chair of the group >>> >>> >>> Adrian Perrig wrote: >>> >>>> Hi, >>>> >>>> Allowing a sender to dynamically alter the disclosure schedule of keys >>>> is very dangerous, and removes the property of TESLA to be robust to >>>> packet loss. Consider the following example. In packet P_i, a sender >>>> would announce that K_j that was supposed to be published after time >>>> T_j is now going to be published earlier. If a receiver misses this >>>> packet, the receiver will still believe that K_j is published after >>>> time T_j, so an attacker can forge packets for that receiver when >>>> obtaining K_j before time T_j. >>>> >>>> This example illustrates that it is dangerous to alter a disclosure >>>> schedule and that is why I suggested removing Section 3.7. This >>>> section was supposed to be removed earlier, but maybe due to version >>>> control issues it has somehow survived. >>>> Adrian >>>> >>>> >>>>> Hi all, > >>>>> **Please note that this document is in RFC Editor Auth-48 stage, so >>>>> please respond as soon as you can.** >>>>> >>>>> Adrian suggests that Section 3.7 from >>>>> http://www.ietf.org/internet-drafts/draft-ietf-msec-tesla-intro >>>>> -04.txt >>>>> be deleted (please see Adrian's note below). >>>>> >>>>> I have several requests: >>>>> >>>>> * I-D authors referring to this document: please check to see if >>>>> this >>>>> impacts your documents. >>>>> * All WG members: please comment on whether you are ok with >>>>> removing >>>>> Section 3.7. >>>>> * Adrian: please elaborate on the vulnerability (or post a link >>>>> to a >>>>> reference that does). >>>>> >>>>> Note: This is to be an informational RFC. >>>>> >>>>> thanks and regards, >>>>> Lakshminath >>>>> >>>>> >>>>> Russ Housley wrote: >>>>> >>>>> >>>>>> Adrian: >>>>>> >>>>>> This is a fairly large change at this stage. Since this is a >>>>>> MSEC WG >>>>>> document, it should be coordinated with the WG. >>>>>> >>>>>> MSEC WG Chairs: >>>>>> >>>>>> Please confirm that this change does not impact consensus. >>>>>> >>>>>> Russ >>>>>> >>>>>> At 07:27 PM 5/23/2005, Adrian Perrig wrote: >>>>>> >>>>>> >>>>>>> Section 3.7: >>>>>>> The entire section must be deleted. Dynamically changing >>>>>>> time >>>>>>> intervals introduces a security vulnerability and TESLA loses the >>>>>>> resilience to packet loss property. _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue May 31 10:17:26 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 KAA13014 for ; Tue, 31 May 2005 10:17:26 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 24F5B8C348; Tue, 31 May 2005 10:17:27 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id E51048C2F1 for ; Tue, 31 May 2005 10:17:25 -0400 (EDT) Received: (qmail 53615 invoked by uid 3269); 31 May 2005 14:17:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 53612 invoked from network); 31 May 2005 14:17:25 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by klesh.pair.com with SMTP; 31 May 2005 14:17:25 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 31 May 2005 07:17:23 -0700 X-IronPort-AV: i="3.93,152,1115017200"; d="scan'208"; a="639680552:sNHT36491948" 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 j4VEHGbw023079; Tue, 31 May 2005 07:17:17 -0700 (PDT) Received: from [192.168.0.10] (sjc-vpn4-196.cisco.com [10.21.80.196]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j4VE5oLK001829; Tue, 31 May 2005 07:05:50 -0700 In-Reply-To: <429B1188.8090301@ece.cmu.edu> References: <20050518231230.GQ2760@isi.edu> <429266E7.6080302@ece.cmu.edu> <6.2.1.2.2.20050524114414.03c82de0@mail.binhost.com> <429350A3.2000808@qualcomm.com> <4297286C.9050802@qualcomm.com> <425c417e57be178d968105723ab2a260@cisco.com> <42976154.5000803@qualcomm.com> <429B1188.8090301@ece.cmu.edu> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0556c1f631f485172bf342a58ce6e4de@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Date: Tue, 31 May 2005 07:17:16 -0700 To: Adrian Perrig X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1117548352.78758"; x:"432200"; a:"rsa-sha1"; b:"nofws:4166"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"nqYlORdryjwbYqymnCwk/69iTSA6YgXxK7Y73hfmfK6eAvIJ6+xLzDTaF6MNG8lVcUXwjTH9" "2LhH/tn6bHeVV2R9AllLWn3aMgyiiph0oaiACIvnSMUzxOpvZBgjfnhcHVe36DOdiBK9IBaiHQa" "XmnmnwBc2JdcE8HFpwaTLFG0="; c:"From: Mark Baugher "; c:"Subject: Re: Please comment on changes to TESLA-INTRO: (Section 3.7 " "to be deleted)"; c:"Date: Tue, 31 May 2005 07:17:16 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Cc: tygar@cs.berkeley.edu, tschofenig Hannes , dawnsong@cmu.edu, canetti@watson.ibm.com, Russ Housley , bob.briscoe@bt.com, msec@securemulticast.org, Elisabetta Carrara , Sam Hartman , Fries Steffen Subject: [MSEC] Re: Please comment on changes to TESLA-INTRO: (Section 3.7 to be deleted) 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 Adrian We might want to summarize this discussion in a sentence or two in the I-D in order to document what is known. Mark On May 30, 2005, at 6:13 AM, Adrian Perrig wrote: > Hi, > > Given the limited usefulness of dynamically altering the disclosure > delay and the security vulnerability that is created by dynamically > shortening the disclosure delay, I vote to remove this section. > For the argument that "it's good to keep it to discuss potential > implementation errors," we would need to add a lot of other potential > errors as well. Best, > Adrian > >> Mark, >> Thanks for sharing your thoughts on this. >> I don't have a specific use case in mind for this feature. However, >> given where we are in the process, and also considering that this is >> an informational RFC, my inclination is to suggest providing >> information on the proverbial "what happens if we do this vs. that" >> in the soon to be RFC. Deleting the section and all references to >> that section is certainly an option too. I am proposing that >> providing that information would be useful (a record of the >> discussion so to speak). >> When it comes to TESLA-SPEC, perhaps I will agree with a SHOULD NOT >> for changing the disclosure delay within a TESLA session. Of course >> that goes along with a security considerations section that contains >> a summary of this discussion on what happens if the disclosure delay >> were to be changed. >> best regards, >> Lakshminath >> (NOT as MSEC co-chair) >> Mark Baugher wrote: >>> Lakshminath, >>> I don't see any value to altering the disclosure delay. >>> >>> Mark >>> On May 27, 2005, at 7:02 AM, Lakshminath Dondeti wrote: >>> >>>> Adrian, >>>> >>>> Thanks. As Steffen notes, if the receiver receives any legitimate >>>> packet after the disclosure delay change, then it would know that >>>> the delay has changed, right? (Of course there is the threat of >>>> an adversary acting as a MiTM after a disclosure delay reduction >>>> and modify all pertinent information to continue to fool the >>>> victim). Furthermore, isn't increasing the disclosure delay ok? >>>> >>>> I am thinking perhaps Section 3.7 could remain but with appropriate >>>> modifications to reflect your notes below and perhaps answering >>>> some of the questions above. (As a side note, that will allow all >>>> references to Section 3.7 to remain, and the reader -- this is an >>>> Informational RFC -- would have information on whether or not >>>> dynamically changing disclosure delay is ok). >>>> >>>> Thoughts? >>>> >>>> regards, >>>> Lakshminath >>>> NOT as co-chair of the group >>>> >>>> >>>> Adrian Perrig wrote: >>>> >>>>> Hi, >>>>> >>>>> Allowing a sender to dynamically alter the disclosure schedule of >>>>> keys >>>>> is very dangerous, and removes the property of TESLA to be robust >>>>> to >>>>> packet loss. Consider the following example. In packet P_i, a >>>>> sender >>>>> would announce that K_j that was supposed to be published after >>>>> time >>>>> T_j is now going to be published earlier. If a receiver misses this >>>>> packet, the receiver will still believe that K_j is published after >>>>> time T_j, so an attacker can forge packets for that receiver when >>>>> obtaining K_j before time T_j. >>>>> >>>>> This example illustrates that it is dangerous to alter a disclosure >>>>> schedule and that is why I suggested removing Section 3.7. This >>>>> section was supposed to be removed earlier, but maybe due to >>>>> version >>>>> control issues it has somehow survived. >>>>> Adrian >>>>> >>>>> >>>>>> Hi all, > >>>>>> **Please note that this document is in RFC Editor Auth-48 stage, >>>>>> so >>>>>> please respond as soon as you can.** >>>>>> >>>>>> Adrian suggests that Section 3.7 from >>>>>> http://www.ietf.org/internet-drafts/draft-ietf-msec-tesla-intro >>>>>> -04.txt >>>>>> be deleted (please see Adrian's note below). >>>>>> >>>>>> I have several requests: >>>>>> >>>>>> * I-D authors referring to this document: please check to see if >>>>>> this >>>>>> impacts your documents. >>>>>> * All WG members: please comment on whether you are ok with >>>>>> removing >>>>>> Section 3.7. >>>>>> * Adrian: please elaborate on the vulnerability (or post a link >>>>>> to a >>>>>> reference that does). >>>>>> >>>>>> Note: This is to be an informational RFC. >>>>>> >>>>>> thanks and regards, >>>>>> Lakshminath >>>>>> >>>>>> >>>>>> Russ Housley wrote: >>>>>> >>>>>> >>>>>>> Adrian: >>>>>>> >>>>>>> This is a fairly large change at this stage. Since this is a >>>>>>> MSEC WG >>>>>>> document, it should be coordinated with the WG. >>>>>>> >>>>>>> MSEC WG Chairs: >>>>>>> >>>>>>> Please confirm that this change does not impact consensus. >>>>>>> >>>>>>> Russ >>>>>>> >>>>>>> At 07:27 PM 5/23/2005, Adrian Perrig wrote: >>>>>>> >>>>>>> >>>>>>>> Section 3.7: >>>>>>>> The entire section must be deleted. Dynamically changing >>>>>>>> time >>>>>>>> intervals introduces a security vulnerability and TESLA loses >>>>>>>> the >>>>>>>> resilience to packet loss property. > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue May 31 16:31:22 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 QAA28320 for ; Tue, 31 May 2005 16:31:21 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 99FA08C79D; Tue, 31 May 2005 16:31:22 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 607D18C6A4 for ; Tue, 31 May 2005 16:31:21 -0400 (EDT) Received: (qmail 43213 invoked by uid 3269); 31 May 2005 20:31:21 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 43203 invoked from network); 31 May 2005 20:31:20 -0000 Received: from ithilien.qualcomm.com (129.46.51.59) by klesh.pair.com with SMTP; 31 May 2005 20:31:20 -0000 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4VKUxdv006383; Tue, 31 May 2005 13:31:00 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4VKUt8A016813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 31 May 2005 13:30:56 -0700 (PDT) Message-ID: <429CC985.2080605@qualcomm.com> Date: Tue, 31 May 2005 16:31:01 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org References: <200505261948.PAA27532@ietf.org> In-Reply-To: <200505261948.PAA27532@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Russ Housley , Ran Canetti , hartmans-ietf@mit.edu, Brian Weis Subject: [MSEC] Consensus call on draft-ietf-msec-ipsec-signatures-05.txt X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Hi all, As you might know, there were some comments during the IESG last call on msec-ipsec-signatures-05 document that Brian Weis is editing/authoring. Specifically, the following points were raised and, in -05-, have been addressed by Brian. Please review and send comments to the list before June 1, 2005. 1. 04 uses encryption schemes for signing as opposed to signature schemes: This has been fixed in the revised version (please see Section 2.0). Instead of RSAES-PKCS1-v1_5, the draft specifies the use of RSASSA-PKCS1-v1_5. 2. There was a suggestion to use PSS padding instead of PKCS1-v1_5. Section 2.0 now specifies that RSASSA-PKCS1-v1_5 is a MUST (no change here except for Item #1 above), and that RSASSA-PSS is a SHOULD. There is an explanation as to why PSS is not a MUST. 3. Section 2.0 also contains details on how to sign packets. 4. The draft now specifies "A conforming implementation MUST support a modulus size of 1024 bits" in Section 2.0. 5. Section 4.0 contains new text on combined modes and states in part "The RSA signatures algorithm cannot be used with an ESP Combined Mode algorithm that includes an explicit ICV." There is an explanation as to why. 6. Now that there is a choice in RSA signature padding schemes, Section 5.0 specifies "Signature Encoding Algorithm SA Attribute" as part of the SA policy download. 7. Section 7.0 now contains IANA considerations for the Signature Encoding Algorithm Attribute. Please review all the changes and send your comments to the list. We would like to hear if you agree with, don't agree with, or don't care about the changes. (Please also indicate if anyone needs more time to review) thanks and regards, Lakshminath Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Multicast Security Working Group of the IETF. > > Title : The Use of RSA/SHA-1 Signatures within ESP and AH > Author(s) : B. Weis > Filename : draft-ietf-msec-ipsec-signatures-05.txt > Pages : 11 > Date : 2005-5-26 > >This memo describes the use of the RSA Digital Signature algorithm as > an authentication algorithm within the revised IP Encapsulating > Security Payload (ESP) as described in RFC XXXX and the revised IP > Authentication Header (AH) as described in RFC YYYY. The use of a > digital signature algorithm, such as RSA, provides data origin > authentication in applications when a secret key method (e.g., HMAC) > does not provide this property. One example is the use of ESP and AH > to authenticate the sender of an IP multicast packet. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-signatures-05.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-msec-ipsec-signatures-05.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-msec-ipsec-signatures-05.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > >------------------------------------------------------------------------ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/i-d-announce > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec