From i1iiyjx@hotmail.com Tue Jan 6 22:29:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18586 for ; Tue, 6 Jan 2004 22:29:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ae4OE-0002Fb-00 for eap-archive@ietf.org; Tue, 06 Jan 2004 22:29:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ae4MS-0002BD-00 for eap-archive@ietf.org; Tue, 06 Jan 2004 22:28:01 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ae4Kn-000266-00 for eap-archive@ietf.org; Tue, 06 Jan 2004 22:26:17 -0500 Received: from [68.208.156.4] (helo=65.246.255.50 ident=CacheFlow Server) by mx2.foretec.com with smtp (Exim 4.24) id 1Ae4Ko-0004SF-Nk for eap-archive@ietf.org; Tue, 06 Jan 2004 22:26:19 -0500 Received: from (HELO b2ooqx) [18.170.90.21] by 65.246.255.50 with ESMTP id <931242-82124>; Thu, 08 Jan 2004 07:26:06 +0600 Message-ID: From: "Roy Mckinnon" Reply-To: "Roy Mckinnon" To: , Subject: Guaranteed weight |oss program a Date: Thu, 08 Jan 04 07:26:06 GMT X-Mailer: Microsoft Outlook, Build 10.0.2616 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_C474_FCAC50_CB7C.3202" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=26.0 required=5.0 tests=ALL_NATURAL, DATE_IN_FUTURE_06_12,DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,FORGED_RCVD_NET_HELO, HTML_40_50,HTML_IMAGE_ONLY_04,HTML_MESSAGE,HTML_TAG_BALANCE_BODY, HTML_TAG_BALANCE_HTML,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,RCVD_NUMERIC_HELO, SUBJ_GUARANTEED,USERPASS autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 2.4 SUBJ_GUARANTEED Subject GUARANTEED * 1.3 ALL_NATURAL BODY: Spam is 100% natural?! * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.3 HTML_TAG_BALANCE_BODY BODY: HTML has unbalanced "body" tags * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.4 HTML_TAG_BALANCE_HTML BODY: HTML has unbalanced "html" tags * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.5 HTML_IMAGE_ONLY_04 BODY: HTML: images with 200-400 bytes of words * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 3.1 USERPASS URI: URL contains username and (optional) password * 1.9 DATE_IN_FUTURE_06_12 Date: is 6 to 12 hours after Received: date * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook --_C474_FCAC50_CB7C.3202 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Take your low carb diet to a new level.
With all natural ProCitravin you'll lose an additional 10 pounds every 12 = days or your money back!

http://ww= w.procitravin.com/index25.html

Jow Derima

R= emove your email from further mailing.



ysbrsf bihzmk ps szfm ufba mnuxk xcjoq uyeyz --_C474_FCAC50_CB7C.3202-- From eap-admin@frascone.com Fri Jan 9 11:00:54 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09475 for ; Fri, 9 Jan 2004 11:00:48 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ADC6F20260; Fri, 9 Jan 2004 10:25:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 3453120260 for ; Fri, 9 Jan 2004 10:24:25 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i09FoPH04672; Fri, 9 Jan 2004 07:50:26 -0800 From: Bernard Aboba To: John Vollbrecht Cc: eap@frascone.com, stds-802-1@ieee.org In-Reply-To: <5973807.1073640555@pm552-11.dialip.mich.net> Message-ID: References: <5973807.1073640555@pm552-11.dialip.mich.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Re: [802.1] Re: 802.1X interface variable Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 9 Jan 2004 07:50:25 -0800 (PST) > does this mean that TLS host only authorization is not going to be allowed? > I think this is being used to allow access to walled garden environments. The TLS protocol does not support "client only" authentication. In any case it says "support", not "use". _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 11:00:56 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09473 for ; Fri, 9 Jan 2004 11:00:48 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BB99420206; Fri, 9 Jan 2004 10:15:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id EBD7B201FF for ; Fri, 9 Jan 2004 10:14:45 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 568CD6A902 for ; Fri, 9 Jan 2004 17:25:24 +0200 (EET) Message-ID: <3FFEC797.5010609@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: multipart/mixed; boundary="------------060004020504080605080407" Subject: [eap] [Fwd: HTTP Digest in EAP?] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 09 Jan 2004 17:24:07 +0200 This is a multi-part message in MIME format. --------------060004020504080605080407 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit --------------060004020504080605080407 Content-Type: message/rfc822; name="HTTP Digest in EAP?" Content-Disposition: inline; filename="HTTP Digest in EAP?" X-Sieve: cmu-sieve 2.0 Return-Path: X-Original-To: jarkko@piuha.net Delivered-To: jarkko@piuha.net Received: from psg.com (psg.com [147.28.0.62]) by p2.piuha.net (Postfix) with ESMTP id 8018A6A902; Fri, 9 Jan 2004 17:17:32 +0200 (EET) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AeyNa-000E23-5v for radiusext-data@psg.com; Fri, 09 Jan 2004 15:16:54 +0000 Received: from [194.25.134.20] (helo=mailout08.sul.t-online.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AeyNN-000E0b-BH for radiusext@ops.ietf.org; Fri, 09 Jan 2004 15:16:41 +0000 Received: from fwd04.aul.t-online.de by mailout08.sul.t-online.com with smtp id 1AeyNM-0007zy-01; Fri, 09 Jan 2004 16:16:40 +0100 Received: from localhost (GElyN4ZDZefubyOSOjiBoZ0U11FxIQ3pm9ovBbPdCQcTKG2BvXsBww@[217.82.41.39]) by fwd04.sul.t-online.com with esmtp id 1AeyN9-1gOoEK0; Fri, 9 Jan 2004 16:16:27 +0100 To: radiusext@ops.ietf.org Subject: HTTP Digest in EAP? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13223.1073661386.1@localhost> Date: Fri, 09 Jan 2004 16:16:26 +0100 From: wolfgang.beck01@t-online.de (Wolfgang Beck) Message-ID: <1AeyN9-1gOoEK0@fwd04.sul.t-online.com> X-Seen: false X-ID: GElyN4ZDZefubyOSOjiBoZ0U11FxIQ3pm9ovBbPdCQcTKG2BvXsBww Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on p2.piuha.net X-Spam-Status: No, hits=-3.7 required=6.0 tests=BAYES_00,FROM_ENDS_IN_NUMS, RCVD_IN_NJABL,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Level: While looking to reduce the amount of attribute numbers for draft-sterman, I stumbled over EAP request / response type 38 'EAP-HTTP Digest', registered by O. Tavakoli of funk.com. I did not find any draft or other specification of this EAP type. Does anybody on the list know about it? -- Wolfgang Beck T-Systems GmbH -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: --------------060004020504080605080407-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 11:00:54 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09474 for ; Fri, 9 Jan 2004 11:00:48 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3B5E620203; Thu, 8 Jan 2004 20:55:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id CE3D0201FC for ; Thu, 8 Jan 2004 20:54:32 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i092KW518955; Thu, 8 Jan 2004 18:20:32 -0800 From: Bernard Aboba To: Henrik Levkowetz Cc: Jari Arkko , "eap@frascone.com" In-Reply-To: <20040109021312.0ca5f30c.henrik@levkowetz.com> Message-ID: References: <20040108004002.23ff24f7.henrik@levkowetz.com> <20040109021312.0ca5f30c.henrik@levkowetz.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Re: Issue 208: Editorial questions Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 8 Jan 2004 18:20:32 -0800 (PST) On Fri, 9 Jan 2004, Henrik Levkowetz wrote: > Hi, > > In the resolution to issue 208, I'd propose changing > > "Identity Requests and Responses are sent in cleartext, so > that an attacker may snoop on the identity, or even modify > or spoof identity exchanges. To address these threats, > it is preferable for an EAP method to include an identity > exchange that supports per-packet authentication, > integrity and replay protection and confidentiality." > > by replacing "so that an attacker may" with "so an attacker may" > because "so that an attacker may" can be understood as "in order > that an attacker may". ok. > Requirements language: > In Section 7.6, should > > "In order to protect against dictionary attacks, authentication > methods resistant to dictionary attacks (as defined in Section 7.2.1) > are recommended." > > end with "... are RECOMMENDED" ? I think we need to leave this lower case. Otherwise we are saying that the mandatory-to-implement method should not be used. > Similarly, in 7.11, should > > "To protect against data modification, spoofing or snooping, it is > recommended that EAP methods supporting mutual authentication, > and key derivation (as defined by Section 7.2.1) be used, along with > a lower layers providing per-packet confidentiality, authentication, > integrity and replay protection." > > instead read "... it is RECOMMENDED that EAP methods supporting ..."? I believe this is lower case as well, for the same reasons. Elsewhere in the text we are citing other documents (such as the IEEE 802.11i liaison letter) that specify EAP method requirements for specific environments. It's best to leave that kind of recommendation out of RFC 2284bis, much as the IKE/IPsec documents do not provide guidance as to various IPsec features need to be turned on. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 11:07:03 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09801 for ; Fri, 9 Jan 2004 11:07:03 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1DA8020202; Fri, 9 Jan 2004 10:55:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from chardonnay.local.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by mail.frascone.com (Postfix) with ESMTP id 51685201FF for ; Fri, 9 Jan 2004 10:54:09 -0500 (EST) Received: from chardonnay ([127.0.0.1] helo=chardonnay.local.levkowetz.com) by chardonnay.local.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1Aez7m-0005ae-00; Fri, 09 Jan 2004 17:04:38 +0100 From: Henrik Levkowetz To: jari.arkko@piuha.net Cc: Bernard Aboba , "eap@frascone.com" Subject: Re: [eap] Re: Issue 208: Editorial questions Message-Id: <20040109170435.28fb947b.henrik@levkowetz.com> In-Reply-To: <3FFE4F31.3010809@piuha.net> References: <20040108004002.23ff24f7.henrik@levkowetz.com> <20040109021312.0ca5f30c.henrik@levkowetz.com> <3FFE4F31.3010809@piuha.net> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 9 Jan 2004 17:04:35 +0100 Content-Transfer-Encoding: 7bit Friday 9 January 2004, Jari Arkko wrote: [Henrik] > >>Similarly, in 7.11, should > >> > >> "To protect against data modification, spoofing or snooping, it is > >> recommended that EAP methods supporting mutual authentication, > >> and key derivation (as defined by Section 7.2.1) be used, along with > >> a lower layers providing per-packet confidentiality, authentication, > >> integrity and replay protection." > >> > >>instead read "... it is RECOMMENDED that EAP methods supporting ..."? > > [Bernard] > > I believe this is lower case as well, for the same reasons. Elsewhere in > > the text we are citing other documents (such as the IEEE 802.11i liaison > > letter) that specify EAP method requirements for specific environments. > > It's best to leave that kind of recommendation out of RFC 2284bis, much as > > the IKE/IPsec documents do not provide guidance as to various IPsec > > features need to be turned on. > [Jari] > I agree with Bernard. By the way, the 7.11 text seems funny to > me when it says "... along with a lower layers ...". Shouldn't that > be "along with a lower layer" or "along with lower layers"? Yes. I provisionally used "along with a lower layer providing..." in the text later last night, but was to tired to send out another mail regarding it at that time. What do the others say? Henrik _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 11:17:28 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10478 for ; Fri, 9 Jan 2004 11:17:27 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A7757201FA; Thu, 8 Jan 2004 17:08:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 4CB0620151 for ; Thu, 8 Jan 2004 17:07:03 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i08MX9u05354 for ; Thu, 8 Jan 2004 14:33:09 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] REVIEW REQUEST: RFC 2284bis-08 strawman Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 8 Jan 2004 14:33:09 -0800 (PST) So as to allow people to review the impact of the changes proposed in Issues 206, 207, 208, 209, 211 and 212 in their entirety, Henrik has gratiously agreed to produce an -08 strawman draft within the next few days. As usual, this will be available on the Document Editor's website: http://ietf.levkowetz.com/drafts/eap/rfc2284bis/ Since RFC 2284bis has already gone through IESG review, we're getting down to the wire, and we want to make sure no new gremlins have crept in due to the proposed resolutions. Once the -08 strawman is posted (should be available by early next week), we'd appreciate it WG participants could look it over and post any Issues by Friday, January 16, 2004. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 11:17:28 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10480 for ; Fri, 9 Jan 2004 11:17:27 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 78E3B201FD; Thu, 8 Jan 2004 15:31:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id C3B9D201FB for ; Thu, 8 Jan 2004 15:30:24 -0500 (EST) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 08 Jan 2004 12:48:56 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i08KexVM001522; Thu, 8 Jan 2004 12:40:59 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.115.90]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 8 Jan 2004 12:46:37 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" Cc: Subject: RE: [eap] Proposed resolution of Issue 212: Protected Result Indications Message-ID: <00eb01c3d627$b8bd2ce0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 08 Jan 2004 20:46:37.0752 (UTC) FILETIME=[82C57380:01C3D628] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 8 Jan 2004 12:40:57 -0800 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Thursday, January 08, 2004 11:34 AM > To: Joseph Salowey > Cc: eap@frascone.com > Subject: RE: [eap] Proposed resolution of Issue 212: > Protected Result Indications > > > > > The client isn't ready to accept an EAP-Success until it receives > > > the FINISHED message from the server, so I don't think > that's right > > > in this case. It's really the joint receipt of the > FINISHED message > > > without receiving a TLS alert prior to that which is the success > > > indication. > > > > [Joe] Not in the case of TLS resume. > > Do you have some text to suggest that will clarify this issue > in the suggested resolution of Issue 212? I thought the text you had proposed was good. It is just that integrity protection of the indicators is required but not sufficient. How about "Protected result indications A method provides result indications if after the method has finished (1) if the peer is willing to use the access provided by the authenticator, it knows whether the authenticator will grant access (that is, only either an EAP-Success or EAP-Failure will be accepted, no more method specific messages are expected), and (2) if the authenticator decides to grant access, it knows whether the peer will accept it. Result indications improve resilience to packet loss; see Section 4.2 for discussion. Depending on the method and circumstances, result indications can be spoofable by an attacker. A method is said to provide protected result indications if supports result indications as well as the "integrity protection" and "replay protection" claims. 7.16 for details." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 11:17:29 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10490 for ; Fri, 9 Jan 2004 11:17:29 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8D49E201F2; Thu, 8 Jan 2004 11:47:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id 0C4BE20151 for ; Thu, 8 Jan 2004 11:46:08 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i08Gui616384 for ; Thu, 8 Jan 2004 18:56:44 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 8 Jan 2004 18:56:44 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 8 Jan 2004 18:56:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Proposed resolution of Issue 212: Protected Result Indications Message-ID: <052E0C61B69C3741AFA5FE88ACC775A612235E@esebe023.ntc.nokia.com> Thread-Topic: [eap] Proposed resolution of Issue 212: Protected Result Indications Thread-Index: AcPVdDqVGuzCLFIRQjW/i/9O2CyKxgAkE+rg From: To: Cc: X-OriginalArrivalTime: 08 Jan 2004 16:56:43.0847 (UTC) FILETIME=[64F69570:01C3D608] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 8 Jan 2004 18:56:43 +0200 Content-Transfer-Encoding: quoted-printable > > I'd say that result indications are protected if they can't > > be spoofed, and unprotected otherwise (since if we don't have > > a "result exchange", speaking of integrity protecting is > > somewhat confusing). It also seems the revised definition > > of "result indication" covers only things that occur after > > key derivation... >=20 > We already have "integrity protection" and "replay protection" claims > so perhaps it is easiest to piggyback on these. I don't=20 > think we have to specify exactly which result indications are=20 > protected and which aren't; the method specification can clarify that. >=20 > So perhaps the right definition is: >=20 > "Protected result indications > A method provides result indications if after the method > has finished (1) if the peer is willing to use the access provided > by the authenticator, it knows whether the authenticator will > grant access (that is, whether it will send an EAP Success or Failure > packet), and (2) if the authenticator decides to grant=20 > access, it knows whether the peer will accept it. =20 > Result indications improve resilience to packet loss; see=20 > Section 4.2 for discussion. Depending on the method and=20 > circumstances, result indications can be spoofable by an attacker.=20 > A method is said to provide protected result indications if supports=20 > result indications as well as the "integrity protection" and=20 > "replay protection" claims. See Section 7.16 for details." Is a method allowed to make this claim if it protects only some of the possible cases, but not all? Hmm.. is integrity & replay protection actually enough to prevent an attacker from changing result indications? For instance, in EAP-TLS=20 the server sends the "client authorization failed" TLS alert after the=20 change_cipher_spec messages, so it is integrity and replay protected.=20 However, at this point the client is in a state where it will also=20 accept EAP Success (so the "result indication" here was a _lack_ of TLS alert message, and that could be spoofed)... Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 11:17:30 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10492 for ; Fri, 9 Jan 2004 11:17:29 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 32882201EF; Thu, 8 Jan 2004 12:10:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id A60D820151 for ; Thu, 8 Jan 2004 12:09:09 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i08HZEL19530; Thu, 8 Jan 2004 09:35:14 -0800 From: Bernard Aboba To: Pasi.Eronen@nokia.com Cc: eap@frascone.com Subject: RE: [eap] Proposed resolution of Issue 212: Protected Result Indications In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A612235E@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A612235E@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 8 Jan 2004 09:35:14 -0800 (PST) > Is a method allowed to make this claim if it protects only some of > the possible cases, but not all? Yes, I think so, since it is impossible to protect all the cases (e.g. before a key is derived, there's nothing to protect it with). All that should be required is that the method specification state what is protected and what isn't. > Hmm.. is integrity & replay protection actually enough to prevent > an attacker from changing result indications? For instance, in EAP-TLS > the server sends the "client authorization failed" TLS alert after the > change_cipher_spec messages, so it is integrity and replay protected. > However, at this point the client is in a state where it will also > accept EAP Success (so the "result indication" here was a _lack_ of > TLS alert message, and that could be spoofed)... The client isn't ready to accept an EAP-Success until it receives the FINISHED message from the server, so I don't think that's right in this case. It's really the joint receipt of the FINISHED message without receiving a TLS alert prior to that which is the success indication. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 11:32:51 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11855 for ; Fri, 9 Jan 2004 11:32:50 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 95EA320262; Fri, 9 Jan 2004 09:19:06 -0500 (EST) Delivered-To: eap@frascone.com Received: from wanderer.mr.itd.umich.edu (wanderer.mr.itd.umich.edu [141.211.93.146]) by mail.frascone.com (Postfix) with ESMTP id 17EB6201FF for ; Fri, 9 Jan 2004 09:18:56 -0500 (EST) Received: from pm552-11.dialip.mich.net (pm552-11.dialip.mich.net [198.110.22.165]) by wanderer.mr.itd.umich.edu (smtp) with ESMTP id i09ETVcX029675; Fri, 9 Jan 2004 09:29:32 -0500 From: John Vollbrecht To: Bernard Aboba , Jari Arkko Cc: eap@frascone.com Subject: Re: [eap] Re: [802.1] Re: 802.1X interface variable Message-ID: <5974650.1073640569@pm552-11.dialip.mich.net> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 09 Jan 2004 09:29:29 -0500 Content-Transfer-Encoding: 7bit This is very interesting - question below - --On Sunday, January 4, 2004 9:22 AM -0800 Bernard Aboba wrote: . . . . > Proving mutual possession of the shared secret is enough to provide mutual > authentication. However, there is a separate issue of authorization -- if > mutual authentication occurs, is this enough for both sides to know that > they are authorized? For this an authorization error message is required. > Since authentication has occurred, this can be MAC'd. If such a message is > supported and is not sent, then the client can know that the server will > eventually signal Success and can silently discard EAP Failure packets. I am not sure it is a requirement that EAP methods provide authorization as well as authentication. Seems they MAY, but are not required to do so. In this circumstance the presence of a key would be sufficient to indicate the method succeeded. I think this is what you are implying here. In the case where a method expects a authorization failure message then message is part of the method, and the method will not complete unless an authorization failure or succeed message is received. EAP Success or Failure messages are discarded when received before a method completes. After a method completes unexpected EAP Success/Fail messages will be discarded. So is it the intention here that all methods should support authorization in addition to authentication? I was thinking that in at least some cases the authorization was done by the AAA protocol and Authentication by EAP. Certainly authorization decisions can be based on rules between the NAS/AP and the AAA Server. - John _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 11:32:51 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11854 for ; Fri, 9 Jan 2004 11:32:50 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AA37520205; Fri, 9 Jan 2004 09:19:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from wanderer.mr.itd.umich.edu (wanderer.mr.itd.umich.edu [141.211.93.146]) by mail.frascone.com (Postfix) with ESMTP id DC781201FF for ; Fri, 9 Jan 2004 09:18:42 -0500 (EST) Received: from pm552-11.dialip.mich.net (pm552-11.dialip.mich.net [198.110.22.165]) by wanderer.mr.itd.umich.edu (smtp) with ESMTP id i09ETHcX029615; Fri, 9 Jan 2004 09:29:18 -0500 From: John Vollbrecht To: Bernard Aboba , Yoshihiro Ohba Cc: eap@frascone.com, stds-802-1@ieee.org Message-ID: <5973807.1073640555@pm552-11.dialip.mich.net> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [eap] Re: [802.1] Re: 802.1X interface variable Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 09 Jan 2004 09:29:15 -0500 Content-Transfer-Encoding: 7bit --On Friday, January 2, 2004 6:50 PM -0800 Bernard Aboba wrote: > > > I think we should require it to avoid possible vulnerability in design > > of future EAP authentication methods, and requiring it should not be a > > problem since many existing mutually authenticating methods (e.g., > > EAP-TLS, PEAP, EAP-TTLS, EAP-SIM, EAP-AKA, EAP-IKEv2, EAP-Archie) are > > already capable of deriving keys. > > Yes. Actually in section 7.10 it already states that methods supporting > key derivation MUST also support mutual authentication. > does this mean that TLS host only authorization is not going to be allowed? I think this is being used to allow access to walled garden environments. > > > Methods supporting mutual authentication MUST also > > > support key derivation and protected result indications." > > > > I agree on adding the text. > > I will add this to the proposed resolution of Issue 207. Together, I > think this makes it unnecessary to add another AAA attribute. > > =>IEEE 802.1 Email List user information: > http://www.ieee802.org/1/email-pages/ _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 11:49:33 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13155 for ; Fri, 9 Jan 2004 11:49:32 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CD2712022D; Tue, 6 Jan 2004 12:41:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 1DC3D201F4 for ; Tue, 6 Jan 2004 12:40:37 -0500 (EST) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 06 Jan 2004 13:57:22 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i06LnmGN011402; Tue, 6 Jan 2004 13:49:49 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.96.169]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 6 Jan 2004 13:55:25 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" , Subject: RE: [eap] Proposed resolution of Issue 212: Protected Result Indications Message-ID: <00ed01c3d49f$013fc1b0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 06 Jan 2004 21:55:26.0002 (UTC) FILETIME=[CA92E920:01C3D49F] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 6 Jan 2004 13:49:47 -0800 Content-Transfer-Encoding: 7bit > In Section 2.4, change: > > " [3] Peer policy satisfaction. EAP methods may support protected > result indications, enabling the peer to indicate to the EAP > server that it successfully authenticated the EAP server. > However, a pass-through authenticator will not be > aware that the > peer has accepted the credentials offered by the EAP server, > unless this information is provided to the > authenticator via the > AAA protocol. As a result, two authentications, one in each > direction, may still be needed. > > It is also possible that the EAP peer's access policy was not > satisfied during the EAP method exchange. For example, the > authenticator may not have successfully authenticated to the > peer, or may not have demonstrated authorization to act in both > peer and server roles. For example, in EAP-TLS [RFC2716], the > authenticator may have authenticated using a valid TLS server > certificate, but not using a valid TLS client > certificate. As a > result, the peer may require an additional > authentication in the > reverse direction, even if the peer provided a protected result > indication to the EAP server indicating that the server had > successfully authenticated to it." > > To: > > "[3] Peer policy satisfaction. EAP methods may support > protected result indications, enabling the peer to indicate > to the EAP server within the method that it successfully > authenticated the EAP server, as well as for the server to > indicate that it has authenticated the peer. However, a > pass-through authenticator will not be aware that the peer > has accepted the credentials offered by the EAP server unless > this information is provided to the authenticator via the AAA > protocol. The authenticator SHOULD interpret the receipt of > a key attribute within an Accept packet as an indication that > the peer has successfully authenticated the server. > [Joe] Is this authenticated or authenticated and authorized? > However, it is possible that the EAP peer's access policy was > not satisfied during the initial EAP exchange, even though > mutual authentication occurred. For example, the EAP > authenticator may not have demonstrated authorization to act > in both peer and authenticator roles. As a result, the peer > may require an additional authentication in the reverse > direction, even if the peer provided an indication that the > EAP server had successfully authenticated to it." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 11:49:33 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13156 for ; Fri, 9 Jan 2004 11:49:32 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C1107201F0; Wed, 7 Jan 2004 14:07:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 902FC2015D for ; Wed, 7 Jan 2004 14:06:49 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i07NVbD17910; Wed, 7 Jan 2004 15:31:37 -0800 From: Bernard Aboba To: Pasi.Eronen@nokia.com Cc: eap@frascone.com Subject: RE: [eap] Proposed resolution of Issue 212: Protected Result Indications In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A612235D@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A612235D@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 7 Jan 2004 15:31:37 -0800 (PST) > Hmm... on a second thought, actually (1) should be something > like "(1) if the peer is willing to use the access provided > by the authenticator, it knows whether the authenticator will > grant access (that is, whether it will send an EAP Success > or Failure packet), and..." > > (Is there some easier way to say that? The idea was that if the > peer is not going to use the access, it doesn't have to know > about the authenticator's decision.) I think your suggestion is OK. > I'd say that result indications are protected if they can't > be spoofed, and unprotected otherwise (since if we don't have > a "result exchange", speaking of integrity protecting is > somewhat confusing). It also seems the revised definition > of "result indication" covers only things that occur after > key derivation... We already have "integrity protection" and "replay protection" claims so perhaps it is easiest to piggyback on these. I don't think we have to specify exactly which result indications are protected and which aren't; the method specification can clarify that. So perhaps the right definition is: "Protected result indications A method provides result indications if after the method has finished (1) if the peer is willing to use the access provided by the authenticator, it knows whether the authenticator will grant access (that is, whether it will send an EAP Success or Failure packet), and (2) if the authenticator decides to grant access, it knows whether the peer will accept it. Result indications improve resilience to packet loss; see Section 4.2 for discussion. Depending on the method and circumstances, result indications can be spoofable by an attacker. A method is said to provide protected result indications if supports result indications as well as the "integrity protection" and "replay protection" claims. See Section 7.16 for details." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 11:49:34 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13175 for ; Fri, 9 Jan 2004 11:49:34 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B3D3520218; Mon, 5 Jan 2004 13:22:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from web12505.mail.yahoo.com (web12505.mail.yahoo.com [216.136.173.197]) by mail.frascone.com (Postfix) with SMTP id F29D420217 for ; Mon, 5 Jan 2004 13:21:55 -0500 (EST) Message-ID: <20040105223108.38025.qmail@web12505.mail.yahoo.com> Received: from [65.205.251.51] by web12505.mail.yahoo.com via HTTP; Mon, 05 Jan 2004 14:31:08 PST From: Thomas Hardjono To: eap@frascone.com Cc: thardjono@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [eap] Comparison of TLVs in PEAP and AVPs in TTLS? Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 5 Jan 2004 14:31:08 -0800 (PST) Apologies if this is a repeat question. I was wondering if anyone has done a detailed comparison between PEAP and TTLS, particularly in their respective ability (and complexity) to perform additional EAP methods/types for authentication (above the TLS channel), and in their respective use of TLVs and AVPs. Thanks in advance. thomas ------ __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 11:49:33 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13154 for ; Fri, 9 Jan 2004 11:49:32 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 73C102021E; Mon, 5 Jan 2004 14:11:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from deneb.mtghouse.com (unknown [206.152.191.132]) by mail.frascone.com (Postfix) with SMTP id BE2542021D for ; Mon, 5 Jan 2004 14:10:02 -0500 (EST) Received: (qmail 6607 invoked from network); 5 Jan 2004 23:19:14 -0000 Received: from unknown (HELO mtghouse.com) (192.168.11.223) by deneb.mtghouse.com with SMTP; 5 Jan 2004 23:19:14 -0000 Message-ID: <3FF9F105.6040005@mtghouse.com> From: Jim Burns User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030829 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Cc: paul.congdon@hp.com, stds-802-1@ieee.org, eap@frascone.com, tony@jeffree.co.uk References: <052E0C61B69C3741AFA5FE88ACC775A612235A@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A612235A@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [eap] Re: [802.1] New EAP/802.1X interface variable proposal Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 05 Jan 2004 18:19:33 -0500 Content-Transfer-Encoding: 7bit Hello Pasi, You are correct, for media using 802.1X, the new variable, eapRemoteSuccess, will not reduce network traffic. Rather its intended goal is to grant the higher layer (EAP/AAA) the ability to dynamically indicate to the lower layer the level of 'policy' satisfaction that has been achieved based on the higher layers knowledge of policy and the EAP methods that were available. Currently, if both 1X machines (supplicant/authenticator) are implemented within a device then both the 1X machines will in fact run simultaneously. There is no suggested/documented/fool-proof method of carrying out tie-breaking between the two .1X machines. This lack of a tie-breaking facility in .1X is discussed in section 2.4 of 2284bis (it is indicated as an issue of 802.11, but I believe it affects 802.3 as well since both use security based on .1X). And, as you have indicated, this means that the eapRemoteSuccess will not reduce the network traffic. The eapRemoteSuccess variable instead addresses a different issue: It allows the higher layer (EAP/AAA) to dynamically indicate full policy satisfaction. It is a recognition that there are two roles ('gain access to network', 'allow access to my resources') involved in making a secure network connection and both roles must indicate policy satisfaction in order for the controlled port to be opened. Policies for each role may be arbitrarily complex. There are a number of EAP methods available with different capabilities and characteristics. Depending on the policy of a device and the EAP method used a single EAP method may satisfy both roles policies. On the other hand, the EAP methods available between two devices may require an EAP method for each role to satisfy its policy. Which EAP method will be used is determined dynamically at the time of running the protocol. Because of these factors (role policies and EAP methods available) there needs to be a way for the higher layer to communicate to the lower layer, dynamically, whether none, one or both roles have been satisfied by the EAP methods that were run. Prior to the definition of eapRemoteSuccess, the higher layer could only indicate that the current role was satisfied (one or none). With the addition of eapRemoteSuccess the higher layer can indicate, dynamically, that both roles have been satisfied. In practical terms this allows policies to be defined that may be satisfied by a single EAP method or two EAP methods and can be dynamically determined at each authentication based on available EAP methods. It should be made clear that two coupled EAP methods do not possess the security of a single mutual authentication EAP method, but there may be policies that allow it, perhaps with reduced authorization. Currently, 802 media (really 802.11 and 802.3) will not see a savings in network traffic. This will require a startup handshake to determine roles and run them sequentially rather than in parallel. This is under consideration for 802.1af (Key agreement protocol for Link Security). Hope this helps, Jim B. Pasi.Eronen@nokia.com wrote: >Hi, > >I have a short question about how eapRemoteSuccess works >when the port first comes operational. > >Let's assume that two parties are using a mutually authenticating >EAP method, and both parties are happy with running the method >in just one direction (and don't care which direction it is). > >When the port comes operational, what happens? Currently it seems >that both parties start both supplicant and authenticator state >machines, so two EAP authentications are started. Presumably, one >of these authentications finishes first and sets eapRemoteSuccess, >and at that point, the second one can be aborted. If both directions >take approximately the same time to complete, we haven't really >avoided the run in the other direction at all... > >Is this the intention, or is there some way the parties can decide >to try one direction first? The description of eapRemoteSuccess >seems to make the assumption that one direction is tried after >the other one, not concurrently, but I couldn't figure out >how this is supposed to happen... > >Best regards, >Pasi > > > >>-----Original Message----- >>From: owner-stds-802-1@majordomo.ieee.org >>[mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of ext >>CONGDON,PAUL (HP-Roseville,ex1) >>Sent: Friday, December 19, 2003 9:13 PM >>To: stds-802-1@ieee.org; eap@frascone.com >>Cc: Jim Burns; Tony Jeffree >>Subject: [802.1] New EAP/802.1X interface variable proposal >> >> >> >> >>A proposed resolution to the 802.1X/EAP interface issue >>related to discussions on EAP issues 204/205 and >>802.1X/D7.1 Ballot comment 15 was developed Dec 5th in a >>phone conference with EAP team members Bernard Aboba, Jari >>Arkko, Nick Petroni and 802.1X team members Jim Burns, Paul >>Congdon and Bob Moskowitz. This memo attempts to document >>the proposal and solicit discussion that will lead to >>closure of this remaining issue for two nearly completed >>documents; 802.1X/D8 and RFC2284bis. >> >>Background - The problem >> >>The resolution of comment 15 on 802.1X/D7.1 uncovered an >>issue with rfc2284bis and the EAP state machine draft. >>Namely, the higher layer(EAP/AAA) is unable to inform the >>lower layer (1X) that its policy has been fully satisfied >>after only one role's state machine has run. This also >>means that it is unable to inform the lower layer that its >>policy will only be satisfied if the other role's state >>machine is run. >> >>In addition, it was discovered that a pass-thru >>authenticator has no way of knowing if a peer has accepted >>a successful mutual authentication exchange since it is >>unaware of any protected indications returned by that peer. >>In contrast a standalone authenticator can be made aware of >>this because the EAP session is terminated locally. >>Consequently pass-thru and standalone configurations behave >>differently and this is not allowed or appropriate. >> >>The ability of the higher layer to inform the lower layer >>when its policy is satisfied can be used to eliminate the >>need for a subsequent authentication exchange in the >>opposite direction. Running two authentications in >>opposite directions of one another is often very difficult >>and not sufficient as pointed out by RFC 2284bis in section >>2.4. >> >>The fix for communicating the satisfaction of policy >>between the higher layer and lower layer is a new interface >>signal. >> >>The fix to ensure that the pass-thru authenticator does not >>behave differently than the standalone authenticator is a >>new RADIUS attribute. The new RADIUS attribute is under >>development and will be documented in a forthcoming RFC. >> >>The new interface signal is communicated across the AAA >>boundary to the EAP. The signal indicates to the layer >>below that the policy of the higher layer is satisfied or >>not. >> >>The RADIUS attribute is used by the authentication server >>to inform a pass-thru authenticator of policy satisfaction >>so it may drive this signal. A standalone authenticator >>could drive this signal based upon local information. >> >>The new interface signal is also made available at the >>802.1X interface and could be used to eliminate the need to >>initiate a second authentication in the opposite direction. >>Essentially this signal could be used to either force >>authorize the alternate role, or activate the Supplicant >>Access Control With Authenticator variable if it were not >>already activated. As RFC 2284bis points out in 2.4 it is >>often neither desirable nor possible to initiate a second >>authentication in the opposite direction, nor is it >>necessary if the 1st authentication resulted in mutual >>authentication with protected indications (essentially what >>the new interface signal asserts). >> >>It is important to note that the EAP layer, EAP methods and >>AAA layer run over transports other than 802.1X and this >>interface signal will be important for those transports as >>well. This new signal will also need to be a consideration >>for future 802.1af work. >> >>The Proposal >> >>The EAP state machine draft will be updated to discuss this >>new indication. Annex F of 802.1X documents the interface >>between the higher layers (EAP, EAP Methods, AAA Layer) and >>802.1X. Annex F must include a definition of all signals >>that cross this interface. This new signal should be >>included in this discussion. >> >>Additionally a short description of how this signal might >>be used to disable reverse authentications in the special >>case where both authenticator and supplicant are configured >>and active on a port. It should reference section 2.4 of >>RFC 2284bis where this type of configuration is discussed >>for peer-to-peer scenarios. A short discussion of this may >>also be needed in clause 6.7. >> >>Proposed Changes to 802.1X/D8 (subject to the editor's >>judgment on wording and style): >> >>Add clause F.2.8 >> >>F.2.8 eapRemoteSuccess >> >>The higher layer will give this signal a value after >>eapSuccess is set. This signal is ignored by the lower >>layer if eapFail is set. If this signal is set following >>eapSuccess then the policy of the higher layer is >>completely satisfied and there is no need to carry out >>further authentication (no need to run the 1X authenticator >>machine). If this signal is reset following setting of >>eapSuccess then the policy of the higher layer requires >>that another authentication (initiated by the 1X >>authenticator) must occur to satisfy the policy. >> >>This variable allows the higher layer to avoid initiating a >>second authentication session where the system would now >>act as authenticator and require the coupling of two >>independent authentications as described in 6.7. >> >>If eapRemoteSuccess is set then Supplicants with this >>indication may choose to set the AuthControlledPortControl >>management variable to ForceAuthorize in order to avoid >>initiating the subsequent authentication. If >>AuthControlledPortControl is set to ForceAuthorize, it must >>be set back to its original state if the supplicant state >>machine exits the authenticated state. >> >>If eapRemoteSuccess is reset then Supplicants with this >>indication may choose to set the AuthControlledPortControl >>management variable to Auto to ensure the authenticator >>machine initiates the subsequent authentication. >> >>Note - Section 2.4 of RFC 2284bis describes several >>situations where coupling two authentications may be needed >>but is difficult to achieve. >> >>Add clause F.3.10 >> >>F.3.10 eapRemoteSuccess >> >>The higher layer will give this signal a value after >>eapSuccess is set. This signal is ignored by the lower >>layer if eapFail is set. If this signal is set following >>eapSuccess then the policy of the higher layer is >>completely satisfied and there is no need to carry out >>further authentication (no need to run the 1X supplicant >>machine). If this signal is reset following setting of >>eapSuccess then the policy of the higher layer requires >>that another authentication (initiated by the 1X >>supplicant) must occur to satisfy the policy. >> >>This variable allows the higher layer to avoid or require a >>second authentication session where the system would now >>act as supplicant and require the coupling of two >>independent authentications as described in 6.7. >> >>If eapRemoteSuccess is set then Authenticators with this >>indication may choose to set the SuppControlledPortControl >>management variable to ForceAuthorize or alternatively >>activate the Supplicant Access Control With Authenticator >>management control. This will avoid initiating the >>subsequent authentication. If either variable is set, it >>must be set back to its original state if the authenticator >>state machine exits the authenticated state. >> >>If eapRemoteSuccess is reset then Authenticators with this >>indication may choose to set the SuppControlledPortControl >>management variable to Auto or alternatively deactivate the >>Supplicant Access Control With Authenticator management >>control. This will cause the supplicant state machine to >>initiate the subsequent authentication. >> >>Note - Section 2.4 of RFC 2284bis describes several >>situations where coupling two authentications may be needed >>but is difficult to achieve. >> >>Comments welcome, >> >>Paul Congdon & Jim Burns >> >>=>IEEE 802.1 Email List user information: >>http://www.ieee802.org/1/email-pages/ >> >> >> > > >=>IEEE 802.1 Email List user information: >http://www.ieee802.org/1/email-pages/ > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 11:49:35 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13185 for ; Fri, 9 Jan 2004 11:49:34 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E72BF20221; Tue, 6 Jan 2004 10:52:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id B232B201F4 for ; Tue, 6 Jan 2004 10:51:42 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i06KGXK14812; Tue, 6 Jan 2004 12:16:34 -0800 From: Bernard Aboba To: Pasi.Eronen@nokia.com Cc: eap@frascone.com Subject: RE: [eap] Revised Proposed Resolution to Issue 207: Miscellaneous Comments In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122359@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A6122359@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 6 Jan 2004 12:16:33 -0800 (PST) > Furthermore, the definition > of "protected result indication" is so vague that it's not > easy to determine which current methods actually do that :-) That is part of what Russ's comment is about, and so I'd suggest that we need to fix this. > As Jari already pointed out, some failure indications > simply can't be protected: if the authentication failed, > how do you authenticate the result indication? If you recall, the requirement was originally called "Acknowledged Result indications", in recognition of the fact that the indications cannot always be protected. The text was then changed to "Protected Result indications" in an attempt to improve clarity, but that seems to have had the opposite effect :( > Authenticating only success indications might be more feasible, > but I don't see any compelling reason to do that. If mutual authentication and key derivation succeed, then one can assume that there is an implicit indication of a successful result in the absence of an error message to the contrary. So I'd agree that there is no need for an explicit success indication. > Acknowledged result indications are quite enough to avoid long timeouts Yes. > Therefore, I suggest we keep the old text. The old text was apparently too vague to be useful, so keeping it probably won't address all the concerns. What I think we need is: a. A definition of "protected result indications" sufficiently clear so that we can understand if an EAP method provides it. b. An understanding of whether we need an additional AAA attribute to tell the authenticator when the peer has successfully authenticated it, or whether the key attribute (and an Access Accept) is sufficient. c. What the implications of a) and b) are in terms of method design. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 11:49:38 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13270 for ; Fri, 9 Jan 2004 11:49:37 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4BEB120239; Wed, 7 Jan 2004 00:28:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.frascone.com (Postfix) with ESMTP id 4AF2E2015C for ; Wed, 7 Jan 2004 00:27:48 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i079b1418737 for ; Wed, 7 Jan 2004 11:37:01 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 7 Jan 2004 11:37:01 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 7 Jan 2004 11:37:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Proposed resolution of Issue 212: Protected Result Indications Message-ID: <052E0C61B69C3741AFA5FE88ACC775A612235C@esebe023.ntc.nokia.com> Thread-Topic: [eap] Proposed resolution of Issue 212: Protected Result Indications Thread-Index: AcPUmpmuHFYPQoaTT3+JlqoDM52vjgAY9orw From: To: , X-OriginalArrivalTime: 07 Jan 2004 09:37:01.0399 (UTC) FILETIME=[CD62BE70:01C3D501] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 7 Jan 2004 11:36:55 +0200 Content-Transfer-Encoding: quoted-printable Bernard Aboba wrote: >=20 > In Section 7.2.1, change: > [...] > To: >=20 > "Protected result indications The ability within a method for > the authenticator to indicate to the peer whether it has > successfully authenticated to it, and for the peer to > acknowledge receipt of that indication as well as indicating > to the authenticator whether it has successfully authenticated > to the peer. This claim requires implication of a > method-specific result exchange that is authenticated, > integrity and replay protected on a per-packet basis. Since > this requires a key, methods making this claim need only > protect result indications sent after a key has been > derived. See Section 7.16 for details." Some methods may derive keys first (using e.g. Diffie-Hellman), and authenticate them later in the exchange. Before this second part has succeeded, the parties don't know who they are sharing=20 the key with, so MAC'ing a packet with that key doesn't=20 really provide per-packet authentication. Since protecting these result indications seems quite complex (and in many cases, impossible), I'd suggest we switch back to "acknowledged result indications", defined something like this: Acknowledged result indications: A method provides acknowledged result indications if after the method has finished (1) the peer knows whether the authenticator will=20 grant access (that is, whether it will send an EAP Success or Failure packet), and (2) if the authenticator decides to grant access, it knows whether the peer will accept it. Acknowledged result indications are intented to improve resilience to packet loss; see Section 4.2 for discussion. Depending on the method and circumstances, these result indications could be spoofable by an attacker. (This definition tries to take into account also "implicit"=20 result indications where there really isn't anything that could be called a "result exchange"). Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 11:49:37 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13231 for ; Fri, 9 Jan 2004 11:49:36 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 191DA20224; Tue, 6 Jan 2004 08:28:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 1DEB920221 for ; Tue, 6 Jan 2004 08:27:19 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i06HqDZ05923 for ; Tue, 6 Jan 2004 09:52:14 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Re: Issue 212: Protected Result Indications Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 6 Jan 2004 09:52:13 -0800 (PST) I've gone ahead and split out the discussion on Protected Result Indications into Issue 212. To help focus the discussion, it might be helpful to take a step back to look at how we got into this discussion. Russ noted that the text relating to implied result indications and error messages was difficult to understand. Separately, Yoshi suggested that there was no need for a separate attribute to tell the pass-through authenticator that the peer had authenticated the server, because the key attribute provided all the required information. We then discussed under what conditions the authenticator could conclude that the peer had authenticated the server, and would accept access granted to it by the authenticator, based on possession of a key attribute. The Accept/Reject indication in AAA tells the authenticator whether it should provide access or not. So the authenticator receiving an Accept knows that it will be granting access. If a key attribute is provided with the Accept (it cannot be provided within a Reject), the question is whether this implies that the peer is willing to accept the access offered it by the authenticator. If the method gets as far as key derivation, and an Access-Accept with a key attribute is sent, then by the requirements in 7.10, mutual authentication MUST have occurred. Then question is then whether there can be a reason why the peer would not accept access offered by the authenticator, even though mutual authentication had occurred. This got us on the subject of error messages. If the client successfully authenticates the server, and the EAP method supports error messages, then the peer has the ability to indicate to the server that a problem exists even though mutual authentication occurred and a key was successfully derived. If the peer does not provide an error message indicating lack of authorization, yet it completes the method, then an implicit success result indication has been sent. By this logic, all that matters in terms of using the key attribute as an indication of peer acceptance is EAP method support for key derivation, mutual authentication and a client result indication (e.g. client error messages). _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 11:49:41 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13395 for ; Fri, 9 Jan 2004 11:49:40 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 25C1720247; Wed, 7 Jan 2004 10:19:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from struggle.mr.itd.umich.edu (struggle.mr.itd.umich.edu [141.211.14.79]) by mail.frascone.com (Postfix) with ESMTP id 9A5CB201EC for ; Wed, 7 Jan 2004 10:18:30 -0500 (EST) Received: from dhcp60-09.merit.edu (dhcp60-09.merit.edu [198.108.60.209]) by struggle.mr.itd.umich.edu (smtp) with ESMTP id i07JRdLk006284; Wed, 7 Jan 2004 14:27:40 -0500 From: John Vollbrecht To: "CONGDON,PAUL (HP-Roseville,ex1)" , stds-802-1@ieee.org, eap@frascone.com Cc: Jim Burns , Tony Jeffree Subject: Re: [eap] New EAP/802.1X interface variable proposal Message-ID: <3906267.1073485656@dhcp60-09.merit.edu> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 07 Jan 2004 14:27:36 -0500 Content-Transfer-Encoding: 7bit The following is comments about the proposal for fixes to the 802.1X/EAP interface. I have attached a power point to this in order to include some diagrams that I can't do in ASCII. I think the proposal is basically very good. I do think there needs to be discussion of details of what the variables between EAP and 802.1X should be, where certain authorization decisions are made, and in what packets RADIUS should carry information (is Access Accept alone correct?) I would appreciate comments on the diagrams, particularly on the description of rules for authorizing in a net to net environment. I think having a set of rules for this would be very helpful, and this is an attempt to describe such rules. I will be in Vancouver next week and hopefully this will be discussed. John --On Friday, December 19, 2003 2:12 PM -0500 "CONGDON,PAUL (HP-Roseville,ex1)" wrote: > > A proposed resolution to the 802.1X/EAP interface issue > related to discussions on EAP issues 204/205 and > 802.1X/D7.1 Ballot comment 15 was developed Dec 5th in a > phone conference with EAP team members Bernard Aboba, Jari > Arkko, Nick Petroni and 802.1X team members Jim Burns, Paul > Congdon and Bob Moskowitz. This memo attempts to document > the proposal and solicit discussion that will lead to > closure of this remaining issue for two nearly completed > documents; 802.1X/D8 and RFC2284bis. > > Background - The problem > > The resolution of comment 15 on 802.1X/D7.1 uncovered an > issue with rfc2284bis and the EAP state machine draft. > Namely, the higher layer(EAP/AAA) is unable to inform the > lower layer (1X) that its policy has been fully satisfied > after only one role's state machine has run. This also > means that it is unable to inform the lower layer that its > policy will only be satisfied if the other role's state > machine is run. > > In addition, it was discovered that a pass-thru > authenticator has no way of knowing if a peer has accepted > a successful mutual authentication exchange since it is > unaware of any protected indications returned by that peer. > In contrast a standalone authenticator can be made aware of > this because the EAP session is terminated locally. > Consequently pass-thru and standalone configurations behave > differently and this is not allowed or appropriate. > > The ability of the higher layer to inform the lower layer > when its policy is satisfied can be used to eliminate the > need for a subsequent authentication exchange in the > opposite direction. Running two authentications in > opposite directions of one another is often very difficult > and not sufficient as pointed out by RFC 2284bis in section > 2.4. > > The fix for communicating the satisfaction of policy > between the higher layer and lower layer is a new interface > signal. > > The fix to ensure that the pass-thru authenticator does not > behave differently than the standalone authenticator is a > new RADIUS attribute. The new RADIUS attribute is under > development and will be documented in a forthcoming RFC. > > The new interface signal is communicated across the AAA > boundary to the EAP. The signal indicates to the layer > below that the policy of the higher layer is satisfied or > not. > > The RADIUS attribute is used by the authentication server > to inform a pass-thru authenticator of policy satisfaction > so it may drive this signal. A standalone authenticator > could drive this signal based upon local information. > > The new interface signal is also made available at the > 802.1X interface and could be used to eliminate the need to > initiate a second authentication in the opposite direction. > Essentially this signal could be used to either force > authorize the alternate role, or activate the Supplicant > Access Control With Authenticator variable if it were not > already activated. As RFC 2284bis points out in 2.4 it is > often neither desirable nor possible to initiate a second > authentication in the opposite direction, nor is it > necessary if the 1st authentication resulted in mutual > authentication with protected indications (essentially what > the new interface signal asserts). > > It is important to note that the EAP layer, EAP methods and > AAA layer run over transports other than 802.1X and this > interface signal will be important for those transports as > well. This new signal will also need to be a consideration > for future 802.1af work. > > The Proposal > > The EAP state machine draft will be updated to discuss this > new indication. Annex F of 802.1X documents the interface > between the higher layers (EAP, EAP Methods, AAA Layer) and > 802.1X. Annex F must include a definition of all signals > that cross this interface. This new signal should be > included in this discussion. > > Additionally a short description of how this signal might > be used to disable reverse authentications in the special > case where both authenticator and supplicant are configured > and active on a port. It should reference section 2.4 of > RFC 2284bis where this type of configuration is discussed > for peer-to-peer scenarios. A short discussion of this may > also be needed in clause 6.7. > > Proposed Changes to 802.1X/D8 (subject to the editor's > judgment on wording and style): > > Add clause F.2.8 > > F.2.8 eapRemoteSuccess > > The higher layer will give this signal a value after > eapSuccess is set. This signal is ignored by the lower > layer if eapFail is set. If this signal is set following > eapSuccess then the policy of the higher layer is > completely satisfied and there is no need to carry out > further authentication (no need to run the 1X authenticator > machine). If this signal is reset following setting of > eapSuccess then the policy of the higher layer requires > that another authentication (initiated by the 1X > authenticator) must occur to satisfy the policy. > > This variable allows the higher layer to avoid initiating a > second authentication session where the system would now > act as authenticator and require the coupling of two > independent authentications as described in 6.7. > > If eapRemoteSuccess is set then Supplicants with this > indication may choose to set the AuthControlledPortControl > management variable to ForceAuthorize in order to avoid > initiating the subsequent authentication. If > AuthControlledPortControl is set to ForceAuthorize, it must > be set back to its original state if the supplicant state > machine exits the authenticated state. > > If eapRemoteSuccess is reset then Supplicants with this > indication may choose to set the AuthControlledPortControl > management variable to Auto to ensure the authenticator > machine initiates the subsequent authentication. > > Note - Section 2.4 of RFC 2284bis describes several > situations where coupling two authentications may be needed > but is difficult to achieve. > > Add clause F.3.10 > > F.3.10 eapRemoteSuccess > > The higher layer will give this signal a value after > eapSuccess is set. This signal is ignored by the lower > layer if eapFail is set. If this signal is set following > eapSuccess then the policy of the higher layer is > completely satisfied and there is no need to carry out > further authentication (no need to run the 1X supplicant > machine). If this signal is reset following setting of > eapSuccess then the policy of the higher layer requires > that another authentication (initiated by the 1X > supplicant) must occur to satisfy the policy. > > This variable allows the higher layer to avoid or require a > second authentication session where the system would now > act as supplicant and require the coupling of two > independent authentications as described in 6.7. > > If eapRemoteSuccess is set then Authenticators with this > indication may choose to set the SuppControlledPortControl > management variable to ForceAuthorize or alternatively > activate the Supplicant Access Control With Authenticator > management control. This will avoid initiating the > subsequent authentication. If either variable is set, it > must be set back to its original state if the authenticator > state machine exits the authenticated state. > > If eapRemoteSuccess is reset then Authenticators with this > indication may choose to set the SuppControlledPortControl > management variable to Auto or alternatively deactivate the > Supplicant Access Control With Authenticator management > control. This will cause the supplicant state machine to > initiate the subsequent authentication. > > Note - Section 2.4 of RFC 2284bis describes several > situations where coupling two authentications may be needed > but is difficult to achieve. > > Comments welcome, > > Paul Congdon & Jim Burns > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 11:49:42 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13431 for ; Fri, 9 Jan 2004 11:49:41 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9702E20237; Tue, 6 Jan 2004 15:09:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id B0C5E20230 for ; Tue, 6 Jan 2004 15:08:43 -0500 (EST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i070HrN9012350; Wed, 7 Jan 2004 09:17:53 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i070HroQ008909; Wed, 7 Jan 2004 09:17:53 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id KAA08901 ; Wed, 7 Jan 2004 09:17:53 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id JAA03166; Wed, 7 Jan 2004 09:17:52 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id JAA12375; Wed, 7 Jan 2004 09:17:51 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i070Hopn001408; Wed, 7 Jan 2004 09:17:51 +0900 (JST) Received: from steelhead ([159.119.168.168]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HR300G9TFHO13@tsbpo1.po.toshiba.co.jp>; Wed, 7 Jan 2004 09:17:49 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Ae1O9-0004sT-00; Tue, 06 Jan 2004 16:17:33 -0800 From: Yoshihiro Ohba Subject: Re: [eap] Revised Proposed Resolution to Issue 207: Miscellaneous Comments In-reply-to: <00ee01c3d4a0$0c0d7410$0300000a@amer.cisco.com> To: Joseph Salowey Cc: "'Bernard Aboba'" , eap@frascone.com Message-id: <20040107001733.GN5444@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i References: <20040106205219.GL5444@steelhead> <00ee01c3d4a0$0c0d7410$0300000a@amer.cisco.com> Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 06 Jan 2004 16:17:33 -0800 On Tue, Jan 06, 2004 at 01:57:14PM -0800, Joseph Salowey wrote: > [Joe] What I am referring to is not access policy. The situation is > that the peer is in a state where it may accept either a EAP-Succes or > an TLS-faliure. SO in this case there does not appear to be a > protected-result-indicator for server success. There may be one for > server failure, but it is probably that the keys won't match and you > wouldn't be able to verify a failure message. In addition since the > protocol is considered complete it is possible that a failure message > could be removed/added/modified without the peer knowing. > Understood. It looks like that EAP-TLS session resumption might need one more protected exchange between TLS finished from TLS client and EAP-Success from TLS server so that the TLS client can securely know whether it has successfully authenticated to the TLS server before receiving the EAP-Success message which is unprotected. Yoshihiro Ohba _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 11:49:44 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13490 for ; Fri, 9 Jan 2004 11:49:43 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DF04220254; Thu, 8 Jan 2004 15:50:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id A1A2020254 for ; Thu, 8 Jan 2004 15:49:41 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i08LFjY00587; Thu, 8 Jan 2004 13:15:45 -0800 From: Bernard Aboba To: Joseph Salowey Cc: eap@frascone.com Subject: RE: [eap] Proposed resolution of Issue 212: Protected Result Indications In-Reply-To: <00eb01c3d627$b8bd2ce0$0300000a@amer.cisco.com> Message-ID: References: <00eb01c3d627$b8bd2ce0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 8 Jan 2004 13:15:44 -0800 (PST) > How about > > "Protected result indications > A method provides result indications if after the method > has finished (1) if the peer is willing to use the access provided by > the authenticator, it knows whether the authenticator will grant access > (that is, only either an EAP-Success or EAP-Failure will be accepted, no > more method specific messages are expected), and (2) if the > authenticator decides to grant access, it knows whether the peer will > accept it. Result indications improve resilience to packet loss; see > Section 4.2 for discussion. Depending on the method and circumstances, > result indications can be spoofable by an attacker. A method is said to > provide protected result indications if supports result indications as > well as the "integrity protection" and "replay protection" claims. 7.16 > for details." OK. Here's the complete current text: "Protected result indications A method provides result indications if after the method has finished (1) if the peer is willing to use the access provided by the authenticator, it knows whether the authenticator will grant access (that is, only either an EAP-Success or EAP-Failure will be accepted, no more method specific messages are expected), and (2) if the authenticator decides to grant access, it knows whether the peer will accept it. Result indications improve resilience to packet loss; see Section 4.2 for discussion. Depending on the method and circumstances, result indications can be spoofable by an attacker. A method is said to provide protected result indications if it supports result indications as well as the "integrity protection" and "replay protection" claims. A method claiming to support protected result indications MUST indicate which result indications are protected, and which are not. See Section 7.16 for details." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 12:05:54 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10481 for ; Fri, 9 Jan 2004 11:17:27 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A8E1A20204; Thu, 8 Jan 2004 20:03:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from chardonnay.local.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by mail.frascone.com (Postfix) with ESMTP id AC62920203 for ; Thu, 8 Jan 2004 20:02:47 -0500 (EST) Received: from chardonnay ([127.0.0.1] helo=chardonnay.local.levkowetz.com) by chardonnay.local.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1AelDC-0005X6-00; Fri, 09 Jan 2004 02:13:18 +0100 From: Henrik Levkowetz To: Bernard Aboba Cc: Jari Arkko , "eap@frascone.com" Message-Id: <20040109021312.0ca5f30c.henrik@levkowetz.com> In-Reply-To: References: <20040108004002.23ff24f7.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Fri__9_Jan_2004_02_13_12_+0100_mO0tfDxvO3EBQSac" Subject: [eap] Issue 208: Editorial questions Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 9 Jan 2004 02:13:12 +0100 --Signature=_Fri__9_Jan_2004_02_13_12_+0100_mO0tfDxvO3EBQSac Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi, In the resolution to issue 208, I'd propose changing "Identity Requests and Responses are sent in cleartext, so that an attacker may snoop on the identity, or even modify or spoof identity exchanges. To address these threats, it is preferable for an EAP method to include an identity exchange that supports per-packet authentication, integrity and replay protection and confidentiality." by replacing "so that an attacker may" with "so an attacker may" because "so that an attacker may" can be understood as "in order that an attacker may". Requirements language: In Section 7.6, should "In order to protect against dictionary attacks, authentication methods resistant to dictionary attacks (as defined in Section 7.2.1) are recommended." end with "... are RECOMMENDED" ? Similarly, in 7.11, should "To protect against data modification, spoofing or snooping, it is recommended that EAP methods supporting mutual authentication, and key derivation (as defined by Section 7.2.1) be used, along with a lower layers providing per-packet confidentiality, authentication, integrity and replay protection." instead read "... it is RECOMMENDED that EAP methods supporting ..."? Henrik --Signature=_Fri__9_Jan_2004_02_13_12_+0100_mO0tfDxvO3EBQSac Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE//gAoeVhrtTJkXCMRAh42AKCi91oFD40h2+M1gm28GJE3j0yjnQCfT0W5 dtYFSxkAh8Yji/NIfkOn80c= =rXna -----END PGP SIGNATURE----- --Signature=_Fri__9_Jan_2004_02_13_12_+0100_mO0tfDxvO3EBQSac-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 12:05:59 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10491 for ; Fri, 9 Jan 2004 11:17:29 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3F3B0201F5; Thu, 8 Jan 2004 12:30:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.frascone.com (Postfix) with ESMTP id C572420151 for ; Thu, 8 Jan 2004 12:29:26 -0500 (EST) Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i08HdwGN013923; Thu, 8 Jan 2004 09:39:59 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.115.90]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 8 Jan 2004 09:45:36 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" , Cc: Subject: RE: [eap] Proposed resolution of Issue 212: Protected Result Indications Message-ID: <00cc01c3d60e$6ee78a20$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 08 Jan 2004 17:45:36.0338 (UTC) FILETIME=[38DD3320:01C3D60F] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 8 Jan 2004 09:39:56 -0800 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Bernard Aboba > Sent: Thursday, January 08, 2004 9:35 AM > To: Pasi.Eronen@nokia.com > Cc: eap@frascone.com > Subject: RE: [eap] Proposed resolution of Issue 212: > Protected Result Indications > > > > Is a method allowed to make this claim if it protects only > some of the > > possible cases, but not all? > > Yes, I think so, since it is impossible to protect all the > cases (e.g. before a key is derived, there's nothing to > protect it with). All that should be required is that the > method specification state what is protected and what isn't. > > > Hmm.. is integrity & replay protection actually enough to > prevent an > > attacker from changing result indications? For instance, in EAP-TLS > > the server sends the "client authorization failed" TLS > alert after the > > change_cipher_spec messages, so it is integrity and replay > protected. > > However, at this point the client is in a state where it will also > > accept EAP Success (so the "result indication" here was a _lack_ of > > TLS alert message, and that could be spoofed)... > > The client isn't ready to accept an EAP-Success until it > receives the FINISHED message from the server, so I don't > think that's right in this case. It's really the joint > receipt of the FINISHED message without receiving a TLS alert > prior to that which is the success indication. [Joe] Not in the case of TLS resume. > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 12:05:59 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10479 for ; Fri, 9 Jan 2004 11:17:27 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 80B392025D; Fri, 9 Jan 2004 01:42:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 3477D201FF for ; Fri, 9 Jan 2004 01:41:06 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 7D24A6A902; Fri, 9 Jan 2004 08:51:42 +0200 (EET) Message-ID: <3FFE4F31.3010809@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: Henrik Levkowetz , Jari Arkko , "eap@frascone.com" References: <20040108004002.23ff24f7.henrik@levkowetz.com> <20040109021312.0ca5f30c.henrik@levkowetz.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [eap] Re: Issue 208: Editorial questions Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 09 Jan 2004 08:50:25 +0200 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > > On Fri, 9 Jan 2004, Henrik Levkowetz wrote: > > >>Hi, >> >>In the resolution to issue 208, I'd propose changing >> >> "Identity Requests and Responses are sent in cleartext, so >> that an attacker may snoop on the identity, or even modify >> or spoof identity exchanges. To address these threats, >> it is preferable for an EAP method to include an identity >> exchange that supports per-packet authentication, >> integrity and replay protection and confidentiality." >> >>by replacing "so that an attacker may" with "so an attacker may" >>because "so that an attacker may" can be understood as "in order >>that an attacker may". > > > ok. > > >>Requirements language: >>In Section 7.6, should >> >> "In order to protect against dictionary attacks, authentication >> methods resistant to dictionary attacks (as defined in Section 7.2.1) >> are recommended." >> >>end with "... are RECOMMENDED" ? > > > I think we need to leave this lower case. Otherwise we are saying that > the mandatory-to-implement method should not be used. > > >>Similarly, in 7.11, should >> >> "To protect against data modification, spoofing or snooping, it is >> recommended that EAP methods supporting mutual authentication, >> and key derivation (as defined by Section 7.2.1) be used, along with >> a lower layers providing per-packet confidentiality, authentication, >> integrity and replay protection." >> >>instead read "... it is RECOMMENDED that EAP methods supporting ..."? > > > I believe this is lower case as well, for the same reasons. Elsewhere in > the text we are citing other documents (such as the IEEE 802.11i liaison > letter) that specify EAP method requirements for specific environments. > It's best to leave that kind of recommendation out of RFC 2284bis, much as > the IKE/IPsec documents do not provide guidance as to various IPsec > features need to be turned on. I agree with Bernard. By the way, the 7.11 text seems funny to me when it says "... along with a lower layers ...". Shouldn't that be "along with a lower layer" or "along with lower layers"? --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 12:06:00 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10477 for ; Fri, 9 Jan 2004 11:17:27 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 58CEC20243; Wed, 7 Jan 2004 08:46:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.frascone.com (Postfix) with ESMTP id D8D4720241 for ; Wed, 7 Jan 2004 08:45:58 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i07HtD417723 for ; Wed, 7 Jan 2004 19:55:13 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 7 Jan 2004 19:55:13 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 7 Jan 2004 19:55:12 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 7 Jan 2004 19:55:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Proposed resolution of Issue 212: Protected Result Indications Message-ID: <052E0C61B69C3741AFA5FE88ACC775A612235D@esebe023.ntc.nokia.com> Thread-Topic: [eap] Proposed resolution of Issue 212: Protected Result Indications Thread-Index: AcPVLrpz7njkcXR9QAe0jmPJiDgRmwADZt/A From: To: Cc: X-OriginalArrivalTime: 07 Jan 2004 17:55:13.0558 (UTC) FILETIME=[66803B60:01C3D547] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 7 Jan 2004 19:55:12 +0200 Content-Transfer-Encoding: quoted-printable Bernard Aboba wrote: > > > Since protecting these result indications seems quite complex > > (and in many cases, impossible), I'd suggest we switch back > > to "acknowledged result indications", defined something like this: >=20 > The original change was made in part because without protection, > result indications only address the timeout issue. What other issue would require that the result indications=20 are protected? (protecting the result indications is not likely to make DoS any harder) > > Acknowledged result indications: A method provides > > acknowledged result indications if after the method has > > finished (1) the peer knows whether the authenticator will > > grant access (that is, whether it will send an EAP Success or > > Failure packet), and (2) if the authenticator decides to grant > > access, it knows whether the peer will accept it. > > > > Acknowledged result indications are intented to improve > > resilience to packet loss; see Section 4.2 for discussion. > > Depending on the method and circumstances, these result > > indications could be spoofable by an attacker. > > > > (This definition tries to take into account also "implicit" > > result indications where there really isn't anything that > > could be called a "result exchange"). >=20 > How about combining them? >=20 > "Protected result indications: A method provides > result indications if after the method has finished (1) the > peer knows whether the authenticator will grant access (that is, > whether it will send an EAP Success or Failure packet), and > (2) if the authenticator decides to grant access, it knows > whether the peer will accept it. Result indications improve > resilience to packet loss; see Section 4.2 for discussion. Hmm... on a second thought, actually (1) should be something=20 like "(1) if the peer is willing to use the access provided by the authenticator, it knows whether the authenticator will=20 grant access (that is, whether it will send an EAP Success=20 or Failure packet), and..." (Is there some easier way to say that? The idea was that if the peer is not going to use the access, it doesn't have to know about the authenticator's decision.) > Depending on the method and circumstances, result indications > can be spoofable by an attacker. Result indications are > said to be protected if they are authenticated, integrity and > replay protected. Since this requires a key, it is only > possible to provide protection once mutual > authentication and key derivation are complete." I'd say that result indications are protected if they can't be spoofed, and unprotected otherwise (since if we don't have=20 a "result exchange", speaking of integrity protecting is somewhat confusing). It also seems the revised definition=20 of "result indication" covers only things that occur after=20 key derivation... Thus, if I'm getting this right, it seems that result indications=20 are protected iff the following cases don't occur: 1. Peer is satisfied. Authenticator is also satisfied=20 (sends EAP Success), but attacker convinces the peer to=20 expect EAP Failure instead. 2. Peer is satisfied. Authenticator is not satisfied=20 (sends EAP Failure), but attacker convinces the peer to=20 expect EAP Success instead. 3. Peer is satisfied. Authenticator is satisfied, but=20 sends EAP Failure anyway because the attacker convinced it=20 the peer is not satisfied. 4. Peer is not satisfied. The authenticator is satisfied=20 and sends EAP Success because the attacker convinced it=20 the peer is satisfied. (or did I get it right? ouch, my brain hurts :-) Or, equivalently (?), one of the parties proceeds to four-way handshake (or whatever comes after EAP) and the other one doesn't because it had spoofed information about the other party's intentions. (Note that the end result is still just=20 a DoS, unless the attacker gets the session keys; and if he=20 does, we have worse problems.) Let's see how e.g. EAP-TLS handles these... it seems that all cases can occur. Cases 1 and 3 could probably be=20 prevented by rather simple cases (silently discard packets with incorrect MAC instead of failing). Cases 2 and 4 might be prevented if TLS Alert messages were used in a different way than shown in Section 3.8's sequence diagrams. Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 12:35:56 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13403 for ; Fri, 9 Jan 2004 11:49:40 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 375DD20232; Tue, 6 Jan 2004 12:44:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id AC57820231 for ; Tue, 6 Jan 2004 12:43:27 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i06M8JS21697; Tue, 6 Jan 2004 14:08:19 -0800 From: Bernard Aboba To: Joseph Salowey Cc: eap@frascone.com Subject: RE: [eap] Proposed resolution of Issue 212: Protected Result Indications In-Reply-To: <00ed01c3d49f$013fc1b0$0300000a@amer.cisco.com> Message-ID: References: <00ed01c3d49f$013fc1b0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 6 Jan 2004 14:08:19 -0800 (PST) > > The authenticator SHOULD interpret the receipt of > > a key attribute within an Accept packet as an indication that > > the peer has successfully authenticated the server. > > > [Joe] Is this authenticated or authenticated and authorized? I think it is "authenticated and authorized". Are there counter-examples? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 12:35:56 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13239 for ; Fri, 9 Jan 2004 11:49:36 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1A6D920249; Thu, 8 Jan 2004 14:08:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 20A3220151 for ; Thu, 8 Jan 2004 14:07:28 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i08JXVt26851; Thu, 8 Jan 2004 11:33:31 -0800 From: Bernard Aboba To: Joseph Salowey Cc: eap@frascone.com Subject: RE: [eap] Proposed resolution of Issue 212: Protected Result Indications In-Reply-To: <00cc01c3d60e$6ee78a20$0300000a@amer.cisco.com> Message-ID: References: <00cc01c3d60e$6ee78a20$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 8 Jan 2004 11:33:31 -0800 (PST) > > The client isn't ready to accept an EAP-Success until it > > receives the FINISHED message from the server, so I don't > > think that's right in this case. It's really the joint > > receipt of the FINISHED message without receiving a TLS alert > > prior to that which is the success indication. > > [Joe] Not in the case of TLS resume. Do you have some text to suggest that will clarify this issue in the suggested resolution of Issue 212? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 12:35:56 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13410 for ; Fri, 9 Jan 2004 11:49:40 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 958152024B; Wed, 7 Jan 2004 10:36:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 0A2612024B for ; Wed, 7 Jan 2004 10:35:03 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i07JxoU05056; Wed, 7 Jan 2004 11:59:50 -0800 From: Bernard Aboba To: Joseph Salowey Cc: eap@frascone.com, mankin@psg.com Subject: RE: [eap] Proposed Resolution to Issue 209: Applicability statement In-Reply-To: <006701c3d552$b5bd1c10$0300000a@amer.cisco.com> Message-ID: References: <006701c3d552$b5bd1c10$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 7 Jan 2004 11:59:50 -0800 (PST) > > EAP was designed for use in network access authentication, > > where IP layer connectivity may not be available. Use of EAP > > for other purposes, such as application layer authentication, > > or bulk data transport, is NOT RECOMMENDED. > > > [Joe] So why is EAP not recommended for application layer > authentication? I think it would be useful to state more clearly why > since many of the requirements for authentication would be the same. > The main difference between EAP and something like SASL, GSSAPI and TLS > is that EAP does not provide security services or a security layer, it > just provides a key material for an existing security layer. A major difference between GSS-API and EAP is that GSS-API (with the exception of IAKERB) assumes that an initial authentication has already occurred. GSS-API also provides a complete suite of security services, as you say. SASL does not provide such a complete suite, and does not assume initial authentication, so it is more analagous to EAP. However, it runs over reliable transport so it is more efficient than EAP. It also typically assumes that it is running over a lower security layer (e.g. TLS) but does not provide keys for that layer or even supporting crypto-binding to it (enabling man-in-the-middle attacks). > I suggest change the above to something like: > > "EAP was designed for the use in network access authentication, where IP > layer connectivity may not be available. EAP also assumes the existence > of a security layer to provide on going data protection such as layer 2 > encryption. Hmm. Section 3.1 states that EAP does *not* assume existence of lower layer security services. > EAP may provide keying material for this external security > layer. It is NOT RECOMMENDED that EAP be used in scenarios where an > external security layer is not provided such as most application layer > protocols. I don't think we want to probibit use of EAP in wired networks, do we? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 12:35:57 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13292 for ; Fri, 9 Jan 2004 11:49:38 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4135C2020A; Mon, 5 Jan 2004 11:05:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id 918F020149 for ; Mon, 5 Jan 2004 11:04:06 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i05KDE601436 for ; Mon, 5 Jan 2004 22:13:16 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 5 Jan 2004 22:13:14 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 5 Jan 2004 22:13:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Revised Proposed Resolution to Issue 207: Miscellaneous Comments Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122359@esebe023.ntc.nokia.com> Thread-Topic: [eap] Revised Proposed Resolution to Issue 207: Miscellaneous Comments Thread-Index: AcPRoP0U675YzD32RiSbsVXd4H5dTQCF7vNQ From: To: , X-OriginalArrivalTime: 05 Jan 2004 20:13:14.0955 (UTC) FILETIME=[59C5A1B0:01C3D3C8] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 5 Jan 2004 22:13:13 +0200 Content-Transfer-Encoding: quoted-printable Bernard Aboba wrote: > > In Section 7.10, change the first paragraph from: >=20 > "It is possible for the peer and EAP server to mutually > authenticate and derive keys. In order to provide keying > material for use in a subsequently negotiated ciphersuite, an > EAP method supporting key derivation MUST export a Master > Session Key (MSK) of at least 64 octets, and an Extended > Master Session Key (EMSK) of at least 64 octets. EAP Methods > deriving keys MUST provide for mutual authentication between > the EAP peer and the EAP Server." >=20 > To: >=20 > "It is possible for the peer and EAP server to mutually > authenticate and derive keys. In order to provide keying > material for use in a subsequently negotiated ciphersuite, an > EAP method supporting key derivation MUST export a Master > Session Key (MSK) of at least 64 octets, and an Extended > Master Session Key (EMSK) of at least 64 octets. >=20 > EAP Methods supporting key derivation MUST also support mutual > authentication between the EAP peer and the EAP Server. EAP > Methods supporting mutual authentication MUST also support key > derivation and protected result indications." I am against adding new "MUST" requirements at this stage, especially if they are not absolutely necessary.=20 The requirement that mutually authenticating methods must=20 also support key derivation isn't probably that bad (it seems that currently all do), but not all existing methods have protected result indications. Furthermore, the definition of "protected result indication" is so vague that it's not easy to determine which current methods actually do that :-) As Jari already pointed out, some failure indications=20 simply can't be protected: if the authentication failed,=20 how do you authenticate the result indication?=20 Authenticating only success indications might be more feasible, but I don't see any compelling reason to do that. Acknowledged result indications are quite enough to avoid long timeouts (in case of packet loss), and spoofing them doesn't lead to=20 anything worse than DoS anyway. Therefore, I suggest we keep the old text. Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 12:35:58 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13153 for ; Fri, 9 Jan 2004 11:49:32 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CF17220234; Wed, 7 Jan 2004 05:50:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 814F02015B for ; Wed, 7 Jan 2004 05:49:23 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i07FECF20540; Wed, 7 Jan 2004 07:14:12 -0800 From: Bernard Aboba To: Pasi.Eronen@nokia.com Cc: eap@frascone.com Subject: RE: [eap] Proposed resolution of Issue 212: Protected Result Indications In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A612235C@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A612235C@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 7 Jan 2004 07:14:12 -0800 (PST) > > "Protected result indications The ability within a method for > > the authenticator to indicate to the peer whether it has > > successfully authenticated to it, and for the peer to > > acknowledge receipt of that indication as well as indicating > > to the authenticator whether it has successfully authenticated > > to the peer. This claim requires a > > method-specific result exchange that is authenticated, > > integrity and replay protected on a per-packet basis. Since > > this requires a key, methods making this claim need only > > protect result indications sent after a key has been > > derived. See Section 7.16 for details." > > Some methods may derive keys first (using e.g. Diffie-Hellman), > and authenticate them later in the exchange. Before this second > part has succeeded, the parties don't know who they are sharing > the key with, so MAC'ing a packet with that key doesn't > really provide per-packet authentication. Agreed. > Since protecting these result indications seems quite complex > (and in many cases, impossible), I'd suggest we switch back > to "acknowledged result indications", defined something like this: The original change was made in part because without protection, result indications only address the timeout issue. > Acknowledged result indications: A method provides > acknowledged result indications if after the method has > finished (1) the peer knows whether the authenticator will > grant access (that is, whether it will send an EAP Success or > Failure packet), and (2) if the authenticator decides to grant > access, it knows whether the peer will accept it. > > Acknowledged result indications are intented to improve > resilience to packet loss; see Section 4.2 for discussion. > Depending on the method and circumstances, these result > indications could be spoofable by an attacker. > > (This definition tries to take into account also "implicit" > result indications where there really isn't anything that > could be called a "result exchange"). How about combining them? "Protected result indications: A method provides result indications if after the method has finished (1) the peer knows whether the authenticator will grant access (that is, whether it will send an EAP Success or Failure packet), and (2) if the authenticator decides to grant access, it knows whether the peer will accept it. Result indications improve resilience to packet loss; see Section 4.2 for discussion. Depending on the method and circumstances, result indications can be spoofable by an attacker. Result indications are said to be protected if they are authenticated, integrity and replay protected. Since this requires a key, it is only possible to provide protection once mutual authentication and key derivation are complete." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 12:35:58 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13203 for ; Fri, 9 Jan 2004 11:49:34 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B7DEF2024F; Wed, 7 Jan 2004 10:55:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.frascone.com (Postfix) with ESMTP id 308692024E for ; Wed, 7 Jan 2004 10:55:01 -0500 (EST) Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i07K4Alx019829; Wed, 7 Jan 2004 12:04:13 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.115.90]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 7 Jan 2004 12:09:48 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" Cc: , Subject: RE: [eap] Proposed Resolution to Issue 209: Applicability statement Message-ID: <007201c3d559$6a313040$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 07 Jan 2004 20:09:48.0830 (UTC) FILETIME=[33BCF3E0:01C3D55A] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 7 Jan 2004 12:04:09 -0800 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Wednesday, January 07, 2004 12:00 PM > To: Joseph Salowey > Cc: eap@frascone.com; mankin@psg.com > Subject: RE: [eap] Proposed Resolution to Issue 209: > Applicability statement > > > > > EAP was designed for use in network access > authentication, where IP > > > layer connectivity may not be available. Use of EAP for other > > > purposes, such as application layer authentication, or bulk data > > > transport, is NOT RECOMMENDED. > > > > > [Joe] So why is EAP not recommended for application layer > > authentication? I think it would be useful to state more > clearly why > > since many of the requirements for authentication would be > the same. > > The main difference between EAP and something like SASL, > GSSAPI and > > TLS is that EAP does not provide security services or a security > > layer, it just provides a key material for an existing > security layer. > > A major difference between GSS-API and EAP is that GSS-API > (with the exception of IAKERB) assumes that an initial > authentication has already occurred. GSS-API also provides a > complete suite of security services, as you say. > [Joe] This depends on the authenticaiton mechanism, not on GSSAPI or EAP. What you say is true of kerberos and may not be true of other GSSAPI mechanisms. > SASL does not provide such a complete suite, and does not > assume initial authentication, so it is more analagous to > EAP. However, it runs over reliable transport so it is more > efficient than EAP. It also typically assumes that it is > running over a lower security layer (e.g. TLS) but does not > provide keys for that layer or even supporting crypto-binding > to it (enabling man-in-the-middle attacks). > [Joe] SASL using Kerberos GSSAPI (or a raw kerberos mechanism) does not assume initial authentication. SASL mechanisms can provide an encryption and integrity protection layer themselves, but you are correct in that this is currently independent of any TLS security because SASL does not have channel bindings or crypto-binding. > > I suggest change the above to something like: > > > > "EAP was designed for the use in network access > authentication, where > > IP layer connectivity may not be available. EAP also assumes the > > existence of a security layer to provide on going data > protection such > > as layer 2 encryption. > > Hmm. Section 3.1 states that EAP does *not* assume existence > of lower layer security services. > [Joe] So lower layer security might not be the correct term for what I am describing. EAP by itself does not provide a full set of security services it must be used in conjunction with some additional mechanism in order to provide this. If it is not used with an external mechanism then you will have vulnerability to man in the middle attacks which compromise the data completely. It is possible that the additional mechanism/layer is physical security (there's that term again). > > EAP may provide keying material for this external security > layer. It > > is NOT RECOMMENDED that EAP be used in scenarios where an external > > security layer is not provided such as most application layer > > protocols. > > I don't think we want to probibit use of EAP in wired networks, do we? > [Joe] No, but it should be used with a security layer. Perhaps that is a layer of physical security. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 12:35:59 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13217 for ; Fri, 9 Jan 2004 11:49:35 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6BBAE20210; Mon, 5 Jan 2004 08:51:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.frascone.com (Postfix) with ESMTP id C189E2020A for ; Mon, 5 Jan 2004 08:50:44 -0500 (EST) Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id i05HxiQw009170; Mon, 5 Jan 2004 09:59:47 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.96.169]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 5 Jan 2004 10:05:22 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" , Subject: RE: [eap] Revised Proposed Resolution to Issue 207: Miscellaneous Comments Message-ID: <008e01c3d3b5$b41bfbe0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 05 Jan 2004 18:05:22.0866 (UTC) FILETIME=[7CD9C120:01C3D3B6] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 5 Jan 2004 09:59:44 -0800 Content-Transfer-Encoding: 7bit > In Section 4.2, 7th paragraph, change: > > " A mutually authenticating method (such as EAP-TLS > [RFC2716]) that provides authorization error messages > provides protected result indications for the purpose of this > specification. Within EAP-TLS, the peer always authenticates > the authenticator, and may send a TLS-alert message in the > event of an authentication failure. An authenticator may use > the "access denied" TLS alert after successfully > authenticating the peer to indicate that a valid certificate > was received from the peer, but when access control was > applied, the authenticator decided not to proceed. If a > method provides authorization error messages, the > authenticator SHOULD use them so as to ensure consistency > with the final access decision and avoid lengthy timeouts." > > To: > > "A mutually authenticating method may use error messages > to provide protected result indications. This ensures that > the peer and server are aware of each other's final access > decision, and prevents lengthy timeouts. > > For example, within EAP-TLS [RFC2716], the peer > always authenticates the server, and sends a TLS alert > message in the event of an authentication or authorization > failure. If the server does not receive a TLS alert message > from the peer and the peer continues the conversation to > completion (e.g. sends a FINISHED message), then the server > can assume that the peer will accept access if granted it by > the server. > > Similarly, the peer can assume that the server will grant > access if it does not receive a TLS alert message from the > server, and the server carries the conversation to completion > (e.g. sends a FINISHED message). > [Joe] does this also hold true in the case of TLS session resume? In session resume the server sends the finished message before the client which is opposite of the full handshake. In the session resume case the peer is in a state where it may accept a TLS-Alert or an EAP-Success. > A server may use the "access denied" TLS alert > after successfully authenticating the peer to indicate that a > valid certificate was received from the peer, but when access > control was applied, the server decided not to proceed." > In Section 7.10, change the first paragraph from: > > "It is possible for the peer and EAP server to mutually > authenticate and derive keys. In order to provide keying > material for use in a subsequently negotiated ciphersuite, an > EAP method supporting key derivation MUST export a Master > Session Key (MSK) of at least 64 octets, and an Extended > Master Session Key (EMSK) of at least 64 octets. EAP Methods > deriving keys MUST provide for mutual authentication between > the EAP peer and the EAP Server." > > To: > > "It is possible for the peer and EAP server to mutually > authenticate and derive keys. In order to provide keying > material for use in a subsequently negotiated ciphersuite, an > EAP method supporting key derivation MUST export a Master > Session Key (MSK) of at least 64 octets, and an Extended > Master Session Key (EMSK) of at least 64 octets. > > EAP Methods supporting key derivation MUST also support > mutual authentication between the EAP peer and the EAP > Server. EAP Methods supporting mutual authentication MUST > also support key derivation and protected result indications." > [Joe] It seems that this disallows authenticated servers and anonymous clients. I'm not sure that this is a good idea. The MUST for protected result indications seems to be a big change. Given the above it appears that EAP-TLS does not meet protected result indications in all cases. > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 12:35:59 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13399 for ; Fri, 9 Jan 2004 11:49:40 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D91BB20259; Thu, 8 Jan 2004 17:34:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.frascone.com (Postfix) with ESMTP id 20B3E20256 for ; Thu, 8 Jan 2004 17:33:05 -0500 (EST) Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i08MhYVM016546; Thu, 8 Jan 2004 14:43:40 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.115.90]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 8 Jan 2004 14:49:12 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" Cc: , Subject: RE: [eap] Proposed Resolution to Issue 209: Applicability statement Message-ID: <00fd01c3d638$d8cf9020$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <007201c3d559$6a313040$0300000a@amer.cisco.com> X-OriginalArrivalTime: 08 Jan 2004 22:49:13.0127 (UTC) FILETIME=[A2EA9B70:01C3D639] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 8 Jan 2004 14:43:33 -0800 Content-Transfer-Encoding: 7bit How about: "EAP was designed for the use in network access authentication, where IP layer connectivity may not be available. EAP does not provide a means for protecting bulk data transfer and must be used in conjunction with a bulk data protection mechanism, such as layer 2 encryption, if such a facility is required. It is NOT RECOMMENDED that EAP be used in scenarios where bulk data protection is required and not provided through some mechanism. EAP may provide keying material for the bulk data protection mechanism. Since not all EAP mechanism provide a channel binding facility it is NOT RECOMMENDED that EAP be used with bulk data protection that does not use keying material from EAP unless the resulting man-in-the-middle threats can be mitigated. The use of EAP itself for bulk data transport is NOT RECOMMENDED." eap-admin@frascone.com wrote: >> -----Original Message----- >> From: Bernard Aboba [mailto:aboba@internaut.com] >> Sent: Wednesday, January 07, 2004 12:00 PM >> To: Joseph Salowey >> Cc: eap@frascone.com; mankin@psg.com >> Subject: RE: [eap] Proposed Resolution to Issue 209: Applicability >> statement >> >> >>>> EAP was designed for use in network access authentication, where IP >>>> layer connectivity may not be available. Use of EAP for other >>>> purposes, such as application layer authentication, or bulk data >>>> transport, is NOT RECOMMENDED. >>>> >>> [Joe] So why is EAP not recommended for application layer >>> authentication? I think it would be useful to state more clearly >>> why since many of the requirements for authentication would be the >>> same. The main difference between EAP and something like SASL, >>> GSSAPI and TLS is that EAP does not provide security services or a >>> security layer, it just provides a key material for an existing >>> security layer. >> >> A major difference between GSS-API and EAP is that GSS-API >> (with the exception of IAKERB) assumes that an initial >> authentication has already occurred. GSS-API also provides a >> complete suite of security services, as you say. >> > [Joe] This depends on the authenticaiton mechanism, not on > GSSAPI or EAP. What you say is true of kerberos and may not > be true of other GSSAPI mechanisms. > > >> SASL does not provide such a complete suite, and does not >> assume initial authentication, so it is more analagous to >> EAP. However, it runs over reliable transport so it is more >> efficient than EAP. It also typically assumes that it is >> running over a lower security layer (e.g. TLS) but does not >> provide keys for that layer or even supporting crypto-binding >> to it (enabling man-in-the-middle attacks). >> > [Joe] SASL using Kerberos GSSAPI (or a raw kerberos > mechanism) does not assume initial authentication. SASL > mechanisms can provide an encryption and integrity protection > layer themselves, but you are correct in that this is > currently independent of any TLS security because SASL does > not have channel bindings or crypto-binding. > > > >>> I suggest change the above to something like: >>> >>> "EAP was designed for the use in network access authentication, >>> where IP layer connectivity may not be available. EAP also assumes >>> the existence of a security layer to provide on going data >>> protection such as layer 2 encryption. >> >> Hmm. Section 3.1 states that EAP does *not* assume existence >> of lower layer security services. >> > [Joe] So lower layer security might not be the correct term > for what I am describing. EAP by itself does not provide a > full set of security services it must be used in conjunction > with some additional mechanism in order to provide this. If > it is not used with an external mechanism then you will have > vulnerability to man in the middle attacks which compromise > the data completely. It is possible that the additional > mechanism/layer is physical security (there's that term again). > > >>> EAP may provide keying material for this external security layer. It >>> is NOT RECOMMENDED that EAP be used in scenarios where an external >>> security layer is not provided such as most application layer >>> protocols. >> >> I don't think we want to probibit use of EAP in wired networks, do >> we? >> > [Joe] No, but it should be used with a security layer. > Perhaps that is a layer of physical security. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 12:36:00 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13169 for ; Fri, 9 Jan 2004 11:49:33 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CC13A20200; Tue, 6 Jan 2004 11:44:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id 78104201F4 for ; Tue, 6 Jan 2004 11:43:32 -0500 (EST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i06KqeN9001845; Wed, 7 Jan 2004 05:52:40 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i06KqeGg016374; Wed, 7 Jan 2004 05:52:40 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA16373 ; Wed, 7 Jan 2004 05:52:40 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA06653; Wed, 7 Jan 2004 05:52:40 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA22798; Wed, 7 Jan 2004 05:52:39 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i06Kqcpn012444; Wed, 7 Jan 2004 05:52:39 +0900 (JST) Received: from steelhead ([159.119.168.151]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HR3007285ZO9C@tsbpo1.po.toshiba.co.jp>; Wed, 7 Jan 2004 05:52:37 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AdyBX-0004Pj-00; Tue, 06 Jan 2004 12:52:19 -0800 From: Yoshihiro Ohba Subject: Re: [eap] Revised Proposed Resolution to Issue 207: Miscellaneous Comments In-reply-to: <008e01c3d3b5$b41bfbe0$0300000a@amer.cisco.com> To: Joseph Salowey Cc: "'Bernard Aboba'" , eap@frascone.com Message-id: <20040106205219.GL5444@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i References: <008e01c3d3b5$b41bfbe0$0300000a@amer.cisco.com> Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 06 Jan 2004 12:52:19 -0800 On Mon, Jan 05, 2004 at 09:59:44AM -0800, Joseph Salowey wrote: > > > > In Section 4.2, 7th paragraph, change: > > > > " A mutually authenticating method (such as EAP-TLS > > [RFC2716]) that provides authorization error messages > > provides protected result indications for the purpose of this > > specification. Within EAP-TLS, the peer always authenticates > > the authenticator, and may send a TLS-alert message in the > > event of an authentication failure. An authenticator may use > > the "access denied" TLS alert after successfully > > authenticating the peer to indicate that a valid certificate > > was received from the peer, but when access control was > > applied, the authenticator decided not to proceed. If a > > method provides authorization error messages, the > > authenticator SHOULD use them so as to ensure consistency > > with the final access decision and avoid lengthy timeouts." > > > > To: > > > > "A mutually authenticating method may use error messages > > to provide protected result indications. This ensures that > > the peer and server are aware of each other's final access > > decision, and prevents lengthy timeouts. > > > > For example, within EAP-TLS [RFC2716], the peer > > always authenticates the server, and sends a TLS alert > > message in the event of an authentication or authorization > > failure. If the server does not receive a TLS alert message > > from the peer and the peer continues the conversation to > > completion (e.g. sends a FINISHED message), then the server > > can assume that the peer will accept access if granted it by > > the server. > > > > Similarly, the peer can assume that the server will grant > > access if it does not receive a TLS alert message from the > > server, and the server carries the conversation to completion > > (e.g. sends a FINISHED message). > > > > [Joe] does this also hold true in the case of TLS session resume? In > session resume the server sends the finished message before the client > which is opposite of the full handshake. In the session resume case the > peer is in a state where it may accept a TLS-Alert or an EAP-Success. I think that whenever TLS session resumption is performed there is an implication that both the client and server agree on the same access policy that was agreed during the initial authentication with a TLS full handshake. Based on this, it seems to me that there is no reason for both entities to send a TLS-Alert message during TLS session resumption procedure to indicate a problem in access policy. If there is a possibility of denying/changing the previous access policy, TLS sesion resumption procedure should not be performed and TLS full handshake should be performed instead. Yoshihiro Ohba > > > > A server may use the "access denied" TLS alert > > after successfully authenticating the peer to indicate that a > > valid certificate was received from the peer, but when access > > control was applied, the server decided not to proceed." > > In Section 7.10, change the first paragraph from: > > > > "It is possible for the peer and EAP server to mutually > > authenticate and derive keys. In order to provide keying > > material for use in a subsequently negotiated ciphersuite, an > > EAP method supporting key derivation MUST export a Master > > Session Key (MSK) of at least 64 octets, and an Extended > > Master Session Key (EMSK) of at least 64 octets. EAP Methods > > deriving keys MUST provide for mutual authentication between > > the EAP peer and the EAP Server." > > > > To: > > > > "It is possible for the peer and EAP server to mutually > > authenticate and derive keys. In order to provide keying > > material for use in a subsequently negotiated ciphersuite, an > > EAP method supporting key derivation MUST export a Master > > Session Key (MSK) of at least 64 octets, and an Extended > > Master Session Key (EMSK) of at least 64 octets. > > > > EAP Methods supporting key derivation MUST also support > > mutual authentication between the EAP peer and the EAP > > Server. EAP Methods supporting mutual authentication MUST > > also support key derivation and protected result indications." > > > > [Joe] It seems that this disallows authenticated servers and anonymous > clients. I'm not sure that this is a good idea. The MUST for protected > result indications seems to be a big change. Given the above it appears > that EAP-TLS does not meet protected result indications in all cases. > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 12:36:00 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13396 for ; Fri, 9 Jan 2004 11:49:40 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 907C2201ED; Wed, 7 Jan 2004 10:07:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 54155201EC for ; Wed, 7 Jan 2004 10:06:59 -0500 (EST) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 07 Jan 2004 11:23:56 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i07JGBVM004217; Wed, 7 Jan 2004 11:16:11 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.115.90]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 7 Jan 2004 11:21:48 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" , Cc: Subject: RE: [eap] Proposed Resolution to Issue 209: Applicability statement Message-ID: <006701c3d552$b5bd1c10$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 07 Jan 2004 19:21:48.0846 (UTC) FILETIME=[7F2244E0:01C3D553] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 7 Jan 2004 11:16:10 -0800 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Bernard Aboba > Sent: Tuesday, December 23, 2003 5:03 PM > To: eap@frascone.com > Cc: mankin@psg.com > Subject: [eap] Proposed Resolution to Issue 209: > Applicability statement > > > The text of Issue 209 is enclosed below. The proposed > resolution is as > follows: > > "1.3 Applicability > > EAP was designed for use in network access authentication, > where IP layer connectivity may not be available. Use of EAP > for other purposes, such as application layer authentication, > or bulk data transport, is NOT RECOMMENDED. > [Joe] So why is EAP not recommended for application layer authentication? I think it would be useful to state more clearly why since many of the requirements for authentication would be the same. The main difference between EAP and something like SASL, GSSAPI and TLS is that EAP does not provide security services or a security layer, it just provides a key material for an existing security layer. I suggest change the above to something like: "EAP was designed for the use in network access authentication, where IP layer connectivity may not be available. EAP also assumes the existence of a security layer to provide on going data protection such as layer 2 encryption. EAP may provide keying material for this external security layer. It is NOT RECOMMENDED that EAP be used in scenarios where an external security layer is not provided such as most application layer protocols. The use of EAP for bulk data transport is also NOT RECOMMENDED." > Since EAP does not require IP connectivity, it provides just > enough support for the reliable transport of authentication > protocols, and no more. > > EAP is a lock-step protocol which only supports a single > packet in flight. As a result EAP cannot efficiently > transport large quantities of data, unlike transport > protocols such as TCP [RFC793] or SCTP [RFC2960]. > > While EAP provides support for retransmission, it assumes > ordering guarantees provided by the lower layer, so that out > of order reception is not supported. > > Since EAP does not support fragmentation and reassembly, > EAP authentication methods generating payloads larger than > the minimum EAP MTU need to provide fragmentation support. > > While authentication methods such as EAP-TLS [RFC2716] > provide support for fragmentation and reassembly, the EAP > methods defined in this document do not. As a result, if the > EAP packet size exceeds the EAP MTU of the link, these > methods will encounter difficulties. > > EAP authentication is initiated by the server > (authenticator), whereas many authentication protocols are > initiated by the client (peer). As a result, it may be > necessary for an authentication algorithm to add one or two > additional messages (at most one roundtrip) in order to run over EAP. > > Where certificate-based authentication is supported, the > number of additional roundtrips may be much larger due to > fragmentation of certificate chains. In general, a fragmented > EAP packet will require as many round-trips to send as there > are fragments. For example, a certificate chain 14960 octets > in size would require ten round-trips to send with a 1496 > octet EAP MTU. > > Where EAP runs over a lower layer in which significant packet > loss is experienced, or where the connection between the > authenticator and authentication server experiences > significant packet loss, EAP methods requiring many > round-trips can experience difficulties. In these situations, > use of EAP methods with fewer roundtrips is advisable." > > -------------------------------------------------------------- > --------- > Issue 209: Applicability statement > Submitter name: Allison Mankin > Submitter email address: mankin@psg.com > Date first submitted: 12/17/2003 > Reference: > Document: RFC 2284bis-07 > Comment type: E > Priority: S > Section: Various > Rationale/Explanation of issue: > > I think there are many virtues to this spec, but it needs > more attention to the applicability description. The problem > is epitomized by comments such > as: > > Where transport efficiency is a consideration, and IP transport is > available, it may be preferable to expose an artificially high EAP > MTU to EAP and allow fragmentation to take place in IP. > Alternatively, it is possible to choose other security mechanisms > such as TLS [RFC2246] or IKE [RFC2409] or an alternative > authentication framework such as SASL [RFC2222] or GSS-API > [RFC2743]. > > How could the same application use GSS-API or SASL if it > intended to use EAP > > They seem to have very different domains of applicability. > It would be good to discuss the ways that EAP is very > applicable and ways in which it can be kind of wedged into > use, with results that may be only just satisfactory. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 12:36:01 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13176 for ; Fri, 9 Jan 2004 11:49:34 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B150F2022F; Tue, 6 Jan 2004 12:49:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id D670B201F4 for ; Tue, 6 Jan 2004 12:48:04 -0500 (EST) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 06 Jan 2004 21:57:32 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id i06LvGQu002510; Tue, 6 Jan 2004 13:57:16 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.96.169]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 6 Jan 2004 14:02:53 -0800 From: "Joseph Salowey" To: "'Yoshihiro Ohba'" Cc: "'Bernard Aboba'" , Subject: RE: [eap] Revised Proposed Resolution to Issue 207: Miscellaneous Comments Message-ID: <00ee01c3d4a0$0c0d7410$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <20040106205219.GL5444@steelhead> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 06 Jan 2004 22:02:53.0627 (UTC) FILETIME=[D56110B0:01C3D4A0] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 6 Jan 2004 13:57:14 -0800 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Tuesday, January 06, 2004 12:52 PM > To: Joseph Salowey > Cc: 'Bernard Aboba'; eap@frascone.com > Subject: Re: [eap] Revised Proposed Resolution to Issue 207: > Miscellaneous Comments > > > On Mon, Jan 05, 2004 at 09:59:44AM -0800, Joseph Salowey wrote: > > > > > > > In Section 4.2, 7th paragraph, change: > > > > > > " A mutually authenticating method (such as EAP-TLS > > > [RFC2716]) that provides authorization error messages > > > provides protected result indications for the purpose of this > > > specification. Within EAP-TLS, the peer always authenticates > > > the authenticator, and may send a TLS-alert message in the > > > event of an authentication failure. An authenticator may use > > > the "access denied" TLS alert after successfully > > > authenticating the peer to indicate that a valid certificate > > > was received from the peer, but when access control was > > > applied, the authenticator decided not to proceed. If a > > > method provides authorization error messages, the > > > authenticator SHOULD use them so as to ensure consistency > > > with the final access decision and avoid lengthy timeouts." > > > > > > To: > > > > > > "A mutually authenticating method may use error messages > > > to provide protected result indications. This ensures that > > > the peer and server are aware of each other's final access > > > decision, and prevents lengthy timeouts. > > > > > > For example, within EAP-TLS [RFC2716], the peer > > > always authenticates the server, and sends a TLS alert > > > message in the event of an authentication or authorization > > > failure. If the server does not receive a TLS alert message > > > from the peer and the peer continues the conversation to > > > completion (e.g. sends a FINISHED message), then the server > > > can assume that the peer will accept access if granted it by > > > the server. > > > > > > Similarly, the peer can assume that the server will grant > > > access if it does not receive a TLS alert message from the > > > server, and the server carries the conversation to completion > > > (e.g. sends a FINISHED message). > > > > > > > [Joe] does this also hold true in the case of TLS session > resume? In > > session resume the server sends the finished message before > the client > > which is opposite of the full handshake. In the session > resume case > > the peer is in a state where it may accept a TLS-Alert or > an EAP-Success. > > I think that whenever TLS session resumption is performed > there is an implication that both the client and server agree > on the same access policy that was agreed during the initial > authentication with a TLS full handshake. Based on this, it > seems to me that there is no reason for both entities to send > a TLS-Alert message during TLS session resumption procedure > to indicate a problem in access policy. If there is a > possibility of denying/changing the previous access policy, > TLS sesion resumption procedure should not be performed and > TLS full handshake should be performed instead. > [Joe] What I am referring to is not access policy. The situation is that the peer is in a state where it may accept either a EAP-Succes or an TLS-faliure. SO in this case there does not appear to be a protected-result-indicator for server success. There may be one for server failure, but it is probably that the keys won't match and you wouldn't be able to verify a failure message. In addition since the protocol is considered complete it is possible that a failure message could be removed/added/modified without the peer knowing. > Yoshihiro Ohba > > > > > > > > A server may use the "access denied" TLS alert > > > after successfully authenticating the peer to indicate that a > > > valid certificate was received from the peer, but when access > > > control was applied, the server decided not to proceed." > > > In Section 7.10, change the first paragraph from: > > > > > > "It is possible for the peer and EAP server to mutually > > > authenticate and derive keys. In order to provide keying > > > material for use in a subsequently negotiated ciphersuite, an > > > EAP method supporting key derivation MUST export a Master > > > Session Key (MSK) of at least 64 octets, and an Extended > > > Master Session Key (EMSK) of at least 64 octets. EAP Methods > > > deriving keys MUST provide for mutual authentication between > > > the EAP peer and the EAP Server." > > > > > > To: > > > > > > "It is possible for the peer and EAP server to mutually > > > authenticate and derive keys. In order to provide keying > > > material for use in a subsequently negotiated ciphersuite, an > > > EAP method supporting key derivation MUST export a Master > > > Session Key (MSK) of at least 64 octets, and an Extended > > > Master Session Key (EMSK) of at least 64 octets. > > > > > > EAP Methods supporting key derivation MUST also support > > > mutual authentication between the EAP peer and the EAP > > > Server. EAP Methods supporting mutual authentication MUST > > > also support key derivation and protected result indications." > > > > > > > [Joe] It seems that this disallows authenticated servers > and anonymous > > clients. I'm not sure that this is a good idea. The MUST for > > protected result indications seems to be a big change. Given the > > above it appears that EAP-TLS does not meet protected result > > indications in all cases. > > > > > > > _______________________________________________ > > > eap mailing list > > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 12:36:02 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13212 for ; Fri, 9 Jan 2004 11:49:35 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 18E382020E; Mon, 5 Jan 2004 07:17:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id DE3322020A for ; Mon, 5 Jan 2004 07:17:00 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id C24596A903; Mon, 5 Jan 2004 18:26:11 +0200 (EET) Message-ID: <3FF98FDA.60007@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Watson Cc: "'eap@frascone.com'" Subject: Re: [eap] network discovery & selection: problem definition References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 05 Jan 2004 18:24:58 +0200 Content-Transfer-Encoding: 7bit (I am summarizing the network discovery discussion, and responding to a couple of old e-mails in the process. Pardon me for the delay.) Mark Watson wrote: > > o Ability of the client to know which of his multiple > > home networks are available from a given access? > > Can I get to jari.arkko@ericsson.com, or only to > > jarkko@piuha.net? > > Interesting question. This is not a requirement that 3GPP have > discussed, since a given user identity (IMSI) is associated with a > single Home Network. > > Bu I wonder if this problem is in fact a sub-problem of the 'AAA > intermediary selection' problem when you consider: > a) The AAA server in the WLAN does not know whether the 'next hop' AAA > servers that the user requsts routing to is in fact an intermediaries or > a home network for this user. The WLAN owner just knows that they have > an agreement with this other network which allows them to be paid for > users authenticated by that route - this is all they care about. Yes, you could classify this as a sub-problem of the AAA intermediary selection -- particularly if "identifier" includes also the desired intermediate networks. > I think in the short/medium term we will be staying with statically > configured routing tables just because these tables represent not just I agree. > message routing but business relationships between the various AAA > entities. If my AAA server is configured to believe Authentication > success messages returning from a someone elses AAA server then I assume > I must have some business relationship with that other person which covers: > > (i) the effectiveness of the authentication scheme they use > (ii) a commitment to pay for the access used by the people they > authenticate > > [mayby (i) is their problem, not mine] > > It would be difficult to create a system for dynamic update of routing > tables which maintained the integrity of these business relationships. While I agree that static tables are more or less sufficient, and will be the only available tools for some time, I'm not sure I agree that the business relationship is an issue. Presumably, you could develop a routing protocol to provide a "network-level" AAA routing table, based on the "link level connectivity" information i.e. the business relationships. Access network A has a path to home network H if and only if for every component X->Y of the path there exists a manually configured business relationship from X to Y. > > Question: what are the security requirements for > > this? This is bordering on solution space, but as > > far as I know, none of the proposed mechanisms > > can support secure advertisements or secure > > selection indications. Is this acceptable? > > It should be possible for the user/Home network to verify that the > request was indeed routed through the user's choice of intermediary. This may be very hard given the current protocols. At least the user is typically not told about the path that the AAA packets took, perhaps this would be easier for the home network to verify. But the home network on the other hand has no secure information about the hints that the user provided. > As for 'securing' network advertisements (including SSIDs etc.) then I'm > not sure what this means. The user has no prior relationship with the > access network - even if I could be sure that an access network claiming > to be 'Joe's access network' really does have that name and that the > advertisement has not been modified by anybody else, I am no better off > because I do not know if I can trust Joe at all. Yes. This has significance only if you know Joe. I think Michael and others who argued for secure network advertisements would like to enable that you can indeed check the advertisements *if* you know Joe, but not require that everyone knows Joe. > A 'rouge' access point might be able to attract authentication attempts > with false advertisements, but if they have no relationship with a > 'real' intermediary, then they will not be able to provide any service. > If they do have a relationship with a 'real' intermediary then their > false advertisement will presumably be in breach of that agreement or > their agreement with another intermediary. > > For example, access networks have an incentive to include false > information in the advertisement which directs users to the intermediary > that is most lucrative for the access network. This presumably involves > including false information about intermediaries which are cheaper for > the user, or omitting that information altogether. The cheaper > intermediary will not be happy about this, but as for whether we should > include mechanisms to help them discover such fraudulent activity, I am > not sure. Some of these issues are really hard, and would be best left to non-protocol means, such as careful users and network monitoring. But having some tools for the users to verify claims would make it easier to be a "careful user". > So, I would suggest we restrict our requirements to verifying that the > intermediary used was the one requested by the user. Uh.... this may be the hardest requirement. I would actually just assume all of the information is just hints, and then provide an optional (and later published) mechanism for verifying claims made by access points. > > An interesting twist in the AAA routing problem > > is that all the above has to work for requests, responses, > > as well as server-initiated messages. > > > > I had assumed that once the intial request was sent, this estalishes > some kind of 'session state' in the AAA devices so that all subsequent > messages related to that initial request follow the same path. Is this > not correct ? Do some intemediaries operate in a completely stateless > fashion ? There is a desire to keep intermediaries stateless, or at least not require that all of them keep state. > > The network discovery and selection problem is closely > > related to the problem of access point discovery and > > selection in wireless networks. The two problems coincide > > when each access point offers exactly one network over > > one AAA route. However, the network discovery and selection > > problem may exist even where there is just one access point > > to attach to, if it offers multiple networks or multiple > > routes to these networks. > > > > During the discussion of solutions for these problems, > > it has become apparent that there are some additional > > constraints that may have to be placed on solutions. Some of > > the possible constraints are listed below: > > > > o Solution can be adopted for the whole network > > without requiring changes to the largest base > > of installed devices -- access points and > > clients. > > > > Not sure how we could introduce intermediate selection without impacting > the clients. For 3GPP, anyway, client impacts are assumed because at > least we have to implement EAP-SIM/AKA. Yes, but this is orthogonal to the issue of network selection. > Do you mean that any solution should be backwards compatible with > existing clients ? i.e. existing clients can still be supported on a > network which also provides advertisements and allows intermediary > selection. That would seem essential. Yes. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 12:36:02 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13180 for ; Fri, 9 Jan 2004 11:49:34 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EB8242022B; Tue, 6 Jan 2004 12:07:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 1B25C201F4 for ; Tue, 6 Jan 2004 12:06:51 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i06LVjq19493 for ; Tue, 6 Jan 2004 13:31:45 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Proposed resolution of Issue 212: Protected Result Indications Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 6 Jan 2004 13:31:45 -0800 (PST) The text of Issue 212 is enclosed below. The proposed resolution is as follows: In Section 4.2, 7th paragraph, delete: " A mutually authenticating method (such as EAP-TLS [RFC2716]) that provides authorization error messages provides protected result indications for the purpose of this specification. Within EAP-TLS, the peer always authenticates the authenticator, and may send a TLS-alert message in the event of an authentication failure. An authenticator may use the "access denied" TLS alert after successfully authenticating the peer to indicate that a valid certificate was received from the peer, but when access control was applied, the authenticator decided not to proceed. If a method provides authorization error messages, the authenticator SHOULD use them so as to ensure consistency with the final access decision and avoid lengthy timeouts." In Section 7.2.1, change: " Protected result indications The ability within a method for the authenticator to indicate to the peer whether it has successfully authenticated to it, and for the peer to acknowledge receipt of that indication as well as indicating to the authenticator whether it has successfully authenticated to the peer. Since EAP Success and Failure packets are neither acknowledged nor integrity protected, this claim requires implementation of a method-specific result exchange that is authenticated, integrity and replay protected on a per-packet basis." To: "Protected result indications The ability within a method for the authenticator to indicate to the peer whether it has successfully authenticated to it, and for the peer to acknowledge receipt of that indication as well as indicating to the authenticator whether it has successfully authenticated to the peer. This claim requires implication of a method-specific result exchange that is authenticated, integrity and replay protected on a per-packet basis. Since this requires a key, methods making this claim need only protect result indications sent after a key has been derived. See Section 7.16 for details." In Section 2.4, change: " For example, EAP-TLS [RFC2716] is a client-server protocol with a different certificate profile for the client and server. This implies that a host supporting peer-to-peer authentication with EAP-TLS would need to implement both the EAP peer and authenticator layers; support both peer and authenticator roles in the EAP-TLS implementation; and provision two distinct certificates, one appropriate for each role." To: "For example, EAP-TLS [RFC2716] is a client-server protocol in which distinct certificate profiles are typically utilized for the client and server. This implies that a host supporting peer-to-peer authentication with EAP-TLS would need to implement both the EAP peer and authenticator layers; support both peer and authenticator roles in the EAP-TLS implementation; and provision certificates appropriate for each role." In Section 2.4, change: " [3] Peer policy satisfaction. EAP methods may support protected result indications, enabling the peer to indicate to the EAP server that it successfully authenticated the EAP server. However, a pass-through authenticator will not be aware that the peer has accepted the credentials offered by the EAP server, unless this information is provided to the authenticator via the AAA protocol. As a result, two authentications, one in each direction, may still be needed. It is also possible that the EAP peer's access policy was not satisfied during the EAP method exchange. For example, the authenticator may not have successfully authenticated to the peer, or may not have demonstrated authorization to act in both peer and server roles. For example, in EAP-TLS [RFC2716], the authenticator may have authenticated using a valid TLS server certificate, but not using a valid TLS client certificate. As a result, the peer may require an additional authentication in the reverse direction, even if the peer provided a protected result indication to the EAP server indicating that the server had successfully authenticated to it." To: "[3] Peer policy satisfaction. EAP methods may support protected result indications, enabling the peer to indicate to the EAP server within the method that it successfully authenticated the EAP server, as well as for the server to indicate that it has authenticated the peer. However, a pass-through authenticator will not be aware that the peer has accepted the credentials offered by the EAP server unless this information is provided to the authenticator via the AAA protocol. The authenticator SHOULD interpret the receipt of a key attribute within an Accept packet as an indication that the peer has successfully authenticated the server. However, it is possible that the EAP peer's access policy was not satisfied during the initial EAP exchange, even though mutual authentication occurred. For example, the EAP authenticator may not have demonstrated authorization to act in both peer and authenticator roles. As a result, the peer may require an additional authentication in the reverse direction, even if the peer provided an indication that the EAP server had successfully authenticated to it." Add Section 7.16: "7.16 Protected Result Indications EAP Success and Failure packets are neither acknowledged nor integrity protected. This creates a potential vulnerability to spoofing, as well as lengthy timeouts. To address this vulnerability, EAP methods may implement protected result indications. Since protected result indications require use of a key for per-packet authentication and integrity protection, methods supporting protected result indications MUST also support key derivation and mutual authentication. Result indications may be implicit or explicit. For example, a method may use error messages in order to explicitly indicate a failure, while the completion of mutual authentication and key derivation without an error message implicitly indicates a successful result. For example, within EAP-TLS [RFC2716], the peer always authenticates the server, and sends a TLS alert message in the event of an authentication or authorization failure. If the server does not receive a TLS alert message from the peer and the peer continues the conversation to completion (e.g. sends a FINISHED message), then the server can assume that the peer will accept access if granted it by the server. Similarly, the peer can assume that the server will grant access if it does not receive a TLS alert message from the server, and the server carries the conversation to completion (e.g. sends a FINISHED message). A server may use the "access denied" TLS alert after successfully authenticating the peer to indicate that a valid certificate was received from the peer, but when access control was applied, the server decided not to proceed." -------------------------------------------------------------------------- Issue 212: Protected Result Indications Submitter name: Russ Housley Submitter email address: housley@vigilsec.com Date first submitted: 12/15/2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-December/002003.html Document: RFC 2284bis-07 Comment type: T Priority: S Section: 4.2 Rationale/Explanation of issue: In section 4.2, 7th paragraph at the top of page 25, 1st sentence, I cannot figure out what the sentence means: "A mutually authenticating method (such as EAP-TLS [RFC2716]) that provides authorization error messages provides protected result indications for the purpose of this specification." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 12:36:03 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13400 for ; Fri, 9 Jan 2004 11:49:40 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 252D12024E; Wed, 7 Jan 2004 11:52:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from struggle.mr.itd.umich.edu (struggle.mr.itd.umich.edu [141.211.14.79]) by mail.frascone.com (Postfix) with ESMTP id F00712015D for ; Wed, 7 Jan 2004 11:51:58 -0500 (EST) Received: from dhcp60-09.merit.edu (dhcp60-09.merit.edu [198.108.60.209]) by struggle.mr.itd.umich.edu (smtp) with ESMTP id i07L1CLk029880; Wed, 7 Jan 2004 16:01:13 -0500 From: John Vollbrecht To: Yoshihiro Ohba , Bernard Aboba Cc: eap@frascone.com, stds-802-1@ieee.org Subject: Re: [eap] Re: [802.1] Re: 802.1X interface variable Message-ID: <4243028.1073491269@dhcp60-09.merit.edu> In-Reply-To: <20040102224444.GA20443@steelhead> References: <20040102114802.16228.13985.Mailman@xavier> <20040102224444.GA20443@steelhead> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 07 Jan 2004 16:01:09 -0500 Content-Transfer-Encoding: 7bit I have some question about the cases. See below - --On Friday, January 2, 2004 2:44 PM -0800 Yoshihiro Ohba wrote: > I agree with Bernard. Please see my further comments in line. > > On Fri, Jan 02, 2004 at 10:50:01AM -0800, Bernard Aboba wrote: > > > > > I agree that overloading the AAA delivery to indicate satisfaction of > > > both authenticator and peer policies should work in most cases, but > > > there are two (2) cases/issues that concern me: > > > > > 1. This presumes the EAP method being utilized can produce a key. Does > > > 2284bis now require only EAP methods that produce keys? Is EAP-MD5 > > > deprecated? > > > > > 2. The definition of 'policy' may go beyond the current EAP method. > > > > I think point #1 is related to the difference between protected result > > indications and mutual authentication/key derivation. It has been > > claimed that running a mutually authenticating method that derives keys > > does not provide protected result indications, but I believe that in > > practice this is a distinction without a difference for a properly > > designed method. > > I agree. > > In my analysis, there there are logically four cases: > > (A) One-way authentication without key derivation (e.g., MD5-Challenge) > (B) One-way authentication with key derivation > (C) Mutual authentication without key derivation > (D) Mutual authentication with key derivation > > Case A) does not provide protected method indication and thus the > authentication server cannot securely know whether the peer is > satisfied. So, defining a new AAA attribute does not provide useful > information to the pass-through authenticator. is the assumption then that if there is no key that there is no mutual authentication? Does this overload the key to mean that mutual authentication occurred? Or can I only make a decision about whether I have a key? > > With regard to Case B), the GUEST scenario using TLS with server auth > only as mentioned by Bernard is an example of this case, and I agree > with Bernard saying that this would be dangerous. I even think that > giving keys to unauthenticated peers is almost equivalent to providing > unauthenticated access without any per-packet protection, and the key > derivation does not seem to be a useful feature in Case B). > I thought that the key would allow secure connection over the air. This seems useful to me. Am I missing something here? Certainly I can provide access to a walled garden and then require authentication to get out. > Case C) would allow a rogue NAS between the peer and the real NAS to > redirect traffic to the attacker's network immediately after > successful mutual authentication and the peer will not notice the > attack because there is no security association between the peer and > real NAS. This makes me think that defining a new AAA attribute does > not provide useful information. > I think this is correct, except if there is an authorization the other direction it might provide a key. Is there a man in the middle attack if there are two authorizations, one of which provides a key and the other does not? > So, I think a properly designed method should always belong to case > D). > does this mean an Authenticator should only call a properly designed method for what it does? i.e. it should call MD5 if that is ok and TLS if that is required? Presumably a return of key and success would not be enough unless it came from a "well designed" method. > > > > In order to clarify this point (which was raised in EAP Issue 207), the > > proposed resolution was to add the following text to Section 4.2: > > > > "If a mutually authenticating method supports error messages, > > then the peer and server SHOULD use them to provide > > protected result indications. This ensures that the peer > > and server are aware of each other's final access decision, > > and prevents lengthy timeouts. > > > > For example, within EAP-TLS [RFC2716], the peer > > always authenticates the server, and sends a TLS alert message > > in the event of an authentication or authorization failure. > > If the server does not receive a TLS alert message from the > > peer and the peer continues the conversation > > to completion (e.g. sends a FINISHED message), > > then the server can assume that the peer > > will accept access if granted it by the server. > > > > Similarly, the peer can assume that the server will grant > > access if it does not receive a TLS alert message from the > > server, and the server carries the conversation to completion > > (e.g. sends a FINISHED message). > > > > A server may use the "access denied" TLS alert > > after successfully authenticating the peer to indicate that a > > valid certificate was received from the peer, but when access > > control was applied, the server decided not to proceed." > > > > The implication here is that methods that provide mutual > > authentication and key derivation as well as error messages also provide > > protected result indications. The absence of an error message, > > taken in concert with successful key derivation and mutual > > authentication, should be taken as an implication that both sides are > > satisfied. > > > > > As long as the key is only transported along with the Access-Accept > > (never an Access-Reject), for such a method, there is no need for an > > additional AAA variable; the presence of the key attribute provides the > > same information. > > I guess an accept and a key would indicate that the remote Authorization Server was happy with the result - but not necessarily that the Authorization Server had authenticated the peer? > > Should we require that all methods providing key derivation also > > provide mutual authentication and error messages? If we do this, then > > all methods providing key derivation will automatically provide > > protected result indications, and we can dispense with the additional > > AAA attribute. > > > > There may be scenarios in which a key is derived, but there is no mutual > > authentication (e.g. GUEST scenarios using TLS with server auth only). > > In such situations it would be dangerous for the authenticator to > > conclude that the peer is satisfied because a key attribute was sent; > > it may not be. > > true. the peer may now know the authenticator, but the peer may want the authenticator to know the peer as well. This seems possible in net to net connections where a rule for both sides is that each knows the other. > > On point #2, while RFC 2284bis only permits a single EAP authentication > > method in one direction, it does allow another EAP authentication to be > > run in the other direction. As discussed in Section 2.4, there may be > > a number of reasons why an authentication may need to be run in the > > other direction, even though a method providing protected result > > indications has already been run in the other direction. > > in > > has already been run. > > > > Section 2.4 describes 3 additional factors: support for bi-directional > > session key derivation in the lower layer, support for tie-breaking and > > peer policy satisfaction. > > > > None of these factors are taken into account either by proposed AAA > > attribute (which really only provides the authenticator with the > > information provided in the peer's protected result indication). > I may be wrong, but I think the attribute is meant to provide information to 802.1X that it will use to implement policy. > I agree. It seems that point #2 is purely an issue of IEEE 802.1X, > and there might be no need to change RFC2284bis, EAP state machine and > AAA protocols. > I also think point 2 is an 802.1X issue having to do with 802.1X connection rules. The proposal seems to impley that 802.1X ports may require certain authentication/ authorization rules to be satisfied. It may run authorizations in one or both directions to try to get the rules satisfied. -- John _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 12:36:05 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13181 for ; Fri, 9 Jan 2004 11:49:34 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EFECC20219; Mon, 5 Jan 2004 12:06:02 -0500 (EST) Delivered-To: eap@frascone.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id 1978C20216 for ; Mon, 5 Jan 2004 12:05:10 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i05LEM608866 for ; Mon, 5 Jan 2004 23:14:22 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 5 Jan 2004 23:14:21 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 5 Jan 2004 23:14:22 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 5 Jan 2004 23:12:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <052E0C61B69C3741AFA5FE88ACC775A612235A@esebe023.ntc.nokia.com> Thread-Topic: [802.1] New EAP/802.1X interface variable proposal Thread-Index: AcPGZHtgJISycCTLThavKlAw4WalRANaMFZQ From: To: , , Cc: , X-OriginalArrivalTime: 05 Jan 2004 21:12:23.0072 (UTC) FILETIME=[9C9D5200:01C3D3D0] Subject: [eap] RE: [802.1] New EAP/802.1X interface variable proposal Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 5 Jan 2004 23:12:22 +0200 Content-Transfer-Encoding: quoted-printable Hi, I have a short question about how eapRemoteSuccess works when the port first comes operational. Let's assume that two parties are using a mutually authenticating=20 EAP method, and both parties are happy with running the method in just one direction (and don't care which direction it is). When the port comes operational, what happens? Currently it seems that both parties start both supplicant and authenticator state=20 machines, so two EAP authentications are started. Presumably, one=20 of these authentications finishes first and sets eapRemoteSuccess, and at that point, the second one can be aborted. If both directions=20 take approximately the same time to complete, we haven't really=20 avoided the run in the other direction at all... Is this the intention, or is there some way the parties can decide=20 to try one direction first? The description of eapRemoteSuccess seems to make the assumption that one direction is tried after=20 the other one, not concurrently, but I couldn't figure out how this is supposed to happen... Best regards, Pasi=20 > -----Original Message----- > From: owner-stds-802-1@majordomo.ieee.org > [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of ext > CONGDON,PAUL (HP-Roseville,ex1) > Sent: Friday, December 19, 2003 9:13 PM > To: stds-802-1@ieee.org; eap@frascone.com > Cc: Jim Burns; Tony Jeffree > Subject: [802.1] New EAP/802.1X interface variable proposal >=20 >=20 >=20 >=20 > A proposed resolution to the 802.1X/EAP interface issue=20 > related to discussions on EAP issues 204/205 and=20 > 802.1X/D7.1 Ballot comment 15 was developed Dec 5th in a=20 > phone conference with EAP team members Bernard Aboba, Jari=20 > Arkko, Nick Petroni and 802.1X team members Jim Burns, Paul=20 > Congdon and Bob Moskowitz. This memo attempts to document=20 > the proposal and solicit discussion that will lead to=20 > closure of this remaining issue for two nearly completed=20 > documents; 802.1X/D8 and RFC2284bis. >=20 > Background - The problem >=20 > The resolution of comment 15 on 802.1X/D7.1 uncovered an=20 > issue with rfc2284bis and the EAP state machine draft. =20 > Namely, the higher layer(EAP/AAA) is unable to inform the=20 > lower layer (1X) that its policy has been fully satisfied=20 > after only one role's state machine has run. This also=20 > means that it is unable to inform the lower layer that its=20 > policy will only be satisfied if the other role's state=20 > machine is run. =20 >=20 > In addition, it was discovered that a pass-thru=20 > authenticator has no way of knowing if a peer has accepted=20 > a successful mutual authentication exchange since it is=20 > unaware of any protected indications returned by that peer. =20 > In contrast a standalone authenticator can be made aware of=20 > this because the EAP session is terminated locally. =20 > Consequently pass-thru and standalone configurations behave=20 > differently and this is not allowed or appropriate. >=20 > The ability of the higher layer to inform the lower layer=20 > when its policy is satisfied can be used to eliminate the=20 > need for a subsequent authentication exchange in the=20 > opposite direction. Running two authentications in=20 > opposite directions of one another is often very difficult=20 > and not sufficient as pointed out by RFC 2284bis in section=20 > 2.4.=20 >=20 > The fix for communicating the satisfaction of policy=20 > between the higher layer and lower layer is a new interface=20 > signal. =20 >=20 > The fix to ensure that the pass-thru authenticator does not=20 > behave differently than the standalone authenticator is a=20 > new RADIUS attribute. The new RADIUS attribute is under=20 > development and will be documented in a forthcoming RFC. >=20 > The new interface signal is communicated across the AAA=20 > boundary to the EAP. The signal indicates to the layer=20 > below that the policy of the higher layer is satisfied or=20 > not. >=20 > The RADIUS attribute is used by the authentication server=20 > to inform a pass-thru authenticator of policy satisfaction=20 > so it may drive this signal. A standalone authenticator=20 > could drive this signal based upon local information. >=20 > The new interface signal is also made available at the=20 > 802.1X interface and could be used to eliminate the need to=20 > initiate a second authentication in the opposite direction. =20 > Essentially this signal could be used to either force=20 > authorize the alternate role, or activate the Supplicant=20 > Access Control With Authenticator variable if it were not=20 > already activated. As RFC 2284bis points out in 2.4 it is=20 > often neither desirable nor possible to initiate a second=20 > authentication in the opposite direction, nor is it=20 > necessary if the 1st authentication resulted in mutual=20 > authentication with protected indications (essentially what=20 > the new interface signal asserts). >=20 > It is important to note that the EAP layer, EAP methods and=20 > AAA layer run over transports other than 802.1X and this=20 > interface signal will be important for those transports as=20 > well. This new signal will also need to be a consideration=20 > for future 802.1af work. >=20 > The Proposal >=20 > The EAP state machine draft will be updated to discuss this=20 > new indication. Annex F of 802.1X documents the interface=20 > between the higher layers (EAP, EAP Methods, AAA Layer) and=20 > 802.1X. Annex F must include a definition of all signals=20 > that cross this interface. This new signal should be=20 > included in this discussion. =20 >=20 > Additionally a short description of how this signal might=20 > be used to disable reverse authentications in the special=20 > case where both authenticator and supplicant are configured=20 > and active on a port. It should reference section 2.4 of=20 > RFC 2284bis where this type of configuration is discussed=20 > for peer-to-peer scenarios. A short discussion of this may=20 > also be needed in clause 6.7. >=20 > Proposed Changes to 802.1X/D8 (subject to the editor's=20 > judgment on wording and style): >=20 > Add clause F.2.8 >=20 > F.2.8 eapRemoteSuccess >=20 > The higher layer will give this signal a value after=20 > eapSuccess is set. This signal is ignored by the lower=20 > layer if eapFail is set. If this signal is set following=20 > eapSuccess then the policy of the higher layer is=20 > completely satisfied and there is no need to carry out=20 > further authentication (no need to run the 1X authenticator=20 > machine). If this signal is reset following setting of=20 > eapSuccess then the policy of the higher layer requires=20 > that another authentication (initiated by the 1X=20 > authenticator) must occur to satisfy the policy. =20 >=20 > This variable allows the higher layer to avoid initiating a=20 > second authentication session where the system would now=20 > act as authenticator and require the coupling of two=20 > independent authentications as described in 6.7. >=20 > If eapRemoteSuccess is set then Supplicants with this=20 > indication may choose to set the AuthControlledPortControl=20 > management variable to ForceAuthorize in order to avoid=20 > initiating the subsequent authentication. If=20 > AuthControlledPortControl is set to ForceAuthorize, it must=20 > be set back to its original state if the supplicant state=20 > machine exits the authenticated state. >=20 > If eapRemoteSuccess is reset then Supplicants with this=20 > indication may choose to set the AuthControlledPortControl=20 > management variable to Auto to ensure the authenticator=20 > machine initiates the subsequent authentication. =20 >=20 > Note - Section 2.4 of RFC 2284bis describes several=20 > situations where coupling two authentications may be needed=20 > but is difficult to achieve. >=20 > Add clause F.3.10 >=20 > F.3.10 eapRemoteSuccess=20 >=20 > The higher layer will give this signal a value after=20 > eapSuccess is set. This signal is ignored by the lower=20 > layer if eapFail is set. If this signal is set following=20 > eapSuccess then the policy of the higher layer is=20 > completely satisfied and there is no need to carry out=20 > further authentication (no need to run the 1X supplicant=20 > machine). If this signal is reset following setting of=20 > eapSuccess then the policy of the higher layer requires=20 > that another authentication (initiated by the 1X=20 > supplicant) must occur to satisfy the policy. =20 >=20 > This variable allows the higher layer to avoid or require a=20 > second authentication session where the system would now=20 > act as supplicant and require the coupling of two=20 > independent authentications as described in 6.7. >=20 > If eapRemoteSuccess is set then Authenticators with this=20 > indication may choose to set the SuppControlledPortControl=20 > management variable to ForceAuthorize or alternatively=20 > activate the Supplicant Access Control With Authenticator=20 > management control. This will avoid initiating the=20 > subsequent authentication. If either variable is set, it=20 > must be set back to its original state if the authenticator=20 > state machine exits the authenticated state.=20 >=20 > If eapRemoteSuccess is reset then Authenticators with this=20 > indication may choose to set the SuppControlledPortControl=20 > management variable to Auto or alternatively deactivate the=20 > Supplicant Access Control With Authenticator management=20 > control. This will cause the supplicant state machine to=20 > initiate the subsequent authentication. =20 >=20 > Note - Section 2.4 of RFC 2284bis describes several=20 > situations where coupling two authentications may be needed=20 > but is difficult to achieve. >=20 > Comments welcome, >=20 > Paul Congdon & Jim Burns >=20 > =3D>IEEE 802.1 Email List user information: > http://www.ieee802.org/1/email-pages/ >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 12:36:05 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13286 for ; Fri, 9 Jan 2004 11:49:37 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4ABC720211; Mon, 5 Jan 2004 07:42:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 6BF572020A for ; Mon, 5 Jan 2004 07:41:40 -0500 (EST) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 05 Jan 2004 08:58:09 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id i05GonJ6003949; Mon, 5 Jan 2004 08:50:50 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.96.169]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 5 Jan 2004 08:56:25 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" Cc: Subject: RE: [eap] Issue 208: Physical Security Message-ID: <008801c3d3ac$121ecd30$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 05 Jan 2004 16:56:25.0632 (UTC) FILETIME=[DADDF200:01C3D3AC] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 5 Jan 2004 08:50:48 -0800 Content-Transfer-Encoding: 7bit The modifications look good. Thanks, Joe > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Tuesday, December 23, 2003 6:28 PM > To: Joseph Salowey > Cc: eap@frascone.com > Subject: RE: [eap] Issue 208: Physical Security > > > > [Joe] I don't think this part should be removed. You might make it > > conditional, but then we must explain when it can be > relaxed. I think > > there is some threat model in the document already that > requires this. > > I agree. In looking at the Security Considerations section > 7, it occurs to me that the role of this section is really > just to outline potential threats as well as the security > claims that address these threats. Just as the IPsec > documents do not specify when ESP/AH are to be used, or even > when IKE is required for dynamic keying, it seems > inappropriate to me for RFC 2248bis to attempt to prescribe > what kinds of EAP methods are appropriate for use in each situation. > > At IETF 56, Erik Nordmark talked about future documents which > will provide that kind of guidance, and requested that IEEE > 802.11i provide such a document for publication as an > Informational RFC, based on the liason letter of March 2003. > I think it is worth making it clear in the Section 7 that we > are relying on those future documents and therefore do not > need to provide guidance on those requirements within RFC 2284bis. > > Otherwise, it seems likely that we could become bogged down > in a never-ending applicability discussion. > > Here is my proposed resolution of Issue 208, taking this into account: > > In Section 3.1, change: > > " [3] Lower layer security. EAP assumes that lower layers > either provide physical security (e.g., wired PPP or IEEE 802 > links) or support per-packet authentication, integrity and > replay protection. EAP SHOULD NOT be used on physically > insecure links (e.g., wireless or the Internet) where > subsequent data is not protected by per-packet > authentication, integrity and replay protection." > > To: > > " [3] Lower layer security. EAP does not require > lower layers to provide security services such as > per-packet confidentiality, authentication, integrity and > replay protection. However, where these security services are > available, EAP methods supporting Key Derivation (see Section > 7.2.1) can be used to provide dynamic keying material. This > makes it possible to bind the EAP authentication to > subsequent data and protect against security threats such as > data modification, spoofing, or replay (see Section 7.1 for details)." > > In Section 3.4, change: > > " After EAP authentication is complete, the peer will > typically transmit data to the network via the authenticator. > In order to provide assurance that the peer transmitting data > is the same entity that successfully completed EAP > authentication, the lower layer needs to bind per-packet > integrity, authentication and replay protection to the > original EAP authentication, using keys derived during EAP > authentication. Alternatively, the lower layer needs to be > physically secure. Otherwise it is possible for subsequent > data traffic to be hijacked or replayed. > > As a result of these considerations, EAP SHOULD be used only > when lower layers provide physical security for data (e.g., > wired PPP or IEEE 802 links), or for insecure links, where > per-packet authentication, integrity and replay protection is > provided." > > To: > > "After EAP authentication is complete, the peer will > typically transmit data to the network via the authenticator. > It is desirable to provide assurance that the entities > transmitting data are the same ones that successfully > completed EAP authentication. To accomplish this, it is > necessary for the lower layer to provide per-packet > integrity, authentication and replay protection and to bind > these per-packet services to the keys derived during EAP > authentication. Otherwise it is possible for subsequent data > traffic to be hijacked or replayed." > > In Section 5.1, change: > > "Identity Requests and Responses are not protected, so > from a privacy perspective it is preferable for an EAP method > to include its own protected identity exchange." > > To: > > "Identity Requests and Responses are sent in cleartext, so > from a privacy perspective it is preferable for an EAP method > to include an identity exchange that supports authentication, > integrity and replay protection and confidentiality." > > Change Section 7 to: > > "7. Security Considerations > > This section defines a generic threat model and security > terms and describes the security claims section required in > EAP method specifications. > > Since the specific threats applicable to a given environment > may differ, this section only attempts to provide a general > outline of potential threats and the corresponding EAP method > security claims mitigating those threats. > > It is expected that the generic threat model and > corresponding security claims will used to define EAP method > requirements for use in specific environments. An example of > such a requirements analysis is provided in [IEEE80211iReq]." > > Add as an informative reference: > > "[IEEE80211iReq] > Kerry, S., "Input the IETF EAP Working Group on Methods and > Key Strength", IEEE 802.11 liason letter, > http://www.ietf.org/IESG/LIAISON/LS-ieee-80211.txt, March 2003." > > In Section 7.1, change: > > "On physically insecure networks, it is possible for an > attacker to gain access to the physical medium. This enables > a range of attacks, including the following:" > > To: > > "EAP was developed for use with dialup PPP [RFC1661] and was > later adapted for use in wired IEEE 802 networks [IEEE-802] > in [IEEE-802.1X]. Subsequently EAP has been proposed for use > on wireless LAN networks, and over the Internet. In all these > situations it is possible for an attacker to gain access to > the link. For example, attacks on telephone infrastructure > are documented in [DECEPTION]. > > An attacker with access to the link may carry out a number of > attacks, including:" > > In Section 7.1, change: > > "Where EAP is used over wired networks, an attacker typically > requires access to the physical infrastructure in order to > carry out these attacks. However, where EAP is used over > wireless networks, EAP packets may be forwarded by > authenticators (e.g., pre-authentication) so that the > attacker need not be within the coverage area of an > authenticator in order to carry out an attack on it or its > peers. Where EAP is used over the Internet, attacks may be > carried out at an even greater distance." > > To: > > "Depending on the lower layer, these attacks may be carried > out without requiring physical proximity. where EAP is used > over wireless networks, EAP packets may be forwarded by > authenticators (e.g., pre-authentication) so that the > attacker need not be within the coverage area of an > authenticator in order to carry out an attack on it or its > peers. Where EAP is used over the Internet, attacks may be > carried out at an even greater distance." > > In Section 7.2, delete: > > "[a] Intended use. This includes a statement of whether the > method is intended for use over a physically secure or > insecure network, as well as a statement of the applicable > lower layers." > > In Sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6 delete the > Intended Use claim. > > In Section 7.5, change: > > "In the case of PPP and IEEE 802 wired links, it is assumed > that such attacks are restricted to attackers who can gain > access to the physical link. However, where EAP is run over > physically insecure lower layers such as wireless (802.11 or > cellular) or the Internet (such as within protocols > supporting PPP, EAP or Ethernet Tunneling), this assumption > is no longer valid and the vulnerability to attack is greater. > > To protect EAP messages sent over physically insecure lower > layers, methods providing mutual authentication and key > derivation, as well as per-packet origin authentication, > integrity and replay protection SHOULD be used." > > To: > > "To protect EAP messages against modification or spoofing, > methods supporting protected ciphersuite negotiation, mutual > authentication and key derivation as well as integrity and > replay protection are recommended. See Section 7.2.1 for > definition of these security claims." > > In Section 7.6, change: > > "In order to protect against dictionary attacks, > authentication algorithms resistant to dictionary attack (as > defined in Section 7.2) SHOULD be used where EAP runs over > lower layers which are not physically secure." > > To: > > "In order to protect against dictionary attacks, > authentication methods resistant to dictionary attacks (as > defined in Section 7.2.1) are recommended." > > In Section 7.7, change: > > "With EAP methods supporting one-way authentication, such as > EAP-MD5, the peer does not authenticate the authenticator. > Where the lower layer is not physically secure (such as where > EAP runs over wireless media or the Internet), the peer is > vulnerable to a rogue authenticator. As a result, where the > lower layer is not physically secure, a method supporting > mutual authentication is RECOMMENDED." > > To: > > "With EAP methods supporting one-way authentication, such as > EAP-MD5, the peer does not authenticate the authenticator, > making the peer vulnerable to attack by a rogue > authenticator. Methods supporting mutual authentication (as > defined in Section 7.2.1) address this vulnerability." > > In Section 7.11, change: > > "As a result, as noted in Section 3.1, where EAP is used over > a physically insecure lower layer, per-packet authentication, > integrity and replay protection SHOULD be used, and > per-packet confidentiality is also recommended." > > To: > > "To protect against modification or snooping of data, it is > recommended that EAP methods supporting mutual > authentication, and key derivation (as defined by Section > 7.2.1) be used, along with a lower layers providing > per-packet confidentiality, authentication, integrity and > replay protection. " > > Change Section 7.12 to: > > "There are reliability and security issues with link > layer indications in PPP, IEEE 802 LANs and IEEE 802.11 wireless LANs: > > [a] PPP. In PPP, link layer indications such as LCP-Terminate > (a link failure indication) and NCP (a link success > indication) are not authenticated or integrity protected. > They can therefore be spoofed by an attacker with access to the link. > > [b] IEEE 802. IEEE 802.1X EAPOL-Start and EAPOL-Logoff frames > are not authenticated or integrity protected. They can > therefore be spoofed by an attacker with access to the link. > > [c] IEEE 802.11. In IEEE 802.11, link layer > indications include Disassociate and Deauthenticate frames > (link failure indications), and the first message of the > 4-way handshake (link success indication). These messages are > not authenticated or integrity protected, and although they > are not forwardable, they are spoofable by an attacker within range. > > In IEEE 802.11, IEEE 802.1X data frames may be sent as Class > 3 unicast data frames, and are therefore forwardable. This > implies that while EAPOL-Start and EAPOL-Logoff messages may > be authenticated and integrity protected, they can be spoofed > by an authenticated attacker far from the target when > "pre-authentication" is enabled. > > In IEEE 802.11 a "link down" indication is an unreliable > indication of link failure, since wireless signal strength > can come and go and may be influenced by radio frequency > interference generated by an attacker. To avoid unnecessary > resets, it is advisable to damp these indications, rather > than passing them directly to the EAP. Since EAP supports > retransmission, it is robust against transient connectivity losses." > > In Section 7.13, change: > > " [c] Where EAP is used over lower layers which are not > physically secure, after completion of the EAP conversation, > a secure association protocol SHOULD be run between the peer > and authenticator in order to provide mutual authentication; > guarantee liveness of the TSKs; provide protected ciphersuite > and capabilities negotiation; synchronize key usage." > > To: > > " [c] After completion of the EAP conversation, where lower > layer lower layer security services such as per-packet > confidentiality, authentication, integrity and replay > protection will be enabled, a secure association protocol > SHOULD be run between the peer and authenticator in order to > provide mutual authentication between the peer and > authenticator; guarantee liveness of transient session keys; > provide protected ciphersuite and capabilities negotiation > for subsequent data; and synchronize key usage." > > In Section 7.14, change: > > " EAP does not support cleartext password authentication. > This omission is intentional. Where EAP is carried over > physically insecure lower layers, including wireless LANs > [IEEE-802.11] or the Internet, use of cleartext passwords > would allow the password to be captured by an attacker with > access to the lower layer. > > Since protocols encapsulating EAP, such as RADIUS [RFC3579], > may not provide confidentiality, even where the lower layer > is physically secure, EAP frames may be subsequently > encapsulated for transport over the Internet where they may > be captured by an attacker." > > To: > > " EAP does not support cleartext password authentication. > This omission is intentional. Use of cleartext passwords > would allow the password to be captured by an attacker with > access to the link. > > Since protocols encapsulating EAP, such as RADIUS [RFC3579], > may not provide confidentiality, EAP frames may be > subsequently encapsulated for transport over the Internet > where they may be captured by an attacker." > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 15:26:17 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09629 for ; Fri, 9 Jan 2004 15:26:16 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B12CE201F5; Fri, 9 Jan 2004 14:55:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id BFAE8201ED for ; Fri, 9 Jan 2004 14:54:46 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i09KKnM21007 for ; Fri, 9 Jan 2004 12:20:49 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] RFC 2284bis strawman Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 9 Jan 2004 12:20:49 -0800 (PST) A strawman version of RFC 2284bis-08 is now available which reflects most of the changes: http://ietf.levkowetz.com/drafts/eap/rfc2284bis/draft-ietf-eap-rfc2284bis-08.j.txt Take a look at this draft and post any comments/issues to the list. Additional revs will probably be forthcoming, so look for "k", "l", etc. versions. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 15:26:17 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09630 for ; Fri, 9 Jan 2004 15:26:16 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2D73C201F0; Fri, 9 Jan 2004 14:53:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 40B4A201ED for ; Fri, 9 Jan 2004 14:52:26 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i09KIOn20857; Fri, 9 Jan 2004 12:18:24 -0800 From: Bernard Aboba To: Henrik Levkowetz Cc: jari.arkko@piuha.net, "eap@frascone.com" Subject: Re: [eap] Re: Issue 208: Editorial questions In-Reply-To: <20040109170435.28fb947b.henrik@levkowetz.com> Message-ID: References: <20040108004002.23ff24f7.henrik@levkowetz.com> <20040109021312.0ca5f30c.henrik@levkowetz.com> <3FFE4F31.3010809@piuha.net> <20040109170435.28fb947b.henrik@levkowetz.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 9 Jan 2004 12:18:24 -0800 (PST) One other small thing: "Protected success/failure:" should probably be changed to "Protected result ind.:" throughout the document, to match the term defined in 7.2.1. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 16:32:52 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17808 for ; Fri, 9 Jan 2004 16:32:50 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0A49A20202; Fri, 9 Jan 2004 16:22:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from chardonnay.local.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by mail.frascone.com (Postfix) with ESMTP id 34148201ED for ; Fri, 9 Jan 2004 16:21:45 -0500 (EST) Received: from chardonnay ([127.0.0.1] helo=chardonnay.local.levkowetz.com) by chardonnay.local.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1Af4Et-0005od-00; Fri, 09 Jan 2004 22:32:19 +0100 From: Henrik Levkowetz To: Bernard Aboba Cc: jari.arkko@piuha.net, "eap@frascone.com" Subject: Re: [eap] Re: Issue 208: Editorial questions Message-Id: <20040109223214.0755a980.henrik@levkowetz.com> In-Reply-To: References: <20040108004002.23ff24f7.henrik@levkowetz.com> <20040109021312.0ca5f30c.henrik@levkowetz.com> <3FFE4F31.3010809@piuha.net> <20040109170435.28fb947b.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Fri__9_Jan_2004_22_32_14_+0100_FjK+PdT1zyVLCC4U" Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 9 Jan 2004 22:32:14 +0100 --Signature=_Fri__9_Jan_2004_22_32_14_+0100_FjK+PdT1zyVLCC4U Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Friday 9 January 2004, Bernard Aboba wrote: > One other small thing: > > "Protected success/failure:" should probably be changed to > "Protected result ind.:" throughout the document, to match the term > defined in 7.2.1. Yes, that's appropriate. That, and the (current) resolution of issues 206, 207, 208, 209, 211 and 212 have now been applied to the draft and are available as an intermediary draft numbered -08.j at http://ietf.levkowetz.com/drafts/eap/rfc2284bis/ Henrik --Signature=_Fri__9_Jan_2004_22_32_14_+0100_FjK+PdT1zyVLCC4U Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE//x3feVhrtTJkXCMRAvqtAKCsiOY9P9weq4iLthCkokVBhNoDigCeJxET G7O1i9zCh/YfcoPCFVJsZPs= =cqlr -----END PGP SIGNATURE----- --Signature=_Fri__9_Jan_2004_22_32_14_+0100_FjK+PdT1zyVLCC4U-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 9 16:34:49 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18056 for ; Fri, 9 Jan 2004 16:34:48 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 09EEA20202; Fri, 9 Jan 2004 16:24:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id 4F031201ED for ; Fri, 9 Jan 2004 16:23:06 -0500 (EST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i09LXhN9026519; Sat, 10 Jan 2004 06:33:43 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i09LXh05003787; Sat, 10 Jan 2004 06:33:43 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id GAA03786 ; Sat, 10 Jan 2004 06:33:43 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id GAA20084; Sat, 10 Jan 2004 06:33:42 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id GAA06286; Sat, 10 Jan 2004 06:33:41 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i09LXeVj011529; Sat, 10 Jan 2004 06:33:41 +0900 (JST) Received: from steelhead ([159.119.168.121]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HR8006E3RW20S@tsbpo1.po.toshiba.co.jp>; Sat, 10 Jan 2004 06:33:40 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Af4FW-0003NI-00; Fri, 09 Jan 2004 13:32:58 -0800 From: Yoshihiro Ohba Subject: Re: [eap] Re: [802.1] Re: 802.1X interface variable In-reply-to: <4243028.1073491269@dhcp60-09.merit.edu> To: John Vollbrecht Cc: Yoshihiro Ohba , Bernard Aboba , eap@frascone.com, stds-802-1@ieee.org Message-id: <20040109213258.GB9900@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i References: <20040102114802.16228.13985.Mailman@xavier> <20040102224444.GA20443@steelhead> <4243028.1073491269@dhcp60-09.merit.edu> Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 09 Jan 2004 13:32:58 -0800 On Wed, Jan 07, 2004 at 04:01:09PM -0500, John Vollbrecht wrote: > > I have some question about the cases. See below - > > --On Friday, January 2, 2004 2:44 PM -0800 Yoshihiro Ohba > wrote: > > >(A) One-way authentication without key derivation (e.g., MD5-Challenge) > >(B) One-way authentication with key derivation > >(C) Mutual authentication without key derivation > >(D) Mutual authentication with key derivation > > > >Case A) does not provide protected method indication and thus the > >authentication server cannot securely know whether the peer is > >satisfied. So, defining a new AAA attribute does not provide useful > >information to the pass-through authenticator. > > is the assumption then that if there is no key that there is no mutual > authentication? Does this overload the key to mean that mutual > authentication occurred? Or can I only make a decision about whether I > have a key? I am not sure I understand the question, but there is certainly a case where there is mutual authentication but there is no key (derivation), which is Case C). > > > > >With regard to Case B), the GUEST scenario using TLS with server auth > >only as mentioned by Bernard is an example of this case, and I agree > >with Bernard saying that this would be dangerous. I even think that > >giving keys to unauthenticated peers is almost equivalent to providing > >unauthenticated access without any per-packet protection, and the key > >derivation does not seem to be a useful feature in Case B). > > > I thought that the key would allow secure connection over the air. This > seems useful to me. > Am I missing something here? Certainly I can provide > access to a walled garden and then require authentication to get out. If both unauthenticated and authenticated clients can equally obtain a key and establish secure connection to the NAS with using the key, it will be a threat for authenticated clients. An attacker can spoof an authenitcated client's MAC address and perform IEEE 802.11 Disassociation (which is unprotected) on the spoofed MAC address, obtain a key as a guest, and finally hijack the authenticated client's traffic by also spoofing the victim's IP address. Unless Disassociation is protected, or protected disconnect procedure is provided at a higher layer, or different access networks are used for unauthenticated and authenticated clients, giving a key to guest seems to be dangerous. Yoshihiro Ohba _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From dzrpress@bol.com.br Fri Jan 9 20:09:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02821 for ; Fri, 9 Jan 2004 20:09:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af7dQ-00023I-00 for eap-archive@ietf.org; Fri, 09 Jan 2004 20:09:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af7bU-0001rC-00 for eap-archive@ietf.org; Fri, 09 Jan 2004 20:07:53 -0500 Received: from bgp01051152bgs.southg01.mi.comcast.net ([68.43.95.196] helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1Af7ZU-0001k8-00; Fri, 09 Jan 2004 20:05:51 -0500 From: "Temas Patrulhados" To: drums-archive@ietf.org Subject: Lindenberg e o Clero "sem-microfone" ref.: esx X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Fri, 09 Jan 2004 20:05:51 -0500 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=9.3 required=5.0 tests=FORGED_MUA_EUDORA,HTML_40_50, HTML_FONT_BIG,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT,REMOVE_REMOVAL_2WORD, SUBJ_HAS_SPACES autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.1 LINES_OF_YELLING_2 BODY: 2 WHOLE LINES OF YELLING DETECTED * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.9 FORGED_MUA_EUDORA Forged mail pretending to be from Eudora

Ref.: gxc FreeAutomaticTranslator / TraductorGratuito / Retirar / SubscreverGratuitamente

Série Temas "Patrulhados" (2)

Acabemos com mais uma exclusão: o Brasil precisa ouvir a voz do Clero sem-microfone

"Por que os grupelhos contestatários, de intenso ativismo no interior da Igreja, e cuja especialidade é reivindicar todo tipo de medidas antiexclusão, não incluem na sua agenda o fim do boicote contra os sacerdotes sem-microfone?"

Adolpho Lindenberg

O destaque que, há muitos anos, a mídia vem dando aos pronunciamentos de bispos e sacerdotes (em geral ligados à CNBB), incitando as invasões de terras promovidas pelo MST, criticando indiscriminadamente a Área de Livre Comércio das Américas (ALCA), as privatizações, as multinacionais (as norte-americanas, em especial), e o plantio dos transgênicos, apresenta um inconveniente sério: tais pronunciamentos podem criar a impressão de que a maioria do Episcopado e dos setores mais responsáveis do Clero brasileiro pensa como esses prelados.

Movimentos contestatários

É contristador perceber que na vasta rede de movimentos contestatários que está sendo articulada por todo o país, a ala progressista religiosa - fruto das Comunidades de Base e da Comissão Pastoral da Terra (CPT) - se sobressai como o núcleo mais ativo e radical em suas convicções. Para esses movimentos de contestação é de fundamental importância dar a impressão de que expressam a opinião majoritária, ou pelo menos muito expressiva, do Episcopado e no Clero.

Não é verdade, necessariamente.

Uma minoria do Clero fala, a maioria está calada

A realidade profunda é bem outra. A maioria do Episcopado e do Clero, na realidade, não tem voz nem vez na grande mídia. Suas pastorais, sermões e opiniões não chegam ao grande público. Quase ninguém os conhece, só alguns paroquianos e amigos próximos, com quem compartilham confidências. Eles são os prelados e sacerdotes sem-microfone; pertencem à imensa maioria dos excluídos dos grandes meios de difusão. E muitos deles inteligentes, cultos, de expressão fácil, com reflexões que ajudariam muito à autêntica formação da opinião nacional. Até por exigência de equilíbrio na ponderação das opiniões e de equidade em relação a este setor social, eles também precisariam ser ouvidos.

Padres sem-microfone são discriminados

O grande número dos padres sem-microfone, muitas vezes, talvez na maioria esmagadora dos casos, teria reservas sérias com as invasões e depredações das propriedades agrícolas. Mas são discriminados, não são ouvidos pelo público. De nada adiantam suas advertências. Não repercutem. Estão excluídos. Para eles, não funciona a encenação publicitária aparatosa, suas opiniões são ignoradas pela grande imprensa, o que acontece por exemplo no caso de "O Grito dos Excluídos". É que, para azar deles, nem estão entre os promotores da revolução social, nem pertencem aos pequenos grupos dos privilegiados pela mídia.

Excluir a exclusão

É preciso que se inclua entre os formadores de opinião, com acesso à mídia, também os prelados e sacerdotes que hoje estão sem microfone. Por que deixá-los de fora? Por que os grupelhos contestatários, de intenso ativismo no interior da Igreja, e cuja especialidade é reivindicar todo tipo de medidas antiexclusão, não incluem na agenda já tão abrangente do "Grito dos Excluídos" também o fim do boicote contra os sacerdotes sem-microfone? Afinal de contas, não se proclamam os seus participantes em batalha contra as exclusões, pelo fim das discriminações? Ou é que umas exclusões podem existir, e são bem-vindas, e outras não? Se for assim afastam-se do que deseja o povo, pois milhões de brasileiros querem saber o que pensa o Clero sem-microfone.

Adolpho Lindenberg é autor do livro "Os católicos e a economia de mercado".

LINKS:

Lindenberg:Concordo (envie seu voto virtual, e, melhor ainda, acrescente seu comentário, caso desejar)

Lindenberg:Discordo (idem)

Lindenberg:MinhaOpinião (para enviar sua valiosa opinião, assim como sugerir a Lindenberg temas relacionados com a temática apresentada, a serem abordados em seus próximos artigos)

LINKS PARA RECEBER ARTIGOS GRATUITOS:

PaginasGratuitas (para receber gratuitamente, por e-mail, Índice e Introdução à edição brasileira do livro de Lindenberg)

GratuitamenteArtigosAnteriores / GratuitamenteProximosArtigos / GratuitamenteTodosOsArtigos

LINKS PARA ADQUIRIR O LIVRO

Lindenberg:DesejoAdquirirLivroEmPortugal (receberá por e-mail o link para adquirir o livro impresso, diretamente da Editora em Portugal; preço: E 19,45)

Lindenberg:DesejoAdquirirLivroNoBrasil (receberá por e-mail o link para adquirir o livro impresso, diretamente da Editora no Brasil, com cartão de crédito ou boleto bancário; preço: R$ 30,00 mais Correio)

LINK DE REMOÇÃO

ConstruNews:Remover

LINK PARA TOMAR CONTATO COM LINDENBERG

Lindenberg:TomarContato (também pode ligar diretamente, se desejar, ao 11- 92527873, em São Paulo)

A difusão e o conteúdo desta mensagem são de exclusiva responsabilidade da ConstruNews

 From eap-admin@frascone.com Fri Jan 9 22:01:45 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06173 for ; Fri, 9 Jan 2004 22:01:44 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A9A65201F5; Fri, 9 Jan 2004 21:51:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id 32B59201ED for ; Fri, 9 Jan 2004 21:50:47 -0500 (EST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0A31PN9029152; Sat, 10 Jan 2004 12:01:25 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0A31P8x016427; Sat, 10 Jan 2004 12:01:25 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id NAA16426 ; Sat, 10 Jan 2004 12:01:25 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id MAA01704; Sat, 10 Jan 2004 12:01:25 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id MAA24783; Sat, 10 Jan 2004 12:01:24 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0A31NVj026946; Sat, 10 Jan 2004 12:01:24 +0900 (JST) Received: from steelhead ([159.119.168.66]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HR900DJN729P8@tsbpo1.po.toshiba.co.jp>; Sat, 10 Jan 2004 12:01:22 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Af9LU-00043l-00; Fri, 09 Jan 2004 18:59:28 -0800 From: Yoshihiro Ohba Subject: Re: [eap] Re: [802.1] Re: 802.1X interface variable In-reply-to: <5974650.1073640569@pm552-11.dialip.mich.net> To: John Vollbrecht Cc: Bernard Aboba , Jari Arkko , eap@frascone.com Message-id: <20040110025928.GK1638@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i References: <5974650.1073640569@pm552-11.dialip.mich.net> Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 09 Jan 2004 18:59:28 -0800 In addition to John's point, there is another issue. Even when the authorization is performed in an EAP method and the AAA server returns access accept with a key, it is still possible that access is rejected by a AAA proxy when the authorization is performed in a distributed manner. In this case, can the peer still always expect EAP Success after protected result indication has been successfully made in the method? Yoshihiro Ohba On Fri, Jan 09, 2004 at 09:29:29AM -0500, John Vollbrecht wrote: > > >Proving mutual possession of the shared secret is enough to provide mutual > >authentication. However, there is a separate issue of authorization -- if > >mutual authentication occurs, is this enough for both sides to know that > >they are authorized? For this an authorization error message is required. > >Since authentication has occurred, this can be MAC'd. If such a message is > >supported and is not sent, then the client can know that the server will > >eventually signal Success and can silently discard EAP Failure packets. > > I am not sure it is a requirement that EAP methods provide authorization as > well as authentication. Seems they MAY, but are not required to do so. In > this circumstance the presence of a key would be sufficient to indicate the > method succeeded. I think this is what you are implying here. > > In the case where a method expects a authorization failure message then > message is part of the method, and the method will not complete unless an > authorization failure or succeed message is received. EAP Success or > Failure messages are discarded when received before a method completes. > After a method completes unexpected EAP Success/Fail messages will be > discarded. > > So is it the intention here that all methods should support authorization > in addition to authentication? I was thinking that in at least some cases > the authorization was done by the AAA protocol and Authentication by EAP. > Certainly authorization decisions can be based on rules between the NAS/AP > and the AAA Server. > > - John > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Jan 10 07:21:45 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03520 for ; Sat, 10 Jan 2004 07:21:45 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3EE582020B; Sat, 10 Jan 2004 07:11:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 8012A2020A for ; Sat, 10 Jan 2004 07:10:39 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id F071A6A902; Sat, 10 Jan 2004 14:21:17 +0200 (EET) Message-ID: <3FFFEDEF.1030001@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [eap] network selection Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 10 Jan 2004 14:19:59 +0200 Content-Transfer-Encoding: 7bit Hi, Bernard and I have put together a draft that defines the network selection problem and summarizes the discussion we had in December. Before it appears in the I-D directories, you can access it from my page at: http://www.arkko.com/publications/eap/draft-ietf-eap-netsel-problem-00.txt http://www.arkko.com/publications/eap/draft-ietf-eap-netsel-problem-00.html One of the key conclusions is that the network selection problem involves many parts, and going forward it is important that we decide which parts need to be addressed. It is also important to ensure that IETF-IEEE-3GPP do not create multiple competing solutions in this space. Comments very much appreciated. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Jan 10 13:42:15 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13535 for ; Sat, 10 Jan 2004 13:42:04 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 87F022020D; Sat, 10 Jan 2004 13:30:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mail.frascone.com (Postfix) with ESMTP id 1F41D20149 for ; Sat, 10 Jan 2004 13:29:40 -0500 (EST) Received: from [192.168.5.50] (pcp02248260pcs.radnor01.pa.comcast.net[68.81.253.120]) by comcast.net (rwcrmhc11) with SMTP id <20040110184018013005mgbre>; Sat, 10 Jan 2004 18:40:19 +0000 From: John Vollbrecht To: Yoshihiro Ohba Cc: Bernard Aboba , eap@frascone.com, stds-802-1@ieee.org Subject: Re: [eap] Re: [802.1] Re: 802.1X interface variable Message-ID: <6392011.1073742021@[192.168.5.50]> In-Reply-To: <20040109213258.GB9900@steelhead> References: <20040102114802.16228.13985.Mailman@xavier> <20040102224444.GA20443@steelhead> <4243028.1073491269@dhcp60-09.merit.edu> <20040109213258.GB9900@steelhead> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 10 Jan 2004 13:40:21 -0500 Content-Transfer-Encoding: 7bit I try to clarify the question below -- --On Friday, January 9, 2004 1:32 PM -0800 Yoshihiro Ohba wrote: > On Wed, Jan 07, 2004 at 04:01:09PM -0500, John Vollbrecht wrote: >> >> I have some question about the cases. See below - >> >> --On Friday, January 2, 2004 2:44 PM -0800 Yoshihiro Ohba >> wrote: >> >> > (A) One-way authentication without key derivation (e.g., MD5-Challenge) >> > (B) One-way authentication with key derivation >> > (C) Mutual authentication without key derivation >> > (D) Mutual authentication with key derivation >> > >> > Case A) does not provide protected method indication and thus the >> > authentication server cannot securely know whether the peer is >> > satisfied. So, defining a new AAA attribute does not provide useful >> > information to the pass-through authenticator. >> >> is the assumption then that if there is no key that there is no mutual >> authentication? Does this overload the key to mean that mutual >> authentication occurred? Or can I only make a decision about whether I >> have a key? > > I am not sure I understand the question, but there is certainly a case > where there is mutual authentication but there is no key (derivation), > which is Case C). > The question is that suppose one uses TLS host only authentication (not mutual). Is it possible for (master) keys to be derived at authenticator and peer? I think this is possible and desirable for allowing access to a walled garden environment. Am I wrong? >> >> > >> > With regard to Case B), the GUEST scenario using TLS with server auth >> > only as mentioned by Bernard is an example of this case, and I agree >> > with Bernard saying that this would be dangerous. I even think that >> > giving keys to unauthenticated peers is almost equivalent to providing >> > unauthenticated access without any per-packet protection, and the key >> > derivation does not seem to be a useful feature in Case B). >> > >> I thought that the key would allow secure connection over the air. This >> seems useful to me. >> Am I missing something here? Certainly I can provide >> access to a walled garden and then require authentication to get out. > > If both unauthenticated and authenticated clients can equally obtain a > key and establish secure connection to the NAS with using the key, it > will be a threat for authenticated clients. An attacker can spoof an > authenitcated client's MAC address and perform IEEE 802.11 > Disassociation (which is unprotected) on the spoofed MAC address, > obtain a key as a guest, and finally hijack the authenticated client's > traffic by also spoofing the victim's IP address. Unless > Disassociation is protected, or protected disconnect procedure is > provided at a higher layer, or different access networks are used for > unauthenticated and authenticated clients, giving a key to guest seems > to be dangerous. > > Yoshihiro Ohba _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Jan 10 13:46:05 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13610 for ; Sat, 10 Jan 2004 13:46:04 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AFAA72020D; Sat, 10 Jan 2004 13:34:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mail.frascone.com (Postfix) with ESMTP id EF96620149 for ; Sat, 10 Jan 2004 13:33:43 -0500 (EST) Received: from [192.168.5.50] (pcp02248260pcs.radnor01.pa.comcast.net[68.81.253.120]) by comcast.net (rwcrmhc13) with SMTP id <2004011018442201500b7j51e>; Sat, 10 Jan 2004 18:44:23 +0000 From: John Vollbrecht To: Bernard Aboba Cc: eap@frascone.com, stds-802-1@ieee.org Message-ID: <6406653.1073742265@[192.168.5.50]> In-Reply-To: References: <5973807.1073640555@pm552-11.dialip.mich.net> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [eap] Re: [802.1] Re: 802.1X interface variable Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 10 Jan 2004 13:44:26 -0500 Content-Transfer-Encoding: 7bit --On Friday, January 9, 2004 7:50 AM -0800 Bernard Aboba wrote: >> does this mean that TLS host only authorization is not going to be >> allowed? I think this is being used to allow access to walled garden >> environments. > > The TLS protocol does not support "client only" authentication. In any > case it says "support", not "use". > But does it support "host only" authentication? If so, then presumably this is not mutual authentication but does derive keys. I think this is allowed - am I wrong? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Jan 12 11:09:07 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03846 for ; Mon, 12 Jan 2004 11:09:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D1835201EC; Mon, 12 Jan 2004 10:58:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id D57D320160 for ; Mon, 12 Jan 2004 10:57:39 -0500 (EST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0CG8KN9001909; Tue, 13 Jan 2004 01:08:20 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0CG8KxX027974; Tue, 13 Jan 2004 01:08:20 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA27973 ; Tue, 13 Jan 2004 01:08:20 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA10350; Tue, 13 Jan 2004 01:08:20 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA07675; Tue, 13 Jan 2004 01:08:19 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0CG8IkL007589; Tue, 13 Jan 2004 01:08:19 +0900 (JST) Received: from steelhead ([159.119.168.172]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRD00FCVWTTHV@tsbpo1.po.toshiba.co.jp>; Tue, 13 Jan 2004 01:08:17 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AfvBs-0000SX-00; Sun, 11 Jan 2004 22:04:44 -0800 From: Yoshihiro Ohba Subject: Re: [eap] Re: [802.1] Re: 802.1X interface variable In-reply-to: <6392011.1073742021@[192.168.5.50]> To: John Vollbrecht Cc: Yoshihiro Ohba , Bernard Aboba , eap@frascone.com, stds-802-1@ieee.org Message-id: <20040112060443.GB16966@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i References: <20040102114802.16228.13985.Mailman@xavier> <20040102224444.GA20443@steelhead> <4243028.1073491269@dhcp60-09.merit.edu> <20040109213258.GB9900@steelhead> <6392011.1073742021@[192.168.5.50]> Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 11 Jan 2004 22:04:43 -0800 On Sat, Jan 10, 2004 at 01:40:21PM -0500, John Vollbrecht wrote: > > I try to clarify the question below -- > > --On Friday, January 9, 2004 1:32 PM -0800 Yoshihiro Ohba > wrote: > > >On Wed, Jan 07, 2004 at 04:01:09PM -0500, John Vollbrecht wrote: > >> > >>I have some question about the cases. See below - > >> > >>--On Friday, January 2, 2004 2:44 PM -0800 Yoshihiro Ohba > >> wrote: > >> > >>> (A) One-way authentication without key derivation (e.g., MD5-Challenge) > >>> (B) One-way authentication with key derivation > >>> (C) Mutual authentication without key derivation > >>> (D) Mutual authentication with key derivation > >>> > >>> Case A) does not provide protected method indication and thus the > >>> authentication server cannot securely know whether the peer is > >>> satisfied. So, defining a new AAA attribute does not provide useful > >>> information to the pass-through authenticator. > >> > >>is the assumption then that if there is no key that there is no mutual > >>authentication? Does this overload the key to mean that mutual > >>authentication occurred? Or can I only make a decision about whether I > >>have a key? > > > >I am not sure I understand the question, but there is certainly a case > >where there is mutual authentication but there is no key (derivation), > >which is Case C). > > > The question is that suppose one uses TLS host only authentication (not > mutual). Is it possible for (master) keys to be derived at authenticator > and peer? I think this is possible and desirable for allowing access to a > walled garden environment. Am I wrong? > That case is another form of Case C). I think host only authentication is as vulnerable to rogue NAS attack as server only authentication. How the host can know whether it is connected to the walled garden instead of the attacker's network without authenticating the server? Yoshihiro Ohba _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Jan 12 16:43:18 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23268 for ; Mon, 12 Jan 2004 16:43:17 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 11E9C201EC; Mon, 12 Jan 2004 16:32:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id C758E20160 for ; Mon, 12 Jan 2004 16:31:36 -0500 (EST) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 12 Jan 2004 22:41:47 +0100 Received: from francetelecom.com ([10.193.106.52]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Mon, 12 Jan 2004 22:41:46 +0100 Message-ID: <40031406.9090700@francetelecom.com> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jari.arkko@piuha.net Cc: eap@frascone.com Subject: Re: [eap] Identity Protection and fast-reconnect References: <3FF06767.1050006@francetelecom.com> <3FF588CD.9090304@piuha.net> In-Reply-To: <3FF588CD.9090304@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jan 2004 21:41:46.0745 (UTC) FILETIME=[E0BCB690:01C3D954] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 12 Jan 2004 13:39:18 -0800 Content-Transfer-Encoding: 7bit Hi Jari, Many thanks for your answer and sorry for the delay in my reply: a few more thoughts inline. Florent Jari Arkko wrote: > Thanks for your comments Florent. They are very useful! > Some discussion inline: > >> During my review of EAP-SIMv12 and the subsequent interactions with >> Henry Haverinen, we've come to discuss topics that seemed not to be >> EAP-SIM specific but rather general about EAP and EAP methods, hence >> this mail. >> >> Apologies in advance if it seems too EAP method oriented (out of >> scope) or useless giberrish. >> >> First thing discussed seems to be old folklore: identity protection. >> I won't get into arguing whether identity protection is a useful >> feature or not since the answer must have already been given >> somewhere, something like: being conservative is no sin in network >> security and if you don't want it, don't implement it when it is an >> optional feature. >> I also won't recall the vulnerability of most identity protection >> schemes within a "symmetric" EAP method ("asymmetric" EAP methods >> such as PEAP+? are not subject to the same vulnerability) due to the >> trade off between functionality (allowing a peer and an AAA server to >> resync) and security (allowing an active attacker to force identity >> disclosure) and the hassle of temporary identity management. > > > Yes, though, I am not sure this is a fundamental distinction. Or perhaps > its not the symmetric/asymetric difference that causes this. It would > seem > that even a symmetric method could avoid the active attackers, if both > end > points were able to "commit" to an identity. This adds some (possibly > tough) requirements on the end point implementations, but it would > prevent active attackers from going back to the original identity, > at worst the previously used temporary identity would have to be > revealed. > With group keys for identity protection, you could have a symmetric > method > and no active attacks at all, from outsiders. > I agree I oversimplified a bit but what I meant is that we have two fundamental different cases depending on the possibility to set up a protected channel before real identity exchange occurs. Using a group key (which is a good example) raises several problems: either the group is small and you offer little identity protection since belonging to the group almost reveals your identity or the group is big and then you have the group key management headache or the attacks from insiders... Anyway, this is not the WG's concern, isn't it? > > >> The second point on fast reconnect was: why provide fast reconnect >> features? Here, after re-reading EAP's latest version, I still think >> that it might be worth a little more discussion. EAP states that >> "fast reconnect" is "The ability, in the case where a security >> association has been previously established, to create a new or >> refreshed security association in a smaller number of round-trips. ". >> I guess here that this leaves aside an important motivation for fast >> reconnect which is processing power consumption: for example, with >> TLS, resuming a session might save some asymmetric cryptography >> calculations which are known to be pretty heavy. This might also be >> the case for EAP methods (eg. EAP-TLS). I also tend to think that we >> could discuss another aspect of fast reconnect which is the "depth" >> or "distance" of the round trips rather than their number (this must >> have been done somewhere else in AAA > > > I agree with all your points above. While I think that the RFC 2284bis > should not include guidance for all possible new features that one's > methods could do, it would still be good to clarify the definition > of fast reconnect. I think a better definition would be: > > Fast reconnect > The ability, in the case where a security association has > been previously established, to create a new or refreshed > security association more efficiently or in a smaller number > of round-trips. > > I'll tell Bernard and Henrik to remember this when we get to AUTH48 > on the document. Your proposed new definitions looks great to me. FMI, what is AUTH48? > >> or wherever - I hope not within EAP ;-), please feel free to mention >> your pointers, I'll go and start with reading the irtf >> aaaarch-handoff mentioned in EAPKMF after I am finished with this >> post): typically if we consider a roamer, his first authentication >> has to be forwarded by the visited AAA server to the home AAA server >> (which might be far away), but we could imagine then that the fast >> reconnect procedures could save time or money by reducing or even >> better suppressing the contacts between the peer and the home AAA >> server (for instance, the home AAA server would delegate to the >> visited AAA server some parts of - when not all - the fast reconnect >> exchanges). Some proposed EAP methods (IIRC EAP-SRP or EAP-SKE) had >> the roaming situation in mind (H-AAA and V-AAA). However, this does >> not seem to be the direction taken by the group if I understand well >> the current draft for the EAP key management framework. > > > Well, there may be a difference between allowing something vs. > providing all the tools and guidance for something. Timing-wise > it may not be possible to provide guidance on all possible fast > handoff, fast reauthentication, and other advanced designs. Particularly > when the field is under active research. However, the draft does provide > some tools and hooks that allow such things to be made later, in > other documents. For instance, the EMSK can be helpful in many of > these schemes. > > I agree about the timeliness issue and the impossibility to cater for everything hence the hooks. May I then however reformulate my remark: in the latest version of the EAP KMF (02b), the EMSK is defined in section 2.2 page 16 as "Additional keying material derived between the EAP client and server that is exported by the EAP method. The EMSK is at least 64 octets in length. The EMSK is reserved for future uses that are not defined yet and is not provided to a third party." My concern is that, as I understand the last part, not providing the EMSK to a third party precludes the interaction between the visited AAA and the home AAA I described. My recommendation would thus be: delete "and is not provided to a third party" to provide some tools to allow advanced services to be provided later. What do you reckon? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Jan 12 20:40:52 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05305 for ; Mon, 12 Jan 2004 20:40:52 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4C8B0201EC; Mon, 12 Jan 2004 20:30:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from hubble.802wirelessworld.com (f34hyatt.fairviewwireless.com [64.69.75.34]) by mail.frascone.com (Postfix) with ESMTP id 426462015F for ; Mon, 12 Jan 2004 20:29:49 -0500 (EST) Received: from [10.0.14.250] (unknown [10.0.14.250]) by hubble.802wirelessworld.com (Postfix) with ESMTP id BD02713B771; Mon, 12 Jan 2004 17:40:28 -0800 (PST) From: John Vollbrecht To: Yoshihiro Ohba Cc: Bernard Aboba , eap@frascone.com, stds-802-1@ieee.org Subject: Re: [eap] Re: [802.1] Re: 802.1X interface variable Message-ID: <6845891.1073940036@[10.0.14.250]> In-Reply-To: <20040112060443.GB16966@steelhead> References: <20040102114802.16228.13985.Mailman@xavier> <20040102224444.GA20443@steelhead> <4243028.1073491269@dhcp60-09.merit.edu><20040109213258.GB9900@steelhead> <6392011.1073742021@[192.168.5.50]> <20040112060443.GB16966@steelhead> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 12 Jan 2004 20:40:37 -0500 Content-Transfer-Encoding: 7bit --On Sunday, January 11, 2004 10:04 PM -0800 Yoshihiro Ohba wrote: > On Sat, Jan 10, 2004 at 01:40:21PM -0500, John Vollbrecht wrote: >> >> I try to clarify the question below -- >> >> --On Friday, January 9, 2004 1:32 PM -0800 Yoshihiro Ohba >> wrote: >> >> > On Wed, Jan 07, 2004 at 04:01:09PM -0500, John Vollbrecht wrote: >> >> >> >> I have some question about the cases. See below - >> >> >> >> --On Friday, January 2, 2004 2:44 PM -0800 Yoshihiro Ohba >> >> wrote: >> >> >> >>> (A) One-way authentication without key derivation (e.g., >> >>> MD5-Challenge) (B) One-way authentication with key derivation >> >>> (C) Mutual authentication without key derivation >> >>> (D) Mutual authentication with key derivation >> >>> >> >>> Case A) does not provide protected method indication and thus the >> >>> authentication server cannot securely know whether the peer is >> >>> satisfied. So, defining a new AAA attribute does not provide useful >> >>> information to the pass-through authenticator. >> >> >> >> is the assumption then that if there is no key that there is no mutual >> >> authentication? Does this overload the key to mean that mutual >> >> authentication occurred? Or can I only make a decision about whether >> >> I have a key? >> > >> > I am not sure I understand the question, but there is certainly a case >> > where there is mutual authentication but there is no key (derivation), >> > which is Case C). >> > >> The question is that suppose one uses TLS host only authentication (not >> mutual). Is it possible for (master) keys to be derived at >> authenticator and peer? I think this is possible and desirable for >> allowing access to a walled garden environment. Am I wrong? >> > > That case is another form of Case C). I think host only > authentication is as vulnerable to rogue NAS attack as server only > authentication. How the host can know whether it is connected to the > walled garden instead of the attacker's network without authenticating > the server? I think a stardard case would be to have the user authenticate the server using TLS, then authenticate some other way over the protected connection into the walled garden. For example one might setup a VPN from the client to an edge device leaving the walled garden. In this case I don't think it is necessary to do mutual authentication initially. John > Yoshihiro Ohba > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Jan 12 21:27:50 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07896 for ; Mon, 12 Jan 2004 21:27:49 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 638AC201EC; Mon, 12 Jan 2004 21:17:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id 7E84B2015F for ; Mon, 12 Jan 2004 21:16:48 -0500 (EST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0D2RVN9026996; Tue, 13 Jan 2004 11:27:31 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0D2RVvA011215; Tue, 13 Jan 2004 11:27:31 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id MAA11214 ; Tue, 13 Jan 2004 11:27:31 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id LAA05934; Tue, 13 Jan 2004 11:27:30 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id LAA01381; Tue, 13 Jan 2004 11:27:27 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0D2RQ7f024784; Tue, 13 Jan 2004 11:27:26 +0900 (JST) Received: from steelhead ([159.119.168.127]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRE003PDPGW9M@tsbpo1.po.toshiba.co.jp>; Tue, 13 Jan 2004 11:26:57 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AgEEa-0004Bu-00; Mon, 12 Jan 2004 18:24:48 -0800 From: Yoshihiro Ohba Subject: Re: [eap] Re: [802.1] Re: 802.1X interface variable In-reply-to: <6845891.1073940036@[10.0.14.250]> To: John Vollbrecht Cc: Yoshihiro Ohba , Bernard Aboba , eap@frascone.com, stds-802-1@ieee.org Message-id: <20040113022448.GA15949@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i References: <20040102114802.16228.13985.Mailman@xavier> <20040102224444.GA20443@steelhead> <4243028.1073491269@dhcp60-09.merit.edu> <20040109213258.GB9900@steelhead> <6392011.1073742021@[192.168.5.50]> <20040112060443.GB16966@steelhead> <6845891.1073940036@[10.0.14.250]> Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 12 Jan 2004 18:24:48 -0800 On Mon, Jan 12, 2004 at 08:40:37PM -0500, John Vollbrecht wrote: > >>The question is that suppose one uses TLS host only authentication (not > >>mutual). Is it possible for (master) keys to be derived at > >>authenticator and peer? I think this is possible and desirable for > >>allowing access to a walled garden environment. Am I wrong? > >> > > > >That case is another form of Case C). I think host only > >authentication is as vulnerable to rogue NAS attack as server only > >authentication. How the host can know whether it is connected to the > >walled garden instead of the attacker's network without authenticating > >the server? > > I think a stardard case would be to have the user authenticate the server > using TLS, then authenticate some other way over the protected connection > into the walled garden. For example one might setup a VPN from the > client to an edge device leaving the walled garden. In this case I don't > think it is necessary to do mutual authentication initially. As long as two one-way authentications in different directions are cryptographically bound, it is ok. But it actually forms a mutual authentication if we view the combined authentications as a unified mechanism (e.g., the EAP usage in IKEv2). Yoshihiro Ohba _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jan 13 08:00:11 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10019 for ; Tue, 13 Jan 2004 08:00:11 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6A2B4201ED; Tue, 13 Jan 2004 07:48:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from smtp2.enst.fr (enst.enst.fr [137.194.2.16]) by mail.frascone.com (Postfix) with ESMTP id 323BD201ED for ; Tue, 13 Jan 2004 07:47:53 -0500 (EST) Received: from email.enst.fr (muse.enst.fr [137.194.2.33]) by smtp2.enst.fr (Postfix) with ESMTP id AEA9553B25 for ; Tue, 13 Jan 2004 13:58:35 +0100 (CET) Received: from DELL.enst.fr (dhcp160-243.enst.fr [137.194.161.243]) by email.enst.fr (8.9.3/8.9.3) with ESMTP id NAA04434 for ; Tue, 13 Jan 2004 13:58:35 +0100 (CET) Message-Id: <5.2.1.1.0.20040113135457.0233dd70@infres.enst.fr> X-Sender: urien@infres.enst.fr X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: eap@frascone.com From: Pascal Urien Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [eap] Test Vector - Annex A - draft-haverinen-ppext-eap-sim-12.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 13 Jan 2004 13:58:06 +0100 Hi Everybody, I have written a C code that checks the test vectors expressed in annexe A of the draft-haverinen-pppext-eap-sim-12.txt document. I found the following typographic error, in A.8 Re-Authentication, page 68 the last byte (6f) of the identity value is missing. Source code is available at http://www.chez.com/urienp/eapsim.zip (for visual C tool). A small lib (eapsim.lib) contains all needed cryptographic procedures. Test results are dumped in the file result.txt. Pascal. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jan 13 08:27:55 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11530 for ; Tue, 13 Jan 2004 08:27:54 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4B0D4201EC; Tue, 13 Jan 2004 08:17:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id 533CB2015F for ; Tue, 13 Jan 2004 08:16:47 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0DDRV212531 for ; Tue, 13 Jan 2004 15:27:31 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 13 Jan 2004 15:27:30 +0200 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 13 Jan 2004 15:27:29 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 13 Jan 2004 15:27:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Test Vector - Annex A - draft-haverinen-ppext-eap-sim-12.txt Message-ID: Thread-Topic: [eap] Test Vector - Annex A - draft-haverinen-ppext-eap-sim-12.txt Thread-Index: AcPZ14PZBli2ELm9T8CSadV3yuQeqQAABfEA From: To: , X-OriginalArrivalTime: 13 Jan 2004 13:27:29.0768 (UTC) FILETIME=[FE36E680:01C3D9D8] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 13 Jan 2004 15:27:28 +0200 Content-Transfer-Encoding: quoted-printable Pascal, Thanks for the test code.=20 We have found a couple of other issues in the test vectors,=20 and we'll update the test vectors in the next draft revision. The fixes are: - wrong Identifier field in EAP-Success - last byte of EAP-Response/Identifier for re-authentication is missing, as you noted - in EAP-Request/SIM/Reauthentication, AT_PADDING should be omitted = because the plaintext is a multiple of 16 bytes - MSK and EMSK are derived incorrectly in re-authentication. K_aut and K_encr are not derived, so the key stream begins directly=20 with MSK bytes. - EAP Success in re-authentication uses a different Identifier than in full authentication, so we cannot say the EAP Success packet is similar as in full authentication=20 Best regards, Henry > -----Original Message----- > From: eap-admin@frascone.com=20 > [mailto:eap-admin@frascone.com]On Behalf Of > ext Pascal Urien > Sent: 13 January, 2004 14:58 > To: eap@frascone.com > Subject: [eap] Test Vector - Annex A - > draft-haverinen-ppext-eap-sim-12.txt >=20 >=20 > Hi Everybody, >=20 > I have written a C code that checks the test vectors=20 > expressed in annexe A > of the draft-haverinen-pppext-eap-sim-12.txt document. >=20 > I found the following typographic error, in A.8=20 > Re-Authentication, page 68 > the last byte (6f) of the identity value is missing. >=20 > Source code is available at http://www.chez.com/urienp/eapsim.zip > (for visual C tool). A small lib (eapsim.lib) contains all needed=20 > cryptographic procedures. >=20 > Test results are dumped in the file result.txt. >=20 > Pascal. >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jan 13 11:32:01 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22430 for ; Tue, 13 Jan 2004 11:32:00 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A508F201EC; Tue, 13 Jan 2004 11:21:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from hubble.802wirelessworld.com (f34hyatt.fairviewwireless.com [64.69.75.34]) by mail.frascone.com (Postfix) with ESMTP id BDAD120149 for ; Tue, 13 Jan 2004 11:20:46 -0500 (EST) Received: from [10.0.14.250] (unknown [10.0.14.250]) by hubble.802wirelessworld.com (Postfix) with ESMTP id 99DA713B8EA; Tue, 13 Jan 2004 08:31:26 -0800 (PST) From: John Vollbrecht To: Yoshihiro Ohba Cc: Bernard Aboba , eap@frascone.com, stds-802-1@ieee.org Subject: Re: [eap] Re: [802.1] Re: 802.1X interface variable Message-ID: <7021090.1073993496@[10.0.14.250]> In-Reply-To: <20040113022448.GA15949@steelhead> References: <20040102114802.16228.13985.Mailman@xavier> <20040102224444.GA20443@steelhead> <4243028.1073491269@dhcp60-09.merit.edu><20040109213258.GB9900@steelhead> <6392011.1073742021@[192.168.5.50]><20040112060443.GB16966@steelhead> <6845891.1073940036@[10.0.14.250]> <20040113022448.GA15949@steelhead> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 13 Jan 2004 11:31:36 -0500 Content-Transfer-Encoding: 7bit --On Monday, January 12, 2004 6:24 PM -0800 Yoshihiro Ohba wrote: > On Mon, Jan 12, 2004 at 08:40:37PM -0500, John Vollbrecht wrote: >> >> The question is that suppose one uses TLS host only authentication >> >> (not mutual). Is it possible for (master) keys to be derived at >> >> authenticator and peer? I think this is possible and desirable for >> >> allowing access to a walled garden environment. Am I wrong? >> >> >> > >> > That case is another form of Case C). I think host only >> > authentication is as vulnerable to rogue NAS attack as server only >> > authentication. How the host can know whether it is connected to the >> > walled garden instead of the attacker's network without authenticating >> > the server? >> >> I think a stardard case would be to have the user authenticate the >> server using TLS, then authenticate some other way over the protected >> connection into the walled garden. For example one might setup a VPN >> from the client to an edge device leaving the walled garden. In this >> case I don't think it is necessary to do mutual authentication >> initially. > > As long as two one-way authentications in different directions are > cryptographically bound, it is ok. But it actually forms a mutual > authentication if we view the combined authentications as a unified > mechanism (e.g., the EAP usage in IKEv2). > I am not sure of your meaning. Are you agreeing that the EAP authentication does not have to be mutual? Or are you thinking the second authentication would be in the same method? My thinking is that if the second authentication is done after the first has allowed attaching to the network at the walled garden, then (in this example) the first (EAP) method is not mutual. In fact, if the user does not want to leave the walled garden, then the second authentication may never be done. The walled garden provider does not care who the user is, and the user knows who the walled garden is. I think this is ok - do you agree? -- John _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jan 13 12:29:51 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27266 for ; Tue, 13 Jan 2004 12:29:50 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 51C9D2015D; Tue, 13 Jan 2004 12:19:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id 8FCD120149 for ; Tue, 13 Jan 2004 12:18:27 -0500 (EST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0DHTAN9015285; Wed, 14 Jan 2004 02:29:10 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0DHTAcb004079; Wed, 14 Jan 2004 02:29:10 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id CAA04076 ; Wed, 14 Jan 2004 02:29:10 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id CAA03974; Wed, 14 Jan 2004 02:29:10 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id CAA13809; Wed, 14 Jan 2004 02:29:09 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0DHT87f025241; Wed, 14 Jan 2004 02:29:09 +0900 (JST) Received: from steelhead ([159.119.168.127]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRF00DQUV8JV3@tsbpo1.po.toshiba.co.jp>; Wed, 14 Jan 2004 02:29:07 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AgSL0-0004aR-00; Tue, 13 Jan 2004 09:28:22 -0800 From: Yoshihiro Ohba Subject: Re: [eap] Re: [802.1] Re: 802.1X interface variable In-reply-to: <7021090.1073993496@[10.0.14.250]> To: John Vollbrecht Cc: Yoshihiro Ohba , Bernard Aboba , eap@frascone.com, stds-802-1@ieee.org Message-id: <20040113172822.GN1777@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i References: <20040102114802.16228.13985.Mailman@xavier> <20040102224444.GA20443@steelhead> <4243028.1073491269@dhcp60-09.merit.edu> <20040109213258.GB9900@steelhead> <6392011.1073742021@[192.168.5.50]> <20040112060443.GB16966@steelhead> <6845891.1073940036@[10.0.14.250]> <20040113022448.GA15949@steelhead> <7021090.1073993496@[10.0.14.250]> Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 13 Jan 2004 09:28:22 -0800 On Tue, Jan 13, 2004 at 11:31:36AM -0500, John Vollbrecht wrote: > >>I think a stardard case would be to have the user authenticate the > >>server using TLS, then authenticate some other way over the protected > >>connection into the walled garden. For example one might setup a VPN > >>from the client to an edge device leaving the walled garden. In this > >>case I don't think it is necessary to do mutual authentication > >>initially. > > > >As long as two one-way authentications in different directions are > >cryptographically bound, it is ok. But it actually forms a mutual > >authentication if we view the combined authentications as a unified > >mechanism (e.g., the EAP usage in IKEv2). > > > I am not sure of your meaning. Are you agreeing that the EAP > authentication does not have to be mutual? Or are you thinking the second > authentication would be in the same method? My thinking is that if the > second authentication is done after the first has allowed attaching to the > network at the walled garden, then (in this example) the first (EAP) method > is not mutual. > > In fact, if the user does not want to leave the walled garden, then the > second authentication may never be done. The walled garden provider does > not care who the user is, and the user knows who the walled garden is. I would agree that the EAP authentication does not have to be mutual in the considered case if the following conditions are met: o The key that is established as a result of the first (EAP) method (which is server-only, one-way authentication) should be used ONLY for protecting the (optional) second authentication signaling traffic, and NOT for protecting data traffic. (As I mentioned already, giving a key to an anonymous user for protecting data traffic can be dangerous for authenticated users in the same network and not much useful.) AND o When the second authentication (which is host-only, one-way authentication) is performed, the first and second authentications are cryptographically bound in order to prevent the known man-in-the-middle attack against compound authentication methods. > > I think this is ok - do you agree? I conditionally agree, as described above. Yoshihiro Ohba _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jan 13 15:51:58 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12314 for ; Tue, 13 Jan 2004 15:51:57 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 49AD7201EC; Tue, 13 Jan 2004 15:41:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.frascone.com (Postfix) with ESMTP id 213B920149 for ; Tue, 13 Jan 2004 15:40:24 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12152; Tue, 13 Jan 2004 15:51:05 -0500 (EST) Message-Id: <200401132051.PAA12152@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: eap@frascone.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [eap] I-D ACTION:draft-ietf-eap-netsel-problem-00.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 13 Jan 2004 15:51:05 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Authentication Protocol Working Group of the IETF. Title : Network Discovery and Selection Problem Author(s) : J. Arkko, B. Aboba Filename : draft-ietf-eap-netsel-problem-00.txt Pages : 27 Date : 2004-1-13 The so called network discovery and selection problem affects network access, particularly in the presence of multiple available wireless accesses and roaming. This problem has been the subject of discussions in various standards bodies. This document summarizes the discussion held about this problem in the Extensible Authentication Protocol (EAP) working group at the IETF. The problem is defined and divided into subproblems, and some constraints for possible solutions are outlined. The document presents also some existing mechanisms which help solve at least parts of the problem, and gives some suggestions on how to proceed for the rest. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel-problem-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-eap-netsel-problem-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eap-netsel-problem-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-13155910.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eap-netsel-problem-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eap-netsel-problem-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-13155910.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jan 13 17:33:50 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18877 for ; Tue, 13 Jan 2004 17:33:49 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 18ECE201EC; Tue, 13 Jan 2004 17:23:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 080AF20149 for ; Tue, 13 Jan 2004 17:22:02 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i0DMlm828919 for ; Tue, 13 Jan 2004 14:47:48 -0800 From: Bernard Aboba To: eap@frascone.com In-Reply-To: <20040112060443.GB16966@steelhead> Message-ID: References: <20040102114802.16228.13985.Mailman@xavier> <20040102224444.GA20443@steelhead> <4243028.1073491269@dhcp60-09.merit.edu> <20040109213258.GB9900@steelhead> <6392011.1073742021@[192.168.5.50]> <20040112060443.GB16966@steelhead> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Resolution of 802.1X/EAP-SM issue Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 13 Jan 2004 14:47:48 -0800 (PST) IEEE 802.1X-REV met today, and my understanding is that the resolution of the issue was that the changes required to resolve this issue would be made solely within the EAP State Machine document. Since no new EAP-SM document was available incorporating the changes, no reference was inserted in IEEE 802.1X-REV. As a result, this Issue exists only within the EAP WG, and there is no need to cc: IEEE 802.1 on this issue discussion any more. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jan 13 17:46:49 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19352 for ; Tue, 13 Jan 2004 17:46:49 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D9E8D201EC; Tue, 13 Jan 2004 17:36:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by mail.frascone.com (Postfix) with ESMTP id 6A17920149 for ; Tue, 13 Jan 2004 17:35:20 -0500 (EST) Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62]) by palrel12.hp.com (Postfix) with ESMTP id 2998C1C0067A for ; Tue, 13 Jan 2004 14:46:05 -0800 (PST) Received: from xpabh3.ptp.hp.com (xpabh3.ptp.hp.com [15.1.28.63]) by xparelay1.ptp.hp.com (Postfix) with ESMTP id 1285E1004BB8 for ; Tue, 13 Jan 2004 14:46:05 -0800 (PST) Received: by xpabh3.ptp.hp.com with Internet Mail Service (5.5.2657.72) id ; Tue, 13 Jan 2004 14:46:04 -0800 Message-ID: From: "CONGDON,PAUL (HP-Roseville,ex1)" To: eap@frascone.com Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 13 Jan 2004 14:45:57 -0800 Well, I'm not sure that is exactly how I read it. We could still update 802.1X during the sponsor ballot. That update would likely only involve a discussion within the annex about the new variable that the EAP-SM document added. If the EAP-SM document doesn't have this new variable (eapRemoteSuccess) nailed prior to the sponsor ballot close, then nothing will be added to 802.1X. It would still be helpful to have the variable documented in the EAP-SM document if this deadline isn't met. The sponsor ballot for 802.1X will likely run in 1 month to 6 weeks time. We don't want to make comments during recirculation ballot since we would have to run another circulation ballot after that. We expect comments in sponsor ballot, so we could slip the changes in there, but only if they are stable in EAP-SM. Paul > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Bernard Aboba > Sent: Tuesday, January 13, 2004 2:48 PM > To: eap@frascone.com > Subject: [eap] Resolution of 802.1X/EAP-SM issue > > > IEEE 802.1X-REV met today, and my understanding is that the > resolution of the issue was that the changes required to > resolve this issue would be made solely within the EAP State > Machine document. Since no new EAP-SM document was available > incorporating the changes, no reference was inserted in IEEE > 802.1X-REV. > > As a result, this Issue exists only within the EAP WG, and > there is no need to cc: IEEE 802.1 on this issue discussion > any more. _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jan 13 18:02:50 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19901 for ; Tue, 13 Jan 2004 18:02:50 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5BF6B201EC; Tue, 13 Jan 2004 17:52:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by mail.frascone.com (Postfix) with ESMTP id 7644620149 for ; Tue, 13 Jan 2004 17:51:07 -0500 (EST) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel8.hp.com (Postfix) with ESMTP id A7A771C017AE for ; Tue, 13 Jan 2004 18:01:52 -0500 (EST) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 9F1B01C00B6A for ; Tue, 13 Jan 2004 18:01:52 -0500 (EST) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2657.72) id ; Tue, 13 Jan 2004 18:01:52 -0500 Message-ID: From: "CONGDON,PAUL (HP-Roseville,ex1)" To: eap@frascone.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [eap] FW: [802.1] Final disposition for P802.1X-REV/D8 ballot Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 13 Jan 2004 18:01:48 -0500 FYI... -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of Tony Jeffree Sent: Tuesday, January 13, 2004 2:51 PM To: stds-802-1@ieee.org Subject: [802.1] Final disposition for P802.1X-REV/D8 ballot http://www.ieee802.org/1/files/private/x-REV-drafts/d8/802-1X-rev-d8-dis.pdf Username: p8021 Password: go_wildcats Regards, Tony =>IEEE 802.1 Email List user information: http://www.ieee802.org/1/email-pages/ _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jan 13 18:39:52 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23029 for ; Tue, 13 Jan 2004 18:39:52 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 58579201EC; Tue, 13 Jan 2004 18:29:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 273D620149 for ; Tue, 13 Jan 2004 18:28:35 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i0DNsI700556; Tue, 13 Jan 2004 15:54:18 -0800 From: Bernard Aboba To: "CONGDON,PAUL (HP-Roseville,ex1)" Cc: eap@frascone.com Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 13 Jan 2004 15:54:18 -0800 (PST) Thanks, Paul. The IETF Internet-Draft submission is coming up very soon, and hopefully we will have an EAP-State Machine revision in by then incorporating the proposed fix. Assuming that this happens, will there be time to get a fix applied to IEEE 802.1X-REV? On Tue, 13 Jan 2004, CONGDON,PAUL (HP-Roseville,ex1) wrote: > > Well, I'm not sure that is exactly how I read it. We could still update > 802.1X during the sponsor ballot. That update would likely only involve a > discussion within the annex about the new variable that the EAP-SM document > added. If the EAP-SM document doesn't have this new variable > (eapRemoteSuccess) nailed prior to the sponsor ballot close, then nothing > will be added to 802.1X. It would still be helpful to have the variable > documented in the EAP-SM document if this deadline isn't met. The sponsor > ballot for 802.1X will likely run in 1 month to 6 weeks time. We don't want > to make comments during recirculation ballot since we would have to run > another circulation ballot after that. We expect comments in sponsor > ballot, so we could slip the changes in there, but only if they are stable > in EAP-SM. > > Paul _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jan 13 18:45:51 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23465 for ; Tue, 13 Jan 2004 18:45:50 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A9108201FB; Tue, 13 Jan 2004 18:35:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by mail.frascone.com (Postfix) with ESMTP id A4C4B20149 for ; Tue, 13 Jan 2004 18:34:18 -0500 (EST) Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62]) by palrel12.hp.com (Postfix) with ESMTP id F37971C01127; Tue, 13 Jan 2004 15:45:03 -0800 (PST) Received: from xpabh3.ptp.hp.com (xpabh3.ptp.hp.com [15.1.28.63]) by xparelay1.ptp.hp.com (Postfix) with ESMTP id E7C671005567; Tue, 13 Jan 2004 15:45:03 -0800 (PST) Received: by xpabh3.ptp.hp.com with Internet Mail Service (5.5.2657.72) id ; Tue, 13 Jan 2004 15:45:03 -0800 Message-ID: From: "CONGDON,PAUL (HP-Roseville,ex1)" To: "'Bernard Aboba'" , "CONGDON,PAUL (HP-Roseville,ex1)" Cc: eap@frascone.com Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 13 Jan 2004 15:44:51 -0800 If the updated EAP-SM document is available in a maximum of 6 weeks, and the EAP group has agreed that the new interface variable is to be supported, we can modify 802.1X during sponsor ballot round. The last message I heard from Yoshi, however, was that the variable is not truly necessary and most likely won't make it into the document. Paul > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Tuesday, January 13, 2004 3:54 PM > To: CONGDON,PAUL (HP-Roseville,ex1) > Cc: eap@frascone.com > Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue > > > Thanks, Paul. > > The IETF Internet-Draft submission is coming up very soon, > and hopefully we will have an EAP-State Machine revision in > by then incorporating the proposed fix. > > Assuming that this happens, will there be time to get a fix > applied to IEEE 802.1X-REV? > > On Tue, 13 Jan 2004, CONGDON,PAUL (HP-Roseville,ex1) wrote: > > > > > Well, I'm not sure that is exactly how I read it. We could still > > update 802.1X during the sponsor ballot. That update would likely > > only involve a discussion within the annex about the new > variable that > > the EAP-SM document added. If the EAP-SM document doesn't > have this > > new variable > > (eapRemoteSuccess) nailed prior to the sponsor ballot > close, then nothing > > will be added to 802.1X. It would still be helpful to > have the variable > > documented in the EAP-SM document if this deadline isn't > met. The sponsor > > ballot for 802.1X will likely run in 1 month to 6 weeks > time. We don't want > > to make comments during recirculation ballot since we would > have to run > > another circulation ballot after that. We expect comments > in sponsor > > ballot, so we could slip the changes in there, but only if > they are stable > > in EAP-SM. > > > > Paul > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jan 13 19:34:50 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24541 for ; Tue, 13 Jan 2004 19:34:49 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A82F7201EC; Tue, 13 Jan 2004 19:24:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 64B2920149 for ; Tue, 13 Jan 2004 19:24:00 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i0E0nj904077; Tue, 13 Jan 2004 16:49:45 -0800 From: Bernard Aboba To: "CONGDON,PAUL (HP-Roseville,ex1)" Cc: eap@frascone.com Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 13 Jan 2004 16:49:44 -0800 (PST) Was it the *variable* that was not necessary -- or a new AAA attribute that was not necessary? As I call, we decided that key possession was sufficient as Yoshi recommended. But I thought we had agreed to include the *variable*, no? On Tue, 13 Jan 2004, CONGDON,PAUL (HP-Roseville,ex1) wrote: > > If the updated EAP-SM document is available in a maximum of 6 weeks, and the > EAP group has agreed that the new interface variable is to be supported, we > can modify 802.1X during sponsor ballot round. The last message I heard > from Yoshi, however, was that the variable is not truly necessary and most > likely won't make it into the document. > > Paul > > > -----Original Message----- > > From: Bernard Aboba [mailto:aboba@internaut.com] > > Sent: Tuesday, January 13, 2004 3:54 PM > > To: CONGDON,PAUL (HP-Roseville,ex1) > > Cc: eap@frascone.com > > Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue > > > > > > Thanks, Paul. > > > > The IETF Internet-Draft submission is coming up very soon, > > and hopefully we will have an EAP-State Machine revision in > > by then incorporating the proposed fix. > > > > Assuming that this happens, will there be time to get a fix > > applied to IEEE 802.1X-REV? > > > > On Tue, 13 Jan 2004, CONGDON,PAUL (HP-Roseville,ex1) wrote: > > > > > > > > Well, I'm not sure that is exactly how I read it. We could still > > > update 802.1X during the sponsor ballot. That update would likely > > > only involve a discussion within the annex about the new > > variable that > > > the EAP-SM document added. If the EAP-SM document doesn't > > have this > > > new variable > > > (eapRemoteSuccess) nailed prior to the sponsor ballot > > close, then nothing > > > will be added to 802.1X. It would still be helpful to > > have the variable > > > documented in the EAP-SM document if this deadline isn't > > met. The sponsor > > > ballot for 802.1X will likely run in 1 month to 6 weeks > > time. We don't want > > > to make comments during recirculation ballot since we would > > have to run > > > another circulation ballot after that. We expect comments > > in sponsor > > > ballot, so we could slip the changes in there, but only if > > they are stable > > > in EAP-SM. > > > > > > Paul > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jan 13 19:38:54 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24670 for ; Tue, 13 Jan 2004 19:38:53 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6BD812021D; Tue, 13 Jan 2004 19:28:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by mail.frascone.com (Postfix) with ESMTP id 6017D20149 for ; Tue, 13 Jan 2004 19:27:26 -0500 (EST) Received: from xparelay2.ptp.hp.com (xparelay2.ptp.hp.com [15.1.28.65]) by palrel11.hp.com (Postfix) with ESMTP id 61BFF1C00E6D; Tue, 13 Jan 2004 16:38:11 -0800 (PST) Received: from xpabh1.ptp.hp.com (xpabh1.ptp.hp.com [15.1.28.60]) by xparelay2.ptp.hp.com (Postfix) with ESMTP id 597F91C000AB; Tue, 13 Jan 2004 16:38:11 -0800 (PST) Received: by xpabh1.ptp.hp.com with Internet Mail Service (5.5.2657.72) id ; Tue, 13 Jan 2004 16:37:22 -0800 Message-ID: From: "CONGDON,PAUL (HP-Roseville,ex1)" To: "'Bernard Aboba'" , "CONGDON,PAUL (HP-Roseville,ex1)" Cc: eap@frascone.com Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 13 Jan 2004 16:37:19 -0800 It was both as I recall. The AAA attribute was clearly not necessary because of the requirements for key derivation and mutual auth. Since this wasn't required, the presence of the key could also be used by the pass-thru authenticator and thus the new interface variable also wasn't needed. Someone correct me if I'm out in the weeds. > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Tuesday, January 13, 2004 4:50 PM > To: CONGDON,PAUL (HP-Roseville,ex1) > Cc: eap@frascone.com > Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue > > > Was it the *variable* that was not necessary -- or a new AAA > attribute that was not necessary? As I call, we decided that > key possession was sufficient as Yoshi recommended. But I > thought we had agreed to include the *variable*, no? > > On Tue, 13 Jan 2004, CONGDON,PAUL (HP-Roseville,ex1) wrote: > > > > > If the updated EAP-SM document is available in a maximum of > 6 weeks, > > and the EAP group has agreed that the new interface > variable is to be > > supported, we can modify 802.1X during sponsor ballot > round. The last > > message I heard from Yoshi, however, was that the variable is not > > truly necessary and most likely won't make it into the document. > > > > Paul > > > > > -----Original Message----- > > > From: Bernard Aboba [mailto:aboba@internaut.com] > > > Sent: Tuesday, January 13, 2004 3:54 PM > > > To: CONGDON,PAUL (HP-Roseville,ex1) > > > Cc: eap@frascone.com > > > Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue > > > > > > > > > Thanks, Paul. > > > > > > The IETF Internet-Draft submission is coming up very soon, and > > > hopefully we will have an EAP-State Machine revision in by then > > > incorporating the proposed fix. > > > > > > Assuming that this happens, will there be time to get a > fix applied > > > to IEEE 802.1X-REV? > > > > > > On Tue, 13 Jan 2004, CONGDON,PAUL (HP-Roseville,ex1) wrote: > > > > > > > > > > > Well, I'm not sure that is exactly how I read it. We > could still > > > > update 802.1X during the sponsor ballot. That update > would likely > > > > only involve a discussion within the annex about the new > > > variable that > > > > the EAP-SM document added. If the EAP-SM document doesn't > > > have this > > > > new variable > > > > (eapRemoteSuccess) nailed prior to the sponsor ballot > > > close, then nothing > > > > will be added to 802.1X. It would still be helpful to > > > have the variable > > > > documented in the EAP-SM document if this deadline isn't > > > met. The sponsor > > > > ballot for 802.1X will likely run in 1 month to 6 weeks > > > time. We don't want > > > > to make comments during recirculation ballot since we would > > > have to run > > > > another circulation ballot after that. We expect comments > > > in sponsor > > > > ballot, so we could slip the changes in there, but only if > > > they are stable > > > > in EAP-SM. > > > > > > > > Paul > > > > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jan 13 19:49:54 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25037 for ; Tue, 13 Jan 2004 19:49:53 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E5F0B20220; Tue, 13 Jan 2004 19:39:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from hubble.802wirelessworld.com (f34hyatt.fairviewwireless.com [64.69.75.34]) by mail.frascone.com (Postfix) with ESMTP id B36FA20149 for ; Tue, 13 Jan 2004 19:38:57 -0500 (EST) Received: from [10.0.14.250] (unknown [10.0.14.250]) by hubble.802wirelessworld.com (Postfix) with ESMTP id 9E28113B8F0; Tue, 13 Jan 2004 16:49:39 -0800 (PST) From: John Vollbrecht To: Bernard Aboba , "CONGDON,PAUL (HP-Roseville,ex1)" Cc: eap@frascone.com Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue Message-ID: <8432060.1074023390@[10.0.14.250]> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 13 Jan 2004 19:49:50 -0500 Content-Transfer-Encoding: 7bit --On Tuesday, January 13, 2004 4:49 PM -0800 Bernard Aboba wrote: > Was it the *variable* that was not necessary -- or a new AAA attribute > that was not necessary? As I call, we decided that key possession was > sufficient as Yoshi recommended. But I thought we had agreed to include > the *variable*, no? > I don't think we need a variable if the key is sufficient. Otherwise - it seems to me - the remote server will need to create an attribute in addition to the key, but based on the presence of a key, when sending an a Access Accept - right? > On Tue, 13 Jan 2004, CONGDON,PAUL (HP-Roseville,ex1) wrote: > > > > > If the updated EAP-SM document is available in a maximum of 6 weeks, > > and the EAP group has agreed that the new interface variable is to be > > supported, we can modify 802.1X during sponsor ballot round. The last > > message I heard from Yoshi, however, was that the variable is not truly > > necessary and most likely won't make it into the document. > > > > Paul > > > > > -----Original Message----- > > > From: Bernard Aboba [mailto:aboba@internaut.com] > > > Sent: Tuesday, January 13, 2004 3:54 PM > > > To: CONGDON,PAUL (HP-Roseville,ex1) > > > Cc: eap@frascone.com > > > Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue > > > > > > > > > Thanks, Paul. > > > > > > The IETF Internet-Draft submission is coming up very soon, > > > and hopefully we will have an EAP-State Machine revision in > > > by then incorporating the proposed fix. > > > > > > Assuming that this happens, will there be time to get a fix > > > applied to IEEE 802.1X-REV? > > > > > > On Tue, 13 Jan 2004, CONGDON,PAUL (HP-Roseville,ex1) wrote: > > > > > > > > > > > Well, I'm not sure that is exactly how I read it. We could still > > > > update 802.1X during the sponsor ballot. That update would likely > > > > only involve a discussion within the annex about the new > > > variable that > > > > the EAP-SM document added. If the EAP-SM document doesn't > > > have this > > > > new variable > > > > (eapRemoteSuccess) nailed prior to the sponsor ballot > > > close, then nothing > > > > will be added to 802.1X. It would still be helpful to > > > have the variable > > > > documented in the EAP-SM document if this deadline isn't > > > met. The sponsor > > > > ballot for 802.1X will likely run in 1 month to 6 weeks > > > time. We don't want > > > > to make comments during recirculation ballot since we would > > > have to run > > > > another circulation ballot after that. We expect comments > > > in sponsor > > > > ballot, so we could slip the changes in there, but only if > > > they are stable > > > > in EAP-SM. > > > > > > > > Paul > > > > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jan 13 20:14:12 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25618 for ; Tue, 13 Jan 2004 20:14:11 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5A78820222; Tue, 13 Jan 2004 20:02:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id 0883C2021F for ; Tue, 13 Jan 2004 20:01:21 -0500 (EST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0E1C5N9004694; Wed, 14 Jan 2004 10:12:05 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0E1C5r8021352; Wed, 14 Jan 2004 10:12:05 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id LAA21349 ; Wed, 14 Jan 2004 10:12:05 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id KAA01684; Wed, 14 Jan 2004 10:12:05 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id KAA28788; Wed, 14 Jan 2004 10:12:04 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0E1C37f002604; Wed, 14 Jan 2004 10:12:03 +0900 (JST) Received: from steelhead ([159.119.168.127]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRG00EOOGO1MD@tsbpo1.po.toshiba.co.jp>; Wed, 14 Jan 2004 10:12:02 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AgZXZ-0005df-00; Tue, 13 Jan 2004 17:09:49 -0800 From: Yoshihiro Ohba Subject: Re: [eap] Resolution of 802.1X/EAP-SM issue In-reply-to: <8432060.1074023390@[10.0.14.250]> To: John Vollbrecht Cc: Bernard Aboba , "CONGDON,PAUL (HP-Roseville,ex1)" , eap@frascone.com Message-id: <20040114010949.GB1777@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i References: <8432060.1074023390@[10.0.14.250]> Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 13 Jan 2004 17:09:49 -0800 I think John is right. The EAP state machine already has eapKeyAvailable variable to indicate key possession status, which means that a new eapRemoteSuccess variable is not needed if we have agreed that key possession is sufficient information. Yoshihiro Ohba On Tue, Jan 13, 2004 at 07:49:50PM -0500, John Vollbrecht wrote: > > > --On Tuesday, January 13, 2004 4:49 PM -0800 Bernard Aboba > wrote: > > >Was it the *variable* that was not necessary -- or a new AAA attribute > >that was not necessary? As I call, we decided that key possession was > >sufficient as Yoshi recommended. But I thought we had agreed to include > >the *variable*, no? > > > > I don't think we need a variable if the key is sufficient. Otherwise - it > seems to me - the remote server will need to create an attribute in > addition to the key, but based on the presence of a key, when sending an a > Access Accept - right? > > > >On Tue, 13 Jan 2004, CONGDON,PAUL (HP-Roseville,ex1) wrote: > > > >> > >> If the updated EAP-SM document is available in a maximum of 6 weeks, > >> and the EAP group has agreed that the new interface variable is to be > >> supported, we can modify 802.1X during sponsor ballot round. The last > >> message I heard from Yoshi, however, was that the variable is not truly > >> necessary and most likely won't make it into the document. > >> > >> Paul > >> > >> > -----Original Message----- > >> > From: Bernard Aboba [mailto:aboba@internaut.com] > >> > Sent: Tuesday, January 13, 2004 3:54 PM > >> > To: CONGDON,PAUL (HP-Roseville,ex1) > >> > Cc: eap@frascone.com > >> > Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue > >> > > >> > > >> > Thanks, Paul. > >> > > >> > The IETF Internet-Draft submission is coming up very soon, > >> > and hopefully we will have an EAP-State Machine revision in > >> > by then incorporating the proposed fix. > >> > > >> > Assuming that this happens, will there be time to get a fix > >> > applied to IEEE 802.1X-REV? > >> > > >> > On Tue, 13 Jan 2004, CONGDON,PAUL (HP-Roseville,ex1) wrote: > >> > > >> > > > >> > > Well, I'm not sure that is exactly how I read it. We could still > >> > > update 802.1X during the sponsor ballot. That update would likely > >> > > only involve a discussion within the annex about the new > >> > variable that > >> > > the EAP-SM document added. If the EAP-SM document doesn't > >> > have this > >> > > new variable > >> > > (eapRemoteSuccess) nailed prior to the sponsor ballot > >> > close, then nothing > >> > > will be added to 802.1X. It would still be helpful to > >> > have the variable > >> > > documented in the EAP-SM document if this deadline isn't > >> > met. The sponsor > >> > > ballot for 802.1X will likely run in 1 month to 6 weeks > >> > time. We don't want > >> > > to make comments during recirculation ballot since we would > >> > have to run > >> > > another circulation ballot after that. We expect comments > >> > in sponsor > >> > > ballot, so we could slip the changes in there, but only if > >> > they are stable > >> > > in EAP-SM. > >> > > > >> > > Paul > >> > > >> > >_______________________________________________ > >eap mailing list > >eap@frascone.com > >http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jan 14 03:33:10 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05169 for ; Wed, 14 Jan 2004 03:33:10 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A86022021F; Wed, 14 Jan 2004 03:21:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id E1763201FC for ; Wed, 14 Jan 2004 03:20:38 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i0E8kML32723; Wed, 14 Jan 2004 00:46:22 -0800 From: Bernard Aboba To: "CONGDON,PAUL (HP-Roseville,ex1)" Cc: eap@frascone.com Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 14 Jan 2004 00:46:22 -0800 (PST) As I recall, the resolution of the comment in IEEE 802.1X-D7.1 was that an interface variable was needed so that EAP could indicate down to the lower layers whether a protected result indication was received. Nick -- if you're out there listening.... can you help us clear this up? On Tue, 13 Jan 2004, CONGDON,PAUL (HP-Roseville,ex1) wrote: > > It was both as I recall. The AAA attribute was clearly not necessary > because of the requirements for key derivation and mutual auth. Since this > wasn't required, the presence of the key could also be used by the pass-thru > authenticator and thus the new interface variable also wasn't needed. > Someone correct me if I'm out in the weeds. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jan 14 03:35:13 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05229 for ; Wed, 14 Jan 2004 03:35:13 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 92EC120224; Wed, 14 Jan 2004 03:23:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 3D2E120224 for ; Wed, 14 Jan 2004 03:22:21 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i0E8ljg00341; Wed, 14 Jan 2004 00:47:45 -0800 From: Bernard Aboba To: Yoshihiro Ohba Cc: John Vollbrecht , "CONGDON,PAUL (HP-Roseville,ex1)" , eap@frascone.com Subject: Re: [eap] Resolution of 802.1X/EAP-SM issue In-Reply-To: <20040114010949.GB1777@steelhead> Message-ID: References: <8432060.1074023390@[10.0.14.250]> <20040114010949.GB1777@steelhead> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 14 Jan 2004 00:47:44 -0800 (PST) OK, now I understand. This makes sense. But we should document this reasoning somewhere in the state machine document. On Tue, 13 Jan 2004, Yoshihiro Ohba wrote: > I think John is right. The EAP state machine already has > eapKeyAvailable variable to indicate key possession status, which > means that a new eapRemoteSuccess variable is not needed if we have agreed > that key possession is sufficient information. > > Yoshihiro Ohba _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jan 14 04:28:11 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06857 for ; Wed, 14 Jan 2004 04:28:11 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8DD3A2021F; Wed, 14 Jan 2004 04:16:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 4B6F9201FC for ; Wed, 14 Jan 2004 04:15:40 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i0E9QPJV007522; Wed, 14 Jan 2004 04:26:25 -0500 (EST) From: Nick Petroni To: Bernard Aboba Cc: "CONGDON,PAUL (HP-Roseville,ex1)" , Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 14 Jan 2004 04:26:25 -0500 (EST) > As I recall, the resolution of the comment in IEEE 802.1X-D7.1 was that an > interface variable was needed so that EAP could indicate down to the lower > layers whether a protected result indication was received. > > Nick -- if you're out there listening.... can you help us clear this up? Actually, I'm not sure I can. I am very confused about who is waiting for what to be put where. Picking up late on the many threads related to this topic has proven unsuccessful for me- I guess I should have been better at keeping up over vacation. It seems we are asking for SOMETHING to be put into the EAP SM, but that the group has not yet reached a consensus on what that somethingis. The way I understand the timeline is as (roughly) as follows: 1. 802.1X-D7.1 Ballot comment 15 was proposed and rejected for grounds that there was insufficient signaling from EAP SM. 2. A discussion was held offline to try to find a solution to this problem, the result was a conclusion that some mechanism to show knowledge of the other party's satisfaction was needed --> eapRemoteSuccess or something similar would be used. 3. Upon presentation to the EAP WG, discussion started as to why this is needed/what it means. To the best of my understanding, there is yet to be a consensus on the solution. I *think* the discussion of key-derivation and its implication of knowledge of the other party's acceptance has led to the conclusion that enough information is provided by the current interface (thereby rebutting #1 above - 1x does, in fact, have the info it needs). 4. Now the question seems to be if the keyAvailable variable is the only indication we want to provide and, if so, how to document it so this is clear. If not, do we want to set another signal in EAP that always has the same result as keyAvailable, but is semantically different in that it answers the exact question 1x is asking. I suppose we are also awaiting an argument playing devil's advocate as to why keyAvailable is not sufficient (if such an argument can be made). The set of dependencies I see is - 802.1x is waiting for Pasi,Nick,John,Yoshihiro to produce an SM draft with a new variable - Pasi et al. are waiting on the consensus of the group before producing a draft. I am trying my best to come up to speed- any help clarifying is greatly appreciated. Thanks, nick > > On Tue, 13 Jan 2004, CONGDON,PAUL (HP-Roseville,ex1) wrote: > > > > > It was both as I recall. The AAA attribute was clearly not necessary > > because of the requirements for key derivation and mutual auth. Since this > > wasn't required, the presence of the key could also be used by the pass-thru > > authenticator and thus the new interface variable also wasn't needed. > > Someone correct me if I'm out in the weeds. > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jan 14 11:57:00 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27673 for ; Wed, 14 Jan 2004 11:56:59 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6CDEE20208; Wed, 14 Jan 2004 11:46:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from hubble.802wirelessworld.com (f34hyatt.fairviewwireless.com [64.69.75.34]) by mail.frascone.com (Postfix) with ESMTP id E55D720207 for ; Wed, 14 Jan 2004 11:45:34 -0500 (EST) Received: from [10.0.14.250] (unknown [10.0.14.250]) by hubble.802wirelessworld.com (Postfix) with ESMTP id E7D4A13B8F2; Wed, 14 Jan 2004 08:56:14 -0800 (PST) From: John Vollbrecht To: Nick Petroni , Bernard Aboba , James Burns Cc: "CONGDON,PAUL (HP-Roseville,ex1)" , eap@frascone.com, Robert Moskowitz , Yoshihiro Ohba Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue Message-ID: <8848668.1074081386@[10.0.14.250]> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 14 Jan 2004 11:56:26 -0500 Content-Transfer-Encoding: 7bit I agree this is confusing, and I have also found it hard to follow. I am now at the 802 Interim meeting and have had conversations with Jim Burns about this, and we have a revised proposal. I wrote up a proposal which was sent to a number of people, and Jim is planning to write the details. The gist of the proposal is that 1. we don't change EAP at all, no new interface variable is needed. This means no dependency on producing new EAP documents. 2. we keep the possibility of running both two state machines at each machine, each could be supplicant and authenticator. Associated with each state machine is a variable, and for the physical port to be enabled, both variables must be set on. The variables currently exist, so only the mechanism for setting them changes. The proposal is to use the standard Success and Failure from EAP to set these variables, with no need to understand whether the authentication is "mutual". Some cases are described below, and some implications of the change described after that. Cases: a. A machine may be configured to have only one state machine (it is either a supplicant or an authenticator). This is the case covered by prior 802.1X. A supplicant only machine can talk to a authenticator only machine. By configuration the null variable in each machine is set to be always ON. b. A machine configured to be both a authenticator and supplicant may talk to another that is also configured as an authenticator and supplicant. In this case when device comes up the supplicant will attempt to start a dialog with an authenticator. If each device has two state machines, two authentications will occur and both must succeed for the actual port to be enabled. This allows certain devices [e.g. bridges with nets behind them] to be connected and to get Unicast and Broadcast keys from both authentions. A problem here is that that a lower device must decide which Unicast key to use and must know about the two multicast keys. Solution to this is considered out of scope for 802.11 but must be understood by protocols that use the keys. c. One device may configured as both supplicant and authenticator and the other as supplicant only. In this case the [authenticator] variable in the supplicant only device is configured on. The suplicant in the dual state machine will attempt to "start" but will get no answer and will timeout and set the variable to ON [this works this way to support the case where there is no authentication required by the device - I am not sure it is right, but this is the way it works]. Thus a device with a supplicant only state machine will work with a device with a authenticator state machine or with a machine with authenticator and supplicant state machine. d. one machine may be configured with authenticator and supplicant machine and the other with only an autheniticator. This case will not work because the authenticator in the device with authenticator and supplicant will wait forever for a supplicant to start. The 802.1X document should be amended to make this case clear. e. It is also true, as now, that two authenticator only or two supplicant only devices will not connect. The above cases seem to be satisfactory but require some documentation to make clear the cases that will not work. Some decision implications: This proposal maintains the interface between 802.1X and EAP. The implications seem to be in making the distinction in what is done on each side of the interface. Authentication is done on the EAP side, and configuration of what eap method to use is done as part of total device configuration. 802.1X determines that the authentication is done, but assumes the configuration forced the correct configuration to be done. This proposal assumes that the EAP method chosen by each device in each direction is configured. The EAP method determines what kind of authentication will be done, whether it is one way or mutual, whether it includes authorization at either or both ends, what keys it creates and derives. If this is configured correctly, then if mutual authentication is required, the configuration must ensure that only a method that supports this will be selected in the EAP negotiation. The implication here is that the selection of the EAP method is part of the whole implementation of an 802.1X device. Defining the EAP methods that are allowed with an application is part of the protocol. In particular, 802.1X may have some requirements, and 802.11 may have additional requirements. The 802.1x requirements presumably should be in the 802.1X documentation, and the 802.11 added requirements should be in 802.11. ---- this is a bit involved/ complex, but I would be interested in comments. John --On Wednesday, January 14, 2004 4:26 AM -0500 Nick Petroni wrote: > > As I recall, the resolution of the comment in IEEE 802.1X-D7.1 was that > > an interface variable was needed so that EAP could indicate down to the > > lower layers whether a protected result indication was received. > > > > Nick -- if you're out there listening.... can you help us clear this up? > > Actually, I'm not sure I can. I am very confused about who is waiting for > what to be put where. Picking up late on the many threads related to this > topic has proven unsuccessful for me- I guess I should have been better at > keeping up over vacation. It seems we are asking for SOMETHING to be > put into the EAP SM, but that the group has not yet reached a consensus > on what that somethingis. The way I understand the timeline is as > (roughly) as follows: > > 1. 802.1X-D7.1 Ballot comment 15 was proposed and rejected for grounds > that there was insufficient signaling from EAP SM. > > 2. A discussion was held offline to try to find a solution to this > problem, the result was a conclusion that some mechanism to show knowledge > of the other party's satisfaction was needed --> eapRemoteSuccess or > something similar would be used. > > 3. Upon presentation to the EAP WG, discussion started as to why this is > needed/what it means. To the best of my understanding, there is yet to be > a consensus on the solution. I *think* the discussion of key-derivation > and its implication of knowledge of the other party's acceptance has led > to the conclusion that enough information is provided by the current > interface (thereby rebutting #1 above - 1x does, in fact, have the info it > needs). > > 4. Now the question seems to be if the keyAvailable variable is the only > indication we want to provide and, if so, how to document it so this is > clear. If not, do we want to set another signal in EAP that always has the > same result as keyAvailable, but is semantically different in that it > answers the exact question 1x is asking. I suppose we are also awaiting an > argument playing devil's advocate as to why keyAvailable is not > sufficient (if such an argument can be made). > > The set of dependencies I see is > - 802.1x is waiting for Pasi,Nick,John,Yoshihiro to produce an SM draft > with a new variable > > - Pasi et al. are waiting on the consensus of the group before > producing a draft. > > I am trying my best to come up to speed- any help clarifying is greatly > appreciated. > > Thanks, > nick > > > > > On Tue, 13 Jan 2004, CONGDON,PAUL (HP-Roseville,ex1) wrote: > > > > > > > > It was both as I recall. The AAA attribute was clearly not necessary > > > because of the requirements for key derivation and mutual auth. > > > Since this wasn't required, the presence of the key could also be > > > used by the pass-thru authenticator and thus the new interface > > > variable also wasn't needed. Someone correct me if I'm out in the > > > weeds. > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > > > > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jan 14 14:08:54 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03674 for ; Wed, 14 Jan 2004 14:08:54 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C9B5120203; Wed, 14 Jan 2004 13:58:03 -0500 (EST) Delivered-To: eap@frascone.com Received: from smtp.um.es (xenon2.um.es [155.54.212.101]) by mail.frascone.com (Postfix) with ESMTP id 0F3B7201EF for ; Wed, 14 Jan 2004 13:57:18 -0500 (EST) Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 2ECD634BBB for ; Wed, 14 Jan 2004 20:08:04 +0100 (CET) Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by smtp.um.es (Postfix) with ESMTP id 18DDA34750 for ; Wed, 14 Jan 2004 20:08:04 +0100 (CET) Received: from dif.um.es (bravecard.dif.um.es [155.54.210.47]) by aries.dif.um.es (Postfix) with ESMTP id 7B1B414426 for ; Wed, 14 Jan 2004 19:54:42 +0100 (MET) Message-ID: <40059307.5050100@dif.um.es> From: =?ISO-8859-1?Q?Rafa_Mar=EDn_L=F3pez?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Accept-Language: en MIME-Version: 1.0 To: eap@frascone.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [eap] EAP Key Management Framework Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 14 Jan 2004 20:05:43 +0100 Content-Transfer-Encoding: 8bit Hello all I am reading EAP Key Management Framework draft... and I am a bit confused ... Figure 4 shows that MSK is placed on Authenticator but only AAA-key is transported from AAA server... ¿? ... furthermore the text tells MSK is transported to Authenticator... in another places AAA-key is carried ... I think it would be better to say : AAA - key is carried to authenticator and it could be the MSK (as appendix E tells)... what do you think? Regard. -- ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------ _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jan 14 18:21:04 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20628 for ; Wed, 14 Jan 2004 18:21:02 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A4D7C20203; Wed, 14 Jan 2004 18:10:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by mail.frascone.com (Postfix) with ESMTP id CC989201FD for ; Wed, 14 Jan 2004 18:09:53 -0500 (EST) Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62]) by palrel10.hp.com (Postfix) with ESMTP id 35CC91C02D46; Wed, 14 Jan 2004 15:20:40 -0800 (PST) Received: from xpabh3.ptp.hp.com (xpabh3.ptp.hp.com [15.1.28.63]) by xparelay1.ptp.hp.com (Postfix) with ESMTP id 3C0AE1004B95; Wed, 14 Jan 2004 15:20:39 -0800 (PST) Received: by xpabh3.ptp.hp.com with Internet Mail Service (5.5.2657.72) id ; Wed, 14 Jan 2004 15:20:39 -0800 Message-ID: From: "CONGDON,PAUL (HP-Roseville,ex1)" To: "'John Vollbrecht'" , Nick Petroni , Bernard Aboba , James Burns Cc: "CONGDON,PAUL (HP-Roseville,ex1)" , eap@frascone.com, Robert Moskowitz , Yoshihiro Ohba Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 14 Jan 2004 15:20:34 -0800 I think, at the end of the day, concerning what documents needs what changing... We could get away with no changes in either document, but since EAP-SM is still in more of a development stage, it would be helpful to include some discussion around the keyAvailable signal that indicates this signal is sufficient for a pass-thru authenticator to know the remote peer has accepted the mutual authentication (or something to that nature)... I believe we are all agreeing the eapRemoteSuccess is not needed, and thus, 802.1X is not waiting for any specific updates to the EAP-SM document. The above recommendation would simply help capture the conclusions we have come to... Paul > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of John Vollbrecht > Sent: Wednesday, January 14, 2004 8:56 AM > To: Nick Petroni; Bernard Aboba; James Burns > Cc: CONGDON,PAUL (HP-Roseville,ex1); eap@frascone.com; Robert > Moskowitz; Yoshihiro Ohba > Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue > > > I agree this is confusing, and I have also found it hard to > follow. I am > now at the 802 Interim meeting and have had conversations > with Jim Burns > about this, and we have a revised proposal. I wrote up a > proposal which > was sent to a number of people, and Jim is planning to write > the details. > > The gist of the proposal is that > > 1. we don't change EAP at all, no new interface variable is > needed. This > means no dependency on producing new EAP documents. > > 2. we keep the possibility of running both two state machines at each > machine, each could be supplicant and authenticator. > Associated with each > state machine is a variable, and for the physical port to be > enabled, both > variables must be set on. The variables currently exist, so only the > mechanism for setting them changes. The proposal is to use > the standard > Success and Failure from EAP to set these variables, with no need to > understand whether the authentication is "mutual". > > > Some cases are described below, and some implications of the change > described after that. Cases: > > a. A machine may be configured to have only one state machine > (it is either > a supplicant or an authenticator). This is the case covered by prior > 802.1X. A supplicant only machine can talk to a authenticator only > machine. By configuration the null variable in each machine > is set to be > always ON. > > b. A machine configured to be both a authenticator and > supplicant may talk > to another that is also configured as an authenticator and > supplicant. In > this case when device comes up the supplicant will attempt > to start a > dialog with an authenticator. If each device has two state > machines, two > authentications will occur and both must succeed for the > actual port to be > enabled. This allows certain devices [e.g. bridges with nets > behind them] > to be connected and to get Unicast and Broadcast keys from > both authentions. > > A problem here is that that a lower device must decide > which Unicast > key > to use and must know about the two multicast keys. > Solution to this is > considered out of scope for 802.11 but must be understood > by protocols > that use the keys. > > c. One device may configured as both supplicant and > authenticator and the > other as supplicant only. In this case the [authenticator] > variable in the > supplicant only device is configured on. The suplicant in > the dual state > machine will attempt to "start" but will get no answer and > will timeout and > set the variable to ON [this works this way to support the > case where there > is no authentication required by the device - I am not sure > it is right, > but this is the way it works]. Thus a device with a > supplicant only state > machine will work with a device with a authenticator state > machine or with > a machine with authenticator and supplicant state machine. > > d. one machine may be configured with authenticator and > supplicant machine > and the other with only an autheniticator. This case will > not work because > the authenticator in the device with authenticator and > supplicant will wait > forever for a supplicant to start. The 802.1X document > should be amended > to make this case clear. > > e. It is also true, as now, that two authenticator only or > two supplicant > only devices will not connect. > > The above cases seem to be satisfactory but require some > documentation to > make clear the cases that will not work. > > Some decision implications: > > This proposal maintains the interface between 802.1X and EAP. The > implications seem to be in making the distinction in what is > done on each > side of the interface. Authentication is done on the EAP side, and > configuration of what eap method to use is done as part of > total device > configuration. 802.1X determines that the authentication is > done, but > assumes the configuration forced the correct configuration to be done. > > This proposal assumes that the EAP method chosen by each > device in each > direction is configured. The EAP method determines what kind of > authentication will be done, whether it is one way or mutual, > whether it > includes authorization at either or both ends, what keys it > creates and > derives. If this is configured correctly, then if mutual > authentication is > required, the configuration must ensure that only a method > that supports > this will be selected in the EAP negotiation. > > The implication here is that the selection of the EAP method > is part of the > whole implementation of an 802.1X device. Defining the EAP > methods that > are allowed with an application is part of the protocol. In > particular, > 802.1X may have some requirements, and 802.11 may have additional > requirements. The 802.1x requirements presumably should be > in the 802.1X > documentation, and the 802.11 added requirements should be in 802.11. > > ---- > this is a bit involved/ complex, but I would be interested in > comments. > > John > > > --On Wednesday, January 14, 2004 4:26 AM -0500 Nick Petroni > wrote: > > > > As I recall, the resolution of the comment in IEEE > 802.1X-D7.1 was > > > that an interface variable was needed so that EAP could indicate > > > down to the lower layers whether a protected result > indication was > > > received. > > > > > > Nick -- if you're out there listening.... can you help us > clear this > > > up? > > > > Actually, I'm not sure I can. I am very confused about who > is waiting > > for what to be put where. Picking up late on the many > threads related > > to this topic has proven unsuccessful for me- I guess I should have > > been better at keeping up over vacation. It seems we are asking for > > SOMETHING to be put into the EAP SM, but that the group has not yet > > reached a consensus on what that somethingis. The way I > understand the > > timeline is as > > (roughly) as follows: > > > > 1. 802.1X-D7.1 Ballot comment 15 was proposed and rejected > for grounds > > that there was insufficient signaling from EAP SM. > > > > 2. A discussion was held offline to try to find a solution to this > > problem, the result was a conclusion that some mechanism to show > > knowledge of the other party's satisfaction was needed --> > > eapRemoteSuccess or something similar would be used. > > > > 3. Upon presentation to the EAP WG, discussion started as > to why this > > is needed/what it means. To the best of my understanding, > there is yet > > to be a consensus on the solution. I *think* the discussion of > > key-derivation and its implication of knowledge of the > other party's > > acceptance has led to the conclusion that enough information is > > provided by the current interface (thereby rebutting #1 above - 1x > > does, in fact, have the info it needs). > > > > 4. Now the question seems to be if the keyAvailable variable is the > > only indication we want to provide and, if so, how to > document it so > > this is clear. If not, do we want to set another signal in EAP that > > always has the same result as keyAvailable, but is semantically > > different in that it answers the exact question 1x is asking. I > > suppose we are also awaiting an argument playing devil's > advocate as > > to why keyAvailable is not sufficient (if such an argument can be > > made). > > > > The set of dependencies I see is > > - 802.1x is waiting for Pasi,Nick,John,Yoshihiro to > produce an SM draft > > with a new variable > > > > - Pasi et al. are waiting on the consensus of the group before > > producing a draft. > > > > I am trying my best to come up to speed- any help clarifying is > > greatly appreciated. > > > > Thanks, > > nick > > > > > > > > On Tue, 13 Jan 2004, CONGDON,PAUL (HP-Roseville,ex1) wrote: > > > > > > > > > > > It was both as I recall. The AAA attribute was clearly not > > > > necessary because of the requirements for key derivation and > > > > mutual auth. Since this wasn't required, the presence > of the key > > > > could also be used by the pass-thru authenticator and > thus the new > > > > interface variable also wasn't needed. Someone correct > me if I'm > > > > out in the weeds. > > > _______________________________________________ > > > eap mailing list > > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > > > > > > > > > > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jan 14 18:34:54 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21667 for ; Wed, 14 Jan 2004 18:34:53 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E175120203; Wed, 14 Jan 2004 18:24:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from hubble.802wirelessworld.com (f34hyatt.fairviewwireless.com [64.69.75.34]) by mail.frascone.com (Postfix) with ESMTP id 38A6D201FD for ; Wed, 14 Jan 2004 18:23:57 -0500 (EST) Received: from [10.0.14.250] (unknown [10.0.14.250]) by hubble.802wirelessworld.com (Postfix) with ESMTP id B764E13B8F2; Wed, 14 Jan 2004 15:34:43 -0800 (PST) From: John Vollbrecht To: "CONGDON,PAUL (HP-Roseville,ex1)" , Nick Petroni , Bernard Aboba , James Burns Cc: eap@frascone.com, Robert Moskowitz , Yoshihiro Ohba Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue Message-ID: <9944730.1074105291@[10.0.14.250]> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 14 Jan 2004 18:34:51 -0500 Content-Transfer-Encoding: 7bit I don't think we agree that anything needs to be included in the EAP SM. If 802.1X decides to use the secret to indicate that the authentication succeeded at both ends, it can do that. I do not think this is needed by 802.1X, and I proposed not using it. So I don't think any changes are needed to EAP SM. 802.1X needs to document something shows how each end of a connection can be configured, but that can be in an annex. It probably needs a small change in the description of how the variables are set. Jim Burns may have some idea of how this would be done. --- John --On Wednesday, January 14, 2004 3:20 PM -0800 "CONGDON,PAUL (HP-Roseville,ex1)" wrote: > > I think, at the end of the day, concerning what documents needs what > changing... We could get away with no changes in either document, but > since EAP-SM is still in more of a development stage, it would be helpful > to include some discussion around the keyAvailable signal that indicates > this signal is sufficient for a pass-thru authenticator to know the > remote peer has accepted the mutual authentication (or something to that > nature)... > > I believe we are all agreeing the eapRemoteSuccess is not needed, and > thus, 802.1X is not waiting for any specific updates to the EAP-SM > document. The above recommendation would simply help capture the > conclusions we have come to... > > Paul > > > -----Original Message----- > > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > > On Behalf Of John Vollbrecht > > Sent: Wednesday, January 14, 2004 8:56 AM > > To: Nick Petroni; Bernard Aboba; James Burns > > Cc: CONGDON,PAUL (HP-Roseville,ex1); eap@frascone.com; Robert > > Moskowitz; Yoshihiro Ohba > > Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue > > > > > > I agree this is confusing, and I have also found it hard to > > follow. I am > > now at the 802 Interim meeting and have had conversations > > with Jim Burns > > about this, and we have a revised proposal. I wrote up a > > proposal which > > was sent to a number of people, and Jim is planning to write > > the details. > > > > The gist of the proposal is that > > > > 1. we don't change EAP at all, no new interface variable is > > needed. This > > means no dependency on producing new EAP documents. > > > > 2. we keep the possibility of running both two state machines at each > > machine, each could be supplicant and authenticator. > > Associated with each > > state machine is a variable, and for the physical port to be > > enabled, both > > variables must be set on. The variables currently exist, so only the > > mechanism for setting them changes. The proposal is to use > > the standard > > Success and Failure from EAP to set these variables, with no need to > > understand whether the authentication is "mutual". > > > > > > Some cases are described below, and some implications of the change > > described after that. Cases: > > > > a. A machine may be configured to have only one state machine > > (it is either > > a supplicant or an authenticator). This is the case covered by prior > > 802.1X. A supplicant only machine can talk to a authenticator only > > machine. By configuration the null variable in each machine > > is set to be > > always ON. > > > > b. A machine configured to be both a authenticator and > > supplicant may talk > > to another that is also configured as an authenticator and > > supplicant. In > > this case when device comes up the supplicant will attempt > > to start a > > dialog with an authenticator. If each device has two state > > machines, two > > authentications will occur and both must succeed for the > > actual port to be > > enabled. This allows certain devices [e.g. bridges with nets > > behind them] > > to be connected and to get Unicast and Broadcast keys from > > both authentions. > > > > A problem here is that that a lower device must decide > > which Unicast > > key > > to use and must know about the two multicast keys. > > Solution to this is > > considered out of scope for 802.11 but must be understood > > by protocols > > that use the keys. > > > > c. One device may configured as both supplicant and > > authenticator and the > > other as supplicant only. In this case the [authenticator] > > variable in the > > supplicant only device is configured on. The suplicant in > > the dual state > > machine will attempt to "start" but will get no answer and > > will timeout and > > set the variable to ON [this works this way to support the > > case where there > > is no authentication required by the device - I am not sure > > it is right, > > but this is the way it works]. Thus a device with a > > supplicant only state > > machine will work with a device with a authenticator state > > machine or with > > a machine with authenticator and supplicant state machine. > > > > d. one machine may be configured with authenticator and > > supplicant machine > > and the other with only an autheniticator. This case will > > not work because > > the authenticator in the device with authenticator and > > supplicant will wait > > forever for a supplicant to start. The 802.1X document > > should be amended > > to make this case clear. > > > > e. It is also true, as now, that two authenticator only or > > two supplicant > > only devices will not connect. > > > > The above cases seem to be satisfactory but require some > > documentation to > > make clear the cases that will not work. > > > > Some decision implications: > > > > This proposal maintains the interface between 802.1X and EAP. The > > implications seem to be in making the distinction in what is > > done on each > > side of the interface. Authentication is done on the EAP side, and > > configuration of what eap method to use is done as part of > > total device > > configuration. 802.1X determines that the authentication is > > done, but > > assumes the configuration forced the correct configuration to be done. > > > > This proposal assumes that the EAP method chosen by each > > device in each > > direction is configured. The EAP method determines what kind of > > authentication will be done, whether it is one way or mutual, > > whether it > > includes authorization at either or both ends, what keys it > > creates and > > derives. If this is configured correctly, then if mutual > > authentication is > > required, the configuration must ensure that only a method > > that supports > > this will be selected in the EAP negotiation. > > > > The implication here is that the selection of the EAP method > > is part of the > > whole implementation of an 802.1X device. Defining the EAP > > methods that > > are allowed with an application is part of the protocol. In > > particular, > > 802.1X may have some requirements, and 802.11 may have additional > > requirements. The 802.1x requirements presumably should be > > in the 802.1X > > documentation, and the 802.11 added requirements should be in 802.11. > > > > ---- > > this is a bit involved/ complex, but I would be interested in > > comments. > > > > John > > > > > > --On Wednesday, January 14, 2004 4:26 AM -0500 Nick Petroni > > wrote: > > > > > > As I recall, the resolution of the comment in IEEE > > 802.1X-D7.1 was > > > > that an interface variable was needed so that EAP could indicate > > > > down to the lower layers whether a protected result > > indication was > > > > received. > > > > > > > > Nick -- if you're out there listening.... can you help us > > clear this > > > > up? > > > > > > Actually, I'm not sure I can. I am very confused about who > > is waiting > > > for what to be put where. Picking up late on the many > > threads related > > > to this topic has proven unsuccessful for me- I guess I should have > > > been better at keeping up over vacation. It seems we are asking for > > > SOMETHING to be put into the EAP SM, but that the group has not yet > > > reached a consensus on what that somethingis. The way I > > understand the > > > timeline is as > > > (roughly) as follows: > > > > > > 1. 802.1X-D7.1 Ballot comment 15 was proposed and rejected > > for grounds > > > that there was insufficient signaling from EAP SM. > > > > > > 2. A discussion was held offline to try to find a solution to this > > > problem, the result was a conclusion that some mechanism to show > > > knowledge of the other party's satisfaction was needed --> > > > eapRemoteSuccess or something similar would be used. > > > > > > 3. Upon presentation to the EAP WG, discussion started as > > to why this > > > is needed/what it means. To the best of my understanding, > > there is yet > > > to be a consensus on the solution. I *think* the discussion of > > > key-derivation and its implication of knowledge of the > > other party's > > > acceptance has led to the conclusion that enough information is > > > provided by the current interface (thereby rebutting #1 above - 1x > > > does, in fact, have the info it needs). > > > > > > 4. Now the question seems to be if the keyAvailable variable is the > > > only indication we want to provide and, if so, how to > > document it so > > > this is clear. If not, do we want to set another signal in EAP that > > > always has the same result as keyAvailable, but is semantically > > > different in that it answers the exact question 1x is asking. I > > > suppose we are also awaiting an argument playing devil's > > advocate as > > > to why keyAvailable is not sufficient (if such an argument can be > > > made). > > > > > > The set of dependencies I see is > > > - 802.1x is waiting for Pasi,Nick,John,Yoshihiro to > > produce an SM draft > > > with a new variable > > > > > > - Pasi et al. are waiting on the consensus of the group before > > > producing a draft. > > > > > > I am trying my best to come up to speed- any help clarifying is > > > greatly appreciated. > > > > > > Thanks, > > > nick > > > > > > > > > > > On Tue, 13 Jan 2004, CONGDON,PAUL (HP-Roseville,ex1) wrote: > > > > > > > > > > > > > > It was both as I recall. The AAA attribute was clearly not > > > > > necessary because of the requirements for key derivation and > > > > > mutual auth. Since this wasn't required, the presence > > of the key > > > > > could also be used by the pass-thru authenticator and > > thus the new > > > > > interface variable also wasn't needed. Someone correct > > me if I'm > > > > > out in the weeds. > > > > _______________________________________________ > > > > eap mailing list > > > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > eap mailing list > > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jan 14 18:56:01 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22319 for ; Wed, 14 Jan 2004 18:55:58 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D63F320203; Wed, 14 Jan 2004 18:45:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by mail.frascone.com (Postfix) with ESMTP id 830C8201FD for ; Wed, 14 Jan 2004 18:44:19 -0500 (EST) Received: from xparelay2.ptp.hp.com (xparelay2.ptp.hp.com [15.1.28.65]) by palrel12.hp.com (Postfix) with ESMTP id 162A51C03384; Wed, 14 Jan 2004 15:55:06 -0800 (PST) Received: from xpabh1.ptp.hp.com (xpabh1.ptp.hp.com [15.1.28.60]) by xparelay2.ptp.hp.com (Postfix) with ESMTP id 00A721C00417; Wed, 14 Jan 2004 15:55:06 -0800 (PST) Received: by xpabh1.ptp.hp.com with Internet Mail Service (5.5.2657.72) id ; Wed, 14 Jan 2004 15:55:05 -0800 Message-ID: From: "CONGDON,PAUL (HP-Roseville,ex1)" To: "'John Vollbrecht'" , "CONGDON,PAUL (HP-Roseville,ex1)" , Nick Petroni , Bernard Aboba , James Burns Cc: eap@frascone.com, Robert Moskowitz , Yoshihiro Ohba Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 14 Jan 2004 15:54:56 -0800 So, we certainly did not agree on any changes anywhere. That is what this thread is all about. I don't agree that 802.1X should include any new configuration variables as you are talking about, nor any additional discussion about how existing ones are used. It is a day late and a dollar short for changes now to that document unless we want to delay the sponsor ballot. It seems like EAP-SM still has room to make editorial comments, so if we are going to do ANY changes, they should go in EAP-SM. The suggestion is simply adding editorial comment, not State Machine or interface changes... Paul > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of John Vollbrecht > Sent: Wednesday, January 14, 2004 3:35 PM > To: CONGDON,PAUL (HP-Roseville,ex1); Nick Petroni; Bernard > Aboba; James Burns > Cc: eap@frascone.com; Robert Moskowitz; Yoshihiro Ohba > Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue > > > I don't think we agree that anything needs to be included in > the EAP SM. > If 802.1X decides to use the secret to indicate that the > authentication > succeeded at both ends, it can do that. I do not think this > is needed by > 802.1X, and I proposed not using it. So I don't think any > changes are > needed to EAP SM. > > 802.1X needs to document something shows how each end of a > connection can > be configured, but that can be in an annex. It probably > needs a small > change in the description of how the variables are set. Jim > Burns may have > some idea of how this would be done. > > --- John > > --On Wednesday, January 14, 2004 3:20 PM -0800 "CONGDON,PAUL > (HP-Roseville,ex1)" wrote: > > > > > I think, at the end of the day, concerning what documents > needs what > > changing... We could get away with no changes in either > document, but > > since EAP-SM is still in more of a development stage, it would be > > helpful to include some discussion around the keyAvailable > signal that > > indicates this signal is sufficient for a pass-thru > authenticator to > > know the remote peer has accepted the mutual authentication (or > > something to that nature)... > > > > I believe we are all agreeing the eapRemoteSuccess is not > needed, and > > thus, 802.1X is not waiting for any specific updates to the EAP-SM > > document. The above recommendation would simply help capture the > > conclusions we have come to... > > > > Paul > > > > > -----Original Message----- > > > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On > > > Behalf Of John Vollbrecht > > > Sent: Wednesday, January 14, 2004 8:56 AM > > > To: Nick Petroni; Bernard Aboba; James Burns > > > Cc: CONGDON,PAUL (HP-Roseville,ex1); eap@frascone.com; Robert > > > Moskowitz; Yoshihiro Ohba > > > Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue > > > > > > > > > I agree this is confusing, and I have also found it hard > to follow. > > > I am now at the 802 Interim meeting and have had conversations > > > with Jim Burns > > > about this, and we have a revised proposal. I wrote up a > > > proposal which > > > was sent to a number of people, and Jim is planning to write > > > the details. > > > > > > The gist of the proposal is that > > > > > > 1. we don't change EAP at all, no new interface variable > is needed. > > > This means no dependency on producing new EAP documents. > > > > > > 2. we keep the possibility of running both two state machines at > > > each machine, each could be supplicant and authenticator. > Associated > > > with each state machine is a variable, and for the > physical port to > > > be enabled, both > > > variables must be set on. The variables currently exist, > so only the > > > mechanism for setting them changes. The proposal is to use > > > the standard > > > Success and Failure from EAP to set these variables, with > no need to > > > understand whether the authentication is "mutual". > > > > > > > > > Some cases are described below, and some implications of > the change > > > described after that. Cases: > > > > > > a. A machine may be configured to have only one state > machine (it is > > > either a supplicant or an authenticator). This is the > case covered > > > by prior 802.1X. A supplicant only machine can talk to a > > > authenticator only machine. By configuration the null > variable in > > > each machine is set to be > > > always ON. > > > > > > b. A machine configured to be both a authenticator and supplicant > > > may talk to another that is also configured as an > authenticator and > > > supplicant. In > > > this case when device comes up the supplicant will attempt > > > to start a > > > dialog with an authenticator. If each device has two state > > > machines, two > > > authentications will occur and both must succeed for the > > > actual port to be > > > enabled. This allows certain devices [e.g. bridges with nets > > > behind them] > > > to be connected and to get Unicast and Broadcast keys from > > > both authentions. > > > > > > A problem here is that that a lower device must decide which > > > Unicast key > > > to use and must know about the two multicast keys. > > > Solution to this is > > > considered out of scope for 802.11 but must be understood > > > by protocols > > > that use the keys. > > > > > > c. One device may configured as both supplicant and authenticator > > > and the other as supplicant only. In this case the > [authenticator] > > > variable in the > > > supplicant only device is configured on. The suplicant in > > > the dual state > > > machine will attempt to "start" but will get no answer and > > > will timeout and > > > set the variable to ON [this works this way to support the > > > case where there > > > is no authentication required by the device - I am not sure > > > it is right, > > > but this is the way it works]. Thus a device with a > > > supplicant only state > > > machine will work with a device with a authenticator state > > > machine or with > > > a machine with authenticator and supplicant state machine. > > > > > > d. one machine may be configured with authenticator and > supplicant > > > machine and the other with only an autheniticator. This case will > > > not work because > > > the authenticator in the device with authenticator and > > > supplicant will wait > > > forever for a supplicant to start. The 802.1X document > > > should be amended > > > to make this case clear. > > > > > > e. It is also true, as now, that two authenticator only or two > > > supplicant only devices will not connect. > > > > > > The above cases seem to be satisfactory but require some > > > documentation to make clear the cases that will not work. > > > > > > Some decision implications: > > > > > > This proposal maintains the interface between 802.1X and > EAP. The > > > implications seem to be in making the distinction in what > is done on > > > each side of the interface. Authentication is done on > the EAP side, > > > and configuration of what eap method to use is done as part of > > > total device > > > configuration. 802.1X determines that the authentication is > > > done, but > > > assumes the configuration forced the correct > configuration to be done. > > > > > > This proposal assumes that the EAP method chosen by each > device in > > > each direction is configured. The EAP method determines > what kind > > > of authentication will be done, whether it is one way or mutual, > > > whether it > > > includes authorization at either or both ends, what keys it > > > creates and > > > derives. If this is configured correctly, then if mutual > > > authentication is > > > required, the configuration must ensure that only a method > > > that supports > > > this will be selected in the EAP negotiation. > > > > > > The implication here is that the selection of the EAP > method is part > > > of the whole implementation of an 802.1X device. Defining the EAP > > > methods that > > > are allowed with an application is part of the protocol. In > > > particular, > > > 802.1X may have some requirements, and 802.11 may have additional > > > requirements. The 802.1x requirements presumably should be > > > in the 802.1X > > > documentation, and the 802.11 added requirements should > be in 802.11. > > > > > > ---- > > > this is a bit involved/ complex, but I would be interested in > > > comments. > > > > > > John > > > > > > > > > --On Wednesday, January 14, 2004 4:26 AM -0500 Nick Petroni > > > wrote: > > > > > > > > As I recall, the resolution of the comment in IEEE > > > 802.1X-D7.1 was > > > > > that an interface variable was needed so that EAP > could indicate > > > > > down to the lower layers whether a protected result > > > indication was > > > > > received. > > > > > > > > > > Nick -- if you're out there listening.... can you help us > > > clear this > > > > > up? > > > > > > > > Actually, I'm not sure I can. I am very confused about who > > > is waiting > > > > for what to be put where. Picking up late on the many > > > threads related > > > > to this topic has proven unsuccessful for me- I guess I should > > > > have been better at keeping up over vacation. It seems we are > > > > asking for SOMETHING to be put into the EAP SM, but > that the group > > > > has not yet reached a consensus on what that > somethingis. The way > > > > I > > > understand the > > > > timeline is as > > > > (roughly) as follows: > > > > > > > > 1. 802.1X-D7.1 Ballot comment 15 was proposed and rejected > > > for grounds > > > > that there was insufficient signaling from EAP SM. > > > > > > > > 2. A discussion was held offline to try to find a > solution to this > > > > problem, the result was a conclusion that some > mechanism to show > > > > knowledge of the other party's satisfaction was needed --> > > > > eapRemoteSuccess or something similar would be used. > > > > > > > > 3. Upon presentation to the EAP WG, discussion started as > > > to why this > > > > is needed/what it means. To the best of my understanding, > > > there is yet > > > > to be a consensus on the solution. I *think* the discussion of > > > > key-derivation and its implication of knowledge of the > > > other party's > > > > acceptance has led to the conclusion that enough information is > > > > provided by the current interface (thereby rebutting #1 > above - 1x > > > > does, in fact, have the info it needs). > > > > > > > > 4. Now the question seems to be if the keyAvailable variable is > > > > the only indication we want to provide and, if so, how to > > > document it so > > > > this is clear. If not, do we want to set another signal in EAP > > > > that always has the same result as keyAvailable, but is > > > > semantically different in that it answers the exact > question 1x is > > > > asking. I suppose we are also awaiting an argument > playing devil's > > > advocate as > > > > to why keyAvailable is not sufficient (if such an > argument can be > > > > made). > > > > > > > > The set of dependencies I see is > > > > - 802.1x is waiting for Pasi,Nick,John,Yoshihiro to > > > produce an SM draft > > > > with a new variable > > > > > > > > - Pasi et al. are waiting on the consensus of the > group before > > > > producing a draft. > > > > > > > > I am trying my best to come up to speed- any help clarifying is > > > > greatly appreciated. > > > > > > > > Thanks, > > > > nick > > > > > > > > > > > > > > On Tue, 13 Jan 2004, CONGDON,PAUL (HP-Roseville,ex1) wrote: > > > > > > > > > > > > > > > > > It was both as I recall. The AAA attribute was clearly not > > > > > > necessary because of the requirements for key > derivation and > > > > > > mutual auth. Since this wasn't required, the presence > > > of the key > > > > > > could also be used by the pass-thru authenticator and > > > thus the new > > > > > > interface variable also wasn't needed. Someone correct > > > me if I'm > > > > > > out in the weeds. > > > > > _______________________________________________ > > > > > eap mailing list > > > > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > eap mailing list > > > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > > > > > > > > _______________________________________________ > > > eap mailing list > > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > > > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jan 14 19:55:58 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24000 for ; Wed, 14 Jan 2004 19:55:57 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7201620203; Wed, 14 Jan 2004 19:45:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 0E055201FD for ; Wed, 14 Jan 2004 19:44:31 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 1A4416A90C; Thu, 15 Jan 2004 02:55:16 +0200 (EET) Message-ID: <4005E4A0.1030309@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florent Bersani Cc: eap@frascone.com Subject: Re: [eap] Identity Protection and fast-reconnect References: <3FF06767.1050006@francetelecom.com> <3FF588CD.9090304@piuha.net> <40031406.9090700@francetelecom.com> In-Reply-To: <40031406.9090700@francetelecom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 15 Jan 2004 02:53:52 +0200 Content-Transfer-Encoding: 7bit Florent Bersani wrote: >>> or wherever - I hope not within EAP ;-), please feel free to mention >>> your pointers, I'll go and start with reading the irtf >>> aaaarch-handoff mentioned in EAPKMF after I am finished with this >>> post): typically if we consider a roamer, his first authentication >>> has to be forwarded by the visited AAA server to the home AAA server >>> (which might be far away), but we could imagine then that the fast >>> reconnect procedures could save time or money by reducing or even >>> better suppressing the contacts between the peer and the home AAA >>> server (for instance, the home AAA server would delegate to the >>> visited AAA server some parts of - when not all - the fast reconnect >>> exchanges). Some proposed EAP methods (IIRC EAP-SRP or EAP-SKE) had >>> the roaming situation in mind (H-AAA and V-AAA). However, this does >>> not seem to be the direction taken by the group if I understand well >>> the current draft for the EAP key management framework. >> >> >> >> Well, there may be a difference between allowing something vs. >> providing all the tools and guidance for something. Timing-wise >> it may not be possible to provide guidance on all possible fast >> handoff, fast reauthentication, and other advanced designs. Particularly >> when the field is under active research. However, the draft does provide >> some tools and hooks that allow such things to be made later, in >> other documents. For instance, the EMSK can be helpful in many of >> these schemes. >> >> > I agree about the timeliness issue and the impossibility to cater for > everything hence the hooks. > > May I then however reformulate my remark: in the latest version of the > EAP KMF (02b), the EMSK is defined in section 2.2 page 16 as "Additional > keying material derived between the EAP client and server that is > exported by the EAP method. The EMSK is at least 64 octets in length. > The EMSK is reserved for future uses that are not defined yet and is not > provided to a third party." > > My concern is that, as I understand the last part, not providing the > EMSK to a third party precludes the interaction between the visited AAA > and the home AAA I described. My recommendation would thus be: delete > "and is not provided to a third party" to provide some tools to allow > advanced services to be provided later. What do you reckon? I think I agree. Though there may be a difference between providing the EMSK as a whole or some values derived from it. However, in IETF-58 we agreed that material from Joe's draft (draft-salowey-eap-key-deriv-02.txt) should be incorporated to the EAP KMF draft. Some open issues were still being discussed on the contents, but in any case. WHat you brought up above is in fact clarified there: o The EMSK MSUT be maintained within the EAP server. Only keys (AMSKs) derived according to this specification may be exported from the EAP server. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jan 14 19:58:54 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24073 for ; Wed, 14 Jan 2004 19:58:54 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 991A620203; Wed, 14 Jan 2004 19:48:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 29C1B201FD for ; Wed, 14 Jan 2004 19:47:02 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i0F1BG227710; Wed, 14 Jan 2004 17:11:16 -0800 From: Bernard Aboba To: "CONGDON,PAUL (HP-Roseville,ex1)" Cc: eap@frascone.com Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 14 Jan 2004 17:11:15 -0800 (PST) Thanks, Paul. Are there any objections to resolving the issue this way? On Wed, 14 Jan 2004, CONGDON,PAUL (HP-Roseville,ex1) wrote: > > I think, at the end of the day, concerning what documents needs what > changing... We could get away with no changes in either document, but since > EAP-SM is still in more of a development stage, it would be helpful to > include some discussion around the keyAvailable signal that indicates this > signal is sufficient for a pass-thru authenticator to know the remote peer > has accepted the mutual authentication (or something to that nature)... > > I believe we are all agreeing the eapRemoteSuccess is not needed, and thus, > 802.1X is not waiting for any specific updates to the EAP-SM document. The > above recommendation would simply help capture the conclusions we have come > to... > > Paul _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jan 14 20:17:55 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24954 for ; Wed, 14 Jan 2004 20:17:55 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 942A220203; Wed, 14 Jan 2004 20:07:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 04D56201FD for ; Wed, 14 Jan 2004 20:06:56 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 657726A90C; Thu, 15 Jan 2004 03:17:42 +0200 (EET) Message-ID: <4005E9E2.4060209@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Proposed resolution of Issue 212: Protected Result Indications References: <00eb01c3d627$b8bd2ce0$0300000a@amer.cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 15 Jan 2004 03:16:18 +0200 Content-Transfer-Encoding: 7bit Hi Bernard, I have a question... > "Protected result indications > A method provides result indications if after the method > has finished (1) if the peer is willing to use the access provided > by the authenticator, it knows whether the authenticator will > grant access (that is, only either an EAP-Success or EAP-Failure will be > accepted, no more method specific messages are expected), and (2) if the > authenticator decides to grant access, it knows > whether the peer will accept it. Result indications improve > resilience to packet loss; see Section 4.2 for discussion. > Depending on the method and circumstances, result indications > can be spoofable by an attacker. A method is said to provide protected > result indications if it supports result indications as well as the > "integrity protection" and "replay protection" claims. A method > claiming to support protected result indications MUST indicate which > result indications are protected, and which are not. See > Section 7.16 for details." My example method is EAP AKA, which sends an authenticated challenge from the server in its first message. Before this challenge is sent, the server already knows the identity of the peer. Here's the question: Lets assume the method specification required that the challenge be sent if and only if authz check for the peer is successful. Would this be sufficient for satisfying condition 1 above? Can you see such practise on shared key methods as sensible? --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jan 14 20:27:53 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25290 for ; Wed, 14 Jan 2004 20:27:53 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 365DF20203; Wed, 14 Jan 2004 20:17:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 5F8B8201FD for ; Wed, 14 Jan 2004 20:16:31 -0500 (EST) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 14 Jan 2004 17:29:28 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i0F1REVM000911; Wed, 14 Jan 2004 17:27:15 -0800 (PST) Received: from jsaloweyw2k01 ([128.107.168.139]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 14 Jan 2004 17:32:57 -0800 From: "Joseph Salowey" To: , "'Florent Bersani'" Cc: Subject: RE: [eap] Identity Protection and fast-reconnect Message-ID: <001501c3db06$b4a784f0$8ba86b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <4005E4A0.1030309@piuha.net> X-OriginalArrivalTime: 15 Jan 2004 01:32:57.0220 (UTC) FILETIME=[8102BC40:01C3DB07] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 14 Jan 2004 17:27:14 -0800 Content-Transfer-Encoding: 7bit eap-admin@frascone.com wrote: > Florent Bersani wrote: > >>>> or wherever - I hope not within EAP ;-), please feel free to >>>> mention your pointers, I'll go and start with reading the irtf >>>> aaaarch-handoff mentioned in EAPKMF after I am finished with this >>>> post): typically if we consider a roamer, his first authentication >>>> has to be forwarded by the visited AAA server to the home AAA >>>> server (which might be far away), but we could imagine then that >>>> the fast reconnect procedures could save time or money by reducing >>>> or even better suppressing the contacts between the peer and the >>>> home AAA server (for instance, the home AAA server would delegate >>>> to the visited AAA server some parts of - when not all - the fast >>>> reconnect exchanges). Some proposed EAP methods (IIRC EAP-SRP or >>>> EAP-SKE) had the roaming situation in mind (H-AAA and V-AAA). >>>> However, this does not seem to be the direction taken by the group >>>> if I understand well the current draft for the EAP key management >>>> framework. >>> >>> >>> >>> Well, there may be a difference between allowing something vs. >>> providing all the tools and guidance for something. Timing-wise it >>> may not be possible to provide guidance on all possible fast >>> handoff, fast reauthentication, and other advanced designs. >>> Particularly when the field is under active research. However, the >>> draft does provide some tools and hooks that allow such things to >>> be made later, in other documents. For instance, the EMSK can be >>> helpful in many of these schemes. >>> >>> >> I agree about the timeliness issue and the impossibility to cater >> for everything hence the hooks. >> >> May I then however reformulate my remark: in the latest version of >> the EAP KMF (02b), the EMSK is defined in section 2.2 page 16 as >> "Additional keying material derived between the EAP client and >> server that is exported by the EAP method. The EMSK is at least 64 >> octets in length. The EMSK is reserved for future uses that are not >> defined yet and is not provided to a third party." >> >> My concern is that, as I understand the last part, not providing the >> EMSK to a third party precludes the interaction between the visited >> AAA and the home AAA I described. My recommendation would thus be: >> delete "and is not provided to a third party" to provide some tools >> to allow advanced services to be provided later. What do you reckon? > > I think I agree. Though there may be a difference between > providing the EMSK as a whole or some values derived from it. > > However, in IETF-58 we agreed that material from Joe's draft > (draft-salowey-eap-key-deriv-02.txt) should be incorporated > to the EAP KMF draft. Some open issues were still being > discussed on the contents, but in any case. WHat you brought > up above is in fact clarified there: > > o The EMSK MSUT be maintained within the EAP server. Only keys > (AMSKs) derived according to this specification may > be exported > from the EAP server. [Joe] Yes, this was one of the motivations for the EMSK work. By coordinating the derivation of key material for different applications (AMSK) so they are computationally independent from the root EMSK we can derive keys for many different purposes including re-authentication, channel-binding, handoff, etc. You do not want to release the EMSK itself because that could result in the compromise of all keys if one is compromised. There is probably additional work to define how keys are requested and distributed for various applications if necessary. I do still owe a list of issues to merge the key derivation draft into the key framework draft which I will provide soon. > > --Jari > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jan 14 21:10:55 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26277 for ; Wed, 14 Jan 2004 21:10:54 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DCCA32022A; Wed, 14 Jan 2004 21:00:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from deneb.mtghouse.com (unknown [206.152.191.132]) by mail.frascone.com (Postfix) with SMTP id 1C3E7201FD for ; Wed, 14 Jan 2004 20:59:12 -0500 (EST) Received: (qmail 12950 invoked from network); 15 Jan 2004 02:09:57 -0000 Received: from unknown (HELO mtghouse.com) (192.168.5.204) by deneb.mtghouse.com with SMTP; 15 Jan 2004 02:09:57 -0000 Message-ID: <4005F673.6000108@mtghouse.com> From: Jim Burns User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030829 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Vollbrecht Cc: "CONGDON,PAUL (HP-Roseville,ex1)" , Nick Petroni , Bernard Aboba , eap@frascone.com, Robert Moskowitz , Yoshihiro Ohba Subject: Re: [eap] Resolution of 802.1X/EAP-SM issue References: <9944730.1074105291@[10.0.14.250]> In-Reply-To: <9944730.1074105291@[10.0.14.250]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 14 Jan 2004 18:09:55 -0800 Content-Transfer-Encoding: 7bit Hi folks, Sorry I am late to this discussion. It would be helpful to the community at large if two notes were written (I volunteer): 1. A note that contains a table with all the .1X state machine combinations down the left side and across the top with an indication of what will happen when each case encounters the other. There are some cases that will not work, for instance if one device is running the supplicant and authenticator and it attempts to connect to another device that is running just the authenticator. 2. A note how to set the .1X administrative variables depending on which machines are being run. I am happy to write these two *informative* notes. Jim B. John Vollbrecht wrote: > I don't think we agree that anything needs to be included in the EAP > SM. If 802.1X decides to use the secret to indicate that the > authentication succeeded at both ends, it can do that. I do not think > this is needed by 802.1X, and I proposed not using it. So I don't > think any changes are needed to EAP SM. > > 802.1X needs to document something shows how each end of a connection > can be configured, but that can be in an annex. It probably needs a > small change in the description of how the variables are set. Jim > Burns may have some idea of how this would be done. > > --- John > > --On Wednesday, January 14, 2004 3:20 PM -0800 "CONGDON,PAUL > (HP-Roseville,ex1)" wrote: > >> >> I think, at the end of the day, concerning what documents needs what >> changing... We could get away with no changes in either document, but >> since EAP-SM is still in more of a development stage, it would be >> helpful >> to include some discussion around the keyAvailable signal that indicates >> this signal is sufficient for a pass-thru authenticator to know the >> remote peer has accepted the mutual authentication (or something to that >> nature)... >> >> I believe we are all agreeing the eapRemoteSuccess is not needed, and >> thus, 802.1X is not waiting for any specific updates to the EAP-SM >> document. The above recommendation would simply help capture the >> conclusions we have come to... >> >> Paul >> >> > -----Original Message----- >> > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] >> > On Behalf Of John Vollbrecht >> > Sent: Wednesday, January 14, 2004 8:56 AM >> > To: Nick Petroni; Bernard Aboba; James Burns >> > Cc: CONGDON,PAUL (HP-Roseville,ex1); eap@frascone.com; Robert >> > Moskowitz; Yoshihiro Ohba >> > Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue >> > >> > >> > I agree this is confusing, and I have also found it hard to >> > follow. I am >> > now at the 802 Interim meeting and have had conversations >> > with Jim Burns >> > about this, and we have a revised proposal. I wrote up a >> > proposal which >> > was sent to a number of people, and Jim is planning to write >> > the details. >> > >> > The gist of the proposal is that >> > >> > 1. we don't change EAP at all, no new interface variable is >> > needed. This >> > means no dependency on producing new EAP documents. >> > >> > 2. we keep the possibility of running both two state machines at each >> > machine, each could be supplicant and authenticator. >> > Associated with each >> > state machine is a variable, and for the physical port to be >> > enabled, both >> > variables must be set on. The variables currently exist, so only the >> > mechanism for setting them changes. The proposal is to use >> > the standard >> > Success and Failure from EAP to set these variables, with no need to >> > understand whether the authentication is "mutual". >> > >> > >> > Some cases are described below, and some implications of the change >> > described after that. Cases: >> > >> > a. A machine may be configured to have only one state machine >> > (it is either >> > a supplicant or an authenticator). This is the case covered by prior >> > 802.1X. A supplicant only machine can talk to a authenticator only >> > machine. By configuration the null variable in each machine >> > is set to be >> > always ON. >> > >> > b. A machine configured to be both a authenticator and >> > supplicant may talk >> > to another that is also configured as an authenticator and >> > supplicant. In >> > this case when device comes up the supplicant will attempt >> > to start a >> > dialog with an authenticator. If each device has two state >> > machines, two >> > authentications will occur and both must succeed for the >> > actual port to be >> > enabled. This allows certain devices [e.g. bridges with nets >> > behind them] >> > to be connected and to get Unicast and Broadcast keys from >> > both authentions. >> > >> > A problem here is that that a lower device must decide >> > which Unicast >> > key >> > to use and must know about the two multicast keys. >> > Solution to this is >> > considered out of scope for 802.11 but must be understood >> > by protocols >> > that use the keys. >> > >> > c. One device may configured as both supplicant and >> > authenticator and the >> > other as supplicant only. In this case the [authenticator] >> > variable in the >> > supplicant only device is configured on. The suplicant in >> > the dual state >> > machine will attempt to "start" but will get no answer and >> > will timeout and >> > set the variable to ON [this works this way to support the >> > case where there >> > is no authentication required by the device - I am not sure >> > it is right, >> > but this is the way it works]. Thus a device with a >> > supplicant only state >> > machine will work with a device with a authenticator state >> > machine or with >> > a machine with authenticator and supplicant state machine. >> > >> > d. one machine may be configured with authenticator and >> > supplicant machine >> > and the other with only an autheniticator. This case will >> > not work because >> > the authenticator in the device with authenticator and >> > supplicant will wait >> > forever for a supplicant to start. The 802.1X document >> > should be amended >> > to make this case clear. >> > >> > e. It is also true, as now, that two authenticator only or >> > two supplicant >> > only devices will not connect. >> > >> > The above cases seem to be satisfactory but require some >> > documentation to >> > make clear the cases that will not work. >> > >> > Some decision implications: >> > >> > This proposal maintains the interface between 802.1X and EAP. The >> > implications seem to be in making the distinction in what is >> > done on each >> > side of the interface. Authentication is done on the EAP side, and >> > configuration of what eap method to use is done as part of >> > total device >> > configuration. 802.1X determines that the authentication is >> > done, but >> > assumes the configuration forced the correct configuration to be done. >> > >> > This proposal assumes that the EAP method chosen by each >> > device in each >> > direction is configured. The EAP method determines what kind of >> > authentication will be done, whether it is one way or mutual, >> > whether it >> > includes authorization at either or both ends, what keys it >> > creates and >> > derives. If this is configured correctly, then if mutual >> > authentication is >> > required, the configuration must ensure that only a method >> > that supports >> > this will be selected in the EAP negotiation. >> > >> > The implication here is that the selection of the EAP method >> > is part of the >> > whole implementation of an 802.1X device. Defining the EAP >> > methods that >> > are allowed with an application is part of the protocol. In >> > particular, >> > 802.1X may have some requirements, and 802.11 may have additional >> > requirements. The 802.1x requirements presumably should be >> > in the 802.1X >> > documentation, and the 802.11 added requirements should be in 802.11. >> > >> > ---- >> > this is a bit involved/ complex, but I would be interested in >> > comments. >> > >> > John >> > >> > >> > --On Wednesday, January 14, 2004 4:26 AM -0500 Nick Petroni >> > wrote: >> > >> > > > As I recall, the resolution of the comment in IEEE >> > 802.1X-D7.1 was >> > > > that an interface variable was needed so that EAP could indicate >> > > > down to the lower layers whether a protected result >> > indication was >> > > > received. >> > > > >> > > > Nick -- if you're out there listening.... can you help us >> > clear this >> > > > up? >> > > >> > > Actually, I'm not sure I can. I am very confused about who >> > is waiting >> > > for what to be put where. Picking up late on the many >> > threads related >> > > to this topic has proven unsuccessful for me- I guess I should have >> > > been better at keeping up over vacation. It seems we are asking for >> > > SOMETHING to be put into the EAP SM, but that the group has not yet >> > > reached a consensus on what that somethingis. The way I >> > understand the >> > > timeline is as >> > > (roughly) as follows: >> > > >> > > 1. 802.1X-D7.1 Ballot comment 15 was proposed and rejected >> > for grounds >> > > that there was insufficient signaling from EAP SM. >> > > >> > > 2. A discussion was held offline to try to find a solution to this >> > > problem, the result was a conclusion that some mechanism to show >> > > knowledge of the other party's satisfaction was needed --> >> > > eapRemoteSuccess or something similar would be used. >> > > >> > > 3. Upon presentation to the EAP WG, discussion started as >> > to why this >> > > is needed/what it means. To the best of my understanding, >> > there is yet >> > > to be a consensus on the solution. I *think* the discussion of >> > > key-derivation and its implication of knowledge of the >> > other party's >> > > acceptance has led to the conclusion that enough information is >> > > provided by the current interface (thereby rebutting #1 above - 1x >> > > does, in fact, have the info it needs). >> > > >> > > 4. Now the question seems to be if the keyAvailable variable is the >> > > only indication we want to provide and, if so, how to >> > document it so >> > > this is clear. If not, do we want to set another signal in EAP that >> > > always has the same result as keyAvailable, but is semantically >> > > different in that it answers the exact question 1x is asking. I >> > > suppose we are also awaiting an argument playing devil's >> > advocate as >> > > to why keyAvailable is not sufficient (if such an argument can be >> > > made). >> > > >> > > The set of dependencies I see is >> > > - 802.1x is waiting for Pasi,Nick,John,Yoshihiro to >> > produce an SM draft >> > > with a new variable >> > > >> > > - Pasi et al. are waiting on the consensus of the group before >> > > producing a draft. >> > > >> > > I am trying my best to come up to speed- any help clarifying is >> > > greatly appreciated. >> > > >> > > Thanks, >> > > nick >> > > >> > > > >> > > > On Tue, 13 Jan 2004, CONGDON,PAUL (HP-Roseville,ex1) wrote: >> > > > >> > > > > >> > > > > It was both as I recall. The AAA attribute was clearly not >> > > > > necessary because of the requirements for key derivation and >> > > > > mutual auth. Since this wasn't required, the presence >> > of the key >> > > > > could also be used by the pass-thru authenticator and >> > thus the new >> > > > > interface variable also wasn't needed. Someone correct >> > me if I'm >> > > > > out in the weeds. >> > > > _______________________________________________ >> > > > eap mailing list >> > > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap >> > > > >> > > >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > eap mailing list >> > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap >> > >> > >> > _______________________________________________ >> > eap mailing list >> > eap@frascone.com >> > http://mail.frascone.com/mailman/listinfo/eap >> > > > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Jan 15 08:03:21 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02509 for ; Thu, 15 Jan 2004 08:03:21 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 50F2920205; Thu, 15 Jan 2004 07:52:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id C8343201F5 for ; Thu, 15 Jan 2004 07:51:22 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i0FD29JV008169; Thu, 15 Jan 2004 08:02:09 -0500 (EST) From: Nick Petroni To: Bernard Aboba Cc: "CONGDON,PAUL (HP-Roseville,ex1)" , Subject: RE: [eap] Resolution of 802.1X/EAP-SM issue In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 15 Jan 2004 08:02:09 -0500 (EST) I agree the implications of a key should be properly explained somewhere within the document. This is a fine resulotion to me. nick Nick L. Petroni, Jr. Graduate Student, Computer Science Maryland Information Systems Security Lab University of Maryland http://www.cs.umd.edu/~npetroni On Wed, 14 Jan 2004, Bernard Aboba wrote: > Thanks, Paul. Are there any objections to resolving the issue this way? > > On Wed, 14 Jan 2004, CONGDON,PAUL (HP-Roseville,ex1) wrote: > > > > > I think, at the end of the day, concerning what documents needs what > > changing... We could get away with no changes in either document, but since > > EAP-SM is still in more of a development stage, it would be helpful to > > include some discussion around the keyAvailable signal that indicates this > > signal is sufficient for a pass-thru authenticator to know the remote peer > > has accepted the mutual authentication (or something to that nature)... > > > > I believe we are all agreeing the eapRemoteSuccess is not needed, and thus, > > 802.1X is not waiting for any specific updates to the EAP-SM document. The > > above recommendation would simply help capture the conclusions we have come > > to... > > > > Paul > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Jan 15 18:16:06 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08020 for ; Thu, 15 Jan 2004 18:16:04 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ACC1F20205; Thu, 15 Jan 2004 18:05:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from deneb.mtghouse.com (unknown [206.152.191.132]) by mail.frascone.com (Postfix) with SMTP id 8D5C3201F5 for ; Thu, 15 Jan 2004 18:04:46 -0500 (EST) Received: (qmail 10825 invoked from network); 15 Jan 2004 23:15:28 -0000 Received: from unknown (HELO mtghouse.com) (192.168.5.204) by deneb.mtghouse.com with SMTP; 15 Jan 2004 23:15:28 -0000 Message-ID: <40071F10.7080400@mtghouse.com> From: Jim Burns User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030829 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Preeti vinayakray Cc: yohba@tari.toshiba.com, paul.congdon@hp.com, stds-802-1@ieee.org, eap@frascone.com, tony@jeffree.co.uk References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [eap] Re: [802.1] New EAP/802.1X interface variable proposal Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 15 Jan 2004 15:15:28 -0800 Content-Transfer-Encoding: 7bit Hi Preeti, Yes, let me try to bring some clarity here. Please see my responses below: Preeti vinayakray wrote: > > > Hello Jim: > > In following email you mentioned about few points and I am somewhat > confused with terminology here. I would appreciate if you can clarify > my if anything I have misunderstood > > Well in brief discussion u did mention that here the scenario can > be focused as P2P. > Yes, this discussion, and the interface variable, were related to resolving an issue that occurred in the peer to peer .11 case. The original problem was, if both peers are running both the authenticator and supplicant (peer) and a mutual authentication occurs on one of the state machines, then should we be able to ignore the result on the other .1X state machine. If the answer was yes, then how would the .1X machine know that a mutual authentication method had been used? The answer was there needed to be a new 1X/EAP variable. It was then discovered that just because a mutual authentication method ran on one .1X machine it may not necessarily follow that you want to ignore the second .1X state machine. It could be the case that each .1X machine should both run mutual authentication EAP methods but use different credentials. This meant that we should only ignore the other .1X machine if the 'policy' had been satisfied by a single .1X machine. This led to issues of what was a 'policy' and how could we know when it had been satisfied. In the end, there is no problem with running two .1X machines, it is just slightly less efficient. In addition, if keys are created, there will be two created (one for each .1X machine) and there must be a mechanism for choosing which key will be used (which .11 peer to peer does define). The current proposal is that there is no need for the 1X/EAP variable and rather that your policy will be defined by a clear definition of how many .1X machines you configure to run along with the EAP methods you configure to support. In other words, if you run two state machines, then you meant to run two state machines with a set of EAP methods and those state machines should run and neither should be dynamically ignored. Likewise, if you configure only one state machine to run with a limited set of EAP methods then this defines your policy. Thus, there is no need to terminate one of the .1X state machines dynamically and there is no need for the new .1X/EAP interface variable. Rather, there is a need for standards that use 1X/EAP to explicity define the number of .1X machines and required EAP methods before starting. > >coupled one-way EAP methods then this is not true. An example may > perhaps be enlightening. > > >A. Imagine a peer that has a policy that indicates that indicates > that >it will only open its controlled port when the following occurs: > >1. The entity on the other end of the connection verifies that it is > a >trusted server (by delivering a server certificate) and accepts the > >peer's client certificate as valid. >2. The entity on the other end > of the connection delivers a client >certificate to the peer after the > peer verifies that it is a trusted >server (by delivering a server > certificate). > > [Preeti] In above Peer I presume that it is playing role of > authenticator. Uncontrolled/Controlled port within authencator is > more relevant to authorization gained through authentication process. > And Client/Station. > Sorry, I used the overloaded word 'peer'. By peer, I meant one of the end stations on one end of a network connection. Let us call the peers as 'local station' and 'remote station'. So, yes, the local station is running both .1X machines: authenticator and supplicant. The remote station is only running the authenticator 1X machine. > >B. Imagine an authenticator that has a policy that indicates that it > >will open its controlled port when the following occurs: >1. The peer > delivers a valid client certifcate after the authenticator >sends its > server certificate. > > [Preeti] Here Peer is client. So if that is so then A and B resembles > same. Or I'm misunderstanding? > You may be misunderstanding...but that is because of my sloppy terminology. The 'remote station' is running only the .1X authenticator machine. > >Now, on a protocol level the following will occur: A. The peer > associates with the authenticator. > > >B. The peer and authenticator agree on EAP-TLS as the EAP method. >C. > EAP-TLS completes successfully after the authenticator delivers a > >server certificate, and the peer delivers its client certificate. >D. > The authenticator/AAA policy is now satisfied and the authenticator > >controlled port is unblocked and the key is delivered. >E. The peer's > policy is not satisfied yet though and the peer's >controlled port > remains blocked. >So, in this case the delivery of the AAA key does > not necessarily mean >the peer's policy has been satisfied. > > [Preeti] Yes, I agree with above that peer policy is not satified. > Yes, in the better terminology, the local station (which is running both .1X machines) has had its supplicant machine satisfied, but not its authenticator machine and its controlled port remains blocked. > >So, issue two (2) above is summarized as, 'what happens when 'policy' > > >spans multiple EAP conversations'? >One potential solution is some > sort of handshake (beyond the EAP NAK) at >the start that allows both > parties to indicate their policies >requirements. If the authenticator > had known that the Peer required a >second EAP conversation then at > step D in the protocol description above >it could have realized that > the Peer was not yet satisfied and would not >have delivered the key > until after the second EAP conversation had > > >completed successfully. > > [Preeti] Or is it possible to convey policy criteria of Peers to each > other while negotiating the capabilities? > Do you mean during a 'discovery' phase? This may be possible and I believe it should be explored as a longer term solution to allow dynamic configuration. I believe that today we are moving toward static definitions. Standards that utilize .1X and EAP (i.e. 802.11 and 802.3) to define the number of .1X state machines and EAP methods to ensure that the policy is set at this level, rather than dynamically being created on the 'fly' in the field. In fact, the example I have given would never occur as long as the definition states that peer-to-peer networks will run both .1X machines and will run mutual authentication EAP methods. It is not as dynamic, but it guarantees a level of policy and allows security folks to better analyze a standard that uses 1X/EAP (I think). > >I suppose another solution is that the peer will only accept an EAP > >method that allows chaining of mutliple EAP methods within it -- in > >other words EAP-PEAP. Then the EAP NAK process will provide the > policy >handshake...although this will not work because the > authenticator is in >charge of which EAP methods will be run and it > will be satisfied after a >single EAP-TLS and not run the second EAP-TLS. > > [Preeti] This may be possible. Perhaps in this chaining process one > has to be careful in selecting the chained methods that are immune to > security any threats. > > Thanks, > > Preeti > > >From: Jim Burns >To: Yoshihiro Ohba >CC: "CONGDON,PAUL > (HP-Roseville,ex1)" , stds-802-1@ieee.org, > eap@frascone.com, Tony Jeffree >Subject: Re: [802.1] New > EAP/802.1X interface variable proposal >Date: Fri, 02 Jan 2004 > 10:56:46 -0500 > > >Hi Yoshi, >This is a good point. >I have a few > questions/concerns that I would like to toss out. I am more >versed in > 1X than in the latest EAP draft so take this into account as >you read > through these - I could just be missing something in the latest >EAP > draft. > >I agree that overloading the AAA delivery to indicate > satisfaction of >both authenticator and peer policies should work in > most cases, but >there are two (2) cases/issues that concern me: >1. > This presumes the EAP method being utilized can produce a key. Does > >2284bis now require only EAP methods that produce keys? Is EAP-MD5 > >deprecated? >2. The definition of 'policy' may go beyond the current > EAP method. This >occurs in the case of two coupled 'one-way' EAP > conversations. Example >below. If the policy does go beyond a single > EAP conversation, then the >delivery of the key by the AAA server only > indicates that satisfaction >has been achieved by the AAA server, the > peer may still want to run a >second EAP conversation. There is no > good solution if the policy extends >beyond a single EAP conversation > I believe, and this is because we have >a more basic problem that > there is no way for a Peer and an >Authenticator to agree on such a > higher level policy. Currently EAP >assumes that the acceptance (non > NAK) of a current EAP method means that >this is the policy that will > satisfy both sides. But, if there are to be >coupled one-way EAP > methods then this is not true. An example may >perhaps be > enlightening. > >A. Imagine a peer that has a policy that indicates > that indicates that >it will only open its controlled port when the > following occurs: >1. The entity on the other end of the connection > verifies that it is a >trusted server (by delivering a server > certificate) and accepts the >peer's client certificate as valid. >2. > The entity on the other end of the connection delivers a client > >certificate to the peer after the peer verifies that it is a trusted > >server (by delivering a server certificate). > >B. Imagine an > authenticator that has a policy that indicates that it >will open its > controlled port when the following occurs: >1. The peer delivers a > valid client certifcate after the authenticator >sends its server > certificate. > >Now, on a protocol level the following will occur: >A. > The peer associates with the authenticator. >B. The peer and > authenticator agree on EAP-TLS as the EAP method. >C. EAP-TLS > completes successfully after the authenticator delivers a >server > certificate, and the peer delivers its client certificate. >D. The > authenticator/AAA policy is now satisfied and the authenticator > >controlled port is unblocked and the key is delivered. >E. The peer's > policy is not satisfied yet though and the peer's >controlled port > remains blocked. >So, in this case the delivery of the AAA key does > not necessarily mean >the peer's policy has been satisfied. > >So, > issue two (2) above is summarized as, 'what happens when 'policy' > >spans multiple EAP conversations'? >One potential solution is some > sort of handshake (beyond the EAP NAK) at >the start that allows both > parties to indicate their policies >requirements. If the authenticator > had known that the Peer required a >second EAP conversation then at > step D in the protocol description above >it could have realized that > the Peer was not yet satisfied and would not >have delivered the key > until after the second EAP conversation had >completed successfully. > >I suppose another solution is that the peer will only accept an EAP > >method that allows chaining of mutliple EAP methods within it -- in > >other words EAP-PEAP. Then the EAP NAK process will provide the > policy >handshake...although this will not work because the > authenticator is in >charge of which EAP methods will be run and it > will be satisfied after a >single EAP-TLS and not run the second > EAP-TLS. > >In summary: >- You suggested that we overload the AAA key > delivery to indicate policy >satisfaction (rather than adding a new > AAA/passthrough authenticator >signal). >- I agree that this should > work in most cases, but there are two cases >that concern me: 1) > non-key generating EAP methods and 2) case that one >party's policy > spans multiple EAP conversations. > >I hope this is helpful, >Thanks, > >Jim B. > > > > >The delivery of the key could double as an indication > of peer success >for the current EAP method. It would be an indication > strictly from the >Authentication Server's point of view, but > currently there is no way to >communicate a higher level policy than > the current EAP method. >Let me back up to try to clarify my point. > > >Yoshihiro Ohba wrote: > > >I am a co-author of EAP State Machine > draft and it is not clear to me > >why a new RADIUS attribute is > needed to solve the problem (or I may be > >missing something). > > > > >I am wondering if the availablity of a AAA-Key at the pass-through > > >authenticator can be equivalent to the eapRemoteSuccess signal. Is > > >there any case where the authentication server transports the AAA-Key > > >to the pass-through authenticator via a AAA protocol while the > higher > >layer policy has not been fully satisfied? > > > >I am > asking because it is difficult for me to imagine the case where > >the > AAA-Key is derived and transferred to the pass-through > > >authenticator while the EAP peer does not accept a successful mutual > > >authentication exchange in an EAP method that creates a shared key. > > > > >If the availablity of a AAA-Key at the pass-through > authenticator can > >be equivalent to the eapRemoteSuccess signal, I > think that > >aaaEapKeyAvailable variable in the EAP Full > Authenticator state > >machine can function as eapRemoteSuccess and a > new RADIUS attribute is > >not needed. > > > >Regards, > > > > >Yoshihiro Ohba > > > > > >On Fri, Dec 19, 2003 at 02:12:54PM -0500, > CONGDON,PAUL (HP-Roseville,ex1) wrote: > > > > > >>A proposed > resolution to the 802.1X/EAP interface issue > >>related to > discussions on EAP issues 204/205 and > >>802.1X/D7.1 Ballot comment > 15 was developed Dec 5th in a > >>phone conference with EAP team > members Bernard Aboba, Jari > >>Arkko, Nick Petroni and 802.1X team > members Jim Burns, Paul > >>Congdon and Bob Moskowitz. This memo > attempts to document > >>the proposal and solicit discussion that will > lead to > >>closure of this remaining issue for two nearly completed > > >>documents; 802.1X/D8 and RFC2284bis. > >> > >>Background - The > problem > >> > >>The resolution of comment 15 on 802.1X/D7.1 uncovered > an > >>issue with rfc2284bis and the EAP state machine draft. > > >>Namely, the higher layer(EAP/AAA) is unable to inform the > >>lower > layer (1X) that its policy has been fully satisfied > >>after only one > role's state machine has run. This also > >>means that it is unable > to inform the lower layer that its > >>policy will only be satisfied > if the other role's state > >>machine is run. > >> > >>In addition, it > was discovered that a pass-thru > >>authenticator has no way of > knowing if a peer has accepted > >>a successful mutual authentication > exchange since it is > >>unaware of any protected indications returned > by that peer. > >>In contrast a standalone authenticator can be made > aware of > >>this because the EAP session is terminated locally. > > >>Consequently pass-thru and standalone configurations behave > > >>differently and this is not allowed or appropriate. > >> > >>The > ability of the higher layer to inform the lower layer > >>when its > policy is satisfied can be used to eliminate the > >>need for a > subsequent authentication exchange in the > >>opposite > direction. Running two authentications in > >>opposite directions of > one another is often very difficult > >>and not sufficient as pointed > out by RFC 2284bis in section > >>2.4. > >> > >>The fix for > communicating the satisfaction of policy > >>between the higher layer > and lower layer is a new interface > >>signal. > >> > >>The fix to > ensure that the pass-thru authenticator does not > >>behave > differently than the standalone authenticator is a > >>new RADIUS > attribute. The new RADIUS attribute is under > >>development and will > be documented in a forthcoming RFC. > >> > >>The new interface signal > is communicated across the AAA > >>boundary to the EAP. The signal > indicates to the layer > >>below that the policy of the higher layer > is satisfied or > >>not. > >> > >>The RADIUS attribute is used by the > authentication server > >>to inform a pass-thru authenticator of > policy satisfaction > >>so it may drive this signal. A standalone > authenticator > >>could drive this signal based upon local > information. > >> > >>The new interface signal is also made available > at the > >>802.1X interface and could be used to eliminate the need to > > >>initiate a second authentication in the opposite direction. > > >>Essentially this signal could be used to either force > >>authorize > the alternate role, or activate the Supplicant > >>Access Control With > Authenticator variable if it were not > >>already activated. As RFC > 2284bis points out in 2.4 it is > >>often neither desirable nor > possible to initiate a second > >>authentication in the opposite > direction, nor is it > >>necessary if the 1st authentication resulted > in mutual > >>authentication with protected indications (essentially > what > >>the new interface signal asserts). > >> > >>It is important > to note that the EAP layer, EAP methods and > >>AAA layer run over > transports other than 802.1X and this > >>interface signal will be > important for those transports as > >>well. This new signal will also > need to be a consideration > >>for future 802.1af work. > >> > >>The > Proposal > >> > >>The EAP state machine draft will be updated to > discuss this > >>new indication. Annex F of 802.1X documents the > interface > >>between the higher layers (EAP, EAP Methods, AAA Layer) > and > >>802.1X. Annex F must include a definition of all signals > > >>that cross this interface. This new signal should be > >>included > in this discussion. > >> > >>Additionally a short description of how > this signal might > >>be used to disable reverse authentications in > the special > >>case where both authenticator and supplicant are > configured > >>and active on a port. It should reference section 2.4 > of > >>RFC 2284bis where this type of configuration is discussed > > >>for peer-to-peer scenarios. A short discussion of this may > >>also > be needed in clause 6.7. > >> > >>Proposed Changes to > 802.1X/D8 (subject to the editor's > >>judgment on wording and > style): > >> > >>Add clause F.2.8 > >> > >>F.2.8 eapRemoteSuccess > > >> > >>The higher layer will give this signal a value after > > >>eapSuccess is set. This signal is ignored by the lower > >>layer if > eapFail is set. If this signal is set following > >>eapSuccess then > the policy of the higher layer is > >>completely satisfied and there > is no need to carry out > >>further authentication (no need to run the > 1X authenticator > >>machine). If this signal is reset following > setting of > >>eapSuccess then the policy of the higher layer requires > > >>that another authentication (initiated by the 1X > > >>authenticator) must occur to satisfy the policy. > >> > >>This > variable allows the higher layer to avoid initiating a > >>second > authentication session where the system would now > >>act as > authenticator and require the coupling of two > >>independent > authentications as described in 6.7. > >> > >>If eapRemoteSuccess is > set then Supplicants with this > >>indication may choose to set the > AuthControlledPortControl > >>management variable to ForceAuthorize in > order to avoid > >>initiating the subsequent authentication. If > > >>AuthControlledPortControl is set to ForceAuthorize, it must > >>be > set back to its original state if the supplicant state > >>machine > exits the authenticated state. > >> > >>If eapRemoteSuccess is reset > then Supplicants with this > >>indication may choose to set the > AuthControlledPortControl > >>management variable to Auto to ensure > the authenticator > >>machine initiates the subsequent authentication. > > >> > >>Note - Section 2.4 of RFC 2284bis describes several > > >>situations where coupling two authentications may be needed > >>but > is difficult to achieve. > >> > >>Add clause F.3.10 > >> > >>F.3.10 > eapRemoteSuccess > >> > >>The higher layer will give this signal a > value after > >>eapSuccess is set. This signal is ignored by the > lower > >>layer if eapFail is set. If this signal is set following > > >>eapSuccess then the policy of the higher layer is > >>completely > satisfied and there is no need to carry out > >>further authentication > (no need to run the 1X supplicant > >>machine). If this signal is > reset following setting of > >>eapSuccess then the policy of the > higher layer requires > >>that another authentication (initiated by > the 1X > >>supplicant) must occur to satisfy the policy. > >> > >>This > variable allows the higher layer to avoid or require a > >>second > authentication session where the system would now > >>act as > supplicant and require the coupling of two > >>independent > authentications as described in 6.7. > >> > >>If eapRemoteSuccess is > set then Authenticators with this > >>indication may choose to set the > SuppControlledPortControl > >>management variable to ForceAuthorize or > alternatively > >>activate the Supplicant Access Control With > Authenticator > >>management control. This will avoid initiating the > > >>subsequent authentication. If either variable is set, it > > >>must be set back to its original state if the authenticator > > >>state machine exits the authenticated state. > >> > >>If > eapRemoteSuccess is reset then Authenticators with this > >>indication > may choose to set the SuppControlledPortControl > >>management > variable to Auto or alternatively deactivate the > >>Supplicant Access > Control With Authenticator management > >>control. This will cause the > supplicant state machine to > >>initiate the subsequent > authentication. > >> > >>Note - Section 2.4 of RFC 2284bis describes > several > >>situations where coupling two authentications may be > needed > >>but is difficult to achieve. > >> > >>Comments welcome, > > >> > >>Paul Congdon & Jim Burns > >> > >>=>IEEE 802.1 Email List user > information: > >>http://www.ieee802.org/1/email-pages/ > >> > >> > > > > > > > > > > >=>IEEE 802.1 Email List user information: > >http://www.ieee802.org/1/email-pages/ > > ------------------------------------------------------------------------ > Send mobile Christmas cards, download a festive ringtone and win a > Motorola E365 Click here _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 16 05:34:57 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08626 for ; Fri, 16 Jan 2004 05:34:57 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8739F20200; Fri, 16 Jan 2004 05:24:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.frascone.com (Postfix) with ESMTP id E793E201FF for ; Fri, 16 Jan 2004 05:23:14 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0GAY2P24854 for ; Fri, 16 Jan 2004 12:34:02 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 16 Jan 2004 12:33:59 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 16 Jan 2004 12:33:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Proposed resolution of Issue 212: Protected Result Indications Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122361@esebe023.ntc.nokia.com> Thread-Topic: [eap] Proposed resolution of Issue 212: Protected Result Indications Thread-Index: AcPWKrHIH3KA/Y5+TQSaj+usgaTobAF6TxXA From: To: , X-OriginalArrivalTime: 16 Jan 2004 10:33:59.0050 (UTC) FILETIME=[402EA6A0:01C3DC1C] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 16 Jan 2004 12:33:57 +0200 Content-Transfer-Encoding: quoted-printable Bernard Aboba wrote: > OK. Here's the complete current text: >=20 > "Protected result indications > > A method provides result indications if after the method has > finished (1) if the peer is willing to use the access provided > by the authenticator, it knows whether the authenticator will > grant access (that is, only either an EAP-Success or > EAP-Failure will be accepted, no more method specific messages > are expected), and (2) if the authenticator decides to grant > access, it knows whether the peer will accept it. Result > indications improve resilience to packet loss; see Section 4.2 > for discussion. =20 I think the explanation "(that is, only either...)" is too strict. To avoid problems with packet loss, it's enough that=20 at no point both EAP-Success and EAP-Failure are possible. =20 For instance, the authenticator could send a method-specific failure message (e.g. TLS Alert) only when e.g. authorization fails, but EAP-Success otherwise (this saves one roundtrip in the successful case). So, I propose we change the text inside parenthesis to=20 "(that is, at no point both EAP-Success and EAP-Failure=20 are acceptable)". > Depending on the method and circumstances, result indications > can be spoofable by an attacker. A method is said to provide > protected result indications if it supports result indications > as well as the "integrity protection" and "replay protection" > claims. A method claiming to support protected result > indications MUST indicate which result indications are > protected, and which are not. See Section 7.16 for details." I still haven't seen any scenario which actually benefits from having _protected_ result indications. It also seems that most methods will protect only some result indications, not all. Given that "protected result indications" is listed as one=20 of the "security claims" for methods, I think Section 7.16=20 should offer some more guidance about what security implications=20 having them, not having them, or protecting only some indications=20 has. (If the only security implication is "very minor improvement to DoS resistance", I think we should probably leave them out... after all, there dozens of other ways an attacker could spoof or modify some packet to cause DoS, and we don't list those in "security claims" either.) Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 16 14:31:57 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25859 for ; Fri, 16 Jan 2004 14:31:56 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 814F920201; Fri, 16 Jan 2004 14:21:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.frascone.com (Postfix) with ESMTP id 0B59C201F2 for ; Fri, 16 Jan 2004 14:20:45 -0500 (EST) Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0GJVVGN025905; Fri, 16 Jan 2004 11:31:31 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.99.27]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 16 Jan 2004 11:37:14 -0800 From: "Joseph Salowey" To: , , Subject: RE: [eap] Proposed resolution of Issue 212: Protected Result Indications Message-ID: <003d01c3dc67$582b22b0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122361@esebe023.ntc.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 16 Jan 2004 19:37:15.0048 (UTC) FILETIME=[24E93A80:01C3DC68] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 16 Jan 2004 11:31:30 -0800 Content-Transfer-Encoding: 7bit I agree with Pasi that I'm not sure I see the value of protected result indicators. Especially given that they seem very difficult if not impoissible to implement in the real world. Even if the EAP method supports it authorization along the NAS-proxy path may take into account information that is not avaiable to process performing the EAP authentication. Joe > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Pasi.Eronen@nokia.com > Sent: Friday, January 16, 2004 2:34 AM > To: aboba@internaut.com; eap@frascone.com > Subject: RE: [eap] Proposed resolution of Issue 212: > Protected Result Indications > > > Bernard Aboba wrote: > > > OK. Here's the complete current text: > > > > "Protected result indications > > > > A method provides result indications if after the method > has finished > > (1) if the peer is willing to use the access provided by the > > authenticator, it knows whether the authenticator will grant access > > (that is, only either an EAP-Success or EAP-Failure will be > accepted, > > no more method specific messages are expected), and (2) if the > > authenticator decides to grant access, it knows whether the > peer will > > accept it. Result indications improve resilience to packet > loss; see > > Section 4.2 for discussion. > > I think the explanation "(that is, only either...)" is too > strict. To avoid problems with packet loss, it's enough that > at no point both EAP-Success and EAP-Failure are possible. > > For instance, the authenticator could send a method-specific > failure message (e.g. TLS Alert) only when e.g. authorization > fails, but EAP-Success otherwise (this saves one roundtrip in > the successful case). > > So, I propose we change the text inside parenthesis to > "(that is, at no point both EAP-Success and EAP-Failure > are acceptable)". > > > Depending on the method and circumstances, result > indications can be > > spoofable by an attacker. A method is said to provide > protected result > > indications if it supports result indications as well as the > > "integrity protection" and "replay protection" claims. A method > > claiming to support protected result indications MUST > indicate which > > result indications are protected, and which are not. See > Section 7.16 > > for details." > > I still haven't seen any scenario which actually benefits > from having _protected_ result indications. It also seems > that most methods will protect only some result indications, not all. > > Given that "protected result indications" is listed as one > of the "security claims" for methods, I think Section 7.16 > should offer some more guidance about what security implications > having them, not having them, or protecting only some indications > has. > > (If the only security implication is "very minor improvement > to DoS resistance", I think we should probably leave them > out... after all, there dozens of other ways an attacker > could spoof or modify some packet to cause DoS, and we don't > list those in "security claims" either.) > > Best regards, > Pasi > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 16 15:37:30 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28130 for ; Fri, 16 Jan 2004 15:37:30 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0E27320201; Fri, 16 Jan 2004 15:26:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id AE971201F2 for ; Fri, 16 Jan 2004 15:25:09 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i0GKoev27814; Fri, 16 Jan 2004 12:50:40 -0800 From: Bernard Aboba To: Joseph Salowey Cc: eap@frascone.com, jesse.walker@intel.com, waa@cs.umd.edu Subject: RE: [eap] Proposed resolution of Issue 212: Protected Result Indications In-Reply-To: <003d01c3dc67$582b22b0$0300000a@amer.cisco.com> Message-ID: References: <003d01c3dc67$582b22b0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 16 Jan 2004 12:50:40 -0800 (PST) Protected Result indications provide for synchronized state between the client and server. The lack of synchronized state was one of the issues brought up in research at the University of Maryland. This in turn lead to the work on the EAP state machine and RFC 2284bis. As demonstrated in the University of Maryland work, synchronized state is achievable in EAP methods that are designed carefully, and the improved resistance to rogue APs and DoS attacks is worth the effort. Of course, not every result indication can be protected, but that's not required for this to be useful. On Fri, 16 Jan 2004, Joseph Salowey wrote: > I agree with Pasi that I'm not sure I see the value of protected result > indicators. Especially given that they seem very difficult if not > impoissible to implement in the real world. Even if the EAP method > supports it authorization along the NAS-proxy path may take into account > information that is not avaiable to process performing the EAP > authentication. > > Joe _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 16 18:46:04 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05572 for ; Fri, 16 Jan 2004 18:46:04 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BD92520213; Fri, 16 Jan 2004 18:35:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id E6C462020F for ; Fri, 16 Jan 2004 18:34:20 -0500 (EST) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 16 Jan 2004 15:45:12 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id i0GNj5Qu007357; Fri, 16 Jan 2004 15:45:05 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.99.27]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 16 Jan 2004 15:50:48 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" Cc: , , Subject: RE: [eap] Proposed resolution of Issue 212: Protected Result Indications Message-ID: <005c01c3dc8a$c41e6630$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 16 Jan 2004 23:50:49.0126 (UTC) FILETIME=[91354C60:01C3DC8B] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 16 Jan 2004 15:45:04 -0800 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Protected Result indications provide for synchronized state > between the client and server. The lack of synchronized > state was one of the issues brought up in research at the > University of Maryland. This in turn lead to the work on the > EAP state machine and RFC 2284bis. > [Joe] I agree that synchronization is good EAP is good. Synchronization in EAP does not translate directly to synchronization of authorized state between peer and authenticator. Authorization may rely upon other factors outside of authentication. > As demonstrated in the University of Maryland work, > synchronized state is achievable in EAP methods that are > designed carefully, and the improved resistance to rogue APs > and DoS attacks is worth the effort. > [Joe] Perhaps in a very constrained environment. If you assume that the EAP is the only authorization mechanism then I can see this working. > Of course, not every result indication can be protected, but > that's not required for this to be useful. > [Joe] I agree with this. Synchronized state between EAP-Peer and EAP-Server is in general good. I do not think that this translates directly to synchronization between EAP-Peer and EAP-Authenticator authorization. I think this synchronization is achieved best by a mechanism outside of EAP. > On Fri, 16 Jan 2004, Joseph Salowey wrote: > >> I agree with Pasi that I'm not sure I see the value of protected >> result indicators. Especially given that they seem very difficult if >> not impoissible to implement in the real world. Even if the EAP >> method supports it authorization along the NAS-proxy path may take >> into account information that is not avaiable to process performing >> the EAP authentication. >> >> Joe _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 16 19:13:15 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06377 for ; Fri, 16 Jan 2004 19:13:14 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0D53720213; Fri, 16 Jan 2004 19:01:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id B00E72020F for ; Fri, 16 Jan 2004 19:00:41 -0500 (EST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0H0BNN9029810; Sat, 17 Jan 2004 09:11:23 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0H0BMLl011994; Sat, 17 Jan 2004 09:11:22 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id KAA11992 ; Sat, 17 Jan 2004 09:11:22 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id JAA20387; Sat, 17 Jan 2004 09:11:22 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id JAA19192; Sat, 17 Jan 2004 09:11:21 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0H0BKXD020462; Sat, 17 Jan 2004 09:11:21 +0900 (JST) Received: from steelhead ([159.119.168.169]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRL00L3NXUVUA@tsbpo1.po.toshiba.co.jp>; Sat, 17 Jan 2004 09:11:20 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Ahe1s-0004fL-00; Fri, 16 Jan 2004 16:09:32 -0800 From: Yoshihiro Ohba Subject: Re: [eap] Proposed resolution of Issue 212: Protected Result Indications In-reply-to: <005c01c3dc8a$c41e6630$0300000a@amer.cisco.com> To: Joseph Salowey Cc: "'Bernard Aboba'" , eap@frascone.com, jesse.walker@intel.com, waa@cs.umd.edu Message-id: <20040117000932.GC17343@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i References: <005c01c3dc8a$c41e6630$0300000a@amer.cisco.com> Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 16 Jan 2004 16:09:32 -0800 On Fri, Jan 16, 2004 at 03:45:04PM -0800, Joseph Salowey wrote: > > > Bernard Aboba wrote: > > Protected Result indications provide for synchronized state > > between the client and server. The lack of synchronized > > state was one of the issues brought up in research at the > > University of Maryland. This in turn lead to the work on the > > EAP state machine and RFC 2284bis. > > > [Joe] I agree that synchronization is good EAP is good. Synchronization > in EAP does not translate directly to synchronization of authorized > state between peer and authenticator. Authorization may rely upon > other factors outside of authentication. > > > As demonstrated in the University of Maryland work, > > synchronized state is achievable in EAP methods that are > > designed carefully, and the improved resistance to rogue APs > > and DoS attacks is worth the effort. > > > [Joe] Perhaps in a very constrained environment. If you assume that the > EAP is the only authorization mechanism then I can see this working. > > > Of course, not every result indication can be protected, but > > that's not required for this to be useful. > > > [Joe] I agree with this. Synchronized state between EAP-Peer and > EAP-Server is in general good. I do not think that this translates > directly to synchronization between EAP-Peer and EAP-Authenticator > authorization. I think this synchronization is achieved best by a > mechanism outside of EAP. I agree with Joe. As an example of an outside mechanism, the PANA protocol has a mechanism to carry EAP-Success/Failure message with acknowledged, and protected if key is available. Even when some AAA proxy finally denies an accept decision once has been made by the server, the pass-through authenticator can send a EAP-Failure which is carried by PANA with protected by using the established key, and the peer can interpret EAP-Failure as "authentication succeeded but authorization was finally rejected". Yoshihiro Ohba > > > > > On Fri, 16 Jan 2004, Joseph Salowey wrote: > > > >> I agree with Pasi that I'm not sure I see the value of protected > >> result indicators. Especially given that they seem very difficult if > >> not impoissible to implement in the real world. Even if the EAP > >> method supports it authorization along the NAS-proxy path may take > >> into account information that is not avaiable to process performing > >> the EAP authentication. > >> > >> Joe > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 16 19:31:13 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07233 for ; Fri, 16 Jan 2004 19:31:13 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 518E220213; Fri, 16 Jan 2004 19:19:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id C8A782020F for ; Fri, 16 Jan 2004 19:18:23 -0500 (EST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0H0T7N9005031; Sat, 17 Jan 2004 09:29:07 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0H0T77n019394; Sat, 17 Jan 2004 09:29:07 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id KAA19393 ; Sat, 17 Jan 2004 09:29:07 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id JAA26299; Sat, 17 Jan 2004 09:29:06 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id JAA16371; Sat, 17 Jan 2004 09:29:06 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0H0T5XD023244; Sat, 17 Jan 2004 09:29:05 +0900 (JST) Received: from steelhead ([159.119.168.169]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRL00M0OYOF0U@tsbpo1.po.toshiba.co.jp>; Sat, 17 Jan 2004 09:29:04 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AheK9-0004hk-00; Fri, 16 Jan 2004 16:28:25 -0800 From: Yoshihiro Ohba Subject: Re: [eap] Proposed resolution of Issue 212: Protected Result Indications In-reply-to: <20040117000932.GC17343@steelhead> To: Joseph Salowey Cc: "'Bernard Aboba'" , eap@frascone.com, jesse.walker@intel.com, waa@cs.umd.edu Message-id: <20040117002825.GD17343@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i References: <005c01c3dc8a$c41e6630$0300000a@amer.cisco.com> <20040117000932.GC17343@steelhead> Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 16 Jan 2004 16:28:25 -0800 Sorry for self-replying: On Fri, Jan 16, 2004 at 04:09:32PM -0800, Yoshihiro Ohba wrote: > > [Joe] I agree with this. Synchronized state between EAP-Peer and > > EAP-Server is in general good. I do not think that this translates > > directly to synchronization between EAP-Peer and EAP-Authenticator > > authorization. I think this synchronization is achieved best by a > > mechanism outside of EAP. > > I agree with Joe. As an example of an outside mechanism, the PANA > protocol has a mechanism to carry EAP-Success/Failure message with > acknowledged, and protected if key is available. Even when some AAA > proxy finally denies an accept decision once has been made by the > server, the pass-through authenticator can send a EAP-Failure which is > carried by PANA with protected by using the established key, and the > peer can interpret EAP-Failure as "authentication succeeded but > authorization was finally rejected". "EAP-Success/Failure" should read as "PANA result indication". Yoshihiro Ohba _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 16 21:35:57 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10217 for ; Fri, 16 Jan 2004 21:35:56 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2434420215; Fri, 16 Jan 2004 21:25:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id E1A332020F for ; Fri, 16 Jan 2004 21:24:01 -0500 (EST) Subject: Re: [eap] network selection From: Alper Yegin To: , "eap@frascone.com" Message-ID: In-Reply-To: <3FFFEDEF.1030001@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 16 Jan 2004 18:34:43 -0800 Content-Transfer-Encoding: 7bit Hello Jari, Thank you for capturing this discussion. I have some comments, please see below... First, there is the problem of "Access Network discovery". This is the problem of discovering access networks available in the vicinity, and the points of presence (POPs) associated with those networks. In PANA we borrowed two terms from the DSL networks, NAP (Network Access Provider) and ISP. NAP is the owner/operator of the access infrastructure (such as the WLAN AP in the coffee shop). It provides L2 access to the clients and connect them to their ISP. ISP should have a business agreement with the NAP for this "roaming" service. I think our "ISP" corresponds to your "Access network"? And what is the "home network" then? If we are talking about general "access network discovery", I think it would involve discovering both NAPs and their associated (serviced) ISPs in my client's vicinity. I think we are more interested in the latter part of the problem. Referring to Figure 2: In this figure, the user "joe@corp3.com" has to be authenticated through ISP 2, since the domain "corp3.com" is served by it. I think another way to read this is "All the employees of corp3.com has an account with ISP2 under their name. When they connect to ISP2, their traffic is VPN'ed to the corporate network". Right? There has been requests to place credential and AAA route selection under user control, as the user is affected by the pricing and other differences. I don't think this is necessary. I should only care about my ISP selection, and be able to trust my ISP to figure out the best AAA route for me (in figure 3, isp1.com is aware of both paths). If the access network is trying to rip me off, my ISP should be able to catch that. And if my ISP is ripping me off, oh well..... Regarding the attack on 2.4.1: I think this is a combined issue of network identity theft in the absence of unprotected or unverified discovery, and bandwidth reselling. These can be issues on their own even when separated. I don't think the combination has an effect here. Basically, if the "rogue" access point has a flat fee account and a contract with a clearing house, it can offer access to anyone with a per-byte account, NAT their packets, and send the traffic forward on its own account, and generate income. And this is just one way to provide a legitimate service, given that the upstream service provider legally allows you to resell the bandwidth. If you are using someone else's network name to lure clients in, this is a separate issue. However, IPsec could be used to detect the presence of such NATs, even if NAT traversal is in use. There wouldn't be any needs for NAT when a /64 IPv6 prefixes are delegated to mobile clients. So, relying on NAT detection is not sufficient. Similarly, the IEEE 802.1af has discussed the idea of supporting network discovery within a future revision to IEEE 802.1X. Supporting this functionality in the EAP lower layer seems logical to me. This is what we did with the PANA design. In the IETF, a potential alternative is use of the SEAMOBY CARD protocol [13], which enables advertisement of network device capabilities over IP. Another alternative is the recently proposed Device Discovery Protocol (DDP) [12], which provides functionality equivalent to IEEE 802.1ab using ASN.1 encoded advertisements sent to a link-local scope multicast address. Using CARD lets you collect information about the networks in your client's vicinity. These are the potential points of attachments upon movement. I think the use of DDP can be similar (if, access points are in the same subnet). Neither is about discovering and selecting an immediate access network. I think it is worth mentioning PANA in here, where this selection takes place during the network access AAA (before client engages in authentication). The representation of link layer parameters within EAP should utilize a common framework, to make it easier to define new link layers and keep the selection of EAP methods independent of the link layer. ... The security requirements for network discovery depend on the type of information being discovered. Some of the parameters may have a security impact, such as the claimed name of the network the user tries to attach to. Unfortunately, current EAP methods do not always make the verification of such parameters possible. I think hosting these functionalities in the EAP lower layer is a better approach. Alper _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From lgknews@mail.com Sat Jan 17 22:37:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25748 for ; Sat, 17 Jan 2004 22:37:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ai3kP-00058m-00 for eap-archive@ietf.org; Sat, 17 Jan 2004 22:37:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ai3hU-00052o-00 for eap-archive@ietf.org; Sat, 17 Jan 2004 22:34:13 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ai3gO-0004ze-00; Sat, 17 Jan 2004 22:33:04 -0500 Received: from [209.58.115.177] (helo=ietf.org) by mx2.foretec.com with smtp (Exim 4.24) id 1Ai3fH-0006sa-VW; Sat, 17 Jan 2004 22:31:59 -0500 From: "Memorial Cubano:" To: discuss-web-archive@ietf.org Subject: Pedem Missas e orações pelas vítimas do comunismo ref.: ire User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Sat, 17 Jan 2004 22:31:59 -0500 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.9 required=5.0 tests=AWL,HTML_40_50,HTML_FONT_BIG, HTML_MESSAGE,MAILTO_SUBJ_REMOVE,MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,REMOVE_REMOVAL_2WORD, SUBJ_HAS_SPACES,SUBJ_ILLEGAL_CHARS autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters * 0.0 AWL AWL: Auto-whitelist adjustment

Ref.: (ijk) InEnglish / InItaliano / EnCastellano

Memorial cubano: Pedido de Missas e orações pelas vítimas do comunismo

A ajuda urgente que solicitamos é de caráter estritamente espiritual, ao alcance de cada um e, sem dúvida, a mais valiosa aos olhos de Deus

Queridos irmãos luso-brasileiros,

* Precisamos de vossa valiosa ajuda para resgatar do esquecimento a mais de 10 mil cubanos que morreram vítimas do regime comunista, sobre os quais se possui informação documentada. Esta ajuda que lhes solicitamos é de caráter estritamente espiritual, inteiramente ao alcance de cada um e, sem dúvida, a mais valiosa aos olhos de Deus!

* Entre os dias 20 e 23 de fevereiro próximo, no Tamiami Park de Miami, Flórida, voluntários de diversos países organizarão o Memorial Cubano, consistente em mais de 10 mil cruzes brancas, cada uma delas tendo inscrito o nome de uma vítima do regime comunista de Cuba. Familiares desterrados que nunca puderam dar o adeus a seus seres queridos assassinados, por não ser-lhes permitido visitar suas tumbas em Cuba, poderão fazê-lo agora.

* No centro da área se localizará uma cruz de madeira gigante, também pintada de branco, denominada "Cruz da vítima desconhecida", que constituirá o reconhecimento a todos os que morreram por causa do regime comunista, porém a respeito dos quais até o momento não se possui informação suficiente.

* De que maneira vocês podem unir-se a esta cruzada de orações e a esta homenagem espiritual? Simplesmente encomendando uma Missa ou serviço religioso, organizando com sua família, comunidade ou colegas de trabalho um momento de oração conjunta, ou rezando privadamente. Solicitamos-lhes que as Missas sejam encomendadas, se for possível, para o domingo 22 de fevereiro. Assim, no mundo inteiro, nesse dia se elevarão preces a Deus pelo eterno descanso dessas almas. Poderão encomendá-las em benefício das "vítimas do genocídio cubano sob o regime comunista de Fidel Castro".

* Muitas destas vítimas foram jovens que enfrentaram o "paredón" de fuzilamento proclamando "Viva Cristo Rei!"

* Confirmem-nos o quanto antes vossa adesão, encomendando Missas, prometendo orações, etc., fazendo clic em:

ConfirmamosMissa/ServicoReligioso e/ou ConfirmamosOraçoesPreces incluindo local, data e, se o desejarem, outros detalhes.

* Irmãos ibero-americanos e homens e mulheres de boa vontade, de outras regiões do mundo, que leiam esta mensagem e a ela adiram: que a Providência os recompense com o cêntuplo já nesta terra!

Com a maior consideração e estima,

Renato Gómez - Coordenador Geral

Comitê Organizador do Memorial Cubano

Tel. (1-786) 621-7505 Miami (FL) www memorialcubano org

PS.:

Em vossas orações e preces incluam também os homens, mulheres e crianças que morreram afogados no estreito da Flórida, tentando alcançar a liberdade. Seus nomes são em sua maioria desconhecidos e fontes autorizadas estimam que o número deles seja de muitas dezenas de milhares de cubanos.

Por fim, rezem pelos presos políticos que agonizam nos cárceres, como o médico Oscar Elias Biscet, pela economista Martha Beatriz Roque e milhares de outros irmãos cubanos detidos DesejoInfoPresosPoliticos. A seis anos da viagem de S.S. João Paulo II a Cuba (21-25 de janeiro de 1998), se continua contrariando o sonho papal de que a ilha-cárcere abra-se ao mundo.

LINKS PRIORITÁRIOS:

ConfirmoMissa/ServiçoReligioso e/ou ConfirmoOraçoesPreces (incluindo nome, cidade e, se desejar, outros detalhes)

MinhaAjuda (narre de que maneira poderá ajudar-nos a difundir esta iniciativa espiritual e humanitária: reenviando esta notícia a seus amigos, levando-a a jornalistas conhecidos, colocando-a no quadro de avisos de seu local de trabalho, etc.; pode incluir também sugestões).

MinhaOpiniao

OUTROS LINKS:

DesejoRecibirLinkMemorialCubano (para receber o link do web site sobre o Memorial Cubano, com nomes de todas as vítimas)

DesejoReceberInfoPresosPoliticos

ProximosEnvios:SoloEnEspañol

NextMails:OnlyInEnglish

Remover

A difusão deste e-mail é de exclusiva responsabilidade da agência humanitária Derechos Sin Fronteras (DSF).

Tradução: Graça Salgueiro

 

 

From eap-admin@frascone.com Sun Jan 18 21:30:14 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12523 for ; Sun, 18 Jan 2004 21:30:14 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 176D3201F6; Sun, 18 Jan 2004 21:19:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by mail.frascone.com (Postfix) with ESMTP id 5262120149 for ; Sun, 18 Jan 2004 21:18:08 -0500 (EST) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0J2UIGd015020 for ; Mon, 19 Jan 2004 02:30:18 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0J2Tm6s028267 for ; Mon, 19 Jan 2004 02:29:48 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011818285912834 for ; Sun, 18 Jan 2004 18:28:59 -0800 Received: from orsmsx401.amr.corp.intel.com ([192.168.65.207]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 18 Jan 2004 18:28:59 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [eap] network selection Message-ID: Thread-Topic: [eap] network selection Thread-Index: AcPcoqkuTsRc5+f1S36FnYecttdi9ABj8+Lw From: "Lortz, Victor" To: X-OriginalArrivalTime: 19 Jan 2004 02:28:59.0668 (UTC) FILETIME=[FED69540:01C3DE33] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 18 Jan 2004 18:28:59 -0800 Content-Transfer-Encoding: quoted-printable Alper, you are assuming that there is a direct roaming agreement between the user's home ISP and the NAP (using PANA terminology). 3GPP is also interested in scenarios in which there is no direct relationship. Instead, there is an intermediary "broker" network such as an aggregator (or in 3GPP parlance, a VPLMN) that has roaming agreements with the other two. In this context, especially if there is more than one candidate intermediary, the user may wish to discover and subsequently designate a preferred intermediary. =20 Best Regards, Vic -----Original Message----- From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf Of Alper Yegin Sent: Friday, January 16, 2004 6:35 PM To: jari.arkko@piuha.net; eap@frascone.com Subject: Re: [eap] network selection Hello Jari, Thank you for capturing this discussion. I have some comments, please see below... First, there is the problem of "Access Network discovery". This is the problem of discovering access networks available in the vicinity, and the points of presence (POPs) associated with those networks.=20 In PANA we borrowed two terms from the DSL networks, NAP (Network Access Provider) and ISP. NAP is the owner/operator of the access infrastructure (such as the WLAN AP in the coffee shop). It provides L2 access to the clients and connect them to their ISP. ISP should have a business agreement with the NAP for this "roaming" service. I think our "ISP" corresponds to your "Access network"? And what is the "home network" then? If we are talking about general "access network discovery", I think it would involve discovering both NAPs and their associated (serviced) ISPs in my client's vicinity. I think we are more interested in the latter part of the problem. Referring to Figure 2: In this figure, the user "joe@corp3.com" has to be authenticated through ISP 2, since the domain "corp3.com" is served by it. I think another way to read this is "All the employees of corp3.com has an account with ISP2 under their name. When they connect to ISP2, their traffic is VPN'ed to the corporate network". Right? There has been requests to place credential and AAA route selection under user control, as the user is affected by the pricing and other differences. I don't think this is necessary. I should only care about my ISP selection, and be able to trust my ISP to figure out the best AAA route for me (in figure 3, isp1.com is aware of both paths). If the access network is trying to rip me off, my ISP should be able to catch that. And if my ISP is ripping me off, oh well..... Regarding the attack on 2.4.1: I think this is a combined issue of network identity theft in the absence of unprotected or unverified discovery, and bandwidth reselling. These can be issues on their own even when separated. I don't think the combination has an effect here. Basically, if the "rogue" access point has a flat fee account and a contract with a clearing house, it can offer access to anyone with a per-byte account, NAT their packets, and send the traffic forward on its own account, and generate income. And this is just one way to provide a legitimate service, given that the upstream service provider legally allows you to resell the bandwidth. If you are using someone else's network name to lure clients in, this is a separate issue.=20 However, IPsec could be used to detect the presence of such NATs, even if NAT traversal is in use. There wouldn't be any needs for NAT when a /64 IPv6 prefixes are delegated to mobile clients. So, relying on NAT detection is not sufficient. Similarly, the IEEE 802.1af has discussed the idea of supporting network discovery within a future revision to IEEE 802.1X. Supporting this functionality in the EAP lower layer seems logical to me. This is what we did with the PANA design. In the IETF, a potential alternative is use of the SEAMOBY CARD protocol [13], which enables advertisement of network device capabilities over IP. Another alternative is the recently proposed Device Discovery Protocol (DDP) [12], which provides functionality equivalent to IEEE 802.1ab using ASN.1 encoded advertisements sent to a link-local scope multicast address. Using CARD lets you collect information about the networks in your client's vicinity. These are the potential points of attachments upon movement. I think the use of DDP can be similar (if, access points are in the same subnet). Neither is about discovering and selecting an immediate access network. I think it is worth mentioning PANA in here, where this selection takes place during the network access AAA (before client engages in authentication).=20 The representation of link layer parameters within EAP should utilize a common framework, to make it easier to define new link layers and keep the selection of EAP methods independent of the link layer. ... The security requirements for network discovery depend on the type of information being discovered. Some of the parameters may have a security impact, such as the claimed name of the network the user tries to attach to. Unfortunately, current EAP methods do not always make the verification of such parameters possible. I think hosting these functionalities in the EAP lower layer is a better approach. Alper _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Jan 19 12:35:18 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28852 for ; Mon, 19 Jan 2004 12:35:18 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6F67F201F8; Mon, 19 Jan 2004 12:23:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 78864201F6 for ; Mon, 19 Jan 2004 12:22:46 -0500 (EST) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 19 Jan 2004 09:36:43 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0JHXZGN020589 for ; Mon, 19 Jan 2004 09:33:36 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.99.27]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 19 Jan 2004 09:39:21 -0800 From: "Joseph Salowey" To: Message-ID: <00e601c3deb2$5db69e60$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 19 Jan 2004 17:39:21.0259 (UTC) FILETIME=[2BD7EFB0:01C3DEB3] Subject: [eap] [Issue ] EMSK usage guidelines Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 19 Jan 2004 09:33:34 -0800 Content-Transfer-Encoding: 7bit Guidelines for the usage of the EMSK Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date first submitted: 1/19/2004 Reference: Document: Keying Framework Comment type: 'T' Technical Priority: 'S' Section: Section 2.4 and Section 5 Rationale/Explanation of issue: Guidelines need to be set for the usage of the EMSK material. Suggested text from draft-salowey-eap-key-deriv-02.txt 2.4 Requirements for EMSK usage EAP reserves a portion of keying material, called the EMSK, for extended uses. Keys derived from this key material may be used to key applications on different devices and different processes separate from the entity that receives the MSK. If the keying material is used to provide keys for multiple Applications or devices, it is desired that the keys will be cryptographically separate. Cryptographic separation means that knowledge of one key does not provide an easy way to determine another key derived from the same key material. This is also known as computationally independent. This section provides guidelines for a mechanism which can be used with existing and new EAP methods and applications to provide cryptographic separation between keys derived for different applications and devices. These derived keys are referred to in this section as Application Master Session Keys or AMSK. 2.4.1 Requirements for EAP methods In order for an EAP method to meet the guidelines for EMSK usage it must meet the following requirements. o It must specify how to derive the EMSK o The key material used for the EMSK MUST be computationally independent of the MSK and TEKs. o The EMSK MUST NOT be used for any other purpose than the key derivation described in this document. o The EMSK MUST be secret and not known to someone observing the authentication mechanism protocol exchange. o The EMSK MUST be maintained within the EAP server. Only keys (AMSKs) derived according to this specification may be exported from the EAP server. o The EMSK MUST be unique for each session. o The EAP mechanism SHOULD provide a way of naming the EMSK. Implementations of EAP frameworks on the EAP-Peer and EAP-Server SHOULD provide an interface to obtain AMSKs. The implementation MAY restrict which callers can obtain which keys. 2.4.2 Requirements for EAP applications In order for an application to meet the guidelines for EMSK usage it must meet the following, o The application MAY use the MSK transmitted to the NAS in any way it chooses. This is required for backward compatibility. New applications following this specification SHOULD NOT use the MSK. If more than one application uses the MSK, then the cryptographic separation is not achieved. Implementations SHOULD prevent such combinations. o The application MUST NOT use the EMSK in any other way except to derive Application Master Session Keys (AMSK) using the key derivation specified in this document. It MUST NOT use the EMSK directly for cryptographic protection of data. o Applications MUST define distinct key labels, application specific data, length of derived key material used in the key derivation described in section 2.4.3. o Applications MUST define how they use their AMSK to derive TSKs for their use. 2.4.3 EAP AMSK Key Derivation The EAP EMSK usage guidelines provide a means for generating multiple application-specific master keys (AMSKs). These AMSKs are then used to derive transient session keys (TSKs), which are used as actual ciphering keys. This allows multiple applications to use keys independently derived from the EAP method. The EAP EMSK usage guidelines AMSK key derivation function (KDF) derives an AMSK from the Extended Master Session Key (EMSK) described above, an application key label, optional application data, and output length. AMSK = KDF(EMSK, key label, optional application data, length) The key labels are printable ASCII strings unique for each application (see Section 5 for IANA Considerations). Additional ciphering keys (TSKs) can be derived from the AMSK using an application specific key derivation mechanism. In many cases, this AMSK->TSK derivation can simply split the AMSK to pieces of correct length. In particular, it is not necessary to use a cryptographic one-way function. Note that the length of the AMSK must be specified by the application. 2.4.3.1 The EAP AMSK Key Derivation Function The EAP key derivation function is taken from the PRF+ key expansion PRF from [IKEv2]. This KDF takes 4 parameters as input: secret, label, application data, and output length. It is only defined for 255 iterations so it may produce up to 5100 bytes of key material. For the purposes of this specification the secret is taken as the EMSK, the label is the key label described above concatenated with a NUL byte, the application data is also described above and the output length is two bytes. The application data is optional and may not be used by some applications. The KDF is based on HMAC-SHA1 [RFC2104] [SHA1]. For this specification we have: KDF (K,L,D,O) = T1 | T2 | T3 | T4 | ... where: T1 = prf (K, S | 0x01) T2 = prf (K, T1 | S | 0x02) T3 = prf (K, T2 | S | 0x03) T4 = prf (K, T3 | S | 0x04) prf = HMAC-SHA1 K = EMSK L = key label D = application data O = OutputLength (2 bytes) S = L | "\0" | D | O The prf+ construction was chosen because of its simplicity and efficiency over other PRFs such as those used in [TLS]. The motivation for the design of this PRF is described in [SIGMA]. The NUL byte after the key label is used to avoid collisions if one key label is a prefix of another label (e.g. "foobar" and "foobarExtendedV2"). This is considered a simpler solution than requiring a key label assignment policy that prevents prefixes from occurring. 5. IANA Considerations This specification introduces a new name space for "key labels". Key labels are ASCII strings and are assigned on a first come first served basis. It is RECOMMENDED that a reference to a specification that provides the following information o A description of the application o The key label to be used o How TSKs will be derived from the AMSK and how they will be used o If application specific data is used, what it is and how it is maintained o Where the AMSKs or TSKs will be used and how they are communicated if necessary. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Jan 19 13:09:18 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00258 for ; Mon, 19 Jan 2004 13:09:18 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 79E2E201F8; Mon, 19 Jan 2004 12:57:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from smtp.um.es (xenon2.um.es [155.54.212.101]) by mail.frascone.com (Postfix) with ESMTP id 9BF8B201F6 for ; Mon, 19 Jan 2004 12:56:01 -0500 (EST) Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 9CF3934A98; Mon, 19 Jan 2004 19:06:54 +0100 (CET) Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by smtp.um.es (Postfix) with ESMTP id 8617E34A27; Mon, 19 Jan 2004 19:06:54 +0100 (CET) Received: from dif.um.es (bravecard.dif.um.es [155.54.210.47]) by aries.dif.um.es (Postfix) with ESMTP id 4E0CB14426; Mon, 19 Jan 2004 18:53:28 +0100 (MET) Message-ID: <400C1C30.3060306@dif.um.es> From: =?ISO-8859-1?Q?Rafa_Mar=EDn_L=F3pez?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Accept-Language: en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Rafa_Mar=EDn_L=F3pez?= Cc: eap@frascone.com Subject: [eap] EAP Key Management Framework doubt References: <40059307.5050100@dif.um.es> In-Reply-To: <40059307.5050100@dif.um.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 19 Jan 2004 19:04:32 +0100 Content-Transfer-Encoding: 8bit Rafa Marín López wrote: > Hello all > > I am reading EAP Key Management Framework draft... and I am a bit > confused ... > > Figure 4 shows that MSK is placed on Authenticator but only AAA-key is > transported from AAA server... ¿? ... furthermore the text tells MSK > is transported to Authenticator... in another places AAA-key is > carried ... I think it would be better to say : AAA - key is carried > to authenticator and it could be the MSK (as appendix E tells)... what > do you think? > > Regard. > -- ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------ _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Jan 19 13:47:09 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01574 for ; Mon, 19 Jan 2004 13:47:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 38866201F8; Mon, 19 Jan 2004 13:36:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 9603E201F6 for ; Mon, 19 Jan 2004 13:35:20 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i0JJ0gm28586; Mon, 19 Jan 2004 11:00:42 -0800 From: Bernard Aboba To: eap@frascone.com, stds-802-1@ieee.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Discrepancies between 802.1XREV and RFC 2248bis Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 19 Jan 2004 11:00:42 -0800 (PST) I just reread RFC 2284bis section 2.4 and 802.1XREV Section 6.7, and they seem miles apart. This needs to be resolved before 802.1X-REV is published. Here is my reading of the differences and what needs to be done to fix them: a. Section 6.7 of 802.1X-REV indicates that EAP authentication can only be uni-directional. RFC 2284bis Section 2.4 states the conditions under which bi-directional authentication is achievable. Since 802.1X-REV now leaves authentication to EAP, it is not possible for IEEE 802 encapsulation to change the fundamental properties of EAP, so the two specs cannot disagree on this point. b. Section 6.7 appears to assume (contrary to recent discussion) that there is no way for the AAA server or higher layer to communicate the peer decision down to the lower layer on the authenticator side. Given the new interface variables and discussion on AAA key implications, I think we've settled this issue. While I'm ok with not changing 802.1X-REV to discuss the new interface variables or AAA implications (this can go in the EAP State Machine document), I do think that the implications for the text of Section 6.7 do need to be addresssed. To fix these issues, it would probably be best if Section 6.7 referenced RFC 2284bis Section 2.4 and removed the paragraphs that appear to contradict RFC 2284bis. Given that 802.1X-REV is entering sponsor ballot, it is relatively late for these fixes to be put in -- but I fear that if the changes are not made now the pain will be much greater down the line, particularly since 802.1af appears to want to address some of the same peer-to-peer issues. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Jan 19 15:07:07 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05438 for ; Mon, 19 Jan 2004 15:07:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 02A5220217; Mon, 19 Jan 2004 14:56:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from reformers.mr.itd.umich.edu (reformers.mr.itd.umich.edu [141.211.93.147]) by mail.frascone.com (Postfix) with ESMTP id E3473201F6 for ; Mon, 19 Jan 2004 14:55:54 -0500 (EST) Received: from dhcp60-09.merit.edu (dhcp60-09.merit.edu [198.108.60.209]) by reformers.mr.itd.umich.edu (smtp) with ESMTP id i0JK6dcJ017620; Mon, 19 Jan 2004 15:06:40 -0500 From: John Vollbrecht To: Joseph Salowey , "'Bernard Aboba'" Cc: eap@frascone.com, jesse.walker@intel.com, waa@cs.umd.edu Subject: RE: [eap] Proposed resolution of Issue 212: Protected Result Indications Message-ID: <576563.1074524795@dhcp60-09.merit.edu> In-Reply-To: <005c01c3dc8a$c41e6630$0300000a@amer.cisco.com> References: <005c01c3dc8a$c41e6630$0300000a@amer.cisco.com> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 19 Jan 2004 15:06:35 -0500 Content-Transfer-Encoding: 7bit --On Friday, January 16, 2004 3:45 PM -0800 Joseph Salowey wrote: > > > Bernard Aboba wrote: > > Protected Result indications provide for synchronized state > > between the client and server. The lack of synchronized > > state was one of the issues brought up in research at the > > University of Maryland. This in turn lead to the work on the > > EAP state machine and RFC 2284bis. > > > [Joe] I agree that synchronization is good EAP is good. Synchronization > in EAP does not translate directly to synchronization of authorized > state between peer and authenticator. Authorization may rely upon > other factors outside of authentication. > > > As demonstrated in the University of Maryland work, > > synchronized state is achievable in EAP methods that are > > designed carefully, and the improved resistance to rogue APs > > and DoS attacks is worth the effort. > > > [Joe] Perhaps in a very constrained environment. If you assume that the > EAP is the only authorization mechanism then I can see this working. > > > Of course, not every result indication can be protected, but > > that's not required for this to be useful. > > > [Joe] I agree with this. Synchronized state between EAP-Peer and > EAP-Server is in general good. I do not think that this translates > directly to synchronization between EAP-Peer and EAP-Authenticator > authorization. I think this synchronization is achieved best by a > mechanism outside of EAP. > > I think Joe's point that there may be authorization outside EAP is pretty strong. In some environments it may be possible for an EAP method to succeed but the authenticated user may be refused. Thus it would seem to be possible to get an Access Reject and an EAP Success. I think what this means is that the Access Point pass the EAP Success, but the AP will also refuse to turn on the port. If this is the case, then I think that the EAP method is used to authenticate the request, but it may be refused for other reasons. The fact that an EAP method can succeed while the authorization fails seems ok to me. It means that one port may be turned on while the other is not. For 802.1X this may cause llong timeouts. My thinking right now at least is that this is a problem with 802.1X because it does not have a way to tell the other side that it failed. Perhaps I am missing something? > > > On Fri, 16 Jan 2004, Joseph Salowey wrote: > > > >> I agree with Pasi that I'm not sure I see the value of protected > >> result indicators. Especially given that they seem very difficult if > >> not impoissible to implement in the real world. Even if the EAP > >> method supports it authorization along the NAS-proxy path may take > >> into account information that is not avaiable to process performing > >> the EAP authentication. > >> > >> Joe > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Jan 19 15:17:00 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06363 for ; Mon, 19 Jan 2004 15:16:59 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8827B20207; Mon, 19 Jan 2004 15:06:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 0EEC1201F6 for ; Mon, 19 Jan 2004 15:05:52 -0500 (EST) Subject: Re: [eap] network selection From: Alper Yegin To: "Lortz, Victor" , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 19 Jan 2004 12:16:37 -0800 Content-Transfer-Encoding: 7bit Hello Victor, > Alper, you are assuming that there is a direct roaming agreement between > the user's home ISP and the NAP (using PANA terminology). 3GPP is also > interested in scenarios in which there is no direct relationship. > Instead, there is an intermediary "broker" network such as an aggregator > (or in 3GPP parlance, a VPLMN) that has roaming agreements with the > other two. In this context, especially if there is more than one > candidate intermediary, the user may wish to discover and subsequently > designate a preferred intermediary. Actually I'm not denying the possibility of a multi-hop AAA routing between the NAP and ISP. All I'm saying is this topology and its associated management is better handled by the servers running the AAA protocols (RADIUS, Diameter). Not by the user's host. Doing otherwise would complicate the host, and I'm not sure if this is necessary. The problem is similar to datagram routing. The host only knows its default gateway and the final destination for its data traffic. The intermediate routing is handled by the routers. Alper > > Best Regards, > Vic > > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf > Of Alper Yegin > Sent: Friday, January 16, 2004 6:35 PM > To: jari.arkko@piuha.net; eap@frascone.com > Subject: Re: [eap] network selection > > Hello Jari, > > Thank you for capturing this discussion. > > I have some comments, please see below... > > First, there is the problem of "Access Network discovery". This > is the problem of discovering access networks available in the > vicinity, and the points of presence (POPs) associated with those > networks. > > In PANA we borrowed two terms from the DSL networks, NAP (Network Access > Provider) and ISP. NAP is the owner/operator of the access > infrastructure > (such as the WLAN AP in the coffee shop). It provides L2 access to the > clients and connect them to their ISP. ISP should have a business > agreement > with the NAP for this "roaming" service. > > I think our "ISP" corresponds to your "Access network"? And what is the > "home network" then? > > If we are talking about general "access network discovery", I think it > would > involve discovering both NAPs and their associated (serviced) ISPs in my > client's vicinity. I think we are more interested in the latter part of > the > problem. > > Referring to Figure 2: > > In this > figure, the user "joe@corp3.com" has to be authenticated through ISP > 2, since the domain "corp3.com" is served by it. > > I think another way to read this is "All the employees of corp3.com has > an > account with ISP2 under their name. When they connect to ISP2, their > traffic > is VPN'ed to the corporate network". Right? > > > There has been requests to place credential and AAA route selection > under user control, as the user is affected by the pricing and other > differences. > > I don't think this is necessary. I should only care about my ISP > selection, > and be able to trust my ISP to figure out the best AAA route for me (in > figure 3, isp1.com is aware of both paths). If the access network is > trying > to rip me off, my ISP should be able to catch that. And if my ISP is > ripping > me off, oh well..... > > Regarding the attack on 2.4.1: I think this is a combined issue of > network > identity theft in the absence of unprotected or unverified discovery, > and > bandwidth reselling. These can be issues on their own even when > separated. I > don't think the combination has an effect here. > > Basically, if the "rogue" access point has a flat fee > account and a contract with a clearing house, it can offer access to > anyone with a per-byte account, NAT their packets, and send the > traffic forward on its own account, and generate income. > > And this is just one way to provide a legitimate service, given that the > upstream service provider legally allows you to resell the bandwidth. If > you > are using someone else's network name to lure clients in, this is a > separate > issue. > > However, IPsec could be used to detect the > presence of such NATs, even if NAT traversal is in use. > > There wouldn't be any needs for NAT when a /64 IPv6 prefixes are > delegated > to mobile clients. So, relying on NAT detection is not sufficient. > > Similarly, the IEEE 802.1af has discussed the > idea of supporting network discovery within a future revision to > IEEE 802.1X. > > Supporting this functionality in the EAP lower layer seems logical to > me. > This is what we did with the PANA design. > > In the IETF, a potential alternative is use of the SEAMOBY CARD > protocol [13], which enables advertisement of network device > capabilities over IP. Another alternative is the recently > proposed Device Discovery Protocol (DDP) [12], which provides > functionality equivalent to IEEE 802.1ab using ASN.1 encoded > advertisements sent to a link-local scope multicast address. > > Using CARD lets you collect information about the networks in your > client's > vicinity. These are the potential points of attachments upon movement. I > think the use of DDP can be similar (if, access points are in the same > subnet). Neither is about discovering and selecting an immediate access > network. I think it is worth mentioning PANA in here, where this > selection > takes place during the network access AAA (before client engages in > authentication). > > The representation of link layer parameters within EAP > should utilize a common framework, to make it easier to define new > link layers and keep the selection of EAP methods independent of the > link layer. > > ... > > The security requirements for network discovery depend on the type of > information being discovered. Some of the parameters may have a > security impact, such as the claimed name of the network the user > tries to attach to. Unfortunately, current EAP methods do not always > make the verification of such parameters possible. > > I think hosting these functionalities in the EAP lower layer is a better > approach. > > Alper > > > > > > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Jan 19 16:10:21 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08751 for ; Mon, 19 Jan 2004 16:10:21 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7D60F20207; Mon, 19 Jan 2004 15:58:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from struggle.mr.itd.umich.edu (struggle.mr.itd.umich.edu [141.211.14.79]) by mail.frascone.com (Postfix) with ESMTP id 316DA201F6 for ; Mon, 19 Jan 2004 15:57:24 -0500 (EST) Received: from dhcp60-09.merit.edu (dhcp60-09.merit.edu [198.108.60.209]) by struggle.mr.itd.umich.edu (smtp) with ESMTP id i0JL8G0b023874; Mon, 19 Jan 2004 16:08:17 -0500 From: John Vollbrecht To: Bernard Aboba , eap@frascone.com, stds-802-1@ieee.org Subject: Re: [eap] Discrepancies between 802.1XREV and RFC 2248bis Message-ID: <798379.1074528492@dhcp60-09.merit.edu> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 19 Jan 2004 16:08:12 -0500 Content-Transfer-Encoding: 7bit --On Monday, January 19, 2004 11:00 AM -0800 Bernard Aboba wrote: > I just reread RFC 2284bis section 2.4 and 802.1XREV Section 6.7, and they > seem miles apart. This needs to be resolved before 802.1X-REV is > published. > > Here is my reading of the differences and what needs to be done to fix > them: > > a. Section 6.7 of 802.1X-REV indicates that EAP authentication > can only be uni-directional. RFC 2284bis Section 2.4 states the > conditions under which bi-directional authentication is achievable. > Since 802.1X-REV now leaves authentication to EAP, it is not possible for > IEEE 802 encapsulation to change the fundamental properties of EAP, so the > two specs cannot disagree on this point. > I agree that this is confusing and should change. > b. Section 6.7 appears to assume (contrary to recent discussion) that > there is no way for the AAA server or higher layer to communicate the peer > decision down to the lower layer on the authenticator side. Given the new > interface variables and discussion on AAA key implications, I think we've > settled this issue. While I'm ok with not changing 802.1X-REV to discuss > the new interface variables or AAA implications (this can go in the EAP > State Machine document), I do think that the implications for the text of > Section 6.7 do need to be addresssed. > The current proposal to fix this, as descrbed by Jim Burns (and myself and others) does not need to pass any signal down, so I don't think this needs to be done. > To fix these issues, it would probably be best if Section 6.7 referenced > RFC 2284bis Section 2.4 and removed the paragraphs that appear to > contradict RFC 2284bis. Given that 802.1X-REV is entering sponsor ballot, > it is relatively late for these fixes to be put in -- but I fear that if > the changes are not made now the pain will be much greater down the line, > particularly since 802.1af appears to want to address some of the same > peer-to-peer issues. > I agree that this should be done. It is in addition to the small changes that Jim Burns has described. I also realize this is late and am not sure how it should be handled. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Jan 19 17:44:01 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13177 for ; Mon, 19 Jan 2004 17:44:00 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DC50C201EF; Mon, 19 Jan 2004 17:33:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by mail.frascone.com (Postfix) with ESMTP id A11FD201EC for ; Mon, 19 Jan 2004 17:32:13 -0500 (EST) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0JMiPuo019757 for ; Mon, 19 Jan 2004 22:44:25 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0JMhsiC017806 for ; Mon, 19 Jan 2004 22:43:56 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011914425817138 for ; Mon, 19 Jan 2004 14:42:58 -0800 Received: from orsmsx401.amr.corp.intel.com ([192.168.65.207]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 19 Jan 2004 14:42:58 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [eap] network selection Message-ID: Thread-Topic: [eap] network selection Thread-Index: AcPeyTFUaizr1VikRnimHsvfghZggQAEgrHA From: "Lortz, Victor" To: X-OriginalArrivalTime: 19 Jan 2004 22:42:58.0217 (UTC) FILETIME=[95FF2190:01C3DEDD] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 19 Jan 2004 14:42:57 -0800 Content-Transfer-Encoding: quoted-printable Generally a user doesn't care how IP datagrams are routed because there is no cost premium paid by the user for one path vs. another. A different analogy that might be helpful is as follows: suppose we consider the phone network. It is possible to establish a default long distance provider for a given phone line. However, even if such a default exists, it remains possible to dial a number such as 10 10 123 or an 800 number for alternative long distance service. This imposes more inconvenience on the user, but the savings may be significant. =20 Best Regards, Vic -----Original Message----- From: Alper Yegin [mailto:alper@docomolabs-usa.com]=20 Sent: Monday, January 19, 2004 12:17 PM To: Lortz, Victor; eap@frascone.com Subject: Re: [eap] network selection Hello Victor, > Alper, you are assuming that there is a direct roaming agreement between > the user's home ISP and the NAP (using PANA terminology). 3GPP is also > interested in scenarios in which there is no direct relationship. > Instead, there is an intermediary "broker" network such as an aggregator > (or in 3GPP parlance, a VPLMN) that has roaming agreements with the > other two. In this context, especially if there is more than one > candidate intermediary, the user may wish to discover and subsequently > designate a preferred intermediary. Actually I'm not denying the possibility of a multi-hop AAA routing between the NAP and ISP. All I'm saying is this topology and its associated management is better handled by the servers running the AAA protocols (RADIUS, Diameter). Not by the user's host. Doing otherwise would complicate the host, and I'm not sure if this is necessary. The problem is similar to datagram routing. The host only knows its default gateway and the final destination for its data traffic. The intermediate routing is handled by the routers. Alper >=20 > Best Regards, > Vic >=20 > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf > Of Alper Yegin > Sent: Friday, January 16, 2004 6:35 PM > To: jari.arkko@piuha.net; eap@frascone.com > Subject: Re: [eap] network selection >=20 > Hello Jari, >=20 > Thank you for capturing this discussion. >=20 > I have some comments, please see below... >=20 > First, there is the problem of "Access Network discovery". This > is the problem of discovering access networks available in the > vicinity, and the points of presence (POPs) associated with those > networks.=20 >=20 > In PANA we borrowed two terms from the DSL networks, NAP (Network Access > Provider) and ISP. NAP is the owner/operator of the access > infrastructure > (such as the WLAN AP in the coffee shop). It provides L2 access to the > clients and connect them to their ISP. ISP should have a business > agreement > with the NAP for this "roaming" service. >=20 > I think our "ISP" corresponds to your "Access network"? And what is the > "home network" then? >=20 > If we are talking about general "access network discovery", I think it > would > involve discovering both NAPs and their associated (serviced) ISPs in my > client's vicinity. I think we are more interested in the latter part of > the > problem. >=20 > Referring to Figure 2: >=20 > In this > figure, the user "joe@corp3.com" has to be authenticated through ISP > 2, since the domain "corp3.com" is served by it. >=20 > I think another way to read this is "All the employees of corp3.com has > an > account with ISP2 under their name. When they connect to ISP2, their > traffic > is VPN'ed to the corporate network". Right? >=20 >=20 > There has been requests to place credential and AAA route selection > under user control, as the user is affected by the pricing and other > differences. >=20 > I don't think this is necessary. I should only care about my ISP > selection, > and be able to trust my ISP to figure out the best AAA route for me (in > figure 3, isp1.com is aware of both paths). If the access network is > trying > to rip me off, my ISP should be able to catch that. And if my ISP is > ripping > me off, oh well..... >=20 > Regarding the attack on 2.4.1: I think this is a combined issue of > network > identity theft in the absence of unprotected or unverified discovery, > and > bandwidth reselling. These can be issues on their own even when > separated. I > don't think the combination has an effect here. >=20 > Basically, if the "rogue" access point has a flat fee > account and a contract with a clearing house, it can offer access to > anyone with a per-byte account, NAT their packets, and send the > traffic forward on its own account, and generate income. >=20 > And this is just one way to provide a legitimate service, given that the > upstream service provider legally allows you to resell the bandwidth. If > you > are using someone else's network name to lure clients in, this is a > separate > issue.=20 >=20 > However, IPsec could be used to detect the > presence of such NATs, even if NAT traversal is in use. >=20 > There wouldn't be any needs for NAT when a /64 IPv6 prefixes are > delegated > to mobile clients. So, relying on NAT detection is not sufficient. >=20 > Similarly, the IEEE 802.1af has discussed the > idea of supporting network discovery within a future revision to > IEEE 802.1X. >=20 > Supporting this functionality in the EAP lower layer seems logical to > me. > This is what we did with the PANA design. >=20 > In the IETF, a potential alternative is use of the SEAMOBY CARD > protocol [13], which enables advertisement of network device > capabilities over IP. Another alternative is the recently > proposed Device Discovery Protocol (DDP) [12], which provides > functionality equivalent to IEEE 802.1ab using ASN.1 encoded > advertisements sent to a link-local scope multicast address. >=20 > Using CARD lets you collect information about the networks in your > client's > vicinity. These are the potential points of attachments upon movement. I > think the use of DDP can be similar (if, access points are in the same > subnet). Neither is about discovering and selecting an immediate access > network. I think it is worth mentioning PANA in here, where this > selection > takes place during the network access AAA (before client engages in > authentication).=20 >=20 > The representation of link layer parameters within EAP > should utilize a common framework, to make it easier to define new > link layers and keep the selection of EAP methods independent of the > link layer. >=20 > ... >=20 > The security requirements for network discovery depend on the type of > information being discovered. Some of the parameters may have a > security impact, such as the claimed name of the network the user > tries to attach to. Unfortunately, current EAP methods do not always > make the verification of such parameters possible. >=20 > I think hosting these functionalities in the EAP lower layer is a better > approach. >=20 > Alper >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Jan 19 17:54:19 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13491 for ; Mon, 19 Jan 2004 17:54:19 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3EDAC2021F; Mon, 19 Jan 2004 17:42:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 8B562201EC for ; Mon, 19 Jan 2004 17:41:20 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i0JN6cb11217; Mon, 19 Jan 2004 15:06:39 -0800 From: Bernard Aboba To: John Vollbrecht Cc: eap@frascone.com, stds-802-1@ieee.org Subject: Re: [eap] Discrepancies between 802.1XREV and RFC 2248bis In-Reply-To: <798379.1074528492@dhcp60-09.merit.edu> Message-ID: References: <798379.1074528492@dhcp60-09.merit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 19 Jan 2004 15:06:38 -0800 (PST) > I agree that this should be done. It is in addition to the small changes > that Jim Burns has described. I also realize this is late and am not sure > how it should be handled. Do we have a proposal for a revised Section 6.7 of 802.1X-REV? If not, do we need to come up with one? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Jan 19 19:10:18 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18035 for ; Mon, 19 Jan 2004 19:10:18 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5E67320204; Mon, 19 Jan 2004 18:59:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 6FB43201EC for ; Mon, 19 Jan 2004 18:58:30 -0500 (EST) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 19 Jan 2004 16:12:33 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i0K09JVO010988; Mon, 19 Jan 2004 16:09:22 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.99.27]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 19 Jan 2004 16:15:06 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" , , Subject: RE: [eap] Discrepancies between 802.1XREV and RFC 2248bis Message-ID: <011f01c3dee9$a747c270$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 20 Jan 2004 00:15:07.0102 (UTC) FILETIME=[757807E0:01C3DEEA] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 19 Jan 2004 16:09:20 -0800 Content-Transfer-Encoding: 7bit eap-admin@frascone.com wrote: > I just reread RFC 2284bis section 2.4 and 802.1XREV Section > 6.7, and they seem miles apart. This needs to be resolved > before 802.1X-REV is published. > > Here is my reading of the differences and what needs to be done to > fix them: > > a. Section 6.7 of 802.1X-REV indicates that EAP > authentication can only be uni-directional. RFC 2284bis > Section 2.4 states the conditions under which bi-directional > authentication is achievable. Since 802.1X-REV now leaves > authentication to EAP, it is not possible for IEEE 802 > encapsulation to change the fundamental properties of EAP, so > the two specs cannot disagree on this point. > [Joe] I'm looking at section 6.7 of 802-1X-REV-d8.pdf and it appears to be somewhat ambiguous, last paragraph gives EAP-TLS as an example of mutual authentication. > b. Section 6.7 appears to assume (contrary to recent > discussion) that there is no way for the AAA server or higher > layer to communicate the peer decision down to the lower > layer on the authenticator side. Given the new interface > variables and discussion on AAA key implications, I think > we've settled this issue. While I'm ok with not changing > 802.1X-REV to discuss the new interface variables or AAA > implications (this can go in the EAP State Machine document), > I do think that the implications for the text of Section 6.7 > do need to be addresssed. > [Joe] I'm still unclear as to what the "decision" really is and its impact on authorization, but this currently does not seem to be an issue discussed in section 6.7. Is this discussed elsewhere in the 802.1XREV document? > To fix these issues, it would probably be best if Section 6.7 > referenced RFC 2284bis Section 2.4 and removed the paragraphs > that appear to contradict RFC 2284bis. Given that 802.1X-REV > is entering sponsor ballot, it is relatively late for these > fixes to be put in -- but I fear that if the changes are not > made now the pain will be much greater down the line, > particularly since 802.1af appears to want to address some of > the same peer-to-peer issues. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Jan 19 19:10:19 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18034 for ; Mon, 19 Jan 2004 19:10:18 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CD79F201EF; Mon, 19 Jan 2004 18:58:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from deneb.mtghouse.com (unknown [206.152.191.132]) by mail.frascone.com (Postfix) with SMTP id 0F898201EF for ; Mon, 19 Jan 2004 18:58:00 -0500 (EST) Received: (qmail 20252 invoked from network); 20 Jan 2004 00:08:54 -0000 Received: from unknown (HELO mtghouse.com) (192.168.11.151) by deneb.mtghouse.com with SMTP; 20 Jan 2004 00:08:54 -0000 Message-ID: <400C719A.5080502@mtghouse.com> From: Jim Burns User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030829 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com, stds-802-1@ieee.org, Paul Congdon , John Vollbrecht , Bob Moskowitz , Preeti vinayakray Subject: Re: [eap] Discrepancies between 802.1XREV and RFC 2248bis References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 19 Jan 2004 19:08:58 -0500 Content-Transfer-Encoding: 7bit Hi folks, Yes, a reread of 6.7 leads me to believe that it could be confusing to implementers. My opinion is that the current 6.7 was written before there was a supplicant controlled port. With the addition of the supplicant controlled port, the uni-directional nature of the transport is no longer a blocking feature to a bi-directional EAP method. -------------------- I believe the points we want to make in 6.7 are the following: .1X is an asymmetric transport protocol (it has two separate roles). It is asymmetric due to history when only the authenticator had a controlled port. Now that both the supplicant and authenticator both have a controlled port the asymmetry of the .1X transport does not disallow a mutual authentication EAP method from doing a bi-directional authentication over the .1X transport. There are some idiosyncracies of the asymmetric nature of the .1X transport, the main one being that two simultaneous authentications can be run if both .1X machines are implemented and both must complete successfully for the controlled port to be unblocked. There are reasons that you may want to utilize two simultaneous authentications, as described in section 2.4 of 2284 (as well as some of the verbage in 6.7). It should be made clear that two coupled one-way authentications does not provide the same security as a single mutual authentication. Each application should define which roles of the .1X state machines each device is to implement as well as the class of EAP methods (mutual authenticating or unidirectional authentication or both) that are required. One must be careful of certain combinations of the number of machines, and be aware that a device with both .1X machines encountering a device with just the .1X authenticator will result in an asymmetric network connection (controlled port open on one device and closed on the other). I have a table that defines all the cases clearly. -------------------------- Known uses are: 802.11 infrastructure: 1 supplicant on client and 1 authenticator on AP using mutual authenticating EAP methods. 802.11 adhoc: Each adhoc station should run both supplicant and authenticator with key generating EAP methods. The key used for group key is from the highest numbered MAC address. 802.1 bridges: Both supplicant and authenticator with special variable that makes controlled port controlled only by authenticator enabled. EAP method type not defined. The current text of 6.7 along with the above points could be the starting point for a revised 6.7 if that is still possible in the IEEE cycle. Please critique and add to the above list and I will create a revised 6.7 and issue it for critique. I can present it to the IEEE to see if it will be accepted at this time. Thanks, Jim B. > >a. Section 6.7 of 802.1X-REV indicates that EAP authentication >can only be uni-directional. RFC 2284bis Section 2.4 states the >conditions under which bi-directional authentication is achievable. >Since 802.1X-REV now leaves authentication to EAP, it is not possible for >IEEE 802 encapsulation to change the fundamental properties of EAP, so the >two specs cannot disagree on this point. > > >b. Section 6.7 appears to assume (contrary to recent discussion) that >there is no way for the AAA server or higher layer to communicate the peer >decision down to the lower layer on the authenticator side. Given the new >interface variables and discussion on AAA key implications, I think we've >settled this issue. While I'm ok with not changing 802.1X-REV to discuss >the new interface variables or AAA implications (this can go in the EAP >State Machine document), I do think that the implications for the text of >Section 6.7 do need to be addresssed. > >To fix these issues, it would probably be best if Section 6.7 referenced >RFC 2284bis Section 2.4 and removed the paragraphs that appear to >contradict RFC 2284bis. Given that 802.1X-REV is entering sponsor ballot, >it is relatively late for these fixes to be put in -- but I fear that if >the changes are not made now the pain will be much greater down the line, >particularly since 802.1af appears to want to address some of the same >peer-to-peer issues. > >_______________________________________________ >eap mailing list >eap@frascone.com >http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Jan 19 19:19:19 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18489 for ; Mon, 19 Jan 2004 19:19:19 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5852D201EF; Mon, 19 Jan 2004 19:07:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 982FB201EC for ; Mon, 19 Jan 2004 19:06:05 -0500 (EST) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 19 Jan 2004 16:20:47 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id i0K0GugP013959; Mon, 19 Jan 2004 16:16:57 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.99.27]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 19 Jan 2004 16:22:19 -0800 From: "Joseph Salowey" To: "'John Vollbrecht'" , "'Bernard Aboba'" Cc: , , Subject: RE: [eap] Proposed resolution of Issue 212: Protected Result Indications Message-ID: <012001c3deea$a90ef870$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <576563.1074524795@dhcp60-09.merit.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 20 Jan 2004 00:22:19.0696 (UTC) FILETIME=[7750A300:01C3DEEB] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 19 Jan 2004 16:16:32 -0800 Content-Transfer-Encoding: 7bit jrv@j.imap.itd.umich.edu wrote: > --On Friday, January 16, 2004 3:45 PM -0800 Joseph Salowey > wrote: > >> >> >>> >> [Joe] I agree with this. Synchronized state between EAP-Peer and >> EAP-Server is in general good. I do not think that this translates >> directly to synchronization between EAP-Peer and EAP-Authenticator >> authorization. I think this synchronization is achieved best by a >> mechanism outside of EAP. >> >> > I think Joe's point that there may be authorization outside > EAP is pretty > strong. In some environments it may be possible for an EAP method to > succeed but the authenticated user may be refused. Thus it > would seem to > be possible to get an Access Reject and an EAP Success. I > think what this > means is that the Access Point pass the EAP Success, but the > AP will also > refuse to turn on the port. If this is the case, then I > think that the EAP > method is used to authenticate the request, but it may be > refused for other > reasons. > > The fact that an EAP method can succeed while the > authorization fails seems > ok to me. It means that one port may be turned on while the > other is not. > For 802.1X this may cause llong timeouts. My thinking right > now at least > is that this is a problem with 802.1X because it does not > have a way to > tell the other side that it failed. Perhaps I am missing something? [Joe] I think so it appears that 802.1X does not have this functionality. I am worried about the current wording of 2284bis section 2.4 "The authenticator SHOULD interpret the receipt of a key attribute within an Accept packet as an indication that the peer has successfully authenticated and authorized the server." Which is equating EAP Authentication with authorization. I think this is bad. >> >>> On Fri, 16 Jan 2004, Joseph Salowey wrote: >>> >>>> I agree with Pasi that I'm not sure I see the value of protected >>>> result indicators. Especially given that they seem very difficult >>>> if not impoissible to implement in the real world. Even if the EAP >>>> method supports it authorization along the NAS-proxy path may take >>>> into account information that is not avaiable to process >>>> performing the EAP authentication. >>>> >>>> Joe >> >> _______________________________________________ >> eap mailing list >> eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Jan 19 22:57:07 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27477 for ; Mon, 19 Jan 2004 22:57:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6CB9120203; Mon, 19 Jan 2004 22:46:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id B46C5201EC for ; Mon, 19 Jan 2004 22:45:51 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i0K4B8U29405; Mon, 19 Jan 2004 20:11:08 -0800 From: Bernard Aboba To: Jim Burns Cc: eap@frascone.com, stds-802-1@ieee.org Subject: Re: [eap] Discrepancies between 802.1XREV and RFC 2248bis In-Reply-To: <400C719A.5080502@mtghouse.com> Message-ID: References: <400C719A.5080502@mtghouse.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 19 Jan 2004 20:11:08 -0800 (PST) > Hi folks, > Yes, a reread of 6.7 leads me to believe that it could be confusing > to implementers. My opinion is that the current 6.7 was written before > there was a supplicant controlled port. With the addition of the > supplicant controlled port, the uni-directional nature of the transport > is no longer a blocking feature to a bi-directional EAP method. I agree (modulo the caveats in Section 2.4 of RFC 2284bis). > I believe the points we want to make in 6.7 are the following: This sounds like a good start. Do you want to draft some sample text for review? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jan 20 09:05:23 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00101 for ; Tue, 20 Jan 2004 09:05:21 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 49A99201FA; Tue, 20 Jan 2004 08:54:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from deneb.mtghouse.com (unknown [206.152.191.132]) by mail.frascone.com (Postfix) with SMTP id 8A037201FA for ; Tue, 20 Jan 2004 08:53:35 -0500 (EST) Received: (qmail 14788 invoked from network); 20 Jan 2004 14:04:30 -0000 Received: from unknown (HELO mtghouse.com) (192.168.11.151) by deneb.mtghouse.com with SMTP; 20 Jan 2004 14:04:31 -0000 Message-ID: <400D3572.40707@mtghouse.com> From: Jim Burns User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030829 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com, stds-802-1@ieee.org Subject: Re: [eap] Discrepancies between 802.1XREV and RFC 2248bis References: <400C719A.5080502@mtghouse.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 20 Jan 2004 09:04:34 -0500 Content-Transfer-Encoding: 7bit Hi Bernard, Yes, I would be happy to take a first crack at it and then accept input. My schedule is such that I will not get it out til this eve or Wednesday AM. Sorry about the delay, Jim B. Bernard Aboba wrote: >>Hi folks, >> Yes, a reread of 6.7 leads me to believe that it could be confusing >>to implementers. My opinion is that the current 6.7 was written before >>there was a supplicant controlled port. With the addition of the >>supplicant controlled port, the uni-directional nature of the transport >>is no longer a blocking feature to a bi-directional EAP method. >> >> > >I agree (modulo the caveats in Section 2.4 of RFC 2284bis). > > > >>I believe the points we want to make in 6.7 are the following: >> >> > >This sounds like a good start. Do you want to draft some sample text for >review? > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jan 20 11:14:06 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08679 for ; Tue, 20 Jan 2004 11:14:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D5C4320211; Tue, 20 Jan 2004 11:03:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 748D920203 for ; Tue, 20 Jan 2004 11:02:40 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i0KGRxK09462 for ; Tue, 20 Jan 2004 08:27:59 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Reminder on Internet Draft submission deadlines Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 20 Jan 2004 08:27:58 -0800 (PST) Here are the ID draft deadlines: February 9, Monday - 00 Internet Draft Cut-off February 16, Monday - Internet Draft cut-off _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jan 20 13:14:02 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14882 for ; Tue, 20 Jan 2004 13:14:02 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 46CF220211; Tue, 20 Jan 2004 13:03:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id 7A48C20203 for ; Tue, 20 Jan 2004 13:02:59 -0500 (EST) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 20 Jan 2004 10:14:46 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i0KIDljQ015144; Tue, 20 Jan 2004 10:13:52 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.99.27]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Jan 2004 10:19:33 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" Cc: Subject: RE: [eap] Proposed resolution of Issue 212: Protected Result Indications Message-ID: <005b01c3df81$256b7380$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 20 Jan 2004 18:19:33.0399 (UTC) FILETIME=[F4010A70:01C3DF81] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 20 Jan 2004 10:13:46 -0800 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >>> The authenticator SHOULD interpret the receipt of >>> a key attribute within an Accept packet as an indication that the >>> peer has successfully authenticated the server. >>> >> [Joe] Is this authenticated or authenticated and authorized? > > I think it is "authenticated and authorized". Are there > counter-examples? I think the problem is that EAP method/framework may not have sufficient information to determine authorization as there may be more considerations than authentication. This escpecially true of the EAP-Server and I believe it is also true of the Peer. I think the EAP framework can be expected to determine that authentication related policy has been satisfied, but this does not gaurantee that peer or the server will allow access. Joe _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jan 20 13:45:03 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15653 for ; Tue, 20 Jan 2004 13:45:03 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2379620211; Tue, 20 Jan 2004 13:34:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from intolerance.mr.itd.umich.edu (intolerance.mr.itd.umich.edu [141.211.14.78]) by mail.frascone.com (Postfix) with ESMTP id ABE9120203 for ; Tue, 20 Jan 2004 13:33:34 -0500 (EST) Received: from dhcp60-09.merit.edu (dhcp60-09.merit.edu [198.108.60.209]) by intolerance.mr.itd.umich.edu (smtp) with ESMTP id i0KIiMw9026981; Tue, 20 Jan 2004 13:44:23 -0500 From: John Vollbrecht To: Joseph Salowey , "'Bernard Aboba'" Cc: eap@frascone.com Subject: RE: [eap] Proposed resolution of Issue 212: Protected Result Indications Message-ID: <656411.1074606258@dhcp60-09.merit.edu> In-Reply-To: <005b01c3df81$256b7380$0300000a@amer.cisco.com> References: <005b01c3df81$256b7380$0300000a@amer.cisco.com> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 20 Jan 2004 13:44:18 -0500 Content-Transfer-Encoding: 7bit --On Tuesday, January 20, 2004 10:13 AM -0800 Joseph Salowey wrote: > > > Bernard Aboba wrote: > >>> The authenticator SHOULD interpret the receipt of > >>> a key attribute within an Accept packet as an indication that the > >>> peer has successfully authenticated the server. > >>> > >> [Joe] Is this authenticated or authenticated and authorized? > > > > I think it is "authenticated and authorized". Are there > > counter-examples? > > I think the problem is that EAP method/framework may not have sufficient > information to determine authorization as there may be more > considerations than authentication. This escpecially true of the > EAP-Server and I believe it is also true of the Peer. I think the EAP > framework can be expected to determine that authentication related > policy has been satisfied, but this does not gaurantee that peer or the > server will allow access. > I agree with Joe. The EAP method does authentication and possibly authorization between the Server and the Peer. Other authorization, such as "is Joe allowed on after 5PM" may have nothing to do with the EAP method but may keep Joe from being allowed to connect even though the EAP method succeeded. John _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jan 20 19:26:03 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03084 for ; Tue, 20 Jan 2004 19:26:02 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 49A0620236; Tue, 20 Jan 2004 19:15:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id DEBAB20235 for ; Tue, 20 Jan 2004 19:14:49 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i0L0dxX06581; Tue, 20 Jan 2004 16:39:59 -0800 From: Bernard Aboba To: John Vollbrecht Cc: Joseph Salowey , eap@frascone.com Subject: RE: [eap] Proposed resolution of Issue 212: Protected Result Indications In-Reply-To: <656411.1074606258@dhcp60-09.merit.edu> Message-ID: References: <005b01c3df81$256b7380$0300000a@amer.cisco.com> <656411.1074606258@dhcp60-09.merit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 20 Jan 2004 16:39:59 -0800 (PST) > > Bernard Aboba wrote: > > >>> The authenticator SHOULD interpret the receipt of > > >>> a key attribute within an Accept packet as an indication that the > > >>> peer has successfully authenticated the server. > > >>> > > >> [Joe] Is this authenticated or authenticated and authorized? > > > > > > I think it is "authenticated and authorized". Are there > > > counter-examples? > > > > I think the problem is that EAP method/framework may not have sufficient > > information to determine authorization as there may be more > > considerations than authentication. This escpecially true of the > > EAP-Server and I believe it is also true of the Peer. I think the EAP > > framework can be expected to determine that authentication related > > policy has been satisfied, but this does not gaurantee that peer or the > > server will allow access. > > > I agree with Joe. The EAP method does authentication and possibly > authorization between the Server and the Peer. Other authorization, such > as "is Joe allowed on after 5PM" may have nothing to do with the EAP method > but may keep Joe from being allowed to connect even though the EAP method > succeeded. OK. So the resolution is to leave the original text the way it is? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jan 20 19:51:04 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04096 for ; Tue, 20 Jan 2004 19:51:03 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7752A20239; Tue, 20 Jan 2004 19:40:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id 066D92020A for ; Tue, 20 Jan 2004 19:39:47 -0500 (EST) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 20 Jan 2004 16:51:38 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id i0L0oeJ0019389; Tue, 20 Jan 2004 16:50:40 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.99.27]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Jan 2004 16:56:26 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" , "'John Vollbrecht'" Cc: Subject: RE: [eap] Proposed resolution of Issue 212: Protected Result Indications Message-ID: <00ac01c3dfb8$972d49d0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 21 Jan 2004 00:56:26.0710 (UTC) FILETIME=[65D7EF60:01C3DFB9] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 20 Jan 2004 16:50:39 -0800 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >>> Bernard Aboba wrote: >>>>>> The authenticator SHOULD interpret the receipt of >>>>>> a key attribute within an Accept packet as an indication that >>>>>> the peer has successfully authenticated the server. >>>>>> >>>>> [Joe] Is this authenticated or authenticated and authorized? >>>> >>>> I think it is "authenticated and authorized". Are there >>>> counter-examples? >>> >>> I think the problem is that EAP method/framework may not have >>> sufficient information to determine authorization as there may be >>> more considerations than authentication. This escpecially true of >>> the EAP-Server and I believe it is also true of the Peer. I think >>> the EAP framework can be expected to determine that authentication >>> related policy has been satisfied, but this does not gaurantee that >>> peer or the server will allow access. >>> >> I agree with Joe. The EAP method does authentication and possibly >> authorization between the Server and the Peer. Other authorization, >> such as "is Joe allowed on after 5PM" may have nothing to do with the >> EAP method but may keep Joe from being allowed to connect even though >> the EAP method succeeded. > > OK. So the resolution is to leave the original text the way it is? [Joe] Yes, with "authenticated" instead of "authenticated and authorized". _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jan 20 20:40:03 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05819 for ; Tue, 20 Jan 2004 20:40:03 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 86B0F20236; Tue, 20 Jan 2004 20:29:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id B3D822020A for ; Tue, 20 Jan 2004 20:28:56 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i0L1s8O10964; Tue, 20 Jan 2004 17:54:08 -0800 From: Bernard Aboba To: Joseph Salowey Cc: "'John Vollbrecht'" , eap@frascone.com Subject: RE: [eap] Proposed resolution of Issue 212: Protected Result Indications In-Reply-To: <00ac01c3dfb8$972d49d0$0300000a@amer.cisco.com> Message-ID: References: <00ac01c3dfb8$972d49d0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 20 Jan 2004 17:54:08 -0800 (PST) > > OK. So the resolution is to leave the original text the way it is? > > [Joe] Yes, with "authenticated" instead of "authenticated and > authorized". Done. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jan 20 21:00:03 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06306 for ; Tue, 20 Jan 2004 21:00:03 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5EFC520236; Tue, 20 Jan 2004 20:49:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 664792020A for ; Tue, 20 Jan 2004 20:48:29 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i0L2Dk012148 for ; Tue, 20 Jan 2004 18:13:46 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Issue 213: Cleanup issues Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 20 Jan 2004 18:13:46 -0800 (PST) Issue 213: Cleanup issues Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 1/20/2004 Reference: Document: RFC 2284bis-08.l Comment type: T Priority: S Section: 3.1, 7.2.1 Rationale/Explanation of issue: This is a generic issue to cleanup the text of -08.l as reflected in WG discussions. In Section 2.4 change: "The authenticator SHOULD interpret the receipt of a key attribute within an Accept packet as an indication that the peer has successfully authenticated and authorized the server." To: "The authenticator SHOULD interpret the receipt of a key attribute within an Accept packet as an indication that the peer has successfully authenticated the server." In Section 7.2.1, change: " Protected result indications A method provides result indications if after the method has finished (1) if the peer is willing to use the access provided by the authenticator, it knows whether the authenticator will grant access (that is, only either an EAP-Success or EAP-Failure will be accepted, no more method specific messages are expected), and (2) if the authenticator decides to grant access, it knows whether the peer will accept it. Result indications improve resilience to packet loss; see Section 4.2 for discussion. Depending on the method and circumstances, result indications can be spoofable by an attacker. A method is said to provide protected result indications if it supports result indications as well as the "integrity protection" and "replay protection" claims. A method claiming to support protected result indications MUST indicate which result indications are protected, and which are not. See Section 7.16 for details." To: Protected result indications A method provides result indications if after the method has finished: 1) When peer is willing to accept access to the network, it knows whether the authenticator will grant access. 2) When the peer decides to grant access, it knows whether the peer will accept it. Result indications improve resilience to packet loss, and prevent long timeouts; see Section 4.2 for discussion. Depending on the method design and circumstances, result indications may be vulnerable to spoofing or replay by an attacker. A method is said to provide protected result indications if it supports result indications as well as the "integrity protection" and "replay protection" claims. A method claiming to support protected result indications MUST indicate which result indications are protected, and which are not. See Section 7.16 for details." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jan 20 23:39:06 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09992 for ; Tue, 20 Jan 2004 23:39:03 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CED7D20236; Tue, 20 Jan 2004 23:28:04 -0500 (EST) Delivered-To: eap@frascone.com Received: from mail0.yrp.nttdocomo.co.jp (mail0.yrp.nttdocomo.co.jp [202.245.184.18]) by mail.frascone.com (Postfix) with ESMTP id E11AC2020A for ; Tue, 20 Jan 2004 23:27:09 -0500 (EST) Received: from mml.yrp.nttdocomo.co.jp (mml.yrp.nttdocomo.co.jp [172.21.48.50]) by mail0.yrp.nttdocomo.co.jp (8.12.10/YRPHUB0-8820020412) with ESMTP id i0L4c383004896 for ; Wed, 21 Jan 2004 13:38:03 +0900 (JST) Received: from [172.21.51.110] (kan-noauto.mml-ad.yrp.nttdocomo.co.jp [172.21.51.110]) by mml.yrp.nttdocomo.co.jp (8.12.6/8.12.6) with ESMTP id i0L4c22b078242 for ; Wed, 21 Jan 2004 13:38:03 +0900 (JST) From: Hisatoshi EGUCHI To: EAP WG Message-Id: <20040121133210.D526.EGUCHI@mml.yrp.nttdocomo.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.06 Subject: [eap] A question about Protected result indications in EAP-AKA. Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 21 Jan 2004 13:38:02 +0900 Content-Transfer-Encoding: 7bit Deer all, I have a question about EAP-AKA [1]. Does EAP working group solve following problem? "EAP-AKA is intended for use over both physically insecure and physically or otherwise secure networks." (10. Security Claims [a]) EAP [2] (Issue 208) is intended for use over physically insecure networks. Use cases of EAP-AKA are different to those of EAP. Nevertheless, current EAP-AKA notifies authentication result by unprotected EAP Success/Failure. In EAP-AKA, peer receives bogus Success/Failure from attacker. ([1] Section 9.8) Then, I am anxious that if attacker sends bogus Failure in case of authentication Success in network, legitimate peer can never get access of network. It is DoS attack by sending bogus authentication result. As a result, any peer cannot get access of network in case of bogus Failure sent by attacker. So, I think that current notification of authentication result is contradictory to Security Claim [a]. Isn't it necessary to update current EAP-AKA to be suitable for Security Claim [a]? To solve this problem, for example, I think that EAP-AKA should be improve to send integrity-protected Success/Failure like PEAP [3]. Then, IK can be used to protect Success/Failure in EAP-AKA. Thank you for reading. References [1] J. Arkko, et al., "EAP AKA Authentication," draft-arkko-pppext-eap-aka-11.txt, October 2003. [2] L.Blunk, et al., "Extensible Authentication Protocol (EAP)," draft-ietf-eap-rfc2284bis-08.j.txt, November 2003. [3] D. Simon, et al., "Protected EAP Protocol (PEAP) Version 2," draft-josefsson-pppext-eap-tls-eap-07.txt, October 2003. With Best Regards, Hisatoshi EGUCHI _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jan 21 00:04:02 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10547 for ; Wed, 21 Jan 2004 00:04:01 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2107A20236; Tue, 20 Jan 2004 23:53:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 48F072020A for ; Tue, 20 Jan 2004 23:52:41 -0500 (EST) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 20 Jan 2004 21:07:00 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0L53YGN026674; Tue, 20 Jan 2004 21:03:35 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.99.27]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Jan 2004 21:09:21 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" , Subject: RE: [eap] Issue 213: Cleanup issues Message-ID: <00c601c3dfdb$ebed86b0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 21 Jan 2004 05:09:21.0421 (UTC) FILETIME=[BAAD13D0:01C3DFDC] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 20 Jan 2004 21:03:33 -0800 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > > " Protected result indications > A method provides result indications if after the method > has finished (1) if the peer is willing to use the access > provided by the authenticator, it knows whether the > authenticator will grant access (that is, only either an > EAP-Success or EAP-Failure will be accepted, no > more method > specific messages are expected), and (2) if the > authenticator decides to grant access, it knows > whether the > peer will accept it. Result indications improve > resilience to packet loss; see Section 4.2 for > discussion. Depending on the method and circumstances, > result > indications can be > spoofable by an attacker. A method is said to provide > protected result indications if it supports result > indications as well as the "integrity protection" and > "replay protection" claims. A method claiming to support > protected result indications MUST indicate which result > indications are protected, and which are not. > See Section > 7.16 for details." > To: > > Protected result indications > A method provides result indications if after the > method has finished: > > 1) When peer is willing to accept access to the network, it > knows whether the authenticator will grant access. > > 2) When the peer decides to grant access, it knows > whether the peer will accept it. > [Joe] Here again we have a mix of authentication and authorization. It would be better to qualify the above statement. "Protected result indications A method provides result indications if after the method has finished: 1) When peer successfully completes the authentication, it knows whether the authenticator has successfully completed the authentication. 2) When the authenticator successfully completes the authentication, it knows whether the peer has successfully completed the authentication. In the case where successful authentication is sufficient to authorize access then the peer and authenticator will also know if the other party is willing to provide or accept access. This may not always be the case." > Result indications improve resilience to packet loss, > and prevent long timeouts; see Section 4.2 for discussion. > Depending on the method design and circumstances, result > indications may be vulnerable to spoofing or replay by an attacker. > > A method is said to provide protected result indications if > it supports result indications as well as the > "integrity protection" and "replay protection" claims. > A method claiming to support protected result indications > MUST indicate which result indications are protected, and > which are not. See Section 7.16 for details." > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jan 21 03:22:05 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11823 for ; Wed, 21 Jan 2004 03:22:04 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4181E20236; Wed, 21 Jan 2004 03:11:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id 7A56D201F5 for ; Wed, 21 Jan 2004 03:10:27 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0L8K4Y19095 for ; Wed, 21 Jan 2004 10:21:19 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 21 Jan 2004 10:20:04 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 21 Jan 2004 10:20:04 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 21 Jan 2004 10:20:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] A question about Protected result indications in EAP-AKA. Message-ID: Thread-Topic: [eap] A question about Protected result indications in EAP-AKA. Thread-Index: AcPf2NHjc+cg2NmAQCG8LpBmqoPV4wAHZOxA From: To: , X-OriginalArrivalTime: 21 Jan 2004 08:20:05.0056 (UTC) FILETIME=[5F9D3400:01C3DFF7] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 21 Jan 2004 10:20:03 +0200 Content-Transfer-Encoding: quoted-printable Hello Hisatoshi, It is true that there are denial of service attacks that can be performed against EAP-AKA, and I'm afraid with any other EAP method. The attacker typically doesn't need to wait for the end of the exchange, but it will be even=20 more productive to spoof packets in the beginning of exchange,=20 where methods typically cannot provide EAP packet integrity=20 protection. Denial of service attacks are notoriously easy to mount in wireless networks. That said, we are currently consider whether we need to improve the result indications in EAP-SIM and EAP-AKA. Best regards, Henry > -----Original Message----- > From: eap-admin@frascone.com=20 > [mailto:eap-admin@frascone.com]On Behalf Of > ext Hisatoshi EGUCHI > Sent: 21 January, 2004 06:38 > To: EAP WG > Subject: [eap] A question about Protected result indications=20 > in EAP-AKA. >=20 >=20 > Deer all, >=20 > I have a question about EAP-AKA [1]. > Does EAP working group solve following problem? >=20 > "EAP-AKA is intended for use over both physically insecure and=20 > physically or otherwise secure networks." (10. Security Claims [a]) > EAP [2] (Issue 208) is intended for use over physically=20 > insecure networks. > Use cases of EAP-AKA are different to those of EAP. > Nevertheless, current EAP-AKA notifies authentication result by=20 > unprotected EAP Success/Failure. >=20 > In EAP-AKA, peer receives bogus Success/Failure from attacker.=20 > ([1] Section 9.8) > Then, I am anxious that if attacker sends bogus Failure in case of=20 > authentication Success in network, legitimate peer can never=20 > get access > of network. > It is DoS attack by sending bogus authentication result. > As a result, any peer cannot get access of network in case of bogus=20 > Failure sent by attacker. >=20 > So, I think that current notification of authentication result is=20 > contradictory to Security Claim [a]. > Isn't it necessary to update current EAP-AKA to be suitable=20 > for Security > Claim [a]? >=20 > To solve this problem, for example, I think that EAP-AKA should be=20 > improve to send integrity-protected Success/Failure like PEAP [3]. > Then, IK can be used to protect Success/Failure in EAP-AKA. >=20 > Thank you for reading. >=20 > References > [1] J. Arkko, et al., "EAP AKA Authentication,"=20 > draft-arkko-pppext-eap-aka-11.txt, October 2003. > [2] L.Blunk, et al., "Extensible Authentication Protocol (EAP),"=20 > draft-ietf-eap-rfc2284bis-08.j.txt, November 2003. > [3] D. Simon, et al., "Protected EAP Protocol (PEAP) Version 2,"=20 > draft-josefsson-pppext-eap-tls-eap-07.txt, October 2003. >=20 > With Best Regards, >=20 > Hisatoshi EGUCHI=20 >=20 >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jan 21 03:29:03 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11979 for ; Wed, 21 Jan 2004 03:29:03 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6FEDB20236; Wed, 21 Jan 2004 03:18:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id AC6DA201F5 for ; Wed, 21 Jan 2004 03:17:05 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id B8F9F6A901; Wed, 21 Jan 2004 10:28:00 +0200 (EET) Message-ID: <400E1B92.7060204@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Burns Cc: Bernard Aboba , eap@frascone.com, stds-802-1@ieee.org, Paul Congdon , John Vollbrecht , Bob Moskowitz , Preeti vinayakray Subject: Re: [eap] Discrepancies between 802.1XREV and RFC 2248bis References: <400C719A.5080502@mtghouse.com> In-Reply-To: <400C719A.5080502@mtghouse.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 21 Jan 2004 08:26:26 +0200 Content-Transfer-Encoding: 7bit Jim, Your list looks good to me. --Jari > I believe the points we want to make in 6.7 are the following: > .1X is an asymmetric transport protocol (it has two separate roles). > It is asymmetric due to history when only the authenticator had a > controlled port. > Now that both the supplicant and authenticator both have a controlled > port the asymmetry of the .1X transport does not disallow a mutual > authentication EAP method from doing a bi-directional authentication > over the .1X transport. > There are some idiosyncracies of the asymmetric nature of the .1X > transport, the main one being that two simultaneous authentications can > be run if both .1X machines are implemented and both must complete > successfully for the controlled port to be unblocked. > There are reasons that you may want to utilize two simultaneous > authentications, as described in section 2.4 of 2284 (as well as some of > the verbage in 6.7). > It should be made clear that two coupled one-way authentications does > not provide the same security as a single mutual authentication. > Each application should define which roles of the .1X state machines > each device is to implement as well as the class of EAP methods (mutual > authenticating or unidirectional authentication or both) that are required. > One must be careful of certain combinations of the number of machines, > and be aware that a device with both .1X machines encountering a device > with just the .1X authenticator will result in an asymmetric network > connection (controlled port open on one device and closed on the > other). I have a table that defines all the cases clearly. > -------------------------- > Known uses are: 802.11 infrastructure: 1 supplicant on client and 1 > authenticator on AP using mutual authenticating EAP methods. > 802.11 adhoc: Each adhoc station should run both supplicant and > authenticator with key generating EAP methods. The key used for group > key is from the highest numbered MAC address. > 802.1 bridges: Both supplicant and authenticator with special > variable that makes controlled port controlled only by authenticator > enabled. EAP method type not defined. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jan 21 03:29:37 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11997 for ; Wed, 21 Jan 2004 03:29:37 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1F89920241; Wed, 21 Jan 2004 03:18:11 -0500 (EST) Delivered-To: eap@frascone.com Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 2F60F20236 for ; Wed, 21 Jan 2004 03:17:06 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 7E5606A902; Wed, 21 Jan 2004 10:28:02 +0200 (EET) Message-ID: <400E1F01.9020709@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Rafa_Mar=EDn_L=F3pez?= Cc: eap@frascone.com, Bernard Aboba Subject: Re: [eap] EAP Key Management Framework doubt References: <40059307.5050100@dif.um.es> <400C1C30.3060306@dif.um.es> In-Reply-To: <400C1C30.3060306@dif.um.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 21 Jan 2004 08:41:05 +0200 Content-Transfer-Encoding: 8bit Rafa Marín Lopez wrote: >> Figure 4 shows that MSK is placed on Authenticator but only AAA-key is >> transported from AAA server... ? ... furthermore the text tells MSK >> is transported to Authenticator... in another places AAA-key is >> carried ... I think it would be better to say : AAA - key is carried >> to authenticator and it could be the MSK (as appendix E tells)... what >> do you think? I'm not sure I can find the place that you find confusing. Can you point us to the location in the text where it says that the MSK is transported to the authenticator? Or perhaps its this text: The MSK and EMSK are used to derive the AAA-Key and key name which are enclosed within the AAA-Token, transported to the NAS by the AAA server, and used within the secure association protocol for derivation of Transient Session Keys (TSKs) required for the negotiated ciphersuite. This may be confusing, as the subject of transportation is not perhaps clear. How about this instead: The MSK and EMSK are used to derive the AAA-Key and key name. AAA-Key and key name are enclosed within the AAA-Token, which is transported to the NAS by the AAA server, and used within the secure association protocol for derivation of Transient Session Keys (TSKs) required for the negotiated ciphersuite. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jan 21 03:30:24 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12049 for ; Wed, 21 Jan 2004 03:30:23 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E0DE720244; Wed, 21 Jan 2004 03:18:15 -0500 (EST) Delivered-To: eap@frascone.com Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id A24BC201F5 for ; Wed, 21 Jan 2004 03:17:07 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id D8D566A903; Wed, 21 Jan 2004 10:28:03 +0200 (EET) Message-ID: <400E21FC.5070709@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba , Joe Salowey Cc: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [eap] keying appendix E vs. EMSK guidelines Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 21 Jan 2004 08:53:48 +0200 Content-Transfer-Encoding: 7bit Description of issue: keying appendix E vs. EMSK guidelines Submitter name: Jari Arkko Submitter email address: jari.arkko@piuha.net Date first submitted: Jan 21, 2004 Reference: Document: Keying Framework Comment type: T Priority: 1 Section: Appendix E Rationale/Explanation of issue: Appendix E of keying-01 talks about the derivation of suitable AAA Keys for handoff situations. It gives the following formulae: AAA-Key-B = PRF(EMSK(0,63),AAA-Key-A, B-Called-Station-Id,Calling-Station-Id) AAA-Key-E = PRF(EMSK(0,63),AAA-Key-A, E-Called-Station-Id,Calling-Station-Id) But draft-salowey-eap-keying-02 discusses EMSK usage, and I think we have agreed at least about this: o The application MUST NOT use the EMSK in any other way except to derive Application Master Session Keys (AMSK) using the key derivation specified in section 3 this document. They MUST NOT use the EMSK directly. o Applications MUST define distinct key labels and application specific data used in the key derivation described in section 3. Appendix E appears to break the second requirement. Joe's draft gives the following construction for AMSKs: AMSK = KDF(EMSK, key label, optional application data, length) Perhaps appendix E could be corrected to be inline with this? Here's the suggested text change: AAA-Key-B = PRF(EMSK(0,63),"EAP AAA-Key derivation for multiple attachments", AAA-Key-A,B-Called-Station-Id,Calling-Station-Id) AAA-Key-E = PRF(EMSK(0,63),"EAP AAA-Key derivation for multiple attachments", AAA-Key-A,E-Called-Station-Id,Calling-Station-Id) Also, the rules about the calling and called station ids could perhaps be made less link layer specific: Calling-Station-Id = STA MAC address B-Called-Station-Id = AP B MAC address E-Called-Station-Id = AP E MAC address => Calling-Station-Id = peer identity B-Called-Station-Id = second attachment point identity E-Called-Station-Id = third attachment point identity --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jan 21 09:39:09 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23513 for ; Wed, 21 Jan 2004 09:39:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 61F442020A; Wed, 21 Jan 2004 09:28:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from smtp.um.es (xenon2.um.es [155.54.212.101]) by mail.frascone.com (Postfix) with ESMTP id B5A4C20202 for ; Wed, 21 Jan 2004 09:27:04 -0500 (EST) Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 173E134DAF; Wed, 21 Jan 2004 15:38:01 +0100 (CET) Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by smtp.um.es (Postfix) with ESMTP id F2D5C34DA6; Wed, 21 Jan 2004 15:38:00 +0100 (CET) Received: from dif.um.es (bravecard.dif.um.es [155.54.210.47]) by aries.dif.um.es (Postfix) with ESMTP id 6899A14426; Wed, 21 Jan 2004 15:24:32 +0100 (MET) Message-ID: <400E8E3A.7040105@dif.um.es> From: =?ISO-8859-1?Q?Rafa_Mar=EDn_L=F3pez?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Accept-Language: en MIME-Version: 1.0 Cc: jari.arkko@piuha.net, eap@frascone.com Subject: Re: [eap] EAP Key Management Framework doubt References: <40059307.5050100@dif.um.es> <400C1C30.3060306@dif.um.es> <400E1F01.9020709@piuha.net> <400E8D3E.70707@dif.um.es> In-Reply-To: <400E8D3E.70707@dif.um.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 21 Jan 2004 15:35:38 +0100 Content-Transfer-Encoding: 8bit Rafa Marín López wrote: > Hello Jari > > Iniatilly in Figure 4 , authenticator box has a MSK written on it. So > I could understand which MSK is transported.... about text... page 30 > > Utilizing the AAA protocol, the authenticator and backend > authentication server mutually authenticate and derive session keys > known only to them, used to provide per-packet integrity and replay > protection, authentication and confidentiality. > ---> The MSK is distributed by the backend authentication server to > the authenticator > over this channel, bound to attributes constraining its usage, as > part of the AAA-Token. ----> The binding of attributes to the MSK > within a > protected package is important so the authenticator receiving the > AAA-Token can determine that it has not been compromised, and that > the keying material has not been replayed, or mis-directed in some > > > > > So I think it would be better to say something like : AAA - key is > carried to authenticator and it could be the MSK (as appendix E tells) > > Regards... > > > > Jari Arkko wrote: > >> Rafa Marín Lopez wrote: >> >>>> Figure 4 shows that MSK is placed on Authenticator but only AAA-key >>>> is transported from AAA server... ? ... furthermore the text tells >>>> MSK is transported to Authenticator... in another places AAA-key is >>>> carried ... I think it would be better to say : AAA - key is >>>> carried to authenticator and it could be the MSK (as appendix E >>>> tells)... what do you think? >>> >>> >> >> I'm not sure I can find the place that you find confusing. Can you >> point us to the location in the text where it says that the MSK is >> transported to the authenticator? >> >> Or perhaps its this text: >> >> The MSK and EMSK are used to derive the AAA-Key and key name which >> are enclosed within the AAA-Token, transported to the NAS by the AAA >> server, and used within the secure association protocol for >> derivation of Transient Session Keys (TSKs) required for the >> negotiated ciphersuite. >> >> This may be confusing, as the subject of transportation is not perhaps >> clear. How about this instead: >> >> The MSK and EMSK are used to derive the AAA-Key and key name. AAA-Key >> and key name are enclosed within the AAA-Token, which is >> transported to the >> NAS by the AAA server, and used within the secure association >> protocol for >> derivation of Transient Session Keys (TSKs) required for the >> negotiated ciphersuite. >> >> --Jari >> >> >> >> > > -- ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------ _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jan 21 17:12:24 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13661 for ; Wed, 21 Jan 2004 17:12:23 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 602612024E; Wed, 21 Jan 2004 17:01:07 -0500 (EST) Delivered-To: eap@frascone.com Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id 6C91F2020B for ; Wed, 21 Jan 2004 17:00:44 -0500 (EST) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 21 Jan 2004 14:12:46 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i0LMBa5k004708 for ; Wed, 21 Jan 2004 14:11:37 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.99.27]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 21 Jan 2004 14:17:23 -0800 From: "Joseph Salowey" To: Message-ID: <013301c3e06b$895c0ea0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 21 Jan 2004 22:17:23.0899 (UTC) FILETIME=[584C48B0:01C3E06C] Subject: [eap] [Issue ] Comments on section 3 of keying draft Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 21 Jan 2004 14:11:36 -0800 Content-Transfer-Encoding: 7bit Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date first submitted: 1/21/2004 Reference: Document: Keying Framework Comment type: 'E'ditorial Priority: '1' Should fix Section: Section 3 Rationale/Explanation of issue: 1. Use of term "security Association": In section 3 the use of term security association is somewhat non-standard. A security association is typically something that is generated dynamically and valid for a length of time. [1] The EAP-SA is more of a static relationship such as a trusted root key. [2] The EAP-Method SA is more along the lines of standard SA terminology. It is not visible outside the EAP-method. [3] The EAP-Key SA I do not think is really an SA. There are EAP-Key(s), but they must be managed outside the EAP protocol since EAP provides no key management functionality other than establishment. These EAP-Seeded SAs are managed by some other application separate from EAP. Examples of EAP Seeded SA are in section 3.5 [4] The AAA-SA is similar to [1] above in that there is a trusted root key. There are also "EAP-Seeded" SAs of which 3.5 is an example Recommended Changes: Use a different term than security association for other relationships or don't discuss them in this section. I'm not sure that so much detail is needed for the EAP-Method SA since it is not visible outside a method. Create section on EAP-Seeded SAs which describes Unicast SA and other possible SA based on the exchanged EAP keys. DO not use the term EAP SA as it confusing as to what is being discussed. I'm not sure that multicast security association needs to be discussed as it is usually is derived from a unicast security association and not directly involved with EAP. 2. Key Naming (Section 3.7) I think the only thing that needs to be named within the scope of EAP is the MSK and the EMSK resulting from a particular EAP exchange. This needs to be defined by the method. Here is some suggested test "EAP methods are responsible for defining and exporting a key name. The base EAP key name is an octet string between 15 and 31 octets. To name the MSK a M is prepended to the base name and for the EMSK a 'E' is prepended to the base name. The method for generating a base name is specific to the method, but it must be unique to each exchange and cryptographically bound to the exchange. An example for EAP-TLS is to take MD5 hash of the two finished messages in the TLS handshake in the order that they appear. It is NOT RECOMMENDED that a static function of the MSK or EMSK be used as publically known name. Other applications may use the EAP key name to derive names for their purposes that have additional meaning. " _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Jan 21 18:41:07 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18088 for ; Wed, 21 Jan 2004 18:41:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 06B6C2025B; Wed, 21 Jan 2004 18:30:09 -0500 (EST) Delivered-To: eap@frascone.com Received: from deneb.mtghouse.com (unknown [206.152.191.132]) by mail.frascone.com (Postfix) with SMTP id C82E0201F2 for ; Wed, 21 Jan 2004 18:29:59 -0500 (EST) Received: (qmail 8411 invoked from network); 21 Jan 2004 23:40:57 -0000 Received: from unknown (HELO mtghouse.com) (192.168.11.223) by deneb.mtghouse.com with SMTP; 21 Jan 2004 23:40:57 -0000 Message-ID: <400F0E0C.7010309@mtghouse.com> From: Jim Burns User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030829 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Burns Cc: Bernard Aboba , eap@frascone.com, stds-802-1@ieee.org, "CONGDON,PAUL (HP-Roseville,ex1)" , Bob Moskowitz , John Vollbrecht , Jari Arkko References: <400C719A.5080502@mtghouse.com> <400D3572.40707@mtghouse.com> In-Reply-To: <400D3572.40707@mtghouse.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [eap] Strawman for a modified section 6.7 for IEEE 802.1XRev Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 21 Jan 2004 18:41:00 -0500 Content-Transfer-Encoding: 8bit Folks, Below is a strawman for section 6.7 of the IEEE 802.1XRev document. It attempts to remedy the discrepencies with section 2.4 of IETF RFC 2284bis. I have incorporated ideas from original 6.7 and a number of folks, thanks to all. Please send critiques, comments, concerns and I will try to make modifications to satisfy all. As Tony J. indicated, we are very late in the 802.1XRev cycle and we will have only one official cycle on this so we should do all our cycling here and get it right the first time. Thanks, Jim B. Modified IEEE 802.1XREV Section 6.7 Please use a fixed width font to view this. Also, you may need to widen your window to view the table. ---------------------------------------------------- 6.7 Coupling two 802.1X authentications This section discusses the asymmetric nature of the 802.1X transport, how this asymmetry affects authentication results, the ability of the 802.1X transport mechanism to run two simultaneous transports in opposite directions, how this affects authentication results and why this simultaneous bi-directional transport may be utilized. 802.1X's transport mechanism for authentication frames is asymmetric; there is a requestor role (authenticator) and a responder role (supplicant). The authenticator transmits frames to the supplicant and the supplicant responds to those frames with frames of its own. It is a request/response transport and the state machines reflect this. This request/response transport mirrors the authentication protocol that is carried within the 802.1X transport: EAP. Such a transport is sometimes called 'one-way' meaning the protocol is always originating from one side (the requestor). This transport asymmetry (of 1X and EAP) does not affect the symmetry (or asymmetry) of the authentication method (EAP method) that is carried by the transport. Please note the separate usage of 'authentication protocol (EAP)' from 'authentication method (EAP method)' in this discussion (for a deeper understanding please see RFC 2284). A mutually authenticating EAP method (such as EAP-TLS) may run atop the asymmetric transport mechanism and mutually authenticate both parties (it is symmetric in that both parties contribute to the authentication result). Likewise, if the EAP-method that is chosen is assymmetric (EAP-MD5), then the authentication will be assymmetric (only one party will be authenticated to the other). In fact, it is not the 802.1X transport that controls the symmetry of the authentication, but rather the chosen EAP method and the existence of a controlled port on both the supplicant and authenticator. It should be noted that in an earlier version of 802.1X (802.1X 2001), only the authenticator was specified to have a controlled port. This previous version of 802.1X did in fact restrict the authentication result to be asymmetric (no matter what EAP method was chosen), but it was due to the lack of a controlled port on the supplicant, not due to the asymmetric transport. The current version of 802.1X remedies this by specifying a controlled port on the supplicant. The 802.1X transport asymmetry means that each role has its own state machine and it is possible that a single device can implement both roles (state machines). If a device with both roles implemented encounters another device with both roles then two separate (and simultaneous) 802.1X transports will take place in opposite directions. This is sometimes referred to as a bi-directional authentication transport or two coupled one-way authentication transports. One must understand that two coupled one-way authentication transports is not equivalent in security to a single transport of a mutually authenticating EAP method (such as EAP-TLS). This is because the authentications on the two separate transports are not specified to be cryptographically bound together. In other words there is no way to cryptographically ascertain that the party involved in the first one-way transport is the same party that is involved in the alternate one-way transport. Despite the ability to mutually authenticate two devices with a single transport, there may exist other reasons to simultaneously run two 802.1X transports in opposite directions. When both devices require the creation of separate keying material as in unicast keys for 802.11 adhoc networks. When different credentials are used for different roles (one credential for the supplicant role and one for the authenticator) then a bi-directional transport with EAP-TLS using different certificates in each direction may be used. When two bridge devices are connected together and they wish to authenticate each other then they may implement both roles on their connecting ports. Some of these cases are discussed in section 2.4 of RFC 2284. Certain encounters between a device with both .1X transport roles implemented and a device with a single .1X transport role can result in an asymmetric traffic flow (traffic can only flow in one direction). This occurs because one device opens its controlled port while the other device does not. A complete table of encounters and results (assuming authentication successes) appears in Table xxxx. Table xxxx: Result of encounters between .1X transport roles assuming key-generating EAP methods are run and result in success. Remote\Local--> | Supplicant | Authenticator | Both | | | | V | | | ---------------------------------------------------------------------- Supplicant |Fails gracefully | Works | Works |No link will be | Authenticated | Authenticated |formed if media | link | link |is considered | Authentication | Authentication |unsafe without | policy is set by | policy set by |encryption | choice of EAP | choice of EAP |(802.11). | method. | method | | | Remote |Unauthenticated | | supplicant and |link will be | | local |formed if media | | authenticator |is considered | | are satisfied. |safe by default | | Local |(802.3) | | supplicant will | | | receive no | | | response and | | | assume no | | | authenticator. | | | Successful | | | authentication | | | to the local | | | authenticator | | | will have made | | | the port | | | secure. ----------------------------------------------------------------------- Authenticator |Works - |Fails gracefully |Fails – |Authenticated |No link will be |Asymmetric link |link – |formed. Each |Remote |Authentication |authenticator |controlled port |policy set by |will send initial |is operational, |choice of EAP |EAP requests but |but local |method. |no response will |controlled port | |arrive. |remains non- | | |operational. | | |Remote | | |authenticator | | |and local | | |supplicant are | | |satisfied, | | |local | | |authenticator | | |remains | | |unsatisfied. ----------------------------------------------------------------------- Both |Works |Fails |Works |Authenticated |Asymmetric link | Authenticated |link |Local controlled | link |Authentication |port is | Authentication |policy set by |operational, but | policy set by |choice of EAP |remote controlled | choice of two |method. |port remains non- | uncoupled EAP |Local supplicant |operational. | methods. Two |and remote |Local | keys will be |authenticator |authenticator and | formed and some |are satisfied. |remote supplicant | mechanism must |Remote |are satisfied, | exist so that |supplicant will |remote | local and |receive no |authenticator | remote choose |response and |remains | the same key. |assume no |unsatisfied. | |authenticator. | | |Successful | | |authentication | | |to the remote | | |authenticator | | |will have made | | |the port secure. | | ----------------------------------------------------------------------- Applications that utilize 802.1X should clearly specify which .1X roles must be implemented to avoid encounters that will result in failed network connections. In addition, an application should consider specifying a class of EAP methods or a limited set of EAP methods to allow for simpler security analysis of the application. Some examples of known applications and their common usage of 802.1X and EAP are: 802.11i infrastructure mode - Access point implements authenticator role - Client implements the supplicant role - A mutually authenticating EAP method is utilized 802.1 bridge to end node - Bridge implements the authenticator role - End node implements the supplicant role - No EAP method type specified 802.11 adhoc mode - Each adhoc device implements both the supplicant and authenticator role - A key-generating EAP method is utilized. 802.1 bridge to 802.1 bridge - Each bridge implements both the supplicant and authenticator role. - Each bridge sets the Supplicant Access Control With Authenticator administrative control parameter to inactive so that only the authenticator role controls the controlled port. Jim Burns wrote: > > Hi Bernard, > Yes, I would be happy to take a first crack at it and then accept input. > My schedule is such that I will not get it out til this eve or > Wednesday AM. > Sorry about the delay, > Jim B. > > Bernard Aboba wrote: > >>> Hi folks, >>> Yes, a reread of 6.7 leads me to believe that it could be confusing >>> to implementers. My opinion is that the current 6.7 was written before >>> there was a supplicant controlled port. With the addition of the >>> supplicant controlled port, the uni-directional nature of the transport >>> is no longer a blocking feature to a bi-directional EAP method. >>> >> >> I agree (modulo the caveats in Section 2.4 of RFC 2284bis). >> >> >> >>> I believe the points we want to make in 6.7 are the following: >>> >> >> This sounds like a good start. Do you want to draft some sample text for >> review? >> >> >> > > > > =>IEEE 802.1 Email List user information: > http://www.ieee802.org/1/email-pages/ > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Jan 22 01:55:12 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28473 for ; Thu, 22 Jan 2004 01:55:11 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AB85720201; Thu, 22 Jan 2004 01:44:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 4B8AD201F2 for ; Thu, 22 Jan 2004 01:43:54 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id BE96B6A903; Thu, 22 Jan 2004 08:54:51 +0200 (EET) Message-ID: <400F7369.8090708@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Rafa_Mar=EDn_L=F3pez?= Cc: "eap@frascone.com" Subject: Re: [eap] EAP Key Management Framework doubt References: <40059307.5050100@dif.um.es> <400C1C30.3060306@dif.um.es> <400E1F01.9020709@piuha.net> <400E8D3E.70707@dif.um.es> In-Reply-To: <400E8D3E.70707@dif.um.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 22 Jan 2004 08:53:29 +0200 Content-Transfer-Encoding: 8bit Rafa Marín López wrote: > Hello Jari > > Iniatilly in Figure 4 , authenticator box has a MSK written on it. So I Ah, now I see it. Figure 4 is IMHO wrong. MSK in the authenticator should be the AAA-Key; as you see the arrow transports the AAA-Key and not the MSK. > could understand which MSK is transported.... about text... page 30 > > Utilizing the AAA protocol, the authenticator and backend > authentication server mutually authenticate and derive session keys > known only to them, used to provide per-packet integrity and replay > protection, authentication and confidentiality. > ---> The MSK is distributed by the backend authentication server to the > authenticator > over this channel, bound to attributes constraining its usage, as > part of the AAA-Token. ----> The binding of attributes to the MSK > within a > protected package is important so the authenticator receiving the > AAA-Token can determine that it has not been compromised, and that > the keying material has not been replayed, or mis-directed in some This is wrong too, I think. s/MSK/AAA-Key/g in this paragraph. Here's a summary of the modifications I would do to fix this: o In Figure 4, s/MSK/AAA-Key/ in the Authenticator box. o In Section 4.1, replace the paragraph Utilizing the AAA protocol, the authenticator and backend authentication server mutually authenticate and derive session keys known only to them, used to provide per-packet integrity and replay protection, authentication and confidentiality. The MSK is distributed by the backend authentication server to the authenticator over this channel, bound to attributes constraining its usage, as part of the AAA-Token. The binding of attributes to the MSK within a protected package is important so the authenticator receiving the AAA-Token can determine that it has not been compromised, and that the keying material has not been replayed, or mis-directed in some way. with Utilizing the AAA protocol, the authenticator and backend authentication server mutually authenticate and derive session keys known only to them, used to provide per-packet integrity and replay protection, authentication and confidentiality. The AAA-Key is distributed by the backend authentication server to the authenticator over this channel, bound to attributes constraining its usage, as part of the AAA-Token. The binding of attributes to the AAA-Key within a protected package is important so the authenticator receiving the AAA-Token can determine that it has not been compromised, and that the keying material has not been replayed, or mis-directed in some way. o Section 2.3, replace the paragraph The MSK and EMSK are used to derive the AAA-Key and key name which are enclosed within the AAA-Token, transported to the NAS by the AAA server, and used within the secure association protocol for derivation of Transient Session Keys (TSKs) required for the negotiated ciphersuite. with The MSK and EMSK are used to derive the AAA-Key and key name. AAA-Key and key name are enclosed within the AAA-Token, which is transported to the NAS by the AAA server, and used within the secure association protocol for derivation of Transient Session Keys (TSKs) required for the negotiated ciphersuite. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Jan 22 09:48:08 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22725 for ; Thu, 22 Jan 2004 09:48:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2A6A52022D; Thu, 22 Jan 2004 09:37:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from deneb.mtghouse.com (unknown [206.152.191.132]) by mail.frascone.com (Postfix) with SMTP id EF09B20215 for ; Thu, 22 Jan 2004 09:36:30 -0500 (EST) Received: (qmail 5913 invoked from network); 22 Jan 2004 14:47:29 -0000 Received: from unknown (HELO mtghouse.com) (192.168.10.122) by deneb.mtghouse.com with SMTP; 22 Jan 2004 14:47:29 -0000 Message-ID: <400FE287.3080709@mtghouse.com> From: Jim Burns User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030829 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com, stds-802-1@ieee.org, Bob Moskowitz , "CONGDON,PAUL (HP-Roseville,ex1)" , John Vollbrecht , Jari Arkko References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [eap] Re: Strawman for a modified section 6.7 (V3) for IEEE 802.1XRev Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 22 Jan 2004 09:47:35 -0500 Content-Transfer-Encoding: 8bit Hello, Thanks for the 2nd revision Bernard, it was much improved. Below is a 3rd revision that began with the 2nd and modified the last two paragraphs: 1. Changed the text in the 2nd to last paragraph to indicate that if a device with two roles implemented encounters one with just an authenticator implemented then an asymmetric network flow can occur (one controlled port open, the other closed). It is only an encounter with a single authenticator that causes this, encounters with a single supplicant will eventually result in a symmetric network flow (supplicant will time out after making 3 attempts to contact a non-existant authenticator and since the authenticator that is running in the same device will have made the link secure the supplicant should enter the authenticated state). 2. Put back a paragraph about suggested use of .1X in applications, but did not put back the discussion about EAP nor about specific applications that currently use .1X. I just want to stress that to avoid the asymmetric network flow an application must ensure that the two role device encountering an authenticator-only role device is avoided. REVISION 3: 6.7 Coupling two 802.1X authentications This section discusses the ability of 802.1X to run two simultaneous transports in opposite directions, how implementation asymetries affect authentication results and how simultaneous bi-directional transport may be utilized. In 802.1X there is a requestor role (authenticator) and a responder role (supplicant). The authenticator transmits frames to the supplicant and the supplicant responds to those frames with frames of its own. 802.1X, like the authentication protocol carried within it (EAP), is a request/response protocol, and the state machines reflect this. Such a transport is sometimes called 'one-way' meaning the protocol exchanges always originate from one side (the requestor). However, it is not 802.1X that controls whether the authentication is mutual or one-way but rather the chosen EAP method and the existence of a controlled port on both the supplicant and authenticator. Despite the asymmetry of 802.1X and EAP, if a mutually authenticating EAP method (such as EAP-TLS) is carried within 802.1X frames, then the supplicant and authenticator can mutually authenticate. However, if an EAP method is chosen which only authenticates the supplicant to the authenticator (e.g. EAP MD5-CHALLENGE), then the authentication will be one-way. In an earlier version of 802.1X (802.1X-2001), only the authenticator was specified to have a controlled port. This previous version of 802.1X did in fact restrict the authentication result to be one-way (no matter what EAP method was chosen). However, this was due to the lack of a controlled port on the supplicant, not due to the inherent properties of the 802.1X protocol. The current version of 802.1X remedies this by specifying a controlled port on the supplicant. In 802.1X, each role has its own state machine and it is possible that a single device can implement both the supplicant and authenticator roles (state machines). If a device implementing both roles encounters another device implementing both roles, then two separate (and simultaneous) 802.1X exchanges will take place in opposite directions. This is sometimes referred to as a bi-directional authentication transport or two coupled one-way authentication exchanges. Two coupled one-way authentication exchanges are not equivalent in security to a single exchange of a mutually authenticating EAP method (such as EAP-TLS). Since the two coupled one-way authentication exchanges are not cryptographically bound together, there is no way to ascertain that the party involved in the first one-way exchange is the same party that is involved in the alternate one-way exchange. Even though a single 802.1X exchange may provide mutual authentication, there may be other reasons to run two 802.1X exchanges in opposite directions. RFC 2284bis, Section 2.4 discusses some of these cases, which include: 1) When the devices require the creation of separate keying material as in unicast keys for 802.11 adhoc networks. 2) When different credentials are used for different roles (one credential for the supplicant role and one for the authenticator). 3) When two bridge devices implementing both roles are connected together and they wish to authenticate each other. When a device which implements both 802.1X roles encounters a device which implements only a single authenticator role, this can result in asymmetric data flow (data traffic can only flow in one direction). This occurs because one device opens its controlled port while the other device does not. A complete table of encounters and results (assuming authentication successes) appears in Table xxxx. It is suggested that applications utilizing 802.1X should specify which .1X roles must be implemented to avoid encounters that will result in failed network connections. Table xxxx: Result of encounters between .1X transport roles assuming key-generating EAP methods are run and result in success. Remote\Local--> | Supplicant | Authenticator | Both | | | | V | | | ---------------------------------------------------------------------- Supplicant |Fails gracefully | Works | Works |No link will be | Authenticated | Authenticated |formed if media | link | link |is considered | Authentication | Authentication |unsafe without | policy is set by | policy set by |encryption | choice of EAP | choice of EAP |(802.11). | method. | method | | | Remote |Unauthenticated | | supplicant and |link will be | | local |formed if media | | authenticator |is considered | | are satisfied. |safe by default | | Local |(802.3) | | supplicant will | | | receive no | | | response and | | | assume no | | | authenticator. | | | Successful | | | authentication | | | to the local | | | authenticator | | | will have made | | | the port | | | secure. ----------------------------------------------------------------------- Authenticator |Works - |Fails gracefully |Fails – |Authenticated |No link will be |Asymmetric link |link – |formed. Each |Remote |Authentication |authenticator |controlled port |policy set by |will send initial |is operational, |choice of EAP |EAP requests but |but local |method. |no response will |controlled port | |arrive. |remains non- | | |operational. | | |Remote | | |authenticator | | |and local | | |supplicant are | | |satisfied, | | |local | | |authenticator | | |remains | | |unsatisfied. ----------------------------------------------------------------------- Both |Works |Fails |Works |Authenticated |Asymmetric link | Authenticated |link |Local controlled | link |Authentication |port is | Authentication |policy set by |operational, but | policy set by |choice of EAP |remote controlled | choice of two |method. |port remains non- | uncoupled EAP |Local supplicant |operational. | methods. Two |and remote |Local | keys will be |authenticator |authenticator and | formed and some |are satisfied. |remote supplicant | mechanism must |Remote |are satisfied, | exist so that |supplicant will |remote | local and |receive no |authenticator | remote choose |response and |remains | the same key. |assume no |unsatisfied. | |authenticator. | | |Successful | | |authentication | | |to the remote | | |authenticator | | |will have made | | |the port secure. | | -----------------------------------------------------------------------. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Jan 22 14:15:25 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05305 for ; Thu, 22 Jan 2004 14:15:25 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5C9EA20215; Thu, 22 Jan 2004 14:03:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from struggle.mr.itd.umich.edu (struggle.mr.itd.umich.edu [141.211.14.79]) by mail.frascone.com (Postfix) with ESMTP id 07D4820201 for ; Thu, 22 Jan 2004 14:02:04 -0500 (EST) Received: from dhcp60-09.merit.edu (dhcp60-09.merit.edu [198.108.60.209]) by struggle.mr.itd.umich.edu (smtp) with ESMTP id i0MJCqCX011436; Thu, 22 Jan 2004 14:12:52 -0500 From: John Vollbrecht To: Joseph Salowey , eap@frascone.com Subject: Re: [eap] [Issue ] Comments on section 3 of keying draft Message-ID: <2954066.1074780768@dhcp60-09.merit.edu> In-Reply-To: <013301c3e06b$895c0ea0$0300000a@amer.cisco.com> References: <013301c3e06b$895c0ea0$0300000a@amer.cisco.com> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 22 Jan 2004 14:12:48 -0500 Content-Transfer-Encoding: 7bit --On Wednesday, January 21, 2004 2:11 PM -0800 Joseph Salowey wrote: > Submitter name: Joe Salowey > Submitter email address: jsalowey@cisco.com > Date first submitted: 1/21/2004 > Reference: > Document: Keying Framework > Comment type: 'E'ditorial > Priority: '1' Should fix > Section: Section 3 > Rationale/Explanation of issue: > > 1. Use of term "security Association": > > In section 3 the use of term security association is somewhat > non-standard. A security association is typically something that is > generated dynamically and valid for a length of time. > > [1] The EAP-SA is more of a static relationship such as a trusted root > key. > [2] The EAP-Method SA is more along the lines of standard SA > terminology. It is not visible outside the EAP-method. > [3] The EAP-Key SA I do not think is really an SA. There are > EAP-Key(s), but they must be managed outside the EAP protocol since EAP > provides no key management functionality other than establishment. > These EAP-Seeded SAs are managed by some other application separate from > EAP. Examples of EAP Seeded SA are in section 3.5 > [4] The AAA-SA is similar to [1] above in that there is a trusted root > key. > > > There are also "EAP-Seeded" SAs of which 3.5 is an example > > Recommended Changes: > > Use a different term than security association for other relationships > or don't discuss them in this section. > > I'm not sure that so much detail is needed for the EAP-Method SA since > it is not visible outside a method. > > Create section on EAP-Seeded SAs which describes Unicast SA and other > possible SA based on the exchanged EAP keys. > I like the approach described here. I do have a question about whether the SA, which is used by 802.11, should be described in an EAP spec. Perhaps it should because EAP is spelling out requirements for EAP methods. Perhaps it should because there is no place else. My question is though, if no use of EMSK is included, why include use of MSK? Also, is there a reason, if multiple AMSKs can be derived from the EMSK that the MSK could not also be derived from it? I am not an expert in this area, so this may well be fine. > DO not use the term EAP SA as it confusing as to what is being > discussed. > > I'm not sure that multicast security association needs to be discussed > as it is usually is derived from a unicast security association and not > directly involved with EAP. > > > 2. Key Naming (Section 3.7) > > I think the only thing that needs to be named within the scope of EAP is > the MSK and the EMSK resulting from a particular EAP exchange. This > needs to be defined by the method. Here is some suggested test > Perhaps some indication of which Server as well as which method would be appropriate? I am not sure exactly what the key name supports, so this may be inappropriate. > "EAP methods are responsible for defining and exporting a key name. The > base EAP key name is an octet string between 15 and 31 octets. To name > the MSK a M is prepended to the base name and for the EMSK a 'E' is > prepended to the base name. The method for generating a base name is > specific to the method, but it must be unique to each exchange and > cryptographically bound to the exchange. An example for EAP-TLS is to > take MD5 hash of the two finished messages in the TLS handshake in the > order that they appear. It is NOT RECOMMENDED that a static function of > the MSK or EMSK be used as publically known name. Other applications may > use the EAP key name to derive names for their purposes that have > additional meaning. " > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Jan 22 16:00:27 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11329 for ; Thu, 22 Jan 2004 16:00:26 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3A91D20201; Thu, 22 Jan 2004 15:48:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from deneb.mtghouse.com (unknown [206.152.191.132]) by mail.frascone.com (Postfix) with SMTP id 393382014D for ; Thu, 22 Jan 2004 15:47:50 -0500 (EST) Received: (qmail 4646 invoked from network); 22 Jan 2004 20:58:49 -0000 Received: from unknown (HELO mtghouse.com) (192.168.10.122) by deneb.mtghouse.com with SMTP; 22 Jan 2004 20:58:49 -0000 Message-ID: <4010398F.1060007@mtghouse.com> From: Jim Burns User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com, stds-802-1@ieee.org, rgm@truesecure.com, paul.congdon@hp.com, jrv@umich.edu, jari.arkko@piuha.net References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [eap] Re: [802.1] Re: Strawman for a modified section 6.7 (V3) for IEEE 802.1XRev Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 22 Jan 2004 15:58:55 -0500 Content-Transfer-Encoding: 7bit Hello Bernard, Thanks for the catch on group vs unicast keys. Actually, the bridge-to-bridge case is a bit more complex. It is partially tie-breaking. In addition there is an issue of access to a single authentication server. The most common bridge-to-bridge configuration is that there is a single authentication server that both bridges are utilizing. One of the bridges has immediate access to the authentication server (no intervening .1X controlled port), the second bridge accesses the authentication server through the first bridge (there is an intervening .1X controlled port). So, in a bridge to bridge configuration, a special .1X variable (Supplicant Access Control With Authenticator ) is set to 'inactive' which means that the controlled port is soley under the control of the authenticator role (the supplicant has no 'say' in the status of the controlled port). Then, both bridges immediately begin to attempt an authentication with each other. B1 = Bridge 1 that has immediate access to authentication server B2 = Bridge 2 that accesses the authentication server through B1 (has an intervening controlled port) --B2's authenticator will be (temporarily) be unable to communicate with its authentication server so the authentication from B1's supplicant to B2's authenticator will 'pause' waiting for a reply from the requests sent to the authentication server. --B1's authenticator will authenticate B2's supplicant and open the controlled port (due to the setting of the 1X variable) --B2's authenticator will now be able to communicate to the authentication server through B1 and authenticate B1's supplicant and open its controlled port. It is difficult to describe this succinctly, so I have dropped a great deal of detail in section 6.7 and just indicated that the bridge to bridge case requires the coupled one-way authentications. Still, the way it is now it is unclear why the bridge case is called out as a required case. I expect to produce a V4 of the document on Friday for continued review and will incorporate all comments. Thanks, Jim B. Bernard Aboba wrote: > Some refinements: > >> If a >> device implementing both roles encounters another >> device implementing both roles, then two separate (and >> simultaneous) 802.1X exchanges will take place in >> opposite directions. > > > Is this "will take place in opposite directions." or "may take place > in opposite directions, depending on the circumstances." Later on, > those circumstances are described. > >> 1) When the devices require the creation of >> separate keying material as in unicast keys for 802.11 >> adhoc networks. > > > Actually, it's the "group keys" not "unicast keys" that are > uni-directional in 802.11. > >> 3) When two bridge devices implementing both roles >> are connected together and they wish to authenticate each >> other. > > > Is this because there is no support for tie-breaking? If so, I'd > change this to: > > "3) When two bridge devices implementing both roles are > connected together and they wish to authenticate each other. > 802.1X does not support "tie breaking" wherein two > hosts initiating authentication with each other will only go > forward with a single authentication." > > _________________________________________________________________ > Check out the coupons and bargains on MSN Offers! > http://shopping.msn.com/softcontent/softcontent.aspx?scmId=1418 > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Jan 22 18:30:24 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19960 for ; Thu, 22 Jan 2004 18:30:24 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A0A2020201; Thu, 22 Jan 2004 18:18:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id C4C9E2014D for ; Thu, 22 Jan 2004 18:18:00 -0500 (EST) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 22 Jan 2004 15:32:41 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0MNSsNM012165; Thu, 22 Jan 2004 15:28:55 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.99.27]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 22 Jan 2004 15:34:42 -0800 From: "Joseph Salowey" To: "'John Vollbrecht'" , Subject: RE: [eap] [Issue ] Comments on section 3 of keying draft Message-ID: <01b001c3e13f$802985e0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <2954066.1074780768@dhcp60-09.merit.edu> X-OriginalArrivalTime: 22 Jan 2004 23:34:42.0454 (UTC) FILETIME=[4F815B60:01C3E140] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 22 Jan 2004 15:28:53 -0800 Content-Transfer-Encoding: 7bit eap-admin@frascone.com scribbled on : > --On Wednesday, January 21, 2004 2:11 PM -0800 Joseph Salowey > wrote: > >> Submitter name: Joe Salowey >> Submitter email address: jsalowey@cisco.com >> Date first submitted: 1/21/2004 >> Reference: >> Document: Keying Framework >> Comment type: 'E'ditorial >> Priority: '1' Should fix >> Section: Section 3 >> Rationale/Explanation of issue: >> >> 1. Use of term "security Association": >> >> In section 3 the use of term security association is somewhat >> non-standard. A security association is typically something that is >> generated dynamically and valid for a length of time. >> >> [1] The EAP-SA is more of a static relationship such as a trusted >> root key. [2] The EAP-Method SA is more along the lines of standard >> SA terminology. It is not visible outside the EAP-method. >> [3] The EAP-Key SA I do not think is really an SA. There are >> EAP-Key(s), but they must be managed outside the EAP protocol since >> EAP provides no key management functionality other than >> establishment. These EAP-Seeded SAs are managed by some other >> application separate from EAP. Examples of EAP Seeded SA are in >> section 3.5 [4] The AAA-SA is similar to [1] above in that there is >> a trusted root key. >> >> >> There are also "EAP-Seeded" SAs of which 3.5 is an example >> >> Recommended Changes: >> >> Use a different term than security association for other >> relationships or don't discuss them in this section. >> >> I'm not sure that so much detail is needed for the EAP-Method SA >> since it is not visible outside a method. >> >> Create section on EAP-Seeded SAs which describes Unicast SA and >> other possible SA based on the exchanged EAP keys. >> > > I like the approach described here. I do have a question > about whether the > SA, which is used by 802.11, should be described in an EAP > spec. Perhaps > it should because EAP is spelling out requirements for EAP methods. > Perhaps it should because there is no place else. My > question is though, > if no use of EMSK is included, why include use of MSK? Also, > is there a > reason, if multiple AMSKs can be derived from the EMSK that > the MSK could > not also be derived from it? [Joe] I'm agree that the SA used specifically by 802.11 is a bit too specific. I think we need to discuss that there are SAs outside the scope of EAP that are seeded by EAP. An example of this is a unicast security association seeded by the MSK. 802.11 is an example of this, but I don't think we need to get itno the details. Two keys the MSK and EMSK are defined for interoperability with existing solutions, so the MSK can't really be derived from the EMSK altough an EAP method could do this internally if it wanted. > > I am not an expert in this area, so this may well be fine. > >> DO not use the term EAP SA as it confusing as to what is being >> discussed. >> >> I'm not sure that multicast security association needs to be >> discussed as it is usually is derived from a unicast security >> association and not directly involved with EAP. >> >> >> 2. Key Naming (Section 3.7) >> >> I think the only thing that needs to be named within the scope of EAP >> is the MSK and the EMSK resulting from a particular EAP exchange. >> This needs to be defined by the method. Here is some suggested test >> > Perhaps some indication of which Server as well as which > method would be > appropriate? I am not sure exactly what the key name > supports, so this > may be inappropriate. > [Joe] SO I think the name just needs to identify keys created by EAP. If additional scoping of the name outside of EAP to a particular server or somethingelse then this should be handled outside EAP in the application that requires it. I think the same applies to a method, although I don't have a particular use case in mind. >> "EAP methods are responsible for defining and exporting a key name. >> The base EAP key name is an octet string between 15 and 31 octets. >> To name the MSK a M is prepended to the base name and for the EMSK a >> 'E' is prepended to the base name. The method for generating a >> base name is specific to the method, but it must be unique to each >> exchange and cryptographically bound to the exchange. An example >> for EAP-TLS is to take MD5 hash of the two finished messages in the >> TLS handshake in the order that they appear. It is NOT RECOMMENDED >> that a static function of the MSK or EMSK be used as publically >> known name. Other applications may use the EAP key name to derive >> names for their purposes that have additional meaning. " >> >> >> _______________________________________________ >> eap mailing list >> eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Jan 22 22:39:10 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27389 for ; Thu, 22 Jan 2004 22:39:09 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AD9D020201; Thu, 22 Jan 2004 22:28:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id BB6162015E for ; Thu, 22 Jan 2004 22:27:07 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i0N3qGR31552 for ; Thu, 22 Jan 2004 19:52:16 -0800 From: Bernard Aboba To: eap@frascone.com Subject: RE: [eap] Issue 213: Cleanup issues In-Reply-To: <00c601c3dfdb$ebed86b0$0300000a@amer.cisco.com> Message-ID: References: <00c601c3dfdb$ebed86b0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 22 Jan 2004 19:52:15 -0800 (PST) >Then, I am anxious that if attacker sends bogus Failure in case of >authentication Success in network, legitimate peer can never get access >of network. It is DoS attack by sending bogus authentication result. >As a result, any peer cannot get access of network in case of bogus >Failure sent by attacker. I think there may be multiple issues lurking here. These include: 1. DoS attacks due to forged Failure packets. 2. Man-in-the-middle attacks due to forged Success packets. 3. Timeouts caused by loss of Success and failure packets. Let me try to review what RFC 2284bis-08 says about these issues, so that we can understand if it makes sense. First, there is Section 4.2: " Success and Failure packets MUST NOT be sent by an EAP authenticator if the specification of the given method does not explicitly permit the method to finish at that point. A peer EAP implementation receiving a Success or Failure packet where sending one is not explicitly permitted MUST silently discard it. By default, an EAP peer MUST silently discard a "canned" Success packet (a Success packet sent immediately upon connection). This ensures that a rogue authenticator will not be able to bypass mutual authentication by sending a Success packet prior to conclusion of the EAP method conversation." To my mind this paragraph targets problems 2&3. For example, in a mutually authenticating method, a Success packet sent prior to completion of the mutual authentication (e.g. in EAP-TLS, before receipt of the FINISHED message from the server) would be silently discarded by the peer. Since a successful mutual authentication results in derivation of a key, protection against a forged Success can rely on mutual proof of possession of the derived key. This proof of possession can at the same time ensure synchronized peer and server state. The end result is that the peer authenticates the server, and also receives an indication that the server will grant access. The server authenticates the peer and receives an indication from the peer that it will accept the granted access. Note that this is really only the definition of a protected SUCCESS indication. The issue of forged Success packets was first raised by the University of Maryland, and much of the state machine, 802.1X-REV and RFC 2284bis effort has been oriented toward resolving this. To some extent this paragraph helps with problem 1, but only partially. A method-specific failure indication can only be protected if it is sent after key derivation. If the method gets as far as allowing both sides to mutually authenticate and derive a key, the failure message is almost by definition an "authorization failure" message. That is, if the key is derived and used to protect the error message, and the peer can successfully verify the MIC, then authentication has succeeded. This kind of protected error message is definitely useful because it prevents what otherwise might be a long timeout on the peer side. But it does not address the DoS vulnerability because forged messages can be sent at many points prior to key derivation that would successfully disrupt the method exchange. In reading the currently proposed definition of "Protected Result Indication" I don't think that it covers this case -- a protected FAILURE indication. Back to the text of Section 4.2: Implementation Note: Because the Success and Failure packets are not acknowledged, they are not retransmitted by the authenticator, and may be potentially lost. A peer MUST allow for this circumstance as described in this note. See also Section 3.4 for guidance on the processing of lower layer success and failure indications. Hmm. Clearly the text seems to imply that a peer MUST do something to handle the loss of Success and Failure packets, but I think the text could be more clear on what an implementation needs to do to be compliant. I think there is an implication that the peer needs to implement the recommendations in Section 3.4. Or perhaps the requirement has to do with the interface between the EAP layer and lower layer? Section 3.4 only has a single normative word (a "MAY") so one searches in vain for requirements there. As described in Section 2.1, only a single EAP authentication method is allowed within an EAP conversation. EAP methods MAY implement protected result indications. After the authenticator sends a method-specific failure indication to the peer, regardless of the response from the peer, it MUST subsequently send a Failure packet. After the authenticator sends a method-specific success indication to the peer, and receives a method-specific success indication from the peer, it MUST subsequently send a Success packet. This paragraph talks about something that an EAP method MAY do. However, the actions to be taken here don't depend on whether the method-specific indication is protected or not. So perhaps the word "protected" should be removed from the second sentence. On the peer, once the method completes unsuccessfully (that is, either the authenticator sends a method-specific failure indication, or the peer decides that it does want to continue the conversation, possibly after sending a method-specific failure indication), the peer MUST terminate the conversation and indicate failure to the lower layer. The peer MUST silently discard Success packets and MAY silently discard Failure packets. As a result, loss of a Failure packet need not result in a timeout. I think we have a typo here. Shouldn't "it does want" be "it does not want"? On the peer, after protected successful result indications have been exchanged by both sides, a Failure packet MUST be silently discarded. The peer MAY, in the event that an EAP Success is not received, conclude that the EAP Success packet was lost and that authentication concluded successfully. If the authenticator has not sent a method-specific result indication, and the peer is willing to continue the conversation, once the method completes the peer waits for a Success or Failure packet and MUST NOT silently discard either of them. In the event that neither a Success nor Failure packet is received, the peer SHOULD terminate the conversation to avoid lengthy timeouts in case the lost packet was an EAP Failure. If the peer attempts to authenticate to the authenticator and fails to do so, the authenticator MUST send a Failure packet and MUST NOT grant access by sending a Success packet. However, an authenticator MAY omit having the peer authenticate to it in situations where limited access is offered (e.g., guest access). In this case the authenticator MUST send a Success packet. Where the peer authenticates successfully to the authenticator, but the authenticator does not send a method-specific result indication the authenticator MAY deny access by sending a Failure packet where the peer is not currently authorized for network access. These paragraphs seem OK to me. Next we have the infamous "protected result indications" definition in Section 7.2.1: Protected result indications A method provides result indications if after the method has finished (1) if the peer is willing to use the access provided by the authenticator, it knows whether the authenticator will grant access (that is, only either an EAP-Success or EAP-Failure will be accepted, no more method specific messages are expected), and (2) if the authenticator decides to grant access, it knows whether the peer will accept it. Result indications improve resilience to packet loss; see Section 4.2 for discussion. Depending on the method and circumstances, result indications can be spoofable by an attacker. A method is said to provide protected result indications if it supports result indications as well as the "integrity protection" and "replay protection" claims. A method claiming to support protected result indications MUST indicate which result indications are protected, and which are not. See Section 7.16 for details. It occurs to me reading this again that the definition of result indications really only applies to a method-specific SUCCESS indication, not to a FAILURE indication. A method provides a method-specific failure indication if it supports error messages of any kind. So perhaps the the first sentence should start "A method provides failure result indications if it supports error messages sent by both the peer and server. A method provides a success result indications if..." Last but not least we have Section 7.16: 7.16 Protected Result Indications EAP Success and Failure packets are neither acknowledged nor integrity protected. This creates a potential vulnerability to spoofing, as well as lengthy timeouts. To address this vulnerability, EAP methods may implement protected result indications. Since protected result indications require use of a key for per-packet authentication and integrity protection, methods supporting protected result indications MUST also support the "key derivation", "mutual authentication" "integrity protection" and "replay protection" claims. This paragraph seems ok, other than perhaps the "may implement" could be changed to a "MAY implement". Result indications may be implicit or explicit. For example, a method may use error messages in order to explicitly indicate a failure, while the completion of mutual authentication and key derivation without an error message implicitly indicates a successful result. On rereading this, it occurs to me that it is only SUCCESS result indications that can be implicit; FAILURE indications need to be explicit. So this is not so clear. For example, within EAP-TLS [RFC2716], the peer always authenticates the server, and sends a TLS alert message in the event of an authentication or authorization failure. If the server does not receive a TLS alert message from the peer and the peer continues the conversation to completion (e.g. sends a FINISHED message), then the server can assume that the peer will accept access if granted it by the server. Similarly, the peer can assume that the server will grant access if it does not receive a TLS alert message from the server, and the server carries the conversation to completion (e.g. sends a FINISHED message). A server may use the "access denied" TLS alert after successfully authenticating the peer to indicate that a valid certificate was received from the peer, but when access control was applied, the server decided not to proceed. As a result of the discussion we had on the operation of TLS session resume, I went back and looked at RFC 2246 as well as E. Rescorla's SSL and TLS book. I think these paragraphs are correct as written and apply to session resume. Or am I missing something? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 23 08:30:36 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29736 for ; Fri, 23 Jan 2004 08:30:26 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 516B520165; Fri, 23 Jan 2004 08:18:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 493CB20165 for ; Fri, 23 Jan 2004 08:17:36 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 0259D6A903; Fri, 23 Jan 2004 15:28:35 +0200 (EET) Message-ID: <4011212E.3050705@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Burns Cc: Bernard Aboba , eap@frascone.com, stds-802-1@ieee.org References: <400FE287.3080709@mtghouse.com> In-Reply-To: <400FE287.3080709@mtghouse.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [eap] Re: Strawman for a modified section 6.7 (V3) for IEEE 802.1XRev Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 23 Jan 2004 15:27:10 +0200 Content-Transfer-Encoding: 7bit Jim Burns wrote: > Below is a 3rd revision that began with the 2nd and modified the last > two paragraphs: Looks good to me, thanks! --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 23 15:22:08 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19688 for ; Fri, 23 Jan 2004 15:22:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4942420216; Fri, 23 Jan 2004 15:11:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from reformers.mr.itd.umich.edu (reformers.mr.itd.umich.edu [141.211.93.147]) by mail.frascone.com (Postfix) with ESMTP id 0A34B2020F for ; Fri, 23 Jan 2004 15:10:31 -0500 (EST) Received: from dhcp60-09.merit.edu (dhcp60-09.merit.edu [198.108.60.209]) by reformers.mr.itd.umich.edu (smtp) with ESMTP id i0NKLRFj022817; Fri, 23 Jan 2004 15:21:28 -0500 From: John Vollbrecht To: Bernard Aboba , jeb@mtghouse.com Cc: eap@frascone.com, stds-802-1@ieee.org, rgm@truesecure.com, paul.congdon@hp.com, jari.arkko@piuha.net Message-ID: <5336025.1074871283@dhcp60-09.merit.edu> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [eap] RE: [802.1] Re: Strawman for a modified section 6.7 (V3) for IEEE 802.1XRev Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 23 Jan 2004 15:21:23 -0500 Content-Transfer-Encoding: 7bit --On Thursday, January 22, 2004 12:30 PM -0800 Bernard Aboba wrote: > Some refinements: > > > If a > > device implementing both roles encounters another > > device implementing both roles, then two separate (and > > simultaneous) 802.1X exchanges will take place in > > opposite directions. > > Is this "will take place in opposite directions." or "may take place in > opposite directions, depending on the circumstances." Later on, those > circumstances are described. > > > 1) When the devices require the creation of > > separate keying material as in unicast keys for 802.11 > > adhoc networks. > > Actually, it's the "group keys" not "unicast keys" that are > uni-directional in 802.11. > > > 3) When two bridge devices implementing both roles > > are connected together and they wish to authenticate each > > other. > > Is this because there is no support for tie-breaking? If so, I'd change > this to: > > "3) When two bridge devices implementing both roles are > connected together and they wish to authenticate each other. > 802.1X does not support "tie breaking" wherein two > hosts initiating authentication with each other will only go > forward with a single authentication." > I think this is not *just* for tie breaking. In some cases it may be for tie breaking, but it is possible that each bridge may have its own requirement for authentication/authorization that is only implemented in one direction (probably the authenticator), but be willing to respond as supplicant to the other. > _________________________________________________________________ > Check out the coupons and bargains on MSN Offers! > http://shopping.msn.com/softcontent/softcontent.aspx?scmId=1418 > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 23 15:35:10 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20721 for ; Fri, 23 Jan 2004 15:35:10 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7BE532025B; Fri, 23 Jan 2004 15:24:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from deneb.mtghouse.com (unknown [206.152.191.132]) by mail.frascone.com (Postfix) with SMTP id F0E832020F for ; Fri, 23 Jan 2004 15:23:04 -0500 (EST) Received: (qmail 10679 invoked from network); 23 Jan 2004 20:33:58 -0000 Received: from unknown (HELO mtghouse.com) (192.168.10.122) by deneb.mtghouse.com with SMTP; 23 Jan 2004 20:33:58 -0000 Message-ID: <4011853D.200@mtghouse.com> From: Jim Burns User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Vollbrecht Cc: Bernard Aboba , eap@frascone.com, stds-802-1@ieee.org, rgm@truesecure.com, paul.congdon@hp.com, jari.arkko@piuha.net Subject: Re: [eap] RE: [802.1] Re: Strawman for a modified section 6.7 (V3) for IEEE References: <5336025.1074871283@dhcp60-09.merit.edu> In-Reply-To: <5336025.1074871283@dhcp60-09.merit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 23 Jan 2004 15:34:05 -0500 Content-Transfer-Encoding: 7bit Hi John, Correct. The bridge-to-bridge case is more than tie-breaking and I believe that your description of the reason that bridge-to-bridge may use the two one-way authentication transports is succinct. I will borrow it to add to the 6.7 text. Thanks, Jim B. John Vollbrecht wrote: > > > --On Thursday, January 22, 2004 12:30 PM -0800 Bernard Aboba > wrote: > >> Some refinements: >> >> > If a >> > device implementing both roles encounters another >> > device implementing both roles, then two separate (and >> > simultaneous) 802.1X exchanges will take place in >> > opposite directions. >> >> Is this "will take place in opposite directions." or "may take place in >> opposite directions, depending on the circumstances." Later on, those >> circumstances are described. >> >> > 1) When the devices require the creation of >> > separate keying material as in unicast keys for 802.11 >> > adhoc networks. >> >> Actually, it's the "group keys" not "unicast keys" that are >> uni-directional in 802.11. >> >> > 3) When two bridge devices implementing both roles >> > are connected together and they wish to authenticate each >> > other. >> >> Is this because there is no support for tie-breaking? If so, I'd change >> this to: >> >> "3) When two bridge devices implementing both roles are >> connected together and they wish to authenticate each other. >> 802.1X does not support "tie breaking" wherein two >> hosts initiating authentication with each other will only go >> forward with a single authentication." >> > I think this is not *just* for tie breaking. In some cases it may be > for tie breaking, but it is possible that each bridge may have its own > requirement for authentication/authorization that is only implemented > in one direction (probably the authenticator), but be willing to > respond as supplicant to the other. > >> _________________________________________________________________ >> Check out the coupons and bargains on MSN Offers! >> http://shopping.msn.com/softcontent/softcontent.aspx?scmId=1418 >> > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 23 19:28:16 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04756 for ; Fri, 23 Jan 2004 19:28:16 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F412A20160; Fri, 23 Jan 2004 19:17:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from deneb.mtghouse.com (unknown [206.152.191.132]) by mail.frascone.com (Postfix) with SMTP id 3C5162015F for ; Fri, 23 Jan 2004 19:16:39 -0500 (EST) Received: (qmail 28728 invoked from network); 24 Jan 2004 00:27:39 -0000 Received: from unknown (HELO mtghouse.com) (192.168.10.122) by deneb.mtghouse.com with SMTP; 24 Jan 2004 00:27:39 -0000 Message-ID: <4011BC00.8090603@mtghouse.com> From: Jim Burns User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Vollbrecht Cc: Bernard Aboba , eap@frascone.com, stds-802-1@ieee.org, rgm@truesecure.com, paul.congdon@hp.com, jari.arkko@piuha.net, 802.1XRev@www.frascone.com References: <5336025.1074871283@dhcp60-09.merit.edu> In-Reply-To: <5336025.1074871283@dhcp60-09.merit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [eap] Rev 4 of section 6.7 for 802.1XRev will be late Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 23 Jan 2004 19:27:44 -0500 Content-Transfer-Encoding: 7bit Hi Folks, Rev 4 of section 6.7 is not going to make it out today. It will be out on Monday. Sorry for the delay, Jim B. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Jan 24 03:36:09 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00334 for ; Sat, 24 Jan 2004 03:36:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5BC0B201F7; Sat, 24 Jan 2004 03:25:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 0F0DA201F3 for ; Sat, 24 Jan 2004 03:24:31 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i0O8nYp08384 for ; Sat, 24 Jan 2004 00:49:34 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Proposed Resolution to Issue 213: Cleanup issues Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 24 Jan 2004 00:49:34 -0800 (PST) The text of Issue 213: Cleanup issues is enclosed below. The proposed fix is as follows: In Section 2.4 change: "The authenticator SHOULD interpret the receipt of a key attribute within an Accept packet as an indication that the peer has successfully authenticated and authorized the server." To: "The authenticator SHOULD interpret the receipt of a key attribute within an Accept packet as an indication that the peer has successfully authenticated the server." In Section 4.2, change: " On the peer, once the method completes unsuccessfully (that is, either the authenticator sends a method-specific failure indication, or the peer decides that it does want to continue the conversation, possibly after sending a method-specific failure indication), the peer MUST terminate the conversation and indicate failure to the lower layer." To: " On the peer, once the method completes unsuccessfully (that is, either the authenticator sends a method-specific failure indication, or the peer decides that it does not want to continue the conversation, possibly after sending a method-specific failure indication), the peer MUST terminate the conversation and indicate failure to the lower layer." In Section 4.2, change: " As described in Section 2.1, only a single EAP authentication method is allowed within an EAP conversation. EAP methods MAY implement protected result indications. " To: " As described in Section 2.1, only a single EAP authentication method is allowed within an EAP conversation. EAP methods may implement method-specific result indications." ----------------------------------------------------------------------------- Issue 213: Cleanup issues Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 1/20/2004 Reference: Document: RFC 2284bis-08.l Comment type: T Priority: S Section: 3.1, 4.2, 7.2.1 Rationale/Explanation of issue: This is a generic issue to cleanup some of the text as reflected in WG discussions. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Jan 25 18:54:23 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23656 for ; Sun, 25 Jan 2004 18:54:23 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1A7F0201FE; Sun, 25 Jan 2004 18:43:06 -0500 (EST) Delivered-To: eap@frascone.com Received: from deneb.mtghouse.com (unknown [206.152.191.132]) by mail.frascone.com (Postfix) with SMTP id E25FB201FC for ; Sun, 25 Jan 2004 18:42:51 -0500 (EST) Received: (qmail 19305 invoked from network); 25 Jan 2004 23:53:54 -0000 Received: from unknown (HELO mtghouse.com) (192.168.5.204) by deneb.mtghouse.com with SMTP; 25 Jan 2004 23:53:54 -0000 Message-ID: <40142EB3.6070102@mtghouse.com> From: Jim Burns User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com, stds-802-1@ieee.org, rgm@truesecure.com, paul.congdon@hp.com, jrv@umich.edu, jari.arkko@piuha.net References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [eap] Re: Strawman for a modified section 6.7 (V4) for IEEE 802.1XRev Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 25 Jan 2004 16:01:39 -0500 Content-Transfer-Encoding: 8bit Hello, I have taken the input from last week and modified the proposal for section 6.7 of IEEE 802.1XRev. This is version 4 of the proposal. Jim B. ---------------------------------------- Version 1: -original release Version 2: -rewrite of text for readability by B. Aboba -remove discussion of specific applications -remove suggestions that specific applications define .1X roles and EAP methods. Version 3: -asymmetric connections are created when a device change 2nd to last paragraph to indicate that with both roles encounters a device with just an authenticator. -add a short paragraph suggesting that specific applications define .1X roles. Version 4: -Ensure the text indicates that two controlled ports enables enforcement of mutual authorization. (paragraph 3 & 5) -Indicate that it is creation of group keys not unicast keys in 802.11 adhoc that requires bi-directional transport. (#2 in list of reasons to utilize bi-directional transport) -Better specify why two bridges utilize bi-directional transport. (#3 in list of reasons to utilize bi-directional transport) -Make clear that the addition of the controlled port for the supplicant is for clarity on what to do with the authorization variable on the supplicant. (paragraph 5) -Mention that 802.1X does not support tie-breaking. (paragraph 6) -In general ensure careful use of terms and language. ------------------------------------------------------------- 6.7 Coupling two 802.1X authentications This section discusses the ability of 802.1X to run two simultaneous transports in opposite directions, how implementation asymmetries affect authentication results and how simultaneous bi-directional transport may be utilized. In 802.1X there is a requestor role (authenticator) and a responder role (supplicant). The authenticator transmits frames to the supplicant and the supplicant responds to those frames with frames of its own. 802.1X, like the authentication protocol carried within it (EAP), is a request/response protocol, and the state machines reflect this. Such a transport is sometimes called 'one-way' meaning the protocol exchanges always originate from one side (the requestor). However, it is not the 802.1X transport that controls whether the authentication is mutual or one-way. Rather, it is the chosen EAP method and controlled ports able to mutually enforce the authorization of the authentication. Despite the asymmetry of 802.1X and EAP transports, if a mutually authenticating EAP method (such as EAP-TLS) is carried within 802.1X frames, then the supplicant and authenticator can mutually authenticate. However, if an EAP method is chosen which only authenticates the supplicant to the authenticator (e.g. EAP MD5-CHALLENGE), then the authentication will be one-way. In an earlier version of 802.1X (802.1X-2001), only the authenticator was specified to affect the controlled port. This one-sided specification prevented mutual authentications from being mutually enforced, essentially preventing mutual authentication. However, this was due to the lack of a specification of the controlled port on the supplicant, not due to the one-way nature of the 802.1X transport protocol. The current version of 802.1X remedies this by specifying how both authenticator and supplicant roles affect the controlled port. In 802.1X, each role has its own state machine and it is possible that a single device can implement both the supplicant and authenticator roles (state machines). If a device implementing both roles encounters another device implementing both roles, then two separate (and simultaneous) 802.1X transports will take place in opposite directions. This is sometimes referred to as a bi- directional authentication transport or two coupled one-way authentication exchanges. 802.1X does not support "tie breaking" wherein two hosts initiating authentication with each other will only go forward with a single authentication. Two coupled one-way authentication exchanges are not equivalent in security to a single exchange of a mutually authenticating EAP method (such as EAP-TLS). Since the two coupled one-way authentication exchanges are not cryptographically bound together, there is no way to ascertain that the party involved in the first one-way exchange is the same party that is involved in the alternate one-way exchange. Even though a single 802.1X exchange may provide mutual authentication, there may be other reasons to run two 802.1X exchanges in opposite directions. RFC 2284bis, Section 2.4 discusses some of these cases, which include: 1) When the devices require the creation of separate keying material as in group keys for 802.11 adhoc networks. 2) When different credentials are used for different roles (one credential for the supplicant role and one for the authenticator). 3) When two bridge devices are connected each bridge may have its own requirement for authentication/authorization that is only enforced by the authenticator ("Supplicant Access Control With Authenticator" variable set to inactive), but will implement the supplicant role to respond to the other bridge. This configuration allows both bridges to utilize the same authentication server even though one bridge is separated from the authentication server by the other bridge's controlled port. The first bridge with access to the authentication server will complete authentication and authorize its controlled port, this will allow the second bridge to access the authentication server so that it may authenticate and authorize the first bridge. When a device that implements both 802.1X roles encounters a device which implements only a single authenticator role, this can result in asymmetric data flow (data traffic can only flow in one direction). This occurs because one device opens its controlled port while the other device does not. A complete table of encounters and results (assuming authentication successes) appears in Table xxxx. It is suggested that applications utilizing 802.1X should specify which .1X roles must be implemented to avoid encounters that will result in failed network connections. Table xxxx: Result of encounters between .1X transport roles assuming key-generating EAP methods are run and result in success. Remote\Local--> | Supplicant | Authenticator | Both | | | | V | | | ---------------------------------------------------------------------- Supplicant |Fails gracefully | Works | Works |No link will be | Authenticated | Authenticated |formed if media | link | link |is considered | Authentication | Authentication |unsafe without | policy is set by | policy set by |encryption | choice of EAP | choice of EAP |(802.11). | method. | method | | | Remote |Unauthenticated | | supplicant and |link will be | | local |formed if media | | authenticator |is considered | | are satisfied. |safe by default | | Local |(802.3) | | supplicant will | | | receive no | | | response and | | | assume no | | | authenticator. | | | Successful | | | authentication | | | to the local | | | authenticator | | | will have made | | | the port | | | secure. ----------------------------------------------------------------------- Authenticator |Works - |Fails gracefully |Fails – |Authenticated |No link will be |Asymmetric link |link – |formed. Each |Remote |Authentication |authenticator |controlled port |policy set by |will send initial |is operational, |choice of EAP |EAP requests but |but local |method. |no response will |controlled port | |arrive. |remains non- | | |operational. | | |Remote | | |authenticator | | |and local | | |supplicant are | | |satisfied, | | |local | | |authenticator | | |remains | | |unsatisfied. ----------------------------------------------------------------------- Both |Works |Fails |Works |Authenticated |Asymmetric link | Authenticated |link |Local controlled | link |Authentication |port is | Authentication |policy set by |operational, but | policy set by |choice of EAP |remote controlled | choice of two |method. |port remains non- | uncoupled EAP |Local supplicant |operational. | methods. Two |and remote |Local | keys will be |authenticator |authenticator and | formed and some |are satisfied. |remote supplicant | mechanism must |Remote |are satisfied, | exist so that |supplicant will |remote | local and |receive no |authenticator | remote choose |response and |remains | the same key. |assume no |unsatisfied. | |authenticator. | | |Successful | | |authentication | | |to the remote | | |authenticator | | |will have made | | |the port secure. | | ----------------------------------------------------------------------- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From XCNFH@hotmail.com Sun Jan 25 23:27:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03976 for ; Sun, 25 Jan 2004 23:27:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkyLZ-000227-00 for eap-archive@ietf.org; Sun, 25 Jan 2004 23:27:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkyKe-0001zo-00 for eap-archive@ietf.org; Sun, 25 Jan 2004 23:26:41 -0500 Received: from c-67-171-134-147.client.comcast.net ([67.171.134.147]) by ietf-mx with smtp (Exim 4.12) id 1AkyJr-0001y2-00; Sun, 25 Jan 2004 23:25:51 -0500 Received: from 190.156.206.50 by web342.mail.yahoo.com; Mon, 26 Jan 2004 01:24:50 -0300 Message-ID: From: "Leta Carpenter" To: eap-archive@ietf.org Subject: lamp goldman Date: Mon, 26 Jan 2004 00:21:50 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--09800556412414704" X-CS-IP: 76.215.240.160 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.3 required=5.0 tests=HTML_70_80,HTML_IMAGE_ONLY_02, HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, USERPASS autolearn=no version=2.60 X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_70_80 BODY: Message is 70% to 80% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 2.2 HTML_IMAGE_ONLY_02 BODY: HTML: images with 0-200 bytes of words * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 3.1 USERPASS URI: URL contains username and (optional) password * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts ----09800556412414704 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable








await xerxes cove counterargument dingy daffod= il

----09800556412414704-- From eap-admin@frascone.com Mon Jan 26 01:21:19 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08089 for ; Mon, 26 Jan 2004 01:21:18 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AFE0E20208; Mon, 26 Jan 2004 01:10:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 5D52F20205 for ; Mon, 26 Jan 2004 01:09:19 -0500 (EST) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 25 Jan 2004 22:25:24 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0Q6KKNM004346; Sun, 25 Jan 2004 22:20:21 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.221.126]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 25 Jan 2004 22:26:09 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" , Subject: RE: [eap] Issue 213: Cleanup issues Message-ID: <001601c3e3d4$789ea2a0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: X-OriginalArrivalTime: 26 Jan 2004 06:26:09.0796 (UTC) FILETIME=[498C0C40:01C3E3D5] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 25 Jan 2004 22:20:17 -0800 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Bernard Aboba > Sent: Thursday, January 22, 2004 7:52 PM > To: eap@frascone.com > Subject: RE: [eap] Issue 213: Cleanup issues > > > >Then, I am anxious that if attacker sends bogus Failure in case of > >authentication Success in network, legitimate peer can never > get access > >of network. It is DoS attack by sending bogus authentication > result. As > >a result, any peer cannot get access of network in case of bogus > >Failure sent by attacker. > > I think there may be multiple issues lurking here. These include: > > 1. DoS attacks due to forged Failure packets. > 2. Man-in-the-middle attacks due to forged Success packets. > 3. Timeouts caused by loss of Success and failure packets. > > Let me try to review what RFC 2284bis-08 says about these > issues, so that we can understand if it makes sense. > > First, there is Section 4.2: > > " Success and Failure packets MUST NOT be sent by an EAP > authenticator > if the specification of the given method does not explicitly permit > the method to finish at that point. A peer EAP implementation > receiving a Success or Failure packet where sending one is not > explicitly permitted MUST silently discard it. By default, an EAP > peer MUST silently discard a "canned" Success packet (a Success > packet sent immediately upon connection). This ensures > that a rogue > authenticator will not be able to bypass mutual authentication by > sending a Success packet prior to conclusion of the EAP method > conversation." > > To my mind this paragraph targets problems 2&3. For example, > in a mutually authenticating method, a Success packet sent > prior to completion of the mutual authentication (e.g. in > EAP-TLS, before receipt of the FINISHED message from the > server) would be silently discarded by the peer. Since a > successful mutual authentication results in derivation of a > key, protection against a forged Success can rely on mutual > proof of possession of the derived key. This proof of > possession can at the same time ensure synchronized peer and > server state. The end result is that the peer authenticates > the server, and also receives an indication that the server > will grant access. The server authenticates the peer and > receives an indication from the peer that it will accept the > granted access. Note that this is really only the definition > of a protected SUCCESS indication. > > The issue of forged Success packets was first raised by the > University of Maryland, and much of the state machine, > 802.1X-REV and RFC 2284bis effort has been oriented toward > resolving this. > > To some extent this paragraph helps with problem 1, but only > partially. A method-specific failure indication can only be > protected if it is sent after key derivation. If the method > gets as far as allowing both sides to mutually authenticate > and derive a key, the failure message is almost by definition > an "authorization failure" message. That is, if the key is > derived and used to protect the error message, and the peer > can successfully verify the MIC, then authentication has > succeeded. This kind of protected error message is definitely > useful because it prevents what otherwise might be a long > timeout on the peer side. But it does not address the DoS > vulnerability because forged messages can be sent at many > points prior to key derivation that would successfully > disrupt the method exchange. > > In reading the currently proposed definition of "Protected > Result Indication" I don't think that it covers this case -- > a protected FAILURE indication. > > Back to the text of Section 4.2: > > Implementation Note: Because the Success and Failure packets are > not acknowledged, they are not retransmitted by the > authenticator, > and may be potentially lost. A peer MUST allow for this > circumstance as described in this note. See also > Section 3.4 for > guidance on the processing of lower layer success and failure > indications. > > Hmm. Clearly the text seems to imply that a peer MUST do > something to handle the loss of Success and Failure packets, > but I think the text could be more clear on what an > implementation needs to do to be compliant. I think there is > an implication that the peer needs to implement the > recommendations in Section 3.4. Or perhaps the requirement > has to do with the interface between the EAP layer and lower > layer? Section 3.4 only has a single normative word (a "MAY") > so one searches in vain for requirements there. > > As described in Section 2.1, only a single EAP authentication > method is allowed within an EAP conversation. EAP methods MAY > implement protected result indications. After the authenticator > sends a method-specific failure indication to the peer, > regardless > of the response from the peer, it MUST subsequently > send a Failure > packet. After the authenticator sends a method-specific success > indication to the peer, and receives a method-specific success > indication from the peer, it MUST subsequently send a Success > packet. > > This paragraph talks about something that an EAP method MAY > do. However, the actions to be taken here don't depend on > whether the method-specific indication is protected or not. > So perhaps the word "protected" should be removed from the > second sentence. > > On the peer, once the method completes unsuccessfully (that is, > either the authenticator sends a method-specific failure > indication, or the peer decides that it does want to > continue the > conversation, possibly after sending a method-specific failure > indication), the peer MUST terminate the conversation > and indicate > failure to the lower layer. The peer MUST silently discard > Success packets and MAY silently discard Failure packets. As a > result, loss of a Failure packet need not result in a timeout. > > I think we have a typo here. Shouldn't "it does want" be "it > does not want"? > > On the peer, after protected successful result indications have > been exchanged by both sides, a Failure packet MUST be silently > discarded. The peer MAY, in the event that an EAP > Success is not > received, conclude that the EAP Success packet was lost and that > authentication concluded successfully. > > If the authenticator has not sent a method-specific result > indication, and the peer is willing to continue the > conversation, > once the method completes the peer waits for a Success > or Failure > packet and MUST NOT silently discard either of them. > In the event > that neither a Success nor Failure packet is received, the peer > SHOULD terminate the conversation to avoid lengthy timeouts in > case the lost packet was an EAP Failure. > > If the peer attempts to authenticate to the authenticator and > fails to do so, the authenticator MUST send a Failure packet and > MUST NOT grant access by sending a Success packet. However, an > authenticator MAY omit having the peer authenticate to it in > situations where limited access is offered (e.g., guest access). > In this case the authenticator MUST send a Success packet. > > Where the peer authenticates successfully to the authenticator, > but the authenticator does not send a method-specific result > indication the authenticator MAY deny access by sending > a Failure > packet where the peer is not currently authorized for network > access. > > These paragraphs seem OK to me. > > Next we have the infamous "protected result indications" > definition in Section 7.2.1: > > Protected result indications > A method provides result indications if after the method > has finished (1) if the peer is willing to use the access > provided by the authenticator, it knows whether the > authenticator will grant access (that is, only either an > EAP-Success or EAP-Failure will be accepted, no > more method > specific messages are expected), and (2) if the > authenticator decides to grant access, it knows > whether the > peer will accept it. Result indications improve > resilience > to packet loss; see Section 4.2 for discussion. Depending > on the method and circumstances, result > indications can be > spoofable by an attacker. A method is said to provide > protected result indications if it supports result > indications as well as the "integrity protection" and > "replay protection" claims. A method claiming to support > protected result indications MUST indicate which result > indications are protected, and which are not. > See Section > 7.16 for details. > > It occurs to me reading this again that the definition of > result indications really only applies to a method-specific > SUCCESS indication, not to a FAILURE indication. A method > provides a method-specific failure indication if it supports > error messages of any kind. So perhaps the the first > sentence should start "A method provides failure result > indications if it supports error messages sent by both the > peer and server. A method provides a success result > indications if..." > > Last but not least we have Section 7.16: > > 7.16 Protected Result Indications > > EAP Success and Failure packets are neither acknowledged nor > integrity protected. This creates a potential vulnerability to > spoofing, as well as lengthy timeouts. > > To address this vulnerability, EAP methods may implement protected > result indications. Since protected result indications require use > of a key for per-packet authentication and integrity protection, > methods supporting protected result indications MUST also > support the > "key derivation", "mutual authentication" "integrity > protection" and > "replay protection" claims. > > This paragraph seems ok, other than perhaps the "may > implement" could be changed to a "MAY implement". > > Result indications may be implicit or explicit. For example, a > method may use error messages in order to explicitly indicate a > failure, while the completion of mutual authentication and key > derivation without an error message implicitly indicates a > successful > result. > > On rereading this, it occurs to me that it is only SUCCESS > result indications that can be implicit; FAILURE indications > need to be explicit. So this is not so clear. > > For example, within EAP-TLS [RFC2716], the peer always > authenticates > the server, and sends a TLS alert message in the event of an > authentication or authorization failure. If the server does not > receive a TLS alert message from the peer and the peer > continues the > conversation to completion (e.g. sends a FINISHED > message), then the > server can assume that the peer will accept access if granted it by > the server. > > Similarly, the peer can assume that the server will grant access if > it does not receive a TLS alert message from the server, and the > server carries the conversation to completion (e.g. sends > a FINISHED > message). > > A server may use the "access denied" TLS alert after successfully > authenticating the peer to indicate that a valid certificate was > received from the peer, but when access control was applied, the > server decided not to proceed. > > As a result of the discussion we had on the operation of TLS > session resume, I went back and looked at RFC 2246 as well as > E. Rescorla's SSL and TLS book. I think these paragraphs are > correct as written and apply to session resume. Or am I > missing something? [Joe] I haven't quite parsed your entire message yet, but here is the issue I was looking at: From 2246 the abbreviated handshake looks like this: Client Server ClientHello --------> ServerHello [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data In this case the client does not receive an indication that the server accepted the authentication. Since the server finished message comes first it is possible that the Client's finished message is rejected by the server. At this point a failure or success is possible. Although the protocol authentication is not considered complete until all the finished messages have been correclty verified, I suppose that it is very unlikely that the client would successfully verify the server's finished message and respond with a bad finished message if it were a valid client. I don't think there is a very big problem here. However I do think we should change "server can assume that the peer will accept access if granted it by the server." to " server can assume that the peer has authenticated the server." And _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Jan 26 01:25:15 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08336 for ; Mon, 26 Jan 2004 01:25:14 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 950ED20206; Mon, 26 Jan 2004 01:14:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id A9D9B20205 for ; Mon, 26 Jan 2004 01:13:28 -0500 (EST) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 25 Jan 2004 22:26:33 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i0Q6OT5k001538; Sun, 25 Jan 2004 22:24:30 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.221.126]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 25 Jan 2004 22:30:19 -0800 From: "Joseph Salowey" To: "'Joseph Salowey'" , "'Bernard Aboba'" , Subject: RE: [eap] Issue 213: Cleanup issues Message-ID: <001701c3e3d5$0d8783f0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 26 Jan 2004 06:30:19.0624 (UTC) FILETIME=[DE74C680:01C3E3D5] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 25 Jan 2004 22:24:27 -0800 Content-Transfer-Encoding: 7bit Sorry I hit send too soon: > > > > On rereading this, it occurs to me that it is only SUCCESS > > result indications that can be implicit; FAILURE indications > > need to be explicit. So this is not so clear. > > > > For example, within EAP-TLS [RFC2716], the peer always > > authenticates > > the server, and sends a TLS alert message in the event of an > > authentication or authorization failure. If the server does not > > receive a TLS alert message from the peer and the peer > > continues the > > conversation to completion (e.g. sends a FINISHED > > message), then the > > server can assume that the peer will accept access if > granted it by > > the server. > > > > and the > > server carries the conversation to completion (e.g. sends > > a FINISHED Similarly, the peer can assume that the server will > grant access if > > it does not receive a TLS alert message from the server, > > message). > > > > A server may use the "access denied" TLS alert after successfully > > authenticating the peer to indicate that a valid certificate was > > received from the peer, but when access control was applied, the > > server decided not to proceed. > > > > As a result of the discussion we had on the operation of TLS > > session resume, I went back and looked at RFC 2246 as well as > > E. Rescorla's SSL and TLS book. I think these paragraphs are > > correct as written and apply to session resume. Or am I > > missing something? > > [Joe] I haven't quite parsed your entire message yet, but > here is the issue I was looking at: > > From 2246 the abbreviated handshake looks like this: > > > Client Server > > ClientHello --------> > ServerHello > [ChangeCipherSpec] > <-------- Finished > [ChangeCipherSpec] > Finished --------> > Application Data <-------> Application Data > > > > In this case the client does not receive an indication that > the server accepted the authentication. Since the server > finished message comes first it is possible that the Client's > finished message is rejected by the server. At this point a > failure or success is possible. Although the protocol > authentication is not considered complete until all the > finished messages have been correctly verified, I suppose > that it is very unlikely that the client would successfully > verify the server's finished message and respond with a bad > finished message if it were a valid client. I don't think > there is a very big problem here. However I do think we > should change > > "...server can assume that the peer will accept access if > granted it by the server." > to > "...server can assume that the peer has authenticated the server." > > And > " Similarly, the peer can assume that the server will grant access if it does not receive a TLS alert message from the server,..." To " Similarly, the peer can assume that the server has successfully authenticated the peer if it does not receive a TLS alert message from the server,..." > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Jan 26 10:54:16 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10344 for ; Mon, 26 Jan 2004 10:54:15 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 653CD20208; Mon, 26 Jan 2004 10:43:06 -0500 (EST) Delivered-To: eap@frascone.com Received: from struggle.mr.itd.umich.edu (struggle.mr.itd.umich.edu [141.211.14.79]) by mail.frascone.com (Postfix) with ESMTP id 8ADD020200 for ; Mon, 26 Jan 2004 10:42:23 -0500 (EST) Received: from [10.0.1.2] (pm474-17.dialip.mich.net [207.75.179.27]) by struggle.mr.itd.umich.edu (smtp) with ESMTP id i0QFrICX008250; Mon, 26 Jan 2004 10:53:20 -0500 From: John Vollbrecht To: Jim Burns , Bernard Aboba Cc: eap@frascone.com, stds-802-1@ieee.org, rgm@truesecure.com, paul.congdon@hp.com, jari.arkko@piuha.net Message-ID: <8342274.1075114400@[10.0.1.2]> In-Reply-To: <40142EB3.6070102@mtghouse.com> References: <40142EB3.6070102@mtghouse.com> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [eap] Re: Strawman for a modified section 6.7 (V4) for IEEE 802.1XRev Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 26 Jan 2004 10:53:20 -0500 Content-Transfer-Encoding: 7bit This is good. I do have a question about the dual bridge case, below. -- John --On Sunday, January 25, 2004 4:01 PM -0500 Jim Burns wrote: > Hello, > I have taken the input from last week and modified the proposal for > section 6.7 of IEEE 802.1XRev. This is version 4 of the proposal. > Jim B. > ---------------------------------------- > Version 1: > -original release > > Version 2: > -rewrite of text for readability by B. Aboba > -remove discussion of specific applications > -remove suggestions that specific applications define .1X > roles and EAP methods. > > Version 3: > -asymmetric connections are created when a device change 2nd > to last paragraph to indicate that with both roles > encounters a device with just an authenticator. > -add a short paragraph suggesting that specific applications > define .1X roles. > > Version 4: > -Ensure the text indicates that two controlled ports > enables enforcement of mutual authorization. (paragraph 3 & > 5) > -Indicate that it is creation of group keys not unicast > keys in 802.11 adhoc that requires bi-directional > transport. (#2 in list of reasons to utilize bi-directional > transport) > -Better specify why two bridges utilize bi-directional > transport. (#3 in list of reasons to utilize bi-directional > transport) > -Make clear that the addition of the controlled port for > the supplicant is for clarity on what to do with the > authorization variable on the supplicant. (paragraph 5) > -Mention that 802.1X does not support tie-breaking. > (paragraph 6) > -In general ensure careful use of terms and language. > > > ------------------------------------------------------------- > 6.7 Coupling two 802.1X authentications > > This section discusses the ability of 802.1X to run two > simultaneous transports in opposite directions, how > implementation asymmetries affect authentication results > and how simultaneous bi-directional transport may be > utilized. > > In 802.1X there is a requestor role (authenticator) and a > responder role (supplicant). The authenticator transmits > frames to the supplicant and the supplicant responds to > those frames with frames of its own. 802.1X, like the > authentication protocol carried within it (EAP), is a > request/response protocol, and the state machines reflect > this. Such a transport is sometimes called 'one-way' > meaning the protocol exchanges always originate from one > side (the requestor). > > However, it is not the 802.1X transport that controls > whether the authentication is mutual or one-way. Rather, > it is the chosen EAP method and controlled ports able to > mutually enforce the authorization of the authentication. > > Despite the asymmetry of 802.1X and EAP transports, if a > mutually authenticating EAP method (such as EAP-TLS) is > carried within 802.1X frames, then the supplicant and > authenticator can mutually authenticate. However, if an > EAP method is chosen which only authenticates the > supplicant to the authenticator (e.g. EAP MD5-CHALLENGE), > then the authentication will be one-way. > > In an earlier version of 802.1X (802.1X-2001), only the > authenticator was specified to affect the controlled port. > This one-sided specification prevented mutual > authentications from being mutually enforced, essentially > preventing mutual authentication. However, this was due to > the lack of a specification of the controlled port on the > supplicant, not due to the one-way nature of the 802.1X > transport protocol. The current version of 802.1X remedies > this by specifying how both authenticator and supplicant > roles affect the controlled port. > > In 802.1X, each role has its own state machine and it is > possible that a single device can implement both the > supplicant and authenticator roles (state machines). If a > device implementing both roles encounters another device > implementing both roles, then two separate (and > simultaneous) 802.1X transports will take place in opposite > directions. This is sometimes referred to as a bi- > directional authentication transport or two coupled one-way > authentication exchanges. 802.1X does not support "tie > breaking" wherein two hosts initiating authentication with > each other will only go forward with a single > authentication. > > Two coupled one-way authentication exchanges are not > equivalent in security to a single exchange of a mutually > authenticating EAP method (such as EAP-TLS). Since the two > coupled one-way authentication exchanges are not > cryptographically bound together, there is no way to > ascertain that the party involved in the first one-way > exchange is the same party that is involved in the > alternate one-way exchange. > > Even though a single 802.1X exchange may provide mutual > authentication, there may be other reasons to run two > 802.1X exchanges in opposite directions. RFC 2284bis, > Section 2.4 discusses some of these cases, which include: > > 1) When the devices require the creation of separate > keying material as in group keys for 802.11 adhoc networks. > > 2) When different credentials are used for different roles > (one credential for the supplicant role and one for the > authenticator). > > 3) When two bridge devices are connected each bridge may > have its own requirement for authentication/authorization > that is only enforced by the authenticator ("Supplicant Access > Control With Authenticator" variable set to inactive), but will > implement the supplicant role to respond to the other > bridge. This configuration allows both bridges to utilize > the same authentication server even though one bridge is > separated from the authentication server by the other > bridge's controlled port. The first bridge with access to > the authentication server will complete authentication and > authorize its controlled port, this will allow the second > bridge to access the authentication server so that it may > authenticate and authorize the first bridge. I don't understand how completing one authentication allows the other authentication to complete. My question - If each authentication enables a variable and both must be on for traffic, then both must complete for traffic to flow. Or is your thought that the supplicant side of each is not required (configured on) so only the authenticator *needs* to authenticate? If so the control port can be on, but I still don't see how the other side's authenticator can do RADIUS (or other) to the authentication server since it does not have a port enabled on its side. I was thinking that that in a two bridge situation both bridges would be set with variables for both authenticator and supplicant open. The autenticator would start on its side. The supplicant would time out if the other side did not start. If both sides did start, both authentications would be required. I don't see how this can allow a bridge coming up to get to a Authentication Server via RADIUS before the connection is made. In my opinion it will require some sort of pass thru capability in EAPOL (or equivalent) that allows passing of RADIUS accross the link, and then to the AS. Somehow there would need to be a shared secret for message integrity between them. Probably this is doable, but not easily, and not for this document. So my thought is that the ability of a bridge to connect to another bridge, and go to an AS behind the bridge to which it is connecting is something that will happen in 802.1af, not here. [Note however that some protection could be built in by using a special EAP method that passed policy info to the connecting bridge after doing authentication. This would require enhancing existing methods to include sending of the info from the authenticator and requiring it (failing if not present) on the supplicant (the attaching bridge).] > > When a device that implements both 802.1X roles encounters > a device which implements only a single authenticator role, > this can result in asymmetric data flow (data traffic can I think no data flows into the unauthenticated port- a I right? If so then I think this misleading. Perhaps better to say one side can turn the port on but the other will not send or receive. This does point out the timeout problem. > only flow in one direction). This occurs because one > device opens its controlled port while the other device > does not. A complete table of encounters and results > (assuming authentication successes) appears in Table xxxx. > > It is suggested that applications utilizing 802.1X should > specify which .1X roles must be implemented to avoid > encounters that will result in failed network connections. > > Table xxxx: Result of encounters between .1X transport > roles assuming key-generating EAP methods are run and > result in success. > > Remote\Local--> | Supplicant | Authenticator | Both > | | | | > V | | | > ---------------------------------------------------------------------- > Supplicant |Fails gracefully | Works | Works > | No link will be | Authenticated | Authenticated > | formed if media | link | link > | is considered | Authentication | Authentication > | unsafe without | policy is set by | policy set by > | encryption | choice of EAP | choice of EAP > | (802.11). | method. | method > | | | Remote > | Unauthenticated | | supplicant and > | link will be | | local > | formed if media | | authenticator > | is considered | | are satisfied. > | safe by default | | Local > | (802.3) | | supplicant will > | | | receive no > | | | response and > | | | assume no > | | | authenticator. > | | | Successful > | | | authentication > | | | to the local > | | | authenticator > | | | will have made > | | | the port > | | | secure. > ----------------------------------------------------------------------- > Authenticator |Works - |Fails gracefully |Fails ? > | Authenticated |No link will be |Asymmetric link > | link ? |formed. Each |Remote > | Authentication |authenticator |controlled port > | policy set by |will send initial |is operational, > | choice of EAP |EAP requests but |but local > | method. |no response will |controlled port > | | arrive. |remains non- > | | | operational. > | | | Remote > | | | authenticator > | | | and local > | | | supplicant are > | | | satisfied, > | | | local > | | | authenticator > | | | remains > | | | unsatisfied. > ----------------------------------------------------------------------- > Both |Works |Fails |Works > | Authenticated |Asymmetric link | Authenticated > | link |Local controlled | link > | Authentication |port is | Authentication > | policy set by |operational, but | policy set by > | choice of EAP |remote controlled | choice of two > | method. |port remains non- | uncoupled EAP > | Local supplicant |operational. | methods. Two > | and remote |Local | keys will be > | authenticator |authenticator and | formed and some > | are satisfied. |remote supplicant | mechanism must > | Remote |are satisfied, | exist so that > | supplicant will |remote | local and > | receive no |authenticator | remote choose > | response and |remains | the same key. > | assume no |unsatisfied. | > | authenticator. | | > | Successful | | > | authentication | | > | to the remote | | > | authenticator | | > | will have made | | > | the port secure. | | > ----------------------------------------------------------------------- > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Jan 26 12:16:32 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13440 for ; Mon, 26 Jan 2004 12:16:31 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3E8572020D; Mon, 26 Jan 2004 12:04:06 -0500 (EST) Delivered-To: eap@frascone.com Received: from deneb.mtghouse.com (unknown [206.152.191.132]) by mail.frascone.com (Postfix) with SMTP id 8256B20205 for ; Mon, 26 Jan 2004 12:03:42 -0500 (EST) Received: (qmail 24871 invoked from network); 26 Jan 2004 17:14:47 -0000 Received: from unknown (HELO mtghouse.com) (192.168.10.122) by deneb.mtghouse.com with SMTP; 26 Jan 2004 17:14:47 -0000 Message-ID: <40154B0F.7040906@mtghouse.com> From: Jim Burns User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Vollbrecht Cc: Bernard Aboba , eap@frascone.com, stds-802-1@ieee.org, rgm@truesecure.com, paul.congdon@hp.com, jari.arkko@piuha.net References: <40142EB3.6070102@mtghouse.com> <8342274.1075114400@[10.0.1.2]> In-Reply-To: <8342274.1075114400@[10.0.1.2]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [eap] Re: Strawman for a modified section 6.7 (V4) for IEEE 802.1XRev Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 26 Jan 2004 12:14:55 -0500 Content-Transfer-Encoding: 7bit John, The key to answering your question is understanding the 802.1X management variable "Supplicant Access Control With Authenticator" that is described in section 6.4 of 802.1XRev draft 8 (around p17 or so). In short, when this management variable is set to the inactive state then the controlled port will only be authorized by the authenticator, the supplicant plays no role in authorizing the controlled port. Setting this variable to inactive causes the controlled port to work the way it did in 802.1X-2001. This is required for backwards compatibility of 802.1XRev draft 8 with 802.1X-2001 on bridges. So, imagin you have two bridges: A and B (both with the "Supplicant Access Control With Authenticator" set to inactive) and addition you have a single authentication server (let us call it S) that A has access to (no intervening controlled port), but which B must go through A to reach. Graphically: ------------- B<====>A<---->S Authentication/authorization would proceed as follows: --------------------------------------------------------- A's authenticator will begin an authentication with B's supplicant B's authenticator will begin an authentication with A's supplicant B's authenticator will send access-requests to S, but they will not reach S because the controlled port on A has not been authorized. So these access-requests will timeout and B will do resends. A's authenticator will send access-requests to S and receive responses and eventually authenticate B's supplicant. A will authorize its controlled port. B's authenticator's access-requests will now reach S (through the authorized controlled port on A) and recieve responses and eventually authenticate A's supplicant. B will authorize its controlled port. The key to understanding the bridge to bridge case is understanding the "Supplicant Access Control With Authenticator" variable that is described in section 6.4. I can add a reference to 6.4 in my description of the bridge to bridge case in 6.7. Hope this helps, Jim B. John Vollbrecht wrote: > This is good. I do have a question about the dual bridge case, below. > > -- John > > --On Sunday, January 25, 2004 4:01 PM -0500 Jim Burns > wrote: > >> Hello, >> I have taken the input from last week and modified the proposal for >> section 6.7 of IEEE 802.1XRev. This is version 4 of the proposal. >> Jim B. >> ---------------------------------------- >> Version 1: >> -original release >> >> Version 2: >> -rewrite of text for readability by B. Aboba >> -remove discussion of specific applications >> -remove suggestions that specific applications define .1X >> roles and EAP methods. >> >> Version 3: >> -asymmetric connections are created when a device change 2nd >> to last paragraph to indicate that with both roles >> encounters a device with just an authenticator. >> -add a short paragraph suggesting that specific applications >> define .1X roles. >> >> Version 4: >> -Ensure the text indicates that two controlled ports >> enables enforcement of mutual authorization. (paragraph 3 & >> 5) >> -Indicate that it is creation of group keys not unicast >> keys in 802.11 adhoc that requires bi-directional >> transport. (#2 in list of reasons to utilize bi-directional >> transport) >> -Better specify why two bridges utilize bi-directional >> transport. (#3 in list of reasons to utilize bi-directional >> transport) >> -Make clear that the addition of the controlled port for >> the supplicant is for clarity on what to do with the >> authorization variable on the supplicant. (paragraph 5) >> -Mention that 802.1X does not support tie-breaking. >> (paragraph 6) >> -In general ensure careful use of terms and language. >> >> >> ------------------------------------------------------------- >> 6.7 Coupling two 802.1X authentications >> >> This section discusses the ability of 802.1X to run two >> simultaneous transports in opposite directions, how >> implementation asymmetries affect authentication results >> and how simultaneous bi-directional transport may be >> utilized. >> >> In 802.1X there is a requestor role (authenticator) and a >> responder role (supplicant). The authenticator transmits >> frames to the supplicant and the supplicant responds to >> those frames with frames of its own. 802.1X, like the >> authentication protocol carried within it (EAP), is a >> request/response protocol, and the state machines reflect >> this. Such a transport is sometimes called 'one-way' >> meaning the protocol exchanges always originate from one >> side (the requestor). >> >> However, it is not the 802.1X transport that controls >> whether the authentication is mutual or one-way. Rather, >> it is the chosen EAP method and controlled ports able to >> mutually enforce the authorization of the authentication. >> >> Despite the asymmetry of 802.1X and EAP transports, if a >> mutually authenticating EAP method (such as EAP-TLS) is >> carried within 802.1X frames, then the supplicant and >> authenticator can mutually authenticate. However, if an >> EAP method is chosen which only authenticates the >> supplicant to the authenticator (e.g. EAP MD5-CHALLENGE), >> then the authentication will be one-way. >> >> In an earlier version of 802.1X (802.1X-2001), only the >> authenticator was specified to affect the controlled port. >> This one-sided specification prevented mutual >> authentications from being mutually enforced, essentially >> preventing mutual authentication. However, this was due to >> the lack of a specification of the controlled port on the >> supplicant, not due to the one-way nature of the 802.1X >> transport protocol. The current version of 802.1X remedies >> this by specifying how both authenticator and supplicant >> roles affect the controlled port. >> >> In 802.1X, each role has its own state machine and it is >> possible that a single device can implement both the >> supplicant and authenticator roles (state machines). If a >> device implementing both roles encounters another device >> implementing both roles, then two separate (and >> simultaneous) 802.1X transports will take place in opposite >> directions. This is sometimes referred to as a bi- >> directional authentication transport or two coupled one-way >> authentication exchanges. 802.1X does not support "tie >> breaking" wherein two hosts initiating authentication with >> each other will only go forward with a single >> authentication. >> >> Two coupled one-way authentication exchanges are not >> equivalent in security to a single exchange of a mutually >> authenticating EAP method (such as EAP-TLS). Since the two >> coupled one-way authentication exchanges are not >> cryptographically bound together, there is no way to >> ascertain that the party involved in the first one-way >> exchange is the same party that is involved in the >> alternate one-way exchange. >> >> Even though a single 802.1X exchange may provide mutual >> authentication, there may be other reasons to run two >> 802.1X exchanges in opposite directions. RFC 2284bis, >> Section 2.4 discusses some of these cases, which include: >> >> 1) When the devices require the creation of separate >> keying material as in group keys for 802.11 adhoc networks. >> >> 2) When different credentials are used for different roles >> (one credential for the supplicant role and one for the >> authenticator). >> >> 3) When two bridge devices are connected each bridge may >> have its own requirement for authentication/authorization >> that is only enforced by the authenticator ("Supplicant Access >> Control With Authenticator" variable set to inactive), but will >> implement the supplicant role to respond to the other >> bridge. This configuration allows both bridges to utilize >> the same authentication server even though one bridge is >> separated from the authentication server by the other >> bridge's controlled port. The first bridge with access to >> the authentication server will complete authentication and >> authorize its controlled port, this will allow the second >> bridge to access the authentication server so that it may >> authenticate and authorize the first bridge. > > > I don't understand how completing one authentication allows the other > authentication to complete. My question - If each authentication > enables a variable and both must be on for traffic, then both must > complete for traffic to flow. Or is your thought that the supplicant > side of each is not required (configured on) so only the authenticator > *needs* to authenticate? If so the control port can be on, but I > still don't see how the other side's authenticator can do RADIUS (or > other) to the authentication server since it does not have a port > enabled on its side. > > I was thinking that that in a two bridge situation both bridges would > be set with variables for both authenticator and supplicant open. The > autenticator would start on its side. The supplicant would time out > if the other side did not start. If both sides did start, both > authentications would be required. > > I don't see how this can allow a bridge coming up to get to a > Authentication Server via RADIUS before the connection is made. In my > opinion it will require some sort of pass thru capability in EAPOL > (or equivalent) that allows passing of RADIUS accross the link, and > then to the AS. Somehow there would need to be a shared secret for > message integrity between them. Probably this is doable, but not > easily, and not for this document. > > So my thought is that the ability of a bridge to connect to another > bridge, and go to an AS behind the bridge to which it is connecting is > something that will happen in 802.1af, not here. [Note however that > some protection could be built in by using a special EAP method that > passed policy info to the connecting bridge after doing > authentication. This would require enhancing existing methods to > include sending of the info from the authenticator and requiring it > (failing if not present) on the supplicant (the attaching bridge).] > >> >> When a device that implements both 802.1X roles encounters >> a device which implements only a single authenticator role, >> this can result in asymmetric data flow (data traffic can > > I think no data flows into the unauthenticated port- a I right? If so > then I think this misleading. Perhaps better to say one side can turn > the port on but the other will not send or receive. This does point > out the timeout problem. > >> only flow in one direction). This occurs because one >> device opens its controlled port while the other device >> does not. A complete table of encounters and results >> (assuming authentication successes) appears in Table xxxx. >> >> It is suggested that applications utilizing 802.1X should >> specify which .1X roles must be implemented to avoid >> encounters that will result in failed network connections. >> >> Table xxxx: Result of encounters between .1X transport >> roles assuming key-generating EAP methods are run and >> result in success. >> >> Remote\Local--> | Supplicant | Authenticator | Both >> | | | | >> V | | | >> ---------------------------------------------------------------------- >> Supplicant |Fails gracefully | Works | Works >> | No link will be | Authenticated | Authenticated >> | formed if media | link | link >> | is considered | Authentication | Authentication >> | unsafe without | policy is set by | policy set by >> | encryption | choice of EAP | choice of EAP >> | (802.11). | method. | method >> | | | Remote >> | Unauthenticated | | supplicant and >> | link will be | | local >> | formed if media | | authenticator >> | is considered | | are satisfied. >> | safe by default | | Local >> | (802.3) | | supplicant will >> | | | receive no >> | | | response and >> | | | assume no >> | | | authenticator. >> | | | Successful >> | | | authentication >> | | | to the local >> | | | authenticator >> | | | will have made >> | | | the port >> | | | secure. >> ----------------------------------------------------------------------- >> Authenticator |Works - |Fails gracefully |Fails ? >> | Authenticated |No link will be |Asymmetric link >> | link ? |formed. Each |Remote >> | Authentication |authenticator |controlled port >> | policy set by |will send initial |is operational, >> | choice of EAP |EAP requests but |but local >> | method. |no response will |controlled port >> | | arrive. |remains non- >> | | | operational. >> | | | Remote >> | | | authenticator >> | | | and local >> | | | supplicant are >> | | | satisfied, >> | | | local >> | | | authenticator >> | | | remains >> | | | unsatisfied. >> ----------------------------------------------------------------------- >> Both |Works |Fails |Works >> | Authenticated |Asymmetric link | Authenticated >> | link |Local controlled | link >> | Authentication |port is | Authentication >> | policy set by |operational, but | policy set by >> | choice of EAP |remote controlled | choice of two >> | method. |port remains non- | uncoupled EAP >> | Local supplicant |operational. | methods. Two >> | and remote |Local | keys will be >> | authenticator |authenticator and | formed and some >> | are satisfied. |remote supplicant | mechanism must >> | Remote |are satisfied, | exist so that >> | supplicant will |remote | local and >> | receive no |authenticator | remote choose >> | response and |remains | the same key. >> | assume no |unsatisfied. | >> | authenticator. | | >> | Successful | | >> | authentication | | >> | to the remote | | >> | authenticator | | >> | will have made | | >> | the port secure. | | >> ----------------------------------------------------------------------- >> >> > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Jan 26 12:22:32 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13520 for ; Mon, 26 Jan 2004 12:22:32 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4FBDB20217; Mon, 26 Jan 2004 12:10:06 -0500 (EST) Delivered-To: eap@frascone.com Received: from deneb.mtghouse.com (unknown [206.152.191.132]) by mail.frascone.com (Postfix) with SMTP id 104FE20205 for ; Mon, 26 Jan 2004 12:09:57 -0500 (EST) Received: (qmail 25331 invoked from network); 26 Jan 2004 17:21:02 -0000 Received: from unknown (HELO mtghouse.com) (192.168.10.122) by deneb.mtghouse.com with SMTP; 26 Jan 2004 17:21:02 -0000 Message-ID: <40154C86.7000607@mtghouse.com> From: Jim Burns User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Vollbrecht Cc: Bernard Aboba , eap@frascone.com, stds-802-1@ieee.org, rgm@truesecure.com, paul.congdon@hp.com, jari.arkko@piuha.net References: <40142EB3.6070102@mtghouse.com> <8342274.1075114400@[10.0.1.2]> In-Reply-To: <8342274.1075114400@[10.0.1.2]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [eap] Re: Strawman for a modified section 6.7 (V4) for IEEE 802.1XRev Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 26 Jan 2004 12:21:10 -0500 Content-Transfer-Encoding: 7bit Hi John, Just noticed your comment on asymmetric data flow definition below. I agree and will clarify this for V5 of this draft. Jim B. John Vollbrecht wrote: > This is good. I do have a question about the dual bridge case, below. > > -- John > > --On Sunday, January 25, 2004 4:01 PM -0500 Jim Burns > wrote: > >> Hello, >> I have taken the input from last week and modified the proposal for >> section 6.7 of IEEE 802.1XRev. This is version 4 of the proposal. >> Jim B. >> ---------------------------------------- >> Version 1: >> -original release >> >> Version 2: >> -rewrite of text for readability by B. Aboba >> -remove discussion of specific applications >> -remove suggestions that specific applications define .1X >> roles and EAP methods. >> >> Version 3: >> -asymmetric connections are created when a device change 2nd >> to last paragraph to indicate that with both roles >> encounters a device with just an authenticator. >> -add a short paragraph suggesting that specific applications >> define .1X roles. >> >> Version 4: >> -Ensure the text indicates that two controlled ports >> enables enforcement of mutual authorization. (paragraph 3 & >> 5) >> -Indicate that it is creation of group keys not unicast >> keys in 802.11 adhoc that requires bi-directional >> transport. (#2 in list of reasons to utilize bi-directional >> transport) >> -Better specify why two bridges utilize bi-directional >> transport. (#3 in list of reasons to utilize bi-directional >> transport) >> -Make clear that the addition of the controlled port for >> the supplicant is for clarity on what to do with the >> authorization variable on the supplicant. (paragraph 5) >> -Mention that 802.1X does not support tie-breaking. >> (paragraph 6) >> -In general ensure careful use of terms and language. >> >> >> ------------------------------------------------------------- >> 6.7 Coupling two 802.1X authentications >> >> This section discusses the ability of 802.1X to run two >> simultaneous transports in opposite directions, how >> implementation asymmetries affect authentication results >> and how simultaneous bi-directional transport may be >> utilized. >> >> In 802.1X there is a requestor role (authenticator) and a >> responder role (supplicant). The authenticator transmits >> frames to the supplicant and the supplicant responds to >> those frames with frames of its own. 802.1X, like the >> authentication protocol carried within it (EAP), is a >> request/response protocol, and the state machines reflect >> this. Such a transport is sometimes called 'one-way' >> meaning the protocol exchanges always originate from one >> side (the requestor). >> >> However, it is not the 802.1X transport that controls >> whether the authentication is mutual or one-way. Rather, >> it is the chosen EAP method and controlled ports able to >> mutually enforce the authorization of the authentication. >> >> Despite the asymmetry of 802.1X and EAP transports, if a >> mutually authenticating EAP method (such as EAP-TLS) is >> carried within 802.1X frames, then the supplicant and >> authenticator can mutually authenticate. However, if an >> EAP method is chosen which only authenticates the >> supplicant to the authenticator (e.g. EAP MD5-CHALLENGE), >> then the authentication will be one-way. >> >> In an earlier version of 802.1X (802.1X-2001), only the >> authenticator was specified to affect the controlled port. >> This one-sided specification prevented mutual >> authentications from being mutually enforced, essentially >> preventing mutual authentication. However, this was due to >> the lack of a specification of the controlled port on the >> supplicant, not due to the one-way nature of the 802.1X >> transport protocol. The current version of 802.1X remedies >> this by specifying how both authenticator and supplicant >> roles affect the controlled port. >> >> In 802.1X, each role has its own state machine and it is >> possible that a single device can implement both the >> supplicant and authenticator roles (state machines). If a >> device implementing both roles encounters another device >> implementing both roles, then two separate (and >> simultaneous) 802.1X transports will take place in opposite >> directions. This is sometimes referred to as a bi- >> directional authentication transport or two coupled one-way >> authentication exchanges. 802.1X does not support "tie >> breaking" wherein two hosts initiating authentication with >> each other will only go forward with a single >> authentication. >> >> Two coupled one-way authentication exchanges are not >> equivalent in security to a single exchange of a mutually >> authenticating EAP method (such as EAP-TLS). Since the two >> coupled one-way authentication exchanges are not >> cryptographically bound together, there is no way to >> ascertain that the party involved in the first one-way >> exchange is the same party that is involved in the >> alternate one-way exchange. >> >> Even though a single 802.1X exchange may provide mutual >> authentication, there may be other reasons to run two >> 802.1X exchanges in opposite directions. RFC 2284bis, >> Section 2.4 discusses some of these cases, which include: >> >> 1) When the devices require the creation of separate >> keying material as in group keys for 802.11 adhoc networks. >> >> 2) When different credentials are used for different roles >> (one credential for the supplicant role and one for the >> authenticator). >> >> 3) When two bridge devices are connected each bridge may >> have its own requirement for authentication/authorization >> that is only enforced by the authenticator ("Supplicant Access >> Control With Authenticator" variable set to inactive), but will >> implement the supplicant role to respond to the other >> bridge. This configuration allows both bridges to utilize >> the same authentication server even though one bridge is >> separated from the authentication server by the other >> bridge's controlled port. The first bridge with access to >> the authentication server will complete authentication and >> authorize its controlled port, this will allow the second >> bridge to access the authentication server so that it may >> authenticate and authorize the first bridge. > > > I don't understand how completing one authentication allows the other > authentication to complete. My question - If each authentication > enables a variable and both must be on for traffic, then both must > complete for traffic to flow. Or is your thought that the supplicant > side of each is not required (configured on) so only the authenticator > *needs* to authenticate? If so the control port can be on, but I > still don't see how the other side's authenticator can do RADIUS (or > other) to the authentication server since it does not have a port > enabled on its side. > > I was thinking that that in a two bridge situation both bridges would > be set with variables for both authenticator and supplicant open. The > autenticator would start on its side. The supplicant would time out > if the other side did not start. If both sides did start, both > authentications would be required. > > I don't see how this can allow a bridge coming up to get to a > Authentication Server via RADIUS before the connection is made. In my > opinion it will require some sort of pass thru capability in EAPOL > (or equivalent) that allows passing of RADIUS accross the link, and > then to the AS. Somehow there would need to be a shared secret for > message integrity between them. Probably this is doable, but not > easily, and not for this document. > > So my thought is that the ability of a bridge to connect to another > bridge, and go to an AS behind the bridge to which it is connecting is > something that will happen in 802.1af, not here. [Note however that > some protection could be built in by using a special EAP method that > passed policy info to the connecting bridge after doing > authentication. This would require enhancing existing methods to > include sending of the info from the authenticator and requiring it > (failing if not present) on the supplicant (the attaching bridge).] > >> >> When a device that implements both 802.1X roles encounters >> a device which implements only a single authenticator role, >> this can result in asymmetric data flow (data traffic can > > I think no data flows into the unauthenticated port- a I right? If so > then I think this misleading. Perhaps better to say one side can turn > the port on but the other will not send or receive. This does point > out the timeout problem. > >> only flow in one direction). This occurs because one >> device opens its controlled port while the other device >> does not. A complete table of encounters and results >> (assuming authentication successes) appears in Table xxxx. >> >> It is suggested that applications utilizing 802.1X should >> specify which .1X roles must be implemented to avoid >> encounters that will result in failed network connections. >> >> Table xxxx: Result of encounters between .1X transport >> roles assuming key-generating EAP methods are run and >> result in success. >> >> Remote\Local--> | Supplicant | Authenticator | Both >> | | | | >> V | | | >> ---------------------------------------------------------------------- >> Supplicant |Fails gracefully | Works | Works >> | No link will be | Authenticated | Authenticated >> | formed if media | link | link >> | is considered | Authentication | Authentication >> | unsafe without | policy is set by | policy set by >> | encryption | choice of EAP | choice of EAP >> | (802.11). | method. | method >> | | | Remote >> | Unauthenticated | | supplicant and >> | link will be | | local >> | formed if media | | authenticator >> | is considered | | are satisfied. >> | safe by default | | Local >> | (802.3) | | supplicant will >> | | | receive no >> | | | response and >> | | | assume no >> | | | authenticator. >> | | | Successful >> | | | authentication >> | | | to the local >> | | | authenticator >> | | | will have made >> | | | the port >> | | | secure. >> ----------------------------------------------------------------------- >> Authenticator |Works - |Fails gracefully |Fails ? >> | Authenticated |No link will be |Asymmetric link >> | link ? |formed. Each |Remote >> | Authentication |authenticator |controlled port >> | policy set by |will send initial |is operational, >> | choice of EAP |EAP requests but |but local >> | method. |no response will |controlled port >> | | arrive. |remains non- >> | | | operational. >> | | | Remote >> | | | authenticator >> | | | and local >> | | | supplicant are >> | | | satisfied, >> | | | local >> | | | authenticator >> | | | remains >> | | | unsatisfied. >> ----------------------------------------------------------------------- >> Both |Works |Fails |Works >> | Authenticated |Asymmetric link | Authenticated >> | link |Local controlled | link >> | Authentication |port is | Authentication >> | policy set by |operational, but | policy set by >> | choice of EAP |remote controlled | choice of two >> | method. |port remains non- | uncoupled EAP >> | Local supplicant |operational. | methods. Two >> | and remote |Local | keys will be >> | authenticator |authenticator and | formed and some >> | are satisfied. |remote supplicant | mechanism must >> | Remote |are satisfied, | exist so that >> | supplicant will |remote | local and >> | receive no |authenticator | remote choose >> | response and |remains | the same key. >> | assume no |unsatisfied. | >> | authenticator. | | >> | Successful | | >> | authentication | | >> | to the remote | | >> | authenticator | | >> | will have made | | >> | the port secure. | | >> ----------------------------------------------------------------------- >> >> > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Jan 26 21:19:25 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02534 for ; Mon, 26 Jan 2004 21:19:24 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9B36820226; Mon, 26 Jan 2004 21:08:06 -0500 (EST) Delivered-To: eap@frascone.com Received: from wanderer.mr.itd.umich.edu (wanderer.mr.itd.umich.edu [141.211.93.146]) by mail.frascone.com (Postfix) with ESMTP id 0A94F20216 for ; Mon, 26 Jan 2004 21:07:14 -0500 (EST) Received: from [10.0.1.2] (pm479-45.dialip.mich.net [207.75.180.55]) by wanderer.mr.itd.umich.edu (smtp) with ESMTP id i0R2I4Mx003387; Mon, 26 Jan 2004 21:18:08 -0500 From: John Vollbrecht To: Jim Burns Cc: Bernard Aboba , eap@frascone.com, stds-802-1@ieee.org, rgm@truesecure.com, paul.congdon@hp.com, jari.arkko@piuha.net Message-ID: <9969903.1075151887@[10.0.1.2]> In-Reply-To: <40154B0F.7040906@mtghouse.com> References: <40142EB3.6070102@mtghouse.com> <8342274.1075114400@[10.0.1.2]> <40154B0F.7040906@mtghouse.com> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [eap] Re: Strawman for a modified section 6.7 (V4) for IEEE 802.1XRev Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 26 Jan 2004 21:18:07 -0500 Content-Transfer-Encoding: 7bit --On Monday, January 26, 2004 12:14 PM -0500 Jim Burns wrote: > John, > The key to answering your question is understanding the 802.1X > management variable "Supplicant Access Control With Authenticator" that > is described in section 6.4 of 802.1XRev draft 8 (around p17 or so). > In short, when this management variable is set to the inactive state then > the controlled port will only be authorized by the authenticator, the > supplicant plays no role in authorizing the controlled port. Setting > this variable to inactive causes the controlled port to work the way it > did in 802.1X-2001. This is required for backwards compatibility of > 802.1XRev draft 8 with 802.1X-2001 on bridges. So, imagin you have > two bridges: A and B (both with the "Supplicant Access Control With > Authenticator" set to inactive) and addition you have a single > authentication server (let us call it S) that A has access to (no > intervening controlled port), but which B must go through A to reach. > Graphically: > ------------- > B<====>A<---->S > Authentication/authorization would proceed as follows: > --------------------------------------------------------- > A's authenticator will begin an authentication with B's supplicant > B's authenticator will begin an authentication with A's supplicant > B's authenticator will send access-requests to S, but they will not > reach S because the controlled port on A has not been authorized. So > these access-requests will timeout and B will do resends. A's > authenticator will send access-requests to S and receive responses and [A talks RADIUS to S right?] > eventually authenticate B's supplicant. A will authorize its > controlled port. > B's authenticator's access-requests will now reach S (through the > authorized controlled port on A) and recieve responses and eventually > authenticate A's supplicant. B will authorize its controlled port. > I don't have my copy of 6.4 here - it is at my desk at Merit. But I don't understand how messages get from B's authenticator to S. My understanding is that these are sent via RADIUS over IP. Without B's port being turned on, I assume no IP traffic can be sent. So perhaps I am wrong, but how does B send traffic to S in this scenario? > The key to understanding the bridge to bridge case is understanding the > "Supplicant Access Control With Authenticator" variable that is described > in section 6.4. I can add a reference to 6.4 in my description of the > bridge to bridge case in 6.7. Hope this helps, > Jim B. > > John Vollbrecht wrote: > > > This is good. I do have a question about the dual bridge case, below. > > > > -- John > > > > --On Sunday, January 25, 2004 4:01 PM -0500 Jim Burns > > wrote: > > > >> Hello, > >> I have taken the input from last week and modified the proposal for > >> section 6.7 of IEEE 802.1XRev. This is version 4 of the proposal. > >> Jim B. > >> ---------------------------------------- > >> Version 1: > >> -original release > >> > >> Version 2: > >> -rewrite of text for readability by B. Aboba > >> -remove discussion of specific applications > >> -remove suggestions that specific applications define .1X > >> roles and EAP methods. > >> > >> Version 3: > >> -asymmetric connections are created when a device change 2nd > >> to last paragraph to indicate that with both roles > >> encounters a device with just an authenticator. > >> -add a short paragraph suggesting that specific applications > >> define .1X roles. > >> > >> Version 4: > >> -Ensure the text indicates that two controlled ports > >> enables enforcement of mutual authorization. (paragraph 3 & > >> 5) > >> -Indicate that it is creation of group keys not unicast > >> keys in 802.11 adhoc that requires bi-directional > >> transport. (#2 in list of reasons to utilize bi-directional > >> transport) > >> -Better specify why two bridges utilize bi-directional > >> transport. (#3 in list of reasons to utilize bi-directional > >> transport) > >> -Make clear that the addition of the controlled port for > >> the supplicant is for clarity on what to do with the > >> authorization variable on the supplicant. (paragraph 5) > >> -Mention that 802.1X does not support tie-breaking. > >> (paragraph 6) > >> -In general ensure careful use of terms and language. > >> > >> > >> ------------------------------------------------------------- > >> 6.7 Coupling two 802.1X authentications > >> > >> This section discusses the ability of 802.1X to run two > >> simultaneous transports in opposite directions, how > >> implementation asymmetries affect authentication results > >> and how simultaneous bi-directional transport may be > >> utilized. > >> > >> In 802.1X there is a requestor role (authenticator) and a > >> responder role (supplicant). The authenticator transmits > >> frames to the supplicant and the supplicant responds to > >> those frames with frames of its own. 802.1X, like the > >> authentication protocol carried within it (EAP), is a > >> request/response protocol, and the state machines reflect > >> this. Such a transport is sometimes called 'one-way' > >> meaning the protocol exchanges always originate from one > >> side (the requestor). > >> > >> However, it is not the 802.1X transport that controls > >> whether the authentication is mutual or one-way. Rather, > >> it is the chosen EAP method and controlled ports able to > >> mutually enforce the authorization of the authentication. > >> > >> Despite the asymmetry of 802.1X and EAP transports, if a > >> mutually authenticating EAP method (such as EAP-TLS) is > >> carried within 802.1X frames, then the supplicant and > >> authenticator can mutually authenticate. However, if an > >> EAP method is chosen which only authenticates the > >> supplicant to the authenticator (e.g. EAP MD5-CHALLENGE), > >> then the authentication will be one-way. > >> > >> In an earlier version of 802.1X (802.1X-2001), only the > >> authenticator was specified to affect the controlled port. > >> This one-sided specification prevented mutual > >> authentications from being mutually enforced, essentially > >> preventing mutual authentication. However, this was due to > >> the lack of a specification of the controlled port on the > >> supplicant, not due to the one-way nature of the 802.1X > >> transport protocol. The current version of 802.1X remedies > >> this by specifying how both authenticator and supplicant > >> roles affect the controlled port. > >> > >> In 802.1X, each role has its own state machine and it is > >> possible that a single device can implement both the > >> supplicant and authenticator roles (state machines). If a > >> device implementing both roles encounters another device > >> implementing both roles, then two separate (and > >> simultaneous) 802.1X transports will take place in opposite > >> directions. This is sometimes referred to as a bi- > >> directional authentication transport or two coupled one-way > >> authentication exchanges. 802.1X does not support "tie > >> breaking" wherein two hosts initiating authentication with > >> each other will only go forward with a single > >> authentication. > >> > >> Two coupled one-way authentication exchanges are not > >> equivalent in security to a single exchange of a mutually > >> authenticating EAP method (such as EAP-TLS). Since the two > >> coupled one-way authentication exchanges are not > >> cryptographically bound together, there is no way to > >> ascertain that the party involved in the first one-way > >> exchange is the same party that is involved in the > >> alternate one-way exchange. > >> > >> Even though a single 802.1X exchange may provide mutual > >> authentication, there may be other reasons to run two > >> 802.1X exchanges in opposite directions. RFC 2284bis, > >> Section 2.4 discusses some of these cases, which include: > >> > >> 1) When the devices require the creation of separate > >> keying material as in group keys for 802.11 adhoc networks. > >> > >> 2) When different credentials are used for different roles > >> (one credential for the supplicant role and one for the > >> authenticator). > >> > >> 3) When two bridge devices are connected each bridge may > >> have its own requirement for authentication/authorization > >> that is only enforced by the authenticator ("Supplicant Access > >> Control With Authenticator" variable set to inactive), but will > >> implement the supplicant role to respond to the other > >> bridge. This configuration allows both bridges to utilize > >> the same authentication server even though one bridge is > >> separated from the authentication server by the other > >> bridge's controlled port. The first bridge with access to > >> the authentication server will complete authentication and > >> authorize its controlled port, this will allow the second > >> bridge to access the authentication server so that it may > >> authenticate and authorize the first bridge. > > > > > > I don't understand how completing one authentication allows the other > > authentication to complete. My question - If each authentication > > enables a variable and both must be on for traffic, then both must > > complete for traffic to flow. Or is your thought that the supplicant > > side of each is not required (configured on) so only the authenticator > > *needs* to authenticate? If so the control port can be on, but I > > still don't see how the other side's authenticator can do RADIUS (or > > other) to the authentication server since it does not have a port > > enabled on its side. > > > > I was thinking that that in a two bridge situation both bridges would > > be set with variables for both authenticator and supplicant open. The > > autenticator would start on its side. The supplicant would time out > > if the other side did not start. If both sides did start, both > > authentications would be required. > > > > I don't see how this can allow a bridge coming up to get to a > > Authentication Server via RADIUS before the connection is made. In my > > opinion it will require some sort of pass thru capability in EAPOL > > (or equivalent) that allows passing of RADIUS accross the link, and > > then to the AS. Somehow there would need to be a shared secret for > > message integrity between them. Probably this is doable, but not > > easily, and not for this document. > > > > So my thought is that the ability of a bridge to connect to another > > bridge, and go to an AS behind the bridge to which it is connecting is > > something that will happen in 802.1af, not here. [Note however that > > some protection could be built in by using a special EAP method that > > passed policy info to the connecting bridge after doing > > authentication. This would require enhancing existing methods to > > include sending of the info from the authenticator and requiring it > > (failing if not present) on the supplicant (the attaching bridge).] > > > >> > >> When a device that implements both 802.1X roles encounters > >> a device which implements only a single authenticator role, > >> this can result in asymmetric data flow (data traffic can > > > > I think no data flows into the unauthenticated port- a I right? If so > > then I think this misleading. Perhaps better to say one side can turn > > the port on but the other will not send or receive. This does point > > out the timeout problem. > > > >> only flow in one direction). This occurs because one > >> device opens its controlled port while the other device > >> does not. A complete table of encounters and results > >> (assuming authentication successes) appears in Table xxxx. > >> > >> It is suggested that applications utilizing 802.1X should > >> specify which .1X roles must be implemented to avoid > >> encounters that will result in failed network connections. > >> > >> Table xxxx: Result of encounters between .1X transport > >> roles assuming key-generating EAP methods are run and > >> result in success. > >> > >> Remote\Local--> | Supplicant | Authenticator | Both > >> | | | | > >> V | | | > >> ---------------------------------------------------------------------- > >> Supplicant |Fails gracefully | Works | Works > >> | No link will be | Authenticated | Authenticated > >> | formed if media | link | link > >> | is considered | Authentication | Authentication > >> | unsafe without | policy is set by | policy set by > >> | encryption | choice of EAP | choice of EAP > >> | (802.11). | method. | method > >> | | | Remote > >> | Unauthenticated | | supplicant and > >> | link will be | | local > >> | formed if media | | authenticator > >> | is considered | | are satisfied. > >> | safe by default | | Local > >> | (802.3) | | supplicant will > >> | | | receive no > >> | | | response and > >> | | | assume no > >> | | | authenticator. > >> | | | Successful > >> | | | authentication > >> | | | to the local > >> | | | authenticator > >> | | | will have made > >> | | | the port > >> | | | secure. > >> ----------------------------------------------------------------------- > >> Authenticator |Works - |Fails gracefully |Fails ? > >> | Authenticated |No link will be |Asymmetric link > >> | link ? |formed. Each |Remote > >> | Authentication |authenticator |controlled port > >> | policy set by |will send initial |is operational, > >> | choice of EAP |EAP requests but |but local > >> | method. |no response will |controlled port > >> | | arrive. |remains non- > >> | | | operational. > >> | | | Remote > >> | | | authenticator > >> | | | and local > >> | | | supplicant are > >> | | | satisfied, > >> | | | local > >> | | | authenticator > >> | | | remains > >> | | | unsatisfied. > >> ----------------------------------------------------------------------- > >> Both |Works |Fails |Works > >> | Authenticated |Asymmetric link | Authenticated > >> | link |Local controlled | link > >> | Authentication |port is | Authentication > >> | policy set by |operational, but | policy set by > >> | choice of EAP |remote controlled | choice of two > >> | method. |port remains non- | uncoupled EAP > >> | Local supplicant |operational. | methods. Two > >> | and remote |Local | keys will be > >> | authenticator |authenticator and | formed and some > >> | are satisfied. |remote supplicant | mechanism must > >> | Remote |are satisfied, | exist so that > >> | supplicant will |remote | local and > >> | receive no |authenticator | remote choose > >> | response and |remains | the same key. > >> | assume no |unsatisfied. | > >> | authenticator. | | > >> | Successful | | > >> | authentication | | > >> | to the remote | | > >> | authenticator | | > >> | will have made | | > >> | the port secure. | | > >> ----------------------------------------------------------------------- > >> > >> > > > > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jan 27 14:30:34 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19218 for ; Tue, 27 Jan 2004 14:30:34 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E861E20213; Tue, 27 Jan 2004 14:18:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from deneb.mtghouse.com (unknown [206.152.191.132]) by mail.frascone.com (Postfix) with SMTP id 89D872022E for ; Tue, 27 Jan 2004 14:17:17 -0500 (EST) Received: (qmail 12608 invoked from network); 27 Jan 2004 19:28:23 -0000 Received: from unknown (HELO mtghouse.com) (192.168.10.122) by deneb.mtghouse.com with SMTP; 27 Jan 2004 19:28:23 -0000 Message-ID: <4016BBE1.5010704@mtghouse.com> From: Jim Burns User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Vollbrecht Cc: Bernard Aboba , eap@frascone.com, stds-802-1@ieee.org, rgm@truesecure.com, paul.congdon@hp.com, jari.arkko@piuha.net Subject: Re: [eap] Re: Strawman for a modified section 6.7 (V4) for IEEE 802.1XRev References: <40142EB3.6070102@mtghouse.com> <8342274.1075114400@[10.0.1.2]> <40154B0F.7040906@mtghouse.com> <9969903.1075151887@[10.0.1.2]> In-Reply-To: <9969903.1075151887@[10.0.1.2]> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 27 Jan 2004 14:28:33 -0500 Content-Transfer-Encoding: 8bit Hi John, You are correct. B's controlled port will not allow RADIUS traffic on the port. I was wrong, and agree with that this is not defined in the standard. Hmmm. So, it is NOT possible for two bridges to utilize a single authentication server where one bridge accesses the authentication server through the other bridge because RADIUS will be blocked by B's controlled port. It is conceivable that an implementation could run a RADIUS stack atop the uncontrolled port, but each new protocol atop the uncontrolled port makes the possibility of compromise that much greater. Or, as you indicate, there could be some sort of RADIUS transport. But, none of these are specified in the standards. So, from a standards perspective, it is not possible. So, the text discussing the bridge to bridge case in relation to the bidirectional transport should instead just read: "When two bridge devices are connected each bridge may have its own requirement for authentication/authorization that is only enforced by the authenticator (“/Supplicant Access Control With Authenticator/” variable set to inactive), but will implement the supplicant role to respond to the other bridge" This text in addition to the sentence I added earlier about the lack of 'tie-breaking' should sufficiently cover this case. I will update V5 of the doc to include this. Thanks for the catch John, Jim B. John Vollbrecht wrote: > > > --On Monday, January 26, 2004 12:14 PM -0500 Jim Burns > wrote: > >> John, >> The key to answering your question is understanding the 802.1X >> management variable "Supplicant Access Control With Authenticator" that >> is described in section 6.4 of 802.1XRev draft 8 (around p17 or so). >> In short, when this management variable is set to the inactive state >> then >> the controlled port will only be authorized by the authenticator, the >> supplicant plays no role in authorizing the controlled port. Setting >> this variable to inactive causes the controlled port to work the way it >> did in 802.1X-2001. This is required for backwards compatibility of >> 802.1XRev draft 8 with 802.1X-2001 on bridges. So, imagin you have >> two bridges: A and B (both with the "Supplicant Access Control With >> Authenticator" set to inactive) and addition you have a single >> authentication server (let us call it S) that A has access to (no >> intervening controlled port), but which B must go through A to reach. >> Graphically: >> ------------- >> B<====>A<---->S >> Authentication/authorization would proceed as follows: >> --------------------------------------------------------- >> A's authenticator will begin an authentication with B's supplicant >> B's authenticator will begin an authentication with A's supplicant >> B's authenticator will send access-requests to S, but they will not >> reach S because the controlled port on A has not been authorized. So >> these access-requests will timeout and B will do resends. A's >> authenticator will send access-requests to S and receive responses and > > [A talks RADIUS to S right?] > >> eventually authenticate B's supplicant. A will authorize its >> controlled port. >> B's authenticator's access-requests will now reach S (through the >> authorized controlled port on A) and recieve responses and eventually >> authenticate A's supplicant. B will authorize its controlled port. >> > I don't have my copy of 6.4 here - it is at my desk at Merit. But I > don't understand how messages get from B's authenticator to S. My > understanding is that these are sent via RADIUS over IP. Without B's > port being turned on, I assume no IP traffic can be sent. So perhaps I > am wrong, but how does B send traffic to S in this scenario? > > >> The key to understanding the bridge to bridge case is understanding the >> "Supplicant Access Control With Authenticator" variable that is >> described >> in section 6.4. I can add a reference to 6.4 in my description of the >> bridge to bridge case in 6.7. Hope this helps, >> Jim B. >> >> John Vollbrecht wrote: >> >> > This is good. I do have a question about the dual bridge case, below. >> > >> > -- John >> > >> > --On Sunday, January 25, 2004 4:01 PM -0500 Jim Burns >> > wrote: >> > >> >> Hello, >> >> I have taken the input from last week and modified the proposal for >> >> section 6.7 of IEEE 802.1XRev. This is version 4 of the proposal. >> >> Jim B. >> >> ---------------------------------------- >> >> Version 1: >> >> -original release >> >> >> >> Version 2: >> >> -rewrite of text for readability by B. Aboba >> >> -remove discussion of specific applications >> >> -remove suggestions that specific applications define .1X >> >> roles and EAP methods. >> >> >> >> Version 3: >> >> -asymmetric connections are created when a device change 2nd >> >> to last paragraph to indicate that with both roles >> >> encounters a device with just an authenticator. >> >> -add a short paragraph suggesting that specific applications >> >> define .1X roles. >> >> >> >> Version 4: >> >> -Ensure the text indicates that two controlled ports >> >> enables enforcement of mutual authorization. (paragraph 3 & >> >> 5) >> >> -Indicate that it is creation of group keys not unicast >> >> keys in 802.11 adhoc that requires bi-directional >> >> transport. (#2 in list of reasons to utilize bi-directional >> >> transport) >> >> -Better specify why two bridges utilize bi-directional >> >> transport. (#3 in list of reasons to utilize bi-directional >> >> transport) >> >> -Make clear that the addition of the controlled port for >> >> the supplicant is for clarity on what to do with the >> >> authorization variable on the supplicant. (paragraph 5) >> >> -Mention that 802.1X does not support tie-breaking. >> >> (paragraph 6) >> >> -In general ensure careful use of terms and language. >> >> >> >> >> >> ------------------------------------------------------------- >> >> 6.7 Coupling two 802.1X authentications >> >> >> >> This section discusses the ability of 802.1X to run two >> >> simultaneous transports in opposite directions, how >> >> implementation asymmetries affect authentication results >> >> and how simultaneous bi-directional transport may be >> >> utilized. >> >> >> >> In 802.1X there is a requestor role (authenticator) and a >> >> responder role (supplicant). The authenticator transmits >> >> frames to the supplicant and the supplicant responds to >> >> those frames with frames of its own. 802.1X, like the >> >> authentication protocol carried within it (EAP), is a >> >> request/response protocol, and the state machines reflect >> >> this. Such a transport is sometimes called 'one-way' >> >> meaning the protocol exchanges always originate from one >> >> side (the requestor). >> >> >> >> However, it is not the 802.1X transport that controls >> >> whether the authentication is mutual or one-way. Rather, >> >> it is the chosen EAP method and controlled ports able to >> >> mutually enforce the authorization of the authentication. >> >> >> >> Despite the asymmetry of 802.1X and EAP transports, if a >> >> mutually authenticating EAP method (such as EAP-TLS) is >> >> carried within 802.1X frames, then the supplicant and >> >> authenticator can mutually authenticate. However, if an >> >> EAP method is chosen which only authenticates the >> >> supplicant to the authenticator (e.g. EAP MD5-CHALLENGE), >> >> then the authentication will be one-way. >> >> >> >> In an earlier version of 802.1X (802.1X-2001), only the >> >> authenticator was specified to affect the controlled port. >> >> This one-sided specification prevented mutual >> >> authentications from being mutually enforced, essentially >> >> preventing mutual authentication. However, this was due to >> >> the lack of a specification of the controlled port on the >> >> supplicant, not due to the one-way nature of the 802.1X >> >> transport protocol. The current version of 802.1X remedies >> >> this by specifying how both authenticator and supplicant >> >> roles affect the controlled port. >> >> >> >> In 802.1X, each role has its own state machine and it is >> >> possible that a single device can implement both the >> >> supplicant and authenticator roles (state machines). If a >> >> device implementing both roles encounters another device >> >> implementing both roles, then two separate (and >> >> simultaneous) 802.1X transports will take place in opposite >> >> directions. This is sometimes referred to as a bi- >> >> directional authentication transport or two coupled one-way >> >> authentication exchanges. 802.1X does not support "tie >> >> breaking" wherein two hosts initiating authentication with >> >> each other will only go forward with a single >> >> authentication. >> >> >> >> Two coupled one-way authentication exchanges are not >> >> equivalent in security to a single exchange of a mutually >> >> authenticating EAP method (such as EAP-TLS). Since the two >> >> coupled one-way authentication exchanges are not >> >> cryptographically bound together, there is no way to >> >> ascertain that the party involved in the first one-way >> >> exchange is the same party that is involved in the >> >> alternate one-way exchange. >> >> >> >> Even though a single 802.1X exchange may provide mutual >> >> authentication, there may be other reasons to run two >> >> 802.1X exchanges in opposite directions. RFC 2284bis, >> >> Section 2.4 discusses some of these cases, which include: >> >> >> >> 1) When the devices require the creation of separate >> >> keying material as in group keys for 802.11 adhoc networks. >> >> >> >> 2) When different credentials are used for different roles >> >> (one credential for the supplicant role and one for the >> >> authenticator). >> >> >> >> 3) When two bridge devices are connected each bridge may >> >> have its own requirement for authentication/authorization >> >> that is only enforced by the authenticator ("Supplicant Access >> >> Control With Authenticator" variable set to inactive), but will >> >> implement the supplicant role to respond to the other >> >> bridge. This configuration allows both bridges to utilize >> >> the same authentication server even though one bridge is >> >> separated from the authentication server by the other >> >> bridge's controlled port. The first bridge with access to >> >> the authentication server will complete authentication and >> >> authorize its controlled port, this will allow the second >> >> bridge to access the authentication server so that it may >> >> authenticate and authorize the first bridge. >> > >> > >> > I don't understand how completing one authentication allows the other >> > authentication to complete. My question - If each authentication >> > enables a variable and both must be on for traffic, then both must >> > complete for traffic to flow. Or is your thought that the supplicant >> > side of each is not required (configured on) so only the authenticator >> > *needs* to authenticate? If so the control port can be on, but I >> > still don't see how the other side's authenticator can do RADIUS (or >> > other) to the authentication server since it does not have a port >> > enabled on its side. >> > >> > I was thinking that that in a two bridge situation both bridges would >> > be set with variables for both authenticator and supplicant open. The >> > autenticator would start on its side. The supplicant would time out >> > if the other side did not start. If both sides did start, both >> > authentications would be required. >> > >> > I don't see how this can allow a bridge coming up to get to a >> > Authentication Server via RADIUS before the connection is made. In my >> > opinion it will require some sort of pass thru capability in EAPOL >> > (or equivalent) that allows passing of RADIUS accross the link, and >> > then to the AS. Somehow there would need to be a shared secret for >> > message integrity between them. Probably this is doable, but not >> > easily, and not for this document. >> > >> > So my thought is that the ability of a bridge to connect to another >> > bridge, and go to an AS behind the bridge to which it is connecting is >> > something that will happen in 802.1af, not here. [Note however that >> > some protection could be built in by using a special EAP method that >> > passed policy info to the connecting bridge after doing >> > authentication. This would require enhancing existing methods to >> > include sending of the info from the authenticator and requiring it >> > (failing if not present) on the supplicant (the attaching bridge).] >> > >> >> >> >> When a device that implements both 802.1X roles encounters >> >> a device which implements only a single authenticator role, >> >> this can result in asymmetric data flow (data traffic can >> > >> > I think no data flows into the unauthenticated port- a I right? If so >> > then I think this misleading. Perhaps better to say one side can turn >> > the port on but the other will not send or receive. This does point >> > out the timeout problem. >> > >> >> only flow in one direction). This occurs because one >> >> device opens its controlled port while the other device >> >> does not. A complete table of encounters and results >> >> (assuming authentication successes) appears in Table xxxx. >> >> >> >> It is suggested that applications utilizing 802.1X should >> >> specify which .1X roles must be implemented to avoid >> >> encounters that will result in failed network connections. >> >> >> >> Table xxxx: Result of encounters between .1X transport >> >> roles assuming key-generating EAP methods are run and >> >> result in success. >> >> >> >> Remote\Local--> | Supplicant | Authenticator | Both >> >> | | | | >> >> V | | | >> >> >> ---------------------------------------------------------------------- >> >> Supplicant |Fails gracefully | Works | Works >> >> | No link will be | Authenticated | Authenticated >> >> | formed if media | link | link >> >> | is considered | Authentication | Authentication >> >> | unsafe without | policy is set by | policy set by >> >> | encryption | choice of EAP | choice of EAP >> >> | (802.11). | method. | method >> >> | | | Remote >> >> | Unauthenticated | | supplicant and >> >> | link will be | | local >> >> | formed if media | | authenticator >> >> | is considered | | are satisfied. >> >> | safe by default | | Local >> >> | (802.3) | | supplicant will >> >> | | | receive no >> >> | | | response and >> >> | | | assume no >> >> | | | authenticator. >> >> | | | Successful >> >> | | | authentication >> >> | | | to the local >> >> | | | authenticator >> >> | | | will have made >> >> | | | the port >> >> | | | secure. >> >> >> ----------------------------------------------------------------------- >> >> Authenticator |Works - |Fails gracefully |Fails ? >> >> | Authenticated |No link will be |Asymmetric link >> >> | link ? |formed. Each |Remote >> >> | Authentication |authenticator |controlled port >> >> | policy set by |will send initial |is operational, >> >> | choice of EAP |EAP requests but |but local >> >> | method. |no response will |controlled port >> >> | | arrive. |remains non- >> >> | | | operational. >> >> | | | Remote >> >> | | | authenticator >> >> | | | and local >> >> | | | supplicant are >> >> | | | satisfied, >> >> | | | local >> >> | | | authenticator >> >> | | | remains >> >> | | | unsatisfied. >> >> >> ----------------------------------------------------------------------- >> >> Both |Works |Fails |Works >> >> | Authenticated |Asymmetric link | Authenticated >> >> | link |Local controlled | link >> >> | Authentication |port is | Authentication >> >> | policy set by |operational, but | policy set by >> >> | choice of EAP |remote controlled | choice of two >> >> | method. |port remains non- | uncoupled EAP >> >> | Local supplicant |operational. | methods. Two >> >> | and remote |Local | keys will be >> >> | authenticator |authenticator and | formed and some >> >> | are satisfied. |remote supplicant | mechanism must >> >> | Remote |are satisfied, | exist so that >> >> | supplicant will |remote | local and >> >> | receive no |authenticator | remote choose >> >> | response and |remains | the same key. >> >> | assume no |unsatisfied. | >> >> | authenticator. | | >> >> | Successful | | >> >> | authentication | | >> >> | to the remote | | >> >> | authenticator | | >> >> | will have made | | >> >> | the port secure. | | >> >> >> ----------------------------------------------------------------------- >> >> >> >> >> > >> > >> > > > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jan 27 19:26:18 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04590 for ; Tue, 27 Jan 2004 19:26:18 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1E32220278; Tue, 27 Jan 2004 19:15:06 -0500 (EST) Delivered-To: eap@frascone.com Received: from intolerance.mr.itd.umich.edu (intolerance.mr.itd.umich.edu [141.211.14.78]) by mail.frascone.com (Postfix) with ESMTP id 4B9A62026D for ; Tue, 27 Jan 2004 19:14:22 -0500 (EST) Received: from [10.0.1.2] (pm478-12.dialip.mich.net [207.75.179.214]) by intolerance.mr.itd.umich.edu (smtp) with ESMTP id i0S0PLbF004540; Tue, 27 Jan 2004 19:25:23 -0500 From: John Vollbrecht To: Jim Burns Cc: Bernard Aboba , eap@frascone.com, stds-802-1@ieee.org, rgm@truesecure.com, paul.congdon@hp.com, jari.arkko@piuha.net Subject: Re: [eap] Re: Strawman for a modified section 6.7 (V4) for IEEE 802.1XRev Message-ID: <86644.1075231518@[10.0.1.2]> In-Reply-To: <4016BBE1.5010704@mtghouse.com> References: <40142EB3.6070102@mtghouse.com> <8342274.1075114400@[10.0.1.2]> <40154B0F.7040906@mtghouse.com> <9969903.1075151887@[10.0.1.2]> <4016BBE1.5010704@mtghouse.com> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 27 Jan 2004 19:25:19 -0500 Content-Transfer-Encoding: 7bit sounds good to me -- John --On Tuesday, January 27, 2004 2:28 PM -0500 Jim Burns wrote: > Hi John, > You are correct. B's controlled port will not allow RADIUS traffic on the > port. I was wrong, and agree with that this is not defined in the > standard. Hmmm. So, it is NOT possible for two bridges to utilize a > single authentication server where one bridge accesses the authentication > server through the other bridge because RADIUS will be blocked by B's > controlled port. It is conceivable that an implementation could run a > RADIUS stack atop the uncontrolled port, but each new protocol atop the > uncontrolled port makes the possibility of compromise that much greater. > Or, as you indicate, there could be some sort of RADIUS transport. But, > none of these are specified in the standards. So, from a standards > perspective, it is not possible. So, the text discussing the bridge to > bridge case in relation to the bidirectional transport should instead > just read: > > "When two bridge devices are connected each bridge may have its own > requirement for authentication/authorization that is only enforced by the > authenticator (?/Supplicant Access Control With Authenticator/? variable > set to inactive), but will implement the supplicant role to respond to > the other bridge" > > This text in addition to the sentence I added earlier about the lack of > 'tie-breaking' should sufficiently cover this case. I will update V5 of > the doc to include this. > Thanks for the catch John, > Jim B. > > > John Vollbrecht wrote: > > > > > > > --On Monday, January 26, 2004 12:14 PM -0500 Jim Burns > > wrote: > > > >> John, > >> The key to answering your question is understanding the 802.1X > >> management variable "Supplicant Access Control With Authenticator" that > >> is described in section 6.4 of 802.1XRev draft 8 (around p17 or so). > >> In short, when this management variable is set to the inactive state > >> then > >> the controlled port will only be authorized by the authenticator, the > >> supplicant plays no role in authorizing the controlled port. Setting > >> this variable to inactive causes the controlled port to work the way it > >> did in 802.1X-2001. This is required for backwards compatibility of > >> 802.1XRev draft 8 with 802.1X-2001 on bridges. So, imagin you have > >> two bridges: A and B (both with the "Supplicant Access Control With > >> Authenticator" set to inactive) and addition you have a single > >> authentication server (let us call it S) that A has access to (no > >> intervening controlled port), but which B must go through A to reach. > >> Graphically: > >> ------------- > >> B<====>A<---->S > >> Authentication/authorization would proceed as follows: > >> --------------------------------------------------------- > >> A's authenticator will begin an authentication with B's supplicant > >> B's authenticator will begin an authentication with A's supplicant > >> B's authenticator will send access-requests to S, but they will not > >> reach S because the controlled port on A has not been authorized. So > >> these access-requests will timeout and B will do resends. A's > >> authenticator will send access-requests to S and receive responses and > > > > [A talks RADIUS to S right?] > > > >> eventually authenticate B's supplicant. A will authorize its > >> controlled port. > >> B's authenticator's access-requests will now reach S (through the > >> authorized controlled port on A) and recieve responses and eventually > >> authenticate A's supplicant. B will authorize its controlled port. > >> > > I don't have my copy of 6.4 here - it is at my desk at Merit. But I > > don't understand how messages get from B's authenticator to S. My > > understanding is that these are sent via RADIUS over IP. Without B's > > port being turned on, I assume no IP traffic can be sent. So perhaps I > > am wrong, but how does B send traffic to S in this scenario? > > > > > >> The key to understanding the bridge to bridge case is understanding the > >> "Supplicant Access Control With Authenticator" variable that is > >> described > >> in section 6.4. I can add a reference to 6.4 in my description of the > >> bridge to bridge case in 6.7. Hope this helps, > >> Jim B. > >> > >> John Vollbrecht wrote: > >> > >> > This is good. I do have a question about the dual bridge case, below. > >> > > >> > -- John > >> > > >> > --On Sunday, January 25, 2004 4:01 PM -0500 Jim Burns > >> > wrote: > >> > > >> >> Hello, > >> >> I have taken the input from last week and modified the proposal for > >> >> section 6.7 of IEEE 802.1XRev. This is version 4 of the proposal. > >> >> Jim B. > >> >> ---------------------------------------- > >> >> Version 1: > >> >> -original release > >> >> > >> >> Version 2: > >> >> -rewrite of text for readability by B. Aboba > >> >> -remove discussion of specific applications > >> >> -remove suggestions that specific applications define .1X > >> >> roles and EAP methods. > >> >> > >> >> Version 3: > >> >> -asymmetric connections are created when a device change 2nd > >> >> to last paragraph to indicate that with both roles > >> >> encounters a device with just an authenticator. > >> >> -add a short paragraph suggesting that specific applications > >> >> define .1X roles. > >> >> > >> >> Version 4: > >> >> -Ensure the text indicates that two controlled ports > >> >> enables enforcement of mutual authorization. (paragraph 3 & > >> >> 5) > >> >> -Indicate that it is creation of group keys not unicast > >> >> keys in 802.11 adhoc that requires bi-directional > >> >> transport. (#2 in list of reasons to utilize bi-directional > >> >> transport) > >> >> -Better specify why two bridges utilize bi-directional > >> >> transport. (#3 in list of reasons to utilize bi-directional > >> >> transport) > >> >> -Make clear that the addition of the controlled port for > >> >> the supplicant is for clarity on what to do with the > >> >> authorization variable on the supplicant. (paragraph 5) > >> >> -Mention that 802.1X does not support tie-breaking. > >> >> (paragraph 6) > >> >> -In general ensure careful use of terms and language. > >> >> > >> >> > >> >> ------------------------------------------------------------- > >> >> 6.7 Coupling two 802.1X authentications > >> >> > >> >> This section discusses the ability of 802.1X to run two > >> >> simultaneous transports in opposite directions, how > >> >> implementation asymmetries affect authentication results > >> >> and how simultaneous bi-directional transport may be > >> >> utilized. > >> >> > >> >> In 802.1X there is a requestor role (authenticator) and a > >> >> responder role (supplicant). The authenticator transmits > >> >> frames to the supplicant and the supplicant responds to > >> >> those frames with frames of its own. 802.1X, like the > >> >> authentication protocol carried within it (EAP), is a > >> >> request/response protocol, and the state machines reflect > >> >> this. Such a transport is sometimes called 'one-way' > >> >> meaning the protocol exchanges always originate from one > >> >> side (the requestor). > >> >> > >> >> However, it is not the 802.1X transport that controls > >> >> whether the authentication is mutual or one-way. Rather, > >> >> it is the chosen EAP method and controlled ports able to > >> >> mutually enforce the authorization of the authentication. > >> >> > >> >> Despite the asymmetry of 802.1X and EAP transports, if a > >> >> mutually authenticating EAP method (such as EAP-TLS) is > >> >> carried within 802.1X frames, then the supplicant and > >> >> authenticator can mutually authenticate. However, if an > >> >> EAP method is chosen which only authenticates the > >> >> supplicant to the authenticator (e.g. EAP MD5-CHALLENGE), > >> >> then the authentication will be one-way. > >> >> > >> >> In an earlier version of 802.1X (802.1X-2001), only the > >> >> authenticator was specified to affect the controlled port. > >> >> This one-sided specification prevented mutual > >> >> authentications from being mutually enforced, essentially > >> >> preventing mutual authentication. However, this was due to > >> >> the lack of a specification of the controlled port on the > >> >> supplicant, not due to the one-way nature of the 802.1X > >> >> transport protocol. The current version of 802.1X remedies > >> >> this by specifying how both authenticator and supplicant > >> >> roles affect the controlled port. > >> >> > >> >> In 802.1X, each role has its own state machine and it is > >> >> possible that a single device can implement both the > >> >> supplicant and authenticator roles (state machines). If a > >> >> device implementing both roles encounters another device > >> >> implementing both roles, then two separate (and > >> >> simultaneous) 802.1X transports will take place in opposite > >> >> directions. This is sometimes referred to as a bi- > >> >> directional authentication transport or two coupled one-way > >> >> authentication exchanges. 802.1X does not support "tie > >> >> breaking" wherein two hosts initiating authentication with > >> >> each other will only go forward with a single > >> >> authentication. > >> >> > >> >> Two coupled one-way authentication exchanges are not > >> >> equivalent in security to a single exchange of a mutually > >> >> authenticating EAP method (such as EAP-TLS). Since the two > >> >> coupled one-way authentication exchanges are not > >> >> cryptographically bound together, there is no way to > >> >> ascertain that the party involved in the first one-way > >> >> exchange is the same party that is involved in the > >> >> alternate one-way exchange. > >> >> > >> >> Even though a single 802.1X exchange may provide mutual > >> >> authentication, there may be other reasons to run two > >> >> 802.1X exchanges in opposite directions. RFC 2284bis, > >> >> Section 2.4 discusses some of these cases, which include: > >> >> > >> >> 1) When the devices require the creation of separate > >> >> keying material as in group keys for 802.11 adhoc networks. > >> >> > >> >> 2) When different credentials are used for different roles > >> >> (one credential for the supplicant role and one for the > >> >> authenticator). > >> >> > >> >> 3) When two bridge devices are connected each bridge may > >> >> have its own requirement for authentication/authorization > >> >> that is only enforced by the authenticator ("Supplicant Access > >> >> Control With Authenticator" variable set to inactive), but will > >> >> implement the supplicant role to respond to the other > >> >> bridge. This configuration allows both bridges to utilize > >> >> the same authentication server even though one bridge is > >> >> separated from the authentication server by the other > >> >> bridge's controlled port. The first bridge with access to > >> >> the authentication server will complete authentication and > >> >> authorize its controlled port, this will allow the second > >> >> bridge to access the authentication server so that it may > >> >> authenticate and authorize the first bridge. > >> > > >> > > >> > I don't understand how completing one authentication allows the other > >> > authentication to complete. My question - If each authentication > >> > enables a variable and both must be on for traffic, then both must > >> > complete for traffic to flow. Or is your thought that the supplicant > >> > side of each is not required (configured on) so only the > >> > authenticator *needs* to authenticate? If so the control port can be > >> > on, but I still don't see how the other side's authenticator can do > >> > RADIUS (or other) to the authentication server since it does not > >> > have a port enabled on its side. > >> > > >> > I was thinking that that in a two bridge situation both bridges would > >> > be set with variables for both authenticator and supplicant open. The > >> > autenticator would start on its side. The supplicant would time out > >> > if the other side did not start. If both sides did start, both > >> > authentications would be required. > >> > > >> > I don't see how this can allow a bridge coming up to get to a > >> > Authentication Server via RADIUS before the connection is made. In my > >> > opinion it will require some sort of pass thru capability in EAPOL > >> > (or equivalent) that allows passing of RADIUS accross the link, and > >> > then to the AS. Somehow there would need to be a shared secret for > >> > message integrity between them. Probably this is doable, but not > >> > easily, and not for this document. > >> > > >> > So my thought is that the ability of a bridge to connect to another > >> > bridge, and go to an AS behind the bridge to which it is connecting > >> > is something that will happen in 802.1af, not here. [Note however > >> > that some protection could be built in by using a special EAP method > >> > that passed policy info to the connecting bridge after doing > >> > authentication. This would require enhancing existing methods to > >> > include sending of the info from the authenticator and requiring it > >> > (failing if not present) on the supplicant (the attaching bridge).] > >> > > >> >> > >> >> When a device that implements both 802.1X roles encounters > >> >> a device which implements only a single authenticator role, > >> >> this can result in asymmetric data flow (data traffic can > >> > > >> > I think no data flows into the unauthenticated port- a I right? If so > >> > then I think this misleading. Perhaps better to say one side can turn > >> > the port on but the other will not send or receive. This does point > >> > out the timeout problem. > >> > > >> >> only flow in one direction). This occurs because one > >> >> device opens its controlled port while the other device > >> >> does not. A complete table of encounters and results > >> >> (assuming authentication successes) appears in Table xxxx. > >> >> > >> >> It is suggested that applications utilizing 802.1X should > >> >> specify which .1X roles must be implemented to avoid > >> >> encounters that will result in failed network connections. > >> >> > >> >> Table xxxx: Result of encounters between .1X transport > >> >> roles assuming key-generating EAP methods are run and > >> >> result in success. > >> >> > >> >> Remote\Local--> | Supplicant | Authenticator | Both > >> >> | | | | > >> >> V | | | > >> >> > >> ---------------------------------------------------------------------- > >> >> Supplicant |Fails gracefully | Works | Works > >> >> | No link will be | Authenticated | Authenticated > >> >> | formed if media | link | link > >> >> | is considered | Authentication | Authentication > >> >> | unsafe without | policy is set by | policy set by > >> >> | encryption | choice of EAP | choice of EAP > >> >> | (802.11). | method. | method > >> >> | | | Remote > >> >> | Unauthenticated | | supplicant and > >> >> | link will be | | local > >> >> | formed if media | | authenticator > >> >> | is considered | | are satisfied. > >> >> | safe by default | | Local > >> >> | (802.3) | | supplicant will > >> >> | | | receive no > >> >> | | | response and > >> >> | | | assume no > >> >> | | | authenticator. > >> >> | | | Successful > >> >> | | | authentication > >> >> | | | to the local > >> >> | | | authenticator > >> >> | | | will have made > >> >> | | | the port > >> >> | | | secure. > >> >> > >> ----------------------------------------------------------------------- > >> >> Authenticator |Works - |Fails gracefully |Fails ? > >> >> | Authenticated |No link will be |Asymmetric link > >> >> | link ? |formed. Each |Remote > >> >> | Authentication |authenticator |controlled port > >> >> | policy set by |will send initial |is operational, > >> >> | choice of EAP |EAP requests but |but local > >> >> | method. |no response will |controlled port > >> >> | | arrive. |remains non- > >> >> | | | operational. > >> >> | | | Remote > >> >> | | | authenticator > >> >> | | | and local > >> >> | | | supplicant are > >> >> | | | satisfied, > >> >> | | | local > >> >> | | | authenticator > >> >> | | | remains > >> >> | | | unsatisfied. > >> >> > >> ----------------------------------------------------------------------- > >> >> Both |Works |Fails |Works > >> >> | Authenticated |Asymmetric link | Authenticated > >> >> | link |Local controlled | link > >> >> | Authentication |port is | Authentication > >> >> | policy set by |operational, but | policy set by > >> >> | choice of EAP |remote controlled | choice of two > >> >> | method. |port remains non- | uncoupled EAP > >> >> | Local supplicant |operational. | methods. Two > >> >> | and remote |Local | keys will be > >> >> | authenticator |authenticator and | formed and some > >> >> | are satisfied. |remote supplicant | mechanism must > >> >> | Remote |are satisfied, | exist so that > >> >> | supplicant will |remote | local and > >> >> | receive no |authenticator | remote choose > >> >> | response and |remains | the same key. > >> >> | assume no |unsatisfied. | > >> >> | authenticator. | | > >> >> | Successful | | > >> >> | authentication | | > >> >> | to the remote | | > >> >> | authenticator | | > >> >> | will have made | | > >> >> | the port secure. | | > >> >> > >> ----------------------------------------------------------------------- > >> >> > >> >> > >> > > >> > > >> > > > > > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Jan 27 19:46:12 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06589 for ; Tue, 27 Jan 2004 19:46:12 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D075120272; Tue, 27 Jan 2004 19:35:05 -0500 (EST) Delivered-To: eap@frascone.com Received: from intolerance.mr.itd.umich.edu (intolerance.mr.itd.umich.edu [141.211.14.78]) by mail.frascone.com (Postfix) with ESMTP id 9E47D2026C for ; Tue, 27 Jan 2004 19:34:53 -0500 (EST) Received: from [10.0.1.2] (pm478-12.dialip.mich.net [207.75.179.214]) by intolerance.mr.itd.umich.edu (smtp) with ESMTP id i0S0jtbF008359; Tue, 27 Jan 2004 19:45:57 -0500 From: John Vollbrecht To: Bernard Aboba , jeb@mtghouse.com Cc: eap@frascone.com, stds-802-1@ieee.org, rgm@truesecure.com, paul.congdon@hp.com, jari.arkko@piuha.net Message-ID: <161035.1075232758@[10.0.1.2]> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [eap] Re: Strawman for a modified section 6.7 (V4) for IEEE 802.1XRev Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 27 Jan 2004 19:45:59 -0500 Content-Transfer-Encoding: 7bit I like most of the changes. They clean up the language a lot. I do have a few comments below. - --On Tuesday, January 27, 2004 2:44 PM -0800 Bernard Aboba wrote: > Thanks for taking this on. The text keeps getting and better each time. > Just a few comments ;) > > > However, it is not the 802.1X transport that controls > > whether the authentication is mutual or one-way. Rather, > > it is the chosen EAP method and controlled ports able to > > mutually enforce the authorization of the authentication. > > I'd rephrase to say: > > "Rather, the chosen EAP method controls whether the > authentication is mutual or one-way, and support for > a supplicant controlled-port determines whether > authorization is mutual or one-way." > > > In an earlier version of 802.1X (802.1X-2001), only the > > authenticator was specified to affect the controlled port. > > I'd rephrase to say "only the authenticator was specified to > have a controlled port." > > > This one-sided specification prevented mutual > > authentications from being mutually enforced, essentially > > preventing mutual authentication. > > I'd rephrase to say "The lack of a supplicant controlled port prevented > mutual authentication from being enforced on both sides." > > > However, this was due to > > the lack of a specification of the controlled port on the > > supplicant, not due to the one-way nature of the 802.1X > > transport protocol. The current version of 802.1X remedies > > this by specifying how both authenticator and supplicant > > roles affect the controlled port. > > would change to "remedies this by specifying controlled ports > for both the authentication and supplicant." > > > 1) When the devices require the creation of separate > > keying material as in group keys for 802.11 adhoc networks. > > The issue here was not that each side required separate keying material; > it was that the 802.11 group key handshake was uni-directional (AP only > provided a group key to the supplicant, not the other way around). So > I'd rephrase to say: > > "When the devices require the creation of separate key material in > each direction but the keying protocol is uni-directional (as in the group > handshake in 802.11 adhoc networks)." > > > 3) When two bridge devices are connected each bridge may > > have its own requirement for authentication/authorization > > that is only enforced by the authenticator ("Supplicant Access > > Control With Authenticator" variable set to inactive), but will > > implement the supplicant role to respond to the other > > bridge. > > Would rephrase to: "When two bridges are connected, each > bridge may implement the Supplicant role, but may have > authorization requirements that can only be enforced by > the Authenticator ("Supplicant Access Control with Authenticator" > variable set to active)." > > > This configuration allows both bridges to utilize > > the same authentication server even though one bridge is > > separated from the authentication server by the other > > bridge's controlled port. The first bridge with access to > > the authentication server will complete authentication and > > authorize its controlled port, this will allow the second > > bridge to access the authentication server so that it may > > authenticate and authorize the first bridge. > > As John noted, I think this is problematic. Do we really need to > get into this here? Personally, I delete the above paragraph. > > When a device that implements both 802.1X roles encounters > > a device which implements only a single authenticator role, > > this can result in asymmetric data flow (data traffic can > > only flow in one direction). This occurs because one > > device opens its controlled port while the other device > > does not. A complete table of encounters and results > > (assuming authentication successes) appears in Table xxxx. > > Let me make sure I understand this fully. > If one device is only an authenticator, then it could authenticate the > dual role device. If a mutual authentication is successful, the dual role > device could decide it is satisfied, and then data would flow in both > directions. However, if the dual role device decided it needed to > initiate authentication in the other direction (e.g. mutual authentication > didn't provide it with sufficient authorization), would presumably send an > EAP-Request/Identity to the authenticator-only device, who would > not respond. As a result, the authentication in the other direction would > fail. At that point, presumably the dual role device would close off > communication in *both* directions, no? So I'm not clear how we can > get data flowing in only one direction. > > > It is suggested that applications utilizing 802.1X should > > specify which .1X roles must be implemented to avoid > > encounters that will result in failed network connections. > > This is good advice -- but I wonder if it's enough. In looking at > Section 2.4 of RFC 2284bis, there are really quite a few requirements for > successful peer-to-peer usage of EAP: > a. Need both authenticator and supplicant 802.1X roles. > b. Need both authenticator and peer layer support within the EAP > implementation. c. Need both authentication and peer support within the > implemented EAP method. d. Need both authenticator and peer credentials > provisioned on both sides. This is made easier if the selected EAP > method is peer-to-peer so that the same credential can be used both ways. > > Perhaps you should add "See Section 2.4 of RFC 2284bis for other issues > which may arise in peer-to-peer usage of EAP." > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Jan 29 03:10:43 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07326 for ; Thu, 29 Jan 2004 03:10:43 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 24BAA20323; Thu, 29 Jan 2004 02:59:17 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 67B0020325; Thu, 29 Jan 2004 02:59:10 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7F7982031D for ; Thu, 29 Jan 2004 02:58:14 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 949CE2015F for ; Thu, 29 Jan 2004 02:58:12 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 378946A910; Thu, 29 Jan 2004 10:09:20 +0200 (EET) Message-ID: <4018BF56.4080809@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Cc: "eap@frascone.com" Subject: Re: [eap] network selection References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 29 Jan 2004 10:07:50 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Alper, Thanks for looking at the draft. Some discussion inline: > I have some comments, please see below... > > First, there is the problem of "Access Network discovery". This > is the problem of discovering access networks available in the > vicinity, and the points of presence (POPs) associated with those > networks. > > In PANA we borrowed two terms from the DSL networks, NAP (Network Access > Provider) and ISP. NAP is the owner/operator of the access infrastructure > (such as the WLAN AP in the coffee shop). It provides L2 access to the > clients and connect them to their ISP. ISP should have a business agreement > with the NAP for this "roaming" service. Those are good terms. > I think our "ISP" corresponds to your "Access network"? And what is the > "home network" then? Our "access network" is the physical access points and associated NAP, I think. A practical example would be a specific AP broadcasting on a specific channel and a specific SSID such as "Starbucks". Our "home network" is where the client would have its subscription, i.e. the domain part of the user's NAI. Does this make it clearer? I'm not exactly sure what the mapping is to PANA ISP, however. PANA ISP appears to be a lower layer concept which may or may not have something to do with the the user's home domain. For instance, you might have two available ISPs in PANA but the same NAI might apply to both. > If we are talking about general "access network discovery", I think it would > involve discovering both NAPs and their associated (serviced) ISPs in my > client's vicinity. I think we are more interested in the latter part of the > problem. This leads me to think that your definition of ISP is closer to what we have called a "mediating network". I.e. it might not be the "end" domain in the AAA chain? > Referring to Figure 2: > > In this > figure, the user "joe@corp3.com" has to be authenticated through ISP > 2, since the domain "corp3.com" is served by it. > > I think another way to read this is "All the employees of corp3.com has an > account with ISP2 under their name. When they connect to ISP2, their traffic This is right. > is VPN'ed to the corporate network". Right? There may or may not be a VPN service associated with this. If you don't think about companies but ISPs with a roaming service instead, you can probably see the non-VPN case: users would just get access through the local ISP, but their packets would be routed directly to the Internet. > There has been requests to place credential and AAA route selection > under user control, as the user is affected by the pricing and other > differences. > > I don't think this is necessary. I should only care about my ISP selection, > and be able to trust my ISP to figure out the best AAA route for me (in > figure 3, isp1.com is aware of both paths). If the access network is trying > to rip me off, my ISP should be able to catch that. And if my ISP is ripping > me off, oh well..... I think I personally agree. But is your ISP the final home domain or possibly a roaming partner of the user's home domain? > Regarding the attack on 2.4.1: I think this is a combined issue of network > identity theft in the absence of unprotected or unverified discovery, and > bandwidth reselling. These can be issues on their own even when separated. I > don't think the combination has an effect here. Ok. > Basically, if the "rogue" access point has a flat fee > account and a contract with a clearing house, it can offer access to > anyone with a per-byte account, NAT their packets, and send the > traffic forward on its own account, and generate income. > > And this is just one way to provide a legitimate service, given that the > upstream service provider legally allows you to resell the bandwidth. If you > are using someone else's network name to lure clients in, this is a separate > issue. I agree. > However, IPsec could be used to detect the > presence of such NATs, even if NAT traversal is in use. > > There wouldn't be any needs for NAT when a /64 IPv6 prefixes are delegated > to mobile clients. So, relying on NAT detection is not sufficient. Right. Good point, thanks. > Similarly, the IEEE 802.1af has discussed the > idea of supporting network discovery within a future revision to > IEEE 802.1X. > > Supporting this functionality in the EAP lower layer seems logical to me. > This is what we did with the PANA design. Great! > In the IETF, a potential alternative is use of the SEAMOBY CARD > protocol [13], which enables advertisement of network device > capabilities over IP. Another alternative is the recently > proposed Device Discovery Protocol (DDP) [12], which provides > functionality equivalent to IEEE 802.1ab using ASN.1 encoded > advertisements sent to a link-local scope multicast address. > > Using CARD lets you collect information about the networks in your client's > vicinity. These are the potential points of attachments upon movement. I > think the use of DDP can be similar (if, access points are in the same > subnet). Neither is about discovering and selecting an immediate access > network. I think it is worth mentioning PANA in here, where this selection > takes place during the network access AAA (before client engages in > authentication). Ok. > The representation of link layer parameters within EAP > should utilize a common framework, to make it easier to define new > link layers and keep the selection of EAP methods independent of the > link layer. > > ... > > The security requirements for network discovery depend on the type of > information being discovered. Some of the parameters may have a > security impact, such as the claimed name of the network the user > tries to attach to. Unfortunately, current EAP methods do not always > make the verification of such parameters possible. > > I think hosting these functionalities in the EAP lower layer is a better > approach. I agree that security for discovery should be done at the layer discovery itself is done, i.e., typically at the link layer. However, there is an additional issue which the above paragraphs are trying to address. The problem is that even if the lower layers are secure by themselves, the information passed in them might be false, if the access points are lying. Thus, it might be useful to be able to cryptographically verify that information passed in the lower layer corresponds to the information passed in the AAA chain. The way to do this is to exchange at least some important parameters over EAP as well, and then ensure that the three pieces of information match. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Jan 29 04:03:21 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08898 for ; Thu, 29 Jan 2004 04:03:21 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0EC99201F9; Thu, 29 Jan 2004 03:52:10 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CC30D2032A; Thu, 29 Jan 2004 03:52:06 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 98A192032A for ; Thu, 29 Jan 2004 03:51:24 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id F2467201F9 for ; Thu, 29 Jan 2004 03:51:22 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id C90416A90F; Thu, 29 Jan 2004 11:02:31 +0200 (EET) Message-ID: <4018CBCE.70401@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Lortz, Victor" Cc: eap@frascone.com Subject: Re: [eap] network selection References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 29 Jan 2004 11:01:02 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Lortz, Victor wrote: > Generally a user doesn't care how IP datagrams are routed because there > is no cost premium paid by the user for one path vs. another. A > different analogy that might be helpful is as follows: suppose we > consider the phone network. It is possible to establish a default long > distance provider for a given phone line. However, even if such a > default exists, it remains possible to dial a number such as 10 10 123 > or an 800 number for alternative long distance service. This imposes > more inconvenience on the user, but the savings may be significant. Requirements for user control have been expressed. Requirements for automatic operation have also been expressed. And there are clear tradeoffs in the user control case, ease of use vs. freedom of selection. I don't think we can make the user control requirement go away, but it may be helpful to think about the analogy from the long distance dialing above. Are we *requiring* the user to do something, or just *allowing* it? This is also related to the use of the mediating network selection, do we have it because of *missing* or just *ambiquous* routes? Finally, there is the question of whether the user or his device are doing this. I think we can agree that the user should not be required to do anything. This would imply either (a) There has to be a working default route, or (b) The user's device needs to take care of the selection Given that existing user devices might not be able to do (b), my preference is (a). Of course, its hard for any standards to dictate that the service providers must keep the AAA routing tables perfectly completely all the time, so it may be necessary to allow (b) as well, as long as we understand its not going to work for everyone. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Jan 29 10:25:22 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24136 for ; Thu, 29 Jan 2004 10:25:21 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7ED7E2034E; Thu, 29 Jan 2004 10:14:09 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 14D6E20355; Thu, 29 Jan 2004 10:14:06 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B5B4720355 for ; Thu, 29 Jan 2004 10:13:55 -0500 (EST) Received: from hermes.hd.intel.com (fmr09.intel.com [192.52.57.35]) by mail.frascone.com (Postfix) with ESMTP id 2140C2034E for ; Thu, 29 Jan 2004 10:13:54 -0500 (EST) Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i0TFP26s018982 for ; Thu, 29 Jan 2004 15:25:02 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.hd.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.9 2004/01/09 01:01:50 root Exp $) with SMTP id i0TFOjB2017504 for ; Thu, 29 Jan 2004 15:25:01 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004012907250013243 for ; Thu, 29 Jan 2004 07:25:00 -0800 Received: from orsmsx401.amr.corp.intel.com ([192.168.65.207]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 29 Jan 2004 07:25:00 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [eap] network selection Message-ID: Thread-Topic: [eap] network selection Thread-Index: AcPmRqIVfHJHHDzTSzWMveb5ILP3NgANF/mg From: "Lortz, Victor" To: X-OriginalArrivalTime: 29 Jan 2004 15:25:00.0554 (UTC) FILETIME=[0F6B76A0:01C3E67C] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 29 Jan 2004 07:25:00 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Jari, I agree that the user's device needs to take care of the selection of AAA routing. There may be some setup procedure to configure user preferences, but once that is done, the device should automatically determine when and how to specify the routing. I also agree that a default route should be provided. That is why I mentioned that one can establish a default long distance provider for a phone line. In retrospect, I should have made this point more clear: I think there should both be a default route and a mechanism for the user's machine to specify a desired route. Based on your comments below, I think we are in agreement. -Vic -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 Sent: Thursday, January 29, 2004 1:01 AM To: Lortz, Victor Cc: eap@frascone.com Subject: Re: [eap] network selection Lortz, Victor wrote: > Generally a user doesn't care how IP datagrams are routed because there > is no cost premium paid by the user for one path vs. another. A > different analogy that might be helpful is as follows: suppose we > consider the phone network. It is possible to establish a default long > distance provider for a given phone line. However, even if such a > default exists, it remains possible to dial a number such as 10 10 123 > or an 800 number for alternative long distance service. This imposes > more inconvenience on the user, but the savings may be significant. Requirements for user control have been expressed. Requirements for automatic operation have also been expressed. And there are clear tradeoffs in the user control case, ease of use vs. freedom of selection. I don't think we can make the user control requirement go away, but it may be helpful to think about the analogy from the long distance dialing above. Are we *requiring* the user to do something, or just *allowing* it? This is also related to the use of the mediating network selection, do we have it because of *missing* or just *ambiquous* routes? Finally, there is the question of whether the user or his device are doing this. I think we can agree that the user should not be required to do anything. This would imply either (a) There has to be a working default route, or (b) The user's device needs to take care of the selection Given that existing user devices might not be able to do (b), my preference is (a). Of course, its hard for any standards to dictate that the service providers must keep the AAA routing tables perfectly completely all the time, so it may be necessary to allow (b) as well, as long as we understand its not going to work for everyone. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Jan 30 11:52:44 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27162 for ; Fri, 30 Jan 2004 11:52:43 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E97D920422; Fri, 30 Jan 2004 11:41:09 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EDE5B20423; Fri, 30 Jan 2004 11:41:06 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D89D620423 for ; Fri, 30 Jan 2004 11:40:26 -0500 (EST) Received: from deneb.mtghouse.com (unknown [206.152.191.132]) by mail.frascone.com (Postfix) with SMTP id 28A5A20422 for ; Fri, 30 Jan 2004 11:40:25 -0500 (EST) Received: (qmail 27336 invoked from network); 30 Jan 2004 16:51:35 -0000 Received: from unknown (HELO mtghouse.com) (192.168.10.122) by deneb.mtghouse.com with SMTP; 30 Jan 2004 16:51:35 -0000 Message-ID: <401A8BA3.9090904@mtghouse.com> From: Jim Burns User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com, stds-802-1@ieee.org, rgm@truesecure.com, paul.congdon@hp.com, jrv@umich.edu, jari.arkko@piuha.net References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: Strawman for a modified section 6.7 (V4) for IEEE 802.1XRev Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 30 Jan 2004 11:51:47 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Bernard, Thanks for your input (and cleanup of my pedantic text). I accept all of your comments except two which I believe need a bit more discussion just to be certain we are on the same wavelength. > > would change to "remedies this by specifying controlled ports > for both the authentication and supplicant." The issue here is that making this change could mislead folks into believing there are two controlled ports. In reality, 802.1XRev still only specifies a single controlled port. The difference between 802.1X-2001 and 802.1XRev is that the controlled port will not become authorized until both the supplicant and authenticator set their individual authorization variables. So, your sentence above is accurate in the case that the authenticator and supplicant are in separate devices since in one device only the authenticator role is implemented and it controls the controlled port alone and in the other only the supplicant. The sentence becomes inaccurate (or less precise) in a device that implements both the authenticator and supplicant roles. In this case the above sentence would indicate that a device with both roles actually has two separate controlled ports. > > >> When a device that implements both 802.1X roles encounters >> a device which implements only a single authenticator role, >> this can result in asymmetric data flow (data traffic can >> only flow in one direction). This occurs because one >> device opens its controlled port while the other device >> does not. A complete table of encounters and results >> (assuming authentication successes) appears in Table xxxx. > > > Let me make sure I understand this fully. > If one device is only an authenticator, then it could authenticate the > dual role device. If a mutual authentication is successful, the dual > role > device could decide it is satisfied, and then data would flow in both > directions. Yes, but this procedure is not directly defined in the standard. An implementation of the dual role device would need to detect that the supplicant was fully satisfied and then ignore the authenticator's result. > However, if the dual role device decided it needed to > initiate authentication in the other direction (e.g. mutual > authentication > didn't provide it with sufficient authorization), would presumably > send an > EAP-Request/Identity to the authenticator-only device, who would > not respond. As a result, the authentication in the other direction > would > fail. At that point, presumably the dual role device would close off > communication in *both* directions, no? So I'm not clear how we can > get data flowing in only one direction. Everything you say in this paragraph is accurate. Our difference appears to be on the definition of 'asymmetric' data flow (which is possibly because it is a poor choice for a name). What I mean to indicate is the single-role device has opened its controlled port and believes it has access to the network and is blissfully unaware that the other side of the connection has a closed port. So, from the point of view of the single-role device the data link is asymmetric -- it can send data out its port, but data never comes in its port. The main issue here is one of end-user experience -- all the network protocols will see the operable port, send their frames and then time out. Perhaps new text around 'asymmetric data flow': "...asymmetric data link (one entity's controlled port is authorized while the other entity's controlled port is not)." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Jan 31 02:58:27 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12145 for ; Sat, 31 Jan 2004 02:58:27 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 83EEC20165; Sat, 31 Jan 2004 02:47:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1191B20350; Sat, 31 Jan 2004 02:47:06 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D01C420350 for ; Sat, 31 Jan 2004 02:46:36 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id C221320165 for ; Sat, 31 Jan 2004 02:46:34 -0500 (EST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 8F5856A905 for ; Sat, 31 Jan 2004 09:57:45 +0200 (EET) Message-ID: <401B5F9E.4060003@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: multipart/mixed; boundary="------------000406070507090707090108" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] [Fwd: I-D ACTION:draft-bersani-eap-psk-00.txt] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 31 Jan 2004 09:56:14 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. --------------000406070507090707090108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------000406070507090707090108 Content-Type: message/rfc822; name="I-D ACTION:draft-bersani-eap-psk-00.txt" Content-Disposition: inline; filename="I-D ACTION:draft-bersani-eap-psk-00.txt" X-Sieve: cmu-sieve 2.0 Return-Path: X-Original-To: jari.arkko@piuha.net Delivered-To: jarkko@piuha.net Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by p2.piuha.net (Postfix) with ESMTP id C0B2F6A907; Fri, 30 Jan 2004 19:15:10 +0200 (EET) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1Ambx8-00038I-9U for ietf-announce-list@asgard.ietf.org; Fri, 30 Jan 2004 11:57:10 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AmbqC-0002AO-8F for all-ietf@asgard.ietf.org; Fri, 30 Jan 2004 11:50:00 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26817 for ; Fri, 30 Jan 2004 11:49:57 -0500 (EST) Message-Id: <200401301649.LAA26817@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-bersani-eap-psk-00.txt Date: Fri, 30 Jan 2004 11:49:57 -0500 Sender: owner-ietf-announce@ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on p2.piuha.net X-Spam-Status: No, hits=-4.2 required=6.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 X-Spam-Level: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The EAP PSK Protocol Author(s) : F. Bersani Filename : draft-bersani-eap-psk-00.txt Pages : 26 Date : 2004-1-29 This document specifies an Extensible Authentication Protocol (EAP) method for authentication and session key distribution using a pre- shared key (PSK). The PSK is used by a unique underlying cryptographic primitive, a block cipher, which is instantiated with AES-128. EAP-PSK performs mutual authentication and session key derivation. It provides identity protection and shall provide fast reconnect in future versions. It provides a secure communication channel within EAP in case the authentication is successful. This secure channel can be used to allow for instance protected result indications. EAP-PSK is intended to be easy to deploy and well-suited for authentication over insecure networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bersani-eap-psk-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-bersani-eap-psk-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-bersani-eap-psk-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <2004-1-30121033.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bersani-eap-psk-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-bersani-eap-psk-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-30121033.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------000406070507090707090108-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Jan 31 14:59:38 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02761 for ; Sat, 31 Jan 2004 14:59:38 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E31B1201FC; Sat, 31 Jan 2004 14:48:10 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A197620218; Sat, 31 Jan 2004 14:48:07 -0500 (EST) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1AB3A20218 for ; Sat, 31 Jan 2004 14:47:49 -0500 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 22DE8201FC for ; Sat, 31 Jan 2004 14:47:47 -0500 (EST) Subject: Re: [eap] network selection From: Alper Yegin To: Cc: "eap@frascone.com" Message-ID: In-Reply-To: <4018BF56.4080809@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 31 Jan 2004 11:59:04 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Jari, >> In PANA we borrowed two terms from the DSL networks, NAP (Network Access >> Provider) and ISP. NAP is the owner/operator of the access infrastructure >> (such as the WLAN AP in the coffee shop). It provides L2 access to the >> clients and connect them to their ISP. ISP should have a business agreement >> with the NAP for this "roaming" service. > > Those are good terms. > >> I think our "ISP" corresponds to your "Access network"? And what is the >> "home network" then? > > Our "access network" is the physical access points and associated NAP, I > think. A practical example would be a specific AP broadcasting on a specific > channel and a specific SSID such as "Starbucks". Our "home network" is where > the client would have its subscription, i.e. the domain part of the user's > NAI. > Does this make it clearer? Can we look at this from routing perspective, and say access networks provide L1-L2 service, home network provides L3 service? I get my IP address from my home network's domain (like the ISP when I connect via a DSL line). > > I'm not exactly sure what the mapping is to PANA ISP, however. PANA ISP > appears > to be a lower layer concept which may or may not have something to do with the > the user's home domain. For instance, you might have two available ISPs in > PANA > but the same NAI might apply to both. In DSL networks: +----- ISP1.com (AAA_server) | PaC ------ NAS (PAA/router/AAA_client) ----+ | +----- ISP2.com (AAA-server) NAS is owned by a NAP. My client (PaC) can have account with both ISP1.com and ISP2.com. It connects to ISP1.com when I login with alper@ISP1.com. > >> If we are talking about general "access network discovery", I think it would >> involve discovering both NAPs and their associated (serviced) ISPs in my >> client's vicinity. I think we are more interested in the latter part of the >> problem. > > This leads me to think that your definition of ISP is closer to what we > have called a "mediating network". I.e. it might not be the "end" domain > in the AAA chain? No, it is. Because this is where I have an account to connect to the Internet. > >> Referring to Figure 2: >> >> In this >> figure, the user "joe@corp3.com" has to be authenticated through ISP >> 2, since the domain "corp3.com" is served by it. >> >> I think another way to read this is "All the employees of corp3.com has an >> account with ISP2 under their name. When they connect to ISP2, their traffic > > This is right. > >> is VPN'ed to the corporate network". Right? > > There may or may not be a VPN service associated with this. If you > don't think about companies but ISPs with a roaming service instead, > you can probably see the non-VPN case: users would just get access > through the local ISP, but their packets would be routed directly to > the Internet. But where do I get the IP address from? If it is from my "home ISP" but the packets are forwarded to the Internet directly via "local ISP", then ingress filtering is an issue. This is why I VPN'ed the packets. > >> There has been requests to place credential and AAA route selection >> under user control, as the user is affected by the pricing and other >> differences. >> >> I don't think this is necessary. I should only care about my ISP selection, >> and be able to trust my ISP to figure out the best AAA route for me (in >> figure 3, isp1.com is aware of both paths). If the access network is trying >> to rip me off, my ISP should be able to catch that. And if my ISP is ripping >> me off, oh well..... > > I think I personally agree. But is your ISP the final home domain or > possibly a roaming partner of the user's home domain? ISP is the final home (from "connecting to the Internet perspective). This is where I get the L3 service from, my IP address and all. (There is another home, like my corporate network, docomolabs-usa.com. If I want to get there while I'm roaming, I use VPN. The ISP that I'm using to connect to the Internet is not the same as the ISP my corporate network is using.) >> The representation of link layer parameters within EAP >> should utilize a common framework, to make it easier to define new >> link layers and keep the selection of EAP methods independent of the >> link layer. >> >> ... >> >> The security requirements for network discovery depend on the type of >> information being discovered. Some of the parameters may have a >> security impact, such as the claimed name of the network the user >> tries to attach to. Unfortunately, current EAP methods do not always >> make the verification of such parameters possible. >> >> I think hosting these functionalities in the EAP lower layer is a better >> approach. > > I agree that security for discovery should be done at the layer discovery > itself is done, i.e., typically at the link layer. > > However, there is an additional issue which the above paragraphs are > trying to address. The problem is that even if the lower layers are > secure by themselves, the information passed in them might be false, > if the access points are lying. Thus, it might be useful to be able > to cryptographically verify that information passed in the lower layer > corresponds to the information passed in the AAA chain. The way to > do this is to exchange at least some important parameters over EAP > as well, and then ensure that the three pieces of information match. I agree. Alper _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap