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