From emu-bounces@ietf.org Sun Jun 04 10:27:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmtZo-0008H3-A8; Sun, 04 Jun 2006 10:27:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmtZn-0008GQ-SC for emu@ietf.org; Sun, 04 Jun 2006 10:27:35 -0400 Received: from mailfe03.tele2.fr ([212.247.154.76] helo=swip.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmtZm-0000Yi-IZ for emu@ietf.org; Sun, 04 Jun 2006 10:27:35 -0400 X-T2-Posting-ID: TlrHmwDFCX01iQZd0Fm6v3T8FBlCqve5GwI1mWaefYU= X-Cloudmark-Score: 0.000000 [] Received: from [83.179.148.71] (HELO DELL.tele2.fr) by mailfe03.swip.net (CommuniGate Pro SMTP 5.0.8) with ESMTP id 214948269 for emu@ietf.org; Sun, 04 Jun 2006 16:27:33 +0200 Message-Id: <5.2.1.1.0.20060604162721.03ec3680@pop.tele2.fr> X-Sender: eu968071@pop.tele2.fr X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sun, 04 Jun 2006 16:27:31 +0200 To: emu@ietf.org From: Pascal Urien Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Emu] Identity Protection in EAP-TLS X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Everybody, A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Identity Protection within EAP-TLS Author(s) : P. Urien, M. Badra Filename : draft-urien-badra-eap-tls-identity-protection-00.txt Pages : 7 Date : 2006-5-31 This document defines a mechanism providing EAP-TLS identity protection. It defines new TLS extension, in order to negotiate the symmetric encryption algorithm that is used to encrypt or decrypt the client's certificate. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-urien-badra-eap-tls-identity-protection-00.txt Pascal _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Jun 04 12:06:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmv7V-00011d-Qb; Sun, 04 Jun 2006 12:06:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmv7V-00011V-B9 for emu@ietf.org; Sun, 04 Jun 2006 12:06:29 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fmv7U-0002ew-4w for emu@ietf.org; Sun, 04 Jun 2006 12:06:29 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 44E2FE000C; Sun, 4 Jun 2006 12:06:17 -0400 (EDT) To: Pascal Urien Subject: Re: [Emu] Identity Protection in EAP-TLS References: <5.2.1.1.0.20060604162721.03ec3680@pop.tele2.fr> From: Sam Hartman Date: Sun, 04 Jun 2006 12:06:17 -0400 In-Reply-To: <5.2.1.1.0.20060604162721.03ec3680@pop.tele2.fr> (Pascal Urien's message of "Sun, 04 Jun 2006 16:27:31 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 In general, it seems that the TLS community has been recommending a second authentication if you have data you need to exchange that is confidential and would normally be in the first authentication. See draft-housley-tls-authz-extns for an example of the use of this method. Clearly using this within eap-tls would require some specification work, but I think would be preferable to your approach. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Jun 04 14:41:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmxXA-0004kZ-SK; Sun, 04 Jun 2006 14:41:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmxX9-0004kU-Th for emu@ietf.org; Sun, 04 Jun 2006 14:41:07 -0400 Received: from bay106-f19.bay106.hotmail.com ([65.54.161.29] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmxX8-0008S5-Je for emu@ietf.org; Sun, 04 Jun 2006 14:41:07 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 4 Jun 2006 11:41:05 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Sun, 04 Jun 2006 18:41:03 GMT X-Originating-IP: [24.16.73.85] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: emu@ietf.org Bcc: Subject: Re: [Emu] Identity Protection in EAP-TLS Date: Sun, 04 Jun 2006 11:41:03 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 04 Jun 2006 18:41:05.0715 (UTC) FILETIME=[70045030:01C68806] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 >Clearly using this within eap-tls would require some specification >work, but I think would be preferable to your approach. The EMU WG charter states: "Backwards compatibility with RFC 2716 is a requirement." So I'd like to understand which approach (if any) is backward compatible with existing RFC 2716 implementations. EAP-TLS server implementations always request a certificate. If the client desires privacy, it can choose not to respond to the certificate request. An EAP-TLS server supporting privacy would then bring up the TLS channel and request the certificate again, and a client supporting privacy would comply. However, existing EAP-TLS servers will terminate the connection if a certificate is not provided in response to the first request, so an uplevel client talking to a downlevel server would have to choose between connectivity and privacy, at least on the first attempt. On subsequent attempts, the uplevel client could choose whether it is willing to hand over its certificate in cleartext and if so, it could connect using the RFC 2716-specified sequence. The backward compatibility of the client extension approach depends on the server's reaction to the offering of client extensions. There seems to be an assumption that a downlevel server will ignore the extensions and that therefore the conversation would complete as in RFC 2716. This would allow a client supporting privacy extensions but willing to connect without privacy to successfully authenticate on the first attempt. However, I'm not clear whether the underlying assumption of extension backward compatibliity is actually true or not -- as I understand it, some EAP-TLS server implementations do not react well to extensions. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Jun 05 05:57:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnBpz-0000rA-Ll; Mon, 05 Jun 2006 05:57:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnBpy-0000r5-B9 for emu@ietf.org; Mon, 05 Jun 2006 05:57:30 -0400 Received: from mailfe08.tele2.fr ([212.247.154.236] helo=swip.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnBpw-0000NF-P9 for emu@ietf.org; Mon, 05 Jun 2006 05:57:30 -0400 X-T2-Posting-ID: TlrHmwDFCX01iQZd0Fm6v3T8FBlCqve5GwI1mWaefYU= X-Cloudmark-Score: 0.000000 [] Received: from [80.170.92.253] (HELO DELL.tele2.fr) by mailfe08.swip.net (CommuniGate Pro SMTP 5.0.8) with ESMTP id 207010636; Mon, 05 Jun 2006 11:57:22 +0200 Message-Id: <5.2.1.1.0.20060605112735.03eb9fc0@pop.tele2.fr> X-Sender: eu968071@pop.tele2.fr X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 05 Jun 2006 11:57:22 +0200 To: emu@ietf.org From: Pascal Urien Subject: Re: [Emu] Identity Protection in EAP-TLS 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: c0bedb65cce30976f0bf60a0a39edea4 Cc: Bernard Aboba X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Everybody At 11:41 04/06/2006 -0700, you wrote: >>Clearly using this within eap-tls would require some specification >>work, but I think would be preferable to your approach. > >The EMU WG charter states: >"Backwards compatibility with RFC 2716 is a requirement." > >So I'd like to understand which approach (if any) is backward compatible >with existing RFC 2716 implementations. > >EAP-TLS server implementations always request a certificate. If the >client desires privacy, it can choose not to respond to the certificate >request. >An EAP-TLS server supporting privacy would then bring up the TLS channel >and request the certificate again, and a client supporting privacy would >comply. However, existing EAP-TLS servers will terminate the connection if >a certificate is not provided in response to the first request, so an >uplevel client talking to a downlevel server would have to choose between >connectivity and privacy, From our point of view the main issue in today RFC 2716 document is that the client always sent its identity (X509 certificate) in clear text. In a Wi-Fi context, this is clearly a major security threat. >at least on the first attempt. On subsequent attempts, the uplevel client >could choose whether it is willing to hand over its certificate in >cleartext and if so, it could connect using the RFC 2716-specified sequence. > >The backward compatibility of the client extension approach depends on the >server's reaction to the offering of client extensions. There seems to be >an assumption that a downlevel server will ignore the extensions and that >therefore the conversation would complete as in RFC 2716. This would >allow a client supporting privacy extensions but willing to connect >without privacy to successfully authenticate on the first >attempt. However, I'm not clear whether the underlying assumption of >extension backward compatibliity is actually true or not -- as I >understand it, some EAP-TLS server implementations do not react well to >extensions. According to http://www.ietf.org/internet-drafts/draft-urien-badra-eap-tls-identity-protection-00.txt the TLS extension is used in order to indicate to the server, that the client certificate will (MUST) be sent encrypted, A choice of encryption algorithms MAY be supported by the client. However the server can easily detects the encryption of the client's certificate, because the first bytes (in clear text) are knows : Certificate: [30] [8x] (with x=2) [Certficate_Length] [30] [8x] (with =2) Furthermore if the server ignores the TLS extension the client MAY send its certificate encrypted with its preferred encryption algorithm (the first in the TLS extension list) Pascal >_______________________________________________ >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 Jun 05 08:16:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnE0C-0002Ru-MK; Mon, 05 Jun 2006 08:16:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnE0B-0002Rp-UA for emu@ietf.org; Mon, 05 Jun 2006 08:16:11 -0400 Received: from bay106-f18.bay106.hotmail.com ([65.54.161.28] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnE0A-0006X6-MG for emu@ietf.org; Mon, 05 Jun 2006 08:16:11 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 5 Jun 2006 05:16:10 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 05 Jun 2006 12:16:06 GMT X-Originating-IP: [24.16.73.85] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <5.2.1.1.0.20060605112735.03eb9fc0@pop.tele2.fr> From: "Bernard Aboba" To: emu@ietf.org Bcc: Subject: Re: [Emu] Identity Protection in EAP-TLS Date: Mon, 05 Jun 2006 05:16:06 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 05 Jun 2006 12:16:10.0045 (UTC) FILETIME=[D4567ED0:01C68899] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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 >Furthermore if the server ignores the TLS extension the client MAY send >its certificate encrypted with its preferred >encryption algorithm (the first in the TLS extension list) This definitely breaks backward compatibility. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Jun 05 10:05:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnFhT-0008TZ-OB; Mon, 05 Jun 2006 10:04:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnFhS-0008TU-2d for emu@ietf.org; Mon, 05 Jun 2006 10:04:58 -0400 Received: from mailfe04.tele2.fr ([212.247.154.108] helo=swip.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnFhQ-0003IK-Kp for emu@ietf.org; Mon, 05 Jun 2006 10:04:58 -0400 X-T2-Posting-ID: TlrHmwDFCX01iQZd0Fm6v3T8FBlCqve5GwI1mWaefYU= X-Cloudmark-Score: 0.000000 [] Received: from [80.170.156.160] (HELO DELL.tele2.fr) by mailfe04.swip.net (CommuniGate Pro SMTP 5.0.8) with ESMTP id 207652149; Mon, 05 Jun 2006 16:04:54 +0200 Message-Id: <5.2.1.1.0.20060605154037.0447ce98@pop.infres.enst.fr> X-Sender: eu968071@pop.tele2.fr X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 05 Jun 2006 16:04:54 +0200 To: "Bernard Aboba" ,emu@ietf.org From: Pascal Urien Subject: Re: [Emu] Identity Protection in EAP-TLS In-Reply-To: References: <5.2.1.1.0.20060605112735.03eb9fc0@pop.tele2.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 At 05:16 05/06/2006 -0700, Bernard Aboba wrote: >>Furthermore if the server ignores the TLS extension the client MAY send >>its certificate encrypted with its preferred >>encryption algorithm (the first in the TLS extension list) > >This definitely breaks backward compatibility. The issue is that any malicious access point may forge EAP-TLS packets in order to collect the supplicant's certificate (e;G. its identity) From the supplicant point of view, the meaning of the TLS extension is something like "i want to keep secret my identity" So a negative answer to the supplicant's request, sings like "i need your identity in clear text" At this step the supplicant doesn't know if the access point is malicious or not.. This leads to two questions 1) what is the right way to manage backward compatibility, without sacrificing privacy issues ? 2) do we need a new EAP type for that concern?. Pascal >_______________________________________________ >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 Jun 05 13:54:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnJH7-0005Ko-Ig; Mon, 05 Jun 2006 13:54:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnJH6-0005Ki-J5 for emu@ietf.org; Mon, 05 Jun 2006 13:54:00 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnJH5-0004V0-8f for emu@ietf.org; Mon, 05 Jun 2006 13:54:00 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C997089870; Mon, 5 Jun 2006 20:53:57 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 895568985B; Mon, 5 Jun 2006 20:53:57 +0300 (EEST) Message-ID: <44846FB4.4010800@piuha.net> Date: Mon, 05 Jun 2006 20:53:56 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: emu@ietf.org, eap@frascone.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Emu] FW: Last Call: 'The Protected One-Time Password Protocol (EAP-POTP)' to Informational RFC (draft-nystrom-eap-potp) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org FYI. Comments on this EAP method specification would be most appreciated. >The IESG has received a request from an individual submitter to consider the >following document: > >- 'The Protected One-Time Password Protocol (EAP-POTP) ' > as an Informational RFC > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by 2006-07-03. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-nystrom-eap-potp-05.txt > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf-announce > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Jun 05 14:06:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnJTV-0001so-EN; Mon, 05 Jun 2006 14:06:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnJTV-0001s8-4P for emu@ietf.org; Mon, 05 Jun 2006 14:06:49 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FnJTT-0004pC-Md for emu@ietf.org; Mon, 05 Jun 2006 14:06:49 -0400 Received: (qmail invoked by alias); 05 Jun 2006 18:06:46 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp043) with SMTP; 05 Jun 2006 20:06:46 +0200 X-Authenticated: #29516787 Message-ID: <448472BF.10508@gmx.net> Date: Mon, 05 Jun 2006 20:06:55 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Subject: Re: [Emu] FW: Last Call: 'The Protected One-Time Password Protocol (EAP-POTP)' to Informational RFC (draft-nystrom-eap-potp) References: <44846FB4.4010800@piuha.net> In-Reply-To: <44846FB4.4010800@piuha.net> 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: e1e48a527f609d1be2bc8d8a70eb76cb Cc: emu@ietf.org, eap@frascone.com 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 must have missed it but who did the expert review for EAP-POTP? Ciao Hannes Jari Arkko wrote: > FYI. Comments on this EAP method specification would be most > appreciated. > > >>The IESG has received a request from an individual submitter to consider the >>following document: >> >>- 'The Protected One-Time Password Protocol (EAP-POTP) ' >> as an Informational RFC >> >>The IESG plans to make a decision in the next few weeks, and solicits >>final comments on this action. Please send any comments to the >>iesg@ietf.org or ietf@ietf.org mailing lists by 2006-07-03. >> >>The file can be obtained via >>http://www.ietf.org/internet-drafts/draft-nystrom-eap-potp-05.txt >> >>_______________________________________________ >>IETF-Announce mailing list >>IETF-Announce@ietf.org >>https://www1.ietf.org/mailman/listinfo/ietf-announce >> >> > > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Jun 05 16:06:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnL9h-0003Gd-4K; Mon, 05 Jun 2006 15:54:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnL9W-00036z-1z for emu@ietf.org; Mon, 05 Jun 2006 15:54:18 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnL9T-0007Gg-IO for emu@ietf.org; Mon, 05 Jun 2006 15:54:17 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 323FD89870; Mon, 5 Jun 2006 22:54:14 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id DFE6D8985B; Mon, 5 Jun 2006 22:54:13 +0300 (EEST) Message-ID: <44848BE4.3000808@piuha.net> Date: Mon, 05 Jun 2006 22:54:12 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Emu] FW: Last Call: 'The Protected One-Time Password Protocol (EAP-POTP)' to Informational RFC (draft-nystrom-eap-potp) References: <44846FB4.4010800@piuha.net> <448472BF.10508@gmx.net> In-Reply-To: <448472BF.10508@gmx.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: emu@ietf.org, eap@frascone.com 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 must have missed it but who did the expert review for EAP-POTP? Technically, it does not need expert review for IANA allocation since an existing allocation (#32) is used. But I believe the document does need wider IETF review due to its potential impact in the real world, and that's why its being last called and I'm asking you to review it. In any case, I have reviewed this document and as a part of that review I also went through the same questions as we normally do on the expert review. That review was recently posted to the EAP WG list and resulted in a new revision of the document. In order to avoid e-mail duplication, if you have comments on my review or this thread, post your comment to the EAP list. But other comments on IETF last calls should normally go to the ietf@ietf.org list. --Jari _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Jun 06 18:43:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnkGl-0002FY-6E; Tue, 06 Jun 2006 18:43:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnkGk-0002DX-Bx for emu@ietf.org; Tue, 06 Jun 2006 18:43:26 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnkGi-0005j0-At for emu@ietf.org; Tue, 06 Jun 2006 18:43:26 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 06 Jun 2006 15:43:24 -0700 X-IronPort-AV: i="4.05,215,1146466800"; d="scan'208"; a="1820583237:sNHT32076212" 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 k56MhNcd029210 for ; Tue, 6 Jun 2006 15:43:23 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k56MhNkg003837 for ; Tue, 6 Jun 2006 15:43:23 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Jun 2006 15:43:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Jun 2006 15:43:22 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EMU PSK design team draft available Thread-Index: AcaJup1BMld2BmK9RxqiEGgOPvo9Dw== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 06 Jun 2006 22:43:23.0285 (UTC) FILETIME=[9DE8F450:01C689BA] DKIM-Signature: a=rsa-sha1; q=dns; l=2556; t=1149633803; x=1150497803; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:EMU=20PSK=20design=20team=20draft=20available; X=v=3Dcisco.com=3B=20h=3Do8GE968bgkyK0DQZH0qGyrYwn/k=3D; b=SjtuUG+vZN7e+mvtqT4I8kWP3/2cDVNdzb9AK7fadtOnkMLuVE5IszK+EPVLlndnXEU5Ip5/ khBCNH66ad5cNyhbrxyBq7a+lr93iYDMgiZHqu5vcIqc6T5q9MV6kz2j; Authentication-Results: sj-dkim-4.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [Emu] EMU PSK design team draft available 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 EMU PSK design team has completed a draft of a Generalized Pre-Shared Key EAP method for consideration by the EMU working group. Information on accessing the draft is included at the end of this message. Please review this draft and post comments to the EMU working group list. =20 I would like to thank the EMU PSK design team for the hard work put into this document. =20 Joe A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : EAP Generalized Pre-Shared Key (EAP-GPSK) Author(s) : C. Clancy, H. Tschofenig Filename : draft-clancy-emu-eap-shared-secret-00.txt Pages : 29 Date : 2006-6-6 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-clancy-emu-eap-shared-secret-0 0.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-clancy-emu-eap-shared-secret-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-clancy-emu-eap-shared-secret-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Jun 06 22:30:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnnol-0000nF-Oe; Tue, 06 Jun 2006 22:30:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnnol-0000nA-0P for emu@ietf.org; Tue, 06 Jun 2006 22:30:47 -0400 Received: from bay106-f2.bay106.hotmail.com ([65.54.161.12] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnnoj-0006vU-Om for emu@ietf.org; Tue, 06 Jun 2006 22:30:46 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 6 Jun 2006 19:30:45 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Wed, 07 Jun 2006 02:30:40 GMT X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: emu@ietf.org Bcc: Subject: RE: [Emu] EMU PSK opaque blogs Date: Tue, 06 Jun 2006 19:30:40 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 07 Jun 2006 02:30:45.0149 (UTC) FILETIME=[611834D0:01C689DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 Just a random comment: "Server identity as an opaque blog." Many blogs are in fact quite opaque, but do we really need to force the user to read an opaque blog as part of the protocol? :) _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Jun 07 03:18:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnsIq-0000I8-O2; Wed, 07 Jun 2006 03:18:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnsIo-0000I0-WF for emu@ietf.org; Wed, 07 Jun 2006 03:18:07 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FnsIn-0007Lw-Hz for emu@ietf.org; Wed, 07 Jun 2006 03:18:06 -0400 Received: (qmail invoked by alias); 07 Jun 2006 07:18:03 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp039) with SMTP; 07 Jun 2006 09:18:03 +0200 X-Authenticated: #29516787 Message-ID: <44867DAA.6070204@gmx.net> Date: Wed, 07 Jun 2006 09:18:02 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [Emu] EMU PSK opaque blogs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 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 Hi Bernard, we did not know how the server identity should look like. Hence, we just said that it is a blog. I guess the same approach was used in PAX. Ciao Hannes Bernard Aboba wrote: > Just a random comment: > > "Server identity as an opaque blog." > > Many blogs are in fact quite opaque, but do we really need to force the > user to read an opaque blog as part of the protocol? :) > > > > _______________________________________________ > 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 Jun 07 07:26:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnwBJ-0004Fp-HB; Wed, 07 Jun 2006 07:26:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnwBH-0004Fk-Gw for emu@ietf.org; Wed, 07 Jun 2006 07:26:35 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FnwBG-0002zI-30 for emu@ietf.org; Wed, 07 Jun 2006 07:26:35 -0400 Received: (qmail invoked by alias); 07 Jun 2006 11:26:32 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp001) with SMTP; 07 Jun 2006 13:26:32 +0200 X-Authenticated: #29516787 Message-ID: <4486B7E7.1010108@gmx.net> Date: Wed, 07 Jun 2006 13:26:31 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Emu] EMU PSK opaque blogs References: <44867DAA.6070204@gmx.net> In-Reply-To: <44867DAA.6070204@gmx.net> 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: cab78e1e39c4b328567edb48482b6a69 Cc: Bernard Aboba , emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Bernard, now I got your point :-) Took a little bit longer.... Hannes Tschofenig wrote: > Hi Bernard, > > > we did not know how the server identity should look like. > Hence, we just said that it is a blog. I guess the same approach was > used in PAX. > > Ciao > Hannes > > Bernard Aboba wrote: > >> Just a random comment: >> >> "Server identity as an opaque blog." >> >> Many blogs are in fact quite opaque, but do we really need to force >> the user to read an opaque blog as part of the protocol? :) >> >> >> >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www1.ietf.org/mailman/listinfo/emu >> >> > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Jun 08 16:01:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoQhG-0007XK-3f; Thu, 08 Jun 2006 16:01:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoQhE-0007XE-Ri for emu@ietf.org; Thu, 08 Jun 2006 16:01:36 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoQhD-0004XF-DT for emu@ietf.org; Thu, 08 Jun 2006 16:01:36 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 08 Jun 2006 13:01:30 -0700 X-IronPort-AV: i="4.05,221,1146466800"; d="scan'208"; a="1822283991:sNHT9172508920" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k58K1TLv027770 for ; Thu, 8 Jun 2006 13:01:29 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k58K1T9u018152 for ; Thu, 8 Jun 2006 13:01:29 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 13:01:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Jun 2006 13:01:28 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Enhanced EAP-TLS Thread-Index: AcaLNlQSq0YF1VjgQFiMo/F8W8E07A== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 08 Jun 2006 20:01:29.0613 (UTC) FILETIME=[54EFBBD0:01C68B36] DKIM-Signature: a=rsa-sha1; q=dns; l=435; t=1149796889; x=1150660889; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:Enhanced=20EAP-TLS; X=v=3Dcisco.com=3B=20h=3DiSmF9ZHWQWe9zKpnYC+9DeJeaHo=3D; b=nOSHcsys6Tv8S2QN+3aw5iymZ7A+//E1BThjsC0noTuRfVPo8kLitOha+wQVzGCK+iYIpiq4 3TuhPUmpZ2rkZ/DIVXT75BiPuyRfeo6j9ZHBCo7qXq3J2E7i/qj7fNbU; Authentication-Results: sj-dkim-1.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Emu] Enhanced EAP-TLS 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 One of our charter items is to develop an enhanced EAP-TLS that can support features that are not possible to support in a manner that is backward compatible with RFC2716.=20 Some of the potential features on the list include: 1. Additional cipher suites (PSK, Kerberos, ECC) 2. TLS extensions=20 3. Channel Bindings 4. Identity protection Are there additional features that should be supported by an enhanced TLS? =20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Jun 08 16:34:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoRCn-0007OI-HS; Thu, 08 Jun 2006 16:34:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoRCm-0007My-4g for emu@ietf.org; Thu, 08 Jun 2006 16:34:12 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoQw9-0005SP-M3 for emu@ietf.org; Thu, 08 Jun 2006 16:17:01 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoQMn-0005zm-Eo for emu@ietf.org; Thu, 08 Jun 2006 15:40:31 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 08 Jun 2006 12:40:29 -0700 X-IronPort-AV: i="4.05,221,1146466800"; d="scan'208"; a="1822265075:sNHT121987624" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k58JeSru017500; Thu, 8 Jun 2006 12:40:28 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k58JeOCW010868; Thu, 8 Jun 2006 12:40:27 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 12:40:25 -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] Identity Protection in EAP-TLS Date: Thu, 8 Jun 2006 12:40:23 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Identity Protection in EAP-TLS Thread-Index: AcaIBne2zH74jFhkQfG4JTh9yw8ttQDKrXjA From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 08 Jun 2006 19:40:25.0257 (UTC) FILETIME=[63525190:01C68B33] DKIM-Signature: a=rsa-sha1; q=dns; l=2729; t=1149795628; x=1150659628; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:RE=3A=20[Emu]=20Identity=20Protection=20in=20EAP-TLS; X=v=3Dcisco.com=3B=20h=3DZqD1iquIS1rAH8jtXPhJ0/KFt+8=3D; b=OiwEqdeSapWM9k1EUT4kUgP5qcpy36pusRI4Ta293ULr8jHszWQ0fM7ymRlXHo9q2o49GPs9 QRitNFGWEgv8FDo61FJywDyIaPKj60ZpqJYqPtVoaP252snKJCu+Ho/I; Authentication-Results: sj-dkim-2.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 agree that we need to determine what we can get away with and still be backward compatible. I think a big issue is whether TLS extensions are allowed within RFC2716bis. It may be that extensions will need to be left for an enhanced EAP-TLS (which the working group needs to define). Do we know what the client and server implementation problems with TLS extensions are?=20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Sunday, June 04, 2006 11:41 AM > To: emu@ietf.org > Subject: Re: [Emu] Identity Protection in EAP-TLS >=20 > >Clearly using this within eap-tls would require some specification > >work, but I think would be preferable to your approach. >=20 > The EMU WG charter states: > "Backwards compatibility with RFC 2716 is a requirement." >=20 > So I'd like to understand which approach (if any) is backward=20 > compatible=20 > with existing RFC 2716 implementations. >=20 > EAP-TLS server implementations always request a certificate. =20 > If the client=20 > desires privacy, it can choose not to respond to the=20 > certificate request. =20 > An EAP-TLS server supporting privacy would then bring up the=20 > TLS channel and=20 > request the certificate again, and a client supporting=20 > privacy would comply.=20 > However, existing EAP-TLS servers will terminate the connection if a=20 > certificate is not provided in response to the first request,=20 > so an uplevel=20 > client talking to a downlevel server would have to choose between=20 > connectivity and privacy, at least on the first attempt. On=20 > subsequent=20 > attempts, the uplevel client could choose whether it is=20 > willing to hand over=20 > its certificate in cleartext and if so, it could connect=20 > using the RFC=20 > 2716-specified sequence. >=20 > The backward compatibility of the client extension approach=20 > depends on the=20 > server's reaction to the offering of client extensions. =20 > There seems to be=20 > an assumption that a downlevel server will ignore the=20 > extensions and that=20 > therefore the conversation would complete as in RFC 2716. =20 > This would allow=20 > a client supporting privacy extensions but willing to connect without=20 > privacy to successfully authenticate on the first attempt. =20 > However, I'm not=20 > clear whether the underlying assumption of extension backward=20 > compatibliity=20 > is actually true or not -- as I understand it, some EAP-TLS server=20 > implementations do not react well to extensions. >=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 Thu Jun 08 21:45:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoW3j-0003y5-K7; Thu, 08 Jun 2006 21:45:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoW3i-0003pa-29 for emu@ietf.org; Thu, 08 Jun 2006 21:45:10 -0400 Received: from bay106-f28.bay106.hotmail.com ([65.54.161.38] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoW3g-0004dp-PH for emu@ietf.org; Thu, 08 Jun 2006 21:45:10 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 8 Jun 2006 18:45:07 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Fri, 09 Jun 2006 01:45:07 GMT X-Originating-IP: [131.107.0.71] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: jsalowey@cisco.com, emu@ietf.org Bcc: Subject: RE: [Emu] Identity Protection in EAP-TLS Date: Thu, 08 Jun 2006 18:45:07 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 09 Jun 2006 01:45:07.0978 (UTC) FILETIME=[56708EA0:01C68B66] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 >Do we know what the client and server implementation problems with TLS >extensions are? At IETF 65, Yngve Petterson gave a presentation relating to TLS interoperability issues: http://www3.ietf.org/proceedings/06mar/slides/tls-6.pdf Slide 3 states: Many SSL/TLS server implementations are broken with respect to forward compatibility: SSLv3 servers will not talk to TLS 1.0 clients. TLS 1.0 servers will not accept TLS extensions. TLS 1.0 servers will not talk to TLS 1.1 clients. TLS 1.0 servers using the wrong protocol field to negotiate version. If anything, our own test results indicate that the problem is even worse than what Yngve indicates. For example, we seen TLS 1.0 servers that cannot talk to TLS 1.0 clients when a ciphersuite other than RC4 (e.g. 3DES) is negotiated. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Jun 09 11:58:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FojNe-0001vh-2N; Fri, 09 Jun 2006 11:58:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FojNd-0001vY-0c for emu@ietf.org; Fri, 09 Jun 2006 11:58:37 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FojNa-0008Iy-LU for emu@ietf.org; Fri, 09 Jun 2006 11:58:36 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 09 Jun 2006 08:58:34 -0700 X-IronPort-AV: i="4.05,224,1146466800"; d="scan'208"; a="292325027:sNHT33067568" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k59FwY0W004968 for ; Fri, 9 Jun 2006 08:58:34 -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 k59FwY9s025413 for ; Fri, 9 Jun 2006 08:58:34 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Jun 2006 08:58:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Jun 2006 08:58:31 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on EAP-TLS for TLS-PSK Thread-Index: AcaL3Y5GIHr+lRncS4+OFJaHy/IB5g== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 09 Jun 2006 15:58:33.0445 (UTC) FILETIME=[8F46C150:01C68BDD] DKIM-Signature: a=rsa-sha1; q=dns; l=2595; t=1149868714; x=1150732714; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:Draft=20on=20EAP-TLS=20for=20TLS-PSK; X=v=3Dcisco.com=3B=20h=3DDvl6jZkP5gyYNGowxs16ZRbOGUQ=3D; b=GB0rkyyFcOXAeal9zAuJQHz89Cxhkkl94WxOGgaHWX9Y9SqNu2yRsXbwX4tesa7SYB1h4VPK Np4zqqrMjPuFMVdIDqNMjZzhOkeK+KiKk5fz+QAC9oi//3ngq63AZP+V; Authentication-Results: sj-dkim-1.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Subject: [Emu] Draft on EAP-TLS for TLS-PSK X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Below is an announcement for a draft that I missed that may be pertinent to some of the discussions in the working group. It looks like it addresses using EAP-TLS with PSK based cipher suites.=20 Joe A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The EAP-TLS-PSK Authentication Protocol Author(s) : T. Otto, H. Tschofenig Filename : draft-otto-emu-eap-tls-psk-00.txt Pages : 28 Date : 2006-4-20 The Extensible Authentication Protocol (EAP), defined in RFC 3748, is a network access authentication framework which provides support for multiple authentication methods. One proposal is EAP-TLS, which relies on the Transport Layer Security (TLS) protocol and allows for certificate-based authentication. This document specifies EAP-TLS- PSK, which also relies on TLS, but allows for shared secret-based authentication. EAP-TLS-PSK supports the pre-shared key ciphersuites specified in RFC 4279. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-otto-emu-eap-tls-psk-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-otto-emu-eap-tls-psk-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-otto-emu-eap-tls-psk-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Jun 11 00:27:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpHXc-0007Fp-LM; Sun, 11 Jun 2006 00:27:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpHXb-0007Fk-Gd for emu@ietf.org; Sun, 11 Jun 2006 00:27:11 -0400 Received: from mail2.genealogia.fi ([194.100.116.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpHXZ-0005qQ-Uk for emu@ietf.org; Sun, 11 Jun 2006 00:27:11 -0400 Received: from dsl017-049-110.sfo4.dsl.speakeasy.net ([69.17.49.110] helo=jm) by mail2.genealogia.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1FpHXU-0000Ew-BP; Sun, 11 Jun 2006 07:27:07 +0300 Received: by jm (sSMTP sendmail emulation); Sat, 10 Jun 2006 21:26:29 -0700 Date: Sat, 10 Jun 2006 21:26:29 -0700 From: Jouni Malinen To: clancy@ltsnet.net, Hannes.Tschofenig@siemens.com Message-ID: <20060611042629.GA9582@jm.kir.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 X-Spam-Score: -2.6 (--) X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: emu@ietf.org Subject: [Emu] EAP-GPSK comments 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 draft-clancy-emu-eap-shared-secret-00.txt KDFData: What defines the arbitrary data (KDFData_Client and KDFData_Server) that is to be included in the KDF? What is this used for? Chapter 7.4 defines a mechanism for server and peer to send "Extra KDF Data" to allow binding data into the key derivation process. However, that looks like any data could be sent and the server/peer would just include it as a seed for KDF. Wouldn't this data need to be specified somehow and used for something else than just an arbitrary seeding material (e.g., export an identity or whatever else could be bound here). The current draft does not seem to describe clearly how this is to be used. 7.4: "If multiple entries are specified in a single PD_Payload with PData/Specifier 3, then the first field must be used." Is there any case where there would be more than one such entry? Shouldn't that be just specified as an invalid message (MUST silently ignore the packet?) instead of ignoring the extra entries that should not have been there in the first place. Chapter 4 seems to concatenate KDFData_Client and KDFData_Server into the generic MSK and EMSK derivation. However, the cipher suite specific derivation (6.1.3 and 6.2.3) does not. Was that on purpose? ID Server/Client in key derivation: Variable length ID_Server and ID_Client are concatenated in MK and KDF_out derivation. This means that there is no explicitly specified boundary between these fields and different values can produce same keys (e.g., 'a || bc' and 'ab || c' would produce same keys). Should ID_Server/Client length be prefixed as 16-bit value before the ID value to make Server/Client ID boundary explicit? Alternatively 0x00 could be used as a delimiter (assuming it is not allowed in either ID string). Failure reporting: What is the server/peer to do when something fails? For example, what if GPSK-1 does not include a supported ciphersuite. What would peer send in response? There does not seem to be an error message defined for this purpose. Similar comments applies to other messages, i.e., behavior for error cases should be defined. GKDF-X(Y, Z) definition (Chap. 5): s%n = int( X / size ) + 1%n = int( (X + size - 1) / size)% (previous version would have one extra operation if X mod size = 0) Need to define how many octets are used for i and X in input to MAC_Y. Is this two octets in network byte order? Input to Integrity MAC (6.1.2 and 6.2.2): SEC_SK is the definition of how plaintext + MAC are concatenated, so it does not look like the correct input for MAC. Should "Value of SEC_SK in message GPSK-#" be replaced with "Payload of message GPSK-#"? Based on other parts of the draft, it looks like this input should be the data following OP-Code in the message. Protected result reporting: 7.4 has following paragraph: Definition of the protected results indiciation field is outside the scope of this document. It could be used to indicate the success or failure of both authentication and authorization in a secure way. Why is this outside the scope of this document? How can 8.2 then claim: EAP-GPSK provides protected result indications based on information exchanged inside the protected data payloads. Protected result indication sounds like a relatively simple addition and I would prefer to see it included in the specification that defined the new EAP method (i.e., in this document). That way, it could be made mandatory and there would be no need for having to handle backwards compatibility cases and allow sessions without protected result indication in order to interoperate with many(most?) implementations (which seems to be the case with, e.g., EAP-SIM and EAP-AKA that leave this optional). 8.12 Channel Binding "Channel binding is accomplished through the protected data blocks" This draft does not specify exact mechanism for channel binding. Is this claim valid without such specification? If nothing else, s/is/can be/ could be considered here. Minor comments/typos: 1: Efficiency: s/allow for/allows for/ (restriction ... allow_s_ for) "Well suited for any type of device" Hmm.. I would assume that there are many embedded devices that do not have enough resources for running AES or SHA256, never mind EAP-GPSK.. ;-) 2: "CSuite_List" title missing before variable definition "An octet array listing available ciphersuites (variable length)" ID_Server: s/blog/blob/ 3: s/consists two/consists of two/ In GPSK-1, ... s/peer sends its identity ID_Server/server sends its identity ID_Server/ 5: "The Code field in Figure 3 uniquely identifies a ciphersuite" There is no Code field in Figure 3.. s%Code%CSuite/Specified% (?) Is the following paragraph valid? 7.2 seems to indicate that ciphersuites are always encoded as 6-octet arrays regardless of whether they are vendir-specific or not. If Code=254 is used, a vendor-specific ciphersuite is encoded. In this case, the following six octets identify the ciphersuite. The first three octets are the vendor-specific OID, and the last three octets are vendor assigned. 7.2: s/indiciates/indicates/ 7.3: s/256-bit RAND_Server/32-octet RAND_Server/ in Figure 7 (GPSK-1) (to be consistent with other figures) s/PD_Payload_1/PD_Payload_2/ in Figure 9 (GPSK-3) 7.4: s/indiciation/indication/ -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Jun 11 08:17:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpOsm-0007Jm-JC; Sun, 11 Jun 2006 08:17:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpOsl-0007Jh-MY for emu@ietf.org; Sun, 11 Jun 2006 08:17:31 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FpOsj-0005Qz-0D for emu@ietf.org; Sun, 11 Jun 2006 08:17:31 -0400 Received: (qmail invoked by alias); 11 Jun 2006 12:17:27 -0000 Received: from p54984C53.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.76.83] by mail.gmx.net (mp042) with SMTP; 11 Jun 2006 14:17:27 +0200 X-Authenticated: #29516787 Message-ID: <448C09D8.7090307@gmx.net> Date: Sun, 11 Jun 2006 14:17:28 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jouni Malinen Subject: Re: [Emu] EAP-GPSK comments References: <20060611042629.GA9582@jm.kir.nu> In-Reply-To: <20060611042629.GA9582@jm.kir.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Cc: emu@ietf.org, clancy@ltsnet.net 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 Jouni, thanks for the detailed comments. Please find my response inline: Jouni Malinen wrote: > draft-clancy-emu-eap-shared-secret-00.txt > > KDFData: > > What defines the arbitrary data (KDFData_Client and KDFData_Server) > that is to be included in the KDF? What is this used for? Chapter 7.4 > defines a mechanism for server and peer to send "Extra KDF Data" to > allow binding data into the key derivation process. However, that > looks like any data could be sent and the server/peer would just > include it as a seed for KDF. Wouldn't this data need to be specified > somehow and used for something else than just an arbitrary seeding > material (e.g., export an identity or whatever else could be bound > here). The current draft does not seem to describe clearly how this is > to be used. The idea was that you would bind some data that is being exchanged between the peer and the server to the keys by including them into the key derivation function. I never saw this functionality being useful but some design team members liked it. It was added very late in the draft writing process. Hence, I guess there are some loose ends. I personally wouldn't mind removing it again. I am missing the uses cases. > > 7.4: "If multiple entries are specified in a single PD_Payload with > PData/Specifier 3, then the first field must be used." > Is there any case where there would be more than one such entry? > Shouldn't that be just specified as an invalid message (MUST silently > ignore the packet?) instead of ignoring the extra entries that should > not have been there in the first place. > > Chapter 4 seems to concatenate KDFData_Client and KDFData_Server into > the generic MSK and EMSK derivation. However, the cipher suite > specific derivation (6.1.3 and 6.2.3) does not. Was that on purpose? > This question is related to the previous one. The reason for not including the KDFDATA into all KDFs is that we need the keys before the KDFDATA is exchanged. Added an issue for this aspect: http://www.tschofenig.com:8080/eap-gpsk/issue3 > > ID Server/Client in key derivation: > > Variable length ID_Server and ID_Client are concatenated in MK and > KDF_out derivation. This means that there is no explicitly specified > boundary between these fields and different values can produce same > keys (e.g., 'a || bc' and 'ab || c' would produce same keys). Should > ID_Server/Client length be prefixed as 16-bit value before the ID > value to make Server/Client ID boundary explicit? Alternatively 0x00 > could be used as a delimiter (assuming it is not allowed in either ID > string). Do you see an attack if we don't use a delimiter? Added an issue: http://www.tschofenig.com:8080/eap-gpsk/issue4 > > > Failure reporting: > > What is the server/peer to do when something fails? For example, what > if GPSK-1 does not include a supported ciphersuite. What would peer > send in response? There does not seem to be an error message defined > for this purpose. Similar comments applies to other messages, i.e., > behavior for error cases should be defined. There is a mandatory to implement ciphersuite (i.e., Ciphersuite 1) and hence this case cannot happen. Do you have other failure cases in mind? > > > GKDF-X(Y, Z) definition (Chap. 5): > > s%n = int( X / size ) + 1%n = int( (X + size - 1) / size)% > (previous version would have one extra operation if X mod size = 0) > > Need to define how many octets are used for i and X in input to MAC_Y. > Is this two octets in network byte order? I am not so sure to what text you are referring. > > > Input to Integrity MAC (6.1.2 and 6.2.2): > > SEC_SK is the definition of how plaintext + MAC are concatenated, so > it does not look like the correct input for MAC. Should "Value of > SEC_SK in message GPSK-#" be replaced with "Payload of message > GPSK-#"? Based on other parts of the draft, it looks like this input > should be the data following OP-Code in the message. > We could make the definition of SEC more clear, namely: " SEC_X(Y): SEC is a function that provides integrity protection based on the chosen ciphersuite. The function SEC uses the algorithm defined by the selected ciphersuite and applies it to the message content Y with key X. As an output the message returns Y concatenated with MAC_X(Y). " SEC is used in the protocol in message 2,3 and 4. Here is message 2: GPSK-2: SEC_SK(ID_Client, ID_Server, RAND_Client, RAND_Server, CSuite_List, CSuite_Sel [, ENC_PK(PD_Payload_1), ... ] ) Regarding the text in 6.2.2: The following instantiation is used: AES-128-CMAC(SK, Input) denotes the MAC of Input under the key SK. where Input refers to the following content: o Value of SEC_SK in message GPSK-2 o Value of SEC_SK in message GPSK-3 o Value of SEC_SK in message GPSK-4 This would now produce ID_Client, ID_Server, RAND_Client, RAND_Server, CSuite_List, CSuite_Sel [, ENC_PK(PD_Payload_1), ... ] || AES-128-CMAC(SK, ID_Client, ID_Server, RAND_Client, RAND_Server, CSuite_List, CSuite_Sel [, ENC_PK(PD_Payload_1), ... ] ) We could also write "... input should be the data following OP-Code in the message." It might be easier. Do I miss the issue here? > Protected result reporting: > > 7.4 has following paragraph: > > Definition of the protected results indiciation field is outside the > scope of this document. It could be used to indicate the success or > failure of both authentication and authorization in a secure way. > > Why is this outside the scope of this document? How can 8.2 then claim: > > EAP-GPSK provides protected result indications based on information > exchanged inside the protected data payloads. > > Protected result indication sounds like a relatively simple addition > and I would prefer to see it included in the specification that > defined the new EAP method (i.e., in this document). That way, it > could be made mandatory and there would be no need for having to > handle backwards compatibility cases and allow sessions without > protected result indication in order to interoperate with many(most?) > implementations (which seems to be the case with, e.g., EAP-SIM and > EAP-AKA that leave this optional). > I agree with you that we should add the protected result indication to the document. Added an issue to the issue tracerk: http://www.tschofenig.com:8080/eap-gpsk/issue1 > > > 8.12 Channel Binding > "Channel binding is accomplished through the protected data blocks" > > This draft does not specify exact mechanism for channel binding. Is > this claim valid without such specification? If nothing else, > s/is/can be/ could be considered here. We discussed two aspects: * what channel binding mechanism should we use (given the non-finalized discussions about this subject) * where should we put it (into this document or into a separate one) I remember that we haven't reached a conclusion. I think we should fix the text in Section 8.12 based on the outcome of our decision how to treat this subject. I changed the text to: " This document enables the ability to exchange channel binding information. It does not, however, define the encoding of channel binding information in the document. " Added an issue: http://www.tschofenig.com:8080/eap-gpsk/issue2 > > > > Minor comments/typos: > > 1: > > Efficiency: s/allow for/allows for/ > (restriction ... allow_s_ for) > > "Well suited for any type of device" > Hmm.. I would assume that there are many embedded devices that do not > have enough resources for running AES or SHA256, never mind > EAP-GPSK.. ;-) ... that also run EAP. > > 2: > > "CSuite_List" title missing before variable definition "An octet array > listing available ciphersuites (variable length)" fixed. > > ID_Server: s/blog/blob/ :-) > > 3: > > s/consists two/consists of two/ > fixed. > In GPSK-1, ... > s/peer sends its identity ID_Server/server sends its identity ID_Server/ > fixed. > 5: > > "The Code field in Figure 3 uniquely identifies a ciphersuite" > There is no Code field in Figure 3.. s%Code%CSuite/Specified% (?) > fixed. > Is the following paragraph valid? 7.2 seems to indicate that > ciphersuites are always encoded as 6-octet arrays regardless of > whether they are vendir-specific or not. > > If Code=254 is used, a vendor-specific ciphersuite is encoded. In > this case, the following six octets identify the ciphersuite. The > first three octets are the vendor-specific OID, and the last three > octets are vendor assigned. > fixed. > 7.2: s/indiciates/indicates/ fixed. > > 7.3: > s/256-bit RAND_Server/32-octet RAND_Server/ in Figure 7 (GPSK-1) > (to be consistent with other figures) > s/PD_Payload_1/PD_Payload_2/ in Figure 9 (GPSK-3) > fixed. > 7.4: s/indiciation/indication/ Thanks for your review. Please find the updated draft at: http://www.tschofenig.com/svn/draft-clancy-emu-eap-gpsk/ Ciao Hannes _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Jun 11 08:27:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpP2P-0004xI-VR; Sun, 11 Jun 2006 08:27:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpP2O-0004xC-9W for emu@ietf.org; Sun, 11 Jun 2006 08:27:28 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FpP2L-0005cb-Rh for emu@ietf.org; Sun, 11 Jun 2006 08:27:28 -0400 Received: (qmail invoked by alias); 11 Jun 2006 12:27:24 -0000 Received: from p54984C53.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.76.83] by mail.gmx.net (mp020) with SMTP; 11 Jun 2006 14:27:24 +0200 X-Authenticated: #29516787 Message-ID: <448C0C2E.9070408@gmx.net> Date: Sun, 11 Jun 2006 14:27:26 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: emu@ietf.org References: <20060611042629.GA9582@jm.kir.nu> <448C09D8.7090307@gmx.net> In-Reply-To: <448C09D8.7090307@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Emu] Fwd: [Emudt] Formal Verification of EAP-GPSK X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Here is a forward from the EMU DT mailing list where I mentioned that we did a formal analysis for EAP-GPSK. As we update the protocol I will also reapply it again. Ciao Hannes -----Ursprüngliche Nachricht----- Von: emu-bounces@machshav.com [mailto:emu-bounces@machshav.com] Im Auftrag von Tschofenig, Hannes Gesendet: Freitag, 26. Mai 2006 11:21 An: emu@machshav.com Betreff: [Emudt] Formal Verification of EAP-GPSK Hi all, to verify that we did not miss a severe (and potentially obvious) security bug we ran the EAP-GPSK protocol against the AVISPA tools. The tool could not spot problems with the protocol. (Note that does not mean that it is correct.) The HLPSL file can be found here: http://www.tschofenig.com/TEMP/EMU/gpsk-Input.hlpsl The language is similar to the one used in CASPER. The security goal that was specified was authentication with the Dolev-Yao intruder model being used. More info about AVISPA can be found here: http://www.avispa-project.org/ Some useful documents are: * The High Level Protocol Specification Language http://www.avispa-project.org/delivs/2.1/d2-1.pdf * The Intermediate Format http://www.avispa-project.org/delivs/2.3/d2-3.pdf * HLPSL Tutorial http://www.avispa-project.org/package/tutorial.pdf * User Manual http://www.avispa-project.org/package/user-manual.pdf Ciao Hannes _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Jun 11 12:35:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpSu8-0006P6-W9; Sun, 11 Jun 2006 12:35:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpSu7-0006O7-GH for emu@ietf.org; Sun, 11 Jun 2006 12:35:11 -0400 Received: from mail2.genealogia.fi ([194.100.116.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpSu5-0006U9-Us for emu@ietf.org; Sun, 11 Jun 2006 12:35:11 -0400 Received: from dsl017-049-110.sfo4.dsl.speakeasy.net ([69.17.49.110] helo=jm) by mail2.genealogia.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1FpSu0-0004GJ-6Y; Sun, 11 Jun 2006 19:35:06 +0300 Received: by jm (sSMTP sendmail emulation); Sun, 11 Jun 2006 09:34:28 -0700 Date: Sun, 11 Jun 2006 09:34:28 -0700 From: Jouni Malinen To: Hannes Tschofenig Subject: Re: [Emu] EAP-GPSK comments Message-ID: <20060611163428.GA9592@jm.kir.nu> References: <20060611042629.GA9582@jm.kir.nu> <448C09D8.7090307@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <448C09D8.7090307@gmx.net> User-Agent: Mutt/1.5.11 X-Spam-Score: -2.6 (--) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: emu@ietf.org, clancy@ltsnet.net 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, Jun 11, 2006 at 02:17:28PM +0200, Hannes Tschofenig wrote: > >ID Server/Client in key derivation: > > > >Variable length ID_Server and ID_Client are concatenated in MK and > >KDF_out derivation. This means that there is no explicitly specified > >boundary between these fields > Do you see an attack if we don't use a delimiter? > http://www.tschofenig.com:8080/eap-gpsk/issue4 I did not look for a concrete attack, but I've seen this kind of explicit field delimiters being added as a fix to number of this kind of constructions and since this does not really add much extra cost in processing, I would add one here, too. > >Failure reporting: > >What is the server/peer to do when something fails? For example, what > >if GPSK-1 does not include a supported ciphersuite. > > There is a mandatory to implement ciphersuite (i.e., Ciphersuite 1) and > hence this case cannot happen. > > Do you have other failure cases in mind? Yes, I just listed the first one. If PSK does not match, server will find an incorrect MAC in GPSK-2. What should it do? Just send EAP-Failure? This is related to how protected result reporting is implemented. In perfect world, there would be no other error cases, but implementation error or an attacker could trigger some other failure cases in GPSK-3 or GPSK-4. I did not find clear instructions on what the implementation should do in such a case. Now I just had to assume that client will drop these silently and server will send EAP-Failure. If protected result protection will be added, that change could also cover a mechanism for reporting any error in the messages (though, error reports for GPSK-1 and GPSK-2 may not really be protected since a shared key is not yet available). > >GKDF-X(Y, Z) definition (Chap. 5): > > > >s%n = int( X / size ) + 1%n = int( (X + size - 1) / size)% > > (previous version would have one extra operation if X mod size = 0) > > > >Need to define how many octets are used for i and X in input to MAC_Y. > >Is this two octets in network byte order? > > I am not so sure to what text you are referring. This is in GKDF-X(Y, Z) definition of chapter 5 (Ciphersuites): GKDF-X (Y, Z) { n = int( X / size ) + 1; /* determine number of output blocks */ M_0 = ""; result = ""; for i=1 to n { M_i = MAC_Y (M_{i-1} || Z || i || X); result = result || M_i; } return truncate (result; X) } The fir part is for determining n. If X=16 and size=16, n = int(16/16)+1 = 2 even though only one MAC_Y operation would have been needed (and n = int(16 + 16 - 1) / 16 = 1). This is just a small rounding off-by-one cleanup. The more important change is in adding explicit definition of how i and X are represented in input to MAC_Y in MAC_Y(M_{i-1} || Z || i || X) construction. This needs added text to specify that i and X are used as 16-bit values in network byte order (assuming that is the intent here; I used that assumption while implementing this since 8-bit X might not have been long enough to cover all needs and 16-bit values seemed large enough for this protocol). > >Input to Integrity MAC (6.1.2 and 6.2.2): > We could make the definition of SEC more clear, namely: > > " > SEC_X(Y): > > SEC is a function that provides integrity protection based on the > chosen ciphersuite. The function SEC uses the algorithm defined by the > selected ciphersuite and applies it to the message content Y with key X. > As an output the message returns Y concatenated with MAC_X(Y). > " This is fine in itself, but.. > Regarding the text in 6.2.2: > > The following instantiation is used: AES-128-CMAC(SK, Input) denotes > the MAC of Input under the key SK. > > where Input refers to the following content: > o Value of SEC_SK in message GPSK-2 This SEC_SK cannot be 'Input'.. Input would be Y in the SEC_X(Y) definition, i.e., this Input is being passed into SEC function as Y.. > We could also write "... input should be the data following OP-Code in > the message." It might be easier. Yes. > Do I miss the issue here? Maybe. My main point was that SEC is a defined function and it does not make sense to pass a function as an Input to AES-128-CMAC.. > Thanks for your review. Please find the updated draft at: > http://www.tschofenig.com/svn/draft-clancy-emu-eap-gpsk/ Thanks. The changes looked fine ot me. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Jun 11 15:30:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpVe3-0004b7-SR; Sun, 11 Jun 2006 15:30:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpVe2-0004b2-Tt for emu@ietf.org; Sun, 11 Jun 2006 15:30:46 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FpVe1-00065b-EI for emu@ietf.org; Sun, 11 Jun 2006 15:30:46 -0400 Received: (qmail invoked by alias); 11 Jun 2006 19:30:42 -0000 Received: from p54984C53.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.76.83] by mail.gmx.net (mp043) with SMTP; 11 Jun 2006 21:30:42 +0200 X-Authenticated: #29516787 Message-ID: <448C6F61.7070702@gmx.net> Date: Sun, 11 Jun 2006 21:30:41 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jouni Malinen Subject: Re: [Emu] EAP-GPSK comments References: <20060611042629.GA9582@jm.kir.nu> <448C09D8.7090307@gmx.net> <20060611163428.GA9592@jm.kir.nu> In-Reply-To: <20060611163428.GA9592@jm.kir.nu> 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: 03169bfe4792634a390035a01a6c6d2f Cc: emu@ietf.org, clancy@ltsnet.net 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 Jouni, Jouni Malinen wrote: > On Sun, Jun 11, 2006 at 02:17:28PM +0200, Hannes Tschofenig wrote: > > >>>ID Server/Client in key derivation: >>> >>>Variable length ID_Server and ID_Client are concatenated in MK and >>>KDF_out derivation. This means that there is no explicitly specified >>>boundary between these fields > > >>Do you see an attack if we don't use a delimiter? >>http://www.tschofenig.com:8080/eap-gpsk/issue4 > > > I did not look for a concrete attack, but I've seen this kind of > explicit field delimiters being added as a fix to number of this kind of > constructions and since this does not really add much extra cost in > processing, I would add one here, too. I am not sure I have seen this type of construction. Maybe I just forgot it. Wouldn't you then have to add a delimiter for each concatenation symbol? > > >>>Failure reporting: >>>What is the server/peer to do when something fails? For example, what >>>if GPSK-1 does not include a supported ciphersuite. >> >>There is a mandatory to implement ciphersuite (i.e., Ciphersuite 1) and >>hence this case cannot happen. >> >>Do you have other failure cases in mind? > > > Yes, I just listed the first one. If PSK does not match, server will > find an incorrect MAC in GPSK-2. What should it do? Just send > EAP-Failure? This is related to how protected result reporting is > implemented. In perfect world, there would be no other error cases, but > implementation error or an attacker could trigger some other failure > cases in GPSK-3 or GPSK-4. I did not find clear instructions on what the > implementation should do in such a case. > > Now I just had to assume that client will drop these silently and server > will send EAP-Failure. If protected result protection will be added, > that change could also cover a mechanism for reporting any error in the > messages (though, error reports for GPSK-1 and GPSK-2 may not really be > protected since a shared key is not yet available). Let me check what other EAP methods do. I created an issue: http://www.tschofenig.com:8080/eap-gpsk/issue5 > > >>>GKDF-X(Y, Z) definition (Chap. 5): >>> >>>s%n = int( X / size ) + 1%n = int( (X + size - 1) / size)% >>>(previous version would have one extra operation if X mod size = 0) >>> >>>Need to define how many octets are used for i and X in input to MAC_Y. >>>Is this two octets in network byte order? >> >>I am not so sure to what text you are referring. > > > This is in GKDF-X(Y, Z) definition of chapter 5 (Ciphersuites): > > GKDF-X (Y, Z) > { > n = int( X / size ) + 1; /* determine number of > output blocks */ > M_0 = ""; > result = ""; > > for i=1 to n { > M_i = MAC_Y (M_{i-1} || Z || i || X); > result = result || M_i; > } > > return truncate (result; X) > } > > > The fir part is for determining n. If X=16 and size=16, > n = int(16/16)+1 = 2 even though only one MAC_Y operation would have > been needed (and n = int(16 + 16 - 1) / 16 = 1). This is just a small > rounding off-by-one cleanup. > > The more important change is in adding explicit definition of how i and > X are represented in input to MAC_Y in MAC_Y(M_{i-1} || Z || i || X) > construction. This needs added text to specify that i and X are used as > 16-bit values in network byte order (assuming that is the intent here; I > used that assumption while implementing this since 8-bit X might not > have been long enough to cover all needs and 16-bit values seemed large > enough for this protocol). > Sounds reasonable to me. >>Input to Integrity MAC (6.1.2 and 6.2.2): > > >>We could make the definition of SEC more clear, namely: >> >>" >> SEC_X(Y): >> >> SEC is a function that provides integrity protection based on the >>chosen ciphersuite. The function SEC uses the algorithm defined by the >>selected ciphersuite and applies it to the message content Y with key X. >>As an output the message returns Y concatenated with MAC_X(Y). >>" > > > This is fine in itself, but.. > > >>Regarding the text in 6.2.2: >> >> The following instantiation is used: AES-128-CMAC(SK, Input) denotes >> the MAC of Input under the key SK. >> >> where Input refers to the following content: >> o Value of SEC_SK in message GPSK-2 > > > This SEC_SK cannot be 'Input'.. Input would be Y in the SEC_X(Y) > definition, i.e., this Input is being passed into SEC function as Y.. > > >>We could also write "... input should be the data following OP-Code in >>the message." It might be easier. > > > Yes. > > >>Do I miss the issue here? > > > Maybe. My main point was that SEC is a defined function and it does not > make sense to pass a function as an Input to AES-128-CMAC.. I don't think we pass a function to AES-128-CMAC. We just use the term SEC as a placeholder for the specific function that is later instantiated Y | MAC_X(Y). This is just an editorial aspect to keep the protocol description in Section 3 easier to read. Ciao Hannes _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Jun 11 16:17:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpWMl-0005GT-SC; Sun, 11 Jun 2006 16:16:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpWMk-0005GO-T3 for emu@ietf.org; Sun, 11 Jun 2006 16:16:58 -0400 Received: from mail2.genealogia.fi ([194.100.116.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpWMh-0002XO-Ht for emu@ietf.org; Sun, 11 Jun 2006 16:16:58 -0400 Received: from dsl017-049-110.sfo4.dsl.speakeasy.net ([69.17.49.110] helo=jm) by mail2.genealogia.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1FpWMe-0005dC-2v; Sun, 11 Jun 2006 23:16:53 +0300 Received: by jm (sSMTP sendmail emulation); Sun, 11 Jun 2006 13:16:15 -0700 Date: Sun, 11 Jun 2006 13:16:15 -0700 From: Jouni Malinen To: Hannes Tschofenig Subject: Re: [Emu] EAP-GPSK comments Message-ID: <20060611201615.GF9592@jm.kir.nu> References: <20060611042629.GA9582@jm.kir.nu> <448C09D8.7090307@gmx.net> <20060611163428.GA9592@jm.kir.nu> <448C6F61.7070702@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <448C6F61.7070702@gmx.net> User-Agent: Mutt/1.5.11 X-Spam-Score: -2.6 (--) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: emu@ietf.org, clancy@ltsnet.net 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, Jun 11, 2006 at 09:30:41PM +0200, Hannes Tschofenig wrote: > >>>Variable length ID_Server and ID_Client are concatenated in MK and > >>>KDF_out derivation. > I am not sure I have seen this type of construction. Maybe I just forgot > it. > > Wouldn't you then have to add a delimiter for each concatenation symbol? As far as I can tell, only the cases where a variable length data is used in a way that there is no clear boundary between two fields (e.g., two variable length fields concatenated together) would need this. Adding 16-bit length field before the variable length ID_Server and ID_Client would resolve this by making it explicit where the boundary between ID_Client and ID_Server is. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Jun 11 17:02:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpX4o-0004cg-8u; Sun, 11 Jun 2006 17:02:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpX4n-0004cb-N1 for emu@ietf.org; Sun, 11 Jun 2006 17:02:29 -0400 Received: from mail2.genealogia.fi ([194.100.116.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpX4m-0007d1-C1 for emu@ietf.org; Sun, 11 Jun 2006 17:02:29 -0400 Received: from dsl017-049-110.sfo4.dsl.speakeasy.net ([69.17.49.110] helo=jm) by mail2.genealogia.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1FpX4d-0005ot-Jd; Mon, 12 Jun 2006 00:02:26 +0300 Received: by jm (sSMTP sendmail emulation); Sun, 11 Jun 2006 14:01:43 -0700 Date: Sun, 11 Jun 2006 14:01:43 -0700 From: Jouni Malinen To: Charles Clancy Subject: Re: [Emu] EAP-GPSK comments Message-ID: <20060611210143.GG9592@jm.kir.nu> References: <20060611042629.GA9582@jm.kir.nu> <448C09D8.7090307@gmx.net> <20060611163428.GA9592@jm.kir.nu> <448C677E.2050607@ltsnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <448C677E.2050607@ltsnet.net> User-Agent: Mutt/1.5.11 X-Spam-Score: -2.6 (--) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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, Jun 11, 2006 at 02:57:02PM -0400, Charles Clancy wrote: > Thanks for your comments. This is quite obviously a -00 document. Many > of the inconsistencies you've pointed out are editorial, and certainly > not intentional. We redesigned large parts of the protocol a couple > times, and unfortunately there are artifacts of previous designs throughout. For -00 version, this was in quite good state. I was able to implement a functional server and peer without any major problems and the number of places needing "liberal interpretations" of the text was very small. > We defined the format for "protected results indication" as out of > scope, mostly to get -00 out. If the WG wants to define it in the > draft, then that's fine with me. However, it might be useful to define > it in a seperate document, since like channel bindings, it could apply > to any method that supports a protected data exchange. As long as it is available at the same time as EAP-GPSK would be taken into use, I don't care that much whether it is included in the same document or not. However, I would like to avoid need for mandatory/optional selection and interoprability issues with some implementations implementing this or not. Making it mandatory for all cases (or not implement it at all, if that is preferred) would make implementations simpler. > We definitely need to add some specific text on what to do if MACs fail. > I imagine the server would send an EAP-Failure if it occured after > packet 2, and others would be silently dropped. One option would be to add a GPSK-ERROR opcode that would be used to information peer of the error. In case the keys have already been derived, this could be used as a protected result indication for the failure case. Peer would reply with GPSK-ERROR and server would finish the negotiation with EAP-Failure. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Jun 11 17:38:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpXdA-0007gF-Is; Sun, 11 Jun 2006 17:38:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpXd8-0007gA-Mg for emu@ietf.org; Sun, 11 Jun 2006 17:37:58 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FpXd7-0000c6-AQ for emu@ietf.org; Sun, 11 Jun 2006 17:37:58 -0400 Received: (qmail invoked by alias); 11 Jun 2006 21:37:55 -0000 Received: from p54984C53.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.76.83] by mail.gmx.net (mp043) with SMTP; 11 Jun 2006 23:37:55 +0200 X-Authenticated: #29516787 Message-ID: <448C8D34.3090707@gmx.net> Date: Sun, 11 Jun 2006 23:37:56 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jouni Malinen Subject: Re: [Emu] EAP-GPSK comments References: <20060611042629.GA9582@jm.kir.nu> <448C09D8.7090307@gmx.net> <20060611163428.GA9592@jm.kir.nu> <448C677E.2050607@ltsnet.net> <20060611210143.GG9592@jm.kir.nu> In-Reply-To: <20060611210143.GG9592@jm.kir.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: emu@ietf.org, Charles Clancy 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 Jouni, ~snip~ > For -00 version, this was in quite good state. I was able to implement a > functional server and peer without any major problems and the number of > places needing "liberal interpretations" of the text was very small. Great. How long did it take you to get something implemented? Will the code be made available? Ciao Hannes _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Jun 11 18:42:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpYdC-0000iI-Kg; Sun, 11 Jun 2006 18:42:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpV9W-00010N-0u for emu@ietf.org; Sun, 11 Jun 2006 14:59:14 -0400 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpV9T-0005E7-Ij for emu@ietf.org; Sun, 11 Jun 2006 14:59:14 -0400 Received: from [192.168.0.3] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (rwcrmhc12) with ESMTP id <20060611185904m1200o398re>; Sun, 11 Jun 2006 18:59:08 +0000 Message-ID: <448C677E.2050607@ltsnet.net> Date: Sun, 11 Jun 2006 14:57:02 -0400 From: Charles Clancy User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jouni Malinen Subject: Re: [Emu] EAP-GPSK comments References: <20060611042629.GA9582@jm.kir.nu> <448C09D8.7090307@gmx.net> <20060611163428.GA9592@jm.kir.nu> In-Reply-To: <20060611163428.GA9592@jm.kir.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 X-Mailman-Approved-At: Sun, 11 Jun 2006 18:42:05 -0400 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Jouni, Thanks for your comments. This is quite obviously a -00 document. Many of the inconsistencies you've pointed out are editorial, and certainly not intentional. We redesigned large parts of the protocol a couple times, and unfortunately there are artifacts of previous designs throughout. We defined the format for "protected results indication" as out of scope, mostly to get -00 out. If the WG wants to define it in the draft, then that's fine with me. However, it might be useful to define it in a seperate document, since like channel bindings, it could apply to any method that supports a protected data exchange. Sections 6.1.3 and 6.2.3 are definitely in error, and should include the KDFData fields. Adding length fields to ID_Server and ID_Client in the KDF can't hurt. Not doing so won't introduce any practical attacks, but it would strenghten the binding between identity and key. We definitely need to add some specific text on what to do if MACs fail. I imagine the server would send an EAP-Failure if it occured after packet 2, and others would be silently dropped. -- Dr. Charles Clancy, Research Scientist Laboratory for Telecommunications Sciences clancy@ltsnet.net Jouni Malinen wrote: > On Sun, Jun 11, 2006 at 02:17:28PM +0200, Hannes Tschofenig wrote: > > >>>ID Server/Client in key derivation: >>> >>>Variable length ID_Server and ID_Client are concatenated in MK and >>>KDF_out derivation. This means that there is no explicitly specified >>>boundary between these fields > > >>Do you see an attack if we don't use a delimiter? >>http://www.tschofenig.com:8080/eap-gpsk/issue4 > > > I did not look for a concrete attack, but I've seen this kind of > explicit field delimiters being added as a fix to number of this kind of > constructions and since this does not really add much extra cost in > processing, I would add one here, too. > > >>>Failure reporting: >>>What is the server/peer to do when something fails? For example, what >>>if GPSK-1 does not include a supported ciphersuite. >> >>There is a mandatory to implement ciphersuite (i.e., Ciphersuite 1) and >>hence this case cannot happen. >> >>Do you have other failure cases in mind? > > > Yes, I just listed the first one. If PSK does not match, server will > find an incorrect MAC in GPSK-2. What should it do? Just send > EAP-Failure? This is related to how protected result reporting is > implemented. In perfect world, there would be no other error cases, but > implementation error or an attacker could trigger some other failure > cases in GPSK-3 or GPSK-4. I did not find clear instructions on what the > implementation should do in such a case. > > Now I just had to assume that client will drop these silently and server > will send EAP-Failure. If protected result protection will be added, > that change could also cover a mechanism for reporting any error in the > messages (though, error reports for GPSK-1 and GPSK-2 may not really be > protected since a shared key is not yet available). > > >>>GKDF-X(Y, Z) definition (Chap. 5): >>> >>>s%n = int( X / size ) + 1%n = int( (X + size - 1) / size)% >>>(previous version would have one extra operation if X mod size = 0) >>> >>>Need to define how many octets are used for i and X in input to MAC_Y. >>>Is this two octets in network byte order? >> >>I am not so sure to what text you are referring. > > > This is in GKDF-X(Y, Z) definition of chapter 5 (Ciphersuites): > > GKDF-X (Y, Z) > { > n = int( X / size ) + 1; /* determine number of > output blocks */ > M_0 = ""; > result = ""; > > for i=1 to n { > M_i = MAC_Y (M_{i-1} || Z || i || X); > result = result || M_i; > } > > return truncate (result; X) > } > > > The fir part is for determining n. If X=16 and size=16, > n = int(16/16)+1 = 2 even though only one MAC_Y operation would have > been needed (and n = int(16 + 16 - 1) / 16 = 1). This is just a small > rounding off-by-one cleanup. > > The more important change is in adding explicit definition of how i and > X are represented in input to MAC_Y in MAC_Y(M_{i-1} || Z || i || X) > construction. This needs added text to specify that i and X are used as > 16-bit values in network byte order (assuming that is the intent here; I > used that assumption while implementing this since 8-bit X might not > have been long enough to cover all needs and 16-bit values seemed large > enough for this protocol). > > > >>>Input to Integrity MAC (6.1.2 and 6.2.2): > > >>We could make the definition of SEC more clear, namely: >> >>" >> SEC_X(Y): >> >> SEC is a function that provides integrity protection based on the >>chosen ciphersuite. The function SEC uses the algorithm defined by the >>selected ciphersuite and applies it to the message content Y with key X. >>As an output the message returns Y concatenated with MAC_X(Y). >>" > > > This is fine in itself, but.. > > >>Regarding the text in 6.2.2: >> >> The following instantiation is used: AES-128-CMAC(SK, Input) denotes >> the MAC of Input under the key SK. >> >> where Input refers to the following content: >> o Value of SEC_SK in message GPSK-2 > > > This SEC_SK cannot be 'Input'.. Input would be Y in the SEC_X(Y) > definition, i.e., this Input is being passed into SEC function as Y.. > > >>We could also write "... input should be the data following OP-Code in >>the message." It might be easier. > > > Yes. > > >>Do I miss the issue here? > > > Maybe. My main point was that SEC is a defined function and it does not > make sense to pass a function as an Input to AES-128-CMAC.. > > >>Thanks for your review. Please find the updated draft at: >>http://www.tschofenig.com/svn/draft-clancy-emu-eap-gpsk/ > > > Thanks. The changes looked fine ot me. > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Jun 11 19:09:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZ3U-0006u9-3Y; Sun, 11 Jun 2006 19:09:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZ3T-0006u2-8h for emu@ietf.org; Sun, 11 Jun 2006 19:09:15 -0400 Received: from mail2.genealogia.fi ([194.100.116.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpZ3O-0001pR-ST for emu@ietf.org; Sun, 11 Jun 2006 19:09:15 -0400 Received: from dsl017-049-110.sfo4.dsl.speakeasy.net ([69.17.49.110] helo=jm) by mail2.genealogia.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1FpZ3G-00063K-J2; Mon, 12 Jun 2006 02:09:09 +0300 Received: by jm (sSMTP sendmail emulation); Sun, 11 Jun 2006 16:08:25 -0700 Date: Sun, 11 Jun 2006 16:08:25 -0700 From: Jouni Malinen To: Hannes Tschofenig Subject: Re: [Emu] EAP-GPSK comments Message-ID: <20060611230825.GH9592@jm.kir.nu> References: <20060611042629.GA9582@jm.kir.nu> <448C09D8.7090307@gmx.net> <20060611163428.GA9592@jm.kir.nu> <448C677E.2050607@ltsnet.net> <20060611210143.GG9592@jm.kir.nu> <448C8D34.3090707@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <448C8D34.3090707@gmx.net> User-Agent: Mutt/1.5.11 X-Spam-Score: -2.6 (--) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: emu@ietf.org, Charles Clancy 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, Jun 11, 2006 at 11:37:56PM +0200, Hannes Tschofenig wrote: > >For -00 version, this was in quite good state. I was able to implement a > >functional server and peer without any major problems and the number of > >places needing "liberal interpretations" of the text was very small. > > Great. How long did it take you to get something implemented? Maybe a total of eight or so hours which includes reading the draft and writing the review comments. Implementation itself with quick tests took only couple of hours. Though, I had already implemented EAP-PSK/PAX/SAKE before and that certainly helped here since I had all the EAP framework and crypto routines available. > Will the code be made available? Server side is included in hostapd (integrated EAP server) and peer in wpa_supplicant. The current development branch snapshot includes the implementation (http://hostap.epitest.fi/releases/snapshots/). For testing, I'm using hostapd as a RADIUS server with EAP-GPSK server and eapol_test (test tool from wpa_supplicant) as a EAP-GPSK peer and IEEE 802.1X authenticator/RADIUS client. EAP-GPSK parts are in hostapd/eap_gpsk.c and wpa_supplicant/eap_gpsk*.[ch]. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Jun 11 21:15:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpb1S-0003mp-8n; Sun, 11 Jun 2006 21:15:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpb1Q-0003mB-Tg for emu@ietf.org; Sun, 11 Jun 2006 21:15:16 -0400 Received: from bay106-f18.bay106.hotmail.com ([65.54.161.28] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpb1P-0004Kz-KY for emu@ietf.org; Sun, 11 Jun 2006 21:15:16 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 11 Jun 2006 18:15:15 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 12 Jun 2006 01:15:14 GMT X-Originating-IP: [24.16.73.85] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <20060611163428.GA9592@jm.kir.nu> From: "Bernard Aboba" To: jkmaline@cc.hut.fi, Hannes.Tschofenig@gmx.net Bcc: Subject: Re: [Emu] EAP-GPSK comments Date: Sun, 11 Jun 2006 18:15:14 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 12 Jun 2006 01:15:15.0000 (UTC) FILETIME=[A8FB1380:01C68DBD] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: emu@ietf.org, clancy@ltsnet.net 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 >Yes, I just listed the first one. If PSK does not match, server will >find an incorrect MAC in GPSK-2. What should it do? Just send EAP-Failure? I would recommend silent discard for packets with MAC failures, since that is most resilient against forgery. Otherwise, an attacker only needs to correctly guess the Identifier (not hard, there are only 256 choices) and it can abort the EAP conversation. >This is related to how protected result reporting is >implemented. If the PSK has not been correctly configured, then it makes little sense to attempt to send a protected result indication, since the MAC on that message would also fail to verify. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Jun 11 22:29:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpcBE-0006HP-0V; Sun, 11 Jun 2006 22:29:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpcBC-0006HK-UQ for emu@ietf.org; Sun, 11 Jun 2006 22:29:26 -0400 Received: from dispatch.cs.umd.edu ([128.8.128.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpcBB-0002FF-Mf for emu@ietf.org; Sun, 11 Jun 2006 22:29:26 -0400 Received: from delegate.pc.cs.umd.edu (exchange.cs.umd.edu [128.8.130.248]) by dispatch.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id k5C2TFvX008489; Sun, 11 Jun 2006 22:29:15 -0400 Received: from [192.168.0.5] ([68.49.199.146]) by delegate.pc.cs.umd.edu with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Jun 2006 22:29:09 -0400 Message-ID: <448CD19C.9010608@cs.umd.edu> Date: Sun, 11 Jun 2006 22:29:48 -0400 From: Charles Clancy User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [Emu] EAP-GPSK comments References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2006 02:29:09.0861 (UTC) FILETIME=[FC5D2950:01C68DC7] X-CSD-MailScanner-Information: Please email staff@cs.umd.edu for more information X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (score=0.374, required 5, autolearn=disabled, DNS_FROM_RFC_ABUSE 0.37) X-MailScanner-From: clancy@cs.umd.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: emu@ietf.org, clancy@ltsnet.net 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: >> Yes, I just listed the first one. If PSK does not match, server will >> find an incorrect MAC in GPSK-2. What should it do? Just send >> EAP-Failure? > > I would recommend silent discard for packets with MAC failures, since > that is most resilient against forgery. Otherwise, an attacker only > needs to correctly guess the Identifier (not hard, there are only 256 > choices) and it can abort the EAP conversation. If the EAP Server silently drops EAP-Response/GPSK-2, then how would the client know the PSK is incorrect? Would the conversation just time out? Perhaps we should add a "MAC Failed" message as Jouni suggested? Sending it would leave the server state unchanged. -- 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 Jun 11 23:11:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpcph-0000YY-SU; Sun, 11 Jun 2006 23:11:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpcpg-0000YT-B6 for emu@ietf.org; Sun, 11 Jun 2006 23:11:16 -0400 Received: from bay106-f23.bay106.hotmail.com ([65.54.161.33] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpcpf-0007Pn-2R for emu@ietf.org; Sun, 11 Jun 2006 23:11:16 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 11 Jun 2006 20:11:14 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 12 Jun 2006 03:11:09 GMT X-Originating-IP: [24.16.73.85] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <448CD19C.9010608@cs.umd.edu> From: "Bernard Aboba" To: clancy@cs.umd.edu Bcc: Subject: Re: [Emu] EAP-GPSK comments Date: Sun, 11 Jun 2006 20:11:09 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 12 Jun 2006 03:11:14.0367 (UTC) FILETIME=[DD1634F0:01C68DCD] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: emu@ietf.org, clancy@ltsnet.net 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 >If the EAP Server silently drops EAP-Response/GPSK-2, then how would the >client know the PSK is incorrect? Would the conversation just time out? Yes. >Perhaps we should add a "MAC Failed" message as Jouni suggested? Sending it >would leave the server state unchanged. What is the peer supposed to do with this? If it isn't authenticated, then an attacker can forge it and cause the peer to abort the conversation. If it is authenticated, then if the PSK is incorrectly configured, the peer will drop it. Since an attacker can send a forged packet and to cause this message to be sent, about all the peer could do with it is log it and leave its own state unchanged. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Jun 11 23:58:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpdZq-00085N-5j; Sun, 11 Jun 2006 23:58:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpdZp-000849-FO for emu@ietf.org; Sun, 11 Jun 2006 23:58:57 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpdZo-0003kU-2f for emu@ietf.org; Sun, 11 Jun 2006 23:58:57 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5C3wljP001472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 11 Jun 2006 20:58:47 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-199.qualcomm.com [10.50.76.199]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5C3whgb016635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 11 Jun 2006 20:58:45 -0700 (PDT) Message-Id: <7.0.1.0.2.20060611205606.041abbb0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 11 Jun 2006 20:58:41 -0700 To: Charles Clancy , Bernard Aboba From: Lakshminath Dondeti Subject: Re: [Emu] EAP-GPSK comments In-Reply-To: <448CD19C.9010608@cs.umd.edu> References: <448CD19C.9010608@cs.umd.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: emu@ietf.org, clancy@ltsnet.net X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org At 07:29 PM 6/11/2006, Charles Clancy wrote: >Bernard Aboba wrote: > >> Yes, I just listed the first one. If PSK does not match, server will > >> find an incorrect MAC in GPSK-2. What should it do? Just send > >> EAP-Failure? > > > > I would recommend silent discard for packets with MAC failures, since > > that is most resilient against forgery. Otherwise, an attacker only > > needs to correctly guess the Identifier (not hard, there are only 256 > > choices) and it can abort the EAP conversation. > >If the EAP Server silently drops EAP-Response/GPSK-2, then how would >the client know the PSK is incorrect? Would the conversation just time out? > >Perhaps we should add a "MAC Failed" message as Jouni suggested? >Sending it would leave the server state unchanged. I am not a fan of MAC failed messages, to say the least. Those would allow an adversary to start guessing the PSK and have the guesses deterministically validated by the server. I would however send a generic failure message, if it helps. I also agree with Bernard's take on this. regards, Lakshminath >-- >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 Jun 12 01:56:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpfPb-0007Pp-7i; Mon, 12 Jun 2006 01:56:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpfPZ-0007BX-Em for emu@ietf.org; Mon, 12 Jun 2006 01:56:29 -0400 Received: from mail2.genealogia.fi ([194.100.116.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpfMi-0007C5-Jc for emu@ietf.org; Mon, 12 Jun 2006 01:53:33 -0400 Received: from dsl017-049-110.sfo4.dsl.speakeasy.net ([69.17.49.110] helo=jm) by mail2.genealogia.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1FpfMY-0000Wt-Kb; Mon, 12 Jun 2006 08:53:24 +0300 Received: by jm (sSMTP sendmail emulation); Sun, 11 Jun 2006 22:52:46 -0700 Date: Sun, 11 Jun 2006 22:52:46 -0700 From: Jouni Malinen To: Lakshminath Dondeti Subject: Re: [Emu] EAP-GPSK comments Message-ID: <20060612055246.GL9592@jm.kir.nu> References: <448CD19C.9010608@cs.umd.edu> <7.0.1.0.2.20060611205606.041abbb0@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7.0.1.0.2.20060611205606.041abbb0@qualcomm.com> User-Agent: Mutt/1.5.11 X-Spam-Score: -2.6 (--) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Bernard Aboba , emu@ietf.org, clancy@ltsnet.net 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, Jun 11, 2006 at 08:58:41PM -0700, Lakshminath Dondeti wrote: > I am not a fan of MAC failed messages, to say the least. Those would > allow an adversary to start guessing the PSK and have the guesses > deterministically validated by the server. I would however send a > generic failure message, if it helps. I also agree with Bernard's > take on this. Based on the number of questions I see from end users wanting to know what exactly went wrong and how to diagnose authentication failures, it would be nice if there were a better mechanism for figuring out that PSK could have been wrong that just waiting for a timeout. Unfortunately, in the case of GPSK-2, there are no shared keys to authenticate this information. Any errors for GPSK-3 or 4 could be reported with a MAC. Generic error message can be faked since the peer has no way of knowing whether the server derived the same key as it did and would have to ignore MAC failure in the error message. Server could send some kind of error notification that the peer is free to ignore based on its security policy. That would allow a faster reaction on the client side and at least possibility of the peer implementation determining that the reason for failed authentication was in server not liking something about GPSK-2 instead of it being unclear whether the server even received GPSK-2. I don't want to open any security issues with this, but it would be nice to provide something to make it easier to report somewhat meaningful report to the user. Now, I can just report "possible PSK mismatch or server unreachable" after a (potentially long) timeout if GPSK-2 with incorrect MAC is silently ignored. Would there be any mechanism to make this report more informational for the user? -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Jun 12 06:57:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpk6m-0002tu-UP; Mon, 12 Jun 2006 06:57:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpk6l-0002n6-Iq for emu@ietf.org; Mon, 12 Jun 2006 06:57:23 -0400 Received: from rwcrmhc14.comcast.net ([216.148.227.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpk6h-00032G-8c for emu@ietf.org; Mon, 12 Jun 2006 06:57:23 -0400 Received: from [192.168.0.3] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (rwcrmhc14) with ESMTP id <20060612105717m1400di53me>; Mon, 12 Jun 2006 10:57:18 +0000 Message-ID: <448D4814.3000105@cs.umd.edu> Date: Mon, 12 Jun 2006 06:55:16 -0400 From: Charles Clancy User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [Emu] EAP-GPSK comments 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: 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 Bernard Aboba wrote: >> If the EAP Server silently drops EAP-Response/GPSK-2, then how would >> the client know the PSK is incorrect? Would the conversation just >> time out? > > > Yes. > >> Perhaps we should add a "MAC Failed" message as Jouni suggested? >> Sending it would leave the server state unchanged. > > > What is the peer supposed to do with this? If it isn't authenticated, > then an attacker can forge it and cause the peer to abort the > conversation. If it is authenticated, then if the PSK is incorrectly > configured, the peer will drop it. Since an attacker can send a forged > packet and to cause this message to be sent, about all the peer could do > with it is log it and leave its own state unchanged. > What sort of attacker are we trying to stop here? A non-MitM, eavesdropping DoS attacker? Certainly a MitM attacker can just drop all our packets. If the MAC in GPSK-2 fails, the server can certainly send an authenticated response. He has all the necessary information to compute the proper session keys. The client jsut wouldn't be able to verify the MAC. Do the following cases sound right according to normal EAP behavior? Case 1: received one MAC-failed message with invalid MAC = PSK incorrect Case 2: received two or more MAC-failed messages with differing invalid MAC = PSK incorrect, and being DoS'd The timeout approach works too. In that case, we can distinguish "invalid PSK" from "EAP Server unreachable". If the EAP Server is unreachable, the client would never have received EAP-GPSK1. -- 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 Jun 12 14:49:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FprTV-0004tm-VT; Mon, 12 Jun 2006 14:49:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FprTV-0004th-3o for emu@ietf.org; Mon, 12 Jun 2006 14:49:21 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FprTT-0006bF-Pf for emu@ietf.org; Mon, 12 Jun 2006 14:49:21 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 12 Jun 2006 11:49:19 -0700 X-IronPort-AV: i="4.05,229,1146466800"; d="scan'208"; a="1824165733:sNHT35622492" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k5CInJeM025602 for ; Mon, 12 Jun 2006 11:49:19 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5CImtcr013476 for ; Mon, 12 Jun 2006 11:49:19 -0700 (PDT) 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.211); Mon, 12 Jun 2006 14:49:17 -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] Enhanced EAP-TLS Date: Mon, 12 Jun 2006 14:49:16 -0400 Message-ID: <9958B444368E884DBB215F3FEF36F5B702722DC6@xmb-rtp-212.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Enhanced EAP-TLS Thread-Index: AcaLNlQSq0YF1VjgQFiMo/F8W8E07ADGdwDw From: "Hao Zhou \(hzhou\)" To: "Joseph Salowey \(jsalowey\)" , X-OriginalArrivalTime: 12 Jun 2006 18:49:17.0273 (UTC) FILETIME=[E8501C90:01C68E50] DKIM-Signature: a=rsa-sha1; q=dns; l=1150; t=1150138159; x=1151002159; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=hzhou@cisco.com; z=From:=22Hao=20Zhou=20\(hzhou\)=22=20 |Subject:RE=3A=20[Emu]=20Enhanced=20EAP-TLS; X=v=3Dcisco.com=3B=20h=3DVsDFZpvXcwzqAt+4bYYofVQ/+yI=3D; b=kURFQNCV3JaTQr7CS/QvRrgbHKtvDelm/mzAZGTYSdijiV0PeCG+5uhP3eQ5B+wUwU98nwxC YqLwfiw9uYehXVIPFfS65vEeNSN/5rVDI3G73lGXXAJy4mn/ou8EC0Xi; Authentication-Results: sj-dkim-6.cisco.com; header.From=hzhou@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 about exchanges of arbitrary data in the protected tunnel (may include channel binding), optional server side authentication with inner method support for weak password. Would it make sense to create a single TLS based tunneling method instead of two separate ones, one for enhanced TLS, and another one for tunneling method support for weak password? > -----Original Message----- > From: Joseph Salowey (jsalowey)=20 > Sent: Thursday, June 08, 2006 4:01 PM > To: emu@ietf.org > Subject: [Emu] Enhanced EAP-TLS >=20 > One of our charter items is to develop an enhanced EAP-TLS=20 > that can support features that are not possible to support in=20 > a manner that is backward compatible with RFC2716.=20 >=20 > Some of the potential features on the list include: >=20 > 1. Additional cipher suites (PSK, Kerberos, ECC) 2. TLS=20 > extensions 3. Channel Bindings 4. Identity protection >=20 > Are there additional features that should be supported by an=20 > enhanced TLS? =20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Jun 12 19:15:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpvdP-0004q5-Db; Mon, 12 Jun 2006 19:15:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpvdO-0004oW-8b for emu@ietf.org; Mon, 12 Jun 2006 19:15:50 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpvdL-0004cx-Um for emu@ietf.org; Mon, 12 Jun 2006 19:15:50 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 12 Jun 2006 16:15:45 -0700 X-IronPort-AV: i="4.06,124,1149490800"; d="scan'208"; a="1824347759:sNHT4991211246" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k5CNFiQ6006167 for ; Mon, 12 Jun 2006 16:15:44 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5CNFi9s024948 for ; Mon, 12 Jun 2006 16:15:44 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 16:15:44 -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, 12 Jun 2006 16:15:44 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tentative EMU meeting slot Thread-Index: AcaOdDQbKs2lqjQAQ6esKsRaFeDRag== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 12 Jun 2006 23:15:44.0755 (UTC) FILETIME=[21984430:01C68E76] DKIM-Signature: a=rsa-sha1; q=dns; l=816; t=1150154144; x=1151018144; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:Tentative=20EMU=20meeting=20slot; X=v=3Dcisco.com=3B=20h=3DyLwBgG1XvBkeHxy3/Qh1lrcZLOE=3D; b=tS9IW63lNOwAcdgI1Z6WNP4xCYyOtmi9fHg/6EWqPNV4kwK2qSf3zfXsofAu1CWSR2JX5TkI h71rZms7sfdw5reFouVtB4spHakmx7Ys6Tobsr3KIc3fA73E+UTbv0BD; Authentication-Results: sj-dkim-1.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Emu] Tentative EMU meeting slot 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 A tentative IETF 66 meeting schedule is available at: https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_num=3D= 66 Note that this agenda is still subject to change. EMU is scheduled for: WEDNESDAY, July 12, 2006 0800-1700 IETF Registration - Foyer 500D 0800-0900 Continental Breakfast - Foyer 500D 0900-1130 Morning Session I Room 513B APP calsify Calendaring and Scheduling Standards Simplification WG Room 518AB INT autoconf Ad-Hoc Network Autoconfiguration WG Room 519B IRTF MobOpts IP Mobility Optimizations Research Group Room 515 OPS v6ops IPv6 Operations WG Room 513C-F RAI mmusic Multiparty Multimedia Session Control WG Room 520DEF RTG mpls Multiprotocol Label Switching WG Room 519A SEC emu EAP Method Update WG Room 520ABC TSV nsis Next Steps in Signaling WG _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Jun 14 14:13:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqZsN-0006MF-4w; Wed, 14 Jun 2006 14:13:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqZsL-0006GE-K6 for emu@ietf.org; Wed, 14 Jun 2006 14:13:57 -0400 Received: from bay106-f13.bay106.hotmail.com ([65.54.161.23] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqZsK-0007dz-9K for emu@ietf.org; Wed, 14 Jun 2006 14:13:57 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 14 Jun 2006 11:13:55 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Wed, 14 Jun 2006 18:13:50 GMT X-Originating-IP: [131.107.0.82] 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: Wed, 14 Jun 2006 11:13:50 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 14 Jun 2006 18:13:55.0369 (UTC) FILETIME=[4C62C190:01C68FDE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Emu] EAP-TLS implementers? 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 EMU WG charter requires that RFC 2716bis remain backward compatible with existing EAP-TLS implementations: "- An update to RFC 2716 to bring EAP-TLS into standards track, clarify specification, interoperability, and implementation issues gathered over the years, and update the document to meet the requirements of RFC 3748, RFC 4017, and EAP keying framework documents. Backwards compatibility with RFC 2716 is a requirement." Given the widespread interoperability problems experienced with TLS implementations, the question has arisen as what if any TLS functionality introduced after TLS v1.0 can be included in RFC 2716bis. To attempt to address this, we would like to assemble a team of EAP-TLS implementers which may participate in impromptu tests of EAP-TLS interoperability (such as exchanges of RADIUS/EAP-TLS traffic over the Internet). If you are interested in participating, please contact me. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Jun 19 11:50:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsM1E-0004vJ-HB; Mon, 19 Jun 2006 11:50:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsM1D-0004vE-LV for emu@ietf.org; Mon, 19 Jun 2006 11:50:27 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsM1C-0005b6-7z for emu@ietf.org; Mon, 19 Jun 2006 11:50:27 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-6.cisco.com with ESMTP; 19 Jun 2006 08:50:25 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k5JFoPtV020378 for ; Mon, 19 Jun 2006 08:50:25 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5JFoPIs011199 for ; Mon, 19 Jun 2006 08:50:25 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Jun 2006 08:50:25 -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] Enhanced EAP-TLS Date: Mon, 19 Jun 2006 08:50:24 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Enhanced EAP-TLS Thread-Index: AcaLNlQSq0YF1VjgQFiMo/F8W8E07ADGdwDwAVl781A= From: "Joseph Salowey \(jsalowey\)" To: "Hao Zhou \(hzhou\)" , X-OriginalArrivalTime: 19 Jun 2006 15:50:25.0550 (UTC) FILETIME=[149962E0:01C693B8] DKIM-Signature: a=rsa-sha1; q=dns; l=2313; t=1150732225; x=1151596225; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:RE=3A=20[Emu]=20Enhanced=20EAP-TLS; X=v=3Dcisco.com=3B=20h=3DxeIry+2odsjbgnZ9vfwKVeaKh9c=3D; b=RWMeErtrgO93MW3c6c4tKZB9BrAtZF26gNGp9NKlbfFtQEt0pi0cyzw0UiOFFbIupIKaSL63 KRWIxoF05QjwJhHrjzRJ79KzT3kINAp3CSqWQgKjY0WCKHprlOjlcdpr; Authentication-Results: sj-dkim-8.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 Exchanging data within the TLS tunnel is one way to achieve channel bindings. I could see advantages to having a single method for legacy password database support and enhanced TLS. At least it seems the core specification could be the same. =20 I'm not quite sure how to handle EAP negotiation with multiple credentials supported by the same method. For example, I don't see a problem with backwards compatibility in adding additional ciphersuite support to RFC2617bis to PSK and other credentials; I believe that most TLS implementations handle ciphersuite negotiation correctly. There may a potential problem because if ciphersuite negotiation fails the only way within EAP to try a new EAP method is to restart the entire conversation in the lower layer. This may be less than ideal, but I'm not sure it is too much of a problem in reality.=20 Joe > -----Original Message----- > From: Hao Zhou (hzhou)=20 > Sent: Monday, June 12, 2006 11:49 AM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] Enhanced EAP-TLS >=20 > What about exchanges of arbitrary data in the protected=20 > tunnel (may include channel binding), optional server side=20 > authentication with inner method support for weak password.=20 > Would it make sense to create a single TLS based tunneling=20 > method instead of two separate ones, one for enhanced TLS,=20 > and another one for tunneling method support for weak password? >=20 > > -----Original Message----- > > From: Joseph Salowey (jsalowey) > > Sent: Thursday, June 08, 2006 4:01 PM > > To: emu@ietf.org > > Subject: [Emu] Enhanced EAP-TLS > >=20 > > One of our charter items is to develop an enhanced EAP-TLS that can=20 > > support features that are not possible to support in a=20 > manner that is=20 > > backward compatible with RFC2716. > >=20 > > Some of the potential features on the list include: > >=20 > > 1. Additional cipher suites (PSK, Kerberos, ECC) 2. TLS=20 > extensions 3.=20 > > Channel Bindings 4. Identity protection > >=20 > > Are there additional features that should be supported by=20 > an enhanced=20 > > TLS? > >=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 Thu Jun 22 00:31:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtGqV-0004NI-1k; Thu, 22 Jun 2006 00:31:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtGqT-0004NA-GZ for emu@ietf.org; Thu, 22 Jun 2006 00:31:09 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtGqS-0002Ab-7M for emu@ietf.org; Thu, 22 Jun 2006 00:31:09 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 21 Jun 2006 21:31:07 -0700 X-IronPort-AV: i="4.06,164,1149490800"; d="scan'208"; a="298954046:sNHT96009182" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k5M4V76D031133 for ; Wed, 21 Jun 2006 21:31:07 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5M4V7CU017166 for ; Wed, 21 Jun 2006 21:31:07 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Jun 2006 21:31:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Jun 2006 21:31:06 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Agenda for EMU working Group Thread-Index: AcaVjNMM6GS6CWFKQRqUROs+f7aFxw== From: "Joseph Salowey \(jsalowey\)" Cc: X-OriginalArrivalTime: 22 Jun 2006 04:31:07.0434 (UTC) FILETIME=[AE1BB0A0:01C695B4] DKIM-Signature: a=rsa-sha1; q=dns; l=656; t=1150950667; x=1151814667; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:Draft=20Agenda=20for=20EMU=20working=20Group; X=v=3Dcisco.com=3B=20h=3D2WS67Ui0jTZOL+tCMcRo8ap7dJw=3D; b=FVxA6EHayiCfPrejrwazA+5fT/8kLpuse89UaAaC38RsOi2uRq5bsRKCCTBFFjV3Gi9ZcODq u4aqrX01XwWNZTNdlZlGU/xbEWMR7M34wxYqFZ86LD87zzpVdhHcLDzw; Authentication-Results: sj-dkim-4.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Emu] Draft Agenda for EMU working Group X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Below is a draft agenda for the EMU working group meeting. Let me know if you have specific items for the agenda.=20 Thanks, Joe EMU WG - WEDNESDAY, July 12, 2006 - 0900-1130=20 ---------------------------------------------- Blue sheets - Agenda Bashing (5 min) PSK ---- GPSK Presentation (15 min) - Hannes/Charles GPSK Discussion (30 min)=20 PSK Working Group Item (10 min) EAP-TLS=20 -------- RFC2716bis update - (15 min) - Bernard EAP-TLS enhancements discussion (40 min) - TBD Password based mechanism ------------------------- Requirements - 15 min - TBD Misc ----- Implementation issues - 10 min - Dave Mitton _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Jun 22 00:34:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtGty-0005uB-Pm; Thu, 22 Jun 2006 00:34:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtGtx-0005u4-PV for emu@ietf.org; Thu, 22 Jun 2006 00:34:45 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtGtw-0003Xw-78 for emu@ietf.org; Thu, 22 Jun 2006 00:34:45 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 21 Jun 2006 21:34:41 -0700 X-IronPort-AV: i="4.06,164,1149490800"; d="tmp'208?scan'208,208"; a="298955137:sNHT5898204820" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k5M4YeXx000448 for ; Wed, 21 Jun 2006 21:34:40 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5M4YeCU018889 for ; Wed, 21 Jun 2006 21:34:40 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Jun 2006 21:34:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C695B5.2CD3BCF9" Date: Wed, 21 Jun 2006 21:34:37 -0700 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [TLS] Fwd: I-D ACTION:draft-pettersen-tls-interop-experience-00.txt Thread-Index: AcaVjwhzUpjTYse+RNe65WNagXs96AAJgxPw From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 22 Jun 2006 04:34:40.0306 (UTC) FILETIME=[2CFD6120:01C695B5] DKIM-Signature: a=rsa-sha1; q=dns; l=4910; t=1150950880; x=1151814880; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:FW=3A=20[TLS]=20Fwd=3A=20I-D=20ACTION=3Adraft-pettersen-tls-interop-expe rience-00.txt=20; X=v=3Dcisco.com=3B=20h=3D9QXRr3wFNH6/XjBqYxvrd3/L0uU=3D; b=Uc/Tz9xIfPlXnPY5AJ4QylQ3Buxwb8I9jCDjHlHnsEJRAGal0ZDr+bbq/4HUjAHAe/Y2TNhX Y1fMmt64Lz/VwGPcoiEW0IXDQjSm+T0NeW9zq70bmXZreBBxzRZYyhtG; Authentication-Results: sj-dkim-4.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( 43 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Subject: [Emu] FW: [TLS] Fwd: I-D ACTION:draft-pettersen-tls-interop-experience-00.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C695B5.2CD3BCF9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: Yngve N. Pettersen [mailto:yngve@opera.com]=20 > Sent: Wednesday, June 21, 2006 5:01 PM > To: Transport Layer Security working group > Subject: [TLS] Fwd: I-D=20 > ACTION:draft-pettersen-tls-interop-experience-00.txt=20 >=20 >=20 >=20 > ------- Forwarded message ------- > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-pettersen-tls-interop-experience-00.txt > Date: Wed, 21 Jun 2006 12:50:01 -0700 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 >=20 > Title : Clientside interoperability experiences for > the SSL and TLS protocols > Author(s) : Y. Pettersen > Filename : draft-pettersen-tls-interop-experience-00.txt > Pages : 27 > Date : 2006-6-21 > =09 > This document presents a number of problems encountered when > implementing TLS 1.0, TLS 1.0 and TLS Extensions for clients, and > their consequences. The problems include servers that refuse to > connect with clients supporting newer versions of the protocol, or > does not handle such negotiation properly. Other problems > encountered are incorrect use of values in the protocol messages. >=20 > The consequences of these problems range from delayed=20 > introduction of > new protocol versions and features, to fallback=20 > mechanisms that may > disable protocol security features, to implementations that cannot > interoperate with some other implementations. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-pettersen-tls-intero p-experience-00.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > 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. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then > "get draft-pettersen-tls-interop-experience-00.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE=20 > /internet-drafts/draft-pettersen-tls-interop-experience-00.txt". > =09 > 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=20 > 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. > =09 > =09 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 >=20 >=20 > -- > Sincerely, > Yngve N. Pettersen >=20 > ******************************************************************** > Senior Developer Email: yngve@opera.com > Opera Software ASA http://www.opera.com/ > Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 > ******************************************************************** >=20 ------_=_NextPart_001_01C695B5.2CD3BCF9 Content-Type: application/octet-stream; name="attachment185.tmp" Content-Transfer-Encoding: base64 Content-Description: attachment185.tmp Content-Disposition: attachment; filename="attachment185.tmp" Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNi02LTIxMTI1NTIxLkkt REBpZXRmLm9yZz4NCg0KRU5DT0RJTkcgbWltZQ0KRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LXBldHRlcnNlbi10bHMtaW50ZXJvcC1leHBlcmllbmNlLTAwLnR4dA0K ------_=_NextPart_001_01C695B5.2CD3BCF9 Content-Type: application/octet-stream; name="attachment186.tmp" Content-Transfer-Encoding: base64 Content-Description: attachment186.tmp Content-Disposition: attachment; filename="attachment186.tmp" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C695B5.2CD3BCF9 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_001_01C695B5.2CD3BCF9-- From emu-bounces@ietf.org Sat Jun 24 21:51:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuJmI-0001Lb-Nq; Sat, 24 Jun 2006 21:51:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuJmG-0001LW-Id for emu@ietf.org; Sat, 24 Jun 2006 21:51:08 -0400 Received: from bay106-f16.bay106.hotmail.com ([65.54.161.26] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuJmG-00049q-1s for emu@ietf.org; Sat, 24 Jun 2006 21:51:08 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 24 Jun 2006 18:51:07 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Sun, 25 Jun 2006 01:51:06 GMT X-Originating-IP: [71.38.130.70] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: emu@ietf.org Bcc: Date: Sat, 24 Jun 2006 18:51:06 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 25 Jun 2006 01:51:07.0392 (UTC) FILETIME=[D346C800:01C697F9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Subject: [Emu] Partial Proposed Resolution to RFC 2716bis Review 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 Find enclosed below some review questions from Joe Salowey. I still am researching the answers to questions 1A and 1B, so I have not included a proposal for these yet. -------------------------------------------------------------------------------------------------------------------------- C. This document should probably reference RFC 3280. [BA] DONE. D. I think the last paragraph might not be quite correct: "... Please note that in the case where the EAP authentication is remoted that the EAP server will not reside on the same machine as the authenticator, and therefore the name in the EAP server's certificate cannot be expected to match that of the intended destination. In this case, a more appropriate test might be whether the EAP server's certificate is signed by a CA controlling the intended destination and whether the EAP server exists within a target sub-domain." I'm not quite sure what the is meant by "target sub-domain." In any case it is important that the peer be able to authorize the server as an EAP-Server that can authorize the authenticator the peer is connecting to. This is more than being issued by an organizational CA since that particular CA may issue certificates for many purposes. There either needs to be something in the certificate or the peer must have configuration to be able to perform the authorization. [BA] How about this? " The peer MUST verify the validity of the EAP server certificate, and SHOULD also examine the EAP server name presented in the certificate, in order to determine whether the EAP server can be trusted. For example, just because a server certificate can chain to a trust anchor does not necessarily imply that it is valid for connection to a particular network. As a result, the peer may also want to test whether the EAP server certificate is signed by a CA controlling the destination network and whether the Server-Id matches the format expected for that network. For example, an EAP peer connecting to the "EXAMPLE" SSID may wish to check whether the Server-Id matches the regular expression "*.example.com", in addition to checking wehther the server certificate chains to the example.com CA." 2. Section 2.5 Key Hierarchy A. Why is the EMSK broken into two halves? It should not be as this implies a particular usage for the EMSK. It should just be one 64 byte value. [BA] Right. I've removed the mateiral on the "halves" of the EMSK. B. Does this section tie the implementation of the PRF to 2246? What if TLS 1.2 supports a different PRF? [BA] I've removed the RFC 2246 reference here and also replaced other 2246 references with RFC 4346 since that obsoletes 2246. C. This section shows the TLS key hierarchy, shouldn't it show the EAP-TLS key hierarchy? [BA] How about this? " In EAP-TLS, the MSK, EMSK and IV are derived from the TLS master secret via a one-way function. This ensures that the TLS master secret cannot be derived from the MSK, EMSK or IV unless the one-way function (TLS PRF) is broken. Since the MSK and EMSK are derived from the TLS master secret, if the TLS master secret is compromised then the MSK and EMSK are also compromised. The MSK is divided into two halves, corresponding to the "Peer to Authenticator Encryption Key" (Enc- RECV-Key, 32 octets) and "Authenticator to Peer Encryption Key" (Enc- SEND-Key, 32 octets). The IV is a 64 octet quantity that is a known value; octets 0-31 are known as the "Peer to Authenticator IV" or RECV-IV, and Octets 32-63 are known as the "Authenticator to Peer IV", or SEND-IV. EAP-TLS derives exported keying material and parameters as follows: MSK(0,63) = TLS-PRF-64(TMS, "client EAP encryption", client.random || server.random) EMSK(0,63) = second 64 octets of: TLS-PRF-128(TMS, "client EAP encryption", client.random || server.random) IV(0,63) = TLS-PRF-64("", "client EAP encryption", client.random || server.random) MSK(0,31) = Peer to Authenticator Encryption Key (Enc-RECV-Key) (MS-MPPE-Recv-Key in [RFC2548]). Also known as the PMK in [IEEE-802.11i]. MSK(32,63) = Authenticator to Peer Encryption Key (Enc-SEND-Key) (MS-MPPE-Send-Key in [RFC2548]) IV(0,31) = Peer to Authenticator Initialization Vector (RECV-IV) IV(32,63) = Authenticator to Peer Initialization vector (SEND-IV) Session-Id = 0x0C || client.random || server.random Where: IV(W,Z) = Octets W through Z inclusive of the IV. MSK(W,Z) = Octets W through Z inclusive of the MSK. EMSK(W,Z) = Octets W through Z inclusive of the EMSK. TMS = TLS master_secret TLS-PRF-X = TLS PRF function computed to X octets client.random = Nonce generated by the TLS client. server.random = Nonce generated by the TLS server. | | pre_master_secret | server| | | client Random| V | Random | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | +---->| master_secret |<----+ | | (TMS) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | V V V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MSK, EMSK | | label == "client EAP encryption" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | MSK(0,31) | MSK(32,63) | EMSK(0,63) | | | | | | V V V Figure 2 - EAP-TLS Key Hierarchy The use of these keys is specific to the lower layer, as described in [KEYFRAME] Section 2.1." 3. Section 2.6 Ciphersuite negotiation A. At the SAAG meeting in IETF 65 Sam brought up an issue with multiple layers of negotiation with EAP-TLS. Is there a vulnerability introduced by multiple levels of negotiation? Is it possible that an peer or server will negotiate a weaker authentication method though the negotiation of TLS ciphersuites than it would through EAP negotiation? [BA] The recommended ciphersuites are addressed in [B] below. The major vulnerability is a "Type Code" replacement attack which could enable an attacker to force negotiation of one TLS-based EAP method instead of another. This could lead to a downgrade attack where the TLS ciphersuite policies were not uniform (e.g. EAP-TLS requires 2048-bit RSA, whereas PEAP will allow 1024). I will add some text on this vulnerablity, which is enabled because some TLS-based methods share the same key-derivation formula. B. The draft does not seem to specify which ciphersuites it is intended to be used with. Should it? [BA] RFC 4346 specifies a mandatory-to-implement ciphersuite in the absence of guidance (e.g. RFC 2716 didn't say anything about ciphersuites). How about this? "2.6. Ciphersuite and Compression Negotiation EAP-TLS implementations need not necessarily support all TLS ciphersuites listed in [RFC4346]. Not all TLS ciphersuites are supported by available TLS tool kits and licenses may be required in some cases. To ensure interoperability, EAP-TLS peers and servers MUST support the TLS [RFC4346] mandatory-to-implement ciphersuite: TLS_RSA_WITH_3DES_EDE_CBC_SHA. In addition, EAP-TLS servers SHOULD support and be able to negotiate all of the following TLS ciphersuites: TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_AES_128_CBC_SHA In addition, EAP-TLS peers SHOULD support at least one of the following TLS ciphersuites: TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_AES_128_CBC_SHA Since TLS supports ciphersuite negotiation, peers completing the TLS negotiation will also have selected a ciphersuite, which includes encryption and hashing methods. Since the ciphersuite negotiated within EAP-TLS applies only to the EAP conversation, TLS ciphersuite negotiation SHOULD NOT be used to negotiate the ciphersuites used to secure data. TLS also supports compression as well as ciphersuite negotiation. Therefore during the EAP-TLS conversation the endpoints MAY request or negotiate TLS compression. Since compression negotiated within EAP-TLS applies only to the EAP conversation, TLS compression negotiation MUST NOT be used to negotiate compression mechanisms to be applied to data." 4. General The document should define a Method-ID (for computing session-ID and key names). The method ID could be as simple as the concatenation of the server and client Finished messages. (these hashes contain the Client and Hello Random's as well as the identities exchanged in the certificates). [BA] Here is the text on Session-Id included in draft-ietf-eap-keying-14.txt: "The EAP-TLS Session-Id is the concatenation of the Expanded EAP Type Code (including the Type, Vendor-Id and Vendor-Type fields defined in [RFC3748] Section 5.7) with the peer and server nonces." My recommendation is to add the following text to Section 2.5: "Session-Id = 0x0D || client.random || server.random" I don't think it necessary makes sense to add the additional zeroes for Vendor-Id and Vendor-Type in this case, since EAP-TLS is allocated from the standard type space, the Session-Id should be unique. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Jun 24 22:25:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuKJ3-0008Ki-Sb; Sat, 24 Jun 2006 22:25:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuKJ3-0008Kc-HH for emu@ietf.org; Sat, 24 Jun 2006 22:25:01 -0400 Received: from bay106-f13.bay106.hotmail.com ([65.54.161.23] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuKJ2-0005uq-8F for emu@ietf.org; Sat, 24 Jun 2006 22:25:01 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 24 Jun 2006 19:24:59 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Sun, 25 Jun 2006 02:24:58 GMT X-Originating-IP: [71.38.130.70] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: emu@ietf.org Bcc: Subject: RE: [Emu] Partial Proposed Resolution to RFC 2716bis Review Date: Sat, 24 Jun 2006 19:24:58 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 25 Jun 2006 02:24:59.0507 (UTC) FILETIME=[8E82EC30:01C697FE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 will add some text on this vulnerablity, which is enabled because some >TLS-based methods share the same key-derivation formula. How about this? "4.6. Packet Modification Attacks The integrity protection of EAP-TLS packets does not extend to the EAP header fields (Code, Identifier, Length) or the Type or Flags fields. As a result, these fields may be modified by attacker. In most cases modification of the Code or Identifier fields will only result in a denial of service attack. However, it may be possible for an attacker to add additional data to an EAP-TLS packet so as to cause it to be longer than implied by the Length field. An implementation that does not check for this could be vulnerable to a buffer overrun. It is also possible for an attacker to modify the Type or Flags fields. By modifying the Type field, an attacker could cause one TLS-based EAP method to be negotiated instead of another. For example, the EAP-TLS Type field (13) could be changed to indicate another TLS-based EAP method. Unless the alternative TLS-based EAP method utilizes a different key derivation formula, it is possible that an EAP method conversation altered by a man-in-the-middle could run all the way to completion without detection. Unless the ciphersuite selection policies are identical for all TLS-based EAP methods utilizing the same key derivation formula, it may be possible for an attacker to mount a successful downgrade attack, causing the peer to utilize an inferior ciphersuite or TLS-based EAP method." _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Jun 27 18:07:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvLiC-0002eh-BM; Tue, 27 Jun 2006 18:07:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvLiB-0002ec-T3 for emu@ietf.org; Tue, 27 Jun 2006 18:07: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 1FvLi8-0001cB-62 for emu@ietf.org; Tue, 27 Jun 2006 18:07:11 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 27 Jun 2006 15:07:09 -0700 X-IronPort-AV: i="4.06,184,1149490800"; d="scan'208"; a="431417568:sNHT37003646" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k5RM772s025585; Tue, 27 Jun 2006 15:07:07 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5RM77CU009558; Tue, 27 Jun 2006 15:07:07 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Jun 2006 15:07:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] Partial Proposed Resolution to RFC 2716bis Review Date: Tue, 27 Jun 2006 15:07:03 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Partial Proposed Resolution to RFC 2716bis Review Thread-Index: AcaX+dqNtBDHi6z7QyCUiGBpSa5MSgCOKyNA From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 27 Jun 2006 22:07:07.0316 (UTC) FILETIME=[079B2F40:01C69A36] DKIM-Signature: a=rsa-sha1; q=dns; l=12528; t=1151446027; x=1152310027; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:RE=3A=20[Emu]=20Partial=20Proposed=20Resolution=20to=20RFC=202716bis=20R eview; X=v=3Dcisco.com=3B=20h=3DSnFILN7oAwoCKF+bEY528s8J0fE=3D; b=QkY5/DydpEz5ncttccsJcpz09xA08M1HRZA9RXcKDu/90KySgGi/qL8YAyYWlPY8WDcxm4JH GXn3fcpfVN54pLFeOahEuDaFXhkMLriMppKEGSQZiKb7vFN7nM46vKLo; Authentication-Results: sj-dkim-4.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Bernard, Thanks for the update, comments inline below:=20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Saturday, June 24, 2006 6:51 PM > To: emu@ietf.org > Subject: [Emu] Partial Proposed Resolution to RFC 2716bis Review >=20 > Find enclosed below some review questions from Joe Salowey. =20 > I still am researching the answers to questions 1A and 1B, so=20 > I have not included a proposal for these yet. >=20 > -------------------------------------------------------------- > ------------------------------------------------------------ > C. This document should probably reference RFC 3280. >=20 > [BA] DONE. >=20 > D. I think the last paragraph might not be quite correct: >=20 > "... Please note that in the case where the EAP=20 > authentication is remoted that > the EAP server will not reside on the same machine as the > authenticator, and therefore the name in the EAP server's=20 > certificate > cannot be expected to match that of the intended=20 > destination. In this > case, a more appropriate test might be whether the EAP server's > certificate is signed by a CA controlling the intended destination > and whether the EAP server exists within a target sub-domain." >=20 > I'm not quite sure what the is meant by "target sub-domain." =20 > In any case it is important that the peer be able to=20 > authorize the server as an EAP-Server that can authorize the=20 > authenticator the peer is connecting to. This is more than=20 > being issued by an organizational CA since that particular CA=20 > may issue certificates for many purposes. There either needs=20 > to be something in the certificate or the peer must have=20 > configuration to be able to perform the authorization. >=20 > [BA] How about this? >=20 > " The peer MUST verify the validity of the EAP server=20 > certificate, and > SHOULD also examine the EAP server name presented in the=20 > certificate, > in order to determine whether the EAP server can be trusted. For > example, just because a server certificate can chain to a trust > anchor does not necessarily imply that it is valid for=20 > connection to > a particular network. As a result, the peer may also want to test > whether the EAP server certificate is signed by a CA=20 > controlling the > destination network and whether the Server-Id matches the format > expected for that network. For example, an EAP peer connecting to > the "EXAMPLE" SSID may wish to check whether the Server-Id matches > the regular expression "*.example.com", in addition to checking > wehther the server certificate chains to the example.com CA." >=20 [Joe] I think this is a step in the right direction. I'm not sure that Server-ID is the only thing you may check for a particular deployment. =20 > 2. Section 2.5 Key Hierarchy >=20 > A. Why is the EMSK broken into two halves? It should not be=20 > as this implies a particular usage for the EMSK. It should=20 > just be one 64 byte value. >=20 > [BA] Right. I've removed the mateiral on the "halves" of the EMSK. >=20 [Joe] OK > B. Does this section tie the implementation of the PRF to=20 > 2246? What if TLS 1.2 supports a different PRF? >=20 > [BA] I've removed the RFC 2246 reference here and also=20 > replaced other 2246 references with RFC 4346 since that=20 > obsoletes 2246. >=20 [Joe] OK I think this is good. How does 1.1 and 1.2 impact backwards compatibility? > C. This section shows the TLS key hierarchy, shouldn't it=20 > show the EAP-TLS key hierarchy? >=20 > [BA] How about this? >=20 > " In EAP-TLS, the MSK, EMSK and IV are derived from the TLS master > secret via a one-way function. This ensures that the TLS master > secret cannot be derived from the MSK, EMSK or IV unless=20 > the one-way > function (TLS PRF) is broken. Since the MSK and EMSK are derived > from the TLS master secret, if the TLS master secret is compromised > then the MSK and EMSK are also compromised. >=20 > The MSK is divided into two halves, corresponding to the "Peer to > Authenticator Encryption Key" (Enc- RECV-Key, 32 octets) and > "Authenticator to Peer Encryption Key" (Enc- SEND-Key, 32 octets). >=20 > The IV is a 64 octet quantity that is a known value;=20 > octets 0-31 are > known as the "Peer to Authenticator IV" or RECV-IV, and=20 > Octets 32-63 > are known as the "Authenticator to Peer IV", or SEND-IV. >=20 > EAP-TLS derives exported keying material and parameters as follows: >=20 > MSK(0,63) =3D TLS-PRF-64(TMS, "client EAP encryption", > client.random || server.random) > EMSK(0,63) =3D second 64 octets of: > TLS-PRF-128(TMS, "client EAP encryption", > client.random || server.random) > IV(0,63) =3D TLS-PRF-64("", "client EAP encryption", > client.random || server.random) >=20 >=20 > MSK(0,31) =3D Peer to Authenticator Encryption Key (Enc-RECV-Key) > (MS-MPPE-Recv-Key in [RFC2548]). Also known as the > PMK in [IEEE-802.11i]. > MSK(32,63) =3D Authenticator to Peer Encryption Key (Enc-SEND-Key) > (MS-MPPE-Send-Key in [RFC2548]) > IV(0,31) =3D Peer to Authenticator Initialization Vector = (RECV-IV) > IV(32,63) =3D Authenticator to Peer Initialization vector = (SEND-IV) > Session-Id =3D 0x0C || client.random || server.random >=20 > Where: >=20 > IV(W,Z) =3D Octets W through Z inclusive of the IV. > MSK(W,Z) =3D Octets W through Z inclusive of the MSK. > EMSK(W,Z) =3D Octets W through Z inclusive of the EMSK. > TMS =3D TLS master_secret > TLS-PRF-X =3D TLS PRF function computed to X octets > client.random =3D Nonce generated by the TLS client. > server.random =3D Nonce generated by the TLS server. >=20 > | | pre_master_secret | > server| | | client > Random| V | Random > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | | | | > +---->| master_secret |<----+ > | | (TMS) | | > | | | | > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | | | > V V V > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | MSK, EMSK | > | label =3D=3D "client EAP encryption" | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | | > | MSK(0,31) | MSK(32,63) | EMSK(0,63) > | | | > | | | > V V V >=20 > Figure 2 - EAP-TLS Key Hierarchy >=20 >=20 > The use of these keys is specific to the lower layer, as=20 > described in > [KEYFRAME] Section 2.1." >=20 [Joe] OK, I think perhaps the Session ID should start with 0x0D? >=20 > 3. Section 2.6 Ciphersuite negotiation >=20 > A. At the SAAG meeting in IETF 65 Sam brought up an issue=20 > with multiple layers of negotiation with EAP-TLS. Is there a=20 > vulnerability introduced by multiple levels of negotiation? =20 > Is it possible that an peer or server will negotiate a weaker=20 > authentication method though the negotiation of TLS=20 > ciphersuites than it would through EAP negotiation? >=20 > [BA] The recommended ciphersuites are addressed in [B] below.=20 > The major vulnerability is a "Type Code" replacement attack=20 > which could enable an attacker to force negotiation of one=20 > TLS-based EAP method instead of another. This could lead to a=20 > downgrade attack where the TLS ciphersuite policies were not=20 > uniform (e.g. EAP-TLS requires 2048-bit RSA, whereas PEAP=20 > will allow 1024). I will add some text on this vulnerablity,=20 > which is enabled because some TLS-based methods share the=20 > same key-derivation formula. >=20 [Joe] OK, but we may want to also include security considerations for the case of EAP-TLS. When EAP-TLS is negotiated the ciphersuite that will be chosen is not known, so it is possible that the TLS negotiation may result is a weaker authentication method than was intended when EAP-TLS was negotiated through EAP. Implementations should take this into account when negotiating TLS ciphersuites.=20 > B. The draft does not seem to specify which ciphersuites it=20 > is intended to be used with. Should it? >=20 > [BA] RFC 4346 specifies a mandatory-to-implement ciphersuite=20 > in the absence of guidance (e.g. RFC 2716 didn't say anything=20 > about ciphersuites). How about this? >=20 > "2.6. Ciphersuite and Compression Negotiation >=20 > EAP-TLS implementations need not necessarily support all TLS > ciphersuites listed in [RFC4346]. Not all TLS ciphersuites are > supported by available TLS tool kits and licenses may be=20 > required in > some cases. >=20 > To ensure interoperability, EAP-TLS peers and servers MUST support > the TLS [RFC4346] mandatory-to-implement ciphersuite: >=20 > TLS_RSA_WITH_3DES_EDE_CBC_SHA. >=20 [Joe] RFC4346 allows you define an application profile so we wouldn't necessarily have to make this ciphersuite mandatory.=20 > In addition, EAP-TLS servers SHOULD support and be able to=20 > negotiate > all of the following TLS ciphersuites: >=20 [Joe] what do you mean support and be able to negotiate? Why not just support? > TLS_RSA_WITH_RC4_128_MD5 > TLS_RSA_WITH_RC4_128_SHA > TLS_RSA_WITH_AES_128_CBC_SHA >=20 > In addition, EAP-TLS peers SHOULD support at least one of the > following TLS ciphersuites: >=20 > TLS_RSA_WITH_RC4_128_MD5 > TLS_RSA_WITH_RC4_128_SHA > TLS_RSA_WITH_AES_128_CBC_SHA >=20 > Since TLS supports ciphersuite negotiation, peers=20 > completing the TLS > negotiation will also have selected a ciphersuite, which includes > encryption and hashing methods. Since the ciphersuite negotiated > within EAP-TLS applies only to the EAP conversation, TLS=20 > ciphersuite > negotiation SHOULD NOT be used to negotiate the=20 > ciphersuites used to > secure data. >=20 > TLS also supports compression as well as ciphersuite negotiation. > Therefore during the EAP-TLS conversation the endpoints MAY request > or negotiate TLS compression. Since compression negotiated within > EAP-TLS applies only to the EAP conversation, TLS compression > negotiation MUST NOT be used to negotiate compression mechanisms to > be applied to data." >=20 [Joe] Section looks good.=20 > 4. General >=20 > The document should define a Method-ID (for computing=20 > session-ID and key names). The method ID could be as simple=20 > as the concatenation of the server and client Finished=20 > messages. (these hashes contain the Client and Hello Random's=20 > as well as the identities exchanged in the certificates). >=20 > [BA] Here is the text on Session-Id included in > draft-ietf-eap-keying-14.txt: >=20 > "The EAP-TLS Session-Id is the concatenation of the Expanded=20 > EAP Type Code (including the Type, Vendor-Id and Vendor-Type=20 > fields defined in [RFC3748] Section 5.7) with the peer and=20 > server nonces." >=20 > My recommendation is to add the following text to Section 2.5: >=20 > "Session-Id =3D 0x0D || client.random || server.random" >=20 > I don't think it necessary makes sense to add the additional=20 > zeroes for Vendor-Id and Vendor-Type in this case, since=20 > EAP-TLS is allocated from the standard type space, the=20 > Session-Id should be unique. >=20 >=20 [Joe] OK, I think in the sample text for section 2.5 you used 0x0c instead of 0x0d. >=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 Jun 27 18:38:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvMCf-0005lA-PC; Tue, 27 Jun 2006 18:38:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvMCe-0005l0-RV for emu@ietf.org; Tue, 27 Jun 2006 18:38:40 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvMCe-0004Ps-Oz for emu@ietf.org; Tue, 27 Jun 2006 18:38:40 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvLqu-00052O-VW for emu@ietf.org; Tue, 27 Jun 2006 18:16:15 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 27 Jun 2006 15:16:12 -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 k5RMGCY9003871; Tue, 27 Jun 2006 15:16:12 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5RMGC9s012271; Tue, 27 Jun 2006 15:16:12 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Jun 2006 15:16:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] Partial Proposed Resolution to RFC 2716bis Review Date: Tue, 27 Jun 2006 15:16:09 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Partial Proposed Resolution to RFC 2716bis Review Thread-Index: AcaX/pFm83RWVh0uQ56VFPBLjBhv2wCN+IjA From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 27 Jun 2006 22:16:12.0049 (UTC) FILETIME=[4C4AD810:01C69A37] DKIM-Signature: a=rsa-sha1; q=dns; l=2354; t=1151446572; x=1152310572; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:RE=3A=20[Emu]=20Partial=20Proposed=20Resolution=20to=20RFC=202716bis=20R eview; X=v=3Dcisco.com=3B=20h=3DSnFILN7oAwoCKF+bEY528s8J0fE=3D; b=M9ZMQ7N6rBkVZhgO2qY+D9mgKxp5KjZDtBfG6g3wJ9NBaMlkOZCEtxJAvuR+HObDjR6ABM5v EwcnwN1yz+8H/d/Sraz7vzlO7ejWSph8KZMuLR1/i6hbHVm5DTlZihEz; Authentication-Results: sj-dkim-4.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org =20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Saturday, June 24, 2006 7:25 PM > To: emu@ietf.org > Subject: RE: [Emu] Partial Proposed Resolution to RFC 2716bis Review >=20 > >I will add some text on this vulnerablity, which is enabled because=20 > >some TLS-based methods share the same key-derivation formula. >=20 > How about this? >=20 > "4.6. Packet Modification Attacks >=20 > The integrity protection of EAP-TLS packets does not extend to the > EAP header fields (Code, Identifier, Length) or the Type or Flags > fields. As a result, these fields may be modified by attacker. >=20 > In most cases modification of the Code or Identifier=20 > fields will only > result in a denial of service attack. However, it may be possible > for an attacker to add additional data to an EAP-TLS=20 > packet so as to > cause it to be longer than implied by the Length field. An > implementation that does not check for this could be=20 > vulnerable to a > buffer overrun. >=20 > It is also possible for an attacker to modify the Type or Flags > fields. By modifying the Type field, an attacker could cause one > TLS-based EAP method to be negotiated instead of another. For > example, the EAP-TLS Type field (13) could be changed to indicate > another TLS-based EAP method. Unless the alternative TLS-based EAP > method utilizes a different key derivation formula, it is possible > that an EAP method conversation altered by a=20 > man-in-the-middle could > run all the way to completion without detection. =20 > Unless the > ciphersuite selection policies are identical for all TLS-based EAP > methods utilizing the same key derivation formula, it may=20 > be possible > for an attacker to mount a successful downgrade attack, causing the > peer to utilize an inferior ciphersuite or TLS-based EAP method." > [Joe] OK, I'm not sure we need to include text about the key derivation. If it is the key derivation that is the only difference then change will only be caught after the completion of the method if the keys are used. =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 Jun 27 21:13:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvOcg-0002aS-VW; Tue, 27 Jun 2006 21:13:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvOcf-0002Z3-He for emu@ietf.org; Tue, 27 Jun 2006 21:13:41 -0400 Received: from bay0-omc3-s25.bay0.hotmail.com ([65.54.246.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvOce-0006EJ-9J for emu@ietf.org; Tue, 27 Jun 2006 21:13:41 -0400 Received: from hotmail.com ([65.54.161.34]) by bay0-omc3-s25.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 18:13:39 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 27 Jun 2006 18:13:39 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Wed, 28 Jun 2006 01:13:37 GMT X-Originating-IP: [208.54.40.201] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: jsalowey@cisco.com, emu@ietf.org Bcc: Subject: RE: [Emu] Partial Proposed Resolution to RFC 2716bis Review Date: Tue, 27 Jun 2006 18:13:37 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 28 Jun 2006 01:13:39.0390 (UTC) FILETIME=[169A25E0:01C69A50] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >[Joe] OK, I'm not sure we need to include text about the key derivation. >If it is the key derivation that is the only difference then change will >only be caught after the completion of the method if the keys are used. The problem is that if the EAP-TLS key derivation formula is re-used in an another method (as it has been), then the problem may never be caught. So I think we need to caution against that. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Jun 27 21:28:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvOrR-00088h-IJ; Tue, 27 Jun 2006 21:28:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvOrP-00088c-VV for emu@ietf.org; Tue, 27 Jun 2006 21:28:55 -0400 Received: from bay0-omc2-s3.bay0.hotmail.com ([65.54.246.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvOrM-0007Si-LJ for emu@ietf.org; Tue, 27 Jun 2006 21:28:55 -0400 Received: from hotmail.com ([65.54.161.16]) by bay0-omc2-s3.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 18:28:52 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 27 Jun 2006 18:28:52 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Wed, 28 Jun 2006 01:28:48 GMT X-Originating-IP: [208.54.40.201] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: jsalowey@cisco.com, emu@ietf.org Bcc: Subject: RE: [Emu] Partial Proposed Resolution to RFC 2716bis Review Date: Tue, 27 Jun 2006 18:28:48 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 28 Jun 2006 01:28:52.0069 (UTC) FILETIME=[3699E950:01C69A52] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >[Joe] OK I think this is good. How does 1.1 and 1.2 impact backwards >compatibility? I don't think we know yet. To get clarity, we need to do some tests. It is possible that only a subset of the problems that Y. Pettersen describes in his draft afflict TLS-based EAP methods: http://www.watersprings.org/pub/id/draft-pettersen-tls-interop-experience-00.txt BTW, I have verified some ciphersuite interoperability problems with existing implementations. For example, it appears that 3DES ciphersuites do not interoperate (though they can be negotiated). >[Joe] OK, I think perhaps the Session ID should start with 0x0D? Oops. Typo :( >[Joe] OK, but we may want to also include security considerations for >the case of EAP-TLS. When EAP-TLS is negotiated the ciphersuite that >will be chosen is not known, so it is possible that the TLS negotiation >may result is a weaker authentication method than was intended when >EAP-TLS was negotiated through EAP. Implementations should take this >into account when negotiating TLS ciphersuites. It is definitely important to have policy in place. This is required in EAP-TLS implementations seeking FIPS 140-2 certification -- only FIPS-approved ciphersuites (e.g. 3DES, AES, HMAC-SHA1) can be negotiated, not RC4 or MD5. I'll add a section on this in the next rev. > > TLS_RSA_WITH_3DES_EDE_CBC_SHA. > > >[Joe] RFC4346 allows you define an application profile so we wouldn't >necessarily have to make this ciphersuite mandatory. Just found some interoperability issues with this ciphersuite, so making it mandatory could be problematic :( Maybe we should stick with RC4 as mandatory, and add AES as a SHOULD? RC4 definitely interoperates. >[Joe] what do you mean support and be able to negotiate? Why not just >support? Support should be sufficient. In some situations, not every supported ciphersuite will be negotiable (e.g. in FIPS mode, RC4 ciphersuites will not be negotiable). >[Joe] OK, I think in the sample text for section 2.5 you used 0x0c >instead of 0x0d. Yup. Typo :( _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Jun 27 23:12:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvQTD-0005dK-5R; Tue, 27 Jun 2006 23:12:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvQTC-0005dF-Ej for emu@ietf.org; Tue, 27 Jun 2006 23:12:02 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvQTB-0001Eo-5h for emu@ietf.org; Tue, 27 Jun 2006 23:12:02 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 27 Jun 2006 20:12:00 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k5S3C0i7026232; Tue, 27 Jun 2006 20:12:00 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5S3C0CU020861; Tue, 27 Jun 2006 20:12:00 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Jun 2006 20:12:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] Partial Proposed Resolution to RFC 2716bis Review Date: Tue, 27 Jun 2006 20:11:57 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Partial Proposed Resolution to RFC 2716bis Review Thread-Index: AcaaUjcIzjJZ/jjHSPeKLrboKh4KpgADfYdA From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 28 Jun 2006 03:12:00.0457 (UTC) FILETIME=[9F2AFB90:01C69A60] DKIM-Signature: a=rsa-sha1; q=dns; l=1058; t=1151464320; x=1152328320; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:RE=3A=20[Emu]=20Partial=20Proposed=20Resolution=20to=20RFC=202716bis=20R eview; X=v=3Dcisco.com=3B=20h=3DSnFILN7oAwoCKF+bEY528s8J0fE=3D; b=Inm4qbmyCiH0jI1JOUgsRUUMFRkUUkDfk2fvBq99NRaEcSScQvIxZE+BvTLrTezn1xBuIKaq X6Qx+YYG2tQeWj1FJBAkqdNC8Bq07Gz1lyuHJjm6Pe6RafKLQs7swpKI; Authentication-Results: sj-dkim-3.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org > I'll add a section on this in the next rev. >=20 > > > TLS_RSA_WITH_3DES_EDE_CBC_SHA. > > > > >[Joe] RFC4346 allows you define an application profile so we=20 > wouldn't=20 > >necessarily have to make this ciphersuite mandatory. >=20 > Just found some interoperability issues with this=20 > ciphersuite, so making it mandatory could be problematic :( >=20 > Maybe we should stick with RC4 as mandatory, and add AES as a=20 > SHOULD? RC4 definitely interoperates. >=20 [Joe] I would be tempted to specify it the other way. I think we want to encourage AES implementation, RC4 I'm not so sure...=20 > >[Joe] what do you mean support and be able to negotiate? =20 > Why not just=20 > >support? >=20 > Support should be sufficient. In some situations, not every=20 > supported ciphersuite will be negotiable (e.g. in FIPS mode,=20 > RC4 ciphersuites will not be negotiable). >=20 [Joe] Right. I think we want it to be implemented, but it is up to the deployment requirements as to what is actually gets negotiated.=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu