From mailman-bounces@six.pairlist.net Mon Nov 1 05:03:27 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10502 for ; Mon, 1 Nov 2004 05:03:26 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 95D0F8DC8C for ; Mon, 1 Nov 2004 05:03:25 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: securemulticast.org mailing list memberships reminder From: mailman-owner@securemulticast.org To: msec-archive@ietf.org X-No-Archive: yes Message-ID: Date: Mon, 01 Nov 2004 05:01:18 -0500 Precedence: bulk X-BeenThere: mailman@six.pairlist.net X-Mailman-Version: 2.1.5 List-Id: mailman.six.pairlist.net X-List-Administrivia: yes Sender: mailman-bounces@six.pairlist.net Errors-To: mailman-bounces@six.pairlist.net Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your securemulticast.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@securemulticast.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@securemulticast.org. Thanks! Passwords for msec-archive@lists.ietf.org: List Password // URL ---- -------- msec@securemulticast.org ucweat http://six.pairlist.net/mailman/options/msec/msec-archive%40lists.ietf.org From msec-bounces@securemulticast.org Thu Nov 4 10:27:36 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00652 for ; Thu, 4 Nov 2004 10:27:36 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id DEAC08D505; Thu, 4 Nov 2004 10:27:36 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 69F0A8D4F1 for ; Thu, 4 Nov 2004 10:27:35 -0500 (EST) Received: (qmail 75680 invoked by uid 3269); 4 Nov 2004 15:27:35 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 75677 invoked from network); 4 Nov 2004 15:27:34 -0000 Received: from thoth.sbs.de (192.35.17.2) by klesh.pair.com with SMTP; 4 Nov 2004 15:27:34 -0000 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id iA4FRXfO025104 for ; Thu, 4 Nov 2004 16:27:33 +0100 Received: from mchn070c (mhpaba5c.mchp.siemens.de [139.23.204.46]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id iA4FRXYO021049 for ; Thu, 4 Nov 2004 16:27:33 +0100 From: "Steffen Fries" Organization: Siemens AG To: msec@securemulticast.org Date: Thu, 04 Nov 2004 16:27:23 +0100 MIME-Version: 1.0 Message-ID: <418A586B.20643.2FB7B6C3@localhost> Priority: normal In-reply-to: <41762511.18921.19C5E4A7@localhost> X-mailer: Pegasus Mail for Windows (4.21c) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Subject: [MSEC] update draft available for bootstrapping TESLA X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: steffen.fries@siemens.com List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7BIT Hi, based on the discussions on the mailing list we have updated the draft regarding bootstrapping TESLA. For your convinience, we placed the current version under http://www.tschofenig.com/snapshot/draft-fries-msec- bootstrapping-tesla-01_4Nov2004.txt http://www.tschofenig.com/snapshot/draft-fries-msec- bootstrapping-tesla-01_4Nov2004.html Regards Steffen _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Nov 5 04:25:37 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19540 for ; Fri, 5 Nov 2004 04:25:36 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 32B2F8D96C; Fri, 5 Nov 2004 04:25:38 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 4F8798D7A8 for ; Fri, 5 Nov 2004 04:25:36 -0500 (EST) Received: (qmail 94374 invoked by uid 3269); 5 Nov 2004 09:25:36 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 94370 invoked from network); 5 Nov 2004 09:25:36 -0000 Received: from smtp8.clb.oleane.net (213.56.31.28) by klesh.pair.com with SMTP; 5 Nov 2004 09:25:36 -0000 Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be forged)) by smtp8.clb.oleane.net with ESMTP id iA59PY82007236 for ; Fri, 5 Nov 2004 10:25:34 +0100 Message-Id: <200411050925.iA59PY82007236@smtp8.clb.oleane.net> From: "Gunther Palmer" To: Date: Fri, 5 Nov 2004 10:25:30 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTDGWRCh/aNer5rS56ZCxaFJ7sh6g== Subject: [MSEC] SSL VPN Conference: Call for proposals 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="===============0436786804==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org This is a multi-part message in MIME format. --===============0436786804== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B2_01C4C321.C75DD910" This is a multi-part message in MIME format. ------=_NextPart_000_00B2_01C4C321.C75DD910 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit . How to provide SSL-based remote access to a broad range of Web and legacy applications? . What about application performance and requirements? . Are encrypted application tunnelling issues solved? . What differences with IPsec VPNs? These questions, among others, will be tackled by the most recognised experts in this field during the SSL VPN Conference to be held in Paris from April 5 to 8, 2005 The call for proposal dead line has been extended to November 30. Details at: http://www.upperside.fr/sslvpn05/sslvpn05intro.htm ------=_NextPart_000_00B2_01C4C321.C75DD910 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

• = How to provide SSL-based remote access to a broad range of Web and legacy applications?
• = What about application performance and requirements?
• = Are encrypted application tunnelling issues solved?
• = What differences with IPsec VPNs?

These questions, among others, will be tackled by the most recognised = experts in this field during the SSL VPN = Conference to be held in Paris from April 5 to 8, 2005

 

The call for proposal dead line has been = extended to November 30.

 

Details = at:

 

http://www.upperside.fr/sslvpn05/sslvpn05intro.htm

 

------=_NextPart_000_00B2_01C4C321.C75DD910-- --===============0436786804== 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 --===============0436786804==-- From msec-bounces@securemulticast.org Fri Nov 5 13:50:35 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06964 for ; Fri, 5 Nov 2004 13:50:35 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id EF5978CC2E; Fri, 5 Nov 2004 13:50:33 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 9E8368CB55 for ; Fri, 5 Nov 2004 13:50:32 -0500 (EST) Received: (qmail 96291 invoked by uid 3269); 5 Nov 2004 18:50:32 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 96287 invoked from network); 5 Nov 2004 18:50:32 -0000 Received: from smtp107.mail.sc5.yahoo.com (66.163.169.227) by klesh.pair.com with SMTP; 5 Nov 2004 18:50:32 -0000 Received: from unknown (HELO mou1thardjon-L2.yahoo.com) (thardjono@67.161.47.160 with login) by smtp107.mail.sc5.yahoo.com with SMTP; 5 Nov 2004 18:50:31 -0000 Message-Id: <6.1.0.6.2.20041026092854.0397f888@pop.mail.yahoo.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Fri, 05 Nov 2004 10:49:39 -0800 To: msec@securemulticast.org From: Thomas Hardjono Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: canetti@watson.ibm.com Subject: [MSEC] MSEC agenda for IETF61 X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Folks, Here is the MSEC Agenda for IETF-61 in DC as of today. MSEC WG Agenda: --------------- - Status report (Ran Canetti/Thomas Hardjono) - TESLA in SRTP Update (Elisabetta Carrara) - General Payload Type in MIKEY (Elisabetta Carrara) - DHHMAC-MIKEY Update (Martin Euchner/Steffen Fries) - Flat multicast key exchange (S. Josset/L.Duquerroy) - Bootstrapping TESLA (Steffen Fries) - Update on GDOIv2/GKDP (Lakshminath Dondeti) Currently MSEC is listed as meeting on: MONDAY, November 8, 2004 1930-2200 Evening Sessions SEC msec Multicast Security WG Please email Ran/Thomas for corrections/additions. Regards, Thomas/Ran ---------- _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Nov 8 19:00:06 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21216 for ; Mon, 8 Nov 2004 19:00:04 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id B99208C5FE; Mon, 8 Nov 2004 18:59:29 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id EB1DF8C5D2 for ; Mon, 8 Nov 2004 18:59:27 -0500 (EST) Received: (qmail 90964 invoked by uid 3269); 8 Nov 2004 23:59:27 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 90961 invoked from network); 8 Nov 2004 23:59:27 -0000 Received: from smtp016.mail.yahoo.com (216.136.174.113) by klesh.pair.com with SMTP; 8 Nov 2004 23:59:27 -0000 Received: from unknown (HELO mou1thardjon-L2.yahoo.com) (thardjono@64.208.10.2 with login) by smtp016.mail.yahoo.com with SMTP; 8 Nov 2004 23:59:26 -0000 Message-Id: <6.1.0.6.2.20041108155714.04de6928@MOU1WNEXM02.verisign.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Mon, 08 Nov 2004 15:58:53 -0800 To: msec@securemulticast.org From: Thomas Hardjono In-Reply-To: <6.1.0.6.2.20041026092854.0397f888@pop.mail.yahoo.com> References: <6.1.0.6.2.20041026092854.0397f888@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: canetti@watson.ibm.com Subject: [MSEC] Status of MSEC drafts X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Folks, I've just updated the Drafts Status page: http://www.securemulticast.org/msec-drafts.htm It should reflect the status of the MSEC drafts (as of last week). Please email for corrections/updates. Regards. thomas ------- _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Nov 11 11:51:25 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00707 for ; Thu, 11 Nov 2004 11:51:22 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 66BA48C702; Thu, 11 Nov 2004 11:51:24 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 582178C6F1 for ; Thu, 11 Nov 2004 11:51:23 -0500 (EST) Received: (qmail 33614 invoked by uid 3269); 11 Nov 2004 16:51:23 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 33611 invoked from network); 11 Nov 2004 16:51:22 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 11 Nov 2004 16:51:22 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id iABGpK7245662; Thu, 11 Nov 2004 11:51:21 -0500 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id iABGpKk53566; Thu, 11 Nov 2004 11:51:20 -0500 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id iABGpJ253564; Thu, 11 Nov 2004 11:51:19 -0500 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id iABGpBB07496; Thu, 11 Nov 2004 11:51:11 -0500 Date: Thu, 11 Nov 2004 11:51:09 -0500 (EST) From: canetti To: housley@vigilsec.com, hartmans@mit.edu, smb@research.att.com, msec@securemulticast.org Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="151130192-647871581-1100191869=:24692" Subject: [MSEC] Summary of MSEC meeting at 61st IETF 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 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --151130192-647871581-1100191869=:24692 Content-Type: TEXT/PLAIN; charset=US-ASCII Folks, Attached is a one-page summary of the msec meeting last monday in DC. Full minutes will follow separately. Best, Ran --151130192-647871581-1100191869=:24692 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=61IETF-MSEC-summary Content-Description: Content-Disposition: attachment; filename=61IETF-MSEC-summary Content-Transfer-Encoding: BASE64 DQpPbmUtUGFnZSBTdW1tYXJ5IG9mIE1TRUMgbWVldGluZyBhdCA2MXN0IElF VEYsIERDLCBOb3ZlbWJlciAyMDA0DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN Cg0KV0cgZHJhZnQgc3RhdHVzOg0KDQogIC0gZHJhZnQtaWV0Zi1tc2VjLW1p a2V5LWRoaG1hYy0wNS50eHQgDQogIA0KICAgIElQUiBub3RpY2Ugc2VudCBi eSBhdXRob3JzIGJ1dCBkb2VzIG5vdCBhcHBlYXIgb24gZmlsZS4gQXV0aG9y cyB3aWxsIHZlcmlmeSB0aGF0DQogICAgaXQgaXMgcmVhY2lldmVkIGFuZCB3 aWxsIHNlbmQgYSBjb3B5IGRpcmVjdGx5IHRvIEFEIHNvIHRoYXQgaGUgY2Fu IHN0YXJ0IHJlYWRpbmcuDQoNCiAgLSBkcmFmdC1pZXRmLW1zZWMtaXBzZWMt c2lnbmF0dXJlcy0wMS50eHQNCg0KICAgIFBhc3NlZCBBRCByZXZpZXcuIFJl dmlzaW9uIHdpbGwgYmUgc2VudCBieSBhdXRob3IgYXNhcC4NCiAgICANCiAg LSBkcmFmdC1pZXRmLW1zZWMtZ3Nha21wLXNlYy0wNS50eHQNCg0KICAgIFRo aXMgZHJhZnQgaXMgY3VycmVudGx5IGluIElFVEYgTGFzdCBDYWxsLiBXYWl0 aW5nIG9uIHRoZSBwb2xpY3kgdG9rZW4gZHJhZnQgdG8NCiAgICBhZHZhbmNl Lg0KDQogIC0gZHJhZnQtaWV0Zi1tc2VjLWdrbWFyY2gtMDgudHh0DQoNCiAg ICBPbiBBRCBwbGF0ZSB0byByZXNvbHZlIGRpc2N1c3MgcG9pbnRzIGJ5IElF U0cuDQoNCiAgLSBkcmFmdC1pZXRmLW1zZWMtdGVzbGEtaW50cm8tMDMudHh0 DQoNCiAgICBOZXcgdmVyc2lvbiB3aWxsIGJlIG91dCBzb29uLg0KDQogIC0g ZHJhZnQtaWV0Zi1tc2VjLXRlc2xhLXNwZWMtMDAudHh0DQogICANCiAgICBB IHJldmlzZWQgSS1EIGlzIG5lZWRlZC4NCg0KICAtIGRyYWZ0LWNhcnJhcmEt bmV3dHlwZS1rZXlpZC0wMC50eHQNCg0KICAgQXV0aG9ycyB3aWxsIGNoZWNr IHdoZXRoZXIgYW4gUkZDIGlzIG5lZWRlZCB0byBnZXQgSUFOQSByZWdpc3Ry YXRpb24uIElmIHllcywgdGhpcw0KICAgZHJhZnQgc2hvdWxkIGFkdmFuY2Ug YWx0aG91Z2ggaXQncyBzaG9ydC4NCg0KICAtIGRyYWZ0LWZyaWVzLW1zZWMt Ym9vdHN0cmFwcGluZy10ZXNsYS0wMC50eHQNCg0KICBUaGUgc3VnZ2VzdGlv biBhdCB0aGUgbWVldGluZyB3YXMgdG8gYWRkIGl0IGFzIHJvbGxvdmVyIHRv IHRoZSBNaWtleSBSRkMsDQogIHdpdGggdGhlIGFsdGVybmF0aXZlIGJlaW5n IGEgc2VwYXJhdGUgUkZDLiBJc3N1ZSB0byBiZSBicm91Z2h0IHRvIHRoZSBs aXN0Lg0KDQogIC0gZHJhZnQtaWV0Zi1tc2VjLWdkb2l2Mi0wMQ0KICAtIGRy YWZ0LWR1cXVlci1mbWtlLTAxLnR4dA0KDQogICBUaGUgYXV0aG9ycyBvZiBi b3RoIGRyYWZ0cyB3aWxsIGdldCB0b2dldGhlciB3aXRoIHRoZSBhdXRob3Jz IG9mIEdET0kgaW4gb3JkZXIgdG8NCiAgcmVzb2x2ZSB3aGV0aGVyIGZta2Ug bmVlZHMgdG8gYmUgYSBzZXBhcmF0ZSBkcmFmdCwgb3Igd2hldGhlciBpdCBj YW4gYmUgY29tYmluZWQgd2l0aA0KICB0aGUgR0RPSXYyL0dLRFAgcHJvdG9j b2wgd2hpbGUgcmV0YWluaW5nIHRoZSBuZWVkZWQgZnVuY3Rpb25hbGl0eS4g DQo= --151130192-647871581-1100191869=:24692 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --151130192-647871581-1100191869=:24692-- From msec-bounces@securemulticast.org Fri Nov 12 03:58:24 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12090 for ; Fri, 12 Nov 2004 03:58:24 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 43DDE8D1AD; Fri, 12 Nov 2004 03:58:25 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id DAC558D15F for ; Fri, 12 Nov 2004 03:58:23 -0500 (EST) Received: (qmail 25072 invoked by uid 3269); 12 Nov 2004 08:58:23 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 25069 invoked from network); 12 Nov 2004 08:58:23 -0000 Received: from thoth.sbs.de (192.35.17.2) by klesh.pair.com with SMTP; 12 Nov 2004 08:58:23 -0000 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id iAC8wIfO025585; Fri, 12 Nov 2004 09:58:18 +0100 Received: from mchh247e.mchh.siemens.de (mchh247e.mchh.siemens.de [139.21.200.57]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id iAC8wCma025237; Fri, 12 Nov 2004 09:58:12 +0100 Received: by mchh247e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id <473X1CB4>; Fri, 12 Nov 2004 09:56:51 +0100 Message-ID: <8C878B55C96F924389908D4A7384842A03A02C4A@mchh2c7e.mchh.siemens.de> From: Euchner Martin To: "'canetti'" , housley@vigilsec.com, hartmans@mit.edu, smb@research.att.com, msec@securemulticast.org, Euchner Martin Subject: RE: [MSEC] Summary of MSEC meeting at 61st IETF Date: Fri, 12 Nov 2004 09:58:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org - draft-ietf-msec-mikey-dhhmac-05.txt IPR notice sent by authors but does not appear on file. Authors will verify that it is reacieved and will send a copy directly to AD so that he can start reading. The ID refers to draft-ietf-msec-mikey-dhhmac-07.txt. The IPR statement was sent to the AD and has been published in the meantime in the IPR DB. You can find it at https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=498 I'll send Russ and Sam a copy of the ID for review. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 62366 | COM GC PS 3 mailto:Martin.Euchner@siemens.com | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://ietf.icn.siemens.de/sr3/Standardisation_Topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Nov 12 04:05:01 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12614 for ; Fri, 12 Nov 2004 04:05:01 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 499CF8D484; Fri, 12 Nov 2004 04:05:02 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id D1E628D47B for ; Fri, 12 Nov 2004 04:05:01 -0500 (EST) Received: (qmail 25986 invoked by uid 3269); 12 Nov 2004 09:05:01 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 25978 invoked from network); 12 Nov 2004 09:05:01 -0000 Received: from thoth.sbs.de (192.35.17.2) by klesh.pair.com with SMTP; 12 Nov 2004 09:05:01 -0000 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id iAC94vfO032133; Fri, 12 Nov 2004 10:04:58 +0100 Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iAC94vBO008385; Fri, 12 Nov 2004 10:04:57 +0100 Received: from mchh246e.mchh.siemens.de (mchh246e.mchh.siemens.de [139.21.200.56]) by moody.mchh.siemens.de (8.12.6/8.12.6) with ESMTP id iAC94v17014180; Fri, 12 Nov 2004 10:04:57 +0100 Received: by mchh246e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id <47399JF1>; Fri, 12 Nov 2004 10:04:57 +0100 Message-ID: <8C878B55C96F924389908D4A7384842A03A02C4B@mchh2c7e.mchh.siemens.de> From: Euchner Martin To: Euchner Martin , "'canetti'" , "'housley@vigilsec.com'" , "'hartmans@mit.edu'" , "'smb@research.att.com'" , "'msec@securemulticast.org'" Date: Fri, 12 Nov 2004 10:04:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [MSEC] draft-ietf-msec-mikey-dhhmac-07.txt for AD review X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hello Russ, hello Sam, HMAC-authenticated Diffie-Hellman for MIKEY With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 62366 | COM GC PS 3 mailto:Martin.Euchner@siemens.com | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://ietf.icn.siemens.de/sr3/Standardisation_Topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Euchner Martin Sent: Freitag, 12. November 2004 09:58 To: 'canetti'; housley@vigilsec.com; hartmans@mit.edu; smb@research.att.com; msec@securemulticast.org; Euchner Martin Subject: RE: [MSEC] Summary of MSEC meeting at 61st IETF - draft-ietf-msec-mikey-dhhmac-05.txt IPR notice sent by authors but does not appear on file. Authors will verify that it is reacieved and will send a copy directly to AD so that he can start reading. The ID refers to draft-ietf-msec-mikey-dhhmac-07.txt. The IPR statement was sent to the AD and has been published in the meantime in the IPR DB. You can find it at https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=498 I'll send Russ and Sam a copy of the ID for review. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 62366 | COM GC PS 3 mailto:Martin.Euchner@siemens.com | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://ietf.icn.siemens.de/sr3/Standardisation_Topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Nov 12 04:07:46 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12889 for ; Fri, 12 Nov 2004 04:07:46 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 5E72F8CF5F; Fri, 12 Nov 2004 04:07:48 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 28BEC8CD6D for ; Fri, 12 Nov 2004 04:07:47 -0500 (EST) Received: (qmail 26344 invoked by uid 3269); 12 Nov 2004 09:07:47 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 26341 invoked from network); 12 Nov 2004 09:07:46 -0000 Received: from david.siemens.de (192.35.17.14) by klesh.pair.com with SMTP; 12 Nov 2004 09:07:46 -0000 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id iAC97gBO021861; Fri, 12 Nov 2004 10:07:42 +0100 Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id iAC97fYO013526; Fri, 12 Nov 2004 10:07:41 +0100 Received: from mchh248e.mchh.siemens.de (mchh248e.mchh.siemens.de [139.21.200.58]) by moody.mchh.siemens.de (8.12.6/8.12.6) with ESMTP id iAC97f17016159; Fri, 12 Nov 2004 10:07:41 +0100 Received: by mchh248e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Fri, 12 Nov 2004 10:07:40 +0100 Message-ID: <8C878B55C96F924389908D4A7384842A03A02C4D@mchh2c7e.mchh.siemens.de> From: Euchner Martin To: Euchner Martin , "'canetti'" , "'housley@vigilsec.com'" , "'hartmans@mit.edu'" , "'smb@research.att.com'" , "'msec@securemulticast.org'" Date: Fri, 12 Nov 2004 10:07:39 +0100 Expiry-Date: Sun, 14 Nov 2004 10:07:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [MSEC] Recall: draft-ietf-msec-mikey-dhhmac-07.txt for AD review X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org The sender would like to recall the message, "draft-ietf-msec-mikey-dhhmac-07.txt for AD review". _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Nov 12 04:08:02 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12912 for ; Fri, 12 Nov 2004 04:08:02 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 00EBD8D8FF; Fri, 12 Nov 2004 04:08:04 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id B98CE8D8CD for ; Fri, 12 Nov 2004 04:08:02 -0500 (EST) Received: (qmail 26408 invoked by uid 3269); 12 Nov 2004 09:08:02 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 26405 invoked from network); 12 Nov 2004 09:08:02 -0000 Received: from david.siemens.de (192.35.17.14) by klesh.pair.com with SMTP; 12 Nov 2004 09:08:02 -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 iAC97wBO022091; Fri, 12 Nov 2004 10:07:58 +0100 Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iAC97vBO011922; Fri, 12 Nov 2004 10:07:57 +0100 Received: from mchh248e.mchh.siemens.de (mchh248e.mchh.siemens.de [139.21.200.58]) by moody.mchh.siemens.de (8.12.6/8.12.6) with ESMTP id iAC97v17016275; Fri, 12 Nov 2004 10:07:57 +0100 Received: by mchh248e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Fri, 12 Nov 2004 10:07:56 +0100 Message-ID: <8C878B55C96F924389908D4A7384842A03A02C4E@mchh2c7e.mchh.siemens.de> From: Euchner Martin To: Euchner Martin , "'canetti'" , "'housley@vigilsec.com'" , "'hartmans@mit.edu'" , "'smb@research.att.com'" , "'msec@securemulticast.org'" Date: Fri, 12 Nov 2004 10:07:54 +0100 Expiry-Date: Sun, 14 Nov 2004 10:07:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [MSEC] Recall: draft-ietf-msec-mikey-dhhmac-07.txt for AD review X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org The sender would like to recall the message, "draft-ietf-msec-mikey-dhhmac-07.txt for AD review". _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Nov 12 14:00:36 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02196 for ; Fri, 12 Nov 2004 14:00:33 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 2F0BD8C7A9; Fri, 12 Nov 2004 14:00:34 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 777408C37A for ; Fri, 12 Nov 2004 14:00:33 -0500 (EST) Received: (qmail 19595 invoked by uid 3269); 12 Nov 2004 19:00:33 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 19592 invoked from network); 12 Nov 2004 19:00:33 -0000 Received: from web12501.mail.yahoo.com (216.136.173.193) by klesh.pair.com with SMTP; 12 Nov 2004 19:00:33 -0000 Received: (qmail 20601 invoked by uid 60001); 12 Nov 2004 19:00:32 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=n1islDiehVApvE2SWg9rNBeXN2DqndMGu33OTL4HwMG9E1rBkEAjFUc2FauFHvI0MnEBU/O4nBF1+jwqCSgyhxvcK8RlKTn7N43nrRO/Brpd4qoIUCKWHe/HugLuDACQYWmBi/vdXPjIOqKGgZhJltDxvk1zkCJ6NdSGLGb+cq4= ; Message-ID: <20041112190031.20599.qmail@web12501.mail.yahoo.com> Received: from [65.205.251.51] by web12501.mail.yahoo.com via HTTP; Fri, 12 Nov 2004 11:00:31 PST Date: Fri, 12 Nov 2004 11:00:31 -0800 (PST) From: Thomas Hardjono To: msec@securemulticast.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [MSEC] Please emal me your slides X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Folks, Please email me your slides from MSEC, so that I can post it on the website. cheers, thomas ------ __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Nov 12 16:45:55 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04509 for ; Fri, 12 Nov 2004 16:45:55 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 157BE8CC1D; Fri, 12 Nov 2004 16:45:57 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id E1DF38C782 for ; Fri, 12 Nov 2004 16:45:54 -0500 (EST) Received: (qmail 51083 invoked by uid 3269); 12 Nov 2004 21:45:54 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 51079 invoked from network); 12 Nov 2004 21:45:54 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 12 Nov 2004 21:45:54 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id iACLjq7173564 for ; Fri, 12 Nov 2004 16:45:53 -0500 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id iACLjqk51174 for ; Fri, 12 Nov 2004 16:45:52 -0500 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id iACLjp251172 for ; Fri, 12 Nov 2004 16:45:51 -0500 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id iACLjoK26954 for ; Fri, 12 Nov 2004 16:45:51 -0500 Date: Fri, 12 Nov 2004 16:45:50 -0500 (EST) From: canetti To: msec@securemulticast.org Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="151130192-466862003-1100295950=:27186" Subject: [MSEC] minutes of the DC meeting X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --151130192-466862003-1100295950=:27186 Content-Type: TEXT/PLAIN; charset=US-ASCII Folks, Attached are the minutes of the MSEC meeting at the 61st IETF in DC this week. Thanks to Brian for devotely taking them! Ran/Thomas --151130192-466862003-1100295950=:27186 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=61IETF-minutes Content-Description: Content-Disposition: attachment; filename=61IETF-minutes Content-Transfer-Encoding: BASE64 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KTVNFQyBXRyBNaW51dGVzLCBJRVRGLTYxLCBXYXNoaW5ndG9u IEQuQy4gKE5vdiA4LCAyMDA0KQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpNZWV0aW5nIGF0IE1v bmRheSA4IE5vdmVtYmVyLCA3OjMwLTk6MDBQTQ0KDQpXZWxjb21lIC0gUmFu IENhbmV0dGkgDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KbyBObyBjaGFu Z2VzIHRvIGFnZW5kYQ0KDQpvIFJldmlldyBvZiBXRyBkcmFmdHMNCg0KICAt IGRyYWZ0LWlldGYtbXNlYy1taWtleS1kaGhtYWMtMDUudHh0IA0KICANCiAg ICBUaGlzIGRyYWZ0IGlzIGN1cnJlbnRseSBpbiBBRCBFdmFsdWF0aW9uLiBU aGVyZSBpcyB0aGlyZC1wYXJ0eSBJUFIgY2xhaW0gDQogICAgb24gdGhlIGRy YWZ0LiBSdXNzIEhvdXNsZXkgc2FpZCB0aGF0IGhlIHdpbGwgd2FpdCB1bnRp bCB0aGUgSVBSIGNsYWltIGlzIA0KICAgIHVuZGVyc3Rvb2QgYmVmb3JlIHJl YWRpbmcgdGhlIGRyYWZ0Lg0KDQogIC0gZHJhZnQtaWV0Zi1tc2VjLWlwc2Vj LXNpZ25hdHVyZXMtMDEudHh0DQoNCiAgICBUaGlzIGRyYWZ0IGlzIHVuZGVy IEFEIGV2YWx1YXRpb24uIFJ1c3MgaGFzIHN1Ym1pdHRlZCBBRCBjb21tZW50 cyBvbg0KICAgIHRoZSBkcmFmdC4gQnJpYW4gd2lsbCBiZSBwcm9kdWNpbmcg YSBuZXcgZHJhZnQgYW5zd2VyaW5nIHRob3NlIGNvbW1lbnRzDQogICAgc2hv cnRseSBhZnRlciB0aGUgSS1EIHF1ZXVlIHJlLW9wZW5zLiANCiAgICANCiAg ICBUaGVyZSB3YXMgc29tZSBkaXNjdXNzaW9uIG9uIHdoZXRoZXIgdGhlDQog ICAgbWluaW11bSAoNDk2IGJpdHMpIGlzIHRvbyBzbWFsbCwgb3Igd2hldGhl ciB0aGF0IGlzIE9LIGlmIG9ubHkgdXNlZCBmb3INCiAgICBhbiBTQSB3aXRo IGEgc2hvcnQgbGlmZXRpbWUgKGUuZy4sIDMwIG1pbnV0ZXMpLiBSdXNzIHdv dWxkIGxpa2UgdGhlIGRyYWZ0DQogICAgdG8gaGF2ZSBtb3JlIGd1aWRhbmNl IG9uIGFjY2VwdGFibGUga2V5IHNpemVzLiANCg0KICAtIGRyYWZ0LWlldGYt bXNlYy1nc2FrbXAtc2VjLTA1LnR4dA0KDQogICAgVGhpcyBkcmFmdCBpcyBj dXJyZW50bHkgaW4gSUVURiBMYXN0IENhbGwuIEh1Z2ggaGFkIGEgcXVlc3Rp b24gb24gd2hhdA0KICAgIGhhcHBlbmVkIHRvIHRoZSBwb2xpY3kgdG9rZW4g ZHJhZnQsIGFzIGl0IGlzIHJlZmVyZW5jZWQgYnkgdGhlIEdTQUtNUA0KICAg IGRyYWZ0LiBSdXNzIHNhaWQgdGhhdCB0aGUgR1NBS01QIGRyYWZ0IHNob3Vs ZCBmaW5pc2ggTGFzdCBDYWxsLiBJdCBqdXN0IA0KICAgIGNhbid0IHByb2Nl ZWQgYW55IGZ1cnRoZXIgdW50aWwgdGhlIG5vcm1hdGl2ZSBwb2xpY3kgdG9r ZW4gZG9jdW1lbnQgDQogICAgYWR2YW5jZXMgdG8gdGhlIHNhbWUgbGV2ZWwu DQoNCiAgLSBkcmFmdC1pZXRmLW1zZWMtZ2ttYXJjaC0wOC50eHQNCg0KICAg IFRoaXMgZHJhZnQgaW5jbHVkZWQgdGV4dCB0byBzYXRpc2Z5IHNvbWUgSUVT RyBEaXNjdXNzIHBvaW50cy4gUnVzcyB3aWxsDQogICAgc2VuZCB0aGUgdGV4 dCB0byB0aGUgcGVvcGxlIHdobyBicm91Z2h0IHVwIHRoZSBEaXNjdXNzZXMg YW5kIGhvcGUgdG8gZ2V0DQogICAgdGhlbSByZXNvbHZlZC4NCg0KICAtIGRy YWZ0LWlldGYtbXNlYy10ZXNsYS1pbnRyby0wMy50eHQNCg0KICAgIFJlbWFy a3MgZnJvbSBJRVNHIGFyZSBiZWluZyBhZGRyZXNzZWQsIGFuZCBhIG5ldyBk cmFmdCB3aWxsIGJlIG91dCBzb29uLg0KDQogIC0gZHJhZnQtaWV0Zi1tc2Vj LXRlc2xhLXNwZWMtMDAudHh0DQogICANCiAgICBBIHJldmlzZWQgSS1EIGlz IG5lZWRlZC4NCg0KbyBPdGhlciBkcmFmdHMgd2lsbCBiZSBkaXNjdXNzZWQg aW4gZm9sbG93aW5nIHByZXNlbnRhdGlvbnMuDQoNCkdlbmVyYWwgUGF5bG9h ZCBUeXBlIGluIE1JS0VZIC0gRWxpemFiZXR0YSBDYXJyYXJhDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN Cm8gZHJhZnQtY2FycmFyYS1uZXd0eXBlLWtleWlkLTAwLnR4dA0KDQpvIFRo ZSBvYmplY3RpdmUgb2YgdGhpcyBkcmFmdCBpcyB0byBkZWZpbmUgYSBuZXcg dHlwZSBpbiB0aGUgZ2VuZXJhbCANCiAgZXh0ZW5zaW9uIHBheWxvYWQgaW4g TUlLRVkuIFRoaXMgaXMgbmVlZGVkIGJ5IHRoZSBtdWx0aW1lZGlhIA0KICBi cm9hZGNhc3QvbXVsdGljYXN0IHNlcnZpY2UgKE1CTVMpIGluIDNHUFAgKFJl bDYpLiBUaGUgc3RyZWFtaW5nIHNjZW5hcmlvIA0KICB1c2VzIFNSVFAgZm9y IG1lZGlhIHByb3RlY3Rpb24gYW5kIE1JS0VZIGZvciBrZXkgbWdtdC4gTUJN UyByZXF1aXJlcyBzb21lDQogIGV4dGVuc2lvbnMgaW4gb3JkZXIgdG8gcGFz cyBhbGwgb2YgTUJNUyB0eXBlcyBvZiBrZXlzLg0KDQpvIFJhbiBhc2tlZCB3 aGF0IHR5cGUgb2YgZG9jdW1lbnQgdGhhdCB0aGUgYXV0aG9ycyB3b3VsZCBs aWtlIHRvIHNlZSwgYW5kDQogIEVsaXphYmV0dGEgcmVwbGllZCB0aGF0IHRo ZXkgd291bGQgbGlrZSBhbiBJbmZvcm1hdGlvbmFsIFJGQy4NCg0KbyBSYW4g YXNrZWQgaWYgYW55b25lIG9iamVjdGVkIHRvIHRoaXMgd29yayBpdGVtLiBO byBvbmUgZGlkLg0KDQpvIFRoZXJlIHdhcyBzb21lIHF1ZXN0aW9uIGFzIHRv IHdoYXQgdGhlIElBTkEgY29uc2lkZXJhdGlvbnMgZm9yIE1JS0VZIHNhaWQg DQogIHdhcyBuZWNlc3NhcnkgaW4gb3JkZXIgdG8gYWRkIHRvIGl0cyBuYW1l c3BhY2VzLCBhbmQgd2hldGhlciBhbiBJbmZvLiBSRkMNCiAgd2FzIGFjY2Vw dGFibGUuIExhdGVyIGluc3BlY3Rpb24gc2hvd2VkIHRoYXQgdGhlIE1JS0VZ IFJGQyBkb2VzIG5vdCANCiAgc3BlY2lmeSBhbnkgY3JpdGVyaWEgcmVnYXJk aW5nIHdoYXQgdHlwZSBvZiBkb2N1bWVudCBpcyByZXF1aXJlZCB0byANCiAg dXBkYXRlIHRoaXMuDQoNCk1JS0VZIERILUhNQUMgLSBTdGVmZmVuIEZyaWVz DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpvIGRyYWZ0LWll dGYtbXNlYy1taWtleS1kaGhtYWMtMDUudHh0DQoNCm8gU3RlZmZhbiBkZXNj cmliZWQgdGhlIGNoYW5nZXMgaW4gdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRo ZSBkb2N1bWVudC4NCg0KbyBUaGUgbmV4dCBzdGVwcyBpbmNsdWRlIGFuIEFE IHJldmlldy4gUnVzcyBhc2tlZCBmb3IgY2xhcmlmaWNhdGlvbiBvbiB0aGUN CiAgdGhpcmQtcGFydHkgSVBSIHN0YXRlbWVudC4gU3RlZmZhbiByZXBsaWVk IHRoYXQgaXQgYWxsZWdlZGx5IHdhcyBzZW50IHRvIHRoZQ0KICBJRVRGIGJ1 dCB0aGF0IGl0IGhhZG4ndCBhcHBlYXJlZCBvbiB0aGUgd2ViIHNpdGUgeWV0 LiBJdCBhcHBhcmVudGx5DQogIGFkZHJlc3NlcyB0aGlzIGRyYWZ0IHBhcnRp Y3VsYXJseS4NCg0KQm9vdHN0cmFwcGluZyBURVNMQSAtIFN0ZWZmZW4gRnJp ZXMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCm8g ZHJhZnQtZnJpZXMtbXNlYy1ib290c3RyYXBwaW5nLXRlc2xhLTAwLnR4dA0K DQpvIFRoaXMgZHJhZnQgZGVmaW5lcyBhIG5ldyBwYXlsb2FkIGFuZCBwb2xp Y3kgcGFyYW1ldGVycyBmb3IgYm9vdHN0cmFwcGluZw0KICBURVNMQSBpbiBT UlRQLiBUaGVyZSBoYXMgYmVlbiBzb21lIHF1ZXN0aW9ucyBvbiB0aGUgbWFp bGluZyBsaXN0IGFib3V0IGhvdw0KICB0byBzeW5jaHJvbml6ZSB0aW1lIGJl dHdlZW4gdGhlIHNlbmRlciBhbmQgcmVjZWl2ZXJzLCBhbmQgU3RlZmZhbiBm YXZvcnMNCiAgdXNpbmcgYW4gb3V0LW9mLWJhbmQgbWV0aG9kIChlLmcuLCBO VFAgb3IgU05UUCkuDQoNCiAgLSBNYXJrIHBvaW50ZWQgb3V0IHRoYXQgdGhl IG1vc3Qgc3RyYWlnaHRmb3J3YXJkIHdheSB0byBzeW5jaHJvbml6ZSBtaWdo dCBiZSANCiAgICB1c2luZyBhIHJvdW5kLXRyaXAgdGltZSAobGlrZSBhICJw aW5nIiByb3VuZC10cmlwKS4gDQogIC0gU3RlZmZhbiBwb2ludGVkIG91dCB0 aGF0IGl0IGRlcGVuZHMgb24gd2hpY2ggc2lkZSBpbml0aWF0ZXMgdGhlIE1J S0VZIA0KICAgIHByb3RvY29sLiBUaGUgY29udGVudCByZWNlaXZlciB3b3Vs ZCBuZWVkIHRvIGluaXRpYXRlIHRoZSBwcm90b2NvbC4NCiAgLSBSYW4gc2Fp ZCB0aGF0IHRoZSBjb250ZW50IHJlY2VpdmVyIHdvdWxkIGhhdmUgdG8gdXNl IHRoZSBpbnRlcmFjdGl2ZSANCiAgICB2ZXJzaW9uIG9mIE1JS0VZLg0KICAt IFN0ZWZmYW4gc2FpZCB0aGF0IGl0IHN0aWxsIGRlcGVuZHMgb24gd2hvIGlu aXRpYXRlcyBNSUtFWS4NCiAgLSBSYW4gc2FpZCB0aGF0IGluIHRoZSAyIG1l c3NhZ2UgdGhlIG1lZGlhIHJlY2VpdmVyIGFsd2F5cyBzdGFydHMgZmlyc3Qu DQogIC0gTGFrc2htaW5hdGggcG9pbnRlZCBvdXQgdGhhdCBpcyB0aGUgb3B0 aW9uYWwgZXhjaGFuZ2UgaW4gTUlLRVksIG5vdCANCiAgICBlaXRoZXIgb2Yg dGhlIHR3byBtYW5kYXRvcnkgb25lcyENCiAgLSBTdGVmZmFuIHNhaWQgdGhh dCBpbiB0aG9zZSB5b3UgbmVlZCBhIDNyZCBtZXNzYWdlIGlmIHRoZSBtZWRp YSBzZW5kZXIgaXMgDQogICAgaW52aXRpbmcgdGhlIHJlY2VpdmVyLg0KDQpv IFRoZSB3b3JraW5nIGdyb3VwIGRpc2N1c3NlZCB3aGV0aGVyIG9yIG5vdCB0 aGF0IHRoZSBkcmFmdCBzaG91bGQgYmUNCiAgc3RhbmQtYWxvbmUsIG9yIHdo ZXRoZXIgaXQgc2hvdWxkIGJlIGNvbWJpbmVkIHdpdGggdGhlIFRFU0xBLVNS VFAgZHJhZnQuIEl0DQogIGN1cnJlbnRseSBpcyBvbmx5IHVzZWQgYnkgdGhl IFRFU0xBLVNSVFAgZHJhZnQsIGJ1dCBpZiBpdCByZW1haW5zIGluZGVwZW5k ZW50DQogIGl0IGNvdWxkIGJlIHVzZWQgYnkgb3RoZXIga2V5IG1hbmFnZW1l bnQgcHJvdG9jb2xzIHN1cHBvcnRpbmcgVEVTTEEgKGUuZy4sDQogIEdTQUtN UCkuIFRoaXMgd2FzIGRpc2N1c3NlZCBhdCBncmVhdGVyIGxlbmd0aCBpbiB0 aGUgbmV4dCBwcmVzZW50YXRpb24uDQoNClRFU0xBX2luLVNSVFAgdXBkYXRl ICAtIEVsaXphYmV0dGEgQ2FycmFyYQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCm8gZHJhZnQtaWV0Zi1tc2VjLXNy dHAtdGVzbGEtMDIudHh0DQoNCm8gRWxpemFiZXR0YSBkaXNjdXNzZWQgdGhl IGNoYW5nZXMgdGhhdCB3ZW50IGludG8gdGhpcyBkcmFmdC4NCg0KICAtIFJh biBhc2tlZCBpZiBpcyB0aGUgVEVTTEEgaW5mb3JtYXRpb24gaW4gU3RlZmZh bidzIGRyYWZ0IGNvbnNpc3RlbnQgd2l0aCANCiAgICB0aGlzIGRyYWZ0Pw0K ICAtIFN0ZWZmYW4gcmVwbGllZCB0aGF0IHRoZXJlIHdlcmUgc29tZSBkaWZm ZXJlbmNlcy4NCg0KbyBSYW4gYXNrZWQgdGhhdCB0aGUgd29ya2luZyBncm91 cCBjb25zaWRlciB3aGV0aGVyIHRoZXNlIHNob3VsZCBiZSBvbmUgZHJhZnQg DQogIG9yIHR3by4NCg0KICAtIE1hcmsgc2FpZCB0aGF0IHRoZSBTUlRQLVRF U0xBIGRyYWZ0IHNob3VsZCBkZXNjcmliZSBib3RoIHRoZSBURVNMQSANCiAg ICBzaWduYWxpbmcgYW5kIGRhdGEgcGFyYW1ldGVycy4NCiAgLSBNYXJrIGhh ZCBhIGNvbmNlcm4gdGhhdCB0aGVyZSB3ZXJlbid0IGFueSBpbXBsZW1lbnRh dGlvbnMgb2YgdGhlIFRFU0xBDQogICAgd29yaywgd2hpY2ggaXMga2V5IHRv IGdldHRpbmcgZ29vZCBkcmFmdHMuIFdlIG91Z2h0IHRvIGhhdmUgMiANCiAg ICBpbXBsZW1lbnRhdGlvbnMuDQoNCm8gQSB2b3RlIHdhcyB0YWtlbiBvbiB3 aGV0aGVyIHRoZSBkcmFmdHMgc2hvdWxkIGJlIG1lcmdlZC4gRm91ciB2b3Rl ZCAiZm9yIiwNCmFuZCB0d28gYWdhaW5zdC4gVGhlIHR3byBhZ2FpbnN0IHdl cmUgdGhlIGF1dGhvcnMgb2YgdGhlIGRyYWZ0cywgd2hpY2ggbGVkIHRvDQpt b3JlIGRpc2N1c3Npb24uDQoNCiAgLSBTdGVmZmFuIHNhaWQgaGUnZCBsaWtl IHRvIGtlZXAgdGhlbSBzZXBhcmF0ZSBpbiBjYXNlIGFub3RoZXIgcHJvdG9j b2wgDQogICAgd2FudGVkIHRvIHVzZSB0aGUgZHJhZnQgdG8gYm9vdHN0cmFw IFRFU0xBLg0KICAtIEJyaWFuIHBvaW50ZWQgb3V0IHRoYXQgdGhlIGRyYWZ0 IGhhZCBwYWNrZXQgZm9ybWF0cyBzcGVjaWZpYyBmb3IgVEVTTEEsIA0KICAg IHdoaWNoIG1pZ2h0IG5vdCB3b3JrIHdpdGggb3RoZXIgcHJvdG9jb2xzLiAN CiAgLSBIdWdoIG1lbnRpb25lZCB0aGF0IGlmIHlvdSBoYXZlIGEgbWl4ZWQg Z3JvdXAgd2l0aCBkaWZmZXJlbnQga2V5DQogICAgbWFuYWdlbWVudCBtZWNo YW5pc21zIGJvdGggYm9vdHN0cmFwcGluZyBURVNMQSAoZS5nLiwgR1NBS01Q LCBNSUtFWSkgaG93IA0KICAgIGVsc2UgYXJlIHRoZXkgZ29pbmcgdG8gbWFr ZSBzdXJlIHRoZSBURVNMQS1TUlRQIHBvbGljeSB3b3JrcyBjb3JyZWN0bHk/ IA0KICAgIEJ5IG1hcnJ5aW5nIHRoZSB0d28gZHJhZnQgeW91IGFyZSBtYWtp bmcgdGhpcyBoYXJkZXIuDQogIC0gTWFyayBzdW1tYXJpemVkIEh1Z2ggYnkg c2F5aW5nIHRoYXQgdGhlcmUgY291bGQgYmUgYW4gaW50ZXJ3b3JraW5nIHBy b2JsZW0NCiAgICBpbiB0aGUgZGlmZmVyZW50IHByb3RvY29scyBpZiB0aGV5 IGRlZmluZSB0aGUgcG9saWN5IGluZGVwZW5kZW50bHkuDQogIC0gQnJpYW4g c2FpZCB0aGF0IHdlIGRpZG4ndCBtYWtlIGl0IGFuIG9iamVjdGl2ZSB0byBt YWtlIHRoZSBrZXkgbWFuYWdlbWVudA0KICAgIHByb3RvY29scyBpbnRlcm9w ZXJhdGUgdXAgJ3RpbCBub3cuDQogIC0gTGFrc2htaW5hdGggYXNrZWQgaWYg dGhlIGRlc2NyaXB0aW9uIGNhbiAgZ28gaW4gdGhlIFRFU0xBIGRvY3M/DQog IC0gUmFuIHNhaWQgdGhhdCB0aGUgVEVTTEEgaW50cm9kdWN0aW9uIGRyYWZ0 IGlzIGluZm9ybWF0aW9uYWwsIHNvIHRoYXQncyANCiAgICB0aGUgd3Jvbmcg cGxhY2UuIFdlIG5lZWQgYSBzdGFuZGFyZHMgdHJhY2sgZG9jdW1lbnQuDQog IC0gTWFyayBhc2tlZCBob3cgYWJvdXQgaWYgd2UgY3JlYXRlIGEgbmV3IE1J S0VZIGRyYWZ0IGJhc2VkIG9uIHRoZSBSRkMgdG8gDQogICAgYWRkIHRoZSBU RVNMQSBib290c3RyYXBwaW5nIHBhcmFtZXRlcnMsIHNpbmNlIHRoYXQncyB3 aGVyZSB0aGV5IHNob3VsZA0KICAgIGhhdmUgYmVlbiBpbiB0aGUgZmlyc3Qg cGxhY2U/IFRoZW4gdGhlIE1JS0VZIGRyYWZ0IHdvdWxkIGJlIGN5Y2xlZCB0 bw0KICAgIHByb3Bvc2VkIHN0YW5kYXJkLg0KICAtIFJ1c3MgZ2F2ZSBzb21l IHRoaW5ncyB0byB0aGluayBhYm91dCByZWdhcmRpbmcgZ29pbmcgdG8gcHJv cG9zZWQgc3RkOiB0bw0KICAgIGFkdmFuY2UgaXQgaXQgaGFzIHRvIGhhdmUg YmVlbiBzdGFibGUgZm9yIDYgbW9udGhzLiBTbyBpZiB5b3UgZ28gdGhpcw0K ICAgIHJvdXRlLCBkbyB0aGUgY2hhbmdlcyBlYXJsaWVyIHNvIHRoYXQgdGhl IHR3byBpbnRlcm9wZXJhdGluZw0KICAgIGltcGxlbWVudGF0aW9ucyBjYW4g YmUgc3RhYmxlIGZvciA2IG1vbnRocy4NCiAgLSBMYWtzaG1pbmF0aCBzYWlk IGxvdHMgb2YgcGVvcGxlIGxpa2UgdG8gc2VlIGEgc3RhYmxlIFJGQyBiZWZv cmUgdGhleSANCiAgICBpbXBsZW1lbnQgaXQhIFRoYXQgbWlnaHQgYmUgYSB3 b3JyeSB0byBjdXJyZW50IE1JS0VZIGltcGxlbWVudGVycy4gVGhpcw0KICAg IGRlY2lzaW9uIHNob3VsZCBiZSB0YWtlbiB0byB0aGUgbGlzdC4NCg0KVXBk YXRlIG9uIEdET0l2Mi9HS0RQIC0gTGFrc2htaW5hdGggRG9uZGV0aQ0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpv IGRyYWZ0LWlldGYtbXNlYy1nZG9pdjItMDENCg0KbyBUaGlzIGRyYWZ0IGhh cyBhIG5ldyBuYW1lOiBHcm91cCBLZXkgRGlzdHJpYnV0aW9uIFByb3RvY29s LiBUaGlzIGlzIHRoZQ0KICByZXN1bHQgb2YgY29tbWVudHMgYWdhaW5zdCAt MDAgd2hpY2ggc2FpZCB0aGF0IHdlIG1pZ2h0IHdhbnQgdG8gYWN0dWFsbHkN CiAgbWFrZSBhIEdET0l2MiBzb21lZGF5IGJhc2VkIG9uIFJGQyAzNTQ3Lg0K DQpvIFRoaXMgZHJhZnQgcHJvcG9zZXMgYSB2YXJpYW50IG9mIEdET0kgdXNp bmcgSUtFdjIgYXMgdGhlIGF1dGhlbnRpY2F0ZWQNCiAgdHVubmVsIHJhdGhl ciB0aGFuIElLRXYxLiBUaGVyZSBhcmUgZmV3IHVwZGF0ZXMgZnJvbSAtMDAg dGltZS4gTGFrc2htaW5hdGggDQogIGhhcyBhIGNvLWF1dGhvciwgYW5kIGlz IGxvb2tpbmcgZm9yIG1vcmUgaGVscC4NCg0KbyBMb29rIGZvciBtb3JlIHVw ZGF0ZXMgb24gdGhlIG1haWxpbmcgbGlzdC4NCg0KRmxhdCBNdWx0aWNhc3Qg S2V5IEV4Y2hhbmdlIC0gRW1hbm5ldWxlIEpvbmVzDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KbyBkcmFmdC1k dXF1ZXItZm1rZS0wMS50eHQNCg0KbyBFbWFubmV1bGUgSm9uZXMgcHJlc2Vu dGVkIG9uIGJlaGFsZiBvZiBhdXRob3JzLCB3aG8gd2VyZSBub3QgYWJsZSB0 byBhdHRlbmQuDQoNCm8gVGhlIHByb3RvY29sIGlzIGRlcml2ZWQgZnJvbSBH RE9JLCBhbmQgcHJvdmlkZXMgYW4gYWRhcHRlZCBzb2x1dGlvbiBmb3IgDQog IHdpcmVsZXNzIGxpbmtzLiBJUCBvdmVyIHNhdGVsbGl0ZSBpcyBjb25zaWRl cmVkLCBhbmQgcG9zc2libHkgYWxzbyBXaUZpIGFuZA0KICBXSU1BWC4NCg0K byBUaGUgLTAxIGRyYWZ0IGhhcyBiZWVuIGNoYW5nZWQgdG8gYmUgYSB1c2Ug YSBjYXNlIG9mIEdET0ksIGFuZCB1bmRlcmxpbmVzIA0KICB0aGUgZGlmZmVy ZW5jZXMgYmV0d2VlbiB0aGUgcHJvdG9jb2xzLg0KICANCiAgLSBHZW9yZ2Ug cG9pbnRlZCBvdXQgdGhhdCB0aGUgcmVsaWFiaWxpdHkgcHJvdG9jb2wgaW4g Rk1LRSBoYXMgYXR0cmlidXRlcyANCiAgICB0aGF0IHJlc2VtYmxlIHRoZSBS TVQgIk5PUk0iIHByb3RvY29sLiBJdCBpcyBhbiBSTVQgYnVpbGRpbmcgYmxv Y2sgdGhhdCBpcw0KICAgIG9wdGltYWwgZm9yIHRoaXMga2luZCBvZiBwcm9i bGVtLg0KDQpvIFR3byBkZW1vbnN0cmF0b3JzIGhhdmUgYmVlbiBkZXZlbG9w ZWQgdXNpbmcgRk1LRS4gT25lIHdhcyBwYXJ0IG9mIHRoZSBJU1QgDQogIFNh dGlwNiBwcm9qZWN0LiBUaGUgb3RoZXIgd2FzIGEgbWlsaXRhcnkgRFZCLVJD UyBhcHBsaWNhdGlvbi4gIEluIGJvdGggY2FzZXMgDQogIEZNS0UgcGhhc2Ug MSBhbmQgcGhhc2UgMiBFU1Agd2VyZSBpbXBsZW1lbnRlZC4NCg0KbyBUaGUg bmV4dCBzdGVwcyBhcmUgdG8gbWluaW1pemUgdGhlIEZNS0UgY2hhbmdlcywg Zm9sZCB0aGVtIGludG8gR0RPSSBpZiBpdCANCiAgaXMgcG9zc2libGUgYW5k IHB1Ymxpc2ggYSBhIG5ldyB2ZXJzaW9uIG9mIEdET0kuDQoNCiAgLSBCcmlh biBzYWlkIHRoYXQgaGUgZGlkbid0IHNlZSB3aHkgdGhlIHByb3Bvc2VkIGNo YW5nZXMgY291bGQgYmUgYWRkZWQgdG8NCiAgICBHRE9JIHJhdGhlciB0aGFu IGNyZWF0aW5nIGEgbmV3IERPSSB2YWx1ZSAoYXMgdGhlIGN1cnJlbnQgZHJh ZnQgcHJvcG9zZXMpLA0KICAgIGJ1dCB3ZSBuZWVkIHRvIHRhbGsgYWJvdXQg dGhlIHJlcXVpcmVtZW50cywgYW5kIHdoYXQgcmVxdWlyZW1lbnRzIHRoYXQg DQogICAgR0RPSSBjYW4gY3VycmVudGx5IHNvbHZlLiBTcGVjaWZpYyBjb21t ZW50cyBzaG91bGQgYmUgcG9zdGVkIHRvIHRoZSBsaXN0DQogICAgdG8gc3Rh cnQgYSBkaXNjdXNzaW9uIHdpdGggdGhlIGF1dGhvcnMuDQogIC0gTWFyayBz YWlkIHRoYXQgR0RPSSBkb2Vzbid0IGFkZHJlc3MgcmVsaWFibGUgbXVsdGlj YXN0LCBhbmQgaGFzIG5vIGJhY2sgDQogICAgY2hhbm5lbCBvcGVyYXRpb24u IEhpcyB0aG91Z2h0IGlzIHRoYXQgR0RPSSBzaG91bGQgYmUgYWJsZSB0byBz dXBwb3J0IA0KICAgIHRoZXNlIGluIHRoZSBiYXNlIHNwZWNpZmljYXRpb24u IEEgZnVydGhlciBwcm9saWZlcmF0aW9uIG9mIGtleSBtZ210IA0KICAgIHBy b3RvY29scyBpcyBub3QgYSBnb29kIHRoaW5nLiANCiAgLSBIdWdoIHBvaW50 ZWQgb3V0IHRoYXQgTG9naWNhIGlzIHNvbHZpbmcgdGhpcyBwcm9ibGVtIHVz aW5nIEdTQUtNUC4NCiAgLSBSYW4gc3VnZ2VzdGVkIHRoYXQgbWF5YmUgdGhp cyBzaG91bGQgYmUgZm9sZGVkIGludG8gR0tEUC4NCg0KbyBSYW4gYXNrZWQg aWYgdGhpcyB3b3JrIGluIHNjb3BlPw0KICAtIEJyaWFuIHNhaWQgeWVzLCB0 aGF0IGl0IGlzIGFkZHJlc3NpbmcgdGhlIGlzc3VlIHdpdGggYW4gSVAgbmV0 d29yayB3aXRoIA0KICAgIGludGVyZXN0aW5nIGNoYXJhY3RlcmlzdGljcy4N CiAgLSBNYXJrIHNhaWQgdGhhdCB3ZSBzaG91bGQgZ2V0IHRvZ2V0aGVyIHRo ZSBHRE9JIGFuZCBETUtFIGF1dGhvcnMgdG8gdGFsayANCiAgICBhYm91dCB0 aGlzIGluIHRoZSBuZXh0IGZldyB3ZWVrcy4NCg0KV3JhcCBVcCAtIFJhbiBD YW5ldHRpDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KbyBSYW4gcG9pbnRl ZCBvdXQgdGhhdCBhY2NvcmRpbmcgdG8gb3VyIGNoYXJ0ZXIgd2Ugc2hvdWxk IGJlIGRvbmUgc29vbiwgYW5kDQphc2tlZCBpZiB0aGVyZSBzaG91bGQgYmUg bmV3IHdvcmsgaXRlbXM/DQogIC0gR2VvcmdlIHNhaWQgYSBnZW5lcmljIHBv bGljeSB0b2tlbi4NCiAgLSBIdWdoIGNsYXJpZmllZCB0aGF0IHRoaXMgaXMg dGhlIHBvaW50IG9mIGEgcG9saWN5IHRva2VuLg0KICAtIExha3NobWluYXRo IG1lbnRpb25lZCB0aGF0IHdlIHRhbGtlZCBhYm91dCByZWxpYWJsZSB0cmFu c3BvcnQgb2YgcmVrZXkgDQogICAgbWVzc2FnZXMgdHdvIHllYXJzIGFnbywg YW5kIHNhaWQgdGhhdCBzaW1wbGUgcmVwZWF0ZWQgdHJhbnNtaXNzaW9uIG9m IHJla2V5DQogICAgbWVzc2FnZXMgc2hvdWxkIHdvcmsuIE5vdyB0aGF0IHRo aXMgaXMgY29taW5nIHVwIGFnYWluIGluIEZNS0UsIGl0DQogICAgbWlnaHQg YmUgdGltZSBhZ2FpbiBpbiB0aGUgTWFyY2ggbWVldGluZyB0byBkaXNjdXNz IHRoaXMgYW5kIGhvdyB3ZSBzaG91bGQgDQogICAgZG8gdGhpcy4NCiAgLSBS YW4gbWVudGlvbmVkIGEgcG9saWN5IHRva2VuIGZvciBFU1AuDQo= --151130192-466862003-1100295950=:27186 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --151130192-466862003-1100295950=:27186-- From msec-bounces@securemulticast.org Fri Nov 12 17:11:40 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06164 for ; Fri, 12 Nov 2004 17:11:39 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id CF2C28CFD7; Fri, 12 Nov 2004 17:11:39 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 5CDDE8CFC6 for ; Fri, 12 Nov 2004 17:11:39 -0500 (EST) Received: (qmail 55578 invoked by uid 3269); 12 Nov 2004 22:11:39 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 55575 invoked from network); 12 Nov 2004 22:11:39 -0000 Received: from mgw-x4.nokia.com (131.228.20.27) by klesh.pair.com with SMTP; 12 Nov 2004 22:11:39 -0000 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iACMBaE02268 for ; Sat, 13 Nov 2004 00:11:37 +0200 (EET) X-Scanned: Sat, 13 Nov 2004 00:11:33 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iACMBXmt012464 for ; Sat, 13 Nov 2004 00:11:33 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 003Gd46u; Sat, 13 Nov 2004 00:11:31 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iACMBVS25118 for ; Sat, 13 Nov 2004 00:11:31 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 12 Nov 2004 16:10:39 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Nov 2004 17:10:38 -0500 Message-ID: Thread-Topic: small MIKEY question - Security policy payload Thread-Index: AcTJBHChbuVqIQrkTsyIwt2mevOGbQ== From: To: X-OriginalArrivalTime: 12 Nov 2004 22:10:39.0803 (UTC) FILETIME=[71B620B0:01C4C904] Subject: [MSEC] small MIKEY question - Security policy payload X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: quoted-printable Hi all, I have a question regarding the Security policy payload (SP) of the = MIKEY protocol. In the I_MESSAGE, there is zero or more Security Policy = payloads. Suppose the Initiator does not include any SP payload (so the = default security policy will be used), in the CS ID map info in the = header, do we still set the policy no. field to zero for all CS?=20 Thanks! BR - Tat _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Nov 15 08:33:27 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24276 for ; Mon, 15 Nov 2004 08:33:26 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 5685C8D30F; Mon, 15 Nov 2004 08:33:27 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 724158D300 for ; Mon, 15 Nov 2004 08:33:25 -0500 (EST) Received: (qmail 78884 invoked by uid 3269); 15 Nov 2004 13:33:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 78881 invoked from network); 15 Nov 2004 13:33:25 -0000 Received: from eagle.ericsson.se (193.180.251.53) by klesh.pair.com with SMTP; 15 Nov 2004 13:33:25 -0000 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iAFDXMR2021629; Mon, 15 Nov 2004 14:33:22 +0100 Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Nov 2004 14:33:22 +0100 Received: from esealmw104.eemea.ericsson.se ([153.88.200.67]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Nov 2004 14:33:26 +0100 Content-class: urn:content-classes:message Subject: RE: [MSEC] small MIKEY question - Security policy payload MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 15 Nov 2004 14:33:20 +0100 Message-ID: <3AD208E1F0D5EB47AC3C5617420BCB021110F9@esealmw104.eemea.ericsson.se> Thread-Topic: small MIKEY question - Security policy payload Thread-Index: AcTJBJYxEm7WoRZLSg2kH/B0GaVW3ACEYk9g From: "Fredrik Lindholm (KI/EAB)" To: , X-OriginalArrivalTime: 15 Nov 2004 13:33:26.0565 (UTC) FILETIME=[AFB30D50:01C4CB17] 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 Tat, you are correct in setting the "policy no" to the same value for=20 all CSs (zero is a good choice). For consistency, you should=20 also include one "empty" SP header with "Policy no" zero (that=20 is if you set "policy no" to zero in the first place),=20 "Prot type" to the value of the protocol you are using (of course=20 today you can only chose SRTP, 0), and finally "Policy param=20 length" to 0 (hence no SP "payload"/parameters should be included).=20 The purpose of the "empty" SP header is to indicate the protocol=20 profile from which the default values are used. BR, Fredrik > -----Original Message----- > From: msec-bounces@securemulticast.org > [mailto:msec-bounces@securemulticast.org]On Behalf Of=20 > Tat.Chan@nokia.com > Sent: den 12 november 2004 23:11 > To: msec@securemulticast.org > Subject: [MSEC] small MIKEY question - Security policy payload >=20 >=20 > Hi all, >=20 > I have a question regarding the Security policy payload (SP)=20 > of the MIKEY protocol. In the I_MESSAGE, there is zero or=20 > more Security Policy payloads. Suppose the Initiator does not=20 > include any SP payload (so the default security policy will=20 > be used), in the CS ID map info in the header, do we still=20 > set the policy no. field to zero for all CS?=20 >=20 > Thanks! >=20 > BR > - Tat > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec >=20 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Nov 18 11:17:23 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07384 for ; Thu, 18 Nov 2004 11:17:23 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 419868D89B; Thu, 18 Nov 2004 11:17:25 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 3F53A8D8A3 for ; Thu, 18 Nov 2004 11:17:24 -0500 (EST) Received: (qmail 8973 invoked by uid 3269); 18 Nov 2004 16:17:24 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 8970 invoked from network); 18 Nov 2004 16:17:23 -0000 Received: from us1.net2.com.br (64.246.26.27) by klesh.pair.com with SMTP; 18 Nov 2004 16:17:23 -0000 Received: (qmail 23190 invoked by uid 513); 18 Nov 2004 16:12:15 -0000 Received: from atv@alan.pro.br by us1.net2.com.br by uid 101 with qmail-scanner-1.22 (f-prot: 4.4.1/3.14.11. Clear:RC:1(200.157.179.240):. Processed in 0.276172 secs); 18 Nov 2004 16:12:15 -0000 Received: from unknown (HELO m1.net2.com.br) (200.157.179.240) by us1.net2.com.br with SMTP; 18 Nov 2004 16:12:14 -0000 Received: from 200.129.132.200 (SquirrelMail authenticated user atv@alan.pro.br) by m1.net2.com.br with HTTP; Thu, 18 Nov 2004 13:14:01 -0300 (BRT) Message-ID: <1527.200.129.132.200.1100794441.squirrel@m1.net2.com.br> Date: Thu, 18 Nov 2004 13:14:01 -0300 (BRT) From: "Alan Tamer Vasques" To: msec@securemulticast.org User-Agent: SquirrelMail/1.4.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Subject: [MSEC] Doubts X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi, I'm a brazilian post-graduation student and I'm developing a research about MSEC architecture. I have some doubts about it and I would be very thankfull if you could answer them. First of all, I know MSEC is the name of IETF WC, but I am not sure if MSEC will be the name of the security protocol for Multicast, like IPSec is for Unicast. It may appear like a silly question, but will MSEC be its name? Then, I'd like to know if there is already any implementation of MSEC (the architecure as a whole). I've already seen GSAKMP for Linux at Sparta, but it's only the GKM protocol. Thanks in advance. Best regards, Alan Tamer Vasques _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Nov 18 11:42:58 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10354 for ; Thu, 18 Nov 2004 11:42:58 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 9EBF98DAF6; Thu, 18 Nov 2004 11:43:00 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 75FEA8DABC for ; Thu, 18 Nov 2004 11:42:59 -0500 (EST) Received: (qmail 12942 invoked by uid 3269); 18 Nov 2004 16:42:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 12939 invoked from network); 18 Nov 2004 16:42:59 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 18 Nov 2004 16:42:59 -0000 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.1/8.13.1) with ESMTP id iAIGgtBx007565; Thu, 18 Nov 2004 10:42:55 -0600 Received: from columbia.sparta.com ([157.185.80.32]) by Beta5.sparta.com (8.12.11/8.12.11) with ESMTP id iAIGgt8v030002; Thu, 18 Nov 2004 10:42:55 -0600 Received: from [157.185.80.11] (dhcp-11.columbia.sparta.com [157.185.80.11]) by columbia.sparta.com (8.12.10+Sun/8.12.10) with ESMTP id iAIGgsor008407; Thu, 18 Nov 2004 11:42:54 -0500 (EST) In-Reply-To: <1527.200.129.132.200.1100794441.squirrel@m1.net2.com.br> References: <1527.200.129.132.200.1100794441.squirrel@m1.net2.com.br> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hugh Harney Subject: Re: [MSEC] Doubts Date: Thu, 18 Nov 2004 11:42:55 -0500 To: "Alan Tamer Vasques" X-Mailer: Apple Mail (2.619) 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 Alan, The GSAKMP code gets you 66% of the way to a full architecture. GSAKMP provides key distribution and policy distribution, the only thing missing is the data layer protocol to use the GSAKMP key. I don't know where you can find the reference code for the data layer. hugh On Nov 18, 2004, at 11:14 AM, Alan Tamer Vasques wrote: > Hi, > > I'm a brazilian post-graduation student and I'm developing a research > about MSEC architecture. I have some doubts about it and I would be > very > thankfull if you could answer them. > > First of all, I know MSEC is the name of IETF WC, but I am not sure if > MSEC will be the name of the security protocol for Multicast, like > IPSec > is for Unicast. It may appear like a silly question, but will MSEC be > its > name? > > Then, I'd like to know if there is already any implementation of MSEC > (the > architecure as a whole). I've already seen GSAKMP for Linux at Sparta, > but > it's only the GKM protocol. > > Thanks in advance. > > Best regards, > > Alan Tamer Vasques > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > Hugh Harney Sparta, Inc. hh@sparta.com 7075 Samuel Morse Drive (410) 872-1515 x203 Columbia, MD, 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Nov 18 17:46:13 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27986 for ; Thu, 18 Nov 2004 17:46:13 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 551398DA98; Thu, 18 Nov 2004 17:46:15 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 26CB48DABD for ; Thu, 18 Nov 2004 17:46:14 -0500 (EST) Received: (qmail 15601 invoked by uid 3269); 18 Nov 2004 22:46:14 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 15598 invoked from network); 18 Nov 2004 22:46:13 -0000 Received: from smtp-out2.oct.nac.net (209.123.233.212) by klesh.pair.com with SMTP; 18 Nov 2004 22:46:13 -0000 Received: (qmail 78268 invoked from network); 18 Nov 2004 17:46:12 -0500 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 18 Nov 2004 17:46:12 -0500 Received: (qmail 36938 invoked from network); 18 Nov 2004 17:46:12 -0500 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.82) by mail1.oct.nac.net with SMTP; 18 Nov 2004 17:46:12 -0500 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id iAIK7cD30137; Thu, 18 Nov 2004 15:07:38 -0500 Date: Thu, 18 Nov 2004 15:07:38 -0500 (EST) From: George Gross To: , Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: gmgross@nac.net Subject: [MSEC] RSA signature distributed key cracking attack 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 Brien, I was reviewing the v03 draft, and it is certainly very improved over earlier editions. I think it is largely ready to go proposed standard. However, while reading section 2.1 that discusses key strength, I thought about the possibility of the following attack. I don't know if anyone else has previously identified something along these lines: Suppose that an adversary has managed to install an agent program on a large fraction of the secure multicast group's endpoints. For example, such an agent program could be distributed via an e-mail virus or by leveraging the multicast group's routing infrastructure itself. The agent program would use some distributed algorithm to focus each compromised endpoint's key cracking efforts on a distinct subset of the RSA signature private key solution space. Once an agent program broke the private key, it would unicast the solution to the adversary. For a large scale group, on the order of 10**6 or 10**7 compromised endpoints, this parallel cracking effort could yield a noticable reduction in the key's useful lifetime. Although I have not implemented this attack, it seems technically feasible in principle. The question is, does this hypothetical attack warrent an adjustment in the section 2.1 text offering key strength guidelines? The rev'd text could indicate that key strength may need to be set stronger as a policy for those large-scale groups that are considered at risk for this attack. thoughts? br, George _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Nov 19 08:33:05 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00317 for ; Fri, 19 Nov 2004 08:33:04 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id A510B8C6CA; Fri, 19 Nov 2004 08:33:03 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 453B08D7D5 for ; Fri, 19 Nov 2004 08:33:02 -0500 (EST) Received: (qmail 74711 invoked by uid 3269); 19 Nov 2004 13:33:02 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 74707 invoked from network); 19 Nov 2004 13:33:01 -0000 Received: from eagle.ericsson.se (193.180.251.53) by klesh.pair.com with SMTP; 19 Nov 2004 13:33:01 -0000 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iAJDWuR2019971; Fri, 19 Nov 2004 14:32:56 +0100 Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 19 Nov 2004 14:32:56 +0100 Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 19 Nov 2004 14:32:56 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Nov 2004 14:32:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <0CDAE977A7172A40A2A3A1C20C12BD653ADC85@esealmw106.eemea.ericsson.se> Thread-Topic: about the integration of TESLA bootstrapping in MIKEY Thread-Index: AcTNj+WBLkka9jdrTjK028uYbNSaSQAqQJkg From: "Elisabetta Carrara (KI/EAB)" To: X-OriginalArrivalTime: 19 Nov 2004 13:32:56.0467 (UTC) FILETIME=[47697630:01C4CE3C] Cc: steffen.fries@siemens.com Subject: [MSEC] TESLA bootstrapping in MIKEY 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, during the meeting in Washington, we discussed about an appropriate place for the new draft on TESLA bootstrapping with MIKEY, presented by Steffen. The alternatives discussed were proceeding with the work as=20 standalone, or integrating it within MIKEY itself, by initiating a MIKEY bis. There were different opinions during the meeting, and we said to take this to the list. Steffen and I discussed further and agreed to maintain the TESLA bootstrapping a standalone draft.=20 A main reason is that we believe that it is anyway too soon for a=20 draft bis for MIKEY. The TESLA bootstrapping is very modular and can=20 constitute a contained RFC. Another reason is of course time related. Starting a bis work takes quite some time and will require much effort from the people involved. This will delay the other work. A draft bis would make sense if there are more extensions popping out, which is not the case for the moment. Also, having a bis would open up the question of adding there existing things like DHHMAC, and the MBMS extension (which definitely can't=20 wait). At the time being, there exists 4 documents dealing with MIKEY=20 and extensions (MIKEY RFC, DHHMAC, MBMS extension, TESLA bootstrapping). = Let's assume that in the future more extensions are being defined.=20 Then we have again the problem of multiple MIKEY documents. We might=20 in that case consider what to do, for example we could write an Info RFC that links the different pieces together, which has also the advantage that it is more easy to keep updated compared to add changes in MIKEY. We would like to hear if this is ok with you folk, or if there are any strong opinion against. Thanks cheers /Elisabetta _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Nov 19 11:58:16 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20922 for ; Fri, 19 Nov 2004 11:58:16 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 05C518DA61; Fri, 19 Nov 2004 11:58:18 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 98FCB8DA59 for ; Fri, 19 Nov 2004 11:58:16 -0500 (EST) Received: (qmail 8627 invoked by uid 3269); 19 Nov 2004 16:58:16 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 8624 invoked from network); 19 Nov 2004 16:58:16 -0000 Received: from sj-iport-4.cisco.com (171.68.10.86) by klesh.pair.com with SMTP; 19 Nov 2004 16:58:16 -0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 19 Nov 2004 08:58:36 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (stealth-10-32-244-212.cisco.com [10.32.244.212]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id iAJGwCVx028902; Fri, 19 Nov 2004 08:58:13 -0800 (PST) Message-ID: <419E266D.1000402@cisco.com> Date: Fri, 19 Nov 2004 08:59:25 -0800 From: Brian Weis User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Gross Subject: Re: [MSEC] RSA signature distributed key cracking attack References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Hi George, You bring up a good point. I became aware of the possibility of distributed attacks during my research into RSA keypair strength, which was necessary in order to write section 2.1. It has been considered carefully. The most promising method known to find an RSA private key (using cryptanalysis) is to factor the modulus. The best known method of factoring is some variant of the Number Field Sieve (NFS) algorithm. I'm not a cryptographer, so I know that getting too specific here is going to get me into trouble. But I'll try to generally describe how NFS works. There are two phases to NFS: a sieve phase and a matrix reduction phase. The sieve phase can indeed be distributed in the way you describe. In fact, the solutions for the last several RSA challenges employed a distributed technique for this phase (although they did not use a virus form of distribution). But the matrix reduction phase is different -- it requires a very large amount of memory. In some cases, the amount of memory required is more than the amount of memory a 32-bit processor can address! There is no known way to efficiently distribute all of that memory and still perform matrix calculations at modern processor speeds. The matrix reduction phase therefore is the gating time factor in factoring the modulus. In summary, an attacker still needs a fast dedicated processor, with much memory, and cannot simply rely upon borrowed machinery to perform the full task. The minimum real time needed to factor a modulus is roughly the maximum amount of time a keypair should be used. The references in Section 2.1 describe some formulae that can be used to make educated guesses as to the minimum real time needed to factor a modulus. This was the basis for my numbers in Table 1. However, because so much is based on "educated guesses", I was advised by Scott Fluhrer to reduce the recommended times significantly (e.g., in case it is discovered that the matrix reduction phase *can* be parallelized). So the numbers in Table 1 of the I-D should be considered to be extremely conservative values at this point in time. Thanks, Brian George Gross wrote: >Hi Brien, > > I was reviewing the v03 draft, and it is certainly very improved >over earlier editions. I think it is largely ready to go proposed >standard. However, while reading section 2.1 that discusses key strength, >I thought about the possibility of the following attack. I don't know if >anyone else has previously identified something along these lines: > > Suppose that an adversary has managed to install an agent program >on a large fraction of the secure multicast group's endpoints. For >example, such an agent program could be distributed via an e-mail virus or >by leveraging the multicast group's routing infrastructure itself. The >agent program would use some distributed algorithm to focus each >compromised endpoint's key cracking efforts on a distinct subset of the >RSA signature private key solution space. Once an agent program broke the >private key, it would unicast the solution to the adversary. > >For a large scale group, on the order of 10**6 or 10**7 compromised >endpoints, this parallel cracking effort could yield a noticable reduction >in the key's useful lifetime. > > Although I have not implemented this attack, it seems technically >feasible in principle. The question is, does this hypothetical attack >warrent an adjustment in the section 2.1 text offering key strength >guidelines? The rev'd text could indicate that key strength may need to be >set stronger as a policy for those large-scale groups that are considered >at risk for this attack. > >thoughts? > >br, > George > > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://six.pairlist.net/mailman/listinfo/msec > > > -- Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Nov 19 12:45:04 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25666 for ; Fri, 19 Nov 2004 12:45:03 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 2CF728D948; Fri, 19 Nov 2004 12:45:06 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 4778F8D930 for ; Fri, 19 Nov 2004 12:45:05 -0500 (EST) Received: (qmail 17448 invoked by uid 3269); 19 Nov 2004 17:45:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 17445 invoked from network); 19 Nov 2004 17:45:04 -0000 Received: from smtp-out2.oct.nac.net (209.123.233.212) by klesh.pair.com with SMTP; 19 Nov 2004 17:45:04 -0000 Received: (qmail 23435 invoked from network); 19 Nov 2004 12:45:02 -0500 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 19 Nov 2004 12:45:02 -0500 Received: (qmail 80476 invoked from network); 19 Nov 2004 12:45:01 -0500 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.82) by mail1.oct.nac.net with SMTP; 19 Nov 2004 12:45:01 -0500 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id iAJF6Jm31905; Fri, 19 Nov 2004 10:06:19 -0500 Date: Fri, 19 Nov 2004 10:06:19 -0500 (EST) From: George Gross To: Brian Weis Subject: Re: [MSEC] RSA signature distributed key cracking attack In-Reply-To: <419E266D.1000402@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: George Gross , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi Brian, this was an insightful summary of the problem domain. Given what you've described, I wonder if the adversary simply has to have the agent program at each of the compromised group endpoints forward their NFS computations to the adversary's super-computer for the matrix reduction phase. I'll grant you, this extra requirement becomes a much harder attack to orchestrate without detection ;o) So, the section 2.1 table 1 already has been adjusted for the prospect of the attacker having to wait for a sequential matrix reduction computation to complete. FWIW, would you consider adding a qualifying statement that says the solution time estimate is dependent on matrix reduction algorithm's state of the art being a sequential algorithm, rather than a parallel algorithm that can be distributed across the multicast group? tia, George On Fri, 19 Nov 2004, Brian Weis wrote: > Hi George, > > You bring up a good point. I became aware of the possibility of > distributed attacks during my research into RSA keypair strength, which > was necessary in order to write section 2.1. It has been considered > carefully. > > The most promising method known to find an RSA private key (using > cryptanalysis) is to factor the modulus. The best known method of > factoring is some variant of the Number Field Sieve (NFS) algorithm. I'm > not a cryptographer, so I know that getting too specific here is going > to get me into trouble. But I'll try to generally describe how NFS works. > > There are two phases to NFS: a sieve phase and a matrix reduction phase. > The sieve phase can indeed be distributed in the way you describe. In > fact, the solutions for the last several RSA challenges employed a > distributed technique for this phase (although they did not use a virus > form of distribution). But the matrix reduction phase is different -- it > requires a very large amount of memory. In some cases, the amount of > memory required is more than the amount of memory a 32-bit processor can > address! There is no known way to efficiently distribute all of that > memory and still perform matrix calculations at modern processor speeds. > The matrix reduction phase therefore is the gating time factor in > factoring the modulus. In summary, an attacker still needs a fast > dedicated processor, with much memory, and cannot simply rely upon > borrowed machinery to perform the full task. > > The minimum real time needed to factor a modulus is roughly the maximum > amount of time a keypair should be used. The references in Section 2.1 > describe some formulae that can be used to make educated guesses as to > the minimum real time needed to factor a modulus. This was the basis for > my numbers in Table 1. > > However, because so much is based on "educated guesses", I was advised > by Scott Fluhrer to reduce the recommended times significantly (e.g., in > case it is discovered that the matrix reduction phase *can* be > parallelized). So the numbers in Table 1 of the I-D should be considered > to be extremely conservative values at this point in time. > > Thanks, > Brian > > George Gross wrote: > > >Hi Brien, > > > > I was reviewing the v03 draft, and it is certainly very improved > >over earlier editions. I think it is largely ready to go proposed > >standard. However, while reading section 2.1 that discusses key strength, > >I thought about the possibility of the following attack. I don't know if > >anyone else has previously identified something along these lines: > > > > Suppose that an adversary has managed to install an agent program > >on a large fraction of the secure multicast group's endpoints. For > >example, such an agent program could be distributed via an e-mail virus or > >by leveraging the multicast group's routing infrastructure itself. The > >agent program would use some distributed algorithm to focus each > >compromised endpoint's key cracking efforts on a distinct subset of the > >RSA signature private key solution space. Once an agent program broke the > >private key, it would unicast the solution to the adversary. > > > >For a large scale group, on the order of 10**6 or 10**7 compromised > >endpoints, this parallel cracking effort could yield a noticable reduction > >in the key's useful lifetime. > > > > Although I have not implemented this attack, it seems technically > >feasible in principle. The question is, does this hypothetical attack > >warrent an adjustment in the section 2.1 text offering key strength > >guidelines? The rev'd text could indicate that key strength may need to be > >set stronger as a policy for those large-scale groups that are considered > >at risk for this attack. > > > >thoughts? > > > >br, > > George > > > > > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://six.pairlist.net/mailman/listinfo/msec > > > > > > > > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Nov 19 23:46:19 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00680 for ; Fri, 19 Nov 2004 23:46:19 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id BA3298D197; Fri, 19 Nov 2004 23:46:20 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 2FC938D0CC for ; Fri, 19 Nov 2004 23:46:19 -0500 (EST) Received: (qmail 20525 invoked by uid 3269); 20 Nov 2004 04:46:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 20522 invoked from network); 20 Nov 2004 04:46:18 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 20 Nov 2004 04:46:18 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id iAK4k7E326936; Fri, 19 Nov 2004 23:46:08 -0500 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id iAK4k7B38026; Fri, 19 Nov 2004 23:46:07 -0500 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id iAK4k6A44260; Fri, 19 Nov 2004 23:46:06 -0500 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id iAK4k5r25514; Fri, 19 Nov 2004 23:46:05 -0500 Date: Fri, 19 Nov 2004 23:46:05 -0500 (EST) From: canetti To: George Gross Subject: Re: [MSEC] RSA signature distributed key cracking attack In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Brian Weis , 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 George, I must say that the specific concern of distributing the NFS computation over the multicast group (as opposed to distributing it in general) seems to me somewhat of a red herring. If an attacker wants to distribute computations it has multiple potential ways of doing so, and I dont see that using the group members is easier than using any other collecion of unsuspecting Internet users... Best, Ran On Fri, 19 Nov 2004, George Gross wrote: > Hi Brian, > > this was an insightful summary of the problem domain. Given what > you've described, I wonder if the adversary simply has to have the agent > program at each of the compromised group endpoints forward their NFS > computations to the adversary's super-computer for the matrix reduction > phase. I'll grant you, this extra requirement becomes a much harder attack > to orchestrate without detection ;o) > > So, the section 2.1 table 1 already has been adjusted for the prospect of > the attacker having to wait for a sequential matrix reduction computation > to complete. > > FWIW, would you consider adding a qualifying statement that says the > solution time estimate is dependent on matrix reduction algorithm's state > of the art being a sequential algorithm, rather than a parallel algorithm > that can be distributed across the multicast group? > > tia, > George > > On Fri, 19 Nov 2004, Brian Weis wrote: > > > Hi George, > > > > You bring up a good point. I became aware of the possibility of > > distributed attacks during my research into RSA keypair strength, which > > was necessary in order to write section 2.1. It has been considered > > carefully. > > > > The most promising method known to find an RSA private key (using > > cryptanalysis) is to factor the modulus. The best known method of > > factoring is some variant of the Number Field Sieve (NFS) algorithm. I'm > > not a cryptographer, so I know that getting too specific here is going > > to get me into trouble. But I'll try to generally describe how NFS works. > > > > There are two phases to NFS: a sieve phase and a matrix reduction phase. > > The sieve phase can indeed be distributed in the way you describe. In > > fact, the solutions for the last several RSA challenges employed a > > distributed technique for this phase (although they did not use a virus > > form of distribution). But the matrix reduction phase is different -- it > > requires a very large amount of memory. In some cases, the amount of > > memory required is more than the amount of memory a 32-bit processor can > > address! There is no known way to efficiently distribute all of that > > memory and still perform matrix calculations at modern processor speeds. > > The matrix reduction phase therefore is the gating time factor in > > factoring the modulus. In summary, an attacker still needs a fast > > dedicated processor, with much memory, and cannot simply rely upon > > borrowed machinery to perform the full task. > > > > The minimum real time needed to factor a modulus is roughly the maximum > > amount of time a keypair should be used. The references in Section 2.1 > > describe some formulae that can be used to make educated guesses as to > > the minimum real time needed to factor a modulus. This was the basis for > > my numbers in Table 1. > > > > However, because so much is based on "educated guesses", I was advised > > by Scott Fluhrer to reduce the recommended times significantly (e.g., in > > case it is discovered that the matrix reduction phase *can* be > > parallelized). So the numbers in Table 1 of the I-D should be considered > > to be extremely conservative values at this point in time. > > > > Thanks, > > Brian > > > > George Gross wrote: > > > > >Hi Brien, > > > > > > I was reviewing the v03 draft, and it is certainly very improved > > >over earlier editions. I think it is largely ready to go proposed > > >standard. However, while reading section 2.1 that discusses key strength, > > >I thought about the possibility of the following attack. I don't know if > > >anyone else has previously identified something along these lines: > > > > > > Suppose that an adversary has managed to install an agent program > > >on a large fraction of the secure multicast group's endpoints. For > > >example, such an agent program could be distributed via an e-mail virus or > > >by leveraging the multicast group's routing infrastructure itself. The > > >agent program would use some distributed algorithm to focus each > > >compromised endpoint's key cracking efforts on a distinct subset of the > > >RSA signature private key solution space. Once an agent program broke the > > >private key, it would unicast the solution to the adversary. > > > > > >For a large scale group, on the order of 10**6 or 10**7 compromised > > >endpoints, this parallel cracking effort could yield a noticable reduction > > >in the key's useful lifetime. > > > > > > Although I have not implemented this attack, it seems technically > > >feasible in principle. The question is, does this hypothetical attack > > >warrent an adjustment in the section 2.1 text offering key strength > > >guidelines? The rev'd text could indicate that key strength may need to be > > >set stronger as a policy for those large-scale groups that are considered > > >at risk for this attack. > > > > > >thoughts? > > > > > >br, > > > George > > > > > > > > > > > >_______________________________________________ > > >msec mailing list > > >msec@securemulticast.org > > >http://six.pairlist.net/mailman/listinfo/msec > > > > > > > > > > > > > > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Sun Nov 28 17:59:30 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23378 for ; Sun, 28 Nov 2004 17:59:28 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 12ACC8D7B2; Sun, 28 Nov 2004 17:59:30 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id EEE198D5D6 for ; Sun, 28 Nov 2004 17:59:28 -0500 (EST) Received: (qmail 74616 invoked by uid 3269); 28 Nov 2004 22:59:28 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 74611 invoked from network); 28 Nov 2004 22:59:28 -0000 Received: from smtp1.smtp.bt.com (217.32.164.137) by klesh.pair.com with SMTP; 28 Nov 2004 22:59:28 -0000 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Sun, 28 Nov 2004 23:00:41 +0000 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Sun, 28 Nov 2004 23:00:41 +0000 Received: from cbibipnt05.hc.bt.com ([147.149.196.177]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.0); Sun, 28 Nov 2004 23:00:40 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.107.36]) by cbibipnt05.hc.bt.com (WebShield SMTP v4.5 MR1a); id 1101682781211; Sun, 28 Nov 2004 22:59:41 +0000 Received: from mut.jungle.bt.co.uk ([132.146.136.69]) by bagheera.jungle.bt.co.uk (8.12.8/8.12.8) with ESMTP id iASMxKP3011690; Sun, 28 Nov 2004 22:59:24 GMT Message-Id: <5.2.1.1.2.20041127120557.034ebdf0@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sat, 27 Nov 2004 12:16:09 +0000 To: Mark Baugher From: Bob Briscoe Subject: Re: [MSEC] Key index field is redundant with SRTP In-Reply-To: <6B65887B-050E-11D9-9416-000A95DC10F2@cisco.com> References: <5.2.1.1.2.20040902085428.019f1ce8@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040902085428.019f1ce8@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 28 Nov 2004 23:00:41.0079 (UTC) FILETIME=[15388070:01C4D59E] Cc: elisabetta.carrara@ericsson.com, "David A. McGrew" , 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 Mark, This is the first of a couple of replies to MSEC-TESLA issues I've left hanging from mid Sep (I've probably lost the right to an opinion taking this long to reply - I got tied up with my day job at that time and I've only just got back that far in my backlog)... At 22:52 12/09/2004, Mark Baugher wrote: >hi Bob, > Do you still think we should use the RTP timestamp in place of the >key ID? Nope, I've relented to pressure. I'm now convinced that there are cases where the RTP timestamp needs to be independent of wall-clock time. Thanks particularly to Dave McGrew's example. I've also been convinced that the general desire not to tie together protocols unnecessarily tightly is worth more than the bytes saved doing so in this case. Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Sun Nov 28 18:00:16 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23451 for ; Sun, 28 Nov 2004 18:00:16 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C5F0D8D7B1; Sun, 28 Nov 2004 18:00:17 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id D29AE8DA42 for ; Sun, 28 Nov 2004 18:00:16 -0500 (EST) Received: (qmail 74826 invoked by uid 3269); 28 Nov 2004 23:00:16 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 74823 invoked from network); 28 Nov 2004 23:00:16 -0000 Received: from saturn.bt.com (HELO cbibipnt08.hc.bt.com) (193.113.57.20) by klesh.pair.com with SMTP; 28 Nov 2004 23:00:16 -0000 Received: from cbibipnt08.hc.bt.com ([147.149.100.81]) by cbibipnt08.hc.bt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WY4V63LR; Sun, 28 Nov 2004 23:00:20 -0000 Received: From bagheera.jungle.bt.co.uk ([132.146.107.36]) by cbibipnt08.hc.bt.com (WebShield SMTP v4.5 MR1a); id 1101682820737; Sun, 28 Nov 2004 23:00:20 +0000 Received: from mut.jungle.bt.co.uk ([132.146.136.69]) by bagheera.jungle.bt.co.uk (8.12.8/8.12.8) with ESMTP id iASN07P3011715; Sun, 28 Nov 2004 23:00:11 GMT Message-Id: <5.2.1.1.2.20041127121743.03638730@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sun, 28 Nov 2004 23:00:28 +0000 To: Mark Baugher , elisabetta.carrara@ericsson.com From: Bob Briscoe In-Reply-To: References: <5.2.1.1.2.20040901174602.01a9d630@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040829115918.01a5b5d8@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040818123555.03388d30@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040818123555.03388d30@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040829115918.01a5b5d8@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040901174602.01a9d630@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040914174749.01aaa9d8@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Atul.Sharma@nokia.com, "Dondeti, Lakshminath" , msec@securemulticast.org Subject: [MSEC] MUST/MAY discard unverifiable (draft-ietf-msec-srtp-tesla-02.txt) X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Mark, Elisabetta, Returning to this subject after a long break (purely my fault)... At 19:24 14/09/2004, Mark Baugher wrote: >On Sep 14, 2004, at 11:55 AM, Mark Baugher wrote: > >>On Sep 14, 2004, at 9:58 AM, Bob Briscoe wrote: >>>>5/ Discard if a packet cannot be authenticated should be optional >>>= Agreed >> >>I did not sign up for this one - or at least I did not mean to. I'd >>like to discuss this some more. Personally, I want to limit options >>wherever possible and this is the second option (including making the >>group [MAC] optional) >>that you have proposed. I don't think we necessarily want to add this >>particular option and would like to hear what others have to say on >>the matter. >> >>thanks, Mark If a packet cannot be authenticated, whether to drop it or not can be chosen unilaterally by the receiver. It isn't a *protocol* option. It is a receiver choice. If it cannot be verified, it doesn't complicate the protocol to say the receiver MAY rather than MUST drop a packet. My view remains that it is over-prescriptive to tell a receiver it MUST drop a packet. Indeed, whatever we say in the RFC, applications will be free to do what they like. The balance between the value of rendering-quality and authenticity is up to the application, not us. Quoting the RFC Editor's policy: "...Imperatives ... MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions). For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability." --- But there *is* a potential protocol issue here (which applies to all authentication protocols, IPsec as much as TESLA). Application(s) 'above' verification in the stack (e.g. rendering, congestion control, intrustion detection) may need to distinguish the difference between discard due to: - congestion/corruption - proven malicious attack - indeterminate authentication (in TESLA due to network delay *or* an attack) For intrustion detection, these can be distinguished by logging different types of security event, as specified in the srtp-tesla draft. But, congestion control usually works purely on packet delivery (I don't think SRTP says anything about whether verification is done before or after congestion control). Yes, proven attack packets should be discarded (after logging), because they aren't part of the stream sent by the genuine sender. But if packets can't be verified they shouldn't necessarily just be discarded: - If they were genuine packets, congestion control will respond wrongly if they *are* discarded - If they were attack packets, congestion control will respond wrongly if they *aren't* discarded. Of course, the same is true of rendering: - If they were genuine packets, rendering will respond wrongly if they *are* discarded - If they were attack packets, rendering will respond wrongly if they *aren't* discarded. So, in order not to complicate the spec, I still maintain we should say (in section 4.4) "...If the safe condition does not hold, the packet MAY [not MUST] be discarded, and the event SHOULD be logged." In these cases, it is up to the receiving system to decide whether such packets are more likely to be genuine or malicious, choosing whether to use or discard the packet. With consequent consistent effects on congestion control, rendering etc. There is a natural tendency for security people to be conservative under uncertainty. But we have to remember security must be balanced by usability. Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Sun Nov 28 18:10:33 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24667 for ; Sun, 28 Nov 2004 18:10:33 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 1461B8DA5F; Sun, 28 Nov 2004 18:10:35 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 555E88DA3A for ; Sun, 28 Nov 2004 18:10:34 -0500 (EST) Received: (qmail 76287 invoked by uid 3269); 28 Nov 2004 23:10:34 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 76282 invoked from network); 28 Nov 2004 23:10:34 -0000 Received: from smtp4.smtp.bt.com (217.32.164.151) by klesh.pair.com with SMTP; 28 Nov 2004 23:10:34 -0000 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Sun, 28 Nov 2004 23:11:47 +0000 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Sun, 28 Nov 2004 23:11:47 +0000 Received: from cbibipnt05.hc.bt.com ([147.149.196.177]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.0); Sun, 28 Nov 2004 23:11:46 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.107.36]) by cbibipnt05.hc.bt.com (WebShield SMTP v4.5 MR1a); id 11016834478; Sun, 28 Nov 2004 23:10:47 +0000 Received: from mut.jungle.bt.co.uk ([132.146.136.69]) by bagheera.jungle.bt.co.uk (8.12.8/8.12.8) with ESMTP id iASNASP3011877; Sun, 28 Nov 2004 23:10:31 GMT Message-Id: <5.2.1.1.2.20041128114033.03672e48@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sun, 28 Nov 2004 23:10:34 +0000 To: Mark Baugher , elisabetta.carrara@ericsson.com From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 28 Nov 2004 23:11:46.0661 (UTC) FILETIME=[A1F04150:01C4D59F] Cc: msec@securemulticast.org Subject: [MSEC] Review of changes in draft-ietf-msec-srtp-tesla-02.txt X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Mark, Elisabetta, 1/ In the new text in section 5. "...Since a key is repeated across packets in an interval, TESLA is robust to packet loss...." This understates TESLA's loss tolerance, so may confuse people trying to understand applicability. Should read something like: "...Since a key in a lost packet can be derived from a future packet, TESLA is robust to packet loss...." 2/ I still disagree with keeping the SRTP (external) MAC mandatory... ...But my argument relies on the technique to protect against DoS you haven't seen in detail yet. I've added this to draft-ietf-msec-tesla-intro-04 (as well as fixing all the IESG comments). I've just sent it to my TESLA co-authors for agreement. I believe it allows us to state very strong DoS prevention properties. Hopefully I should be able to send it to the list within the week. 3/ Other than the comment in the previous mail on "MUST/MAY discard unverifiable", these are the only problems I can find with a nice clean, clear draft. Thanks Bob ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Nov 29 05:33:11 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03503 for ; Mon, 29 Nov 2004 05:33:11 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 6D1948D0ED; Mon, 29 Nov 2004 05:33:12 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 054638D03E for ; Mon, 29 Nov 2004 05:33:12 -0500 (EST) Received: (qmail 28517 invoked by uid 3269); 29 Nov 2004 10:33:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 28514 invoked from network); 29 Nov 2004 10:33:11 -0000 Received: from penguin.ericsson.se (193.180.251.47) by klesh.pair.com with SMTP; 29 Nov 2004 10:33:11 -0000 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iATAWvh7010653; Mon, 29 Nov 2004 11:33:02 +0100 (MET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Nov 2004 11:32:59 +0100 Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Nov 2004 11:32:59 +0100 Content-class: urn:content-classes:message Subject: RE: [MSEC] Review of changes in draft-ietf-msec-srtp-tesla-02.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Nov 2004 11:32:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <0CDAE977A7172A40A2A3A1C20C12BD653ADDF2@esealmw106.eemea.ericsson.se> Thread-Topic: [MSEC] Review of changes in draft-ietf-msec-srtp-tesla-02.txt Thread-Index: AcTVn3geQW5EVZ4cQky9RPkTt5FtvwAXkYCw From: "Elisabetta Carrara (KI/EAB)" To: "Bob Briscoe" X-OriginalArrivalTime: 29 Nov 2004 10:32:59.0681 (UTC) FILETIME=[CC282910:01C4D5FE] Cc: Mark Baugher , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: quoted-printable Hi Bob, first of all many thanks for your comments. > >1/ In the new text in section 5. >"...Since a key is repeated across packets in an interval,=20 >TESLA is robust=20 >to packet loss...." > >This understates TESLA's loss tolerance, so may confuse people=20 >trying to=20 >understand applicability. Should read something like: > >"...Since a key in a lost packet can be derived from a future=20 >packet, TESLA=20 >is robust to packet loss...." ok > >2/ I still disagree with keeping the SRTP (external) MAC mandatory... > >...But my argument relies on the technique to protect against DoS you=20 >haven't seen in detail yet. I've added this to=20 >draft-ietf-msec-tesla-intro-04 (as well as fixing all the=20 >IESG comments).=20 >I've just sent it to my TESLA co-authors for agreement. I=20 >believe it allows=20 >us to state very strong DoS prevention properties. Hopefully I=20 >should be=20 >able to send it to the list within the week. The external MAC is mandatory only for SRTCP, it is optional for SRTP.=20 We thought this was a good choice, mainly for two reasons: - the RTCP packet is generally long and not that frequent. This means=20 that the bandwidth issue is not of such a high concern as instead it is=20 for RTP packets. We can live with 4 extra bytes in SRTCP. - we wanted to maintain the choice done in the SRTP main spec (auth tag mandatory for SRTCP and optional for SRTP). Those were the motivations for the current normative language.=20 Cheers /E _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Nov 29 07:55:34 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15226 for ; Mon, 29 Nov 2004 07:55:34 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 3668F8D4D6; Mon, 29 Nov 2004 07:55:34 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 4AFB18D4CC for ; Mon, 29 Nov 2004 07:55:33 -0500 (EST) Received: (qmail 49124 invoked by uid 3269); 29 Nov 2004 12:55:33 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 49121 invoked from network); 29 Nov 2004 12:55:33 -0000 Received: from smtp3.smtp.bt.com (217.32.164.138) by klesh.pair.com with SMTP; 29 Nov 2004 12:55:33 -0000 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Mon, 29 Nov 2004 12:56:45 +0000 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 29 Nov 2004 12:56:45 +0000 Received: from cbibipnt05.hc.bt.com ([147.149.196.177]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 29 Nov 2004 12:56:43 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.107.36]) by cbibipnt05.hc.bt.com (WebShield SMTP v4.5 MR1a); id 1101732930139; Mon, 29 Nov 2004 12:55:30 +0000 Received: from mut.jungle.bt.co.uk (maat.jungle.bt.co.uk [132.146.108.145]) by bagheera.jungle.bt.co.uk (8.12.8/8.12.8) with ESMTP id iATCtRP3020067; Mon, 29 Nov 2004 12:55:28 GMT Message-Id: <5.2.1.1.2.20041129115344.0368c6e0@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 29 Nov 2004 12:55:23 +0000 To: "Elisabetta Carrara (KI/EAB)" From: Bob Briscoe Subject: RE: [MSEC] Review of changes in draft-ietf-msec-srtp-tesla-02.txt In-Reply-To: <0CDAE977A7172A40A2A3A1C20C12BD653ADDF2@esealmw106.eemea.er icsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 29 Nov 2004 12:56:43.0352 (UTC) FILETIME=[E043ED80:01C4D612] Cc: Mark Baugher , 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 Elisabetta, At 10:32 29/11/2004, Elisabetta Carrara \(KI/EAB\) wrote: > >2/ I still disagree with keeping the SRTP (external) MAC mandatory... > > > >...But my argument relies on the technique to protect against DoS you > >haven't seen in detail yet. I've added this to > >draft-ietf-msec-tesla-intro-04 (as well as fixing all the > >IESG comments). > >I've just sent it to my TESLA co-authors for agreement. I > >believe it allows > >us to state very strong DoS prevention properties. Hopefully I > >should be > >able to send it to the list within the week. > >The external MAC is mandatory only for SRTCP, it is optional for SRTP. >We thought this was a good choice, mainly for two reasons: >- the RTCP packet is generally long and not that frequent. This means >that the bandwidth issue is not of such a high concern as instead it is >for RTP packets. We can live with 4 extra bytes in SRTCP. >- we wanted to maintain the choice done in the SRTP main spec (auth tag >mandatory for SRTCP and optional for SRTP). >Those were the motivations for the current normative language. OK, I admit to being to hasty. I hadn't noticed the reference to the "SRTP (external) MAC" being mandatory was only in the "SRTCP packet format" section. I'm glad to see that, for SRTP packet format, the SRTP MAC is now recommended, not mandatory. Regarding SRTCP, I can see the rationale you lay out. And I certainly cannot think of a scalable alternatiev for authenticating each receiver separately to the source. But, I can still see scenarios where mandating a group keyed MAC, even just for SRTCP, will be seen by implementors as just "baggage to comply with the standard", involving creating disseminating, re-keying and managing a group key when it provides no useful protection. Think for example of Internet TV. A shared secret really is an oxymoron when millions of people share it. 3/ So we are left with a DoS vulnerability for the source from group members (who can't be identified individually) flooding it with SRTCP reports appearing to come from different receivers - possibly bogus ones that cause the session to slow to a snail-pace. This would be nasty for Internet TV, say. But I can't think how to fix this easily. The cookie approach would help. Where, when under attack, the source could switch the session to a mode where each SRTCP report should be preceded by a request to make a report. It would reply with a cookie, which it would check against the next incoming RTCP report from that receiver. At least this would validate the IP addresses of the receivers making reports, as a deterrent. But this cookie approach would have to go into base SRTP (I'm not even sure that's the best place for it). It's nothing specific to SRTP-TESLA. Bob ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Nov 29 09:09:00 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22819 for ; Mon, 29 Nov 2004 09:08:59 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 74BD68D46F; Mon, 29 Nov 2004 09:09:00 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id AEB878D1A3 for ; Mon, 29 Nov 2004 09:08:59 -0500 (EST) Received: (qmail 60736 invoked by uid 3269); 29 Nov 2004 14:08:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 60733 invoked from network); 29 Nov 2004 14:08:59 -0000 Received: from david.siemens.de (192.35.17.14) by klesh.pair.com with SMTP; 29 Nov 2004 14:08:59 -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 iATE8vDw005404; Mon, 29 Nov 2004 15:08:57 +0100 Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iATE8u2B021717; Mon, 29 Nov 2004 15:08:56 +0100 Received: from mchh253e.mchh.siemens.de (mchh253e.mchh.siemens.de [139.21.200.63]) by moody.mchh.siemens.de (8.12.6/8.12.6) with ESMTP id iATE8unI003126; Mon, 29 Nov 2004 15:08:56 +0100 Received: by mchh253e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Mon, 29 Nov 2004 15:08:34 +0100 Message-ID: <8C878B55C96F924389908D4A7384842A03A02C75@mchh2c7e.mchh.siemens.de> From: Euchner Martin To: "'Elisabetta Carrara (KI/EAB)'" , msec@securemulticast.org, Euchner Martin Subject: RE: [MSEC] TESLA bootstrapping in MIKEY Date: Mon, 29 Nov 2004 15:03:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Cc: Fries Steffen 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 No opinion against but slightly in favor. Steffen and I discussed further and agreed to maintain the TESLA bootstrapping a standalone draft. MEU: agree. A main reason is that we believe that it is anyway too soon for a draft bis for MIKEY. The TESLA bootstrapping is very modular and can constitute a contained RFC. Also, having a bis would open up the question of adding there existing things like DHHMAC, and the MBMS extension (which definitely can't wait). At the time being, there exists 4 documents dealing with MIKEY and extensions (MIKEY RFC, DHHMAC, MBMS extension, TESLA bootstrapping). Let's assume that in the future more extensions are being defined. Then we have again the problem of multiple MIKEY documents. We might in that case consider what to do, for example we could write an Info RFC that links the different pieces together, which has also the advantage that it is more easy to keep updated compared to add changes in MIKEY. MEU:> Given time and resource constraints, I share your view that MIKEY-bis draft may be too early in time. Let's mature first the other MIKEY dos first. Still, I would consider such a long-term effort useful, to consolidate the existing material within one document. Until the time is right for this, let me suggest an interim yez more lean approach: Instead of the MIKEY-bis draft, let's create an informational RFC, such as "MIKEY: Overview and Applications". This rather short document would summarize the existing (known) work by giving an overview of the various MIKEY documents and their scope and applications. The new document should not reiterate the specs; just provide some summary and make pointers to the docs; technical spec content is left subject to the various MIKEY docs. Once time will have arrived, and we all feel that MIKEY has matured, then the informational RFC can be superseded by the MIKEY-bis RFC. Does this make sense? Martin. _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Nov 29 09:29:35 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24627 for ; Mon, 29 Nov 2004 09:29:35 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 388D48C8C1; Mon, 29 Nov 2004 09:29:36 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 6F2098C812 for ; Mon, 29 Nov 2004 09:29:34 -0500 (EST) Received: (qmail 64880 invoked by uid 3269); 29 Nov 2004 14:29:34 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 64875 invoked from network); 29 Nov 2004 14:29:34 -0000 Received: from us1.net2.com.br (64.246.26.27) by klesh.pair.com with SMTP; 29 Nov 2004 14:29:34 -0000 Received: (qmail 13498 invoked by uid 513); 29 Nov 2004 14:23:06 -0000 Received: from atv@alan.pro.br by us1.net2.com.br by uid 101 with qmail-scanner-1.22 (f-prot: 4.4.1/3.14.11. Clear:RC:1(200.157.179.240):. Processed in 0.39194 secs); 29 Nov 2004 14:23:06 -0000 Received: from unknown (HELO m1.net2.com.br) (200.157.179.240) by us1.net2.com.br with SMTP; 29 Nov 2004 14:23:06 -0000 Received: from 200.129.132.200 (SquirrelMail authenticated user atv@alan.pro.br) by m1.net2.com.br with HTTP; Mon, 29 Nov 2004 11:26:24 -0300 (BRT) Message-ID: <2996.200.129.132.200.1101738384.squirrel@m1.net2.com.br> Date: Mon, 29 Nov 2004 11:26:24 -0300 (BRT) From: "Alan Tamer Vasques" To: msec@securemulticast.org User-Agent: SquirrelMail/1.4.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Subject: [MSEC] Implementations of MSEC X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi, As the first MSEC RFCs are starting to being released, I'd like to know if there are already commercial implementations of MSEC suite of protocols. If the answer is yes, which are them? Thanks in advance. Best regards, Alan Tamer Vasques http://www.alan.pro.br/ _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Nov 29 09:59:29 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27061 for ; Mon, 29 Nov 2004 09:59:28 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 6C4AC8D880; Mon, 29 Nov 2004 09:59:29 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 0D0858D85D for ; Mon, 29 Nov 2004 09:59:29 -0500 (EST) Received: (qmail 69560 invoked by uid 3269); 29 Nov 2004 14:59:28 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 69552 invoked from network); 29 Nov 2004 14:59:27 -0000 Received: from penguin.ericsson.se (193.180.251.47) by klesh.pair.com with SMTP; 29 Nov 2004 14:59:27 -0000 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iATEw7h5017906; Mon, 29 Nov 2004 15:58:07 +0100 (MET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Nov 2004 15:58:07 +0100 Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Nov 2004 15:58:07 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Nov 2004 15:58:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <0CDAE977A7172A40A2A3A1C20C12BD653ADE06@esealmw106.eemea.ericsson.se> Thread-Topic: MUST/MAY discard unverifiable (draft-ietf-msec-srtp-tesla-02.txt) Thread-Index: AcTVngaeJGZzUBp/R8emHYY6v+F19QAhNjUg From: "Elisabetta Carrara (KI/EAB)" To: "Bob Briscoe" , "Mark Baugher" X-OriginalArrivalTime: 29 Nov 2004 14:58:07.0054 (UTC) FILETIME=[D5B0A6E0:01C4D623] Cc: Atul.Sharma@nokia.com, "Dondeti, Lakshminath" , msec@securemulticast.org Subject: [MSEC] RE: MUST/MAY discard unverifiable (draft-ietf-msec-srtp-tesla-02.txt) X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: quoted-printable Bob, I would personally read the MAY that you propose in the=20 sentence as if the checking of the safety condition could=20 be skipped completely.=20 I feel comfortable only with a MUST. If the rx's policy wants to do something else, well=20 the protocol cannot force him otherwise (as it is local=20 matter), as you say. /E >-----Original Message----- >From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] >Sent: den 29 november 2004 00:00 >To: Mark Baugher; Elisabetta Carrara (KI/EAB) >Cc: msec@securemulticast.org; Atul.Sharma@nokia.com; Dondeti, >Lakshminath >Subject: MUST/MAY discard unverifiable >(draft-ietf-msec-srtp-tesla-02.txt) > > >Mark, Elisabetta, > >Returning to this subject after a long break (purely my fault)... > >At 19:24 14/09/2004, Mark Baugher wrote: > >>On Sep 14, 2004, at 11:55 AM, Mark Baugher wrote: >> >>>On Sep 14, 2004, at 9:58 AM, Bob Briscoe wrote: >>>>>5/ Discard if a packet cannot be authenticated should be optional >>>>=3D Agreed >>> >>>I did not sign up for this one - or at least I did not mean to. I'd >>>like to discuss this some more. Personally, I want to limit options >>>wherever possible and this is the second option (including making the >>>group [MAC] optional) >>>that you have proposed. I don't think we necessarily want=20 >to add this >>>particular option and would like to hear what others have to say on >>>the matter. >>> >>>thanks, Mark > >If a packet cannot be authenticated, whether to drop it or not can be=20 >chosen unilaterally by the receiver. It isn't a *protocol*=20 >option. It is a=20 >receiver choice. If it cannot be verified, it doesn't complicate the=20 >protocol to say the receiver MAY rather than MUST drop a packet. > >My view remains that it is over-prescriptive to tell a=20 >receiver it MUST=20 >drop a packet. Indeed, whatever we say in the RFC,=20 >applications will be=20 >free to do what they like. The balance between the value of=20 >rendering-quality and authenticity is up to the application, not us. > >Quoting the RFC Editor's policy: >"...Imperatives ... MUST only be used where it is actually=20 >required for=20 >interoperation or to limit behavior which has potential for=20 >causing harm=20 >(e.g., limiting retransmissions). For example, they must not=20 >be used to try=20 >to impose a particular method on implementors where the method is not=20 >required for interoperability." > > --- > >But there *is* a potential protocol issue here (which applies to all=20 >authentication protocols, IPsec as much as TESLA).=20 >Application(s) 'above'=20 >verification in the stack (e.g. rendering, congestion control,=20 >intrustion=20 >detection) may need to distinguish the difference between=20 >discard due to: >- congestion/corruption >- proven malicious attack >- indeterminate authentication (in TESLA due to network delay=20 >*or* an attack) > >For intrustion detection, these can be distinguished by=20 >logging different=20 >types of security event, as specified in the srtp-tesla draft. > >But, congestion control usually works purely on packet=20 >delivery (I don't=20 >think SRTP says anything about whether verification is done=20 >before or after=20 >congestion control). > >Yes, proven attack packets should be discarded (after=20 >logging), because=20 >they aren't part of the stream sent by the genuine sender. But=20 >if packets=20 >can't be verified they shouldn't necessarily just be discarded: >- If they were genuine packets, congestion control will=20 >respond wrongly if=20 >they *are* discarded >- If they were attack packets, congestion control will respond=20 >wrongly if=20 >they *aren't* discarded. > >Of course, the same is true of rendering: >- If they were genuine packets, rendering will respond wrongly if they=20 >*are* discarded >- If they were attack packets, rendering will respond wrongly if they=20 >*aren't* discarded. > >So, in order not to complicate the spec, I still maintain we=20 >should say (in=20 >section 4.4) > > >"...If the safe condition does not hold, the packet MAY [not MUST] be > discarded, and the event SHOULD be logged." > > > >In these cases, it is up to the receiving system to decide=20 >whether such=20 >packets are more likely to be genuine or malicious, choosing=20 >whether to use=20 >or discard the packet. With consequent consistent effects on=20 >congestion=20 >control, rendering etc. > >There is a natural tendency for security people to be=20 >conservative under=20 >uncertainty. But we have to remember security must be balanced=20 >by usability. > >Bob > >_______________________________________________________________ >_____________ >Bob Briscoe, Networks Research=20 >Centre, BT Research >B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. =20 >+44 1473 645196=20 > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Nov 29 10:34:29 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01922 for ; Mon, 29 Nov 2004 10:34:28 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id F087B8D9BB; Mon, 29 Nov 2004 10:33:04 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id B0B678D9AA for ; Mon, 29 Nov 2004 10:33:02 -0500 (EST) Received: (qmail 76145 invoked by uid 3269); 29 Nov 2004 15:33:02 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 76142 invoked from network); 29 Nov 2004 15:33:02 -0000 Received: from penguin.ericsson.se (193.180.251.47) by klesh.pair.com with SMTP; 29 Nov 2004 15:33:02 -0000 Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iATFX0h7026551; Mon, 29 Nov 2004 16:33:01 +0100 (MET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Nov 2004 16:33:00 +0100 Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Nov 2004 16:33:00 +0100 Content-class: urn:content-classes:message Subject: RE: [MSEC] TESLA bootstrapping in MIKEY MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Nov 2004 16:32:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <0CDAE977A7172A40A2A3A1C20C12BD653ADE10@esealmw106.eemea.ericsson.se> Thread-Topic: [MSEC] TESLA bootstrapping in MIKEY Thread-Index: AcTWHPheJVxA5E81R2KOrchf9z6lLgAC4/oQ From: "Elisabetta Carrara (KI/EAB)" To: "Euchner Martin" X-OriginalArrivalTime: 29 Nov 2004 15:33:00.0238 (UTC) FILETIME=[B5532EE0:01C4D628] Cc: Fries Steffen , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: quoted-printable Hi Martin,=20 I personally feel that the time is still quite early also=20 for such Informational RFC. In addition, there are not that=20 many pieces around MIKEY, which would motivate such tight=20 tracking.=20 I think that the suggestion could be valid if more additions=20 are popping out. Cheers /E >-----Original Message----- >From: Euchner Martin [mailto:martin.euchner@siemens.com] >Sent: den 29 november 2004 15:03 >To: Elisabetta Carrara (KI/EAB); msec@securemulticast.org; Euchner >Martin >Cc: Fries Steffen >Subject: RE: [MSEC] TESLA bootstrapping in MIKEY > > >No opinion against but slightly in favor. > > >Steffen and I discussed further and agreed to maintain the TESLA >bootstrapping a standalone draft.=20 > >MEU: agree. > >A main reason is that we believe that it is anyway too soon for a=20 >draft bis for MIKEY. The TESLA bootstrapping is very modular and can=20 >constitute a contained RFC. >Also, >having a bis would open up the question of adding there existing >things like DHHMAC, and the MBMS extension (which definitely can't=20 >wait). At the time being, there exists 4 documents dealing with MIKEY=20 >and extensions (MIKEY RFC, DHHMAC, MBMS extension, TESLA=20 >bootstrapping).=20 >Let's assume that in the future more extensions are being defined.=20 >Then we have again the problem of multiple MIKEY documents. We might=20 >in that case consider what to do, for example we could write=20 >an Info RFC >that links the different pieces together, which has also the advantage >that it is more easy to keep updated compared to add changes in MIKEY. > > >MEU:> Given time and resource constraints, I share your view=20 >that MIKEY-bis draft may be too early in time. Let's mature=20 >first the other MIKEY dos first. Still, I would consider such=20 >a long-term effort useful, to consolidate the existing=20 >material within one document. > >Until the time is right for this, let me suggest an interim=20 >yez more lean approach: >Instead of the MIKEY-bis draft, let's create an informational=20 >RFC, such as "MIKEY: Overview and Applications". This rather=20 >short document would summarize the existing (known) work by=20 >giving an overview of the various MIKEY documents and their=20 >scope and applications. The new document should not reiterate=20 >the specs; just provide some summary and make pointers to the=20 >docs; technical spec content is left subject to the various MIKEY docs. > > >Once time will have arrived, and we all feel that MIKEY has=20 >matured, then the informational RFC can be superseded by the=20 >MIKEY-bis RFC. > >Does this make sense? > > >Martin. > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Nov 30 11:23:30 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03495 for ; Tue, 30 Nov 2004 11:23:30 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 4728A8C6A5; Tue, 30 Nov 2004 11:23:32 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 7DDE68BFC8 for ; Tue, 30 Nov 2004 11:23:31 -0500 (EST) Received: (qmail 74923 invoked by uid 3269); 30 Nov 2004 16:23:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 74920 invoked from network); 30 Nov 2004 16:23:31 -0000 Received: from zcars04f.nortelnetworks.com (47.129.242.57) by klesh.pair.com with SMTP; 30 Nov 2004 16:23:31 -0000 Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iAUGNEh29383; Tue, 30 Nov 2004 11:23:14 -0500 (EST) Received: from [47.16.67.20] (atices-1.us.nortel.com [47.16.67.20]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id WKL3LCDL; Tue, 30 Nov 2004 11:23:14 -0500 Message-ID: <41AC9E70.4080101@nortelnetworks.com> Date: Tue, 30 Nov 2004 11:23:12 -0500 From: "Dondeti, Lakshminath" Organization: Nortel Networks User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Briscoe Subject: Re: [MSEC] MUST/MAY discard unverifiable (draft-ietf-msec-srtp-tesla- 02.txt) References: <5.2.1.1.2.20041127121743.03638730@pop3.jungle.bt.co.uk> In-Reply-To: <5.2.1.1.2.20041127121743.03638730@pop3.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Atul.Sharma@nokia.com, elisabetta.carrara@ericsson.com, Mark Baugher , 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 I would use - as you also mention - IPsec RFCs as a guideline. RFC2402 says "MUST discard" if the ICV test fails. In the same spirit, if 'TESLA verifications' fail, the MSEC-SRTP-TESLA spec should say that the receiver MUST discard packets. The other guideline I would cite is from Section 4.4 of RFC 2401, "compliant implementations need not match details of this model as presented, but the external behavior of such implementations must be mappable to the externally observable characteristics of this model." Given all that, and if the TESLA spec says "MAY" then some receivers might end up with a different copy of the stream than others, with all implementations being "RFC-compliant"; and that is unacceptable! regards, Lakshminath Bob Briscoe wrote: > Mark, Elisabetta, > > Returning to this subject after a long break (purely my fault)... > > At 19:24 14/09/2004, Mark Baugher wrote: > > >On Sep 14, 2004, at 11:55 AM, Mark Baugher wrote: > > > >>On Sep 14, 2004, at 9:58 AM, Bob Briscoe wrote: > >>>>5/ Discard if a packet cannot be authenticated should be optional > >>>= Agreed > >> > >>I did not sign up for this one - or at least I did not mean to. I'd > >>like to discuss this some more. Personally, I want to limit options > >>wherever possible and this is the second option (including making the > >>group [MAC] optional) > >>that you have proposed. I don't think we necessarily want to add this > >>particular option and would like to hear what others have to say on > >>the matter. > >> > >>thanks, Mark > > If a packet cannot be authenticated, whether to drop it or not can be > chosen unilaterally by the receiver. It isn't a *protocol* option. It > is a > receiver choice. If it cannot be verified, it doesn't complicate the > protocol to say the receiver MAY rather than MUST drop a packet. > > My view remains that it is over-prescriptive to tell a receiver it MUST > drop a packet. Indeed, whatever we say in the RFC, applications will be > free to do what they like. The balance between the value of > rendering-quality and authenticity is up to the application, not us. > > Quoting the RFC Editor's policy: > "...Imperatives ... MUST only be used where it is actually required for > interoperation or to limit behavior which has potential for causing harm > (e.g., limiting retransmissions). For example, they must not be used > to try > to impose a particular method on implementors where the method is not > required for interoperability." > > --- > > But there *is* a potential protocol issue here (which applies to all > authentication protocols, IPsec as much as TESLA). Application(s) 'above' > verification in the stack (e.g. rendering, congestion control, intrustion > detection) may need to distinguish the difference between discard due to: > - congestion/corruption > - proven malicious attack > - indeterminate authentication (in TESLA due to network delay *or* an > attack) > > For intrustion detection, these can be distinguished by logging different > types of security event, as specified in the srtp-tesla draft. > > But, congestion control usually works purely on packet delivery (I don't > think SRTP says anything about whether verification is done before or > after > congestion control). > > Yes, proven attack packets should be discarded (after logging), because > they aren't part of the stream sent by the genuine sender. But if packets > can't be verified they shouldn't necessarily just be discarded: > - If they were genuine packets, congestion control will respond > wrongly if > they *are* discarded > - If they were attack packets, congestion control will respond wrongly if > they *aren't* discarded. > > Of course, the same is true of rendering: > - If they were genuine packets, rendering will respond wrongly if they > *are* discarded > - If they were attack packets, rendering will respond wrongly if they > *aren't* discarded. > > So, in order not to complicate the spec, I still maintain we should > say (in > section 4.4) > > > "...If the safe condition does not hold, the packet MAY [not MUST] be > discarded, and the event SHOULD be logged." > > > > In these cases, it is up to the receiving system to decide whether such > packets are more likely to be genuine or malicious, choosing whether > to use > or discard the packet. With consequent consistent effects on congestion > control, rendering etc. > > There is a natural tendency for security people to be conservative under > uncertainty. But we have to remember security must be balanced by > usability. > > Bob > > ____________________________________________________________________________ > > Bob Briscoe, Networks Research Centre, BT > Research > B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 > > > _______________________________________________ > 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