From emu-bounces@ietf.org Mon Mar 05 12:01:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOGZ9-0003Jk-Kg; Mon, 05 Mar 2007 12:01:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOGZ5-00038e-7M for emu@ietf.org; Mon, 05 Mar 2007 12:01:35 -0500 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 1HOGYD-0002Tw-S5 for emu@ietf.org; Mon, 05 Mar 2007 12:00:44 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 05 Mar 2007 09:00:41 -0800 X-IronPort-AV: i="4.14,251,1170662400"; d="scan'208"; a="468462484:sNHT248700904" 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/8.12.11) with ESMTP id l25H0elF020822 for ; Mon, 5 Mar 2007 09:00:40 -0800 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 l25GxsYm005050 for ; Mon, 5 Mar 2007 17:00:33 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 08:59:53 -0800 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, 5 Mar 2007 08:59:52 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda for EMU at IETF 68 Thread-Index: AcdfR7FezkfxUMuCQb2UW9BkTVmpDQ== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 05 Mar 2007 16:59:53.0834 (UTC) FILETIME=[B2144CA0:01C75F47] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1054; t=1173114040; x=1173978040; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20Agenda=20for=20EMU=20at=20IETF=2068 |Sender:=20; bh=MU3y9ozj/VBmSgfTDSLFwCZ+N6p5gbBaZKs+x2ewBhM=; b=vXaIGPkqMIYEBBkKRz5FGPCYJUeYe6BIDi6Wt1cc0VtCUDuwJ94C1Ip/PyeLDSp6kWiLHtqB qkC+T/+Td2BrVEmeibmC/3x3q+DK4YfZpyU6Uc9IH9Wm8W+2lCfAmntP; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Emu] Agenda for EMU at IETF 68 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 let me know if you have any additions or corrections: PRELIMINARIES (10 minutes) Blue sheets Minute takers Agenda bash Document Status ITEMS IN EMU WG LAST CALL (40 minutes) Topic: RFC2716bis - EAP-TLS Presenter: TBD (Bernard Aboba) Time: 20 minutes URL: http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-08.txt Topic: EAP-GPSK Presenter: TBD (Hannes Tschofenig, Charles Clancy) Time: 20 minutes URL: http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-03.txt PASSWORD BASED METHOD (50 min) Topic: Password Based Method Requirements Presenter: TBD (password based design team) Time: 20 minutes URL: TBD(Summary mail to be sent to list) Topic: Password based method approach discussion Presenter: TBD (password based design team) Time: 30 URL: TBD(Summary mail to be sent to list) ADDITIONAL TOPICS (10 min) Topic: An EAP Method for EAP Extension (EAP-EXT) Presenter: Yoshihiro Obha=20 Time: 10 Min URL: http://www.ietf.org/internet-drafts/draft-ohba-hokey-emu-eap-ext-00.txt _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Mar 05 21:04:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOP2H-0001Wt-0c; Mon, 05 Mar 2007 21:04:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOP2F-0001Nw-6S for emu@ietf.org; Mon, 05 Mar 2007 21:04:15 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOP2D-0000Zj-Q0 for emu@ietf.org; Mon, 05 Mar 2007 21:04:15 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l2624Cgc013454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 5 Mar 2007 18:04:12 -0800 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l2624AiG022146 for ; Mon, 5 Mar 2007 18:04:12 -0800 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 18:03:16 -0800 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, 5 Mar 2007 18:03:18 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC: Review of draft-ietf-emu-eap-gpsk-03 Thread-Index: Acdfk5vHaTVjvLZQTgaRB8Vl7DrXTQ== From: "Narayanan, Vidya" To: X-OriginalArrivalTime: 06 Mar 2007 02:03:16.0841 (UTC) FILETIME=[9AFC5D90:01C75F93] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [Emu] WGLC: Review of draft-ietf-emu-eap-gpsk-03 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 All, I reviewed the document and unfortunately, don't feel it is ready for publication yet. I will only get into the meta issues here - nits can be addressed later.=20 Major Comments:=20 --------------- 1. Overall, I'm looking for a compelling reason to have another EAP method and I found none in the document. For instance, all the design goals listed seem to be satisfied by EAP-TLS-PSK (inclusion of protected payloads can be done as an extension to TLS as well). And, given that EAP-TLS-PSK is an incremental change to EAP-TLS, it would be much more compelling to use EAP-TLS-PSK than EAP-GPSK. So, is there at least one design goal of GPSK that cannot be met by other methods?=20 2. Are the EAP and GPSK headers integrity protected? The SEC_SK construction in various places does not seem to imply so - I don't think that is the intention, as those headers must be integrity protected.=20 3. The message, GPSK-4, seems to be there since an EAP Response is needed after an EAP Request. However, this seems to lead to a couple of things - a) a potentially empty message sent with a MAC (what is the MAC calculated on?), b) having the client to reflect back a failure message in the event of a failure. I think if the EAP and GPSK headers are protected with a MAC, we should be okay with this.=20 4. Is there a reference to GKDF? I'm wondering why we are advocating the use of hash functions as KDFs instead of HMACs. I have more questions on the derivation of MK and other keys, but, I'll wait for the clarification on GKDF before I ask those.=20 5. Is the PK always derived? Having a PK for the case where the encryption algorithm is NULL (in Ciphersuite 2, for instance), doesn't seem to be of any value. This actually brings up a question on the need to define the KDFs the way this document has. For instance, the 2*KS value seems to be there to determine the KDF length, with the assumption that the encryption and integrity key lengths required for the ciphersuites are equal. A better construction seems to be along the lines of IKEv2's prf+, that can produce keys of variable lengths. Was this considered and if so, why was the GKDF construction as defined seen as a better way to go?=20 Not-so-major Comments: 6. The document seems to re-naming some EAP terminology. I don't think there is a need to do that.=20 7. Section 8 says "Any packet that cannot be parsed by the EAP client or the EAP server MUST be silently discarded" - this seems to be defining EAP behavior. In other words, if the packet cannot even be parsed as a GPSK packet, EAP will be discarding that packet, not GPSK.=20 Thanks, Vidya _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Mar 05 21:17:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOPEg-0006JX-PZ; Mon, 05 Mar 2007 21:17:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOPEe-0006JS-Ua for emu@ietf.org; Mon, 05 Mar 2007 21:17:04 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOPEd-0001hF-GD for emu@ietf.org; Mon, 05 Mar 2007 21:17:04 -0500 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l262H2VO015189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Mar 2007 18:17:02 -0800 Received: from [10.50.69.72] (qconnect-10-50-69-72.qualcomm.com [10.50.69.72]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l262H1MA011107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Mar 2007 18:17:01 -0800 (PST) Message-ID: <45ECCED3.5080501@qualcomm.com> Date: Mon, 05 Mar 2007 18:15:47 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: emu@ietf.org Subject: Re: [Emu] WG Last Call: draft-ietf-emu-eap-gpsk-03.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Review summary: Thanks to Charles and Hannes for their hard work on this draft, but I think it needs another revision before going to AD Review and IETF LC. I have been part of the design team, and so I am responsible for some of the following issues being still pending at this stage. I may have also brought up some of these issues in the past and the consensus determined the current contents; if so, please refresh my memory :). Thanks. 1. The definition of KS is inconsistent. Figure 3 shows that SHA-1 is the hash function and the key size is 16. The definition in Section 2 says that KS is the key size of the selected cipher suite. Well that is not precise enough as it turns with the 128-bit key cipher and 160-bit key hash function being used. 2. Nit: There may be 1 or more occurrences of the word PD_Payload_Blocks; my understanding is that there is only one block and there could be 1 or more PD_Payloads. 3. Nits: The relative order of definitions of PK, SK and MK might be changed so there is no forward referencing. I recall complaining that the names PK and SK are not intuitive. Same goes for SEC_X(Y) by the way. I also realized I don't quite like us renaming the EAP peer as the "client." 4. Borderline Nit: The description of the messages at the beginning of Page 9 can be tighter. Some examples: * The MAC computation needs to be more clearly specified. The current text says the MAC is over all "these" parameters and "session parameter". We need a more precise specification. The MAC serves two purposes, the first is a PoP of the PSK or a derived key thereof and integrity protection over the message contents. For the PoP we need a certain MAC coverage and for integrity protection a larger coverage. A related question is whether the EAP header needs integrity protection? Otherwise, what happens if an adversary modifies the message ID (OP Code). Perhaps all that is plausible is a DoS attack. However, since we have specific error codes, we might take advantage and be more precise about the error (I am of course not happy that we are declaring that "Authentication failed" indirectly signaling MAC failure :) ). 5. GPSK-4 is needed only as a filler for EAP request/response pairing, right? Perhaps we should state that clearly. 6. At the end of Section 3, we have "Upon receipt of GPSK-4, the server assures that the peer has derived session keys." I guess the server assures "itself." :) More importantly though, doesn't the server know that about the peer upon request of GPSK-2. 7. (Page 10) Why is MK's KDF using 0 as the key? Why not use the PSK? I do see that the MK is used as input in other KDFs and so there might not be a problem. Thoughts? 8. (Page 12) s/SHA-1/HMAC-SHA-1; s/SHA256/HMAC-SHA-256 Also I like the GKDF specification that Charles had in one of the earlier inputs to this process. As it is, we need to make at least one modification: s/ Hash-Function(i||Y||Z)/KDF_Y(i||Z)/ or KDF_Y(M_{i-1}||i||Z) (I think this is what Charles specified earlier). 9. s/MAC-based ciphersuite/hash-based ciphersuite s/MAC output size/hash output size 10. In Section 6.1.1, I strongly suggest that we should AES-CTR and not AES-CBC. I can make a case in a separate email if necessary, but with AES-CTR it is plausible that a host can get away with not implementing the AES cipher's reverse operation and we should allow that possibility. 11. Section 7.3. Instead of length(CSuite_List), could we not use NumberOf_CSuites and reduce the field size to 1 octet? Clearly there are a few nits and things that we could live with; however there are some issues that need to be addressed now. Some of them are for clarity and correctness of the spec and others are to address security issues (8 above and 7 too). 10 is an issue I request the group to consider. thanks, Lakshminath Joseph Salowey (jsalowey) wrote: > This is a working group last call for draft-ietf-emu-eap-gpsk-03. > > Send your comments to the EMU list by March 7, 2007. Please respond to > this call even if you have reviewed the draft and found no problems. > > The document can be accessed here: > http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-03.txt > > _______________________________________________ > 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 Mar 05 22:58:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOQok-0003HU-Gt; Mon, 05 Mar 2007 22:58:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOQoj-0003HP-Lh for emu@ietf.org; Mon, 05 Mar 2007 22:58:25 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOQoi-0005cN-BT for emu@ietf.org; Mon, 05 Mar 2007 22:58:25 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l263wNfY006447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 5 Mar 2007 19:58:23 -0800 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l263wMjF007058 for ; Mon, 5 Mar 2007 19:58:23 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 19:58:22 -0800 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, 5 Mar 2007 19:58:22 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC4279 support in draft-simon-emu-rfc2716bis? Thread-Index: Acdfo67ZPntb3gKrTrOhNCxCUXJKdw== From: "Narayanan, Vidya" To: X-OriginalArrivalTime: 06 Mar 2007 03:58:22.0652 (UTC) FILETIME=[AF2B7FC0:01C75FA3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis? 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 All, I have a question on support for the TLS PSK ciphersuites in EAP-TLS. Looking at the message flow in section 2.1.1, I don't see any reason why the TLS PSK ciphersuites, as specified in RFC4279, cannot be used with it, but, the optional TLS elements are not immediately clear from it and hence, the question.=20 Thanks, Vidya _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Mar 06 02:29:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOU6T-0001Px-VQ; Tue, 06 Mar 2007 02:28:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOU6S-0001Pp-Bg for emu@ietf.org; Tue, 06 Mar 2007 02:28:56 -0500 Received: from bay0-omc1-s10.bay0.hotmail.com ([65.54.246.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOU6R-0006QP-2k for emu@ietf.org; Tue, 06 Mar 2007 02:28:56 -0500 Received: from hotmail.com ([207.46.8.116]) by bay0-omc1-s10.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 5 Mar 2007 23:28:54 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 5 Mar 2007 23:28:54 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Tue, 06 Mar 2007 07:28:52 GMT X-Originating-IP: [24.16.66.58] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: vidyan@qualcomm.com, emu@ietf.org Bcc: Subject: RE: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis? Date: Mon, 05 Mar 2007 23:28:52 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 06 Mar 2007 07:28:54.0572 (UTC) FILETIME=[186186C0:01C75FC1] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 According to RFC 2716, a compliant EAP-TLS implementation must support certificates. Since the resources required to support certificates is much larger than the resources required for TLS-PSK, a combined method would not be optimal for use within an embedded environment. There would also be substantial costs to adding support for additional authentication methods to EAP-TLS. For example, EAP-TLS certification and testing programs have been developed which focus solely on certificate ciphersuites; rewriting those test suites would be costly. By developing EAP-TLS-PSK as a separate EAP method an implementation can solely implement TLS-PSK while remaining compliant. This permits EAP TLS-PSK implementations to be optimized for embedded environments. As a side benefit, this approach also eliminates multiple levels of negotiation, which had been raised as a potential problem. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Mar 06 14:51:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOfh2-0007xo-IK; Tue, 06 Mar 2007 14:51:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOfh1-0007r7-B5 for emu@ietf.org; Tue, 06 Mar 2007 14:51:27 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOfgy-0000CU-V0 for emu@ietf.org; Tue, 06 Mar 2007 14:51:27 -0500 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 l26JpNMI022811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 6 Mar 2007 11:51:23 -0800 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l26JpHdC026374; Tue, 6 Mar 2007 11:51:22 -0800 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 11:51:09 -0800 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] RFC4279 support in draft-simon-emu-rfc2716bis? Date: Tue, 6 Mar 2007 11:51:05 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis? Thread-Index: AcdfwTgm8NcDCsOxRYOHV8R1FGtqLQAZculw References: From: "Narayanan, Vidya" To: "Bernard Aboba" , X-OriginalArrivalTime: 06 Mar 2007 19:51:09.0120 (UTC) FILETIME=[C90A4400:01C76028] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Bernard, Thanks much for the response. If we go down this path, are we then saying that for every new ciphersuite that may be added to TLS, a separate EAP method would need to be designed to support that in EAP? Also, how is this different from TLS implementations having to support the newer ciphersuites?=20 I can understand the mandatory cert requirement in RFC2716, since at that point of time, TLS did not have the PSK ciphersuites. But, now that we are revising it, does it not make sense to support all the ciphersuites supported in TLS?=20 Also, could you please elaborate on the multiple negotiation problem? Looking at the message flows in section 2.1 in draft-otto-emu-eap-tls-psk-02 and section 2.1.1 in draft-simon-emu-rfc2716bis-08, except for the certs portion, everything else looks the same.=20 Thanks, Vidya > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Monday, March 05, 2007 11:29 PM > To: Narayanan, Vidya; emu@ietf.org > Subject: RE: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis? >=20 > According to RFC 2716, a compliant EAP-TLS implementation=20 > must support certificates. Since the resources required to=20 > support certificates is much larger than the resources=20 > required for TLS-PSK, a combined method would not be optimal=20 > for use within an embedded environment. There would also be=20 > substantial costs to adding support for additional=20 > authentication methods to EAP-TLS. For example, EAP-TLS=20 > certification and testing programs have been developed which=20 > focus solely on certificate ciphersuites; rewriting those=20 > test suites would be costly. >=20 > By developing EAP-TLS-PSK as a separate EAP method an=20 > implementation can solely implement TLS-PSK while remaining=20 > compliant. This permits EAP TLS-PSK implementations to be=20 > optimized for embedded environments. As a side benefit, this=20 > approach also eliminates multiple levels of negotiation,=20 > which had been raised as a potential problem. >=20 >=20 >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Mar 06 15:19:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOg7e-0002Q5-4e; Tue, 06 Mar 2007 15:18:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOg7c-0002Pl-W4 for emu@ietf.org; Tue, 06 Mar 2007 15:18:56 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOg7W-0005ND-V3 for emu@ietf.org; Tue, 06 Mar 2007 15:18:56 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 06 Mar 2007 12:18:51 -0800 X-IronPort-AV: i="4.14,255,1170662400"; d="scan'208"; a="397717076:sNHT74469286" 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/8.12.11) with ESMTP id l26KIo9Y001748; Tue, 6 Mar 2007 12:18:50 -0800 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 l26KIie1004981; Tue, 6 Mar 2007 20:18:50 GMT 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.1830); Tue, 6 Mar 2007 12:18:46 -0800 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] RFC4279 support in draft-simon-emu-rfc2716bis? Date: Tue, 6 Mar 2007 12:18:44 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis? Thread-Index: AcdfwTgm8NcDCsOxRYOHV8R1FGtqLQAZculwAAC5nsA= From: "Joseph Salowey \(jsalowey\)" To: "Narayanan, Vidya" , "Bernard Aboba" , X-OriginalArrivalTime: 06 Mar 2007 20:18:46.0040 (UTC) FILETIME=[A4A43180:01C7602C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3264; t=1173212330; x=1174076330; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20RFC4279=20support=20in=20draft-simon-emu-rfc2 716bis? |Sender:=20; bh=coBfCP6+ibK07/X2ofyb448ZFePseL/rn89uWYeSoKE=; b=MOaIiq7TGVImCfNcu2xNAQh+rs4o82Qi9JHzWkZfMuKsjUhTGOe/62w3XxDr0GVzSrwJ5mGU 7V5TqsRXVBczS7U0b2Ew0FnwgG4i/RVk6gBV84MazMxPXouZ3u1AJT3D; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Sent: Tuesday, March 06, 2007 11:51 AM > To: Bernard Aboba; emu@ietf.org > Subject: RE: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis? >=20 > Hi Bernard, > Thanks much for the response. If we go down this path, are we=20 > then saying that for every new ciphersuite that may be added=20 > to TLS, a separate EAP method would need to be designed to=20 > support that in EAP? > Also, how is this different from TLS implementations having=20 > to support the newer ciphersuites?=20 >=20 [Joe] We have a charter item for enhanced TLS which could support other types of ciphersuites along with other features.=20 > I can understand the mandatory cert requirement in RFC2716,=20 > since at that point of time, TLS did not have the PSK=20 > ciphersuites. But, now that we are revising it, does it not=20 > make sense to support all the ciphersuites supported in TLS?=20 >=20 > Also, could you please elaborate on the multiple negotiation problem? > Looking at the message flows in section 2.1 in > draft-otto-emu-eap-tls-psk-02 and section 2.1.1 in=20 > draft-simon-emu-rfc2716bis-08, except for the certs portion,=20 > everything else looks the same.=20 >=20 [Joe] EAP negotiation happens early before TLS negotiation. If a peer or server negotiate a particular EAP method they may actually not actually be able to complete this because TLS negotiation arrives upon an result that is not satisfactory. Restricting EAP-TLS to certificate based ciphers does not solve this problem, but it helps. In an enhanced EAP-TLS the initial message from the server could indicate the supported ciphers giving the chance for a client to NAK.=20 > Thanks, > Vidya >=20 > > -----Original Message----- > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > Sent: Monday, March 05, 2007 11:29 PM > > To: Narayanan, Vidya; emu@ietf.org > > Subject: RE: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis? > >=20 > > According to RFC 2716, a compliant EAP-TLS implementation=20 > must support=20 > > certificates. Since the resources required to support=20 > certificates is=20 > > much larger than the resources required for TLS-PSK, a=20 > combined method=20 > > would not be optimal for use within an embedded environment. There=20 > > would also be substantial costs to adding support for additional=20 > > authentication methods to EAP-TLS. For example, EAP-TLS=20 > certification=20 > > and testing programs have been developed which focus solely on=20 > > certificate ciphersuites; rewriting those test suites would=20 > be costly. > >=20 > > By developing EAP-TLS-PSK as a separate EAP method an=20 > implementation=20 > > can solely implement TLS-PSK while remaining compliant. =20 > This permits=20 > > EAP TLS-PSK implementations to be optimized for embedded=20 > environments. =20 > > As a side benefit, this approach also eliminates multiple levels of=20 > > negotiation, which had been raised as a potential problem. > >=20 > >=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 Wed Mar 07 05:45:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOteS-00012L-0X; Wed, 07 Mar 2007 05:45:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOteQ-0000vt-48 for emu@ietf.org; Wed, 07 Mar 2007 05:45:42 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HOteO-00052J-MT for emu@ietf.org; Wed, 07 Mar 2007 05:45:42 -0500 Received: (qmail invoked by alias); 07 Mar 2007 10:45:39 -0000 Received: from p54986A0E.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.106.14] by mail.gmx.net (mp053) with SMTP; 07 Mar 2007 11:45:39 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX187Tr4QDnQ78hoK8Fhe/FjAuQYlJ7REbFpUG+WDPp WJfO1PbQaPxCId Message-ID: <45EE97DD.7070802@gmx.net> Date: Wed, 07 Mar 2007 12:45:49 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis? 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: 9182cfff02fae4f1b6e9349e01d62f32 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 discussed this already several times and this lead me to work on a draft together with Thomas Otto: http://tools.ietf.org/id/draft-otto-emu-eap-tls-psk-02.txt Ciao Hannes Narayanan, Vidya wrote: > All, > I have a question on support for the TLS PSK ciphersuites in EAP-TLS. > Looking at the message flow in section 2.1.1, I don't see any reason why > the TLS PSK ciphersuites, as specified in RFC4279, cannot be used with > it, but, the optional TLS elements are not immediately clear from it and > hence, the question. > > Thanks, > Vidya > > _______________________________________________ > 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 Mar 07 05:56:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOtov-0000DL-Ov; Wed, 07 Mar 2007 05:56:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOtov-0000DG-7Y for emu@ietf.org; Wed, 07 Mar 2007 05:56:33 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HOtot-0000Ic-Om for emu@ietf.org; Wed, 07 Mar 2007 05:56:33 -0500 Received: (qmail invoked by alias); 07 Mar 2007 10:56:30 -0000 Received: from p54986A0E.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.106.14] by mail.gmx.net (mp017) with SMTP; 07 Mar 2007 11:56:30 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/6RUxFVVT6sXNVcNt7pNQrS/Z4hL4GsFTyDNQddY iEsu8b9TiEdCjX Message-ID: <45EE9A69.20808@gmx.net> Date: Wed, 07 Mar 2007 12:56:41 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [Emu] WGLC: Review of draft-ietf-emu-eap-gpsk-03 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: 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 Vidya, just a quick comment. Narayanan, Vidya wrote: > All, > I reviewed the document and unfortunately, don't feel it is ready for > publication yet. I will only get into the meta issues here - nits can be > addressed later. > > Major Comments: > --------------- > 1. Overall, I'm looking for a compelling reason to have another EAP > method and I found none in the document. For instance, all the design > goals listed seem to be satisfied by EAP-TLS-PSK (inclusion of protected > payloads can be done as an extension to TLS as well). And, given that > EAP-TLS-PSK is an incremental change to EAP-TLS, it would be much more > compelling to use EAP-TLS-PSK than EAP-GPSK. So, is there at least one > design goal of GPSK that cannot be met by other methods? > > You must be kidding. We worked on this several months within a design team. The design team concluded that a new EAP method is the right direction. Then, the result of the design team was confirmed by working group a long time ago. Now, in WGLC you raise your voice although you and Lakshminath actively participate in the working group (with Lakshminath even being a design team member). I will address your comments after I recovered from a flu. Ciao Hannes > 2. Are the EAP and GPSK headers integrity protected? The SEC_SK > construction in various places does not seem to imply so - I don't think > that is the intention, as those headers must be integrity protected. > > 3. The message, GPSK-4, seems to be there since an EAP Response is > needed after an EAP Request. However, this seems to lead to a couple of > things - a) a potentially empty message sent with a MAC (what is the MAC > calculated on?), b) having the client to reflect back a failure message > in the event of a failure. I think if the EAP and GPSK headers are > protected with a MAC, we should be okay with this. > > 4. Is there a reference to GKDF? I'm wondering why we are advocating the > use of hash functions as KDFs instead of HMACs. I have more questions on > the derivation of MK and other keys, but, I'll wait for the > clarification on GKDF before I ask those. > > 5. Is the PK always derived? Having a PK for the case where the > encryption algorithm is NULL (in Ciphersuite 2, for instance), doesn't > seem to be of any value. This actually brings up a question on the need > to define the KDFs the way this document has. For instance, the 2*KS > value seems to be there to determine the KDF length, with the assumption > that the encryption and integrity key lengths required for the > ciphersuites are equal. A better construction seems to be along the > lines of IKEv2's prf+, that can produce keys of variable lengths. Was > this considered and if so, why was the GKDF construction as defined seen > as a better way to go? > > Not-so-major Comments: > > 6. The document seems to re-naming some EAP terminology. I don't think > there is a need to do that. > > 7. Section 8 says "Any packet that cannot be parsed by the EAP client or > the EAP server MUST be silently discarded" - this seems to be defining > EAP behavior. In other words, if the packet cannot even be parsed as a > GPSK packet, EAP will be discarding that packet, not GPSK. > > Thanks, > Vidya > > _______________________________________________ > 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 Mar 07 11:12:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOykm-0002wV-9s; Wed, 07 Mar 2007 11:12:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOykj-0002pk-V2 for emu@ietf.org; Wed, 07 Mar 2007 11:12:34 -0500 Received: from bay0-omc1-s28.bay0.hotmail.com ([65.54.246.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HOykd-0006OT-4c for emu@ietf.org; Wed, 07 Mar 2007 11:12:33 -0500 Received: from hotmail.com ([207.46.8.97]) by bay0-omc1-s28.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 7 Mar 2007 08:12:26 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 7 Mar 2007 08:12:26 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Wed, 07 Mar 2007 16:12:21 GMT X-Originating-IP: [24.16.66.58] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <45EE97DD.7070802@gmx.net> From: "Bernard Aboba" To: Hannes.Tschofenig@gmx.net, vidyan@qualcomm.com Bcc: Subject: Re: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis? Date: Wed, 07 Mar 2007 08:12:21 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 07 Mar 2007 16:12:26.0314 (UTC) FILETIME=[65A6BAA0:01C760D3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Hannes Tschofenig said: >We discussed this already several times and this lead me to work on a draft >together with Thomas Otto: > >http://tools.ietf.org/id/draft-otto-emu-eap-tls-psk-02.txt Which begs the question: what is the WG doing with this draft? >From where I sit, it seems quite likely that EAP-TLS-PSK, if completed, will be deployed. When TLS 1.2 is done, this method could eventually benefit from KDF negotiation, and should meet the criteria for FIPS 140-2 certification. Given the TLS code base in embedded systems, it should not be hard to add support for EAP-TLS-PSK within embedded devices. I my doubts about EAP-GPSK on several of these dimensions. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Mar 07 11:45:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOzGf-0004gJ-Bu; Wed, 07 Mar 2007 11:45:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOzGe-0004gD-LL for emu@ietf.org; Wed, 07 Mar 2007 11:45:32 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOzGc-00074E-5H for emu@ietf.org; Wed, 07 Mar 2007 11:45:32 -0500 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 l27GjQ3a031401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 7 Mar 2007 08:45:26 -0800 Received: from [10.50.76.156] (qconnect-10-50-76-156.qualcomm.com [10.50.76.156]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l27GjKMB027519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Mar 2007 08:45:23 -0800 Message-ID: <45EEEBD6.2020508@qualcomm.com> Date: Wed, 07 Mar 2007 08:44:06 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Emu] WGLC: Review of draft-ietf-emu-eap-gpsk-03 References: <45EE9A69.20808@gmx.net> In-Reply-To: <45EE9A69.20808@gmx.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit 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 Hannes, I hope you recover quickly from the flu. Please see inline for some notes: Hannes Tschofenig wrote: > Hi Vidya, > > just a quick comment. > > Narayanan, Vidya wrote: >> All, >> I reviewed the document and unfortunately, don't feel it is ready for >> publication yet. I will only get into the meta issues here - nits can be >> addressed later. >> Major Comments: --------------- >> 1. Overall, I'm looking for a compelling reason to have another EAP >> method and I found none in the document. For instance, all the design >> goals listed seem to be satisfied by EAP-TLS-PSK (inclusion of protected >> payloads can be done as an extension to TLS as well). And, given that >> EAP-TLS-PSK is an incremental change to EAP-TLS, it would be much more >> compelling to use EAP-TLS-PSK than EAP-GPSK. So, is there at least one >> design goal of GPSK that cannot be met by other methods? >> > > You must be kidding. Why do you think that? While we don't (need to) do this often, there is nothing wrong in asking ourselves why a certain protocol is needed or not before we forward it out of the WG. In the MSEC WG (several years ago), we considered the question of why we need to publish yet another group key management protocol, a few times. When MIKEY was sent to the IESG, there was the question of why we need one more DH-based key management protocol. It doesn't hurt to ask ourselves that question. > > We worked on this several months within a design team. The design team > concluded that a new EAP method is the right direction. Then, the result > of the design team was confirmed by working group a long time ago. > > Now, in WGLC you raise your voice although you and Lakshminath actively > participate in the working group (with Lakshminath even being a design > team member). Let's see: I haven't (yet) said anything about not forwarding this to the AD. I sent in my comments and others might explain why one or more of them are invalid. That's where it stands. I did consider the question that Vidya poses as to why we need GPSK and why can't we use EAP-TLS-PSK instead. I disagree with her opinion at the moment: assuming all else goes well with GPSK, I am ok with publishing it. I am not sure about recommending it to anyone (other SDOs for e.g.) just yet. There is a question in the back of my mind as to if/when EAP-TLS-PSK is specified and if/when a TLS extension to carry "additional data" is specified, why would anyone use GPSK and not EAP-TLS-PSK. In the meanwhile, if Vidya or anyone else raises the question on why are we doing this, we have a responsibility to answer. My answer is EAP-TLS-PSK is not there yet and there is no way to carry "additional data" in EAP-TLS-* yet. regards, Lakshminath > > I will address your comments after I recovered from a flu. > > Ciao > Hannes > > >> 2. Are the EAP and GPSK headers integrity protected? The SEC_SK >> construction in various places does not seem to imply so - I don't think >> that is the intention, as those headers must be integrity protected. >> 3. The message, GPSK-4, seems to be there since an EAP Response is >> needed after an EAP Request. However, this seems to lead to a couple of >> things - a) a potentially empty message sent with a MAC (what is the MAC >> calculated on?), b) having the client to reflect back a failure message >> in the event of a failure. I think if the EAP and GPSK headers are >> protected with a MAC, we should be okay with this. >> 4. Is there a reference to GKDF? I'm wondering why we are advocating the >> use of hash functions as KDFs instead of HMACs. I have more questions on >> the derivation of MK and other keys, but, I'll wait for the >> clarification on GKDF before I ask those. >> 5. Is the PK always derived? Having a PK for the case where the >> encryption algorithm is NULL (in Ciphersuite 2, for instance), doesn't >> seem to be of any value. This actually brings up a question on the need >> to define the KDFs the way this document has. For instance, the 2*KS >> value seems to be there to determine the KDF length, with the assumption >> that the encryption and integrity key lengths required for the >> ciphersuites are equal. A better construction seems to be along the >> lines of IKEv2's prf+, that can produce keys of variable lengths. Was >> this considered and if so, why was the GKDF construction as defined seen >> as a better way to go? >> Not-so-major Comments: >> >> 6. The document seems to re-naming some EAP terminology. I don't think >> there is a need to do that. >> 7. Section 8 says "Any packet that cannot be parsed by the EAP client or >> the EAP server MUST be silently discarded" - this seems to be defining >> EAP behavior. In other words, if the packet cannot even be parsed as a >> GPSK packet, EAP will be discarding that packet, not GPSK. >> Thanks, >> Vidya >> >> _______________________________________________ >> 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 Mar 07 20:00:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP6zS-0006YR-UK; Wed, 07 Mar 2007 20:00:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP53n-0006Sn-IP for emu@ietf.org; Wed, 07 Mar 2007 17:56:39 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP3gw-0006gI-PY for emu@ietf.org; Wed, 07 Mar 2007 16:29:00 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l27LSsqd014867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 7 Mar 2007 13:28:54 -0800 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l27LSqbf027761; Wed, 7 Mar 2007 13:28:53 -0800 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 13:28:23 -0800 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] RFC4279 support in draft-simon-emu-rfc2716bis? Date: Wed, 7 Mar 2007 13:28:28 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis? Thread-Index: AcdfwTgm8NcDCsOxRYOHV8R1FGtqLQAZculwAAC5nsAANTMLsA== References: From: "Narayanan, Vidya" To: "Joseph Salowey \(jsalowey\)" , "Bernard Aboba" , X-OriginalArrivalTime: 07 Mar 2007 21:28:23.0051 (UTC) FILETIME=[88BF3DB0:01C760FF] 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 Hi Joe,=20 Let me separate this into different topics for clarity. =20 >=20 > [Joe] EAP negotiation happens early before TLS negotiation. If a peer > or server negotiate a particular EAP method they may actually not=20 > actually be able to complete this because TLS negotiation arrives upon > an result that is not satisfactory. Restricting EAP-TLS to certificate > based ciphers does not solve this problem, but it helps. In an=20 > enhanced EAP-TLS the initial message from the server could indicate=20 > the supported ciphers giving the chance for a client to NAK. >=20 >=20 1. TLS negotiations in EAP:=20 --------------------------- I guess in a way, this is trying to perform some rudimentary TLS ciphersuite negotiation at the EAP level. For regular TLS operation, I can see clients connecting to just about any server. However, for EAP, typically, the peer has an "association" with a certain server that at least knows a list of methods that the peer or peers that have an association with it support - that's how it knows what method to start in the EAP Request following the EAP Response Identity. EAP doesn't quite provide method negotiation per se - by using EAP NAKs, we can make it soemthing of a negotiation. If the EAP server has no clue about the peer attempting to authenticate or if the server does not have a reasonable number of methods that it supports, the EAP exchange could potentially go on with several NAKs and that wouldn't be good. By that same principle, it seems like whatever would indicate to the server that the client can do EAP-TLS-PSK (when that is a separate method) should also indicate that the client can do EAP-TLS with PSK ciphersuites.=20 2. TLS vs. EAP-TLS Implementations: ------------------------------------ I'm a bit concerned about supporting a subset of TLS in EAP-TLS. For instance, consider a server that has a regular TLS implementation and typically supports the PSK ciphersuites. For a client that talks TLS directly to it, it allows negotiation of any ciphersuites, including the PSK ones. However, for a client that talks TLS via EAP, it needs to make sure that only a subset of the TLS ciphersuites are provided as an option. So, in this case, EAP is not just a carrier for the TLS authentication method - EAP then only supports one "profile" of TLS, so to say.=20 If we think that optimizations can be supported by having a separate EAP-TLS-PSK method, we may still want to do that, but, precluding the use of certain TLS ciphersuites with EAP-TLS seems restrictive.=20 3. Client authentication in EAP-TLS: ------------------------------------ I also notice that client authentication is optional as written in draft-simon-emu-rfc2716bis. When would peer authentication ever be optional for EAP operation? I realize this is something that came from TLS, since client authentication is truly optional in TLS (and that makes sense in certain uses of TLS). However, in the context of EAP, that seems strange. If we were to follow the same notions about optional TLS elements as in RFC4346 (or 4346bis), the server certificate would also then be optional.=20 Vidya _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Mar 07 20:22:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP7Ka-0006d7-M8; Wed, 07 Mar 2007 20:22:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP54U-0006V9-3G for emu@ietf.org; Wed, 07 Mar 2007 17:57:22 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP3Zb-0005Wm-1u for emu@ietf.org; Wed, 07 Mar 2007 16:21:24 -0500 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l27LLIvc014229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 7 Mar 2007 13:21:19 -0800 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l27LKwX3025404; Wed, 7 Mar 2007 13:21:18 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 13:21:13 -0800 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] WGLC: Review of draft-ietf-emu-eap-gpsk-03 Date: Wed, 7 Mar 2007 13:21:17 -0800 Message-ID: In-Reply-To: <45EEEBD6.2020508@qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] WGLC: Review of draft-ietf-emu-eap-gpsk-03 Thread-Index: Acdg2AJDjM4cLSM5QZWFJurywpA+rwAJYrIg References: <45EE9A69.20808@gmx.net> <45EEEBD6.2020508@qualcomm.com> From: "Narayanan, Vidya" To: "Dondeti, Lakshminath" , "Hannes Tschofenig" X-OriginalArrivalTime: 07 Mar 2007 21:21:13.0395 (UTC) FILETIME=[88A6F030:01C760FE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Hannes, Lakshminath, Some responses inline. =20 > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20 > Sent: Wednesday, March 07, 2007 8:44 AM > To: Hannes Tschofenig > Cc: Narayanan, Vidya; emu@ietf.org > Subject: Re: [Emu] WGLC: Review of draft-ietf-emu-eap-gpsk-03 >=20 > Hi Hannes, >=20 > I hope you recover quickly from the flu. Please see inline=20 > for some notes: >=20 > Hannes Tschofenig wrote: > > Hi Vidya, > >=20 > > just a quick comment. > >=20 > > Narayanan, Vidya wrote: > >> All, > >> I reviewed the document and unfortunately, don't feel it=20 > is ready for=20 > >> publication yet. I will only get into the meta issues here=20 > - nits can=20 > >> be addressed later. > >> Major Comments: --------------- > >> 1. Overall, I'm looking for a compelling reason to have=20 > another EAP=20 > >> method and I found none in the document. For instance, all=20 > the design=20 > >> goals listed seem to be satisfied by EAP-TLS-PSK (inclusion of=20 > >> protected payloads can be done as an extension to TLS as=20 > well). And,=20 > >> given that EAP-TLS-PSK is an incremental change to=20 > EAP-TLS, it would=20 > >> be much more compelling to use EAP-TLS-PSK than EAP-GPSK. So, is=20 > >> there at least one design goal of GPSK that cannot be met=20 > by other methods? > >> =20 > >=20 > > You must be kidding. >=20 > Why do you think that? While we don't (need to) do this=20 > often, there is nothing wrong in asking ourselves why a=20 > certain protocol is needed or not before we forward it out of=20 > the WG. In the MSEC WG (several years ago), we considered=20 > the question of why we need to publish yet another group key=20 > management protocol, a few times. When MIKEY was sent to the=20 > IESG, there was the question of why we need one more DH-based=20 > key management protocol. It doesn't hurt to ask ourselves=20 > that question. >=20 I'm sorry that I'm raising this question at LC, rather than before, but, I figured it was better late than never. We all have finite amounts of time and we try to follow a bunch of work and often find ourselves waking up during LCs, sometimes later even. If someone asked me the advantage of doing GPSK over TLS-PSK, I really don't have an answer from the document as of now.=20 > >=20 > > We worked on this several months within a design team. The=20 > design team=20 > > concluded that a new EAP method is the right direction. Then, the=20 > > result of the design team was confirmed by working group a=20 > long time ago. > >=20 > > Now, in WGLC you raise your voice although you and Lakshminath=20 > > actively participate in the working group (with Lakshminath=20 > even being=20 > > a design team member). >=20 I cannot speak for Lakshminath and he has responded for himself already. I have to say that I haven't closely followed the design team activities. An LC review of the document is what really triggered this.=20 > Let's see: I haven't (yet) said anything about not forwarding=20 > this to the AD. I sent in my comments and others might=20 > explain why one or more of them are invalid. That's where it stands. >=20 > I did consider the question that Vidya poses as to why we=20 > need GPSK and why can't we use EAP-TLS-PSK instead. I=20 > disagree with her opinion at the moment: assuming all else=20 > goes well with GPSK, I am ok with publishing it. I am not=20 > sure about recommending it to anyone (other SDOs for e.g.)=20 > just yet. There is a question in the back of my mind as to=20 > if/when EAP-TLS-PSK is specified and if/when a TLS extension=20 > to carry "additional data" is specified, why would anyone use=20 > GPSK and not EAP-TLS-PSK. >=20 > In the meanwhile, if Vidya or anyone else raises the question=20 > on why are we doing this, we have a responsibility to answer. >=20 > My answer is EAP-TLS-PSK is not there yet and there is no way=20 > to carry "additional data" in EAP-TLS-* yet. >=20 Well, defining and implementing carrying of "additional data" in TLS is IMHO much simpler than defining and implementing a new method. So, if "additional data" is your only justification, that seems really weak to me.=20 Regards, Vidya ps: Hannes, I wish you recover soon and look forward to discussing more details later.=20 > regards, > Lakshminath >=20 > >=20 > > I will address your comments after I recovered from a flu. > >=20 > > Ciao > > Hannes > >=20 > >=20 > >> 2. Are the EAP and GPSK headers integrity protected? The SEC_SK=20 > >> construction in various places does not seem to imply so - I don't=20 > >> think that is the intention, as those headers must be=20 > integrity protected. > >> 3. The message, GPSK-4, seems to be there since an EAP Response is=20 > >> needed after an EAP Request. However, this seems to lead=20 > to a couple=20 > >> of things - a) a potentially empty message sent with a MAC=20 > (what is=20 > >> the MAC calculated on?), b) having the client to reflect back a=20 > >> failure message in the event of a failure. I think if the EAP and=20 > >> GPSK headers are protected with a MAC, we should be okay with this. > >> 4. Is there a reference to GKDF? I'm wondering why we are=20 > advocating=20 > >> the use of hash functions as KDFs instead of HMACs. I have more=20 > >> questions on the derivation of MK and other keys, but,=20 > I'll wait for=20 > >> the clarification on GKDF before I ask those. > >> 5. Is the PK always derived? Having a PK for the case where the=20 > >> encryption algorithm is NULL (in Ciphersuite 2, for instance),=20 > >> doesn't seem to be of any value. This actually brings up a=20 > question=20 > >> on the need to define the KDFs the way this document has. For=20 > >> instance, the 2*KS value seems to be there to determine the KDF=20 > >> length, with the assumption that the encryption and integrity key=20 > >> lengths required for the ciphersuites are equal. A better=20 > >> construction seems to be along the lines of IKEv2's prf+, that can=20 > >> produce keys of variable lengths. Was this considered and=20 > if so, why=20 > >> was the GKDF construction as defined seen as a better way to go? > >> Not-so-major Comments: > >> > >> 6. The document seems to re-naming some EAP terminology. I don't=20 > >> think there is a need to do that. > >> 7. Section 8 says "Any packet that cannot be parsed by the=20 > EAP client=20 > >> or the EAP server MUST be silently discarded" - this seems to be=20 > >> defining EAP behavior. In other words, if the packet=20 > cannot even be=20 > >> parsed as a GPSK packet, EAP will be discarding that=20 > packet, not GPSK. > >> Thanks, > >> Vidya > >> > >> _______________________________________________ > >> Emu mailing list > >> Emu@ietf.org > >> https://www1.ietf.org/mailman/listinfo/emu > >> =20 > >=20 > >=20 > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu > >=20 >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Mar 07 20:39:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP7bT-00052g-MI; Wed, 07 Mar 2007 20:39:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP7bT-00050B-5j for emu@ietf.org; Wed, 07 Mar 2007 20:39:35 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP7bR-0007T5-L2 for emu@ietf.org; Wed, 07 Mar 2007 20:39:35 -0500 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 <0JEK00FLM9XW8Q@usaga01-in.huawei.com> for emu@ietf.org; Wed, 07 Mar 2007 17:39:32 -0800 (PST) Received: from N737011 (pool-71-112-126-182.sttlwa.dsl-w.verizon.net [71.112.126.182]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JEK00HPA9XRL6@usaga01-in.huawei.com> for emu@ietf.org; Wed, 07 Mar 2007 17:39:32 -0800 (PST) Date: Wed, 07 Mar 2007 17:39:30 -0800 From: Madjid Nakhjiri To: emu@ietf.org Message-id: <004d01c76122$9e512990$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcdhIp2S0cAB3EZER+mm85PAvUpZxg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: Subject: [Emu] Looking for WG input: Password based method requirements 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="===============1250721648==" Errors-To: emu-bounces@ietf.org This is a multi-part message in MIME format. --===============1250721648== Content-type: multipart/alternative; boundary="Boundary_(ID_Q4m2gKdLYAqtzrb+cvgNYA)" This is a multi-part message in MIME format. --Boundary_(ID_Q4m2gKdLYAqtzrb+cvgNYA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi folks, The design team working on password based authentication has arrived at the set of requirements to be met by the following design and is looking for input from the WG on these requirements, especially on the second subset below. MUST requirements (design team has agreed on the "MUST"ness :-) ================= 1-Support transport of encrypted password to Support legacy user Data/password databases, 2-Provide server authentication 3-Provide resistance to offline dictionary attacks, man in the middle attacks, and replay attacks. 4--RFC 3748, RFC 4017 compliant, compliant with EAP-Keying draft (includes MSK and EMSK generation) 5--active User identity confidentiality for the peer 6-crypto-agility/ cipher suite negotiation (need to define mandatory supported ciphers) 7-Session Resumption (avoid need for new passwords when resuming) 8-Fragmentation and reassembly Requirements we are looking to WG for input, i.e. should we include the following requirements as MUST/SHOULD =============== 1-support password/pin change 2. Support other password based protocols (CHAP, MSCHAP, etc) 3. Cryptographic binding of password exchange to tunnel 4. Defined Extension Mechanism 5-Support transport of channel binding data FYI: the team is narrowing down its options towards use of TLS based encryption for the tunnel carrying pass-word exchanges. Comments/ input are welcome, Thanks and Regards, Madjid Nakhjiri On behalf of the password based authentication design team. --Boundary_(ID_Q4m2gKdLYAqtzrb+cvgNYA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi folks,

 

The design team working on password based authentication has arrived at the set of requirements to be met by the following design and is looking for input from the WG on these requirements, especially on the second subset below.

 

MUST requirements (design team has agreed on the “MUST”ness J

=================

1-Support transport of encrypted password to Support legacy user Data/password databases,

2-Provide server authentication

3-Provide resistance to offline dictionary attacks, man in the middle attacks, and replay attacks.

4--RFC 3748, RFC 4017 compliant, compliant with EAP-Keying draft (includes MSK and EMSK generation)

5--active User identity confidentiality for the peer

6-crypto-agility/ cipher suite negotiation (need to define mandatory supported ciphers)

7-Session Resumption (avoid need for new passwords when resuming)

8-Fragmentation and reassembly

 

Requirements we are looking to WG for input, i.e. should we include the following requirements as MUST/SHOULD

===============

1-support password/pin change

2. Support other password based protocols (CHAP, MSCHAP, etc)

3. Cryptographic binding of password exchange to tunnel

4. Defined Extension Mechanism

5-Support transport of channel binding data

 

 

FYI: the team is narrowing down its options towards use of TLS based encryption for the tunnel carrying pass-word exchanges.

 

 

Comments/ input are welcome,

 

Thanks and Regards,

 

Madjid Nakhjiri

On behalf of the password based authentication design team.

--Boundary_(ID_Q4m2gKdLYAqtzrb+cvgNYA)-- --===============1250721648== 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 --===============1250721648==-- From emu-bounces@ietf.org Wed Mar 07 22:38:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP9S3-00047r-5k; Wed, 07 Mar 2007 22:37:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP9S2-00047l-Sl for emu@ietf.org; Wed, 07 Mar 2007 22:37:58 -0500 Received: from mail5.sea5.speakeasy.net ([69.17.117.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP9S1-0005Lx-Cg for emu@ietf.org; Wed, 07 Mar 2007 22:37:58 -0500 Received: (qmail 4582 invoked from network); 8 Mar 2007 03:37:54 -0000 Received: from dsl017-049-110.sfo4.dsl.speakeasy.net (HELO jm) ([69.17.49.110]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 8 Mar 2007 03:37:54 -0000 Received: by jm (sSMTP sendmail emulation); Wed, 7 Mar 2007 19:37:53 -0800 Date: Wed, 7 Mar 2007 19:37:53 -0800 From: Jouni Malinen To: "Narayanan, Vidya" Subject: Re: [Emu] WGLC: Review of draft-ietf-emu-eap-gpsk-03 Message-ID: <20070308033753.GE5059@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.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Mon, Mar 05, 2007 at 06:03:18PM -0800, Narayanan, Vidya wrote: > 1. Overall, I'm looking for a compelling reason to have another EAP > method and I found none in the document. For instance, all the design > goals listed seem to be satisfied by EAP-TLS-PSK (inclusion of protected > payloads can be done as an extension to TLS as well). And, given that > EAP-TLS-PSK is an incremental change to EAP-TLS, it would be much more > compelling to use EAP-TLS-PSK than EAP-GPSK. So, is there at least one > design goal of GPSK that cannot be met by other methods? As far as I can tell, EAP-TLS-PSK would be yet another EAP method in the same sense as EAP-GPSK, so I don't see EAP-TLS-PSK in any way a better solution from the view point of not adding a new method. As far as comparison of EAP-GPSK vs. EAP-TLS-PSK is concerned, one major part is in EAP-GPSK being much simpler and smaller from implementation view point. In most cases, extending TLS seems to bring in a major extra cost of having to modify a TLS library which is not desirable in many cases. It may mean that the TLS implementation included in the system would not be suitable and the EAP implementation would need to bring in another TLS implementation with maintenance and memory/flash footprint concerns. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Mar 07 23:49:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPAZh-0000WW-Os; Wed, 07 Mar 2007 23:49:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPAZg-0000Vr-U7 for emu@ietf.org; Wed, 07 Mar 2007 23:49:56 -0500 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 1HPAZf-0005oU-HD for emu@ietf.org; Wed, 07 Mar 2007 23:49:56 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 07 Mar 2007 20:49:57 -0800 X-IronPort-AV: i="4.14,262,1170662400"; d="scan'208"; a="469174166:sNHT48173884" 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/8.12.11) with ESMTP id l284ntm9005377; Wed, 7 Mar 2007 20:49:55 -0800 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 l284nt1T000176; Thu, 8 Mar 2007 04:49:55 GMT 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.1830); Wed, 7 Mar 2007 20:49:55 -0800 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] RFC4279 support in draft-simon-emu-rfc2716bis? Date: Wed, 7 Mar 2007 20:49:51 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis? Thread-Index: Acdg033kNyrGe+jPQfaSwGYq2nwTpgAaL1tg From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , , X-OriginalArrivalTime: 08 Mar 2007 04:49:55.0044 (UTC) FILETIME=[37349240:01C7613D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1823; t=1173329395; x=1174193395; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20RFC4279=20support=20in=20draft-simon-emu-rfc2 716bis? |Sender:=20; bh=BTp8nM9gjNpeoewDhzdborjm1Nw2Y7LKUq0FYiu13Hw=; b=CkgQ4D1dkKKzr7Y/JGj1T142KZ66M/YGsxX9aGq7AXv6r+kSUauojaCoQxFvn5ACUPFW1vUj 8hVO92ZOspbcrVbm/hlajQsoPjlQcY/xU7Yd0/ab/OIdZOXijFkMYKHE; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org =20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Wednesday, March 07, 2007 8:12 AM > To: Hannes.Tschofenig@gmx.net; vidyan@qualcomm.com > Cc: emu@ietf.org > Subject: Re: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis? >=20 > Hannes Tschofenig said: >=20 > >We discussed this already several times and this lead me to=20 > work on a=20 > >draft together with Thomas Otto: > > > >http://tools.ietf.org/id/draft-otto-emu-eap-tls-psk-02.txt >=20 > Which begs the question: what is the WG doing with this draft? >=20 [Joe] The draft is not currently a working group item. The pre-shared key mechanism charter item is covered by EAP-GPSK. There is a charter item for enhanced EAP-TLS which could support TLS-PSK and other enhancements. =20 > >From where I sit, it seems quite likely that EAP-TLS-PSK, if=20 > completed,=20 > >will > be deployed. When TLS 1.2 is done, this method could=20 > eventually benefit from KDF negotiation, and should meet the=20 > criteria for FIPS 140-2 certification. Given the TLS code=20 > base in embedded systems, it should not be hard to add=20 > support for EAP-TLS-PSK within embedded devices. >=20 [Joe] The KDF needs to be looked at, but I do not think it is necessarily a show stopper, it does provide KDF agility. Reports from people who implemented EAP-GPSK indicate that it was simple to implement. I have heard push back from embedded system implementers on EAP-TLS stating that it is too complex, this may be a result of certificate support I am not sure.=20 > I my doubts about EAP-GPSK on several of these dimensions. >=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 Wed Mar 07 23:55:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPAfB-0005QB-Km; Wed, 07 Mar 2007 23:55:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPAfA-0005Q5-T6 for emu@ietf.org; Wed, 07 Mar 2007 23:55:36 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPAf9-0007RI-9G for emu@ietf.org; Wed, 07 Mar 2007 23:55:36 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 07 Mar 2007 20:55:35 -0800 X-IronPort-AV: i="4.14,262,1170662400"; d="scan'208"; a="398559502:sNHT53924872" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l284tYvp017347; Wed, 7 Mar 2007 20:55:34 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l284tSa9025572; Thu, 8 Mar 2007 04:55:34 GMT 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.1830); Wed, 7 Mar 2007 20:55:34 -0800 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] RFC4279 support in draft-simon-emu-rfc2716bis? Date: Wed, 7 Mar 2007 20:55:30 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis? Thread-Index: AcdfwTgm8NcDCsOxRYOHV8R1FGtqLQAZculwAAC5nsAANTMLsAAApOsQ From: "Joseph Salowey \(jsalowey\)" To: "Narayanan, Vidya" , "Bernard Aboba" , X-OriginalArrivalTime: 08 Mar 2007 04:55:34.0555 (UTC) FILETIME=[0191D6B0:01C7613E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4909; t=1173329734; x=1174193734; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20RFC4279=20support=20in=20draft-simon-emu-rfc2 716bis? |Sender:=20; bh=b8+4ztLbm+Lp1kWyEjwIkdHCl/XxIo7VNIJMw5oSkvk=; b=tX8v7UZp1IOQG43A/y3sJEhqUYJYITgEdvgQvzYR8s4QQXGph2NsQ2Chvw3zB08Bs33QG0fS JNlSBvqNmDR/VGnoLfVWeZt/6LVzoDw5cU0lBIUCc4k50+z69Np3E9M3; Authentication-Results: sj-dkim-5; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Sent: Wednesday, March 07, 2007 1:28 PM > To: Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org > Subject: RE: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis? >=20 > Hi Joe,=20 >=20 > Let me separate this into different topics for clarity. =20 >=20 > >=20 > > [Joe] EAP negotiation happens early before TLS negotiation.=20 > If a peer >=20 > > or server negotiate a particular EAP method they may actually not=20 > > actually be able to complete this because TLS negotiation=20 > arrives upon >=20 > > an result that is not satisfactory. Restricting EAP-TLS to=20 > certificate >=20 > > based ciphers does not solve this problem, but it helps. In an=20 > > enhanced EAP-TLS the initial message from the server could indicate=20 > > the supported ciphers giving the chance for a client to NAK. > >=20 > >=20 >=20 > 1. TLS negotiations in EAP:=20 > --------------------------- > I guess in a way, this is trying to perform some rudimentary=20 > TLS ciphersuite negotiation at the EAP level. For regular TLS=20 > operation, I can see clients connecting to just about any=20 > server. However, for EAP, typically, the peer has an=20 > "association" with a certain server that at least knows a=20 > list of methods that the peer or peers that have an=20 > association with it support - that's how it knows what method=20 > to start in the EAP Request following the EAP Response=20 > Identity. EAP doesn't quite provide method negotiation per se=20 > - by using EAP NAKs, we can make it soemthing of a=20 > negotiation. If the EAP server has no clue about the peer=20 > attempting to authenticate or if the server does not have a=20 > reasonable number of methods that it supports, the EAP=20 > exchange could potentially go on with several NAKs and that=20 > wouldn't be good.=20 [Joe] EAP provides negotiation and it is even used in real networks. I agree it is not ideal, but it is what we have.=20 >By that same principle, it seems like=20 > whatever would indicate to the server that the client can do=20 > EAP-TLS-PSK (when that is a separate method) should also=20 > indicate that the client can do EAP-TLS with PSK ciphersuites.=20 >=20 [Joe] I'm not sure what principle you are referring to so I don't see how it can be applied to this problem. The client tells the server it supports method x by responding to the server's challenge for method x. The ciphersuite is not available in the initial challenge. One could modify EAP-TLS such ciphersuites are advertised in the EAP-TLS start, but this would interfere with backwards capability, hence there is a charter item for enhanced TLS.=20 > 2. TLS vs. EAP-TLS Implementations: > ------------------------------------ > I'm a bit concerned about supporting a subset of TLS in=20 > EAP-TLS. For instance, consider a server that has a regular=20 > TLS implementation and typically supports the PSK=20 > ciphersuites. For a client that talks TLS directly to it, it=20 > allows negotiation of any ciphersuites, including the PSK=20 > ones. However, for a client that talks TLS via EAP, it needs=20 > to make sure that only a subset of the TLS ciphersuites are=20 > provided as an option. So, in this case, EAP is not just a=20 > carrier for the TLS authentication method - EAP then only=20 > supports one "profile" of TLS, so to say.=20 >=20 [Joe] Most TLS libraries support "profiling" of TLS ciphersuites for different applications and deployments. =20 > If we think that optimizations can be supported by having a=20 > separate EAP-TLS-PSK method, we may still want to do that,=20 > but, precluding the use of certain TLS ciphersuites with=20 > EAP-TLS seems restrictive.=20 >=20 [Joe] It is not necessary to put restrictions on an enhanced EAP-TLS since it does not have the same backwards compatible expectations as EAP-TLS. =20 > 3. Client authentication in EAP-TLS: > ------------------------------------ > I also notice that client authentication is optional as=20 > written in draft-simon-emu-rfc2716bis. When would peer=20 > authentication ever be optional for EAP operation?=20 >I realize=20 > this is something that came from TLS, since client=20 > authentication is truly optional in TLS (and that makes sense=20 > in certain uses of TLS). However, in the context of EAP, that=20 > seems strange. If we were to follow the same notions about=20 > optional TLS elements as in RFC4346 (or 4346bis), the server=20 > certificate would also then be optional.=20 >=20 [Joe] There are EAP use cases where peer authentication is not required but server authentication is. There are also instances where anonymous ciphersuites are used, but the trade off in security is much more severe with anonymous ciphersuites.=20 > Vidya >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Mar 07 23:59:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPAjE-0006ar-BU; Wed, 07 Mar 2007 23:59:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPAjD-0006YY-0C for emu@ietf.org; Wed, 07 Mar 2007 23:59:47 -0500 Received: from bay0-omc1-s23.bay0.hotmail.com ([65.54.246.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPAjA-00083q-F6 for emu@ietf.org; Wed, 07 Mar 2007 23:59:46 -0500 Received: from hotmail.com ([207.46.8.103]) by bay0-omc1-s23.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 7 Mar 2007 20:59:42 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 7 Mar 2007 20:59:42 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Thu, 08 Mar 2007 04:59:40 GMT X-Originating-IP: [131.107.0.73] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: jsalowey@cisco.com, Hannes.Tschofenig@gmx.net, vidyan@qualcomm.com Bcc: Subject: RE: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis? Date: Wed, 07 Mar 2007 20:59:40 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 08 Mar 2007 04:59:42.0509 (UTC) FILETIME=[955C9DD0:01C7613E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 >[Joe] The KDF needs to be looked at, but I do not think it is >necessarily a show stopper, it does provide KDF agility. Reports from >people who implemented EAP-GPSK indicate that it was simple to >implement. I have heard push back from embedded system implementers on >EAP-TLS stating that it is too complex, this may be a result of >certificate support I am not sure. In my experience, adding certificate support dramatically increases footprint. For example, as I recall IKEv1/IPsec with AES CBC/HMAC-SHA1 is around 250 KB or so if we're just talking about pre-shared key authentication but if you add certificate support that is another 750 KB, which will be too big for some applications. I would think that the same logic applies to EAP-TLS-PSK. Of course that would require a stripped down implemenation of TLS that only supported TLS-PSK, no certificates. I guess that doesn't exist yet? If you had to pull in all of say, Open SSL plus add TLS-PSK support, that would almost certainly make it too large for many embedded applications. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Mar 08 00:08:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPArQ-0006Z2-Ag; Thu, 08 Mar 2007 00:08:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPArP-0006Xy-Cl for emu@ietf.org; Thu, 08 Mar 2007 00:08:15 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPArO-0001XN-2N for emu@ietf.org; Thu, 08 Mar 2007 00:08:15 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 07 Mar 2007 21:08:13 -0800 X-IronPort-AV: i="4.14,262,1170662400"; d="scan'208"; a="46462691:sNHT47269611" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l2858Dmq009881; Wed, 7 Mar 2007 21:08:13 -0800 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 l2858D1T008743; Thu, 8 Mar 2007 05:08:13 GMT 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); Wed, 7 Mar 2007 21:08:13 -0800 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] RFC4279 support in draft-simon-emu-rfc2716bis? Date: Wed, 7 Mar 2007 21:08:10 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis? Thread-Index: AcdhPpYi/vKKioIoSE2MNVkwlEJUGwAAQJ1g From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , , X-OriginalArrivalTime: 08 Mar 2007 05:08:13.0249 (UTC) FILETIME=[C5C95B10:01C7613F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1620; t=1173330493; x=1174194493; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20RFC4279=20support=20in=20draft-simon-emu-rfc2 716bis? |Sender:=20; bh=IDEaBQWd9XyrZA36pq/v64aGdmRz22EK9K+YQqWmE0c=; b=c+oii0+Me73Mt5scluGT5nISYR8fuKRRB0kRUsFbXcU3Lepaa39MUiHGg40RC9usQQHRwa54 us7U4v+Cf98ZlZsiH5YBcXETz5IL25E+vBcRC4DKJnEg5ao5uob164mk; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org =20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Wednesday, March 07, 2007 9:00 PM > To: Joseph Salowey (jsalowey); Hannes.Tschofenig@gmx.net;=20 > vidyan@qualcomm.com > Cc: emu@ietf.org > Subject: RE: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis? >=20 > >[Joe] The KDF needs to be looked at, but I do not think it is=20 > >necessarily a show stopper, it does provide KDF agility. =20 > Reports from=20 > >people who implemented EAP-GPSK indicate that it was simple to=20 > >implement. I have heard push back from embedded system=20 > implementers on=20 > >EAP-TLS stating that it is too complex, this may be a result of=20 > >certificate support I am not sure. >=20 > In my experience, adding certificate support dramatically=20 > increases footprint. For example, as I recall IKEv1/IPsec=20 > with AES CBC/HMAC-SHA1 is around 250 KB or so if we're just=20 > talking about pre-shared key authentication but if you add=20 > certificate support that is another 750 KB, which will be too=20 > big for some applications. >=20 > I would think that the same logic applies to EAP-TLS-PSK. Of=20 > course that would require a stripped down implemenation of=20 > TLS that only supported TLS-PSK, no certificates. I guess=20 > that doesn't exist yet? If you had to pull in all of say,=20 > Open SSL plus add TLS-PSK support, that would almost=20 > certainly make it too large for many embedded applications. >=20 [Joe] Yes OpenSSL is a commonly used toolkit, however I don't think one of its design goals is a small footprint.=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Mar 09 04:21:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbHO-0007lN-1V; Fri, 09 Mar 2007 04:20:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPSUU-0002Br-B5 for emu@ietf.org; Thu, 08 Mar 2007 18:57:46 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPSUS-0005b6-OF for emu@ietf.org; Thu, 08 Mar 2007 18:57:46 -0500 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 <0JEL0034XZW7KP@usaga01-in.huawei.com> for emu@ietf.org; Thu, 08 Mar 2007 15:57:44 -0800 (PST) Received: from N737011 (pool-71-112-126-182.sttlwa.dsl-w.verizon.net [71.112.126.182]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JEL006CUZW3E1@usaga01-in.huawei.com> for emu@ietf.org; Thu, 08 Mar 2007 15:57:43 -0800 (PST) Date: Thu, 08 Mar 2007 15:57:43 -0800 From: Madjid Nakhjiri To: emu@ietf.org Message-id: <006001c761dd$904adb00$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acdh3Y+oTFHg9e8WR9uErUbBRy3PEA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d Cc: 'Bernard Aboba' Subject: [Emu] Q & C on 2716bis-08 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="===============0101686856==" Errors-To: emu-bounces@ietf.org This is a multi-part message in MIME format. --===============0101686856== Content-type: multipart/alternative; boundary="Boundary_(ID_T1NmXsqghHqImC1JG61uLg)" This is a multi-part message in MIME format. --Boundary_(ID_T1NmXsqghHqImC1JG61uLg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Bernard, others, I have a few comments/ questions on 08 of the 2716bis. I apologize if this has been discussed before. Section 2.1.3 " If the EAP server authenticates unsuccessfully, the peer MAY send an EAP-Response packet of EAP-Type=EAP-TLS containing a TLS Alert message identifying the reason for the failed authentication. The peer MAY send a TLS alert message rather than immediately terminating the conversation so as to allow the EAP server to log the cause of the error for examination by the system administrator. To ensure that the EAP Server receives the TLS alert message, the peer MUST wait for the EAP-Server to reply before terminating the conversation. The EAP Server MUST reply with an EAP-Failure packet since server authentication failure is a terminal condition. " What sort of benefit does this provide. If a server fails to authenticate due to a security reason, then its EAP failure would not matter, since it cannot be trusted anyway. If the authentication fails because of channel errors, we are not giving the server another chance to authenticate, since it must send failure, so no benefit here either. Is this to allow the server to shut down the EAP state machine successfully? Section 2.1.4 " An EAP-TLS peer supporting privacy MUST provide a certificate list containing at least one entry in response to the subsequent certificate_request sent by the server. If the EAP-TLS server supporting privacy does not receive a client certificate in response to the subsequent certificate_request, then it MUST abort the session." How would the peer and the server know this is a "subsequent certificate request" and not the initial certificate request? is there anything in the protocol to indicate this, not sure how? Or you simply rely on the state for TLS tunnel. Nit on key hierarchy text: TMS only mentioned in the figure 1, but nowhere in the text. Finally, this might be a dumb TLS question: Seems that if the TLS session is being resumed, it seems that only a sessionID is being presented by the client, no server certs, no key exchange records. Is possession of anything (except of sessionID) being proven? Anything is signed? Or the client and server just start using the established TLS master key (TMS)? Thanks, Madjid --Boundary_(ID_T1NmXsqghHqImC1JG61uLg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Bernard, others,

 

I have a few comments/ questions on 08 of the 2716bis. I apologize if this has been discussed before.

 

Section 2.1.3

“

   If the EAP server authenticates unsuccessfully, the peer MAY send an

   EAP-Response packet of EAP-Type=EAP-TLS containing a TLS Alert

   message identifying the reason for the failed authentication.  The

   peer MAY send a TLS alert message rather than immediately terminating

   the conversation so as to allow the EAP server to log the cause of

   the error for examination by the system administrator.

 

To ensure that the EAP Server receives the TLS alert message, the

   peer MUST wait for the EAP-Server to reply before terminating the

   conversation.  The EAP Server MUST reply with an EAP-Failure packet

   since server authentication failure is a terminal condition.

“

 

What sort of benefit does this provide. If a server fails to authenticate due to a security reason, then its EAP failure would not matter, since it cannot be trusted anyway.

If the authentication fails because of channel errors, we are not giving the server another chance to authenticate, since it must send failure, so no benefit here either.

Is this to allow the server to shut down the EAP state machine successfully?

 

 

Section 2.1.4

“

An EAP-TLS peer supporting privacy MUST provide a certificate list

   containing at least one entry in response to the subsequent

   certificate_request sent by the server.  If the EAP-TLS server

   supporting privacy does not receive a client certificate in response

   to the subsequent certificate_request, then it MUST abort the

   session.”

 

How would the peer and the server know this is a “subsequent certificate request” and not the initial certificate request?

is there anything in the protocol to indicate this, not sure how? Or you simply rely on the state for TLS tunnel.

 

Nit on key hierarchy text: TMS only mentioned in the figure 1, but nowhere in the text.

 

Finally, this might be a dumb TLS question:

 

Seems that if the TLS session is being resumed, it seems that only a sessionID is being presented by the client, no server certs, no key exchange records.

Is possession of anything (except of sessionID) being proven? Anything is signed? Or the client and server just start using the established TLS master key (TMS)?

 

Thanks,

 

Madjid

--Boundary_(ID_T1NmXsqghHqImC1JG61uLg)-- --===============0101686856== 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 --===============0101686856==-- From emu-bounces@ietf.org Fri Mar 09 09:34:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPgBD-0003Er-95; Fri, 09 Mar 2007 09:34:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPgBC-0003EX-Jo for emu@ietf.org; Fri, 09 Mar 2007 09:34:46 -0500 Received: from bay0-omc3-s38.bay0.hotmail.com ([65.54.246.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPgB9-00043K-IG for emu@ietf.org; Fri, 09 Mar 2007 09:34:46 -0500 Received: from hotmail.com ([207.46.8.95]) by bay0-omc3-s38.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Fri, 9 Mar 2007 06:34:43 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 9 Mar 2007 06:34:42 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Fri, 09 Mar 2007 14:34:38 GMT X-Originating-IP: [24.16.66.58] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <006001c761dd$904adb00$2f01a8c0@china.huawei.com> From: "Bernard Aboba" To: mnakhjiri@huawei.com, emu@ietf.org Bcc: Subject: RE: [Emu] Q & C on 2716bis-08 Date: Fri, 09 Mar 2007 06:34:38 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 09 Mar 2007 14:34:42.0987 (UTC) FILETIME=[13A987B0:01C76258] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 >What sort of benefit does this provide. If a server fails to authenticate >due to a security reason, then its EAP failure would not matter, since it >cannot be trusted anyway. This is an optional mechanism for enabling the server to log the reason for the error. This might allow an administrator to diagnose and correct the problem. >How would the peer and the server know this is a "subsequent certificate >request" and not the initial certificate request? Because the peer did not provide a certificate in response to the first request -- that is how privacy is provided. >Is possession of anything (except of sessionID) being proven? Anything is >signed? Authentication is provided in the Finished message. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Mar 09 13:33:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPjth-0002ZA-Tu; Fri, 09 Mar 2007 13:32:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPjtg-0002Yu-Ma for emu@ietf.org; Fri, 09 Mar 2007 13:32:56 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPjte-0000eH-7h for emu@ietf.org; Fri, 09 Mar 2007 13:32:56 -0500 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 <0JEN00D6XFHUL9@usaga01-in.huawei.com> for emu@ietf.org; Fri, 09 Mar 2007 10:32:18 -0800 (PST) Received: from N737011 (pool-71-112-126-182.sttlwa.dsl-w.verizon.net [71.112.126.182]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JEN004URFHPSS@usaga01-in.huawei.com> for emu@ietf.org; Fri, 09 Mar 2007 10:32:18 -0800 (PST) Date: Fri, 09 Mar 2007 10:32:16 -0800 From: Madjid Nakhjiri Subject: RE: [Emu] Q & C on 2716bis-08 In-reply-to: To: 'Bernard Aboba' , emu@ietf.org Message-id: <001e01c76279$43f086f0$2f01a8c0@china.huawei.com> 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: AcdiWBYNBQAhRxTQSzWNxkqc93ivrgAIObGQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 quick reply. I am ok on the first and third questions, thanks. However, what I meant by my second question was how do we know from a protocol stand point that this is not the first but a subsequent request? Are we relying on the server state (a tunnel is established now)? Madjid -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: Friday, March 09, 2007 6:35 AM To: mnakhjiri@huawei.com; emu@ietf.org Subject: RE: [Emu] Q & C on 2716bis-08 >What sort of benefit does this provide. If a server fails to authenticate >due to a security reason, then its EAP failure would not matter, since it >cannot be trusted anyway. This is an optional mechanism for enabling the server to log the reason for the error. This might allow an administrator to diagnose and correct the problem. >How would the peer and the server know this is a "subsequent certificate >request" and not the initial certificate request? Because the peer did not provide a certificate in response to the first request -- that is how privacy is provided. >Is possession of anything (except of sessionID) being proven? Anything is >signed? Authentication is provided in the Finished message. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Mar 09 14:57:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPlDV-0008JU-0S; Fri, 09 Mar 2007 14:57:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPlDU-0008JO-D6 for emu@ietf.org; Fri, 09 Mar 2007 14:57:28 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPlDR-0000IP-IJ for emu@ietf.org; Fri, 09 Mar 2007 14:57:28 -0500 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l29JvLwJ023311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 Mar 2007 11:57:22 -0800 Received: from [129.46.78.141] (ldondeti.na.qualcomm.com [129.46.78.141]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l29JvK4m008044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Mar 2007 11:57:21 -0800 (PST) Message-ID: <45F1BBD7.1030203@qualcomm.com> Date: Fri, 09 Mar 2007 11:56:07 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Jouni Malinen Subject: TLS reuse (Re: [Emu] WGLC: Review of draft-ietf-emu-eap-gpsk-03) References: <20070308033753.GE5059@jm.kir.nu> In-Reply-To: <20070308033753.GE5059@jm.kir.nu> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi, I have a question. I have some experience with code reuse, but I was hacking, err... prototyping. What is the general sense on using a piece of TLS code to do things like EAP-TLS or EAP-TLS and EAP-TLS-PSK? I ask because elsewhere people make the argument that TLS is already there on a certain device and so DTLS is an incremental implementation etc. I hope we don't have a huge thread on it, but I am curious about thoughts on reuse. thanks, Lakshminath Jouni Malinen wrote: > On Mon, Mar 05, 2007 at 06:03:18PM -0800, Narayanan, Vidya wrote: > > > As far as I can tell, EAP-TLS-PSK would be yet another EAP method in the > same sense as EAP-GPSK, so I don't see EAP-TLS-PSK in any way a better > solution from the view point of not adding a new method. > > As far as comparison of EAP-GPSK vs. EAP-TLS-PSK is concerned, one > major part is in EAP-GPSK being much simpler and smaller from > implementation view point. In most cases, extending TLS seems to bring > in a major extra cost of having to modify a TLS library which is not > desirable in many cases. It may mean that the TLS implementation > included in the system would not be suitable and the EAP implementation > would need to bring in another TLS implementation with maintenance and > memory/flash footprint concerns. > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Mar 09 22:10:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPryz-0007Xt-AY; Fri, 09 Mar 2007 22:10:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPryx-0007Xo-Sk for emu@ietf.org; Fri, 09 Mar 2007 22:10:55 -0500 Received: from mail6.sea5.speakeasy.net ([69.17.117.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPryw-0004Qs-ER for emu@ietf.org; Fri, 09 Mar 2007 22:10:55 -0500 Received: (qmail 17152 invoked from network); 10 Mar 2007 03:10:47 -0000 Received: from dsl017-049-110.sfo4.dsl.speakeasy.net (HELO jm) ([69.17.49.110]) (envelope-sender ) by mail6.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 10 Mar 2007 03:10:47 -0000 Received: by jm (sSMTP sendmail emulation); Fri, 9 Mar 2007 19:10:45 -0800 Date: Fri, 9 Mar 2007 19:10:45 -0800 From: Jouni Malinen To: Lakshminath Dondeti Subject: Re: TLS reuse (Re: [Emu] WGLC: Review of draft-ietf-emu-eap-gpsk-03) Message-ID: <20070310031045.GA5050@jm.kir.nu> References: <20070308033753.GE5059@jm.kir.nu> <45F1BBD7.1030203@qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45F1BBD7.1030203@qualcomm.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 Fri, Mar 09, 2007 at 11:56:07AM -0800, Lakshminath Dondeti wrote: > I have a question. I have some experience with code reuse, but I was > hacking, err... prototyping. What is the general sense on using a piece > of TLS code to do things like EAP-TLS or EAP-TLS and EAP-TLS-PSK? I ask > because elsewhere people make the argument that TLS is already there on > a certain device and so DTLS is an incremental implementation etc. I think the answer is "it depends".. In many (most?) embedded client designs I've been involved with in one way or another, TLS library has been one of the key issues due to the possible overhead (e.g., OpenSSL can add almost 1 MB to the binary). It would be ideal, to be able to share the same TLS implementation for all uses on the device to save in size (both flash and RAM). In addition to size concerns, it would also be quite helpful if the native TLS implementation with the target platform could be used (if one is available) to benefit from existing integration with certificate store and private key access, including UI components. Providing a nice user experience with another TLS library can get difficult, if not impossible, in many cases. That said, it is not always possible to use the native TLS implementation. For example, one of the most difficult aspects of EAP-FAST from implementation view point is its requirement for TLS extensions (ClientHello extension and session ticket). Most existing TLS libraries do not support this, so whoever is implementing EAP-FAST may need to modify TLS implementation and this is something, that is often not feasible for OS/SDK provided implementation. Consequently, EAP-FAST (or EAP-TLS-PSK for that matter) may end up requiring the EAP server/peer implementation to include another TLS library. If whoever is working with EAP method implementation is also in control of the system TLS library, adding support for TLS extensions is less likely to be an issue (though, often the person working on EAP method is not the same as the one working on TLS library, so this adds some extra overhead, but anyway, still manageable). If EAP method is being implemented by someone who does not have any control on the system TLS library, things can get quite difficult. Convinsing TLS vendors to add some extensions may take time and effort; especially so, when they may not see much need for the requested extension as far as the "main uses" of the TLS from their and most of their customers view points are concerned (HTTPS? IMAPS?, etc.). I would say that reusing TLS implementations with functionality specified in TLSv1 (i.e., without any extensions) is fine in many cases since most TLS libraries include all the needed functionality. However, anything new (as in anything brought in during last few years) is going to make such reuse difficult at this point. Sure, in the future this can get easier should the TLS vendors like the new extensions enough to implement them, but until that, there is a risk of causing extra issues to vendors who work with EAP implementation and just rely on external TLS libraries.. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Mar 11 23:22:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQb7J-0001nP-9B; Sun, 11 Mar 2007 23:22:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQb7I-0001nK-8G for emu@ietf.org; Sun, 11 Mar 2007 23:22:32 -0400 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQb79-00081d-75 for emu@ietf.org; Sun, 11 Mar 2007 23:22:32 -0400 Received: from [127.0.0.1] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (sccrmhc13) with ESMTP id <200703120322220130012a9te>; Mon, 12 Mar 2007 03:22:22 +0000 Message-ID: <45F4C767.1080803@cs.umd.edu> Date: Sun, 11 Mar 2007 23:22:15 -0400 From: Charles Clancy User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: emu@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Subject: [Emu] EAP-GPSK update X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org All, We've put together an update to the GPSK draft to address the last call comments. Below is a list of the identified issues and their solutions. For a variety of issues we recommended no change with a brief description. If more detail is desired, we can certainly discuss them further on the list. You can find the latest version here, pending the I-D editor's release: http://www.tschofenig.com/svn/draft-clancy-emu-eap-gpsk/draft-ietf-emu-eap-gpsk-04.txt -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy ----------- TECHNICAL ----------- Issue: why not use EAP-TLS-PSK instead (narayanan) Resolution: no change -- WG consensus was to do GPSK Issue: MAC does not cover the EAP or GPSK header (Dondeti, Narayanan) Resolution: no change -- protecting the EAP header is pointless, since the EAP engine would not be able to validate the MAC. The GPSK header only includes an op-code, which can be implicitly checked by validating the MAC on the rest of the packet contents. Issue: use of SHA-1 (Aboba) Resolution: switched AES ciphersuite to use SHA256 Issue: KDFs do not appear compliant with draft-dange-nistkdf-01 (Aboba) Resolution: no change, NIST reviewed our KDF, and the current one is based specifically on their recommendations Issue: Why doesn't the MK derviation use the PSK as it's keying input, instead of all zeros? (Dondeti) Resolution: no change -- The PSK can be of arbitrary length, and therefore may not be the correct length to use as the KDF input key. Issue: revert to previous KDF based on MACs (Dondeti, Narayanan) Resolution: no change -- the KDF changes from MAC to Hash were proposed by NIST Issue: Use of CTR instead of CBC to avoid implementing AES decryption code (Dondeti) Resolution: no change -- we discussed this at length, CTR does its own integrity protection, which would be redundant, hence the decision to use CBC instead Issue: dropping nonparsable packets is EAP behavior (Narayanan) Resolution: changed to talk about parsing EAP-GPSK packets, rather than EAP packets Issue: derive keys individually rather than deriving a big block and then split it up (Narayanan) Resolution: no change -- places fewer restrictions on the KDF, and guarantees cryptographic independence Issue: derivation of PK when not using an encryption Ciphersuite (Narayanan) Resolution: removed PK from hash ciphersuite discussion, added other comments indicating it's lack of necessity for non-encrypting ciphersuites ----------- EDITORIAL ----------- Issue: citing old drafts (Malinen) Resolution: moot, as references were removed Issue: s/needs to instantiated/needs to be instantiated/ (Malinen) Resolution: text edited Issue: discussion of other protocols and deficiencies (Aboba) Resolution: section removed Issue: quick availability as a design goal (Aboba) Resolution: text edited Issue: design goal s/Wide Applicability/Security Model/ (Aboba) Resolution: text edited Issue: efficiency design goal, mention round trips (Aboba) Resolution: text edited Issue: efficiency design goal, mention Privacy not supported (Aboba) Resolution: no change -- privacy supported if AES ciphersuite is used Issue: define peer/server/session-ID (Aboba) Resolution: defined Issue: ambiguous definition of KS with respect to hashes (Dondeti) Resolution: removed ambiguous text Issue: erronious references to multiple protected payload blocks (Dondeti) Resolution: fixed some references -- others referred to them as plural as you can have a total 3 in the entire protocol exchange Issue: order of key definitions in terminology section (Dondeti) Resolution: changed the order to be alphabetical -- not quite what was proposed, but logical IMHO Issue: precision of some of the protocol specification (Dondeti) Resolution: made some minor edits Issue: GPSK-4 is needed only as a filler, specify that (Dondeti) Resolution: no change, GPSK-4 can contain a PD_Payload_Block Issue: Text involving validation of keys after GPSK-4 (Dondeti) Resolution: text revised Issue: discussion of MACs in KDF section (Dondeti) Resolution: text replaced Issue: instead of length(Csuites_List) use NumberOf_CSuites to save one byte (Dondeti) Resolution: no change -- using a 2-byte length makes parsing code consistent across all length-prefixed data blocks Issue: EAP terminology renamed (Narayanan) Resolution: s/client/peer/g _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Mar 11 23:59:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQbhK-0000L6-V8; Sun, 11 Mar 2007 23:59:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQbhJ-0000J3-Qk for emu@ietf.org; Sun, 11 Mar 2007 23:59:45 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQbhI-0006ET-Fw for emu@ietf.org; Sun, 11 Mar 2007 23:59:45 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l2C3xaXH028439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 11 Mar 2007 20:59:36 -0700 Received: from [10.50.76.160] (qconnect-10-50-76-160.qualcomm.com [10.50.76.160]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l2C3xZgi014752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 11 Mar 2007 20:59:36 -0700 (PDT) Message-ID: <45F4CFDE.40704@qualcomm.com> Date: Sun, 11 Mar 2007 20:58:22 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Charles Clancy References: <45F4C767.1080803@cs.umd.edu> In-Reply-To: <45F4C767.1080803@cs.umd.edu> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: emu@ietf.org Subject: [Emu] On my suggestion to use CTR mode instead of CBC 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 ++++++ Issue: Use of CTR instead of CBC to avoid implementing AES decryption code (Dondeti) Resolution: no change -- we discussed this at length, CTR does its own integrity protection, which would be redundant, hence the decision to use CBC instead +++++ Charles, CTR mode encryption does not include integrity protection. There are what are known as combined modes, e.g., CCM, OCB, GCM, which use CTR mode for encryption. I am not talking about using CCM or something like that. I am proposing using CTR mode alone. thanks, Lakshminath Charles Clancy wrote: > All, > > We've put together an update to the GPSK draft to address the last call > comments. Below is a list of the identified issues and their solutions. > For a variety of issues we recommended no change with a brief > description. If more detail is desired, we can certainly discuss them > further on the list. > > You can find the latest version here, pending the I-D editor's release: > > http://www.tschofenig.com/svn/draft-clancy-emu-eap-gpsk/draft-ietf-emu-eap-gpsk-04.txt > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Mar 12 09:19:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQkQS-0003rV-Ji; Mon, 12 Mar 2007 09:18:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQkQR-0003r0-Eu for emu@ietf.org; Mon, 12 Mar 2007 09:18:55 -0400 Received: from rwcrmhc14.comcast.net ([204.127.192.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQkQP-00089C-8l for emu@ietf.org; Mon, 12 Mar 2007 09:18:55 -0400 Received: from [192.168.0.52] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (rwcrmhc14) with ESMTP id <20070312131851m1400ft2uue>; Mon, 12 Mar 2007 13:18:52 +0000 Message-ID: <45F553B6.8080906@cs.umd.edu> Date: Mon, 12 Mar 2007 08:20:54 -0500 From: Charles Clancy User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Lakshminath Dondeti References: <45F4C767.1080803@cs.umd.edu> <45F4CFDE.40704@qualcomm.com> In-Reply-To: <45F4CFDE.40704@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: emu@ietf.org Subject: [Emu] Re: On my suggestion to use CTR mode instead of CBC 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 > CTR mode encryption does not include integrity protection. There are > what are known as combined modes, e.g., CCM, OCB, GCM, which use CTR > mode for encryption. I am not talking about using CCM or something like > that. I have no objection to switching from CBC to CTR. Anyone else have an opinion? -- 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 Mar 12 12:48:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQngn-0006mk-RR; Mon, 12 Mar 2007 12:48:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQngn-0006mc-8a for emu@ietf.org; Mon, 12 Mar 2007 12:48:01 -0400 Received: from wr-out-0506.google.com ([64.233.184.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQngl-0000aR-73 for emu@ietf.org; Mon, 12 Mar 2007 12:48:01 -0400 Received: by wr-out-0506.google.com with SMTP id 68so2234448wra for ; Mon, 12 Mar 2007 09:47:58 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AJ3c5fBOVh4iT6TZwWLH4jE4wrjiUMf3iYMHz3TmvsU806ONDFAxiw38GorK4siFdOVc9lTOBHPkk/nGOV5qkPoXhgkXpQrM5driH4Dy5uw/I1Y8KGEuF5oGdQ8mYuig9VHyOT7OhIVh0UtvcrqkukPzLjzm0W5EQgHe5MiguGA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jZE47hKeWET5YB++WIPfGXVUMxftwnAGnHdOQokHP5jFkYsI3LJLWZlm/pBLJzPhobWMybrfuyUXoNBpNBMcyz0V64aYW2n2z9e2syTcC+d/nnQknfvDmmDB+VigPbTl4Ugs6sux+uO7MIXBya6308NR7AO9/wtctBycCsGENXQ= Received: by 10.90.100.2 with SMTP id x2mr4713636agb.1173718078748; Mon, 12 Mar 2007 09:47:58 -0700 (PDT) Received: by 10.90.117.6 with HTTP; Mon, 12 Mar 2007 09:47:58 -0700 (PDT) Message-ID: Date: Mon, 12 Mar 2007 09:47:58 -0700 From: "Clint Chaplin" To: "Charles Clancy" Subject: Re: [Emu] Re: On my suggestion to use CTR mode instead of CBC In-Reply-To: <45F553B6.8080906@cs.umd.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45F4C767.1080803@cs.umd.edu> <45F4CFDE.40704@qualcomm.com> <45F553B6.8080906@cs.umd.edu> 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 What does NIST (FIPS) have to say? On 3/12/07, Charles Clancy wrote: > > CTR mode encryption does not include integrity protection. There are > > what are known as combined modes, e.g., CCM, OCB, GCM, which use CTR > > mode for encryption. I am not talking about using CCM or something like > > that. > > I have no objection to switching from CBC to CTR. Anyone else have an > opinion? > > -- > 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 > -- Clint (JOATMON) Chaplin Principal Engineer Corporate Standardization (US) SISA _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Mar 12 13:53:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQohc-0004b7-U7; Mon, 12 Mar 2007 13:52:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQohc-0004Z9-GA for emu@ietf.org; Mon, 12 Mar 2007 13:52:56 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQohZ-0001zu-Gw for emu@ietf.org; Mon, 12 Mar 2007 13:52:56 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 12 Mar 2007 10:52:51 -0700 X-IronPort-AV: i="4.14,275,1170662400"; d="scan'208"; a="120382036:sNHT43752915" 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/8.12.11) with ESMTP id l2CHqpTT005707; Mon, 12 Mar 2007 10:52:51 -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 l2CHqfeH005133; Mon, 12 Mar 2007 17:52:51 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 10:52: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] Re: On my suggestion to use CTR mode instead of CBC Date: Mon, 12 Mar 2007 10:52:48 -0700 Message-ID: In-Reply-To: <45F553B6.8080906@cs.umd.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Re: On my suggestion to use CTR mode instead of CBC Thread-Index: AcdkqQohQMwCXJtZRMmTydfNypN42gAJf8BQ From: "Joseph Salowey \(jsalowey\)" To: "Charles Clancy" , "Lakshminath Dondeti" X-OriginalArrivalTime: 12 Mar 2007 17:52:50.0617 (UTC) FILETIME=[407B2A90:01C764CF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=969; t=1173721971; x=1174585971; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20Re=3A=20On=20my=20suggestion=20to=20use=20CTR =20mode=20instead=20of=20CBC |Sender:=20; bh=o0UCsgDOYyBk17c4bI2HjzSGZCKW03fwtFY2+622EhU=; b=j6U+b/vMEHrfMnCQZg/fPa4YQtU2nztoTCKsfov2YPEgTKqvXAeinUbFMbdE13VNciKtkKPn pKjssikkPHwmPD4AUmpnuh8M2o/3UNYmWf6fVSVbF/xXm9IgoImAX/DR; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 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 We discussed using CBC mode because it was slightly simpler than CTR mode. What is the significant advantage you see with CTR mode? =20 Joe > -----Original Message----- > From: Charles Clancy [mailto:clancy@cs.umd.edu]=20 > Sent: Monday, March 12, 2007 6:21 AM > To: Lakshminath Dondeti > Cc: emu@ietf.org > Subject: [Emu] Re: On my suggestion to use CTR mode instead of CBC >=20 > > CTR mode encryption does not include integrity protection.=20 > There are > what are known as combined modes, e.g., CCM,=20 > OCB, GCM, which use CTR > mode for encryption. I am not=20 > talking about using CCM or something like > that. >=20 > I have no objection to switching from CBC to CTR. Anyone=20 > else have an opinion? >=20 > -- > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Mar 12 13:59:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQooC-0002It-Nx; Mon, 12 Mar 2007 13:59:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQooB-0002Ig-Kh for emu@ietf.org; Mon, 12 Mar 2007 13:59:43 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQoo8-000382-RA for emu@ietf.org; Mon, 12 Mar 2007 13:59:43 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l2CHxVjB005962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Mar 2007 10:59:32 -0700 Received: from [129.46.78.141] (ldondeti.na.qualcomm.com [129.46.78.141]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l2CHxUhC022962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Mar 2007 10:59:31 -0700 (PDT) Message-ID: <45F594B9.4000702@qualcomm.com> Date: Mon, 12 Mar 2007 10:58:17 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" Subject: Re: [Emu] Re: On my suggestion to use CTR mode instead of CBC References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Joseph Salowey (jsalowey) wrote: > We discussed using CBC mode because it was slightly simpler than CTR > mode. What is the significant advantage you see with CTR mode? CTR mode as the encryption algorithm and AES_CMAC_128 as the integrity algorithm requires the implementation of the forward operation of the cipher only. I missed the part about CBC being simpler (btw, I have nothing against CBC :) ). Could you refresh my memory? Thanks. regards, Lakshminath > > Joe > >> -----Original Message----- >> From: Charles Clancy [mailto:clancy@cs.umd.edu] >> Sent: Monday, March 12, 2007 6:21 AM >> To: Lakshminath Dondeti >> Cc: emu@ietf.org >> Subject: [Emu] Re: On my suggestion to use CTR mode instead of CBC >> >> > CTR mode encryption does not include integrity protection. >> There are > what are known as combined modes, e.g., CCM, >> OCB, GCM, which use CTR > mode for encryption. I am not >> talking about using CCM or something like > that. >> >> I have no objection to switching from CBC to CTR. Anyone >> else have an opinion? >> >> -- >> 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 >> > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Mar 12 14:13:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQp18-00072e-Lk; Mon, 12 Mar 2007 14:13:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQp16-00072Y-Tx for emu@ietf.org; Mon, 12 Mar 2007 14:13:04 -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 1HQp14-0004hJ-8Q for emu@ietf.org; Mon, 12 Mar 2007 14:13:04 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 12 Mar 2007 11:13:02 -0700 X-IronPort-AV: i="4.14,275,1170662400"; d="scan'208"; a="766273714:sNHT54693218" 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/8.12.11) with ESMTP id l2CID1dH024922; Mon, 12 Mar 2007 11:13:01 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2CID01X023086; Mon, 12 Mar 2007 18:13:01 GMT 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, 12 Mar 2007 11:12:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] Re: On my suggestion to use CTR mode instead of CBC Date: Mon, 12 Mar 2007 11:12:56 -0700 Message-ID: In-Reply-To: <45F594B9.4000702@qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Re: On my suggestion to use CTR mode instead of CBC Thread-Index: Acdk0DJbaRZf5/++QkKwPg855N9yEQAAS5NA From: "Joseph Salowey \(jsalowey\)" To: "Lakshminath Dondeti" X-OriginalArrivalTime: 12 Mar 2007 18:12:58.0328 (UTC) FILETIME=[10553D80:01C764D2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2011; t=1173723181; x=1174587181; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20Re=3A=20On=20my=20suggestion=20to=20use=20CTR =20mode=20instead=20of=20CBC |Sender:=20; bh=FHiO5qCg28TaWYQn8MwaHL8UxaqElXRirmzjJdw8HbA=; b=d72yJZssdACSgufXUJC9SgrpNhONsUGLTgv20KNYNsxhXlheFStYxEyk/in07uoAiR3cg5cJ kzhK+gPzvXFGDvu883cQDW9yr/detgQ7trdTFYtitOfCUkQeY0O8wfpqh7B/LRgrQCgAJRBYNz mAEB+gU8ZGKYkgdmECuM+sgZE=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org =20 > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20 > Sent: Monday, March 12, 2007 10:58 AM > To: Joseph Salowey (jsalowey) > Cc: Charles Clancy; emu@ietf.org > Subject: Re: [Emu] Re: On my suggestion to use CTR mode instead of CBC >=20 > Joseph Salowey (jsalowey) wrote: > > We discussed using CBC mode because it was slightly simpler=20 > than CTR=20 > > mode. What is the significant advantage you see with CTR mode? >=20 > CTR mode as the encryption algorithm and AES_CMAC_128 as the=20 > integrity algorithm requires the implementation of the=20 > forward operation of the cipher only. >=20 [Joe] Would this make the implementation more compact? =20 > I missed the part about CBC being simpler (btw, I have=20 > nothing against CBC :) ). Could you refresh my memory? Thanks. >=20 [Joe] Most implementers are fairly familiar with CBC and its use, many libraries are available for it. CTR is a less familiar, which can result in difficulties in counter management. =20 > regards, > Lakshminath >=20 > >=20 > > Joe > >=20 > >> -----Original Message----- > >> From: Charles Clancy [mailto:clancy@cs.umd.edu] > >> Sent: Monday, March 12, 2007 6:21 AM > >> To: Lakshminath Dondeti > >> Cc: emu@ietf.org > >> Subject: [Emu] Re: On my suggestion to use CTR mode instead of CBC > >> > >> > CTR mode encryption does not include integrity protection.=20 > >> There are > what are known as combined modes, e.g., CCM,=20 > OCB, GCM,=20 > >> which use CTR > mode for encryption. I am not talking=20 > about using=20 > >> CCM or something like > that. > >> > >> I have no objection to switching from CBC to CTR. Anyone=20 > else have=20 > >> an opinion? > >> > >> -- > >> 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 > >> > >=20 >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Mar 12 14:20:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQp8B-0001FO-L5; Mon, 12 Mar 2007 14:20:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQp8A-0001F5-Fe for emu@ietf.org; Mon, 12 Mar 2007 14:20:22 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQp88-00067m-Rj for emu@ietf.org; Mon, 12 Mar 2007 14:20:22 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l2CIKCA1009101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Mar 2007 11:20:13 -0700 Received: from [129.46.78.141] (ldondeti.na.qualcomm.com [129.46.78.141]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l2CIKBM4002969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Mar 2007 11:20:12 -0700 (PDT) Message-ID: <45F59992.5050106@qualcomm.com> Date: Mon, 12 Mar 2007 11:18:58 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" Subject: Re: [Emu] Re: On my suggestion to use CTR mode instead of CBC References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit 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 Joseph Salowey (jsalowey) wrote: > > >> -----Original Message----- >> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] >> Sent: Monday, March 12, 2007 10:58 AM >> To: Joseph Salowey (jsalowey) >> Cc: Charles Clancy; emu@ietf.org >> Subject: Re: [Emu] Re: On my suggestion to use CTR mode instead of CBC >> >> Joseph Salowey (jsalowey) wrote: >>> We discussed using CBC mode because it was slightly simpler >> than CTR >>> mode. What is the significant advantage you see with CTR mode? >> CTR mode as the encryption algorithm and AES_CMAC_128 as the >> integrity algorithm requires the implementation of the >> forward operation of the cipher only. >> > [Joe] Would this make the implementation more compact? Yep! > >> I missed the part about CBC being simpler (btw, I have >> nothing against CBC :) ). Could you refresh my memory? Thanks. >> > [Joe] Most implementers are fairly familiar with CBC and its use, many > libraries are available for it. CTR is a less familiar, which can > result in difficulties in counter management. CTR mode is common enough now :). Lakshminath > >> regards, >> Lakshminath >> >>> Joe >>> >>>> -----Original Message----- >>>> From: Charles Clancy [mailto:clancy@cs.umd.edu] >>>> Sent: Monday, March 12, 2007 6:21 AM >>>> To: Lakshminath Dondeti >>>> Cc: emu@ietf.org >>>> Subject: [Emu] Re: On my suggestion to use CTR mode instead of CBC >>>> >>>> > CTR mode encryption does not include integrity protection. >>>> There are > what are known as combined modes, e.g., CCM, >> OCB, GCM, >>>> which use CTR > mode for encryption. I am not talking >> about using >>>> CCM or something like > that. >>>> >>>> I have no objection to switching from CBC to CTR. Anyone >> else have >>>> an opinion? >>>> >>>> -- >>>> 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 >>>> > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Mar 12 17:25:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQs1P-0007hi-EL; Mon, 12 Mar 2007 17:25:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQs1N-0007hQ-VD for emu@ietf.org; Mon, 12 Mar 2007 17:25:33 -0400 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQs16-0004sb-5y for emu@ietf.org; Mon, 12 Mar 2007 17:25:33 -0400 Received: from [192.168.0.52] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (rwcrmhc11) with ESMTP id <20070312212511m11009nmiae>; Mon, 12 Mar 2007 21:25:15 +0000 Message-ID: <45F5C5AF.1060405@cs.umd.edu> Date: Mon, 12 Mar 2007 16:27:11 -0500 From: Charles Clancy User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Clint Chaplin Subject: Re: [Emu] Re: On my suggestion to use CTR mode instead of CBC References: <45F4C767.1080803@cs.umd.edu> <45F4CFDE.40704@qualcomm.com> <45F553B6.8080906@cs.umd.edu> 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: 97adf591118a232206bdb5a27b217034 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 FIPS 140-2 defers to SP 800-38a, which includes ECB, CBC, CFB, OFB, and CTR as allowable block cipher modes of operation. The only RFC specifying AES-CTR (that I can find) is 3686, which uses it with IPsec ESP. OpenSSL includes support. See AES_ctr128_encrypt(). -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Clint Chaplin wrote: > What does NIST (FIPS) have to say? > > On 3/12/07, Charles Clancy wrote: >> > CTR mode encryption does not include integrity protection. There are >> > what are known as combined modes, e.g., CCM, OCB, GCM, which use CTR >> > mode for encryption. I am not talking about using CCM or something >> like >> > that. >> >> I have no objection to switching from CBC to CTR. Anyone else have an >> opinion? >> >> -- >> 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 >> > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Mar 12 18:50:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQtLA-0002R4-40; Mon, 12 Mar 2007 18:50:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQtL8-0002Qd-NC; Mon, 12 Mar 2007 18:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQtL8-0001nt-BX; Mon, 12 Mar 2007 18:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 4E9E1328F3; Mon, 12 Mar 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HQtL8-000565-6z; Mon, 12 Mar 2007 18: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: Mon, 12 Mar 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: emu@ietf.org Subject: [Emu] I-D ACTION:draft-ietf-emu-eap-gpsk-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 : EAP Generalized Pre-Shared Key (EAP-GPSK) Author(s) : C. Clancy, H. Tschofenig Filename : draft-ietf-emu-eap-gpsk-04.txt Pages : 34 Date : 2007-3-12 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-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-ietf-emu-eap-gpsk-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-ietf-emu-eap-gpsk-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: <2007-3-12150639.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-emu-eap-gpsk-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-emu-eap-gpsk-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-12150639.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --NextPart-- From emu-bounces@ietf.org Mon Mar 12 19:26:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQtty-0008Q7-9Z; Mon, 12 Mar 2007 19:26:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQttw-0008Pm-SV for emu@ietf.org; Mon, 12 Mar 2007 19:26:00 -0400 Received: from rwcrmhc15.comcast.net ([216.148.227.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQtts-000338-HN for emu@ietf.org; Mon, 12 Mar 2007 19:26:00 -0400 Received: from [192.168.0.52] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (rwcrmhc15) with ESMTP id <20070312232553m15002bnvle>; Mon, 12 Mar 2007 23:25:53 +0000 Message-ID: <45F5F00A.5080106@cs.umd.edu> Date: Mon, 12 Mar 2007 19:27:54 -0500 From: Charles Clancy User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" , emu@ietf.org Subject: Re: [Emu] Re: On my suggestion to use CTR mode instead of CBC 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: b4a0a5f5992e2a4954405484e7717d8c 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 the code sizes for the different modes of operation are negligible, but the openssl implementation does indeed manage the counter. See: http://www.srcdoc.com/openssl_0.9.7g/aes__ctr_8c-source.html OpenSSL assumes the lower "num" bytes of the IV are used as the counter. Considering EAP's MTU is 1024, we could only ever have 64 AES blocks per packet. Use 1 byte of the IV for the counter, and the other 15 as the IV. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Joseph Salowey (jsalowey) wrote: > Does the library provide counter management or is that up to the > implementation? > >> -----Original Message----- >> From: Charles Clancy [mailto:clancy@cs.umd.edu] >> Sent: Monday, March 12, 2007 2:27 PM >> To: Clint Chaplin >> Cc: emu@ietf.org >> Subject: Re: [Emu] Re: On my suggestion to use CTR mode instead of CBC >> >> FIPS 140-2 defers to SP 800-38a, which includes ECB, CBC, >> CFB, OFB, and CTR as allowable block cipher modes of operation. >> >> The only RFC specifying AES-CTR (that I can find) is 3686, >> which uses it with IPsec ESP. >> >> OpenSSL includes support. See AES_ctr128_encrypt(). >> >> -- >> t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy >> >> Clint Chaplin wrote: >>> What does NIST (FIPS) have to say? >>> >>> On 3/12/07, Charles Clancy wrote: >>>> > CTR mode encryption does not include integrity >> protection. There >>>> are > what are known as combined modes, e.g., CCM, OCB, >> GCM, which >>>> use CTR > mode for encryption. I am not talking about >> using CCM or >>>> something like > that. >>>> >>>> I have no objection to switching from CBC to CTR. Anyone >> else have >>>> an opinion? >>>> >>>> -- >>>> 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 >>>> >>> >> _______________________________________________ >> 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 Mar 12 20:01:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQuSH-0006n2-Um; Mon, 12 Mar 2007 20:01:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQuSF-0006ds-AT for emu@ietf.org; Mon, 12 Mar 2007 20:01:27 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQuSC-0001VN-Ld for emu@ietf.org; Mon, 12 Mar 2007 20:01:27 -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 l2D01GVR017989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Mar 2007 17:01:16 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l2D01FY8032187; Mon, 12 Mar 2007 17:01:15 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 17:01:15 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] EAP-GPSK update Date: Mon, 12 Mar 2007 17:01:15 -0700 Message-ID: In-Reply-To: <45F4C767.1080803@cs.umd.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EAP-GPSK update Thread-Index: AcdkWRNbD5ffToSPQZuiXIYeZ9tYJQAeyteA References: <45F4C767.1080803@cs.umd.edu> From: "Narayanan, Vidya" To: "Charles Clancy" , X-OriginalArrivalTime: 13 Mar 2007 00:01:15.0311 (UTC) FILETIME=[B7E7CBF0:01C76502] X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 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 Charles, Thanks for the quick update of the draft. A few comments inline. =20 > -----Original Message----- > From: Charles Clancy [mailto:clancy@cs.umd.edu]=20 > Sent: Sunday, March 11, 2007 8:22 PM > To: emu@ietf.org > Subject: [Emu] EAP-GPSK update >=20 > All, >=20 > We've put together an update to the GPSK draft to address the=20 > last call comments. Below is a list of the identified issues=20 > and their solutions.=20 > For a variety of issues we recommended no change with a=20 > brief description. If more detail is desired, we can=20 > certainly discuss them further on the list. >=20 > You can find the latest version here, pending the I-D=20 > editor's release: >=20 > http://www.tschofenig.com/svn/draft-clancy-emu-eap-gpsk/draft- > ietf-emu-eap-gpsk-04.txt >=20 > -- > t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy >=20 >=20 > ----------- > TECHNICAL > ----------- >=20 > Issue: why not use EAP-TLS-PSK instead (narayanan) > Resolution: no change -- WG consensus was to do GPSK >=20 Well, I didn't really ask why not use EAP-TLS-PSK instead of GPSK :) I was asking if there could be an explanation of some design goal that really justified the use of GPSK over the other listed PSK-based methods. Invariably, when an enduser is trying to pick between GPSK and say, TLS-PSK, they're going to run through the relative advantages - all things being equal, TLS-PSK may be preferred for reasons like what Bernard was saying. But, my question is - are all things equal? The design goals listed in the draft led me to believe that all things are equal - but, I may be missing something.=20 > Issue: MAC does not cover the EAP or GPSK header (Dondeti, Narayanan) > Resolution: no change -- protecting the EAP header is pointless, since > the EAP engine would not be able to validate the=20 > MAC. The > GPSK header only includes an op-code, which can be > implicitly checked by validating the MAC on the=20 > rest of the > packet contents. >=20 This is not too clear to me. The TLS-suite of protocols seem to have taken the route of not integrity protecting the EAP header, while almost every other EAP method has included the EAP header into the MAC (cases in point: EAP-AKA, EAP-SIM, EAP-PAX, EAP-SAKE). There is not adequate information in those documents on why it is a good idea - perhaps someone here can elaborate?=20 Specifically in GPSK, the GPSK-Fail message seems to be the same in either direction (peer to server or vice-versa). The EAP code seems to be the only differentiating factor in it. If the EAP code is not integrity protected, an entity can simply reflect the message back. With GPSK-Fail, the effect of such reflection may be questionable, but, do we have other cases like this that I might have missed?=20 > Issue: use of SHA-1 (Aboba) > Resolution: switched AES ciphersuite to use SHA256 >=20 > Issue: KDFs do not appear compliant with=20 > draft-dange-nistkdf-01 (Aboba) > Resolution: no change, NIST reviewed our KDF, and the current one is > based specifically on their recommendations >=20 > Issue: Why doesn't the MK derviation use the PSK as it's keying input, > instead of all zeros? (Dondeti) > Resolution: no change -- The PSK can be of arbitrary length, and > therefore may not be the correct length to use as the KDF > input key. >=20 > Issue: revert to previous KDF based on MACs (Dondeti, Narayanan) > Resolution: no change -- the KDF changes from MAC to Hash were > proposed by NIST >=20 I couldn't find a discussion of this on the EMU list. Could you please provide a summary of the advantages of going with Hash?=20 > Issue: Use of CTR instead of CBC to avoid implementing AES decryption > code (Dondeti) > Resolution: no change -- we discussed this at length, CTR does its > own integrity protection, which would be redundant, hence > the decision to use CBC instead >=20 > Issue: dropping nonparsable packets is EAP behavior (Narayanan) > Resolution: changed to talk about parsing EAP-GPSK packets,=20 > rather than > EAP packets >=20 > Issue: derive keys individually rather than deriving a big block > and then split it up (Narayanan) > Resolution: no change -- places fewer restrictions on the KDF, and > guarantees cryptographic independence >=20 Hmmm.. I'm not sure I understand - as far as I can tell, the same level of cryptographic independence and the same kind of KDFs can be used in either approach. If anything, it seems like the current construction places some limitations on the KDFs, given the key and output length requirements. I don't think either approach is necessarily bad - so, this issue is more a matter of preference than anything.=20 Vidya > Issue: derivation of PK when not using an encryption Ciphersuite > (Narayanan) > Resolution: removed PK from hash ciphersuite discussion, added other > comments indicating it's lack of necessity for > non-encrypting ciphersuites >=20 >=20 > ----------- > EDITORIAL > ----------- >=20 > Issue: citing old drafts (Malinen) > Resolution: moot, as references were removed >=20 > Issue: s/needs to instantiated/needs to be instantiated/ (Malinen) > Resolution: text edited >=20 > Issue: discussion of other protocols and deficiencies (Aboba) > Resolution: section removed >=20 > Issue: quick availability as a design goal (Aboba) > Resolution: text edited >=20 > Issue: design goal s/Wide Applicability/Security Model/ (Aboba) > Resolution: text edited >=20 > Issue: efficiency design goal, mention round trips (Aboba) > Resolution: text edited >=20 > Issue: efficiency design goal, mention Privacy not supported (Aboba) > Resolution: no change -- privacy supported if AES ciphersuite is used >=20 > Issue: define peer/server/session-ID (Aboba) > Resolution: defined >=20 > Issue: ambiguous definition of KS with respect to hashes (Dondeti) > Resolution: removed ambiguous text >=20 > Issue: erronious references to multiple protected payload=20 > blocks (Dondeti) > Resolution: fixed some references -- others referred to them as plural > as you can have a total 3 in the entire protocol exchange >=20 > Issue: order of key definitions in terminology section (Dondeti) > Resolution: changed the order to be alphabetical -- not quite what was > proposed, but logical IMHO >=20 > Issue: precision of some of the protocol specification (Dondeti) > Resolution: made some minor edits >=20 > Issue: GPSK-4 is needed only as a filler, specify that (Dondeti) > Resolution: no change, GPSK-4 can contain a PD_Payload_Block >=20 > Issue: Text involving validation of keys after GPSK-4 (Dondeti) > Resolution: text revised >=20 > Issue: discussion of MACs in KDF section (Dondeti) > Resolution: text replaced >=20 > Issue: instead of length(Csuites_List) use NumberOf_CSuites to save > one byte (Dondeti) > Resolution: no change -- using a 2-byte length makes parsing code > consistent across all length-prefixed data blocks >=20 > Issue: EAP terminology renamed (Narayanan) > Resolution: s/client/peer/g >=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 Tue Mar 13 13:05:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRARW-0000S6-Kj; Tue, 13 Mar 2007 13:05:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRAQv-00089G-M6 for emu@ietf.org; Tue, 13 Mar 2007 13:05:09 -0400 Received: from bay0-omc2-s19.bay0.hotmail.com ([65.54.246.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRAOJ-0008L5-6F for emu@ietf.org; Tue, 13 Mar 2007 13:02:28 -0400 Received: from hotmail.com ([207.46.8.98]) by bay0-omc2-s19.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 13 Mar 2007 10:02:26 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 13 Mar 2007 10:02:26 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Tue, 13 Mar 2007 17:02:25 GMT X-Originating-IP: [24.16.66.58] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: jsalowey@cisco.com, clancy@cs.umd.edu, ldondeti@qualcomm.com Bcc: Subject: RE: [Emu] Re: On my suggestion to use CTR mode instead of CBC Date: Tue, 13 Mar 2007 09:02:25 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 13 Mar 2007 17:02:26.0301 (UTC) FILETIME=[6042EAD0:01C76591] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 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 CBC mode is much more widely available in libraries than CTR mode. RFC 3723 specified CTR mode and this was probably a mistake. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Mar 13 13:21:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRAhD-0000aA-HM; Tue, 13 Mar 2007 13:21:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRAhB-0000ZI-GH for emu@ietf.org; Tue, 13 Mar 2007 13:21:57 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRAhA-0004Bc-5o for emu@ietf.org; Tue, 13 Mar 2007 13:21:57 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l2DHLhMV003398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 13 Mar 2007 10:21:44 -0700 Received: from [129.46.78.141] (ldondeti.na.qualcomm.com [129.46.78.141]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l2DHLgEq011252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Mar 2007 10:21:43 -0700 (PDT) Message-ID: <45F6DDA1.7010209@qualcomm.com> Date: Tue, 13 Mar 2007 10:21:37 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [Emu] Re: On my suggestion to use CTR mode instead of CBC References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 wrote: > CBC mode is much more widely available in libraries than CTR mode. RFC > 3723 specified CTR mode and this was probably a mistake. > CBC of course has been in use for a long time; no dispute there. However, CTR mode has been the mode specified for network access in a lot of "new" wireless access networks, including 802.11, 802.16, and 3GPP2 link layers. I would contend that CTR mode is more suitable -- compared to CBC -- for high-speed encryption also :). Anyway, we are not discussing 3723 here. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Mar 18 09:24:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSvN1-0005VR-28; Sun, 18 Mar 2007 09:24:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSvMz-0005VM-4z for emu@ietf.org; Sun, 18 Mar 2007 09:24:21 -0400 Received: from mcfeely.cs.umd.edu ([128.8.128.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSvMx-0001wH-Tw for emu@ietf.org; Sun, 18 Mar 2007 09:24:21 -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 l2IDOHg5022193; Sun, 18 Mar 2007 09:24:17 -0400 Received: (from apache@localhost) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.11/Submit) id l2IDOHWo022191; Sun, 18 Mar 2007 09:24:17 -0400 X-Authentication-Warning: mcfeely.cs.umd.edu: apache set sender to clancy@cs.umd.edu using -f Received: from 81.19.44.226 (SquirrelMail authenticated user clancy) by webmail.cs.umd.edu with HTTP; Sun, 18 Mar 2007 09:24:17 -0400 (EDT) Message-ID: <11506.81.19.44.226.1174224257.squirrel@webmail.cs.umd.edu> In-Reply-To: References: <45F4C767.1080803@cs.umd.edu> Date: Sun, 18 Mar 2007 09:24:17 -0400 (EDT) Subject: RE: [Emu] EAP-GPSK update From: "Charles Clancy" To: "Narayanan, Vidya" 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: 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 On Mon, March 12, 2007 8:01 pm, Narayanan, Vidya wrote: > > Well, I didn't really ask why not use EAP-TLS-PSK instead of GPSK :) I > was asking if there could be an explanation of some design goal that > really justified the use of GPSK over the other listed PSK-based > methods. The design goals for EAP-GPSK are specified in the introduction. GPSK vs TLS-PSK isn't discussed, because it seems generally taboo to point out other protocols' shortcomings and claim your superiority in an RFC. I think TLS-PSK's man shortcoming is that it wasn't the direction indicated by the WG consensus. > But, my question is - are all things equal? The > design goals listed in the draft led me to believe that all things are > equal - but, I may be missing something. Probably more or less equal. Method implementers have indicated that GPSK is easier to implement. > Specifically in GPSK, the GPSK-Fail message seems to be the same in > either direction (peer to server or vice-versa). The EAP code seems to > be the only differentiating factor in it. If the EAP code is not > integrity protected, an entity can simply reflect the message back. With > GPSK-Fail, the effect of such reflection may be questionable, but, do we > have other cases like this that I might have missed? According to the draft, GPSK-Fail messages MUST be reflected, but only because EAP is a request/response protocol. The server's state machine doesn't change due to the response. >> Issue: revert to previous KDF based on MACs (Dondeti, Narayanan) >> Resolution: no change -- the KDF changes from MAC to Hash were >> proposed by NIST > > I couldn't find a discussion of this on the EMU list. Could you please > provide a summary of the advantages of going with Hash? I don't think there was a discussion. At the last IETF meeting Russ suggested we talk to NIST about our KDF. We did, they recommend changes, and the draft was updated to reflect those changes. The main advantage of going with a hash is that it's in line with NISTs new set of key derivation requirements, which use hashes rather than HMACs. I'd wager the security is probably identical. -- 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 Sun Mar 18 11:11:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSx2J-0002AK-W1; Sun, 18 Mar 2007 11:11:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSx2I-00028A-QF for emu@ietf.org; Sun, 18 Mar 2007 11:11:06 -0400 Received: from mail1.sea5.speakeasy.net ([69.17.117.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSx2H-0006Vn-El for emu@ietf.org; Sun, 18 Mar 2007 11:11:06 -0400 Received: (qmail 15093 invoked from network); 18 Mar 2007 15:10:58 -0000 Received: from dsl017-049-110.sfo4.dsl.speakeasy.net (HELO jm) ([69.17.49.110]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 18 Mar 2007 15:10:58 -0000 Received: by jm (sSMTP sendmail emulation); Sun, 18 Mar 2007 08:10:57 -0700 Date: Sun, 18 Mar 2007 08:10:57 -0700 From: Jouni Malinen To: Charles Clancy Subject: Re: [Emu] EAP-GPSK update Message-ID: <20070318151056.GA5358@jm.kir.nu> References: <45F4C767.1080803@cs.umd.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45F4C767.1080803@cs.umd.edu> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Sun, Mar 11, 2007 at 11:22:15PM -0400, Charles Clancy wrote: > We've put together an update to the GPSK draft to address the last call > comments. Below is a list of the identified issues and their solutions. > Issue: use of SHA-1 (Aboba) > Resolution: switched AES ciphersuite to use SHA256 While I understand the desire not to use SHA-1, use of SHA256 with AES ciphersuite is somewhat unfortunate due to the added requirement for a new crypto primitive. Would you be willing to consider using AES-128-CMAC here instead? That would make ciphersuite #1 depend only on AES-based constructions and SHA256 would only be used for ciphersuite #2 (which is optional). PS. With PK derivation removed from 6.2.3, there is no need for the last 32 octets of GKDF-192(MK, inputString) data and GDF-192 could be replaced with GKDF-160 here. Since the requested length of the GDFK output is not mixed into the Hash-Function input (should it?), this does not change the derived keys, but is just a cleanup and small speed improvement (drop one SHA256 operation). -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Mar 18 13:24:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSz7H-0000AI-4O; Sun, 18 Mar 2007 13:24:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSz7F-00006V-KJ for emu@ietf.org; Sun, 18 Mar 2007 13:24:21 -0400 Received: from mcfeely.cs.umd.edu ([128.8.128.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSz7E-0007Y7-DK for emu@ietf.org; Sun, 18 Mar 2007 13:24:21 -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 l2IHOKqZ014777; Sun, 18 Mar 2007 13:24:20 -0400 Received: (from apache@localhost) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.11/Submit) id l2IHOK1L014775; Sun, 18 Mar 2007 13:24:20 -0400 X-Authentication-Warning: mcfeely.cs.umd.edu: apache set sender to clancy@cs.umd.edu using -f Received: from 81.19.44.226 (SquirrelMail authenticated user clancy) by webmail.cs.umd.edu with HTTP; Sun, 18 Mar 2007 13:24:20 -0400 (EDT) Message-ID: <7206.81.19.44.226.1174238660.squirrel@webmail.cs.umd.edu> In-Reply-To: <20070318151056.GA5358@jm.kir.nu> References: <45F4C767.1080803@cs.umd.edu> <20070318151056.GA5358@jm.kir.nu> Date: Sun, 18 Mar 2007 13:24:20 -0400 (EDT) Subject: Re: [Emu] EAP-GPSK update 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: bb8f917bb6b8da28fc948aeffb74aa17 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 The problem is that the new KDF construction uses hashes instead of MACs. -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy On Sun, March 18, 2007 11:10 am, Jouni Malinen wrote: > On Sun, Mar 11, 2007 at 11:22:15PM -0400, Charles Clancy wrote: > >> We've put together an update to the GPSK draft to address the last call >> comments. Below is a list of the identified issues and their solutions. > >> Issue: use of SHA-1 (Aboba) >> Resolution: switched AES ciphersuite to use SHA256 > > While I understand the desire not to use SHA-1, use of SHA256 with AES > ciphersuite is somewhat unfortunate due to the added requirement for a > new crypto primitive. Would you be willing to consider using > AES-128-CMAC here instead? That would make ciphersuite #1 depend only on > AES-based constructions and SHA256 would only be used for ciphersuite > #2 (which is optional). > > > PS. > > With PK derivation removed from 6.2.3, there is no need for the last 32 > octets of GKDF-192(MK, inputString) data and GDF-192 could be replaced > with GKDF-160 here. Since the requested length of the GDFK output is not > mixed into the Hash-Function input (should it?), this does not change > the derived keys, but is just a cleanup and small speed improvement > (drop one SHA256 operation). > > -- > Jouni Malinen PGP id EFC895FA > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Mar 18 13:53:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSzYZ-0006U7-Ph; Sun, 18 Mar 2007 13:52:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSzYY-0006Tu-AX for emu@ietf.org; Sun, 18 Mar 2007 13:52:34 -0400 Received: from mail4.sea5.speakeasy.net ([69.17.117.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSzYV-0002jj-Oy for emu@ietf.org; Sun, 18 Mar 2007 13:52:34 -0400 Received: (qmail 28511 invoked from network); 18 Mar 2007 17:52:26 -0000 Received: from dsl017-049-110.sfo4.dsl.speakeasy.net (HELO jm) ([69.17.49.110]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 18 Mar 2007 17:52:26 -0000 Received: by jm (sSMTP sendmail emulation); Sun, 18 Mar 2007 10:52:25 -0700 Date: Sun, 18 Mar 2007 10:52:25 -0700 From: Jouni Malinen To: Charles Clancy Subject: Re: [Emu] EAP-GPSK update Message-ID: <20070318175225.GO5358@jm.kir.nu> References: <45F4C767.1080803@cs.umd.edu> <20070318151056.GA5358@jm.kir.nu> <7206.81.19.44.226.1174238660.squirrel@webmail.cs.umd.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7206.81.19.44.226.1174238660.squirrel@webmail.cs.umd.edu> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Sun, Mar 18, 2007 at 01:24:20PM -0400, Charles Clancy wrote: > The problem is that the new KDF construction uses hashes instead of MACs. Would use of CMAC with zero-key be acceptable to generate a hash function for a KDF? Is there any publicly available document describing why hashes should be used instead of MACs? I've only seen a comment saying that this is because NIST says so for this particular construction, but I have not seen any more details. Getting more details on this would be interesting for other reasons, too, since there are new designs (e.g., IEEE 802.11r) which are using HMAC-SHA256 -based KDF. Since the 802.11r KDF construction is also claimed to be compliant to NIST recommendations, it is somewhat odd to see EAP-GPSK take the other direction with the reasoning that this came from NIST.. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Mar 18 18:01:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT3R1-0001Bp-2H; Sun, 18 Mar 2007 18:01:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT3R0-0001Bh-5E for emu@ietf.org; Sun, 18 Mar 2007 18:01:02 -0400 Received: from mcfeely.cs.umd.edu ([128.8.128.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HT3Qy-0001QU-Tj for emu@ietf.org; Sun, 18 Mar 2007 18:01:02 -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 l2IM0wEp009470; Sun, 18 Mar 2007 18:00:58 -0400 Received: (from apache@localhost) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.11/Submit) id l2IM0wku009468; Sun, 18 Mar 2007 18:00:58 -0400 X-Authentication-Warning: mcfeely.cs.umd.edu: apache set sender to clancy@cs.umd.edu using -f Received: from 81.19.44.226 (SquirrelMail authenticated user clancy) by webmail.cs.umd.edu with HTTP; Sun, 18 Mar 2007 18:00:58 -0400 (EDT) Message-ID: <19016.81.19.44.226.1174255258.squirrel@webmail.cs.umd.edu> In-Reply-To: <20070318175225.GO5358@jm.kir.nu> References: <45F4C767.1080803@cs.umd.edu> <20070318151056.GA5358@jm.kir.nu> <7206.81.19.44.226.1174238660.squirrel@webmail.cs.umd.edu> <20070318175225.GO5358@jm.kir.nu> Date: Sun, 18 Mar 2007 18:00:58 -0400 (EDT) Subject: Re: [Emu] EAP-GPSK update 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: b19722fc8d3865b147c75ae2495625f2 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 The problem with using a known key is that the function is invertable. The KDF doesn't work unless you can't invert it. See: http://tools.ietf.org/html/draft-dang-nistkdf Sounds like we should talk to our new A-D, since he's a coauthor on the document from NIST. -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy On Sun, March 18, 2007 1:52 pm, Jouni Malinen wrote: > On Sun, Mar 18, 2007 at 01:24:20PM -0400, Charles Clancy wrote: >> The problem is that the new KDF construction uses hashes instead of >> MACs. > > Would use of CMAC with zero-key be acceptable to generate a hash > function for a KDF? Is there any publicly available document describing > why hashes should be used instead of MACs? I've only seen a comment > saying that this is because NIST says so for this particular > construction, but I have not seen any more details. > > Getting more details on this would be interesting for other reasons, > too, since there are new designs (e.g., IEEE 802.11r) which are using > HMAC-SHA256 -based KDF. Since the 802.11r KDF construction is also > claimed to be compliant to NIST recommendations, it is somewhat odd to > see EAP-GPSK take the other direction with the reasoning that this came > from NIST.. > > -- > Jouni Malinen PGP id EFC895FA > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Mar 19 05:01:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTDjs-00087B-Br; Mon, 19 Mar 2007 05:01:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTDjr-00086y-JO for emu@ietf.org; Mon, 19 Mar 2007 05:01:11 -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 1HTDjq-0004PN-Av for emu@ietf.org; Mon, 19 Mar 2007 05:01:11 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 19 Mar 2007 02:01:10 -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/8.12.11) with ESMTP id l2J919Kg014181 for ; Mon, 19 Mar 2007 02:01:09 -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 l2J919MF013021 for ; Mon, 19 Mar 2007 09:01:09 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 02:01:09 -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, 19 Mar 2007 02:01:04 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Presentations for EMU Thread-Index: AcdqBR/wb9uxTmwYRiuEqD3y+lOmbg== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 19 Mar 2007 09:01:09.0555 (UTC) FILETIME=[22DBA830:01C76A05] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=86; t=1174294869; x=1175158869; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20Presentations=20for=20EMU |Sender:=20; bh=5Ep+uWc2SRLViiq1nkvtxWcwpAHqb9wBNQ/1RvAbBCI=; b=NzKpmIDMMHOZWIaRmdNAjq5xRa23oIy02A1oEQsKFdJmeq59zAapCChwhIVGTiyg+WliuZ+m TjusIX+TWVKIPit15OwFayJTMBrnzSWuSRrSRdQtJYNhTt3U0l+MRE6v; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [Emu] Presentations for EMU 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 presentations for EMU agenda items this morning.=20 Thanks, Joe _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Mar 19 05:21:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTE3a-0004l8-Rm; Mon, 19 Mar 2007 05:21:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTE3Z-0004ky-L0 for emu@ietf.org; Mon, 19 Mar 2007 05:21:33 -0400 Received: from bay0-omc1-s2.bay0.hotmail.com ([65.54.246.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTE3Y-0006qr-C6 for emu@ietf.org; Mon, 19 Mar 2007 05:21:33 -0400 Received: from hotmail.com ([207.46.8.103]) by bay0-omc1-s2.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 19 Mar 2007 02:21:31 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 19 Mar 2007 02:21:31 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Mon, 19 Mar 2007 09:21:29 GMT X-Originating-IP: [130.129.64.9] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <20070318175225.GO5358@jm.kir.nu> From: "Bernard Aboba" To: j@w1.fi, clancy@cs.umd.edu Bcc: Subject: Re: [Emu] EAP-GPSK update Date: Mon, 19 Mar 2007 02:21:29 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 19 Mar 2007 09:21:31.0733 (UTC) FILETIME=[FB553850:01C76A07] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 >Getting more details on this would be interesting for other reasons, >too, since there are new designs (e.g., IEEE 802.11r) which are using >HMAC-SHA256 -based KDF. Since the 802.11r KDF construction is also >claimed to be compliant to NIST recommendations, it is somewhat odd to >see EAP-GPSK take the other direction with the reasoning that this came >from NIST.. I agree that the KDF usage in EAP-GPSK does not seem to be consistent with other standards that also claim NIST KDF compliance. Maybe we should ask Tim Polk to attend the EMU WG meeting so we can ask him to explain this to us :) _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Mar 19 13:47:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLwn-0000qI-OZ; Mon, 19 Mar 2007 13:47:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLwm-0000q9-Im for emu@ietf.org; Mon, 19 Mar 2007 13:47:04 -0400 Received: from mcfeely.cs.umd.edu ([128.8.128.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTLwf-0000Dm-EG for emu@ietf.org; Mon, 19 Mar 2007 13:47:04 -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 l2JHkvvY010414 for ; Mon, 19 Mar 2007 13:46:57 -0400 Received: (from apache@localhost) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.11/Submit) id l2JHkqe3010412; Mon, 19 Mar 2007 13:46:52 -0400 X-Authentication-Warning: mcfeely.cs.umd.edu: apache set sender to clancy@cs.umd.edu using -f Received: from 130.129.19.126 (SquirrelMail authenticated user clancy) by webmail.cs.umd.edu with HTTP; Mon, 19 Mar 2007 13:46:52 -0400 (EDT) Message-ID: <32790.130.129.19.126.1174326412.squirrel@webmail.cs.umd.edu> Date: Mon, 19 Mar 2007 13:46:52 -0400 (EDT) From: "Charles Clancy" To: emu@ietf.org 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: 08e48e05374109708c00c6208b534009 Subject: [Emu] AES CBC vs CTR 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 reference, in OpenSSL 0.9.8 on a Pentium M, AES-CBC requires roughly 18 Kb and AES-CTR requires 8 Kb. The CTR mode is half the size of CBC, and only requires half the AES core code (i.e. not the decryption). -- 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 Tue Mar 27 11:07:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWDGe-0006Tw-Pp; Tue, 27 Mar 2007 11:07:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWDGe-0006Tq-6W for emu@ietf.org; Tue, 27 Mar 2007 11:07:24 -0400 Received: from bay0-omc3-s38.bay0.hotmail.com ([65.54.246.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWDGb-0001E7-SA for emu@ietf.org; Tue, 27 Mar 2007 11:07:24 -0400 Received: from hotmail.com ([207.46.8.106]) by bay0-omc3-s38.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 27 Mar 2007 08:07:21 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 27 Mar 2007 08:07:21 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Tue, 27 Mar 2007 15:07:19 GMT X-Originating-IP: [71.222.95.241] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: emu@ietf.org Bcc: Date: Tue, 27 Mar 2007 08:07:19 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 27 Mar 2007 15:07:21.0279 (UTC) FILETIME=[9E54ACF0:01C77081] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Emu] Thoughts on Password-based EAP Methods 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 After listening to the IETF 68 presentation on a password-based EAP method, I would like to voice some concerns. Today we already have an "over abundance" of such methods. These include PEAPv0, PEAPv1, EAP-TTLSv0, EAP-TTLSv1, and EAP-FAST. In my discussions with customers, I invariably hear complaints about this explosion, and about various interoperability and compatibility problems that it causes. Simply put, customers do not want "yet another password-based EAP method"; they want a single method that is widely implemented and interoperable. I am concerned that by defining yet another password-based authentication mechanism, EMU WG will be making this problem worse, not better. Creating yet another mechanism which differs little from the existing ones also seems to have very little chance of being implemented. There is a better alternative that EMU WG should consider. This is to choose an existing method for inclusion on the IETF Standards Track, rather than creating a new one. In order to maintain backward compatibility, this would require that the owners give up change control to the IETF. I would suggest that the best candidate for this would be EAP-TTLSv0, since it is very widely implemented, and has an existing certification program in WFA. Also, EAP-TTLSv0 had previously been on the Standards Track in the PPPEXT WG, before work on EAP methods was removed from the PPPEXT WG charter and the EAP WG was formed. In terms of steps to be taken, this would require the following actions: a. Review and publication of the existing EAP-TTLSv0 specification as an RFC. The goal here would be to document EAP-TTLSv0 as it exists today. b. Agreement by the authors to give up change control to the IETF. c. EMU WG efforts to publish an EAP-TTLSv0 "bis" document, specifying additional capabilities (such as Channel Bindings). _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Mar 28 16:40:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWew6-0001qL-1f; Wed, 28 Mar 2007 16:40:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWew2-0001p8-H8 for emu@ietf.org; Wed, 28 Mar 2007 16:39:58 -0400 Received: from bay0-omc2-s21.bay0.hotmail.com ([65.54.246.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWevt-00046w-I7 for emu@ietf.org; Wed, 28 Mar 2007 16:39:58 -0400 Received: from hotmail.com ([207.46.8.82]) by bay0-omc2-s21.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 28 Mar 2007 13:39:49 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 28 Mar 2007 13:39:48 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Wed, 28 Mar 2007 20:39:43 GMT X-Originating-IP: [71.222.95.241] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: emu@ietf.org Bcc: Date: Wed, 28 Mar 2007 13:39:43 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 28 Mar 2007 20:39:48.0925 (UTC) FILETIME=[3A77A6D0:01C77179] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Emu] Re: Thoughts on Password-based EAP Methods 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 latest EAP-TTLSv0 draft is available here: http://www.watersprings.org/pub/id/draft-funk-eap-ttls-v0-00.txt In terms of publication interest, back in the fall Jari Arkko had announced a program to encourage widely implemented EAP methods to publish their specifications as RFCs. As I recall, there was interest to publish EAP-FAST (in the RFC Editor queue), PEAPv0 (documentation currently being revised for submission as an Internet Draft). I don't know the current status of the EAP-TTLSv0 publication effort (e.g. whether publication has been requested or not). Steve Hanna might know. In terms of history, EAP-TTLSv0 was accepted as a Standards Track work item of the PPPEXT WG prior to the formation of the EAP WG. It has been implemented on a wide variety of platforms including open source versions for Windows (http://www.securew2.com/) and Linux (http://open1x.sourceforge.net/). Interoperability of EAP-TTLSv0 implementations is currently certified by the WFA. In terms of features that would be needed to meet EMU WG requirements, I think we are probably talking about crypto-binding and channel binding. It is possible that there may be other features needed for some scenarios (e.g. mutual certificate authentication for a device/machine plus user auth for scenarios currently discussed within WiMAX Forum and 3GPP2). _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Mar 28 17:33:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWflz-0003c2-PD; Wed, 28 Mar 2007 17:33:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWflx-0003Tr-Jb for emu@ietf.org; Wed, 28 Mar 2007 17:33:37 -0400 Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWfl1-0007Os-0F for emu@ietf.org; Wed, 28 Mar 2007 17:32:46 -0400 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 28 Mar 2007 14:32:38 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) with Microsoft SMTP Server id 8.0.685.25; Wed, 28 Mar 2007 14:32:38 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.26]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Wed, 28 Mar 2007 14:32:37 -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] Re: Thoughts on Password-based EAP Methods Date: Wed, 28 Mar 2007 14:31:59 -0700 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004A51590@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Re: Thoughts on Password-based EAP Methods Thread-Index: Acdxe8rGGmWEtgdLS7ueMADjneLpAgABGhNw References: From: Ryan Hurst To: Bernard Aboba , X-OriginalArrivalTime: 28 Mar 2007 21:32:38.0034 (UTC) FILETIME=[9B674F20:01C77180] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Stephen Hanna 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 not seen Steve on this list (though he might be), so I have added him to this thread. I have looked at TTLS and think it's a good method, I would be interested in supporting participating in work to address the outlined short comings if such a project were to be kicked off by Juniper in the EMU group :) Ryan -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Wednesday, March 28, 2007 1:40 PM To: emu@ietf.org Subject: [Emu] Re: Thoughts on Password-based EAP Methods The latest EAP-TTLSv0 draft is available here: http://www.watersprings.org/pub/id/draft-funk-eap-ttls-v0-00.txt In terms of publication interest, back in the fall Jari Arkko had announced=20 a program to encourage widely implemented EAP methods to publish their=20 specifications as RFCs. As I recall, there was interest to publish=20 EAP-FAST (in the RFC Editor queue), PEAPv0 (documentation currently being=20 revised for submission as an Internet Draft). I don't know the current status of the EAP-TTLSv0 publication effort (e.g. whether publication has=20 been requested or not). Steve Hanna might know. In terms of history, EAP-TTLSv0 was accepted as a Standards Track work item=20 of the PPPEXT WG prior to the formation of the EAP WG. It has been=20 implemented on a wide variety of platforms including open source versions=20 for Windows (http://www.securew2.com/) and Linux=20 (http://open1x.sourceforge.net/). Interoperability of EAP-TTLSv0=20 implementations is currently certified by the WFA. In terms of features that would be needed to meet EMU WG requirements, I think we are probably talking about crypto-binding and channel binding. It=20 is possible that there may be other features needed for some scenarios (e.g.=20 mutual certificate authentication for a device/machine plus user auth for=20 scenarios currently discussed within WiMAX Forum and 3GPP2). _______________________________________________ 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 Mar 28 17:58:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWgAQ-0003w5-8I; Wed, 28 Mar 2007 17:58:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWgAO-0003vc-Ed for emu@ietf.org; Wed, 28 Mar 2007 17:58:52 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWgAK-0007Bz-1r for emu@ietf.org; Wed, 28 Mar 2007 17:58:52 -0400 Received: by nf-out-0910.google.com with SMTP id l36so3821061nfa for ; Wed, 28 Mar 2007 14:58:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=CnBaMK6oJ07BWt8+PmMrHbsV8o8raY//V8MWIO1bMhnDs2dbTzuhZydHSsjSHczPZt/MzNwA1HQQuFvv3p6hnlIX+alZFs34IlasXtrbnm19iVhY7h4vqoftuCtcQXGWCsOqS+NFJfs7FMS9Pr1DQilpI9eBk+K30gzzuPZjo1Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=tolFe2+ES2mqu9WzghP9UH0IzAXOltdfTIWnwSD6ddIDP1gqm5tfF2GyvA9AF3iSbwt+jw1D3xuNUJFEx/DfU8tam3U/D7JAL0AP7addl3otHHzhIcMy8J2sJYXjl64TF59eZB4PtkGJGtMJfVLzx/DpUomOCvAjCA3d9R5J/fA= Received: by 10.78.178.5 with SMTP id a5mr4545040huf.1175119126557; Wed, 28 Mar 2007 14:58:46 -0700 (PDT) Received: by 10.78.37.12 with HTTP; Wed, 28 Mar 2007 14:58:46 -0700 (PDT) Message-ID: Date: Wed, 28 Mar 2007 23:58:46 +0200 From: Badra To: "Bernard Aboba" Subject: Re: [Emu] Re: Thoughts on Password-based EAP Methods In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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: , Content-Type: multipart/mixed; boundary="===============1325819036==" Errors-To: emu-bounces@ietf.org --===============1325819036== Content-Type: multipart/alternative; boundary="----=_Part_28809_15555860.1175119126470" ------=_Part_28809_15555860.1175119126470 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Does it need to recharter? Best regards, Badra On 3/28/07, Bernard Aboba wrote: > > The latest EAP-TTLSv0 draft is available here: > http://www.watersprings.org/pub/id/draft-funk-eap-ttls-v0-00.txt > > In terms of publication interest, back in the fall Jari Arkko had > announced > a program to encourage widely implemented EAP methods to publish their > specifications as RFCs. As I recall, there was interest to publish > EAP-FAST (in the RFC Editor queue), PEAPv0 (documentation currently being > revised for submission as an Internet Draft). I don't know the current > status of the EAP-TTLSv0 publication effort (e.g. whether publication has > been requested or not). Steve Hanna might know. > > In terms of history, EAP-TTLSv0 was accepted as a Standards Track work > item > of the PPPEXT WG prior to the formation of the EAP WG. It has been > implemented on a wide variety of platforms including open source versions > for Windows (http://www.securew2.com/) and Linux > (http://open1x.sourceforge.net/). Interoperability of EAP-TTLSv0 > implementations is currently certified by the WFA. > > In terms of features that would be needed to meet EMU WG requirements, I > think we are probably talking about crypto-binding and channel > binding. It > is possible that there may be other features needed for some scenarios ( > e.g. > mutual certificate authentication for a device/machine plus user auth for > scenarios currently discussed within WiMAX Forum and 3GPP2). ------=_Part_28809_15555860.1175119126470 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Does it need to recharter?
 
Best regards,
Badra

 
On 3/28/07, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
The latest EAP-TTLSv0 draft is available here:
http://www.watersprings.org/pub/id/draft-funk-eap-ttls-v0-00.txt

In terms of publication interest, back in the fall Jari Arkko had announced
a program to encourage widely implemented EAP methods to publish their
specifications  as RFCs.  As I recall, there was interest to publish
EAP-FAST (in the RFC Editor queue), PEAPv0 (documentation currently being
revised for submission as an Internet Draft).   I don't know the current
status of the EAP-TTLSv0 publication effort (e.g. whether publication has
been requested or not).   Steve Hanna might know.

In terms of history, EAP-TTLSv0 was accepted as a Standards Track work item
of the PPPEXT WG prior to the formation of the EAP WG.  It has been
implemented on a wide variety of platforms including open source versions
for Windows (http://www.securew2.com/) and Linux
(http://open1x.sourceforge.net/ ).  Interoperability of EAP-TTLSv0
implementations is currently certified by the WFA.

In terms of features that would be needed to meet EMU WG requirements, I
think we are probably talking about crypto-binding and channel binding.  It
is possible that there may be other features needed for some scenarios (e.g.
mutual certificate authentication for a device/machine plus user auth for
scenarios currently discussed within WiMAX Forum and 3GPP2).
------=_Part_28809_15555860.1175119126470-- --===============1325819036== 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 --===============1325819036==-- From emu-bounces@ietf.org Thu Mar 29 04:31:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWq2H-00022L-Px; Thu, 29 Mar 2007 04:31:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWq2G-00022D-L3 for emu@ietf.org; Thu, 29 Mar 2007 04:31:08 -0400 Received: from mailfe07.tele2.fr ([212.247.154.204] helo=swip.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWq2A-0006Wy-5b for emu@ietf.org; Thu, 29 Mar 2007 04:31:08 -0400 X-Cloudmark-Score: 0.000000 [] Received: from [137.194.3.106] (account eu968071@tele2.fr HELO VAIO.tele2.fr) by mailfe07.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 452068093; Thu, 29 Mar 2007 10:30:38 +0200 Message-Id: <7.0.0.16.0.20070329102758.01c93d68@tele2.fr> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 29 Mar 2007 10:30:35 +0200 To: "Bernard Aboba" ,emu@ietf.org From: Pascal Urien Subject: Re: [Emu] Re: Thoughts on Password-based EAP Methods 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: 50a516d93fd399dc60588708fd9a3002 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, Is there a patent about TTLS ? On the web i found this reference [0001] This application claims the benefit under 35 U.S.C. .sctn.119(e) to commonly-owned U.S. provisional patent application Ser. No. 60/430,398, entitled THE EAP-MD5 TUNNELED AUTHENTICATION PROTOCOL, filed on Dec. 3, 2002 under attorney docket no. F0232.70000US00, which is hereby incorporated by reference in its entirety. Pascal At 22:39 28/03/2007, Bernard Aboba wrote: >The latest EAP-TTLSv0 draft is available here: >http://www.watersprings.org/pub/id/draft-funk-eap-ttls-v0-00.txt > >In terms of publication interest, back in the fall Jari Arkko had >announced a program to encourage widely implemented EAP methods to >publish their specifications as RFCs. As I recall, there was >interest to publish EAP-FAST (in the RFC Editor queue), PEAPv0 >(documentation currently being revised for submission as an Internet >Draft). I don't know the current status of the EAP-TTLSv0 >publication effort (e.g. whether publication has been requested or >not). Steve Hanna might know. > >In terms of history, EAP-TTLSv0 was accepted as a Standards Track >work item of the PPPEXT WG prior to the formation of the EAP WG. It >has been implemented on a wide variety of platforms including open >source versions for Windows (http://www.securew2.com/) and Linux >(http://open1x.sourceforge.net/). Interoperability of EAP-TTLSv0 >implementations is currently certified by the WFA. > >In terms of features that would be needed to meet EMU WG >requirements, I think we are probably talking about crypto-binding >and channel binding. It is possible that there may be other >features needed for some scenarios (e.g. mutual certificate >authentication for a device/machine plus user auth for scenarios >currently discussed within WiMAX Forum and 3GPP2). > > > >_______________________________________________ >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 Mar 29 17:29:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX2At-0004Qx-TL; Thu, 29 Mar 2007 17:28:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX29Q-0003DD-Lk for emu@ietf.org; Thu, 29 Mar 2007 17:27:20 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX278-00065M-0e for emu@ietf.org; Thu, 29 Mar 2007 17:24:59 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 29 Mar 2007 17:24:58 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2TLOv81026213; Thu, 29 Mar 2007 17:24:57 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2TLOPlQ013396; Thu, 29 Mar 2007 21:24:57 GMT Received: from xmb-rtp-212.amer.cisco.com ([64.102.31.111]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 17:24:57 -0400 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] Thoughts on Password-based EAP Methods Date: Thu, 29 Mar 2007 17:24:54 -0400 Message-ID: <9958B444368E884DBB215F3FEF36F5B7041F9206@xmb-rtp-212.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Thoughts on Password-based EAP Methods Thread-Index: AcdwgbzySqNxsBtJTearLSfmJ3RQ5wBxBJuw References: From: "Hao Zhou \(hzhou\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 29 Mar 2007 21:24:57.0415 (UTC) FILETIME=[B3442D70:01C77248] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3861; t=1175203497; x=1176067497; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=hzhou@cisco.com; z=From:=20=22Hao=20Zhou=20\(hzhou\)=22=20 |Subject:=20RE=3A=20[Emu]=20Thoughts=20on=20Password-based=20EAP=20Method s |Sender:=20 |To:=20=22Bernard=20Aboba=22=20, =20; bh=WG+iIN1t/Py8Kvkt2RXgkEJ2JH+ezdD7p1Vov25DsJ0=; b=cYc7ryCtx7j80xw9Fen3dCpMkLF3YHxM9egYiWNhehbNruDNZGwocvyrkA9KWiBLS/eMDLFd mrybUmR8dlXy9PmvR1K8w+afADZHyCrZsqiHglsnmyRhQvxjiVkf6qoB; Authentication-Results: rtp-dkim-2; header.From=hzhou@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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: I am not sure reusing one of the existing EAP methods is the right approach. All three EAP method mentioned, EAP-TTLS/PEAP/EAP-FAST all has something that are outside the scope of the charter, which means we have to take some of them out. Not unitl we change the charter, then we can pick one of them and declare victory. Some (if not all) are also missing some features required, like crypto-agility, etc. This means we will change the existing protocol and make it not backward compatible. There will be the same issue with implementation whether a new EAP method or a modified EAP method. I think part of the benefits of defining a new standard EAP method, people will want to implement it, as opposed to implement according to some expired draft. The design team are aware of TTLS and is working towards something that will probably be similar and much simpler. We try to strive for something simple but extensible, then over time we can enhance it as it is in IETF control.=20 EAP-TTLS itself also has its own issues: =20 1. It's internal AVP uses Radius attribute, I am not sure that' a good idea. 2. There is also TTLSv1 draft, which is quite different than v0. I am not sure about there are actual implementations or not. But if we create another modified TTLS from TTLSv0, it might create confusions. 3. The patent issue mentioned by Pascal. > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Tuesday, March 27, 2007 11:07 AM > To: emu@ietf.org > Subject: [Emu] Thoughts on Password-based EAP Methods >=20 > After listening to the IETF 68 presentation on a=20 > password-based EAP method, I would like to voice some concerns. >=20 > Today we already have an "over abundance" of such methods. =20 > These include=20 > PEAPv0, PEAPv1, EAP-TTLSv0, EAP-TTLSv1, and EAP-FAST. In my=20 > discussions=20 > with customers, I invariably hear complaints about this=20 > explosion, and about various interoperability and=20 > compatibility problems that it causes. Simply put, customers=20 > do not want "yet another password-based EAP method"; they=20 > want a single method that is widely implemented and interoperable. >=20 > I am concerned that by defining yet another password-based=20 > authentication=20 > mechanism, EMU WG will be making this problem worse, not=20 > better. Creating=20 > yet another mechanism which differs little from the existing=20 > ones also seems to have very little chance of being implemented. >=20 > There is a better alternative that EMU WG should consider.=20 > This is to choose an existing method for inclusion on the=20 > IETF Standards Track, rather than creating a new one. In=20 > order to maintain backward compatibility, this would require=20 > that the owners give up change control to the IETF. >=20 > I would suggest that the best candidate for this would be=20 > EAP-TTLSv0, since it is very widely implemented, and has an=20 > existing certification program in=20 > WFA. Also, EAP-TTLSv0 had previously been on the Standards=20 > Track in the=20 > PPPEXT WG, before work on EAP methods was removed from the=20 > PPPEXT WG charter and the EAP WG was formed. >=20 > In terms of steps to be taken, this would require the=20 > following actions: >=20 > a. Review and publication of the existing EAP-TTLSv0=20 > specification as an RFC. The goal here would be to document=20 > EAP-TTLSv0 as it exists today. >=20 > b. Agreement by the authors to give up change control to the IETF. >=20 > c. EMU WG efforts to publish an EAP-TTLSv0 "bis" document,=20 > specifying additional capabilities (such as Channel Bindings). >=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