From emu-bounces@ietf.org Tue Aug 15 22:19:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDAzw-0003mM-2q; Tue, 15 Aug 2006 22:19:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDAzv-0003mE-3U for emu@ietf.org; Tue, 15 Aug 2006 22:19:11 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDAzs-0007Fw-PL for emu@ietf.org; Tue, 15 Aug 2006 22:19:11 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 15 Aug 2006 19:19:08 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7G2J8E9032338 for ; Tue, 15 Aug 2006 19:19:08 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7G2J8lN000106 for ; Tue, 15 Aug 2006 19:19:08 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 19:19:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] GPSK as a working group item Date: Tue, 15 Aug 2006 19:19:06 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] GPSK as a working group item Thread-Index: AcasK6FHW7ZvdP/eTgmdm/cfw3GPqwUrnzDw From: "Joseph Salowey \(jsalowey\)" To: "Joseph Salowey \(jsalowey\)" , X-OriginalArrivalTime: 16 Aug 2006 02:19:07.0869 (UTC) FILETIME=[5A6638D0:01C6C0DA] DKIM-Signature: a=rsa-sha1; q=dns; l=718; t=1155694748; x=1156558748; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:RE=3A=20[Emu]=20GPSK=20as=20a=20working=20group=20item; X=v=3Dcisco.com=3B=20h=3DjX/LQjKSN3iybDmJF7dLV/rgdc0=3D; b=QzZht8flIKOZ8904bKBx5lbERdoHIewsWcr4X1kA2uSGwRJ7tsNGaLTFWpiKZyTnZF62kOc5 6vsMNDj8Egt5ZXIhLQWroXfNozKDjOr/wgaxw3FLr6jEi6jI45FMCRv0; Authentication-Results: sj-dkim-2.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Since we haven't had any objections it seems there is consensus to take this on as a working group item. =20 Cheers, Joe=20 > -----Original Message----- > From: Joseph Salowey (jsalowey)=20 > Sent: Thursday, July 20, 2006 11:38 AM > To: emu@ietf.org > Subject: [Emu] GPSK as a working group item >=20 > At IETF 66 EMU working group meeting there was consensus to take on > draft-clancy-emu-eap-shared-secret-01.txt as a working group item. =20 >=20 > Are there any objections to taking this on as a working group item? >=20 > Thanks, >=20 > Joe=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Aug 15 22:29:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDB9n-0007GS-Ef; Tue, 15 Aug 2006 22:29:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDB9m-0007GN-Dg for emu@ietf.org; Tue, 15 Aug 2006 22:29:22 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDB9l-00083r-3G for emu@ietf.org; Tue, 15 Aug 2006 22:29:22 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 15 Aug 2006 19:29:20 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7G2TKNZ011263; Tue, 15 Aug 2006 19:29:20 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7G2TKlN003567; Tue, 15 Aug 2006 19:29:20 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Aug 2006 19:29:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] Duplicate integrity protection on Protected Payload datain GPSK Date: Tue, 15 Aug 2006 19:29:17 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Duplicate integrity protection on Protected Payload datain GPSK Thread-Index: AcapOuq6i3UIaFlkROSNEgDx+x63WwXoLJJg From: "Joseph Salowey \(jsalowey\)" To: "Charles Clancy" , "Lakshminath Dondeti" X-OriginalArrivalTime: 16 Aug 2006 02:29:20.0017 (UTC) FILETIME=[C7449810:01C6C0DB] DKIM-Signature: a=rsa-sha1; q=dns; l=986; t=1155695360; x=1156559360; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:RE=3A=20[Emu]=20Duplicate=20integrity=20protection=20on=20Protected=20Pa yload=20datain=20GPSK; X=v=3Dcisco.com=3B=20h=3DwzncS7iim0jz9ZWgACDUT6Y5BEk=3D; b=RZ8c5/w5iggO5pn496m3tK8OtMudCx/VYO4AnVWuzC0YLmuR+KSQZFiQfLwLxKYWPSmcW4bx 6UOsVr30XNb/Cfkm8wF5r8nJiMaKVXOFNBNd9WEta+QCk4jka+xNgj1d; Authentication-Results: sj-dkim-1.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org AES-CBC seems like a good choice. =20 Joe=20 > -----Original Message----- > From: Charles Clancy [mailto:clancy@cs.umd.edu]=20 > Sent: Sunday, July 16, 2006 5:52 PM > To: Lakshminath Dondeti > Cc: emu@ietf.org > Subject: Re: [Emu] Duplicate integrity protection on=20 > Protected Payload datain GPSK >=20 > > My reading of the GPSK draft is that the Protected Payload=20 > data will > be integrity protected using the MAC from the=20 > combined mode and there > is the integrity checksum over the=20 > entire GPSK-Message. I think we > should avoid the multiple MACs. >=20 > ... >=20 > > I am curious about others' opinions on EAX vs. CCM. >=20 > We could replace AES-EAX with AES-CBC. Would address both=20 > your concerns? >=20 > -- > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Aug 15 23:01:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDBeE-0007kJ-2x; Tue, 15 Aug 2006 23:00:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDBeD-0007kE-AT for emu@ietf.org; Tue, 15 Aug 2006 23:00:49 -0400 Received: from bay0-omc3-s32.bay0.hotmail.com ([65.54.246.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDBeA-00012B-0Y for emu@ietf.org; Tue, 15 Aug 2006 23:00:49 -0400 Received: from hotmail.com ([65.54.161.37]) by bay0-omc3-s32.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 20:00:45 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 15 Aug 2006 20:00:44 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Wed, 16 Aug 2006 03:00:43 GMT X-Originating-IP: [131.107.0.71] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: jsalowey@cisco.com Bcc: Subject: RE: [Emu] Duplicate integrity protection on Protected Payload datainGPSK Date: Tue, 15 Aug 2006 20:00:43 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 16 Aug 2006 03:00:44.0969 (UTC) FILETIME=[2AC97190:01C6C0E0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >AES-CBC seems like a good choice. This might also be a decent choice for the EAP-TLS mandatory-to-implement ciphersuite (unless the issues with 3DES can be ironed out). _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Aug 16 01:57:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDEOm-0002u7-GX; Wed, 16 Aug 2006 01:57:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDEOk-0002tv-Sq for emu@ietf.org; Wed, 16 Aug 2006 01:57:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDBYY-0000ht-Tl for emu@ietf.org; Tue, 15 Aug 2006 22:54:58 -0400 Received: from bay0-omc2-s7.bay0.hotmail.com ([65.54.246.143]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GDBSl-0007C6-Ps for emu@ietf.org; Tue, 15 Aug 2006 22:49:01 -0400 Received: from hotmail.com ([65.54.161.85]) by bay0-omc2-s7.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 19:48:58 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 15 Aug 2006 19:48:58 -0700 Message-ID: Received: from 131.107.0.72 by BAY106-DAV13.phx.gbl with DAV; Wed, 16 Aug 2006 02:48:54 +0000 X-Originating-IP: [131.107.0.72] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: References: In-Reply-To: Date: Tue, 15 Aug 2006 19:48:59 -0700 Message-ID: <013701c6c0de$8689ac40$939d04c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcasK6FHW7ZvdP/eTgmdm/cfw3GPqwUrnzDwAAEUzCA= Content-language: en-us X-OriginalArrivalTime: 16 Aug 2006 02:48:58.0653 (UTC) FILETIME=[85CA2CD0:01C6C0DE] X-Spam-Score: -0.7 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Subject: [Emu] EMU WG issues tracker? X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Does the EMU WG have an issues tracker? _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Aug 20 10:56:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEoiV-0000WM-7J; Sun, 20 Aug 2006 10:55:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEoiT-0000WH-Rv for emu@ietf.org; Sun, 20 Aug 2006 10:55:57 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GEoiS-00085b-Ec for emu@ietf.org; Sun, 20 Aug 2006 10:55:57 -0400 Received: (qmail invoked by alias); 20 Aug 2006 14:55:55 -0000 Received: from p54986990.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.105.144] by mail.gmx.net (mp018) with SMTP; 20 Aug 2006 16:55:55 +0200 X-Authenticated: #29516787 Message-ID: <44E877FF.10000@gmx.net> Date: Sun, 20 Aug 2006 16:55:59 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: emu@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Emu] EAP-GPSK: Ciphersuites X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi all, the current version of the document http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secret-01.txt still supports AES-EAX: +-----------+----+-------------+---------------+--------------------+ | CSuite/ | KS | Encryption | Integrity | Key Derivation | | Specifier | | | | Function | +-----------+----+-------------+---------------+--------------------+ | 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 | GKDF-128 | +-----------+----+-------------+---------------+--------------------+ At the IETF#66 EMU meeting AES CCM was suggested. Later, it got the impression that AES-CBC was more appreciated. Should we update the draft with AES-CBC? Ciao Hannes _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Aug 20 18:23:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEvhG-0000VI-3p; Sun, 20 Aug 2006 18:23:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEvhE-0000VC-NH for emu@ietf.org; Sun, 20 Aug 2006 18:23:08 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEvhD-0001tw-B9 for emu@ietf.org; Sun, 20 Aug 2006 18:23:08 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k7KMN3ZP030257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 20 Aug 2006 15:23:04 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-64-52.qualcomm.com [10.50.64.52]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7KMMxOO015830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 20 Aug 2006 15:23:02 -0700 (PDT) Message-Id: <7.0.1.0.2.20060820151614.04592850@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 20 Aug 2006 15:23:02 +0800 To: Hannes Tschofenig , emu@ietf.org From: Lakshminath Dondeti Subject: Re: [Emu] EAP-GPSK: Ciphersuites In-Reply-To: <44E877FF.10000@gmx.net> References: <44E877FF.10000@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org At the expense of generating some confusion, here is my take on this: The objection is to having to carry multiple integrity checksums in GPSK, if we used the combined mode *and* an integrity algorithm. I think CCM is fine for instance, the only catch is that we need to make sure and define AAD for CCM carefully to include appropriate data into the integrity checksum calculation. So, once we define CCM as the mode, we shouldn't need AES-CMAC-128 if encryption is being used. I would suggest using CCM and specifying the use of it fully so it can be used without misunderstandings. If you want me to put some time into writing that up, let me know. cheers, Lakshminath At 10:55 PM 8/20/2006, Hannes Tschofenig wrote: >Hi all, > >the current version of the document >http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secret-01.txt >still supports AES-EAX: > > +-----------+----+-------------+---------------+--------------------+ > | CSuite/ | KS | Encryption | Integrity | Key Derivation | > | Specifier | | | | Function | > +-----------+----+-------------+---------------+--------------------+ > | 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 | GKDF-128 | > +-----------+----+-------------+---------------+--------------------+ > >At the IETF#66 EMU meeting AES CCM was suggested. > >Later, it got the impression that AES-CBC was more appreciated. >Should we update the draft with AES-CBC? > >Ciao >Hannes > > >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Aug 21 12:10:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFCMJ-0008Et-L4; Mon, 21 Aug 2006 12:10:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFCMI-00089B-Bh for emu@ietf.org; Mon, 21 Aug 2006 12:10:38 -0400 Received: from web54408.mail.yahoo.com ([206.190.49.138]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GFCI5-0002Ex-3x for emu@ietf.org; Mon, 21 Aug 2006 12:06:18 -0400 Received: (qmail 29428 invoked by uid 60001); 21 Aug 2006 16:06:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=n682uen6GN1vc6IzFYfqadpRiM7jJkWGM/oqqVd5shFkZhzNT3Y77pIaJ8YCF5ybhR23M9vR8f36X6RFFeb5QMf/u9gkmrwsno5rFZg1fbSMpu0aFbfN1u9APlIJiouom7anJZlCHMxXKpykURjdw6XOh5NDAL57XmmaFy2CuOc= ; Message-ID: <20060821160616.29426.qmail@web54408.mail.yahoo.com> Received: from [67.181.83.189] by web54408.mail.yahoo.com via HTTP; Mon, 21 Aug 2006 09:06:16 PDT Date: Mon, 21 Aug 2006 09:06:16 -0700 (PDT) From: "M. Vanderveen" Subject: Re: [Emu] EAP-GPSK: Ciphersuites To: Hannes Tschofenig , emu@ietf.org In-Reply-To: <44E877FF.10000@gmx.net> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1837694866==" Errors-To: emu-bounces@ietf.org --===============1837694866== Content-Type: multipart/alternative; boundary="0-783658664-1156176376=:27777" Content-Transfer-Encoding: 8bit --0-783658664-1156176376=:27777 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Both are pretty popular. Why not list them both? As for which one to be mandatory to implement, someone should to a search through other systems (e.g. IEEE, IPSec) and see which one is most popular. Hannes Tschofenig wrote: Hi all, the current version of the document http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secret-01.txt still supports AES-EAX: +-----------+----+-------------+---------------+--------------------+ | CSuite/ | KS | Encryption | Integrity | Key Derivation | | Specifier | | | | Function | +-----------+----+-------------+---------------+--------------------+ | 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 | GKDF-128 | +-----------+----+-------------+---------------+--------------------+ At the IETF#66 EMU meeting AES CCM was suggested. Later, it got the impression that AES-CBC was more appreciated. Should we update the draft with AES-CBC? Ciao Hannes _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --------------------------------- Do you Yahoo!? Get on board. You're invited to try the new Yahoo! Mail Beta. --0-783658664-1156176376=:27777 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Both are pretty popular. Why not list them both? As for which one to be mandatory to implement, someone should to a search through other systems (e.g. IEEE, IPSec) and see which one is most popular.

Hannes Tschofenig <Hannes.Tschofenig@gmx.net> wrote:
Hi all,

the current version of the document
http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secret-01.txt
still supports AES-EAX:

+-----------+----+-------------+---------------+--------------------+
| CSuite/ | KS | Encryption | Integrity | Key Derivation |
| Specifier | | | | Function |
+-----------+----+-------------+---------------+--------------------+
| 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 | GKDF-128 |
+-----------+----+-------------+---------------+--------------------+

At the IETF#66 EMU meeting AES CCM was suggested.

Later, it got the impression that AES-CBC was more appreciated. Should
we update the draft with AES-CBC?

Ciao
Hannes


_______________________________________________
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

Do you Yahoo!?
Get on board. You're invited to try the new Yahoo! Mail Beta. --0-783658664-1156176376=:27777-- --===============1837694866== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --===============1837694866==-- From emu-bounces@ietf.org Tue Aug 22 05:12:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFSJE-0004e0-5o; Tue, 22 Aug 2006 05:12:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFSJC-0004dr-Hc for emu@ietf.org; Tue, 22 Aug 2006 05:12:30 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GFSJB-0003zI-3h for emu@ietf.org; Tue, 22 Aug 2006 05:12:30 -0400 Received: (qmail invoked by alias); 22 Aug 2006 09:12:28 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp010) with SMTP; 22 Aug 2006 11:12:28 +0200 X-Authenticated: #29516787 Message-ID: <44EACA80.8090701@gmx.net> Date: Tue, 22 Aug 2006 11:12:32 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Lakshminath Dondeti Subject: Re: [Emu] EAP-GPSK: Ciphersuites References: <44E877FF.10000@gmx.net> <7.0.1.0.2.20060820151614.04592850@qualcomm.com> In-Reply-To: <7.0.1.0.2.20060820151614.04592850@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Lakshminath, Lakshminath Dondeti schrieb: > At the expense of generating some confusion, here is my take on this: > > The objection is to having to carry multiple integrity checksums in > GPSK, if we used the combined mode *and* an integrity algorithm. I don't agree with you. There is no reason to optimize a few bits in a pre-shared secret method. Note that we are not talking about a protocol for data transfer. We wanted the flexibility to use different cipher suites. We do not only want to use cipher suites that provide authenticated encryption (since we almost have nothing to encrypt; currently 1 bit and almost no EAP method provides this functionality). Ciao Hannes > > I think CCM is fine for instance, the only catch is that we need to make > sure and define AAD for CCM carefully to include appropriate data into > the integrity checksum calculation. So, once we define CCM as the mode, > we shouldn't need AES-CMAC-128 if encryption is being used. > > I would suggest using CCM and specifying the use of it fully so it can > be used without misunderstandings. If you want me to put some time into > writing that up, let me know. > > cheers, > Lakshminath > > At 10:55 PM 8/20/2006, Hannes Tschofenig wrote: >> Hi all, >> >> the current version of the document >> http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secret-01.txt >> still supports AES-EAX: >> >> +-----------+----+-------------+---------------+--------------------+ >> | CSuite/ | KS | Encryption | Integrity | Key Derivation | >> | Specifier | | | | Function | >> +-----------+----+-------------+---------------+--------------------+ >> | 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 | GKDF-128 | >> +-----------+----+-------------+---------------+--------------------+ >> >> At the IETF#66 EMU meeting AES CCM was suggested. >> >> Later, it got the impression that AES-CBC was more appreciated. Should >> we update the draft with AES-CBC? >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www1.ietf.org/mailman/listinfo/emu > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Aug 22 05:26:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFSWu-0000Y9-HS; Tue, 22 Aug 2006 05:26:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFSWt-0000Y3-Bq for emu@ietf.org; Tue, 22 Aug 2006 05:26:39 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GFSWr-0005jG-Ul for emu@ietf.org; Tue, 22 Aug 2006 05:26:39 -0400 Received: (qmail invoked by alias); 22 Aug 2006 09:19:57 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp031) with SMTP; 22 Aug 2006 11:19:57 +0200 X-Authenticated: #29516787 Message-ID: <44EACC41.1000506@gmx.net> Date: Tue, 22 Aug 2006 11:20:01 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "M. Vanderveen" Subject: Re: [Emu] EAP-GPSK: Ciphersuites References: <20060821160616.29426.qmail@web54408.mail.yahoo.com> In-Reply-To: <20060821160616.29426.qmail@web54408.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi let us for a moment assume that RFC 4307 makes some reasonable algorithm choices (we are talking about IKEv2 here). If we take the text and apply it to EAP-GPSK then we would produce something like: Conservative Choice: ----------------------- (Integrity) AUTH_HMAC_SHA1_96 2 [RFC2404] MUST (Encryption) ENCR_3DES 3 [RFC2451] MUST- (Key Derivation) PRF_HMAC_SHA1 2 [RFC2104] MUST (Note that there is no MUST for encryption algorithms specified in RFC 4307.) Choice for the Future: ----------------------- (Encryption) ENCR_AES_CBC 12 [AES-CBC] SHOULD+ (Integrity) AUTH_AES_XCBC_96 5 [AES-MAC] SHOULD+ (Key Derivation) PRF_AES128_CBC 4 [AESPRF] SHOULD+ Does this sound like a terrible bad idea? Ciao Hannes M. Vanderveen schrieb: > Both are pretty popular. Why not list them both? As for which one to be > mandatory to implement, someone should to a search through other systems > (e.g. IEEE, IPSec) and see which one is most popular. > > */Hannes Tschofenig /* wrote: > > Hi all, > > the current version of the document > http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secret-01.txt > still supports AES-EAX: > > +-----------+----+-------------+---------------+--------------------+ > | CSuite/ | KS | Encryption | Integrity | Key Derivation | > | Specifier | | | | Function | > +-----------+----+-------------+---------------+--------------------+ > | 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 | GKDF-128 | > +-----------+----+-------------+---------------+--------------------+ > > At the IETF#66 EMU meeting AES CCM was suggested. > > Later, it got the impression that AES-CBC was more appreciated. Should > we update the draft with AES-CBC? > > Ciao > Hannes > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > > > ------------------------------------------------------------------------ > Do you Yahoo!? > Get on board. You're invited > > to try the new Yahoo! Mail Beta. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Aug 22 05:44:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFSoK-0006fj-CC; Tue, 22 Aug 2006 05:44:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFSoJ-0006fe-6F for emu@ietf.org; Tue, 22 Aug 2006 05:44:39 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFSoH-0008VA-Qg for emu@ietf.org; Tue, 22 Aug 2006 05:44:39 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k7M9iNS9016217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 22 Aug 2006 02:44:23 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-72-125.qualcomm.com [10.50.72.125]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7M9iKqs022530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Aug 2006 02:44:22 -0700 (PDT) Message-Id: <7.0.1.0.2.20060822174100.042f0df8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 22 Aug 2006 17:44:21 +0800 To: Hannes Tschofenig From: Lakshminath Dondeti Subject: Re: [Emu] EAP-GPSK: Ciphersuites In-Reply-To: <44EACA80.8090701@gmx.net> References: <44E877FF.10000@gmx.net> <7.0.1.0.2.20060820151614.04592850@qualcomm.com> <44EACA80.8090701@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I guess we agree to disagree. The addition integrity checksum is spurious in my view and I believe we can define things so that combined modes can be employed without encrypting anything, so I am somewhat confused here. What's your opinion on the latter part of my email? thanks, Lakshminath At 05:12 PM 8/22/2006, Hannes Tschofenig wrote: >Hi Lakshminath, > >Lakshminath Dondeti schrieb: >>At the expense of generating some confusion, here is my take on this: >>The objection is to having to carry multiple integrity checksums in >>GPSK, if we used the combined mode *and* an integrity algorithm. > >I don't agree with you. There is no reason to optimize a few bits in >a pre-shared secret method. >Note that we are not talking about a protocol for data transfer. >We wanted the flexibility to use different cipher suites. We do not >only want to use cipher suites that provide authenticated encryption >(since we almost have nothing to encrypt; currently 1 bit and almost >no EAP method provides this functionality). > >Ciao >Hannes > >>I think CCM is fine for instance, the only catch is that we need to >>make sure and define AAD for CCM carefully to include appropriate >>data into the integrity checksum calculation. So, once we define >>CCM as the mode, we shouldn't need AES-CMAC-128 if encryption is being used. >>I would suggest using CCM and specifying the use of it fully so it >>can be used without misunderstandings. If you want me to put some >>time into writing that up, let me know. >>cheers, >>Lakshminath >>At 10:55 PM 8/20/2006, Hannes Tschofenig wrote: >>>Hi all, >>> >>>the current version of the document >>>http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secret-01.txt >>>still supports AES-EAX: >>> >>> +-----------+----+-------------+---------------+--------------------+ >>> | CSuite/ | KS | Encryption | Integrity | Key Derivation | >>> | Specifier | | | | Function | >>> +-----------+----+-------------+---------------+--------------------+ >>> | 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 | GKDF-128 | >>> +-----------+----+-------------+---------------+--------------------+ >>> >>>At the IETF#66 EMU meeting AES CCM was suggested. >>> >>>Later, it got the impression that AES-CBC was more appreciated. >>>Should we update the draft with AES-CBC? >>> >>>Ciao >>>Hannes >>> >>> >>>_______________________________________________ >>>Emu mailing list >>>Emu@ietf.org >>>https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Aug 22 07:04:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFU3k-0005Kp-Hl; Tue, 22 Aug 2006 07:04:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFU3j-0005Kk-N8 for emu@ietf.org; Tue, 22 Aug 2006 07:04:39 -0400 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFU3h-0008Hk-BQ for emu@ietf.org; Tue, 22 Aug 2006 07:04:39 -0400 Received: from [192.168.0.4] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (rwcrmhc11) with ESMTP id <20060822110436m11002tr2je>; Tue, 22 Aug 2006 11:04:36 +0000 Message-ID: <44EAE4C4.8020404@cs.umd.edu> Date: Tue, 22 Aug 2006 07:04:36 -0400 From: Charles Clancy User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Lakshminath Dondeti Subject: Re: [Emu] EAP-GPSK: Ciphersuites References: <44E877FF.10000@gmx.net> <7.0.1.0.2.20060820151614.04592850@qualcomm.com> <44EACA80.8090701@gmx.net> <7.0.1.0.2.20060822174100.042f0df8@qualcomm.com> In-Reply-To: <7.0.1.0.2.20060822174100.042f0df8@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Interesting idea, but what does it gain you? Why not just use an AES-CBC and CMAC ciphersuite? -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Lakshminath Dondeti wrote: > I guess we agree to disagree. The addition integrity checksum is > spurious in my view and I believe we can define things so that combined > modes can be employed without encrypting anything, so I am somewhat > confused here. What's your opinion on the latter part of my email? > > thanks, > Lakshminath > > At 05:12 PM 8/22/2006, Hannes Tschofenig wrote: >> Hi Lakshminath, >> >> Lakshminath Dondeti schrieb: >>> At the expense of generating some confusion, here is my take on this: >>> The objection is to having to carry multiple integrity checksums in >>> GPSK, if we used the combined mode *and* an integrity algorithm. >> >> I don't agree with you. There is no reason to optimize a few bits in a >> pre-shared secret method. >> Note that we are not talking about a protocol for data transfer. >> We wanted the flexibility to use different cipher suites. We do not >> only want to use cipher suites that provide authenticated encryption >> (since we almost have nothing to encrypt; currently 1 bit and almost >> no EAP method provides this functionality). >> >> Ciao >> Hannes >> >>> I think CCM is fine for instance, the only catch is that we need to >>> make sure and define AAD for CCM carefully to include appropriate >>> data into the integrity checksum calculation. So, once we define CCM >>> as the mode, we shouldn't need AES-CMAC-128 if encryption is being used. >>> I would suggest using CCM and specifying the use of it fully so it >>> can be used without misunderstandings. If you want me to put some >>> time into writing that up, let me know. >>> cheers, >>> Lakshminath >>> At 10:55 PM 8/20/2006, Hannes Tschofenig wrote: >>>> Hi all, >>>> >>>> the current version of the document >>>> http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secret-01.txt >>>> still supports AES-EAX: >>>> >>>> >>>> +-----------+----+-------------+---------------+--------------------+ >>>> | CSuite/ | KS | Encryption | Integrity | Key >>>> Derivation | >>>> | Specifier | | | | >>>> Function | >>>> >>>> +-----------+----+-------------+---------------+--------------------+ >>>> | 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 | >>>> GKDF-128 | >>>> >>>> +-----------+----+-------------+---------------+--------------------+ >>>> >>>> At the IETF#66 EMU meeting AES CCM was suggested. >>>> >>>> Later, it got the impression that AES-CBC was more appreciated. >>>> Should we update the draft with AES-CBC? >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>> _______________________________________________ >>>> Emu mailing list >>>> Emu@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/emu > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Aug 22 07:24:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFUMo-0002Vd-QL; Tue, 22 Aug 2006 07:24:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFUMn-0002VL-EQ for emu@ietf.org; Tue, 22 Aug 2006 07:24:21 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFUK9-0003k5-4d for emu@ietf.org; Tue, 22 Aug 2006 07:21:40 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k7MBLVx6026980; Tue, 22 Aug 2006 13:21:31 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k7MBLV9v007161; Tue, 22 Aug 2006 13:21:31 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 13:21:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Emu] EAP-GPSK: Ciphersuites Date: Tue, 22 Aug 2006 13:21:30 +0200 Message-ID: In-Reply-To: <7.0.1.0.2.20060822174100.042f0df8@qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EAP-GPSK: Ciphersuites Thread-Index: AcbF0DIyame7nrMuSNe9sPJCCer4fAAAXCaw From: "Tschofenig, Hannes" To: "Lakshminath Dondeti" , "Hannes Tschofenig" X-OriginalArrivalTime: 22 Aug 2006 11:21:30.0912 (UTC) FILETIME=[1E0B0200:01C6C5DD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Lakshminath,=20 I am not sure that the group wants to use CCM.=20 (If you are referring to this part of your mail.) Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20 > Gesendet: Dienstag, 22. August 2006 11:44 > An: Hannes Tschofenig > Cc: emu@ietf.org > Betreff: Re: [Emu] EAP-GPSK: Ciphersuites >=20 > I guess we agree to disagree. The addition integrity checksum is=20 > spurious in my view and I believe we can define things so that=20 > combined modes can be employed without encrypting anything, so I am=20 > somewhat confused here. What's your opinion on the latter=20 > part of my email? >=20 > thanks, > Lakshminath >=20 > At 05:12 PM 8/22/2006, Hannes Tschofenig wrote: > >Hi Lakshminath, > > > >Lakshminath Dondeti schrieb: > >>At the expense of generating some confusion, here is my=20 > take on this: > >>The objection is to having to carry multiple integrity checksums in=20 > >>GPSK, if we used the combined mode *and* an integrity algorithm. > > > >I don't agree with you. There is no reason to optimize a few bits in=20 > >a pre-shared secret method. > >Note that we are not talking about a protocol for data transfer. > >We wanted the flexibility to use different cipher suites. We do not=20 > >only want to use cipher suites that provide authenticated encryption=20 > >(since we almost have nothing to encrypt; currently 1 bit and almost=20 > >no EAP method provides this functionality). > > > >Ciao > >Hannes > > > >>I think CCM is fine for instance, the only catch is that we need to=20 > >>make sure and define AAD for CCM carefully to include appropriate=20 > >>data into the integrity checksum calculation. So, once we define=20 > >>CCM as the mode, we shouldn't need AES-CMAC-128 if=20 > encryption is being used. > >>I would suggest using CCM and specifying the use of it fully so it=20 > >>can be used without misunderstandings. If you want me to put some=20 > >>time into writing that up, let me know. > >>cheers, > >>Lakshminath > >>At 10:55 PM 8/20/2006, Hannes Tschofenig wrote: > >>>Hi all, > >>> > >>>the current version of the document > >>>http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-se cret-01.txt > >>>still supports AES-EAX: > >>> > >>> =20 > +-----------+----+-------------+---------------+--------------------+ > >>> | CSuite/ | KS | Encryption | Integrity | Key=20 > Derivation | > >>> | Specifier | | | |=20 > Function | > >>> =20 > +-----------+----+-------------+---------------+--------------------+ > >>> | 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 |=20 > GKDF-128 | > >>> =20 > +-----------+----+-------------+---------------+--------------------+ > >>> > >>>At the IETF#66 EMU meeting AES CCM was suggested. > >>> > >>>Later, it got the impression that AES-CBC was more appreciated.=20 > >>>Should we update the draft with AES-CBC? > >>> > >>>Ciao > >>>Hannes > >>> > >>> > >>>_______________________________________________ > >>>Emu mailing list > >>>Emu@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/emu >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Aug 22 15:14:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFbi4-0006Z4-Je; Tue, 22 Aug 2006 15:14:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFbi4-0006Yu-1Q for emu@ietf.org; Tue, 22 Aug 2006 15:14:48 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFZA1-00072f-Ei for emu@ietf.org; Tue, 22 Aug 2006 12:31:29 -0400 Received: from bay0-omc2-s20.bay0.hotmail.com ([65.54.246.156]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFZ8K-0003oO-Jk for emu@ietf.org; Tue, 22 Aug 2006 12:29:45 -0400 Received: from hotmail.com ([65.54.161.43]) by bay0-omc2-s20.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 09:29:43 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 22 Aug 2006 09:29:43 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 22 Aug 2006 16:29:40 GMT X-Originating-IP: [24.16.73.85] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <44EACC41.1000506@gmx.net> From: "Bernard Aboba" To: Hannes.Tschofenig@gmx.net, mvandervn@yahoo.com Bcc: Subject: Re: [Emu] EAP-GPSK: Ciphersuites Date: Tue, 22 Aug 2006 09:29:40 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 22 Aug 2006 16:29:43.0387 (UTC) FILETIME=[2C6AC2B0:01C6C608] X-Spam-Score: -2.4 (--) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org > >let us for a moment assume that RFC 4307 makes some reasonable algorithm >choices (we are talking about IKEv2 here). If we take the text and apply it >to EAP-GPSK then we would produce something like: > >Conservative Choice: >----------------------- > >(Integrity) > AUTH_HMAC_SHA1_96 2 [RFC2404] MUST > >(Encryption) > ENCR_3DES 3 [RFC2451] MUST- > >(Key Derivation) > PRF_HMAC_SHA1 2 [RFC2104] MUST > >(Note that there is no MUST for encryption algorithms specified in RFC >4307.) > > >Choice for the Future: >----------------------- > >(Encryption) > ENCR_AES_CBC 12 [AES-CBC] SHOULD+ > >(Integrity) > AUTH_AES_XCBC_96 5 [AES-MAC] SHOULD+ > >(Key Derivation) > PRF_AES128_CBC 4 [AESPRF] SHOULD+ > >Does this sound like a terrible bad idea? Actually, it sounds reasonable to me. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Aug 22 17:44:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFe2X-0000GE-8s; Tue, 22 Aug 2006 17:44:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFe2V-0000G9-UM for emu@ietf.org; Tue, 22 Aug 2006 17:44:03 -0400 Received: from mail712.megamailservers.com ([69.49.98.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFe2U-0001jC-L1 for emu@ietf.org; Tue, 22 Aug 2006 17:44:03 -0400 X-Authenticated-User: ray.grid-net.com Received: from RBLAPTOP (h-68-167-203-99.snfccasy.covad.net [68.167.203.99]) (authenticated bits=0) by mail712.megamailservers.com (8.13.6/8.13.1) with ESMTP id k7MLhdZ1004795; Tue, 22 Aug 2006 17:43:45 -0400 From: "Ray Bell" To: "'Bernard Aboba'" , , Subject: RE: [Emu] EAP-GPSK: Ciphersuites Date: Tue, 22 Aug 2006 14:43:37 -0700 Message-ID: <002001c6c634$0ed7a390$63cba744@RBLAPTOP> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbGH06AeP5sE6JMTPKtroMIUQvUbgAD1Xmg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-reply-to: X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org (Encryption) ENCR_3DES Comment: In October 1999, FIPS 64-3 the former specification for 3DES was withdrawn, so it would be better to cite "National Institute of Standards and Technology, Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, Special Publication 800-67, May 2004" than RFC2451 (Integrity) AUTH_HMAC_SHA1_96 and (Key Derivation) PRF_HMAC_SHA1 Comment: With respect to requiring SHA1, consideration should be given to the following NIST guidelines that were issued on March 15, 2006: "The SHA-2 family of hash functions (i.e., SHA-224, SHA-256, SHA-384 and SHA-512) may be used by Federal agencies for all applications using secure hash algorithms. Federal agencies should stop using SHA-1 for digital signatures, digital time stamping and other applications that require collision resistance as soon as practical, and must use the SHA-2 family of hash functions for these applications after 2010." Ray Bell Grid Net, Inc. -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: Tuesday, August 22, 2006 9:30 AM To: Hannes.Tschofenig@gmx.net; mvandervn@yahoo.com Cc: emu@ietf.org Subject: Re: [Emu] EAP-GPSK: Ciphersuites > >let us for a moment assume that RFC 4307 makes some reasonable algorithm >choices (we are talking about IKEv2 here). If we take the text and apply it >to EAP-GPSK then we would produce something like: > >Conservative Choice: >----------------------- > >(Integrity) > AUTH_HMAC_SHA1_96 2 [RFC2404] MUST > >(Encryption) > ENCR_3DES 3 [RFC2451] MUST- > >(Key Derivation) > PRF_HMAC_SHA1 2 [RFC2104] MUST > >(Note that there is no MUST for encryption algorithms specified in RFC >4307.) > > >Choice for the Future: >----------------------- > >(Encryption) > ENCR_AES_CBC 12 [AES-CBC] SHOULD+ > >(Integrity) > AUTH_AES_XCBC_96 5 [AES-MAC] SHOULD+ > >(Key Derivation) > PRF_AES128_CBC 4 [AESPRF] SHOULD+ > >Does this sound like a terrible bad idea? Actually, it sounds reasonable to me. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Aug 23 04:03:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFni9-0006MY-US; Wed, 23 Aug 2006 04:03:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFni9-0006MT-0R for emu@ietf.org; Wed, 23 Aug 2006 04:03:41 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GFni7-0001bI-HI for emu@ietf.org; Wed, 23 Aug 2006 04:03:40 -0400 Received: (qmail invoked by alias); 23 Aug 2006 08:03:38 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp027) with SMTP; 23 Aug 2006 10:03:38 +0200 X-Authenticated: #29516787 Message-ID: <44EC0BDE.6020905@gmx.net> Date: Wed, 23 Aug 2006 10:03:42 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Ray Bell Subject: Re: [Emu] EAP-GPSK: Ciphersuites References: <002001c6c634$0ed7a390$63cba744@RBLAPTOP> In-Reply-To: <002001c6c634$0ed7a390$63cba744@RBLAPTOP> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: 'Bernard Aboba' , emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Ray, thanks for your thoughts on this subject. Ray Bell schrieb: > (Encryption) > ENCR_3DES > > Comment: In October 1999, FIPS 64-3 the former specification for 3DES was > withdrawn, so it would be better to cite "National Institute of Standards > and Technology, Recommendation for the Triple Data Encryption Algorithm > (TDEA) Block Cipher, Special Publication 800-67, May 2004" than RFC2451 > Maybe someone should also update RFC 4307 to add a MUST for encryption pointing to the changed reference or to add something else there. For EAP-GPSK: A good hint. > > (Integrity) > AUTH_HMAC_SHA1_96 > and > (Key Derivation) > PRF_HMAC_SHA1 > > Comment: With respect to requiring SHA1, consideration should be given to > the following NIST guidelines that were issued on March 15, 2006: > > "The SHA-2 family of hash functions (i.e., SHA-224, SHA-256, SHA-384 and > SHA-512) may be used by Federal agencies for all applications using secure > hash algorithms. Federal agencies should stop using SHA-1 for digital > signatures, digital time stamping and other applications that require > collision resistance as soon as practical, and must use the SHA-2 family of > hash functions for these applications after 2010." > That's inline with the two sets of cipher suites where one aims for a usage in the future (denoted as SHOULD+) and the other one for a more near-time usage (MUST). RFC 4307 says that AES128_CBC is a SHOULD+ as a pseudo random function. Ciao Hannes > > > Ray Bell > Grid Net, Inc. > > > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: Tuesday, August 22, 2006 9:30 AM > To: Hannes.Tschofenig@gmx.net; mvandervn@yahoo.com > Cc: emu@ietf.org > Subject: Re: [Emu] EAP-GPSK: Ciphersuites > >> let us for a moment assume that RFC 4307 makes some reasonable algorithm >> choices (we are talking about IKEv2 here). If we take the text and apply it > >> to EAP-GPSK then we would produce something like: >> >> Conservative Choice: >> ----------------------- >> >> (Integrity) >> AUTH_HMAC_SHA1_96 2 [RFC2404] MUST >> >> (Encryption) >> ENCR_3DES 3 [RFC2451] MUST- >> >> (Key Derivation) >> PRF_HMAC_SHA1 2 [RFC2104] MUST >> >> (Note that there is no MUST for encryption algorithms specified in RFC >> 4307.) >> >> >> Choice for the Future: >> ----------------------- >> >> (Encryption) >> ENCR_AES_CBC 12 [AES-CBC] SHOULD+ >> >> (Integrity) >> AUTH_AES_XCBC_96 5 [AES-MAC] SHOULD+ >> >> (Key Derivation) >> PRF_AES128_CBC 4 [AESPRF] SHOULD+ >> >> Does this sound like a terrible bad idea? > > Actually, it sounds reasonable to me. > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Aug 23 20:13:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG2qL-0005Os-4b; Wed, 23 Aug 2006 20:13:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG2qI-0005On-ML for emu@ietf.org; Wed, 23 Aug 2006 20:13:07 -0400 Received: from bay0-omc1-s37.bay0.hotmail.com ([65.54.246.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG2qG-000067-CP for emu@ietf.org; Wed, 23 Aug 2006 20:13:06 -0400 Received: from hotmail.com ([65.54.161.17]) by bay0-omc1-s37.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 17:13:03 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 23 Aug 2006 17:13:03 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Thu, 24 Aug 2006 00:13:02 GMT X-Originating-IP: [71.37.13.64] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <44EC0BDE.6020905@gmx.net> From: "Bernard Aboba" To: emu@ietf.org Bcc: Date: Wed, 23 Aug 2006 17:13:02 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 24 Aug 2006 00:13:03.0369 (UTC) FILETIME=[10E91F90:01C6C712] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Emu] RFC 2716bis update X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org At IETF 66, we discussed a number of issues, including: o Optional privacy support o Ciphersuite support o Changes from RFC 2716 I've updated RFC 2716bis to include a new section 2.7 on privacy, have clarified the ciphersuite requirements, and have included an Appendix A on changes from RFC 2716. I have also updated the examples to include one on privacy and fix some mistakes. I also found a problem in Section 2.2 where the EAP server is being said to handle retransmissions rather than the EAP authenticator. The strawman -03 document is available here: http://www.drizzle.com/~aboba/EAP/draft-simon-emu-rfc2716bis-03.txt _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Aug 23 20:40:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG3Gk-0000TX-86; Wed, 23 Aug 2006 20:40:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDMve-0000TB-Br for emu@ietf.org; Wed, 16 Aug 2006 11:03:34 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDMvc-0006AW-2b for emu@ietf.org; Wed, 16 Aug 2006 11:03:34 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 16 Aug 2006 08:03:31 -0700 X-IronPort-AV: i="4.08,132,1154934000"; d="scan'208"; a="336563633:sNHT33020908" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7GF3VWC009240; Wed, 16 Aug 2006 08:03:31 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7GF3V1E007190; Wed, 16 Aug 2006 08:03:31 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 08:03:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] EMU WG issues tracker? Date: Wed, 16 Aug 2006 08:03:27 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250279D2A2@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EMU WG issues tracker? Thread-Index: AcasK6FHW7ZvdP/eTgmdm/cfw3GPqwUrnzDwAAEUzCAAGZxCUA== From: "Glen Zorn \(gwz\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 16 Aug 2006 15:03:31.0137 (UTC) FILETIME=[23098B10:01C6C145] DKIM-Signature: a=rsa-sha1; q=dns; l=142; t=1155740611; x=1156604611; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20[Emu]=20EMU=20WG=20issues=20tracker?; X=v=3Dcisco.com=3B=20h=3D4cI2zYPZlcZW7XfgS3QuMqe0az8=3D; b=jNhEYHt8zBfOTbkYM008bVL8IGnIDWDxZNOdzou4s10fXIvk6kUbWrbyO52vPLp7TuxcaAG3 xYaXYOaWnKsH/Aoi5vRxFJVfpbCMeOLcicLwfkU7zYglmGwbixflFWP/; Authentication-Results: sj-dkim-2.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db X-Mailman-Approved-At: Wed, 23 Aug 2006 20:40:25 -0400 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Bernard Aboba supposedly scribbled: > Does the EMU WG have an issues tracker? I certainly hope not. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Aug 23 21:15:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG3oJ-0002yx-Qj; Wed, 23 Aug 2006 21:15:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG3oI-0002ys-Ai for emu@ietf.org; Wed, 23 Aug 2006 21:15:06 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG3oB-0001zW-Ls for emu@ietf.org; Wed, 23 Aug 2006 21:15:06 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 23 Aug 2006 18:15:00 -0700 X-IronPort-AV: i="4.08,162,1154934000"; d="scan'208"; a="313362203:sNHT35131252" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7O1Ex6M018876 for ; Wed, 23 Aug 2006 18:14:59 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7O1Ew6W000883 for ; Wed, 23 Aug 2006 18:14:58 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 18:14:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Aug 2006 18:06:50 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new authenticated encryption draft and a proposed use inEMU GPSK Thread-Index: AcbHF+sig/1MNEzrQhyaW6L0jDDQegAAX7Sw From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 24 Aug 2006 01:14:58.0451 (UTC) FILETIME=[B745A630:01C6C71A] DKIM-Signature: a=rsa-sha1; q=dns; l=4265; t=1156382099; x=1157246099; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:new=20authenticated=20encryption=20draft=20and=20a=20proposed=20use=20in EMU=20GPSK; X=v=3Dcisco.com=3B=20h=3DUPJhATe+ysIWUFNgLbE+raBen68=3D; b=NmK7Oqp2UED0w7FjdiYwPaNoffjwoNSjAAm9uqCbtk+VG42i7IJ2AOd4EfH8VxJGnnwGkBKB 80qrfwlzab1CyUBVFTB5/KTIUIDUd/hNDi/19U7tudq2obaRkMaoMPpr; Authentication-Results: sj-dkim-6.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Subject: [Emu] new authenticated encryption draft and a proposed use inEMU GPSK X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org =20 > -----Original Message----- > From: emu-bounces@machshav.com=20 > [mailto:emu-bounces@machshav.com] On Behalf Of David A. McGrew > Sent: Friday, August 18, 2006 11:48 AM > To: emu@machshav.com; Hannes Tschofenig; Charles Clancy > Subject: [Emudt] new authenticated encryption draft and a=20 > proposed use inEMU GPSK >=20 > Hi Hannes, Charles, and others, >=20 > I've recently submitted an ID that defines a set of=20 > application- independent authenticated encryption algorithms,=20 > and I'd like to propose that it be used in=20 > draft-clancy-emu-eap-shared-secret-01 and/ or in other work=20 > in this area. It is online at http://=20 > www.mindspring.com/~dmcgrew/draft-mcgrew-auth-enc-00.html,=20 > and the "Introduction" section explains its benefits. It is=20 > a very natural fit to the EMU work. >=20 > Here is how to use this new spec for the EMU shared secret method. =20 > Below I've adapted the EAP-GPSK protocol notation from=20 > Section 3 of draft-clancy-emu-eap-shared-secret, and defined=20 > how the fields of the messages relate to the inputs and=20 > outputs of an authenticated encryption algorithm (defined at=20 > http://www.mindspring.com/~dmcgrew/ > draft-mcgrew-auth-enc-00.html#anchor3): >=20 > Authenticated encryption inputs: > K =3D secret key > AAD =3D additional authenticated (but not encrypted) data > P =3D plaintext >=20 > Authenticated encryption outputs: > C =3D ciphertext > IV =3D initialization vector > T =3D authentication tag >=20 > GPSK using the authenticated encryption interface: >=20 > GPSK-1 :=3D ID_Server, RAND_Server, CSuite_List >=20 > GPSK-2 :=3D ID_Client, ID_Server, RAND_Client, RAND_Server, > CSuite_List, CSuite_Sel [, Ciphertext1, ... ], ICV1 >=20 > AAD :=3D HDR2, ID_Client, ID_Server, RAND_Client,=20 > RAND_Server, CSuite_List, CSuite_Sel > P :=3D PD_Payload_1 > Ciphertext1 :=3D IV || C > ICV1 :=3D T >=20 > GPSK-3 :=3D RAND_Client, RAND_Server, CSuite_Sel [, Ciphertext2 ], > ICV2 >=20 > AAD :=3D HDR3, RAND_Client, RAND_Server, CSuite_Sel > P :=3D PD_Payload_2 > Ciphertext2 :=3D IV || C > ICV2 :=3D T >=20 > GPSK-4 :=3D [ Ciphertext_3, ] ICV >=20 > AAD :=3D HDR4 > P :=3D PD_Payload_3 > Ciphertext3 :=3D IV || C > ICV3 :=3D T >=20 >=20 > To leverage the authenticated encryption spec, large parts of=20 > Sections 5 and 6 in the GPSK draft would be replaced by=20 > references to the former document. This would have the=20 > effect of replacing the =20 > currently defined ciphersuites with slightly different ones. =20 > However, there are problems with the current definitions, so=20 > changes are needed in this area anyway. (Ciphersuite #1 is=20 > defined to use > AES-EAX-128 for encryption and AES-CMAC-128 for integrity, and =20 > includes a key derivation function to derive keys for each mode. =20 > This is a serious misuse of EAX, or a faulty explanation of=20 > the intended use of EAX, because that mode of operation can provide > *both* encryption and integrity, without the need for=20 > AES-CMAC or a key derivation function.) If no confidentiality=20 > is needed, this is indicated by providing a zero-length=20 > plaintext to the authenticated encryption algorithm, so there=20 > is no need for a separate authentication-only ciphersuite. >=20 > The authenticated encryption draft uses AES CCM instead of AES EAX, =20 > because CCM is widely supported and is approved for use in=20 > FIPS-140. =20 > Of course, the really important thing about the authenticated=20 > encryption draft is the interface that it defines, and if=20 > there is a need for a different authenticated encryption=20 > algorithm, it would be easy to add. FWIW I do think that the=20 > AE algorithms that are currently defined meet the EMU requirements. >=20 > Comments welcome. I'll be traveling over the next week, so=20 > my response time might lag a bit. >=20 > Best regards, >=20 > David > _______________________________________________ > Emu mailing list > Emu@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Aug 24 05:21:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGBP8-0007eI-MR; Thu, 24 Aug 2006 05:21:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGBP6-0007dw-OZ for emu@ietf.org; Thu, 24 Aug 2006 05:21:37 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GGBK2-00033x-W4 for emu@ietf.org; Thu, 24 Aug 2006 05:16:24 -0400 Received: (qmail invoked by alias); 24 Aug 2006 09:16:21 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp031) with SMTP; 24 Aug 2006 11:16:21 +0200 X-Authenticated: #29516787 Message-ID: <44ED6E68.8070703@gmx.net> Date: Thu, 24 Aug 2006 11:16:24 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: emu@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Subject: [Emu] Re: new authenticated encryption draft and a proposed use in EMU GPSK X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi David, I have a problem with the suggested approach for a couple of reasons: * There is no problem with the currently defined cipher suites. The design team has just picked something; Different cipher suites got proposed during the design team discussions and almost all of them got removed from the document. As you saw from the discussions and my previous mail to the EMU mailing list it seems that there is a shift towards AES CBC. That's fine with me. Whatever you propose there will be someone that does not like your selection for whatever reason. This is, btw, a very natural way to progressing document. You will not get things right the first time. * I don't like the split into two documents since it makes a simple protocol complicated. For EAP-GPSK I don't think that we will see 10+ cipher suites being proposed. * I don't see how the document is useful to other areas. The example section points to IPsec ESP; this is confusing for someone that only wants to implement a simple EAP method. Recall that we started with the goal to produce a simple EAP method as a replacement for EAP-MD5. Your document is unfortunately years too late. * Currently, we have the idea of putting 1 BIT!!!!! into the protected payload part of the message (and that's not yet even there in the document). Note, that it does not require encryption for this 1 bit. There is currently nothing in the document that requires encryption. We are wasting time on problems that do not exist. * This document will help to delay the work on EAP-GPSK for a year making it impossible to get EAP-GPSK deployed anytime in the near future. * IANA consideration: If your document is applicable to other environments then we might see plenty of cipher suites being specified. That's fine but does not really help us a lot to realize a simple EAP method. What cipher suites should folks implement? Should we then have an additional document that says "These are the cipher suites applicable for EAP GPSK? " You are essentially asking us to rewrite the entire draft to make it fit to your document just because you had the idea for a common registry? Sorry for my lack of excitement. Ciao Hannes David A. McGrew schrieb: > Hi Hannes, Charles, and others, > > I've recently submitted an ID that defines a set of > application-independent authenticated encryption algorithms, and I'd > like to propose that it be used in draft-clancy-emu-eap-shared-secret-01 > and/or in other work in this area. It is online at > http://www.mindspring.com/~dmcgrew/draft-mcgrew-auth-enc-00.html, and > the "Introduction" section explains its benefits. It is a very natural > fit to the EMU work. > > Here is how to use this new spec for the EMU shared secret method. > Below I've adapted the EAP-GPSK protocol notation from Section 3 of > draft-clancy-emu-eap-shared-secret, and defined how the fields of the > messages relate to the inputs and outputs of an authenticated encryption > algorithm (defined at > http://www.mindspring.com/~dmcgrew/draft-mcgrew-auth-enc-00.html#anchor3): > > Authenticated encryption inputs: > K = secret key > AAD = additional authenticated (but not encrypted) data > P = plaintext > > Authenticated encryption outputs: > C = ciphertext > IV = initialization vector > T = authentication tag > > GPSK using the authenticated encryption interface: > > GPSK-1 := ID_Server, RAND_Server, CSuite_List > > GPSK-2 := ID_Client, ID_Server, RAND_Client, RAND_Server, > CSuite_List, CSuite_Sel [, Ciphertext1, ... ], ICV1 > > AAD := HDR2, ID_Client, ID_Server, RAND_Client, RAND_Server, > CSuite_List, CSuite_Sel > P := PD_Payload_1 > Ciphertext1 := IV || C > ICV1 := T > > GPSK-3 := RAND_Client, RAND_Server, CSuite_Sel [, Ciphertext2 ], ICV2 > > AAD := HDR3, RAND_Client, RAND_Server, CSuite_Sel > P := PD_Payload_2 > Ciphertext2 := IV || C > ICV2 := T > > GPSK-4 := [ Ciphertext_3, ] ICV > > AAD := HDR4 > P := PD_Payload_3 > Ciphertext3 := IV || C > ICV3 := T > > > To leverage the authenticated encryption spec, large parts of Sections 5 > and 6 in the GPSK draft would be replaced by references to the former > document. This would have the effect of replacing the currently defined > ciphersuites with slightly different ones. However, there are problems > with the current definitions, so changes are needed in this area > anyway. (Ciphersuite #1 is defined to use AES-EAX-128 for encryption > and AES-CMAC-128 for integrity, and includes a key derivation function > to derive keys for each mode. This is a serious misuse of EAX, or a > faulty explanation of the intended use of EAX, because that mode of > operation can provide *both* encryption and integrity, without the need > for AES-CMAC or a key derivation function.) > If no confidentiality is needed, this is indicated by providing a > zero-length plaintext to the authenticated encryption algorithm, so > there is no need for a separate authentication-only ciphersuite. > > The authenticated encryption draft uses AES CCM instead of AES EAX, > because CCM is widely supported and is approved for use in FIPS-140. Of > course, the really important thing about the authenticated encryption > draft is the interface that it defines, and if there is a need for a > different authenticated encryption algorithm, it would be easy to add. > FWIW I do think that the AE algorithms that are currently defined meet > the EMU requirements. > > Comments welcome. I'll be traveling over the next week, so my response > time might lag a bit. > > Best regards, > > David > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Aug 24 08:33:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGEOX-0004Fb-LR; Thu, 24 Aug 2006 08:33:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGEOW-0004FW-6G for emu@ietf.org; Thu, 24 Aug 2006 08:33:12 -0400 Received: from bay0-omc1-s41.bay0.hotmail.com ([65.54.246.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGEOU-00082A-Sj for emu@ietf.org; Thu, 24 Aug 2006 08:33:12 -0400 Received: from hotmail.com ([65.54.161.36]) by bay0-omc1-s41.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 05:33:10 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 24 Aug 2006 05:33:10 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Thu, 24 Aug 2006 12:33:05 GMT X-Originating-IP: [24.16.73.85] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <44ED6E68.8070703@gmx.net> From: "Bernard Aboba" To: Hannes.Tschofenig@gmx.net, emu@ietf.org Bcc: Subject: RE: [Emu] Re: new authenticated encryption draft and a proposed use in EMU GPSK Date: Thu, 24 Aug 2006 05:33:05 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 24 Aug 2006 12:33:10.0205 (UTC) FILETIME=[75728ED0:01C6C779] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >Hi David, > >I have a problem with the suggested approach for a couple of reasons: > >* There is no problem with the currently defined cipher suites. The >design team has just picked something; Different cipher suites got >proposed during the design team discussions and almost all of them got >removed from the document. As you saw from the discussions and my previous >mail to the EMU mailing list it seems that there is a shift towards AES >CBC. That's fine with me. I agree with Hannes here. To date, EMU documents have been consistent with respect to the choice of ciphersuites - rmandating 3DES/HMAC-SHA1 ciphersuites today, transitioning to AES CBC tommorrow. Introducing a dependency on AES CCM for EAP GPSK is not advisable at this time, since FIPS 140-2 certified libraries for AES CCM are not common today, whereas support for AES CBC is more widespread. >* I don't like the split into two documents since it makes a simple >protocol complicated. For EAP-GPSK I don't think that we will see 10+ >cipher suites being proposed. The goal for EAP GPSK was to produce a simple, low footprint method that could be implemented easily in embedded devices. Splitting the specification in two parts, and introducing 10+ ciphersuites runs counter to that goal and and could risk introducing interoperability problems. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Aug 24 13:25:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGIxb-0003Ow-Jh; Thu, 24 Aug 2006 13:25:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGIxa-0003O6-9t for emu@ietf.org; Thu, 24 Aug 2006 13:25:42 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGIn0-0003iZ-GN for emu@ietf.org; Thu, 24 Aug 2006 13:14:48 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 24 Aug 2006 10:14:46 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7OHEkK5029600; Thu, 24 Aug 2006 10:14:46 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7OHEj1E015331; Thu, 24 Aug 2006 10:14:45 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 10:14:45 -0700 Received: from [128.107.163.125] ([128.107.163.125]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 10:14:45 -0700 Mime-Version: 1.0 (Apple Message framework v752.2) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8BAF633F-DCD9-4F67-8A72-25C62144384C@cisco.com> Content-Transfer-Encoding: 7bit From: David McGrew Date: Thu, 24 Aug 2006 10:14:46 -0700 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 24 Aug 2006 17:14:45.0116 (UTC) FILETIME=[CB9963C0:01C6C7A0] DKIM-Signature: a=rsa-sha1; q=dns; l=9489; t=1156439686; x=1157303686; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:David=20McGrew=20 |Subject:Fwd=3A=20new=20authenticated=20encryption=20draft=20and=20a=20proposed=2 0use=20in=20EMU=20GPSK; X=v=3Dcisco.com=3B=20h=3DxqoazVFSuqE44zMaSjUOePi3F0E=3D; b=evv8itiZxm49v2BLFj7bOqPsb29HUAfgxPMOnKCkUTuzN+o3Qj9lmtRBuu/sDdSavOb7t0Nb sBvNW/+Ed4hrXtptYOo/iQq+/+Qh3V13qMooo+H68bl9YTk8z7bU9eBv; Authentication-Results: sj-dkim-4.cisco.com; header.From=mcgrew@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: emu@ietf.org Subject: [Emu] Fwd: new authenticated encryption draft and a proposed use in EMU GPSK X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org re-sending from the mail account that's subscribed to the EMU list, sorry for the confusion Begin forwarded message: > From: David A. McGrew > Date: August 24, 2006 10:09:07 AM PDT > To: Hannes Tschofenig > Cc: Charles Clancy , emu@ietf.org > Subject: Re: new authenticated encryption draft and a proposed use > in EMU GPSK > > Hi Hannes, > > On Aug 24, 2006, at 1:23 AM, Hannes Tschofenig wrote: > >> Hi David, >> >> I have a problem with the suggested approach for a couple of reasons: >> >> * There is no problem with the currently defined cipher suites. The >> design team has just picked something; Different cipher suites got >> proposed during >> the design team discussions and almost all of them got removed >> from the >> document. As you saw from the discussions and my previous mail to the >> EMU mailing list it seems that there is a shift towards AES CBC. >> That's >> fine with me. > > That's a tangent; the choice of cipher suite is not the issue here. > >> >> Whatever you propose there will be someone that does not like your >> selection for whatever reason. >> >> This is, btw, a very natural way to progressing document. You will >> not >> get things right the first time. >> >> * I don't like the split into two documents since it makes a simple >> protocol complicated. For EAP-GPSK I don't think that we will see 10+ >> cipher suites being proposed. >> > > True enough, but EAP-GPSK will need to reference one or more > external algorithms anyway, CCM or EAX or both AES-CBC and a MAC > like HMAC-SHA1, if the preference towards CBC continues. > > It's worth noting that, if CBC encryption is included in GPSK, > there will be a need to design and review a 'generic composition' > algorithm of that mode with a MAC, and there will be the issue of > defining the interface(s) between the protocol and that algorithm > and the AEAD method(s) of CCM and/or EAX. The latter two > algorithms *already* use an interface that is nearly identical to > the one defined in the AEAD draft. Why not do all this work once > in a reusable way? > >> * I don't see how the document is useful to other areas. > > Why do you think the AEAD draft is not generally useful? Do you > think that the interface that it defines is too restrictive? Or > do you think that there is a scarcity of new applications for > symmetric encryption and authentication? > > AFAICT, new applications of crypto are defined all the time; for > example, there's now a motivation to put AES GCM into TLS. > Defining a uniform interface that these new applications can use > makes sense, and the AEAD model is a perfect fit. If the AEAD > interface definition isn't perfect, let's fix it. > >> The example >> section points to IPsec ESP; this is confusing for someone that only >> wants to implement a simple EAP method. >> > > Perhaps the specification didn't make clear enough that the > "Example Usage" section was informative and not normative. Also, > IMO it would be good to add a subsection showing an example usage > in a TLV-based protocol. > >> Recall that we started with the goal to produce a simple EAP >> method as a >> replacement for EAP-MD5. >> >> Your document is unfortunately years too late. >> >> * Currently, we have the idea of putting 1 BIT!!!!! into the >> protected >> payload part of the message (and that's not yet even there in the >> document). Note, that it does not require encryption for this 1 bit. >> There is currently nothing in the document that requires encryption. > > The security goals of GPSK line up with those of AEAD since > encryption is an option. For sure it adds complexity to the > protocol to have that option; that complexity is going to be there > regardless of how the encryption gets provided. > >> >> We are wasting time on problems that do not exist. >> >> * This document will help to delay the work on EAP-GPSK for a year >> making it impossible to get EAP-GPSK deployed anytime in the near >> future. > > That's a valid concern and I'm very sympathetic to it. > > One way to use some of the AEAD benefits while keeping the AEAD > specification off of the critical path of GPSK would be to have > GPSK be as compatible as possible with the AEAD draft, and have it > reference the AEAD draft as being informative. This wouldn't be > much effort, and it wouldn't hold up the GPSK draft. Heck, if CCM > or EAX is included in GPSK, then the work would need to be done > anyway. > >> >> * IANA consideration: If your document is applicable to other >> environments then we might see plenty of cipher suites being >> specified. >> That's fine but does not really help us a lot to realize a simple EAP >> methods. What methods should folks implement? Should we have a simple >> document that says "These are the cipher suites applicable for EAP >> GPSK? " > > If GPSK were written in terms of the AEAD specification, I'd expect > that it would indicate which algorithm was mandatory to implement. > It could also include SHOULD or MUST NOT guidance on algorithms, if > that seemed appropriate. > >> >> You are essentially asking us to rewrite the entire draft to make >> it fit to your document just because you had the idea for a common >> registry? > > Nonsense. I'm trying to bring the benefits (outlined in Section 1 > of the draft) of the AEAD idea from the theoretical crypto > community into the standards community. > > David > >> >> Sorry for my lack of excitement. >> >> Ciao >> Hannes >> >> David A. McGrew schrieb: >>> Hi Hannes, Charles, and others, >>> I've recently submitted an ID that defines a set of application- >>> independent authenticated encryption algorithms, and I'd like to >>> propose that it be used in draft-clancy-emu-eap-shared-secret-01 >>> and/or in other work in this area. It is online at http:// >>> www.mindspring.com/~dmcgrew/draft-mcgrew-auth-enc-00.html, and >>> the "Introduction" section explains its benefits. It is a very >>> natural fit to the EMU work. >>> Here is how to use this new spec for the EMU shared secret >>> method. Below I've adapted the EAP-GPSK protocol notation from >>> Section 3 of draft-clancy-emu-eap-shared-secret, and defined how >>> the fields of the messages relate to the inputs and outputs of an >>> authenticated encryption algorithm (defined at http:// >>> www.mindspring.com/~dmcgrew/draft-mcgrew-auth-enc-00.html#anchor3): >>> Authenticated encryption inputs: >>> K = secret key >>> AAD = additional authenticated (but not encrypted) data >>> P = plaintext >>> Authenticated encryption outputs: >>> C = ciphertext >>> IV = initialization vector >>> T = authentication tag >>> GPSK using the authenticated encryption interface: >>> GPSK-1 := ID_Server, RAND_Server, CSuite_List >>> GPSK-2 := ID_Client, ID_Server, RAND_Client, RAND_Server, >>> CSuite_List, CSuite_Sel [, Ciphertext1, ... ], ICV1 >>> AAD := HDR2, ID_Client, ID_Server, RAND_Client, >>> RAND_Server, CSuite_List, CSuite_Sel >>> P := PD_Payload_1 >>> Ciphertext1 := IV || C >>> ICV1 := T >>> GPSK-3 := RAND_Client, RAND_Server, CSuite_Sel [, >>> Ciphertext2 ], ICV2 >>> AAD := HDR3, RAND_Client, RAND_Server, CSuite_Sel >>> P := PD_Payload_2 >>> Ciphertext2 := IV || C >>> ICV2 := T >>> GPSK-4 := [ Ciphertext_3, ] ICV >>> AAD := HDR4 >>> P := PD_Payload_3 >>> Ciphertext3 := IV || C >>> ICV3 := T >>> To leverage the authenticated encryption spec, large parts of >>> Sections 5 and 6 in the GPSK draft would be replaced by >>> references to the former document. This would have the effect of >>> replacing the currently defined ciphersuites with slightly >>> different ones. However, there are problems with the current >>> definitions, so changes are needed in this area anyway. >>> (Ciphersuite #1 is defined to use AES-EAX-128 for encryption and >>> AES-CMAC-128 for integrity, and includes a key derivation >>> function to derive keys for each mode. This is a serious misuse >>> of EAX, or a faulty explanation of the intended use of EAX, >>> because that mode of operation can provide *both* encryption and >>> integrity, without the need for AES-CMAC or a key derivation >>> function.) >>> If no confidentiality is needed, this is indicated by providing a >>> zero-length plaintext to the authenticated encryption algorithm, >>> so there is no need for a separate authentication-only ciphersuite. >>> The authenticated encryption draft uses AES CCM instead of AES >>> EAX, because CCM is widely supported and is approved for use in >>> FIPS-140. Of course, the really important thing about the >>> authenticated encryption draft is the interface that it defines, >>> and if there is a need for a different authenticated encryption >>> algorithm, it would be easy to add. FWIW I do think that the AE >>> algorithms that are currently defined meet the EMU requirements. >>> Comments welcome. I'll be traveling over the next week, so my >>> response time might lag a bit. >>> Best regards, >>> David >> >> > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Aug 24 19:25:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGOZW-0002MZ-SR; Thu, 24 Aug 2006 19:25:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGOZV-0002MR-Rn; Thu, 24 Aug 2006 19:25:13 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGLSC-0006RP-4n; Thu, 24 Aug 2006 16:05:28 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGLDk-0005KL-4u; Thu, 24 Aug 2006 15:50:34 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 1352A2AC54; Thu, 24 Aug 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GGLDF-0000v9-RR; Thu, 24 Aug 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 24 Aug 2006 15:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: emu@ietf.org Subject: [Emu] I-D ACTION:draft-simon-emu-rfc2716bis-03.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update Working Group of the IETF. Title : The EAP TLS Authentication Protocol Author(s) : D. Simon, B. Aboba Filename : draft-simon-emu-rfc2716bis-03.txt Pages : 34 Date : 2006-8-24 The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Level Security (TLS) provides for mutual authentication, integrity- protected ciphersuite negotiation and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-simon-emu-rfc2716bis-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-simon-emu-rfc2716bis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-24131054.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-simon-emu-rfc2716bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-simon-emu-rfc2716bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-24131054.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --NextPart-- From emu-bounces@ietf.org Mon Aug 28 13:22:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHkp2-0001WF-UK; Mon, 28 Aug 2006 13:22:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHkp1-0001WA-O7 for emu@ietf.org; Mon, 28 Aug 2006 13:22:51 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHkp0-0007ZH-Bn for emu@ietf.org; Mon, 28 Aug 2006 13:22:51 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 28 Aug 2006 10:22:50 -0700 X-IronPort-AV: i="4.08,176,1154934000"; d="scan'208"; a="314942446:sNHT34418866" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7SHMnvs022596; Mon, 28 Aug 2006 10:22:49 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k7SHMnw7001804; Mon, 28 Aug 2006 10:22:49 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Aug 2006 10:22:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] EAP-GPSK: Ciphersuites Date: Mon, 28 Aug 2006 10:22:48 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EAP-GPSK: Ciphersuites Thread-Index: AcbFzRxRvYJQ1B0sT0uZqhYdDLk4xQE+S9fw From: "Joseph Salowey \(jsalowey\)" To: "Hannes Tschofenig" , "M. Vanderveen" X-OriginalArrivalTime: 28 Aug 2006 17:22:49.0477 (UTC) FILETIME=[95F40350:01C6CAC6] DKIM-Signature: a=rsa-sha1; q=dns; l=3325; t=1156785769; x=1157649769; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:RE=3A=20[Emu]=20EAP-GPSK=3A=20Ciphersuites; X=v=3Dcisco.com=3B=20h=3D2dulrjaYeLr0EwCAImBrFO70zqA=3D; b=B2Zr1rTL79BtvM0SwJnAXvsqyiB+TfQtfX71C0jFdBRw95T8Q7amEe4nUw1i28k3z/9bdCq5 YuTw8i+gr1opYfCJMfSffVMPh3rs5Ghg5duyQHxsaYrDjRWaB9GvfI9f; Authentication-Results: sj-dkim-7.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Is the proposal to make 3DES mandatory and AES optional?=20 It seems that we should be moving toward AES. Since this is a new method it may be better to make AES mandatory and 3DES optional. =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Tuesday, August 22, 2006 2:20 AM > To: M. Vanderveen > Cc: emu@ietf.org > Subject: Re: [Emu] EAP-GPSK: Ciphersuites >=20 > Hi >=20 > let us for a moment assume that RFC 4307 makes some=20 > reasonable algorithm choices (we are talking about IKEv2=20 > here). If we take the text and apply it to EAP-GPSK then we=20 > would produce something like: >=20 > Conservative Choice: > ----------------------- >=20 > (Integrity) > AUTH_HMAC_SHA1_96 2 [RFC2404] MUST >=20 > (Encryption) > ENCR_3DES 3 [RFC2451] MUST- >=20 > (Key Derivation) > PRF_HMAC_SHA1 2 [RFC2104] MUST >=20 > (Note that there is no MUST for encryption algorithms specified in RFC > 4307.) >=20 >=20 > Choice for the Future: > ----------------------- >=20 > (Encryption) > ENCR_AES_CBC 12 [AES-CBC] SHOULD+ >=20 > (Integrity) > AUTH_AES_XCBC_96 5 [AES-MAC] SHOULD+ >=20 > (Key Derivation) > PRF_AES128_CBC 4 [AESPRF] SHOULD+ >=20 > Does this sound like a terrible bad idea? >=20 > Ciao > Hannes >=20 > M. Vanderveen schrieb: > > Both are pretty popular. Why not list them both? As for=20 > which one to be=20 > > mandatory to implement, someone should to a search through=20 > other systems=20 > > (e.g. IEEE, IPSec) and see which one is most popular. > >=20 > > */Hannes Tschofenig /* wrote: > >=20 > > Hi all, > >=20 > > the current version of the document > > =20 > http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secret-01.txt > > still supports AES-EAX: > >=20 > > =20 > +-----------+----+-------------+---------------+--------------------+ > > | CSuite/ | KS | Encryption | Integrity | Key Derivation | > > | Specifier | | | | Function | > > =20 > +-----------+----+-------------+---------------+--------------------+ > > | 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 | GKDF-128 | > > =20 > +-----------+----+-------------+---------------+--------------------+ > >=20 > > At the IETF#66 EMU meeting AES CCM was suggested. > >=20 > > Later, it got the impression that AES-CBC was more=20 > appreciated. Should > > we update the draft with AES-CBC? > >=20 > > Ciao > > Hannes > >=20 > >=20 > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu > >=20 > >=20 > >=20 > -------------------------------------------------------------- > ---------- > > Do you Yahoo!? > > Get on board. You're invited=20 > >=20 > ahoo.com/handraisers>=20 > > to try the new Yahoo! Mail Beta. >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Aug 28 14:15:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHldX-0000Z7-C8; Mon, 28 Aug 2006 14:15:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHldW-0000Z2-5i for emu@ietf.org; Mon, 28 Aug 2006 14:15:02 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHldT-0001J7-MI for emu@ietf.org; Mon, 28 Aug 2006 14:15:02 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 28 Aug 2006 11:14:59 -0700 X-IronPort-AV: i="4.08,176,1154934000"; d="scan'208"; a="314969812:sNHT36410916" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7SIEw8T024386; Mon, 28 Aug 2006 11:14:58 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7SIEw6W011151; Mon, 28 Aug 2006 11:14:58 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Aug 2006 11:14:58 -0700 Received: from [192.168.1.100] ([10.32.254.211]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Aug 2006 11:14:57 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4A985FCF-ED5D-4EB5-B034-162EE1CBF1A0@cisco.com> Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: [Emu] EAP-GPSK: Ciphersuites Date: Mon, 28 Aug 2006 11:14:56 -0700 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 28 Aug 2006 18:14:58.0059 (UTC) FILETIME=[DEBBBDB0:01C6CACD] DKIM-Signature: a=rsa-sha1; q=dns; l=3633; t=1156788898; x=1157652898; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:David=20McGrew=20 |Subject:Re=3A=20[Emu]=20EAP-GPSK=3A=20Ciphersuites; X=v=3Dcisco.com=3B=20h=3DbVIcIhSDmSaT1Cxpa00uf1jA/Fc=3D; b=Y4n4eU0P5166guLWCcEJ++/9rW4IQkFTcioA7cAlptZFROjTZkQBQ/JMe5nMwUwDwR+cYuQh cawjj+XWaWHlTwz2tSWUE0usmC9umaPKioumSl4atMRBso99zjm2YRhC; Authentication-Results: sj-dkim-7.cisco.com; header.From=mcgrew@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Hannes, a few comments inline: > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Tuesday, August 22, 2006 2:20 AM > To: M. Vanderveen > Cc: emu@ietf.org > Subject: Re: [Emu] EAP-GPSK: Ciphersuites > > Hi > > let us for a moment assume that RFC 4307 makes some > reasonable algorithm choices (we are talking about IKEv2 > here). If we take the text and apply it to EAP-GPSK then we > would produce something like: > > Conservative Choice: > ----------------------- > > (Integrity) > AUTH_HMAC_SHA1_96 2 [RFC2404] MUST > > (Encryption) > ENCR_3DES 3 [RFC2451] MUST- I agree with Joe that AES is preferable to 3DES, barring some strong legacy considerations. > > (Key Derivation) > PRF_HMAC_SHA1 2 [RFC2104] MUST If it is a goal to conform to FIPS-140-2, that goal will probably drive the key derivation function choice in the direction of http:// www.ietf.org/internet-drafts/draft-dang-nistkdf-01.txt. (I like HMAC as a KDF, but I am not confident that it is going to be approved for that purpose within FIPS-140-2.) > > (Note that there is no MUST for encryption algorithms specified in RFC > 4307.) > > > Choice for the Future: > ----------------------- > > (Encryption) > ENCR_AES_CBC 12 [AES-CBC] SHOULD+ > > (Integrity) > AUTH_AES_XCBC_96 5 [AES-MAC] SHOULD+ OMAC is a better choice than XCBC, since it is FIPS-140 approved, and has some minor advantages (it's a refinement of XCBC that is unfortunately not backwards compatible with it). > > (Key Derivation) > PRF_AES128_CBC 4 [AESPRF] SHOULD+ > Same KDF considerations as above. David > Does this sound like a terrible bad idea? > > Ciao > Hannes > > M. Vanderveen schrieb: >> Both are pretty popular. Why not list them both? As for > which one to be >> mandatory to implement, someone should to a search through > other systems >> (e.g. IEEE, IPSec) and see which one is most popular. >> >> */Hannes Tschofenig /* wrote: >> >> Hi all, >> >> the current version of the document >> > http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secret-01.txt >> still supports AES-EAX: >> >> > +-----------+----+-------------+---------------+--------------------+ >> | CSuite/ | KS | Encryption | Integrity | Key Derivation | >> | Specifier | | | | Function | >> > +-----------+----+-------------+---------------+--------------------+ >> | 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 | GKDF-128 | >> > +-----------+----+-------------+---------------+--------------------+ >> >> At the IETF#66 EMU meeting AES CCM was suggested. >> >> Later, it got the impression that AES-CBC was more > appreciated. Should >> we update the draft with AES-CBC? >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www1.ietf.org/mailman/listinfo/emu >> >> >> > -------------------------------------------------------------- > ---------- >> Do you Yahoo!? >> Get on board. You're invited >> > ahoo.com/handraisers> >> to try the new Yahoo! Mail Beta. > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Aug 28 14:19:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHlhN-00033v-Lw; Mon, 28 Aug 2006 14:19:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHlhL-00033q-SY for emu@ietf.org; Mon, 28 Aug 2006 14:18:59 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHl1Z-0002qK-EY for emu@ietf.org; Mon, 28 Aug 2006 13:35:49 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHl0B-00021P-J8 for emu@ietf.org; Mon, 28 Aug 2006 13:34:25 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-6.cisco.com with ESMTP; 28 Aug 2006 10:34:23 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7SHYM7A031129; Mon, 28 Aug 2006 10:34:22 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7SHYM6Y018110; Mon, 28 Aug 2006 10:34:22 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Aug 2006 10:34:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] EAP-GPSK: Ciphersuites Date: Mon, 28 Aug 2006 10:34:20 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EAP-GPSK: Ciphersuites Thread-Index: AcbF2scsPQGlfSwvT2qIo2knAS/wJgE7DSiw From: "Joseph Salowey \(jsalowey\)" To: "Charles Clancy" , "Lakshminath Dondeti" X-OriginalArrivalTime: 28 Aug 2006 17:34:22.0468 (UTC) FILETIME=[33020C40:01C6CAC8] DKIM-Signature: a=rsa-sha1; q=dns; l=4166; t=1156786462; x=1157650462; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:RE=3A=20[Emu]=20EAP-GPSK=3A=20Ciphersuites; X=v=3Dcisco.com=3B=20h=3D2dulrjaYeLr0EwCAImBrFO70zqA=3D; b=ThgbNzX8FnkfzQRxdW4omWYvlByMMnBAZbFMVyxx1Fsi3TGWiF5FuPJfQCl+cR/WEQwnSigd 53mQGLGuku769lHidc1zctKj3Sm/wOF/o7BVBUvogX/KWd+z6/PASjcZ; Authentication-Results: sj-dkim-8.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org We want to define GPSK as a framework that can accommodate new algorithms when they are available. I believe that Lakshminath is looking to allow optimizations within this framework in the case where a combined mode cipher is used. At this point I'm not sure how much complexity this would add to the specification. If it can be done simply then it might be worthwhile pursuing, perhaps David McGrew's AEAD specification would help here. =20 > -----Original Message----- > From: Charles Clancy [mailto:clancy@cs.umd.edu]=20 > Sent: Tuesday, August 22, 2006 4:05 AM > To: Lakshminath Dondeti > Cc: emu@ietf.org > Subject: Re: [Emu] EAP-GPSK: Ciphersuites >=20 > Interesting idea, but what does it gain you? Why not just=20 > use an AES-CBC and CMAC ciphersuite? >=20 > -- > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy >=20 > Lakshminath Dondeti wrote: > > I guess we agree to disagree. The addition integrity checksum is=20 > > spurious in my view and I believe we can define things so that=20 > > combined modes can be employed without encrypting anything, so I am=20 > > somewhat confused here. What's your opinion on the latter=20 > part of my email? > >=20 > > thanks, > > Lakshminath > >=20 > > At 05:12 PM 8/22/2006, Hannes Tschofenig wrote: > >> Hi Lakshminath, > >> > >> Lakshminath Dondeti schrieb: > >>> At the expense of generating some confusion, here is my=20 > take on this: > >>> The objection is to having to carry multiple integrity=20 > checksums in=20 > >>> GPSK, if we used the combined mode *and* an integrity algorithm. > >> > >> I don't agree with you. There is no reason to optimize a=20 > few bits in=20 > >> a pre-shared secret method. > >> Note that we are not talking about a protocol for data transfer. > >> We wanted the flexibility to use different cipher suites.=20 > We do not=20 > >> only want to use cipher suites that provide authenticated=20 > encryption=20 > >> (since we almost have nothing to encrypt; currently 1 bit=20 > and almost=20 > >> no EAP method provides this functionality). > >> > >> Ciao > >> Hannes > >> > >>> I think CCM is fine for instance, the only catch is that=20 > we need to=20 > >>> make sure and define AAD for CCM carefully to include appropriate=20 > >>> data into the integrity checksum calculation. So, once we define=20 > >>> CCM as the mode, we shouldn't need AES-CMAC-128 if=20 > encryption is being used. > >>> I would suggest using CCM and specifying the use of it=20 > fully so it=20 > >>> can be used without misunderstandings. If you want me to=20 > put some=20 > >>> time into writing that up, let me know. > >>> cheers, > >>> Lakshminath > >>> At 10:55 PM 8/20/2006, Hannes Tschofenig wrote: > >>>> Hi all, > >>>> > >>>> the current version of the document=20 > >>>>=20 > http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secret-01. > >>>> txt > >>>> still supports AES-EAX: > >>>> > >>>> =20 > >>>>=20 > +-----------+----+-------------+---------------+--------------------+ > >>>> | CSuite/ | KS | Encryption | Integrity | Key=20 > >>>> Derivation | > >>>> | Specifier | | | |=20 > >>>> Function | > >>>> =20 > >>>>=20 > +-----------+----+-------------+---------------+--------------------+ > >>>> | 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 |=20 > >>>> GKDF-128 | > >>>> =20 > >>>>=20 > +-----------+----+-------------+---------------+--------------------+ > >>>> > >>>> At the IETF#66 EMU meeting AES CCM was suggested. > >>>> > >>>> Later, it got the impression that AES-CBC was more appreciated.=20 > >>>> Should we update the draft with AES-CBC? > >>>> > >>>> Ciao > >>>> Hannes > >>>> > >>>> > >>>> _______________________________________________ > >>>> Emu mailing list > >>>> Emu@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/emu > >=20 > >=20 > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Aug 28 14:43:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHm51-0008Py-Uh; Mon, 28 Aug 2006 14:43:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHm50-0008PD-ML for emu@ietf.org; Mon, 28 Aug 2006 14:43:26 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GHm4z-0006bZ-7g for emu@ietf.org; Mon, 28 Aug 2006 14:43:26 -0400 Received: (qmail invoked by alias); 28 Aug 2006 18:43:24 -0000 Received: from p54984D01.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.77.1] by mail.gmx.net (mp024) with SMTP; 28 Aug 2006 20:43:24 +0200 X-Authenticated: #29516787 Message-ID: <44F3394C.4080703@gmx.net> Date: Mon, 28 Aug 2006 20:43:24 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: David McGrew Subject: Re: [Emu] EAP-GPSK: Ciphersuites References: <4A985FCF-ED5D-4EB5-B034-162EE1CBF1A0@cisco.com> In-Reply-To: <4A985FCF-ED5D-4EB5-B034-162EE1CBF1A0@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi David, thanks for your feedback. If I read through it I get the impression that the IKEv2 selected algorithms (as defined in RFC 4307) would not be allowed to go forward. I wonder whether we put the bar a bit high here. One might even get the impression that nobody read RFC 4307 before it was published. Ciao Hannes David McGrew schrieb: > Hi Hannes, > > a few comments inline: > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Tuesday, August 22, 2006 2:20 AM >> To: M. Vanderveen >> Cc: emu@ietf.org >> Subject: Re: [Emu] EAP-GPSK: Ciphersuites >> >> Hi >> >> let us for a moment assume that RFC 4307 makes some >> reasonable algorithm choices (we are talking about IKEv2 >> here). If we take the text and apply it to EAP-GPSK then we >> would produce something like: >> >> Conservative Choice: >> ----------------------- >> >> (Integrity) >> AUTH_HMAC_SHA1_96 2 [RFC2404] MUST >> >> (Encryption) >> ENCR_3DES 3 [RFC2451] MUST- > > I agree with Joe that AES is preferable to 3DES, barring some strong > legacy considerations. > >> >> (Key Derivation) >> PRF_HMAC_SHA1 2 [RFC2104] MUST > > If it is a goal to conform to FIPS-140-2, that goal will probably drive > the key derivation function choice in the direction of > http://www.ietf.org/internet-drafts/draft-dang-nistkdf-01.txt. (I > like HMAC as a KDF, but I am not confident that it is going to be > approved for that purpose within FIPS-140-2.) > >> >> (Note that there is no MUST for encryption algorithms specified in RFC >> 4307.) >> >> >> Choice for the Future: >> ----------------------- >> >> (Encryption) >> ENCR_AES_CBC 12 [AES-CBC] SHOULD+ >> >> (Integrity) >> AUTH_AES_XCBC_96 5 [AES-MAC] SHOULD+ > > OMAC is a better choice than XCBC, since it is FIPS-140 approved, and > has some minor advantages (it's a refinement of XCBC that is > unfortunately not backwards compatible with it). > >> >> (Key Derivation) >> PRF_AES128_CBC 4 [AESPRF] SHOULD+ >> > > Same KDF considerations as above. > > David > > >> Does this sound like a terrible bad idea? >> >> Ciao >> Hannes >> >> M. Vanderveen schrieb: >>> Both are pretty popular. Why not list them both? As for >> which one to be >>> mandatory to implement, someone should to a search through >> other systems >>> (e.g. IEEE, IPSec) and see which one is most popular. >>> >>> */Hannes Tschofenig /* wrote: >>> >>> Hi all, >>> >>> the current version of the document >>> >> http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secret-01.txt >>> still supports AES-EAX: >>> >>> >> +-----------+----+-------------+---------------+--------------------+ >>> | CSuite/ | KS | Encryption | Integrity | Key Derivation | >>> | Specifier | | | | Function | >>> >> +-----------+----+-------------+---------------+--------------------+ >>> | 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 | GKDF-128 | >>> >> +-----------+----+-------------+---------------+--------------------+ >>> >>> At the IETF#66 EMU meeting AES CCM was suggested. >>> >>> Later, it got the impression that AES-CBC was more >> appreciated. Should >>> we update the draft with AES-CBC? >>> >>> Ciao >>> Hannes >>> >>> >>> _______________________________________________ >>> Emu mailing list >>> Emu@ietf.org >>> https://www1.ietf.org/mailman/listinfo/emu >>> >>> >>> >> -------------------------------------------------------------- >> ---------- >>> Do you Yahoo!? >>> Get on board. You're invited >>> >> > ahoo.com/handraisers> >>> to try the new Yahoo! Mail Beta. >> >> >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www1.ietf.org/mailman/listinfo/emu >> > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Aug 28 14:43:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHm57-00005b-25; Mon, 28 Aug 2006 14:43:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHm56-0008WS-5P for emu@ietf.org; Mon, 28 Aug 2006 14:43:32 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GHm53-0006c0-LD for emu@ietf.org; Mon, 28 Aug 2006 14:43:32 -0400 Received: (qmail invoked by alias); 28 Aug 2006 18:36:48 -0000 Received: from p54984D01.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.77.1] by mail.gmx.net (mp043) with SMTP; 28 Aug 2006 20:36:48 +0200 X-Authenticated: #29516787 Message-ID: <44F337C3.5070007@gmx.net> Date: Mon, 28 Aug 2006 20:36:51 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" Subject: Re: [Emu] EAP-GPSK: Ciphersuites References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Joe, I don't think that we on-the-fly want to use new algorithms as they come available. Based on Bernhard's experience with EAP-TLS I got the impression that most EAP implementers and users are not really excited about updating their implementation whenever a new algorithm becomes available. Furthermore, if new algorithms become available we need to specify a ciphersuite that makes sense for the given environment. The most difficult part with protocol design is to sometimes say NO when features and optimizations are proposed. Ciao Hannes Joseph Salowey (jsalowey) schrieb: > We want to define GPSK as a framework that can accommodate new > algorithms when they are available. I believe that Lakshminath is > looking to allow optimizations within this framework in the case where a > combined mode cipher is used. At this point I'm not sure how much > complexity this would add to the specification. If it can be done > simply then it might be worthwhile pursuing, perhaps David McGrew's > AEAD specification would help here. > > > >> -----Original Message----- >> From: Charles Clancy [mailto:clancy@cs.umd.edu] >> Sent: Tuesday, August 22, 2006 4:05 AM >> To: Lakshminath Dondeti >> Cc: emu@ietf.org >> Subject: Re: [Emu] EAP-GPSK: Ciphersuites >> >> Interesting idea, but what does it gain you? Why not just >> use an AES-CBC and CMAC ciphersuite? >> >> -- >> t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy >> >> Lakshminath Dondeti wrote: >>> I guess we agree to disagree. The addition integrity checksum is >>> spurious in my view and I believe we can define things so that >>> combined modes can be employed without encrypting anything, so I am >>> somewhat confused here. What's your opinion on the latter >> part of my email? >>> thanks, >>> Lakshminath >>> >>> At 05:12 PM 8/22/2006, Hannes Tschofenig wrote: >>>> Hi Lakshminath, >>>> >>>> Lakshminath Dondeti schrieb: >>>>> At the expense of generating some confusion, here is my >> take on this: >>>>> The objection is to having to carry multiple integrity >> checksums in >>>>> GPSK, if we used the combined mode *and* an integrity algorithm. >>>> I don't agree with you. There is no reason to optimize a >> few bits in >>>> a pre-shared secret method. >>>> Note that we are not talking about a protocol for data transfer. >>>> We wanted the flexibility to use different cipher suites. >> We do not >>>> only want to use cipher suites that provide authenticated >> encryption >>>> (since we almost have nothing to encrypt; currently 1 bit >> and almost >>>> no EAP method provides this functionality). >>>> >>>> Ciao >>>> Hannes >>>> >>>>> I think CCM is fine for instance, the only catch is that >> we need to >>>>> make sure and define AAD for CCM carefully to include appropriate >>>>> data into the integrity checksum calculation. So, once we define >>>>> CCM as the mode, we shouldn't need AES-CMAC-128 if >> encryption is being used. >>>>> I would suggest using CCM and specifying the use of it >> fully so it >>>>> can be used without misunderstandings. If you want me to >> put some >>>>> time into writing that up, let me know. >>>>> cheers, >>>>> Lakshminath >>>>> At 10:55 PM 8/20/2006, Hannes Tschofenig wrote: >>>>>> Hi all, >>>>>> >>>>>> the current version of the document >>>>>> >> http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secret-01. >>>>>> txt >>>>>> still supports AES-EAX: >>>>>> >>>>>> >>>>>> >> +-----------+----+-------------+---------------+--------------------+ >>>>>> | CSuite/ | KS | Encryption | Integrity | Key >>>>>> Derivation | >>>>>> | Specifier | | | | >>>>>> Function | >>>>>> >>>>>> >> +-----------+----+-------------+---------------+--------------------+ >>>>>> | 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 | >>>>>> GKDF-128 | >>>>>> >>>>>> >> +-----------+----+-------------+---------------+--------------------+ >>>>>> At the IETF#66 EMU meeting AES CCM was suggested. >>>>>> >>>>>> Later, it got the impression that AES-CBC was more appreciated. >>>>>> Should we update the draft with AES-CBC? >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Emu mailing list >>>>>> Emu@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/emu >>> >>> _______________________________________________ >>> Emu mailing list >>> Emu@ietf.org >>> https://www1.ietf.org/mailman/listinfo/emu >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www1.ietf.org/mailman/listinfo/emu >> > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Aug 28 14:50:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHmBv-0004IG-6P; Mon, 28 Aug 2006 14:50:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHmBu-0004IB-I8 for emu@ietf.org; Mon, 28 Aug 2006 14:50:34 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHmBs-0007UO-U0 for emu@ietf.org; Mon, 28 Aug 2006 14:50:34 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 28 Aug 2006 11:50:32 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7SIoWah002797; Mon, 28 Aug 2006 11:50:32 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7SIoS1O006536; Mon, 28 Aug 2006 11:50:32 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Aug 2006 11:50:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] EAP-GPSK: Ciphersuites Date: Mon, 28 Aug 2006 11:50:27 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EAP-GPSK: Ciphersuites Thread-Index: AcbK0PS61Y4GjeRGRVGBBiynpJ/nrQAAPJVQ From: "Joseph Salowey \(jsalowey\)" To: "Hannes Tschofenig" X-OriginalArrivalTime: 28 Aug 2006 18:50:29.0673 (UTC) FILETIME=[D5463990:01C6CAD2] DKIM-Signature: a=rsa-sha1; q=dns; l=6075; t=1156791032; x=1157655032; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:RE=3A=20[Emu]=20EAP-GPSK=3A=20Ciphersuites; X=v=3Dcisco.com=3B=20h=3D2dulrjaYeLr0EwCAImBrFO70zqA=3D; b=nKZf3/u51ktMrIPv54qe5Jy1RjIxZmDlKKJ71CFApBHDQCQ2zUdUwMESZDyxqOU+iB3sGpAV ldoLH3YlTxeYo4O6fQ7zEdcN+pyuV5oa+3YZojgkYXTyC7WSeXNtV6vI; Authentication-Results: sj-dkim-3.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Monday, August 28, 2006 11:37 AM > To: Joseph Salowey (jsalowey) > Cc: Charles Clancy; Lakshminath Dondeti; emu@ietf.org > Subject: Re: [Emu] EAP-GPSK: Ciphersuites >=20 > Hi Joe, >=20 > I don't think that we on-the-fly want to use new algorithms=20 > as they come available.=20 [Joe] Not sure what you mean by on the fly, but I think it would be bad to have to rewrite large portions of EAP-GPSK to make use of a new algorithm.=20 Based on Bernhard's experience with=20 > EAP-TLS I got the impression that most EAP implementers and=20 > users are not really excited about updating their=20 > implementation whenever a new algorithm becomes available. >=20 [Joe] However, new algorithms are implemented and requirements for algorithm agility exist. =20 > Furthermore, if new algorithms become available we need to=20 > specify a ciphersuite that makes sense for the given environment. >=20 > The most difficult part with protocol design is to sometimes=20 > say NO when features and optimizations are proposed. >=20 [Joe] True, but an analysis of the cost and benefits should be done. It is also not good to end up with a protocol that is obsolete when a new algorithm is required.=20 > Ciao > Hannes >=20 >=20 > Joseph Salowey (jsalowey) schrieb: > > We want to define GPSK as a framework that can accommodate new=20 > > algorithms when they are available. I believe that Lakshminath is=20 > > looking to allow optimizations within this framework in the=20 > case where=20 > > a combined mode cipher is used. At this point I'm not sure=20 > how much=20 > > complexity this would add to the specification. If it can be done=20 > > simply then it might be worthwhile pursuing, perhaps David=20 > McGrew's=20 > > AEAD specification would help here. > >=20 > > =20 > >=20 > >> -----Original Message----- > >> From: Charles Clancy [mailto:clancy@cs.umd.edu] > >> Sent: Tuesday, August 22, 2006 4:05 AM > >> To: Lakshminath Dondeti > >> Cc: emu@ietf.org > >> Subject: Re: [Emu] EAP-GPSK: Ciphersuites > >> > >> Interesting idea, but what does it gain you? Why not just use an=20 > >> AES-CBC and CMAC ciphersuite? > >> > >> -- > >> t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > >> > >> Lakshminath Dondeti wrote: > >>> I guess we agree to disagree. The addition integrity checksum is=20 > >>> spurious in my view and I believe we can define things so that=20 > >>> combined modes can be employed without encrypting=20 > anything, so I am=20 > >>> somewhat confused here. What's your opinion on the latter > >> part of my email? > >>> thanks, > >>> Lakshminath > >>> > >>> At 05:12 PM 8/22/2006, Hannes Tschofenig wrote: > >>>> Hi Lakshminath, > >>>> > >>>> Lakshminath Dondeti schrieb: > >>>>> At the expense of generating some confusion, here is my > >> take on this: > >>>>> The objection is to having to carry multiple integrity > >> checksums in > >>>>> GPSK, if we used the combined mode *and* an integrity algorithm. > >>>> I don't agree with you. There is no reason to optimize a > >> few bits in > >>>> a pre-shared secret method. > >>>> Note that we are not talking about a protocol for data transfer. > >>>> We wanted the flexibility to use different cipher suites.=20 > >> We do not > >>>> only want to use cipher suites that provide authenticated > >> encryption > >>>> (since we almost have nothing to encrypt; currently 1 bit > >> and almost > >>>> no EAP method provides this functionality). > >>>> > >>>> Ciao > >>>> Hannes > >>>> > >>>>> I think CCM is fine for instance, the only catch is that > >> we need to > >>>>> make sure and define AAD for CCM carefully to include=20 > appropriate=20 > >>>>> data into the integrity checksum calculation. So, once=20 > we define=20 > >>>>> CCM as the mode, we shouldn't need AES-CMAC-128 if > >> encryption is being used. > >>>>> I would suggest using CCM and specifying the use of it > >> fully so it > >>>>> can be used without misunderstandings. If you want me to > >> put some > >>>>> time into writing that up, let me know. > >>>>> cheers, > >>>>> Lakshminath > >>>>> At 10:55 PM 8/20/2006, Hannes Tschofenig wrote: > >>>>>> Hi all, > >>>>>> > >>>>>> the current version of the document > >>>>>> > >> http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secret-01. > >>>>>> txt > >>>>>> still supports AES-EAX: > >>>>>> > >>>>>> =20 > >>>>>> > >>=20 > +-----------+----+-------------+---------------+--------------------+ > >>>>>> | CSuite/ | KS | Encryption | Integrity | Key=20 > >>>>>> Derivation | > >>>>>> | Specifier | | | |=20 > >>>>>> Function | > >>>>>> =20 > >>>>>> > >>=20 > +-----------+----+-------------+---------------+--------------------+ > >>>>>> | 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 |=20 > >>>>>> GKDF-128 | > >>>>>> =20 > >>>>>> > >>=20 > +-----------+----+-------------+---------------+--------------------+ > >>>>>> At the IETF#66 EMU meeting AES CCM was suggested. > >>>>>> > >>>>>> Later, it got the impression that AES-CBC was more=20 > appreciated.=20 > >>>>>> Should we update the draft with AES-CBC? > >>>>>> > >>>>>> Ciao > >>>>>> Hannes > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Emu mailing list > >>>>>> Emu@ietf.org > >>>>>> https://www1.ietf.org/mailman/listinfo/emu > >>> > >>> _______________________________________________ > >>> Emu mailing list > >>> Emu@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/emu > >> _______________________________________________ > >> Emu mailing list > >> Emu@ietf.org > >> https://www1.ietf.org/mailman/listinfo/emu > >> > >=20 > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu > >=20 > >=20 >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Aug 28 14:57:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHmIz-0000KB-LF; Mon, 28 Aug 2006 14:57:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHmIy-0000Ht-Fa for emu@ietf.org; Mon, 28 Aug 2006 14:57:52 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHmIy-0000D8-Do for emu@ietf.org; Mon, 28 Aug 2006 14:57:52 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHm5K-0004s6-Q2 for emu@ietf.org; Mon, 28 Aug 2006 14:43:50 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 28 Aug 2006 11:43:46 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7SIhkj1012885; Mon, 28 Aug 2006 11:43:46 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7SIhjQX023591; Mon, 28 Aug 2006 11:43:46 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Aug 2006 11:43:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] EAP-GPSK: Ciphersuites Date: Mon, 28 Aug 2006 11:43:43 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EAP-GPSK: Ciphersuites Thread-Index: AcbK0D+6MjB0ONFmS9OMaw9hX90mFQAAXWpg From: "Joseph Salowey \(jsalowey\)" To: "Hannes Tschofenig" X-OriginalArrivalTime: 28 Aug 2006 18:43:45.0284 (UTC) FILETIME=[E43D5C40:01C6CAD1] DKIM-Signature: a=rsa-sha1; q=dns; l=4315; t=1156790626; x=1157654626; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:RE=3A=20[Emu]=20EAP-GPSK=3A=20Ciphersuites; X=v=3Dcisco.com=3B=20h=3D2dulrjaYeLr0EwCAImBrFO70zqA=3D; b=hauHNMHo0zmVUrujIWlGNO8goUsj7U4TIhNiP8mqasF/30ZO21FpHMnpYirbPL8AaJvtsG3s 5GINkfoDDsLdoJ5EH1RDrhJP8u45SUfIlJHINfG6RTvmrS8kY2uGFNwu; Authentication-Results: sj-dkim-4.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org IKEv2 has been designed for a different environment which already had 3DES deployed, I'm not sure that this is the case with EAP-GPSK.=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Monday, August 28, 2006 11:32 AM > To: Joseph Salowey (jsalowey) > Cc: M. Vanderveen; emu@ietf.org > Subject: Re: [Emu] EAP-GPSK: Ciphersuites >=20 > Hi Joe, >=20 > we might want to ask ourself why IKEv2 guys have chosen the=20 > indicated list of algorithms and why we decide to use different onces. >=20 > If we think that their list represents a problem we might=20 > want to convince them to submit an updated version of RFC 4307. >=20 > Ciao > Hannes >=20 > Joseph Salowey (jsalowey) schrieb: > > Is the proposal to make 3DES mandatory and AES optional?=20 > > It seems that we should be moving toward AES. Since this is a new > > method it may be better to make AES mandatory and 3DES optional. =20 > >=20 > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> Sent: Tuesday, August 22, 2006 2:20 AM > >> To: M. Vanderveen > >> Cc: emu@ietf.org > >> Subject: Re: [Emu] EAP-GPSK: Ciphersuites > >> > >> Hi > >> > >> let us for a moment assume that RFC 4307 makes some reasonable=20 > >> algorithm choices (we are talking about IKEv2 here). If we=20 > take the=20 > >> text and apply it to EAP-GPSK then we would produce something like: > >> > >> Conservative Choice: > >> ----------------------- > >> > >> (Integrity) > >> AUTH_HMAC_SHA1_96 2 [RFC2404] =20 > MUST > >> > >> (Encryption) > >> ENCR_3DES 3 [RFC2451] MUST- > >> > >> (Key Derivation) > >> PRF_HMAC_SHA1 2 [RFC2104] MUST > >> > >> (Note that there is no MUST for encryption algorithms specified in=20 > >> RFC > >> 4307.) > >> > >> > >> Choice for the Future: > >> ----------------------- > >> > >> (Encryption) > >> ENCR_AES_CBC 12 [AES-CBC] SHOULD+ > >> > >> (Integrity) > >> AUTH_AES_XCBC_96 5 [AES-MAC] SHOULD+ > >> > >> (Key Derivation) > >> PRF_AES128_CBC 4 [AESPRF] SHOULD+ > >> > >> Does this sound like a terrible bad idea? > >> > >> Ciao > >> Hannes > >> > >> M. Vanderveen schrieb: > >>> Both are pretty popular. Why not list them both? As for > >> which one to be > >>> mandatory to implement, someone should to a search through > >> other systems > >>> (e.g. IEEE, IPSec) and see which one is most popular. > >>> > >>> */Hannes Tschofenig /* wrote: > >>> > >>> Hi all, > >>> > >>> the current version of the document > >>> =20 > >>=20 > http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secret-01.tx > >> t > >>> still supports AES-EAX: > >>> > >>> =20 > >>=20 > +-----------+----+-------------+---------------+--------------------+ > >>> | CSuite/ | KS | Encryption | Integrity | Key Derivation | > >>> | Specifier | | | | Function | > >>> =20 > >>=20 > +-----------+----+-------------+---------------+--------------------+ > >>> | 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 | GKDF-128 | > >>> =20 > >>=20 > +-----------+----+-------------+---------------+--------------------+ > >>> At the IETF#66 EMU meeting AES CCM was suggested. > >>> > >>> Later, it got the impression that AES-CBC was more > >> appreciated. Should > >>> we update the draft with AES-CBC? > >>> > >>> Ciao > >>> Hannes > >>> > >>> > >>> _______________________________________________ > >>> Emu mailing list > >>> Emu@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/emu > >>> > >>> > >>> > >> -------------------------------------------------------------- > >> ---------- > >>> Do you Yahoo!? > >>> Get on board. You're invited > >>> > >> >> ahoo.com/handraisers> > >>> to try the new Yahoo! Mail Beta. > >> > >> _______________________________________________ > >> Emu mailing list > >> Emu@ietf.org > >> https://www1.ietf.org/mailman/listinfo/emu > >> > >=20 > >=20 >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Aug 28 15:05:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHmQE-0004if-5k; Mon, 28 Aug 2006 15:05:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHmQD-0004iZ-2a for emu@ietf.org; Mon, 28 Aug 2006 15:05:21 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GHmQB-00018H-Ei for emu@ietf.org; Mon, 28 Aug 2006 15:05:21 -0400 Received: (qmail invoked by alias); 28 Aug 2006 19:05:18 -0000 Received: from p54984D01.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.77.1] by mail.gmx.net (mp017) with SMTP; 28 Aug 2006 21:05:18 +0200 X-Authenticated: #29516787 Message-ID: <44F33E70.6040807@gmx.net> Date: Mon, 28 Aug 2006 21:05:20 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" Subject: Re: [Emu] EAP-GPSK: Ciphersuites References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Joe, Joseph Salowey (jsalowey) schrieb: > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Monday, August 28, 2006 11:37 AM >> To: Joseph Salowey (jsalowey) >> Cc: Charles Clancy; Lakshminath Dondeti; emu@ietf.org >> Subject: Re: [Emu] EAP-GPSK: Ciphersuites >> >> Hi Joe, >> >> I don't think that we on-the-fly want to use new algorithms >> as they come available. > > [Joe] Not sure what you mean by on the fly, but I think it would be bad > to have to rewrite large portions of EAP-GPSK to make use of a new > algorithm. That wouldn't have to be done. But you need to specify a new document that describes the ciphersuites. > > Based on Bernhard's experience with >> EAP-TLS I got the impression that most EAP implementers and >> users are not really excited about updating their >> implementation whenever a new algorithm becomes available. >> > > [Joe] However, new algorithms are implemented and requirements for > algorithm agility exist. > >> Furthermore, if new algorithms become available we need to >> specify a ciphersuite that makes sense for the given environment. >> >> The most difficult part with protocol design is to sometimes >> say NO when features and optimizations are proposed. >> > > [Joe] True, but an analysis of the cost and benefits should be done. It > is also not good to end up with a protocol that is obsolete when a new > algorithm is required. Sure. I don't think we are doing this. Ciao Hannes > > >> Ciao >> Hannes >> >> >> Joseph Salowey (jsalowey) schrieb: >>> We want to define GPSK as a framework that can accommodate new >>> algorithms when they are available. I believe that Lakshminath is >>> looking to allow optimizations within this framework in the >> case where >>> a combined mode cipher is used. At this point I'm not sure >> how much >>> complexity this would add to the specification. If it can be done >>> simply then it might be worthwhile pursuing, perhaps David >> McGrew's >>> AEAD specification would help here. >>> >>> >>> >>>> -----Original Message----- >>>> From: Charles Clancy [mailto:clancy@cs.umd.edu] >>>> Sent: Tuesday, August 22, 2006 4:05 AM >>>> To: Lakshminath Dondeti >>>> Cc: emu@ietf.org >>>> Subject: Re: [Emu] EAP-GPSK: Ciphersuites >>>> >>>> Interesting idea, but what does it gain you? Why not just use an >>>> AES-CBC and CMAC ciphersuite? >>>> >>>> -- >>>> t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy >>>> >>>> Lakshminath Dondeti wrote: >>>>> I guess we agree to disagree. The addition integrity checksum is >>>>> spurious in my view and I believe we can define things so that >>>>> combined modes can be employed without encrypting >> anything, so I am >>>>> somewhat confused here. What's your opinion on the latter >>>> part of my email? >>>>> thanks, >>>>> Lakshminath >>>>> >>>>> At 05:12 PM 8/22/2006, Hannes Tschofenig wrote: >>>>>> Hi Lakshminath, >>>>>> >>>>>> Lakshminath Dondeti schrieb: >>>>>>> At the expense of generating some confusion, here is my >>>> take on this: >>>>>>> The objection is to having to carry multiple integrity >>>> checksums in >>>>>>> GPSK, if we used the combined mode *and* an integrity algorithm. >>>>>> I don't agree with you. There is no reason to optimize a >>>> few bits in >>>>>> a pre-shared secret method. >>>>>> Note that we are not talking about a protocol for data transfer. >>>>>> We wanted the flexibility to use different cipher suites. >>>> We do not >>>>>> only want to use cipher suites that provide authenticated >>>> encryption >>>>>> (since we almost have nothing to encrypt; currently 1 bit >>>> and almost >>>>>> no EAP method provides this functionality). >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>>> I think CCM is fine for instance, the only catch is that >>>> we need to >>>>>>> make sure and define AAD for CCM carefully to include >> appropriate >>>>>>> data into the integrity checksum calculation. So, once >> we define >>>>>>> CCM as the mode, we shouldn't need AES-CMAC-128 if >>>> encryption is being used. >>>>>>> I would suggest using CCM and specifying the use of it >>>> fully so it >>>>>>> can be used without misunderstandings. If you want me to >>>> put some >>>>>>> time into writing that up, let me know. >>>>>>> cheers, >>>>>>> Lakshminath >>>>>>> At 10:55 PM 8/20/2006, Hannes Tschofenig wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> the current version of the document >>>>>>>> >>>> http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secret-01. >>>>>>>> txt >>>>>>>> still supports AES-EAX: >>>>>>>> >>>>>>>> >>>>>>>> >> +-----------+----+-------------+---------------+--------------------+ >>>>>>>> | CSuite/ | KS | Encryption | Integrity | Key >>>>>>>> Derivation | >>>>>>>> | Specifier | | | | >>>>>>>> Function | >>>>>>>> >>>>>>>> >> +-----------+----+-------------+---------------+--------------------+ >>>>>>>> | 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 | >>>>>>>> GKDF-128 | >>>>>>>> >>>>>>>> >> +-----------+----+-------------+---------------+--------------------+ >>>>>>>> At the IETF#66 EMU meeting AES CCM was suggested. >>>>>>>> >>>>>>>> Later, it got the impression that AES-CBC was more >> appreciated. >>>>>>>> Should we update the draft with AES-CBC? >>>>>>>> >>>>>>>> Ciao >>>>>>>> Hannes >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Emu mailing list >>>>>>>> Emu@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/emu >>>>> _______________________________________________ >>>>> Emu mailing list >>>>> Emu@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/emu >>>> _______________________________________________ >>>> Emu mailing list >>>> Emu@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/emu >>>> >>> _______________________________________________ >>> Emu mailing list >>> Emu@ietf.org >>> https://www1.ietf.org/mailman/listinfo/emu >>> >>> > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Aug 28 15:07:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHmSa-0005Oq-FN; Mon, 28 Aug 2006 15:07:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHmSY-0005Og-Ni for emu@ietf.org; Mon, 28 Aug 2006 15:07:46 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHmSX-0001Wu-4Q for emu@ietf.org; Mon, 28 Aug 2006 15:07:46 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 28 Aug 2006 12:07:45 -0700 X-IronPort-AV: i="4.08,176,1154934000"; d="scan'208"; a="338505454:sNHT34723764" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7SJ7iIB022501; Mon, 28 Aug 2006 12:07:44 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7SJ7iQV010276; Mon, 28 Aug 2006 12:07:44 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Aug 2006 12:07:44 -0700 Received: from [192.168.1.100] ([10.32.254.211]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Aug 2006 12:07:43 -0700 In-Reply-To: <44F3394C.4080703@gmx.net> References: <4A985FCF-ED5D-4EB5-B034-162EE1CBF1A0@cisco.com> <44F3394C.4080703@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8D8204B0-64C0-4EDD-A5FE-4D63202881CC@cisco.com> Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: [Emu] EAP-GPSK: Ciphersuites Date: Mon, 28 Aug 2006 12:07:41 -0700 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 28 Aug 2006 19:07:44.0032 (UTC) FILETIME=[3DCCE200:01C6CAD5] DKIM-Signature: a=rsa-sha1; q=dns; l=5021; t=1156792064; x=1157656064; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:David=20McGrew=20 |Subject:Re=3A=20[Emu]=20EAP-GPSK=3A=20Ciphersuites; X=v=3Dcisco.com=3B=20h=3DbVIcIhSDmSaT1Cxpa00uf1jA/Fc=3D; b=n7o49uQDAKycfklFTWvrb/bGNdv0nomUC/5N6mCL7qPVJdeBZRhfT5Oo7PmZVHFdue9zxvlR h923YsoRYEF15Og/+4baQyjmH3KJ9NJq5a6nh8rT26ceMOQm2X7R9lXY; Authentication-Results: sj-dkim-3.cisco.com; header.From=mcgrew@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Hannes, On Aug 28, 2006, at 11:43 AM, Hannes Tschofenig wrote: > Hi David, > > thanks for your feedback. > > If I read through it I get the impression that the IKEv2 selected > algorithms (as defined in RFC 4307) would not be allowed to go > forward. I wonder whether we put the bar a bit high here. > > One might even get the impression that nobody read RFC 4307 before > it was published. > I think that it comes down to unfortunate timing. XCBC was proposed to NIST but not adopted by them when it got picked up by IKEv2; afterwards, XCBC got improved into OMAC. I believe that IKEv2 re- used HMAC as a KDF out of a desire for compatibility with IKEv1. NIST SP 800-56 Sec. 5.3 mandates a hash-based KDF; NIST has made an exception for IKE and TLS, allowing their use in FIPS-140 certified crypto modules, but AFAICT this exception is specific to those protocols, and would not apply to GPSK. (I would be happy to be wrong on this point. If it is important, then let's ask the NIST crypto folks.) David > Ciao > Hannes > > David McGrew schrieb: >> Hi Hannes, >> a few comments inline: >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: Tuesday, August 22, 2006 2:20 AM >>> To: M. Vanderveen >>> Cc: emu@ietf.org >>> Subject: Re: [Emu] EAP-GPSK: Ciphersuites >>> >>> Hi >>> >>> let us for a moment assume that RFC 4307 makes some >>> reasonable algorithm choices (we are talking about IKEv2 >>> here). If we take the text and apply it to EAP-GPSK then we >>> would produce something like: >>> >>> Conservative Choice: >>> ----------------------- >>> >>> (Integrity) >>> AUTH_HMAC_SHA1_96 2 [RFC2404] >>> MUST >>> >>> (Encryption) >>> ENCR_3DES 3 [RFC2451] MUST- >> I agree with Joe that AES is preferable to 3DES, barring some >> strong legacy considerations. >>> >>> (Key Derivation) >>> PRF_HMAC_SHA1 2 [RFC2104] MUST >> If it is a goal to conform to FIPS-140-2, that goal will probably >> drive the key derivation function choice in the direction of >> http://www.ietf.org/internet-drafts/draft-dang-nistkdf-01.txt. >> (I like HMAC as a KDF, but I am not confident that it is going to >> be approved for that purpose within FIPS-140-2.) >>> >>> (Note that there is no MUST for encryption algorithms specified >>> in RFC >>> 4307.) >>> >>> >>> Choice for the Future: >>> ----------------------- >>> >>> (Encryption) >>> ENCR_AES_CBC 12 [AES-CBC] SHOULD+ >>> >>> (Integrity) >>> AUTH_AES_XCBC_96 5 [AES-MAC] SHOULD+ >> OMAC is a better choice than XCBC, since it is FIPS-140 approved, >> and has some minor advantages (it's a refinement of XCBC that is >> unfortunately not backwards compatible with it). >>> >>> (Key Derivation) >>> PRF_AES128_CBC 4 [AESPRF] SHOULD+ >>> >> Same KDF considerations as above. >> David >>> Does this sound like a terrible bad idea? >>> >>> Ciao >>> Hannes >>> >>> M. Vanderveen schrieb: >>>> Both are pretty popular. Why not list them both? As for >>> which one to be >>>> mandatory to implement, someone should to a search through >>> other systems >>>> (e.g. IEEE, IPSec) and see which one is most popular. >>>> >>>> */Hannes Tschofenig /* wrote: >>>> >>>> Hi all, >>>> >>>> the current version of the document >>>> >>> http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared- >>> secret-01.txt >>>> still supports AES-EAX: >>>> >>>> >>> +-----------+----+-------------+--------------- >>> +--------------------+ >>>> | CSuite/ | KS | Encryption | Integrity | Key Derivation | >>>> | Specifier | | | | Function | >>>> >>> +-----------+----+-------------+--------------- >>> +--------------------+ >>>> | 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 | GKDF-128 | >>>> >>> +-----------+----+-------------+--------------- >>> +--------------------+ >>>> >>>> At the IETF#66 EMU meeting AES CCM was suggested. >>>> >>>> Later, it got the impression that AES-CBC was more >>> appreciated. Should >>>> we update the draft with AES-CBC? >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>> _______________________________________________ >>>> Emu mailing list >>>> Emu@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/emu >>>> >>>> >>>> >>> -------------------------------------------------------------- >>> ---------- >>>> Do you Yahoo!? >>>> Get on board. You're invited >>>> >>> >> ahoo.com/handraisers> >>>> to try the new Yahoo! Mail Beta. >>> >>> >>> _______________________________________________ >>> Emu mailing list >>> Emu@ietf.org >>> https://www1.ietf.org/mailman/listinfo/emu >>> _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Aug 28 15:24:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHmhg-0004oE-Ch; Mon, 28 Aug 2006 15:23:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHmhf-0004o9-75 for emu@ietf.org; Mon, 28 Aug 2006 15:23:23 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHmhd-00031j-TL for emu@ietf.org; Mon, 28 Aug 2006 15:23:23 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 28 Aug 2006 12:23:21 -0700 X-IronPort-AV: i="4.08,176,1154934000"; d="scan'208"; a="315003868:sNHT2505609632" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7SJNKS0031013; Mon, 28 Aug 2006 12:23:20 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7SJNJ6Y017130; Mon, 28 Aug 2006 12:23:19 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Aug 2006 12:23:19 -0700 Received: from [192.168.1.100] ([10.32.254.211]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Aug 2006 12:23:18 -0700 In-Reply-To: <8D8204B0-64C0-4EDD-A5FE-4D63202881CC@cisco.com> References: <4A985FCF-ED5D-4EB5-B034-162EE1CBF1A0@cisco.com> <44F3394C.4080703@gmx.net> <8D8204B0-64C0-4EDD-A5FE-4D63202881CC@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7CB71EFD-EADA-40DD-9375-AE60B25012F0@cisco.com> Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: [Emu] EAP-GPSK: Ciphersuites Date: Mon, 28 Aug 2006 12:23:16 -0700 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 28 Aug 2006 19:23:18.0871 (UTC) FILETIME=[6B01FE70:01C6CAD7] DKIM-Signature: a=rsa-sha1; q=dns; l=1553; t=1156793000; x=1157657000; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:David=20McGrew=20 |Subject:Re=3A=20[Emu]=20EAP-GPSK=3A=20Ciphersuites; X=v=3Dcisco.com=3B=20h=3DbVIcIhSDmSaT1Cxpa00uf1jA/Fc=3D; b=ljJNfSBQcmPFoDv7uXVDLsl0WT/bkGpe6k7GrAESDEpBzJCMNvDup1Q+ikL25kJIt4Y2u22S LL9OUhamp++rpszXXyowJUbEr65rHRDvzWRGAC3Q5MX84p1cQ7MGHQiE; Authentication-Results: sj-dkim-7.cisco.com; header.From=mcgrew@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi again Hannes, On Aug 28, 2006, at 12:07 PM, David McGrew wrote: > Hi Hannes, > > On Aug 28, 2006, at 11:43 AM, Hannes Tschofenig wrote: > >> Hi David, >> >> thanks for your feedback. >> >> If I read through it I get the impression that the IKEv2 selected >> algorithms (as defined in RFC 4307) would not be allowed to go >> forward. I wonder whether we put the bar a bit high here. >> >> One might even get the impression that nobody read RFC 4307 before >> it was published. >> > > I think that it comes down to unfortunate timing. XCBC was > proposed to NIST but not adopted by them when it got picked up by > IKEv2; afterwards, XCBC got improved into OMAC. I believe that > IKEv2 re-used HMAC as a KDF out of a desire for compatibility with > IKEv1. NIST SP 800-56 Sec. 5.3 mandates a hash-based KDF; NIST > has made an exception for IKE and TLS, allowing their use in > FIPS-140 certified crypto modules, but AFAICT this exception is > specific to those protocols, and would not apply to GPSK. (I would > be happy to be wrong on this point. OK, I think I get my wish :-) The most recent version of SP800-56 says in Sec. 5.8.3 that "the IKEv2 KDF of Section 5.8.3 and the PRF TLS KDF of Section 5.8.4 are allowed; the use of one of these allowed KDFs is to be used only when both parties agree on its use." Sounds to me like the HMAC-based IKEv2 key derivation could be used in applications like GPSK and get a FIPS-140 certification, which is great news. David _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Aug 28 15:44:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHmzO-0003LU-Bh; Mon, 28 Aug 2006 15:41:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHmzL-0003Ce-Me for emu@ietf.org; Mon, 28 Aug 2006 15:41:39 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GHmpe-0003zG-Vr for emu@ietf.org; Mon, 28 Aug 2006 15:31:40 -0400 Received: (qmail invoked by alias); 28 Aug 2006 18:31:38 -0000 Received: from p54984D01.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.77.1] by mail.gmx.net (mp027) with SMTP; 28 Aug 2006 20:31:38 +0200 X-Authenticated: #29516787 Message-ID: <44F3368D.2020807@gmx.net> Date: Mon, 28 Aug 2006 20:31:41 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" Subject: Re: [Emu] EAP-GPSK: Ciphersuites References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Joe, we might want to ask ourself why IKEv2 guys have chosen the indicated list of algorithms and why we decide to use different onces. If we think that their list represents a problem we might want to convince them to submit an updated version of RFC 4307. Ciao Hannes Joseph Salowey (jsalowey) schrieb: > Is the proposal to make 3DES mandatory and AES optional? > It seems that we should be moving toward AES. Since this is a new > method it may be better to make AES mandatory and 3DES optional. > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Tuesday, August 22, 2006 2:20 AM >> To: M. Vanderveen >> Cc: emu@ietf.org >> Subject: Re: [Emu] EAP-GPSK: Ciphersuites >> >> Hi >> >> let us for a moment assume that RFC 4307 makes some >> reasonable algorithm choices (we are talking about IKEv2 >> here). If we take the text and apply it to EAP-GPSK then we >> would produce something like: >> >> Conservative Choice: >> ----------------------- >> >> (Integrity) >> AUTH_HMAC_SHA1_96 2 [RFC2404] MUST >> >> (Encryption) >> ENCR_3DES 3 [RFC2451] MUST- >> >> (Key Derivation) >> PRF_HMAC_SHA1 2 [RFC2104] MUST >> >> (Note that there is no MUST for encryption algorithms specified in RFC >> 4307.) >> >> >> Choice for the Future: >> ----------------------- >> >> (Encryption) >> ENCR_AES_CBC 12 [AES-CBC] SHOULD+ >> >> (Integrity) >> AUTH_AES_XCBC_96 5 [AES-MAC] SHOULD+ >> >> (Key Derivation) >> PRF_AES128_CBC 4 [AESPRF] SHOULD+ >> >> Does this sound like a terrible bad idea? >> >> Ciao >> Hannes >> >> M. Vanderveen schrieb: >>> Both are pretty popular. Why not list them both? As for >> which one to be >>> mandatory to implement, someone should to a search through >> other systems >>> (e.g. IEEE, IPSec) and see which one is most popular. >>> >>> */Hannes Tschofenig /* wrote: >>> >>> Hi all, >>> >>> the current version of the document >>> >> http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secret-01.txt >>> still supports AES-EAX: >>> >>> >> +-----------+----+-------------+---------------+--------------------+ >>> | CSuite/ | KS | Encryption | Integrity | Key Derivation | >>> | Specifier | | | | Function | >>> >> +-----------+----+-------------+---------------+--------------------+ >>> | 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 | GKDF-128 | >>> >> +-----------+----+-------------+---------------+--------------------+ >>> At the IETF#66 EMU meeting AES CCM was suggested. >>> >>> Later, it got the impression that AES-CBC was more >> appreciated. Should >>> we update the draft with AES-CBC? >>> >>> Ciao >>> Hannes >>> >>> >>> _______________________________________________ >>> Emu mailing list >>> Emu@ietf.org >>> https://www1.ietf.org/mailman/listinfo/emu >>> >>> >>> >> -------------------------------------------------------------- >> ---------- >>> Do you Yahoo!? >>> Get on board. You're invited >>> >> > ahoo.com/handraisers> >>> to try the new Yahoo! Mail Beta. >> >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www1.ietf.org/mailman/listinfo/emu >> > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Aug 28 19:10:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHqFc-0002Qm-Jg; Mon, 28 Aug 2006 19:10:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHqFb-0002Pf-4G for emu@ietf.org; Mon, 28 Aug 2006 19:10:39 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHqFZ-0003pW-ML for emu@ietf.org; Mon, 28 Aug 2006 19:10:39 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 28 Aug 2006 16:10:37 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7SNAbDm005561; Mon, 28 Aug 2006 16:10:37 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7SNAZQr001344; Mon, 28 Aug 2006 16:10:36 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Aug 2006 16:10:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] EAP-GPSK: Ciphersuites Date: Mon, 28 Aug 2006 16:10:33 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EAP-GPSK: Ciphersuites Thread-Index: AcbEp0NNCO5HNz9tT+6LfV23wMzJCgGTQKiA From: "Joseph Salowey \(jsalowey\)" To: "Lakshminath Dondeti" , "Hannes Tschofenig" , X-OriginalArrivalTime: 28 Aug 2006 23:10:34.0067 (UTC) FILETIME=[2A37CA30:01C6CAF7] DKIM-Signature: a=rsa-sha1; q=dns; l=2720; t=1156806637; x=1157670637; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:RE=3A=20[Emu]=20EAP-GPSK=3A=20Ciphersuites; X=v=3Dcisco.com=3B=20h=3D2dulrjaYeLr0EwCAImBrFO70zqA=3D; b=IVArlNrr13JM1+WZYmFh71610qHtKtrkTplskRNDA9feB/zo2zv8U1otGt7O/7rZ69cdOWy2 ymOH6DZj6u6cktGfPfkVHGgdvdeukHZLimf85OaHk3rqNuLZk4LC6z7L; Authentication-Results: sj-dkim-4.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Lakshminath, I have not seen a lot of support for use of CCM/EAX with or without the optimization of eliminating additional MAC algorithm on the list. I think it would be useful to understand what the impact is on the current specification to support ciphers that provide both integrity protection and encryption without requiring additional MAC algorithms. Would the current spec need to be modified to support this? If so, what modifications are needed? Thanks, Joe > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20 > Sent: Sunday, August 20, 2006 12:23 AM > To: Hannes Tschofenig; emu@ietf.org > Subject: Re: [Emu] EAP-GPSK: Ciphersuites >=20 > At the expense of generating some confusion, here is my take on this: >=20 > The objection is to having to carry multiple integrity=20 > checksums in GPSK, if we used the combined mode *and* an=20 > integrity algorithm. >=20 > I think CCM is fine for instance, the only catch is that we=20 > need to make sure and define AAD for CCM carefully to include=20 > appropriate data into the integrity checksum calculation. =20 > So, once we define CCM as the mode, we shouldn't need=20 > AES-CMAC-128 if encryption is being used. >=20 > I would suggest using CCM and specifying the use of it fully=20 > so it can be used without misunderstandings. If you want me=20 > to put some time into writing that up, let me know. >=20 > cheers, > Lakshminath >=20 > At 10:55 PM 8/20/2006, Hannes Tschofenig wrote: > >Hi all, > > > >the current version of the document > >http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secr > et-01.txt > >still supports AES-EAX: > > > > =20 > +-----------+----+-------------+---------------+--------------------+ > > | CSuite/ | KS | Encryption | Integrity | Key=20 > Derivation | > > | Specifier | | | |=20 > Function | > > =20 > +-----------+----+-------------+---------------+--------------------+ > > | 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 |=20 > GKDF-128 | > > =20 > >=20 > +-----------+----+-------------+---------------+--------------------+ > > > >At the IETF#66 EMU meeting AES CCM was suggested. > > > >Later, it got the impression that AES-CBC was more appreciated.=20 > >Should we update the draft with AES-CBC? > > > >Ciao > >Hannes > > > > > >_______________________________________________ > >Emu mailing list > >Emu@ietf.org > >https://www1.ietf.org/mailman/listinfo/emu >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Aug 28 23:26:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHuFY-0003jo-JZ; Mon, 28 Aug 2006 23:26:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHuFX-0003jj-QZ for emu@ietf.org; Mon, 28 Aug 2006 23:26:51 -0400 Received: from rwcrmhc14.comcast.net ([216.148.227.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHuFW-0007xr-FG for emu@ietf.org; Mon, 28 Aug 2006 23:26:51 -0400 Received: from [192.168.0.5] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (rwcrmhc14) with ESMTP id <20060829032649m1400p0e6ke>; Tue, 29 Aug 2006 03:26:49 +0000 Message-ID: <44F3B3FB.8080406@cs.umd.edu> Date: Mon, 28 Aug 2006 23:26:51 -0400 From: Charles Clancy User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: emu@ietf.org Subject: Re: [Emu] EAP-GPSK: Ciphersuites References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Lots of interesting conversation... Being ciphersuite-modular doesn't mean we have to give up all control or write a protocol that would work in every possible case. I don't see any reason to add optimizations to support CCM/EAX-like primitives when there's no reason to use them in the first place. Both supporting them and using them adds unnecessary complexity. IMHO, the ciphersuites should be AES-CBC with a suitable MAC (I'm flexible here) and HMAC-256, with HMAC-256 mandatory to implement because it would most easily achieve FIPS140-2 certification. Is there general consensus on this part? There seems to be more contention on which MAC should be used with an AES-based ciphersuite. -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy Joseph Salowey (jsalowey) wrote: > Hi Lakshminath, > > I have not seen a lot of support for use of CCM/EAX with or without the > optimization of eliminating additional MAC algorithm on the list. I > think it would be useful to understand what the impact is on the current > specification to support ciphers that provide both integrity protection > and encryption without requiring additional MAC algorithms. Would the > current spec need to be modified to support this? If so, what > modifications are needed? > > Thanks, > Joe > > >>-----Original Message----- >>From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] >>Sent: Sunday, August 20, 2006 12:23 AM >>To: Hannes Tschofenig; emu@ietf.org >>Subject: Re: [Emu] EAP-GPSK: Ciphersuites >> >>At the expense of generating some confusion, here is my take on this: >> >>The objection is to having to carry multiple integrity >>checksums in GPSK, if we used the combined mode *and* an >>integrity algorithm. >> >>I think CCM is fine for instance, the only catch is that we >>need to make sure and define AAD for CCM carefully to include >>appropriate data into the integrity checksum calculation. >>So, once we define CCM as the mode, we shouldn't need >>AES-CMAC-128 if encryption is being used. >> >>I would suggest using CCM and specifying the use of it fully >>so it can be used without misunderstandings. If you want me >>to put some time into writing that up, let me know. >> >>cheers, >>Lakshminath >> >>At 10:55 PM 8/20/2006, Hannes Tschofenig wrote: >> >>>Hi all, >>> >>>the current version of the document >>>http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secr >> >>et-01.txt >> >>>still supports AES-EAX: >>> >>> >> >>+-----------+----+-------------+---------------+--------------------+ >> >>> | CSuite/ | KS | Encryption | Integrity | Key >> >>Derivation | >> >>> | Specifier | | | | >> >>Function | >> >>> >> >>+-----------+----+-------------+---------------+--------------------+ >> >>> | 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 | >> >>GKDF-128 | >> >>> >>> >> >>+-----------+----+-------------+---------------+--------------------+ >> >>>At the IETF#66 EMU meeting AES CCM was suggested. >>> >>>Later, it got the impression that AES-CBC was more appreciated. >>>Should we update the draft with AES-CBC? >>> >>>Ciao >>>Hannes >>> >>> >>>_______________________________________________ >>>Emu mailing list >>>Emu@ietf.org >>>https://www1.ietf.org/mailman/listinfo/emu >> >> >>_______________________________________________ >>Emu mailing list >>Emu@ietf.org >>https://www1.ietf.org/mailman/listinfo/emu >> > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Aug 28 23:53:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHufI-0008PB-EO; Mon, 28 Aug 2006 23:53:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHufH-0008Jo-DP for emu@ietf.org; Mon, 28 Aug 2006 23:53:27 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHufG-0002wn-0a for emu@ietf.org; Mon, 28 Aug 2006 23:53:27 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k7T3rMSO010224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 28 Aug 2006 20:53:22 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-103.qualcomm.com [10.50.76.103]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7T3rKnl026849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Aug 2006 20:53:21 -0700 (PDT) Message-Id: <7.0.1.0.2.20060828204743.048b6ca8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 28 Aug 2006 20:53:21 -0700 To: "Joseph Salowey \(jsalowey\)" , "Hannes Tschofenig" , From: Lakshminath Dondeti Subject: RE: [Emu] EAP-GPSK: Ciphersuites In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Joe, Since we are talking about a Authentication and Key establishment protocol, any optimizations that come with combined modes are not really crucial. On the other hand, it is not too difficult to use them without multiple integrity checksums. If there is interest, sure I can help specify that. We started with EAX and I was curious about why and did some investigation. Others did too and suggested CCM perhaps to reuse the 802.11i choice of algorithm. When the discussion about two integrity checksums started, we were quick to move off of combined modes. I submit that we don't need to rule them out. Let's specify how to use them properly. We don't need to belabor the topic so much really. As I noted, I am willing to put the time to write the text. thanks, Lakshminath At 04:10 PM 8/28/2006, Joseph Salowey \(jsalowey\) wrote: >Hi Lakshminath, > >I have not seen a lot of support for use of CCM/EAX with or without the >optimization of eliminating additional MAC algorithm on the list. I >think it would be useful to understand what the impact is on the current >specification to support ciphers that provide both integrity protection >and encryption without requiring additional MAC algorithms. Would the >current spec need to be modified to support this? If so, what >modifications are needed? > >Thanks, >Joe > > > -----Original Message----- > > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > > Sent: Sunday, August 20, 2006 12:23 AM > > To: Hannes Tschofenig; emu@ietf.org > > Subject: Re: [Emu] EAP-GPSK: Ciphersuites > > > > At the expense of generating some confusion, here is my take on this: > > > > The objection is to having to carry multiple integrity > > checksums in GPSK, if we used the combined mode *and* an > > integrity algorithm. > > > > I think CCM is fine for instance, the only catch is that we > > need to make sure and define AAD for CCM carefully to include > > appropriate data into the integrity checksum calculation. > > So, once we define CCM as the mode, we shouldn't need > > AES-CMAC-128 if encryption is being used. > > > > I would suggest using CCM and specifying the use of it fully > > so it can be used without misunderstandings. If you want me > > to put some time into writing that up, let me know. > > > > cheers, > > Lakshminath > > > > At 10:55 PM 8/20/2006, Hannes Tschofenig wrote: > > >Hi all, > > > > > >the current version of the document > > >http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secr > > et-01.txt > > >still supports AES-EAX: > > > > > > > > +-----------+----+-------------+---------------+--------------------+ > > > | CSuite/ | KS | Encryption | Integrity | Key > > Derivation | > > > | Specifier | | | | > > Function | > > > > > +-----------+----+-------------+---------------+--------------------+ > > > | 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 | > > GKDF-128 | > > > > > > > > +-----------+----+-------------+---------------+--------------------+ > > > > > >At the IETF#66 EMU meeting AES CCM was suggested. > > > > > >Later, it got the impression that AES-CBC was more appreciated. > > >Should we update the draft with AES-CBC? > > > > > >Ciao > > >Hannes > > > > > > > > >_______________________________________________ > > >Emu mailing list > > >Emu@ietf.org > > >https://www1.ietf.org/mailman/listinfo/emu > > > > > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Aug 29 02:01:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHwf0-0005Rq-1S; Tue, 29 Aug 2006 02:01:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHwey-0005Ri-H0 for emu@ietf.org; Tue, 29 Aug 2006 02:01:16 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHwev-0003M4-U6 for emu@ietf.org; Tue, 29 Aug 2006 02:01:16 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-6.cisco.com with ESMTP; 28 Aug 2006 23:01:13 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7T61DBR011979; Mon, 28 Aug 2006 23:01:13 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k7T61Cw7026937; Mon, 28 Aug 2006 23:01:12 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Aug 2006 23:01:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] EAP-GPSK: Ciphersuites Date: Mon, 28 Aug 2006 23:00:11 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EAP-GPSK: Ciphersuites Thread-Index: AcbLGwa0fxk1UiL4SAOevzQBpKyfeQAE6AMw From: "Joseph Salowey \(jsalowey\)" To: "Charles Clancy" , X-OriginalArrivalTime: 29 Aug 2006 06:01:12.0776 (UTC) FILETIME=[88086C80:01C6CB30] DKIM-Signature: a=rsa-sha1; q=dns; l=4631; t=1156831273; x=1157695273; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:RE=3A=20[Emu]=20EAP-GPSK=3A=20Ciphersuites; X=v=3Dcisco.com=3B=20h=3D2dulrjaYeLr0EwCAImBrFO70zqA=3D; b=Hr2toDrK4imPcDPixPeSH1f2SxYmAWBs3qm/dzK9q7UIlKaH7Jya1tfcAuT2l7r9zVCwUoxl XH/Fa8HFfN/g2E41Rl6+IfGP08ygirtkbFYIeJ4ytNEMlwr6kfFx7qhb; Authentication-Results: sj-dkim-5.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org =20 > -----Original Message----- > From: Charles Clancy [mailto:clancy@cs.umd.edu]=20 > Sent: Monday, August 28, 2006 8:27 PM > To: emu@ietf.org > Subject: Re: [Emu] EAP-GPSK: Ciphersuites >=20 > Lots of interesting conversation... >=20 > Being ciphersuite-modular doesn't mean we have to give up all=20 > control or write a protocol that would work in every possible=20 > case. I don't see any reason to add optimizations to support=20 > CCM/EAX-like primitives when there's no reason to use them in=20 > the first place. Both supporting them and using them adds=20 > unnecessary complexity. >=20 > IMHO, the ciphersuites should be AES-CBC with a suitable MAC=20 > (I'm flexible here) and HMAC-256, with HMAC-256 mandatory to=20 > implement because it would most easily achieve FIPS140-2=20 > certification. >=20 > Is there general consensus on this part? There seems to be=20 > more contention on which MAC should be used with an AES-based=20 > ciphersuite. [Joe] I personally would prefer to have a mandatory to implement encrypting ciphersuite. I'm also flexible when it comes to which AES MAC is used, either XCBC or OMAC is fine. >=20 > -- > t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy >=20 > Joseph Salowey (jsalowey) wrote: > > Hi Lakshminath, > >=20 > > I have not seen a lot of support for use of CCM/EAX with or without=20 > > the optimization of eliminating additional MAC algorithm on=20 > the list. =20 > > I think it would be useful to understand what the impact is on the=20 > > current specification to support ciphers that provide both=20 > integrity=20 > > protection and encryption without requiring additional MAC=20 > algorithms. =20 > > Would the current spec need to be modified to support this? If so,=20 > > what modifications are needed? > >=20 > > Thanks, > > Joe > >=20 > >=20 > >>-----Original Message----- > >>From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > >>Sent: Sunday, August 20, 2006 12:23 AM > >>To: Hannes Tschofenig; emu@ietf.org > >>Subject: Re: [Emu] EAP-GPSK: Ciphersuites > >> > >>At the expense of generating some confusion, here is my=20 > take on this: > >> > >>The objection is to having to carry multiple integrity checksums in=20 > >>GPSK, if we used the combined mode *and* an integrity algorithm. > >> > >>I think CCM is fine for instance, the only catch is that we need to=20 > >>make sure and define AAD for CCM carefully to include=20 > appropriate data=20 > >>into the integrity checksum calculation. > >>So, once we define CCM as the mode, we shouldn't need > >>AES-CMAC-128 if encryption is being used. > >> > >>I would suggest using CCM and specifying the use of it=20 > fully so it can=20 > >>be used without misunderstandings. If you want me to put some time=20 > >>into writing that up, let me know. > >> > >>cheers, > >>Lakshminath > >> > >>At 10:55 PM 8/20/2006, Hannes Tschofenig wrote: > >> > >>>Hi all, > >>> > >>>the current version of the document > >>>http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secr > >> > >>et-01.txt > >> > >>>still supports AES-EAX: > >>> > >>> =20 > >> > >>+-----------+----+-------------+---------------+------------ > --------+ > >> > >>> | CSuite/ | KS | Encryption | Integrity | Key=20 > >> > >>Derivation | > >> > >>> | Specifier | | | |=20 > >> > >>Function | > >> > >>> =20 > >> > >>+-----------+----+-------------+---------------+------------ > --------+ > >> > >>> | 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 | > >> > >>GKDF-128 | > >> > >>> =20 > >>> > >> > >>+-----------+----+-------------+---------------+------------ > --------+ > >> > >>>At the IETF#66 EMU meeting AES CCM was suggested. > >>> > >>>Later, it got the impression that AES-CBC was more appreciated.=20 > >>>Should we update the draft with AES-CBC? > >>> > >>>Ciao > >>>Hannes > >>> > >>> > >>>_______________________________________________ > >>>Emu mailing list > >>>Emu@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/emu > >> > >> > >>_______________________________________________ > >>Emu mailing list > >>Emu@ietf.org > >>https://www1.ietf.org/mailman/listinfo/emu > >> > >=20 > >=20 > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Aug 29 13:22:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI7I2-0008Bk-TD; Tue, 29 Aug 2006 13:22:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI7I2-0008Bf-4s for emu@ietf.org; Tue, 29 Aug 2006 13:22:18 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI7I0-00058N-IP for emu@ietf.org; Tue, 29 Aug 2006 13:22:18 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 29 Aug 2006 10:22:16 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7THMFrQ015433; Tue, 29 Aug 2006 10:22:15 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7THMFYp000994; Tue, 29 Aug 2006 10:22:15 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Aug 2006 10:22:15 -0700 Received: from [192.168.1.100] ([10.32.254.211]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Aug 2006 10:22:15 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <882D7BFB-ABDA-46CB-94AF-B827BD19121D@cisco.com> Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: [Emu] EAP-GPSK: Ciphersuites Date: Tue, 29 Aug 2006 10:22:12 -0700 To: Joseph Salowey ((jsalowey)) X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 29 Aug 2006 17:22:15.0376 (UTC) FILETIME=[AC0A5D00:01C6CB8F] DKIM-Signature: a=rsa-sha1; q=dns; l=4836; t=1156872135; x=1157736135; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:David=20McGrew=20 |Subject:Re=3A=20[Emu]=20EAP-GPSK=3A=20Ciphersuites; X=v=3Dcisco.com=3B=20h=3DbVIcIhSDmSaT1Cxpa00uf1jA/Fc=3D; b=kPLlYwY7T/fqKB2QfzzwYPeO/meYFXZVwoEoA9nLaHk05Y9PzXrWr7kTvaO/hf3pU5RkSG7J eiHQI0BVfNe/KYFAKJGuvEuuLsoMBkfHlLFTRuMPx5yyHz+9g6Pr1Z3o; Authentication-Results: sj-dkim-3.cisco.com; header.From=mcgrew@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Joe, On Aug 28, 2006, at 4:10 PM, Joseph Salowey ((jsalowey)) wrote: > Hi Lakshminath, > > I have not seen a lot of support for use of CCM/EAX with or without > the > optimization of eliminating additional MAC algorithm on the list. I > think it would be useful to understand what the impact is on the > current > specification to support ciphers that provide both integrity > protection > and encryption without requiring additional MAC algorithms. Would the > current spec need to be modified to support this? If so, what > modifications are needed? > the simplest way to add an AEAD mode would be to replace Sections 6.1.1 and 6.1.2 with something like the following adaptation: 6.1.1. Encryption and Integrity With this ciphersuite all cryptography is built around a single cryptographic primitive, AES-128. Within the protected data frames, AES-128 is used in EAX mode of operation. Ciphersuite 1 makes use of the EAX mode of encryption. EAX is an Authenticated-Encryption- With- Associated-Data (AEAD) scheme. It has as input a plaintext M, a header H and a nonce N and is keyed with a key K. The idea is that both M and H are integrity protected, but only M is encrypted. Therefore, EAX encryption returns the ciphertext, which consists of H and encrypted M, and a cryptographic checksum Tag T. We use EAX with a 128-bit nonce that is generated uniformly at random for each invocation of the encryption function. The nonce is returned by the Encrypt operation, along with the ciphertext and tag, in that order. During the decryption operation, these fields are parsed; since N and T have fixed widths, this procedure is simple. The decryption uses N and T in its processing, then returns the plaintext. Symbolically, N || C || T = EAX.Encrypt (K; N, H, M) M = EAX.Decrypt (K; N, H, C, T). The use of EAX in GPSK is defined by the mapping of the protocol messages to its inputs, as follows. Message GPSK-2: o M is the Value of PD_Payload_1 o H is the Value of SEC_SK Message GPSK-3: o M is the Value of PD_Payload_2 o H is the Value of SEC_SK Message GPSK-4: o M is the Value of PD_Payload_3 o H is the Value of SEC_SK Here I've tried to minimize changes from the existing document. David > Thanks, > Joe > >> -----Original Message----- >> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] >> Sent: Sunday, August 20, 2006 12:23 AM >> To: Hannes Tschofenig; emu@ietf.org >> Subject: Re: [Emu] EAP-GPSK: Ciphersuites >> >> At the expense of generating some confusion, here is my take on this: >> >> The objection is to having to carry multiple integrity >> checksums in GPSK, if we used the combined mode *and* an >> integrity algorithm. >> >> I think CCM is fine for instance, the only catch is that we >> need to make sure and define AAD for CCM carefully to include >> appropriate data into the integrity checksum calculation. >> So, once we define CCM as the mode, we shouldn't need >> AES-CMAC-128 if encryption is being used. >> >> I would suggest using CCM and specifying the use of it fully >> so it can be used without misunderstandings. If you want me >> to put some time into writing that up, let me know. >> >> cheers, >> Lakshminath >> >> At 10:55 PM 8/20/2006, Hannes Tschofenig wrote: >>> Hi all, >>> >>> the current version of the document >>> http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secr >> et-01.txt >>> still supports AES-EAX: >>> >>> >> +-----------+----+-------------+---------------+--------------------+ >>> | CSuite/ | KS | Encryption | Integrity | Key >> Derivation | >>> | Specifier | | | | >> Function | >>> >> +-----------+----+-------------+---------------+--------------------+ >>> | 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 | >> GKDF-128 | >>> >>> >> +-----------+----+-------------+---------------+--------------------+ >>> >>> At the IETF#66 EMU meeting AES CCM was suggested. >>> >>> Later, it got the impression that AES-CBC was more appreciated. >>> Should we update the draft with AES-CBC? >>> >>> Ciao >>> Hannes >>> >>> >>> _______________________________________________ >>> Emu mailing list >>> Emu@ietf.org >>> https://www1.ietf.org/mailman/listinfo/emu >> >> >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www1.ietf.org/mailman/listinfo/emu >> > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu