From emu-bounces@ietf.org Tue Jan 02 15:50:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1qaT-0004iE-Jj; Tue, 02 Jan 2007 15:50:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1qaB-0004Ea-OA; Tue, 02 Jan 2007 15:50:04 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1qaA-0002T0-EZ; Tue, 02 Jan 2007 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 5167926E36; Tue, 2 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H1qaA-0002n3-6O; Tue, 02 Jan 2007 15: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: Tue, 02 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: emu@ietf.org Subject: [Emu] I-D ACTION:draft-simon-emu-rfc2716bis-06.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update Working Group of the IETF. Title : The EAP TLS Authentication Protocol Author(s) : D. Simon, B. Aboba Filename : draft-simon-emu-rfc2716bis-06.txt Pages : 30 Date : 2007-1-2 The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Level Security (TLS) provides for mutual authentication, integrity- protected ciphersuite negotiation and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-06.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-06.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-06.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-1-2120538.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-simon-emu-rfc2716bis-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-simon-emu-rfc2716bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-2120538.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --NextPart-- From emu-bounces@ietf.org Mon Jan 08 15:00:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H40fl-0007NS-EC; Mon, 08 Jan 2007 15:00:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H40fk-0007NN-KI for emu@ietf.org; Mon, 08 Jan 2007 15:00:44 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H40ff-0006dn-Vo for emu@ietf.org; Mon, 08 Jan 2007 15:00:44 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 08 Jan 2007 12:00:39 -0800 X-IronPort-AV: i="4.13,160,1167638400"; d="scan'208"; a="99295478:sNHT299360826" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l08K0bVG021157; Mon, 8 Jan 2007 12:00:37 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l08K0FZp024009; Mon, 8 Jan 2007 12:00:37 -0800 (PST) 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, 8 Jan 2007 12:00:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] WGLC comments for draft-simon-emu-rfc2716bis Date: Mon, 8 Jan 2007 12:00:35 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] WGLC comments for draft-simon-emu-rfc2716bis Thread-Index: Acceufu0GdFnq7U+SSuGxcqsTB494gUotD1w From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , , X-OriginalArrivalTime: 08 Jan 2007 20:00:37.0170 (UTC) FILETIME=[AA141120:01C7335F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5153; t=1168286437; x=1169150437; 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:=20RE=3A=20[Emu]=20WGLC=20comments=20for=20draft-simon-emu-rfc27 16bis |Sender:=20; bh=KyY8d5bdgSFHdYzAbg6OF/003MONIg646bM+7RY4Mrg=; b=B4so7xDgKtys0seopu7k4SaI95iedZVedAoYXzkkdKeuT5zzuuEmx/UPS0EGjc8RF+tuQOMn NerGaw60fitobrq7DALlcAG3E091Sf+neZ3PLDwDfbJNuS47a+Vs9j8t; 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: 8fbbaa16f9fd29df280814cb95ae2290 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Bernard, I'm not sure I understand some of the text below: > The peer MUST verify the validity of the EAP server=20 > certificate, and > SHOULD also examine the Server-id in order to determine whether the > EAP server can be trusted. Even though a server certificate chains > to a trust anchor, this does not necessarily imply that it is valid > for connection to a particular network. >=20 > Comparing the Server-Id in the certificate to the expected server > name limits the damage that will result from an attacker=20 > compromising > a server private key. If the peer does not check the=20 > Server-Id, then > the peer would accept a compromised server certificate chaining to > any of the configured trust anchors. >=20 [Joe] If the server key is compromised then it seems checking the server-ID will not help discover this or limit damage. =20 > The peer MAY also test whether the EAP server certificate is signed > by a CA controlling the destination network and whether=20 > the Server-Id > matches the format expected for that network. For example, an EAP > peer connecting to the "EXAMPLE" SSID may check whether=20 > the Server-Id > matches the regular expression "*.example.com", in addition to > checking whether the server certificate chains to the=20 > example.com CA." >=20 > -------------------------------------------------------------- > ----------------------------------------- > >From: > >To: , > >Subject: RE: [Emu] WGLC comments for draft-simon-emu-rfc2716bis > >Date: Wed, 13 Dec 2006 09:52:13 +0200 > > > >Thanks for handling my comments so quickly! (If every author=20 > had this=20 > >fast turnaround times, IETF would get documents to RFCs in a=20 > fraction=20 > >of current time... :-) > > > >About 1: the figure in 2.6 is not quite right yet. There should be a=20 > >finished message after the first change_cipher_spec sent by=20 > the server,=20 > >and the certificate/server_key_exchange messages after the second=20 > >server_hello are not optional. > > > >About 2: I'd further suggest rephrasing the last two paragraphs of > >2.1.1 along these lines (basic case first, session=20 > resumption second): > > > > If the peer supports EAP-TLS and is configured to use it, it MUST > > respond to the EAP-Request with an EAP-Response packet of EAP- > > Type=3DEAP-TLS. If the preceding server_hello message sent by = the > > EAP server in the preceeding EAP-Request packet did not indicate > > the resumption of a previous session, the data field of=20 > this packet > > MUST encapsulate one or more TLS records containing a TLS > > client_key_exchange, change_cipher_spec and finished=20 > messages. If > > the EAP server sent a certificate_request message in the=20 > preceding > > EAP-Request packet, then unless the peer is configured=20 > for privacy > > (see Section 2.6) the peer MUST send, in addition,=20 > certificate and > > certificate_verify messages. The former contains a=20 > certificate for > > the peer's signature public key, while the latter contains the > > peer's signed authentication response to the EAP server. After > > receiving this packet, the EAP server will verify the peer's > > certificate and digital signature, if requested. > > > > If the preceding server_hello message sent by the EAP=20 > server in the > > preceding EAP-Request packet indicated the resumption of=20 > a previous > > session, then the peer MUST send only the change_cipher_spec and > > finished handshake messages. The finished message contains the > > peer's authentication response to the EAP server. > > > >(And maybe Section 2.6 could be moved to 2.1.4?) > > > >About 7: This one is not there yet. > > > >About 9: The document still doesn't specify=20 > mandatory-to-implement TLS=20 > >version (which is required in addition to=20 > mandatory-to-implement cipher=20 > >suite to get interoperability). > > > >About 11: The S bit was removed from the bit diagram, but=20 > the text "The=20 > >S bit (EAP-TLS start) is set in an EAP-TLS Start message" is still=20 > >there. > > > >Best regards, > >Pasi > > > > > -----Original Message----- > > > From: ext Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > Sent: 13 December, 2006 01:55 > > > To: Eronen Pasi (Nokia-NRC/Helsinki); emu@ietf.org > > > Subject: RE: [Emu] WGLC comments for draft-simon-emu-rfc2716bis > > > > > > I think I have now incorporated most of these comments into a=20 > > > strawman -06 document: > > >=20 > http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-06.txt > > > > > > Let me know if I've missed something. > > > >_______________________________________________ > >Emu mailing list > >Emu@ietf.org > >https://www1.ietf.org/mailman/listinfo/emu >=20 >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Jan 08 15:51:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H41SO-000488-V6; Mon, 08 Jan 2007 15:51:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H41Ry-0003JA-Fv; Mon, 08 Jan 2007 15:50:34 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H41Rx-0005uv-68; Mon, 08 Jan 2007 15:50:34 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id DE575175FB; Mon, 8 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H41RS-0004v6-G8; Mon, 08 Jan 2007 15: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: Mon, 08 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: emu@ietf.org Subject: [Emu] I-D ACTION:draft-ietf-emu-eap-gpsk-02.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-02.txt Pages : 30 Date : 2007-1-8 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-02.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-02.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-02.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-1-8124219.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-emu-eap-gpsk-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-emu-eap-gpsk-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-8124219.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --NextPart-- From emu-bounces@ietf.org Mon Jan 08 19:33:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H44vh-0002nN-DI; Mon, 08 Jan 2007 19:33:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H44vf-0002n3-RS; Mon, 08 Jan 2007 19:33:27 -0500 Received: from mgw2.sony.co.jp ([137.153.0.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H44ve-0001c8-6N; Mon, 08 Jan 2007 19:33:27 -0500 Received: from mail6.sony.co.jp ([43.0.1.208]) Received: from mail6.sony.co.jp (localhost [127.0.0.1]) by mail6.sony.co.jp (R8/Sony) with ESMTP id l090XObs023550; Tue, 9 Jan 2007 09:33:25 +0900 (JST) Received: from jptkyxim01.jp.sony.com (jptkyxim01.jp.sony.com [43.15.17.87]) by mail6.sony.co.jp (R8/Sony) with ESMTP id l090XKQ4022965; Tue, 9 Jan 2007 09:33:23 +0900 (JST) Received: from jptkyxms80.jp.sony.com ([43.20.57.1]) by jptkyxim01.jp.sony.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 9 Jan 2007 09:33:17 +0900 Received: from mail pickup service by jptkyxms80.jp.sony.com with Microsoft SMTPSVC; Tue, 9 Jan 2007 09:16:51 +0900 Received: from mail5.sony.co.jp ([43.0.1.204]) by jptkyxim03.jp.sony.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 9 Jan 2007 06:03:08 +0900 Received: from mail5.sony.co.jp (localhost [127.0.0.1]) by mail5.sony.co.jp (R8/Sony) with ESMTP id l08L1POX011169 for ; Tue, 9 Jan 2007 06:01:31 +0900 (JST) Received: from ns5.sony.co.jp (mail11.sony.co.jp [43.15.125.7]) by mail5.sony.co.jp (R8/Sony) with ESMTP id l08L175J010258; Tue, 9 Jan 2007 06:01:07 +0900 (JST) Received: from megatron.ietf.org (stiedprmman1.ietf.ORG [156.154.16.145]) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H41SS-0004BL-6B; Mon, 08 Jan 2007 15:51:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H41Ry-0003JA-Fv; Mon, 08 Jan 2007 15:50:34 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H41Rx-0005uv-68; Mon, 08 Jan 2007 15:50:34 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id DE575175FB; Mon, 8 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H41RS-0004v6-G8; Mon, 08 Jan 2007 15: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: Mon, 08 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 08 Jan 2007 21:03:34.0882 (UTC) FILETIME=[75C52C20:01C73368] X-Spam-Score: 0.3 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: emu@ietf.org Subject: [Emu] I-D ACTION:draft-ietf-emu-eap-gpsk-02.txt X-BeenThere: emu@ietf.org Reply-To: internet-drafts@ietf.org 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-02.txt Pages : 30 Date : 2007-1-8 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-02.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-02.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-02.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-1-8124219.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-emu-eap-gpsk-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-emu-eap-gpsk-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-8124219.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --NextPart-- From emu-bounces@ietf.org Mon Jan 08 22:39:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H47pc-0006G0-8O; Mon, 08 Jan 2007 22:39:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H47pb-0006Fv-39 for emu@ietf.org; Mon, 08 Jan 2007 22:39:23 -0500 Received: from mail2.genealogia.fi ([194.100.116.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H47pZ-0005vY-JZ for emu@ietf.org; Mon, 08 Jan 2007 22:39:23 -0500 Received: from dsl017-049-110.sfo4.dsl.speakeasy.net ([69.17.49.110] helo=jm) by mail2.genealogia.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1H47pO-00065T-J7; Tue, 09 Jan 2007 05:39:12 +0200 Received: by jm (sSMTP sendmail emulation); Mon, 8 Jan 2007 19:39:06 -0800 Date: Mon, 8 Jan 2007 19:39:06 -0800 From: Jouni Malinen To: clancy@ltsnet.net, Hannes.Tschofenig@siemens.com Subject: Re: [Emu] I-D ACTION:draft-ietf-emu-eap-gpsk-02.txt Message-ID: <20070109033906.GB6653@jm.kir.nu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: -2.6 (--) X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org On Mon, Jan 08, 2007 at 03:50:02PM -0500, Internet-Drafts@ietf.org wrote: > Title : EAP Generalized Pre-Shared Key (EAP-GPSK) > Author(s) : C. Clancy, H. Tschofenig > Filename : draft-ietf-emu-eap-gpsk-02.txt Some comments.. General - How long are the random values? 16 octets? 32 octets? * I assumed they were 32 octets (256 bits), but the draft is in conflict with itself.. * 2. Terminology: 16 octets (this was 256 bits in -00) * 7.3. Payload Formatting: 32 octets * 9.4. Replay Protection: 16 octets * 9.8. Denial of Service Resistance: 16 octets 2. Terminology - MSK and EMSK were changed from 512 bits (64 octets) to 32 octets * Why? * Other EAP methods use 64 octet MSK and EMSK, so I hope this was just an accident and the purpose was only to move from bits to octets: s/32 octets/64 octets/ * Similar change in 4. Key Derivation (though, that section is also using 64 octets.. only Figure 2 is incorrect; s/32-octet/64-octet/) 3. Overview - Order of CSuite_Sel and CSuite_List in GPSK-2 was reversed * Why? * 7.3. Payload Formatting is still using the previous order, i.e., CSuite_List before CSuite_Sel; in other words, there is now conflict between sections 3 and 7.3 on the order of these fields 5. Ciphersuites - definitions of GKDF-X(Y, Z) was changed, but some cleanup missing * 'X' is not used anymore as an input to hash function and because of this, there is no need to say that it is repredsented as a 2-octet value in network byte order: s/'i' and 'X' in M_i are represented as 2-octet values/ 'i' is represented as 2-octet value/ 6.1.1. Encryption - CBC is mentioned to require an IV * However, there is no definition on where this IV is coming from or how it is to be transmitted to the other party * How exactly is this supposed to work? 8. Packet Processing Rules - typo: s/receving/receiving/ - "(i.e. an EAP client receiving GPSK-3 before receving GPSK-1 or before transmitting GPSK-2)" * isn't that more of an example (e.g.) than the only possible case (i.e.)? * s/i.e./e.g./ - "GPSK-1 contains no MAC protection, so provided it properly parses, it MUST be accepted by the client." * MUST?? * What if CSuite_List in GPSK-1 does not include any supported cipher? - s/EAP-NACK/EAP-Nak/ to match with "Nak" spelling in RFC 3748 - "A client receiving a GPSK-Fail or GPSK-Protected-Fail message in response to a GPSK-2 message MUST either transmit an EAP-Failure message and end the session" * Success and Failure messages are sent by authenticator, not peer * This should probably be changed to say that client (peer) is sending back GPSK-Fail / GPSK-Protected-Fail, not EAP-Failure, to acknowledge failure; this will be followed by the authenticator sending EAP-Failure - "For GPSK-3, a client MUST silently discard any packet containing whose RAND_Client, RAND_Server, or CSuite_Sel fields do match those transmitted in GPSK-2." * There's something wrong with this sentence.. s/whose // s/do match/that do not match/ 9.4. Replay Protection - typo: s/RAND_P/RAND_Client/ 9.8. Denial of Service Resistance - typo: s/RAND_S/RAND_Server/ -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Jan 08 22:41:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H47rP-000791-7v; Mon, 08 Jan 2007 22:41:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H47rO-00078t-8Q for emu@ietf.org; Mon, 08 Jan 2007 22:41:14 -0500 Received: from bay0-omc3-s20.bay0.hotmail.com ([65.54.246.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H47rL-00067O-VR for emu@ietf.org; Mon, 08 Jan 2007 22:41:14 -0500 Received: from hotmail.com ([207.46.8.92]) by bay0-omc3-s20.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 8 Jan 2007 19:41:11 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 8 Jan 2007 19:41:10 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Tue, 09 Jan 2007 03:41:07 GMT X-Originating-IP: [131.107.0.73] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: jsalowey@cisco.com, Pasi.Eronen@nokia.com, emu@ietf.org Bcc: Subject: RE: [Emu] WGLC comments for draft-simon-emu-rfc2716bis Date: Mon, 08 Jan 2007 19:41:07 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 09 Jan 2007 03:41:10.0920 (UTC) FILETIME=[0113B080:01C733A0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org > > Comparing the Server-Id in the certificate to the expected server > > name limits the damage that will result from an attacker compromising > > a server private key. If the peer does not check the Server-Id, then > > the peer would accept a compromised server certificate chaining to > > any of the configured trust anchors. > > > >[Joe] If the server key is compromised then it seems checking the >server-ID will not help discover this or limit damage. Maybe this should have been "compromising a trust anchor private key". I think the idea was to prevent a compromise of a trust anchor from enabling attackers to carry out "rogue authenticator" attacks across the board. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Jan 08 23:09:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H48Ie-0001l2-PP; Mon, 08 Jan 2007 23:09:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H48Ic-0001ik-MP for emu@ietf.org; Mon, 08 Jan 2007 23:09:22 -0500 Received: from mail2.genealogia.fi ([194.100.116.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H48Ib-0003QF-CT for emu@ietf.org; Mon, 08 Jan 2007 23:09:22 -0500 Received: from dsl017-049-110.sfo4.dsl.speakeasy.net ([69.17.49.110] helo=jm) by mail2.genealogia.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1H48IY-0006ET-Rb; Tue, 09 Jan 2007 06:09:20 +0200 Received: by jm (sSMTP sendmail emulation); Mon, 8 Jan 2007 20:09:13 -0800 Date: Mon, 8 Jan 2007 20:09:13 -0800 From: Jouni Malinen To: clancy@ltsnet.net, Hannes.Tschofenig@siemens.com Subject: Re: [Emu] I-D ACTION:draft-ietf-emu-eap-gpsk-02.txt Message-ID: <20070109040913.GC6653@jm.kir.nu> References: <20070109033906.GB6653@jm.kir.nu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070109033906.GB6653@jm.kir.nu> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: -2.6 (--) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org On Mon, Jan 08, 2007 at 07:39:06PM -0800, Jouni Malinen wrote: > > Title : EAP Generalized Pre-Shared Key (EAP-GPSK) > > Author(s) : C. Clancy, H. Tschofenig > > Filename : draft-ietf-emu-eap-gpsk-02.txt > > Some comments.. And one more.. 5. Ciphersuites GKDF-X(Y, Z) was modified to use "Hash-Function" instead of MAC_Y. However, there does not seem to be any definition on which hash function is used here.. SHA-1 is mentioned as a required function and "SHAs" are recommended (whatever that means; SHA-256 and friends?), but the ciphersuite does not include information on which hash function is to be used here. Previously, this was covered by the "Integrity" column of Figure 3. Should the ciphersuite table be extended to define the hash function for GKDF now? In addition, this "SHA-1" here is the only need use of SHA-1 for EAP-GPSK. Do we really need it? Was this done because of possible NIST issues with the use of AES-CMAC for KDF? -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Jan 09 07:17:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Fuv-0002S7-JJ; Tue, 09 Jan 2007 07:17:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Fuu-0002S2-HW for emu@ietf.org; Tue, 09 Jan 2007 07:17:24 -0500 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4Fut-0001q8-6H for emu@ietf.org; Tue, 09 Jan 2007 07:17:24 -0500 Received: from [192.168.0.52] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (rwcrmhc11) with ESMTP id <20070109121721m11003u06ke>; Tue, 9 Jan 2007 12:17:22 +0000 Message-ID: <45A38853.7030808@cs.umd.edu> Date: Tue, 09 Jan 2007 07:19:31 -0500 From: Charles Clancy User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Jouni Malinen Subject: Re: [Emu] I-D ACTION:draft-ietf-emu-eap-gpsk-02.txt References: <20070109033906.GB6653@jm.kir.nu> In-Reply-To: <20070109033906.GB6653@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: 37af5f8fbf6f013c5b771388e24b09e7 Cc: emu@ietf.org, clancy@ltsnet.net X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Jouni, In the last draft I tried to make all the terminology consistent by using octets for everything instead of bits and bytes. Apparently I can't properly divide by 8, and introduced a bunch of inconsistencies. Thanks for all your additional comments. We'll try to get them all resolved ASAP. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Jouni Malinen wrote: > On Mon, Jan 08, 2007 at 03:50:02PM -0500, Internet-Drafts@ietf.org wrote: > >> Title : EAP Generalized Pre-Shared Key (EAP-GPSK) >> Author(s) : C. Clancy, H. Tschofenig >> Filename : draft-ietf-emu-eap-gpsk-02.txt > > Some comments.. > > General > > - How long are the random values? 16 octets? 32 octets? > * I assumed they were 32 octets (256 bits), but the draft is in > conflict with itself.. > * 2. Terminology: 16 octets (this was 256 bits in -00) > * 7.3. Payload Formatting: 32 octets > * 9.4. Replay Protection: 16 octets > * 9.8. Denial of Service Resistance: 16 octets > > > 2. Terminology > > - MSK and EMSK were changed from 512 bits (64 octets) to 32 octets > * Why? > * Other EAP methods use 64 octet MSK and EMSK, so I hope this was > just an accident and the purpose was only to move from bits to > octets: s/32 octets/64 octets/ > * Similar change in 4. Key Derivation (though, that section is also > using 64 octets.. only Figure 2 is incorrect; s/32-octet/64-octet/) > > > 3. Overview > > - Order of CSuite_Sel and CSuite_List in GPSK-2 was reversed > * Why? > * 7.3. Payload Formatting is still using the previous order, i.e., > CSuite_List before CSuite_Sel; in other words, there is now conflict > between sections 3 and 7.3 on the order of these fields > > > 5. Ciphersuites > > - definitions of GKDF-X(Y, Z) was changed, but some cleanup missing > * 'X' is not used anymore as an input to hash function and because > of this, there is no need to say that it is repredsented as a > 2-octet value in network byte order: > s/'i' and 'X' in M_i are represented as 2-octet values/ > 'i' is represented as 2-octet value/ > > > 6.1.1. Encryption > > - CBC is mentioned to require an IV > * However, there is no definition on where this IV is coming from or > how it is to be transmitted to the other party > * How exactly is this supposed to work? > > > 8. Packet Processing Rules > > - typo: s/receving/receiving/ > > - "(i.e. an EAP client receiving GPSK-3 before receving GPSK-1 or before > transmitting GPSK-2)" > * isn't that more of an example (e.g.) than the only possible case > (i.e.)? > * s/i.e./e.g./ > > - "GPSK-1 contains no MAC protection, so provided it properly parses, it > MUST be accepted by the client." > * MUST?? > * What if CSuite_List in GPSK-1 does not include any supported > cipher? > > - s/EAP-NACK/EAP-Nak/ to match with "Nak" spelling in RFC 3748 > > - "A client receiving a GPSK-Fail or GPSK-Protected-Fail message in > response to a GPSK-2 message MUST either transmit an EAP-Failure > message and end the session" > * Success and Failure messages are sent by authenticator, not > peer > * This should probably be changed to say that client (peer) is sending > back GPSK-Fail / GPSK-Protected-Fail, not EAP-Failure, to > acknowledge failure; this will be followed by the authenticator > sending EAP-Failure > > - "For GPSK-3, a client MUST silently discard any packet containing > whose RAND_Client, RAND_Server, or CSuite_Sel fields do match those > transmitted in GPSK-2." > * There's something wrong with this sentence.. > s/whose // > s/do match/that do not match/ > > > 9.4. Replay Protection > > - typo: s/RAND_P/RAND_Client/ > > > 9.8. Denial of Service Resistance > > - typo: s/RAND_S/RAND_Server/ > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Jan 09 15:21:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4NSv-0004el-8k; Tue, 09 Jan 2007 15:21:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4NSu-0004ea-FU for emu@ietf.org; Tue, 09 Jan 2007 15:21:00 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4NSs-00048H-3u for emu@ietf.org; Tue, 09 Jan 2007 15:21:00 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 09 Jan 2007 12:20:44 -0800 X-IronPort-AV: i="4.13,164,1167638400"; d="scan'208"; a="456163067:sNHT4901412192" 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 l09KKiE0023716; Tue, 9 Jan 2007 12:20:44 -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 l09KKh06022452; Tue, 9 Jan 2007 12:20:43 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 12:20:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] WGLC comments for draft-simon-emu-rfc2716bis Date: Tue, 9 Jan 2007 12:20:42 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] WGLC comments for draft-simon-emu-rfc2716bis Thread-Index: AcczoALRNdUd0MFjR+Sd9q2Po7WI7QAhlpCg From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , , X-OriginalArrivalTime: 09 Jan 2007 20:20:43.0676 (UTC) FILETIME=[A3A005C0:01C7342B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3044; t=1168374044; x=1169238044; 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]=20WGLC=20comments=20for=20draft-simon-emu-rfc27 16bis |Sender:=20; bh=K3E2YJcnRI4dEcPcj47b6muAsOc71wuB4S2BlUgHheY=; b=JsbC8iueiRG4RpENpqDzDKQn27fVaW0+/x5HagOVCS/kdfdNHHw0iIwUQNidamqjtu92nf/5 JB7TRSb5BoOVhtfuWLf8iORHZ3pML5akHv1y3zolXHMvPmZxneY/yqD0; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 > > > Comparing the Server-Id in the certificate to the=20 > expected server > > > name limits the damage that will result from an=20 > attacker compromising > > > a server private key. If the peer does not check the=20 > Server-Id, then > > > the peer would accept a compromised server certificate=20 > chaining to > > > any of the configured trust anchors. > > > > > > >[Joe] If the server key is compromised then it seems checking the=20 > >server-ID will not help discover this or limit damage. >=20 > Maybe this should have been "compromising a trust anchor=20 > private key". I think the idea was to prevent a compromise=20 > of a trust anchor from enabling attackers to carry out "rogue=20 > authenticator" attacks across the board. [Joe] I don't think so, since a compromised trust anchor is a bigger problem. This text appears to mostly deal with authorization issues. Here is a proposal for some modifications to the text: In section 5.2, we may want to rethink the recommendation to use the TLS WWW EKU, I'm not sure it is appropriate. Right now I suggest we remove this paragraph. The text for the rest of the section could be replaced by the following text.=20 "Once the endpoints of the EAP-TLS conversation have been authenticated and have had their certificates validated they then must be authorized. The authorization process makes use of the contents of the certificates as well as other contextual information. While authorization requirements will vary from deployment to deployment it is RECOMMENDED that implementations be able to authorize based on the EAP Peer and EAP Server identities defined above.=20 Certificate extensions for use with EAP-TLS are discussed in "Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)" [RFC4334]. These extensions enable certificate usage to be restricted to use with lower layers such as PPP or IEEE 802.11. An EAP-TLS implementation MAY make these and other certificate fields available to the lower layer. Since authorization based on specific identities may not scale well in a large environment implementations may make use of other fields in the certificate. For example an implementation may be configured to accept all certificates issued by a CA with a certain name format as trusted. In another example the peer may test whether the EAP server certificate is signed by a CA controlling the destination network and whether the Server-Id matches the format expected for that network. For example, an EAP peer connecting to the "EXAMPLE" SSID may check whether the Server-Id matches the regular expression "*.example.com", in addition to checking whether the server certificate chains to the example.com CA. However, it is important to realize that any certificate matching the above criteria will be authorized, so this method should only be used in environments where this is guaranteed to be accurate." _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Jan 16 17:22:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6whE-0004Tz-6w; Tue, 16 Jan 2007 17:22:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6whC-0004S0-20 for emu@ietf.org; Tue, 16 Jan 2007 17:22:22 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6wh9-0002QY-71 for emu@ietf.org; Tue, 16 Jan 2007 17:22:22 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 16 Jan 2007 14:22:18 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l0GMMIwK008064 for ; Tue, 16 Jan 2007 14:22:18 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0GMM7iA010983 for ; Tue, 16 Jan 2007 14:22:18 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 14:22:03 -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: Tue, 16 Jan 2007 14:22:01 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Open issues with draft-simon-emu-rfc2716bis-06.txt Thread-Index: Acc5vL5eN2kCaPHiSsC79Ujpp4I/Vw== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 16 Jan 2007 22:22:03.0668 (UTC) FILETIME=[BFBAE540:01C739BC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1431; t=1168986138; x=1169850138; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20Open=20issues=20with=20draft-simon-emu-rfc2716bis-06.txt |Sender:=20; bh=IFEc8Ei6b1LYUwmqCG17PPoasMhI5Pg0l/xdioOYuLc=; b=Q6KHgatezPAAyWm7lga8ALxFpx2PGXmTbMY2/sbQoS5A+BU5ll1b4SntLmIosf1yx1lvJQmI gLR+ax9VeOhZ3KbWCUn92V6sEA0vWWurh3xJ4/oV5HfFc4w/iAOmmK7/; Authentication-Results: sj-dkim-5; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Emu] Open issues with draft-simon-emu-rfc2716bis-06.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 It seems that most of the issues brought up in last call are resolved or nearly resolved in draft-simon-emu-rfc2716bis-06.txt. The one area where we need more discussion is section 5.2 on certificate usage. Below are the remaining open issue I have tracked with this section, please indicate if there are others with this section or other sections that I have missed. =20 1. Use of TLS-WWW EKU=20 The question was raised that the TLS WWW EKU may not be appropriate for EAP-TLS. The suggestion was made to remove the text on EKU. Are members of the working group in favor of removing this text?=20 2. Discussion of naming This section recommends "Where the subjectAltName field is present, the Peer-Id or Server-Id is set to the contents of the subjectAltName. If subject naming information is present only in the subject field, then the Peer-Id or Server-Id is set to the Distinguished Name (DN)."=20 It is possible that more than one subjectAltName may be present in a certificate. Are there any rules as to how this is represented as a Peer name? Also would it be more consistent to use the DN unless it is empty? =20 3. Discussion of authorization The later part of this section seems to discuss authorization. A suggestion for revised text was made in http://www1.ietf.org/mail-archive/web/emu/current/msg00309.html. Does the suggested text convey the necessary information?=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Jan 16 22:41:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H71fz-0003Nn-TV; Tue, 16 Jan 2007 22:41:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H71fy-0003K9-IS for emu@ietf.org; Tue, 16 Jan 2007 22:41:26 -0500 Received: from bay0-omc3-s6.bay0.hotmail.com ([65.54.246.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H71fx-0001cv-2f for emu@ietf.org; Tue, 16 Jan 2007 22:41:26 -0500 Received: from hotmail.com ([207.46.8.111]) by bay0-omc3-s6.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 16 Jan 2007 19:41:24 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 16 Jan 2007 19:41:24 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Wed, 17 Jan 2007 03:41:20 GMT X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: jsalowey@cisco.com, emu@ietf.org Bcc: Subject: RE: [Emu] Open issues with draft-simon-emu-rfc2716bis-06.txt Date: Tue, 16 Jan 2007 19:41:20 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 17 Jan 2007 03:41:24.0198 (UTC) FILETIME=[5C4BC060:01C739E9] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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 >1. Use of TLS-WWW EKU > >The question was raised that the TLS WWW EKU may not be appropriate for >EAP-TLS. The suggestion was made to remove the text on EKU. Are >members of the working group in favor of removing this text? There are a number of EAP-TLS implementations that require TLS WWW EKUs (or any). So in practice an implementation needs to understand that or it may not interoperate. It also occurs to me that there could be some security issues that would surface. For example, if there is no indication that an EAP-TLS server is authorized for that function (e.g. if it doesn't contain a TLS WWW server EKU or any), then any machine possessing an EAP-TLS client certificate chaining to a trust anchor could use that certiciate to act as an EAP-TLS server (assuming that the NASes were configured to trust it). It seems like this could make it easier to put up a rogue NAS. With respect to the RFC 4334 OIDs, I'm ok with removing mention of them. There are no existing implementations, and as a result, there should be no expectation that EAP-TLS clients or servers will understand these extensions. It seems like these OIDs are problematic since they don't correspond to values of the NAS-Port-Type attribute, and therefore can't be compared to NAS-Port-Type values by implementations that don't understand them. >2. Discussion of naming > >This section recommends > >"Where the subjectAltName field is present, the Peer-Id or Server-Id >is set to the contents of the subjectAltName. If subject naming >information is present only in the subject field, then the Peer-Id or >Server-Id is set to the Distinguished Name (DN)." > >It is possible that more than one subjectAltName may be present in a >certificate. Are there any rules as to how this is represented as a >Peer name? Also would it be more consistent to use the DN unless it is >empty? Can someone descirbe a case where there would be more than one subjectAltName in a certificate? I'm having a hard time wrapping my head around this case. >3. Discussion of authorization > >The later part of this section seems to discuss authorization. A >suggestion for revised text was made in >http://www1.ietf.org/mail-archive/web/emu/current/msg00309.html. Does >the suggested text convey the necessary information? I'd suggest that the rest of the section include the following text (missing the RFC 4334 discussion): "Once the endpoints of the EAP-TLS conversation have been authenticated and have had their certificates validated they then must be authorized. The authorization process makes use of the contents of the certificates as well as other contextual information. While authorization requirements will vary from deployment to deployment it is RECOMMENDED that implementations be able to authorize based on the EAP Peer and EAP Server identities defined above. Since authorization based on specific identities may not scale well in a large environment implementations may make use of other fields in the certificate. For example an implementation may be configured to accept all certificates issued by a CA with a certain name format as trusted. In another example the peer may test whether the EAP server certificate is signed by a CA controlling the destination network and whether the Server-Id matches the format expected for that network. For example, an EAP peer connecting to the "EXAMPLE" SSID may check whether the Server-Id matches the regular expression "*.example.com", in addition to checking whether the server certificate chains to the example.com CA. However, it is important to realize that any certificate matching the above criteria will be authorized, so this method should only be used in environments where this is guaranteed to be accurate." _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Jan 17 15:06:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7H3F-0006ZN-CB; Wed, 17 Jan 2007 15:06:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7H3D-0006Yy-Qt for emu@ietf.org; Wed, 17 Jan 2007 15:06:27 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7H32-000559-IW for emu@ietf.org; Wed, 17 Jan 2007 15:06:19 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 17 Jan 2007 12:06:16 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l0HK6G53019283; Wed, 17 Jan 2007 12:06:16 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0HK67hs006918; Wed, 17 Jan 2007 12:06:15 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jan 2007 12:06:12 -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] Open issues with draft-simon-emu-rfc2716bis-06.txt Date: Wed, 17 Jan 2007 12:06:10 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Open issues with draft-simon-emu-rfc2716bis-06.txt Thread-Index: Acc56V8C9H9sjkNYSM+tX7u21KXWEAAfZclQ From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 17 Jan 2007 20:06:12.0877 (UTC) FILETIME=[EFE4A3D0:01C73A72] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5776; t=1169064376; x=1169928376; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20Open=20issues=20with=20draft-simon-emu-rfc271 6bis-06.txt |Sender:=20; bh=7DZXWSySdqTftwPux0dSIREvDrQjx0zioUqp7Lh1dUw=; b=yAqSPgKmCIQES6oW+A0gBNg0dCFfLzomXK1Ebp/JVcemDeT70DzN1WTxhnSi+CCyreiN5u4q eDxiMiSa5AJfnzukKAKHBGInO2hl/NoWXEej8lgZf8hSTPCfdsbpnF7l; Authentication-Results: sj-dkim-5; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org =20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Tuesday, January 16, 2007 7:41 PM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] Open issues with draft-simon-emu-rfc2716bis-06.txt >=20 > >1. Use of TLS-WWW EKU > > > >The question was raised that the TLS WWW EKU may not be=20 > appropriate for=20 > >EAP-TLS. The suggestion was made to remove the text on EKU. Are=20 > >members of the working group in favor of removing this text? >=20 > There are a number of EAP-TLS implementations that require=20 > TLS WWW EKUs (or any). So in practice an implementation=20 > needs to understand that or it may not interoperate. It also=20 > occurs to me that there could be some security issues that=20 > would surface. For example, if there is no indication that=20 > an EAP-TLS server is authorized for that function (e.g. if it=20 > doesn't contain a TLS WWW server EKU or any), then any=20 > machine possessing an EAP-TLS client certificate chaining to=20 > a trust anchor could use that certiciate to act as an EAP-TLS=20 > server (assuming that the NASes were configured to trust it).=20 > It seems like this could make it easier to put up a rogue NAS. >=20 [Joe] It also seems that there are the same type of security issues with using the TLS WWW EKUs. There are the same certificates that are issued to web servers. However the TLS WWW server EKU at least differentiates between the server and client role. How about including: "Some deployments may require the presence of client and server authentication extended key usage extensions in certificates. Client implementations wishing to interoperate in these environments SHOULD check the server's certificate for an Extended Key Usage field implementations id-kp-serverAuth (1.3.6.1.5.5.7.3.1) or the special keyPurposeID anyExtendedKeyUsage. Server implementations wishing to interoperate in this environment SHOULD check the client's certificate for an Extended Key Usage field containing id-kp-clientAuth (1.3.6.1.5.5.7.3.2) or the special keyPurposeID anyExtendedKeyUsage. Note that these key usage extension identifiers for server and client authentication are somewhat generic and may not be sufficient to authorize an entity's role specifically as an EAP-TLS client or server." > With respect to the RFC 4334 OIDs, I'm ok with removing=20 > mention of them. =20 > There are no existing implementations, and as a result, there=20 > should be no expectation that EAP-TLS clients or servers will=20 > understand these extensions. It seems like these OIDs are=20 > problematic since they don't correspond to values of the=20 > NAS-Port-Type attribute, and therefore can't be compared to=20 > NAS-Port-Type values by implementations that don't understand them. >=20 [Joe] OK=20 > >2. Discussion of naming > > > >This section recommends > > > >"Where the subjectAltName field is present, the Peer-Id or=20 > Server-Id is=20 > >set to the contents of the subjectAltName. If subject naming=20 > >information is present only in the subject field, then the=20 > Peer-Id or=20 > >Server-Id is set to the Distinguished Name (DN)." > > > >It is possible that more than one subjectAltName may be present in a=20 > >certificate. Are there any rules as to how this is represented as a=20 > >Peer name? Also would it be more consistent to use the DN=20 > unless it is=20 > >empty? >=20 > Can someone descirbe a case where there would be more than=20 > one subjectAltName in a certificate? > I'm having a hard time wrapping my head around this case. >=20 [Joe] The subjectAltName may contain a host name as DNSName and a manufacturing serial number as an OtherName or perhaps it may contain a UPN and a SIP URI.=20 > >3. Discussion of authorization > > > >The later part of this section seems to discuss authorization. A=20 > >suggestion for revised text was made in=20 > >http://www1.ietf.org/mail-archive/web/emu/current/msg00309.ht > ml. Does=20 > >the suggested text convey the necessary information? >=20 > I'd suggest that the rest of the section include the=20 > following text (missing the RFC 4334 discussion): >=20 > "Once the endpoints of the EAP-TLS conversation have been=20 > authenticated and have had their certificates validated they=20 > then must be authorized. > The authorization process makes use of the contents of the=20 > certificates as well as other contextual information. While=20 > authorization requirements will vary from deployment to=20 > deployment it is RECOMMENDED that implementations be able to=20 > authorize based on the EAP Peer and EAP Server identities=20 > defined above. >=20 > Since authorization based on specific identities may not=20 > scale well in a large environment implementations may make=20 > use of other fields in the certificate. For example an=20 > implementation may be configured to accept all certificates=20 > issued by a CA with a certain name format as trusted. > In another example the peer may test whether the EAP server=20 > certificate is signed by a CA controlling the destination=20 > network and whether the Server-Id matches the format expected=20 > for that network. For example, an EAP peer connecting to the=20 > "EXAMPLE" SSID may check whether the Server-Id matches the=20 > regular expression "*.example.com", in addition to checking=20 > whether the server certificate chains to the example.com CA. > However, it is important to realize that any certificate=20 > matching the above criteria will be authorized, so this=20 > method should only be used in environments where this is=20 > guaranteed to be accurate." >=20 [Joe] OK _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Jan 18 15:40:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7e3H-0006OS-Ni; Thu, 18 Jan 2007 15:40:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7e3G-0006Nf-8m for emu@ietf.org; Thu, 18 Jan 2007 15:40:02 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7e3E-00044J-Tu for emu@ietf.org; Thu, 18 Jan 2007 15:40:02 -0500 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l0IKdqRM015182; Thu, 18 Jan 2007 15:39:52 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <45AFDB19.1030404@tari.toshiba.com> Date: Thu, 18 Jan 2007 15:39:53 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: emu@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Subject: [Emu] Questions on draft-ietf-emu-eap-gpsk-02.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Tom/Hannes, I just have a couple of questions/comments regarding draft-ietf-emu-eap-gpsk-02.txt: o In the terminology section, the last sentence of SEC_X(Y) definition is "SEC_X(Y) = Y|MAC_X(Y)". Maybe it should be "SEC_X(Y) = Y || MAC_X(Y)" instead. o In Sec 8., 3rd paragraph: "GPSK-1 contains no MAC protection, so provided it properly parses, it MUST be accepted by the client. If the EAP client decides the ID_Server is that of a AAA server to which it does not wish to authenticate, the EAP client should respond with an EAP-NACK." Should this also provision for the case where the client is unable to support any of the ciphers in CSuite_List of GPSK-1 ? In such a case is it proper for the client to just send an EAP-NACK ? o In Sec 8., 4th paragraph: "For GPSK-2, if ID_Client is for an unknown user, the EAP server MUST send either a "PSK Not Found" GPSK-Fail message, or an "Authentication Failure" GPSK-Fail, depending on its policy, and discard the received packet. If the MAC validation fails, the server MUST transmit a GPSK-Fail message specifying "Authentication Failure". and discard the received packet. If the RAND_Server or CSuite_List field in GPSK-2 does not match the values in GPSK-1, the server MUST silently discard the packet. If server policy determines the client is not authorized and the MAC is correct, the server MUST transmit a GPSK-Protected-Fail message indicating "Authorization Failure" and discard the received packet." In the case of "Authentication Failure" where the user is unknown or MAC is not correct maybe EAP_FAILURE is better (???) rather than GPSK-Fail since the failure is severe enough to warrant a method failure ? Should the CSuite_List in GPSK-2 be equivalent to CSuite_List in GPSK-1 ? Maybe I have the wrong impression but I thought the idea is auth sends a CSuite_List to peer and peer selects a supported CSuite denoted by CSuite_Sel. If this is the case we may not need CSuite_List in GPSK-2. Also, if CSuite_Sel does not match any value in CSuite_List in GPSK-1 then auth can send GPSK-Fail. o In Sec 8, 5th paragraph: "A client receiving a GPSK-Fail or GPSK-Protected-Fail message in response to a GPSK-2 message MUST either transmit an EAP-Failure message and end the session, ... " I'm probably missing something but is the client allowed to send EAP-Failure ? regards, victor _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Jan 19 02:02:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7nlN-0003iv-1Y; Fri, 19 Jan 2007 02:02:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7nlM-0003if-0L for emu@ietf.org; Fri, 19 Jan 2007 02:02:12 -0500 Received: from bay0-omc2-s16.bay0.hotmail.com ([65.54.246.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7nlK-00064o-NC for emu@ietf.org; Fri, 19 Jan 2007 02:02:11 -0500 Received: from hotmail.com ([207.46.8.113]) by bay0-omc2-s16.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 18 Jan 2007 23:02:10 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 18 Jan 2007 23:02:10 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Fri, 19 Jan 2007 07:02:09 GMT X-Originating-IP: [24.16.66.58] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: emu@ietf.org Bcc: Date: Thu, 18 Jan 2007 23:02:09 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 19 Jan 2007 07:02:10.0036 (UTC) FILETIME=[BD004340:01C73B97] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Emu] Removal of key strength table in RFC 2716bis X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org On the EAP WG list, Lakshminath Dondeti has pointed out the problems with including a copy of the RFC 3766 Key Strength table in another document: "Section 3.7 has a copy of the attack resistance table from RFC 3766. It is sufficient to provide a reference to that RFC. There is no need to reproduce the table in the eap-keying document. In fact, if 3766 is updated, the eap keying draft also needs to be updated; if 3766 is simply referenced, the problem goes away." This same argument can be made to remove the key strength table from RFC 2716bis. My recommendation is to change Note [3] in Section 5.1 to the following, removing the table: [3] BCP 86 [RFC3766] Section 5 offers advice on the required RSA or DH module and DSA subgroup size in bits, for a given level of attack resistance in bits. For example, a 2048-bit RSA key is recommended to provide 128-bit equivalent key strength. The National Institute for Standards and Technology (NIST) also offers advice on appropriate key sizes in [SP800-57]. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Jan 19 13:12:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7yDa-0002bG-NY; Fri, 19 Jan 2007 13:12:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7yDZ-0002YD-3c for emu@ietf.org; Fri, 19 Jan 2007 13:12:01 -0500 Received: from bay0-omc1-s9.bay0.hotmail.com ([65.54.246.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7yDA-0007zB-Ra for emu@ietf.org; Fri, 19 Jan 2007 13:12:01 -0500 Received: from hotmail.com ([207.46.8.103]) by bay0-omc1-s9.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Fri, 19 Jan 2007 10:11:36 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 19 Jan 2007 10:11:35 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Fri, 19 Jan 2007 18:11:34 GMT X-Originating-IP: [24.16.66.58] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: jsalowey@cisco.com, emu@ietf.org Bcc: Subject: RE: [Emu] Open issues with draft-simon-emu-rfc2716bis-06.txt Date: Fri, 19 Jan 2007 10:11:34 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 19 Jan 2007 18:11:35.0780 (UTC) FILETIME=[41A66A40:01C73BF5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 >How about including: > >"Some deployments may require the presence of client and server >authentication extended key usage extensions in certificates. Client >implementations wishing to interoperate in these environments SHOULD >check the server's certificate for an Extended Key Usage field >implementations id-kp-serverAuth (1.3.6.1.5.5.7.3.1) or the special >keyPurposeID anyExtendedKeyUsage. Server implementations wishing to >interoperate in this environment SHOULD check the client's certificate >for an Extended Key Usage field containing id-kp-clientAuth >(1.3.6.1.5.5.7.3.2) or the special keyPurposeID anyExtendedKeyUsage. >Note that these key usage extension identifiers for server and client >authentication are somewhat generic and may not be sufficient to >authorize an entity's role specifically as an EAP-TLS client or server." Looks good. > > Can someone descirbe a case where there would be more than > > one subjectAltName in a certificate? > > I'm having a hard time wrapping my head around this case. > > >[Joe] The subjectAltName may contain a host name as DNSName and a >manufacturing serial number as an OtherName or perhaps it may contain a >UPN and a SIP URI. Any recommendations on what we should say about this? _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Jan 20 22:54:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8TmI-00053N-MU; Sat, 20 Jan 2007 22:53:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8TmH-00053I-AX for emu@ietf.org; Sat, 20 Jan 2007 22:53:57 -0500 Received: from rwcrmhc14.comcast.net ([216.148.227.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8TmF-0000gA-1l for emu@ietf.org; Sat, 20 Jan 2007 22:53:57 -0500 Received: from [127.0.0.1] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (rwcrmhc14) with ESMTP id <20070121035351m1400jdv74e>; Sun, 21 Jan 2007 03:53:52 +0000 Message-ID: <45B2E3CF.10702@cs.umd.edu> Date: Sat, 20 Jan 2007 22:53:51 -0500 From: Charles Clancy User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [Emu] Open issues with draft-simon-emu-rfc2716bis-06.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Bernard Aboba wrote: >> How about including: >> >> "Some deployments may require the presence of client and server >> authentication extended key usage extensions in certificates. Client >> implementations wishing to interoperate in these environments SHOULD >> check the server's certificate for an Extended Key Usage field >> implementations id-kp-serverAuth (1.3.6.1.5.5.7.3.1) or the special >> keyPurposeID anyExtendedKeyUsage. Server implementations wishing to >> interoperate in this environment SHOULD check the client's certificate >> for an Extended Key Usage field containing id-kp-clientAuth >> (1.3.6.1.5.5.7.3.2) or the special keyPurposeID anyExtendedKeyUsage. >> Note that these key usage extension identifiers for server and client >> authentication are somewhat generic and may not be sufficient to >> authorize an entity's role specifically as an EAP-TLS client or server." > > Looks good. What about RFC 4334? -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Jan 21 12:30:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8gWU-00067P-Oi; Sun, 21 Jan 2007 12:30:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8gWT-00067K-TY for emu@ietf.org; Sun, 21 Jan 2007 12:30:29 -0500 Received: from bay0-omc1-s15.bay0.hotmail.com ([65.54.246.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8gWR-00047U-Je for emu@ietf.org; Sun, 21 Jan 2007 12:30:29 -0500 Received: from hotmail.com ([207.46.8.105]) by bay0-omc1-s15.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun, 21 Jan 2007 09:30:27 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 21 Jan 2007 09:30:26 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Sun, 21 Jan 2007 17:30:23 GMT X-Originating-IP: [24.16.66.58] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <45B2E3CF.10702@cs.umd.edu> From: "Bernard Aboba" To: clancy@cs.umd.edu Bcc: Subject: Re: [Emu] Open issues with draft-simon-emu-rfc2716bis-06.txt Date: Sun, 21 Jan 2007 09:30:23 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 21 Jan 2007 17:30:26.0736 (UTC) FILETIME=[D6CFB300:01C73D81] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >What about RFC 4334? As far as I know, no EAP-TLS implementation supports RFC 4334 and I don't think we should be encouraging implementers to support it. The OIDs defined in RFC 4334 do not correspond to values of the NAS-Port-Type attribute, so the backend authentication server certificate handling code would need to be updated everytime a new value were to be assigned; the AAA server can't just check that the NAS-Port-Type attribute includes a value that matches one of the OIDs in the client certificate. Similarly, client code would need to be updated every time a new EAP lower layer was defined, since the client would need to check if the server certificate contained an OID allowing it to be used to authorize a given EAP lower layer. As a result, I think that RFC 4334 compromises the ability of EAP-TLS to run over any suitable lower layer without code changes. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Jan 22 12:14:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H92kp-0004kq-OO; Mon, 22 Jan 2007 12:14:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H92kp-0004kD-2b for emu@ietf.org; Mon, 22 Jan 2007 12:14:47 -0500 Received: from mcfeely.cs.umd.edu ([128.8.128.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H92kn-0005A4-RW for emu@ietf.org; Mon, 22 Jan 2007 12:14:47 -0500 Received: from mcfeely.cs.umd.edu (localhost [127.0.0.1]) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id l0MHEioL011726; Mon, 22 Jan 2007 12:14:44 -0500 Received: (from apache@localhost) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.11/Submit) id l0MHEixv011724; Mon, 22 Jan 2007 12:14:44 -0500 X-Authentication-Warning: mcfeely.cs.umd.edu: apache set sender to clancy@cs.umd.edu using -f Received: from 63.239.69.1 (SquirrelMail authenticated user clancy) by webmail.cs.umd.edu with HTTP; Mon, 22 Jan 2007 12:14:44 -0500 (EST) Message-ID: <57130.63.239.69.1.1169486084.squirrel@webmail.cs.umd.edu> In-Reply-To: References: <45B2E3CF.10702@cs.umd.edu> Date: Mon, 22 Jan 2007 12:14:44 -0500 (EST) Subject: Re: [Emu] Open issues with draft-simon-emu-rfc2716bis-06.txt From: "Charles Clancy" To: "Bernard Aboba" User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org On Sun, January 21, 2007 12:30 pm, Bernard Aboba wrote: >>What about RFC 4334? > > The OIDs defined in RFC 4334 do not correspond to values of the > NAS-Port-Type attribute, so the backend authentication server certificate > handling code would need to be updated everytime a new value were to be > assigned; the AAA server can't just check that the NAS-Port-Type attribute > includes a value that matches one of the OIDs in the client certificate. > Similarly, client code would need to be updated every time a new EAP lower > layer was defined, since the client would need to check if the server > certificate contained an OID allowing it to be used to authorize a given > EAP > lower layer. So your objection is that essentially different lower layers have been hard-coded into 4334 (PPP and EAPoL), and consequently into the cert handling code, such that new RFCs and new code would be required to support EAP over different L2/L3 technologies? I can see that as an objection to the fundamental approach, and a reason to possibly not support future EKUs for other lower layers, but not as a reason to not support the currently-defined EKUs. If implementers are rev-ing their EAP-TLS code for 2716bis compliance, this would be a good time to roll in these changes. I'd think a statement like "When EAP-TLS is used with WLANs, support for WLAN-specific EKUs [RFC 4334] is RECOMMENDED to improve certificiate-based authorization of EAP clients and servers" would be appropriate. -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Jan 22 12:51:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H93K8-0004zJ-UG; Mon, 22 Jan 2007 12:51:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H93K7-0004y3-36 for emu@ietf.org; Mon, 22 Jan 2007 12:51:15 -0500 Received: from mcfeely.cs.umd.edu ([128.8.128.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H93K5-0001uz-QO for emu@ietf.org; Mon, 22 Jan 2007 12:51:15 -0500 Received: from mcfeely.cs.umd.edu (localhost [127.0.0.1]) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id l0MHpDNZ022949; Mon, 22 Jan 2007 12:51:13 -0500 Received: (from apache@localhost) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.11/Submit) id l0MHp9iV022941; Mon, 22 Jan 2007 12:51:09 -0500 X-Authentication-Warning: mcfeely.cs.umd.edu: apache set sender to clancy@cs.umd.edu using -f Received: from 63.239.69.1 (SquirrelMail authenticated user clancy) by webmail.cs.umd.edu with HTTP; Mon, 22 Jan 2007 12:51:09 -0500 (EST) Message-ID: <64304.63.239.69.1.1169488269.squirrel@webmail.cs.umd.edu> In-Reply-To: <45AFDB19.1030404@tari.toshiba.com> References: <45AFDB19.1030404@tari.toshiba.com> Date: Mon, 22 Jan 2007 12:51:09 -0500 (EST) Subject: Re: [Emu] Questions on draft-ietf-emu-eap-gpsk-02.txt From: "Charles Clancy" To: "Victor Fajardo" User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org On Thu, January 18, 2007 3:39 pm, Victor Fajardo wrote: > Hi Tom/Hannes, > > I just have a couple of questions/comments regarding > draft-ietf-emu-eap-gpsk-02.txt: > > o In the terminology section, the last sentence of SEC_X(Y) definition > is "SEC_X(Y) = Y|MAC_X(Y)". Maybe it should be "SEC_X(Y) = Y || > MAC_X(Y)" instead. Yes. > o In Sec 8., 3rd paragraph: > > "GPSK-1 contains no MAC protection, so provided it properly parses, it > MUST be accepted by the client. If the EAP client decides the > ID_Server is that of a AAA server to which it does not wish to > authenticate, the EAP client should respond with an EAP-NACK." > > Should this also provision for the case where the client is unable to > support any of the ciphers in CSuite_List of GPSK-1 ? In such a case > is it proper for the client to just send an EAP-NACK ? There is a mandatory-to-implement cipher, so this should never happen. > o In Sec 8., 4th paragraph: > > "For GPSK-2, if ID_Client is for an unknown user, the EAP server MUST > send either a "PSK Not Found" GPSK-Fail message, or an > "Authentication Failure" GPSK-Fail, depending on its policy, and > discard the received packet. If the MAC validation fails, the server > MUST transmit a GPSK-Fail message specifying "Authentication > Failure". and discard the received packet. If the RAND_Server or > CSuite_List field in GPSK-2 does not match the values in GPSK-1, the > server MUST silently discard the packet. If server policy determines > the client is not authorized and the MAC is correct, the server MUST > transmit a GPSK-Protected-Fail message indicating "Authorization > Failure" and discard the received packet." > > In the case of "Authentication Failure" where the user is unknown or MAC > is not correct maybe EAP_FAILURE is better (???) rather than GPSK-Fail > since the failure is severe enough to warrant a method failure ? See the paragraph immediately after the one you quoted: A client receiving a GPSK-Fail or GPSK-Protected-Fail message in response to a GPSK-2 message MUST either transmit an EAP-Failure message and end the session, or retry transmission of GPSK-2, attempting to correct whatever failure occured. If MAC validation on a GPSK-Protected-Fail packet fails, then the received packet MUST be silently discarded. The client has the option to send an EAP Failure to end the session and try another EAP type, or retry EAP-GPSK. > Should the CSuite_List in GPSK-2 be equivalent to CSuite_List in GPSK-1 ? > Maybe I have the wrong impression but I thought the idea is auth sends > a CSuite_List to peer and peer selects a supported CSuite denoted by > CSuite_Sel. If this is the case we may not need CSuite_List in GPSK-2. > Also, if CSuite_Sel does not match any value in CSuite_List in GPSK-1 > then auth can send GPSK-Fail. The reason for sending CSuite_List in GPSK-2 is to authenticate it. GPSK-1 has no MAC protection, while GPSK-2 does. This way the server knows that the CSuite_List sent in GPSK-1 wasn't altered in transit, which allows it to detect downgrade attacks. > o In Sec 8, 5th paragraph: > > "A client receiving a GPSK-Fail or GPSK-Protected-Fail message in > response to a GPSK-2 message MUST either transmit an EAP-Failure > message and end the session, ... " > > I'm probably missing something but is the client allowed to send > EAP-Failure ? I don't see anything in RFC 3748 saying a peer CANNOT send an EAP-Failure, but perhaps it would be better for GPSK to respond with another GPSK-Failure message, and then have the sever send the EAP-Failure. -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Jan 22 15:50:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H967L-0007Fi-3j; Mon, 22 Jan 2007 15:50:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9679-00077s-2X; Mon, 22 Jan 2007 15:50:03 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9678-0007B4-Mw; Mon, 22 Jan 2007 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 925E93293F; Mon, 22 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H9678-00082r-E1; Mon, 22 Jan 2007 15: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: Mon, 22 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: emu@ietf.org Subject: [Emu] I-D ACTION:draft-simon-emu-rfc2716bis-07.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update Working Group of the IETF. Title : The EAP TLS Authentication Protocol Author(s) : D. Simon, B. Aboba Filename : draft-simon-emu-rfc2716bis-07.txt Pages : 30 Date : 2007-1-22 The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Level Security (TLS) provides for mutual authentication, integrity- protected ciphersuite negotiation and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-07.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-07.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-07.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-1-22143457.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-simon-emu-rfc2716bis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-simon-emu-rfc2716bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-22143457.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --NextPart-- From emu-bounces@ietf.org Mon Jan 22 18:01:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H98AT-0000RH-SG; Mon, 22 Jan 2007 18:01:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H98AS-0000RC-70 for emu@ietf.org; Mon, 22 Jan 2007 18:01:36 -0500 Received: from bay0-omc1-s11.bay0.hotmail.com ([65.54.246.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H98AP-0004D8-SB for emu@ietf.org; Mon, 22 Jan 2007 18:01:36 -0500 Received: from hotmail.com ([207.46.8.94]) by bay0-omc1-s11.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 22 Jan 2007 15:01:33 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 22 Jan 2007 15:01:32 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Mon, 22 Jan 2007 23:01:28 GMT X-Originating-IP: [131.107.0.105] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <57130.63.239.69.1.1169486084.squirrel@webmail.cs.umd.edu> From: "Bernard Aboba" To: clancy@cs.umd.edu Bcc: Subject: Re: [Emu] Open issues with draft-simon-emu-rfc2716bis-06.txt Date: Mon, 22 Jan 2007 15:01:28 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 22 Jan 2007 23:01:32.0886 (UTC) FILETIME=[425F5F60:01C73E79] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >So your objection is that essentially different lower layers have been >hard-coded into 4334 (PPP and EAPoL), and consequently into the cert >handling code, such that new RFCs and new code would be required to >support EAP over different L2/L3 technologies? The problem is that the RFC 4334 lower layer number space is not synchronized with the existing RADIUS NAS-Port-Type space. On the server side, this means that a AAA server could not just compare the NAS-Port-Type attribute value with the OIDs in the cert; it has to have a table mapping one to the other. This would require addition of an OID mapping table to the AAA server. So far, no servers have implemented this, and I suspect that they will not do so in the near future. >I can see that as an objection to the fundamental approach, and a reason >to possibly not support future EKUs for other lower layers, but not as a >reason to not support the currently-defined EKUs. If implementers are >rev-ing their EAP-TLS code for 2716bis compliance, this would be a good >time to roll in these changes. If the approach is not good for the long-term, why should implementers be encouraged to embrace it? This is likely to encourage further requests for allocation of RFC 4334 OIDs, creating interoperability problems where none existed previously. >I'd think a statement like "When EAP-TLS is used with WLANs, support for >WLAN-specific EKUs [RFC 4334] is RECOMMENDED to improve certificiate-based >authorization of EAP clients and servers" would be appropriate. RFC 4334 doesn't improve authorization of clients. Today AAA servers can check the NAS-Port-Type attribute and send a Reject if the client is not authorized for that medium. Adding lower layer OIDs to the client certificate will not provide more authorization functionality than we already have, but will add complexity. In terms of server authorization, the benefit is unclear to me. Assuming a server is authenticated and appears authorized along other dimensions (chains to a trust anchor, has an appropriate name), should a client reject it because it lacks the OIDs for the particular form of access involved? >From an architectural point of view, EAP-TLS implementations typically leave certificate selection to the TLS implementation. RFC 4334 support could require changes to the certificate selection code. Overall, given the lack of RFC 4334 implementation and the cost/benefit ratio going forward, it's probably best to let this "sleeping dog" RFC lie. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Jan 22 22:34:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9CQp-0004eG-Hi; Mon, 22 Jan 2007 22:34:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9CQo-0004eB-0m for emu@ietf.org; Mon, 22 Jan 2007 22:34:46 -0500 Received: from bay0-omc1-s27.bay0.hotmail.com ([65.54.246.99]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9CQm-00057h-Ny for emu@ietf.org; Mon, 22 Jan 2007 22:34:46 -0500 Received: from hotmail.com ([207.46.8.99]) by bay0-omc1-s27.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 22 Jan 2007 19:34:44 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 22 Jan 2007 19:34:43 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Tue, 23 Jan 2007 03:34:39 GMT X-Originating-IP: [131.107.0.73] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <64304.63.239.69.1.1169488269.squirrel@webmail.cs.umd.edu> From: "Bernard Aboba" To: clancy@cs.umd.edu, vfajardo@tari.toshiba.com Bcc: Subject: Re: [Emu] Questions on draft-ietf-emu-eap-gpsk-02.txt Date: Mon, 22 Jan 2007 19:34:39 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 23 Jan 2007 03:34:43.0947 (UTC) FILETIME=[6C34CBB0:01C73E9F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >I don't see anything in RFC 3748 saying a peer CANNOT send an EAP-Failure, >but perhaps it would be better for GPSK to respond with another >GPSK-Failure message, and then have the sever send the EAP-Failure. RFC 3748 Section 4.1 says: The peer MUST send a Response packet in reply to a valid Request packet. So an EAP peer cannot send an EAP-Failure in response to a Request. If it were to do so, the authenticator would just retransmit the Request, since Section 4.1 says: The Request packet (Code field set to 1) is sent by the authenticator to the peer. Each Request has a Type field which serves to indicate what is being requested. Additional Request packets MUST be sent until a valid Response packet is received, an optional retry counter expires, or a lower layer failure indication is received. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Jan 23 01:24:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9F5H-0003Vt-I7; Tue, 23 Jan 2007 01:24:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9F5G-0003Vh-Eu for emu@ietf.org; Tue, 23 Jan 2007 01:24:42 -0500 Received: from mcfeely.cs.umd.edu ([128.8.128.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9F5F-0003wb-6A for emu@ietf.org; Tue, 23 Jan 2007 01:24:42 -0500 Received: from mcfeely.cs.umd.edu (localhost [127.0.0.1]) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id l0N6OdZr012176; Tue, 23 Jan 2007 01:24:39 -0500 Received: (from apache@localhost) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.11/Submit) id l0N6OdWO012174; Tue, 23 Jan 2007 01:24:39 -0500 X-Authentication-Warning: mcfeely.cs.umd.edu: apache set sender to clancy@cs.umd.edu using -f Received: from 67.127.64.169 (SquirrelMail authenticated user clancy) by webmail.cs.umd.edu with HTTP; Tue, 23 Jan 2007 01:24:39 -0500 (EST) Message-ID: <26830.67.127.64.169.1169533479.squirrel@webmail.cs.umd.edu> In-Reply-To: References: <57130.63.239.69.1.1169486084.squirrel@webmail.cs.umd.edu> Date: Tue, 23 Jan 2007 01:24:39 -0500 (EST) Subject: Re: [Emu] Open issues with draft-simon-emu-rfc2716bis-06.txt From: "Charles Clancy" To: "Bernard Aboba" User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org > In terms of server authorization, the benefit is unclear to me. Assuming > a server is authenticated and appears authorized along other dimensions > (chains to a trust anchor, has an appropriate name), should a client > reject it because it lacks the OIDs for the particular form of access > involved? From an architectural point of view, EAP-TLS implementations > typically leave certificate selection to the TLS implementation. RFC > 4334 support could require changes to the certificate selection code. I don't care about client authorization -- there should be server-side ACLs for this. I guess for EAP-TLS, server authorization isn't a huge deal. If an unauthorized server is giving you access to the network, what difference does it make to a client? The only compromise is maybe that of user confidentiality. What worries me are improperly authorized servers for something like PEAP+MSCHAPv2, where a dictionary attack against a client's password might be possible. My biggest worry is that someone, for example, hacks a web server, steals the key pair, fires up a rogue AP+AAA, and starts stealing client passwords. The user is never presented with a dialog box saying "by the way, you're talking to CN=www.domain.net, not CN=aaa.domain.net". Oh, and be sure to check the CRL to see if it's been revoked or not. I definitely understand the deployment issues. I just wish there was some way to fix this without client-side ACLs for server authorization. -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Jan 23 10:55:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9NzQ-0003YN-Ty; Tue, 23 Jan 2007 10:55:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9NzL-0003TB-TP for emu@ietf.org; Tue, 23 Jan 2007 10:55:11 -0500 Received: from bay0-omc1-s24.bay0.hotmail.com ([65.54.246.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9NvT-0001WX-2s for emu@ietf.org; Tue, 23 Jan 2007 10:51:12 -0500 Received: from hotmail.com ([207.46.8.107]) by bay0-omc1-s24.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 23 Jan 2007 07:51:10 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 23 Jan 2007 07:51:09 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Tue, 23 Jan 2007 15:51:05 GMT X-Originating-IP: [24.16.66.58] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <26830.67.127.64.169.1169533479.squirrel@webmail.cs.umd.edu> From: "Bernard Aboba" To: clancy@cs.umd.edu Bcc: Subject: Re: [Emu] Open issues with draft-simon-emu-rfc2716bis-06.txt Date: Tue, 23 Jan 2007 07:51:05 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 23 Jan 2007 15:51:09.0966 (UTC) FILETIME=[4D203AE0:01C73F06] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >I don't care about client authorization -- there should be server-side ACLs >for this. Right. >I guess for EAP-TLS, server authorization isn't a huge deal. If an >unauthorized server is giving you access to the network, what difference >does it make to a client? The only compromise is maybe that of user >confidentiality. What worries me are improperly authorized servers for >something like PEAP+MSCHAPv2, where a dictionary attack against a client's >password might be possible. > >My biggest worry is that someone, for example, hacks a web server, steals >the key pair, fires up a rogue AP+AAA, and starts stealing client >passwords. They wouldn't even have to steal the key pair. All they'd have to do is start a modified RADIUS service and get a rogue AP to point to it. >The user is never presented with a dialog box saying "by the >way, you're talking to CN=www.domain.net, not CN=aaa.domain.net". Oh, and >be sure to check the CRL to see if it's been revoked or not. Typically the client will not check for a particular FQDN in the subjectAltName field in the server cert, only a pattern (e.g. *.domain.net). CRL checking has to occur after the fact, unless the client already has connectivity; most implementations don't seem to do the checks at all. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu