From emu-bounces@ietf.org Mon Dec 03 19:39:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzLp8-0002jU-1j; Mon, 03 Dec 2007 19:39:42 -0500 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1IzLp7-0002jF-3y for emu-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 19:39:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzLp6-0002j3-QP for emu@ietf.org; Mon, 03 Dec 2007 19:39:40 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzLp5-0005rz-Ta for emu@ietf.org; Mon, 03 Dec 2007 19:39:40 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 03 Dec 2007 16:39:39 -0800 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 lB40ddAE022310; Mon, 3 Dec 2007 16:39:39 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lB40dVqd008365; Tue, 4 Dec 2007 00:39:39 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 16:39:31 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] EMU charter update for tunneled method Date: Mon, 3 Dec 2007 16:39:54 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EMU charter update for tunneled method Thread-Index: Acgq66C291A2zaUqTrGk3daCZ96DewADLN9wAsVe0OA= From: "Joseph Salowey (jsalowey)" To: "Stephen Hanna" , X-OriginalArrivalTime: 04 Dec 2007 00:39:31.0868 (UTC) FILETIME=[22A415C0:01C8360E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6297; t=1196728779; x=1197592779; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Emu]=20EMU=20charter=20update=20for=20tunneled=20met hod |Sender:=20; bh=YlYkUBdqYOUor+i4DIWqTSkYMH5XIswqwVPDZH2kb9o=; b=BgPNFjiLRK8vOvs80Fbjp59a0RbRolFXPgQhO1rIslLTZLCXb8w3ONoAkCmWX1YagZHiHEli qWz7+PPr0/KFlhcYqMJT5eBeP6MuTQhUN5PO+DC26V2wbLyTvtnTJt+6; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 225414c974e0d6437992164e91287a51 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 Thanks Steve, I think "Tunnel Method" might be the best term. Adding a deliverable for a requirements draft is a good suggestion we can discuss. =20 Cheers, Joe > -----Original Message----- > From: Stephen Hanna [mailto:shanna@juniper.net]=20 > Sent: Wednesday, November 28, 2007 3:28 AM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] EMU charter update for tunneled method >=20 > Here is my feedback on this proposed charter update. >=20 > 1) RFC 3748 and RFC 4017 requirements should apply to > all deliverables. The proposed language omits them > from the tunneled method deliverable. Please add them > to that deliverable. >=20 > 2) Some of the new milestones are not clear. The main > problem is that there's no verb. For example, what > does "Tunnel Method requirements" mean? It should > say "Agree on Tunnel Method requirements" or some such. >=20 > 3) I think that we should have an Internet Draft on > "Tunnel Method requirements" that goes through the > normal approval process to achieve IETF consensus > and become an RFC. Agreeing on a Tunnel Method is > a major effort (and quite valuable). We should have > IETF consensus on the requirements before we start. >=20 > Publishing the requirements as an Internet Draft > will also make it easier for other standards groups > to comments, which is probably a good idea in this > instance. >=20 > 4) The terms "tunneled" and "tunnel" are used interchangably. > We should choose one or the other and stick to it. I think > the term "tunneled" is more common for this usage so I > suggest that we use that term. >=20 >=20 > 5) In the second paragraph, the "this methods" should be > "these methods". >=20 > I appreciate your work on drafting this proposed charter=20 > update. It's a good start. I'm glad that we're getting some=20 > discussion of it and look forward to more discussion on the=20 > email list and in Vancouver. >=20 > Thanks, >=20 > Steve >=20 > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Monday, November 19, 2007 3:35 PM > To: emu@ietf.org > Subject: [Emu] EMU charter update for tunneled method >=20 > Below is a proposed update to the EMU charter to add a=20 > tunneled method. > The following are the changes to the existing charter: >=20 > - add charter item for tunneled EAP method > - modified password based item to make use of the above=20 > tunneled method > - modify "enhanced TLS" item to focus on adding channel=20 > bindings to a TLS based mechanism > - updated milestones=20 >=20 >=20 > ------------------ >=20 > Description of Working Group: > The Extensible Authentication Protocol (EAP) [RFC 3748] is a network > access authentication framework used in the PPP, 802.11, 802.16, VPN, > PANA, and in some functions in 3G networks. EAP itself is a simple > protocol and actual authentication happens in EAP methods. >=20 > Over 40 different EAP methods exist. Most of this methods are > proprietary methods and only a few methods are documented in RFCs. The > lack of documented, open specifications is a deployment and > interoperability problem. In addition, none of the EAP methods in the > standards track implement features such as key derivation that are > required for many modern applications. This poses a problem for, among > other things, the selection of a mandatory to implement EAP method in > new network access technologies. For example, no standards=20 > track methods > meet new requirements such as those posed in RFC 4017, which documents > IEEE 802.11 requirements for EAP methods. >=20 > This group is chartered to work on the following types of=20 > mechanisms to > meet RFC 3748 and RFC 4017 requirements: >=20 > - An update to RFC 2716 to bring EAP-TLS into standards track, clarify > specification, interoperability, and implementation issues=20 > gathered over > the years, and update the document to meet the requirements=20 > of RFC 3748, > RFC 4017, and EAP keying framework documents. Backwards compatibility > with RFC 2716 is a requirement. >=20 > - A mechanism based on strong shared secrets that meets RFC=20 > 3748 and RFC > 4017 requirements. This mechanism should strive to be simple=20 > and compact > for implementation in resource constrained environments. >=20 > - A mechanism to support extensible communication within a=20 > TLS protected > tunnel to support meeting the requirements of an enhanced TLS=20 > mechanism, > a password based authentication mechanism, and to support additional > inner authentication mechanisms. >=20 > - Enhanced functionality to enable a TLS-based EAP method to support > channel bindings. So as to enable RFC 2716bis to focus solely on > clarifications to the existing protocol, this effort will be=20 > handled in > a separate document. This item should not generate a new=20 > method rather > it should be based on existing EAP-TLS or a TLS based=20 > tunneled method. =20 >=20 > - A mechanism meeting RFC 3748 and RFC 4017 requirements that=20 > makes use > of existing password databases such as AAA databases. The=20 > implementation > should strive to be usable in resource constrained environments. This > item will make use of the above tunneled method. >=20 > Goals and Milestones: > Done Form design team to work on strong shared secret > mechanism > Done Submit 2716bis I-D > Done Submit first draft of shared secret mechanism I-D > Done Form password based mechanism design team > Done (July 2007) Submit 2716bis draft to IESG for Proposed > Standard > Dec 2007 Submit Strong Shared Secret Mechanism to IESG > Dec 2007 Tunnel Method requirements > Mar 2008 Tunnel Method first draft submitted > May 2008 Submit Password method extensions to tunnel method > June 2008 Submit Extended TLS method extensions to tunnel method > Nov 2008 Submit Tunnel Method to IESG > Nov 2008 Submit Enhanced EAP-TLS to IESG > Nov 2008 Submit Password based method to IESG >=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 Dec 04 16:46:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izfah-0000lz-Hh; Tue, 04 Dec 2007 16:46:07 -0500 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1Izfag-0000ju-BH for emu-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 16:46:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izfaf-0000hR-VL for emu@ietf.org; Tue, 04 Dec 2007 16:46:06 -0500 Received: from mail.ltsnet.net ([65.127.220.12] helo=ltsnet.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izfaf-0001LR-Hy for emu@ietf.org; Tue, 04 Dec 2007 16:46:05 -0500 Received: from [127.0.0.1] (robin.ltsnet.net [65.127.220.47]) by ltsnet.net (8.13.8/8.13.5) with ESMTP id lB4LTJEO020722; Tue, 4 Dec 2007 16:29:20 -0500 Message-ID: <4755CA9C.9010708@cs.umd.edu> Date: Tue, 04 Dec 2007 16:46:04 -0500 From: Charles Clancy User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Jouni Malinen Subject: Re: [Emu] I-D Action:draft-ietf-emu-eap-gpsk-07.txt References: <20071124225733.GL8672@jm.kir.nu> In-Reply-To: <20071124225733.GL8672@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: f60d0f7806b0c40781eee6b9cd0b2135 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. They have been addressed in v08. http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-08.txt -- t. charles clancy, ph.d. eng.umd.edu/~tcc electrical & computer engineering, university of maryland Jouni Malinen wrote: > On Mon, Nov 19, 2007 at 03:50:02AM -0500, Internet-Drafts@ietf.org wrote: > >> Title : EAP Generalized Pre-Shared Key (EAP-GPSK) >> Filename : draft-ietf-emu-eap-gpsk-07.txt > > Minor editorial comments: > > It looks like the general description of MK derivation in '4. Key > Derivation' was not updated to match with the ciphersuite specific > changes in 7.1.3 and 7.2.3. > > The following lines: > o inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server > o zero = 0x00 || 0x00 || ... || 0x00 (KS times) > > o MK = KDF-KS(zero, PL || PSK || CSuite_Sel || inputString)[0..KS-1] > > would need to be changed to: > o inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server > > o MK = KDF-KS(PSK[0..KS-1], PL || PSK || CSuite_Sel || inputString)[0..KS-1] > > > > > 7.1.3 and 7.2.3: > > MK = GKDF-16 (PSK[0..127], PL || PSK || CSuite_Sel || inputString) > MK = GKDF-32 (PSK[0..255], PL || PSK || CSuite_Sel || inputString) > > The 0..127 and 0..255 are clearly usings bits, but these should be bytes > to be consistent with the 0..KS-1 style used elsewhere, i.e., these > lines should be > > MK = GKDF-16 (PSK[0..15], PL || PSK || CSuite_Sel || inputString) > MK = GKDF-32 (PSK[0..31], PL || PSK || CSuite_Sel || inputString) > > > Now that definition of 'zero' was removed from MK derivation, Method-ID > derivation is using implicitly defined 'zero'. Even though it is > relatively obvious what length will be used here, it would be better to > state this explicitly: > > Add following line to 7.1.3 before Method-ID derivation: > zero = 0x00 || 0x00 || ... || 0x00 (16 times) > > Add following line to 7.2.3 before Method-ID derivation: > zero = 0x00 || 0x00 || ... || 0x00 (32 times) > > > Especially the ciphersuite 2 case would benefit from explicit statement > since HMAC-SHA256 could use any key length. I don't see any particular > need for this to be 32 octets, but that would be consistent with other > uses of GKDF and anyway, this matches with the KS-octet 'zero' used in > Ch. 4. > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Dec 04 16:50:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzfeW-0005rt-6S; Tue, 04 Dec 2007 16:50:04 -0500 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1IzfeV-0005oG-CU for emu-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 16:50:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzfeV-0005nL-0H; Tue, 04 Dec 2007 16:50:03 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzfeU-0001dV-Ke; Tue, 04 Dec 2007 16:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 42A69175DD; Tue, 4 Dec 2007 21:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IzfeT-0007EI-PM; Tue, 04 Dec 2007 16:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 04 Dec 2007 16:50:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: emu@ietf.org Subject: [Emu] I-D Action:draft-ietf-emu-eap-gpsk-08.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update Working Group of the IETF. Title : EAP Generalized Pre-Shared Key (EAP-GPSK) Author(s) : C. Clancy, H. Tschofenig Filename : draft-ietf-emu-eap-gpsk-08.txt Pages : 37 Date : 2007-12-04 This Internet Draft defines an Extensible Authentication Protocol method called EAP Generalized Pre-Shared Key (EAP-GPSK). This method is a lightweight shared-key authentication protocol supporting mutual authentication and key derivation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-emu-eap-gpsk-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-emu-eap-gpsk-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-12-04164431.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-emu-eap-gpsk-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-emu-eap-gpsk-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-04164431.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --NextPart-- From emu-bounces@ietf.org Wed Dec 05 22:12:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J07A6-0003eb-1g; Wed, 05 Dec 2007 22:12:30 -0500 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1J07A4-0003aw-Th for emu-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 22:12:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J07A4-0003an-Iw for emu@ietf.org; Wed, 05 Dec 2007 22:12:28 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J07A4-0008Eb-95 for emu@ietf.org; Wed, 05 Dec 2007 22:12:28 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id DF5B1175E5 for ; Thu, 6 Dec 2007 03:11:57 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J079Z-0005C8-8j for emu@ietf.org; Wed, 05 Dec 2007 22:11:57 -0500 X-test-idtracker: no @To: IETF-Announce From: The IESG Cc: Message-Id: Date: Wed, 05 Dec 2007 22:11:57 -0500 X-Spam-Score: 1.6 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Emu] Last Call: draft-simon-emu-rfc2716bis (The EAP TLS Authentication Protocol) to Proposed Standard X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org The IESG has received a request from the EAP Method Update WG (emu) to consider the following document: - 'The EAP TLS Authentication Protocol ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-12-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-11.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14259&rfc_flag=0 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Dec 10 16:56:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1qbZ-0003DK-GL; Mon, 10 Dec 2007 16:56:01 -0500 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1J1qbX-0003Ch-Dq for emu-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 16:55:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1qbX-00039j-22 for emu@ietf.org; Mon, 10 Dec 2007 16:55:59 -0500 Received: from sp.isima.fr ([193.55.95.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1qbW-0000pD-I4 for emu@ietf.org; Mon, 10 Dec 2007 16:55:58 -0500 Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id lBAMrApL512254 for ; Mon, 10 Dec 2007 22:53:10 GMT Received: from 86.72.162.23 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Mon, 10 Dec 2007 23:52:14 +0100 (CET) Message-ID: <63451.86.72.162.23.1197327134.squirrel@www.isima.fr> Date: Mon, 10 Dec 2007 23:52:14 +0100 (CET) Subject: Re: [Emu] Last Call: draft-simon-emu-rfc2716bis (The EAP TLS Authentication Protocol) to Proposed Standard From: badra@isima.fr To: emu@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Mon, 10 Dec 2007 22:53:10 +0000 (WET) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi all, When privacy is activated with respect to section 2.1.4., which master_secret (the 1st or 2nd handshake) is used in section 2.3? Best regards Badra On Dec 6, 2007 4:11 AM, The IESG wrote: The IESG has received a request from the EAP Method Update WG (emu) to consider the following document: - 'The EAP TLS Authentication Protocol ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-12-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-11.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14259&rfc_flag=0 _______________________________________________ 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 Dec 12 19:02:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2bWi-0004CZ-Us; Wed, 12 Dec 2007 19:02:08 -0500 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1J2bWh-0004CK-II for emu-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 19:02:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2bWh-0004CC-77 for emu@ietf.org; Wed, 12 Dec 2007 19:02:07 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2bWg-0001Jd-O2 for emu@ietf.org; Wed, 12 Dec 2007 19:02:07 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 12 Dec 2007 16:02:06 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBD025KP010751 for ; Wed, 12 Dec 2007 16:02:05 -0800 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 lBD025CF020182 for ; Thu, 13 Dec 2007 00:02:05 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 16:02:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Dec 2007 16:02:30 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] EMU working group summary Thread-Index: Acg4LJeYZCIKxKw8S/e9RPGrnIVPjgE7rc3Q From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 13 Dec 2007 00:02:05.0552 (UTC) FILETIME=[65733700:01C83D1B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1018; t=1197504125; x=1198368125; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20FW=3A=20[saag]=20EMU=20working=20group=20summar y |Sender:=20; bh=Y6vnggWYCYU8m4sCjzFh+MHdKufACHZq/Vdb+If/FWA=; b=SnYirWDHV8Qh0j7AZ1U+e/AyR1xZsvt71r1K4gm7iPFswtHYQ4xG2ciX7T 6WjO6iWwx5+g28ohhE5HdRX5SV3dFtXXuaXlyygQCnOvYrMq18K+crbyT+CX 1WdiMm1Vje; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Emu] FW: [saag] EMU working group summary 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 the summary that was sent to the SAAG list for emu. I will post full minutes later this week. Thanks, Joe -----Original Message----- From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On Behalf Of Joseph Salowey (jsalowey) Sent: Thursday, December 06, 2007 9:23 AM To: saag@mit.edu Subject: [saag] EMU working group summary The EMU (EAP Method Update) working group met on Tuesday morning. RFC2716bis (EAP-TLS) has started IETF Last Call. EAP-GPSK (Generalized Pre-Shared Key) has completed working group review and will be sent to the IESG shortly. In the meeting we discussed a charter revision to add a work item to deliver a standards track EAP Tunnel method based on TLS that supports passwords and other authentication mechanisms. Discussion of the charter and of the requirements for a tunnel method will continue on the EMU list. =20 _______________________________________________ saag mailing list saag@mit.edu http://mailman.mit.edu/mailman/listinfo/saag _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Dec 17 14:12:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4LOT-0003gK-VW; Mon, 17 Dec 2007 14:12:49 -0500 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1J4LOT-0003eD-4G for emu-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 14:12:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4LOS-0003d8-O8 for emu@ietf.org; Mon, 17 Dec 2007 14:12:48 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4LOR-00046l-Os for emu@ietf.org; Mon, 17 Dec 2007 14:12:48 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 17 Dec 2007 11:12:47 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBHJCl7b022963 for ; Mon, 17 Dec 2007 11:12:47 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id lBHJCgdg014590 for ; Mon, 17 Dec 2007 19:12:47 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Dec 2007 11:12:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Dec 2007 11:13:05 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PROTO write-up for EAP-GPSK Thread-Index: AchA4NnAUTDionU2SgCVxj1B8WEvZg== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 17 Dec 2007 19:12:38.0154 (UTC) FILETIME=[C9BD56A0:01C840E0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6951; t=1197918767; x=1198782767; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20PROTO=20write-up=20for=20EAP-GPSK |Sender:=20; bh=3xOO0NpA4D+HPLN/juTFtdR91uBs2yTgKRUNVi3UiHI=; b=sZ78pFNfie1DurX/VQNNp2Nkn6WTrniwmnj32OZ5xtuN4rEcV8ekWRZqz7 vkEc5EwuaNkoV3dug3UuotdnQHgvD5nk3SHE/5A3wJ+XXTN5itRSZQjKWAGT DVYAuvS0Cl; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Subject: [Emu] PROTO write-up for 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 Below is the PROTO write-up for EAP-GPSK. Please let me know if there are any issues with the write-up. I will send EAP-GPSK to the IESG in the next few weeks. =20 Thanks, Joe ---------- (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? I am the document shepherd for this document and I have personally reviewed the document and believe it is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has received adequate review from both working group and non WG members. At least one working group member, Jouni Malinen has implemented the specification and provided feedback that has improved the document. In addition the document has received review from researchers from several universities an their feedback has been incorporated. The document has also received some review from NIST.=20 (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No (1.d) Does the Document Shepherd have any specific concerns or issues with this document hat the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. The working group had some discussion late in the process over whether an approach using EAP-TLS with TLS-PSK was a better approach. The EAP-GPSK document was preferred because: 1. Implementation experience has shown that EAP-GPSK is easy to implement.=20 2. EAP-GPSK requires fewer cryptographic primitives than TLS and can be implemented more compactly. 3. Currently EAP-TLS explicitly requires the use of certificates.=20 EAP-GPSK should be able to meet any future EAP channel binding requirements because it defines a mechanism to carry payloads of various types.=20 (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document represents a reasonably strong consensus with most of the active members of the working group in favor of the document moving forward. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has split references with no downward or dependent references (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? IANA considerations section exists and is consistent with the body of the document. Appropriate registries are requested, identified and populated with initial values. =20 (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Not applicable (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary=20 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. The method should be able to support any future EAP channel binding requirements.=20 Working Group Summary=20 The base document for EAP-GPSK was originally created by a design team. There was working group consensus to accept the document to meet the Pre-Shared-Key EAP method on the working group charter.=20 Document Quality=20 There is an existing implementation of the protocol. NIST was consulted and participated in the review of the document resulting in some modifications to the key derivation function. The document has been reviewed by external researchers and their feedback has been incorporated. EAP experts within the EMU working group have reviewed the document. This document meets requirements set forth in RF3748, RFC 4017 and the EAP Key Management Framework.=20 Personnel=20 Joe Salowey, the EMU chair, is the document shepherd. The responsible Area Director is Sam Hartman.=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Dec 17 23:23:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Tzj-0003bi-2U; Mon, 17 Dec 2007 23:23:51 -0500 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1J4Tzh-0003a4-AJ for emu-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 23:23:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Tzg-0003Zw-MH for emu@ietf.org; Mon, 17 Dec 2007 23:23:48 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4Tze-0003DM-JW for emu@ietf.org; Mon, 17 Dec 2007 23:23:48 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 17 Dec 2007 20:23:46 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBI4Nk6X028476 for ; Mon, 17 Dec 2007 20:23:46 -0800 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 lBI4Ne41029293 for ; Tue, 18 Dec 2007 04:23:40 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Dec 2007 20:23:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Dec 2007 20:24:07 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft minutes for IETF-70 EMU meeting Thread-Index: AchBLdRXJx//dRgMRcacgaR9VtaUvQ== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 18 Dec 2007 04:23:40.0742 (UTC) FILETIME=[C493E660:01C8412D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=19012; t=1197951826; x=1198815826; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Draft=20minutes=20for=20IETF-70=20EMU=20meeting |Sender:=20; bh=bvCy3+clDGH3PIZAOgefJmKd2zhkGXWr2sEGu6+q388=; b=NX8mAXuNqrzd6jCloagDV79fs2LkzIUsR/DqIIdDWHzWD+/k8Qn4KEyFfj qpQNHMtRhJT4wOh8jCHovnP1tCGoOTfpl99b/Bp8m0dq3L3oqfNqW+rjax3a FRwxExE6f3; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a961490db2a74c7613bf0201229f176 Subject: [Emu] Draft minutes for IETF-70 EMU meeting 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 are the draft minutes for the IETF-70 EMU meeting. Thanks to Nancy, Steve and Sue for taking notes. Please let me know if you have any corrections. ------------------------------------------------------------------------ ---------------- EMU Minutes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TUESDAY, December 4, 2007 0900-1130 Morning Session I Cypress =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Chair: Joe Salowey Note Takers: Nancy Cam-Winget, Steve Hanna, Susan Thomson =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D + Draft updates - EAP-TLS (RFC2716bis) sent to the IESG - EAP-GPSK editorial fixes and comment resolution for EAP-GSK based on feedback from some researches ready for IESG Sam Harman: mentioned that he will prioritize to forward the EAP-TLS draft and when ready, the EAP-GSK drafts. ----------------------------- + Charter update * Add a charter item for a standard tunnel method * Modify the password-based item to use the tunnel method * Modify the enhanced TLS item to focus on adding channel binding to a TLS-based method (EAP-TLS or a tunnel method) * Update the milestones to include requirements draft + method name Joe Salowey: need to choose a consistent term: tunneled method, tunneling method, tunnel method. Propose "tunnel method" Steve Hanna: prefers "tunnel method". + RFC compliance requirements Hao Zhou: do we have an exact definition of "enhanced TLS mechanism" and what the enhancements are? Joe: no, that is something we'll need to define and clarify. Hao: when we say "additional authentication methods" are we talking about channel binding, or other things? Joe: channel binding is a requirement but the others, not sure that they will need to be explicitly called out in the charter. Bernard Aboba: clarifies that the bindings are optional based on RFC 3748. Sam: speaking as an individual, I don't see how we would meet the requirements of RFC 4962 without imposing channel bindings. It would be useless if we adopted something that didn't meet those requirements. Comment: RFC 4962 is currently not in the charter Sam: is EAP keying listed in the charter? Comment: given that it's still a draft, don't see how it could be included. Also not referenced in the current charter (EAP keying) Sam: if we're not bound by RFC 4962, then channel bindings are optional. But then this can jeopardize the efforts of Hokey as there's no way to ensure a method that can work with the work coming out of Hokey. Joe: there no mention of these items in the emu-charter, not sure if this was an oversight or intentional. =20 Steve: raised that the charter doesn't call out requirements such as the keying framework....since other requirements list out the RFC's to reference other documents to extract requirements should we do the same for tunnels? Steve: perhaps we can just clarify generally "all mechanisms defined by EMU should meet the following requirements"....if there are other RFC's then we can just add it to one list. Update can read "All mechanisms standardized by this group must meet RFC 3748 and RFC 4017 requirements. This group is chartered to work on the following types of mechanisms:" Hao: are those the only 2 RFC's requirements? What about EAP-keying? Why would we single other requirements to only one particular Joe: does anyone else agree on this? Sam: am more concerned on RFC 4962....would recommend not adopting EAP-keying yet Charles Clancy: how is RFC 4962 required for Hokey? The fact that its bootstrapping its keying from RFC 4962 Sam: may put a requirement on an EAP method to get such keying material Charles: RFC 4962 still has gaps in how keys are distributed. Sam: there's an open issue with RFC 4962 and Hokey and how keys are delivered Charles: during authentication, the MSK needs to be delivered and its not something that is currently RFC 4962 be compliant. Sam: that was one of the intents of RFC 4962 Charles: if there's a proxy, then it will not help especially how all those keys are being managed Sam: yes, that is an issue that will be discussed tomorrow. There are some problems with RFC 4962 Joe: RFC 4962 does not have EAP requirements. Bernard: believe the issue is whether the method can determine that the authenticator (or the port) gets the key as the intended party. The channel binding can help as there is full agreement....there would worthwhile to have a document that explains and clarify what the channel binding architecture achieves since it has been hard to get the lower layer guys push up required material. Making a case to go in this direction is needed. Sam: need to move on. Joe: sounds like we need to require a statement that says methods must also support for RFC 4962.=20 Hao: if we add this, then we'll have problems with EAP-PSK and EAP-TLS....are we going to backtrack to fulfill these requirements? Sam: sent question before regarding this. My recollection on mail sent, Sam will ask to make it clear on how channel binding could be added to these methods. Would be okay accepting this....did not recall getting negative comments for this. Hao: if we make the requirement to support channel binding, one of the problems for TLS is we would have to grandfather it in since there are implementations out there. Sam: EAP-TLS has already move forward so lets leave it Steve: lets remove it out of the list then. Sam: remove completed items. Paul Hoffman: that is weird. You're going to have a set of milestones that will have a hole in the middle of them. Where there's normative specs in the body but not in the ASN specs....while we're not meeting RFC 4962, to take it out of the deliverables but then above to imply that we've delivered it, is confusion. We need to be clear of where it is required. =20 Joe: OK Sam: doesn't like that but it's not worth fighting over. Joe: includes RFC 4962 for some of the methods. There is a path to support this in EAP-PSK so authors are okay with this addition. =20 Hao: suggests that we explicitly state channel binding versus calling out RFC 4962. =20 Joe: believes it would be clearer though not sure it would be accurate as there may be other requirements. Sam: doesn't want to get into argument of what is and is not in RFC 4962 within the working group. So if 4962 is broken then we should fix it. Steve: though we have an unspoken agreement, not clear that there is a plan to address RFC 4962...don't think we should proceed "must meet 4962" when it may not be clear. Hao: we should be clear on what it means to meet RFC 4962 Joe: so can change to "mechanisms must be capable of supporting channel bindings." Bernard: we really should defined what it means to "support channel binding" should we add this as a work item? How do we ensure that it is added to the group? Joe: we will need to clearly define what this means.... Sam: agree with Bernard & must be written somewhere, though updates to EAP are outside this group. We can change charter to this group, but it will cause further review. This piece is missing and no one is fixing it. Joe: we need to fix this if we are to move forward. Nancy Cam-Winget: if we can't define it in this group, then we should remove it as a requirement on our charter revision. Tim Polk: its up to the area directors to figure out where this work is to be done. Perhaps we create an adhoc editing team to...may came back to this group or another group. Regardless of where it happens, it impacts many groups so leave it for now so it doesn't hinder our progress. Bernard: we will need to get consensus behind this. There will be requirements on L2 that they are not doing, so the IETF will need to motivate the lower layers to comply as well. Tim: yes, it will have to be compelling enough to make everyone do it. But we don't want to hold other work until this gets sorted out. + Enhanced TLS Joe: we can move off this update to next item on the "enhanced TLS" item. Bernard: how is this different from the "tunnel method"? Joe: feedback from Jari that definition may be slightly different even though it's the same problem. Hao: to clarify, it's not 2 different methods. As far as the channel binding it's already covered in the top. Joe: will modify it to explicitly state that it's not a new method. Hao: we do need to ensure that "emergency call" scenarios are supported. Joe: a response was made to TGu, that we "could" support them but until we understand the security requirements of the emergency call and operational requirements, it's not clear how we can tailor EAP-TLS to meet their requirements. Hao: am personally advocating that we should support such a scenario. Joe: that is fine, but we will need to get clarifications on requirements from them. Glen Zorn: combing slides 6 and 7, there is probably a politically morass given that these can constrain requirements to two methods that have already been deployed. Joe: while there is a desire to do that, it is not specifically requiring it to be a particular method. This particular item is to state that we don't want to create a new EAP TLS based method. Steve: can clarify by stating "based on EAP-TLS or a TLS based tunnel method in the preceding item". +Password Method Joe: Next item discussion are the updates on Slide 7: "A mechanism that makes use of existing password databases such as AAA databases. The implementation should strive to be usable in resource constrained environments. This item will make use of the above tunnel method." Dan Harkins: does the "constrain" mean no PKI? Sam: if don't know what it means, then take it out. Glen: don't want to take it out, but we should clarify. It's a good thing to have as there are large customers do work in resource constrained environments like 3GPP and 3GPP2. For this to be really useful, we should be able to clarify such as "resource constrained environments, such as mobile phones." Bernard: we did have a discussion in GPSK. One of the conclusions was that couldn't do a full TLS...but adding this to the work item may Dan: a suggestion is to remove that sentence Joe: group has already chosen this direction. Pasi: note that current phone does support PKI Sam: adding example will not help. To be useful as a constraint, we need to be clear what the constraint is....must work in an environment without PKI would be fine, but is one that we would disagree with. If there's no volunteer to clarify, then drop it. Glen Zorn: volunteers to help make this concrete. =09 + Milestone update - tunnel method items: add item for requirements draft Glen: this (requirements) would be a good place to impose resource constraints in here.=20 Joe: we can discuss them during requirements, not sure it makes sense to impose in charter until we have clarity. Hao: there should be 3 things in tunnel method, two of which are mentioned but the inner method extensions are missing, not to mention what the clarification of "inner methods". Discussed tunnel and password method requirements but we need to define what the inner authentication mechanisms. Need to see a definition of what "inner authentication" (like method sequencing, data exchanges, vendor extensions) means. Joe: we should call that out in the charter though. At this point, need to determine what the requirements are. Hao: for the "extended tls method extension" deliverables, is that base on the EAP-TLS method or the new method? (Joe agrees that it may apply to both?) Steve: agree that constraint environments should be included. Suggest that "resource constraint" and level to which it is needed should be part of the requirements definition and not necessarily part of the charter. Tim & Joe: agree....during requirements definition is when we as a group can decide the constraints. =20 Glen accepts this...though milestones don't quite mesh yet as there are no requirements for the password method in the deliverables. Point is that we should be more explicit. Joe: brought in by reference is that it would be included. But, we can remove the "resource constraints" from the charter. Joe: Take milestone discussion to the list.=20 (presentation modified during discussion is available with proceedings) --------------------------------- Tunnel Method Presentations --------------------------------- + Steve Hanna Presents on EAP-TTLS * New drafts for crypto agility and extensions for TTLS. * Overview of TTLS protocol and supported features * Extensions to TTLS: PRF negotiation through TLS version; crypto binding through a key-confirmation AVP=20 - Hao: what keys are used to generate the crypto-binding? So, if the inner method fails, TTLS can not do the key confirmation. =20 - Steve: correct. Pat Calhoun: have addressed security issues with TTLS, that is good. Should the standard address current security requirements and how would the legacy be enabled and handled as it would have to be supported? Steve: this depends on the group, whether we start from an existing method and upgrade then to include the security extensions. TLS adds support for transition through turning on M bit. Up to WG to decide on whether new functionality falls under new EAP method or not. Not a strong position either way. + Gene Chang presents on EAP-FAST * description of deployed features inclusive of security considerations * features include flexibility and scalability of credential types and computational constraints Sam: PAC What is it? How can you get one? referred as RFC 4507. Joe: PAC is like a ticket as defined by the RFC Sam: how do you get a ticket if you don't get it via a certificate. Gene: can provision in-band through the protocol or manually (out-of-band). Hao: PAC is in RFC 4851 and used as defined in RFC 4507 -------------------------------- Requirements Discussion -------------------------------- * Can start with password based methods since members were already thinking of tunnel methods Hao: we'll need to add crypto agility Joe: hold that for now and add it during the brainstorm. Looking at current requirements, we'll need to make sure that we can meet RFC 3748, 4017, eap keying, etc. Hao: authentication of the EAP headers should be included and Identity privacy. Sam: if we are going to do anything with TLS, it needs to be reviewed by the TLS group. Any mechanism like the PAC should be reviewed by the TLS community. Joe: so any novel uses of TLS should be approved by the TLS community. Sam: how about requirement that the use of TLS and the tunnel method be removed by the TLS community before completion of our work. Consensus that suggestion is a good idea. Steve: are these requirements for the tunnel method or the password method? Joe: we need to cover both, thus far these requirements are for both. We could treat them as separate requirements. Steve: requirements for the two are largely disjoint; no strong opinion on whether its one or two documents. If it is one document, then they should be described as two totally different things. For example: password requirement may not need to include mutual authentication. Joe: since group has decided to address password thru tunnel, the combination must meet the requirement of mutual authentication. While the requirements are disjoint, there may be some specific to tunnel or to password, but there are interdependencies...so we need to make sure that the combined meet full requirements. Agreement that we do need to be clear. Kaushik: are we creating a new set of requirements? Shouldn't the requirements be to include existing password methods? =20 Joe: don't know that it is part of the charter....we are to support existing databases not necessarily methods. If we're supporting EAP authentication mechanisms within the tunnel, those will have their set of requirements. Hao: just as we mentioned internationalization, agree with Steve that we need to list separate set of requirements. Glen: ultimate goal is to get secure password based method; tunnel method is to facilitate this. Joe: yes, but there are those that want to support other features beyond password authentication in the tunnel. Glen: having designed a tunnel method before, would like to state that it would be better to design these things together so that they work appropriately. Generalization would be the enemy of this. If we're to design a password based method, making the tunnel method support "the kitchen sink" is not a good idea....focus should be on password first and not make the goal to support other things. Steve: disagrees. If we look at them together, that is good; but its not desirable that we only focus on the password only. There was consensus by the group to not specialize for password based method only; not suggesting we expand the scope to include everything. But it would be an error to only consider password. Glen: intent was to ensure that the tunnel based and password based method and how they work together are extremely well understood. Generalizing makes it harder to do analysis. Joe: agreement that we need to consider the password method within the tunnel method. There is a constrained set, though not fully constrained yet, of other conversations that may happen within the tunnel. Glen: if tunnel method is well designed, then probability that its confined to only work with the particular password method is low. Not sure that password change really belongs here. Joe: there was consensus that this was a desirable feature. Steve: change of topic. Add requirement to include internationalization of human readable strings. Sam: should include "internationalization must be consistent with NAI, human typed passwords, and prompts. Consider errors and other indications." SASL RFC has good text on how to deal with internationalization. If you use something like RFC 4013, we should be on the right track. Glen: not sure what the point of internationalizing password. Sam: we need to ensure that it can work across different OS' which is why we need to ensure it meets the internationalization criteria. If the user has a password that contains an accented character, the bytecodes generated for that password may differ depending on which computer the user is typing on. Joe: earlier we had a requirement for Constrained devices =09 Decide the charter updates through the working list Need to get working on requirements draft together Sam: RFC 4962 and channel bindings confusion. Could use some help here, so contact Joe, Tim and Sam on how to resolve this as it is more complicated than originally thought. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Dec 19 13:06:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J53JY-0007Hq-Jh; Wed, 19 Dec 2007 13:06:40 -0500 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1J53JX-0007EJ-3v for emu-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 13:06:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J53JW-0007CY-P3 for emu@ietf.org; Wed, 19 Dec 2007 13:06:38 -0500 Received: from bay0-omc2-s41.bay0.hotmail.com ([65.54.246.177]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J53JW-00015I-EQ for emu@ietf.org; Wed, 19 Dec 2007 13:06:38 -0500 Received: from BAY117-DS2 ([207.46.8.29]) by bay0-omc2-s41.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Dec 2007 10:06:37 -0800 X-Originating-IP: [71.197.208.131] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: To: , Date: Wed, 19 Dec 2007 10:06:46 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 19 Dec 2007 18:06:37.0893 (UTC) FILETIME=[E610F750:01C84269] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Subject: [Emu] Re: EAP-TLS privacy and master_secret X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0247608584==" Errors-To: emu-bounces@ietf.org This is a multi-part message in MIME format. --===============0247608584== Content-Type: multipart/alternative; boundary="----=_NextPart_000_007A_01C84226.DD418BF0" This is a multi-part message in MIME format. ------=_NextPart_000_007A_01C84226.DD418BF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Badra said: "Hi all, When privacy is activated with respect to section 2.1.4., which master_secret (the 1st or 2nd handshake) is used in section 2.3? Best regards Badra" The master_secret from the 2nd handshake should be used.=20 ------=_NextPart_000_007A_01C84226.DD418BF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Badra said:
 
"Hi=20 all,

When privacy is activated with respect to section 2.1.4.,=20 which
master_secret (the 1st or 2nd handshake) is used in section=20 2.3?

Best regards
Badra"
 
The master_secret from the 2nd = handshake should=20 be used.
 
 
------=_NextPart_000_007A_01C84226.DD418BF0-- --===============0247608584== 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 --===============0247608584==-- From emu-bounces@ietf.org Wed Dec 19 14:33:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J54fW-0000A3-7i; Wed, 19 Dec 2007 14:33:26 -0500 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1J54fV-00009O-70 for emu-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 14:33:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J54fU-00009G-So; Wed, 19 Dec 2007 14:33:24 -0500 Received: from bay0-omc2-s33.bay0.hotmail.com ([65.54.246.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J54fS-0005Qq-HW; Wed, 19 Dec 2007 14:33:24 -0500 Received: from BAY117-W25 ([207.46.8.60]) by bay0-omc2-s33.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Dec 2007 11:33:22 -0800 Message-ID: X-Originating-IP: [71.197.208.131] From: Bernard Aboba To: , , , , , , , Date: Wed, 19 Dec 2007 11:33:21 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 19 Dec 2007 19:33:22.0001 (UTC) FILETIME=[03F4D410:01C84276] X-Spam-Score: 0.0 (/) X-Scan-Signature: d094b18a574860cb9e2fe5fedfbcc179 Cc: Subject: [Emu] Re: secdir review of draft-simon-emu-rfc2716bis-11.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: , Content-Type: multipart/mixed; boundary="===============1882535071==" Errors-To: emu-bounces@ietf.org --===============1882535071== Content-Type: multipart/alternative; boundary="_30c6aeba-f0ad-49f7-97bd-431c90e411b4_" --_30c6aeba-f0ad-49f7-97bd-431c90e411b4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you for your detailed comments.=20 I have produced an updated version of the document to address these and oth= er IETF last call comments: http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-12.txt Some responses below: - I assume that its correct to target this document at TLS 1.1 and not to consider any features that are part of TLS 1.2 which is at WGLC? Does TLS= 1.2 cause any difficulties? 2.1.1 says "TLS v1.0 or later" so hopefully there aren't any issues. (I didn't check in detail.) [rmh] No I have reviewed TLS 1.2 and I see no issues. [ba] EAP-TLS can use TLS 1.0 or later. I am not aware of any issues with TLS v1.2. However, existing implementations have only=20 been tested with TLS v1.1, so that is cited as the normative reference.=20 - In the case of a session resume, SHOULD the client_hello contain exactly = one ciphersuite? If more than one is ok there, why? (Since it says in section 2.1.1 that "If the session matches the client's, then the ciphersuite MUS= T match the one negotiated during the handshake protocol execution that established the session.") [ba] In EAP-TLS, the peer does not necessarily know whether it will encount= er the same AAA server as before. As a result, an attempt to resume can fail,= in which case the server will select among the ciphersuites offered by the pee= r.=20 Therefore having the peer provide only a single ciphersuite can increase the chance of negotiation failure after an unsuccessful resume att= empt.=20 - In section 2.1.3 1st para, the server sends an alert " so as to allow the peer to inform the user of the cause of the failure..." What if there's n= o user? Is there a bit of applicability stuff missing here? (I'm assuming t= hat this protocol could be used by devices like a wireless printer.) [rmh] Would a change to the effect of the following address this concern: "so as to allow the peer to inform the user or log of the cause of the fail= ure..." [BA] Added.=20 - 2.1.3, 2nd para. The anti-DoS limit to the number of restarts. Does that = only apply per client or should there also be an overall limit on the number o= f outstanding "hanging" sessions? [BA] Added clarification about a per-client limit.=20 - 2.1.3: should the peer re-use the same session id for a number of attempt= s when server authentication fails? I think one could argue that the peer SHOULD delete that session from its cache or whatever on the basis that t= he peer sending the TLS alert might expose some information. [BA] How about this?=20 "If EAP server authentication is unsuccessful, the peer SHOULD delete the session from its cache, preventing reuse of the sessionId." - 2.1.4 says "In order to determine the privacy configuration on link layer= s (such as IEEE 802 wired networks) which do not support network advertisem= ent, it may be desirable to utilize information provided in the server certifi= cate or within identity selection hints [RFC4284] to determine the appropriate configuration." That seems overly vague - what information? (And I note t= hat rfc4284 itself says that is limited to small scale networks.) [BA] Added mention of the subject and subjectAltName fields. =20 - 2.1.5 says "However, in order to ensure interoperability with existing implementations, TLS handshake messages SHOULD NOT be fragmented into multiple TLS records if they fit within a single TLS record." (which is f= ine, except should it say "multiple EAP-Responses"?) Does that also mean that = a set of TLS handshake messages SHOULD NOT be fragmented if they all fit in a s= ingle MTU? (i.e. would it be ok to split the TLS certificate, client_key_exchan= ge from the change_cipher_spec and finished if all 4 would fit in a single EAP-Response?) [BA] The statement was about TLS records, not about EAP-TLS fragmentation. = So it would be ok to split the TLS certificate, etc. messages even if it would= fit in a single EAP-Response (although that would be inefficient). =20 - 2.2 discusses when a certificate subject (or alt name?) is identical to t= he identity from an EAP-Response/Identity message. Is that comparison sufficiently well-defined? In particular the uri alt name choice might ha= ve some issues. (And a forward pointer to section 5.2 would be useful here.) [BA] The point being made in this section is that there is no need for such= a comparison, because the EAP-Response/Identity is only used for routing purp= oses as described in RFC 3748. Added the forward reference.=20 - Section 2.3 seems to describe a specific TLS extractor (as in draft-rescorla-tls-extractor). Would it be better to move (now or in futu= re) to that more generic sheme? [rmh] Right now the goal of this effort is to document what implementations= do today, changes=20 such as this might make sense long term but are not compatible with that go= al. - Would it make sense to align the mandatory ciphersuites with those being chosen for TLS 1.2? [rmh] The goal of the effort is to document what implementations do today. Since none of todays implementations are based on 1.2 we have retained the = 1.1 mandatory ciphersuite.=20 - Section 5.3 says "it must be pre-configured" - ought that be a MUST? (Sam= e section has a lot of lowercase occurrences of "may") [BA] I don't think the intent is to specify a normative requirement in this= case.=20 How about this? "Where the EAP-TLS server is unable to retrieve intermediate certificates, it either will need to be pre-configured with the necessary = =20 intermediate certificates to complete path validation or it will rely on the EAP-TLS peer to provide this information as part of the TLS Handshake (see [RFC4346] section 7.4.6)." - Section 5.4 says the peer MUST be able to check cert status after network access is available. Presumably that should be done quickly and has to include all intermediate CA certs as well as the server cert? If one of t= hose is revoked or no information is available what should the peer do? (Aside= : is this really used?) [rmh] In our implementation we do post admission checks as well as OCSP in-= band=20 via the OCSP TLS extension however I am hesitate to over specify how this s= hould=20 be done, as different enviroments, scenarios and policies mandate different= =20 approaches and when it comes to the authoritative documents for revocation= =20 checking 2560, 5019 and 3280 are the authoritative documents. Editorial - It'd be good if the abstract said whether or not this is backwards compat= ible with RFC 2716 or not. Without having read 2716, I'm still not clear. [rmh] It is, and thats the intent; I am not apposed to further clarificatio= n. [BA] Added a statement to this effect in Section 1.=20 - Seems a bit odd to specify the length, but nothing else for the MSK and E= MSK in the terminology section. Saying less is probably easier. [BA] Removed mention of the length, since this is already stated in RFC 374= 8.=20 - 2.1.1 says " While the EAP server SHOULD require client authentication, t= his is not a requirement, since it may be possible that the server will requi= re that the peer authenticate via some other means." Using "require" three t= imes there is odd. [BA] How about this?=20 "While the EAP server SHOULD require client authentication, this is not=20 mandatory, since there are circumstances in which client authentication will not be needed (e.g. emergency services, as described in [UNAUTH]), or = where the peer will authenticate via some other means." - 2.1.2 2nd para uses the term NAS without expansion, "tunnel server" isn't defined and "rotary" and "remoted" aren't entirely clear. Suggest reword= ing this paragraph. [BA] How about this?=20 "In the case where the EAP server and authenticator reside on the same device, then peer will only be able to continue sessions when connecting to the same authenticator. Should the authenticators be set up in a rotary or round-robin then it may not be possible for the peer to know in advance the authenticator it will be connecting to, and therefore which sessionId to attempt to reuse." - 2.1.3 3rd para says "verify the hash" without saying which hash. [BA] I presume we're talking about the Finished message, no? Do we need to state that explicitly?=20 - 2.1.3 4th para "server authenticates unsuccessfully" is very odd wording [BA] How about "If EAP server authentication is unsuccessful..." - 2.1.4, 5th para says "MUST accept a client certificate" which is too stro= ng, I guess what's meant is that they "MUST be able to accept..." since e.g. = the client cert might be revoked. [rmh] Yes that is the intent, I am not opposed to the change. [BA] Done.=20 - 2.1.5 is "may be desirable" right? That paragraph seems a bit vague overa= ll. [rmh] Yes, that is an ok change. [BA] Are we talking about the second paragraph? Is there a suggested chang= e in the text?=20 " In order to protect against reassembly lockup and denial of service attacks, it may be desirable for an implementation to set a maximum size for one such group of TLS messages. Since a single certificate is rarely longer than a few thousand octets, and no other field is likely to be anywhere near as long, a reasonable choice of maximum acceptable message length might be 64 KB." - Sections 5.3 and 5.4 seem more like protocol than security considerations= . If it were easily do-able, I suggest moving those to somewhere in section 2. [BA] Making this big a change could introduce unintended consequences, so I'm wary of it.=20 typos: - Intro, 2nd para, s/a EAP peer/an EAP peer/ - Indenting of 1.2 is wrong - 2.1.1 s/then client/then the client/ - 2.1.3 s/message rather immediately/message immediately/ - 2.1.3 s/If the peers authenticates/If the peer authenticates/ - 2.1.4 has a lower case "should" that I think ought be SHOULD? [BA] Fixed.=20 > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Monday, December 17, 2007 9:10 AM > To: secdir@mit.edu; Ryan Hurst; Bernard Aboba; Dan Simon > Cc: Salowey, Joe; Sam Hartman > Subject: secdir review of draft-simon-emu-rfc2716bis-11.txt >=20 >=20 > I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. >=20 > Overall, there are at least some typos and editorial comments that I would say should be fixed and possibly a few technical issues. My review is attached. >=20 > Regards, > Stephen. >=20 --_30c6aeba-f0ad-49f7-97bd-431c90e411b4_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you for your detailed comments.

I have produced an updated ve= rsion of the document to address these and other IETF last call comments:http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-12.txt
Some responses below:

- I assume that its correct to target this d= ocument at TLS 1.1 and not to
  consider any features that are part= of TLS 1.2 which is at WGLC? Does TLS 1.2
  cause any difficulties= ? 2.1.1 says "TLS v1.0 or later" so hopefully there
  aren't any is= sues. (I didn't check in detail.)

[rmh] No I have reviewed TLS 1.2 a= nd I see no issues.

[ba] EAP-TLS can use TLS 1.0 or later.  I a= m not aware of
any issues with TLS v1.2.  However, existing impleme= ntations have only
been tested with TLS v1.1, so that is cited as the n= ormative reference.

- In the case of a session resume, SHOULD the c= lient_hello contain exactly one
  ciphersuite? If more than one is = ok there, why? (Since it says in section
  2.1.1 that "If the sessi= on matches the client's, then the ciphersuite MUST
  match the one = negotiated during the handshake protocol execution that
  establish= ed the session.")

[ba] In EAP-TLS, the peer does not necessarily kno= w whether it will encounter
the same AAA server as before.  As a re= sult, an attempt to resume can fail, in
which case the server will selec= t among the ciphersuites offered by the peer.
Therefore having the peer= provide only a single ciphersuite can
increase the chance of negotiatio= n failure after an unsuccessful resume attempt.

- In section 2.1.3 = 1st para, the server sends an alert " so as to allow the
  peer to = inform the user of the cause of the failure..." What if there's no
 = ; user? Is there a bit of applicability stuff missing here? (I'm assuming t= hat
  this protocol could be used by devices like a wireless printe= r.)

[rmh] Would a change to the effect of the following address this= concern:

"so as to allow the peer to inform the user or log of the = cause of the failure..."

[BA] Added.

- 2.1.3, 2nd para. The = anti-DoS limit to the number of restarts. Does that only
  apply pe= r client or should there also be an overall limit on the number of
 = ; outstanding "hanging" sessions?

[BA] Added clarification about a p= er-client limit.

- 2.1.3: should the peer re-use the same session i= d for a number of attempts
  when server authentication fails? I th= ink one could argue that the peer
  SHOULD delete that session from= its cache or whatever on the basis that the
  peer sending the TLS= alert might expose some information.

[BA] How about this?

"= If EAP server authentication is unsuccessful, the peer SHOULD
delete the= session from its cache, preventing reuse of the
sessionId."

- 2.= 1.4 says "In order to determine the privacy configuration on link layers  (such as IEEE 802 wired networks) which do not support network adve= rtisement,
  it may be desirable to utilize information provided in= the server certificate
  or within identity selection hints [RFC42= 84] to determine the appropriate
  configuration." That seems overl= y vague - what information? (And I note that
  rfc4284 itself says = that is limited to small scale networks.)

[BA] Added mention of the = subject and subjectAltName fields. 

- 2.1.5 says "However, in = order to ensure interoperability with existing
  implementations, T= LS handshake messages SHOULD NOT be fragmented into
  multiple TLS = records if they fit within a single TLS record." (which is fine,
  = except should it say "multiple EAP-Responses"?) Does that also mean that a = set
  of TLS handshake messages SHOULD NOT be fragmented if they al= l fit in a single
  MTU? (i.e. would it be ok to split the TLS cert= ificate, client_key_exchange
  from the change_cipher_spec and fini= shed if all 4 would fit in a single
  EAP-Response?)

[BA] Th= e statement was about TLS records, not about EAP-TLS fragmentation.  S= o
it would be ok to split the TLS certificate, etc. messages even if it = would fit
in a single EAP-Response (although that would be inefficient).=  

- 2.2 discusses when a certificate subject (or alt name?) is= identical to the
  identity from an EAP-Response/Identity message.= Is that comparison
  sufficiently well-defined? In particular the = uri alt name choice might have
  some issues. (And a forward pointe= r to section 5.2 would be useful here.)

[BA] The point being made in= this section is that there is no need for such a
comparison, because th= e EAP-Response/Identity is only used for routing purposes
as described i= n RFC 3748.   Added the forward reference.

- Section 2.3 = seems to describe a specific TLS extractor (as in
  draft-rescorla-= tls-extractor). Would it be better to move (now or in future)
  to = that more generic sheme?

[rmh] Right now the goal of this effort is = to document what implementations do today, changes
such as this might m= ake sense long term but are not compatible with that goal.

- Would i= t make sense to align the mandatory ciphersuites with those being
 = chosen for TLS 1.2?

[rmh] The goal of the effort is to document wha= t implementations do today.
Since none of todays implementations are bas= ed on 1.2 we have retained the 1.1
mandatory ciphersuite.

- Sect= ion 5.3 says "it must be pre-configured" - ought that be a MUST? (Same
&= nbsp; section has a lot of lowercase occurrences of "may")

[BA] I do= n't think the intent is to specify a normative requirement in this case. How about this?

"Where the EAP-TLS server is unable to retrieve in= termediate
certificates, it either will need to be pre-configured with t= he necessary 
intermediate certificates to complete path validatio= n or
it will rely on the EAP-TLS peer to provide this information as
= part of the TLS Handshake (see [RFC4346] section 7.4.6)."

- Section = 5.4 says the peer MUST be able to check cert status after network
 = access is available. Presumably that should be done quickly and has to
=   include all intermediate CA certs as well as the server cert? If one= of those
  is revoked or no information is available what should t= he peer do? (Aside: is
  this really used?)

[rmh] In our imp= lementation we do post admission checks as well as OCSP in-band
via the= OCSP TLS extension however I am hesitate to over specify how this should <= br>be done, as different enviroments, scenarios and policies mandate differ= ent
approaches and when it comes to the authoritative documents for rev= ocation
checking 2560, 5019 and 3280 are the authoritative documents.
Editorial

- It'd be good if the abstract said whether or not t= his is backwards compatible
  with RFC 2716 or not. Without having = read 2716, I'm still not clear.

[rmh] It is, and thats the intent; I= am not apposed to further clarification.

[BA] Added a statement to = this effect in Section 1.

- Seems a bit odd to specify the length, = but nothing else for the MSK and EMSK
  in the terminology section.= Saying less is probably easier.

[BA] Removed mention of the length,= since this is already stated in RFC 3748.

- 2.1.1 says " While the= EAP server SHOULD require client authentication, this
  is not a r= equirement, since it may be possible that the server will require
 = that the peer authenticate via some other means." Using "require" three ti= mes
  there is odd.

[BA] How about this?

"While the = EAP server SHOULD require client authentication, this is not
mandatory,= since there are circumstances in which client authentication
will not b= e needed (e.g. emergency services, as described in [UNAUTH]), or where
t= he peer will authenticate via some other means."

- 2.1.2 2nd para us= es the term NAS without expansion, "tunnel server" isn't
  defined = and "rotary" and "remoted" aren't entirely clear.  Suggest rewording  this paragraph.

[BA] How about this?

"In the case w= here the EAP server and authenticator reside on the same
device, then pe= er will only be able to continue sessions when
connecting to the same au= thenticator.  Should the authenticators be
set up in a rotary or ro= und-robin then it may not be possible for the
peer to know in advance th= e authenticator it will be connecting to,
and therefore which sessionId = to attempt to reuse."

- 2.1.3 3rd para says "verify the hash" withou= t saying which hash.

[BA] I presume we're talking about the Finished= message, no? Do we need to
state that explicitly?

- 2.1.3 4th p= ara "server authenticates unsuccessfully" is very odd wording

[BA] H= ow about "If EAP server authentication is unsuccessful..."

- 2.1.4, = 5th para says "MUST accept a client certificate" which is too strong,
&n= bsp; I guess what's meant is that they "MUST be able to accept..." since e.= g. the
  client cert might be revoked.

[rmh] Yes that is the= intent, I am not opposed to the change.

[BA] Done.

- 2.1.5 = is "may be desirable" right? That paragraph seems a bit vague overall.
<= br>[rmh] Yes, that is an ok change.

[BA] Are we talking about the se= cond paragraph?  Is there a suggested change in the text?

"&nb= sp;  In order to protect against reassembly lockup and denial of servi= ce
   attacks, it may be desirable for an implementation to se= t a maximum
   size for one such group of TLS messages.  = Since a single certificate
   is rarely longer than a few thou= sand octets, and no other field is
   likely to be anywhere ne= ar as long, a reasonable choice of maximum
   acceptable messa= ge length might be 64 KB."

- Sections 5.3 and 5.4 seem more like pro= tocol than security considerations. If
  it were easily do-able, I = suggest moving those to somewhere in section 2.

[BA] Making this big= a change could introduce unintended consequences, so
I'm wary of it.
typos:

- Intro, 2nd para, s/a EAP peer/an EAP peer/
- Inden= ting of 1.2 is wrong
- 2.1.1 s/then client/then the client/
- 2.1.3 s= /message rather immediately/message immediately/
- 2.1.3 s/If the peers = authenticates/If the peer authenticates/
- 2.1.4 has a lower case "shoul= d" that I think ought be SHOULD?

[BA] Fixed.

> -----Origi= nal Message-----
> From: Stephen Farrell [mailto:stephen.farrell@cs.t= cd.ie]
> Sent: Monday, December 17, 2007 9:10 AM
> To: secdir@m= it.edu; Ryan Hurst; Bernard Aboba; Dan Simon
> Cc: Salowey, Joe; Sam = Hartman
> Subject: secdir review of draft-simon-emu-rfc2716bis-11.txt=
>
>
> I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.
>
> Overall, there are at least some typos and editorial comments that I would say should be fixed and possibly a few technical issues. My review is attached.
>
> Regards,
> Stephen.
>
= = --_30c6aeba-f0ad-49f7-97bd-431c90e411b4_-- --===============1882535071== 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 --===============1882535071==-- From emu-bounces@ietf.org Fri Dec 21 11:23:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5keS-0007sT-4T; Fri, 21 Dec 2007 11:23:08 -0500 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1J5kWv-0008IV-EY for emu-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 11:15:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5kWu-0008HK-LT for emu@ietf.org; Fri, 21 Dec 2007 11:15:20 -0500 Received: from wpad.iss.tcd.ie ([134.226.1.156] helo=imx2.tcd.ie) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5kWr-0001xV-Nu for emu@ietf.org; Fri, 21 Dec 2007 11:15:19 -0500 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 9AB40681C1; Fri, 21 Dec 2007 16:15:16 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A045FA96D66; Fri, 21 Dec 2007 16:15:16 +0000 Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id 8E5E7681C1; Fri, 21 Dec 2007 16:15:16 +0000 (GMT) Message-ID: <476BE69C.7020103@cs.tcd.ie> Date: Fri, 21 Dec 2007 16:15:24 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A145FA96D66 X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.57.6 VDF=9.117.8) X-Spam-Score: -4.0 (----) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-Mailman-Approved-At: Fri, 21 Dec 2007 11:23:07 -0500 Cc: dansimon@microsoft.com, secdir@mit.edu, rmh@microsoft.com, emu@ietf.org Subject: [Emu] Re: secdir review of draft-simon-emu-rfc2716bis-11.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 Bernard Aboba wrote: > Thank you for your detailed comments. > > I have produced an updated version of the document to address these and > other IETF last call comments: > http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-12.txt Except as noted below those look fine. And since the things below are ok too, I've no remaining issues with this draft. Regards, Stephen. > - 2.1.3 3rd para says "verify the hash" without saying which hash. > > [BA] I presume we're talking about the Finished message, no? Do we need to > state that explicitly? I'd just say "verify the finished message" but its a nit. > - 2.1.5 is "may be desirable" right? That paragraph seems a bit vague > overall. > > [rmh] Yes, that is an ok change. > > [BA] Are we talking about the second paragraph? Is there a suggested > change in the text? > > " In order to protect against reassembly lockup and denial of service > attacks, it may be desirable for an implementation to set a maximum > size for one such group of TLS messages. Since a single certificate > is rarely longer than a few thousand octets, and no other field is > likely to be anywhere near as long, a reasonable choice of maximum > acceptable message length might be 64 KB." Actually on re-reading I also it clearer so you can ignore me here (must've had a bad day before:-) _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Dec 21 12:13:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5lQn-00082l-CV; Fri, 21 Dec 2007 12:13:05 -0500 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1J5lQl-0007zM-KP for emu-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 12:13:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5lQk-0007zB-Qz for emu@ietf.org; Fri, 21 Dec 2007 12:13:03 -0500 Received: from bay0-omc2-s30.bay0.hotmail.com ([65.54.246.166]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5lQk-0007Eu-GG for emu@ietf.org; Fri, 21 Dec 2007 12:13:02 -0500 Received: from BAY117-DS2 ([207.46.8.29]) by bay0-omc2-s30.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Dec 2007 09:13:01 -0800 X-Originating-IP: [71.197.208.131] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: In-Reply-To: <476BE69C.7020103@cs.tcd.ie> To: "Stephen Farrell" References: <476BE69C.7020103@cs.tcd.ie> Date: Fri, 21 Dec 2007 09:13:02 -0800 X-Unsent: 1 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 21 Dec 2007 17:13:01.0902 (UTC) FILETIME=[BE032EE0:01C843F4] X-Spam-Score: 1.7 (+) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: dansimon@microsoft.com, emu@ietf.org, secdir@mit.edu, rmh@microsoft.com Subject: [Emu] Re: [secdir] secdir review of draft-simon-emu-rfc2716bis-11.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 >> [BA] I presume we're talking about the Finished message, no? Do we need >> to >> state that explicitly? > > I'd just say "verify the finished message" but its a nit. Fixed. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Dec 28 03:50:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8Aus-0005Sy-3z; Fri, 28 Dec 2007 03:50:06 -0500 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1J8Aup-0005Se-3l for emu-confirm+ok@megatron.ietf.org; Fri, 28 Dec 2007 03:50:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8Auo-0005SW-QQ; Fri, 28 Dec 2007 03:50:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J8Auo-0005YU-ED; Fri, 28 Dec 2007 03:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 4C9B02AB68; Fri, 28 Dec 2007 08:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J8Auo-0006lD-6g; Fri, 28 Dec 2007 03:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 28 Dec 2007 03:50:02 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: emu@ietf.org Subject: [Emu] I-D Action:draft-simon-emu-rfc2716bis-12.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update Working Group of the IETF. Title : The EAP TLS Authentication Protocol Author(s) : D. Simon, et al. Filename : draft-simon-emu-rfc2716bis-12.txt Pages : 33 Date : 2007-12-28 The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Level Security (TLS) provides for mutual authentication, integrity- protected ciphersuite negotiation and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation. This document obsoletes RFC 2716. A summary of the changes between this document and RFC 2716 is available in Appendix A. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-simon-emu-rfc2716bis-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-simon-emu-rfc2716bis-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-12-28034957.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-simon-emu-rfc2716bis-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-simon-emu-rfc2716bis-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-28034957.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --NextPart--