From msec-admin@securemulticast.org Wed Mar 10 03:26:36 2004 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25778 for ; Wed, 10 Mar 2004 03:26:36 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1862A53A32; Wed, 10 Mar 2004 03:26:06 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 733FE53A4F for ; Wed, 10 Mar 2004 03:24:33 -0500 (EST) Received: (qmail 50979 invoked by uid 3269); 10 Mar 2004 08:24:33 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 50976 invoked from network); 10 Mar 2004 08:24:32 -0000 Received: from albatross-ext.wise.edt.ericsson.se (193.180.251.49) by klesh.pair.com with SMTP; 10 Mar 2004 08:24:32 -0000 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2A8OVqY008491 for ; Wed, 10 Mar 2004 09:24:31 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 10 Mar 2004 09:24:16 +0100 Received: from ericsson.com (eramoli_2k.er.ki.sw.ericsson.se [147.214.97.152]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id GSLN6VZX; Wed, 10 Mar 2004 09:24:30 +0100 Message-ID: <404ED00A.6060806@ericsson.com> X-Sybari-Trust: febf0421 2c4885b5 73569057 00000138 From: =?ISO-8859-1?Q?Mats_N=E4slund?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec Cc: "Hardjono, Thomas" , Ran Canetti Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2004 08:24:16.0227 (UTC) FILETIME=[13909B30:01C40679] Subject: [MSEC] Final MIKEY edits Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 10 Mar 2004 09:21:30 +0100 Content-Transfer-Encoding: 7bit Apologies for possible multiple posts, but this was mailed yesterday, and there is some indication it did not reach the list properly, thus this re-post. --- Dear all, We are anticipating that MIKEY will in a not too distant future pop out of the RFC editor queue, and become an RFC. We will take care of some editorial nits before this happens. However, there is also one larger change that we are suggesting, hence this mail to open up a possibility for the WG to provide feedback. We would like to have a one week deadline for the comment period (see exact dates below). To summarize the change, it concerns the key derivation function, and specifically, we would like to change input key ("inkey") block size division in the pseudo random function (PRF) from 512 bits to 256 bits. This is an effect of some analysis the authors have made (see below). Editorially, this change is trivial, but since it is still of technical nature, we here provide a short (but hopefully convincing) rationale. A more nicely typeset and more complete problem description is available for those interested by request (we wanted to avoid flooding thousands of inboxes.) The PRF in MIKEY is used e.g. to derive TEKs from TGKs. It's similar to that of TLS with one change: while TLS applies the PRF to the whole key, MIKEY's PRF applies it blockwise to 512-bit blocks of the TGK (and XORs the results). The rationale for this is that since the PRF is based on HMAC and HMAC by definition first hashes keys of size > 512, the TLS PRF cannot produce a key with, let's say, 384-bit entropy, even if the the TGK is, say, a 2048-bit Diffie-Hellman key. Although one could argue that most "practical" key sizes can still be supported also by the TLS PRF, in MIKEY we wanted to remove this bottleneck. Now, it turns out that there is one problem with this (which applies also to the original TLS PRF if one looks closer). To see what, recall that the PRF(s) we talk about are HMAC (we assume using SHA1) used (more or less) in an "output feedback mode" (OFB). (Refer to the MIKEY draft for exact details.) Consider the following three cases: 1. The TGK is *longer* than 512 bits. Obviously, HMAC will hash the TGK and the effective key size is <= 2*160 = 320 bits (the hashed "TGK XOR ipad" and "TGK XOR opad"). This is all well known. 2. The TGK is *exactly* 512 bits. While a hash will not occur, the iterative nature of SHA1 and its 512-bit blockwise processing means that one can still guess the internal state of the "inner" and "outer" HMAC hashes at *precisely* the instant where the key has been processed. Again, the security is 320 bits. 3. Suppose the TGK is *almost* 512 bits, say 512-b bits. While the processing of the key material now does not coincide with the first block note that: - the additional b bits that enter the *first* SHA1 blocks are public - heuristically, with probability 2^(-b) the b-bit output prefix of any single hash/HMAC in the "OFB chain" will take a give value. Consequently, assuming L blocks of output is produced, with probability about 2^(-2b(L-1)), all hashes/HMACs in the chain will produce b-bit prefixes "colliding" with the (known) b-bit inputs to the first stage of the OFB chain. *If* this happens, guessing the 2*160 bit hash states after the first 512 bits of the first two hashes (in the first HMAC) has been processed is enough to deduce the TEK. Working out the details, the effective key size for MIKEY, when applied to (512-b)-bit TGK to produce L*160 bit TEKs is bounded by 320 + 3b(L-1) bits. For instance, a 500-bit TGK will produce 480-bit TEKs with entropy 392 bits, etc. (Note that similar bounds can be obtained for the TLS, WTLS, and IKEv2 PRFs too, where the "effects" will set in at varying key sizes due to the slightly different construction. We make no claims about "insecurity" of the PRF construction in general.) For sure (or at least: relative to the above analysis), the PRF will never produce keys with entropy less than 320 bits, and one could argue that this is sufficient in "practice". Nevertheless, since removing this "bottleneck" is easy (see below) we strongly feel that we would like to make MIKEY theoretically sound by indeed fixing it. The suggested fix is as follows: instead of diving long keys into 512-bit blocks, divide them into 256-bit blocks. This will assert that "b" in the above expression is never less than 256 and will effectively kill the collision probabilities of the above "attack". Editorially, this implies to change one parameter in MIKEY from "512" to "256" and the effect on an existing MIKEY implementation seems very small. We would like to hear your feedback whether you approve of this change. We will put a deadline of one week. Specifically, we will collect comments until March 16/2004, 2359UTC. The Security AD Russ suggested the following way forward: 1. During the one week comment period, we address comments from the working group mail list immediately. 2. On March 17, we summarize the changes that the RFC Editor will be asked to make during AUTH48. 3. The Working group chairs confirm that the changes do not break rough consensus. 4. The ADs will handle IESG review of the changes, if needed. 5. The ADs will submit the changes to the RFC Editor, avoiding the need for them to seek further approval for the changes. Comments? Regards, MIKEY authors This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Mar 17 07:30:46 2004 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03185 for ; Wed, 17 Mar 2004 07:30:45 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id AFE26539CD; Wed, 17 Mar 2004 07:30:10 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 8DEDD535AF for ; Wed, 17 Mar 2004 07:29:11 -0500 (EST) Received: (qmail 54243 invoked by uid 3269); 17 Mar 2004 12:29:11 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 54240 invoked from network); 17 Mar 2004 12:29:11 -0000 Received: from penguin-ext.wise.edt.ericsson.se (193.180.251.47) by klesh.pair.com with SMTP; 17 Mar 2004 12:29:11 -0000 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2HCT9YG013814 for ; Wed, 17 Mar 2004 13:29:10 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 17 Mar 2004 13:29:09 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Mar 2004 13:30:43 +0100 Message-ID: <4E85E49D1F0CBF4F96EA08E335750D7D0A009808@Esealnt877.al.sw.ericsson.se> From: "Elisabetta Carrara (KI/EAB)" To: msec Cc: "Hardjono, Thomas" , Ran Canetti Subject: RE: [MSEC] Final MIKEY edits MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 17 Mar 2004 12:29:09.0614 (UTC) FILETIME=[7265C8E0:01C40C1B] Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 17 Mar 2004 13:28:33 +0100 Content-Transfer-Encoding: quoted-printable Dear all, last week we proposed a change to the MIKEY key derivation=20 function (going from 512-bit blocks to 256-bit blocks) and=20 asked for a one week comment period, which has elapsed. We received one request for the paper describing the details=20 behind the analysis, but got no comment. We interpret this=20 as a "yes" from msec to the proposed change.=20 We therefore suggest to complete the plan as outlined in the=20 previous mail. The remaining steps are: - Summarize the changes that the RFC Editor will be asked to make=20 during AUTH48 (which is done above). - We ask that the Working group chairs confirm that the changes do=20 not break rough consensus. - The Area Directors will handle IESG review of the changes,=20 if needed. - The Area Directors will submit the changes to the RFC Editor,=20 avoiding the need for them to seek my approval for the changes. Hence, we would like the chairmen to confirm the change, so that=20 we can then submit to the ADs. Cheers, /MIKEY authors > -----Original Message----- > From: msec-admin@securemulticast.org > [mailto:msec-admin@securemulticast.org]On Behalf Of Mats N=E4slund > (KI/EAB) > Sent: den 10 mars 2004 09:22 > To: msec > Cc: Hardjono, Thomas; Ran Canetti > Subject: [MSEC] Final MIKEY edits >=20 >=20 >=20 > Apologies for possible multiple posts, but this was mailed yesterday, > and there is some indication it did not reach the list properly, thus > this re-post. >=20 > --- >=20 > Dear all, >=20 > We are anticipating that MIKEY will in a not too distant future > pop out of the RFC editor queue, and become an RFC. We will take > care of some editorial nits before this happens. However, there > is also one larger change that we are suggesting, hence this mail > to open up a possibility for the WG to provide feedback. We would > like to have a one week deadline for the comment period (see exact > dates below). >=20 > To summarize the change, it concerns the key derivation function, > and specifically, we would like to change input key ("inkey") block > size division in the pseudo random function (PRF) from 512 bits to > 256 bits. This is an effect of some analysis the authors have made > (see below). >=20 > Editorially, this change is trivial, but since it is still of > technical nature, we here provide a short (but hopefully convincing) > rationale. A more nicely typeset and more complete problem description > is available for those interested by request (we wanted to avoid > flooding thousands of inboxes.) >=20 > The PRF in MIKEY is used e.g. to derive TEKs from TGKs. It's similar > to that of TLS with one change: while TLS applies the PRF to the > whole key, MIKEY's PRF applies it blockwise to 512-bit blocks=20 > of the TGK > (and XORs the results). The rationale for this is that since the PRF > is based on HMAC and HMAC by definition first hashes keys of size > > 512, the TLS PRF cannot produce a key with, let's say, 384-bit > entropy, even if the the TGK is, say, a 2048-bit Diffie-Hellman key. > Although one could argue that most "practical" key sizes can still > be supported also by the TLS PRF, in MIKEY we wanted to remove this > bottleneck. >=20 > Now, it turns out that there is one problem with this (which applies > also to the original TLS PRF if one looks closer). To see what, > recall that the PRF(s) we talk about are HMAC (we assume using SHA1) > used (more or less) in an "output feedback mode" (OFB). (Refer to the > MIKEY draft for exact details.) Consider the following three cases: >=20 > 1. The TGK is *longer* than 512 bits. Obviously, HMAC will hash > the TGK and the effective key size is <=3D 2*160 =3D 320 bits > (the hashed "TGK XOR ipad" and "TGK XOR opad"). This is all > well known. >=20 > 2. The TGK is *exactly* 512 bits. While a hash will not occur, the > iterative nature of SHA1 and its 512-bit blockwise processing > means that one can still guess the internal state of the "inner" > and "outer" HMAC hashes at *precisely* the instant where the > key has been processed. Again, the security is 320 bits. >=20 > 3. Suppose the TGK is *almost* 512 bits, say 512-b bits. While the > processing of the key material now does not coincide with the > first block note that: >=20 > - the additional b bits that enter the *first* SHA1=20 > blocks are public > - heuristically, with probability 2^(-b) the b-bit output prefix > of any single hash/HMAC in the "OFB chain" will take a=20 > give value. >=20 > Consequently, assuming L blocks of output is produced, with > probability about 2^(-2b(L-1)), all hashes/HMACs in the=20 > chain will > produce b-bit prefixes "colliding" with the (known)=20 > b-bit inputs to > the first stage of the OFB chain. *If* this happens, guessing the > 2*160 bit hash states after the first 512 bits of the first two > hashes (in the first HMAC) has been processed is enough to deduce > the TEK. >=20 > Working out the details, the effective key size for MIKEY,=20 > when applied > to (512-b)-bit TGK to produce L*160 bit TEKs is bounded by >=20 > 320 + 3b(L-1) >=20 > bits. For instance, a 500-bit TGK will produce 480-bit TEKs with > entropy 392 bits, etc. (Note that similar bounds can be obtained for > the TLS, WTLS, and IKEv2 PRFs too, where the "effects" will set in at > varying key sizes due to the slightly different construction. We make > no claims about "insecurity" of the PRF construction in general.) >=20 > For sure (or at least: relative to the above analysis), the PRF will > never produce keys with entropy less than 320 bits, and one=20 > could argue > that this is sufficient in "practice". Nevertheless, since=20 > removing this > "bottleneck" is easy (see below) we strongly feel that we=20 > would like to > make MIKEY theoretically sound by indeed fixing it. >=20 > The suggested fix is as follows: instead of diving long keys into > 512-bit blocks, divide them into 256-bit blocks. This will assert > that "b" in the above expression is never less than 256 and will > effectively kill the collision probabilities of the above "attack". > Editorially, this implies to change one parameter in MIKEY from > "512" to "256" and the effect on an existing MIKEY implementation > seems very small. >=20 > We would like to hear your feedback whether you approve of=20 > this change. > We will put a deadline of one week. Specifically, we will collect > comments until March 16/2004, 2359UTC. The Security AD Russ suggested > the following way forward: >=20 > 1. During the one week comment period, we address comments from > the working group mail list immediately. >=20 > 2. On March 17, we summarize the changes that the RFC > Editor will be asked to make during AUTH48. >=20 > 3. The Working group chairs confirm that the changes do not break > rough consensus. >=20 > 4. The ADs will handle IESG review of the changes, if needed. >=20 > 5. The ADs will submit the changes to the RFC Editor, avoiding > the need for them to seek further approval for the changes. >=20 > Comments? >=20 > Regards, >=20 > MIKEY authors >=20 >=20 >=20 >=20 > This communication is confidential and intended solely for=20 > the addressee(s). Any unauthorized review, use, disclosure or=20 > distribution is prohibited. If you believe this message has=20 > been sent to you in error, please notify the sender by=20 > replying to this transmission and delete the message without=20 > disclosing it. Thank you. >=20 > E-mail including attachments is susceptible to data=20 > corruption, interruption, unauthorized amendment, tampering=20 > and viruses, and we only send and receive e-mails on the=20 > basis that we are not liable for any such corruption,=20 > interception, amendment, tampering or viruses or any=20 > consequences thereof. >=20 >=20 > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec >=20 This communication is confidential and intended solely for the addressee(= s). Any unauthorized review, use, disclosure or distribution is prohibite= d. If you believe this message has been sent to you in error, please noti= fy the sender by replying to this transmission and delete the message wit= hout disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interrupt= ion, unauthorized amendment, tampering and viruses, and we only send and = receive e-mails on the basis that we are not liable for any such corrupti= on, interception, amendment, tampering or viruses or any consequences the= reof. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Mar 17 18:51:21 2004 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17785 for ; Wed, 17 Mar 2004 18:51:20 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 02AB253823; Wed, 17 Mar 2004 18:50:52 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 38115535AF for ; Wed, 17 Mar 2004 18:49:45 -0500 (EST) Received: (qmail 20912 invoked by uid 3269); 17 Mar 2004 23:49:45 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 20905 invoked from network); 17 Mar 2004 23:49:45 -0000 Received: from mailout2.samsung.com (203.254.224.25) by klesh.pair.com with SMTP; 17 Mar 2004 23:49:45 -0000 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUQ0076KVIUUL@mailout2.samsung.com> for msec@securemulticast.org; Thu, 18 Mar 2004 08:49:42 +0900 (KST) Received: from ep_ms12_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUQ0086SVIE9W@mailout2.samsung.com> for msec@securemulticast.org; Thu, 18 Mar 2004 08:49:26 +0900 (KST) Received: from ep_spt01 (ms12.samsung.com [203.254.225.99]) by ms12.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUQ00GI5VIEO3@ms12.samsung.com> for msec@securemulticast.org; Thu, 18 Mar 2004 08:49:26 +0900 (KST) Content-return: prohibited From: =?euc-kr?B?wfa+xr+1?= X-Sender: =?euc-kr?B?u++8usD8wNqh501vYmlsZSBTb2x1dGlv?= =?euc-kr?B?biBMYWIuKLHiw9EpoedFMyi757/4KS+757/4?= To: msec@securemulticast.org Reply-To: ay.ji@samsung.com Message-id: <0HUQ00GI6VIEO3@ms12.samsung.com> MIME-version: 1.0 Content-type: text/html; charset=euc-kr Content-transfer-encoding: base64 X-Priority: 3 Msgkey: 20040317234850895@ay.ji X-MTR: 20040317234850895@ay.ji X-EPLocale: ko_KR.euc-kr X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Generator: NamoMIME 1.1.0.14 Subject: [MSEC] unsubscribe Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 17 Mar 2004 23:49:47 +0000 (GMT) Content-Transfer-Encoding: base64 PEhUTUw+PEhFQUQ+PE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVudD0ndGV4dC9o dG1sOyBjaGFyc2V0PWV1Yy1rcic+Cjx0aXRsZT5TYW1zdW5nIEVudGVycHJpc2UgUG9ydGFsIG15 U2luZ2xlPC90aXRsZT4KPHN0eWxlPiBQLCBsaSB7Zm9udC1mYW1pbHk6sby4ssO8LCBhcmlhbDsg Zm9udC1zaXplOjlwdDsgbWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7fTwvc3R5bGU+ CjwvSEVBRD4KPEJPRFk+DQo8cD51bnN1YnNjcmliZSBheS5qaUBzYW1zdW5nLmNvbTwvcD4NCjwv Qk9EWT48L0hUTUw+ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec