From emu-bounces@ietf.org Tue Oct 03 02:25:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUdiM-0005jY-Az; Tue, 03 Oct 2006 02:25:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUdiL-0005jT-6X for emu@ietf.org; Tue, 03 Oct 2006 02:25:13 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUdiJ-0003FB-M9 for emu@ietf.org; Tue, 03 Oct 2006 02:25:13 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 02F7A89837; Tue, 3 Oct 2006 09:25:08 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id AD4238980A; Tue, 3 Oct 2006 09:25:07 +0300 (EEST) Message-ID: <4522022C.1020803@piuha.net> Date: Tue, 03 Oct 2006 09:24:44 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: eap@frascone.com, emu@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Subject: [Emu] FW: Document Action: 'The Protected One-Time Password Protocol (EAP-POTP)' to Informational RFC 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 FYI > The IESG has approved the following document: > > - 'The Protected One-Time Password Protocol (EAP-POTP) ' > as an Informational RFC > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Jari Arkko. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-nystrom-eap-potp-07.txt > > Technical Summary > > This document describes a general EAP method suitable for use > with One-Time Password (OTP) tokens, particularly with > tokens that have direct electronic interfaces to their > associated clients. The method provides either unilateral > or mutual authentication and key material. It can be > used in environments that employ EAP authentication, such > as IKEv2, 802.11, 802.1X, or PPP. > > Working Group Summary > > This is an individual submission to the IESG. > > Pointers to the specification have been posted in > the EAP and EMU WGs, and presentation about the > protocol have been held in IETF 62 and 64. The > specification has also been discussed in the > OTPS mailing list and forum hosted by RSA > Security. > > There are a number of vendors who have or are about > to implement this. Given the widespread use of > OTP token cards, it is expected that specifications > for their use in EAP can be beneficial interoperability. > While there are existing specifications for the > use of OTP in EAP, they do not fulfill all current > requirements. In addition, neither the EAP or > EMU WGs currently have OTP support in their > charter. > > Uri Blumenthal, Pasi Eronen, and David Black have > reviewed this specification as a part of the > IETF Last Call and solicited secdir reviews. > All comments were addressed. > > Protocol Quality > > The protocol was reviewed for the IESG by Jari Arkko. > > Note to RFC Editor > > Please delete first paragraph of Section 8. > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Oct 03 18:19:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUsbG-0003BM-60; Tue, 03 Oct 2006 18:18:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUsbF-0003B8-0G for emu@ietf.org; Tue, 03 Oct 2006 18:18:53 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUsbD-0003KF-N6 for emu@ietf.org; Tue, 03 Oct 2006 18:18:52 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 03 Oct 2006 15:18:51 -0700 X-IronPort-AV: i="4.09,252,1157353200"; d="scan'208"; a="444874032:sNHT53057304" 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 k93MIpKm021963 for ; Tue, 3 Oct 2006 15:18:51 -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 k93MIoqn016621 for ; Tue, 3 Oct 2006 15:18:51 -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, 3 Oct 2006 15:18:50 -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: Tue, 3 Oct 2006 15:18:49 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GPSK issue - KDF Data Thread-Index: AcbnOea+JF/193/oSUqebf5T61P1sQ== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 03 Oct 2006 22:18:50.0515 (UTC) FILETIME=[E73A5630:01C6E739] DKIM-Signature: a=rsa-sha1; q=dns; l=384; t=1159913931; x=1160777931; 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:GPSK=20issue=20-=20KDF=20Data; X=v=3Dcisco.com=3B=20h=3DiIOGoIeQ5Gw0o9lOinVWiMkdYuA=3D; b=AAa2acKKcqaOiH4b3tFdafbT+E9QIMspS+efTHI/nkl5TAulqDNQozi+yPSRU4p4RIOMudoY Kb+piINQ2kdDdnEgtaN6eIiDtFp89zhJr7/oSa0mDVso0sDrEiSyhBlz; 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: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Emu] GPSK issue - KDF Data 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 The current GPSK draft includes the capability for the client and server to combine data into the KDF. This is currently incompletely described in the GPSK draft. The question has been raised as to whether we need this functionality. Unless there is a reason to support this it should be removed from the specification. Is there a good reason to keep this? Thanks, Joe _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Oct 03 18:38:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUsti-00073h-27; Tue, 03 Oct 2006 18:37:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUstg-0006yq-AO for emu@ietf.org; Tue, 03 Oct 2006 18:37:56 -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 1GUste-00087O-16 for emu@ietf.org; Tue, 03 Oct 2006 18:37:56 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 03 Oct 2006 15:37:54 -0700 X-IronPort-AV: i="4.09,252,1157353200"; d="scan'208"; a="344454238:sNHT46207680" 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 k93MbrLp009343 for ; Tue, 3 Oct 2006 15:37:53 -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 k93Mbrql029158 for ; Tue, 3 Oct 2006 15:37:53 -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, 3 Oct 2006 15:37:52 -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: Tue, 3 Oct 2006 15:37:51 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GPSK Issue - Identity in key derivation Thread-Index: AcbnPI+U+++1Ug2TQXaMoPi1uBcgzw== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 03 Oct 2006 22:37:53.0141 (UTC) FILETIME=[90493A50:01C6E73C] DKIM-Signature: a=rsa-sha1; q=dns; l=394; t=1159915073; x=1160779073; 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:GPSK=20Issue=20-=20Identity=20in=20key=20derivation; X=v=3Dcisco.com=3B=20h=3DmV8pUskBOZpJ8KcRNu8kqhu/pQs=3D; b=vEygb3xzO0Fp4CDsNLGln2ePhOAKicE0tpu+aX3f11R7+Lf+e4S/qg4iGnFwEYtt3a7Bb9tg WcMpWfl2PvjCvYzeBo52Tpoy4lonWz7qPVSfEMk0H6stKAwRFBi0oPZT; 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: d17f825e43c9aed4fd65b7edddddec89 Subject: [Emu] GPSK Issue - Identity in key derivation 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 There currently is no separator between the identities in the GPSK key derivation which means that 'a || bc' and 'ab || c' would produce same keys. It seems this can be addressed by including the length as part of the identity or inserting a delimiter between identities.=20 It seems that including the lengths as part of the identity would be fine. Any objections? Thanks, Joe _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Oct 03 18:51:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUt6y-0008HG-Pu; Tue, 03 Oct 2006 18:51:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUt6w-0008HA-Pw for emu@ietf.org; Tue, 03 Oct 2006 18:51:38 -0400 Received: from web54407.mail.yahoo.com ([206.190.49.137]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GUt6v-0002Zx-9c for emu@ietf.org; Tue, 03 Oct 2006 18:51:38 -0400 Received: (qmail 82720 invoked by uid 60001); 3 Oct 2006 22:51:34 -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=Y86qyCNFuzGB/BYdfiOcn4L/RePdfVPOSu9QvPNPMXfgo8syQagr+POOi3z/+BzfuOK5eZyZrcpnEmszKYv7TjGfm8yE5uskkvnyFGILpln7jYaSh/5KSfQC4hhcjD4WvkQICpiJ7bekXbtDrrbu4n3aB99MTHYpVsOMykt6xNc= ; Message-ID: <20061003225134.82716.qmail@web54407.mail.yahoo.com> Received: from [67.181.83.189] by web54407.mail.yahoo.com via HTTP; Tue, 03 Oct 2006 15:51:34 PDT Date: Tue, 3 Oct 2006 15:51:34 -0700 (PDT) From: "M. Vanderveen" Subject: Re: [Emu] GPSK Issue - Identity in key derivation To: "Joseph Salowey \(jsalowey\)" , emu@ietf.org In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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="===============1305529405==" Errors-To: emu-bounces@ietf.org --===============1305529405== Content-Type: multipart/alternative; boundary="0-516603501-1159915894=:81558" Content-Transfer-Encoding: 8bit --0-516603501-1159915894=:81558 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I have heard from folks who actually implemented such key derivations that the null character would work just as well. "Joseph Salowey (jsalowey)" wrote: There currently is no separator between the identities in the GPSK key derivation which means that 'a || bc' and 'ab || c' would produce same keys. It seems this can be addressed by including the length as part of the identity or inserting a delimiter between identities. It seems that including the lengths as part of the identity would be fine. Any objections? Thanks, Joe _______________________________________________ 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. --0-516603501-1159915894=:81558 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I have heard from folks who actually implemented such key derivations that the null character would work just as well.

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> wrote:
There currently is no separator between the identities in the GPSK key
derivation which means that 'a || bc' and 'ab || c' would produce same
keys. It seems this can be addressed by including the length as part of
the identity or inserting a delimiter between identities.

It seems that including the lengths as part of the identity would be
fine. Any objections?

Thanks,

Joe

_______________________________________________
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. --0-516603501-1159915894=:81558-- --===============1305529405== 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 --===============1305529405==-- From emu-bounces@ietf.org Tue Oct 03 19:15:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUtTr-0006pf-7G; Tue, 03 Oct 2006 19:15:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUtTp-0006oQ-7W for emu@ietf.org; Tue, 03 Oct 2006 19:15:17 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUtLl-0005bm-OK for emu@ietf.org; Tue, 03 Oct 2006 19:06:59 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 03 Oct 2006 15:05:07 -0700 X-IronPort-AV: i="4.09,252,1157353200"; d="scan'208"; a="327815460:sNHT2424875032" 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 k93M58eH008828 for ; Tue, 3 Oct 2006 15:05:08 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k93M4pjF019799 for ; Tue, 3 Oct 2006 15:05:08 -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); Tue, 3 Oct 2006 15:05:00 -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: Tue, 3 Oct 2006 15:04:56 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GPSK Open Issues - mandatory ciphersuites Thread-Index: AcbnN/XV0XZEX66+SB+WCKdaq0uJvw== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 03 Oct 2006 22:05:00.0420 (UTC) FILETIME=[F873E440:01C6E737] DKIM-Signature: a=rsa-sha1; q=dns; l=620; t=1159913108; x=1160777108; 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:GPSK=20Open=20Issues=20-=20mandatory=20ciphersuites; X=v=3Dcisco.com=3B=20h=3DZNHu3WzVAlAym3l3SM1nh9Gn5KU=3D; b=VdywPE+3cQqzI7ytscTEQIRZecdQ8mMMUsgMTDusFHXpJRjHCHLjGoOIZmTVxTLIbMeXgdmr fcTIFrADvciCJ9gjz/Df433xS0uwl3/oSAF79Jt6sZkZ0osUCrBbmB4j; Authentication-Results: sj-dkim-8.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Emu] GPSK Open Issues - mandatory 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 Here is my suggestion for resolving the ciphersuite issue: We need to define a small set (preferably one, maybe two) of mandatory to implement ciphersuites for GPSK. The mandatory to implement ciphers should exercise the features of GPSK. This would suggest that it should be a block cipher based ciphersuite. It seems a reasonable choice is AES-CBC with AES-CMAC. This makes use of a single base algorithm using relatively simple modes of operation.=20 The HMAC-SHA256 ciphersuite should also be described, but is not mandatory to implement. Does this seem reasonable? Any objections? Thanks, Joe _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Oct 04 01:39:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUzTA-0008Sl-8H; Wed, 04 Oct 2006 01:39:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUzT9-0008Sg-4E for emu@ietf.org; Wed, 04 Oct 2006 01:38:59 -0400 Received: from bay0-omc1-s12.bay0.hotmail.com ([65.54.246.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUzT6-00016j-Pf for emu@ietf.org; Wed, 04 Oct 2006 01:38:59 -0400 Received: from hotmail.com ([65.54.161.13]) by bay0-omc1-s12.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 22:38:55 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 3 Oct 2006 22:38:55 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Wed, 04 Oct 2006 05:38:52 GMT X-Originating-IP: [24.16.73.85] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: jsalowey@cisco.com, emu@ietf.org Bcc: Subject: RE: [Emu] GPSK issue - KDF Data Date: Tue, 03 Oct 2006 22:38:52 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 04 Oct 2006 05:38:55.0818 (UTC) FILETIME=[6203D2A0:01C6E777] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Can you be a bit more specific? Are you talking about mixing of client and server nonces or something else? >From: "Joseph Salowey (jsalowey)" >To: >Subject: [Emu] GPSK issue - KDF Data >Date: Tue, 3 Oct 2006 15:18:49 -0700 > >The current GPSK draft includes the capability for the client and server >to combine data into the KDF. This is currently incompletely described >in the GPSK draft. The question has been raised as to whether we need >this functionality. Unless there is a reason to support this it should >be removed from the specification. Is there a good reason to keep this? > >Thanks, > >Joe > >_______________________________________________ >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 Oct 04 05:41:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV3G2-0005mu-1m; Wed, 04 Oct 2006 05:41:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV3G0-0005fn-St for emu@ietf.org; Wed, 04 Oct 2006 05:41:40 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GV3Fz-0004dT-Eu for emu@ietf.org; Wed, 04 Oct 2006 05:41:40 -0400 Received: (qmail invoked by alias); 04 Oct 2006 09:41:38 -0000 Received: from ip-80-226-243-168.vodafone-net.de (EHLO [10.227.161.92]) [80.226.243.168] by mail.gmx.net (mp031) with SMTP; 04 Oct 2006 11:41:38 +0200 X-Authenticated: #29516787 Message-ID: <452381D2.6000403@gmx.net> Date: Wed, 04 Oct 2006 11:41:38 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "M. Vanderveen" Subject: Re: [Emu] GPSK Issue - Identity in key derivation References: <20061003225134.82716.qmail@web54407.mail.yahoo.com> In-Reply-To: <20061003225134.82716.qmail@web54407.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: 21c69d3cfc2dd19218717dbe1d974352 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 could also use the null character as separator. Ciao Hannes M. Vanderveen schrieb: > I have heard from folks who actually implemented such key derivations > that the null character would work just as well. > > */"Joseph Salowey (jsalowey)" /* wrote: > > There currently is no separator between the identities in the GPSK key > derivation which means that 'a || bc' and 'ab || c' would produce same > keys. It seems this can be addressed by including the length as part of > the identity or inserting a delimiter between identities. > > It seems that including the lengths as part of the identity would be > fine. Any objections? > > Thanks, > > Joe > > _______________________________________________ > 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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Oct 04 05:41:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV3G4-0005wh-9m; Wed, 04 Oct 2006 05:41:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV3G3-0005rG-2J for emu@ietf.org; Wed, 04 Oct 2006 05:41:43 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GV3Fy-0004dO-Kj for emu@ietf.org; Wed, 04 Oct 2006 05:41:43 -0400 Received: (qmail invoked by alias); 04 Oct 2006 09:41:36 -0000 Received: from ip-80-226-243-168.vodafone-net.de (EHLO [10.227.161.92]) [80.226.243.168] by mail.gmx.net (mp044) with SMTP; 04 Oct 2006 11:41:36 +0200 X-Authenticated: #29516787 Message-ID: <452381CE.6030105@gmx.net> Date: Wed, 04 Oct 2006 11:41:34 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" Subject: Re: [Emu] GPSK issue - KDF Data 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: 9466e0365fc95844abaf7c3f15a05c7d 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, this refers to issue#3: http://www.tschofenig.com:8080/eap-gpsk/issue3 I personally think we should remove it. Ciao Hannes Joseph Salowey (jsalowey) schrieb: > The current GPSK draft includes the capability for the client and server > to combine data into the KDF. This is currently incompletely described > in the GPSK draft. The question has been raised as to whether we need > this functionality. Unless there is a reason to support this it should > be removed from the specification. Is there a good reason to keep this? > > Thanks, > > Joe > > _______________________________________________ > 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 Oct 04 05:47:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV3Ln-000369-JJ; Wed, 04 Oct 2006 05:47:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV3Lm-000360-5w for emu@ietf.org; Wed, 04 Oct 2006 05:47:38 -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 1GV3Lj-00067u-Np for emu@ietf.org; Wed, 04 Oct 2006 05:47:38 -0400 Received: (qmail invoked by alias); 04 Oct 2006 09:47:31 -0000 Received: from ip-80-226-243-168.vodafone-net.de (EHLO [10.227.161.92]) [80.226.243.168] by mail.gmx.net (mp013) with SMTP; 04 Oct 2006 11:47:31 +0200 X-Authenticated: #29516787 Message-ID: <45238332.5040903@gmx.net> Date: Wed, 04 Oct 2006 11:47:30 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [Emu] GPSK issue - KDF Data References: In-Reply-To: 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: c1c65599517f9ac32519d043c37c5336 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 Bernard, this aspect refers to the ability to put arbitrary data exchanged between the end points into the key derivation function. It is therefore not about the nonces, identities etc. that is typically incorporated into the key derivation function. Why would someone want todo this? I don't think it is useful. Ciao Hannes Bernard Aboba schrieb: > Can you be a bit more specific? Are you talking about mixing of client > and server nonces or something else? > > >> From: "Joseph Salowey (jsalowey)" >> To: >> Subject: [Emu] GPSK issue - KDF Data >> Date: Tue, 3 Oct 2006 15:18:49 -0700 >> >> The current GPSK draft includes the capability for the client and server >> to combine data into the KDF. This is currently incompletely described >> in the GPSK draft. The question has been raised as to whether we need >> this functionality. Unless there is a reason to support this it should >> be removed from the specification. Is there a good reason to keep this? >> >> Thanks, >> >> Joe >> >> _______________________________________________ >> 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 Wed Oct 04 05:52:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV3Qs-0006mf-SD; Wed, 04 Oct 2006 05:52:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV3Qr-0006mV-JG for emu@ietf.org; Wed, 04 Oct 2006 05:52:53 -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 1GV3Qq-0007JW-59 for emu@ietf.org; Wed, 04 Oct 2006 05:52:53 -0400 Received: (qmail invoked by alias); 04 Oct 2006 09:52:50 -0000 Received: from ip-80-226-243-168.vodafone-net.de (EHLO [10.227.161.92]) [80.226.243.168] by mail.gmx.net (mp010) with SMTP; 04 Oct 2006 11:52:50 +0200 X-Authenticated: #29516787 Message-ID: <4523846E.7080400@gmx.net> Date: Wed, 04 Oct 2006 11:52:46 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" Subject: Re: [Emu] GPSK Open Issues - mandatory 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: e5ba305d0e64821bf3d8bc5d3bb07228 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 Fine with me. Issue#6: http://www.tschofenig.com:8080/eap-gpsk/issue6 Joseph Salowey (jsalowey) schrieb: > Here is my suggestion for resolving the ciphersuite issue: > > We need to define a small set (preferably one, maybe two) of mandatory > to implement ciphersuites for GPSK. The mandatory to implement ciphers > should exercise the features of GPSK. This would suggest that it should > be a block cipher based ciphersuite. It seems a reasonable choice is > AES-CBC with AES-CMAC. This makes use of a single base algorithm using > relatively simple modes of operation. > > The HMAC-SHA256 ciphersuite should also be described, but is not > mandatory to implement. > > Does this seem reasonable? Any objections? > > Thanks, > > Joe > > _______________________________________________ > 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 Oct 04 13:00:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVA6L-0000dp-Qz; Wed, 04 Oct 2006 13:00:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVA6K-0000cT-Iu for emu@ietf.org; Wed, 04 Oct 2006 13:00:08 -0400 Received: from bay0-omc1-s30.bay0.hotmail.com ([65.54.246.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVA6I-0008Al-9R for emu@ietf.org; Wed, 04 Oct 2006 13:00:08 -0400 Received: from hotmail.com ([65.54.161.36]) by bay0-omc1-s30.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 10:00:05 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 4 Oct 2006 10:00:05 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Wed, 04 Oct 2006 17:00:00 GMT X-Originating-IP: [24.16.73.85] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <45238332.5040903@gmx.net> From: "Bernard Aboba" To: Hannes.Tschofenig@gmx.net Bcc: Subject: Re: [Emu] GPSK issue - KDF Data Date: Wed, 04 Oct 2006 10:00:00 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 04 Oct 2006 17:00:05.0055 (UTC) FILETIME=[89FA7CF0:01C6E7D6] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 >this aspect refers to the ability to put arbitrary data exchanged between >the end points into the key derivation function. > >It is therefore not about the nonces, identities etc. that is typically >incorporated into the key derivation function. > >Why would someone want todo this? I don't think it is useful. Channel Bindings? _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Oct 04 13:29:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVAYj-0002Wk-85; Wed, 04 Oct 2006 13:29:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVAYi-0002UQ-7D for emu@ietf.org; Wed, 04 Oct 2006 13:29:28 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GVAYg-0005Ps-Qo for emu@ietf.org; Wed, 04 Oct 2006 13:29:28 -0400 Received: (qmail invoked by alias); 04 Oct 2006 17:29:24 -0000 Received: from unknown (EHLO [172.16.68.33]) [83.210.43.6] by mail.gmx.net (mp010) with SMTP; 04 Oct 2006 19:29:24 +0200 X-Authenticated: #29516787 Message-ID: <4523EF6D.7020003@gmx.net> Date: Wed, 04 Oct 2006 19:29:17 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [Emu] GPSK issue - KDF Data References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 For channel bindings you don't need to incorporate something into the KDF. Checking whether the identities seen by the three parties is enough. Ciao Hannes PS: Btw, what is the status of the channel binding work? Totally stalled? Bernard Aboba schrieb: >> this aspect refers to the ability to put arbitrary data exchanged >> between the end points into the key derivation function. >> >> It is therefore not about the nonces, identities etc. that is >> typically incorporated into the key derivation function. >> >> Why would someone want todo this? I don't think it is useful. > > Channel Bindings? > > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Oct 04 14:04:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVB6l-0003SA-CG; Wed, 04 Oct 2006 14:04:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVB6j-0003ME-J0 for emu@ietf.org; Wed, 04 Oct 2006 14:04:37 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVB6h-00010d-7e for emu@ietf.org; Wed, 04 Oct 2006 14:04:37 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k94I4VdO025259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Oct 2006 11:04:32 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k94I4RX8024771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Oct 2006 11:04:30 -0700 (PDT) Message-Id: <7.0.1.0.2.20061004110155.05fcc0b0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 04 Oct 2006 11:04:25 -0700 To: "Joseph Salowey \(jsalowey\)" , From: Lakshminath Dondeti Subject: Re: [Emu] GPSK Issue - Identity in key derivation 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: 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 I think this issue comes from: o Entropy = RAND_Client || RAND_Server || ID_Client || ID_Server First, a nit, none of the information in there qualifies as entropy, so let's call it something else, please. How about we define the above as RAND_Client || ID_Client || RAND_Server || ID_Server ? Lakshminath At 03:37 PM 10/3/2006, Joseph Salowey \(jsalowey\) wrote: >There currently is no separator between the identities in the GPSK key >derivation which means that 'a || bc' and 'ab || c' would produce same >keys. It seems this can be addressed by including the length as part of >the identity or inserting a delimiter between identities. > >It seems that including the lengths as part of the identity would be >fine. Any objections? > >Thanks, > >Joe > >_______________________________________________ >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 Oct 04 14:04:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVB75-0003rY-OK; Wed, 04 Oct 2006 14:04:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVB74-0003rG-H3 for emu@ietf.org; Wed, 04 Oct 2006 14:04:58 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVB72-00011t-Sh for emu@ietf.org; Wed, 04 Oct 2006 14:04:58 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k94I1ifV005414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Oct 2006 11:01:44 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k94I1c9G023368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Oct 2006 11:01:42 -0700 (PDT) Message-Id: <7.0.1.0.2.20061004110127.05f9f7f8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 04 Oct 2006 11:01:39 -0700 To: Hannes Tschofenig , Bernard Aboba From: Lakshminath Dondeti Subject: Re: [Emu] GPSK issue - KDF Data In-Reply-To: <4523EF6D.7020003@gmx.net> References: <4523EF6D.7020003@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Agree with Hannes on this. Lakshminath At 10:29 AM 10/4/2006, Hannes Tschofenig wrote: >For channel bindings you don't need to incorporate something into >the KDF. Checking whether the identities seen by the three parties is enough. > >Ciao >Hannes > >PS: Btw, what is the status of the channel binding work? Totally stalled? > >Bernard Aboba schrieb: >>>this aspect refers to the ability to put arbitrary data exchanged >>>between the end points into the key derivation function. >>> >>>It is therefore not about the nonces, identities etc. that is >>>typically incorporated into the key derivation function. >>> >>>Why would someone want todo this? I don't think it is useful. >>Channel Bindings? >> > > >_______________________________________________ >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 Oct 04 14:05:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVB7N-0004Qp-2U; Wed, 04 Oct 2006 14:05:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVB7L-0004Qb-Na for emu@ietf.org; Wed, 04 Oct 2006 14:05:15 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVB7K-00012s-Cn for emu@ietf.org; Wed, 04 Oct 2006 14:05:15 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k94I5BBI025386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Oct 2006 11:05:13 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k94I55iC003179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Oct 2006 11:05:09 -0700 (PDT) Message-Id: <7.0.1.0.2.20061004110455.0641dc28@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 04 Oct 2006 11:05:04 -0700 To: "Joseph Salowey \(jsalowey\)" , From: Lakshminath Dondeti Subject: Re: [Emu] GPSK Open Issues - mandatory 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: 0bc60ec82efc80c84b8d02f4b0e4de22 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 This is good! Lakshminath At 03:04 PM 10/3/2006, Joseph Salowey \(jsalowey\) wrote: >Here is my suggestion for resolving the ciphersuite issue: > >We need to define a small set (preferably one, maybe two) of mandatory >to implement ciphersuites for GPSK. The mandatory to implement ciphers >should exercise the features of GPSK. This would suggest that it should >be a block cipher based ciphersuite. It seems a reasonable choice is >AES-CBC with AES-CMAC. This makes use of a single base algorithm using >relatively simple modes of operation. > >The HMAC-SHA256 ciphersuite should also be described, but is not >mandatory to implement. > >Does this seem reasonable? Any objections? > >Thanks, > >Joe > >_______________________________________________ >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 Oct 04 19:25:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVG6m-00063z-Gi; Wed, 04 Oct 2006 19:25:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVG6l-00063u-1i for emu@ietf.org; Wed, 04 Oct 2006 19:24:59 -0400 Received: from smtpout1432.sc1.he.tucows.com ([64.97.157.132] helo=n007.sc1.cp.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVG6i-0002MD-Nm for emu@ietf.org; Wed, 04 Oct 2006 19:24:59 -0400 Received: from fh1035.dia.cp.net (64.97.139.2) by n007.sc1.cp.net (7.2.069.1) id 45242865000049B9; Wed, 4 Oct 2006 23:24:44 +0000 Received: from 192.80.211.11 (authenticated as user david@mitton.com) by 64.97.168.45 with HTTP; Wed, 4 Oct 2006 23:24:44 UTC Message-ID: <28338023.1160004284231.JavaMail.?@fh1035.dia.cp.net> Date: Wed, 4 Oct 2006 23:24:44 +0000 (UTC) From: "mailbox@mitton.com" To: , Hannes Tschofenig , Bernard Aboba Subject: Re: [Emu] GPSK issue - KDF Data MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "mailbox@mitton.com" List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org One small problem, how does an EAP peer see the identity of the other parties? Dave. ----Original Message---- From: ldondeti@qualcomm.com Date: Oct 4, 2006 14:01 To: "Hannes Tschofenig", "Bernard Aboba" Cc: Subj: Re: [Emu] GPSK issue - KDF Data Agree with Hannes on this. Lakshminath At 10:29 AM 10/4/2006, Hannes Tschofenig wrote: >For channel bindings you don't need to incorporate something into >the KDF. Checking whether the identities seen by the three parties is enough. > >Ciao >Hannes > >PS: Btw, what is the status of the channel binding work? Totally stalled? > >Bernard Aboba schrieb: >>>this aspect refers to the ability to put arbitrary data exchanged >>>between the end points into the key derivation function. >>> >>>It is therefore not about the nonces, identities etc. that is >>>typically incorporated into the key derivation function. >>> >>>Why would someone want todo this? I don't think it is useful. >>Channel Bindings? >> > > >_______________________________________________ >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 Wed Oct 04 19:41:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVGMt-0001QV-UL; Wed, 04 Oct 2006 19:41:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVGMr-0001QP-SN for emu@ietf.org; Wed, 04 Oct 2006 19:41:37 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVGMq-0004V6-Gv for emu@ietf.org; Wed, 04 Oct 2006 19:41:37 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k94NfVxS005956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Oct 2006 16:41:33 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-72-150.qualcomm.com [10.50.72.150]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k94NfOwx014730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Oct 2006 16:41:28 -0700 (PDT) Message-Id: <7.0.1.0.2.20061004163156.0780fa80@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 04 Oct 2006 16:36:14 -0700 To: "mailbox@mitton.com" , Hannes Tschofenig , Bernard Aboba From: Lakshminath Dondeti Subject: Re: [Emu] GPSK issue - KDF Data In-Reply-To: <28338023.1160004284231.JavaMail.?@fh1035.dia.cp.net> References: <28338023.1160004284231.JavaMail.?@fh1035.dia.cp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 Dave, I was tersely agreeing to Hannes's note on CB not needing to incorporate anything into KDF and Identity checking is sufficient. To your question on the EAP peer knowing the identities of the other parties, the server's id would be available through the method and I would assume the authenticator's id would be available through the EAP lower layer. Or, did I totally misunderstand your question? regards, Lakshminath At 04:24 PM 10/4/2006, mailbox@mitton.com wrote: >One small problem, how does an EAP peer see the identity of the other >parties? >Dave. > >----Original Message---- >From: ldondeti@qualcomm.com >Date: Oct 4, 2006 14:01 >To: "Hannes Tschofenig", "Bernard Aboba" > >Cc: >Subj: Re: [Emu] GPSK issue - KDF Data > >Agree with Hannes on this. > >Lakshminath > >At 10:29 AM 10/4/2006, Hannes Tschofenig wrote: > >For channel bindings you don't need to incorporate something into > >the KDF. Checking whether the identities seen by the three parties is >enough. > > > >Ciao > >Hannes > > > >PS: Btw, what is the status of the channel binding work? Totally >stalled? > > > >Bernard Aboba schrieb: > >>>this aspect refers to the ability to put arbitrary data exchanged > >>>between the end points into the key derivation function. > >>> > >>>It is therefore not about the nonces, identities etc. that is > >>>typically incorporated into the key derivation function. > >>> > >>>Why would someone want todo this? I don't think it is useful. > >>Channel Bindings? > >> > > > > > >_______________________________________________ > >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 Wed Oct 04 19:47:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVGSn-0008Bu-77; Wed, 04 Oct 2006 19:47:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVGSm-0008Bp-Fb for emu@ietf.org; Wed, 04 Oct 2006 19:47:44 -0400 Received: from mail734.megamailservers.com ([69.49.98.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVGSl-0005GY-6h for emu@ietf.org; Wed, 04 Oct 2006 19:47:44 -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 mail734.megamailservers.com (8.13.6.20060614/8.13.1) with ESMTP id k94NlG3V002769; Wed, 4 Oct 2006 19:47:19 -0400 From: "Ray Bell" To: "'mailbox@mitton.com'" , , "'Hannes Tschofenig'" , "'Bernard Aboba'" Subject: RE: [Emu] GPSK issue - KDF Data Date: Wed, 4 Oct 2006 16:47:15 -0700 Message-ID: <001401c6e80f$6ca08350$63cba744@RBLAPTOP> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <28338023.1160004284231.JavaMail.?@fh1035.dia.cp.net> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-index: AcboDGNOY3EkiHaBSJqvgsk8Qm459AAAvcaw X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 Do you mean mutual authentication between the peers? Ray -----Original Message----- From: mailbox@mitton.com [mailto:david@mitton.com] Sent: Wednesday, October 04, 2006 4:25 PM To: ldondeti@qualcomm.com; Hannes Tschofenig; Bernard Aboba Cc: emu@ietf.org Subject: Re: [Emu] GPSK issue - KDF Data One small problem, how does an EAP peer see the identity of the other parties? Dave. ----Original Message---- From: ldondeti@qualcomm.com Date: Oct 4, 2006 14:01 To: "Hannes Tschofenig", "Bernard Aboba" Cc: Subj: Re: [Emu] GPSK issue - KDF Data Agree with Hannes on this. Lakshminath At 10:29 AM 10/4/2006, Hannes Tschofenig wrote: >For channel bindings you don't need to incorporate something into >the KDF. Checking whether the identities seen by the three parties is enough. > >Ciao >Hannes > >PS: Btw, what is the status of the channel binding work? Totally stalled? > >Bernard Aboba schrieb: >>>this aspect refers to the ability to put arbitrary data exchanged >>>between the end points into the key derivation function. >>> >>>It is therefore not about the nonces, identities etc. that is >>>typically incorporated into the key derivation function. >>> >>>Why would someone want todo this? I don't think it is useful. >>Channel Bindings? >> > > >_______________________________________________ >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 Wed Oct 04 21:42:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVIFx-0006XK-9V; Wed, 04 Oct 2006 21:42:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVIFw-0006XB-0l for emu@ietf.org; Wed, 04 Oct 2006 21:42:36 -0400 Received: from smtpout1434.sc1.he.tucows.com ([64.97.157.134] helo=n007.sc1.cp.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVIFu-0006f9-N4 for emu@ietf.org; Wed, 04 Oct 2006 21:42:35 -0400 Received: from CPQ-SEMPRON.mitton.com (71.232.147.244) by n007.sc1.cp.net (7.2.069.1) (authenticated as david@mitton.com) id 452428650000A629; Thu, 5 Oct 2006 01:40:34 +0000 Message-Id: <6.2.3.4.2.20061004213616.040986f0@getmail.mitton.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 04 Oct 2006 21:39:53 -0400 To: Lakshminath Dondeti , Hannes Tschofenig , Bernard Aboba From: David Mitton Subject: Re: [Emu] GPSK issue - KDF Data In-Reply-To: <7.0.1.0.2.20061004163156.0780fa80@qualcomm.com> References: <28338023.1160004284231.JavaMail.?@fh1035.dia.cp.net> <7.0.1.0.2.20061004163156.0780fa80@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) 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 Lakshminath, The devil is in the details. As I see it EAP doesn't provide a way for an 802.11 supplicant to know it's authenticator's ID. I'd like to be proven wrong, but I am skeptical of claims based on assumptions. Dave. On 10/4/2006 07:36 PM, Lakshminath Dondeti wrote: >Hi Dave, > >I was tersely agreeing to Hannes's note on CB not needing to >incorporate anything into KDF and Identity checking is sufficient. > >To your question on the EAP peer knowing the identities of the other >parties, the server's id would be available through the method and I >would assume the authenticator's id would be available through the >EAP lower layer. > >Or, did I totally misunderstand your question? > >regards, >Lakshminath > > >At 04:24 PM 10/4/2006, mailbox@mitton.com wrote: >>One small problem, how does an EAP peer see the identity of the other >>parties? >>Dave. >> >>----Original Message---- >>From: ldondeti@qualcomm.com >>Date: Oct 4, 2006 14:01 >>To: "Hannes Tschofenig", "Bernard Aboba" >> >>Cc: >>Subj: Re: [Emu] GPSK issue - KDF Data >> >>Agree with Hannes on this. >> >>Lakshminath >> >>At 10:29 AM 10/4/2006, Hannes Tschofenig wrote: >> >For channel bindings you don't need to incorporate something into >> >the KDF. Checking whether the identities seen by the three parties is >>enough. >> > >> >Ciao >> >Hannes >> > >> >PS: Btw, what is the status of the channel binding work? Totally >>stalled? >> > >> >Bernard Aboba schrieb: >> >>>this aspect refers to the ability to put arbitrary data exchanged >> >>>between the end points into the key derivation function. >> >>> >> >>>It is therefore not about the nonces, identities etc. that is >> >>>typically incorporated into the key derivation function. >> >>> >> >>>Why would someone want todo this? I don't think it is useful. >> >>Channel Bindings? >> >> >> > >> > >> >_______________________________________________ >> >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 Wed Oct 04 22:28:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVIyl-00048n-3b; Wed, 04 Oct 2006 22:28:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVIyj-00045F-OK for emu@ietf.org; Wed, 04 Oct 2006 22:28:53 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVIyh-0004Hw-9y for emu@ietf.org; Wed, 04 Oct 2006 22:28:53 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k952SljD032446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Oct 2006 19:28:48 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k952SlfP021498; Wed, 4 Oct 2006 19:28:47 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 19:28:47 -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 issue - KDF Data Date: Wed, 4 Oct 2006 19:28:47 -0700 Message-ID: In-Reply-To: <6.2.3.4.2.20061004213616.040986f0@getmail.mitton.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] GPSK issue - KDF Data thread-index: AcboH544BnAPE+60TbqAJMRiNNRVPwABTufw From: "Narayanan, Vidya" To: "David Mitton" , "Dondeti, Lakshminath" , "Hannes Tschofenig" , "Bernard Aboba" X-OriginalArrivalTime: 05 Oct 2006 02:28:47.0220 (UTC) FILETIME=[FC5FAB40:01C6E825] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 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 Dave,=20 >=20 > Lakshminath, >=20 > The devil is in the details. >=20 > As I see it EAP doesn't provide a way for an 802.11=20 > supplicant to know it's authenticator's ID. >=20 True that EAP does not provide a mechanism for the peer to know it's authenticator's ID. The authenticator ID is meant to be known to the peer via the lower layer. For instance, this could be one of the following - MAC address of the AP, BSSID of the AP, or something else that may be advertised in the beacon or sent in a Probe Response. The AAA client provides a NAS ID to the backend server.=20 Channel Bindings is meant to provide a means for the peer to verify that the entity claiming to be the authenticator is the same as the entity the server thinks is the authenticator as well.=20 All this is irrespective of whether CB is realized by putting some arbitrary information into the key derivation or by authenticated matching of authenticator identities by peer and server.=20 Having said that, I agree with Hannes and Lakshminath that we don't need to add data to the KDF to realize channel binding. Identity matching via authenticated exchange of information is sufficient.=20 Regards, Vidya > I'd like to be proven wrong, but I am skeptical of claims=20 > based on assumptions. >=20 > Dave. >=20 >=20 > On 10/4/2006 07:36 PM, Lakshminath Dondeti wrote: > >Hi Dave, > > > >I was tersely agreeing to Hannes's note on CB not needing to=20 > >incorporate anything into KDF and Identity checking is sufficient. > > > >To your question on the EAP peer knowing the identities of the other=20 > >parties, the server's id would be available through the method and I=20 > >would assume the authenticator's id would be available=20 > through the EAP=20 > >lower layer. > > > >Or, did I totally misunderstand your question? > > > >regards, > >Lakshminath > > > > > >At 04:24 PM 10/4/2006, mailbox@mitton.com wrote: > >>One small problem, how does an EAP peer see the identity of=20 > the other=20 > >>parties? > >>Dave. > >> > >>----Original Message---- > >>From: ldondeti@qualcomm.com > >>Date: Oct 4, 2006 14:01 > >>To: "Hannes Tschofenig", "Bernard Aboba" > >> > >>Cc: > >>Subj: Re: [Emu] GPSK issue - KDF Data > >> > >>Agree with Hannes on this. > >> > >>Lakshminath > >> > >>At 10:29 AM 10/4/2006, Hannes Tschofenig wrote: > >> >For channel bindings you don't need to incorporate something into=20 > >> >the KDF. Checking whether the identities seen by the=20 > three parties=20 > >> >is > >>enough. > >> > > >> >Ciao > >> >Hannes > >> > > >> >PS: Btw, what is the status of the channel binding work? Totally > >>stalled? > >> > > >> >Bernard Aboba schrieb: > >> >>>this aspect refers to the ability to put arbitrary data=20 > exchanged=20 > >> >>>between the end points into the key derivation function. > >> >>> > >> >>>It is therefore not about the nonces, identities etc. that is=20 > >> >>>typically incorporated into the key derivation function. > >> >>> > >> >>>Why would someone want todo this? I don't think it is useful. > >> >>Channel Bindings? > >> >> > >> > > >> > > >> >_______________________________________________ > >> >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 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Oct 05 08:56:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVSlU-0007Zg-9o; Thu, 05 Oct 2006 08:55:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVSlT-0007ZW-6I for emu@ietf.org; Thu, 05 Oct 2006 08:55:51 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVSlN-0007kp-Oi for emu@ietf.org; Thu, 05 Oct 2006 08:55:51 -0400 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k95CsxZo007571; Thu, 5 Oct 2006 08:54:59 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Date: Thu, 5 Oct 2006 08:55:01 -0400 To: emu@ietf.org Subject: Channel Binding [was Re: [Emu] GPSK issue - KDF Data] Message-ID: <20061005125501.GA21779@steelhead> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 15 X-Spam-Score: -2.4 (--) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Bernard Aboba 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 Dear all, I have been proposing to use a stronger way of channel binding, stronger in the sense that the keys generated by EAP methods cannot be used by a non-intended authenticator even if the keys are incorrectly delivered to such an authenticator. Key mixing with KDF (such as the one described in draft-ohba-eap-channel-binding-01.txt) is one solution for such stronger channel binding but there can be other ways such as tickets used by Kerberos. I'd like to hear opinions from this list as to whether defining a strong channel binding is not required at all even as an experimental solution. Yoshihiro Ohba _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Oct 05 14:05:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVXbG-0005JT-W0; Thu, 05 Oct 2006 14:05:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVXbG-0005JO-CR for emu@ietf.org; Thu, 05 Oct 2006 14:05:38 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVXbD-0000IX-06 for emu@ietf.org; Thu, 05 Oct 2006 14:05:38 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k95I5Xbu025365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 5 Oct 2006 11:05:34 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k95I5WlK020944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 5 Oct 2006 11:05:32 -0700 (PDT) Message-Id: <7.0.1.0.2.20061005104124.07aff340@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 05 Oct 2006 11:05:29 -0700 To: emu@ietf.org From: Lakshminath Dondeti Subject: Re: Channel Binding [was Re: [Emu] GPSK issue - KDF Data] In-Reply-To: <20061005125501.GA21779@steelhead> References: <20061005125501.GA21779@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 This topic has been discussed before on the EAP mailing list, here are some references: http://lists.frascone.com/pipermail/eap/msg04381.html http://lists.frascone.com/pipermail/eap/msg04385.html http://lists.frascone.com/pipermail/eap/msg04366.html and more available at: http://lists.frascone.com/pipermail/eap/threads.html Lakshminath At 05:55 AM 10/5/2006, Yoshihiro Ohba wrote: >Dear all, > >I have been proposing to use a stronger way of channel binding, >stronger in the sense that the keys generated by EAP methods cannot be >used by a non-intended authenticator even if the keys are incorrectly >delivered to such an authenticator. Key mixing with KDF (such as the >one described in draft-ohba-eap-channel-binding-01.txt) is one >solution for such stronger channel binding but there can be other ways >such as tickets used by Kerberos. > >I'd like to hear opinions from this list as to whether defining a >strong channel binding is not required at all even as an experimental >solution. > >Yoshihiro Ohba > >_______________________________________________ >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 Thu Oct 05 21:16:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVeK4-0003OA-Lx; Thu, 05 Oct 2006 21:16:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVeK3-0003O5-W6 for emu@ietf.org; Thu, 05 Oct 2006 21:16:19 -0400 Received: from alnrmhc11.comcast.net ([204.127.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVeK2-0001ln-Mo for emu@ietf.org; Thu, 05 Oct 2006 21:16:19 -0400 Received: from [192.168.0.2] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (alnrmhc11) with ESMTP id <20061006011607b11008aoffe>; Fri, 6 Oct 2006 01:16:18 +0000 Message-ID: <4525AE57.2030402@cs.umd.edu> Date: Thu, 05 Oct 2006 21:16:07 -0400 From: Charles Clancy User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Lakshminath Dondeti Subject: Re: [Emu] GPSK Issue - Identity in key derivation References: <7.0.1.0.2.20061004110155.05fcc0b0@qualcomm.com> In-Reply-To: <7.0.1.0.2.20061004110155.05fcc0b0@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 Sure, it can be renamed. I vote for simply prepending the identities with 16-bit lengths. It's consistent with the rest of the protocol payload formatting. Inserting NULLs could work in theory, but a poor implementation might accept an identity "a\0b" in which case we haven't protected against the malleability attack. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Lakshminath Dondeti wrote: > I think this issue comes from: > > > o Entropy = RAND_Client || RAND_Server || ID_Client || ID_Server > > First, a nit, none of the information in there qualifies as entropy, so > let's call it something else, please. > > How about we define the above as RAND_Client || ID_Client || > RAND_Server || ID_Server ? > > Lakshminath > > At 03:37 PM 10/3/2006, Joseph Salowey \(jsalowey\) wrote: >> There currently is no separator between the identities in the GPSK key >> derivation which means that 'a || bc' and 'ab || c' would produce same >> keys. It seems this can be addressed by including the length as part of >> the identity or inserting a delimiter between identities. >> >> It seems that including the lengths as part of the identity would be >> fine. Any objections? >> >> Thanks, >> >> Joe >> >> _______________________________________________ >> 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 Thu Oct 05 21:16:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVeKM-0003fR-Sd; Thu, 05 Oct 2006 21:16:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVeKL-0003fH-Cx for emu@ietf.org; Thu, 05 Oct 2006 21:16:37 -0400 Received: from alnrmhc13.comcast.net ([204.127.225.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVeKK-0001n2-51 for emu@ietf.org; Thu, 05 Oct 2006 21:16:37 -0400 Received: from [192.168.0.2] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (alnrmhc13) with ESMTP id <20061006011635b1300l9dibe>; Fri, 6 Oct 2006 01:16:35 +0000 Message-ID: <4525AE73.60908@cs.umd.edu> Date: Thu, 05 Oct 2006 21:16:35 -0400 From: Charles Clancy User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" Subject: Re: [Emu] GPSK Open Issues - mandatory 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: 0bc60ec82efc80c84b8d02f4b0e4de22 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 concur. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Joseph Salowey (jsalowey) wrote: > Here is my suggestion for resolving the ciphersuite issue: > > We need to define a small set (preferably one, maybe two) of mandatory > to implement ciphersuites for GPSK. The mandatory to implement ciphers > should exercise the features of GPSK. This would suggest that it should > be a block cipher based ciphersuite. It seems a reasonable choice is > AES-CBC with AES-CMAC. This makes use of a single base algorithm using > relatively simple modes of operation. > > The HMAC-SHA256 ciphersuite should also be described, but is not > mandatory to implement. > > Does this seem reasonable? Any objections? > > Thanks, > > Joe > > _______________________________________________ > 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 Thu Oct 05 21:16:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVeK4-0003OA-Lx; Thu, 05 Oct 2006 21:16:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVeK3-0003O5-W6 for emu@ietf.org; Thu, 05 Oct 2006 21:16:19 -0400 Received: from alnrmhc11.comcast.net ([204.127.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVeK2-0001ln-Mo for emu@ietf.org; Thu, 05 Oct 2006 21:16:19 -0400 Received: from [192.168.0.2] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (alnrmhc11) with ESMTP id <20061006011607b11008aoffe>; Fri, 6 Oct 2006 01:16:18 +0000 Message-ID: <4525AE57.2030402@cs.umd.edu> Date: Thu, 05 Oct 2006 21:16:07 -0400 From: Charles Clancy User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Lakshminath Dondeti Subject: Re: [Emu] GPSK Issue - Identity in key derivation References: <7.0.1.0.2.20061004110155.05fcc0b0@qualcomm.com> In-Reply-To: <7.0.1.0.2.20061004110155.05fcc0b0@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 Sure, it can be renamed. I vote for simply prepending the identities with 16-bit lengths. It's consistent with the rest of the protocol payload formatting. Inserting NULLs could work in theory, but a poor implementation might accept an identity "a\0b" in which case we haven't protected against the malleability attack. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Lakshminath Dondeti wrote: > I think this issue comes from: > > > o Entropy = RAND_Client || RAND_Server || ID_Client || ID_Server > > First, a nit, none of the information in there qualifies as entropy, so > let's call it something else, please. > > How about we define the above as RAND_Client || ID_Client || > RAND_Server || ID_Server ? > > Lakshminath > > At 03:37 PM 10/3/2006, Joseph Salowey \(jsalowey\) wrote: >> There currently is no separator between the identities in the GPSK key >> derivation which means that 'a || bc' and 'ab || c' would produce same >> keys. It seems this can be addressed by including the length as part of >> the identity or inserting a delimiter between identities. >> >> It seems that including the lengths as part of the identity would be >> fine. Any objections? >> >> Thanks, >> >> Joe >> >> _______________________________________________ >> 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 Thu Oct 05 21:16:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVeKM-0003fR-Sd; Thu, 05 Oct 2006 21:16:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVeKL-0003fH-Cx for emu@ietf.org; Thu, 05 Oct 2006 21:16:37 -0400 Received: from alnrmhc13.comcast.net ([204.127.225.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVeKK-0001n2-51 for emu@ietf.org; Thu, 05 Oct 2006 21:16:37 -0400 Received: from [192.168.0.2] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (alnrmhc13) with ESMTP id <20061006011635b1300l9dibe>; Fri, 6 Oct 2006 01:16:35 +0000 Message-ID: <4525AE73.60908@cs.umd.edu> Date: Thu, 05 Oct 2006 21:16:35 -0400 From: Charles Clancy User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" Subject: Re: [Emu] GPSK Open Issues - mandatory 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: 0bc60ec82efc80c84b8d02f4b0e4de22 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 concur. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Joseph Salowey (jsalowey) wrote: > Here is my suggestion for resolving the ciphersuite issue: > > We need to define a small set (preferably one, maybe two) of mandatory > to implement ciphersuites for GPSK. The mandatory to implement ciphers > should exercise the features of GPSK. This would suggest that it should > be a block cipher based ciphersuite. It seems a reasonable choice is > AES-CBC with AES-CMAC. This makes use of a single base algorithm using > relatively simple modes of operation. > > The HMAC-SHA256 ciphersuite should also be described, but is not > mandatory to implement. > > Does this seem reasonable? Any objections? > > Thanks, > > Joe > > _______________________________________________ > 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 Thu Oct 05 21:18:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVeLg-0003kK-6G; Thu, 05 Oct 2006 21:18:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVeLe-0003kF-RH for emu@ietf.org; Thu, 05 Oct 2006 21:17:58 -0400 Received: from alnrmhc12.comcast.net ([206.18.177.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVeLd-00023H-IZ for emu@ietf.org; Thu, 05 Oct 2006 21:17:58 -0400 Received: from [192.168.0.2] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (alnrmhc12) with ESMTP id <20061006011746b1200en9ule>; Fri, 6 Oct 2006 01:17:57 +0000 Message-ID: <4525AEBB.9080002@cs.umd.edu> Date: Thu, 05 Oct 2006 21:17:47 -0400 From: Charles Clancy User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [Emu] GPSK issue - KDF Data 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: 8b30eb7682a596edff707698f4a80f7d 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 It was originally added for channel binding purposes, for those in the "add stuff to the KDF" camp of channel bindings. I'm personally not all that attached to it, so if the consensus is to remove it, that's fine with me. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Bernard Aboba wrote: > Can you be a bit more specific? Are you talking about mixing of client > and server nonces or something else? > > >> From: "Joseph Salowey (jsalowey)" >> To: >> Subject: [Emu] GPSK issue - KDF Data >> Date: Tue, 3 Oct 2006 15:18:49 -0700 >> >> The current GPSK draft includes the capability for the client and server >> to combine data into the KDF. This is currently incompletely described >> in the GPSK draft. The question has been raised as to whether we need >> this functionality. Unless there is a reason to support this it should >> be removed from the specification. Is there a good reason to keep this? >> >> Thanks, >> >> Joe >> >> _______________________________________________ >> 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 Thu Oct 12 08:09:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXzNV-0005PR-Nl; Thu, 12 Oct 2006 08:09:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXzNU-0005PM-61 for emu@ietf.org; Thu, 12 Oct 2006 08:09:32 -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 1GXzNS-00041l-RT for emu@ietf.org; Thu, 12 Oct 2006 08:09:32 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 12 Oct 2006 05:09:30 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AY8CABnMLUWMIwEJDio X-IronPort-AV: i="4.09,299,1157353200"; d="scan'208"; a="345811932:sNHT28934716" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9CC9U1s011862 for ; Thu, 12 Oct 2006 05:09:30 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9CC9Uin000325 for ; Thu, 12 Oct 2006 05:09:30 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 05:09:30 -0700 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 05:09:29 -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: <8267F5AB-5D7A-4436-BE00-A184594BA844@cisco.com> Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: [Emu] GPSK Open Issues - mandatory ciphersuites Date: Thu, 12 Oct 2006 05:09:28 -0700 To: Joseph Salowey ((jsalowey)) X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 12 Oct 2006 12:09:29.0826 (UTC) FILETIME=[4513AC20:01C6EDF7] DKIM-Signature: a=rsa-sha1; q=dns; l=1456; t=1160654970; x=1161518970; c=relaxed/simple; s=sjdkim2002; 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]=20GPSK=20Open=20Issues=20-=20mandatory=20ciphersuites; X=v=3Dcisco.com=3B=20h=3DZThiq+fw14tQiEadT0HQLeOtWbw=3D; b=sjGnWMQjNUTaO6mM5HJpnMvBsGg9R9Yj/KGD11YHPRNX7UqMXFmaYEkLoSi6pJ5yoSOE2MCW Pe5RusDznlTFHP2OIBJMKbWNenyUIMABr+gSiymQBS/7NCoAdUrZ5Zrg; Authentication-Results: sj-dkim-2.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 Joe, a ciphersuite consisting of AES-CBC and AES-CMAC seems reasonable, but we should strive to make sure that the method that derives keys for these algorithms is FIPS-140 approved, so that a module implementing all three methods can be validated. The KDFs defined in draft-dang-nistkdf-01.txt meet this requirement, but would require that a hash function like SHA-256 be present. Still, this seems like a decent way to go because at least it keeps SHA-256 out of the data- processing path, and the alternate ciphersuite that you mention has it there. David On Oct 3, 2006, at 3:04 PM, Joseph Salowey ((jsalowey)) wrote: > Here is my suggestion for resolving the ciphersuite issue: > > We need to define a small set (preferably one, maybe two) of mandatory > to implement ciphersuites for GPSK. The mandatory to implement ciphers > should exercise the features of GPSK. This would suggest that it > should > be a block cipher based ciphersuite. It seems a reasonable choice is > AES-CBC with AES-CMAC. This makes use of a single base algorithm > using > relatively simple modes of operation. > > The HMAC-SHA256 ciphersuite should also be described, but is not > mandatory to implement. > > Does this seem reasonable? Any objections? > > Thanks, > > Joe > > _______________________________________________ > 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 Sun Oct 15 23:21:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZJ2A-0005ii-4q; Sun, 15 Oct 2006 23:20:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZJ29-0005id-5y for emu@ietf.org; Sun, 15 Oct 2006 23:20:57 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZJ25-0006nF-Sb for emu@ietf.org; Sun, 15 Oct 2006 23:20:57 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 15 Oct 2006 20:20:52 -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 k9G3Kq05022762 for ; Sun, 15 Oct 2006 20:20:52 -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 k9G3KoW4028098 for ; Sun, 15 Oct 2006 20:20:52 -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); Sun, 15 Oct 2006 20:20:50 -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 Open Issues - mandatory ciphersuites Date: Sun, 15 Oct 2006 20:20:49 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] GPSK Open Issues - mandatory ciphersuites Thread-Index: Acbt90U/rrQO2i51QOyeFaM3ACBERwC2hztQ From: "Joseph Salowey \(jsalowey\)" To: "David McGrew \(mcgrew\)" X-OriginalArrivalTime: 16 Oct 2006 03:20:50.0093 (UTC) FILETIME=[144B85D0:01C6F0D2] DKIM-Signature: a=rsa-sha1; q=dns; l=2166; t=1160968852; x=1161832852; 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]=20GPSK=20Open=20Issues=20-=20mandatory=20ciphersuites; X=v=3Dcisco.com=3B=20h=3DFArGVjo4GzDrjQP2tU7Cn+FIas8=3D; b=FCvNLVhRhKz+8yP7ICz4B969hptIntSqlvC8ReO4zLMMH3Q2PYDxlHGa6FAHoAOSHPDomVDP APTObs+sL3yINtEULNmeCvPzmZQ0jpBKZazdMNRElZQ3NGRCmB4OLFBV; 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: 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 David, Do you know if NIST is planning on producing a block cipher based method for key derivation? It would be nice to get away with only AES. One approach would be to keep the AES-CBC cipher AES only and let implementations that are concerned about FIPS 140 have the choice of implementing the SHA-256 cipher.=20 Thanks, Joe > -----Original Message----- > From: David McGrew (mcgrew)=20 > Sent: Thursday, October 12, 2006 5:09 AM > To: Joseph Salowey (jsalowey) > Cc: emu@ietf.org > Subject: Re: [Emu] GPSK Open Issues - mandatory ciphersuites >=20 > Hi Joe, >=20 > a ciphersuite consisting of AES-CBC and AES-CMAC seems=20 > reasonable, but we should strive to make sure that the method=20 > that derives keys for these algorithms is FIPS-140 approved,=20 > so that a module implementing all three methods can be=20 > validated. The KDFs defined in draft-dang-nistkdf-01.txt=20 > meet this requirement, but would require that a hash function=20 > like SHA-256 be present. Still, this seems like a decent way=20 > to go because at least it keeps SHA-256 out of the data-=20 > processing path, and the alternate ciphersuite that you=20 > mention has it there. >=20 > David >=20 > On Oct 3, 2006, at 3:04 PM, Joseph Salowey ((jsalowey)) wrote: >=20 > > Here is my suggestion for resolving the ciphersuite issue: > > > > We need to define a small set (preferably one, maybe two)=20 > of mandatory=20 > > to implement ciphersuites for GPSK. The mandatory to=20 > implement ciphers=20 > > should exercise the features of GPSK. This would suggest that it=20 > > should be a block cipher based ciphersuite. It seems a reasonable=20 > > choice is AES-CBC with AES-CMAC. This makes use of a single base=20 > > algorithm using relatively simple modes of operation. > > > > The HMAC-SHA256 ciphersuite should also be described, but is not=20 > > mandatory to implement. > > > > Does this seem reasonable? Any objections? > > > > Thanks, > > > > Joe > > > > _______________________________________________ > > 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 From emu-bounces@ietf.org Mon Oct 16 09:57:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZSyD-0007Mt-K8; Mon, 16 Oct 2006 09:57:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZSyB-0007Mk-Lb; Mon, 16 Oct 2006 09:57:31 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZSy8-0007PU-57; Mon, 16 Oct 2006 09:57:31 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id CB7CE8988B; Mon, 16 Oct 2006 16:57:26 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7765089884; Mon, 16 Oct 2006 16:57:26 +0300 (EEST) Message-ID: <45338FA2.8000004@piuha.net> Date: Mon, 16 Oct 2006 16:56:50 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: eap@frascone.com, emu@ietf.org References: <200610132032.NAA03323@gra.isi.edu> In-Reply-To: <200610132032.NAA03323@gra.isi.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: IESG , Bernard Aboba Subject: [Emu] an effort to bring legacy EAP methods to RFCs 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 As you you are well aware, much of the real-world EAP authentication happens through methods that are either undocumented, poorly documented, or not documented in a stable reference. Some methods have been described as expired Internet Drafts, but there is little certainty that the descriptions match to the protocols that are actually implemented. We are and have been addressing methods in the EMU WG, as well as in some individual submissions. For instance, there are currently four methods in the RFC Editor's queue. However, these activities are mostly about creating new methods that can be used in future networks. In addition, the IESG would like to see some commonly used current EAP methods to be published as RFCs. The intention would be to document current practice and focus on accurate descriptions (as opposed to improving the protocols or attempting to fix bugs in them). We believe this improves overall interoperability and makes it easier for anyone to implement equipment that employs EAP. I have talked with the RFC Editor about this and we expect to be able to publish such documents via the independent submission channel at the RFC editor. A number of volunteer reviewers (Cced) have agreed to help make sure the documents are clear and implementable (additional reviewers are always welcome; please contact me). We expect the publication process to go fairly fast, particularly given that we can help the RFC Editor with the ISR review task, focus on documentation rather than development, and clear IESG position. So please contact me to indicate your willigness to participate in this. If you have an EAP method that has a type number and has been deployed in current systems but not described in an RFC, talk to us. What we expect from you is a commitment to edit the document, but we hope that the rest of the process in the RFC Editor, ISR, IESG RFC 3932 review, etc. goes smoothly. Jari Arkko _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Oct 16 12:31:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZVMt-0007hz-M9; Mon, 16 Oct 2006 12:31:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZVMr-0007eW-OE for emu@ietf.org; Mon, 16 Oct 2006 12:31:09 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZVMp-0002lF-Ev for emu@ietf.org; Mon, 16 Oct 2006 12:31:09 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 16 Oct 2006 09:31:07 -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 k9GGV6g7006867 for ; Mon, 16 Oct 2006 09:31:06 -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 k9GGV4Oh018101 for ; Mon, 16 Oct 2006 09:31:06 -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, 16 Oct 2006 09:31:05 -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: Mon, 16 Oct 2006 09:31:03 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EMU meeting Scheduled for IETF 67 Thread-Index: AcbxQHjlB02JLBmgR+6BVIZE/avA3Q== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 16 Oct 2006 16:31:05.0248 (UTC) FILETIME=[79EE0200:01C6F140] DKIM-Signature: a=rsa-sha1; q=dns; l=254; t=1161016266; x=1161880266; 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:EMU=20meeting=20Scheduled=20for=20IETF=20=20=2067; X=v=3Dcisco.com=3B=20h=3DHTUCD7P2Bnijvfv39/BblGN1+PU=3D; b=BCmRP9bVAAEdHjFPiuSqWqHOOfPbpz3D4s+iZhktloEY/VsiKNT5tIItMrnzkQxepEwsEYGU TZZi5l/8aBpbq1EfsB6h7Ev9wsyctYLpRFoLgggY1R/qrBBSm4zJewnO; Authentication-Results: sj-dkim-8.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Emu] EMU meeting Scheduled for IETF 67 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 The following is the scheduled meeting slot for IETF 67 MONDAY, November 6, 2006 1300-1500 Afternoon Session I SEC emu EAP Method Update WG Let me know if you have any agenda items you would like to cover in this meeting. =20 Thanks, Joe _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Oct 17 19:47:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZyeT-00016I-5n; Tue, 17 Oct 2006 19:47:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZyeK-0000rM-5A; Tue, 17 Oct 2006 19:47:08 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZyUB-0006ib-6B; Tue, 17 Oct 2006 19:36:40 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7B008J303WFZ@usaga01-in.huawei.com>; Tue, 17 Oct 2006 16:33:33 -0700 (PDT) Received: from huawei6cc10c70 (pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J7B006A303SGT@usaga01-in.huawei.com>; Tue, 17 Oct 2006 16:33:32 -0700 (PDT) Date: Tue, 17 Oct 2006 16:36:33 -0700 From: Madjid Nakhjiri Subject: RE: [Emu] use of EAP in IKEv2/ an effort to bring legacy EAP methods to RFCs/ In-reply-to: <45338FA2.8000004@piuha.net> To: 'Jari Arkko' , eap@frascone.com, emu@ietf.org Message-id: <006b01c6f245$14dc3980$2f01a8c0@huawei6cc10c70> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbxK6rqoyGlyF2TSHOX2xRbd45gMQBFlSfQ X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: charlieK@microsoft.com, 'IESG' , 'Bernard Aboba' 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, Sorry for hijacking this email for something that might seem as an unrelated topic. The following may be a personal misunderstanding or may be that the fact that many of EAP methods have not been formally standardized by IETF have some impact on the use of EAP elsewhere: IETF has published IKEv2 as RFC4306 less than a year ago and included use of EAP methods as an alternative method in performing authentications required for Internet key exchange. However, even though the text states (section 2.16): "...this memo references [EAP] with the intent that new methods can be added in the future without updating this specification..." Still in the same section it is stated: "In addition to authentication using public key signatures and shared secrets, IKE supports authentication using methods defined in RFC 3748 [EAP]. Typically, these methods are asymmetric (designed for a user authenticating to a server), and they may not be mutual. For this reason, these protocols are typically used to authenticate the initiator to the responder and MUST be used in conjunction with a public key signature based authentication of the responder to the initiator. These methods are often associated with mechanisms referred to as "Legacy Authentication" mechanisms." I am guessing "legacy authentication" mean EAP methods listed in 3748 and the text possibly refers to some specific EAP methods (at the time, such as possibly EAP-TLS or EAP-TTLS) that required use of public keys or it is actually requiring the use of public keys for every EAP method that is used with IKEv2. Clarification is appreciated, as EAP for IKEv2 is now being used in some WGs quite seriously. Thanks and again sorry for hijacking the subject line, Madjid -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net] Sent: Monday, October 16, 2006 6:57 AM To: eap@frascone.com; emu@ietf.org Cc: IESG; Bernard Aboba Subject: [Emu] an effort to bring legacy EAP methods to RFCs As you you are well aware, much of the real-world EAP authentication happens through methods that are either undocumented, poorly documented, or not documented in a stable reference. Some methods have been described as expired Internet Drafts, but there is little certainty that the descriptions match to the protocols that are actually implemented. We are and have been addressing methods in the EMU WG, as well as in some individual submissions. For instance, there are currently four methods in the RFC Editor's queue. However, these activities are mostly about creating new methods that can be used in future networks. In addition, the IESG would like to see some commonly used current EAP methods to be published as RFCs. The intention would be to document current practice and focus on accurate descriptions (as opposed to improving the protocols or attempting to fix bugs in them). We believe this improves overall interoperability and makes it easier for anyone to implement equipment that employs EAP. I have talked with the RFC Editor about this and we expect to be able to publish such documents via the independent submission channel at the RFC editor. A number of volunteer reviewers (Cced) have agreed to help make sure the documents are clear and implementable (additional reviewers are always welcome; please contact me). We expect the publication process to go fairly fast, particularly given that we can help the RFC Editor with the ISR review task, focus on documentation rather than development, and clear IESG position. So please contact me to indicate your willigness to participate in this. If you have an EAP method that has a type number and has been deployed in current systems but not described in an RFC, talk to us. What we expect from you is a commitment to edit the document, but we hope that the rest of the process in the RFC Editor, ISR, IESG RFC 3932 review, etc. goes smoothly. Jari Arkko _______________________________________________ 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 Oct 17 21:56:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga0fj-0001dZ-Qf; Tue, 17 Oct 2006 21:56:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga0fh-0001dG-Py for emu@ietf.org; Tue, 17 Oct 2006 21:56:41 -0400 Received: from bay0-omc2-s15.bay0.hotmail.com ([65.54.246.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga0ff-0003j0-GE for emu@ietf.org; Tue, 17 Oct 2006 21:56:41 -0400 Received: from hotmail.com ([207.46.8.114]) by bay0-omc2-s15.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 18:56:38 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 17 Oct 2006 18:56:38 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Wed, 18 Oct 2006 01:56:33 GMT X-Originating-IP: [24.16.73.85] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <8267F5AB-5D7A-4436-BE00-A184594BA844@cisco.com> From: "Bernard Aboba" To: emu@ietf.org Bcc: Date: Tue, 17 Oct 2006 18:56:33 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 18 Oct 2006 01:56:38.0424 (UTC) FILETIME=[A6178180:01C6F258] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Emu] Review requested: 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 I have updated RFC 2716bis with a list of changes, added a section on privacy, rewritten the key hierarchy section to utilize modern terminology (MSK, EMSK), and updated the security considerations section. The updated document is available here: http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-03.txt Comments welcome. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Oct 18 15:50:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaHR1-0001hg-6T; Wed, 18 Oct 2006 15:50:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaHQR-00011M-RR; Wed, 18 Oct 2006 15:50:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaHQQ-0003mt-IL; Wed, 18 Oct 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 8158B26E42; Wed, 18 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GaHQQ-0001Te-BO; Wed, 18 Oct 2006 15:50:02 -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: Wed, 18 Oct 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: emu@ietf.org Subject: [Emu] I-D ACTION:draft-ietf-emu-eap-gpsk-00.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 : EAP Generalized Pre-Shared Key (EAP-GPSK) Author(s) : C. Clancy, H. Tschofenig Filename : draft-ietf-emu-eap-gpsk-00.txt Pages : 29 Date : 2006-10-18 This Internet Draft defines an Extensible Authentication Protocol method called EAP Generalized Pre-Shared Key (EAP-GPSK). This method is a lightweight shared-key authentication protocol supporting mutual authentication and key derivation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-emu-eap-gpsk-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-emu-eap-gpsk-00.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-10-18124419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-emu-eap-gpsk-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-emu-eap-gpsk-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-18124419.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 Fri Oct 20 01:02:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GamWf-0001KU-HJ; Fri, 20 Oct 2006 01:02:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GamWd-0001KM-SW for emu@ietf.org; Fri, 20 Oct 2006 01:02:32 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GamWc-0008Lp-Gs for emu@ietf.org; Fri, 20 Oct 2006 01:02:31 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 19 Oct 2006 22:02:30 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9K52TZF025910; Thu, 19 Oct 2006 22:02:29 -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 k9K52Tin018560; Thu, 19 Oct 2006 22:02:30 -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); Thu, 19 Oct 2006 22:02: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] Review requested: draft-simon-emu-rfc2716bis-03.txt Date: Thu, 19 Oct 2006 22:02:17 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt Thread-Index: AcbyWKuxzcVt/y0USIGPLIyFkeAyuQBp508w From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 20 Oct 2006 05:02:29.0789 (UTC) FILETIME=[F1A644D0:01C6F404] DKIM-Signature: a=rsa-sha1; q=dns; l=2040; t=1161320549; x=1162184549; 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]=20Review=20requested=3A=20=20draft-simon-emu-rfc2716bis-03 .txt; X=v=3Dcisco.com=3B=20h=3D2AAb+kZJ932TAMgXcwIKUJYY8dc=3D; b=ejgvIimZQ1q0v/2t0hYUPhBCdlx5qkHNCzil+0tTYxe05IIcIZFliC5jNu4jWSlZgZCiEEGR jCN9q2I1PXdM4OkKY0vrPPnEtQTVx8+56FGOAIddbTadOE0F7DwMemYE; 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: 8b431ad66d60be2d47c7bfeb879db82c 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 Bernard, Thanks for the update. I'd like to have some discussion on section 2.4 - Identity verification. Currently the section states that the peer identity is obtained from the subjectAltName in the certificate. Is this text meant to be normative? Currently there are implementations that use elements of the subject distinguished name and do not provide a subjectAltName.=20 Perhaps it would be better to say the subjectAltName is used if it is present and if it is not then the subject distinguished name is used. However it seems that RFC3280 might indicate that it would be better to use subject distinguished name if it is present and subjectAltName if not. This section should reference RFC3280. Also is there any reason why mapping using a directory service is called out, isn't just mapping to a Peer-ID or Server-ID sufficient? It would may also be good to say that an EAP-TLS implementation MAY make other certificate fields available to the lower layer. The document should also state in the security considerations section that the identity in the identity response is not necessarily related to the identity authenticated in EAP-TLS and should not be relied upon for any access control or accounting purposes.=20 Joe > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Tuesday, October 17, 2006 6:57 PM > To: emu@ietf.org > Subject: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt >=20 > I have updated RFC 2716bis with a list of changes, added a=20 > section on privacy, rewritten the key hierarchy section to=20 > utilize modern terminology (MSK, EMSK), and updated the=20 > security considerations section. >=20 > The updated document is available here: > http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-03.txt >=20 > Comments welcome. >=20 >=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 Fri Oct 20 13:26:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gay8b-0006PK-IF; Fri, 20 Oct 2006 13:26:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gay7m-0005qv-8I for emu@ietf.org; Fri, 20 Oct 2006 13:25:38 -0400 Received: from revol2.enst.fr ([137.194.2.14] helo=smtp2.enst.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaxsS-0003yT-Rd for emu@ietf.org; Fri, 20 Oct 2006 13:09:51 -0400 Received: from localhost (localhost.enst.fr [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id 07D1EB831E for ; Fri, 20 Oct 2006 19:09:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at enst.fr Received: from infres.enst.fr (infres.enst.fr [137.194.192.1]) by smtp2.enst.fr (Postfix) with ESMTP id CFEC5B831D for ; Fri, 20 Oct 2006 19:09:39 +0200 (CEST) Received: from VAIO.enst.fr (mechmech.enst.fr [137.194.164.56]) by infres.enst.fr (Postfix) with ESMTP id 89BE613CBB for ; Fri, 20 Oct 2006 19:09:39 +0200 (MEST) Message-Id: <7.0.0.16.0.20061020190904.02304f18@enst.fr> Message-Id: <7.0.0.16.0.20061020190413.02315cb8@enst.fr> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 20 Oct 2006 19:09:37 +0200 To: emu@ietf.org From: Pascal Urien Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Emu] draft-urien-badra-eap-tls-identity-protection-01.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 Hi everybody A new version of the draft eap-tls-identity-protection is available at http://tools.ietf.org/wg/tls/draft-urien-badra-eap-tls-identity-protection-01.txt Best Regards Pascal ============================ Title: draft-urien-badra-eap-tls-identity-protection-01.txt Authors: P.Urien & M.Badra Expires: April 2007 Abstract: This document defines a mechanism that ensures EAP-TLS identity protection. The main idea is to encrypt the client's certificate. Three procedures are proposed in order to determine the certificate encryption mechanism, - Implicit, the client's certificate is encrypted according to a pre-defined algorithm, deduced from the server's certificate. - Notified, the EAP-identity response message, delivered by the client includes information that precise the encryption algorithm to be used. - Negotiated, the client indicates a list of encryption algorithm, the server chooses one of them, and indicates its choice. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Oct 21 13:45:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbKu9-0004cc-CB; Sat, 21 Oct 2006 13:45:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbKu8-0004cR-TQ for emu@ietf.org; Sat, 21 Oct 2006 13:45:04 -0400 Received: from mail2.genealogia.fi ([194.100.116.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbKu6-0006gd-Hq for emu@ietf.org; Sat, 21 Oct 2006 13:45:04 -0400 Received: from dsl017-049-110.sfo4.dsl.speakeasy.net ([69.17.49.110] helo=jm) by mail2.genealogia.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1GbKtv-00030I-I1 for emu@ietf.org; Sat, 21 Oct 2006 20:44:53 +0300 Received: by jm (sSMTP sendmail emulation); Sat, 21 Oct 2006 10:43:26 -0700 Date: Sat, 21 Oct 2006 10:43:26 -0700 From: Jouni Malinen To: emu@ietf.org Subject: Re: [Emu] I-D ACTION:draft-ietf-emu-eap-gpsk-00.txt Message-ID: <20061021174326.GF6103@jm.kir.nu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 X-Spam-Score: -2.6 (--) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 On Wed, Oct 18, 2006 at 03:50:02PM -0400, Internet-Drafts@ietf.org wrote: > Title : EAP Generalized Pre-Shared Key (EAP-GPSK) > Author(s) : C. Clancy, H. Tschofenig > Filename : draft-ietf-emu-eap-gpsk-00.txt While updating my implementation to the new draft, I noticed couple of conflicts in how the key derivation is defined. Chapter 4 uses KDF_Zero-String(PL || PSK | ...) to derive MK whereas 6.1.8 and 6.2.8 use GKDF-#(PSK, ...). I would assume that the version in 6.1.8 and 6.2.8 is the correct one and chapter 4 should be updated to match with this. Another difference is in whether CSuite_Sel is to be included in the GKDF data field. Chapter 4 seems to include it (just before inputString), but 6.1.8 and 6.2.8 do not. Should it be there or not? The new draft is trying to fix the GKDF-X n (number of output blocks) calculation, but that seems to have a typo of some sort. Now: n = int( X / size - 1 ) + 1; That doesn't make any sense since -1 and +1 are are cancelling eachother and we are left with n = int( X / size ). I would assume that this was supposed to be taken into account rounding up (ceiling) by using n = int( (X + size - 1) / size ) which could be written as n = int( (X - 1) / size ) + 1. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Oct 22 11:46:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbfX8-0005JE-5V; Sun, 22 Oct 2006 11:46:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbfX7-0005J6-57 for emu@ietf.org; Sun, 22 Oct 2006 11:46:41 -0400 Received: from bay0-omc2-s29.bay0.hotmail.com ([65.54.246.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbfX5-0006Ad-RY for emu@ietf.org; Sun, 22 Oct 2006 11:46:41 -0400 Received: from hotmail.com ([207.46.8.103]) by bay0-omc2-s29.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Oct 2006 08:46:39 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 22 Oct 2006 08:46:39 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Sun, 22 Oct 2006 15:46:37 GMT X-Originating-IP: [24.16.73.85] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: jsalowey@cisco.com, emu@ietf.org Bcc: Subject: RE: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt Date: Sun, 22 Oct 2006 08:46:37 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 22 Oct 2006 15:46:39.0089 (UTC) FILETIME=[4340EE10:01C6F5F1] 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 >The document should also state in the security considerations section >that the identity in the identity response is not necessarily related to >the identity authenticated in EAP-TLS and should not be relied upon for >any access control or accounting purposes. Here is some proposed new text for Section 2.4: "As noted in [RFC3748] Section 5.1: It is RECOMMENDED that the Identity Response be used primarily for routing purposes and selecting which EAP method to use. EAP Methods SHOULD include a method-specific mechanism for obtaining the identity, so that they do not have to rely on the Identity Response. As part of the TLS negotiation, the server presents a certificate to the peer, and if mutual authentication is requested, the peer presents a certificate to the server. EAP-TLS therefore provides a mechanism for determining both the peer identity (Peer-Id in [KEYFRAME]) and server identity (Server-Id in [KEYFRAME]). Since the identity presented in the Identity Response need not be related to the identity presented in the peer certificate, EAP-TLS implementations SHOULD NOT require that they be identical, and SHOULD NOT use the identity presented in the Identity Response for access control or accounting purposes." _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Oct 22 12:43:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbgQ8-0008JS-3W; Sun, 22 Oct 2006 12:43:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbgQ6-0008Fi-Fi for emu@ietf.org; Sun, 22 Oct 2006 12:43:30 -0400 Received: from bay0-omc3-s4.bay0.hotmail.com ([65.54.246.204]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbgLi-0005WN-RF for emu@ietf.org; Sun, 22 Oct 2006 12:39:00 -0400 Received: from hotmail.com ([207.46.8.84]) by bay0-omc3-s4.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Oct 2006 09:38:58 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 22 Oct 2006 09:38:57 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Sun, 22 Oct 2006 16:38:55 GMT X-Originating-IP: [24.16.73.85] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: jsalowey@cisco.com, emu@ietf.org Bcc: Subject: RE: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt Date: Sun, 22 Oct 2006 09:38:55 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 22 Oct 2006 16:38:57.0778 (UTC) FILETIME=[920EDD20:01C6F5F8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 Joe Salowey said: >Currently the section states that the peer >identity is obtained from the subjectAltName in the certificate. Is >this text meant to be normative? >Currently there are implementations >that use elements of the subject distinguished name and do not provide a >subjectAltName. > >Perhaps it would be better to say the subjectAltName is used if it is >present and if it is not then the subject distinguished name is used. >However it seems that RFC3280 might indicate that it would be better to >use subject distinguished name if it is present and subjectAltName if >not. This section should reference RFC3280. Also is there any reason >why mapping using a directory service is called out, isn't just mapping >to a Peer-ID or Server-ID sufficient? > >It would may also be good to say that an EAP-TLS implementation MAY make >other certificate fields available to the lower layer. I've added some text in Section 4.2 that hopefully will clear this up: 4.2. Certificate Usage The EAP-TLS peer name (Peer-Id) represents the Network Access Identifier (NAI) [RFC4282] to be used for authorization and accounting purposes. The Peer-Id is determined from the subject or altSubjectName fields in the peer certificate. As noted in [RFC3280] Section 4.1.2.6: The subject field identifies the entity associated with the public key stored in the subject public key field. The subject name MAY be carried in the subject field and/or the subjectAltName extension... If subject naming information is present only in the subjectAltName extension (e.g., a key bound only to an email address or URI), then the subject name MUST be an empty sequence and the subjectAltName extension MUST be critical. Where it is non-empty, the subject field MUST contain an X.500 distinguished name (DN). Where the subject field is not empty, the Peer-Id and Server-Id are obtained from the Common Name (CN) field of the DN. Where subject naming information is present only in the subjectAltName extension, the Peer-Id and Server-Id are obtained from the subjectAltName. A valid EAP-TLS client certificate SHOULD contain an extendedKeyUsage value indicating support for Client Authentication (1.3.6.1.5.5.7.3.2). A valid EAP-TLS server certificate SHOULD contain an extendedKeyUsage value indicating support for Server Authentication (1.3.6.1.5.5.7.3.1). As discussed in [He], the security of EAP-TLS can be compromised if the same credentials are used for authentication within multiple applications. Certificate extensions for use with EAP-TLS are discussed in "Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)" [RFC4334]. These extensions enable certificate usage to be restricted to use with lower layers such as PPP or IEEE 802.11. An EAP-TLS implementation MAY make these and other certificate fields available to the lower layer. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Oct 23 00:40:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbrcG-0003a1-Tk; Mon, 23 Oct 2006 00:40:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbrcF-0003Zw-Vu for emu@ietf.org; Mon, 23 Oct 2006 00:40:47 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbrcE-0001R0-MK for emu@ietf.org; Mon, 23 Oct 2006 00:40:47 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 22 Oct 2006 21:40: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 k9N4ekAA025100 for ; Sun, 22 Oct 2006 21:40:46 -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 k9N4ekW4006060 for ; Sun, 22 Oct 2006 21:40:46 -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); Sun, 22 Oct 2006 21:40: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 Date: Sun, 22 Oct 2006 21:40:44 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tying EAP-TLS method type to specific ciphersuites Thread-Index: Acb2XWbZa3g+quUYSYe+AXdCZeeihA== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 23 Oct 2006 04:40:45.0942 (UTC) FILETIME=[67BC4160:01C6F65D] DKIM-Signature: a=rsa-sha1; q=dns; l=769; t=1161578446; x=1162442446; 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:Tying=20EAP-TLS=20method=20type=20to=20specific=20ciphersuites; X=v=3Dcisco.com=3B=20h=3Dp8zQUIVrRcdIklTAeEq3lKyal4o=3D; b=i1SNs2OxmryfrB2FvA+5C7uSMqNZs3lwGh8N4S68KENr1OoiUu9flEMxMKO+IkgbTus5uh1d RDPRySN8+nN35kIb8RGZnR6WG6jz53QPvSrgXjj+1uyZU2R94kh0RCnE; 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: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Emu] Tying EAP-TLS method type to specific 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 We have had discussions on limiting the ciphersuites that are supported by EAP-TLS in the past. In particular it seemed that there was some leaning towards limiting it to certificate based ciphersuites. For the most part this seems unnecessary since TLS supports ciphersuite negotiation. However some have raised the concern that negotiating the use of different credentials may not be appropriate at the TLS level. If this is the case then one approach would be to assign different EAP method types to different types of ciphersuites.=20 Do people see the need to limit the types of ciphersuites that can be negotiated within EAP-TLS? =20 If so what would be the appropriate way to divide up the ciphersuites with method types?=20 Thanks, Joe _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Oct 23 12:17:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc2UB-0005k5-DQ; Mon, 23 Oct 2006 12:17:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc2UA-0005k0-4o for emu@ietf.org; Mon, 23 Oct 2006 12:17:10 -0400 Received: from bay0-omc3-s7.bay0.hotmail.com ([65.54.246.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc2U6-0007J6-IT for emu@ietf.org; Mon, 23 Oct 2006 12:17:10 -0400 Received: from hotmail.com ([207.46.8.100]) by bay0-omc3-s7.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 09:17:06 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 23 Oct 2006 09:17:05 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Mon, 23 Oct 2006 16:17:00 GMT X-Originating-IP: [24.16.73.85] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: emu@ietf.org Bcc: Subject: RE: [Emu] Tying EAP-TLS method type to specific ciphersuites Date: Mon, 23 Oct 2006 09:17:00 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 23 Oct 2006 16:17:05.0609 (UTC) FILETIME=[AE5B8390:01C6F6BE] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 During the EMU BOF we talked about the high cost that would be imposed on customers by introducing new non-certificate ciphersuites during EAP-TLS. EAP-TLS is now ten years old, and has a very large installed base. Virtually all of these installations only support certificate-based authentication, since that is a requirement of RFC 2716, which states: If the EAP server is not resuming a previously established session, then it MUST include a TLS server_certificate handshake message, and a server_hello_done handshake message MUST be the last handshake message encapsulated in this EAP-Request packet.... If the EAP server sent a certificate_request message in the preceding EAP-Request packet, then the peer MUST send, in addition, certificate and certificate_verify handshake messages. As a result of these and other specification requirements, an implementation that does not support certificate authentication is non-compliant with RFC 2716. During the BOF we also talked about the drawbacks of attempting to support both certificate and non-certificate modes in a single EAP method. Such an approach would require embedded systems to take on the footprint of certificate handling even when all they really needed to do was to support pre-shared keys. It would also add new potential security vulnerabilities to one of the few EAP methods that has provable security properties. In addition adding new non-certificate modes would impose large costs on customers. Today there are interoperability and conformance test suites for EAP-TLS that assume that only certificate-based authentication is supported. In addition, EAP-TLS has been approved for use within FIPS 140-2 installations, based on support for certificate-base ciphersuites. Introducing new non-certificate modes would introduce confusion, and would force existing test suites to be re-written. For customers, deployment of EAP is difficult enough without introducing confusion, interoperability problems and new security vulnerabilities into the one EAP method that today is synonmous with high security. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Oct 23 12:17:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc2Ux-0005xW-C7; Mon, 23 Oct 2006 12:17:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc2Uv-0005xI-NR for emu@ietf.org; Mon, 23 Oct 2006 12:17:57 -0400 Received: from mcfeely.cs.umd.edu ([128.8.128.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc2Us-0007RX-8P for emu@ietf.org; Mon, 23 Oct 2006 12:17:57 -0400 Received: from mcfeely.cs.umd.edu (localhost [127.0.0.1]) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id k9NGHrEn022151; Mon, 23 Oct 2006 12:17:53 -0400 Received: (from apache@localhost) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.11/Submit) id k9NGHqTp022149; Mon, 23 Oct 2006 12:17:52 -0400 X-Authentication-Warning: mcfeely.cs.umd.edu: apache set sender to clancy@cs.umd.edu using -f Received: from 63.239.69.1 (SquirrelMail authenticated user clancy) by webmail.cs.umd.edu with HTTP; Mon, 23 Oct 2006 12:17:52 -0400 (EDT) Message-ID: <64039.63.239.69.1.1161620272.squirrel@webmail.cs.umd.edu> In-Reply-To: References: Date: Mon, 23 Oct 2006 12:17:52 -0400 (EDT) Subject: Re: [Emu] Tying EAP-TLS method type to specific ciphersuites From: "Charles Clancy" To: "Joseph Salowey \(jsalowey\)" User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 > Do people see the need to limit the types of ciphersuites that can be > negotiated within EAP-TLS? In general, no. > If so what would be the appropriate way to divide up the ciphersuites > with method types? When going down this road, it's difficult to tell where you should stop. The first step would be splitting PSK and PKI into two different EAP types. The problem is that the argument for doing the first split can be recursively applied until we have a different EAP type code for every EAP-TLS ciphersuite. I think the point of EAP-level vs TLS-level credential negotiation is valid from a protocol standpoint, but of insignificant importance in real-world deployments. For example, I've yet to encounter an 11i network that supports more than a single EAP type for authentication. Are we trying to solve a non-existant problem? Are there *real-world* scenarios (i.e. something someone has actually encountered, and not a hypothetical corner case) where this would be a *real* issue? -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Oct 23 12:37:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc2ni-0002hJ-IA; Mon, 23 Oct 2006 12:37:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc2nh-0002eN-NQ for emu@ietf.org; Mon, 23 Oct 2006 12:37:21 -0400 Received: from mcfeely.cs.umd.edu ([128.8.128.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc2iN-0000Wc-8C for emu@ietf.org; Mon, 23 Oct 2006 12:31:52 -0400 Received: from mcfeely.cs.umd.edu (localhost [127.0.0.1]) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id k9NGSbT7023121; Mon, 23 Oct 2006 12:28:37 -0400 Received: (from apache@localhost) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.11/Submit) id k9NGSbJg023119; Mon, 23 Oct 2006 12:28:37 -0400 X-Authentication-Warning: mcfeely.cs.umd.edu: apache set sender to clancy@cs.umd.edu using -f Received: from 63.239.69.1 (SquirrelMail authenticated user clancy) by webmail.cs.umd.edu with HTTP; Mon, 23 Oct 2006 12:28:37 -0400 (EDT) Message-ID: <59123.63.239.69.1.1161620917.squirrel@webmail.cs.umd.edu> In-Reply-To: References: Date: Mon, 23 Oct 2006 12:28:37 -0400 (EDT) Subject: RE: [Emu] Tying EAP-TLS method type to specific ciphersuites From: "Charles Clancy" To: "Bernard Aboba" User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 So that answers the questions from my last email. It sounds like PKI vs PSK is a reasonable split, but for reasons somewhat unrelated to EAP vs TLS credential negotiation, which I don't see as a big problem, personally. Should the split be EAP-TLS-v1 (PKI only) vs EAP-TLS-v2 (PKI and PSK)? Or EAP-TLS-PKI and EAP-TLS-PSK? If we have both legacy issues AND footprint issues, perhaps something like ... EAP-TLS-v1 EAP-TLS-v2-PSK EAP-TLS-v2-PKI ... might be appropriate. -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy On Mon, October 23, 2006 12:17 pm, Bernard Aboba wrote: > During the EMU BOF we talked about the high cost that would be imposed on > customers by introducing new non-certificate ciphersuites during EAP-TLS. > > EAP-TLS is now ten years old, and has a very large installed base. > Virtually all of these installations only support certificate-based > authentication, since that is a requirement of RFC 2716, which states: > > If the EAP server is not resuming a previously established > session, then it MUST include a TLS server_certificate handshake > message, and a server_hello_done handshake message MUST be the last > handshake message encapsulated in this EAP-Request packet.... > > If the EAP server sent a certificate_request message in the preceding > EAP-Request packet, then > the peer MUST send, in addition, certificate and certificate_verify > handshake messages. > > As a result of these and other specification requirements, an > implementation > that does not support certificate authentication is non-compliant with RFC > 2716. > > During the BOF we also talked about the drawbacks of attempting to support > both certificate and non-certificate modes in a single EAP method. Such > an > approach would require embedded systems to take on the footprint of > certificate handling even when all they really needed to do was to support > pre-shared keys. It would also add new potential security vulnerabilities > to one of the few EAP methods that has provable security properties. > > In addition adding new non-certificate modes would impose large costs on > customers. Today there are interoperability and conformance test suites > for > EAP-TLS that assume that only certificate-based authentication is > supported. > In addition, EAP-TLS has been approved for use within FIPS 140-2 > installations, based on support for certificate-base ciphersuites. > Introducing new non-certificate modes would introduce confusion, and would > force existing test suites to be re-written. > > For customers, deployment of EAP is difficult enough without introducing > confusion, interoperability problems and new security vulnerabilities into > the one EAP method that today is synonmous with high security. > > > > _______________________________________________ > 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 Oct 23 14:44:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc4mU-0003cq-4s; Mon, 23 Oct 2006 14:44:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc4mS-0003cR-Ap for emu@ietf.org; Mon, 23 Oct 2006 14:44:12 -0400 Received: from nz-out-0102.google.com ([64.233.162.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc4ll-0001yI-37 for emu@ietf.org; Mon, 23 Oct 2006 14:44:12 -0400 Received: by nz-out-0102.google.com with SMTP id 13so632897nzn for ; Mon, 23 Oct 2006 11:43:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=f5wsXgq2kiZiLp3/mvr1Q8sQSUQPW/72dSOTStdu09C97CntLUEtUe6WPgq6/NM089kZW7fhy/QSbZAAMmsPfmb5LSyP8Pv7bZo/kE2vXdsimIvI6Zl6yT7spM3NiWE2GI8otAdIfdBqMLieZxvzRJYK2Pv7DAMjTb3HwIHXamg= Received: by 10.64.27.13 with SMTP id a13mr5839606qba; Mon, 23 Oct 2006 11:43:28 -0700 (PDT) Received: by 10.65.220.13 with HTTP; Mon, 23 Oct 2006 11:43:28 -0700 (PDT) Message-ID: Date: Mon, 23 Oct 2006 20:43:28 +0200 From: Badra To: "Charles Clancy" Subject: Re: [Emu] Tying EAP-TLS method type to specific ciphersuites In-Reply-To: <59123.63.239.69.1.1161620917.squirrel@webmail.cs.umd.edu> MIME-Version: 1.0 References: <59123.63.239.69.1.1161620917.squirrel@webmail.cs.umd.edu> X-Spam-Score: 0.5 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d 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: , Content-Type: multipart/mixed; boundary="===============2105446680==" Errors-To: emu-bounces@ietf.org --===============2105446680== Content-Type: multipart/alternative; boundary="----=_Part_152701_9376861.1161629008566" ------=_Part_152701_9376861.1161629008566 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline So what Joe did propose is the appropriate way: assign different EAP method types to different types of ciphersuites. > Do people see the need to limit the types of ciphersuites that can be > negotiated within EAP-TLS? I think it is better to keep TLS ciphersuite negotiation as it is. Best regards, Badra On 10/23/06, Charles Clancy wrote: > > So that answers the questions from my last email. It sounds like PKI vs > PSK is a reasonable split, but for reasons somewhat unrelated to EAP vs > TLS credential negotiation, which I don't see as a big problem, > personally. > > Should the split be EAP-TLS-v1 (PKI only) vs EAP-TLS-v2 (PKI and PSK)? Or > EAP-TLS-PKI and EAP-TLS-PSK? If we have both legacy issues AND footprint > issues, perhaps something like ... > > EAP-TLS-v1 > EAP-TLS-v2-PSK > EAP-TLS-v2-PKI > > ... might be appropriate. > > -- > t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy > > On Mon, October 23, 2006 12:17 pm, Bernard Aboba wrote: > > During the EMU BOF we talked about the high cost that would be imposed > on > > customers by introducing new non-certificate ciphersuites during > EAP-TLS. > > > > EAP-TLS is now ten years old, and has a very large installed base. > > Virtually all of these installations only support certificate-based > > authentication, since that is a requirement of RFC 2716, which states: > > > > If the EAP server is not resuming a previously established > > session, then it MUST include a TLS server_certificate handshake > > message, and a server_hello_done handshake message MUST be the last > > handshake message encapsulated in this EAP-Request packet.... > > > > If the EAP server sent a certificate_request message in the preceding > > EAP-Request packet, then > > the peer MUST send, in addition, certificate and certificate_verify > > handshake messages. > > > > As a result of these and other specification requirements, an > > implementation > > that does not support certificate authentication is non-compliant with > RFC > > 2716. > > > > During the BOF we also talked about the drawbacks of attempting to > support > > both certificate and non-certificate modes in a single EAP method. > Such > > an > > approach would require embedded systems to take on the footprint of > > certificate handling even when all they really needed to do was to > support > > pre-shared keys. It would also add new potential security > vulnerabilities > > to one of the few EAP methods that has provable security properties. > > > > In addition adding new non-certificate modes would impose large costs on > > customers. Today there are interoperability and conformance test suites > > for > > EAP-TLS that assume that only certificate-based authentication is > > supported. > > In addition, EAP-TLS has been approved for use within FIPS 140-2 > > installations, based on support for certificate-base ciphersuites. > > Introducing new non-certificate modes would introduce confusion, and > would > > force existing test suites to be re-written. > > > > For customers, deployment of EAP is difficult enough without introducing > > confusion, interoperability problems and new security vulnerabilities > into > > the one EAP method that today is synonmous with high security. > > > > > > > > _______________________________________________ > > 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 > ------=_Part_152701_9376861.1161629008566 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
So what Joe did propose is the appropriate way: assign different EAP
method types to different types of ciphersuites.
 
Do people see the need to limit the types of ciphersuites that can be
negotiated within EAP-TLS?
 
I think it is better to keep TLS ciphersuite negotiation as it is.
Best regards,
Badra
 
On 10/23/06, Charles Clancy <clancy@cs.umd.edu> wrote:
So that answers the questions from my last email.  It sounds like PKI vs
PSK is a reasonable split, but for reasons somewhat unrelated to EAP vs
TLS credential negotiation, which I don't see as a big problem,
personally.

Should the split be EAP-TLS-v1 (PKI only) vs EAP-TLS-v2 (PKI and PSK)?  Or
EAP-TLS-PKI and EAP-TLS-PSK?  If we have both legacy issues AND footprint
issues, perhaps something like ...

EAP-TLS-v1
EAP-TLS-v2-PSK
EAP-TLS-v2-PKI

... might be appropriate.

--
t. charles clancy, ph.d.  <>  tcc@umd.edu  <>   www.cs.umd.edu/~clancy

On Mon, October 23, 2006 12:17 pm, Bernard Aboba wrote:
> During the EMU BOF we talked about the high cost that would be imposed on
> customers by introducing new non-certificate ciphersuites during EAP-TLS.
>
> EAP-TLS is now ten years old, and has a very large installed base.
> Virtually all of these installations only support certificate-based
> authentication, since that is a requirement of RFC 2716, which states:
>
>    If the EAP server is not resuming a previously established
>    session, then it MUST include a TLS server_certificate handshake
>    message, and a server_hello_done handshake message MUST be the last
>    handshake message encapsulated in this EAP-Request packet....
>
>    If the EAP server sent a certificate_request message in the preceding
> EAP-Request packet, then
>    the peer MUST send, in addition, certificate and certificate_verify
> handshake messages.
>
> As a result of these and other specification requirements, an
> implementation
> that does not support certificate authentication is non-compliant with RFC
> 2716.
>
> During the BOF we also talked about the drawbacks of attempting to support
> both certificate and non-certificate modes in a single EAP method.   Such
> an
> approach would require embedded systems to take on the footprint of
> certificate handling even when all they really needed to do was to support
> pre-shared keys.  It would also add new potential security vulnerabilities
> to one of the few EAP methods that has provable security properties.
>
> In addition adding new non-certificate modes would impose large costs on
> customers. Today there are interoperability and conformance test suites
> for
> EAP-TLS that assume that only certificate-based authentication is
> supported.
>   In addition, EAP-TLS has been approved for use within FIPS 140-2
> installations, based on support for certificate-base ciphersuites.
> Introducing new non-certificate modes would introduce confusion, and would
> force existing test suites to be re-written.
>
> For customers, deployment of EAP is difficult enough without introducing
> confusion, interoperability problems and new security vulnerabilities into
> the one EAP method that today is synonmous with high security.
>
>
>
> _______________________________________________
> 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

------=_Part_152701_9376861.1161629008566-- --===============2105446680== 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 --===============2105446680==-- From emu-bounces@ietf.org Mon Oct 23 15:29:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc5UJ-0002DD-Ud; Mon, 23 Oct 2006 15:29:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc5UI-0002Cl-Sh for emu@ietf.org; Mon, 23 Oct 2006 15:29:30 -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 1Gc5GR-0005WV-Fh for emu@ietf.org; Mon, 23 Oct 2006 15:15:11 -0400 Received: from mail730.megamailservers.com ([69.49.98.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gc507-00070a-Hq for emu@ietf.org; Mon, 23 Oct 2006 14:58:24 -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 mail730.megamailservers.com (8.13.6.20060614/8.13.1) with ESMTP id k9NIw5gw020539; Mon, 23 Oct 2006 14:58:08 -0400 From: "Ray Bell" To: "'Badra'" , "'Charles Clancy'" Subject: RE: [Emu] Tying EAP-TLS method type to specific ciphersuites Date: Mon, 23 Oct 2006 11:58:00 -0700 Message-ID: <001101c6f6d5$2a441650$63cba744@RBLAPTOP> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb200rLIOKMjxm9RH20IRE9UiIcFwAAay6w X-Spam-Score: 0.1 (/) X-Scan-Signature: 3643ee1fccf5d6cf2af25f27d28abb29 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: , Content-Type: multipart/mixed; boundary="===============1183496734==" Errors-To: emu-bounces@ietf.org This is a multi-part message in MIME format. --===============1183496734== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C6F69A.7DE53E50" This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C6F69A.7DE53E50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit There appears to be a requirement for either approach, or a combination of both. I thought Charles' suggestion made sense. Ray _____ From: Badra [mailto:mbadra@gmail.com] Sent: Monday, October 23, 2006 11:43 AM To: Charles Clancy Cc: Bernard Aboba; emu@ietf.org Subject: Re: [Emu] Tying EAP-TLS method type to specific ciphersuites So what Joe did propose is the appropriate way: assign different EAP method types to different types of ciphersuites. Do people see the need to limit the types of ciphersuites that can be negotiated within EAP-TLS? I think it is better to keep TLS ciphersuite negotiation as it is. Best regards, Badra On 10/23/06, Charles Clancy wrote: So that answers the questions from my last email. It sounds like PKI vs PSK is a reasonable split, but for reasons somewhat unrelated to EAP vs TLS credential negotiation, which I don't see as a big problem, personally. Should the split be EAP-TLS-v1 (PKI only) vs EAP-TLS-v2 (PKI and PSK)? Or EAP-TLS-PKI and EAP-TLS-PSK? If we have both legacy issues AND footprint issues, perhaps something like ... EAP-TLS-v1 EAP-TLS-v2-PSK EAP-TLS-v2-PKI ... might be appropriate. -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy On Mon, October 23, 2006 12:17 pm, Bernard Aboba wrote: > During the EMU BOF we talked about the high cost that would be imposed on > customers by introducing new non-certificate ciphersuites during EAP-TLS. > > EAP-TLS is now ten years old, and has a very large installed base. > Virtually all of these installations only support certificate-based > authentication, since that is a requirement of RFC 2716, which states: > > If the EAP server is not resuming a previously established > session, then it MUST include a TLS server_certificate handshake > message, and a server_hello_done handshake message MUST be the last > handshake message encapsulated in this EAP-Request packet.... > > If the EAP server sent a certificate_request message in the preceding > EAP-Request packet, then > the peer MUST send, in addition, certificate and certificate_verify > handshake messages. > > As a result of these and other specification requirements, an > implementation > that does not support certificate authentication is non-compliant with RFC > 2716. > > During the BOF we also talked about the drawbacks of attempting to support > both certificate and non-certificate modes in a single EAP method. Such > an > approach would require embedded systems to take on the footprint of > certificate handling even when all they really needed to do was to support > pre-shared keys. It would also add new potential security vulnerabilities > to one of the few EAP methods that has provable security properties. > > In addition adding new non-certificate modes would impose large costs on > customers. Today there are interoperability and conformance test suites > for > EAP-TLS that assume that only certificate-based authentication is > supported. > In addition, EAP-TLS has been approved for use within FIPS 140-2 > installations, based on support for certificate-base ciphersuites. > Introducing new non-certificate modes would introduce confusion, and would > force existing test suites to be re-written. > > For customers, deployment of EAP is difficult enough without introducing > confusion, interoperability problems and new security vulnerabilities into > the one EAP method that today is synonmous with high security. > > > > _______________________________________________ > 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 ------=_NextPart_000_0012_01C6F69A.7DE53E50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There appears to be a requirement = for either approach, or a combination of both.  I thought Charles’ = suggestion made sense.

 

Ray

 

 

From: Badra [mailto:mbadra@gmail.com]
Sent: Monday, October 23, = 2006 11:43 AM
To: Charles Clancy
Cc: Bernard Aboba; = emu@ietf.org
Subject: Re: [Emu] Tying = EAP-TLS method type to specific ciphersuites

 

So what Joe did propose is the appropriate way: assign different = EAP
method types to different types of ciphersuites.
 

Do people see the need to limit the types of ciphersuites that = can be
negotiated within EAP-TLS?

 

I think it is better to keep TLS ciphersuite = negotiation as it is.

Best regards,

Badra
 

On 10/23/06, Charles Clancy <clancy@cs.umd.edu> wrote:

So that answers the questions from my last email.  It = sounds like PKI vs
PSK is a reasonable split, but for reasons somewhat unrelated to EAP vs =
TLS credential negotiation, which I don't see as a big problem,
personally.

Should the split be EAP-TLS-v1 (PKI only) vs EAP-TLS-v2 (PKI and PSK)?  Or
EAP-TLS-PKI and EAP-TLS-PSK?  If we have both legacy issues = AND footprint
issues, perhaps something like ...

EAP-TLS-v1
EAP-TLS-v2-PSK
EAP-TLS-v2-PKI

... might be appropriate.

--
t. charles clancy, ph.d.  <>  tcc@umd.edu  <> &nbs= p; www.cs.umd.edu/~clancy

On Mon, October 23, 2006 12:17 pm, Bernard Aboba wrote:
> During the EMU BOF we talked about the high cost that would be = imposed on
> customers by introducing new non-certificate ciphersuites during = EAP-TLS.
>
> EAP-TLS is now ten years old, and has a very large installed = base.
> Virtually all of these installations only support = certificate-based
> authentication, since that is a requirement of RFC 2716, which = states:
>
>    If the EAP server is not resuming a = previously established
>    session, then it MUST include a TLS server_certificate handshake
>    message, and a server_hello_done handshake = message MUST be the last
>    handshake message encapsulated in this = EAP-Request packet....
>
>    If the EAP server sent a certificate_request message in the preceding
> EAP-Request packet, then
>    the peer MUST send, in addition, certificate = and certificate_verify
> handshake messages.
>
> As a result of these and other specification requirements, an
> implementation
> that does not support certificate authentication is non-compliant = with RFC
> 2716.
>
> During the BOF we also talked about the drawbacks of attempting to = support
> both certificate and non-certificate modes in a single EAP method.   Such
> an
> approach would require embedded systems to take on the footprint of =
> certificate handling even when all they really needed to do was to = support
> pre-shared keys.  It would also add new potential = security vulnerabilities
> to one of the few EAP methods that has provable security = properties.
>
> In addition adding new non-certificate modes would impose large = costs on
> customers. Today there are interoperability and conformance test = suites
> for
> EAP-TLS that assume that only certificate-based authentication is =
> supported.
>   In addition, EAP-TLS has been approved for use within = FIPS 140-2
> installations, based on support for certificate-base = ciphersuites.
> Introducing new non-certificate modes would introduce confusion, = and would
> force existing test suites to be re-written.
>
> For customers, deployment of EAP is difficult enough without = introducing
> confusion, interoperability problems and new security = vulnerabilities into
> the one EAP method that today is synonmous with high security.
>
>
>
> _______________________________________________
> 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

 

------=_NextPart_000_0012_01C6F69A.7DE53E50-- --===============1183496734== 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 --===============1183496734==-- From emu-bounces@ietf.org Mon Oct 23 21:07:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcAlf-0001Mn-AK; Mon, 23 Oct 2006 21:07:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcAle-0001LT-ND for emu@ietf.org; Mon, 23 Oct 2006 21:07:46 -0400 Received: from bay0-omc1-s6.bay0.hotmail.com ([65.54.246.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcAld-00074o-9w for emu@ietf.org; Mon, 23 Oct 2006 21:07:46 -0400 Received: from hotmail.com ([207.46.8.106]) by bay0-omc1-s6.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 18:07:44 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 23 Oct 2006 18:07:44 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Tue, 24 Oct 2006 01:07:43 GMT X-Originating-IP: [131.107.0.72] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <001101c6f6d5$2a441650$63cba744@RBLAPTOP> From: "Bernard Aboba" To: emu@ietf.org Bcc: Subject: RE: [Emu] Tying EAP-TLS method type to specific ciphersuites Date: Mon, 23 Oct 2006 18:07:43 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 24 Oct 2006 01:07:44.0301 (UTC) FILETIME=[CFB25DD0:01C6F708] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 >Should the split be EAP-TLS-v1 (PKI only) vs EAP-TLS-v2 (PKI and PSK)? Or >EAP-TLS-PKI and EAP-TLS-PSK? If we have both legacy issues AND footprint >issues, perhaps something like ... So far, we've talked about handling PSK support by creating a new EAP method with a distinct name: "EAP-TLS-PSK". That approach enables embedded devices to implement only PSK ciphersuites, reducing footprint. It also avoids impacting the interoperability and security of existing EAP-TLS implementations. Given that EAP-TLS already supports PKI, I'm not sure why a distinct EAP method called "EAP-TLS-PKI" would be needed. Creating "versions" of EAP-TLS would potentially confuse customers and cause problems with existing test suites and certification programs. Witness the confusion that was created by PEAP versioning, where PEAPv0 and PEAPv1 did not interoperate. So I'd stay away from versioning if at all possible. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Oct 23 23:45:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcDDt-0008QS-Vv; Mon, 23 Oct 2006 23:45:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcBE5-0005zt-Rx for emu@ietf.org; Mon, 23 Oct 2006 21:37:09 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcB0G-00036W-88 for emu@ietf.org; Mon, 23 Oct 2006 21:22:55 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 23 Oct 2006 18:22:52 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9O1MpIl014964; Mon, 23 Oct 2006 18:22:51 -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 k9O1MkOf007169; Mon, 23 Oct 2006 18:22:51 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 Oct 2006 18:22:51 -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] Tying EAP-TLS method type to specific ciphersuites Date: Mon, 23 Oct 2006 18:22:49 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502D2C38D@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Tying EAP-TLS method type to specific ciphersuites Thread-Index: Acb3CNwA3swKYzfBT0yq6E7xZBVlKgAAb7oQ From: "Glen Zorn \(gwz\)" To: "Bernard Aboba" X-OriginalArrivalTime: 24 Oct 2006 01:22:51.0518 (UTC) FILETIME=[EC70B1E0:01C6F70A] DKIM-Signature: a=rsa-sha1; q=dns; l=518; t=1161652971; x=1162516971; c=relaxed/simple; s=sjdkim5002; 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]=20Tying=20EAP-TLS=20method=20type=20to=20specific=20cipher suites; X=v=3Dcisco.com=3B=20h=3DOjp2GugJG3217IDpFEQc4a1WtV4=3D; b=ezlLniKaCFGoMunUa3mHbSykYxf9ggPrrdIlHvfKcikpGHdZFnlLGUGW4wmjhMsPXD9DO0D2 5GzLf4/42RjFknskc0XbfRuzMdx+hmLc5iCbiDhR7YVjTbDt+hVY+0aB; Authentication-Results: sj-dkim-5.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-Mailman-Approved-At: Mon, 23 Oct 2006 23:45:02 -0400 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 Bernard Aboba supposedly scribbled on Monday, October 23, 2006 6:08 PM: ... > Creating "versions" of EAP-TLS would potentially confuse customers > and cause problems with existing test suites and certification > programs. Witness the confusion that was created by PEAP versioning, > where PEAPv0 and PEAPv1 did not interoperate. =20 I believe that the interoperability problems were caused by corporate power plays & infighting rather than versioning per se. ... _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Oct 25 03:07:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GccrU-0001YZ-SB; Wed, 25 Oct 2006 03:07:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GccrT-0001Ul-8f for emu@ietf.org; Wed, 25 Oct 2006 03:07:39 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GccrP-000174-N4 for emu@ietf.org; Wed, 25 Oct 2006 03:07:38 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9P74Mq5013859; Wed, 25 Oct 2006 10:04:22 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 10:04:23 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 10:04:22 +0300 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] Tying EAP-TLS method type to specific ciphersuites Date: Wed, 25 Oct 2006 10:04:23 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Tying EAP-TLS method type to specific ciphersuites Thread-Index: Acb2vs63Uw0cyfQvRUKgNkkR9I9FYQBRI2zA From: To: , X-OriginalArrivalTime: 25 Oct 2006 07:04:22.0309 (UTC) FILETIME=[CC510550:01C6F803] X-Spam-Score: 0.2 (/) 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 Bernard Aboba wrote: > In addition adding new non-certificate modes would impose large > costs on customers. Today there are interoperability and conformance > test suites for EAP-TLS that assume that only certificate-based > authentication is supported. > > In addition, EAP-TLS has been approved for use within FIPS 140-2 > installations, based on support for certificate-base ciphersuites. > Introducing new non-certificate modes would introduce confusion, and > would force existing test suites to be re-written. >=20 > For customers, deployment of EAP is difficult enough without > introducing confusion, interoperability problems and new security > vulnerabilities into the one EAP method that today is synonmous with > high security. By certificate-based ciphersuites, do you mean TLS_RSA_WITH_* ciphersuites from RFC 2246 specifically, or any ciphersuite that=20 uses any kind of certificates? (To me it looks like many of these arguments would also suggest defining a separate EAP type code for e.g. ECC certificates based on the RFC 4492 ciphersuites. I don't think that would be a good idea...) Best regards, Pasi _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Oct 25 11:04:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GckIU-0002iK-OH; Wed, 25 Oct 2006 11:04:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GckIT-0002hK-33 for emu@ietf.org; Wed, 25 Oct 2006 11:04:01 -0400 Received: from bay0-omc1-s32.bay0.hotmail.com ([65.54.246.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GckIP-0003xd-70 for emu@ietf.org; Wed, 25 Oct 2006 11:04:01 -0400 Received: from hotmail.com ([207.46.8.83]) by bay0-omc1-s32.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 08:03:26 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 25 Oct 2006 08:02:58 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Wed, 25 Oct 2006 15:02:57 GMT X-Originating-IP: [131.107.0.101] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: Pasi.Eronen@nokia.com, emu@ietf.org Bcc: Subject: RE: [Emu] Tying EAP-TLS method type to specific ciphersuites Date: Wed, 25 Oct 2006 08:02:57 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 25 Oct 2006 15:02:58.0478 (UTC) FILETIME=[A87CACE0:01C6F846] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 >By certificate-based ciphersuites, do you mean TLS_RSA_WITH_* >ciphersuites from RFC 2246 specifically, or any ciphersuite that >uses any kind of certificates? Any ciphersuite supporting client certificate authentication would be ok. >(To me it looks like many of these arguments would also suggest >defining a separate EAP type code for e.g. ECC certificates >based on the RFC 4492 ciphersuites. I don't think that would >be a good idea...) I'd agree. It isn't necessary to have a new EAP method for each ciphersuite. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Oct 25 12:16:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GclQY-0003u0-0z; Wed, 25 Oct 2006 12:16:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GclQX-0003tT-8D for emu@ietf.org; Wed, 25 Oct 2006 12:16:25 -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 1GclQU-0001EL-SC for emu@ietf.org; Wed, 25 Oct 2006 12:16:25 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 25 Oct 2006 09:16:22 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9PGGMBH010292 for ; Wed, 25 Oct 2006 09:16:22 -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 k9PGG8j1014222 for ; Wed, 25 Oct 2006 09:16: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); Wed, 25 Oct 2006 09:16:19 -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, 25 Oct 2006 09:16:19 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tentative Agenda for EMU at IETF 67 Thread-Index: Acb4UOePBfuWgRApSQmODqE3DkBKpQ== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 25 Oct 2006 16:16:19.0975 (UTC) FILETIME=[E7FBD170:01C6F850] DKIM-Signature: a=rsa-sha1; q=dns; l=664; t=1161792982; x=1162656982; 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:Tentative=20Agenda=20for=20EMU=20at=20IETF=2067; X=v=3Dcisco.com=3B=20h=3DmxbP9mi8LFCjx91wVwq6oynxSH4=3D; b=DDZqA3PMV6//qi1ZGhHrB6xMa9gVKGU3NWwCVf4jgj0+06xFf2+S/l8b9JRs6vJZmfFfwdp/ /7kzGXEBzC4nabwDDVteD02m/T0OGf2wbwpXBlIxn+QYIrp0Lj8JGzqJ; 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: 2409bba43e9c8d580670fda8b695204a Subject: [Emu] Tentative Agenda for EMU at IETF 67 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 Below is the tentative agenda for EMU. Please let me know if you have any additions or corrections. Thanks, Joe EMU Agenda For IETF 67 -------------------------------------- EMU Session 1 (2 hours) Monday, Afternoon Session I 1300-1500 Room Name: Harbor 1 -------------------------------------- 1. Agenda bashing, blue sheets, note takes - 5 min 2. EAP-TLS (Aboba) - 30 min http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-03.txt 3. EAP-GPSK (Clancy/Tschofenig) - 30 min=20 http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-00.txt 4. TLS-Enhanced (TBD) - 25 min 5. Password based method (TBD) - 25 min _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Oct 25 16:00:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcovk-0000yu-Uv; Wed, 25 Oct 2006 16:00:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcoll-00043G-6e; Wed, 25 Oct 2006 15:50:33 -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 1Gcoll-0007vU-4X; Wed, 25 Oct 2006 15:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gcolk-000638-RD; Wed, 25 Oct 2006 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 8BCD2175BC; Wed, 25 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GcolG-0004nx-2I; Wed, 25 Oct 2006 15:50:02 -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: Wed, 25 Oct 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: emu@ietf.org Subject: [Emu] I-D ACTION:draft-simon-emu-rfc2716bis-04.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-04.txt Pages : 35 Date : 2006-10-25 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-04.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-04.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-04.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-10-25105244.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-simon-emu-rfc2716bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-simon-emu-rfc2716bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-25105244.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 Thu Oct 26 12:45:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd8Li-0006Hf-HO; Thu, 26 Oct 2006 12:44:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd8Lh-0006HZ-Ka for emu@ietf.org; Thu, 26 Oct 2006 12:44:57 -0400 Received: from mcfeely.cs.umd.edu ([128.8.128.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd8Lb-0005HU-Su for emu@ietf.org; Thu, 26 Oct 2006 12:44:57 -0400 Received: from mcfeely.cs.umd.edu (localhost [127.0.0.1]) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id k9QGinGI016372; Thu, 26 Oct 2006 12:44:49 -0400 Received: (from apache@localhost) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.11/Submit) id k9QGinRw016370; Thu, 26 Oct 2006 12:44:49 -0400 X-Authentication-Warning: mcfeely.cs.umd.edu: apache set sender to clancy@cs.umd.edu using -f Received: from 63.239.69.1 (SquirrelMail authenticated user clancy) by webmail.cs.umd.edu with HTTP; Thu, 26 Oct 2006 12:44:49 -0400 (EDT) Message-ID: <46710.63.239.69.1.1161881089.squirrel@webmail.cs.umd.edu> In-Reply-To: References: <001101c6f6d5$2a441650$63cba744@RBLAPTOP> Date: Thu, 26 Oct 2006 12:44:49 -0400 (EDT) Subject: RE: [Emu] Tying EAP-TLS method type to specific ciphersuites From: "Charles Clancy" To: "Bernard Aboba" User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal 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 So, it sounds like defining an EAP type code for EAP-TLS with non-PKI ciphersuites sounds like the best way to go. Would it be appropriate to have IANA allocate a new EAP type code with 2716bis, or have a seperate document discussing EAP-TLS with TLS-PSK ciphersuites? -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy On Mon, October 23, 2006 9:07 pm, Bernard Aboba wrote: >>Should the split be EAP-TLS-v1 (PKI only) vs EAP-TLS-v2 (PKI and PSK)? >> Or >>EAP-TLS-PKI and EAP-TLS-PSK? If we have both legacy issues AND footprint >>issues, perhaps something like ... > > So far, we've talked about handling PSK support by creating a new EAP > method > with a distinct name: "EAP-TLS-PSK". That approach enables embedded > devices to implement only PSK ciphersuites, reducing footprint. It also > avoids impacting the interoperability and security of existing EAP-TLS > implementations. > > Given that EAP-TLS already supports PKI, I'm not sure why a distinct EAP > method called "EAP-TLS-PKI" would be needed. > > Creating "versions" of EAP-TLS would potentially confuse customers and > cause > problems with existing test suites and certification programs. Witness > the > confusion that was created by PEAP versioning, where PEAPv0 and PEAPv1 did > not interoperate. So I'd stay away from versioning if at all possible. > > > > _______________________________________________ > 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 Thu Oct 26 12:52:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd8Sk-0001iu-3G; Thu, 26 Oct 2006 12:52:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd8Sj-0001gW-KQ for emu@ietf.org; Thu, 26 Oct 2006 12:52:13 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd8Se-0006aN-P6 for emu@ietf.org; Thu, 26 Oct 2006 12:52:13 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k9QGpoYH025305; Thu, 26 Oct 2006 18:51:50 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k9QGpnqw009222; Thu, 26 Oct 2006 18:51:50 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 18:51:49 +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] Tying EAP-TLS method type to specific ciphersuites Date: Thu, 26 Oct 2006 18:51:45 +0200 Message-ID: In-Reply-To: <46710.63.239.69.1.1161881089.squirrel@webmail.cs.umd.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Tying EAP-TLS method type to specific ciphersuites Thread-Index: Acb5HjS09OSHcbl+T262PHiIXtqBwQAAICtA From: "Tschofenig, Hannes" To: "Charles Clancy" , "Bernard Aboba" X-OriginalArrivalTime: 26 Oct 2006 16:51:49.0650 (UTC) FILETIME=[07C82F20:01C6F91F] 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 Hi Charles, > -----Urspr=FCngliche Nachricht----- > Von: Charles Clancy [mailto:clancy@cs.umd.edu]=20 > Gesendet: Donnerstag, 26. Oktober 2006 18:45 > An: Bernard Aboba > Cc: emu@ietf.org > Betreff: RE: [Emu] Tying EAP-TLS method type to specific ciphersuites >=20 > So, it sounds like defining an EAP type code for EAP-TLS with non-PKI > ciphersuites sounds like the best way to go. Would it be=20 > appropriate to > have IANA allocate a new EAP type code with 2716bis, or have=20 > a seperate > document discussing EAP-TLS with TLS-PSK ciphersuites? A separate document is needed since the security properties are = different. You need to describe them somewhere.=20 Example: draft-otto-emu-eap-tls-psk-01.txt For some other ciphersuites you even need todo more.=20 Example: A Kerberos based TLS ciphersuite Ciao Hannes >=20 > --=20 > t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy >=20 >=20 > On Mon, October 23, 2006 9:07 pm, Bernard Aboba wrote: > >>Should the split be EAP-TLS-v1 (PKI only) vs EAP-TLS-v2=20 > (PKI and PSK)? > >> Or > >>EAP-TLS-PKI and EAP-TLS-PSK? If we have both legacy issues=20 > AND footprint > >>issues, perhaps something like ... > > > > So far, we've talked about handling PSK support by creating=20 > a new EAP > > method > > with a distinct name: "EAP-TLS-PSK". That approach=20 > enables embedded > > devices to implement only PSK ciphersuites, reducing=20 > footprint. It also > > avoids impacting the interoperability and security of=20 > existing EAP-TLS > > implementations. > > > > Given that EAP-TLS already supports PKI, I'm not sure why a=20 > distinct EAP > > method called "EAP-TLS-PKI" would be needed. > > > > Creating "versions" of EAP-TLS would potentially confuse=20 > customers and > > cause > > problems with existing test suites and certification=20 > programs. Witness > > the > > confusion that was created by PEAP versioning, where PEAPv0=20 > and PEAPv1 did > > not interoperate. So I'd stay away from versioning if at=20 > all possible. > > > > > > > > _______________________________________________ > > 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 Thu Oct 26 14:10:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd9g7-0005cV-RA; Thu, 26 Oct 2006 14:10:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd9g6-0005aY-B3 for emu@ietf.org; Thu, 26 Oct 2006 14:10:06 -0400 Received: from mcfeely.cs.umd.edu ([128.8.128.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd9bF-000170-0l for emu@ietf.org; Thu, 26 Oct 2006 14:05:09 -0400 Received: from mcfeely.cs.umd.edu (localhost [127.0.0.1]) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id k9QI50DM023289; Thu, 26 Oct 2006 14:05:00 -0400 Received: (from apache@localhost) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.11/Submit) id k9QI4wwM023283; Thu, 26 Oct 2006 14:04:58 -0400 X-Authentication-Warning: mcfeely.cs.umd.edu: apache set sender to clancy@cs.umd.edu using -f Received: from 63.239.69.1 (SquirrelMail authenticated user clancy) by webmail.cs.umd.edu with HTTP; Thu, 26 Oct 2006 14:04:58 -0400 (EDT) Message-ID: <51725.63.239.69.1.1161885898.squirrel@webmail.cs.umd.edu> In-Reply-To: <20061021174326.GF6103@jm.kir.nu> References: <20061021174326.GF6103@jm.kir.nu> Date: Thu, 26 Oct 2006 14:04:58 -0400 (EDT) Subject: Re: [Emu] I-D ACTION:draft-ietf-emu-eap-gpsk-00.txt From: "Charles Clancy" To: "Jouni Malinen" User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 Jouni, Actually, the descriptions in chapter 6 are incorrect, and need be fixed to reflect the changes in chapter 4. The KDF in chapter 4 was changed to allow PSKs of variable length and entropy. Using the PSK to directly key the KDF to generate the MK has problems because most KDFs have fixed-length inputs for keys. Imagine someone who uses a 50-character passphrase (English text has around 2.5 bits of entropy per character, so that's roughly a 128-bit secure key). If we follow what's currently in chapter 6, we truncate that to 16 bytes, which would only be 40 bits of security. Not a good thing. -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy On Sat, October 21, 2006 1:43 pm, Jouni Malinen wrote: > On Wed, Oct 18, 2006 at 03:50:02PM -0400, Internet-Drafts@ietf.org wrote: >> Title : EAP Generalized Pre-Shared Key (EAP-GPSK) >> Author(s) : C. Clancy, H. Tschofenig >> Filename : draft-ietf-emu-eap-gpsk-00.txt > > While updating my implementation to the new draft, I noticed couple of > conflicts in how the key derivation is defined. Chapter 4 uses > KDF_Zero-String(PL || PSK | ...) to derive MK whereas 6.1.8 and 6.2.8 > use GKDF-#(PSK, ...). I would assume that the version in 6.1.8 and 6.2.8 > is the correct one and chapter 4 should be updated to match with this. > > Another difference is in whether CSuite_Sel is to be included in the > GKDF data field. Chapter 4 seems to include it (just before > inputString), but 6.1.8 and 6.2.8 do not. Should it be there or not? > > > The new draft is trying to fix the GKDF-X n (number of output blocks) > calculation, but that seems to have a typo of some sort. > > Now: n = int( X / size - 1 ) + 1; > > That doesn't make any sense since -1 and +1 are are cancelling eachother > and we are left with n = int( X / size ). > > I would assume that this was supposed to be taken into account rounding > up (ceiling) by using n = int( (X + size - 1) / size ) which could be > written as n = int( (X - 1) / size ) + 1. > > -- > Jouni Malinen PGP id EFC895FA > > _______________________________________________ > 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 Fri Oct 27 01:03:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdJrx-0002zj-Ut; Fri, 27 Oct 2006 01:03:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdJrw-0002ze-DE for emu@ietf.org; Fri, 27 Oct 2006 01:03:00 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdJru-0008Ee-2R for emu@ietf.org; Fri, 27 Oct 2006 01:03:00 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 26 Oct 2006 22:02:57 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9R52vFx004210; Thu, 26 Oct 2006 22:02:57 -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 k9R52vin024932; Thu, 26 Oct 2006 22:02:57 -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); Thu, 26 Oct 2006 22:02:57 -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] Review requested: draft-simon-emu-rfc2716bis-03.txt Date: Thu, 26 Oct 2006 22:02:55 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt Thread-Index: Acb18UXSEB3h4MAjRnyCjcSBqsylugDk92Bg From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 27 Oct 2006 05:02:57.0230 (UTC) FILETIME=[2AE5AEE0:01C6F985] DKIM-Signature: a=rsa-sha1; q=dns; l=1683; t=1161925377; x=1162789377; 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]=20Review=20requested=3A=20draft-simon-emu-rfc2716bis-03.tx t; X=v=3Dcisco.com=3B=20h=3D2AAb+kZJ932TAMgXcwIKUJYY8dc=3D; b=okSoTCsdkl4C0H9SpcYn4NwkXrG8pp5TFSvWjsqu1yU8nRjWGHWCLdiaMB/xrKkV0Ptq6pw5 DtSSLYWYkWezwzgC+lUFgCOZ1n3IGnkU1N0rgfAfXKQwstRqyK5neV6r; 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: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Looks good to me.=20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Sunday, October 22, 2006 8:47 AM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt >=20 > >The document should also state in the security=20 > considerations section=20 > >that the identity in the identity response is not=20 > necessarily related=20 > >to the identity authenticated in EAP-TLS and should not be=20 > relied upon=20 > >for any access control or accounting purposes. >=20 > Here is some proposed new text for Section 2.4: >=20 > "As noted in [RFC3748] Section 5.1: >=20 > It is RECOMMENDED that the Identity Response be used primarily for > routing purposes and selecting which EAP method to use. EAP > Methods SHOULD include a method-specific mechanism for obtaining > the identity, so that they do not have to rely on the Identity > Response. >=20 > As part of the TLS negotiation, the server presents a=20 > certificate to the peer, and if mutual authentication is=20 > requested, the peer presents a certificate to the server. =20 > EAP-TLS therefore provides a mechanism for determining both=20 > the peer identity (Peer-Id in [KEYFRAME]) and server identity=20 > (Server-Id in [KEYFRAME]). > Since the identity presented in the Identity Response need=20 > not be related to the identity presented in the peer=20 > certificate, EAP-TLS implementations SHOULD NOT require that=20 > they be identical, and SHOULD NOT use the identity presented=20 > in the Identity Response for access control or accounting purposes." >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Oct 27 01:15:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdK3e-0006DP-PX; Fri, 27 Oct 2006 01:15:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdK3d-0006Ah-PD for emu@ietf.org; Fri, 27 Oct 2006 01:15:05 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdK3a-0001uI-AJ for emu@ietf.org; Fri, 27 Oct 2006 01:15:05 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 26 Oct 2006 22:15:01 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9R5F1BT003801; Thu, 26 Oct 2006 22:15:01 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9R5Embr018427; Thu, 26 Oct 2006 22:15:00 -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); Thu, 26 Oct 2006 22:15:00 -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] Review requested: draft-simon-emu-rfc2716bis-03.txt Date: Thu, 26 Oct 2006 22:14:59 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt Thread-Index: Acb1+JQjg+jpSQNVTj2YFPF84EpHTgDjPGDA From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 27 Oct 2006 05:15:00.0374 (UTC) FILETIME=[D9ECB360:01C6F986] DKIM-Signature: a=rsa-sha1; q=dns; l=3972; t=1161926101; x=1162790101; 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:RE=3A=20[Emu]=20Review=20requested=3A=20draft-simon-emu-rfc2716bis-03.tx t; X=v=3Dcisco.com=3B=20h=3D2AAb+kZJ932TAMgXcwIKUJYY8dc=3D; b=MnWF6dxSYIEi8sCfux6J63PfAzqxKVC4bAlco1KwPa9evIfDfFbGzl9QxH+y15MI2jJ8Ot45 /SYHU1B6zhk0k95mIOpjQKZEPyDyiNPhnszeu9Ohk9hL/v4ucdHwV6ep; 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: 34d35111647d654d033d58d318c0d21a 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: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Sunday, October 22, 2006 9:39 AM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt >=20 > Joe Salowey said: >=20 > >Currently the section states that the peer identity is obtained from=20 > >the subjectAltName in the certificate. Is this text meant to be=20 > >normative? > >Currently there are implementations > >that use elements of the subject distinguished name and do=20 > not provide=20 > >a subjectAltName. > > > >Perhaps it would be better to say the subjectAltName is used=20 > if it is=20 > >present and if it is not then the subject distinguished name is used. > >However it seems that RFC3280 might indicate that it would=20 > be better to=20 > >use subject distinguished name if it is present and subjectAltName if > >not. This section should reference RFC3280. Also is there=20 > any reason > >why mapping using a directory service is called out, isn't=20 > just mapping=20 > >to a Peer-ID or Server-ID sufficient? > > > >It would may also be good to say that an EAP-TLS implementation MAY=20 > >make other certificate fields available to the lower layer. >=20 > I've added some text in Section 4.2 that hopefully will clear this up: >=20 > 4.2. Certificate Usage >=20 > The EAP-TLS peer name (Peer-Id) represents the Network Access > Identifier (NAI) [RFC4282] to be used for authorization and > accounting purposes. The Peer-Id is determined from the subject or > altSubjectName fields in the peer certificate. As noted=20 > in [RFC3280] > Section 4.1.2.6: >=20 > The subject field identifies the entity associated with=20 > the public > key stored in the subject public key field. The=20 > subject name MAY > be carried in the subject field and/or the subjectAltName > extension... If subject naming information is present=20 > only in the > subjectAltName extension (e.g., a key bound only to an email > address or URI), then the subject name MUST be an empty sequence > and the subjectAltName extension MUST be critical. >=20 > Where it is non-empty, the subject field MUST contain an X.500 > distinguished name (DN). >=20 > Where the subject field is not empty, the Peer-Id and Server-Id are > obtained from the Common Name (CN) field of the DN. Where subject > naming information is present only in the subjectAltName extension, > the Peer-Id and Server-Id are obtained from the subjectAltName. >=20 [Joe] OK > A valid EAP-TLS client certificate SHOULD contain an=20 > extendedKeyUsage > value indicating support for Client Authentication > (1.3.6.1.5.5.7.3.2). A valid EAP-TLS server certificate SHOULD > contain an extendedKeyUsage value indicating support for Server > Authentication (1.3.6.1.5.5.7.3.1). >=20 [Joe] I think I remember that some protocols specify the presence of a specific EKU or the ANY EKU. > As discussed in [He], the security of EAP-TLS can be compromised if > the same credentials are used for authentication within multiple > applications. =20 [Joe] I haven't looked at [He] in a while, but I thought that it wasn't applications in general, but applications that use a protocol that bindly signs arbitrary data. Perhaps this should be a bit clearer.=20 > Certificate extensions for use with EAP-TLS are > discussed in "Certificate Extensions and Attributes Supporting > Authentication in Point-to-Point Protocol (PPP) and Wireless Local > Area Networks (WLAN)" [RFC4334]. These extensions enable=20 > certificate > usage to be restricted to use with lower layers such as=20 > PPP or IEEE 802.11. > An EAP-TLS implementation MAY make these and other=20 > certificate fields > available to the lower layer. >=20 [Joe] OK _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Oct 27 01:27:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdKFC-00043b-6h; Fri, 27 Oct 2006 01:27:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdKFA-00043Q-8C for emu@ietf.org; Fri, 27 Oct 2006 01:27:00 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdKF8-0003qO-S8 for emu@ietf.org; Fri, 27 Oct 2006 01:27:00 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 26 Oct 2006 22:26:58 -0700 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 k9R5Qwce008644; Thu, 26 Oct 2006 22:26:58 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9R5QvAo014517; Thu, 26 Oct 2006 22:26:58 -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); Thu, 26 Oct 2006 22:26:57 -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] Tying EAP-TLS method type to specific ciphersuites Date: Thu, 26 Oct 2006 22:26:56 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Tying EAP-TLS method type to specific ciphersuites Thread-Index: Acb5HjS09OSHcbl+T262PHiIXtqBwQAAICtAABpHkpA= From: "Joseph Salowey \(jsalowey\)" To: "Tschofenig, Hannes" , "Charles Clancy" , "Bernard Aboba" X-OriginalArrivalTime: 27 Oct 2006 05:26:57.0513 (UTC) FILETIME=[855F6D90:01C6F988] DKIM-Signature: a=rsa-sha1; q=dns; l=3377; t=1161926818; x=1162790818; 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]=20Tying=20EAP-TLS=20method=20type=20to=20specific=20cipher suites; X=v=3Dcisco.com=3B=20h=3D6zj/5MZ6S9RCo3x6FqXz5S1aVBI=3D; b=o497N6vXhZg2ss/Jw+kv29Yen5XrP+AL3QR9D295lKiEtend0xDJK3gqIY9i9wEoCDemB4DC LvL3JNardPKMulssDGk5BvdVr+IA/JO01gE0udOX+7BQPqFHi6K9odaw; 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: 944ecb6e61f753561f559a497458fb4f 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 think the typecode and separate document are orthogonal. There has = been discussion of adding enhancements to EAP-TLS, such as channel = bindings, which would probably not be backward compatible. In this case = we would need a new typecode for this new protocol. PSK or other = ciphersuites could be negotiated in TLS under this method type. =20 Joe > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 > Sent: Thursday, October 26, 2006 9:52 AM > To: Charles Clancy; Bernard Aboba > Cc: emu@ietf.org > Subject: AW: [Emu] Tying EAP-TLS method type to specific ciphersuites >=20 > Hi Charles, >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Charles Clancy [mailto:clancy@cs.umd.edu] > > Gesendet: Donnerstag, 26. Oktober 2006 18:45 > > An: Bernard Aboba > > Cc: emu@ietf.org > > Betreff: RE: [Emu] Tying EAP-TLS method type to specific=20 > ciphersuites > >=20 > > So, it sounds like defining an EAP type code for EAP-TLS=20 > with non-PKI=20 > > ciphersuites sounds like the best way to go. Would it be=20 > appropriate=20 > > to have IANA allocate a new EAP type code with 2716bis, or have a=20 > > seperate document discussing EAP-TLS with TLS-PSK ciphersuites? >=20 > A separate document is needed since the security properties=20 > are different. > You need to describe them somewhere.=20 >=20 > Example: > draft-otto-emu-eap-tls-psk-01.txt >=20 > For some other ciphersuites you even need todo more.=20 > Example: A Kerberos based TLS ciphersuite >=20 > Ciao > Hannes >=20 >=20 > >=20 > > -- > > t. charles clancy, ph.d. <> tcc@umd.edu <> =20 > www.cs.umd.edu/~clancy > >=20 > >=20 > > On Mon, October 23, 2006 9:07 pm, Bernard Aboba wrote: > > >>Should the split be EAP-TLS-v1 (PKI only) vs EAP-TLS-v2 > > (PKI and PSK)? > > >> Or > > >>EAP-TLS-PKI and EAP-TLS-PSK? If we have both legacy issues > > AND footprint > > >>issues, perhaps something like ... > > > > > > So far, we've talked about handling PSK support by creating > > a new EAP > > > method > > > with a distinct name: "EAP-TLS-PSK". That approach=20 > > enables embedded > > > devices to implement only PSK ciphersuites, reducing > > footprint. It also > > > avoids impacting the interoperability and security of > > existing EAP-TLS > > > implementations. > > > > > > Given that EAP-TLS already supports PKI, I'm not sure why a > > distinct EAP > > > method called "EAP-TLS-PKI" would be needed. > > > > > > Creating "versions" of EAP-TLS would potentially confuse > > customers and > > > cause > > > problems with existing test suites and certification > > programs. Witness > > > the > > > confusion that was created by PEAP versioning, where PEAPv0 > > and PEAPv1 did > > > not interoperate. So I'd stay away from versioning if at=20 > > all possible. > > > > > > > > > > > > _______________________________________________ > > > 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 Fri Oct 27 01:29:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdKHG-0001L8-JH; Fri, 27 Oct 2006 01:29:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdKHF-0001Kt-OA for emu@ietf.org; Fri, 27 Oct 2006 01:29:09 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdKHC-0003ym-Mn for emu@ietf.org; Fri, 27 Oct 2006 01:29:09 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 26 Oct 2006 22:29:07 -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 k9R5T6K3021163; Thu, 26 Oct 2006 22:29:06 -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 k9R5T6Ao015426; Thu, 26 Oct 2006 22:29:06 -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); Thu, 26 Oct 2006 22:29:05 -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] Tying EAP-TLS method type to specific ciphersuites Date: Thu, 26 Oct 2006 22:29:04 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Tying EAP-TLS method type to specific ciphersuites Thread-Index: Acb2vru3gOh3KEAqSHqHI+a2b/LA1gCyd1tQ From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 27 Oct 2006 05:29:05.0991 (UTC) FILETIME=[D1F39D70:01C6F988] DKIM-Signature: a=rsa-sha1; q=dns; l=2845; t=1161926946; x=1162790946; 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]=20Tying=20EAP-TLS=20method=20type=20to=20specific=20cipher suites; X=v=3Dcisco.com=3B=20h=3DZSzsBQ6530/h4e5ZbHbM6vMdABY=3D; b=FaFG2M6BaTw2hIKeVsLfYN3ocYaaKcNIcwrsFJKdZbqz7rOi3jic3UFtGWeoA9WZE4yBAB7n CT4A0xhE1qwNWawZynaV73loTJHxhUJu6bRd5e/0s8rKbCww4+JRWv5A; 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: 244a2fd369eaf00ce6820a760a3de2e8 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 I don't think we would go down the route of making other types of ciphersuites mandatory to implement. =20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Monday, October 23, 2006 9:17 AM > To: emu@ietf.org > Subject: RE: [Emu] Tying EAP-TLS method type to specific ciphersuites >=20 > During the EMU BOF we talked about the high cost that would=20 > be imposed on customers by introducing new non-certificate=20 > ciphersuites during EAP-TLS. >=20 > EAP-TLS is now ten years old, and has a very large installed base. =20 > Virtually all of these installations only support=20 > certificate-based authentication, since that is a requirement=20 > of RFC 2716, which states: >=20 > If the EAP server is not resuming a previously established > session, then it MUST include a TLS server_certificate handshake > message, and a server_hello_done handshake message MUST be the last > handshake message encapsulated in this EAP-Request packet.... >=20 > If the EAP server sent a certificate_request message in=20 > the preceding EAP-Request packet, then > the peer MUST send, in addition, certificate and=20 > certificate_verify handshake messages. >=20 > As a result of these and other specification requirements, an=20 > implementation that does not support certificate=20 > authentication is non-compliant with RFC 2716. >=20 > During the BOF we also talked about the drawbacks of=20 > attempting to support=20 > both certificate and non-certificate modes in a single EAP=20 > method. Such an=20 > approach would require embedded systems to take on the=20 > footprint of certificate handling even when all they really=20 > needed to do was to support pre-shared keys. It would also=20 > add new potential security vulnerabilities to one of the few=20 > EAP methods that has provable security properties. >=20 > In addition adding new non-certificate modes would impose=20 > large costs on customers. Today there are interoperability=20 > and conformance test suites for EAP-TLS that assume that only=20 > certificate-based authentication is supported.=20 > In addition, EAP-TLS has been approved for use within FIPS=20 > 140-2 installations, based on support for certificate-base=20 > ciphersuites. =20 > Introducing new non-certificate modes would introduce=20 > confusion, and would force existing test suites to be re-written. >=20 > For customers, deployment of EAP is difficult enough without=20 > introducing confusion, interoperability problems and new=20 > security vulnerabilities into the one EAP method that today=20 > is synonmous with high security. >=20 >=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 Fri Oct 27 13:01:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdV54-0006gQ-Ps; Fri, 27 Oct 2006 13:01:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdV54-0006gL-C6 for emu@ietf.org; Fri, 27 Oct 2006 13:01:18 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdV51-0005Ja-2I for emu@ietf.org; Fri, 27 Oct 2006 13:01:18 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 27 Oct 2006 10:01:14 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9RH1EnB010779 for ; Fri, 27 Oct 2006 10:01:14 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9RH1COp014356 for ; Fri, 27 Oct 2006 10:01:14 -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); Fri, 27 Oct 2006 10:00:56 -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: Fri, 27 Oct 2006 10:00:54 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Password based mechanism Design team Thread-Index: Acb56Xa+hCD3nPz3S5+fqaWLV9hzrg== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 27 Oct 2006 17:00:56.0401 (UTC) FILETIME=[78158410:01C6F9E9] DKIM-Signature: a=rsa-sha1; q=dns; l=367; t=1161968474; x=1162832474; 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:Password=20based=20mechanism=20Design=20team; X=v=3Dcisco.com=3B=20h=3D+wVhy9wpl5jvIfdfN7mrCQBCmnc=3D; b=TKuq1a3rj6RHYHsRLTsLcFHcwzB7zdPU33jO/DnhflgA9PUyzrZP/v7/W7CWvJNQxEE/gqWE OJBSJ/3OLxf1FBrjqmZ5Cvhfm/DC6Zfk0Z+yGumS050/lbboPh4kEdMI; 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: d17f825e43c9aed4fd65b7edddddec89 Subject: [Emu] Password based mechanism Design team 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 Please send me a message if you are interested in participating on a design team for the following EMU working group charter item: - A mechanism meeting RFC 3748 and RFC 4017 requirements that makes use of existing password databases such as AAA databases. The implementation should strive to be usable in resource constrained environments. Thanks, Joe _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Oct 27 16:21:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdYCR-0005Dw-84; Fri, 27 Oct 2006 16:21:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdYCQ-0005CW-D1 for emu@ietf.org; Fri, 27 Oct 2006 16:21:06 -0400 Received: from mailfe04.tele2.fr ([212.247.154.108] helo=swip.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdYCL-0000m0-2V for emu@ietf.org; Fri, 27 Oct 2006 16:21:06 -0400 X-T2-Posting-ID: TlrHmwDFCX01iQZd0Fm6v3T8FBlCqve5GwI1mWaefYU= X-Cloudmark-Score: 0.000000 [] Received: from [80.170.201.241] (HELO VAIO.tele2.fr) by mailfe04.swip.net (CommuniGate Pro SMTP 5.0.8) with ESMTP id 310061469; Fri, 27 Oct 2006 22:20:41 +0200 Message-Id: <7.0.0.16.0.20061027221827.02365320@tele2.fr> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 27 Oct 2006 22:20:34 +0200 To: "Joseph Salowey \(jsalowey\)" , From: Pascal Urien Subject: Re: [Emu] Password based mechanism Design team In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 I am interested in participating Pascal At 19:00 27/10/2006, Joseph Salowey \(jsalowey\) wrote: >Please send me a message if you are interested in participating on a >design team for the following EMU working group charter item: > >- A mechanism meeting RFC 3748 and RFC 4017 requirements that makes use >of existing password databases such as AAA databases. The implementation >should strive to be usable in resource constrained >environments. > >Thanks, > >Joe > >_______________________________________________ >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 Sat Oct 28 12:29:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdr40-0001U5-Hf; Sat, 28 Oct 2006 12:29:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdr3y-0001Oo-Ml for emu@ietf.org; Sat, 28 Oct 2006 12:29:38 -0400 Received: from mail2.genealogia.fi ([194.100.116.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdr3x-0005IQ-51 for emu@ietf.org; Sat, 28 Oct 2006 12:29:38 -0400 Received: from dsl017-049-110.sfo4.dsl.speakeasy.net ([69.17.49.110] helo=jm) by mail2.genealogia.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1Gdr3n-0000PC-6s; Sat, 28 Oct 2006 19:29:29 +0300 Received: by jm (sSMTP sendmail emulation); Sat, 28 Oct 2006 09:27:59 -0700 Date: Sat, 28 Oct 2006 09:27:59 -0700 From: Jouni Malinen To: Charles Clancy Subject: Re: [Emu] I-D ACTION:draft-ietf-emu-eap-gpsk-00.txt Message-ID: <20061028162759.GB6150@jm.kir.nu> References: <20061021174326.GF6103@jm.kir.nu> <51725.63.239.69.1.1161885898.squirrel@webmail.cs.umd.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51725.63.239.69.1.1161885898.squirrel@webmail.cs.umd.edu> User-Agent: Mutt/1.5.11 X-Spam-Score: -2.6 (--) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 On Thu, Oct 26, 2006 at 02:04:58PM -0400, Charles Clancy wrote: > Actually, the descriptions in chapter 6 are incorrect, and need be fixed > to reflect the changes in chapter 4. OK. > The KDF in chapter 4 was changed to allow PSKs of variable length and > entropy. Using the PSK to directly key the KDF to generate the MK has > problems because most KDFs have fixed-length inputs for keys. Imagine > someone who uses a 50-character passphrase (English text has around 2.5 > bits of entropy per character, so that's roughly a 128-bit secure key). > If we follow what's currently in chapter 6, we truncate that to 16 bytes, > which would only be 40 bits of security. Not a good thing. Only with Ciphersuite 1.. Ciphersuite 2, i.e., HMAC-SHA256, should be able to handle arbitrary length keys. Does the following change match with your understanding? In 6.1.3, replace MK = GKDF-16 (PSK[0..15], RAND_Client || ID_Client || RAND_Server || ID_Server) with MK = GKDF-16 (Zero-String, PL || PSK || CSuite_Sel || RAND_Client || ID_Client || RAND_Server || ID_Server) (I did not find definition for how PL is to be represented here. Is it enough to limit to PSKs of up to 255 octets and define PL to be one octet?) In 6.2.3, replace MK = GKDF-32 (PSK, RAND_Client || ID_Client || RAND_Server || ID_Server) with MK = GKDF-32 (Zero-String, PL || PSK || CSuite_Sel || RAND_Client || ID_Client || RAND_Server || ID_Server) (Same comment about PL) As an alternative, this could be MK = GKDF-32 (PSK, CSuite_Sel || RAND_Client || ID_Client || RAND_Server || ID_Server) since HMAC-SHA256 should have no problems with variable length PSK. By the way, is the definition of Zero-String (KS octets of 0x00) really suitable for Ciphersuite 2? Why bother generating a sequence of 32 octets of 0x00 for HMAC-SHA256 key (which could as well be zero-length). -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu