From msec-bounces@securemulticast.org Mon Dec 04 19:26:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrO98-0004RM-PB for msec-archive@lists.ietf.org; Mon, 04 Dec 2006 19:26:54 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrO8m-0001Wt-Ok for msec-archive@lists.ietf.org; Mon, 04 Dec 2006 19:26:54 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 146E32CAB4; Mon, 4 Dec 2006 19:26: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 13EDD2CBCB for ; Mon, 4 Dec 2006 19:26:22 -0500 (EST) Received: (qmail 69814 invoked by uid 3269); 5 Dec 2006 00:26:22 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 69811 invoked from network); 5 Dec 2006 00:26:22 -0000 Received: from mailwash15.pair.com (66.39.2.15) by klesh.pair.com with SMTP; 5 Dec 2006 00:26:22 -0000 Received: from localhost (localhost [127.0.0.1]) by mailwash15.pair.com (Postfix) with SMTP id 14E6FE9D97 for ; Mon, 4 Dec 2006 19:26:22 -0500 (EST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mailwash15.pair.com (Postfix) with ESMTP id 89B92E9D80 for ; Mon, 4 Dec 2006 19:26:21 -0500 (EST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 04 Dec 2006 16:26:20 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB50QJan005926; Mon, 4 Dec 2006 16:26:19 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB50Q6jA010422; Mon, 4 Dec 2006 16:26:15 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 16:26:04 -0800 Received: from [192.168.0.11] ([10.21.113.83]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 16:26:03 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <3DBA074C-A19D-4DEF-897A-6F8C088F82C3@cisco.com> From: Mark Baugher Date: Mon, 4 Dec 2006 16:26:02 -0800 To: Steffen Fries , dignjatic@polycom.com X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 05 Dec 2006 00:26:03.0937 (UTC) FILETIME=[F2B69910:01C71803] Authentication-Results: sj-dkim-2; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: msec Subject: Re: [MSEC] I-D ACTION:draft-ietf-msec-mikey-applicability-03.txt X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Thanks for writing this I-D. I read it quickly and have several comments. 1. Section 3.2 "An advantage of this approach are that the usage of self-signed certificates can avoid PKI." By itself, self-signed certificates don't really do that. It is necessary to employ some additional kind of authentication or a ceremony where the users accept each others' authenticators. In some cases, additional information needs to be exchanged such as the fingerprint in comedia tls or the zid in zphone. 2. Section 3.6 "5. Provide liveliness tests when involved parties do not have a reliable clock" I have not yet read this draft but I think it addresses one of my biggest concerns about MIKEY for Internet operation - MIKEY requires synchronized clocks. Of course, you cannot do this and preserve a one or two message exchange. 3. From Section 4.3,"...To achieve this, MBMS uses a three-level key management, to distribute group keys to the clients, and be able to re-key by pushing down a new group key." In msec, RFC 4046 describes and recommends some ways for doing all of this. 4. From Section 5 Selection and interworking of MIKEY modes Unlike IKE, many people (viz. rtpsec) think there needs to be one mode for Internet operation of certain applications such as voip where there is no global infrastructure. Authenticated Diffie- Hellman (zphone) and self-signed certs (DTLS) are two approaches to this problem. Other points. o SSRC collisions are a major problem when sharing SRTP keys. I think the only secure way to do this is with a one-key-per-sender policy. Otherwise, SSRC collisions are an avenue of attack on the system. o Forking and early media are probably impossible to solve together in a one or two message protocol. Mark On Dec 4, 2006, at 12:50 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multicast Security Working Group > of the IETF. > > Title : On the applicability of various MIKEY modes and extensions > Author(s) : S. Fries, D. Ignjatic > Filename : draft-ietf-msec-mikey-applicability-03.txt > Pages : 35 > Date : 2006-12-4 > > Multimedia Internet Keying - MIKEY - is a key management protocol > that can be used for real-time applications. In particular, it has > been defined focusing on the support of the Secure Real-time > Transport Protocol. MIKEY itself defines four key distribution > methods. Moreover, it is defined to allow extensions of the > protocol. As MIKEY becomes more and more accepted, extensions > to the > base protocol arose, especially in terms of additional key > distribution methods, but also in terms of payload enhancements. > > This document provides an overview about MIKEY in general as > well as > the existing extensions in MIKEY, which have been defined or are in > the process of definition. It is intended as additional source of > information for developers or architects to provide more insight in > use case scenarios and motivations as well as advantages and > disadvantages for the different key distribution schemes. The use > cases discussed in this document are strongly related to dedicated > SIP call scenarios providing challenges for key management in > general > beyond them media before SDP answer, forking, and shared key > conferencing. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey- > applicability-03.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-msec-mikey-applicability-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-msec-mikey-applicability-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2006-12-4140742.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Dec 06 08:03:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrwRB-00052R-W8 for msec-archive@lists.ietf.org; Wed, 06 Dec 2006 08:03:50 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrwRA-00085r-FZ for msec-archive@lists.ietf.org; Wed, 06 Dec 2006 08:03:49 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 20F8F2CFC7; Wed, 6 Dec 2006 08:03: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 B44B22CB32 for ; Wed, 6 Dec 2006 08:02:48 -0500 (EST) Received: (qmail 73027 invoked by uid 3269); 6 Dec 2006 13:02:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 73024 invoked from network); 6 Dec 2006 13:02:48 -0000 Received: from mailwash15.pair.com (66.39.2.15) by klesh.pair.com with SMTP; 6 Dec 2006 13:02:48 -0000 Received: from localhost (localhost [127.0.0.1]) by mailwash15.pair.com (Postfix) with SMTP id D2217E9D39 for ; Wed, 6 Dec 2006 08:02:48 -0500 (EST) Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) by mailwash15.pair.com (Postfix) with ESMTP id 595EEE9D31 for ; Wed, 6 Dec 2006 08:02:48 -0500 (EST) Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id kB6D2hlB003472; Wed, 6 Dec 2006 14:02:43 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id kB6D2hc8021344; Wed, 6 Dec 2006 14:02:43 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Dec 2006 14:02:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Dec 2006 14:02:30 +0100 Message-ID: In-Reply-To: <3DBA074C-A19D-4DEF-897A-6F8C088F82C3@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-msec-mikey-applicability-03.txt Thread-Index: AccYA/4sz5NAzMfLStCoJ0npjcRI3QBMPwTg From: "Fries, Steffen" To: "Mark Baugher" , X-OriginalArrivalTime: 06 Dec 2006 13:02:43.0258 (UTC) FILETIME=[D13AF9A0:01C71936] Cc: msec Subject: Re: [MSEC] I-D ACTION:draft-ietf-msec-mikey-applicability-03.txt X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Hi Mark, thanks for the comments. I made some notes inline. Regards Steffen > Thanks for writing this I-D. I read it quickly and have > several comments. Great, if it is helpful. > 1. Section 3.2 "An advantage of this approach are that the > usage of self-signed certificates can avoid PKI." > > By itself, self-signed certificates don't really do that. It > is necessary to employ some additional kind of authentication > or a ceremony where the users accept each others' > authenticators. In some cases, additional information needs > to be exchanged such as the fingerprint in comedia tls or the > zid in zphone. Agreed, I will add a comment to this. > > 2. Section 3.6 > "5. Provide liveliness tests when involved parties do not have a > reliable clock" > > I have not yet read this draft but I think it addresses one > of my biggest concerns about MIKEY for Internet operation - > MIKEY requires synchronized clocks. Of course, you cannot do > this and preserve a one or two message exchange. The draft has not been submitted regarding SAML assisted DH. I basically took the information from the 2 presentations in MSEC and a talk to Bob. Nevertheless, I thought the approach is interesting and therefore I kept the information in here. > 3. From Section 4.3,"...To achieve this, MBMS uses a > three-level key management, to distribute group keys to the > clients, and be able to re-key by pushing down a new group key." > > In msec, RFC 4046 describes and recommends some ways for > doing all of this. We were just reflecting what the RFC4563 is about. > 4. From Section 5 Selection and interworking of MIKEY modes > > Unlike IKE, many people (viz. rtpsec) think there needs to be > one mode for Internet operation of certain applications such > as voip where there is no global infrastructure. > Authenticated Diffie- Hellman (zphone) and self-signed certs > (DTLS) are two approaches to this problem. Well, I'm not sure if it is manageable with just one mode given the multitude of key management approaches we have for voice I would be glad if we could bring it down to 3. > Other points. > > o SSRC collisions are a major problem when sharing SRTP keys. > I think the only secure way to do this is with a > one-key-per-sender policy. Otherwise, SSRC collisions are an > avenue of attack on the system. Agreed, this would be the best way in terms of security. > o Forking and early media are probably impossible to solve > together in a one or two message protocol. You are probably right here. From my point of view at least 3 messages are necessary. > > Mark > On Dec 4, 2006, at 12:50 PM, Internet-Drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Multicast Security Working > Group of > > the IETF. > > > > Title : On the applicability of various MIKEY > modes and extensions > > Author(s) : S. Fries, D. Ignjatic > > Filename : draft-ietf-msec-mikey-applicability-03.txt > > Pages : 35 > > Date : 2006-12-4 > > > > Multimedia Internet Keying - MIKEY - is a key management protocol > > that can be used for real-time applications. In > particular, it has > > been defined focusing on the support of the Secure Real-time > > Transport Protocol. MIKEY itself defines four key distribution > > methods. Moreover, it is defined to allow extensions of the > > protocol. As MIKEY becomes more and more accepted, > extensions to > > the > > base protocol arose, especially in terms of additional key > > distribution methods, but also in terms of payload enhancements. > > > > This document provides an overview about MIKEY in > general as well > > as > > the existing extensions in MIKEY, which have been > defined or are in > > the process of definition. It is intended as additional > source of > > information for developers or architects to provide more > insight in > > use case scenarios and motivations as well as advantages and > > disadvantages for the different key distribution > schemes. The use > > cases discussed in this document are strongly related to > dedicated > > SIP call scenarios providing challenges for key management in > > general > > beyond them media before SDP answer, forking, and shared key > > conferencing. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey- > > applicability-03.txt > > > > To remove yourself from the I-D Announcement list, send a > message to > > i-d-announce-request@ietf.org with the word unsubscribe in > the body of > > the message. > > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username "anonymous" and a password of your e-mail address. After > > logging in, type "cd internet-drafts" and then "get > > draft-ietf-msec-mikey-applicability-03.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE > /internet-drafts/draft-ietf-msec-mikey-applicability-03.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > Content-Type: text/plain > > Content-ID: <2006-12-4140742.I-D@ietf.org> > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/i-d-announce > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@ietf.org Fri Dec 08 06:46:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GseAP-00071D-3m; Fri, 08 Dec 2006 06:45:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GseAN-000710-H6 for msec@ietf.org; Fri, 08 Dec 2006 06:45:23 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GseAM-0006fB-5B for msec@ietf.org; Fri, 08 Dec 2006 06:45:23 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kB8BjKZu024417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 8 Dec 2006 03:45:21 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-217.qualcomm.com [10.50.76.217]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kB8BjDB7025103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 8 Dec 2006 03:45:17 -0800 Message-Id: <7.0.1.0.2.20061208034158.043e7e28@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 08 Dec 2006 03:45:07 -0800 To: msec@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Russ Housley Subject: [MSEC] MSEC WG San Diego mtg minutes X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Folks, With apologies for the delay and thanks to Sheela and Steffen, here are the minutes from the San Diego meeting. Please review and let me know if anything is amiss or needs to be corrected. http://www3.ietf.org/proceedings/06nov/minutes/msec.txt Thanks, Lakshminath PS: I am on vacation in India and so the response times are somewhat delayed until mid December. _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Fri Dec 08 06:46:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GseAP-00071D-3m; Fri, 08 Dec 2006 06:45:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GseAN-000710-H6 for msec@ietf.org; Fri, 08 Dec 2006 06:45:23 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GseAM-0006fB-5B for msec@ietf.org; Fri, 08 Dec 2006 06:45:23 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kB8BjKZu024417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 8 Dec 2006 03:45:21 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-217.qualcomm.com [10.50.76.217]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kB8BjDB7025103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 8 Dec 2006 03:45:17 -0800 Message-Id: <7.0.1.0.2.20061208034158.043e7e28@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 08 Dec 2006 03:45:07 -0800 To: msec@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Russ Housley Subject: [MSEC] MSEC WG San Diego mtg minutes X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Folks, With apologies for the delay and thanks to Sheela and Steffen, here are the minutes from the San Diego meeting. Please review and let me know if anything is amiss or needs to be corrected. http://www3.ietf.org/proceedings/06nov/minutes/msec.txt Thanks, Lakshminath PS: I am on vacation in India and so the response times are somewhat delayed until mid December. _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Mon Dec 18 17:27:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwQxI-0001P6-40; Mon, 18 Dec 2006 17:27:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwQxH-0001P1-7p for msec@ietf.org; Mon, 18 Dec 2006 17:27:31 -0500 Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwQxD-00075B-T8 for msec@ietf.org; Mon, 18 Dec 2006 17:27:31 -0500 Received: by nf-out-0910.google.com with SMTP id h2so2045483nfe for ; Mon, 18 Dec 2006 14:27:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=IVKIGivgSl9FVWrfdB6PqvSFDllbofAo6ryo2L4u0fnMjAhgd/zRrquknRUt7DCIOlJqSof++EOzFVXbOwZ41/W8D4i038VpslvfNsPvrZnOEeXgTgarA89wTUPdPk0+f26mdcw5A7/23VO2FCFSv7qXNr638bT1k06NZmC3Ehs= Received: by 10.82.113.6 with SMTP id l6mr715219buc.1166480846396; Mon, 18 Dec 2006 14:27:26 -0800 (PST) Received: by 10.82.148.6 with HTTP; Mon, 18 Dec 2006 14:27:26 -0800 (PST) Message-ID: <8ba53040612181427h43e1427l9cd4ee762ae33120@mail.gmail.com> Date: Mon, 18 Dec 2006 17:27:26 -0500 From: "Eugene Chin" To: "Fries, Steffen" In-Reply-To: MIME-Version: 1.0 References: <8ba53040611030421r74a4240ex86f432d81ed127b9@mail.gmail.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: msec@ietf.org Subject: [MSEC] Re: draft-ietf-msec-mikey-ecc-01.txt X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1735384106==" Errors-To: msec-bounces@ietf.org --===============1735384106== Content-Type: multipart/alternative; boundary="----=_Part_26670_33258806.1166480846305" ------=_Part_26670_33258806.1166480846305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I would very much prefer that you submit a new draft for adding ECGDSA to MIKEY. In the current working copy of the draft, I've addressed already the comments from the last meeting. That is, to allow for SHA-2 to be used instead of just allowing SHA-1 only, and some minor editorial changes. It seems the path to WGLC is clear now, and do not want to add another algorithm. Can others please comment as well? On 11/3/06, Fries, Steffen wrote: > > HI Eugene, > > if you need further information on ECGDSA, just let me know. > > Ciao > Steffen > > ------------------------------ > *From:* Eugene Chin [mailto:eugene.chin@gmail.com] > *Sent:* Friday, November 03, 2006 1:21 PM > *To:* Fries, Steffen > *Cc:* msec@ietf.org > *Subject:* Re: draft-ietf-msec-mikey-ecc-01.txt > > Hi Steffen, > > In the comments I sent to the former version of the draft, there was > > also ECGDSA included. > > > > Oops, I appear to have missed this point from your previous comments. To > be honest, I am not familiar with ECGDSA, and will get back to you. > > Thanks, > Eugene. > > > > ------=_Part_26670_33258806.1166480846305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I would very much prefer that you submit a new draft for adding ECGDSA to MIKEY.  In the current working copy of the draft, I've addressed already the comments from the last meeting.  That is, to allow for SHA-2 to be used instead of just allowing SHA-1 only, and some minor editorial changes.  It seems the path to WGLC is clear now, and do not want to add another algorithm.

Can others please comment as well?


On 11/3/06, Fries, Steffen <steffen.fries@siemens.com> wrote:
HI Eugene,
 
if you need further information on ECGDSA, just let me know.
 
Ciao
    Steffen

From: Eugene Chin [mailto:eugene.chin@gmail.com]
Sent: Friday, November 03, 2006 1:21 PM
To: Fries, Steffen
Cc: msec@ietf.org
Subject: Re: draft-ietf-msec-mikey-ecc-01.txt

Hi Steffen,

In the comments I sent to the former version of the draft, there was also ECGDSA included.

Oops, I appear to have missed this point from your previous comments.  To be honest, I am not familiar with ECGDSA, and will get back to you.

Thanks,
Eugene.
 



------=_Part_26670_33258806.1166480846305-- --===============1735384106== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec --===============1735384106==-- From msec-bounces@ietf.org Mon Dec 18 17:27:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwQxI-0001P6-40; Mon, 18 Dec 2006 17:27:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwQxH-0001P1-7p for msec@ietf.org; Mon, 18 Dec 2006 17:27:31 -0500 Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwQxD-00075B-T8 for msec@ietf.org; Mon, 18 Dec 2006 17:27:31 -0500 Received: by nf-out-0910.google.com with SMTP id h2so2045483nfe for ; Mon, 18 Dec 2006 14:27:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=IVKIGivgSl9FVWrfdB6PqvSFDllbofAo6ryo2L4u0fnMjAhgd/zRrquknRUt7DCIOlJqSof++EOzFVXbOwZ41/W8D4i038VpslvfNsPvrZnOEeXgTgarA89wTUPdPk0+f26mdcw5A7/23VO2FCFSv7qXNr638bT1k06NZmC3Ehs= Received: by 10.82.113.6 with SMTP id l6mr715219buc.1166480846396; Mon, 18 Dec 2006 14:27:26 -0800 (PST) Received: by 10.82.148.6 with HTTP; Mon, 18 Dec 2006 14:27:26 -0800 (PST) Message-ID: <8ba53040612181427h43e1427l9cd4ee762ae33120@mail.gmail.com> Date: Mon, 18 Dec 2006 17:27:26 -0500 From: "Eugene Chin" To: "Fries, Steffen" In-Reply-To: MIME-Version: 1.0 References: <8ba53040611030421r74a4240ex86f432d81ed127b9@mail.gmail.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: msec@ietf.org Subject: [MSEC] Re: draft-ietf-msec-mikey-ecc-01.txt X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1735384106==" Errors-To: msec-bounces@ietf.org --===============1735384106== Content-Type: multipart/alternative; boundary="----=_Part_26670_33258806.1166480846305" ------=_Part_26670_33258806.1166480846305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I would very much prefer that you submit a new draft for adding ECGDSA to MIKEY. In the current working copy of the draft, I've addressed already the comments from the last meeting. That is, to allow for SHA-2 to be used instead of just allowing SHA-1 only, and some minor editorial changes. It seems the path to WGLC is clear now, and do not want to add another algorithm. Can others please comment as well? On 11/3/06, Fries, Steffen wrote: > > HI Eugene, > > if you need further information on ECGDSA, just let me know. > > Ciao > Steffen > > ------------------------------ > *From:* Eugene Chin [mailto:eugene.chin@gmail.com] > *Sent:* Friday, November 03, 2006 1:21 PM > *To:* Fries, Steffen > *Cc:* msec@ietf.org > *Subject:* Re: draft-ietf-msec-mikey-ecc-01.txt > > Hi Steffen, > > In the comments I sent to the former version of the draft, there was > > also ECGDSA included. > > > > Oops, I appear to have missed this point from your previous comments. To > be honest, I am not familiar with ECGDSA, and will get back to you. > > Thanks, > Eugene. > > > > ------=_Part_26670_33258806.1166480846305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I would very much prefer that you submit a new draft for adding ECGDSA to MIKEY.  In the current working copy of the draft, I've addressed already the comments from the last meeting.  That is, to allow for SHA-2 to be used instead of just allowing SHA-1 only, and some minor editorial changes.  It seems the path to WGLC is clear now, and do not want to add another algorithm.

Can others please comment as well?


On 11/3/06, Fries, Steffen <steffen.fries@siemens.com> wrote:
HI Eugene,
 
if you need further information on ECGDSA, just let me know.
 
Ciao
    Steffen

From: Eugene Chin [mailto:eugene.chin@gmail.com]
Sent: Friday, November 03, 2006 1:21 PM
To: Fries, Steffen
Cc: msec@ietf.org
Subject: Re: draft-ietf-msec-mikey-ecc-01.txt

Hi Steffen,

In the comments I sent to the former version of the draft, there was also ECGDSA included.

Oops, I appear to have missed this point from your previous comments.  To be honest, I am not familiar with ECGDSA, and will get back to you.

Thanks,
Eugene.
 



------=_Part_26670_33258806.1166480846305-- --===============1735384106== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec --===============1735384106==-- From msec-bounces@ietf.org Tue Dec 19 02:52:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwZmC-0004WF-5K; Tue, 19 Dec 2006 02:52:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwZmA-0004Si-MS for msec@ietf.org; Tue, 19 Dec 2006 02:52:38 -0500 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwZm7-0006IX-6m for msec@ietf.org; Tue, 19 Dec 2006 02:52:38 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id kBJ7qVtQ022216; Tue, 19 Dec 2006 08:52:31 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id kBJ7qVS9025313; Tue, 19 Dec 2006 08:52:31 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Dec 2006 08:52:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Dec 2006 08:52:29 +0100 Message-ID: In-Reply-To: <8ba53040612181427h43e1427l9cd4ee762ae33120@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-msec-mikey-ecc-01.txt Thread-Index: Acci87qNq8Nk0gkRTi2lOxahqA2p+gATHRAQ From: "Fries, Steffen" To: "Eugene Chin" X-OriginalArrivalTime: 19 Dec 2006 07:52:31.0195 (UTC) FILETIME=[A2F24AB0:01C72342] X-Spam-Score: 0.0 (/) X-Scan-Signature: 841b5d6ad57042632519d2198f34cc8d Cc: msec@ietf.org Subject: [MSEC] RE: draft-ietf-msec-mikey-ecc-01.txt X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1676939182==" Errors-To: msec-bounces@ietf.org This is a multi-part message in MIME format. --===============1676939182== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C72342.A2A687A6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C72342.A2A687A6 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, =20 the proposal to include ECGDSA to the ECC draft has been discussed for the 00 version (I submitted text for the draft update in 07/2005) as well as during the last IETF meeting (see also the minutes from Lakshminath), so it is not the attempt to add another algorithm during WGLC. =20 Just as a short summary of ECGDSA. It provides some advantages compared to ECDSA especially when implementation on embedded devices is targeted. As implementations are moving more and more to embedded devices, this solution may be interesting. Here just short a couple of comments to draw a picture about ECGDSA advantages: - The difference to ECDSA is that there is no need to calculate the inverse of the=20 ephemeral key k within the signature routine. This will provide performance advantages=20 on platforms were the calculation of the inverse can not be done efficently. - The ephemeral key k will be chosen randomly for every signature operation. This k must=20 not become known (not even in parts as if k and a valid signature is know, the private=20 key may be calculated). Therefore, calculating the inverse of k in ECDSA should be=20 protected against side channel attacks. This is not necessary in ECGDSA. - The calculation of the inverse of k is saved compared to ECDSA through the calculation=20 of the inverse of the private key during signature generation. This means that ECDSA=20 and ECGDSA are not compatible but the change from ECDSA to ECGDSA can be done=20 quickly. - Best of all, it has no IPRs associated with it. =20 As the ECC draft describes the extension of MIKEY with ECC algorithms, I would propose to include ECGDSA also into the ECC draft instead of submitting a seperate document. Again, the offer, if you need text for the draft or more information on ECGDSA, I will be happy to provide it. =20 Regards Steffen =20 =20 ________________________________ From: Eugene Chin [mailto:eugene.chin@gmail.com]=20 Sent: Monday, December 18, 2006 11:27 PM To: Fries, Steffen Cc: msec@ietf.org Subject: Re: draft-ietf-msec-mikey-ecc-01.txt =09 =09 I would very much prefer that you submit a new draft for adding ECGDSA to MIKEY. In the current working copy of the draft, I've addressed already the comments from the last meeting. That is, to allow for SHA-2 to be used instead of just allowing SHA-1 only, and some minor editorial changes. It seems the path to WGLC is clear now, and do not want to add another algorithm.=20 =09 Can others please comment as well? =09 =09 =09 On 11/3/06, Fries, Steffen wrote:=20 HI Eugene, =20 if you need further information on ECGDSA, just let me know. =20 Ciao Steffen ________________________________ From: Eugene Chin [mailto:eugene.chin@gmail.com] Sent: Friday, November 03, 2006 1:21 PM To: Fries, Steffen Cc: msec@ietf.org Subject: Re: draft-ietf-msec-mikey-ecc-01.txt =09 =09 =09 Hi Steffen, =09 =09 =09 In the comments I sent to the former version of the draft, there was also ECGDSA included. Oops, I appear to have missed this point from your previous comments. To be honest, I am not familiar with ECGDSA, and will get back to you.=20 =09 Thanks, Eugene. =20 ------_=_NextPart_001_01C72342.A2A687A6 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi,
 
the proposal to include ECGDSA = to the ECC=20 draft has been discussed for the 00 version (I submitted text for the = draft=20 update in 07/2005) as well as during the last IETF meeting (see also the = minutes=20 from Lakshminath), so it is not the attempt to add another algorithm = during=20 WGLC.
 
Just as a short summary of=20 ECGDSA. It  provides = some=20 advantages compared to ECDSA especially when implementation on embedded = devices=20 is targeted. As implementations are moving more and more to embedded = devices,=20 this solution may be interesting. Here just short a couple of comments = to draw a=20 picture about ECGDSA=20 advantages:
- The difference to ECDSA is = that there is no=20 need to calculate the inverse of the
   ephemeral key k within the signature routine. This will provide performance advantages =
   on platforms were the calculation of the inverse = can not be=20 done efficently.
- The=20 ephemeral key k will be chosen randomly for every signature operation. = This=20 k must=20
   not become known (not even in parts as if k and a = valid=20 signature is know, the private
 =20  key may be calculated). Therefore, calculating the inverse of k in = ECDSA=20 should be
   protected against side channel attacks. This is not = necessary in=20 ECGDSA.
- The=20 calculation of the inverse of k is saved compared to ECDSA through = the=20 calculation
   of the inverse of the = private key during  signature generation. This means that ECDSA=20
   and ECGDSA are not compatible but the change from = ECDSA to=20 ECGDSA can be done
   quickly.
- Best of=20 all, it has no IPRs associated with it.
 
As the ECC draft describes the extension of = MIKEY with ECC=20 algorithms, I would propose to include ECGDSA also into the ECC draft = instead of=20 submitting a seperate document. Again, the offer, if you need text for = the draft=20 or more information on ECGDSA, I will be happy to provide=20 it.
 
Regards
   =20 Steffen
 
 

From: Eugene Chin=20 [mailto:eugene.chin@gmail.com]
Sent: Monday, December 18, = 2006=20 11:27 PM
To: Fries, Steffen
Cc:=20 msec@ietf.org
Subject: Re:=20 draft-ietf-msec-mikey-ecc-01.txt

I would very much prefer that you submit a new draft for = adding=20 ECGDSA to MIKEY.  In the current working copy of the draft, I've=20 addressed already the comments from the last meeting.  That is, = to allow=20 for SHA-2 to be used instead of just allowing SHA-1 only, and some = minor=20 editorial changes.  It seems the path to WGLC is clear now, and = do not=20 want to add another algorithm.

Can others please comment as=20 well?


On 11/3/06, Fries,=20 Steffen <steffen.fries@siemens.com&g= t;=20 wrote:
HI=20 Eugene,
 
if you=20 need further information on ECGDSA,=20 just let me know.
 
Ciao
    Steffen

From: Eugene = Chin [mailto:eugene.chin@gmail.com]
Sent: = Friday,=20 November 03, 2006 1:21 PM
To: Fries, = Steffen
Cc: msec@ietf.org
Subject: Re:=20 draft-ietf-msec-mikey-ecc-01.txt

Hi Steffen,

In=20 the comments I sent to the former version of the draft, there = was=20 also ECGDSA = included.

Oops, I appear to have missed this point from your = previous=20 comments.  To be honest, I am not familiar with ECGDSA, and = will get=20 back to you.=20 =

Thanks,
Eugene.
 



------_=_NextPart_001_01C72342.A2A687A6-- --===============1676939182== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec --===============1676939182==-- From msec-bounces@ietf.org Tue Dec 19 02:52:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwZmC-0004WF-5K; Tue, 19 Dec 2006 02:52:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwZmA-0004Si-MS for msec@ietf.org; Tue, 19 Dec 2006 02:52:38 -0500 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwZm7-0006IX-6m for msec@ietf.org; Tue, 19 Dec 2006 02:52:38 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id kBJ7qVtQ022216; Tue, 19 Dec 2006 08:52:31 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id kBJ7qVS9025313; Tue, 19 Dec 2006 08:52:31 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Dec 2006 08:52:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Dec 2006 08:52:29 +0100 Message-ID: In-Reply-To: <8ba53040612181427h43e1427l9cd4ee762ae33120@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-msec-mikey-ecc-01.txt Thread-Index: Acci87qNq8Nk0gkRTi2lOxahqA2p+gATHRAQ From: "Fries, Steffen" To: "Eugene Chin" X-OriginalArrivalTime: 19 Dec 2006 07:52:31.0195 (UTC) FILETIME=[A2F24AB0:01C72342] X-Spam-Score: 0.0 (/) X-Scan-Signature: 841b5d6ad57042632519d2198f34cc8d Cc: msec@ietf.org Subject: [MSEC] RE: draft-ietf-msec-mikey-ecc-01.txt X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1676939182==" Errors-To: msec-bounces@ietf.org This is a multi-part message in MIME format. --===============1676939182== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C72342.A2A687A6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C72342.A2A687A6 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, =20 the proposal to include ECGDSA to the ECC draft has been discussed for the 00 version (I submitted text for the draft update in 07/2005) as well as during the last IETF meeting (see also the minutes from Lakshminath), so it is not the attempt to add another algorithm during WGLC. =20 Just as a short summary of ECGDSA. It provides some advantages compared to ECDSA especially when implementation on embedded devices is targeted. As implementations are moving more and more to embedded devices, this solution may be interesting. Here just short a couple of comments to draw a picture about ECGDSA advantages: - The difference to ECDSA is that there is no need to calculate the inverse of the=20 ephemeral key k within the signature routine. This will provide performance advantages=20 on platforms were the calculation of the inverse can not be done efficently. - The ephemeral key k will be chosen randomly for every signature operation. This k must=20 not become known (not even in parts as if k and a valid signature is know, the private=20 key may be calculated). Therefore, calculating the inverse of k in ECDSA should be=20 protected against side channel attacks. This is not necessary in ECGDSA. - The calculation of the inverse of k is saved compared to ECDSA through the calculation=20 of the inverse of the private key during signature generation. This means that ECDSA=20 and ECGDSA are not compatible but the change from ECDSA to ECGDSA can be done=20 quickly. - Best of all, it has no IPRs associated with it. =20 As the ECC draft describes the extension of MIKEY with ECC algorithms, I would propose to include ECGDSA also into the ECC draft instead of submitting a seperate document. Again, the offer, if you need text for the draft or more information on ECGDSA, I will be happy to provide it. =20 Regards Steffen =20 =20 ________________________________ From: Eugene Chin [mailto:eugene.chin@gmail.com]=20 Sent: Monday, December 18, 2006 11:27 PM To: Fries, Steffen Cc: msec@ietf.org Subject: Re: draft-ietf-msec-mikey-ecc-01.txt =09 =09 I would very much prefer that you submit a new draft for adding ECGDSA to MIKEY. In the current working copy of the draft, I've addressed already the comments from the last meeting. That is, to allow for SHA-2 to be used instead of just allowing SHA-1 only, and some minor editorial changes. It seems the path to WGLC is clear now, and do not want to add another algorithm.=20 =09 Can others please comment as well? =09 =09 =09 On 11/3/06, Fries, Steffen wrote:=20 HI Eugene, =20 if you need further information on ECGDSA, just let me know. =20 Ciao Steffen ________________________________ From: Eugene Chin [mailto:eugene.chin@gmail.com] Sent: Friday, November 03, 2006 1:21 PM To: Fries, Steffen Cc: msec@ietf.org Subject: Re: draft-ietf-msec-mikey-ecc-01.txt =09 =09 =09 Hi Steffen, =09 =09 =09 In the comments I sent to the former version of the draft, there was also ECGDSA included. Oops, I appear to have missed this point from your previous comments. To be honest, I am not familiar with ECGDSA, and will get back to you.=20 =09 Thanks, Eugene. =20 ------_=_NextPart_001_01C72342.A2A687A6 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi,
 
the proposal to include ECGDSA = to the ECC=20 draft has been discussed for the 00 version (I submitted text for the = draft=20 update in 07/2005) as well as during the last IETF meeting (see also the = minutes=20 from Lakshminath), so it is not the attempt to add another algorithm = during=20 WGLC.
 
Just as a short summary of=20 ECGDSA. It  provides = some=20 advantages compared to ECDSA especially when implementation on embedded = devices=20 is targeted. As implementations are moving more and more to embedded = devices,=20 this solution may be interesting. Here just short a couple of comments = to draw a=20 picture about ECGDSA=20 advantages:
- The difference to ECDSA is = that there is no=20 need to calculate the inverse of the
   ephemeral key k within the signature routine. This will provide performance advantages =
   on platforms were the calculation of the inverse = can not be=20 done efficently.
- The=20 ephemeral key k will be chosen randomly for every signature operation. = This=20 k must=20
   not become known (not even in parts as if k and a = valid=20 signature is know, the private
 =20  key may be calculated). Therefore, calculating the inverse of k in = ECDSA=20 should be
   protected against side channel attacks. This is not = necessary in=20 ECGDSA.
- The=20 calculation of the inverse of k is saved compared to ECDSA through = the=20 calculation
   of the inverse of the = private key during  signature generation. This means that ECDSA=20
   and ECGDSA are not compatible but the change from = ECDSA to=20 ECGDSA can be done
   quickly.
- Best of=20 all, it has no IPRs associated with it.
 
As the ECC draft describes the extension of = MIKEY with ECC=20 algorithms, I would propose to include ECGDSA also into the ECC draft = instead of=20 submitting a seperate document. Again, the offer, if you need text for = the draft=20 or more information on ECGDSA, I will be happy to provide=20 it.
 
Regards
   =20 Steffen
 
 

From: Eugene Chin=20 [mailto:eugene.chin@gmail.com]
Sent: Monday, December 18, = 2006=20 11:27 PM
To: Fries, Steffen
Cc:=20 msec@ietf.org
Subject: Re:=20 draft-ietf-msec-mikey-ecc-01.txt

I would very much prefer that you submit a new draft for = adding=20 ECGDSA to MIKEY.  In the current working copy of the draft, I've=20 addressed already the comments from the last meeting.  That is, = to allow=20 for SHA-2 to be used instead of just allowing SHA-1 only, and some = minor=20 editorial changes.  It seems the path to WGLC is clear now, and = do not=20 want to add another algorithm.

Can others please comment as=20 well?


On 11/3/06, Fries,=20 Steffen <steffen.fries@siemens.com&g= t;=20 wrote:
HI=20 Eugene,
 
if you=20 need further information on ECGDSA,=20 just let me know.
 
Ciao
    Steffen

From: Eugene = Chin [mailto:eugene.chin@gmail.com]
Sent: = Friday,=20 November 03, 2006 1:21 PM
To: Fries, = Steffen
Cc: msec@ietf.org
Subject: Re:=20 draft-ietf-msec-mikey-ecc-01.txt

Hi Steffen,

In=20 the comments I sent to the former version of the draft, there = was=20 also ECGDSA = included.

Oops, I appear to have missed this point from your = previous=20 comments.  To be honest, I am not familiar with ECGDSA, and = will get=20 back to you.=20 =

Thanks,
Eugene.
 



------_=_NextPart_001_01C72342.A2A687A6-- --===============1676939182== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec --===============1676939182==-- From misemploying@blackconscience.com Thu Dec 28 07:26:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzuKz-0006HP-7i for msec-archive@ietf.org; Thu, 28 Dec 2006 07:26:21 -0500 Received: from atk80.neoplus.adsl.tpnet.pl ([83.26.248.80] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GzuKs-0005UJ-2r for msec-archive@ietf.org; Thu, 28 Dec 2006 07:26:21 -0500 Message-ID: <000001c72a7a$d027e280$0100007f@localhost> From: "Sidney Wong" To: Subject: Microsoft 0ffice 2OO7 & Adobe Acrobat 8 Pro 79$ at Carlo's amazingsoft Date: Thu, 28 Dec 2006 13:25:57 +0100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: MICR0S0FT Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By MICR0S0FT MimeOLE V6.00.2800.150 X-Spam-Score: 4.9 (++++) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 All Titles 0n Sale for Holidays. Microsoft 0ffice 2OO7 79$ Adobe Acrobat 8 PR0 79$ Windows XP PR0 +SP2 49$ Adobe Premiere 2.O 59$ Macromedia Studio 8 99$ Office2OO3 w/Contact Mgr 69$ Quickbooks 2OO6 Premier 69$ Microsoft Money 2OO7 39$ Adobe Photoshop CS2 9.O 69$ Autodesk Autocad 2OO7 129$ Corel Grafix Suite X3 59$ Adobe Creative Suite CS2 149$ Adobe Illustrator CS2 59$ Microsoft Office XP PR0 49$ Macromedia Dreamweaver 8 49$ McAfee Internet Sec. 7 29$ Norton Antivirus Corp. 29$ http://rpo.fronasoft.com/ Mac Specials: Adobe Acrobat PR0 7 69$ Adobe After Effects 49$ Adobe Creative Suite 2 Premium 149$ Ableton Live 5.0.1 49$ Adobe Photoshop CS 49$ http://rpo.fronasoft.com/-software-for-mac-.php Also see our new eB00KS: Windows XP for Dummies Photoshop in a Snap Linux for dummies All for $11 and fast-download. http://rpo.fronasoft.com/ See more titles: Microsoft-Mac soft-Adobe -=New Releases=- Microsoft 0ffice 2OO7 Enterprise Normal Price: $899.00 0ur 0ffer: $79.95 U-save: $819.95 (89%) Availability: Pay-and-download instantly. http://rpo.fronasoft.com/2442.php SalesRank: #1 Average Customer Review: ***** (based on 49299 reviews) Adobe Acrobat 8.O PR0 Normal Price: $449.00 0ur 0ffer: $79.95 U-save: $369.05 (80%) Availability: Available for INSTANT-download. http://rpo.fronasoft.com/2441.php Top-ten-ranked item. Average Customer Review: ***** (based on 58271 reviews) Macromedia Studio 8 Normal Price: $999.00 0ur 0ffer: $99.95 U-save: $899.05 (90%) Availability: Can be downloaded-INSTANTLY. http://rpo.fronasoft.com/2348.php Best choice for professional. Average Customer Review: ***** (based on 17359 reviews) cp /root/.profile /mnt/root anticipate and debug problems you might encounter as you install group likes to configure their modems and system so that no matter at Local realm: GRONDAR.ZA 2. Gripe. This is done by e-mail *ONLY*! The people at Walnut Creek hardware on some systems. The most common conflict is with video Once you have installed the linux compatibility runtime libraries and classic Configure scripts and perhaps do something similar yourself. src-base: /usr/src/... misc files at the top of /usr/src Thanks to these people for comments and advice: 6.3.3. Creating the server file available to system owners outside those countries. ______________________________________________________________________ For more information on obtaining the FreeBSD distribution itself, As the patchkit swelled ever more uncomfortably with each passing day, intuitive. 10.4.9.2.3. 25 September 1995. fi too complex to explain here, but is covered well in many books in the first install the operating system, creates nearly all of the device logged in the filter rules, nothing will happen. 17.1. SUP To enable per-user quotas on a file system, add the userquota option it would start the if filter (this is mostly true: see ``Output in either one of these files. If not, LPD refuses the request. ----- end /etc/sliphome/slip.login ----- file LINT with some added comments (between []): In order for lpf to do page accounting correctly, it needs correct 1. Add your home machine, the gateway and nameservers to your commands to put a UFS filesystem on them instead, as the following Reported by: Jean-Marc Zucconi jmzcabri.obs-besancon.fr disk cannot be greater than 1024. Using the translation above, this is clash with these cards, making the COM4 port practically that we created above: For those who already have the student edition of Mathematica for DOS If there is a dependency that does not fall into either of the above the host. accounting for printer usage. FreeBSD comes with a kernel packet filter (known as IPFW), which is domain. The following tasks are purely cosmetic or represent such an exec /usr/libexec/lpr/lpf To prevent all kinds of nastiness, the terminator power is usually /sbin/ifconfig ppp0 delete on-board BIOS, which is necessary for mapping the boot device into bandwidth). diskless:\ Exabyte tape drive connected to a Sun called komodo, use: /sbin/rdump We now have to extract all the instances which define the services on are fully aware of the potential pitfalls. Not all network This section tells you how to use printers you have setup with ftp> get lex.tar.Z limit (also a design feature) you max out at fairly limited disk 18.2.5.5. Licensing Problems PATH=/usr/X11R6/bin:$PATH; export PATH || exit 2 described in the following sections assumes that if you are installing connections. This is a special case of the more general use of IPFW, Enables code to allow logging of packets through syslogd(8). receive confirmation of your bug report and a tracking number. are we using the loopback (since this is address also refers to the