From mailman-bounces@six.pairlist.net Fri Apr 1 05:05:11 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07864 for ; Fri, 1 Apr 2005 05:05:11 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 0999E8D222 for ; Fri, 1 Apr 2005 05:04:22 -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: Fri, 01 Apr 2005 05:02:21 -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 Wed Apr 6 09:46:30 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12092 for ; Wed, 6 Apr 2005 09:46:28 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 711E88C7EE; Wed, 6 Apr 2005 09:46:29 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 2FE968C747 for ; Wed, 6 Apr 2005 09:46:22 -0400 (EDT) Received: (qmail 48428 invoked by uid 3269); 6 Apr 2005 13:46:22 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 48425 invoked from network); 6 Apr 2005 13:46:21 -0000 Received: from unknown (HELO 126.com) (202.108.45.160) by klesh.pair.com with SMTP; 6 Apr 2005 13:46:21 -0000 Received: from thinker (unknown [202.115.28.189]) by smtp3 (Coremail) with SMTP id NsBSACroU0K6VUh6.1 for ; Wed, 06 Apr 2005 21:46:21 +0800 (CST) X-Originating-IP: [202.115.28.189] Date: Wed, 6 Apr 2005 21:46:29 +0800 From: "QinKe" To: "msec" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-Id: <20050406134622.2FE968C747@six.pairlist.net> Subject: [MSEC] I need your help 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="===============0462666091==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org --===============0462666091== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBhbGw6DQpJIGFtIGEgQ2hpbmVzZSBzdHVkZW50IHdobyBoYXMgc3Ryb25nIGludGVyZXN0 cyBpbiBtdWx0aWNhc3QuIE5vdyBJIGhhdmUgYSB0aG91Z2h0IGFib3V0IGtleSBtYW5hZ2VtZW50 LiBXaGVuIGl0IGNvbWVzIHRvIHRoaXMgdGhvdWdodCwgSSBoYXZlIGV2ZXIgd3JpdHRlbiB0byBQ cm9mIENhbmV0dGkgYW5kIFRob21hcyBoYXJkam9ubyBsb25nIGFnby4gTWF5YmUgdGhleSBhcmUg dG9vIGJ1c3kgdG8gcmVwbHkgbWUuIA0KTXkgdGhvdWdodCBpcyB0aGlzOiBnaXZlbiB0aGF0IG1v c3Qgb2Yga2V5IG1hbmFnZW1lbnRzIG5lZWQgdG8gc2VuZCByZS1rZXlpbmcgbWVzc2FnZXMgd2hl biBzb21lb25lIGpvaW4gaW4gb3IgbGVhdmUgYSBncm91cCwgSSB3YW50IHRvIGRlc2lnbiBzdWNo IGEgbWVjaGFuaXNtIHRoYXQgR0MgbmVlZG4ndCBzZW5kIGFueSByZS1rZXlpbmcgbWVzc2FnZXMg d2hlbiB0aGUgbWVtYmVyc2hpcCBoYXMgY2hhbmdlZC4NCkluIGRldGFpbCwgZWFjaCBsZWdpdGlt YXRlIG1lbWJlciwgZm9yIGluc3RhbmNlLCBtZW1iZXIgdV8xIGhhcyBoaXMgb3duIGtleSBrXzEs IHVfMiBoYXMga18yoa11X24gaGFzIGhpcyBvd24ga2V5IGtfbiwgYW5kIEdDIGhhcyBhIHNlcmll cyBvZiBrZXlzIGRlbm90ZWQgYXMga2dfMSxrZ18yoa1rZ19yLiBFYWNoIG1lbWJlciBzZW5kcyBo aXMga2V5IHRvIEdDIGFuZCB0aGVuIEdDIGNhbGN1bGF0ZXMgSz1mKGtfMSwga18yoa1rX24sIGtn XzEsIGtnXzKhrWtnX3IpLiBUaGUgc2VuZGVyIHVzZXMgSyB0byBlbmNyeXB0IG1lc3NhZ2VzIG5l ZWQgc2VuZGluZywgZGVub3RlZCBhcyBDPUUoSyxNKS4gQWZ0ZXIgZWFjaCBsZWdpdGltYXRlIG1l bWJlciByZWNlaXZlcyBDLCBoZSBjYW4gdXNlIGhpcyBvbmx5IGtleSBrX2kgdG8gZGVjcnlwdCB0 aGlzIGNpcGhlcnRleHQuIFdoZW4gc29tZW9uZSwgZm9yIGluc3RhbmNlIHVfaiB3aWxsIGJlIGtp Y2tlZCBvdXQsIHRoZSBHQyBvbmx5IG5lZWRzIHRvIGNhbGN1bGF0ZSBLJz1mKGtfMSwga18yoa1r XyhqLTEpLCBrXyhqKzEpoa1rX24sIGtnXzEsIGtnXzKhrWtnX3IpLiBBbHRob3VnaCB0aGUgZW5j cnlwdGlvbiBrZXkgaGFzIGNoYW5nZWQgZnJvbSBLIHRvIEsnLCBvdGhlciBtZW1iZXJzIGNhbiBh bHNvIHVzZSB0aGVpciBwcmV2aW91cyBrZXlzIHRvIGRlY3J5cHQgY2lwaGVydGV4dCBlbmNyeXB0 ZWQgYnkgSycuDQpJJ2QgbGlrZSB0byBrbm93IHdoZXRoZXIgdGhlcmUgYXJlIHNpbWlsYXIgc2No ZW1lcy4gSWYgdGhlcmUgYXJlLCB3b3VsZCB5b3UgcGxlYXNlIHRlbGxpbmcgbWUgd2hlcmUgSSBj YW4gZmluZCBzdWNoIGluZm9ybWF0aW9uPyBBbmQgaWYgbm90LCBob3cgY2FuIHdlIHJlYWxpemUg dGhpcyBwcm9wb3NpdGlvbj8gDQpUaGFuayB5b3UgYWxsIGluIGFkdmFuY2UhDQpCZXN0IHJlZ2Fy ZHMhDQoNCqGhoaGhoaGhoaGhoaGhoaFRaW5LZQ0KoaGhoaGhoaGhoaGhoaGhoXl1eHVhbnFrQDEy Ni5jb20NCqGhoaGhoaGhoaGhoaGhoaGhoaGhMjAwNS0wNC0wNg0K --===============0462666091== 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 --===============0462666091==-- From msec-bounces@securemulticast.org Wed Apr 13 11:53:08 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08019 for ; Wed, 13 Apr 2005 11:53:04 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 37C138C2EC; Wed, 13 Apr 2005 11:53:06 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id B05918C4CE for ; Wed, 13 Apr 2005 11:53:04 -0400 (EDT) Received: (qmail 72664 invoked by uid 3269); 13 Apr 2005 15:53:04 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 72661 invoked from network); 13 Apr 2005 15:53:04 -0000 Received: from m5tmail1.m5t.com (66.129.134.96) by klesh.pair.com with SMTP; 13 Apr 2005 15:53:04 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Apr 2005 11:54:01 -0400 Message-ID: <83F34964B9BBA546BF2584D46870EB9903C64C@m5tmail1.m5t.com> Thread-Topic: Potential problem with Authentication key lengths Thread-Index: AcVAQQLUkS7A4zCnT2KK/EwHbWZPnA== From: "Christian Beaulieu" To: Subject: [MSEC] Potential problem with Authentication key lengths 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="===============0779468749==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org This is a multi-part message in MIME format. --===============0779468749== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C54041.0302FFA9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C54041.0302FFA9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In section 4.2.4 of RFC 3830, it is stated that "authentication key size SHOULD be equal to the size of the hash function's output (e.g., for HMAC-SHA-1, a 160-bit authentication key is used)"=20 =20 This means that there is nothing stopping an implementation from using a key length different from 160 bits. The problem that arises from this is that there is no way for 2 peers to know which size of authentication key the other is using. =20 Shouldn't the authentication key size be a MUST rather than a SHOULD? =20 Also in draft-ietf-msec-mikey-dhhmac-11 in section 4.2 it says that "KEMAC when used in conjunction with DHHMAC SHALL not convey any encrypted data; thus Encr alg SHALL be set to 2 (NULL), Encr data len SHALL be set" =20 In RFC 3830, the NULL for the encryption algorithm for a KEMAC payload is 0. The value 2 is for AES-KW-128. =20 =20 Christian ------_=_NextPart_001_01C54041.0302FFA9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In section 4.2.4 of RFC 3830, it is stated that = “authentication key size SHOULD be equal to the size of the = hash

   function's output (e.g., for HMAC-SHA-1, = a 160-bit authentication key

   is used)” =

 

This means that there is nothing stopping an = implementation from using a key length different from 160 bits. The problem that arises from = this is that there is no way for 2 peers to know which size of authentication = key the other is using.

 

Shouldn’t the authentication key size be a MUST = rather than a SHOULD?

 

Also in draft-ietf-msec-mikey-dhhmac-11 in section = 4.2 it says that “KEMAC when used

     in conjunction with DHHMAC = SHALL not convey any encrypted data;

     thus Encr alg SHALL be set = to 2 (NULL), Encr data len SHALL be set”

 

In RFC 3830, the NULL for the encryption algorithm = for a KEMAC payload is 0. The value 2 is for = AES-KW-128.

 

 

Christian

------_=_NextPart_001_01C54041.0302FFA9-- --===============0779468749== 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 --===============0779468749==-- From msec-bounces@securemulticast.org Wed Apr 13 14:00:55 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18383 for ; Wed, 13 Apr 2005 14:00:54 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 1E3658C818; Wed, 13 Apr 2005 14:00:55 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 850998C813 for ; Wed, 13 Apr 2005 14:00:54 -0400 (EDT) Received: (qmail 96286 invoked by uid 3269); 13 Apr 2005 18:00:54 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 96276 invoked from network); 13 Apr 2005 18:00:54 -0000 Received: from albatross.ericsson.se (193.180.251.49) by klesh.pair.com with SMTP; 13 Apr 2005 18:00:54 -0000 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3DI0lfo009518; Wed, 13 Apr 2005 20:00:49 +0200 (MEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Apr 2005 20:00:44 +0200 Received: from ericsson.com ([147.214.97.151]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Apr 2005 20:00:43 +0200 Message-ID: <425D5E4D.3000304@ericsson.com> Date: Wed, 13 Apr 2005 20:00:45 +0200 From: =?windows-1252?Q?Mats_N=E4slund?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Beaulieu Subject: Re: [MSEC] Potential problem with Authentication key lengths References: <83F34964B9BBA546BF2584D46870EB9903C64C@m5tmail1.m5t.com> In-Reply-To: <83F34964B9BBA546BF2584D46870EB9903C64C@m5tmail1.m5t.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 13 Apr 2005 18:00:44.0055 (UTC) FILETIME=[B6569270:01C54052] Cc: msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 8bit Hi Christian, Note that Section 4.2.4 of RFC 3830 specifies general requirements on the functions (and also extensions to MIKEY). Section 6.2 on the other hand specifies the exact profile used. And as you may see, RFC3830 only supports the full length, 160 bits output. So, the SHOULD in section 4.2.4 is to be seen as guideline for those who like to specify new authentication profiles for MIKEY. Sect 6.2, OTOH, is a specification of the current profile. Best, /Mats + MIKEY team Christian Beaulieu wrote: > In section 4.2.4 of RFC 3830, it is stated that “authentication key size > SHOULD be equal to the size of the hash > > function's output (e.g., for HMAC-SHA-1, a 160-bit authentication key > > is used)” > > > > This means that there is nothing stopping an implementation from using a > key length different from 160 bits. The problem that arises from this is > that there is no way for 2 peers to know which size of authentication > key the other is using. > > > > Shouldn’t the authentication key size be a MUST rather than a SHOULD? > > > > Also in draft-ietf-msec-mikey-dhhmac-11 in section 4.2 it says that > “KEMAC when used > > in conjunction with DHHMAC SHALL not convey any encrypted data; > > thus Encr alg SHALL be set to 2 (NULL), Encr data len SHALL be set” > > > > In RFC 3830, the NULL for the encryption algorithm for a KEMAC payload > is 0. The value 2 is for AES-KW-128. > > > > > > Christian > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Apr 13 17:51:58 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09839 for ; Wed, 13 Apr 2005 17:51:57 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 265EC8C4DF; Wed, 13 Apr 2005 17:51:59 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 335F38C466 for ; Wed, 13 Apr 2005 17:51:58 -0400 (EDT) Received: (qmail 36352 invoked by uid 3269); 13 Apr 2005 21:51:58 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 36345 invoked from network); 13 Apr 2005 21:51:57 -0000 Received: from ithilien.qualcomm.com (129.46.51.59) by klesh.pair.com with SMTP; 13 Apr 2005 21:51:57 -0000 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j3DLpoXO000243; Wed, 13 Apr 2005 14:51:51 -0700 (PDT) Received: from [129.46.75.63] (ldondeti.na.qualcomm.com [129.46.75.63]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j3DLplIU016275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Apr 2005 14:51:47 -0700 (PDT) Message-ID: <425D9463.9010507@qualcomm.com> Date: Wed, 13 Apr 2005 14:51:31 -0700 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?windows-1252?Q?Mats_N=E4slund?= Subject: Re: [MSEC] Potential problem with Authentication key lengths References: <83F34964B9BBA546BF2584D46870EB9903C64C@m5tmail1.m5t.com> <425D5E4D.3000304@ericsson.com> In-Reply-To: <425D5E4D.3000304@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-PMX-Version: 4.7.0.111621 Cc: canetti@watson.ibm.com, msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 8bit Hi, There are two separate topics: Auth key length and MAC length. I know MAC truncation is acceptable in some cases (pl. see CFRG archive), but don't think specifying key length can be arbitrary, especially less than the block size, is a good idea. In fact, 2104 says that "The key for HMAC can be of any length (keys longer than B bytes are first hashed using H). However, less than L bytes is strongly discouraged as it would decrease the security strength of the function." L = 20 for SHA-1 as specified elsewhere in that RFC. 2104 is informational so that might be the strongest terminology Ran et. al. could use. So, I think MUST is more appropriate in Sec 4.2.4 of 3830, as in "Key length MUST be equal to or greater than the block size" (I think block size is more appropriate since it is conceivable that MIKEY might be used with cipher-based MAC algorithms in addition to hash-based ones). best, Lakshminath (My opinion as a WG contributor) Mats Näslund wrote: > Hi Christian, > > Note that Section 4.2.4 of RFC 3830 specifies general requirements on > the functions (and also extensions to MIKEY). > > Section 6.2 on the other hand specifies the exact profile used. And as > you may see, RFC3830 only supports the full length, 160 bits output. > > So, the SHOULD in section 4.2.4 is to be seen as guideline for those who > like to specify new authentication profiles for MIKEY. Sect 6.2, OTOH, > is a specification of the current profile. > > Best, > > /Mats + MIKEY team > > Christian Beaulieu wrote: > >> In section 4.2.4 of RFC 3830, it is stated that “authentication key >> size SHOULD be equal to the size of the hash >> >> function's output (e.g., for HMAC-SHA-1, a 160-bit authentication key >> >> is used)” >> >> >> >> This means that there is nothing stopping an implementation from >> using a key length different from 160 bits. The problem that arises >> from this is that there is no way for 2 peers to know which size of >> authentication key the other is using. >> >> >> >> Shouldn’t the authentication key size be a MUST rather than a SHOULD? >> >> >> >> Also in draft-ietf-msec-mikey-dhhmac-11 in section 4.2 it says that >> “KEMAC when used >> >> in conjunction with DHHMAC SHALL not convey any encrypted data; >> >> thus Encr alg SHALL be set to 2 (NULL), Encr data len SHALL be set” >> >> >> >> In RFC 3830, the NULL for the encryption algorithm for a KEMAC >> payload is 0. The value 2 is for AES-KW-128. >> >> >> >> >> >> Christian >> > > _______________________________________________ > 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 Apr 15 03:26:15 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01496 for ; Fri, 15 Apr 2005 03:26:04 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 2F2318C5F5; Fri, 15 Apr 2005 03:25:55 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id C8BA28C546 for ; Fri, 15 Apr 2005 03:25:53 -0400 (EDT) Received: (qmail 70974 invoked by uid 3269); 15 Apr 2005 07:25:53 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 70967 invoked from network); 15 Apr 2005 07:25:53 -0000 Received: from david.siemens.de (192.35.17.14) by klesh.pair.com with SMTP; 15 Apr 2005 07:25:53 -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 j3F7PiFk016503; Fri, 15 Apr 2005 09:25:45 +0200 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 j3F7Ph89031782; Fri, 15 Apr 2005 09:25:44 +0200 Received: from mchh274e.mchh.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84]) by moody.mchh.siemens.de (8.12.6/8.12.6) with ESMTP id j3F7Phnj008002; Fri, 15 Apr 2005 09:25:43 +0200 Received: by mchh274e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id <28HFGPQN>; Fri, 15 Apr 2005 09:25:26 +0200 Message-ID: <8C878B55C96F924389908D4A7384842A03A02F81@mchh2c7e.mchh.siemens.de> From: Euchner Martin To: "'Christian Beaulieu'" , msec@securemulticast.org, Euchner Martin Subject: RE: [MSEC] Potential problem with Authentication key lengths Date: Fri, 15 Apr 2005 09:25:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0542179428==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0542179428== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5418C.49E6A4AA" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5418C.49E6A4AA Content-Type: text/plain Christian, Many thanks for pointing out the error. You're correct in that the value of the MIKEY null encryption is indeed 0 as is specified in RFC 3830 section 6.2. So the corrected first paragraph in section 4.2 of draft-ietf-msec-mikey-dhhmac-11.txt should now read: DHHMAC SHALL apply this payload for conveying the HMAC result along with the indicated authentication algorithm. KEMAC when used in conjunction with DHHMAC SHALL not convey any encrypted data; thus Encr alg SHALL be set to 0 (NULL), Encr data len SHALL be set to 0 and Encr data SHALL be left empty. The AES key wrap method (see [23]) SHALL not be applied for DHHMAC. Question to WG chair: How can we best handle this correction appropriately, since dhhmac-11.txt has already entered the RFC editor's queue? Should I submit an update (dhhmac-12.txt) with that correction and let the RFC editor know? Or should I instruct the RFC editor to make that particular correction on my behalf? Martin. Also in draft-ietf-msec-mikey-dhhmac-11 in section 4.2 it says that "KEMAC when used in conjunction with DHHMAC SHALL not convey any encrypted data; thus Encr alg SHALL be set to 2 (NULL), Encr data len SHALL be set" In RFC 3830, the NULL for the encryption algorithm for a KEMAC payload is 0. The value 2 is for AES-KW-128. Christian ------_=_NextPart_001_01C5418C.49E6A4AA Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Christian,<= /o:p>

 

Many thanks for = pointing out the error. You're correct in that the value of the MIKEY null encryption is indeed 0 as is specified in RFC 3830 section = 6.2.

 

So the = corrected first paragraph in section 4.2 of draft-ietf-msec-mikey-dhhmac-11.txt should now = read:

 

DHHMAC SHALL apply = this payload for conveying the HMAC result along with the indicated = authentication algorithm. KEMAC when used in conjunction with DHHMAC SHALL not convey = any encrypted data; thus Encr alg SHALL be set to 0 (NULL), Encr data len = SHALL be set to 0 and Encr data SHALL be left empty. The AES key wrap method = (see [23]) SHALL not be applied for DHHMAC.

 

Question to WG = chair:

 

How can we best = handle this correction appropriately, since dhhmac-11.txt has already entered = the RFC editor's queue?

Should I submit = an update (dhhmac-12.txt) with that correction and let the RFC editor = know?

Or should I = instruct the RFC editor to make that particular correction on my = behalf?

 

Martin.

 

 

Also in draft-ietf-msec-mikey-dhhmac-11 in = section 4.2 it says that "KEMAC when used

     in conjunction with = DHHMAC SHALL not convey any encrypted data;

     thus Encr alg SHALL = be set to 2 (NULL), Encr data len SHALL be set"

 

In RFC 3830, the NULL for the encryption = algorithm for a KEMAC payload is 0. The value 2 is for = AES-KW-128.

 

 

Christian

------_=_NextPart_001_01C5418C.49E6A4AA-- --===============0542179428== 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 --===============0542179428==-- From msec-bounces@securemulticast.org Fri Apr 15 15:12:59 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04913 for ; Fri, 15 Apr 2005 15:12:59 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 2A5F48C887; Fri, 15 Apr 2005 15:13:00 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 1F0308C85A for ; Fri, 15 Apr 2005 15:12:59 -0400 (EDT) Received: (qmail 93859 invoked by uid 3269); 15 Apr 2005 19:12:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 93850 invoked from network); 15 Apr 2005 19:12:58 -0000 Received: from numenor.qualcomm.com (129.46.51.58) by klesh.pair.com with SMTP; 15 Apr 2005 19:12:58 -0000 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j3FJCse2008144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 15 Apr 2005 12:12:55 -0700 (PDT) Received: from [129.46.75.63] (ldondeti.na.qualcomm.com [129.46.75.63]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j3FJCpIU024895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Apr 2005 12:12:51 -0700 (PDT) Message-ID: <42601225.3030408@qualcomm.com> Date: Fri, 15 Apr 2005 12:12:37 -0700 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org, perrig@cmu.edu, "can >> Ran Canetti" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621 Subject: [MSEC] Question on SRTP-TESLA implementations X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Hi all, I was wondering if there are any implementations or implementation efforts on SRTP-TESLA. (I have already checked with Mark and Elisabetta, and they are not aware of any). Adrian and Ran, There is at least one TESLA implementation, right? thanks and regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Apr 15 20:17:38 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11962 for ; Fri, 15 Apr 2005 20:17:35 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C2E5E8C6DE; Fri, 15 Apr 2005 20:17:35 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id D1E118C6D4 for ; Fri, 15 Apr 2005 20:17:33 -0400 (EDT) Received: (qmail 34101 invoked by uid 3269); 16 Apr 2005 00:17:33 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 34098 invoked from network); 16 Apr 2005 00:17:33 -0000 Received: from sj-iport-4.cisco.com (171.68.10.86) by klesh.pair.com with SMTP; 16 Apr 2005 00:17:33 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-4.cisco.com with ESMTP; 15 Apr 2005 17:17:33 -0700 Received: from [128.107.178.85] (dhcp-128-107-178-85.cisco.com [128.107.178.85]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3G0HS2w000040; Fri, 15 Apr 2005 17:17:29 -0700 (PDT) Message-ID: <42605996.1060308@cisco.com> Date: Fri, 15 Apr 2005 17:17:26 -0700 From: Brian Weis User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: saag@mit.edu, cfrg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: msec@securemulticast.org Subject: [MSEC] RSA Signature padding recommendations 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 When an RSA signature is created, the signature algorithm input encapsulates the hash output with a padding method. RFC 3447 (PKCS #1 v2.1) specifies two methods of padding: EMSA-PKCS1-v1_5 and EMSA-PSS. EMSA-PKCS1-v1_5 is the traditional method of padding, but since attacks have been found on that method PSS was added to PKCS#1 v2.1. Due to its improved security properties, new protocols using RSA signatures are being given the advice to adopt PSS as a MUST. However, there are some complications with using PSS. 1. The base PSS specification has intellectual property claimed on it. Whether or not the construction of PSS specified in RFC 3447 is covered is not clear. (No IPR disclosure has been filed with the IETF. However, the only publicly available statement regarding licensing its use applies to IEEE P1363, not the IETF.) 2. Commonly used crypto toolkits and RSA hardware accelerators that I have investigated do not typically support PSS padding. So while PSS padding is a better security method, specifying it as a required method will likely not result in those standards being adopted until these issues are sorted out. RFC 3447 suggests that no known attacks are known against the EMSA-PKCS-v1_5 encoding method, yet "a gradual transition to EMSA-PSS is recommended as a precaution against future developments". It doesn't seem to me as if such a transition is yet possible, but I'd be interested in other hearing other opinions. Thanks, Brian -- 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 Sat Apr 16 14:54:34 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23837 for ; Sat, 16 Apr 2005 14:54:33 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 148B18C11A; Sat, 16 Apr 2005 11:40:13 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id B95F88C110 for ; Sat, 16 Apr 2005 11:40:11 -0400 (EDT) Received: (qmail 56185 invoked by uid 3269); 16 Apr 2005 15:40:11 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 56181 invoked from network); 16 Apr 2005 15:40:11 -0000 Received: from bache.ece.cmu.edu (128.2.129.23) by klesh.pair.com with SMTP; 16 Apr 2005 15:40:11 -0000 Received: from FINCH.ECE.CMU.EDU (FINCH.ECE.CMU.EDU [128.2.134.43]) by bache.ece.cmu.edu (Postfix) with ESMTP id 3759C68; Sat, 16 Apr 2005 11:40:06 -0400 (EDT) Date: Sat, 16 Apr 2005 11:40:06 -0400 (EDT) From: Adrian Perrig To: Lakshminath Dondeti Subject: Re: [MSEC] Question on SRTP-TESLA implementations In-Reply-To: <42601225.3030408@qualcomm.com> Message-ID: References: <42601225.3030408@qualcomm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Hi, An early implementation of TESLA is available from this page: http://www.ece.cmu.edu/~adrian/tesla.html Best wishes, Adrian > Hi all, > > I was wondering if there are any implementations or implementation > efforts on SRTP-TESLA. (I have already checked with Mark and > Elisabetta, and they are not aware of any). > > Adrian and Ran, > > There is at least one TESLA implementation, right? > > thanks and regards, > Lakshminath > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Sat Apr 16 14:54:36 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23855 for ; Sat, 16 Apr 2005 14:54:35 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id F15C78C71A; Sat, 16 Apr 2005 11:42:07 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id D8E858C110 for ; Sat, 16 Apr 2005 11:42:06 -0400 (EDT) Received: (qmail 56522 invoked by uid 3269); 16 Apr 2005 15:42:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 56519 invoked from network); 16 Apr 2005 15:42:06 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by klesh.pair.com with SMTP; 16 Apr 2005 15:42:06 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 16 Apr 2005 08:42:06 -0700 X-IronPort-AV: i="3.92,106,1112598000"; d="scan'208"; a="250547104:sNHT35496552" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3GFg12w006262; Sat, 16 Apr 2005 08:42:01 -0700 (PDT) Received: from [192.168.0.10] (sjc-vpn2-615.cisco.com [10.21.114.103]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j3GFXJe3000383; Sat, 16 Apr 2005 08:33:19 -0700 In-Reply-To: References: <42601225.3030408@qualcomm.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2d432a253bc66c1b05245dc53fd7dd83@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] Question on SRTP-TESLA implementations Date: Sat, 16 Apr 2005 08:42:01 -0700 To: Adrian Perrig X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1113665600.26392"; x:"432200"; a:"rsa-sha1"; b:"nofws:752"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"hHkna0tpW89DXVrhhgbn3cxKIK9d2DuUcWf3cwUl5SQnlQp3OHYji2Gdq+fOrlEB2mlWt6JI" "AeHn664iYQ2gFXD0Kx9IimkGJteA0hkyA4XGo3fP5ChrV2JfPVSzx/S35s6kCqnyUM5tV7gWGq6" "2BOJOb7g210RXGnt1pl96RH8="; c:"From: Mark Baugher "; c:"Subject: Re: [MSEC] Question on SRTP-TESLA implementations"; c:"Date: Sat, 16 Apr 2005 08:42:01 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Cc: msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Alas, we are looking for SRTP-TESLA to accompany the I-D. thanks, Mark On Apr 16, 2005, at 8:40 AM, Adrian Perrig wrote: > Hi, > > An early implementation of TESLA is available from this page: > http://www.ece.cmu.edu/~adrian/tesla.html > Best wishes, > Adrian > >> Hi all, >> >> I was wondering if there are any implementations or implementation >> efforts on SRTP-TESLA. (I have already checked with Mark and >> Elisabetta, and they are not aware of any). >> >> Adrian and Ran, >> >> There is at least one TESLA implementation, right? >> >> thanks and regards, >> Lakshminath >> _______________________________________________ >> msec mailing list >> msec@securemulticast.org >> http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Apr 20 17:15:58 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21777 for ; Wed, 20 Apr 2005 17:15:56 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 36DE88C1F1; Wed, 20 Apr 2005 17:15:47 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 093658C6F1 for ; Wed, 20 Apr 2005 17:15:21 -0400 (EDT) Received: (qmail 59054 invoked by uid 3269); 20 Apr 2005 21:15:10 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 59051 invoked from network); 20 Apr 2005 21:15:10 -0000 Received: from numenor.qualcomm.com (129.46.51.58) by klesh.pair.com with SMTP; 20 Apr 2005 21:15:10 -0000 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j3KLF7IP024519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 20 Apr 2005 14:15:08 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j3KLF3IU029156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Apr 2005 14:15:04 -0700 (PDT) Message-ID: <4266C66B.4070000@qualcomm.com> Date: Wed, 20 Apr 2005 17:15:23 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621 Cc: "cane >> Ran Canetti" Subject: [MSEC] Revised milestones section of MSEC work items: Need input from I-D authors ASAP X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Hi all, As you may have noticed, MSEC working group Goals and Milestones section needs to revised. We have decided to recharter at the last San Diego meeting (so the last item in the list has been decided), and finished a number of the items in that list. Ran and I will communicate to the IESG secretary shortly to get them updated. In addition to that, we have taken up a number of new work items, on MIKEY, TESLA, and other topics. I hereby request the authors of the current I-Ds to send Ran and I (please feel free to cc the mailing list) the following information: 0) I-D file name, title, and authors 1) the date you plan to submit the next version of your I-D* 2) proposed WG last call date (whereas a week or two delay is acceptable, but we would generally like to finish before the proposed date) I hope we can do this in the *next few* days (or I will have to send individual messages :-)). Thanks in advance. best regards, Lakshminath * For new/revised I-D submissions, please note that RFC 3667 has been obsoleted by 3978. See below for the message from the IESG secretary. * Also please try and use XML or NROFF to write your I-Ds. My guess is that the RFC editor retypes the I-Ds (in part or in full) when we use other formats, which delays the eventual publication, introduces errors, and consumes more time. ++++++++++ From: IETF Secretariat +++++++++++++++ As you may be aware, RFC 3667 (BCP 78), "IETF Rights in Contributions," has been obsoleted by RFC 3978 (BCP 78), which was published in March 2005, and which bears the same title. The major difference between the two RFCs is that the IPR-related notices and disclaimers that the IETF requires in all Internet-Drafts have been updated to correct anomalies. The updated versions of the required notices and disclaimers are specified in Section 5, "Notices Required in IETF Documents," of RFC 3978, and in Section 3, "IPR-Related Notices Required in Internet-Drafts," of the recently revised "Guidelines to Authors of Internet-Drafts" (http://www.ietf.org/ietf/1id-guidelines.html). The "Guidelines" document also provides additional guidance regarding the placement of these notices. Currently, the IETF Secretariat accepts and posts Internet-Drafts that include *either* the RFC 3667 or the RFC 3978 version of these notices. However, as of 17:00 ET on Friday May 6, 2005, the Secretariat will accept *only* those Internet-Drafts that comply with the requirements of RFC 3978, and with the most recent version of the "Guidelines" document. Please note that the required notices and disclaimers must be reproduced verbatim since they have been legally reviewed and formally adopted as part of the IETF process. The Secretariat will not accept deviations from the specified text, nor will it correct the text. Any documents that do not comply with the requirements will be returned to the submitter. The IETF Secretariat _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Apr 21 11:47:25 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10690 for ; Thu, 21 Apr 2005 11:47:25 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 6993F8C247; Thu, 21 Apr 2005 11:47:26 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id DE6408C633 for ; Thu, 21 Apr 2005 11:33:20 -0400 (EDT) Received: (qmail 65751 invoked by uid 3269); 21 Apr 2005 15:33:20 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 65748 invoked from network); 21 Apr 2005 15:33:20 -0000 Received: from numenor.qualcomm.com (129.46.51.58) by klesh.pair.com with SMTP; 21 Apr 2005 15:33:20 -0000 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j3LFXHIP029230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 21 Apr 2005 08:33:17 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j3LFXDLU015862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Apr 2005 08:33:14 -0700 (PDT) Message-ID: <4267C7B8.2080400@qualcomm.com> Date: Thu, 21 Apr 2005 11:33:12 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621 Cc: Ran Canetti Subject: [MSEC] IETF-63 deadlines X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Hi all, Here are some deadlines to keep in mind in preparation for the Paris meeting: * July 5, Tuesday - Working Group Chair approval for initial document (Version -00) submissions appreciated by 09:00 ET (13:00 GMT) Note that this applies to all 00s including those resulting from I-D name changes etc. Unless your document falls into the above category (i.e., name change), please submit your draft as individual submission at least a month prior to the deadline to see if there is consensus in the WG to accept it as a working group item. * July 11, Monday - Internet Draft Cut-off for initial document (-00) submission by 09:00 ET (13:00 GMT) * July 18, Monday - Internet Draft final submission cut-off by 09:00 ET (13:00 GMT) (Hint: This is of interest if you want to go through a quick review cycle before the meeting, we have about 3 months to this deadline!) cheers, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Apr 21 12:18:02 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13369 for ; Thu, 21 Apr 2005 12:18:01 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id A831B8C5D6; Thu, 21 Apr 2005 12:18:03 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id AD5DF8C59E for ; Thu, 21 Apr 2005 12:18:01 -0400 (EDT) Received: (qmail 74958 invoked by uid 3269); 21 Apr 2005 16:18:01 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 74955 invoked from network); 21 Apr 2005 16:18:01 -0000 Received: from ithilien.qualcomm.com (129.46.51.59) by klesh.pair.com with SMTP; 21 Apr 2005 16:18:01 -0000 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j3LGHwHa010652; Thu, 21 Apr 2005 09:17:58 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j3LGHqLU001644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Apr 2005 09:17:53 -0700 (PDT) Message-ID: <4267D22C.1050603@qualcomm.com> Date: Thu, 21 Apr 2005 12:17:48 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org, Brian Weis References: <4267C7B8.2080400@qualcomm.com> In-Reply-To: <4267C7B8.2080400@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621 Cc: Ran Canetti Subject: [MSEC] Followup to 2401bis in the MSEC WG X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Hi Brian and all, Now that 2401bis is in the RFC Ed queue, it is probably time to start working on Russ's request at the IETF-62 meeting on preparing a document on multicast SPD and SAD management similar to unicast SPD and SAD management in 2401bis. Russ's verbatim instructions were: "MSEC WG [to] develop an update to address the multicast shortcomings [of 2401bis]" Brian, you will be the editor/co-editor of this document, as you have been involved in the original discussions on this 2 years ago, and were interested last we talked about this (you are still interested, right ? :-) ). Thank you. All, Brian does need help with his other ongoing MSEC commitments, and his day job. This is a very interesting topic, so please sign-up to be co-editor/author of this work. thanks and regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Apr 21 12:42:20 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15727 for ; Thu, 21 Apr 2005 12:42:20 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 981CB8C3C4; Thu, 21 Apr 2005 12:42:22 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id F17558C2C8 for ; Thu, 21 Apr 2005 12:42:20 -0400 (EDT) Received: (qmail 80766 invoked by uid 3269); 21 Apr 2005 16:42:18 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 80751 invoked from network); 21 Apr 2005 16:42:14 -0000 Received: from sj-iport-5.cisco.com (171.68.10.87) by klesh.pair.com with SMTP; 21 Apr 2005 16:42:14 -0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 21 Apr 2005 09:42:12 -0700 Received: from [128.107.163.59] (dhcp-128-107-163-59.cisco.com [128.107.163.59]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j3LGg9pR014250; Thu, 21 Apr 2005 09:42:10 -0700 (PDT) Message-ID: <4267D7E1.4080201@cisco.com> Date: Thu, 21 Apr 2005 09:42:09 -0700 From: Brian Weis User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ldondeti@qualcomm.com Subject: Re: [MSEC] Followup to 2401bis in the MSEC WG References: <4267C7B8.2080400@qualcomm.com> <4267D22C.1050603@qualcomm.com> In-Reply-To: <4267D22C.1050603@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ran Canetti , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Lakshminath, Yes, I am interested in seeing this document be created. As you mention below, I don't expect to do it alone :-). By the way, pretty much all of the issues we addressed in the original discussions (2 years ago) were addressed in 2401bis. This work is to address a new set of issues, some of which are to make sure that there is an IPsec architecture that matches RFC 3740, which is the MSEC Multicast Group Security Architecture. Brian Lakshminath Dondeti wrote: > Hi Brian and all, > > Now that 2401bis is in the RFC Ed queue, it is probably time to start > working on Russ's request at the IETF-62 meeting on preparing a document > on multicast SPD and SAD management similar to unicast SPD and SAD > management in 2401bis. > > Russ's verbatim instructions were: > > "MSEC WG [to] develop an update to address the multicast shortcomings > [of 2401bis]" > > Brian, you will be the editor/co-editor of this document, as you have > been involved in the original discussions on this 2 years ago, and were > interested last we talked about this (you are still interested, right ? > :-) ). Thank you. > > All, > > Brian does need help with his other ongoing MSEC commitments, and his > day job. This is a very interesting topic, so please sign-up to be > co-editor/author of this work. > > thanks and regards, > Lakshminath > _______________________________________________ > 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 Thu Apr 21 13:47:44 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21377 for ; Thu, 21 Apr 2005 13:47:42 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 82FCD8C6DE; Thu, 21 Apr 2005 13:47:41 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 601A58C6B2 for ; Thu, 21 Apr 2005 13:47:40 -0400 (EDT) Received: (qmail 93716 invoked by uid 3269); 21 Apr 2005 17:47:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 93711 invoked from network); 21 Apr 2005 17:47:40 -0000 Received: from numenor.qualcomm.com (129.46.51.58) by klesh.pair.com with SMTP; 21 Apr 2005 17:47:40 -0000 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j3LHlaIP012813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 21 Apr 2005 10:47:37 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j3LHlVLU005928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Apr 2005 10:47:32 -0700 (PDT) Message-ID: <4267E71D.9000701@qualcomm.com> Date: Thu, 21 Apr 2005 13:47:09 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Weis Subject: Re: [MSEC] Followup to 2401bis in the MSEC WG References: <4267C7B8.2080400@qualcomm.com> <4267D22C.1050603@qualcomm.com> <4267D7E1.4080201@cisco.com> In-Reply-To: <4267D7E1.4080201@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621 Cc: Ran Canetti , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Brian, Thanks. Perhaps starting a discussion on the contents of the new work (please cc Russ) might be a good way to sign-up contributors to this :-). regards, Lakshminath Brian Weis wrote: > Lakshminath, > > Yes, I am interested in seeing this document be created. As you > mention below, I don't expect to do it alone :-). > > By the way, pretty much all of the issues we addressed in the original > discussions (2 years ago) were addressed in 2401bis. This work is to > address a new set of issues, some of which are to make sure that there > is an IPsec architecture that matches RFC 3740, which is the MSEC > Multicast Group Security Architecture. > > Brian > > Lakshminath Dondeti wrote: > >> Hi Brian and all, >> >> Now that 2401bis is in the RFC Ed queue, it is probably time to start >> working on Russ's request at the IETF-62 meeting on preparing a >> document on multicast SPD and SAD management similar to unicast SPD >> and SAD management in 2401bis. >> >> Russ's verbatim instructions were: >> >> "MSEC WG [to] develop an update to address the multicast shortcomings >> [of 2401bis]" >> >> Brian, you will be the editor/co-editor of this document, as you have >> been involved in the original discussions on this 2 years ago, and >> were interested last we talked about this (you are still interested, >> right ? :-) ). Thank you. >> >> All, >> >> Brian does need help with his other ongoing MSEC commitments, and his >> day job. This is a very interesting topic, so please sign-up to be >> co-editor/author of this work. >> >> thanks and regards, >> Lakshminath >> _______________________________________________ >> msec mailing list >> msec@securemulticast.org >> http://six.pairlist.net/mailman/listinfo/msec >> > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Apr 25 17:08:09 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29981 for ; Mon, 25 Apr 2005 17:08:07 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 77E4F8C8B3; Mon, 25 Apr 2005 17:08:08 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 9787A8C2C1 for ; Mon, 25 Apr 2005 17:08:06 -0400 (EDT) Received: (qmail 35492 invoked by uid 3269); 25 Apr 2005 21:08:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 35488 invoked from network); 25 Apr 2005 21:08:06 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 25 Apr 2005 21:08:06 -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 j3PL85p51302 for ; Mon, 25 Apr 2005 17:08:05 -0400 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 j3PL85Z203834 for ; Mon, 25 Apr 2005 17:08:05 -0400 Received: from mgsmtp00 (mgsmtp00.watson.ibm.com [9.2.40.58]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j3PL84g203832 for ; Mon, 25 Apr 2005 17:08:04 -0400 Received: from prf.watson.ibm.com ([9.2.16.112]) by mgsmtp00.watson.ibm.com ID IMFd1114463029.1; Mon, 25 Apr 2005 17:03:49 -0400 Received: from localhost (canetti@localhost) by prf.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id j3PL84t17340 for ; Mon, 25 Apr 2005 17:08:04 -0400 Date: Mon, 25 Apr 2005 17:08:03 -0400 (EDT) From: canetti To: msec@securemulticast.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] New work item? X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Folks, The following private I-D: http://www.ietf.org/internet-drafts/draft-ignjatic-msec-mikey-rsa-r-00.txt was presented and well received at the IETF meeting in Minneapolis. Essentially, it proposes a new MIKEY mode that works in one round-trip, and is aimed at situations where the initiator does not know in advance the public key/certificate of the responder. I'd like to get a sense if there is interest in making this into an MSEC work item. Thanks, Ran _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Apr 26 08:15:11 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02527 for ; Tue, 26 Apr 2005 08:15:11 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id BBDCC8C16F; Tue, 26 Apr 2005 08:15:10 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 29BC78BFD4 for ; Tue, 26 Apr 2005 08:15:09 -0400 (EDT) Received: (qmail 24778 invoked by uid 3269); 26 Apr 2005 12:15:09 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 24775 invoked from network); 26 Apr 2005 12:15:08 -0000 Received: from david.siemens.de (192.35.17.14) by klesh.pair.com with SMTP; 26 Apr 2005 12:15:08 -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 j3QCF7KY020864; Tue, 26 Apr 2005 14:15:07 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j3QCF6kF020062; Tue, 26 Apr 2005 14:15:06 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <2SQ5PZBK>; Tue, 26 Apr 2005 14:15:06 +0200 Message-ID: From: Fries Steffen To: canetti , msec@securemulticast.org Subject: RE: [MSEC] New work item? Date: Tue, 26 Apr 2005 14:15:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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 Ran, I think that this is a very valuable approach, as it allows the inband certificate exchange. Making it WG item would enhance the possible scenarios in which MIKEY can be (easier) applied. Regards Steffen > -----Original Message----- > From: msec-bounces@securemulticast.org > [mailto:msec-bounces@securemulticast.org] On Behalf Of canetti > Sent: Monday, April 25, 2005 11:08 PM > To: msec@securemulticast.org > Subject: [MSEC] New work item? > > > > Folks, > > The following private I-D: > > http://www.ietf.org/internet-drafts/draft-ignjatic-msec-mikey- > rsa-r-00.txt > > was presented and well received at the IETF meeting in Minneapolis. > > Essentially, it proposes a new MIKEY mode that works in one > round-trip, and is aimed at situations where the initiator > does not know in advance the public key/certificate of the responder. > > I'd like to get a sense if there is interest in making this > into an MSEC work item. > > Thanks, > > Ran > > > _______________________________________________ > 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 Apr 29 13:03:32 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15554 for ; Fri, 29 Apr 2005 13:03:31 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 00CB08C7AB; Fri, 29 Apr 2005 13:03:31 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id BB2AF8C7BB for ; Fri, 29 Apr 2005 13:03:29 -0400 (EDT) Received: (qmail 80111 invoked by uid 3269); 29 Apr 2005 17:03:29 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 80108 invoked from network); 29 Apr 2005 17:03:29 -0000 Received: from zcars04f.nortelnetworks.com (47.129.242.57) by klesh.pair.com with SMTP; 29 Apr 2005 17:03:29 -0000 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j3TH3P907567; Fri, 29 Apr 2005 13:03:25 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Apr 2005 13:03:10 -0400 Message-ID: <1ECE0EB50388174790F9694F77522CCF020B02F4@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "'canetti'" , "'msec@securemulticast.org'" Subject: RE: [MSEC] New work item? Date: Fri, 29 Apr 2005 13:02:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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="===============0275683222==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0275683222== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C54CDD.4ACAFD2B" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C54CDD.4ACAFD2B Content-Type: text/plain I presented the draft at IETF 62, and would be very interested in being a co-author with Laksminah and Dragan (with who I worked on the original draft). > > -----Original Message----- > > From: msec-bounces@securemulticast.org > > [mailto:msec-bounces@securemulticast.org] On Behalf Of canetti > > Sent: Monday, April 25, 2005 11:08 PM > > To: msec@securemulticast.org > > Subject: [MSEC] New work item? > > > > > > > > Folks, > > > > The following private I-D: > > > > http://www.ietf.org/internet-drafts/draft-ignjatic-msec-mikey- > > rsa-r-00.txt > > > > was presented and well received at the IETF meeting in Minneapolis. > > > > Essentially, it proposes a new MIKEY mode that works in one > > round-trip, and is aimed at situations where the initiator > > does not know in advance the public key/certificate of the > responder. > > > > I'd like to get a sense if there is interest in making this > > into an MSEC work item. > > > > Thanks, > > > > Ran > > > > > > _______________________________________________ > > 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 > > ------_=_NextPart_001_01C54CDD.4ACAFD2B Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MSEC] New work item?

I presented the draft at IETF 62, and would be very = interested in
being a co-author with Laksminah and Dragan (with = who I worked on
the original draft).



> > -----Original Message-----
> > From: = msec-bounces@securemulticast.org
> > [mailto:msec-bounces@sec= uremulticast.org] On Behalf Of canetti
> > Sent: Monday, April 25, 2005 11:08 = PM
> > To: msec@securemulticast.org
> > Subject: [MSEC] New work item?
> >
> >
> >
> > Folks,
> >
> > The following private I-D:
> >
> > http://www.ietf.org/internet-drafts/draft-ignjatic-mse= c-mikey-
> > rsa-r-00.txt
> >
> > was presented and well received at the = IETF meeting in Minneapolis.
> >
> > Essentially, it proposes a new MIKEY mode = that works in one
> > round-trip, and is aimed at situations = where the initiator
> > does not know in advance the public = key/certificate of the
> responder.
> >
> > I'd like to get a sense if there is = interest in making this
> > into an MSEC work item.
> >
> > Thanks,
> >
> > Ran
> >
> >
> > = _______________________________________________
> > 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
>
>

------_=_NextPart_001_01C54CDD.4ACAFD2B-- --===============0275683222== 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 --===============0275683222==--