From jsalowey@cisco.com Mon Aug 3 15:13:14 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28EAD3A6827 for ; Mon, 3 Aug 2009 15:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKnwO8skGIiM for ; Mon, 3 Aug 2009 15:13:13 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 0AA263A68D2 for ; Mon, 3 Aug 2009 15:13:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAI79dkqrR7PD/2dsb2JhbAC7cogpjwgFhBg X-IronPort-AV: E=Sophos;i="4.43,316,1246838400"; d="scan'208";a="181180527" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 03 Aug 2009 22:13:15 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n73MDFqS023875; Mon, 3 Aug 2009 15:13:15 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n73MDFU8029996; Mon, 3 Aug 2009 22:13:15 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 15:13:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Aug 2009 15:13:14 -0700 Message-ID: In-Reply-To: <8556013e0907271457q13581d51s93096777402cc483@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] If we use the Radius property extension Thread-Index: AcoPBT0qdpOtiRbOSoq64SFoIXM0IAFgP1YA References: <8556013e0907270754l5d1d746fvac668e077e0a9144@mail.gmail.com> <8556013e0907271457q13581d51s93096777402cc483@mail.gmail.com> From: "Joseph Salowey (jsalowey)" To: "Richard" , "Dan Harkins" X-OriginalArrivalTime: 03 Aug 2009 22:13:15.0475 (UTC) FILETIME=[99128A30:01CA1487] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6668; t=1249337595; x=1250201595; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Emu]=20If=20we=20use=20the=20Radius=20 property=20extension |Sender:=20; bh=dlJajoNHSuBToXFl965RXSmYarbCenDok1mU7shiISE=; b=Lw5pSifuh8nQEob4chVij6K7kmeede+dP7fOxtl+Mdzcwji2WwjTaeP5Tf Va+FkkWHn3ZUzm9SLVi3b22YvoBI8BAdMlOnlI/m8MzwngiCYSIPjVGXsY4o 9+/EuaBE25; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: emu@ietf.org, dstanley@arubanetworks.com Subject: Re: [Emu] If we use the Radius property extension X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 22:13:14 -0000 =20 > -----Original Message----- > From: Richard [mailto:rishyang@gmail.com]=20 > Sent: Monday, July 27, 2009 2:57 PM > To: Dan Harkins > Cc: Joseph Salowey (jsalowey); emu@ietf.org;=20 > dstanley@arubanetworks.com > Subject: Re: [Emu] If we use the Radius property extension >=20 > Hi, Dan: > =20 > Thanks for your comments. Please check my comments inline=20 > which is identified by [Richard]. >=20 >=20 > 2009/7/28 Dan Harkins >=20 >=20 >=20 > Hi Richard, > =09 > [Dan] On slide 11 you say you want to reuse the AAA=20 > architecture. > But EAP is not a AAA protocol. RADIUS is but you don't want to > use RADIUS. So I don't understand what reuse you're hoping to > take advantage of. >=20 > =20 > ////////////////////////////////////////////////////////////// > //////////// > [Richard] Yes, I want to reuse the AAA architecture. This=20 > is a main objective > and the reason for it is described on the slide 9. For=20 > the reusing, > there are two methods. One is the Radius property=20 > extension and it is a direct > way to reuse the AAA; Another way is to make the WAI over=20 > EAP. As the Radius=20 > has a EAP property, so WAI over EAP establish a bridge to=20 > reuse the AAA.=20 >=20 [Joe] EAP is a protocol to authenticate an EAP Peer that communicates between the EAP Peer and an EAP Server. EAP is not an alternative to a AAA protocol. =20 > =09 > [Dan]Since EAP doesn't have a transport how do you=20 > propose to send > EAP packets from the AP to the server? Over UDP port 3810? The > same port you send WAI packets to now? If that's the case then > all EAP is doing is providing a needless encapsulation of your > WAI packet. You gain nothing by encapsulating your WAI packet > with an EAP header. >=20 > =20 > ////////////////////////////////////////////////////////////// > ////////// >=20 > [ Richard] When using the WAI over EAP, the AP would=20 > transport EAP packet=20 >=20 > (contains WAI) over Radius.=20 >=20 > Also, Please check my last email: It compares the solutions of > the Radius Property extension with the WAI over EAP.=20 > The main advantage of WAI over EAP is to keep the loose coupling > between the AAA and the WAPI. > The reason is: > Radius server need not check things going on with WAPI. (EAP-WAI). > There is a standard interface (EAP-SUCCESS or EAP-FAILURE) > to let Radius know the result of the authentication. > From the AAA server perspective, like the other=20 > authentication methods such as EAP- TLS, there is no any=20 > special handle required for EAP-WAI. > =20 [Joe] EAP-Success and EAP-Failure are not part of RADIUS. They are part of EAP messages that are for the peer, which is the client being authenticated. RADIUS has an Access-Accept and Access-Reject messages for informing the RADIUS client of its decision. Your proposal does not appear to be an authentication mechanism like EAP-TLS since it does not communicate with the peer. =20 Can you give an example of what you mean by loose coupling between AAA and WAPI? =20 > [Dan] I do have a suggestion to fix this problem. Just get=20 > rid of the "certificate authentication" exchange and have the=20 > client validate the AP's certificate and the AP validate the=20 > client's certificate. > It is not necessary to have a central authority to approve of=20 > certificates, that's the whole point in using certificates. > /////////////////////////////////////////////////////////////////// > [ Richard] Yes, your suggestion could work well without a a=20 > central authority involved. > While the current problem I try to resolve is: The WAPI=20 > protocol already exist (it needs a central authority to=20 > valide the certificate), to support (follow) it and enable it=20 > work well under the AAA architecture, I brougt forward the=20 > method of WAI over EAP.=20 > To avoid the change of the station, and minimize the influnce=20 > to the customers, the solution would only change the packet=20 > between AP (authenticator) and AAA server. > To achieve this objective and avoid the influnce to the AAA,=20 > the AP should minic the station. > For the WAPI protocol, please see the slide 7. >=20 [Joe] This is not the way EAP works currently. EAP is a protocol that involves the peer. If you have the authenticator mimic the peer then it is not EAP in its current form.=20 >=20 > =09 > =09 > regards, > =09 > Dan. > =09 >=20 > On Mon, July 27, 2009 7:54 am, Richard wrote: > > Hi, all: > > > > The link to the slide: > > http://www.ietf.org/proceedings/75/slides/emu-10.ppt > > Thanks for your comments in the EMU session. > > > > Yes, the Radius property extension could be one solution. > > The problem to it is: > > The Radius has to handle the WAPI packet (Certificate=20 > authentication > > response), > > it would lead to the tight coupling between Radius=20 > and WAPI (ASE). > > > > Compared to it, the EAP solution is simple and make=20 > it loose coupling with > > WAPI. > > Radius server need not check things going on with=20 > WAPI. (EAP-WAI). > > There is a standard interface to let Radius to know the result > > of authentication (EAP-SUCCESS or EAP-FAILURE). > > From the AAA server perspective, there is no any=20 > special for EAP-WAI > > to the other authentication methods such as EAP-TLS. > > The loose coupling for EAP solution is a main=20 > advantage to the Radius > > extension > > method. > > > > Yes, the EAP framework is to authenticate the station=20 > (supplicant). I > > guess > > the > > main reason is that most authentication methods are=20 > to authenticate the > > supplicant, > > and the behavior of Authenticator is pass-through. > > Now, WAPI is a use case of authenticating the=20 > authenticator (the behavior > > of > > Authenticator > > is not Pass-through). And it may have more protocols=20 > which have similar > > behavior > > (use cases) like the WAPI. > > Could we allow the EAP method behavior like the WAI=20 > over EAP instead of > > forbidding it? > > > > Any way, the problem I am trying to resolve is to=20 > reuse the AAA and > > avoid the tight coupling between Radius and WAPI (ASE). > > > > Do you have any better solution to it? > > > > Regards > > Richard > =09 > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu > > > =09 > =09 > =09 >=20 >=20 >=20 From madjid.nakhjiri@motorola.com Mon Aug 3 15:50:23 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C4F93A6AA4 for ; Mon, 3 Aug 2009 15:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyX0l5CVTTGs for ; Mon, 3 Aug 2009 15:50:22 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 8F8223A69C2 for ; Mon, 3 Aug 2009 15:50:22 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: madjid.nakhjiri@motorola.com X-Msg-Ref: server-12.tower-55.messagelabs.com!1249339822!93294198!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [136.182.1.12] Received: (qmail 32728 invoked from network); 3 Aug 2009 22:50:22 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (136.182.1.12) by server-12.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Aug 2009 22:50:22 -0000 Received: from il27exr04.cig.mot.com (il27exr04.mot.com [10.17.196.73]) by motgate2.mot.com (8.14.3/8.14.3) with ESMTP id n73MoL9H005345 for ; Mon, 3 Aug 2009 15:50:22 -0700 (MST) Received: from il27vts01 (il27vts01.cig.mot.com [10.17.196.85]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id n73MoLXA001674 for ; Mon, 3 Aug 2009 17:50:21 -0500 (CDT) Received: from ct11exm63.ds.mot.com (ct11exm63.am.mot.com [10.177.8.47]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id n73MoLL6001669 for ; Mon, 3 Aug 2009 17:50:21 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA148C.BB1B5447" Date: Mon, 3 Aug 2009 18:50:00 -0400 Message-ID: <13E2E485D9AA7240A1C55B0B464198B202F6AFCF@ct11exm63.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EAP-TLS EMSK exposure thread-index: AcoUjLsAFiX16qQUQS2Ieo3HQV4BBQ== From: "Nakhjiri Madjid-VXT746" To: X-CFilter-Loop: Reflected X-Mailman-Approved-At: Mon, 03 Aug 2009 16:05:46 -0700 Cc: Nakhjiri Madjid-VXT746 , rmh@microsoft.com Subject: [Emu] EAP-TLS EMSK exposure X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 22:50:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA148C.BB1B5447 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,=20 =20 I would appreciate if you could forward this question to the list. =20 I have a question regarding EAP-TLS. I am trying to understand if it is possible for an attacker to extract the EMSK from EAP peer memory (if not protected) and plant it inside another EAP peer and establish new child keys for the new peer. I guess sessionID is a measure against this, but I did not see anything in RFC 5216 that says the EAP server checks for uniqueness of sessionIDs across clients. It only says, if it finds the sessionID, it resumes the session and if it does not it tries to start a new session, so I guess if the attacker extracted both EMSK and sessionID, the attack would be possible, no? =20 The other related question is what needs to happen before session resumption? Is there a state between initially authenticated active session and the resumed one? Does the EAP session go dormant? The reason I ask, is whether the server keeps track of active sessionIDs or dormant sessionIDs? Can two peers use the same sessionID at the same time? =20 thanks, Madjid =20 ------_=_NextPart_001_01CA148C.BB1B5447 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,=20
 
I = would appreciate=20 if you could forward this question to the list.
 
I have = a question=20 regarding EAP-TLS. I am trying to understand if it is possible for an = attacker=20 to extract the EMSK from EAP peer memory (if not protected) and plant it = inside=20 another EAP peer and establish new child keys for the new=20 peer.
I = guess sessionID is=20 a measure against this, but I did not see anything in RFC 5216 that says = the EAP=20 server checks for uniqueness of sessionIDs across clients. It only says, = if it=20 finds the sessionID, it resumes the session and if it does not it tries = to start=20 a new session, so I guess if the attacker extracted both EMSK and = sessionID, the=20 attack would be possible, no?
 
The = other related=20 question is what needs to happen before session resumption? Is = there a=20 state between initially authenticated active session and the resumed = one? Does=20 the EAP session go dormant? The reason I ask, is whether the server = keeps track=20 of active sessionIDs or dormant sessionIDs?
Can two peers use the same sessionID at the same = time?
 
thanks,
Madjid  
------_=_NextPart_001_01CA148C.BB1B5447-- From jsalowey@cisco.com Mon Aug 3 16:23:00 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C5C53A6806 for ; Mon, 3 Aug 2009 16:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QDZMKvVvy+3 for ; Mon, 3 Aug 2009 16:22:59 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 159BD3A6AD8 for ; Mon, 3 Aug 2009 16:22:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPgNd0qrR7PD/2dsb2JhbAC8PYgpjw8FhBg X-IronPort-AV: E=Sophos;i="4.43,317,1246838400"; d="scan'208";a="181193263" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 03 Aug 2009 23:23:01 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n73NN116032497; Mon, 3 Aug 2009 16:23:01 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n73NN1Vb004319; Mon, 3 Aug 2009 23:23:01 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 16:23:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Aug 2009 16:23:00 -0700 Message-ID: In-Reply-To: <8556013e0907270754l5d1d746fvac668e077e0a9144@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: If we use the Radius property extension Thread-Index: AcoOyhtgBBsubB9tRMeTbnmuiF0djgFvZzsA References: <8556013e0907270754l5d1d746fvac668e077e0a9144@mail.gmail.com> From: "Joseph Salowey (jsalowey)" To: "Richard" , X-OriginalArrivalTime: 03 Aug 2009 23:23:01.0384 (UTC) FILETIME=[58119080:01CA1491] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2828; t=1249341781; x=1250205781; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20If=20we=20use=20the=20Radius=20property =20extension |Sender:=20; bh=r8DiKcXkaJh6BDuObABAL+0y3T9qapIQiOwe3zm7VUE=; b=u4BCzI+2M6BY17NjL5LHym8RvQas4G6hblcdEzczCmOKvrGH8L7GUYNn5w lNbQSThfb9utTVE8uAOSs1R8r4yAT3EpYGbz0c+0nSBg6nsxMd22MngRBoXg u86L2c1Psn; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Emu] If we use the Radius property extension X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 23:23:00 -0000 =20 > -----Original Message----- > From: Richard [mailto:rishyang@gmail.com]=20 > Sent: Monday, July 27, 2009 7:54 AM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: If we use the Radius property extension >=20 > Hi, all: > =20 > The link to the slide: > http://www.ietf.org/proceedings/75/slides/emu-10.ppt > Thanks for your comments in the EMU session. > =20 > Yes, the Radius property extension could be one solution. > The problem to it is: > The Radius has to handle the WAPI packet (Certificate=20 > authentication response), it would lead to the tight coupling=20 > between Radius and WAPI (ASE). > =20 > Compared to it, the EAP solution is simple and make it loose=20 > coupling with WAPI. > Radius server need not check things going on with WAPI. (EAP-WAI).=20 > There is a standard interface to let Radius to know the=20 > result of authentication (EAP-SUCCESS or EAP-FAILURE). > From the AAA server perspective, there is no any special for=20 > EAP-WAI to the other authentication methods such as EAP-TLS. > The loose coupling for EAP solution is a main advantage to=20 > the Radius extension method.=20 >=20 [Joe] EAP-Success and EAP-Failure are for the Peer and not the RADIUS client. The RADIUS access-accept and access-reject are for the RADIUS client. =20 =20 > Yes, the EAP framework is to authenticate the station=20 > (supplicant). I guess the main reason is that most=20 > authentication methods are to authenticate the supplicant,=20 > and the behavior of Authenticator is pass-through. [Joe] Correct. > Now, WAPI is a use case of authenticating the authenticator=20 > (the behavior of Authenticator is not Pass-through). And it=20 > may have more protocols which have similar behavior (use=20 > cases) like the WAPI.=20 [Joe] When the authenticator does not run in pass-through then the EAP communication is only between the Peer and EAP-Authenticator, EAP is not communicated to the AAA. =20 > Could we allow the EAP method behavior like the WAI over EAP=20 > instead of forbidding it? > =20 [Joe] Not without changing the EAP architecture. =20 > Any way, the problem I am trying to resolve is to reuse the=20 > AAA and avoid the tight coupling between Radius and WAPI (ASE). > =20 > Do you have any better solution to it? > =20 [Joe] You need to have a AAA server talk to a WAI service. You need to define some protocol or API to do this. You would like EAP to be this protocol, but this is not the appropriate use for EAP as it is bound to the communication between the EAP peer and EAP authenticator. You can define a separate protocol that includes messages that indicates success or fail clearly. This protocol can be incorporated into RADIUS attributes just as EAP can. =20 > Regards > Richard >=20 From jsalowey@cisco.com Wed Aug 5 13:20:09 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39DF73A6880 for ; Wed, 5 Aug 2009 13:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r36DXLvGLQvq for ; Wed, 5 Aug 2009 13:20:08 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E7EC93A71CD for ; Wed, 5 Aug 2009 13:18:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAE6GeUqrR7MV/2dsb2JhbAC9FIgpkGoFhBg X-IronPort-AV: E=Sophos;i="4.43,330,1246838400"; d="scan'208";a="223963939" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 05 Aug 2009 20:18:43 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n75KIhN5025738 for ; Wed, 5 Aug 2009 13:18:43 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n75KIh2W014805 for ; Wed, 5 Aug 2009 20:18:43 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 13:18:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Aug 2009 13:18:40 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 6: RFC 2119 Language Thread-Index: AcoWCewsIzPjLF1NSam5IC6nhNYLAA== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 05 Aug 2009 20:18:43.0103 (UTC) FILETIME=[EDA54AF0:01CA1609] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1681; t=1249503523; x=1250367523; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Issue=206=3A=20RFC=202119=20Language |Sender:=20; bh=jyCUZBrevZbTCXPpnBtPEs37Z4O1dMzfHog1FIzLGkk=; b=XHco3bRQEend1cKEvrzrgZP8nuLEXhvqmB62CTVWkdENJmUAVmcgBOAPmS plpRwCVzskAeraHkz7w42mU+QN+Q+pq7t9U2rK7m3UEo0pZkZZhcjw7+0lRx r5EujUxKTTJAUuvNW458cXBnaWI86Xhz8WPNDOQqStAyhZlwI/3IY=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Emu] Issue 6: RFC 2119 Language X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 20:20:09 -0000 Description: Section 2 " Because this specification is an informational specification (not able to directly use [RFC2119])," Since a large number of Informational RFCs reference RFC 2119 and use normative language, this statement seems odd. Perhaps what it is trying to say is that the terms don't mean the same thing in this document as they do in RFC 2119? If that is the case, language such as that from RFC 2989 Section 1.1 might make sense:=20 Please note that the requirements specified in this document are to be used in evaluating protocol submissions. As such, the requirements language refers to capabilities of these protocols; the protocol documents will specify whether these features are required, recommended, or optional. For example, requiring that a protocol support confidentiality is NOT the same thing as requiring that all protocol traffic be encrypted. A protocol submission is not compliant if it fails to satisfy one or more of the MUST or MUST NOT requirements for the capabilities that it implements. A protocol submission that satisfies all the MUST, MUST NOT, SHOULD and SHOULD NOT requirements for its capabilities is said to be "unconditionally compliant"; one that satisfies all the MUST and MUST NOT requirements but not all the SHOULD or SHOULD NOT requirements for its protocols is said to be "conditionally compliant."=20 As it is, the MUST, MUST NOT, SHOULD, SHOULD NOT, etc. definitions are confusing.=20 Proposed Resolution: Currently we use the same text as in RFC 5209 (NEA requirements). I think we can remove the first sentence in the paragraph, which is not in RFC 5209, to remove the confusion.=20 From jsalowey@cisco.com Wed Aug 5 13:25:19 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C0A63A6969 for ; Wed, 5 Aug 2009 13:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39XZj--Gmrz7 for ; Wed, 5 Aug 2009 13:25:18 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 30F063A71DD for ; Wed, 5 Aug 2009 13:25:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAImHeUqrR7PE/2dsb2JhbAC9EIgpNgMEkC0FglCBSA X-IronPort-AV: E=Sophos;i="4.43,330,1246838400"; d="scan'208";a="223967715" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 05 Aug 2009 20:25:21 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n75KPLcZ004377 for ; Wed, 5 Aug 2009 13:25:21 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n75KPF6M029133 for ; Wed, 5 Aug 2009 20:25:21 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 13:25:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Aug 2009 13:25:17 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #7: Password Authentication Thread-Index: AcoWCm3yKXUv47QGTd6cvMRwt5d3SwAAFWyw From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 05 Aug 2009 20:25:19.0351 (UTC) FILETIME=[D9D3F070:01CA160A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1827; t=1249503921; x=1250367921; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Issue=20#7=3A=20Password=20Authentication |Sender:=20; bh=/DVMvaMHP/S4cPRdD6Fm4RuTLiL+8j5o4pqwUjP7UdQ=; b=EdH0SZJb99MXX/Dru+SmRMRcqaF9qVsgMUwfKqkupJIOAL22Au82K2HV+1 QqwnqApsPf0zRP7ArSAGl7eJ9XYu6EzrCj8tSPTO9lkcILEqsD0opXSaX6bN HgjnyKkJJE; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Emu] Issue #7: Password Authentication X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 20:25:19 -0000 =20 #7: Password Authentication > Section 3.1 Password Authentication > > " Many legacy systems only support user authentication with > passwords. > Some of these systems require transport of the actual username and > password to the authentication server. The tunnel method > MUST support > this use case." > > As currently worded, this statement is somewhat vague. > Is this statement implying that a tunnel method must support > password-only authentication (e.g. no certificates)? If so, > is there a requiremnent to support weak passwords or just > pre-shared keys? [Joe] Perhaps this can be clarified by saying: "The tunnel method MUST support transporting username and password to the authentication server." > Would a tunnel method utilizing a server certificate to > create a tunnel, and doing password authentication within the > tunnel meet this requirement? What about a tunnel method > utilizing a pre-shared key ciphersuite? > [Joe] If the tunnel method can transport the username and password to the authentication server securely it would meet the requirement, however if you already have a pre-shared key that is sufficient to establish the tunnel it is not clear why you would need to do password authentication. > " However, it MUST NOT expose the username and password to parties in > the communication path between the peer and the EAP Server and it > MUST provide protection against man-in-the-middle and dictionary > attacks." > > Does this requirement apply to provisioning or just to > ongoing password authentication? > [Joe] This section is talking about ongoing password authentication. -- Ticket URL: emu From dharkins@lounge.org Wed Aug 5 13:30:07 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E64A28C499 for ; Wed, 5 Aug 2009 13:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.006 X-Spam-Level: X-Spam-Status: No, score=-6.006 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5LTUYdQ6t2r for ; Wed, 5 Aug 2009 13:30:06 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id ACF1D28C653 for ; Wed, 5 Aug 2009 13:29:38 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 8A32EA888108; Wed, 5 Aug 2009 13:29:41 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 5 Aug 2009 13:29:41 -0700 (PDT) Message-ID: <3fdd59d6b44f49b0f9899d42590370e5.squirrel@www.trepanning.net> In-Reply-To: References: Date: Wed, 5 Aug 2009 13:29:41 -0700 (PDT) From: "Dan Harkins" To: "Joseph Salowey (jsalowey)" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: emu@ietf.org Subject: Re: [Emu] Issue #7: Password Authentication X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 20:30:07 -0000 Hello, Perhaps it would be a good idea to mandate that the method used to authenticate the tunnel (outer method, whatever you want to call it) MUST NOT be susceptible to a dictionary attack if it is going to be used to transport a username and plaintext password to the authentication server. regards, Dan. On Wed, August 5, 2009 1:25 pm, Joseph Salowey (jsalowey) wrote: > > #7: Password Authentication > > > Section 3.1 Password Authentication > > > > " Many legacy systems only support user authentication with > > passwords. > > Some of these systems require transport of the actual username and > > password to the authentication server. The tunnel method > > MUST support > > this use case." > > > > As currently worded, this statement is somewhat vague. > > Is this statement implying that a tunnel method must support > > password-only authentication (e.g. no certificates)? If so, > is there > a requiremnent to support weak passwords or just > pre-shared keys? > > [Joe] Perhaps this can be clarified by saying: > > "The tunnel method MUST support transporting username and password to > the authentication server." > > > Would a tunnel method utilizing a server certificate to > create a > tunnel, and doing password authentication within the > tunnel meet this > requirement? What about a tunnel method > utilizing a pre-shared key > ciphersuite? > > > [Joe] If the tunnel method can transport the username and password to > the authentication server securely it would meet the requirement, > however if you already have a pre-shared key that is sufficient to > establish the tunnel it is not clear why you would need to do password > authentication. > > > " However, it MUST NOT expose the username and password to parties > in > > the communication path between the peer and the EAP Server and it > > MUST provide protection against man-in-the-middle and dictionary > > attacks." > > > > Does this requirement apply to provisioning or just to > ongoing > password authentication? > > > [Joe] This section is talking about ongoing password authentication. > > -- > Ticket URL: > emu > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > From jsalowey@cisco.com Wed Aug 5 15:01:02 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DFF63A6880 for ; Wed, 5 Aug 2009 15:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.568 X-Spam-Level: X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNKJ+BUWvL5O for ; Wed, 5 Aug 2009 15:01:01 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 18FBE3A6C0A for ; Wed, 5 Aug 2009 15:01:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHOeeUqrR7O6/2dsb2JhbAC8WIgpkF0FhBg X-IronPort-AV: E=Sophos;i="4.43,331,1246838400"; d="scan'208";a="361283433" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 05 Aug 2009 22:01:04 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n75M13Ua007399 for ; Wed, 5 Aug 2009 15:01:03 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n75M13Sm005217 for ; Wed, 5 Aug 2009 22:01:03 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 15:01:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Aug 2009 15:01:02 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #8: Cryptographic Binding Text Thread-Index: AcoWGBWY2Bl8BqPIT1mDEYfcAshHDQAAA4aw From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 05 Aug 2009 22:01:03.0765 (UTC) FILETIME=[39C3F450:01CA1618] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1351; t=1249509663; x=1250373663; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Issue=20#8=3A=20Cryptographic=20Binding=20Text |Sender:=20; bh=mtzO5q0w3vRZkeDM8VFgDewr0PG4fLSHqmx+LEt6umk=; b=oXB0KISFX7vB5cPANPENXJIThjQHMLvN6XqasaE135ojbY/JOzQfcmtt+x LAcqzACUfowz5R48KbQQspt/BzjfwCG9r+tw0LuZNYQnWSq+ObVmjFnFBPYQ JlpbUvHRiG; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Emu] Issue #8: Cryptographic Binding Text X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 22:01:02 -0000 #8: Cryptographic Binding Text > Section 3.2 > > " In > particular, when weak methods are used, security policies enforcing > that such methods can only be executed inside a tunnel but never > outside one are required to mitigate the attack." > > The requirement that methods only be executed within a tunnel > is necessary > even for strong methods, if crypto-binding isn't used. > > " On the other hand, > a technical solution (so-called cryptographic bindings) can be used > whenever the inner method is not susceptible to attacks outside a > tunnel and derives keying material." > > Cryptographic binding can be used whenever the inner method > generates keys. If this isn't used, then even methods not > susceptible to attack outside the tunnel should be prohibited > from use outside the tunnel, or else MiTM attacks would still > be feasible. > How about changing the last paragraph to: "The tunnel method MUST support protection of weak EAP methods. Cryptographic protection from tunnel MitM attacks MUST be provided for all key generating methods. In combination with an appropriate security policy this will thwart MitM attacks against inner methods." -- Ticket URL: emu From jsalowey@cisco.com Wed Aug 5 15:25:02 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03D7C3A6BC4 for ; Wed, 5 Aug 2009 15:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJvpJKIXXpYD for ; Wed, 5 Aug 2009 15:25:01 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 3959E28C655 for ; Wed, 5 Aug 2009 15:24:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANajeUqrR7PD/2dsb2JhbAC8NogpNgeQIwWCMoFm X-IronPort-AV: E=Sophos;i="4.43,331,1246838400"; d="scan'208";a="192924407" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 05 Aug 2009 22:25:02 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n75MP26Y013344 for ; Wed, 5 Aug 2009 15:25:02 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n75MP25f001972 for ; Wed, 5 Aug 2009 22:25:02 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 15:25:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Aug 2009 15:25:00 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #9: Peer Identity Protection Thread-Index: AcoWGzCkdllDTEKZRquuFF2DYtMMHQAAE3sg From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 05 Aug 2009 22:25:02.0099 (UTC) FILETIME=[93144E30:01CA161B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1962; t=1249511102; x=1250375102; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Issue=20#9=3A=20Peer=20Identity=20Protection |Sender:=20; bh=Gtvoefv0vAgmrqM41QikyymmpNtbmvKFjNDOLQWo+94=; b=vhFdcZvJCfc7Ycm7kfnfiFpEdQ4rhR0874EbqJdzM8+dpV19AzK0PFl2oa numi+K5FEKk2cR1JuKvN3fplQY2vPO8owviENv+5hCClTcwaIfIVBlPzC4AO y3lDJ2ucB0; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Emu] Issue #9: Peer Identity Protection X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 22:25:02 -0000 #9: Peer Identity Protection > Section 3.4 > > " When performing an EAP authentication, the peer may want to protect > its identity, only disclosing its identity to a trusted backend > authentication server. This helps to maintain the privacy of the > peer's identity." > > Within tunneled authentication, there are a number of > identities involved. This includes the identity included in > the EAP-Request/Identity, identities used in TLS (subject and > subjectAltName fields), and identities used in the inner EAP > method. To which identities does this requirement apply? > Add "Peer identity protection provided by the tunnel method applies to tunnel methods and inner method specific identities." > Section 4.2.1.4 > > " A tunnel protocol MUST support peer privacy. This > requires that the > username and other attributes associated with the peer are not > transmitted in the clear or to an unauthenticated, unauthorized > party. If applicable, the peer certificate is sent confidentially > (i.e. encrypted)." > > Does a username of "anonymous" need to be encrypted? Or does > this requirement only apply to the tunnel method-specific > identities? add "Peer identity protection provided by the tunnel method applies to tunnel methods and inner method specific identities." > Is there an issue with transmission of dientities to > authenticated and authorized parties (e.g. the NAS)? In some > regulatory jurisdictions this is also a concern. > [Joe] I don't think so. Either the NAS is authorized to receive the name or it isn't. If it terminates the tunnel then the tunnel method will authenticate it so it can be authorized. If it is outside the tunnel then it is out of scope of the method. -- --=20 Ticket URL: emu From jsalowey@cisco.com Wed Aug 5 15:32:16 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C16A83A6BC4 for ; Wed, 5 Aug 2009 15:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.571 X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuivPh94lHVU for ; Wed, 5 Aug 2009 15:32:16 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id EA2733A68F8 for ; Wed, 5 Aug 2009 15:32:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHuleUqrR7O6/2dsb2JhbAC8TYgpkGAFgjeBYQ X-IronPort-AV: E=Sophos;i="4.43,331,1246838400"; d="scan'208";a="361299476" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 05 Aug 2009 22:32:19 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n75MWJxL025593 for ; Wed, 5 Aug 2009 15:32:19 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n75MWJTh011494 for ; Wed, 5 Aug 2009 22:32:19 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 15:32:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Aug 2009 15:32:17 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #10: Emergency Services Thread-Index: AcoWHGOmce1vQMzKTrKVbSXkpVtBMgAAA6Dw From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 05 Aug 2009 22:32:18.0878 (UTC) FILETIME=[976B7DE0:01CA161C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=897; t=1249511539; x=1250375539; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Issue=20#10=3A=20Emergency=20Services |Sender:=20; bh=6hQ7DzA/fcTAO27gfUZ4Vxh+q/JkoKQHt2mwpWq1BNg=; b=w+HLObRrj/4PvAmRrhpNrQgzTaqMw54esmvapOgbl145t+bQa2dwGqlKy4 lJdIb2MJYfE1/MqVLNbji5XBcCkKqwwoRAl+8ECfLrSUa3jAawge5oAnLYUA 8PfnTAcpYg; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Emu] Issue #10: Emergency Services X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 22:32:16 -0000 #10: Emergency Services > Section 3.5 > > " When wireless VOIP service is provided, some regulations =20 > require any > user to be able to gain access to the network to make an emergency > telephone call." > > Which regulations are being referred to? In a number of =20 > places, support for anonymous authentication is actually =20 > being removed, not added: > http://www.ietf.org/mail-archive/web/ecrit/current/msg06378.html > OK, lets remove the part about the regulations, how about: "When network service is provided, it is sometimes desirable for any user to be able to gain access to the network to enable emergency communication. To avoid eavesdropping, it's best to negotiate link layer security as with any other authentication." -- Ticket URL: emu From jsalowey@cisco.com Wed Aug 5 15:50:50 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F1DE3A6C4E for ; Wed, 5 Aug 2009 15:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJ3r1PgG0SIf for ; Wed, 5 Aug 2009 15:50:49 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4D6A23A699C for ; Wed, 5 Aug 2009 15:50:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAO+peUqrR7O6/2dsb2JhbAC8J4gpkGAFhBg X-IronPort-AV: E=Sophos;i="4.43,331,1246838400"; d="scan'208";a="361308678" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 05 Aug 2009 22:50:52 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n75Moqgu018372 for ; Wed, 5 Aug 2009 15:50:52 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n75Moquw019788 for ; Wed, 5 Aug 2009 22:50:52 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 15:50:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Aug 2009 15:50:46 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #11: TLS version Thread-Index: AcoWHvehbMbFkpSURRu4ead/0fxenAAACOGg From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 05 Aug 2009 22:50:52.0241 (UTC) FILETIME=[2F093410:01CA161F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=989; t=1249512652; x=1250376652; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Issue=20#11=3A=20TLS=20version |Sender:=20; bh=bDapOp/kaZlgf+hvOx2xRE7Vh2cmgpw1AI49t+TYn8w=; b=V+J2gQiI54iwHOJxtEAFDmFDbtTsfwJL/XwQ4feSCe5mmN5QMpbO2yLrlj Ug/e13eRPJiuVTLs4yhqhz6CT6xycMq231FU7s9w2xbeRjyGyujes9x6Hftt hdqACDKGAt; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Emu] Issue #11: TLS version X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 22:50:50 -0000 #11: TLS version > Section 4.2.1 > > " The tunnel based method MUST support TLS version 1.2 [RFC5246] and > SHOULD support TLS version 1.0 [RFC2246] and version 1.1 > [RFC4346] to > enable the possibility of backwards compatibility with existing > deployments." > > I am not sure how to interpret this requirement. Is it > sufficient for a proposal to enable negotiation of TLS 1.2 > between a peer and server that support it? Or does the > protocol actually have to require that both the peer and > server implement TLS 1.2? If the former, is the requirement > really just properly supporting TLS version negotiation? > I interpret the requirement to mean the latter. Would this be clearer: "The tunnel based method MUST implement TLS version 1.2 [RFC5246] and may support earlier versions for backward compatibility." --=20 Ticket URL: emu From jsalowey@cisco.com Wed Aug 5 16:02:34 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45A0D3A6ADC for ; Wed, 5 Aug 2009 16:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RW-Ocbg3cHKN for ; Wed, 5 Aug 2009 16:02:30 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id DDC1F3A6988 for ; Wed, 5 Aug 2009 16:02:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEeseUqrR7PD/2dsb2JhbAC8C4gpkF4FhBg X-IronPort-AV: E=Sophos;i="4.43,331,1246838400"; d="scan'208";a="88823638" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 05 Aug 2009 23:02:33 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n75N2Xfi001922 for ; Wed, 5 Aug 2009 16:02:33 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n75N2XMP012140 for ; Wed, 5 Aug 2009 23:02:33 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 16:02:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Aug 2009 16:02:31 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #12: TLS Extensions Thread-Index: AcoWIAfIJTpXdmeWRBuCEuMb5cMi9wAABX6g From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 05 Aug 2009 23:02:33.0745 (UTC) FILETIME=[D12A3810:01CA1620] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=749; t=1249513353; x=1250377353; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Issue=20#12=3A=20TLS=20Extensions |Sender:=20; bh=A5wKNb4lC4BlGWUNYjf2xL35MToQi2vIEKPaePzyCi8=; b=kUhYIWRhvk8GXt5tHmkhb8wLDQ1d7h2y6OGrVF6RYry5ZwUjCf20nWF8es 4xLjRVbZ0nserszsk1irWiA1hBLq4n8+y1tItvTGWiGu+/7+MIMqUKxTq/e2 mLZz64xeqK; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Emu] Issue #12: TLS Extensions X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 23:02:34 -0000 #12: TLS Extensions > Section 4.2.1.3 > > " In order to meet the requirements in this document TLS > extensions MAY > be used. For example, TLS extensions may be useful in providing > certificate revocation information via the TLS OCSP extension (thus > meeting the requirement in Section 4.5.1.3)." > > Why is it necessary to include optional requirements in this document? > Presumably the selection will only be influenced by MUST and > SHOULD requirements, right? > This section is just stating that it is acceptable to use TLS extensions to meet requirements. I don't see a problem here. --=20 Ticket URL: emu From jsalowey@cisco.com Wed Aug 5 16:15:13 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F6AB3A687E for ; Wed, 5 Aug 2009 16:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyShyF81X2kk for ; Wed, 5 Aug 2009 16:15:12 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 2EB1F28C510 for ; Wed, 5 Aug 2009 16:14:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMuveUqrR7PD/2dsb2JhbAC7dYgpkFsFhBg X-IronPort-AV: E=Sophos;i="4.43,331,1246838400"; d="scan'208";a="88826898" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 05 Aug 2009 23:14:58 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n75NExxH018174 for ; Wed, 5 Aug 2009 16:14:59 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n75NExAQ012934 for ; Wed, 5 Aug 2009 23:14:59 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 16:14:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Aug 2009 16:14:57 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #13: Protection of Data Outside Tunnel Thread-Index: AcoWIjwhUDr5mNBIR7iopZw0OHEbhwAAC3lw From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 05 Aug 2009 23:14:58.0853 (UTC) FILETIME=[8D48AD50:01CA1622] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1676; t=1249514099; x=1250378099; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Issue=20#13=3A=20Protection=20of=20Data=20Outsi de=20Tunnel |Sender:=20; bh=9J3MEuAP30Ui6bVp1EDkqh2dGBqc0q12d0U3GgdRLGI=; b=EaFISUpEPhfOlCLymP/SlVFVilExu5ljLPWOHuScVM0xYBnqQKpL2Hgp/k b6MTsMN6O8mzxOEQg3XRSY77KAO7RwBbj9/EzN8xVSNprkYDdEOf0gElgA1r bwGWF4SXPp; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Emu] Issue #13: Protection of Data Outside Tunnel X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 23:15:13 -0000 #13: Protection of Data Outside Tunnel > Section 4.2.3 > > "If modification of this information can cause > vulnerabilities, the tunnel method MUST provide protection against > modification of this data." > > This seems a bit vague. Why not just require secure > confirmation of the protocol version and/or type code, either > implicitly or explicitly? > This is vague because a tunnel method may include other data outside the tunnel. How about adding: "The tunnel method MUST provide implicit or explicit confirmation of the protocol version and type code." > Section 6.3 > > " The tunnel method will use data that is outside the TLS tunnel such > as the EAP type code or version numbers. If an attacker can > compromise the protocol by modifying these values the tunnel method > MUST protect this data from modification." > > Why is it necessary to protect the data from modification in > order to address the attacks? For example, if the key > derivation is unique to an EAP type, then modifying the type > would cause proof of key possession to fail. Wouldn't this > be sufficient? Yes, the text says if an attacker can compromise the method by modifying the data. In the example you cite as long as you are sure the proof of possession will fail then the EAP type does not need additional protection. We could add a sentence: "In some cases external data may not need additional protection because it is implicitly verified during the protocol operation." --=20 Ticket URL: emu From jsalowey@cisco.com Thu Aug 6 12:15:03 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BDB33A6D0D for ; Thu, 6 Aug 2009 12:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LONZdru--e28 for ; Thu, 6 Aug 2009 12:15:02 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 970A73A6E53 for ; Thu, 6 Aug 2009 12:13:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABzIekqrR7O6/2dsb2JhbAC4dIgqkCAFgjeBYQ X-IronPort-AV: E=Sophos;i="4.43,335,1246838400"; d="scan'208";a="362003479" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 06 Aug 2009 19:14:00 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n76JE06N005738 for ; Thu, 6 Aug 2009 12:14:00 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n76JE0hA026552 for ; Thu, 6 Aug 2009 19:14:00 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 12:14:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Aug 2009 12:13:59 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #14 Emergency auth Thread-Index: AcoWygz7SUqy1ZFxRmuwSIaYjBW3YQ== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 06 Aug 2009 19:14:00.0413 (UTC) FILETIME=[0DCB90D0:01CA16CA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=910; t=1249586040; x=1250450040; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Issue=20#14=20Emergency=20auth |Sender:=20; bh=lQdqb6mdWfdeYHV668eGrfti/GwLJpRDlOCEw6DRx0A=; b=EaKxju4PbIVLT+2QfjVOXSi41Wk4oHdIgqTosP2m8l4auxBfsfqUYjLPya LPEMbkJ4rTvlIAkTTOGTm6rFrQ/7YZi29GxaWAvLN7rjgjfJMO1yDTznpikS S9VE0/LN6M; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Emu] Issue #14 Emergency auth X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 19:15:03 -0000 > Referring to Sec. 3.5 of http://tools.ietf.org/html/draft-ietf-emu-eaptunnel-req-03, there should be an indication to the application that is using EAP > that such "strange" authentication took place. For example, the VoIP server may than make sure that only calls to 911 or 112 are allowed. Otherwise=20 > there is no way to authorize the user without some backchannel into the AAA. > > So I propose to add: > "The tunnel method, if it supports emergency services, MUST provide an indication at the EAP or EAP-method level that such authentication took place; > =20 > the indication MUST be unencrypted but integrity protected". I don't understand what this text is for? Who is this indication for? An application should not be sniffing EAP packets to see what happens. It seems that this is the responsibility of a local API between the EAP server and the application. =20 Joe From jsalowey@cisco.com Thu Aug 6 12:15:46 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD2B23A6DB6 for ; Thu, 6 Aug 2009 12:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XectzEG+ibt for ; Thu, 6 Aug 2009 12:15:46 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 290293A6D0D for ; Thu, 6 Aug 2009 12:15:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAM7IekqrR7MV/2dsb2JhbAC4Z4gqkCAFhBg X-IronPort-AV: E=Sophos;i="4.43,335,1246838400"; d="scan'208";a="193278145" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 06 Aug 2009 19:15:48 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n76JFm0g025919 for ; Thu, 6 Aug 2009 12:15:48 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n76JFmNk003515 for ; Thu, 6 Aug 2009 19:15:48 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 12:15:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Aug 2009 12:15:47 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #15: Algorithm agility and certs Thread-Index: AcoWxmERgUoSkKTXSIaLQkc/rqy6NgAA7MTg From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 06 Aug 2009 19:15:48.0077 (UTC) FILETIME=[4DF7C9D0:01CA16CA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=750; t=1249586148; x=1250450148; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Issue=20#15=3A=20Algorithm=20agility=20and=20ce rts |Sender:=20; bh=lTBy2AF6JzXpICcyoEn/yjEMP3BFHCpjrzDazL5CANs=; b=oJGoaBL+0y59lBv7R2yMB/vzj4HdWRO9z2/lKCtDduYnAzt5B16iVpmmQt k7Ja8zwn+Hn1zcnowT1I7aaLqC5oAyO+26S9KLuZ03CIWZhIMpy5JQaXPPeL 3Tfkl54+ub+MzDHGwBMt+T7W67RBO5sLfSuNDPR/BZ35C59Cwt/Yo=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Emu] Issue #15: Algorithm agility and certs X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 19:15:46 -0000 Issue: Sec. 4.1.1 has requirements on algorithm agility. They are important, but insufficient. I propose to mention that when the tunnel method uses certificates, it MUST be possible to migrate to new algorithms for such certificates as well. (This possibly belongs in 4.2.1).=20 Comment: Proposed Text in section 4.1.1: " The tunnel method MUST NOT be tied to any single cryptographic algorithm. Instead, it MUST support run-time negotiation to select among an extensible set of cryptographic algorithms. This includes algorithms used with certificates presented during tunnel establishment. ..." -- Ticket URL: emu From jsalowey@cisco.com Thu Aug 6 12:16:56 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C7B93A6E6B for ; Thu, 6 Aug 2009 12:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqvLIhJe83Y0 for ; Thu, 6 Aug 2009 12:16:55 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id DCF603A6DE0 for ; Thu, 6 Aug 2009 12:16:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAM7IekqrR7PE/2dsb2JhbAC4Z4gqOY9nBYJQgUg X-IronPort-AV: E=Sophos;i="4.43,335,1246838400"; d="scan'208";a="193278935" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 06 Aug 2009 19:16:59 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n76JGxAg024755 for ; Thu, 6 Aug 2009 12:16:59 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n76JGx0R004144 for ; Thu, 6 Aug 2009 19:16:59 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 12:16:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Aug 2009 12:16:58 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #16: Server auth Thread-Index: AcoWyDMYw3nlL9C0SvCgVO6fAPdgpgAAiHnA From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 06 Aug 2009 19:16:59.0010 (UTC) FILETIME=[783F4E20:01CA16CA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=511; t=1249586219; x=1250450219; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Issue=20#16=3A=20Server=20auth |Sender:=20; bh=cibSBONdY+IeYajxqol6Llw7bK01wRGzXsKGBI6l/Kk=; b=rWEpoijas6P6szI8BVfnc0bD2k03DU8Z9M2vNd47piIO5lfdpvOoJfWBTZ cm/b6uLgwg3ZaMXc4lajiyiYv5ONvfFyX9Hgxb10fidrQ04rJyN/JnjKEJCA VIbJJeBIXY; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Emu] Issue #16: Server auth X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 19:16:56 -0000 #16: Server auth Issue: 4.5.1: I suggest to mention that even in cases where passwords are *not* sent in the clear (e.g. challenge-response methods), server authentication is still a MUST.=20 Comment: Suggested Text: "The EAP server MUST be authenticated before the peer can send the clear text password or information generated directly from the password to the server." -- Ticket URL: emu From jsalowey@cisco.com Thu Aug 6 12:18:24 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 787CB3A6E65 for ; Thu, 6 Aug 2009 12:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edcfqEP1GjE1 for ; Thu, 6 Aug 2009 12:18:23 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 85EE33A6E70 for ; Thu, 6 Aug 2009 12:18:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAL/JekqrR7O6/2dsb2JhbAC5UIgqNQQBj2YFgksFAYFH X-IronPort-AV: E=Sophos;i="4.43,335,1246838400"; d="scan'208";a="224539248" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 06 Aug 2009 19:18:26 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n76JIQr5015848 for ; Thu, 6 Aug 2009 12:18:26 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n76JIQh4022060 for ; Thu, 6 Aug 2009 19:18:26 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 12:18:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Aug 2009 12:18:25 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #17: What is "housekeeping" Thread-Index: AcoWyMRQogTU5P0HRqukSGp1ecj+pQAAdGLg From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 06 Aug 2009 19:18:26.0557 (UTC) FILETIME=[AC6DEAD0:01CA16CA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=573; t=1249586306; x=1250450306; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Issue=20#17=3A=20What=20is=20=22housekeeping=22 |Sender:=20; bh=8Y9x8R0PQS4eojemeGqhJGRDTDABg9R22MwSQYX13GM=; b=glICEGa+IEcMgnnWJDeSxNHLvZX5IlXyxXqsJOo8tCaI9gzFBBuLmknSts 3+//PP7omxoaMRfxa1KgU2ycRqeDSyh1McewKzITLTICk1A4svM7neVIRm6E UZw+vvVKAb; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Emu] Issue #17: What is "housekeeping" X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 19:18:24 -0000 #17: What is "housekeeping" Issue: "The password authentication exchange MUST support password change, as well as other "housekeeping" functions, such as the management of PINs or other data, required by some systems."=20 Comment: Suggested Change: "The password authentication exchange MUST support password change, as well as other "housekeeping" functions, such as the management of PINs or other data, required by some systems." -- Ticket URL: emu From jsalowey@cisco.com Thu Aug 6 12:27:30 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 747A728C199 for ; Thu, 6 Aug 2009 12:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCw55S1oxHWv for ; Thu, 6 Aug 2009 12:27:29 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 9727128C198 for ; Thu, 6 Aug 2009 12:27:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANvLekqrR7O6/2dsb2JhbAC5WogqNgMEj2IFgjIaBAiBQA X-IronPort-AV: E=Sophos;i="4.43,335,1246838400"; d="scan'208";a="181956270" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 06 Aug 2009 19:27:32 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n76JRWoQ021914 for ; Thu, 6 Aug 2009 12:27:32 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n76JRWCu015256 for ; Thu, 6 Aug 2009 19:27:32 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 12:27:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Aug 2009 12:27:31 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #18: Internationalization Thread-Index: AcoWy4UWlNQeigKqSSOx9ldnXnrZcwAAD4Gg From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 06 Aug 2009 19:27:32.0133 (UTC) FILETIME=[F19E3550:01CA16CB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1761; t=1249586852; x=1250450852; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Issue=20#18=3A=20Internationalization |Sender:=20; bh=8PDW+fkzu+Cck+tlsFwXcMicwep1lsmKS9pVJaiOtGc=; b=Z2eHCZA+qQV/7zYfTywGflZdeIfBf6Zbd8bLstaqV+3NvbLmD61Ogy3cqc kgTauo8X+AWIsK7RfEJD3MxzdV9cZecgztzBoclwWlEkPAyCPB1SbDA7tCEj Xq0qr8ROgy; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Emu] Issue #18: Internationalization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 19:27:30 -0000 #18: Internationalization Is the use of UTF-8 sufficient or is other tagging necessary. The following cases need to be considered: 1. Usernames and passwords 2. Prompts and error associated with username and password authentication 3. Other textual data > Section 4.3.6 > > " The payload MAY provide a standard attribute format that supports > international strings. This attribute format MUST support encoding > strings in UTF-8 [RFC3629] format. Any strings sent by the server > intended for display to the user MUST be sent in UTF-8 format and > SHOULD be able to be marked with language information and > adapted to > the user's language preference." > > If UTF-8 is supported, is it necessary to also mark the language? > Why is language negotiation a SHOULD? > > EAP methods such as Identity & Notification don't support this. > and > Section 4.5.2 > > " The password authentication exchange MUST support user names and > passwords in international languages. It MUST support encoding of > user name and password strings in UTF-8 [RFC3629] format. Any > strings sent by the server during the password exchange > and intended > for display to the user MUST be sent in UTF-8 format and SHOULD be > able to be marked with language information and adapted to > the user's > language preference. > " > Why is it useful to mark usernames and passwords with > language information on the wire? Comment: In the Stockholm meeting it was suggested UTF-8 was sufficient, but there did not appear to be consensus on this.=20 --=20 Ticket URL: emu From jsalowey@cisco.com Thu Aug 6 12:44:42 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF5EC3A6C8F for ; Thu, 6 Aug 2009 12:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0Lf-VCd-JuH for ; Thu, 6 Aug 2009 12:44:41 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id D2F1C3A677C for ; Thu, 6 Aug 2009 12:43:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANfPekqrR7PE/2dsb2JhbAC5YogqkB8FhBg X-IronPort-AV: E=Sophos;i="4.43,336,1246838400"; d="scan'208";a="193298223" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 06 Aug 2009 19:43:50 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n76JhoEG011075 for ; Thu, 6 Aug 2009 12:43:50 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n76JhoqP016050 for ; Thu, 6 Aug 2009 19:43:50 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 12:43:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Aug 2009 12:43:50 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #19: Method Chaining Thread-Index: AcoWzeZWWi30NxybRpW3/EmLFyyDdwAACnFQ From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 06 Aug 2009 19:43:50.0734 (UTC) FILETIME=[38E8DEE0:01CA16CE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1354; t=1249587830; x=1250451830; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Issue=20#19=3A=20Method=20Chaining |Sender:=20; bh=8NyXRYV+3xrSlneN7bWF+I7/+OxvMVlzkzZ8o4CYD2M=; b=uNJPlta5Wn2Px7b64mDg+pvNSVK+ubg+4jtJ3qN0KnaG1UsnovNfuTPSow oj1HxIxPcde2AT2UztuRnkBEZviFSdJ+Fn6rDQ45ssd+om2v134a0ZbXFTS9 EVuIP+VKhS; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Emu] Issue #19: Method Chaining X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 19:44:43 -0000 #19: Method Chaining > Section 3.3 > > " Several circumstances are best addressed by using chained EAP > methods. For example, it may be desirable to authenticate the user > and also authenticate the device that he or she is using." > This requirement can be met by support for cryptographic > binding, without chaining of EAP methods. For example, the > combination of TLS and an inner method can support > user/device auth. Given that, why is support for chained > methods a must, and not device/user auth support? > and > Section 4.6.2 > > " The tunnel method MUST support the chaining of multiple > EAP methods. > The tunnel method MUST allow for the communication of intermediate > result and verification of compound binding between executed inner > methods when chained methods are employed. > " > > Given that the basic use case (machine + user auth) doesn't > require chaining of EAP methods, why is this a MUST? > -- Comment(by jsalowey@cisco.com): In the Stockholm meeting there was indication that there were other mechanisms that could require chaining, such as posture checking. People seemed to favor changing from MUST to SHOULD. --=20 Ticket URL: emu From jsalowey@cisco.com Thu Aug 6 12:51:21 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17B2328C159 for ; Thu, 6 Aug 2009 12:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GG5bAVoYubeD for ; Thu, 6 Aug 2009 12:51:20 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 7606A28C12A for ; Thu, 6 Aug 2009 12:51:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMfQekqrR7O6/2dsb2JhbAC5SIgqOY9mBYJQgUg X-IronPort-AV: E=Sophos;i="4.43,336,1246838400"; d="scan'208";a="224564460" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 06 Aug 2009 19:51:21 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n76JpMMJ013444 for ; Thu, 6 Aug 2009 12:51:22 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n76JpMlj023075 for ; Thu, 6 Aug 2009 19:51:22 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 12:51:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Aug 2009 12:51:20 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #20: Method Meta-Data Thread-Index: AcoWzxG4GdSmFqmjRFqXehvVx1UUbAAAB7Ww From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 06 Aug 2009 19:51:22.0488 (UTC) FILETIME=[462D0F80:01CA16CF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1563; t=1249588282; x=1250452282; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Issue=20#20=3A=20Method=20Meta-Data |Sender:=20; bh=aqUiWAqN2uLmbzW6stNnV8cXl5C0TTp/u/abZ4OKlFU=; b=IVgQ3WtVqQMrFU0lfmAvfuAdopD3dAvc8wWZc2DdUr4WnsGGFrMhNKU2ZM /llzU5nsSk/gbGK2w3JdYbYpzAFMrPFBAeuPcJLCmPcN/v9qrtdbt9Bs7LxA 8XHMccOWy7; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Emu] Issue #20: Method Meta-Data X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 19:51:21 -0000 #20: Method Meta-Data > Section 4.5.3 > > " The password authentication exchange MUST support additional > associated meta-data which can be used to indicate whether the > authentication is for a user or a machine. This allows the EAP > server and peer to request and negotiate authentication > specifically > for a user or machine. This is useful in the case of > multiple inner > authentications where the user and machine both need to be > authenticated. > " > Why is it necessary to support meta-data to indicate whether > authentication is for a user or machine? Few authentication > protocols support this today and don't seem to miss it. For > example, does Kerberos or PKI distinguish explicitly between > user and machine credentials? > and > Section 4.6.5 > > " The tunnel method MUST allow for the communication of > additional data > associated with an EAP method. This can be used to > indicate whether > the authentication is for a user or a machine. This allows the EAP > server and peer to request and negotiate authentication > specifically > for a user or machine. This is useful in the case of > multiple inner > EAP authentications where the user and machine both need to be > authenticated. > " > Again, why is meta-data necessary? Can't the basic need for > machine + user auth be met without this? > --=20 Ticket URL: emu From aland@deployingradius.com Thu Aug 6 13:00:28 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 677A83A68CC for ; Thu, 6 Aug 2009 13:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbz61oKhGNNI for ; Thu, 6 Aug 2009 13:00:27 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id A30293A681C for ; Thu, 6 Aug 2009 13:00:27 -0700 (PDT) Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 74E2012345B8; Thu, 6 Aug 2009 22:00:29 +0200 (CEST) Message-ID: <4A7B365D.50405@deployingradius.com> Date: Thu, 06 Aug 2009 22:00:29 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Dan Harkins References: <3fdd59d6b44f49b0f9899d42590370e5.squirrel@www.trepanning.net> In-Reply-To: <3fdd59d6b44f49b0f9899d42590370e5.squirrel@www.trepanning.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org Subject: Re: [Emu] Issue #7: Password Authentication X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 20:00:28 -0000 Dan Harkins wrote: > Perhaps it would be a good idea to mandate that the method used > to authenticate the tunnel (outer method, whatever you want to call > it) MUST NOT be susceptible to a dictionary attack if it is going > to be used to transport a username and plaintext password to the > authentication server. That is reasonable. Alan DeKok. From jsalowey@cisco.com Thu Aug 6 13:05:52 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F36E3A67FD for ; Thu, 6 Aug 2009 13:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxR+FEYa8+kp for ; Thu, 6 Aug 2009 13:05:51 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2B63C3A6850 for ; Thu, 6 Aug 2009 13:05:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEvUekqrR7PD/2dsb2JhbAC5QIgqkCEFhBg X-IronPort-AV: E=Sophos;i="4.43,336,1246838400"; d="scan'208";a="224571938" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 06 Aug 2009 20:05:49 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n76K5nGL008509 for ; Thu, 6 Aug 2009 13:05:49 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n76K5nC6025959 for ; Thu, 6 Aug 2009 20:05:49 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 13:05:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Aug 2009 13:05:48 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #21: Mandatory Vs. Optional Thread-Index: AcoWz4aXb4eS6mhYTRqAvHPjDprjxQAAbf7Q From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 06 Aug 2009 20:05:49.0459 (UTC) FILETIME=[4AEE5630:01CA16D1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=560; t=1249589149; x=1250453149; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Issue=20#21=3A=20Mandatory=20Vs.=20Optional |Sender:=20; bh=a9OJMnHcWNVDUqxQfRJBbNY7CjPC+DTv4VuvhgA2oEk=; b=iKojDmY3zvRHKLgJLay7Oq36oCDwVMl2bwHRRqZLw/Xn1L3KmVTFR9fR73 a/1PsbXPAXZf9E18M9dyEGNAcmtXih5Cst8Kx1+LIY+wJoEN1wV+pGmm+Onq 5QPhp6KKlo; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Emu] Issue #21: Mandatory Vs. Optional X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 20:05:52 -0000 =20 #21: Mandatory Vs. Optional > Section 4.3.3 > > " The payload MUST support marking of mandatory and optional > attributes, as well as an attribute used for rejecting mandatory > attributes." > > Why is it necessary for mandatory and optional attributes to > be explicitly marked? Is it be sufficient for the attributes > to be divided into standardized and vendor-specific spaces, > with the latter optional? > --=20 Ticket URL: emu From jsalowey@cisco.com Thu Aug 6 13:11:34 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6430A3A681C for ; Thu, 6 Aug 2009 13:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jlvIWoQx3DQ for ; Thu, 6 Aug 2009 13:11:33 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 8DA0B3A6C6E for ; Thu, 6 Aug 2009 13:11:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAE7VekqrR7PE/2dsb2JhbAC5JYgqkCEFgjKBZg X-IronPort-AV: E=Sophos;i="4.43,336,1246838400"; d="scan'208";a="181972061" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 06 Aug 2009 20:11:36 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n76KBaXE030914 for ; Thu, 6 Aug 2009 13:11:36 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n76KBapx012561 for ; Thu, 6 Aug 2009 20:11:36 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 13:11:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Aug 2009 13:11:35 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #23: Tunnel Protection requirements Thread-Index: AcoW0bmrfo86FVOiSKaD4Oj6uKLQHwAAEzHQ From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 06 Aug 2009 20:11:36.0678 (UTC) FILETIME=[19E3C060:01CA16D2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1327; t=1249589496; x=1250453496; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Issue=20#23=3A=20Tunnel=20Protection=20requirem ents |Sender:=20; bh=mUgVEkYk+adYDoicSb1NdMbvZMG/tskNlrhHzxiuGxo=; b=Z7muSfD2VUmHR+88q5eGVd9407rvdvVSSyk1Vlb6g1lC9bvrecyNojwW9A Ig4r74sL/aPh60Fg9sRsK33U78UWaBbtwsKwPpiODDFDia41uQDPQ4/jyCeq Du8RtI1Opj; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Emu] Issue #23: Tunnel Protection requirements X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 20:11:34 -0000 #23: Tunnel Protection requirements > Section 4.2.1.1.2 > > "See Part 1 of the NIST Recommendation for > Key Management [NIST SP 800-57] for a discussion of the relative > strengths of common algorithms." > > Why not reference the NIST SP 800-120 requirements here? > > "o One-way key derivation > o Cryptographically separated keys. > o Cryptographically separated entities. > o Identity binding > o Context binding > o Key lifetime > o Mutual implicit key authentication > o Key freshness" > > Given that this document assumes a TLS-based tunnel method, > the text on requirements can be made considerably more > specific and actionable based on TLS properties and the > specific requirements of NIST 800-120. > As it stands, a number of these requirements either don't > apply to EAP methods at all (e.g. context binding, key > lifetime) but rather to other elements of the system, or are > automatically provided by TLS (e.g. key freshness, Identity > binding). > > So these requirements need to be made actionable and > specific. The ones that don't apply to the problem at hand > (e.g. TLS-based tunnel euth) should be removed. > --=20 Ticket URL: emu From jsalowey@cisco.com Thu Aug 6 13:13:20 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 743AD3A6C6E for ; Thu, 6 Aug 2009 13:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMccslexoBnC for ; Thu, 6 Aug 2009 13:13:19 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 656543A6C1A for ; Thu, 6 Aug 2009 13:13:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALPVekqrR7PD/2dsb2JhbAC5KYgqkCEFhBg X-IronPort-AV: E=Sophos;i="4.43,336,1246838400"; d="scan'208";a="193308968" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 06 Aug 2009 20:10:46 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n76KAkkZ017373 for ; Thu, 6 Aug 2009 13:10:46 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n76KAjNC004478 for ; Thu, 6 Aug 2009 20:10:45 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 13:10:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Aug 2009 13:10:45 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #22: Collection of smaller issues Thread-Index: AcoW0TnWwitTTVzbQIWGnZOkXkD4zQAALKbA From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 06 Aug 2009 20:10:45.0816 (UTC) FILETIME=[FB92D380:01CA16D1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2667; t=1249589446; x=1250453446; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Issue=20#22=3A=20Collection=20of=20smaller=20is sues |Sender:=20; bh=TkQ/INU25Q9o6V39w9+wvWL3zDHDooPDu8vHkVGNVtM=; b=sSJFR8cUqV5m3+96b7N8ZLVaiHNhDT46ncRAECpZ/j+MM2DMoboVq/glOM DlWdFq9PGxssJkYqkBnBpsBoVof+aNsW+RHxEHbLgX3JWVQCfOoDpQG5kX5D c/ayJKdT3v; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Emu] Issue #22: Collection of smaller issues X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 20:13:20 -0000 #22: Collection of smaller issues > Section 4.1.1 > > " The tunnel method MUST meet all the MUST and SHOULD requirements > relevant to EAP methods contained in the EAP Key > Management Framework > [RFC5247] or its successor. The tunnel method MUST include MSK and > EMSK generation. This will enable the tunnel method to > properly fit > into the EAP key management framework, maintaining all of the > security properties and guarantees of that framework." > > The primary aspects of [RFC5247] that apply to EAP methods is > the generation of the Peer-Id, Server-Id and Session-Id. Why > not just spell out those requirements specifically? > Suggested Text: "The tunnel method MUST meet all the MUST and SHOULD requirements relevant to EAP methods contained in the EAP Key Management Framework [RFC5247] or its successor. This includes the generation of the MSK, EMSK, Peer-Id, Server-Id and Session-Id. This will enable the tunnel method to properly fit into the EAP key management framework, maintaining all of the security properties and guarantees of that framework. " > " The tunnel method MUST meet the SHOULD and MUST requirements > pertinent to EAP method contained in Section 3 of RFC 4962 > [RFC4962]. > This includes: cryptographic algorithm independence; strong, fresh > session keys; replay detection; keying material confidentiality and > integrity; confirm cipher suite selection; and uniquely > named keys." > > The key naming requirement is handled by generation of the > Session-Id, so it needn't be mentioned specifically. > > With respect to some of these issues, NIST 800-120 provides > more detailed and specific requirements. > Proposal to remove key naming from list > Section 4.1.2 > > " Several existing tunnel methods are already in widespread > usage: EAP- > FAST [RFC4851], EAP-TTLS [RFC5281], and PEAP." > > The definitive reference for the PEAP protocol is: > http://msdn.microsoft.com/en-us/library/cc238354(PROT.10).aspx > Propose resolution to update reference > Section 4.2.1.1.3 > > " A tunnel method MUST provide unidirectional authentication from > authentication server to EAP peer or mutual authentication between > authentication server and EAP peer." > > Is this really an or? For example, would a tunnel method > that only supports undirectional authentication satisfy the > requirement? > It should be "and" --=20 Ticket URL: emu From shanna@juniper.net Thu Aug 6 13:17:13 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC2373A6D1F for ; Thu, 6 Aug 2009 13:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhLTmoJ6bkg9 for ; Thu, 6 Aug 2009 13:17:12 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id E626B3A6A2D for ; Thu, 6 Aug 2009 13:17:11 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSns6STpu+QDvh7/U5VSPYLIl8q4CeNxG@postini.com; Thu, 06 Aug 2009 13:17:16 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 6 Aug 2009 13:13:20 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 6 Aug 2009 16:13:19 -0400 From: Stephen Hanna To: "Joseph Salowey (jsalowey)" , "emu@ietf.org" Date: Thu, 6 Aug 2009 16:12:38 -0400 Thread-Topic: Issue #18: Internationalization Thread-Index: AcoWy4UWlNQeigKqSSOx9ldnXnrZcwAAD4GgAACmiCA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Alexey Melnikov Subject: Re: [Emu] Issue #18: Internationalization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 20:17:13 -0000 With respect to the internationalization issue noted below, relating to draft-ietf-emu-eaptunnel-req-02.txt, Alexey Melnikov recently pointed out to me that BCP 18 (RFC 2277), section 4.2 says: Protocols that transfer text MUST provide for carrying information about the language of that text. Protocols SHOULD also provide for carrying information about the language of names, where appropriate. Section 4.1 of that document explains the reason why. Here's an excerpt: Many operations, including high quality formatting, text-to-speech synthesis, searching, hyphenation, spellchecking and so on benefit greatly from access to information about the language of a piece of text. [WC 3.1.1.4]. Internationalization of usernames and passwords has been discussed at length on other lists. Nobody is suggesting in today's discussion that they should have language tags. That is problematic since usernames and passwords often aren't words in any language and the user often doesn't have control over the language settings of the system being used to enter the username and password. But the text being reviewed does not have anything to do with username and password language issues. The text under discussion in draft-ietf-emu-eaptunnel-req-03.txt says "Any strings sent by the server intended for display to the user MUST be sent in UTF-8 format and SHOULD be able to be marked with language information and adapted to the user's language preference." Notice the words "sent by the server intended for display to the user". That would not generally apply to usernames and passwords. Instead, it would apply to messages like "Please enter your password" or "Sorry, you can't sign in right now due to system maintenance". In order to provide for proper formatting and to allow blind users to have those messages properly converted to audio, it is a good idea for our protocol to include a standard place where the EAP authenticator can send language tags with such messages. It's also a good idea for the protocol to include a way for the EAP peer to indicate what the user's language preferences are (if known). That way, the authenticator can send its messages in the user's preferred language (if the software allows the administrator to enter messages in multiple languages and the administrator has chosen to do so). So I submit that the text currently in draft-ietf-emu-eaptunnel-req-03.txt on this topic is a good idea and that it should not be removed. As Joe noted below, there was not consensus on this issue in the EMU session at IETF 75. I suggest that we discuss it on the list. One concern that I heard expressed was that servers may decide to fail the entire exchange if they don't support any of the user's preferred languages. Apparently, some other protocols some seen this behavior when language preferences were sent. Maybe we should add text to the eventual protocol specification advising servers not to do that. Instead, they should fall back to a default language. Are there other concerns? Thanks, Steve > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On=20 > Behalf Of Joseph Salowey (jsalowey) > Sent: Thursday, August 06, 2009 3:28 PM > To: emu@ietf.org > Subject: [Emu] Issue #18: Internationalization >=20 >=20 > #18: Internationalization >=20 > Is the use of UTF-8 sufficient or is other tagging necessary. The > following cases need to be considered: >=20 > 1. Usernames and passwords > 2. Prompts and error associated with username and password > authentication > 3. Other textual data >=20 > > Section 4.3.6 > > > > " The payload MAY provide a standard attribute format=20 > that supports > > international strings. This attribute format MUST support > encoding > > strings in UTF-8 [RFC3629] format. Any strings sent by=20 > the server > > intended for display to the user MUST be sent in UTF-8=20 > format and > > SHOULD be able to be marked with language information and > > adapted to > > the user's language preference." > > > > If UTF-8 is supported, is it necessary to also mark the language? > > Why is language negotiation a SHOULD? > > > > EAP methods such as Identity & Notification don't support this. > > >=20 > and >=20 > > Section 4.5.2 > > > > " The password authentication exchange MUST support user names and > > passwords in international languages. It MUST support=20 > encoding of > > user name and password strings in UTF-8 [RFC3629] format. Any > > strings sent by the server during the password exchange > > and intended > > for display to the user MUST be sent in UTF-8 format=20 > and SHOULD be > > able to be marked with language information and adapted to > > the user's > > language preference. > > " > > Why is it useful to mark usernames and passwords with > > language information on the wire? >=20 > Comment: >=20 > In the Stockholm meeting it was suggested UTF-8 was sufficient, but > there did not appear to be consensus on this.=20 >=20 > --=20 > Ticket URL: > emu >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > = From jsalowey@cisco.com Thu Aug 6 13:24:59 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B13BD3A6D82 for ; Thu, 6 Aug 2009 13:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-mcbneVSk3i for ; Thu, 6 Aug 2009 13:24:58 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id BC8743A6E3E for ; Thu, 6 Aug 2009 13:24:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADfZekqrR7PD/2dsb2JhbAC5K4gqOY9mBYJMBAiBQA X-IronPort-AV: E=Sophos;i="4.43,336,1246838400"; d="scan'208";a="193313893" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 06 Aug 2009 20:22:46 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n76KMk9N007664 for ; Thu, 6 Aug 2009 13:22:46 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n76KMkVW017272 for ; Thu, 6 Aug 2009 20:22:46 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 13:22:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Aug 2009 13:22:45 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #24: Backend password attacks Thread-Index: AcoW01ZQ6V50SEsMSQyQAcK39A7QJwAAD31w From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 06 Aug 2009 20:22:46.0339 (UTC) FILETIME=[A909E930:01CA16D3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1168; t=1249590166; x=1250454166; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Issue=20#24=3A=20Backend=20password=20attacks |Sender:=20; bh=P8LLO/Ty7k30DJD+PCEcodu2mDT74wGjBd23mZcGI6E=; b=Yk990BWaYWvRHIBRVJqDU8GmXcePYO1pFAfS6BxHcspJN5MarCqRP5PHaN RHwbXcGszYWGnrnbriKFEchLkaz16YGBnfRkdUPW/DzS3jSCJ8TWlRru/thA IgIgMxE8Hi; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Emu] Issue #24: Backend password attacks X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 20:24:59 -0000 #24: Backend password attacks > Section 4.5 > > "These typically > require the password in its original text form in order to > authenticate the peer, hence they require the peer to send > the clear > text user name and password to the EAP server." > > One of the issues with support for cleartext passwords are > the potential attacks against the AAA backend (e.g. > User-Password attribute) in split authentication scenarios. > Is it worth calling this out? > How about adding the following to security considerations section: "If the inner method is terminated at a different location than the outer tunnel then the inner method data may be vulnerable to modification and eavesdropping between the server that terminates the tunnel and the server that terminates the inner method. For example if a clear text password is used then it may be sent to the inner method server in a RADIUS password attribute which uses weak encryption that may not be suitable protection for many environments. " --=20 Ticket URL: emu From yaronf@checkpoint.com Thu Aug 6 13:26:19 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F64A3A6DE0 for ; Thu, 6 Aug 2009 13:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t22j016CYzoj for ; Thu, 6 Aug 2009 13:26:18 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 2448C3A6B14 for ; Thu, 6 Aug 2009 13:26:18 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 9DF2029C036; Thu, 6 Aug 2009 23:26:39 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 53CAE29C025; Thu, 6 Aug 2009 23:26:39 +0300 (IDT) X-CheckPoint: {4A7B3AA2-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n76KQJ3d006759; Thu, 6 Aug 2009 23:26:19 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 6 Aug 2009 23:26:18 +0300 From: Yaron Sheffer To: "Joseph Salowey (jsalowey)" , "emu@ietf.org" Date: Thu, 6 Aug 2009 23:26:16 +0300 Thread-Topic: Issue #15: Algorithm agility and certs Thread-Index: AcoWxmERgUoSkKTXSIaLQkc/rqy6NgAA7MTgAAKCSNA= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E56C7781@il-ex01.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00EB_01CA16ED.4BC4CF50" MIME-Version: 1.0 Subject: Re: [Emu] Issue #15: Algorithm agility and certs X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 20:26:19 -0000 ------=_NextPart_000_00EB_01CA16ED.4BC4CF50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm fine with this text. Thanks, Yaron > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of > Joseph Salowey (jsalowey) > Sent: Thursday, August 06, 2009 22:16 > To: emu@ietf.org > Subject: [Emu] Issue #15: Algorithm agility and certs > > > Issue: > > Sec. 4.1.1 has requirements on algorithm agility. They are important, > but insufficient. I propose to mention that when the tunnel method uses > certificates, it MUST be possible to migrate to new algorithms for such > certificates as well. (This possibly belongs in 4.2.1). > > Comment: > > Proposed Text in section 4.1.1: > > " The tunnel method MUST NOT be tied to any single cryptographic > algorithm. Instead, it MUST support run-time negotiation to select > among an extensible set of cryptographic algorithms. This includes > algorithms used with certificates presented during tunnel establishment. > ..." > > -- > Ticket URL: > emu > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_00EB_01CA16ED.4BC4CF50 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgwNjIwMjYxNlowIwYJKoZIhvcNAQkEMRYEFFfVybib/xUr ooVFMlxcQLXxKUWlMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA H2GTW0myIMmMfU/2NROVCHE8vly2KukyyeyUaJcEF9WtLCJMccx3KwnOEI6PiaNuUlqpGsWHdVoG rAUjzCQgkOX+YYO2XtI8v4LqfOVDLesicmtziwkbOvkma6Bhxurm4kIWvOrRywUW/Cdih1ovagcR ko9NsX2WR9uQ8P5l39rD+X5dG1tHBx7QbfoC3rD/7Q0jBC/uAZZAt2apILXebFqoGAxZ9niuBdUO eged9XYaxEZyzImJPeRhsK1qj8h0/mv65Yg9VJMYYO3hg4KEAbfz6WLpocLrQ2gCTqPOJMAy1jjz IDgOWEM41wKknni14aiSgEW12OpfT//XTZJw9gAAAAAAAA== ------=_NextPart_000_00EB_01CA16ED.4BC4CF50-- From yaronf@checkpoint.com Thu Aug 6 13:40:13 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 172973A6E5D for ; Thu, 6 Aug 2009 13:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IefoGZduJjls for ; Thu, 6 Aug 2009 13:40:12 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id A8E8B28C13A for ; Thu, 6 Aug 2009 13:39:32 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 9E66129C036; Thu, 6 Aug 2009 23:39:54 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 4E6B729C025; Thu, 6 Aug 2009 23:39:54 +0300 (IDT) X-CheckPoint: {4A7B3DBC-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n76KdY3d010110; Thu, 6 Aug 2009 23:39:34 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 6 Aug 2009 23:39:33 +0300 From: Yaron Sheffer To: "Joseph Salowey (jsalowey)" , "emu@ietf.org" Date: Thu, 6 Aug 2009 23:39:32 +0300 Thread-Topic: Issue #16: Server auth Thread-Index: AcoWyDMYw3nlL9C0SvCgVO6fAPdgpgAAiHnAAAKkqRA= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E56C7782@il-ex01.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00F0_01CA16EF.25D82EC0" MIME-Version: 1.0 Subject: Re: [Emu] Issue #16: Server auth X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 20:40:13 -0000 ------=_NextPart_000_00F0_01CA16EF.25D82EC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Actually this is still kind of vague: what is "generated directly"? In a challenge-response, it is the password is encrypted/hashed - does this count as "directly"? Also, *all of* sec. 4.5.1 should apply to this kind of methods, not just server authentication. So I suggest to replace: Due to the fact that the EAP peer needs to send clear text password to the EAP server to authenticate against the legacy user information, the security measures in the following sections MUST be met. By: Many internal EAP methods have the peer send its password in the clear To the EAP server. Other methods (e.g. challenge-response methods) are vulnerable to attacks if an eavesdropper can intercept the traffic. For any such methods, the security measures in the following sections MUST be met. Thanks, Yaron > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of > Joseph Salowey (jsalowey) > Sent: Thursday, August 06, 2009 22:17 > To: emu@ietf.org > Subject: [Emu] Issue #16: Server auth > > #16: Server auth > > Issue: > > 4.5.1: I suggest to mention that even in cases where passwords are *not* > sent in the clear (e.g. challenge-response methods), server > authentication is still a MUST. > > Comment: > > Suggested Text: > "The EAP server MUST be authenticated before the peer can send the > clear text password or information generated directly from the password > to the server." > > -- > Ticket URL: > emu > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_00F0_01CA16EF.25D82EC0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgwNjIwMzkzMlowIwYJKoZIhvcNAQkEMRYEFKiP5twvQnT/ IuwRcbP24OrcwnSzMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA Iv/Ex/4X2TVOvQc5h61nsKtoKUH/jIJuFWpWExefHotZmewfi9B8jdwlrvlNGpF7Jg+z2NixHlSN +rX0kejMLk7PogUJitRA/oOXfdClZ77SUEluo8Zste7XDOdxpE/cyi3U6ZQNZA5eI825K95V/scI ZI/ypnby8bdJQBxFL/z5w7LBjzDcoC0eyc8vhskAxaq2NMzpwB4KIebMDdQsGmBRsYVbT6TaPLym TuJL7MiYsfdBO0i5PJ5sz6TnZJ9GtTd8OgYHZie9GNbuRzUVFGk5KwDZD+TWrQthupo3Jzi0do0Z STXsveo+wG3KB1XYbBfsmj0yYUMR+X9vlXwcDQAAAAAAAA== ------=_NextPart_000_00F0_01CA16EF.25D82EC0-- From yaronf@checkpoint.com Thu Aug 6 13:41:17 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE5A03A6DEE for ; Thu, 6 Aug 2009 13:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8rBSROeemol for ; Thu, 6 Aug 2009 13:41:15 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id C9FB33A6CE2 for ; Thu, 6 Aug 2009 13:41:09 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 9A19B29C036; Thu, 6 Aug 2009 23:41:31 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 4EE7329C025; Thu, 6 Aug 2009 23:41:31 +0300 (IDT) X-CheckPoint: {4A7B3E1E-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n76KfB3d010474; Thu, 6 Aug 2009 23:41:11 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 6 Aug 2009 23:41:10 +0300 From: Yaron Sheffer To: "Joseph Salowey (jsalowey)" , "emu@ietf.org" Date: Thu, 6 Aug 2009 23:41:10 +0300 Thread-Topic: Issue #17: What is "housekeeping" Thread-Index: AcoWyMRQogTU5P0HRqukSGp1ecj+pQAAdGLgAALjzbA= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E56C7783@il-ex01.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00F5_01CA16EF.603D37E0" MIME-Version: 1.0 Subject: Re: [Emu] Issue #17: What is "housekeeping" X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 20:41:17 -0000 ------=_NextPart_000_00F5_01CA16EF.603D37E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Well, this could stand even more detail, but fine... > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of > Joseph Salowey (jsalowey) > Sent: Thursday, August 06, 2009 22:18 > To: emu@ietf.org > Subject: [Emu] Issue #17: What is "housekeeping" > > #17: What is "housekeeping" > > Issue: > > "The password authentication exchange MUST support password change, as > well as other "housekeeping" functions, such as the management of PINs > or other data, required by some systems." > > Comment: > > Suggested Change: > > "The password authentication exchange MUST support password change, as > well as other "housekeeping" functions, such as the management of PINs > or other data, required by some systems." > > -- > Ticket URL: > emu > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_00F5_01CA16EF.603D37E0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgwNjIwNDExMFowIwYJKoZIhvcNAQkEMRYEFN9jcoH8q8Ti Kj2T2vh9w8KUYMrAMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA qc21EhDMcTaMGswUvzqKrMQYI1J87+FN/J5D0Ni+YplF68mCTOcmdGCimxNzUsYyxrauNuYGthxM ZddlWJ4HgtDA9VuQvjJhjPLvqKmqGPVJKtvw2SAGLhUKHIq/Ki9525tefS4+WMnCHuRHsojAJ9xP bkXaqAccRVCQY9M+YmzUp4eZlsWiNcJ9/ZsstAyMJTBJZ/CqKqF7UVxrI262lC9g5qrsrc4+B1Oh LKPS78gzhTZutR3IOJKC/J2ruNYRY15bR7neqQ8K28/OgldzgcnneAzRJHfDt5jGbCFdFXkiWaBK HRyTAbAbHVf26QwZ2+XcCQ3Mw6Ymc0oyZReX8QAAAAAAAA== ------=_NextPart_000_00F5_01CA16EF.603D37E0-- From jsalowey@cisco.com Thu Aug 6 13:41:26 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B17753A6D9F for ; Thu, 6 Aug 2009 13:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lG3XjqAaDNMh for ; Thu, 6 Aug 2009 13:41:25 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 770453A6CE2 for ; Thu, 6 Aug 2009 13:41:25 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADPdekqrR7PD/2dsb2JhbAC5P4gqNgMEj18FglCBSA X-IronPort-AV: E=Sophos;i="4.43,336,1246838400"; d="scan'208";a="362066524" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Aug 2009 20:41:10 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n76KfB4i006281; Thu, 6 Aug 2009 13:41:11 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n76KfBJJ001347; Thu, 6 Aug 2009 20:41:11 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 13:41:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Aug 2009 13:41:10 -0700 Message-ID: In-Reply-To: <4A7B365D.50405@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Issue #7: Password Authentication Thread-Index: AcoW0JVcZCclgtSqTxaEU85Ch6VSKAABWH0g References: <3fdd59d6b44f49b0f9899d42590370e5.squirrel@www.trepanning.net> <4A7B365D.50405@deployingradius.com> From: "Joseph Salowey (jsalowey)" To: "Alan DeKok" , "Dan Harkins" X-OriginalArrivalTime: 06 Aug 2009 20:41:11.0092 (UTC) FILETIME=[3B85D740:01CA16D6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1150; t=1249591271; x=1250455271; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Emu]=20Issue=20#7=3A=20Password=20Auth entication |Sender:=20; bh=7iLzfxWVH6gAyDtxiYDIBH70MluVoilgjfUx8vEjHIU=; b=mN5CdX5xaGFdd9ic0QKtgCTcqlxMRsYQHSesFPJUK3TTTl8Apy3wUTnIs9 gBBdqH588PEIwWanHdjrJXgYX9zm5UHwIQOszS29knD9v+l53EtHNHsUI0m/ Q9hHwXkKDz; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: emu@ietf.org Subject: Re: [Emu] Issue #7: Password Authentication X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 20:41:26 -0000 Section 3.1 already states: " ... The tunnel method MUST support this use case. However, it MUST NOT expose the username and password to parties in the communication path between the peer and the EAP Server and it MUST provide protection against man-in-the-middle and dictionary attacks. The combination of the tunnel authentication and password authentication MUST enable mutual authentication." Is there any modification necessary? =20 Joe > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com]=20 > Sent: Thursday, August 06, 2009 1:00 PM > To: Dan Harkins > Cc: Joseph Salowey (jsalowey); emu@ietf.org > Subject: Re: [Emu] Issue #7: Password Authentication >=20 > Dan Harkins wrote: > > Perhaps it would be a good idea to mandate that the=20 > method used to=20 > > authenticate the tunnel (outer method, whatever you want to call > > it) MUST NOT be susceptible to a dictionary attack if it is=20 > going to=20 > > be used to transport a username and plaintext password to the=20 > > authentication server. >=20 > That is reasonable. >=20 > Alan DeKok. >=20 From jsalowey@cisco.com Thu Aug 6 13:48:00 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 979F43A6E2D for ; Thu, 6 Aug 2009 13:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVpUezcDRxDx for ; Thu, 6 Aug 2009 13:47:59 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id CA0F03A6E23 for ; Thu, 6 Aug 2009 13:47:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAF/eekqrR7PD/2dsb2JhbAC5RYgqOY9jBYJQgUg X-IronPort-AV: E=Sophos;i="4.43,336,1246838400"; d="scan'208";a="362070843" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Aug 2009 20:48:01 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n76Km1gS018573; Thu, 6 Aug 2009 13:48:01 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n76Km1Bm017561; Thu, 6 Aug 2009 20:48:01 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 13:48:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Aug 2009 13:48:00 -0700 Message-ID: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E56C7782@il-ex01.ad.checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #16: Server auth Thread-Index: AcoWyDMYw3nlL9C0SvCgVO6fAPdgpgAAiHnAAAKkqRAAAIjjIA== References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E56C7782@il-ex01.ad.checkpoint.com> From: "Joseph Salowey (jsalowey)" To: "Yaron Sheffer" , X-OriginalArrivalTime: 06 Aug 2009 20:48:01.0634 (UTC) FILETIME=[30399420:01CA16D7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2320; t=1249591681; x=1250455681; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20Issue=20#16=3A=20Server=20auth |Sender:=20; bh=O0N9vi1WprXU8FijJ6kcGUSkcVK4K067fv3HngUB3RU=; b=lZ1wLDDMs0hQ4ZP+QhDgjvkhNQDtAIldQvM6fdu7uauji4TxkU8JAGoz48 ThVoshF8lpuPPL1FskHYJMSWgMUrFge0Fvf6sLF6aS938CZqKlpoUHh64nWP CeuFhKzVSx; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Emu] Issue #16: Server auth X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 20:48:00 -0000 I think your proposed text is good. Thanks, Joe > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf@checkpoint.com]=20 > Sent: Thursday, August 06, 2009 1:40 PM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: Issue #16: Server auth >=20 > Actually this is still kind of vague: what is "generated=20 > directly"? In a challenge-response, it is the password is=20 > encrypted/hashed - does this count as "directly"? >=20 > Also, *all of* sec. 4.5.1 should apply to this kind of=20 > methods, not just server authentication. So I suggest to replace:=20 >=20 > Due to the fact that the EAP peer needs to send clear text password > to the EAP server to authenticate against the legacy user > information, the security measures in the following=20 > sections MUST be > met. >=20 > By: >=20 > Many internal EAP methods have the peer send its password=20 > in the clear > To the EAP server. Other methods (e.g. challenge-response=20 > methods) are > vulnerable to attacks if an eavesdropper can intercept the=20 > traffic. For > any such methods, the security measures in the following=20 > sections MUST be > met. >=20 > Thanks, > Yaron >=20 > > -----Original Message----- > > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On=20 > Behalf Of=20 > > Joseph Salowey (jsalowey) > > Sent: Thursday, August 06, 2009 22:17 > > To: emu@ietf.org > > Subject: [Emu] Issue #16: Server auth > >=20 > > #16: Server auth > >=20 > > Issue: > >=20 > > 4.5.1: I suggest to mention that even in cases where passwords are=20 > > *not* sent in the clear (e.g. challenge-response methods), server=20 > > authentication is still a MUST. > >=20 > > Comment: > >=20 > > Suggested Text: > > "The EAP server MUST be authenticated before the peer can send the=20 > > clear text password or information generated directly from the=20 > > password to the server." > >=20 > > -- > > Ticket URL:=20 > > > > emu > >=20 > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu > >=20 > > Scanned by Check Point Total Security Gateway. >=20 From yaronf@checkpoint.com Thu Aug 6 13:52:29 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48A0E3A67BD for ; Thu, 6 Aug 2009 13:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpjUPLp3f8UH for ; Thu, 6 Aug 2009 13:52:28 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id D3E2B3A681C for ; Thu, 6 Aug 2009 13:52:27 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id AFF7B29C036; Thu, 6 Aug 2009 23:52:49 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 6405129C025; Thu, 6 Aug 2009 23:52:49 +0300 (IDT) X-CheckPoint: {4A7B40C3-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n76KqT3d013105; Thu, 6 Aug 2009 23:52:29 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 6 Aug 2009 23:52:29 +0300 From: Yaron Sheffer To: "Joseph Salowey (jsalowey)" , "emu@ietf.org" Date: Thu, 6 Aug 2009 23:52:26 +0300 Thread-Topic: Issue #21: Mandatory Vs. Optional Thread-Index: AcoWz4aXb4eS6mhYTRqAvHPjDprjxQAAbf7QAAGN4mA= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E56C7784@il-ex01.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00FA_01CA16F0.F3A61370" MIME-Version: 1.0 Subject: Re: [Emu] Issue #21: Mandatory Vs. Optional X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 20:52:29 -0000 ------=_NextPart_000_00FA_01CA16F0.F3A61370 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I support the current text. Having explicit marking for mandatory attributes (a "Critical bit") adds power to protocol extensions, in that you can ensure that negotiation will fail if the other side doesn't understand you. Thanks, Yaron > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of > Joseph Salowey (jsalowey) > Sent: Thursday, August 06, 2009 23:06 > To: emu@ietf.org > Subject: [Emu] Issue #21: Mandatory Vs. Optional > > > #21: Mandatory Vs. Optional > > > Section 4.3.3 > > > > " The payload MUST support marking of mandatory and optional > > attributes, as well as an attribute used for rejecting mandatory > > attributes." > > > > Why is it necessary for mandatory and optional attributes to > > be explicitly marked? Is it be sufficient for the attributes > > to be divided into standardized and vendor-specific spaces, > > with the latter optional? > > > > -- > Ticket URL: > emu > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_00FA_01CA16F0.F3A61370 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgwNjIwNTIyNlowIwYJKoZIhvcNAQkEMRYEFKhnWX9/XXHa Zg0tXFVSvZOsEYvGMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA m8UHgIQvY8LnxfLQjPizMew0mYDbowGn8Xk5lVlb1VpBv+8okIsoS5kE+zA9kP2iP0dhnAx1dwAe 4Jn8jDWDpCMdYWKONF6wx++byByHhDhN7pr0Fu7JJMHZHjWEd/ExVugEGhIfm1GzuNOQZbHtAjXn WpfPBtLuRvHCjVwus2lIVo1UnKXMDFYOaCIp5lJN3tk/NRfA89rEQGhXMjWtWcOBSyMAfrR+ra9y uRV7RQBw5QnDqdjZRuQkfYeStf+UDK07S986YhsXmKh6tP903RMAxPF0G+JdxrOtjZAQgAmUfNAv NlR19BeVfN6rYeow+7x2FeO6xvi9kebnei4IgAAAAAAAAA== ------=_NextPart_000_00FA_01CA16F0.F3A61370-- From jsalowey@cisco.com Thu Aug 6 13:56:31 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 619C23A6935 for ; Thu, 6 Aug 2009 13:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKTI6w3HCvlq for ; Thu, 6 Aug 2009 13:56:30 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 81B943A67BD for ; Thu, 6 Aug 2009 13:56:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALjgekqrR7PE/2dsb2JhbAC5P4gqkB0FhBg X-IronPort-AV: E=Sophos;i="4.43,336,1246838400"; d="scan'208";a="362076453" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 06 Aug 2009 20:56:33 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n76KuXFx012804 for ; Thu, 6 Aug 2009 13:56:33 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n76KuXjc020383 for ; Thu, 6 Aug 2009 20:56:33 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 13:56:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Aug 2009 13:56:32 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tunnel Requirements issues Thread-Index: AcoW2GDbkU1/6vjPQ6qJHCKN/U3qBA== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 06 Aug 2009 20:56:33.0558 (UTC) FILETIME=[615AFB60:01CA16D8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=461; t=1249592193; x=1250456193; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Tunnel=20Requirements=20issues |Sender:=20; bh=hx9MlTIdiuFp8hzWyq/8ZUiDK0SE69JbLEZdddzHOU4=; b=Yws3vBNw1C2I5Dj+HZ9V+5VrnKN2vQi97auZqi7xEydI0TeFSy2TKlzmLS I9kWn9oupY0opDF0DYiLWo8cWGc8TndwvZniCDp+VnXg3aWWOSmwu0sW+XGD Z1JB60C0jm; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Emu] Tunnel Requirements issues X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 20:56:31 -0000 I just created several tickets for the tunnel requirements draft in the issue tracker: http://trac.tools.ietf.org/wg/emu/trac/report/1 I think issues 9 - 13, 15, 16, 22 are fairly straight forward. If there is no discussion on these issues by 8/24 I will close the issues and update the document accordingly. =20 For the remaining issues (14, 17 - 21, 23, 24) I think we need to have discussion on the list to resolve them. =20 Thanks, Joe From yaronf@checkpoint.com Thu Aug 6 13:57:29 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2856E3A6D1F for ; Thu, 6 Aug 2009 13:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYSNV46aM1ol for ; Thu, 6 Aug 2009 13:57:28 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 055B93A681C for ; Thu, 6 Aug 2009 13:57:28 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id B639629C036; Thu, 6 Aug 2009 23:57:49 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 6B09529C025; Thu, 6 Aug 2009 23:57:49 +0300 (IDT) X-CheckPoint: {4A7B41EF-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n76KvT3d014288; Thu, 6 Aug 2009 23:57:29 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 6 Aug 2009 23:57:29 +0300 From: Yaron Sheffer To: "Joseph Salowey (jsalowey)" , "emu@ietf.org" Date: Thu, 6 Aug 2009 23:57:27 +0300 Thread-Topic: Issue #22: Collection of smaller issues Thread-Index: AcoW0TnWwitTTVzbQIWGnZOkXkD4zQAALKbAAAGSz7A= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E56C7785@il-ex01.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00FF_01CA16F1.A6A8A500" MIME-Version: 1.0 Subject: Re: [Emu] Issue #22: Collection of smaller issues X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 20:57:29 -0000 ------=_NextPart_000_00FF_01CA16F1.A6A8A500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit [snip] > > > Section 4.2.1.1.3 > > > > " A tunnel method MUST provide unidirectional authentication from > > authentication server to EAP peer or mutual authentication between > > authentication server and EAP peer." > > > > Is this really an or? For example, would a tunnel method > > that only supports undirectional authentication satisfy the > > requirement? > > > > It should be "and" > [YS] Why? This is discussing the "outer" method, which may indeed provide only unidirectional auth. Thanks, Yaron > -- > Ticket URL: > emu > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_00FF_01CA16F1.A6A8A500 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgwNjIwNTcyN1owIwYJKoZIhvcNAQkEMRYEFFCov//Gde6F FZSa2Xqje7GTzBHiMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA MPLEzJbj+bKhE54REedcwBj45XIq4izEy1iy75UZMPe1uHbjnvlr7Bq3JuRZe6Td6SNO/JCSupIE wbBqLQ4BdUiuq+xUyN51FVUfgJgJyLn2uDI7S5s8x21DU1mAfI7Fky8xu4za7rw0QQLNwcssGzW8 lbvlOQT6xin4WXG3dLg2Qzhoc1f8pikLabcy5kR/EZ8NE/s0O/mJxCKaDz6jDGWvgnMy8vYpwsXN uC7Xb18oYnbeIgjPtMsXjSUJ87/udh3aL8FRPz31dX9EkQE+05ONuevj0ijPb8mb/aUbVwcVzPhZ YbVbmuNRz3YJyQboSuZ8Hpq16LUEjvRzUjJZRgAAAAAAAA== ------=_NextPart_000_00FF_01CA16F1.A6A8A500-- From alexey.melnikov@isode.com Thu Aug 6 13:46:45 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F01893A6A2A for ; Thu, 6 Aug 2009 13:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvMB-hn2K6K1 for ; Thu, 6 Aug 2009 13:46:45 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 9617428C0FF for ; Thu, 6 Aug 2009 13:46:44 -0700 (PDT) Received: from [94.197.220.36] (94.197.220.36.threembb.co.uk [94.197.220.36]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 6 Aug 2009 21:46:45 +0100 Message-ID: <4A7B4124.7000807@isode.com> Date: Thu, 06 Aug 2009 21:46:28 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Stephen Hanna References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 06 Aug 2009 13:57:56 -0700 Cc: "emu@ietf.org" Subject: Re: [Emu] Issue #18: Internationalization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 20:46:46 -0000 Hi Stephen, Stephen Hanna wrote: >With respect to the internationalization issue noted below, relating >to draft-ietf-emu-eaptunnel-req-02.txt, Alexey Melnikov recently pointed >out to me that BCP 18 (RFC 2277), section 4.2 says: > > Protocols that transfer text MUST provide for carrying information > about the language of that text. > > Protocols SHOULD also provide for carrying information about the > language of names, where appropriate. > >Section 4.1 of that document explains the reason why. Here's an excerpt: > > Many operations, including high quality formatting, text-to-speech > synthesis, searching, hyphenation, spellchecking and so on benefit > greatly from access to information about the language of a piece of > text. [WC 3.1.1.4]. > >Internationalization of usernames and passwords has been discussed >at length on other lists. Nobody is suggesting in today's discussion >that they should have language tags. > Correct. UTF-8 usernames/password need some normalization instead (e.g. SASLPrep [RFC4013] or Net-UTF-8 [RFC5198]). >That is problematic since usernames >and passwords often aren't words in any language and the user often >doesn't have control over the language settings of the system being used >to enter the username and password. But the text being reviewed does not >have anything to do with username and password language issues. > >The text under discussion in draft-ietf-emu-eaptunnel-req-03.txt says >"Any strings sent by the server intended for display to the user >MUST be sent in UTF-8 format and SHOULD be able to be marked with >language information and adapted to the user's language preference." > > As a side note: this would need a reference to RFC 4646. >Notice the words "sent by the server intended for display to the user". >That would not generally apply to usernames and passwords. Instead, >it would apply to messages like "Please enter your password" or >"Sorry, you can't sign in right now due to system maintenance". > >In order to provide for proper formatting and to allow blind users >to have those messages properly converted to audio, it is a good idea >for our protocol to include a standard place where the EAP authenticator >can send language tags with such messages. It's also a good idea for >the protocol to include a way for the EAP peer to indicate what the >user's language preferences are (if known). That way, the authenticator >can send its messages in the user's preferred language (if the software >allows the administrator to enter messages in multiple languages and >the administrator has chosen to do so). > > Right. >So I submit that the text currently in draft-ietf-emu-eaptunnel-req-03.txt >on this topic is a good idea and that it should not be removed. As Joe >noted below, there was not consensus on this issue in the EMU session >at IETF 75. I suggest that we discuss it on the list. > >One concern that I heard expressed was that servers may decide to fail >the entire exchange if they don't support any of the user's preferred >languages. Apparently, some other protocols some seen this behavior when >language preferences were sent. Maybe we should add text to the eventual >protocol specification advising servers not to do that. Instead, they >should fall back to a default language. > Agreed. >Are there other concerns? > >Thanks, > >Steve > > >>-----Original Message----- >>From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On >>Behalf Of Joseph Salowey (jsalowey) >>Sent: Thursday, August 06, 2009 3:28 PM >>To: emu@ietf.org >>Subject: [Emu] Issue #18: Internationalization >> >> >>#18: Internationalization >> >> Is the use of UTF-8 sufficient or is other tagging necessary. The >> following cases need to be considered: >> >> 1. Usernames and passwords >> 2. Prompts and error associated with username and password >>authentication >> 3. Other textual data >> >> > Section 4.3.6 >> > >> > " The payload MAY provide a standard attribute format >>that supports >> > international strings. This attribute format MUST support >>encoding >> > strings in UTF-8 [RFC3629] format. Any strings sent by >>the server >> > intended for display to the user MUST be sent in UTF-8 >>format and >> > SHOULD be able to be marked with language information and >> > adapted to >> > the user's language preference." >> > >> > If UTF-8 is supported, is it necessary to also mark the language? >> > Why is language negotiation a SHOULD? >> > >> > EAP methods such as Identity & Notification don't support this. >> > >> >> and >> >> > Section 4.5.2 >> > >> > " The password authentication exchange MUST support user names and >> > passwords in international languages. It MUST support >>encoding of >> > user name and password strings in UTF-8 [RFC3629] format. Any >> > strings sent by the server during the password exchange >> > and intended >> > for display to the user MUST be sent in UTF-8 format >>and SHOULD be >> > able to be marked with language information and adapted to >> > the user's >> > language preference. >> > " >> > Why is it useful to mark usernames and passwords with >> > language information on the wire? >> >>Comment: >> >>In the Stockholm meeting it was suggested UTF-8 was sufficient, but >>there did not appear to be consensus on this. >> >>-- >>Ticket URL: >>emu >> >>_______________________________________________ >>Emu mailing list >>Emu@ietf.org >>https://www.ietf.org/mailman/listinfo/emu >> >> From shanna@juniper.net Thu Aug 6 14:11:17 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1390F3A6A70 for ; Thu, 6 Aug 2009 14:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.543 X-Spam-Level: X-Spam-Status: No, score=-6.543 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjG-mIsbY0kt for ; Thu, 6 Aug 2009 14:11:16 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 01A263A6850 for ; Thu, 6 Aug 2009 14:11:13 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSntG9AErrd1FSldZtVPEO8/UenUUxrmv@postini.com; Thu, 06 Aug 2009 14:11:19 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 6 Aug 2009 14:06:51 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 6 Aug 2009 17:06:51 -0400 From: Stephen Hanna To: Yaron Sheffer , "Joseph Salowey (jsalowey)" , "emu@ietf.org" Date: Thu, 6 Aug 2009 17:06:10 -0400 Thread-Topic: Issue #21: Mandatory Vs. Optional Thread-Index: AcoWz4aXb4eS6mhYTRqAvHPjDprjxQAAbf7QAAGN4mAAAHg5MA== Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E56C7784@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E56C7784@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Emu] Issue #21: Mandatory Vs. Optional X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 21:11:17 -0000 I agree with Yaron. Being able to define optional IETF standard attributes is also useful since you sometimes DON'T want to fail the negotiation if the other side doesn't understand the extension. So optional/mandatory is orthogonal to standard/vendor-defined. Thanks, Steve > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On=20 > Behalf Of Yaron Sheffer > Sent: Thursday, August 06, 2009 4:52 PM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: Re: [Emu] Issue #21: Mandatory Vs. Optional >=20 > I support the current text. Having explicit marking for=20 > mandatory attributes > (a "Critical bit") adds power to protocol extensions, in that=20 > you can ensure > that negotiation will fail if the other side doesn't understand you. >=20 > Thanks, > Yaron >=20 > > -----Original Message----- > > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On=20 > Behalf Of > > Joseph Salowey (jsalowey) > > Sent: Thursday, August 06, 2009 23:06 > > To: emu@ietf.org > > Subject: [Emu] Issue #21: Mandatory Vs. Optional > >=20 > >=20 > > #21: Mandatory Vs. Optional > >=20 > > > Section 4.3.3 > > > > > > " The payload MUST support marking of mandatory and optional > > > attributes, as well as an attribute used for=20 > rejecting mandatory > > > attributes." > > > > > > Why is it necessary for mandatory and optional attributes to > > > be explicitly marked? Is it be sufficient for the attributes > > > to be divided into standardized and vendor-specific spaces, > > > with the latter optional? > > > > >=20 > > -- > > Ticket URL: > > emu > >=20 > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu > >=20 > > Scanned by Check Point Total Security Gateway. > = From jsalowey@cisco.com Thu Aug 6 14:26:21 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D1D53A694E for ; Thu, 6 Aug 2009 14:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fU9f6OcCQoOh for ; Thu, 6 Aug 2009 14:26:20 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 21D493A6850 for ; Thu, 6 Aug 2009 14:26:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAvnekqrR7MV/2dsb2JhbAC5PogqkB8FhBg X-IronPort-AV: E=Sophos;i="4.43,336,1246838400"; d="scan'208";a="224611822" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 06 Aug 2009 21:26:23 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n76LQNU5005238; Thu, 6 Aug 2009 14:26:23 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n76LQNiH020656; Thu, 6 Aug 2009 21:26:23 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 14:26:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Aug 2009 14:26:21 -0700 Message-ID: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E56C7785@il-ex01.ad.checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #22: Collection of smaller issues Thread-Index: AcoW0TnWwitTTVzbQIWGnZOkXkD4zQAALKbAAAGSz7AAAPXaAA== References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E56C7785@il-ex01.ad.checkpoint.com> From: "Joseph Salowey (jsalowey)" To: "Yaron Sheffer" , X-OriginalArrivalTime: 06 Aug 2009 21:26:23.0169 (UTC) FILETIME=[8C0BF310:01CA16DC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1448; t=1249593983; x=1250457983; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20Issue=20#22=3A=20Collection=20of=20smal ler=20issues |Sender:=20; bh=LiadTuIeEq45X+1SLffRK13yGXKcJC5DUstgL6PqxkE=; b=KxKv0itj9knrfgj6FHpinJN/A27qHzF+Hm8UrlvE7WLyfTMdukKvd6txE5 X7oFNKUFib1D17ha7G4jE2RlPAFNIF08vZlsHubSFTz6UIzBXJRKMV/CnFW5 v6UrHGpjsswl6/Bko1u6b4zc7gIByIfYg8sQDbqTv4xr+JLIL+ZYo=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Emu] Issue #22: Collection of smaller issues X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 21:26:21 -0000 In section 3.7 we say: "The tunnel method MUST be capable of providing client side authentication during tunnel establishment." So the tunnel MUST be capable of proving mutual authentication. Does the text need modification? Joe=20 > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf@checkpoint.com]=20 > Sent: Thursday, August 06, 2009 1:57 PM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: Issue #22: Collection of smaller issues >=20 > [snip] > >=20 > > > Section 4.2.1.1.3 > > > > > > " A tunnel method MUST provide unidirectional=20 > authentication from > > > authentication server to EAP peer or mutual=20 > authentication between > > > authentication server and EAP peer." > > > > > > Is this really an or? For example, would a tunnel=20 > method > that=20 > > only supports undirectional authentication satisfy the >=20 > requirement? > > > > >=20 > > It should be "and" > >=20 > [YS] Why? This is discussing the "outer" method, which may=20 > indeed provide only unidirectional auth. >=20 > Thanks, > Yaron > > -- > > Ticket URL: > > emu > >=20 > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu > >=20 > > Scanned by Check Point Total Security Gateway. >=20 From yaronf@checkpoint.com Thu Aug 6 14:42:14 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C730B3A6E07 for ; Thu, 6 Aug 2009 14:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxeU2kumYR+e for ; Thu, 6 Aug 2009 14:42:13 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id AB8873A6AC8 for ; Thu, 6 Aug 2009 14:42:12 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 23DF229C036; Fri, 7 Aug 2009 00:42:34 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id C940F29C025; Fri, 7 Aug 2009 00:42:33 +0300 (IDT) X-CheckPoint: {4A7B4C6B-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n76LgD3d024408; Fri, 7 Aug 2009 00:42:13 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Fri, 7 Aug 2009 00:42:13 +0300 From: Yaron Sheffer To: "Joseph Salowey (jsalowey)" , "emu@ietf.org" Date: Fri, 7 Aug 2009 00:42:11 +0300 Thread-Topic: Issue #22: Collection of smaller issues Thread-Index: AcoW0TnWwitTTVzbQIWGnZOkXkD4zQAALKbAAAGSz7AAAPXaAAAAcbRQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E56C7787@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E56C7785@il-ex01.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0104_01CA16F7.E67CEB40" MIME-Version: 1.0 Subject: Re: [Emu] Issue #22: Collection of smaller issues X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 21:42:14 -0000 ------=_NextPart_000_0104_01CA16F7.E67CEB40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yes, you are right. Yaron > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Friday, August 07, 2009 0:26 > To: Yaron Sheffer; emu@ietf.org > Subject: RE: Issue #22: Collection of smaller issues > > In section 3.7 we say: > > "The tunnel method MUST be > capable of providing client side authentication during tunnel > establishment." > > So the tunnel MUST be capable of proving mutual authentication. Does > the text need modification? > > Joe > > > -----Original Message----- > > From: Yaron Sheffer [mailto:yaronf@checkpoint.com] > > Sent: Thursday, August 06, 2009 1:57 PM > > To: Joseph Salowey (jsalowey); emu@ietf.org > > Subject: RE: Issue #22: Collection of smaller issues > > > > [snip] > > > > > > > Section 4.2.1.1.3 > > > > > > > > " A tunnel method MUST provide unidirectional > > authentication from > > > > authentication server to EAP peer or mutual > > authentication between > > > > authentication server and EAP peer." > > > > > > > > Is this really an or? For example, would a tunnel > > method > that > > > only supports undirectional authentication satisfy the > > > requirement? > > > > > > > > > > It should be "and" > > > > > [YS] Why? This is discussing the "outer" method, which may > > indeed provide only unidirectional auth. > > > > Thanks, > > Yaron > > > -- > > > Ticket URL: > > > emu > > > > > > _______________________________________________ > > > Emu mailing list > > > Emu@ietf.org > > > https://www.ietf.org/mailman/listinfo/emu > > > > > > Scanned by Check Point Total Security Gateway. > > > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0104_01CA16F7.E67CEB40 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgwNjIxNDIxMVowIwYJKoZIhvcNAQkEMRYEFBghcA9+rybx ur4PKv2rJCyy1uI0MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA mpTumswWFeoXCk182RSbU78vfdv6lGHo2fhPjsvrfwGC5NzScdEQWIdusqDHPMGDKEekl0WMNd6+ e5+u/+EmRNoidZhtrOhnEpewIUiev6UG8dZgXbCOVEighdWC41zW0r/wF5D1aM29y4nPZbyoRMRQ ExioKMex1jjcmq3eRlLTLwTIakggl9NntqVd32exilZ7eVwfys3POuaY8frFnrZMrLoaWVilx0FO QDMGhPOTBWrWie/xpJ+foSSHQxdDN2YOjx2rziv0+7ySPwqByMlx6GjqEiK5CICZ9aMHtTJ5OPBc 7qQ2MRzRiK+XivSffPCZbniw3cyKOR1DeWyetgAAAAAAAA== ------=_NextPart_000_0104_01CA16F7.E67CEB40-- From yaronf@checkpoint.com Thu Aug 6 15:04:43 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A8593A6D92 for ; Thu, 6 Aug 2009 15:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qB9i+5sws9P2 for ; Thu, 6 Aug 2009 15:04:42 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 856173A6D8C for ; Thu, 6 Aug 2009 15:04:41 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 3DBE929C036; Fri, 7 Aug 2009 01:05:03 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id E490729C025; Fri, 7 Aug 2009 01:05:02 +0300 (IDT) X-CheckPoint: {4A7B51B0-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n76M4g3d029410; Fri, 7 Aug 2009 01:04:43 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Fri, 7 Aug 2009 01:04:42 +0300 From: Yaron Sheffer To: "Joseph Salowey (jsalowey)" , "emu@ietf.org" Date: Fri, 7 Aug 2009 01:04:39 +0300 Thread-Topic: Issue #14 Emergency auth Thread-Index: AcoWygz7SUqy1ZFxRmuwSIaYjBW3YQAFrKsA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E56C7788@il-ex01.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0109_01CA16FB.09C24750" MIME-Version: 1.0 Subject: Re: [Emu] Issue #14 Emergency auth X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 22:04:43 -0000 ------=_NextPart_000_0109_01CA16FB.09C24750 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The contract between the authenticator and the EAP layer is, when I see an EAP Success message, it means that both sides are authenticated. We are now breaking this contract, so it makes sense to have EAP inform the upper layer of this fact. But I suppose EAP is not extensible enough to add such semantics. Sigh. Thanks, Yaron > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of > Joseph Salowey (jsalowey) > Sent: Thursday, August 06, 2009 22:14 > To: emu@ietf.org > Subject: [Emu] Issue #14 Emergency auth > > > > Referring to Sec. 3.5 of > http://tools.ietf.org/html/draft-ietf-emu-eaptunnel-req-03, there should > be an indication to the application that is using EAP > that such > "strange" authentication took place. For example, the VoIP server may > than make sure that only calls to 911 or 112 are allowed. Otherwise > > there is no way to authorize the user without some backchannel into > the AAA. > > > > So I propose to add: > > > "The tunnel method, if it supports emergency services, MUST provide an > indication at the EAP or EAP-method level that such authentication took > place; > > > the indication MUST be unencrypted but integrity protected". > > I don't understand what this text is for? Who is this indication for? > An application should not be sniffing EAP packets to see what happens. > It seems that this is the responsibility of a local API between the EAP > server and the application. > > > Joe > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0109_01CA16FB.09C24750 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgwNjIyMDQzOFowIwYJKoZIhvcNAQkEMRYEFHjknNuPjOXU R7jz17zA9zKOIQi0MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA peJCHyJz8ySCZ16RmptlkOFj0kvCXA3JcGi8whCqu/4qZYKeb1xT+sWIJ2qvqdY+oDFkmtW8XJ5L Qfa3FGfBbjbdM8KTGIEChVfzhoScBmwPojYlmjIwHGQfZNLwpGtq+J0K+uJQB+ecx132e6TXJPsv qADipjcwfSM3kYpMbg6Z7gUB0joqVCghzCTqd0ygvw8I59h67TfT0coxCQnZGh/ZJmJ/Qik2NPtZ IfFRMnV2it7P6cMCN4ROLuwZU6l+V9F50pHyv69tNIjhzrMhHRT7xRKOwEAdSUsxC+02uohT7c+h mFNcueFakA0niq8trgmEfbEcDqYO2eXzTb88fAAAAAAAAA== ------=_NextPart_000_0109_01CA16FB.09C24750-- From jsalowey@cisco.com Thu Aug 6 16:36:14 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2861328C0FC for ; Thu, 6 Aug 2009 16:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7+E5yaGdUuX for ; Thu, 6 Aug 2009 16:36:13 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3A1F128C0EE for ; Thu, 6 Aug 2009 16:36:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEEGe0qrR7MV/2dsb2JhbAC5KIgqkCUFgjIFgWE X-IronPort-AV: E=Sophos;i="4.43,337,1246838400"; d="scan'208";a="362166717" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 06 Aug 2009 23:36:15 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n76NaGSf025875; Thu, 6 Aug 2009 16:36:16 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n76NaG31025433; Thu, 6 Aug 2009 23:36:16 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 16:36:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Aug 2009 16:36:14 -0700 Message-ID: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E56C7788@il-ex01.ad.checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #14 Emergency auth Thread-Index: AcoWygz7SUqy1ZFxRmuwSIaYjBW3YQAFrKsAAAM+WNA= References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E56C7788@il-ex01.ad.checkpoint.com> From: "Joseph Salowey (jsalowey)" To: "Yaron Sheffer" , X-OriginalArrivalTime: 06 Aug 2009 23:36:16.0379 (UTC) FILETIME=[B1296CB0:01CA16EE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2554; t=1249601776; x=1250465776; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20Issue=20#14=20Emergency=20auth |Sender:=20; bh=XpWfmcwrBzHwudWwncHFuvcn2MAT6HCaK4bOfJNJ2sw=; b=oQ3SB6YGObytUdbNa5bcvVRu3hEseXduuZoulGNqgHRetw/qCytV69gt/+ 9XLfo3btVECE/SDwxli4Yg/pOQ1gBewMaNpyBei3NqokmGCPQVkkYM0ff2Oa DUFAKJYiXB706sw+zwtk9k/eAjNdz4aztYhO/piz6CHvSkkG/XS3g=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Emu] Issue #14 Emergency auth X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 23:36:14 -0000 Often, there is a richer interface between EAP and the authenticator. For example in an Access-Accept message from RADIUS a number of things can be communicated about the authentication including the identity of the authenticated peer. I also don't think that EAP-Success necessarily implies mutual authentication, it just says that the EAP server is satisfied with the result of the process.=20 Joe > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf@checkpoint.com]=20 > Sent: Thursday, August 06, 2009 3:05 PM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: Issue #14 Emergency auth >=20 > The contract between the authenticator and the EAP layer is,=20 > when I see an EAP Success message, it means that both sides=20 > are authenticated. We are now breaking this contract, so it=20 > makes sense to have EAP inform the upper layer of this fact. >=20 > But I suppose EAP is not extensible enough to add such=20 > semantics. Sigh. >=20 > Thanks, > Yaron >=20 > > -----Original Message----- > > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On=20 > Behalf Of=20 > > Joseph Salowey (jsalowey) > > Sent: Thursday, August 06, 2009 22:14 > > To: emu@ietf.org > > Subject: [Emu] Issue #14 Emergency auth > >=20 > >=20 > > > Referring to Sec. 3.5 of > > http://tools.ietf.org/html/draft-ietf-emu-eaptunnel-req-03, there=20 > > should be an indication to the application that is using EAP > that=20 > > such "strange" authentication took place. For example, the=20 > VoIP server=20 > > may than make sure that only calls to 911 or 112 are allowed.=20 > > Otherwise > > > there is no way to authorize the user without some=20 > backchannel into > > the AAA. > > > > > > So I propose to add: > >=20 > > > "The tunnel method, if it supports emergency services,=20 > MUST provide=20 > > > an > > indication at the EAP or EAP-method level that such authentication=20 > > took place; > > > > the indication MUST be unencrypted but integrity protected". > >=20 > > I don't understand what this text is for? Who is this=20 > indication for? > > An application should not be sniffing EAP packets to see=20 > what happens. > > It seems that this is the responsibility of a local API between the=20 > > EAP server and the application. > >=20 > >=20 > > Joe > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu > >=20 > > Scanned by Check Point Total Security Gateway. >=20 From alper.yegin@yegin.org Fri Aug 7 06:30:55 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33D963A6D04 for ; Fri, 7 Aug 2009 06:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.959 X-Spam-Level: X-Spam-Status: No, score=0.959 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQNc5sVmoNSB for ; Fri, 7 Aug 2009 06:30:51 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id C1CAB3A6A66 for ; Fri, 7 Aug 2009 06:30:51 -0700 (PDT) Received: from LENOVO (dsl.static.85-105-43069.ttnet.net.tr [85.105.168.61]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1MZPX207Qy-0001In; Fri, 07 Aug 2009 09:30:53 -0400 From: "Alper Yegin" To: Date: Fri, 7 Aug 2009 16:30:49 +0300 Message-ID: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_012E_01CA177C.6EB74AD0" X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcoXY0bvU1SkoJktTJ64sMyZV/eh5w== Content-Language: en-us X-Provags-ID: V01U2FsdGVkX18A3wqNbPOz/Ws5c3oSXZ88psyUBvbx1xoFPqP MqILE2NrJgOBRUVRTKGL0hDfkEc92/UemPQlsVBLIQErR2O/wC xvxeAH6WaX4jv2b2AYAtw== Subject: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 13:30:55 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_012E_01CA177C.6EB74AD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This issue came up during the last IETF meeting when the WG discussed channel binding. Pasi said the discussion was within the scope of EMU WG charter. - A document that defines EAP channel bindings and provides guidance for establishing EAP channel bindings within EAP methods. - A mechanism to support extensible communication within a TLS protected tunnel. I'm not against this. But let's face it, this is venturing into dealing with authorization parameters with EAP (EAP layer? EAP method layer? Etc.) I'm not against that either. In fact, I know there are a lot of people who'd be happy to see that happen. So, my question is, is this what we are doing: Enabling EAP to exchange authorization parameters among the EAP peer - authenticator - authentication server? If not, I hope someone can explain how this is different than what it takes to solve channel binding problem. Thanks. Alper ------=_NextPart_000_012E_01CA177C.6EB74AD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This issue came up during the last IETF meeting = when the WG discussed channel binding.

 

Pasi said the discussion was within the scope of = EMU WG charter.

 

- A document that = defines EAP channel bindings and provides guidance
for establishing EAP channel bindings within EAP methods.

 

 

- A mechanism to support = extensible communication within a TLS
protected tunnel.

 

 

I’m not against this. But let’s face = it, this is venturing into dealing with authorization parameters with EAP (EAP = layer? EAP method layer? Etc.) I’m not against that either. In fact, I know = there are a lot of people who’d be happy to see that happen. =

 

So, my question is, is this what we are doing: = Enabling EAP to exchange authorization parameters among the EAP peer – = authenticator – authentication server? If not, I hope someone can explain how this is = different than what it takes to solve channel binding problem.

 

Thanks.

 

Alper

 

 

------=_NextPart_000_012E_01CA177C.6EB74AD0-- From bernard_aboba@hotmail.com Mon Aug 10 00:08:38 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DC5A28C0CF for ; Mon, 10 Aug 2009 00:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.164 X-Spam-Level: X-Spam-Status: No, score=0.164 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hb-pQKI9Cdkq for ; Mon, 10 Aug 2009 00:08:37 -0700 (PDT) Received: from blu0-omc3-s2.blu0.hotmail.com (blu0-omc3-s2.blu0.hotmail.com [65.55.116.77]) by core3.amsl.com (Postfix) with ESMTP id 4DEFB28B56A for ; Mon, 10 Aug 2009 00:08:37 -0700 (PDT) Received: from BLU137-W4 ([65.55.116.72]) by blu0-omc3-s2.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 00:08:41 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_43046a23-f4df-4f0b-8f59-a18682f49e88_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: Date: Mon, 10 Aug 2009 00:08:41 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 10 Aug 2009 07:08:41.0200 (UTC) FILETIME=[63F9A700:01CA1989] Subject: Re: [Emu] #18 Internationalization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 07:08:38 -0000 --_43046a23-f4df-4f0b-8f59-a18682f49e88_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Joe Salowey said: "#18: Internationalization Is the use of UTF-8 sufficient or is other tagging necessary. The following cases need to be considered: 1. Usernames and passwords 2. Prompts and error associated with username and password authentication 3. Other textual data " It's important to keep in mind that this is a tunnel method requirements do= cument. The tunnel method will use TLS=2C so as far as bringing up the tun= nel is concerned=2C it is TLS internationalization that is relevant here. = With respect to inner authentication methods=2C it is the internationalizat= ion support of the inner method that matters.=20 Given this=2C what exactly is within the purview of the tunnel method with = respect to internationalization? Clearly=2C the EMU WG is not chartered to= change EAP itself=2C TLS or existing EAP methods. =20 Given that=2C what *exactly* does this requirement refer to? While it's c= ertainly possible for a tunnel method to do language negotiation=2C given t= hat such a negotiation wouldn't affect most of what goes on in the method (= e.g. TLS or the inner method)=2C I don't see what good it would do.=20 --_43046a23-f4df-4f0b-8f59-a18682f49e88_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Joe Salowey said:

"
#18: Internationalization

 Is the use=
 of UTF-8 sufficient or is other tagging necessary.  The
 following case=
s need to be considered:

 1. Usernames and passwords
 2. Prompts =
and error associated with username and password
authentication
 3. Ot=
her textual data
"

It's important to keep in mind that this= is a tunnel method requirements document. =3B The tunnel method will u= se TLS=2C so as far as bringing up the tunnel is concerned=2C it is TLS int= ernationalization that is relevant here. =3B With respect to inner auth= entication methods=2C it is the internationalization support of the inner m= ethod that matters.

Given this=2C what exactly is within the purvie= w of the tunnel method with respect to internationalization? =3B Clearl= y=2C the EMU WG is not chartered to change EAP itself=2C TLS or existing EA= P methods. =3B

Given that=2C what *exactly* does this requireme= nt refer to? =3B =3B While it's certainly possible for a tunnel met= hod to do language negotiation=2C given that such a negotiation wouldn't af= fect most of what goes on in the method (e.g. TLS or the inner method)=2C I= don't see what good it would do.




= --_43046a23-f4df-4f0b-8f59-a18682f49e88_-- From aland@deployingradius.com Tue Aug 11 09:28:00 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7DA03A6CE2 for ; Tue, 11 Aug 2009 09:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rH5i3-LDcnoA for ; Tue, 11 Aug 2009 09:28:00 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 10B783A6F70 for ; Tue, 11 Aug 2009 09:28:00 -0700 (PDT) Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 20274123443A; Tue, 11 Aug 2009 18:26:58 +0200 (CEST) Message-ID: <4A819BD1.90802@deployingradius.com> Date: Tue, 11 Aug 2009 18:26:57 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Alper Yegin References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org> In-Reply-To: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 16:28:01 -0000 Alper Yegin wrote: > I’m not against this. But let’s face it, this is venturing into dealing > with authorization parameters with EAP (EAP layer? EAP method layer? > Etc.) I’m not against that either. In fact, I know there are a lot of > people who’d be happy to see that happen. Prior to authentication, EAP is the only communications protocol between a supplicant and *anywhere* on the network. It is therefore natural to overload it as a general purpose transport protocol. > So, my question is, is this what we are doing: Enabling EAP to exchange > authorization parameters among the EAP peer – authenticator – > authentication server? If not, I hope someone can explain how this is > different than what it takes to solve channel binding problem. I believe that is what is happening: authorization parameters are being exchanged in EAP. This should be made clearer in the documents. Alan DeKok. From glenzorn@comcast.net Tue Aug 11 11:28:34 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A90E3A6DD6 for ; Tue, 11 Aug 2009 11:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vgr4oWJYHc0P for ; Tue, 11 Aug 2009 11:28:33 -0700 (PDT) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id C5BF43A69BA for ; Tue, 11 Aug 2009 11:28:33 -0700 (PDT) Received: from OMTA20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id T3U31c00B1smiN4A35x5gc; Tue, 11 Aug 2009 17:57:05 +0000 Received: from gwzPC ([71.231.55.1]) by OMTA20.emeryville.ca.mail.comcast.net with comcast id T5x41c00101ae1j8g5x4EX; Tue, 11 Aug 2009 17:57:04 +0000 From: "Glen Zorn" To: "'Alan DeKok'" , "'Alper Yegin'" References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org> <4A819BD1.90802@deployingradius.com> In-Reply-To: <4A819BD1.90802@deployingradius.com> Date: Tue, 11 Aug 2009 10:56:38 -0700 Message-ID: <008f01ca1aad$137353b0$3a59fb10$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoaoLbziHRirRbVSUqQu8BoFIEd7gAC31bg Content-Language: en-us Cc: emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 18:28:34 -0000 Alan DeKok [mailto://aland@deployingradius.com] writes: > Alper Yegin wrote: > > I=E2=80=99m not against this. But let=E2=80=99s face it, this is = venturing into > dealing > > with authorization parameters with EAP (EAP layer? EAP method layer? > > Etc.) I=E2=80=99m not against that either. In fact, I know there are = a lot of > > people who=E2=80=99d be happy to see that happen. >=20 > Prior to authentication, EAP is the only communications protocol > between a supplicant and *anywhere* on the network. It is therefore > natural to overload it as a general purpose transport protocol. To transport what, exactly? >=20 > > So, my question is, is this what we are doing: Enabling EAP to > exchange > > authorization parameters among the EAP peer =E2=80=93 authenticator = =E2=80=93 > > authentication server? If not, I hope someone can explain how this = is > > different than what it takes to solve channel binding problem. >=20 > I believe that is what is happening: authorization parameters are > being exchanged in EAP. This should be made clearer in the documents. Above you said "Prior to authentication, EAP is the only communications = protocol between a supplicant and *anywhere* on the network" by way of = rationalizing the use of EAP "as a general purpose transport protocol". = I could have sworn that authorization _follows_ and is parameterized by = authentication. So, please tell me again why EAP should be (further) = bastardized for this purpose. From aland@deployingradius.com Tue Aug 11 11:51:16 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C43B13A6ED9 for ; Tue, 11 Aug 2009 11:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqnrFkcLwpxo for ; Tue, 11 Aug 2009 11:51:16 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id F1C1F3A6DB4 for ; Tue, 11 Aug 2009 11:51:15 -0700 (PDT) Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id AFBB7123443A; Tue, 11 Aug 2009 20:36:28 +0200 (CEST) Message-ID: <4A81BA2B.1090400@deployingradius.com> Date: Tue, 11 Aug 2009 20:36:27 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Glen Zorn References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org> <4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net> In-Reply-To: <008f01ca1aad$137353b0$3a59fb10$@net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 18:51:16 -0000 Glen Zorn wrote: > Alan DeKok [mailto://aland@deployingradius.com] writes: ... >> Prior to authentication, EAP is the only communications protocol >> between a supplicant and *anywhere* on the network. It is therefore >> natural to overload it as a general purpose transport protocol. > > To transport what, exactly? The data discussed in the tunnel requirements draft, Section 3.6. Among others. >> I believe that is what is happening: authorization parameters are >> being exchanged in EAP. This should be made clearer in the documents. > > Above you said ... by way of rationalizing "explaining" The two are very different. > the use of EAP "as a general purpose transport protocol". I could have > sworn that authorization _follows_ and is parameterized by authentication. I agree. I haven't seen any proposal that contradicts this. > So, please tell me again why EAP should be (further) bastardized for this purpose. People are proposing it because they find it useful. This isn't mean it's a good idea, just that it's one that has real-world uses. My message about this topic was intended to foster discussion. If there is strong objection to the idea, we can refuse to "bastardize" EAP. If there is strong consensus that this is necessary, it's best to make it explicit in the documents. Alan DeKok. From shanna@juniper.net Tue Aug 11 12:09:46 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 627EC3A6DD3 for ; Tue, 11 Aug 2009 12:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WC-38HfIi-A for ; Tue, 11 Aug 2009 12:09:45 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 7E7CE3A7019 for ; Tue, 11 Aug 2009 12:09:11 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSoHBaBaa02nuhUF5hyXHYzySgK1nV6SB@postini.com; Tue, 11 Aug 2009 12:09:18 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 11 Aug 2009 12:03:47 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 11 Aug 2009 15:03:47 -0400 From: Stephen Hanna To: Alan DeKok , Glen Zorn Date: Tue, 11 Aug 2009 15:02:54 -0400 Thread-Topic: [Emu] EAP and authorization Thread-Index: AcoatLlCAszI8sGKTRmcw+oJ4tpQrAAALHMw Message-ID: References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org> <4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net> <4A81BA2B.1090400@deployingradius.com> In-Reply-To: <4A81BA2B.1090400@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "emu@ietf.org" Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 19:09:46 -0000 Network Endpoint Assessment (NEA) messages can be considered authorization data. Certainly, they're not authentication. They convey information about endpoint posture (like whether anti-virus software is installed and enabled). Yet they are carried in EAP messages every day, generally in tunnel methods. I don't think there's anything wrong with this practice. In fact, it's the best way to ensure that a NEA assessment is performed before network access is granted. I wouldn't say that EAP is becoming a "general purpose" transport protocol. EAP has many limitations that make it a poor choice for most situations that need a transport protocol. However, for some purposes it is a good match. NEA is one of those purposes. Thanks, Steve > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On=20 > Behalf Of Alan DeKok > Sent: Tuesday, August 11, 2009 2:36 PM > To: Glen Zorn > Cc: emu@ietf.org > Subject: Re: [Emu] EAP and authorization >=20 > Glen Zorn wrote: > > Alan DeKok [mailto://aland@deployingradius.com] writes: > ... > >> Prior to authentication, EAP is the only communications protocol > >> between a supplicant and *anywhere* on the network. It is=20 > therefore > >> natural to overload it as a general purpose transport protocol. > >=20 > > To transport what, exactly? >=20 > The data discussed in the tunnel requirements draft, Section 3.6. > Among others. >=20 > >> I believe that is what is happening: authorization parameters are > >> being exchanged in EAP. This should be made clearer in=20 > the documents. > >=20 > > Above you said ... by way of rationalizing >=20 > "explaining" >=20 > The two are very different. >=20 > > the use of EAP "as a general purpose transport protocol". =20 > I could have > > sworn that authorization _follows_ and is parameterized by=20 > authentication. >=20 > I agree. I haven't seen any proposal that contradicts this. >=20 > > So, please tell me again why EAP should be (further)=20 > bastardized for this purpose. >=20 > People are proposing it because they find it useful. This=20 > isn't mean > it's a good idea, just that it's one that has real-world uses. >=20 > My message about this topic was intended to foster discussion. If > there is strong objection to the idea, we can refuse to "bastardize" > EAP. If there is strong consensus that this is necessary,=20 > it's best to > make it explicit in the documents. >=20 > Alan DeKok. > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > = From glenzorn@comcast.net Tue Aug 11 13:27:44 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C0B53A6B72 for ; Tue, 11 Aug 2009 13:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewelvXL3EDgo for ; Tue, 11 Aug 2009 13:27:43 -0700 (PDT) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by core3.amsl.com (Postfix) with ESMTP id 1CD2A3A6917 for ; Tue, 11 Aug 2009 13:27:42 -0700 (PDT) Received: from OMTA15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id T49P1c0041Y3wxoA88NX7R; Tue, 11 Aug 2009 20:22:31 +0000 Received: from gwzPC ([71.231.55.1]) by OMTA15.emeryville.ca.mail.comcast.net with comcast id T8NW1c00C01ae1j8b8NXMX; Tue, 11 Aug 2009 20:22:31 +0000 From: "Glen Zorn" To: "'Alan DeKok'" References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org> <4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net> <4A81BA2B.1090400@deployingradius.com> In-Reply-To: <4A81BA2B.1090400@deployingradius.com> Date: Tue, 11 Aug 2009 13:22:04 -0700 Message-ID: <00c201ca1ac1$64b9f800$2e2de800$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acoasqiu621ufxpGTRex8HWnRlMLhgADXykA Content-Language: en-us Cc: emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 20:27:44 -0000 Alan DeKok [mailto:aland@deployingradius.com] writes: > Glen Zorn wrote: > > Alan DeKok [mailto://aland@deployingradius.com] writes: > ... > >> Prior to authentication, EAP is the only communications protocol > >> between a supplicant and *anywhere* on the network. It is = therefore > >> natural to overload it as a general purpose transport protocol. > > > > To transport what, exactly? >=20 > The data discussed in the tunnel requirements draft, Section 3.6. Since that section is the only one that specifically mentions support = for network configuration control (I won't stoop to claiming that NEA = has any relation to security) rather than authentication, perhaps it = should be removed. > Among others. What others? >=20 > >> I believe that is what is happening: authorization parameters are > >> being exchanged in EAP. This should be made clearer in the > documents. > > > > Above you said ... by way of rationalizing >=20 > "explaining" >=20 > The two are very different. >=20 > > the use of EAP "as a general purpose transport protocol". I could > have > > sworn that authorization _follows_ and is parameterized by > authentication. >=20 > I agree. I haven't seen any proposal that contradicts this. >=20 > > So, please tell me again why EAP should be (further) bastardized for > this purpose. >=20 > People are proposing it because they find it useful. This isn't = mean > it's a good idea, just that it's one that has real-world uses. >=20 > My message about this topic was intended to foster discussion. =20 Success! > If > there is strong objection to the idea, we can refuse to "bastardize" > EAP. If there is strong consensus that this is necessary, it's best = to > make it explicit in the documents. More likely the creation of a new protocol, unless "convenience" (a word = that is used often in the draft as (often the only) justification for = bizarre additions to EAP) has taken precedence over engineering in this = WG. >=20 > Alan DeKok. From glenzorn@comcast.net Tue Aug 11 13:39:54 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ACFF3A6B72 for ; Tue, 11 Aug 2009 13:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCnatAoHyfzO for ; Tue, 11 Aug 2009 13:39:53 -0700 (PDT) Received: from QMTA14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by core3.amsl.com (Postfix) with ESMTP id 224593A6922 for ; Tue, 11 Aug 2009 13:39:30 -0700 (PDT) Received: from OMTA20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by QMTA14.emeryville.ca.mail.comcast.net with comcast id T8VU1c0011smiN4AE8eCyH; Tue, 11 Aug 2009 20:38:12 +0000 Received: from gwzPC ([71.231.55.1]) by OMTA20.emeryville.ca.mail.comcast.net with comcast id T8de1c00501ae1j8g8dojY; Tue, 11 Aug 2009 20:37:54 +0000 From: "Glen Zorn" To: "'Stephen Hanna'" , "'Alan DeKok'" References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org> <4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net> <4A81BA2B.1090400@deployingradius.com> In-Reply-To: Date: Tue, 11 Aug 2009 13:37:12 -0700 Message-ID: <00c301ca1ac3$8a0af800$9e20e800$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoatLlCAszI8sGKTRmcw+oJ4tpQrAAALHMwAAM71BA= Content-Language: en-us Cc: emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 20:39:54 -0000 Stephen Hanna [mailto:shanna@juniper.net] writes: > Network Endpoint Assessment (NEA) messages can be considered > authorization data. They can, in the broadest sense of authorization as policy enforcement. It has almost nothing to do with actual security, but that's OK, I guess. > Certainly, they're not authentication. Certainly not. > They convey information about endpoint posture (like whether > anti-virus software is installed and enabled). Yet they are > carried in EAP messages every day, generally in tunnel methods. So is the argument "Juniper (& presumably Cisco) have already bastardized EAP, so we must rubberstamp it"? > > I don't think there's anything wrong with this practice. > In fact, it's the best way to ensure that a NEA assessment > is performed before network access is granted. Hmm. Has another way been tried or is it the best way because it's the easiest (or only) way we've tried? > > I wouldn't say that EAP is becoming a "general purpose" > transport protocol. EAP has many limitations that make > it a poor choice for most situations that need a > transport protocol. However, for some purposes it > is a good match. NEA is one of those purposes. Except for that whole pesky name & purpose thing -- you know, Extensible _Authentication_ Protocol. > > Thanks, > > Steve > > > -----Original Message----- > > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On > > Behalf Of Alan DeKok > > Sent: Tuesday, August 11, 2009 2:36 PM > > To: Glen Zorn > > Cc: emu@ietf.org > > Subject: Re: [Emu] EAP and authorization > > > > Glen Zorn wrote: > > > Alan DeKok [mailto://aland@deployingradius.com] writes: > > ... > > >> Prior to authentication, EAP is the only communications protocol > > >> between a supplicant and *anywhere* on the network. It is > > therefore > > >> natural to overload it as a general purpose transport protocol. > > > > > > To transport what, exactly? > > > > The data discussed in the tunnel requirements draft, Section 3.6. > > Among others. > > > > >> I believe that is what is happening: authorization parameters > are > > >> being exchanged in EAP. This should be made clearer in > > the documents. > > > > > > Above you said ... by way of rationalizing > > > > "explaining" > > > > The two are very different. > > > > > the use of EAP "as a general purpose transport protocol". > > I could have > > > sworn that authorization _follows_ and is parameterized by > > authentication. > > > > I agree. I haven't seen any proposal that contradicts this. > > > > > So, please tell me again why EAP should be (further) > > bastardized for this purpose. > > > > People are proposing it because they find it useful. This > > isn't mean > > it's a good idea, just that it's one that has real-world uses. > > > > My message about this topic was intended to foster discussion. If > > there is strong objection to the idea, we can refuse to "bastardize" > > EAP. If there is strong consensus that this is necessary, > > it's best to > > make it explicit in the documents. > > > > Alan DeKok. > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu > > From shanna@juniper.net Tue Aug 11 14:06:28 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15D6E28C11F for ; Tue, 11 Aug 2009 14:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWhzA7l5uSIL for ; Tue, 11 Aug 2009 14:06:27 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 4245128C117 for ; Tue, 11 Aug 2009 14:06:25 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSoHc8j72jcYXlM5ndID0Sqfw7EoNOQwr@postini.com; Tue, 11 Aug 2009 14:06:31 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 11 Aug 2009 14:00:46 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 11 Aug 2009 17:00:45 -0400 From: Stephen Hanna To: Glen Zorn , 'Alan DeKok' Date: Tue, 11 Aug 2009 16:59:53 -0400 Thread-Topic: [Emu] EAP and authorization Thread-Index: Acoasqiu621ufxpGTRex8HWnRlMLhgADXykAAADFFYA= Message-ID: References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org> <4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net> <4A81BA2B.1090400@deployingradius.com> <00c201ca1ac1$64b9f800$2e2de800$@net> In-Reply-To: <00c201ca1ac1$64b9f800$2e2de800$@net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "emu@ietf.org" Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 21:06:28 -0000 This discussion started with the statement that channel bindings are a form of authorization data. Our charter requires us to support carrying channel bindings in the tunnel method. Password change is another form of non-authentication data that we need to support. Clearly there are several kinds of non-authentication data that we must support carrying in EAP. They are in our charter. I see no harm in also supporting carrying NEA assessments in the tunnel method. The only bizarre engineering here is Glen's suggestion that because the A in EAP stands for Authentication, it should not be allowed to carry anything other than authentication protocols. By that logic, RADIUS should be prohibited from carrying VLAN assignments and anything other than authentication information. After all, the A in RADIUS also stands for authentication. And RADIUS should be restricted to Dial In access since that's what the D and I stand for! Glen, if you don't have any substantive arguments to make, don't try to impress us with bluster. Thanks, Steve > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On=20 > Behalf Of Glen Zorn > Sent: Tuesday, August 11, 2009 4:22 PM > To: 'Alan DeKok' > Cc: emu@ietf.org > Subject: Re: [Emu] EAP and authorization >=20 > Alan DeKok [mailto:aland@deployingradius.com] writes: >=20 > > Glen Zorn wrote: > > > Alan DeKok [mailto://aland@deployingradius.com] writes: > > ... > > >> Prior to authentication, EAP is the only=20 > communications protocol > > >> between a supplicant and *anywhere* on the network. It=20 > is therefore > > >> natural to overload it as a general purpose transport protocol. > > > >=20 > >=20 > > >> I believe that is what is happening: authorization=20 > parameters are > > >> being exchanged in EAP. This should be made clearer in the > > documents. > > > > > > Above you said ... by way of rationalizing > >=20 > > "explaining" > >=20 > > The two are very different. > >=20 > > > the use of EAP "as a general purpose transport protocol". I could > > have > > > sworn that authorization _follows_ and is parameterized by > > authentication. > >=20 > > I agree. I haven't seen any proposal that contradicts this. > >=20 > > > So, please tell me again why EAP should be (further)=20 > bastardized for > > this purpose. > >=20 > > People are proposing it because they find it useful. =20 > This isn't mean > > it's a good idea, just that it's one that has real-world uses. > >=20 > > My message about this topic was intended to foster discussion. =20 >=20 > Success! >=20 > > If > > there is strong objection to the idea, we can refuse to "bastardize" > > EAP. If there is strong consensus that this is necessary,=20 > it's best to > > make it explicit in the documents. >=20 > More likely the creation of a new protocol, unless=20 > "convenience" (a word that is used often in the draft as=20 > (often the only) justification for bizarre additions to EAP)=20 > has taken precedence over engineering in this WG. >=20 > >=20 > > Alan DeKok. >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > = From khoeper@motorola.com Tue Aug 11 14:35:30 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59E913A6A69 for ; Tue, 11 Aug 2009 14:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9H64fUJidXJl for ; Tue, 11 Aug 2009 14:35:29 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id EBA1B3A6950 for ; Tue, 11 Aug 2009 14:35:28 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: khoeper@motorola.com X-Msg-Ref: server-10.tower-55.messagelabs.com!1250026469!98361049!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 31444 invoked from network); 11 Aug 2009 21:34:29 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Aug 2009 21:34:29 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n7BLYTAL002164 for ; Tue, 11 Aug 2009 14:34:29 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id n7BLYSRk002320 for ; Tue, 11 Aug 2009 16:34:28 -0500 (CDT) Received: from de01exm68.ds.mot.com (de01exm68.am.mot.com [10.176.8.24]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id n7BLYS3q002317 for ; Tue, 11 Aug 2009 16:34:28 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Aug 2009 17:34:06 -0400 Message-ID: <3A241A6B234BE948B8B474D261FEBC2F06555BE4@de01exm68.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Emu] EAP and authorization thread-index: Acoasqiu621ufxpGTRex8HWnRlMLhgADXykAAADFFYAAAUxUUA== References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org><4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net><4A81BA2B.1090400@deployingradius.com><00c201ca1ac1$64b9f800$2e2de800$@net> From: "Hoeper Katrin-QWKN37" To: "Stephen Hanna" , "Glen Zorn" , "Alan DeKok" X-CFilter-Loop: Reflected Cc: emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 21:35:30 -0000 Hi, Before this discussion escalades any further, I would like to summarize the open issue(s) that need to be addressed to move the channel binding draft forward. Channel binding is a work group item because there was a group consensus that the lying NAS and lying provider problem are real threats that need to be addressed. In other words, we decided that EAP needs to provide means to find out whether an authenticator (or intermediary entity) is sending false information to the peer and/or the EAP server. There is no need to further discuss the above, since we achieved group consensus on this a long time ago.=20 draft-ietf-emu-chbind-03 (http://tools.ietf.org/html/draft-ietf-emu-chbind-03) was accepted as a WG item and addresses the above problem. Here's the open issue (as I see it from previous posts to the list): The draft also introduces an additional feature that can be achieved using channel bindings, namely checking whether an authenticator is authorized to provide the requested services. This feature was added at some time, because Bernard pointed out that it could be provided at not much extra cost. Channel binding itself already requires an integrity-protected exchange of data as well as a local database (only additional DB entries would be needed and the exchange of data that is relevant to authorization (and not to channel bindings)).=20 I already mentioned in my reply to Klaas' review of draft-ietf-emu-chbind-02 (http://www.ietf.org/mail-archive/web/emu/current/msg01140.html) that I could remove this additional feature, if there is a group consensus to do so. So please let's concentrate on this issue and not rehash the whole channel binding discussion. Is this the only issue that people are having with the draft? If so, I'd be interested if 1) there is a group consensus to remove the authorization feature and 2) whether removing this feature solves all open issues with the draft. Thanks, Katrin > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of > Stephen Hanna > Sent: Tuesday, August 11, 2009 4:00 PM > To: Glen Zorn; 'Alan DeKok' > Cc: emu@ietf.org > Subject: Re: [Emu] EAP and authorization >=20 > This discussion started with the statement that channel bindings > are a form of authorization data. Our charter requires us to > support carrying channel bindings in the tunnel method. > Password change is another form of non-authentication data > that we need to support. Clearly there are several kinds of > non-authentication data that we must support carrying in EAP. > They are in our charter. I see no harm in also supporting > carrying NEA assessments in the tunnel method. >=20 > The only bizarre engineering here is Glen's suggestion > that because the A in EAP stands for Authentication, it > should not be allowed to carry anything other than > authentication protocols. By that logic, RADIUS should > be prohibited from carrying VLAN assignments and anything > other than authentication information. After all, the A > in RADIUS also stands for authentication. And RADIUS > should be restricted to Dial In access since that's > what the D and I stand for! >=20 > Glen, if you don't have any substantive arguments to > make, don't try to impress us with bluster. >=20 > Thanks, >=20 > Steve >=20 > > -----Original Message----- > > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On > > Behalf Of Glen Zorn > > Sent: Tuesday, August 11, 2009 4:22 PM > > To: 'Alan DeKok' > > Cc: emu@ietf.org > > Subject: Re: [Emu] EAP and authorization > > > > Alan DeKok [mailto:aland@deployingradius.com] writes: > > > > > Glen Zorn wrote: > > > > Alan DeKok [mailto://aland@deployingradius.com] writes: > > > ... > > > >> Prior to authentication, EAP is the only > > communications protocol > > > >> between a supplicant and *anywhere* on the network. It > > is therefore > > > >> natural to overload it as a general purpose transport protocol. > > > > > > > > > > > > >> I believe that is what is happening: authorization > > parameters are > > > >> being exchanged in EAP. This should be made clearer in the > > > documents. > > > > > > > > Above you said ... by way of rationalizing > > > > > > "explaining" > > > > > > The two are very different. > > > > > > > the use of EAP "as a general purpose transport protocol". I could > > > have > > > > sworn that authorization _follows_ and is parameterized by > > > authentication. > > > > > > I agree. I haven't seen any proposal that contradicts this. > > > > > > > So, please tell me again why EAP should be (further) > > bastardized for > > > this purpose. > > > > > > People are proposing it because they find it useful. > > This isn't mean > > > it's a good idea, just that it's one that has real-world uses. > > > > > > My message about this topic was intended to foster discussion. > > > > Success! > > > > > If > > > there is strong objection to the idea, we can refuse to "bastardize" > > > EAP. If there is strong consensus that this is necessary, > > it's best to > > > make it explicit in the documents. > > > > More likely the creation of a new protocol, unless > > "convenience" (a word that is used often in the draft as > > (often the only) justification for bizarre additions to EAP) > > has taken precedence over engineering in this WG. > > > > > > > > Alan DeKok. > > > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From aland@deployingradius.com Tue Aug 11 15:09:55 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08D843A6AC9 for ; Tue, 11 Aug 2009 15:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3BBWqVFB8+R for ; Tue, 11 Aug 2009 15:09:54 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id E89633A7009 for ; Tue, 11 Aug 2009 15:09:47 -0700 (PDT) Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 85AB9123443A; Wed, 12 Aug 2009 00:07:55 +0200 (CEST) Message-ID: <4A81EBBB.7040507@deployingradius.com> Date: Wed, 12 Aug 2009 00:07:55 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Glen Zorn References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org> <4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net> <4A81BA2B.1090400@deployingradius.com> <00c301ca1ac3$8a0af800$9e20e800$@net> In-Reply-To: <00c301ca1ac3$8a0af800$9e20e800$@net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 22:09:55 -0000 Glen Zorn wrote: > Hmm. Has another way been tried or is it the best way because it's the > easiest (or only) way we've tried? Authentication decisions have traditionally involved more than just username / password checking. Authentication decisions are also commonly based on "pre-authorization" data, such as: * time of day * location * physical * network * account balance * past behavior * machine used to authenticate And so on. An authentication server may use any of that information to return a "failed authentication" status to the client, even if the username / password is superficially correct. This is not "authorization", because the user has not been authenticated. But that information is still used to make authentication decisions. Enabling EAP to carry this information is well within the bounds of the protocol. TLS-based EAP methods can carry information such as time of life for a certificate, issuer, etc. If we restrict EAP to solely "authentication", then I would ask what that means. An authentication protocol that is incapable of transporting the data required to make authentication decisions would be perfectly secure: No one would ever be authenticated. Alan DeKok. From glenzorn@comcast.net Tue Aug 11 16:10:34 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5AFA3A682D for ; Tue, 11 Aug 2009 16:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=0.472, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iP6dLF4185hF for ; Tue, 11 Aug 2009 16:10:33 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id CEBD63A67F8 for ; Tue, 11 Aug 2009 16:10:32 -0700 (PDT) Received: from OMTA17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id T9qx1c0081afHeLA1B8cjC; Tue, 11 Aug 2009 23:08:36 +0000 Received: from gwzPC ([71.231.55.1]) by OMTA17.emeryville.ca.mail.comcast.net with comcast id TB8b1c00201ae1j8dB8b5b; Tue, 11 Aug 2009 23:08:36 +0000 From: "Glen Zorn" To: "'Stephen Hanna'" References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org> <4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net> <4A81BA2B.1090400@deployingradius.com> <00c201ca1ac1$64b9f800$2e2de800$@net> In-Reply-To: Date: Tue, 11 Aug 2009 16:08:08 -0700 Message-ID: <00e001ca1ad8$97a63230$c6f29690$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acoasqiu621ufxpGTRex8HWnRlMLhgADXykAAADFFYAAA9IWAA== Content-Language: en-us Cc: emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 23:10:34 -0000 Stephen Hanna [mailto:shanna@juniper.net] writes: > This discussion started with the statement that channel bindings > are a form of authorization data. And no one disputed this? > Our charter requires us to > support carrying channel bindings in the tunnel method. > Password change is another form of non-authentication data > that we need to support. Please explain how passwords are unrelated to authentication. > Clearly there are several kinds of > non-authentication data that we must support carrying in EAP. > They are in our charter. I see no harm in also supporting > carrying NEA assessments in the tunnel method. You are entitled to your opinion. > > The only bizarre engineering here is Glen's suggestion > that because the A in EAP stands for Authentication, it > should not be allowed to carry anything other than > authentication protocols. By that logic, RADIUS should > be prohibited from carrying VLAN assignments and anything > other than authentication information. After all, the A > in RADIUS also stands for authentication. And RADIUS > should be restricted to Dial In access since that's > what the D and I stand for! I really appreciate your putting two separate messages from me into your magic blender. Unsurprisingly, what came out was only vaguely related to what I actually wrote, but that was the point, wasn't it? What I actually said (in a message you didn't quote) was: Except for that whole pesky name & purpose thing -- you know, Extensible _Authentication_ Protocol. ------- The Abstract of RFC 3748 says "This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods.", a sentence that is repeated in virtually every EAP-related RFC. For some reason it _doesn't_ say "an authentication and authorization framework" or "an authentication and configuration management framework", which is apparently what you want it to be (it's so convenient!). WRT to RADIUS, the Abstract of RFC 2865 says "This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server." This seems to sum up the purpose of RADIUS pretty well, as the abstract from RFC 3748 sums up the purpose of EAP. > > Glen, if you don't have any substantive arguments to > make, don't try to impress us with bluster. OK, I'd appreciate the same from you (along with accurate, rather than misleading, quoting). BTW, while you may consider your personal opinion to be a "substantive argument" ("I see no harm in also supporting carrying NEA assessments in the tunnel method"), others might not. ... From glenzorn@comcast.net Tue Aug 11 21:29:57 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65D5E3A69ED for ; Tue, 11 Aug 2009 21:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyYIZfBOUjP1 for ; Tue, 11 Aug 2009 21:29:56 -0700 (PDT) Received: from QMTA13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by core3.amsl.com (Postfix) with ESMTP id 925D23A6AAE for ; Tue, 11 Aug 2009 21:29:39 -0700 (PDT) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA13.emeryville.ca.mail.comcast.net with comcast id TGFF1c00616AWCUADGUr3U; Wed, 12 Aug 2009 04:28:51 +0000 Received: from gwzPC ([71.231.55.1]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id TGUq1c00D01ae1j8SGUqRW; Wed, 12 Aug 2009 04:28:51 +0000 From: "Glen Zorn" To: "'Alan DeKok'" References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org> <4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net> <4A81BA2B.1090400@deployingradius.com> <00c301ca1ac3$8a0af800$9e20e800$@net> <4A81EBBB.7040507@deployingradius.com> In-Reply-To: <4A81EBBB.7040507@deployingradius.com> Date: Tue, 11 Aug 2009 21:28:22 -0700 Message-ID: <012a01ca1b05$53ffa610$fbfef230$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acoa0DBWSX5MayXsQnaKne2c8GFcJQACTUQw Content-Language: en-us Cc: emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 04:29:57 -0000 Alan DeKok [mailto:aland@deployingradius.com] writes: > Glen Zorn wrote: > > Hmm. Has another way been tried or is it the best way because it's > the > > easiest (or only) way we've tried? > > Authentication decisions have traditionally involved more than just > username / password checking. Authentication decisions are also > commonly based on "pre-authorization" data, such as: > > * time of day > * location > * physical > * network > * account balance > * past behavior > * machine used to authenticate > > And so on. No. Please don't confuse authentication with authorization. The parameters you mention above are policy-related, not related to authentication. > > An authentication server may use any of that information to return a > "failed authentication" status to the client, even if the username / > password is superficially correct. What authentication server is that? Not RADIUS: the semantics of the Access-Reject message don't distinguish between failed authentication and failed authorization. > This is not "authorization", > because > the user has not been authenticated. A server can tell me that I'm not authorized without knowing who I am? This is incredibly cool technology! Where can I get some of that? But seriously, the initial authorization checks made by a RADIUS server for example are based upon so-called "simple" authentication (as used daily by billions of humans). Although this consists of my telling you my name & you believing me (for the time being anyway), it is authentication all the same. > But that information is still > used > to make authentication decisions. No, they are authorization decisions. > > Enabling EAP to carry this information is well within the bounds of > the protocol. TLS-based EAP methods can carry information such as time > of life for a certificate, issuer, etc. I suppose so, but since all those things are typically in the cert, I don't know why. In any case, those things are directly related to authentication. > > If we restrict EAP to solely "authentication", then I would ask what > that means. An authentication protocol that is incapable of > transporting the data required to make authentication decisions would > be > perfectly secure: No one would ever be authenticated. I have no idea what you're talking about. From aland@deployingradius.com Tue Aug 11 22:15:46 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33FC33A6875 for ; Tue, 11 Aug 2009 22:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=0.479, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYqCzTqaUgQm for ; Tue, 11 Aug 2009 22:15:45 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 35F633A699A for ; Tue, 11 Aug 2009 22:15:45 -0700 (PDT) Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 5A51B123443A; Wed, 12 Aug 2009 07:13:42 +0200 (CEST) Message-ID: <4A824F85.6080307@deployingradius.com> Date: Wed, 12 Aug 2009 07:13:41 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Glen Zorn References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org> <4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net> <4A81BA2B.1090400@deployingradius.com> <00c301ca1ac3$8a0af800$9e20e800$@net> <4A81EBBB.7040507@deployingradius.com> <012a01ca1b05$53ffa610$fbfef230$@net> In-Reply-To: <012a01ca1b05$53ffa610$fbfef230$@net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 05:15:46 -0000 Glen Zorn wrote: > No. Please don't confuse authentication with authorization. The parameters > you mention above are policy-related, not related to authentication. You are making arbitrary distinctions between pieces of information. Ones you like are deemed "authentication". Ones you don't like are deemed "authorization". > What authentication server is that? Not RADIUS: the semantics of the > Access-Reject message don't distinguish between failed authentication and > failed authorization. This is the EMU WG, not RADIUS. EAP has an "EAP-Failure" code. > A server can tell me that I'm not authorized without knowing who I am? Yes. A policy could state that all logins between 5pm and 9am are to be rejected. In that case, it can reject you without knowing (or caring) who you are. This process can't be "authorization", because it can happen *before* authentication. >> If we restrict EAP to solely "authentication", then I would ask what >> that means. An authentication protocol that is incapable of >> transporting the data required to make authentication decisions would >> be >> perfectly secure: No one would ever be authenticated. > > I have no idea what you're talking about. Explain what criteria you use to distinguish between "authentication" data and "authorization" data. Give a name to the policies that get processed *before* a user is authenticated. Such policies exist, and are in wide use. The NEA use of EAP falls within this use. Alan DeKok. From glenzorn@comcast.net Tue Aug 11 23:51:34 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8560A3A6A6F for ; Tue, 11 Aug 2009 23:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIRBa4jZw7Z5 for ; Tue, 11 Aug 2009 23:51:33 -0700 (PDT) Received: from QMTA11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by core3.amsl.com (Postfix) with ESMTP id 7CB763A692A for ; Tue, 11 Aug 2009 23:51:32 -0700 (PDT) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA11.emeryville.ca.mail.comcast.net with comcast id TJgQ1c00616AWCUABJjUUi; Wed, 12 Aug 2009 06:43:28 +0000 Received: from gwzPC ([71.231.55.1]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id TJk11c00101ae1j8SJk1cW; Wed, 12 Aug 2009 06:44:02 +0000 From: "Glen Zorn" To: "'Alan DeKok'" References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org> <4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net> <4A81BA2B.1090400@deployingradius.com> <00c301ca1ac3$8a0af800$9e20e800$@net> <4A81EBBB.7040507@deployingradius.com> <012a01ca1b05$53ffa610$fbfef230$@net> <4A824F85.6080307@deployingradius.com> In-Reply-To: <4A824F85.6080307@deployingradius.com> Date: Tue, 11 Aug 2009 23:43:32 -0700 Message-ID: <014501ca1b18$3638af10$a2aa0d30$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcobC6rxvyyb4uDJQsWDefkPNwClFgABeW+w Content-Language: en-us Cc: emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 06:51:34 -0000 Alan DeKok [mailto:aland@deployingradius.com] writes: > Glen Zorn wrote: > > No. Please don't confuse authentication with authorization. The > parameters > > you mention above are policy-related, not related to authentication. > > You are making arbitrary distinctions between pieces of information. > Ones you like are deemed "authentication". Ones you don't like are > deemed "authorization". The distinctions may be arbitrary but I'm hardly inventing them; these are pretty standard. And for the record, I love both Authentication and Authorization equally; it does annoy me when people can't tell them apart, though ;-). > > > What authentication server is that? Not RADIUS: the semantics of the > > Access-Reject message don't distinguish between failed authentication > and > > failed authorization. > > This is the EMU WG, not RADIUS. Oh, yeah, thanks for reminding me. > EAP has an "EAP-Failure" code. It seems that here in EMU it is habitual to quote others extremely selectively. I guess I'll just have to get used to that; for the time being, though, here's a little context: Authentication decisions have traditionally involved more than just username / password checking. Authentication decisions are also commonly based on "pre-authorization" data, such as: * time of day * location * physical * network * account balance * past behavior * machine used to authenticate And so on. An authentication server may use any of that information to return a "failed authentication" status to the client, even if the username / password is superficially correct. So I guess that what you are saying is that _EAP_ servers (as opposed to AAA servers) typically use such data in making authentication decisions (not access-control decisions or authorization decisions). Is that correct? > > > A server can tell me that I'm not authorized without knowing who I > am? > > Yes. A policy could state that all logins between 5pm and 9am are to > be rejected. In that case, it can reject you without knowing (or > caring) who you are. This process can't be "authorization", because it > can happen *before* authentication. OK. So, if authentication is irrelevant to the enforcement of this policy, how is the policy relevant to EAP? > > >> If we restrict EAP to solely "authentication", then I would ask > what > >> that means. An authentication protocol that is incapable of > >> transporting the data required to make authentication decisions > would > >> be > >> perfectly secure: No one would ever be authenticated. > > > > I have no idea what you're talking about. > > Explain what criteria you use to distinguish between "authentication" > data and "authorization" data. Pretty obviously, authentication data is used for authentication & authorization data are used for authorization. Maybe I don't understand the question: are you looking for definitions of authentication and authorization? ? Give a name to the policies that get > processed *before* a user is authenticated. I don't know; what do you call it when you turn off the ringer on your phone (to use an example similar to the one you gave above)? The fact that you don't answer the phone has nothing to do with who's calling (authentication) nor whether you want to talk to them (authorization). > > Such policies exist, and are in wide use. The NEA use of EAP falls > within this use. Again, since authentication is irrelevant to the policies, how are the policies relevant to EAP (aside from the fact that it's just so darn convenient)? > > Alan DeKok. From aland@deployingradius.com Wed Aug 12 01:09:44 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D41BF3A6B42 for ; Wed, 12 Aug 2009 01:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrtDpBZCnW1b for ; Wed, 12 Aug 2009 01:09:44 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 3E57C3A695D for ; Wed, 12 Aug 2009 01:09:42 -0700 (PDT) Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 57BBB123443A; Wed, 12 Aug 2009 10:07:56 +0200 (CEST) Message-ID: <4A82785C.4010304@deployingradius.com> Date: Wed, 12 Aug 2009 10:07:56 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Glen Zorn References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org> <4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net> <4A81BA2B.1090400@deployingradius.com> <00c301ca1ac3$8a0af800$9e20e800$@net> <4A81EBBB.7040507@deployingradius.com> <012a01ca1b05$53ffa610$fbfef230$@net> <4A824F85.6080307@deployingradius.com> <014501ca1b18$3638af10$a2aa0d30$@net> In-Reply-To: <014501ca1b18$3638af10$a2aa0d30$@net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 08:09:44 -0000 Glen Zorn wrote: > I don't know; what do you call it when you turn off the ringer on your phone > (to use an example similar to the one you gave above)? The fact that you > don't answer the phone has nothing to do with who's calling (authentication) > nor whether you want to talk to them (authorization). Using that analogy: what do you call a policy that has you turning your cell phone off when in one place, and on again in another? It's not authentication, because you don't care who's calling. It's not authorization, because no one is being authenticated. > Again, since authentication is irrelevant to the policies, how are the > policies relevant to EAP (aside from the fact that it's just so darn > convenient)? To use NEA as an example, the decision about whether or not to return "success" or "fail" depends on information OTHER than strictly a username/password check. This information is called "authentication credentials", which can be: 1) username / password (PAP) 2) client certificate (TLS-based methods) * issuer * expiry * etc. 3) machine status, etc. (NEA) I find it curious that you're willing to accept the first two as being acceptable for authentication, but not the third. How do you determine that "X" is acceptable as an authentication credential, but "Y" is not? A clear explanation of the method is most welcome. Your presentation so far has been "Glen says it's OK", or "Glen says it's not OK". That isn't anything we can put into a specification. Alan DeKok. From aland@deployingradius.com Wed Aug 12 04:01:57 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 252943A69E4 for ; Wed, 12 Aug 2009 04:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsG3ibuRFNuz for ; Wed, 12 Aug 2009 04:01:56 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 534D83A677E for ; Wed, 12 Aug 2009 04:01:56 -0700 (PDT) Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 92AFA123443A; Wed, 12 Aug 2009 12:15:15 +0200 (CEST) Message-ID: <4A829633.2020602@deployingradius.com> Date: Wed, 12 Aug 2009 12:15:15 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Hoeper Katrin-QWKN37 References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org><4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net><4A81BA2B.1090400@deployingradius.com><00c201ca1ac1$64b9f800$2e2de800$@net> <3A241A6B234BE948B8B474D261FEBC2F06555BE4@de01exm68.ds.mot.com> In-Reply-To: <3A241A6B234BE948B8B474D261FEBC2F06555BE4@de01exm68.ds.mot.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 11:01:57 -0000 Hoeper Katrin-QWKN37 wrote: > Here's the open issue (as I see it from previous posts to the list): ... > Is this the only issue that people are having with the draft? > If so, I'd be interested if 1) there is a group consensus to remove the > authorization feature and 2) whether removing this feature solves all > open issues with the draft. I believe that this feature is useful enough to warrant mentioning in the draft. If there is objection, we can have a WG consensus call on this issue. Alan DeKok. From shanna@juniper.net Wed Aug 12 04:07:47 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D17D03A6999 for ; Wed, 12 Aug 2009 04:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XL06YlSwf-5W for ; Wed, 12 Aug 2009 04:07:47 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id D26673A69E4 for ; Wed, 12 Aug 2009 04:07:46 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSoKiKPkK9OTWGWP2WOu2ynjIhcGmFJ6V@postini.com; Wed, 12 Aug 2009 04:07:51 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 12 Aug 2009 04:04:44 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 12 Aug 2009 07:04:43 -0400 From: Stephen Hanna To: Glen Zorn Date: Wed, 12 Aug 2009 07:03:48 -0400 Thread-Topic: [Emu] EAP and authorization Thread-Index: Acoasqiu621ufxpGTRex8HWnRlMLhgADXykAAADFFYAAA9IWAAAWw+zg Message-ID: References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org> <4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net> <4A81BA2B.1090400@deployingradius.com> <00c201ca1ac1$64b9f800$2e2de800$@net> <00e001ca1ad8$97a63230$c6f29690$@net> In-Reply-To: <00e001ca1ad8$97a63230$c6f29690$@net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "emu@ietf.org" Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 11:07:47 -0000 Glen, Thanks for clarifying your position. I believe that your argument is that because EAP is an "authentication framework", it should not be allowed to carry anything other than authentication protocols. Is that correct? My apologies if this is not quite right. I am having some difficulty finding a crisp summary of your position in your emails. Please feel free to clarify your point of view. I would argue that an "authentication framework" should not just be concerned with verifying the EAP peer's identity. EAP should also include other elements relevant to the authentication process and the decision about whether to grant network access. For example, password change requests should be allowed. Channel bindings are another example. Having the peer send information about the NAS to the EAP server allows the server to warn the peer about a lying NAS. It also helps the server decide whether the peer is authorized to obtain the requested network service. Performing a NEA assessment helps the server decide whether the peer is secure enough to connect to the network. I suppose that my basic argument is a practical one. Password change, channel bindings, and NEA assessments are useful things to do during the EAP exchange. They are relevant to the authentication process and the server's decision about whether to grant network access. There is no harm in doing them as part of the EAP exchange. And there is no better way to implement them. Would you like to argue with any of these assertions? Thanks, Steve From d.b.nelson@comcast.net Wed Aug 12 06:17:51 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E95A63A688C for ; Wed, 12 Aug 2009 06:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7S8I4vHBgeK for ; Wed, 12 Aug 2009 06:17:51 -0700 (PDT) Received: from QMTA12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by core3.amsl.com (Postfix) with ESMTP id 206D13A6AAA for ; Wed, 12 Aug 2009 06:17:51 -0700 (PDT) Received: from OMTA17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by QMTA12.emeryville.ca.mail.comcast.net with comcast id TQwG1c0031afHeLACREzwZ; Wed, 12 Aug 2009 13:14:59 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA17.emeryville.ca.mail.comcast.net with comcast id TREy1c0074H2mdz8dREyy5; Wed, 12 Aug 2009 13:14:59 +0000 From: "Dave Nelson" To: References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org> <4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net><4A81BA2B.1090400@deployingradius.com><00c301ca1ac3$8a0af800$9e20e800$@net><4A81EBBB.7040507@deployingradius.com><012a01ca1b05$53ffa610$fbfef230$@net> <4A824F85.6080307@deployingradius.com> Date: Wed, 12 Aug 2009 09:15:04 -0400 Message-ID: <144465FACC914EA48639B7CACC77C68D@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4A824F85.6080307@deployingradius.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcobC/c8C+lRbbVKQBSEz+nOpjUFlgAQYtcg Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 13:17:52 -0000 Alan DeKok writes... > > A server can tell me that I'm not authorized without > > knowing who I am? > > Yes. A policy could state that all logins between 5pm > and 9am are to be rejected. In that case, it can reject > you without knowing (or caring) who you are. This process > can't be "authorization", because it can happen *before* > authentication. I hate to jump into the heated debates over terminology, but I have to support Glen in this case. Alan, I'm sorry, you're simply mistaken about this. Authentication is "proof of identity", i.e., it's about who you are. Authorization is about "access control policy", i.e., what you may do. In the example that you cite above, the action is clearly authorization. The server is enforcing the "access control policy" that the "wildcard" user is prohibited from logging in during the hours of 5 PM and 9 AM. This authorization action *was* preceded by an implicit authentication action. It's just that the "wildcard" user, i.e., anyone on the planet, can easily be authenticated without the exchange of credentials. From aland@deployingradius.com Wed Aug 12 06:33:14 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42BF33A6B97 for ; Wed, 12 Aug 2009 06:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHyC7VpE8QGw for ; Wed, 12 Aug 2009 06:33:13 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 1C21A3A6805 for ; Wed, 12 Aug 2009 06:33:13 -0700 (PDT) Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id B1338123443A; Wed, 12 Aug 2009 15:32:10 +0200 (CEST) Message-ID: <4A82C45A.2030605@deployingradius.com> Date: Wed, 12 Aug 2009 15:32:10 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Dave Nelson References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org> <4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net><4A81BA2B.1090400@deployingradius.com><00c301ca1ac3$8a0af800$9e20e800$@net><4A81EBBB.7040507@deployingradius.com><012a01ca1b05$53ffa610$fbfef230$@net> <4A824F85.6080307@deployingradius.com> <144465FACC914EA48639B7CACC77C68D@NEWTON603> In-Reply-To: <144465FACC914EA48639B7CACC77C68D@NEWTON603> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 13:33:14 -0000 Dave Nelson wrote: > Authentication is "proof of identity", i.e., it's about who you are. > Authorization is about "access control policy", i.e., what you may do. In > the example that you cite above, the action is clearly authorization. I've been told that it's impossible to call that process authorization, because the user has not yet been authenticated. I would suggest that a common terminology be used. Changing the meaning of terms mid-discussion is not appropriate. > The > server is enforcing the "access control policy" that the "wildcard" user is > prohibited from logging in during the hours of 5 PM and 9 AM. This > authorization action *was* preceded by an implicit authentication action. This is the first I've heard of an "implicit authentication action" in this context. > It's just that the "wildcard" user, i.e., anyone on the planet, can easily > be authenticated without the exchange of credentials. We're arguing over semantics. No matter which semantics I choose, I get old I'm using them incorrectly. Stop nit-picking over the details, and pay attention to the *requirements* and *use-cases* that I have outlined. There is information that can be carried in EAP. Depending on who you are, it's called "authentication credentials", or "authorization data", or "damned if I know". Depending on who you are, the process of checking it is called "authorization" or "authentication" or "implicit authentication", or "something magic". Depending on who you are, it is "inappropriate" or "useful" to carry that information in EAP. If we can't agree on a consistent set of terminology, perhaps you could give your opinion on *what* information is being carried in EAP, and whether or not that information is useful or inappropriate. My opinion has been clear and consistent: Authenticators would like to know certain information before returning "success" or "fail" in EAP. Within some limitations, where that information can be carried in EAP, I believe it is appropriate and useful to carry it in EAP. Alan DeKok. From khoeper@motorola.com Wed Aug 12 06:41:08 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABA1D3A69CA for ; Wed, 12 Aug 2009 06:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-9F0IeT0w1T for ; Wed, 12 Aug 2009 06:41:07 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 85B1E3A6981 for ; Wed, 12 Aug 2009 06:41:07 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: khoeper@motorola.com X-Msg-Ref: server-11.tower-55.messagelabs.com!1250084313!33287428!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 5147 invoked from network); 12 Aug 2009 13:38:33 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Aug 2009 13:38:33 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n7CDcXY6007909 for ; Wed, 12 Aug 2009 06:38:33 -0700 (MST) Received: from de01exm68.ds.mot.com (de01exm68.am.mot.com [10.176.8.24]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id n7CDcWsv005804 for ; Wed, 12 Aug 2009 08:38:33 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Aug 2009 09:38:10 -0400 Message-ID: <3A241A6B234BE948B8B474D261FEBC2F06555D43@de01exm68.ds.mot.com> In-Reply-To: <4A829633.2020602@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Emu] EAP and authorization thread-index: AcobNdDZ53ionxLURPS1LQUaKHXZAwAHBEzw References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org><4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net><4A81BA2B.1090400@deployingradius.com><00c201ca1ac1$64b9f800$2e2de800$@net> <3A241A6B234BE948B8B474D261FEBC2F06555BE4@de01exm68.ds.mot.com> <4A829633.2020602@deployingradius.com> From: "Hoeper Katrin-QWKN37" To: "Alan DeKok" Cc: emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 13:41:08 -0000 > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com] > Sent: Wednesday, August 12, 2009 5:15 AM > To: Hoeper Katrin-QWKN37 > Cc: Stephen Hanna; Glen Zorn; emu@ietf.org > Subject: Re: [Emu] EAP and authorization >=20 > Hoeper Katrin-QWKN37 wrote: > > Here's the open issue (as I see it from previous posts to the list): > ... > > Is this the only issue that people are having with the draft? > > If so, I'd be interested if 1) there is a group consensus to remove the > > authorization feature and 2) whether removing this feature solves all > > open issues with the draft. >=20 > I believe that this feature is useful enough to warrant mentioning in > the draft. >=20 > If there is objection, we can have a WG consensus call on this issue. >=20 [KH] I like this idea! Let's do it :) > Alan DeKok. From d.b.nelson@comcast.net Wed Aug 12 06:46:27 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E92E43A69CA for ; Wed, 12 Aug 2009 06:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.532 X-Spam-Level: X-Spam-Status: No, score=-1.532 tagged_above=-999 required=5 tests=[AWL=1.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFAV3G+y6vMH for ; Wed, 12 Aug 2009 06:46:27 -0700 (PDT) Received: from QMTA14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by core3.amsl.com (Postfix) with ESMTP id 106F23A6805 for ; Wed, 12 Aug 2009 06:46:27 -0700 (PDT) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA14.emeryville.ca.mail.comcast.net with comcast id TQBE1c0080x6nqcAERYyFB; Wed, 12 Aug 2009 13:32:58 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id TRYw1c0034H2mdz8YRYxJC; Wed, 12 Aug 2009 13:32:58 +0000 From: "Dave Nelson" To: References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org><4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net><4A81BA2B.1090400@deployingradius.com><00c201ca1ac1$64b9f800$2e2de800$@net><00e001ca1ad8$97a63230$c6f29690$@net> Date: Wed, 12 Aug 2009 09:33:03 -0400 Message-ID: <64267BE4CECB4CAE83EFB0A6F5039285@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: Acoasqiu621ufxpGTRex8HWnRlMLhgADXykAAADFFYAAA9IWAAAWw+zgAAhwxrA= Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 13:46:28 -0000 Stephen Hanna writes... > I suppose that my basic argument is a practical one. Password > change, channel bindings, and NEA assessments are useful things > to do during the EAP exchange. That much I think most of us would agree with. EAP is a convenient protocol to use for exchanging that kind of information, even if it's stretching the original purpose of EAP. Remember, EAP was to be used during the authentication phase of PPP. > They are relevant to the authentication process and the server's > decision about whether to grant network access. I really hate to have to agree with Glen's position on this, but I do. I firmly believe that you, and others, are conflating elements of authorization into the meaning of authentication. Authentication is about proof of identity. I can be authenticated as Dave Nelson, by various means. I'm still Dave Nelson whether I'm a good guy or a bad guy. If I'm a bad guy, you may not want to grant me access to your home. If I'm a good guy, but an active carrier for Swine Flue, you still may not want to grant me access to your home. In any case I'm still Dave Nelson, and none of the other "access control" considerations affect my proof of identity. All those other considerations are authorization considerations, not authentication considerations. I agree that using words clearly and with their exact meaning is important. However, it appears that the real point of this semantic debate is whether the "domain of applicability" for EAP will admit the introduction on very useful, but clearly non-authentication, data elements. It's quite possible for the WG to have consensus to do so and at the same time be in apparent conflict with the "domain of applicability" for EAP. Of course, maybe the WG has within its charter the authority to revise the "domain of applicability" for EAP. > There is no harm in doing them as part of the EAP exchange. And there > is no better way to implement them. Assuming that's true -- and it may well be -- then EMU ought to expand the definition of EAP to explicitly include authorization related data, rather than making semantic, re-definitional, arguments that the authorization data is really authentication data. From d.b.nelson@comcast.net Wed Aug 12 07:05:20 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC0FA3A6ADF for ; Wed, 12 Aug 2009 07:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.591 X-Spam-Level: X-Spam-Status: No, score=-1.591 tagged_above=-999 required=5 tests=[AWL=1.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gaiJBV8JOsG for ; Wed, 12 Aug 2009 07:05:20 -0700 (PDT) Received: from QMTA13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by core3.amsl.com (Postfix) with ESMTP id EE4F83A683F for ; Wed, 12 Aug 2009 07:05:19 -0700 (PDT) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA13.emeryville.ca.mail.comcast.net with comcast id TRPg1c0080mlR8UADS3zjE; Wed, 12 Aug 2009 14:03:59 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id TS3x1c0064H2mdz8XS3yvc; Wed, 12 Aug 2009 14:03:59 +0000 From: "Dave Nelson" To: References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org> <4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net><4A81BA2B.1090400@deployingradius.com><00c301ca1ac3$8a0af800$9e20e800$@net><4A81EBBB.7040507@deployingradius.com><012a01ca1b05$53ffa610$fbfef230$@net> <4A824F85.6080307@deployingradius.com> <144465FACC914EA48639B7CACC77C68D@NEWTON603> <4A82C45A.2030605@deployingradius.com> Date: Wed, 12 Aug 2009 10:04:04 -0400 Message-ID: <111EFB0EC0224D21B64121456DAB1D4C@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4A82C45A.2030605@deployingradius.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcobUU4YD/rgXSPzSVqgkxn558uUHAAAv7eA Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 14:05:20 -0000 Alan DeKok writes... > This is the first I've heard of an "implicit authentication > action" in this context. We have NULL cipher-suites, why can't we have NULL authentication methods? > We're arguing over semantics. Yes. > Depending on who you are, it is "inappropriate" or "useful" to carry > that information in EAP. My opinion is that is both "useful" *and* "inappropriate". See my recent response to Steve Hanna's post. I think that either the EMU WG or NEA WG needs to seek to amend the "domain of applicability" for EAP to explicitly include transport of authorization-related data, and be done with it. That's the straightforward approach. It avoids the need to cling to alternate definitions of well understood terms. If you need to re-charter to gain that authority, then so be it. IMHO, this whole discussion looks like an end-run around the "domain of applicability" restrictions for EAP. Shall we take the high road here? At the very least, you could seek clarification from the IESG as to whether they think that the current "domain of applicability" for EAP embraces the "additional data" you want to include. After all, enforcement of "applicability statements" is a very hit or miss thing in the IETF. You may get lucky. :-) From aland@deployingradius.com Wed Aug 12 09:01:47 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D711B3A6BEC for ; Wed, 12 Aug 2009 09:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoIxdiW+5-ci for ; Wed, 12 Aug 2009 09:01:47 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id C75AD3A6BC0 for ; Wed, 12 Aug 2009 09:01:46 -0700 (PDT) Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id E67A5123443A; Wed, 12 Aug 2009 16:43:00 +0200 (CEST) Message-ID: <4A82D4F4.6050903@deployingradius.com> Date: Wed, 12 Aug 2009 16:43:00 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Dave Nelson References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org> <4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net><4A81BA2B.1090400@deployingradius.com><00c301ca1ac3$8a0af800$9e20e800$@net><4A81EBBB.7040507@deployingradius.com><012a01ca1b05$53ffa610$fbfef230$@net> <4A824F85.6080307@deployingradius.com> <144465FACC914EA48639B7CACC77C68D@NEWTON603> <4A82C45A.2030605@deployingradius.com> <111EFB0EC0224D21B64121456DAB1D4C@NEWTON603> In-Reply-To: <111EFB0EC0224D21B64121456DAB1D4C@NEWTON603> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 16:01:47 -0000 Dave Nelson wrote: >> This is the first I've heard of an "implicit authentication >> action" in this context. > > We have NULL cipher-suites, why can't we have NULL authentication methods? Yes, but it means we are far afield of the original discussion. > My opinion is that is both "useful" *and* "inappropriate". See my recent > response to Steve Hanna's post. I think that either the EMU WG or NEA WG > needs to seek to amend the "domain of applicability" for EAP to explicitly > include transport of authorization-related data, and be done with it. That's clear enough. > That's the straightforward approach. It avoids the need to cling to > alternate definitions of well understood terms. If you need to re-charter > to gain that authority, then so be it. IMHO, this whole discussion looks > like an end-run around the "domain of applicability" restrictions for EAP. I agree it does look that way. I don't even think that's a wrong characterization of the issue. > Shall we take the high road here? At the very least, you could seek > clarification from the IESG as to whether they think that the current > "domain of applicability" for EAP embraces the "additional data" you want to > include. After all, enforcement of "applicability statements" is a very hit > or miss thing in the IETF. You may get lucky. :-) I would prefer to get WG consensus first. If the WG believes it's a good idea, the re-chartering process becomes simpler. Alan DeKok. From d.b.nelson@comcast.net Wed Aug 12 11:19:33 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A832F3A6AC5 for ; Wed, 12 Aug 2009 11:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3bkiNnr7XjG for ; Wed, 12 Aug 2009 11:19:32 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 63F813A6B97 for ; Wed, 12 Aug 2009 11:19:11 -0700 (PDT) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id TSkn1c0040EPchoA4WJK9C; Wed, 12 Aug 2009 18:18:19 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id TWJJ1c0024H2mdz8MWJJGl; Wed, 12 Aug 2009 18:18:19 +0000 From: "Dave Nelson" To: References: <4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net> <4A81BA2B.1090400@deployingradius.com> <00c201ca1ac1$64b9f800$2e2de800$@net> <00e001ca1ad8$97a63230$c6f29690$@net> <64267BE4CECB4CAE83EFB0A6F5039285@NEWTON603> Date: Wed, 12 Aug 2009 14:18:24 -0400 Message-ID: <835827F05717467691DDBB94FAD980CE@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: Acobdsw7KRu4KCWfSy6JA/rZgN4AlwAANDcg Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 18:19:33 -0000 Bret Jordan writes... > Now EAP back in the day may have been the brain child of > simple authentication for PPP links. However, today we need > to look into what is really needed to enforce Security Policies > on networks. It is my belief that regardless of the legacy name > given to the protocol, EAP, EAP makes a great transport for > dealing with the age old questions "is this user who they say they > are" which has been expanded in recent years to be, "is this user > who they say they are and are they using a company owned system=20 > in the right part of the building at the right time of day).=20 It's not simply about legacies and names. It's about the rules for = protocol usage. In the IETF these rules are typically called "applicability statements". These limit the area of intended use for a given protocol. This is not about what's implied by the name, it's about whether we = follow the rules or attempt to circumvent them. All I'm suggesting is that we address the rule head on, instead of attempting to dance around it. =20 > Even though the ID badge is valid. The ID badge grants the=20 > holder to access certain resources, but the Security Guard > through visual inspection is able to make a better determination > of are these authentication credentials valid. Such procedures and meta-data are indeed related to authentication. However, that's not to say that *all* network access control policy is authentication meta-data. Some is; some isn't. > It is not that I am not authorized to use the systems at weird > hours, the system just knows that it is out side my normal usage > times and thus it may need to ask me follow up questions to verify > that I really am who I say I am.=A0 This is all about authentication. Well, that might be, but there is absolutely no reason that your normal hours of employment need to be communicated in an EAP message. In fact, = it would seem much a more reasonable design that the AAA server's database contains such access control policies. I think your argument about the = need for additional authentication meta-data is reasonable, but does not on = face value justify the need to send that meta-data between an EAP client and = EAP server. From shanna@juniper.net Wed Aug 12 11:58:30 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 635FB3A6ADB for ; Wed, 12 Aug 2009 11:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxv9d4g2N6am for ; Wed, 12 Aug 2009 11:58:29 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 551473A6B7D for ; Wed, 12 Aug 2009 11:58:29 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSoMQiYGAK97956+C6haHsnGILXisGaYm@postini.com; Wed, 12 Aug 2009 11:58:33 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 12 Aug 2009 11:53:43 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 12 Aug 2009 14:53:43 -0400 From: Stephen Hanna To: Dave Nelson , "emu@ietf.org" Date: Wed, 12 Aug 2009 14:52:46 -0400 Thread-Topic: [Emu] EAP and authorization Thread-Index: Acoasqiu621ufxpGTRex8HWnRlMLhgADXykAAADFFYAAA9IWAAAWw+zgAAhwxrAAAYIRAA== Message-ID: References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org><4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net><4A81BA2B.1090400@deployingradius.com><00c201ca1ac1$64b9f800$2e2de800$@net><00e001ca1ad8$97a63230$c6f29690$@net> <64267BE4CECB4CAE83EFB0A6F5039285@NEWTON603> In-Reply-To: <64267BE4CECB4CAE83EFB0A6F5039285@NEWTON603> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 18:58:30 -0000 There are various definitions of authentication. One could argue for the broad definition included in RFC 4949: $ authentication (I) The process of verifying a claim that a system entity or system resource has a certain attribute value. Password change, channel bindings, and NEA assessments could be included in that definition. However, I agree that it would be better to get IESG clarification that carrying authorization data in EAP is permissible. As Alan suggested, the first step is probably to have a WG consensus check to verify that we have rough consensus that this should be permitted. After that, maybe we would ask the IESG for a clarification of the applicability statement for EAP. I will note that the IESG has already approved a change to the EMU charter to add a work item for channel bindings. So they have already indicated their support for that effort. Thanks, Steve > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On=20 > Behalf Of Dave Nelson > Sent: Wednesday, August 12, 2009 9:33 AM > To: emu@ietf.org > Subject: Re: [Emu] EAP and authorization >=20 > Stephen Hanna writes... >=20 > > I suppose that my basic argument is a practical one. Password > > change, channel bindings, and NEA assessments are useful things > > to do during the EAP exchange. >=20 > That much I think most of us would agree with. EAP is a=20 > convenient protocol > to use for exchanging that kind of information, even if it's=20 > stretching the > original purpose of EAP. Remember, EAP was to be used during the > authentication phase of PPP. >=20 > > They are relevant to the authentication process and the server's > > decision about whether to grant network access.=20 >=20 > I really hate to have to agree with Glen's position on this,=20 > but I do. I > firmly believe that you, and others, are conflating elements of > authorization into the meaning of authentication. =20 > Authentication is about > proof of identity. I can be authenticated as Dave Nelson, by=20 > various means. > I'm still Dave Nelson whether I'm a good guy or a bad guy. =20 > If I'm a bad > guy, you may not want to grant me access to your home. If=20 > I'm a good guy, > but an active carrier for Swine Flue, you still may not want=20 > to grant me > access to your home. In any case I'm still Dave Nelson, and=20 > none of the > other "access control" considerations affect my proof of=20 > identity. All > those other considerations are authorization considerations, not > authentication considerations. >=20 > I agree that using words clearly and with their exact meaning=20 > is important. >=20 > However, it appears that the real point of this semantic=20 > debate is whether > the "domain of applicability" for EAP will admit the=20 > introduction on very > useful, but clearly non-authentication, data elements. It's=20 > quite possible > for the WG to have consensus to do so and at the same time be=20 > in apparent > conflict with the "domain of applicability" for EAP. Of=20 > course, maybe the > WG has within its charter the authority to revise the "domain of > applicability" for EAP. >=20 > > There is no harm in doing them as part of the EAP exchange.=20 > And there > > is no better way to implement them.=20 >=20 > Assuming that's true -- and it may well be -- then EMU ought=20 > to expand the > definition of EAP to explicitly include authorization related=20 > data, rather > than making semantic, re-definitional, arguments that the=20 > authorization data > is really authentication data. >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > = From jordan@thejordans.us Wed Aug 12 11:26:07 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CA773A6838 for ; Wed, 12 Aug 2009 11:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RysX4E8PIcf9 for ; Wed, 12 Aug 2009 11:26:06 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id EF10E3A67DB for ; Wed, 12 Aug 2009 11:26:05 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 28so61480wff.31 for ; Wed, 12 Aug 2009 11:25:13 -0700 (PDT) MIME-Version: 1.0 Sender: jordan@thejordans.us Received: by 10.142.194.1 with SMTP id r1mr39736wff.178.1250100036807; Wed, 12 Aug 2009 11:00:36 -0700 (PDT) In-Reply-To: <64267BE4CECB4CAE83EFB0A6F5039285@NEWTON603> References: <4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net> <4A81BA2B.1090400@deployingradius.com> <00c201ca1ac1$64b9f800$2e2de800$@net> <00e001ca1ad8$97a63230$c6f29690$@net> <64267BE4CECB4CAE83EFB0A6F5039285@NEWTON603> Date: Wed, 12 Aug 2009 12:00:36 -0600 X-Google-Sender-Auth: 2eee3babada94e4a Message-ID: From: Bret Jordan To: Dave Nelson Content-Type: multipart/alternative; boundary=000e0cd14ed8a0adf30470f5989d Cc: emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 19:39:51 -0000 --000e0cd14ed8a0adf30470f5989d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dave et all, I agree that Authentication in the truest sense of the term is about knowing and verifying who someone is or what something is (you can authenticate things in addition to people). Also remember that authentication is NOT restricted to just usernames and passwords. If we look at a business as a whole, not just the IT network there are lots of different types of data that can be used as authentication credentials. Things from fingerprints, retinal scans, facial recognition, stored CERT, hidden values in the registry of Windows boxes, simple host based names, ID badges or labels, stickers on the rear window of a car, etc can all be used as authentication in the business. Some of these are viewed as really weak forms of authentication and others as really strong, but the point is that everything from strong to really weak data can be used for authentication. It all depends on your appetite for risk. Given EAP and 802.1X it can also interesting to authentication a system at the same time you authenticate a user. One use case is to make sure that a said computer is one of the company owned computers or looks enough like a company owned computer to be acceptable. You may assess that the computer is company owned computer if it has some hidden regkey, it has a certain vendor's MAC address, it has a hidden file on the filesystem or that the system is fully compliant with the Security Policy of the organization. This is not Authorization of the computer to the network but is verifying that the computer is a company owned or a system that is deemed to look enough like a company owned system to be allowed access to the network, which is authentication. Now EAP back in the day may have been the brain child of simple authentication for PPP links. However, today we need to look into what is really needed to enforce Security Policies on networks. It is my belief that regardless of the legacy name given to the protocol, EAP, EAP makes a great transport for dealing with the age old questions "is this user who they say they are" which has been expanded in recent years to be, "is this user who they say they are and are they using a company owned system in the right part of the building at the right time of day). Yes the later half of the second age old question is a mix of authentication and authorization, but this is the world we live in, for better or worse. NEA and other attributes/data tunneled inside of EAP allow the authentication server and thus the business make more educated decisions about whether or not someone is who they say they are or a machine is what it says it is. This is authentication. Think of this in the terms of the security guard that checks ID badges when you enter the building. If a homeless person, all dressed in rags walks in to Chase Bank headquarters with a valid ID badge, the Security Guard will probably not trust his authentication, the ID badge. Even though the ID badge is valid. The ID badge grants the holder to access certain resources, but the Security Guard through visual inspection is able to make a better determination of are these authentication credentials valid. The username / password presented is often not enough to guarantee that the user is who the user says they are. A business may want to make sure they are using a certain computer, the computer is in a certain location, the computer is being used a certain time of day, and the computer has certain things, before they grant network access. This is NOT authorization. It is all about making sure people are really and honestly who they say they are. Some businesses and government agencies build profiles of work habits. So if I try to use my username/password after what is deemed my normal work patterns, that username/password is not accepted. It is not that I am not authorized to use the systems at weird hours, the system just knows that it is out side my normal usage times and thus it may need to ask me follow up questions to verify that I really am who I say I am. This is all about authentication. Bret On Wed, Aug 12, 2009 at 7:33 AM, Dave Nelson wrote: > Stephen Hanna writes... > > > I suppose that my basic argument is a practical one. Password > > change, channel bindings, and NEA assessments are useful things > > to do during the EAP exchange. > > That much I think most of us would agree with. EAP is a convenient > protocol > to use for exchanging that kind of information, even if it's stretching the > original purpose of EAP. Remember, EAP was to be used during the > authentication phase of PPP. > > > They are relevant to the authentication process and the server's > > decision about whether to grant network access. > > I really hate to have to agree with Glen's position on this, but I do. I > firmly believe that you, and others, are conflating elements of > authorization into the meaning of authentication. Authentication is about > proof of identity. I can be authenticated as Dave Nelson, by various > means. > I'm still Dave Nelson whether I'm a good guy or a bad guy. If I'm a bad > guy, you may not want to grant me access to your home. If I'm a good guy, > but an active carrier for Swine Flue, you still may not want to grant me > access to your home. In any case I'm still Dave Nelson, and none of the > other "access control" considerations affect my proof of identity. All > those other considerations are authorization considerations, not > authentication considerations. > > I agree that using words clearly and with their exact meaning is important. > > However, it appears that the real point of this semantic debate is whether > the "domain of applicability" for EAP will admit the introduction on very > useful, but clearly non-authentication, data elements. It's quite possible > for the WG to have consensus to do so and at the same time be in apparent > conflict with the "domain of applicability" for EAP. Of course, maybe the > WG has within its charter the authority to revise the "domain of > applicability" for EAP. > > > There is no harm in doing them as part of the EAP exchange. And there > > is no better way to implement them. > > Assuming that's true -- and it may well be -- then EMU ought to expand the > definition of EAP to explicitly include authorization related data, rather > than making semantic, re-definitional, arguments that the authorization > data > is really authentication data. > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > --000e0cd14ed8a0adf30470f5989d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Dave et all,

I agree that Authentication in the truest sense of the term is about knowing and verifying who someone is or what something is (you can authenticate things in addition to people). Also remember that authentication is NOT restricted to just usernames and passwords. If we look at a business as a whole, not just the IT network there are lots of different types of data that can be used as authentication credentials. Things from fingerprints, retinal scans, facial recognition, stored CERT, hidden values in the registry of Windows boxes, simple host based names, ID badges or labels, stickers on the rear window of a car, etc can all be used as authentication in the business. Some of these are viewed as really weak forms of authentication and others as really strong, but the point is that everything from strong to really weak data can be used for authentication. It all depends on your appetite for risk.


Given EAP and 802.1X it can also interesting to authentication a system at the same time you authenticate a user. One use case is to make sure that a said computer is one of the company owned computers or looks enough = like a company owned computer to be acceptable. You may assess that the computer is company owned computer if it has some hidden regkey, it has a certain vendor's MAC address, it has a hidden f= ile on the filesystem or that the system is fully compliant with the Security Policy of the organization. This is not Authorization of the computer to the network but is verifying that the computer is a company owned or a system that is deemed to look enough like a company owned system to be allowed access to the network, which is authentication.


Now EAP b= ack in the day may have been the brain child of simple authentication for PPP links. However, today we need to look into what is really needed to enforce Security Policies on networks. It is my belief that regardless of the legacy name given to the protocol, EAP, EAP makes a great transport for dealing with the age old questions "is this user who they say they= are" which has been expanded in recent years to be, "is this user who they say they are and are they using a company owned= system in the right part of the building at the right time of day). Yes th= e later half of the second age old question is a mix of authentication and authorization, but this is the world we live in, for better or worse.


NEA and other attribut= es/data tunneled inside of EAP allow the authentication server and thus the business make more educated decisions about whether or not someone is who they say they are or a machine is what it says it is. This is authentication. Think of this in the terms of the security guard that checks ID badges when you enter the building. If a homeless person, all dressed in rags walks in to Chase Bank headquarters with a valid ID badge, the Security Guard will probably not trust his authentication, the ID badge. Even though the ID badge is valid.=20 The ID badge grants the holder to access certain resources, but the Security Guard through visual inspection is able to make a better determination of are these authentication credentials valid. The username / password presented is often not enough to guarantee that the user is who the user says they are. A business may want to make sure they are using a certain computer, the computer is in a certain locati= on, the computer is being used a certain time of day, and the computer has = certain things, before they grant network access. This is NOT authorization. It is all about making sure people are really and honestly who they say they are.=A0 Some businesses and government agencies build profiles of = work habits.=A0 So if I try to use my username/password after what is deeme= d my normal work patterns, that username/password is not accepted.=A0 It is= not that I am not authorized to use the systems at weird hours, the system= just knows that it is out side my normal usage times and thus it may need = to ask me follow up questions to verify that I really am who I say I am.=A0= This is all about authentication.



Bret




On Wed, Aug 12, = 2009 at 7:33 AM, Dave Nelson <d.b.nelson@comcast.net> wrote:
Stephen Hanna writes...

> I suppose that my basic argument is a practical one. Password
> change, channel bindings, and NEA assessments are useful things
> to do during the EAP exchange.

That much I think most of us would agree with. =A0EAP is a convenient= protocol
to use for exchanging that kind of information, even if it's stretching= the
original purpose of EAP. =A0Remember, EAP was to be used during the
authentication phase of PPP.

> They are relevant to the authentication process and the server's > decision about whether to grant network access.

I really hate to have to agree with Glen's position on this, but = I do. =A0I
firmly believe that you, and others, are conflating elements of
authorization into the meaning of authentication. =A0Authentication is abou= t
proof of identity. =A0I can be authenticated as Dave Nelson, by various mea= ns.
I'm still Dave Nelson whether I'm a good guy or a bad guy. =A0If I&= #39;m a bad
guy, you may not want to grant me access to your home. =A0If I'm a good= guy,
but an active carrier for Swine Flue, you still may not want to grant me access to your home. =A0In any case I'm still Dave Nelson, and none of = the
other "access control" considerations affect my proof of identity= . =A0All
those other considerations are authorization considerations, not
authentication considerations.

I agree that using words clearly and with their exact meaning is important.=

However, it appears that the real point of this semantic debate is whether<= br> the "domain of applicability" for EAP will admit the introduction= on very
useful, but clearly non-authentication, data elements. =A0It's quite po= ssible
for the WG to have consensus to do so and at the same time be in apparent conflict with the "domain of applicability" for EAP. =A0Of course= , maybe the
WG has within its charter the authority to revise the "domain of
applicability" for EAP.

> There is no harm in doing them as part of the EAP exchange. And there<= br> > is no better way to implement them.

Assuming that's true -- and it may well be -- then EMU ought to e= xpand the
definition of EAP to explicitly include authorization related data, rather<= br> than making semantic, re-definitional, arguments that the authorization dat= a
is really authentication data.


_______________________________________________
Emu mailing list
Emu@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/emu




--000e0cd14ed8a0adf30470f5989d-- From jordan@open1x.org Wed Aug 12 13:47:40 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27DCE28C14B for ; Wed, 12 Aug 2009 13:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oUnEiZHdTSK for ; Wed, 12 Aug 2009 13:47:38 -0700 (PDT) Received: from spaceymail-a2.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 9BEF928C100 for ; Wed, 12 Aug 2009 13:47:38 -0700 (PDT) Received: from mail-pz0-f178.google.com (mail-pz0-f178.google.com [209.85.222.178]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by spaceymail-a2.g.dreamhost.com (Postfix) with ESMTP id A57F6EE413 for ; Wed, 12 Aug 2009 13:47:21 -0700 (PDT) Received: by pzk8 with SMTP id 8so219794pzk.31 for ; Wed, 12 Aug 2009 13:47:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.231.15 with SMTP id d15mr64896wfh.248.1250110041013; Wed, 12 Aug 2009 13:47:21 -0700 (PDT) In-Reply-To: <64267BE4CECB4CAE83EFB0A6F5039285@NEWTON603> References: <4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net> <4A81BA2B.1090400@deployingradius.com> <00c201ca1ac1$64b9f800$2e2de800$@net> <00e001ca1ad8$97a63230$c6f29690$@net> <64267BE4CECB4CAE83EFB0A6F5039285@NEWTON603> Date: Wed, 12 Aug 2009 14:47:20 -0600 Message-ID: From: Bret Jordan To: emu@ietf.org Content-Type: multipart/alternative; boundary=000e0cd29cd8ecbc9f0470f7ec0a Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 20:47:40 -0000 --000e0cd29cd8ecbc9f0470f7ec0a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit It looks like my first attempt at responding did not work due to send-from email address problems. If this comes through twice, I apologize in advance. Dave et all, I agree that Authentication in the truest sense of the term is about knowing and verifying who someone is or what something is (you can authenticate things in addition to people). Also remember that authentication is NOT restricted to just usernames and passwords. If we look at a business as a whole, not just the IT network there are lots of different types of data that can be used as authentication credentials. Things from fingerprints, retinal scans, facial recognition, stored CERT, hidden values in the registry of Windows boxes, simple host based names, ID badges or labels, stickers on the rear window of a car, etc can all be used as authentication in the business. Some of these are viewed as really weak forms of authentication and others as really strong, but the point is that everything from strong to really weak data can be used for authentication. It all depends on your appetite for risk. Given EAP and 802.1X it can also interesting to authentication a system at the same time you authenticate a user. One use case is to make sure that a said computer is one of the company owned computers or looks enough like a company owned computer to be acceptable. You may assess that the computer is company owned computer if it has some hidden regkey, it has a certain vendor's MAC address, it has a hidden file on the filesystem or that the system is fully compliant with the Security Policy of the organization. This is not Authorization of the computer to the network but is verifying that the computer is a company owned or a system that is deemed to look enough like a company owned system to be allowed access to the network, which is authentication. Now EAP back in the day may have been the brain child of simple authentication for PPP links. However, today we need to look into what is really needed to enforce Security Policies on networks. It is my belief that regardless of the legacy name given to the protocol, EAP, EAP makes a great transport for dealing with the age old questions "is this user who they say they are" which has been expanded in recent years to be, "is this user who they say they are and are they using a company owned system in the right part of the building at the right time of day). Yes the later half of the second age old question is a mix of authentication and authorization, but this is the world we live in, for better or worse. NEA and other attributes/data tunneled inside of EAP allow the authentication server and thus the business make more educated decisions about whether or not someone is who they say they are or a machine is what it says it is. This is authentication. Think of this in the terms of the security guard that checks ID badges when you enter the building. If a homeless person, all dressed in rags walks in to Chase Bank headquarters with a valid ID badge, the Security Guard will probably not trust his authentication, the ID badge. Even though the ID badge is valid. The ID badge grants the holder to access certain resources, but the Security Guard through visual inspection is able to make a better determination of are these authentication credentials valid. The username / password presented is often not enough to guarantee that the user is who the user says they are. A business may want to make sure they are using a certain computer, the computer is in a certain location, the computer is being used a certain time of day, and the computer has certain things, before they grant network access. This is NOT authorization. It is all about making sure people are really and honestly who they say they are. Some businesses and government agencies build profiles of work habits. So if I try to use my username/password after what is deemed my normal work patterns, that username/password is not accepted. It is not that I am not authorized to use the systems at weird hours, the system just knows that it is out side my normal usage times and thus it may need to ask me follow up questions to verify that I really am who I say I am. This is all about authentication. Bret On Wed, Aug 12, 2009 at 7:33 AM, Dave Nelson wrote: > Stephen Hanna writes... > > > I suppose that my basic argument is a practical one. Password > > change, channel bindings, and NEA assessments are useful things > > to do during the EAP exchange. > > That much I think most of us would agree with. EAP is a convenient > protocol > to use for exchanging that kind of information, even if it's stretching the > original purpose of EAP. Remember, EAP was to be used during the > authentication phase of PPP. > > > They are relevant to the authentication process and the server's > > decision about whether to grant network access. > > I really hate to have to agree with Glen's position on this, but I do. I > firmly believe that you, and others, are conflating elements of > authorization into the meaning of authentication. Authentication is about > proof of identity. I can be authenticated as Dave Nelson, by various > means. > I'm still Dave Nelson whether I'm a good guy or a bad guy. If I'm a bad > guy, you may not want to grant me access to your home. If I'm a good guy, > but an active carrier for Swine Flue, you still may not want to grant me > access to your home. In any case I'm still Dave Nelson, and none of the > other "access control" considerations affect my proof of identity. All > those other considerations are authorization considerations, not > authentication considerations. > > I agree that using words clearly and with their exact meaning is important. > > However, it appears that the real point of this semantic debate is whether > the "domain of applicability" for EAP will admit the introduction on very > useful, but clearly non-authentication, data elements. It's quite possible > for the WG to have consensus to do so and at the same time be in apparent > conflict with the "domain of applicability" for EAP. Of course, maybe the > WG has within its charter the authority to revise the "domain of > applicability" for EAP. > > > There is no harm in doing them as part of the EAP exchange. And there > > is no better way to implement them. > > Assuming that's true -- and it may well be -- then EMU ought to expand the > definition of EAP to explicitly include authorization related data, rather > than making semantic, re-definitional, arguments that the authorization > data > is really authentication data. > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > -- --------------------------------------------------------------------------------- Bret Jordan CISSP Treasurer, OpenSEA Alliance jordan@open1x.org --------------------------------------------------------------------------------- "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." --000e0cd29cd8ecbc9f0470f7ec0a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It looks like my first attempt at responding did not work due to send-from = email address problems.=A0 If this comes through twice, I apologize in adva= nce.=A0


Dave et all,

I = agree that Authentication in the truest sense of the term is about knowing and verifying who someone is or what something is (you can authenticate things in addition to people). Also remember that authentication is NOT restricted to just usernames and passwords. If we look at a business as a whole, not just the IT network there are lots of different types of data that can be used as authentication credentials. Things from fingerprints, retinal scans, facial recognition, stored CERT, hidden values in the registry of Windows boxes, simple host based names, ID badges or labels, stickers on the rear window of a car, etc can all be used as authentication in the business. Some of these are viewed as really weak forms of authentication and others as really strong, but the point is that everything from strong to really weak data can be used for authentication. It all depends on your appetite for risk.


Given EAP and 802.1X it can also interesting to authentication a system at the same time you authenticate a user. One use case is to make sure that a said computer is one of the company owned computers or looks enough like a company owned computer to be acceptable. You may assess that the computer is company owned computer if it has some hidden regkey, it has a certain vendor's MAC address, it has a hidden file on the filesystem or that the system is fully compliant with the Security Policy of the organization. This is not Authorization of the computer to the network but is verifying that the computer is a company owned or a system that is deemed to look enough like a company owned system to be allowed access to the network, which is authentication.


Now EAP back in the day may have been the brain child of simple authentication for PPP links. However, today we need to look into what is really needed to enforce Security Policies on networks. It is my belief that regardless of the legacy name given to the protocol, EAP, EAP makes a great transport for dealing with the age old questions "is this user who they say they are" which has been expanded in recent years to be, "is this user who they say they are and are they using a company owned system in the right part of the building at the right time of day). Yes the later half of the second age old question is a mix of authentication and authorization, but this is the world we live in, for better or worse.


NEA and other attributes/data tunneled inside of EAP allow the authentication server and thus the business make more educated decisions about whether or not someone is who they say they are or a machine is what it says it is. This is authentication. Think of this in the terms of the security guard that checks ID badges when you enter the building. If a homeless person, all dressed in rags walks in to Chase Bank headquarters with a valid ID badge, the Security Guard will probably not trust his authentication, the ID badge. Even though the ID badge is valid. The ID badge grants the holder to access certain resources, but the Security Guard through visual inspection is able to make a better determination of are these authentication credentials valid. The username / password presented is often not enough to guarantee that the user is who the user says they are. A business may want to make sure they are using a certain computer, the computer is in a certain location, the computer is being used a certain time of day, and the computer has certain things, before they grant network access. This is NOT authorization. It is all about making sure people are really and honestly who they say they are.=A0 Some businesses and government agencies build profiles of work habits.=A0 So if I try to use my username/password after what is deemed my normal work patterns, that username/password is not accepted.=A0 It is not that I am not authorized to use the systems at weird hours, the system just knows that it is out side my normal usage times and thus it may need to ask me follow up questions to verify that I really am who I say I am.=A0 This is all about authentication.



Bret



On Wed, Aug 12, 2009= at 7:33 AM, Dave Nelson <d.b.nelson@comcast.net> wrote:
Stephen Hanna writes...

> I suppose that my basic argument is a practical one. Password
> change, channel bindings, and NEA assessments are useful things
> to do during the EAP exchange.

That much I think most of us would agree with. =A0EAP is a convenient= protocol
to use for exchanging that kind of information, even if it's stretching= the
original purpose of EAP. =A0Remember, EAP was to be used during the
authentication phase of PPP.

> They are relevant to the authentication process and the server's > decision about whether to grant network access.

I really hate to have to agree with Glen's position on this, but = I do. =A0I
firmly believe that you, and others, are conflating elements of
authorization into the meaning of authentication. =A0Authentication is abou= t
proof of identity. =A0I can be authenticated as Dave Nelson, by various mea= ns.
I'm still Dave Nelson whether I'm a good guy or a bad guy. =A0If I&= #39;m a bad
guy, you may not want to grant me access to your home. =A0If I'm a good= guy,
but an active carrier for Swine Flue, you still may not want to grant me access to your home. =A0In any case I'm still Dave Nelson, and none of = the
other "access control" considerations affect my proof of identity= . =A0All
those other considerations are authorization considerations, not
authentication considerations.

I agree that using words clearly and with their exact meaning is important.=

However, it appears that the real point of this semantic debate is whether<= br> the "domain of applicability" for EAP will admit the introduction= on very
useful, but clearly non-authentication, data elements. =A0It's quite po= ssible
for the WG to have consensus to do so and at the same time be in apparent conflict with the "domain of applicability" for EAP. =A0Of course= , maybe the
WG has within its charter the authority to revise the "domain of
applicability" for EAP.

> There is no harm in doing them as part of the EAP exchange. And there<= br> > is no better way to implement them.

Assuming that's true -- and it may well be -- then EMU ought to e= xpand the
definition of EAP to explicitly include authorization related data, rather<= br> than making semantic, re-definitional, arguments that the authorization dat= a
is really authentication data.


_______________________________________________
Emu mailing list
Emu@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/emu



--

-------= --------------------------------------------------------------------------<= br>Bret Jordan CISSP
Treasurer, OpenSEA Alliance
jordan@open1x.org
---------------------------------------------------------------------------= ------
"Without cryptography vihv vivc ce xhrnrw, however,
the= only thing that can not be unscrambled is an egg."

--000e0cd29cd8ecbc9f0470f7ec0a-- From glenzorn@comcast.net Wed Aug 12 16:05:27 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E2B23A6A3D for ; Wed, 12 Aug 2009 16:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPnp-ikwnRfz for ; Wed, 12 Aug 2009 16:05:26 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id 96FA83A6890 for ; Wed, 12 Aug 2009 16:05:26 -0700 (PDT) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id TYKW1c0030vp7WLA9aznNB; Wed, 12 Aug 2009 22:59:47 +0000 Received: from gwzPC ([71.231.55.1]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id Tazl1c00M01ae1j8RazmtC; Wed, 12 Aug 2009 22:59:46 +0000 From: "Glen Zorn" To: "'Dave Nelson'" References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org> <4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net><4A81BA2B.1090400@deployingradius.com><00c301ca1ac3$8a0af800$9e20e800$@net><4A81EBBB.7040507@deployingradius.com><012a01ca1b05$53ffa610$fbfef230$@net> <4A824F85.6080307@deployingradius.com> <144465FACC914EA48639B7CACC77C68D@NEWTON603> In-Reply-To: <144465FACC914EA48639B7CACC77C68D@NEWTON603> Date: Wed, 12 Aug 2009 15:59:44 -0700 Message-ID: <00a901ca1ba0$95c76330$c1562990$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcobC/c8C+lRbbVKQBSEz+nOpjUFlgAQYtcgABRccpA= Content-Language: en-us x-cr-hashedpuzzle: fWU= BI44 Bd0F D7jk F+cr JO1F Ja2S Kc64 LGK0 MC6s MDv7 PgtX QfIW RKyv SpIa VGgE; 2; ZAAuAGIALgBuAGUAbABzAG8AbgBAAGMAbwBtAGMAYQBzAHQALgBuAGUAdAA7AGUAbQB1AEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {BB7AA1E1-9BD3-4AA8-B2BE-27446DA9224D}; ZwBsAGUAbgB6AG8AcgBuAEAAYwBvAG0AYwBhAHMAdAAuAG4AZQB0AA==; Wed, 12 Aug 2009 22:59:39 GMT; UgBFADoAIABbAEUAbQB1AF0AIABFAEEAUAAgAGEAbgBkACAAYQB1AHQAaABvAHIAaQB6AGEAdABpAG8AbgA= x-cr-puzzleid: {BB7AA1E1-9BD3-4AA8-B2BE-27446DA9224D} Cc: emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 23:05:27 -0000 Dave Nelson [mailto://d.b.nelson@comcast.net] writes: > Alan DeKok writes... > > > > A server can tell me that I'm not authorized without > > > knowing who I am? > > > > Yes. A policy could state that all logins between 5pm > > and 9am are to be rejected. In that case, it can reject > > you without knowing (or caring) who you are. This process > > can't be "authorization", because it can happen *before* > > authentication. > > I hate to jump into the heated debates over terminology, but I have to > support Glen in this case. Alan, I'm sorry, you're simply mistaken > about > this. > > Authentication is "proof of identity", i.e., it's about who you are. > Authorization is about "access control policy", i.e., what you may do. > In > the example that you cite above, the action is clearly authorization. > The > server is enforcing the "access control policy" that the "wildcard" > user is > prohibited from logging in during the hours of 5 PM and 9 AM. This > authorization action *was* preceded by an implicit authentication > action. > It's just that the "wildcard" user, i.e., anyone on the planet, can > easily > be authenticated without the exchange of credentials. I don't actually think that we need to invent a NULL authentication type here: there is no authentication nor any authorization in this case, there is just a fixed policy. There are lots of policies that are unrelated to both authentication and authorization, including policies controlling network access. For example, it might be a corporation's policy not to put Ethernet ports in conference rooms, so unless your laptop have a wireless interface, no network access. This policy has nothing to do with either authentication or authorization, only with having the right equipment (not unlike NEA). From stefan.winter@restena.lu Wed Aug 12 23:27:51 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1029D3A68A0 for ; Wed, 12 Aug 2009 23:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgPkcevFkYst for ; Wed, 12 Aug 2009 23:27:50 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF6283A685E for ; Wed, 12 Aug 2009 23:27:49 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 08F9E10A82; Thu, 13 Aug 2009 08:23:46 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id DF19010A81; Thu, 13 Aug 2009 08:23:45 +0200 (CEST) Message-ID: <4A83B266.8080405@restena.lu> Date: Thu, 13 Aug 2009 08:27:50 +0200 From: Stefan Winter User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: Alan DeKok References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org> <4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net><4A81BA2B.1090400@deployingradius.com><00c301ca1ac3$8a0af800$9e20e800$@net><4A81EBBB.7040507@deployingradius.com><012a01ca1b05$53ffa610$fbfef230$@net> <4A824F85.6080307@deployingradius.com> <144465FACC914EA48639B7CACC77C68D@NEWTON603> <4A82C45A.2030605@deployingradius.com> <111EFB0EC0224D21B64121456DAB1D4C@NEWTON603> <4A82D4F4.6050903@deployingradius.com> In-Reply-To: <4A82D4F4.6050903@deployingradius.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV Cc: emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 06:27:51 -0000 Hello, >> That's the straightforward approach. It avoids the need to cling to >> alternate definitions of well understood terms. If you need to re-charter >> to gain that authority, then so be it. IMHO, this whole discussion looks >> like an end-run around the "domain of applicability" restrictions for EAP. >> > > I agree it does look that way. I don't even think that's a wrong > characterization of the issue. > It also reminds me of the discussion in radext prior to the last re-charter, when "No new security mechanisms will be defined for RADIUS" but at the same time crypto-agility and keywrap lay on the table. There were lengthy and at times seemingly far-fetched arguments on why this would or would not be permitted by the charter. In the end, things were clarified by issuing a new charter and everybody lived happily ever after (well, sortof ...). >> Shall we take the high road here? At the very least, you could seek >> clarification from the IESG as to whether they think that the current >> "domain of applicability" for EAP embraces the "additional data" you want to >> include. After all, enforcement of "applicability statements" is a very hit >> or miss thing in the IETF. You may get lucky. :-) >> > > I would prefer to get WG consensus first. If the WG believes it's a > good idea, the re-chartering process becomes simpler. > I think it's a good idea to acknowledge the reality that transport of authorization data happens right now in EAP methods. I also think it's a good idea to have both authentication and authorization data in EAP. If a re-charter were to acknowledge that EMU is also allowed to work on authorization, I think we might end up with a way cleaner, proper approach to handle authorization in EAP (which might end Dave's perceived inappropriateness of it). Having an encrypted channel to exchange authorization information post-authentication, even if the authentication does not set up a tunnel for it comes to mind. That way, the EAP conversation could for example always carry NEA information, agnostic of the protocol used in the prior authentication phase. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Rseau Tlinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 From jsalowey@cisco.com Thu Aug 13 12:24:54 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D8CA28C10E for ; Thu, 13 Aug 2009 12:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+Rx6fKuVseD for ; Thu, 13 Aug 2009 12:24:53 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 846BC3A6B9B for ; Thu, 13 Aug 2009 12:24:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOMFhEqrR7PD/2dsb2JhbAC7FIgrkRcFgjiBYQ X-IronPort-AV: E=Sophos;i="4.43,375,1246838400"; d="scan'208";a="195342205" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 13 Aug 2009 19:24:46 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7DJOlGN028359; Thu, 13 Aug 2009 12:24:47 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7DJOlQK024041; Thu, 13 Aug 2009 19:24:47 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 12:24:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Aug 2009 12:24:43 -0700 Message-ID: In-Reply-To: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EAP and authorization Thread-Index: AcoXY0bvU1SkoJktTJ64sMyZV/eh5wE3nfmw References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org> From: "Joseph Salowey (jsalowey)" To: "Alper Yegin" , X-OriginalArrivalTime: 13 Aug 2009 19:24:46.0974 (UTC) FILETIME=[B81131E0:01CA1C4B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4084; t=1250191487; x=1251055487; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Emu]=20EAP=20and=20authorization |Sender:=20; bh=Cz9WFdRUje9Zbt+1YUjYKwdLoJmp+Z/EAKAFWEXpR+g=; b=WM0siS90YNj9dXH+3pFGDMWAt0++qj6Kq27q9lbGf8nSB12C6zCxfiTbd+ EkZOzGGCPB4K9z0pWNnkhU8V9pRUuljkrW/8xphYJVML8AjEnN1/pOGQ4zxR vWEj3It1Wa; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 19:24:54 -0000 There have been a lot of proposals about EAP and authorization in the past. At its very basis EAP performs authentication at the time of service access and the data resulting from the authentication can then be used for authorization and accounting purposes. Some of the proposals attempt to enhance this in various ways. =20 One way is to carry additional data for use in the authorization process. EAP channel bindings are perhaps the simplest form of authorization data proposed for EAP. The authorization data is directly related to the service which is performing the authentication, at the time of authentication and the exchange is relatively simple; data sent from client and result response from server. This exchange helps to ensure that an authenticator isn't trying to provide services that it is not authorized to. I don't see much purpose in channel bindings if they are not used for authorization or accounting for later forensic analysis of authorization after the event.=20 There are other types of data that may be collected for authorization. One example is the validation of the "security posture" of the peer in which information about the peers compliance with a particular policy is collected. This example may require the exchange of more data and require more complex exchanges than channel bindings. This process may even involve authentication. =20 There are other ways in which EAP has proposed authorization enhancements. Other proposals have dealt with requesting authorizations for or providing authorization data to services other than the one that is performing the authentication. In addition proposals have discussed authorization after the initial authentication to the service. =20 I think carrying channel bindings within EAP is useful and necessary. I believe it is also reasonable to carry other exchanges to establish data for authorization. However, I think there are some limitations. For example carrying large amounts of data is probably not a good thing. I also think we have to be careful to not leave end stations with the only means to communicate is through EAP. I don't think we should be applying patches or browsing the web through EAP (I don't think anyone is proposing this, but I'm not certain). This means that a some point other communication channels have to be established to perform these functions. =20 When we get into the realm of using EAP for establishing authorization data for other services, requesting authorization or invoking authorization at times other than authentication I think there is a much bigger gray area. =20 Joe > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On=20 > Behalf Of Alper Yegin > Sent: Friday, August 07, 2009 6:31 AM > To: emu@ietf.org > Subject: [Emu] EAP and authorization >=20 > This issue came up during the last IETF meeting when the WG=20 > discussed channel binding. >=20 > =20 >=20 > Pasi said the discussion was within the scope of EMU WG charter. >=20 > =20 >=20 > - A document that defines EAP channel bindings and provides=20 > guidance for establishing EAP channel bindings within EAP methods. >=20 > =20 >=20 > =20 >=20 > - A mechanism to support extensible communication within a=20 > TLS protected tunnel. >=20 > =20 >=20 > =20 >=20 > I'm not against this. But let's face it, this is venturing=20 > into dealing with authorization parameters with EAP (EAP=20 > layer? EAP method layer? Etc.) I'm not against that either.=20 > In fact, I know there are a lot of people who'd be happy to=20 > see that happen.=20 >=20 > =20 >=20 > So, my question is, is this what we are doing: Enabling EAP=20 > to exchange authorization parameters among the EAP peer -=20 > authenticator - authentication server? If not, I hope someone=20 > can explain how this is different than what it takes to solve=20 > channel binding problem. >=20 > =20 >=20 > Thanks. >=20 > =20 >=20 > Alper >=20 > =20 >=20 > =20 >=20 >=20 From jsalowey@cisco.com Thu Aug 13 12:24:54 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CECE3A6AA4 for ; Thu, 13 Aug 2009 12:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjJZPPfzj8rQ for ; Thu, 13 Aug 2009 12:24:53 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 6C6E23A6B96 for ; Thu, 13 Aug 2009 12:24:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOMFhEqrR7MV/2dsb2JhbAC7FIgrkRcFgjiBYQ X-IronPort-AV: E=Sophos;i="4.43,375,1246838400"; d="scan'208";a="195342201" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 13 Aug 2009 19:24:45 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7DJOkV5014376; Thu, 13 Aug 2009 12:24:47 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n7DJOkT9016045; Thu, 13 Aug 2009 19:24:46 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 12:24:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Aug 2009 12:24:43 -0700 Message-ID: In-Reply-To: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EAP and authorization Thread-Index: AcoXY0bvU1SkoJktTJ64sMyZV/eh5wE3nfmw References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org> From: "Joseph Salowey (jsalowey)" To: "Alper Yegin" , X-OriginalArrivalTime: 13 Aug 2009 19:24:46.0646 (UTC) FILETIME=[B7DF2560:01CA1C4B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4084; t=1250191487; x=1251055487; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Emu]=20EAP=20and=20authorization |Sender:=20; bh=Cz9WFdRUje9Zbt+1YUjYKwdLoJmp+Z/EAKAFWEXpR+g=; b=m4i3rMSzuDar0j2TBLf5A1BhvlBKeMgjNT3DOEUrSrn9PDrTDZYwYgH11Y INdHEqMKmqaS3we5wu9qzYjnBU3wg6hzNvsC7uLvAA2oDHDQ1M5Ac3dWgkq3 eNd5VCiR6QonDAIQZUuKeF+N7tw6yFYQCq/8YPfyMukrpk1CNJRB0=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 19:24:54 -0000 There have been a lot of proposals about EAP and authorization in the past. At its very basis EAP performs authentication at the time of service access and the data resulting from the authentication can then be used for authorization and accounting purposes. Some of the proposals attempt to enhance this in various ways. =20 One way is to carry additional data for use in the authorization process. EAP channel bindings are perhaps the simplest form of authorization data proposed for EAP. The authorization data is directly related to the service which is performing the authentication, at the time of authentication and the exchange is relatively simple; data sent from client and result response from server. This exchange helps to ensure that an authenticator isn't trying to provide services that it is not authorized to. I don't see much purpose in channel bindings if they are not used for authorization or accounting for later forensic analysis of authorization after the event.=20 There are other types of data that may be collected for authorization. One example is the validation of the "security posture" of the peer in which information about the peers compliance with a particular policy is collected. This example may require the exchange of more data and require more complex exchanges than channel bindings. This process may even involve authentication. =20 There are other ways in which EAP has proposed authorization enhancements. Other proposals have dealt with requesting authorizations for or providing authorization data to services other than the one that is performing the authentication. In addition proposals have discussed authorization after the initial authentication to the service. =20 I think carrying channel bindings within EAP is useful and necessary. I believe it is also reasonable to carry other exchanges to establish data for authorization. However, I think there are some limitations. For example carrying large amounts of data is probably not a good thing. I also think we have to be careful to not leave end stations with the only means to communicate is through EAP. I don't think we should be applying patches or browsing the web through EAP (I don't think anyone is proposing this, but I'm not certain). This means that a some point other communication channels have to be established to perform these functions. =20 When we get into the realm of using EAP for establishing authorization data for other services, requesting authorization or invoking authorization at times other than authentication I think there is a much bigger gray area. =20 Joe > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On=20 > Behalf Of Alper Yegin > Sent: Friday, August 07, 2009 6:31 AM > To: emu@ietf.org > Subject: [Emu] EAP and authorization >=20 > This issue came up during the last IETF meeting when the WG=20 > discussed channel binding. >=20 > =20 >=20 > Pasi said the discussion was within the scope of EMU WG charter. >=20 > =20 >=20 > - A document that defines EAP channel bindings and provides=20 > guidance for establishing EAP channel bindings within EAP methods. >=20 > =20 >=20 > =20 >=20 > - A mechanism to support extensible communication within a=20 > TLS protected tunnel. >=20 > =20 >=20 > =20 >=20 > I'm not against this. But let's face it, this is venturing=20 > into dealing with authorization parameters with EAP (EAP=20 > layer? EAP method layer? Etc.) I'm not against that either.=20 > In fact, I know there are a lot of people who'd be happy to=20 > see that happen.=20 >=20 > =20 >=20 > So, my question is, is this what we are doing: Enabling EAP=20 > to exchange authorization parameters among the EAP peer -=20 > authenticator - authentication server? If not, I hope someone=20 > can explain how this is different than what it takes to solve=20 > channel binding problem. >=20 > =20 >=20 > Thanks. >=20 > =20 >=20 > Alper >=20 > =20 >=20 > =20 >=20 >=20 From jsalowey@cisco.com Thu Aug 13 12:32:21 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 381A93A6AA4 for ; Thu, 13 Aug 2009 12:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txrzm4kssbza for ; Thu, 13 Aug 2009 12:32:20 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3ACE23A6BCA for ; Thu, 13 Aug 2009 12:32:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAJUHhEqrR7PD/2dsb2JhbACPXas/iCs2AwSQWwWCUYFI X-IronPort-AV: E=Sophos;i="4.43,375,1246838400"; d="scan'208";a="366892976" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 13 Aug 2009 19:32:02 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7DJW2LW011160; Thu, 13 Aug 2009 12:32:02 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n7DJW0Pb023694; Thu, 13 Aug 2009 19:32:02 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 12:32:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Aug 2009 12:31:59 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] #18 Internationalization Thread-Index: AcoZiX10ZlaQcfV9QcC0X0zyBQBAcQCwnY7g References: From: "Joseph Salowey (jsalowey)" To: "Bernard Aboba" , X-OriginalArrivalTime: 13 Aug 2009 19:32:01.0142 (UTC) FILETIME=[BAD9F960:01CA1C4C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2180; t=1250191922; x=1251055922; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Emu]=20#18=20Internationalization |Sender:=20; bh=quTK+h+ZPlK2pfrdT3jpVSmldWfimY3+9QhCXRrG9fU=; b=oneMqLSus0VQMsI5cu1avqWB8MXAdhncqxCB50SIW9H5/yiVlmIC2HQOcZ 0EuEPDE/apug8yZV3WfPOpgiHeu2ruRXYMHhlqvBXh0xoUCsGk/I6UaGyjiR XxIee36HTL; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Emu] #18 Internationalization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 19:32:21 -0000 The core chartered requirements also include the use of the tunnel method for password authentication, so it is important to consider this case. =20 In addition, there is a proposal for defining conventions for defining generic textual attributes within the tunnel. I think the main advantage of doing this would be to have a consistent approach to internationalization. If this is too difficult, perhaps it should be dropped, although I'm not sure these requirements would be too different form what is needed for password authentication. =20 Joe > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On=20 > Behalf Of Bernard Aboba > Sent: Monday, August 10, 2009 12:09 AM > To: emu@ietf.org > Subject: Re: [Emu] #18 Internationalization >=20 > Joe Salowey said: >=20 > " > #18: Internationalization >=20 > Is the use of UTF-8 sufficient or is other tagging necessary. The > following cases need to be considered: >=20 > 1. Usernames and passwords > 2. Prompts and error associated with username and password > authentication > 3. Other textual data > " >=20 > It's important to keep in mind that this is a tunnel method=20 > requirements document. The tunnel method will use TLS, so as=20 > far as bringing up the tunnel is concerned, it is TLS=20 > internationalization that is relevant here. With respect to=20 > inner authentication methods, it is the internationalization=20 > support of the inner method that matters.=20 >=20 > Given this, what exactly is within the purview of the tunnel=20 > method with respect to internationalization? Clearly, the=20 > EMU WG is not chartered to change EAP itself, TLS or existing=20 > EAP methods. =20 >=20 > Given that, what *exactly* does this requirement refer to? =20 > While it's certainly possible for a tunnel method to do=20 > language negotiation, given that such a negotiation wouldn't=20 > affect most of what goes on in the method (e.g. TLS or the=20 > inner method), I don't see what good it would do.=20 >=20 >=20 >=20 >=20 > =20 > =09 >=20 From bernard_aboba@hotmail.com Thu Aug 13 16:39:55 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0A873A6D5F for ; Thu, 13 Aug 2009 16:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.836 X-Spam-Level: X-Spam-Status: No, score=-0.836 tagged_above=-999 required=5 tests=[AWL=1.762, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieKq3uChILCC for ; Thu, 13 Aug 2009 16:39:54 -0700 (PDT) Received: from blu0-omc4-s1.blu0.hotmail.com (blu0-omc4-s1.blu0.hotmail.com [65.55.111.140]) by core3.amsl.com (Postfix) with ESMTP id 10A513A6D6B for ; Thu, 13 Aug 2009 16:39:36 -0700 (PDT) Received: from BLU137-W13 ([65.55.111.137]) by blu0-omc4-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 16:39:17 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_9d319aff-dd69-4063-924b-998878c2a534_" X-Originating-IP: [131.107.0.104] From: Bernard Aboba To: "Joseph Salowey (jsalowey)" , Date: Thu, 13 Aug 2009 16:39:18 -0700 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 13 Aug 2009 23:39:17.0934 (UTC) FILETIME=[4644C4E0:01CA1C6F] Subject: Re: [Emu] #18 Internationalization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 23:39:55 -0000 --_9d319aff-dd69-4063-924b-998878c2a534_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Within Tunnel methods=2C exchanges of user names and passwords are often ac= complished either using TLS or existing EAP methods (e.g. Identity or inner authentication me= thods). There are some tunnel methods that have their own native authentication methods (e.g.= EAP-TTLSv0)=2C but even those typically reuse functionality defined previously (e.g. Diameter = AVPs for PAP=2C CHAP=2C etc.). =20 Given that=2C I'd suggest that the scope of the requirements needs to be cl= arified. For example=2C=20 support for negotiation of language tags might make sense for tunnel method= s that carry such text in an EAP-method specific way. However=2C a method that relies solely= on TLS or existing EAP methods would not benefit from this functionality=2C and the requiremen= ts document should not imply that it is within scope for proposals to change TLS=2C RFC 3748 o= r existing EAP methods so as to better support internationalization.=20 > Subject: RE: [Emu] #18 Internationalization > Date: Thu=2C 13 Aug 2009 12:31:59 -0700 > From: jsalowey@cisco.com > To: bernard_aboba@hotmail.com=3B emu@ietf.org >=20 > The core chartered requirements also include the use of the tunnel > method for password authentication=2C so it is important to consider this > case. =20 >=20 > In addition=2C there is a proposal for defining conventions for defining > generic textual attributes within the tunnel. I think the main > advantage of doing this would be to have a consistent approach to > internationalization. If this is too difficult=2C perhaps it should be > dropped=2C although I'm not sure these requirements would be too differen= t > form what is needed for password authentication. =20 >=20 > Joe >=20 > > -----Original Message----- > > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On=20 > > Behalf Of Bernard Aboba > > Sent: Monday=2C August 10=2C 2009 12:09 AM > > To: emu@ietf.org > > Subject: Re: [Emu] #18 Internationalization > >=20 > > Joe Salowey said: > >=20 > > " > > #18: Internationalization > >=20 > > Is the use of UTF-8 sufficient or is other tagging necessary. The > > following cases need to be considered: > >=20 > > 1. Usernames and passwords > > 2. Prompts and error associated with username and password > > authentication > > 3. Other textual data > > " > >=20 > > It's important to keep in mind that this is a tunnel method=20 > > requirements document. The tunnel method will use TLS=2C so as=20 > > far as bringing up the tunnel is concerned=2C it is TLS=20 > > internationalization that is relevant here. With respect to=20 > > inner authentication methods=2C it is the internationalization=20 > > support of the inner method that matters.=20 > >=20 > > Given this=2C what exactly is within the purview of the tunnel=20 > > method with respect to internationalization? Clearly=2C the=20 > > EMU WG is not chartered to change EAP itself=2C TLS or existing=20 > > EAP methods. =20 > >=20 > > Given that=2C what *exactly* does this requirement refer to? =20 > > While it's certainly possible for a tunnel method to do=20 > > language negotiation=2C given that such a negotiation wouldn't=20 > > affect most of what goes on in the method (e.g. TLS or the=20 > > inner method)=2C I don't see what good it would do.=20 > >=20 > >=20 > >=20 > >=20 > > =20 > > =09 > >=20 --_9d319aff-dd69-4063-924b-998878c2a534_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Within Tunnel methods=2C exchanges of user names and passwords are often ac= complished either
using TLS or existing EAP methods (e.g. Identity or in= ner authentication methods). =3B =3B There are
some tunnel metho= ds that have their own native authentication methods (e.g. EAP-TTLSv0)=2C b= ut
even those typically reuse functionality defined previously (e.g. Dia= meter AVPs for PAP=2C CHAP=2C etc.). =3B

Given that=2C I'd sugg= est that the scope of the requirements needs to be clarified. =3B For e= xample=2C
support for negotiation of language tags might make sense for= tunnel methods that carry such
text in an EAP-method specific way. = =3B However=2C a method that relies solely on TLS or existing
EAP method= s would not benefit from this functionality=2C and the requirements documen= t should
not imply that it is within scope for proposals to change TLS= =2C RFC 3748 or existing EAP methods
so as to better support internation= alization.

>=3B Subject: RE: [Emu] #18 Internationalization
&g= t=3B Date: Thu=2C 13 Aug 2009 12:31:59 -0700
>=3B From: jsalowey@cisco= .com
>=3B To: bernard_aboba@hotmail.com=3B emu@ietf.org
>=3B
= >=3B The core chartered requirements also include the use of the tunnel>=3B method for password authentication=2C so it is important to consid= er this
>=3B case.
>=3B
>=3B In addition=2C there is a p= roposal for defining conventions for defining
>=3B generic textual att= ributes within the tunnel. I think the main
>=3B advantage of doing t= his would be to have a consistent approach to
>=3B internationalizatio= n. If this is too difficult=2C perhaps it should be
>=3B dropped=2C = although I'm not sure these requirements would be too different
>=3B f= orm what is needed for password authentication.
>=3B
>=3B Joe<= br>>=3B
>=3B >=3B -----Original Message-----
>=3B >=3B Fro= m: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On
>=3B >=3B = Behalf Of Bernard Aboba
>=3B >=3B Sent: Monday=2C August 10=2C 2009 = 12:09 AM
>=3B >=3B To: emu@ietf.org
>=3B >=3B Subject: Re: [E= mu] #18 Internationalization
>=3B >=3B
>=3B >=3B Joe Salowey= said:
>=3B >=3B
>=3B >=3B "
>=3B >=3B #18: Internati= onalization
>=3B >=3B
>=3B >=3B Is the use of UTF-8 suffici= ent or is other tagging necessary. The
>=3B >=3B following cases n= eed to be considered:
>=3B >=3B
>=3B >=3B 1. Usernames and = passwords
>=3B >=3B 2. Prompts and error associated with username a= nd password
>=3B >=3B authentication
>=3B >=3B 3. Other text= ual data
>=3B >=3B "
>=3B >=3B
>=3B >=3B It's importa= nt to keep in mind that this is a tunnel method
>=3B >=3B requireme= nts document. The tunnel method will use TLS=2C so as
>=3B >=3B fa= r as bringing up the tunnel is concerned=2C it is TLS
>=3B >=3B int= ernationalization that is relevant here. With respect to
>=3B >=3B= inner authentication methods=2C it is the internationalization
>=3B = >=3B support of the inner method that matters.
>=3B >=3B
>= =3B >=3B Given this=2C what exactly is within the purview of the tunnel <= br>>=3B >=3B method with respect to internationalization? Clearly=2C t= he
>=3B >=3B EMU WG is not chartered to change EAP itself=2C TLS or= existing
>=3B >=3B EAP methods.
>=3B >=3B
>=3B >= =3B Given that=2C what *exactly* does this requirement refer to?
>= =3B >=3B While it's certainly possible for a tunnel method to do
>= =3B >=3B language negotiation=2C given that such a negotiation wouldn't <= br>>=3B >=3B affect most of what goes on in the method (e.g. TLS or the=
>=3B >=3B inner method)=2C I don't see what good it would do.
= >=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B
>= =3B >=3B <=3Bhttp://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_Gr= eaterGood>=3B
>=3B >=3B
>=3B >=3B
= --_9d319aff-dd69-4063-924b-998878c2a534_-- From aland@deployingradius.com Thu Aug 13 23:16:56 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C77E23A6D8A for ; Thu, 13 Aug 2009 23:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGpYyIaKw4ow for ; Thu, 13 Aug 2009 23:16:56 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id E50703A68D4 for ; Thu, 13 Aug 2009 23:16:55 -0700 (PDT) Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id AC174123443A; Fri, 14 Aug 2009 08:16:27 +0200 (CEST) Message-ID: <4A85013B.8060705@deployingradius.com> Date: Fri, 14 Aug 2009 08:16:27 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 06:16:56 -0000 Joseph Salowey (jsalowey) wrote: > There are other ways in which EAP has proposed authorization > enhancements. Other proposals have dealt with requesting authorizations > for or providing authorization data to services other than the one that > is performing the authentication. In addition proposals have discussed > authorization after the initial authentication to the service. I think part of the concern here is that authorization has traditionally involved the PDP telling the PEP how the user should be treated. The proposals on the table for EAP do not communicate authorization information over EAP to the PEP. As such, they do not fit well into the traditional model. > I think carrying channel bindings within EAP is useful and necessary. I > believe it is also reasonable to carry other exchanges to establish data > for authorization. ... of who, to what? This could be made clearer in the document. > However, I think there are some limitations. For > example carrying large amounts of data is probably not a good thing. I > also think we have to be careful to not leave end stations with the only > means to communicate is through EAP. I don't think we should be > applying patches or browsing the web through EAP (I don't think anyone > is proposing this, but I'm not certain). I can propose EAP-IP: carrying IP packets in EAP. It's crazy, but possible. The main limitation on bulk data transfer is that most EAP to RADIUS gateways (AP's, etc.) will terminate an EAP session after ~50 packets. > When we get into the realm of using EAP for establishing authorization > data for other services, requesting authorization or invoking > authorization at times other than authentication I think there is a much > bigger gray area. ERP is leveraging EAP to obtain authentication and authorization at later points in time. This seems to be acceptable. Alan DeKok. From david@mitton.com Fri Aug 14 08:13:39 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A45D3A6A96 for ; Fri, 14 Aug 2009 08:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id el1vtIe2q-yL for ; Fri, 14 Aug 2009 08:13:38 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0233.hostedemail.com [216.40.44.233]) by core3.amsl.com (Postfix) with ESMTP id A44E53A6860 for ; Fri, 14 Aug 2009 08:13:38 -0700 (PDT) Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay01.hostedemail.com (Postfix) with SMTP id 5A08918B9CDD for ; Fri, 14 Aug 2009 15:13:26 +0000 (UTC) X-Session-Marker: 6461766964406D6974746F6E2E636F6D X-Filterd-Recvd-Size: 2164 Received: from webmail04 (imap-ext [216.40.42.5]) (Authenticated sender: david@mitton.com) by omf06.hostedemail.com (Postfix) with ESMTP for ; Fri, 14 Aug 2009 15:13:26 +0000 (UTC) Received: from 128.221.197.55 ([128.221.197.55]) by webmail04 (Tucows Webmail) with HTTP; Fri, 14 Aug 2009 15:13:26 +0000 (GMT) Date: Fri, 14 Aug 2009 15:13:26 +0000 (GMT) From: David Mitton To: emu@ietf.org Message-ID: <2018380107.9112.1250262806060.JavaMail.mail@webmail04> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: Tucows Webmail X-Originating-IP: [128.221.197.55] Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: david@mitton.com List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 15:13:39 -0000 On Aug 14, 2009, Alan DeKok wrote: ... > I can propose EAP-IP: carrying IP packets in EAP. It's crazy, but > possible. In many ways that's what PANA is about, but that's not what spurred me to respond..... > The main limitation on bulk data transfer is that most EAP to > RADIUS gateways (AP's, etc.) will terminate an EAP session after ~50 > packets. This kind of thing drives me crazy. Why are their such policies? I develop/maintain a user interactive time-based EAP authentication that, unfortunately, has to jump through all sorts of real-time hoops for Access Points and 802.1x clients that have these ad-hoc rules about what constitutes a "valid" EAP session time and packet wise. It's one thing when many EAP methods deal with cached non-interactive credentials. They can wham, bam, thank you ma'am in less than 10 seconds. It's another when a user and an authentication device is in the loop. My user may wait for a new OTP value to come around, fumble finger it in, and possibly have to do it twice if he got it wrong or is out of the sync window. It can take several minutes. Please do not build EAP session breaking assumptions into AAA implementations. Sorry for the rant, but I still need to write up my EAP implementation experiences from doing my SecurID Vista client. The pain still hasn't completely subsided completely yet. Dave. From dharkins@lounge.org Sun Aug 16 00:29:58 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 227C428C0D7 for ; Sun, 16 Aug 2009 00:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.29 X-Spam-Level: X-Spam-Status: No, score=-5.29 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omaN-5ahi8QN for ; Sun, 16 Aug 2009 00:29:56 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id C4F8B3A687F for ; Sun, 16 Aug 2009 00:29:56 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id B4E5D10224074; Sun, 16 Aug 2009 00:30:00 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sun, 16 Aug 2009 00:30:00 -0700 (PDT) Message-ID: In-Reply-To: References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org><4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net><4A81BA2B.1090400@deployingradius.com><00c201ca1ac1$64b9f800$2e2de800$@net><00e001ca1ad8$97a63230$c6f29690$@net> <64267BE4CECB4CAE83EFB0A6F5039285@NEWTON603> Date: Sun, 16 Aug 2009 00:30:00 -0700 (PDT) From: "Dan Harkins" To: "Stephen Hanna" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "emu@ietf.org" Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 07:29:58 -0000 Hi Steve, I don't think what you're talking about falls into the definition of "channel binding", at least not the one I have, and I wouldn't be surprised if others (like maybe people on the IESG) agree. And I agree with Dave, and Glen, that this isn't authentication either. "channel bindings" are supposed to solve the lying NAS problem* which is an issue of authentication (is this guy really who he claims to be?). What you want to do is use the EAP tunnel to transfer other kinds of data to do NEA posture checking. And, yes, we should determine whether it is permissible for EMU to work on such a thing. What we shouldn't do is say that it's really part of "authentication" or it's part of "channel binding" and just proceed. Dan. *the example given, at the Philly IETF I think, was of a Russian mobile phone operator that made its cell towers broadcast out that they were actually from an Estonian mobile phone operator and then billed Estonians whose phones connected to them (even when they had manual network selection turned on to intentionally avoid accidentially connecting to the Russian network) as if they were roaming on the Russian network. On Wed, August 12, 2009 11:52 am, Stephen Hanna wrote: > However, I agree that it would be better to get IESG clarification > that carrying authorization data in EAP is permissible. As Alan > suggested, the first step is probably to have a WG consensus > check to verify that we have rough consensus that this should > be permitted. After that, maybe we would ask the IESG for a > clarification of the applicability statement for EAP. > > I will note that the IESG has already approved a change to the > EMU charter to add a work item for channel bindings. So they > have already indicated their support for that effort. > > Thanks, > > Steve > >> -----Original Message----- >> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On >> Behalf Of Dave Nelson >> Sent: Wednesday, August 12, 2009 9:33 AM >> To: emu@ietf.org >> Subject: Re: [Emu] EAP and authorization >> >> Stephen Hanna writes... >> >> > I suppose that my basic argument is a practical one. Password >> > change, channel bindings, and NEA assessments are useful things >> > to do during the EAP exchange. >> >> That much I think most of us would agree with. EAP is a >> convenient protocol >> to use for exchanging that kind of information, even if it's >> stretching the >> original purpose of EAP. Remember, EAP was to be used during the >> authentication phase of PPP. >> >> > They are relevant to the authentication process and the server's >> > decision about whether to grant network access. >> >> I really hate to have to agree with Glen's position on this, >> but I do. I >> firmly believe that you, and others, are conflating elements of >> authorization into the meaning of authentication. >> Authentication is about >> proof of identity. I can be authenticated as Dave Nelson, by >> various means. >> I'm still Dave Nelson whether I'm a good guy or a bad guy. >> If I'm a bad >> guy, you may not want to grant me access to your home. If >> I'm a good guy, >> but an active carrier for Swine Flue, you still may not want >> to grant me >> access to your home. In any case I'm still Dave Nelson, and >> none of the >> other "access control" considerations affect my proof of >> identity. All >> those other considerations are authorization considerations, not >> authentication considerations. >> >> I agree that using words clearly and with their exact meaning >> is important. >> >> However, it appears that the real point of this semantic >> debate is whether >> the "domain of applicability" for EAP will admit the >> introduction on very >> useful, but clearly non-authentication, data elements. It's >> quite possible >> for the WG to have consensus to do so and at the same time be >> in apparent >> conflict with the "domain of applicability" for EAP. Of >> course, maybe the >> WG has within its charter the authority to revise the "domain of >> applicability" for EAP. >> >> > There is no harm in doing them as part of the EAP exchange. >> And there >> > is no better way to implement them. >> >> Assuming that's true -- and it may well be -- then EMU ought >> to expand the >> definition of EAP to explicitly include authorization related >> data, rather >> than making semantic, re-definitional, arguments that the >> authorization data >> is really authentication data. >> >> >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu >> > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > From aland@deployingradius.com Sun Aug 16 01:09:30 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A83033A6ABF for ; Sun, 16 Aug 2009 01:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOjNHdm3wmMl for ; Sun, 16 Aug 2009 01:09:29 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 982363A6839 for ; Sun, 16 Aug 2009 01:09:29 -0700 (PDT) Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id B398412342A5; Sun, 16 Aug 2009 10:09:33 +0200 (CEST) Message-ID: <4A87BEBD.2010407@deployingradius.com> Date: Sun, 16 Aug 2009 10:09:33 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Dan Harkins References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org><4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net><4A81BA2B.1090400@deployingradius.com><00c201ca1ac1$64b9f800$2e2de800$@net><00e001ca1ad8$97a63230$c6f29690$@net> <64267BE4CECB4CAE83EFB0A6F5039285@NEWTON603> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "emu@ietf.org" Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 08:09:30 -0000 Dan Harkins wrote: > "channel bindings" are supposed to solve the lying NAS problem* > which is an issue of authentication (is this guy really who he claims > to be?). What you want to do is use the EAP tunnel to transfer other > kinds of data to do NEA posture checking. And, yes, we should determine > whether it is permissible for EMU to work on such a thing. What we > shouldn't do is say that it's really part of "authentication" or it's > part of "channel binding" and just proceed. My question again is where do we draw the line? What information is permissible as authentication credentials, and what isn't permissible? And why? Some sites determine that username/password authentication is sufficient. Others also require that the MAC be known, too. Is the MAC part of the authentication credentials? Or is the site doing "posture checking" by requiring that the MAC be known? We need to achieve a common understanding before making any decisions. > *the example given, at the Philly IETF I think, was of a Russian > mobile phone operator that made its cell towers broadcast out that > they were actually from an Estonian mobile phone operator and then > billed Estonians whose phones connected to them (even when they had > manual network selection turned on to intentionally avoid accidentially > connecting to the Russian network) as if they were roaming on the > Russian network. That is largely an issue of fraud, and best *resolved* through legal methods. But channel bindings may permit the end user to *detect* the fraud, at least. Alan DeKok. From aland@deployingradius.com Sun Aug 16 01:30:05 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF2DE3A6D2C for ; Sun, 16 Aug 2009 01:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N38W6LplmCBL for ; Sun, 16 Aug 2009 01:30:05 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 856D53A6D14 for ; Sun, 16 Aug 2009 01:30:04 -0700 (PDT) Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id B757F12342A5; Sun, 16 Aug 2009 10:30:08 +0200 (CEST) Message-ID: <4A87C38F.9030505@deployingradius.com> Date: Sun, 16 Aug 2009 10:30:07 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: david@mitton.com References: <2018380107.9112.1250262806060.JavaMail.mail@webmail04> In-Reply-To: <2018380107.9112.1250262806060.JavaMail.mail@webmail04> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 08:30:05 -0000 David Mitton wrote: >> The main limitation on bulk data transfer is that most EAP to >> RADIUS gateways (AP's, etc.) will terminate an EAP session after ~50 >> packets. > > This kind of thing drives me crazy. Why are their such policies? To prevent bulk transfer of data over EAP, among others. > Please do not build EAP session breaking assumptions into AAA implementations. It would be useful to codify these experiences into an EAP "best practices" document. Alan DeKok. From dharkins@lounge.org Sun Aug 16 09:06:38 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 520573A6E7B for ; Sun, 16 Aug 2009 09:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.983 X-Spam-Level: X-Spam-Status: No, score=-5.983 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1OK7xBhU6P1 for ; Sun, 16 Aug 2009 09:06:37 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 8C9813A6B1B for ; Sun, 16 Aug 2009 09:06:37 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 2EE5610224074; Sun, 16 Aug 2009 09:06:42 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sun, 16 Aug 2009 09:06:42 -0700 (PDT) Message-ID: <1f4de74e2f95083ff1814d4a2cd5a8cd.squirrel@www.trepanning.net> In-Reply-To: <4A87BEBD.2010407@deployingradius.com> References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org><4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net><4A81BA2B.1090400@deployingradius.com><00c201ca1ac1$64b9f800$2e2de800$@net><00e001ca1ad8$97a63230$c6f29690$@net> <64267BE4CECB4CAE83EFB0A6F5039285@NEWTON603> <4A87BEBD.2010407@deployingradius.com> Date: Sun, 16 Aug 2009 09:06:42 -0700 (PDT) From: "Dan Harkins" To: "Alan DeKok" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "emu@ietf.org" Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 16:06:38 -0000 Hi Alan, On Sun, August 16, 2009 1:09 am, Alan DeKok wrote: > Dan Harkins wrote: >> "channel bindings" are supposed to solve the lying NAS problem* >> which is an issue of authentication (is this guy really who he claims >> to be?). What you want to do is use the EAP tunnel to transfer other >> kinds of data to do NEA posture checking. And, yes, we should determine >> whether it is permissible for EMU to work on such a thing. What we >> shouldn't do is say that it's really part of "authentication" or it's >> part of "channel binding" and just proceed. > > My question again is where do we draw the line? What information is > permissible as authentication credentials, and what isn't permissible? Authentication has to do with proving an identity. Authorization has to do with determining whether that proven identity is "good" or "bad". > And why? Because it helps answer questions like "why isn't this part of authentication?" > Some sites determine that username/password authentication is > sufficient. Others also require that the MAC be known, too. Is the MAC > part of the authentication credentials? Or is the site doing "posture > checking" by requiring that the MAC be known? I'm not sure what sites do what but I'm not aware of an EAP method that checks a username and a password AND a MAC address. If the policy says, "Alan DeKok is only allowed to access the network if he's on 00:01:02:03:04:05" then the MAC address is not an authentication credential because the username and password are deciding the identity and the MAC address is deciding whether that authenticated identity is "good" or "bad". > We need to achieve a common understanding before making any decisions. Yes, but I hope it's not by going through a hundred or so different things and gauging consensus on "is it authentication or authorization?" Ask yourself, what is the identity of this peer and is this thing critical to proving that identity or not? If it is critical to proving the identity (like a CA certificate to perform validation of the peer's certificate, for instance) then it's for authentication, otherwise it's not for authentication. Channel bindings are subtly different. Since a 2-party protocol is being used with 3 parties it is necessary to ensure that all 3 parties have a consistent view of all 3 identities. But that's still an authentication problem-- is this 3rd entity really who it says it is? Dan. From shanna@juniper.net Sun Aug 16 09:45:36 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FE783A6C22 for ; Sun, 16 Aug 2009 09:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGtbJ9Dv+o5Y for ; Sun, 16 Aug 2009 09:45:35 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 47C913A6EB4 for ; Sun, 16 Aug 2009 09:45:28 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSog3rCC34qgwdr7T3RvNUcuYPOsyVlP/@postini.com; Sun, 16 Aug 2009 09:45:34 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sun, 16 Aug 2009 09:44:59 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Sun, 16 Aug 2009 12:44:59 -0400 From: Stephen Hanna To: Dan Harkins Date: Sun, 16 Aug 2009 12:43:51 -0400 Thread-Topic: [Emu] EAP and authorization Thread-Index: AcoeQ17FjtUP43tHTmCzcgFa1E0X+QAScIlA Message-ID: References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org><4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net><4A81BA2B.1090400@deployingradius.com><00c201ca1ac1$64b9f800$2e2de800$@net><00e001ca1ad8$97a63230$c6f29690$@net> <64267BE4CECB4CAE83EFB0A6F5039285@NEWTON603> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "emu@ietf.org" Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 16:45:36 -0000 Actually, in the email that you responded to, I was referring to the EMU working group item in the current charter: - A document that defines EAP channel bindings and provides guidance for establishing EAP channel bindings within EAP methods. I hope that we can both agree that this falls within our definition of "channel binding". Otherwise, we really have a communication failure! ;-) I do not agree that EAP channel bindings are about authentication. They have two parts: checking whether the NAS is advertising services that it's not authorized to advertise and using information from the NAS (like which SSID the peer is trying to connect to) to supplement the AAA server's decision about whether to grant the requested access. Both of these are authorization decisions and they are made not based on authenticating the NAS (which we have had for many years in the form of the secret shared between the NAS and the AAA server) but on supplementary information about the SSIDs and other things being advertised by the NAS and requested by the EAP peer. I agree that NEA assessments are a different topic. They're not the same as channel bindings. I'd say that the data conveyed in EAP for channel bindings and for NEA assessments are both authorization data in that they are not authentication protocols but supplementary data that the AAA server will use in deciding whether access should be granted (and maybe whether other action should be taken, like getting the lying NAS repaired or sending remediation instructions to an unhealthy endpoint). Thanks, Steve > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org]=20 > Sent: Sunday, August 16, 2009 3:30 AM > To: Stephen Hanna > Cc: Dave Nelson; emu@ietf.org > Subject: Re: [Emu] EAP and authorization >=20 >=20 > Hi Steve, >=20 > I don't think what you're talking about falls into the definition > of "channel binding", at least not the one I have, and I wouldn't be > surprised if others (like maybe people on the IESG) agree. And I > agree with Dave, and Glen, that this isn't authentication either. >=20 > "channel bindings" are supposed to solve the lying NAS problem* > which is an issue of authentication (is this guy really who he claims > to be?). What you want to do is use the EAP tunnel to transfer other > kinds of data to do NEA posture checking. And, yes, we should=20 > determine > whether it is permissible for EMU to work on such a thing. What we > shouldn't do is say that it's really part of "authentication" or it's > part of "channel binding" and just proceed. >=20 > Dan. >=20 > *the example given, at the Philly IETF I think, was of a Russian > mobile phone operator that made its cell towers broadcast out that > they were actually from an Estonian mobile phone operator and then > billed Estonians whose phones connected to them (even when they had > manual network selection turned on to intentionally avoid=20 > accidentially > connecting to the Russian network) as if they were roaming on the > Russian network. >=20 > On Wed, August 12, 2009 11:52 am, Stephen Hanna wrote: > > However, I agree that it would be better to get IESG clarification > > that carrying authorization data in EAP is permissible. As Alan > > suggested, the first step is probably to have a WG consensus > > check to verify that we have rough consensus that this should > > be permitted. After that, maybe we would ask the IESG for a > > clarification of the applicability statement for EAP. > > > > I will note that the IESG has already approved a change to the > > EMU charter to add a work item for channel bindings. So they > > have already indicated their support for that effort. > > > > Thanks, > > > > Steve > > > >> -----Original Message----- > >> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On > >> Behalf Of Dave Nelson > >> Sent: Wednesday, August 12, 2009 9:33 AM > >> To: emu@ietf.org > >> Subject: Re: [Emu] EAP and authorization > >> > >> Stephen Hanna writes... > >> > >> > I suppose that my basic argument is a practical one. Password > >> > change, channel bindings, and NEA assessments are useful things > >> > to do during the EAP exchange. > >> > >> That much I think most of us would agree with. EAP is a > >> convenient protocol > >> to use for exchanging that kind of information, even if it's > >> stretching the > >> original purpose of EAP. Remember, EAP was to be used during the > >> authentication phase of PPP. > >> > >> > They are relevant to the authentication process and the server's > >> > decision about whether to grant network access. > >> > >> I really hate to have to agree with Glen's position on this, > >> but I do. I > >> firmly believe that you, and others, are conflating elements of > >> authorization into the meaning of authentication. > >> Authentication is about > >> proof of identity. I can be authenticated as Dave Nelson, by > >> various means. > >> I'm still Dave Nelson whether I'm a good guy or a bad guy. > >> If I'm a bad > >> guy, you may not want to grant me access to your home. If > >> I'm a good guy, > >> but an active carrier for Swine Flue, you still may not want > >> to grant me > >> access to your home. In any case I'm still Dave Nelson, and > >> none of the > >> other "access control" considerations affect my proof of > >> identity. All > >> those other considerations are authorization considerations, not > >> authentication considerations. > >> > >> I agree that using words clearly and with their exact meaning > >> is important. > >> > >> However, it appears that the real point of this semantic > >> debate is whether > >> the "domain of applicability" for EAP will admit the > >> introduction on very > >> useful, but clearly non-authentication, data elements. It's > >> quite possible > >> for the WG to have consensus to do so and at the same time be > >> in apparent > >> conflict with the "domain of applicability" for EAP. Of > >> course, maybe the > >> WG has within its charter the authority to revise the "domain of > >> applicability" for EAP. > >> > >> > There is no harm in doing them as part of the EAP exchange. > >> And there > >> > is no better way to implement them. > >> > >> Assuming that's true -- and it may well be -- then EMU ought > >> to expand the > >> definition of EAP to explicitly include authorization related > >> data, rather > >> than making semantic, re-definitional, arguments that the > >> authorization data > >> is really authentication data. > >> > >> > >> _______________________________________________ > >> Emu mailing list > >> Emu@ietf.org > >> https://www.ietf.org/mailman/listinfo/emu > >> > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu > > >=20 >=20 > = From aland@deployingradius.com Sun Aug 16 11:01:17 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1F7828C116 for ; Sun, 16 Aug 2009 11:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyXFwoxjkwFW for ; Sun, 16 Aug 2009 11:01:17 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 00A573A6BD3 for ; Sun, 16 Aug 2009 11:01:16 -0700 (PDT) Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 4184212342A5; Sun, 16 Aug 2009 20:01:19 +0200 (CEST) Message-ID: <4A88496E.5020506@deployingradius.com> Date: Sun, 16 Aug 2009 20:01:18 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Dan Harkins References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org><4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net><4A81BA2B.1090400@deployingradius.com><00c201ca1ac1$64b9f800$2e2de800$@net><00e001ca1ad8$97a63230$c6f29690$@net> <64267BE4CECB4CAE83EFB0A6F5039285@NEWTON603> <4A87BEBD.2010407@deployingradius.com> <1f4de74e2f95083ff1814d4a2cd5a8cd.squirrel@www.trepanning.net> In-Reply-To: <1f4de74e2f95083ff1814d4a2cd5a8cd.squirrel@www.trepanning.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "emu@ietf.org" Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 18:01:17 -0000 Dan Harkins wrote: > Authentication has to do with proving an identity. Authorization has > to do with determining whether that proven identity is "good" or "bad". That's a clear explanation. > I'm not sure what sites do what but I'm not aware of an EAP method > that checks a username and a password AND a MAC address. Bare EAP, no. But it's possible to put a MAC into a field of a client cert, and then to compare the MAC received via EAP-TLS against the MAC received in the same RADIUS packet. In this case, the MAC is part of the identity. > Channel bindings are subtly different. Since a 2-party protocol is being > used with 3 parties it is necessary to ensure that all 3 parties have a > consistent view of all 3 identities. But that's still an authentication > problem-- is this 3rd entity really who it says it is? ... and is he authorized to provide the services he's claiming to offer. Are we really authenticating the NAS, and then authorizing it, by passing tunneled data in EAP? Do we really want to go down that path? Alan DeKok. From dharkins@lounge.org Sun Aug 16 12:43:43 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7091D3A6C48 for ; Sun, 16 Aug 2009 12:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.009 X-Spam-Level: X-Spam-Status: No, score=-6.009 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKUlCjIcdtCd for ; Sun, 16 Aug 2009 12:43:42 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 8BACD3A6AA4 for ; Sun, 16 Aug 2009 12:43:42 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 5148210224074; Sun, 16 Aug 2009 12:43:47 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sun, 16 Aug 2009 12:43:47 -0700 (PDT) Message-ID: <561f44e6d5be23d9b92e24c47c241e43.squirrel@www.trepanning.net> In-Reply-To: References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org><4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net><4A81BA2B.1090400@deployingradius.com><00c201ca1ac1$64b9f800$2e2de800$@net><00e001ca1ad8$97a63230$c6f29690$@net> <64267BE4CECB4CAE83EFB0A6F5039285@NEWTON603> Date: Sun, 16 Aug 2009 12:43:47 -0700 (PDT) From: "Dan Harkins" To: "Stephen Hanna" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "emu@ietf.org" Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 19:43:43 -0000 Hi Steve, On Sun, August 16, 2009 9:43 am, Stephen Hanna wrote: > I do not agree that EAP channel bindings are about > authentication. They have two parts: checking whether > the NAS is advertising services that it's not > authorized to advertise and using information from > the NAS (like which SSID the peer is trying to > connect to) to supplement the AAA server's decision > about whether to grant the requested access. > Both of these are authorization decisions and they > are made not based on authenticating the NAS (which > we have had for many years in the form of the secret > shared between the NAS and the AAA server) but on > supplementary information about the SSIDs and other > things being advertised by the NAS and requested by > the EAP peer. The problem with your definition of channel bindings is that it completely ignores the lying NAS problem. An identity is not a service that a NAS can be authorized to provide that is checked after authentication has completed. When there are 3 parties involved in this 2 party protocol it is justified by saying that the EAP server trusts the NAS so there is no security issue when MSK is disclosed to it. But what NAS identity does the EAP server trust? The peer and EAP server derive a shared key and for the key to be disclosed to another entity the peer and EAP server must have a consistent view of the identity of that entity. If they cannot arrive at a consistent view of all identities then the protocol deriving the key fails. That is not an authorization issue, it's an authentication issue. > I agree that NEA assessments are a different topic. > They're not the same as channel bindings. I'd say > that the data conveyed in EAP for channel bindings > and for NEA assessments are both authorization data > in that they are not authentication protocols but > supplementary data that the AAA server will use in > deciding whether access should be granted (and maybe > whether other action should be taken, like getting > the lying NAS repaired or sending remediation > instructions to an unhealthy endpoint). "Repair" the lying NAS after authentication? Whoa! If authentication does not fail because a lying NAS was detected then there is a huge security problem. You seem to be conflating authentication and authorization because a "AAA server" might use information from both steps in deciding whether access is granted or not. An EAP server asks "who are you?" and then proceeds to prove the identity it is told using a method of its choice. If the EAP method derives keys the keys have to be bound to a consistent view of the identities involved in the communication (including the NAS identity). If the EAP server is successful in proving that the peer really is the identity it claimed (and the key is successfully bound to a consistent view of all identities) there can still be other, supplementary, things to consider before deciding to grant access or not-- time-of-day, location, up-to-date anti-virus software, etc. But those other, supplementary, things are not EAP, which is why you're mentioning a "AAA server" and not an "EAP server". We might want to make them part of EAP since EAP is the only protocol allowed prior to the access decision being made and it's attractive to pass arbitrary data encapsulated in EAP. But I think it's wrong to say that NEA assessments can piggy back in because the door is being held open for channel bindings. Dan. From shanna@juniper.net Sun Aug 16 18:22:48 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E44428C0D8 for ; Sun, 16 Aug 2009 18:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+UdLiY8IK6Z for ; Sun, 16 Aug 2009 18:22:47 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id E826B3A69CF for ; Sun, 16 Aug 2009 18:22:45 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSoiw6i9yDXyNQZ6/l1NRCB047h6GbnQw@postini.com; Sun, 16 Aug 2009 18:22:52 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sun, 16 Aug 2009 18:20:00 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Sun, 16 Aug 2009 21:19:59 -0400 From: Stephen Hanna To: Dan Harkins Date: Sun, 16 Aug 2009 21:18:55 -0400 Thread-Topic: [Emu] EAP and authorization Thread-Index: AcoeqeCmi/OAz1PISQKEiCQh4WEDewAITbTQ Message-ID: References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org><4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net><4A81BA2B.1090400@deployingradius.com><00c201ca1ac1$64b9f800$2e2de800$@net><00e001ca1ad8$97a63230$c6f29690$@net> <64267BE4CECB4CAE83EFB0A6F5039285@NEWTON603> <561f44e6d5be23d9b92e24c47c241e43.squirrel@www.trepanning.net> In-Reply-To: <561f44e6d5be23d9b92e24c47c241e43.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "emu@ietf.org" Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 01:22:48 -0000 Dan Harkins wrote: > On Sun, August 16, 2009 9:43 am, Stephen Hanna wrote: > > I do not agree that EAP channel bindings are about > > authentication. They have two parts: checking whether > > the NAS is advertising services that it's not > > authorized to advertise and using information from > > the NAS (like which SSID the peer is trying to > > connect to) to supplement the AAA server's decision > > about whether to grant the requested access. > > Both of these are authorization decisions and they > > are made not based on authenticating the NAS (which > > we have had for many years in the form of the secret > > shared between the NAS and the AAA server) but on > > supplementary information about the SSIDs and other > > things being advertised by the NAS and requested by > > the EAP peer. >=20 > The problem with your definition of channel bindings is that it > completely ignores the lying NAS problem. An identity is not a service > that a NAS can be authorized to provide that is checked after > authentication has completed. After carefully reviewing again the list of attributes verified by draft-ietf-emu-chbind-03.txt, I would agree that several of them are related to the NAS identity: NAS-IP-Address, Called-Station-Id (the MAC part), and NAS-Identifier. Some are related to the identity of the network to which the NAS claims to provide access or to the mobility domain of which it is a part: Called-Station-Id (the SSID part) and Mobility-Domain-Id. For those, I agree that we can call them authentication since the main purpose of channel bindings is to verify that the identity claimed by the NAS to the EAP peer is acceptable (although SSID and Mobility-Domain-Id are not really NAS identity but network identity). If/when the AAA server uses the SSID to decide whether a user is authorized to connect to that SSID, there's definitely authorization taking place but one can argue that the primary reason to convey this attribute in channel bindings is to verify the network identity claimed by the NAS to the EAP peer. So let's overlook this authorization aspect. However, I wonder if you really want to claim that the Cost-Information AVP is part of the NAS identity. That seems to be clearly not. Do you want to claim that this is part of the network identity? That seems to be a stretch. Really, I think that this is an attribute of the network (or one could say an advertisement) that is being verified. > > I agree that NEA assessments are a different topic. > > They're not the same as channel bindings. I'd say > > that the data conveyed in EAP for channel bindings > > and for NEA assessments are both authorization data > > in that they are not authentication protocols but > > supplementary data that the AAA server will use in > > deciding whether access should be granted (and maybe > > whether other action should be taken, like getting > > the lying NAS repaired or sending remediation > > instructions to an unhealthy endpoint). >=20 > "Repair" the lying NAS after authentication? Whoa! If authentication > does not fail because a lying NAS was detected then there is a huge > security problem. I agree that authentication should not succeed if a lying NAS is detected. I didn't say otherwise. I said that you might want to repair a lying NAS. Of course, "repair" would mainly apply if it's your equipment. If it's a rogue NAS, you might want to find it and smash it with a sledgehammer. ;-) > You seem to be conflating authentication and authorization > because a "AAA server" might use information from both steps > in deciding whether access is granted or not. An EAP server > asks "who are you?" and then proceeds to prove the identity > it is told using a method of its choice. If the EAP method > derives keys the keys have to be bound to a consistent > view of the identities involved in the communication=20 > (including the NAS identity). If the EAP server is successful > in proving that the peer really is the identity it claimed > (and the key is successfully bound to a consistent view of > all identities) there can still be other, supplementary, > things to consider before deciding to grant access or not--=20 > time-of-day, location, up-to-date anti-virus software, etc. > But those other, supplementary, things are not EAP, which > is why you're mentioning a "AAA server" and not an "EAP server". >=20 > We might want to make them part of EAP since EAP is the only > protocol allowed prior to the access decision being made and > it's attractive to pass arbitrary data encapsulated in EAP. > But I think it's wrong to say that NEA assessments can piggy > back in because the door is being held open for channel bindings. I am not trying to conflate authentication and authorization. I recognize that these are two different things and I think that it will help us to have a clear definition of each. That should help us decide whether we want to allow some authorization data to travel over EAP. You wrote: > Authentication has to do with proving an identity. Authorization > has to do with determining whether that proven identity is > "good" or "bad". I agree with the gist of your definition of authentication. We might more precisely define authentication as: the process of verifying a claim that an entity has a certain identity However, I think that your definition of authorization is a bit too loose. A perfectly good person should not be authorized to access someone else's records. I suggest that we use this definition of authorization from RFC 4949: 1b. (I) A process for granting approval to a system entity to access a system resource. I agree that EAP was originally defined solely for the purpose of authentication. I agree that it is wise for us to consider carefully whether we want to also allow it to be used to carry information that is useful in authorization. While I believe that this is a good idea, I think that we'll want to continue to place constraints on the amount and kind of data that should be conveyed over EAP. EAP is not a bulk data transfer protocol and it should not be used as one. That will only result in heartache for all involved (due to the limit of one packet in flight at any time, the frequently long round trip times when RADIUS proxies are used, and the short timeouts given by many NASs, among other issues). Thanks, Steve From david@mitton.com Sun Aug 16 21:42:13 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 074863A6B7C for ; Sun, 16 Aug 2009 21:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMLHH-OquQDY for ; Sun, 16 Aug 2009 21:42:12 -0700 (PDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id 09A1D3A6A47 for ; Sun, 16 Aug 2009 21:42:11 -0700 (PDT) Received: from OMTA17.westchester.pa.mail.comcast.net ([76.96.62.89]) by QMTA01.westchester.pa.mail.comcast.net with comcast id VGi61c0031vXlb851GiHsh; Mon, 17 Aug 2009 04:42:17 +0000 Received: from CPQ-SEMPRON.mitton.com ([24.62.189.157]) by OMTA17.westchester.pa.mail.comcast.net with comcast id VGm21c0093QBy5C3dGm44X; Mon, 17 Aug 2009 04:46:04 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 17 Aug 2009 00:42:20 -0400 To: Alan DeKok From: David Mitton In-Reply-To: <4A87C38F.9030505@deployingradius.com> References: <2018380107.9112.1250262806060.JavaMail.mail@webmail04> <4A87C38F.9030505@deployingradius.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20090817044212.09A1D3A6A47@core3.amsl.com> Cc: emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 04:42:13 -0000 On 8/16/2009 04:30 AM, Alan DeKok wrote: >David Mitton wrote: > >> The main limitation on bulk data transfer is that most EAP to > >> RADIUS gateways (AP's, etc.) will terminate an EAP session after ~50 > >> packets. > > > > This kind of thing drives me crazy. Why are their such policies? > > To prevent bulk transfer of data over EAP, among others. This would seem like a highly unlikely scenario, as in most system, someone privileged would have to install this rogue EAP module in the AAA system. > > Please do not build EAP session breaking assumptions into AAA > implementations. > > It would be useful to codify these experiences into an EAP "best >practices" document. I've done it before... (I'll find the proceedings reference) An update is coming.... Dave. > Alan DeKok. From jordan@open1x.org Sun Aug 16 22:03:02 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F3323A6B17 for ; Sun, 16 Aug 2009 22:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pp4bnfQDuACf for ; Sun, 16 Aug 2009 22:03:01 -0700 (PDT) Received: from spaceymail-a7.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 737043A6910 for ; Sun, 16 Aug 2009 22:03:01 -0700 (PDT) Received: from mail-pz0-f178.google.com (mail-pz0-f178.google.com [209.85.222.178]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by spaceymail-a7.g.dreamhost.com (Postfix) with ESMTP id 25A2E142AE for ; Sun, 16 Aug 2009 22:02:22 -0700 (PDT) Received: by pzk8 with SMTP id 8so1967616pzk.31 for ; Sun, 16 Aug 2009 22:02:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.239.17 with SMTP id m17mr576476wfh.2.1250485341091; Sun, 16 Aug 2009 22:02:21 -0700 (PDT) In-Reply-To: References: <4A819BD1.90802@deployingradius.com> <00e001ca1ad8$97a63230$c6f29690$@net> <64267BE4CECB4CAE83EFB0A6F5039285@NEWTON603> <561f44e6d5be23d9b92e24c47c241e43.squirrel@www.trepanning.net> Date: Sun, 16 Aug 2009 23:02:21 -0600 Message-ID: From: Bret Jordan To: Stephen Hanna Content-Type: multipart/alternative; boundary=000e0cd145f28d7b0f04714f4eac Cc: "emu@ietf.org" Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 05:03:02 -0000 --000e0cd145f28d7b0f04714f4eac Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All, > I agree that EAP was originally defined solely for the purpose > of authentication. I agree that it is wise for us to consider > carefully whether we want to also allow it to be used to carry > information that is useful in authorization. While I believe that > this is a good idea, I think that we'll want to continue to place > constraints on the amount and kind of data that should be > conveyed over EAP. EAP is not a bulk data transfer protocol > and it should not be used as one. That will only result in > heartache for all involved (due to the limit of one packet > in flight at any time, the frequently long round trip times > when RADIUS proxies are used, and the short timeouts given > by many NASs, among other issues). > > At some level we need to really consider some level of enhanced authentication meta-data to flow over the EAP session. I would still argue that it is not all really authorization in the traditional sense. There is a big fat gray area these days. Organizations are looking at using these traditioinal chunks of data to make more educated authenitcation decisions. Simply trusting a username/password is not longer sufficient. We want to be able to make sure the person is using the computer that was assigned to them, the computer is still fully compliant with security policy, the user is in the office that was assigned to them, and a slew of other things. If all of these and the stars align just right, then we will authenticate them to the network and then they can be granted network access and normal network authorization processes can take place through processes and protocols that exist or will be created. Bret --------------------------------------------------------------------------------- Bret Jordan CISSP "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." --000e0cd145f28d7b0f04714f4eac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,
=A0
I agree that EAP was originally defined sol= ely for the purpose
of authentication. I agree that it is wise for us to consider
carefully whether we want to also allow it to be used to carry
information that is useful in authorization. While I believe that
this is a good idea, I think that we'll want to continue to place
constraints on the amount and kind of data that should be
conveyed over EAP. EAP is not a bulk data transfer protocol
and it should not be used as one. That will only result in
heartache for all involved (due to the limit of one packet
in flight at any time, the frequently long round trip times
when RADIUS proxies are used, and the short timeouts given
by many NASs, among other issues).


=A0At some level we need to really consider some leve= l of enhanced authentication meta-data to flow over the EAP session. I woul= d still argue that it is not all really authorization in the traditional se= nse.=A0 There is a big fat gray area these days.=A0 Organizations are looki= ng at using these traditioinal chunks of data to make more educated autheni= tcation decisions.=A0 Simply trusting a username/password is not longer suf= ficient.=A0 We want to be able to make sure the person is using the compute= r that was assigned to them, the computer is still fully compliant with sec= urity policy, the user is in the office that was assigned to them, and a sl= ew of other things.=A0 If all of these and the stars align just right, then= we will authenticate them to the network and then they can be granted netw= ork access and normal network authorization processes can take place throug= h processes and protocols that exist or will be created.


Bret

---------------------------------------=
------------------------------------------
Bret Jordan CISSP

&quo=
t;Without cryptography vihv vivc ce xhrnrw, however,
the only thing that=
 can not be unscrambled is an egg."
=A0

--000e0cd145f28d7b0f04714f4eac-- From stefan.winter@restena.lu Sun Aug 16 23:47:56 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69C423A6B3B for ; Sun, 16 Aug 2009 23:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9T3HuWYadKco for ; Sun, 16 Aug 2009 23:47:52 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by core3.amsl.com (Postfix) with ESMTP id BA1C73A6ACD for ; Sun, 16 Aug 2009 23:47:51 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 28E2910A97; Mon, 17 Aug 2009 08:43:46 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 00A6510A96; Mon, 17 Aug 2009 08:43:45 +0200 (CEST) Message-ID: <4A88FD1A.6080809@restena.lu> Date: Mon, 17 Aug 2009 08:47:54 +0200 From: Stefan Winter User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: David Mitton References: <2018380107.9112.1250262806060.JavaMail.mail@webmail04> <4A87C38F.9030505@deployingradius.com> <20090817044212.09A1D3A6A47@core3.amsl.com> In-Reply-To: <20090817044212.09A1D3A6A47@core3.amsl.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV Cc: emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 06:47:56 -0000 Hi, >> >> The main limitation on bulk data transfer is that most EAP to >> >> RADIUS gateways (AP's, etc.) will terminate an EAP session after ~50 >> >> packets. >> > >> > This kind of thing drives me crazy. Why are their such policies? >> >> To prevent bulk transfer of data over EAP, among others. > > This would seem like a highly unlikely scenario, as in most system, > someone privileged would have > to install this rogue EAP module in the AAA system. Which might make sense in a roaming system if you want your users to get around being billed. Provider A and B operate WLAN hotspots, say with realm-based routing. A wants all his users to get access to B's hotspots, but without being billed for it :-) A sets up an EAP server with "EAP-Fraud" method which merely tunnels IP in EAP, installs supplicant with EAP-Fraud support on his clients. A's clients travel to a B-hotspot, and start a LONG authentication session to their A realm which is in fact normal IP communication via an IP proxy on their home EAP server. After an hour or so of merrily speaking IP, client indicates a wish to disconnect to home and the EAP server sends an Access-Reject. No bill, since "the authentication failed". Just took a while. Greetings, Stefan Winter >> > Please do not build EAP session breaking assumptions into AAA >> implementations. >> >> It would be useful to codify these experiences into an EAP "best >> practices" document. > > I've done it before... (I'll find the proceedings reference) > An update is coming.... > > Dave. > > >> Alan DeKok. > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Rseau Tlinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 From Josh.Howlett@ja.net Mon Aug 17 00:33:43 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5BAC3A67DD for ; Mon, 17 Aug 2009 00:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVtNLlsAtiXB for ; Mon, 17 Aug 2009 00:33:42 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id C83593A6B3B for ; Mon, 17 Aug 2009 00:33:42 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 14C9B4A6B3C_A890793B; Mon, 17 Aug 2009 07:32:35 +0000 (GMT) Received: from uxsrvr20.atlas.ukerna.ac.uk (uxsrvr20.ukerna.ac.uk [193.62.83.209]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id F15904A6B7D_A89078EF; Mon, 17 Aug 2009 07:32:30 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Aug 2009 08:34:19 +0100 Message-ID: <6ED388AA006C454BA35B0098396B9BFB05C867AD@uxsrvr20.atlas.ukerna.ac.uk> In-Reply-To: <4A88FD1A.6080809@restena.lu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EAP and authorization Thread-Index: AcofBrOiB1V3m2r2TuScVrepaWNkmQABfuGg References: <2018380107.9112.1250262806060.JavaMail.mail@webmail04> <4A87C38F.9030505@deployingradius.com><20090817044212.09A1D3A6A47@core3.amsl.com> <4A88FD1A.6080809@restena.lu> From: "Josh Howlett" To: "Stefan Winter" , "David Mitton" Cc: Josh Howlett , emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 07:33:43 -0000 > A sets up an EAP server with "EAP-Fraud" method which merely=20 > tunnels IP in EAP, installs supplicant with EAP-Fraud support=20 > on his clients. This approach has some precedent, albeit in a slightly different context. http://thomer.com/howtos/nstx.html josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From sunseawq@huawei.com Mon Aug 17 01:02:25 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1C033A6C2C for ; Mon, 17 Aug 2009 01:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.95 X-Spam-Level: X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[AWL=-0.969, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBC889AE9c54 for ; Mon, 17 Aug 2009 01:02:25 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id BF52D3A691C for ; Mon, 17 Aug 2009 01:02:24 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOI00GK4GVXAB@szxga04-in.huawei.com> for emu@ietf.org; Mon, 17 Aug 2009 15:59:57 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOI00JVIGVXOD@szxga04-in.huawei.com> for emu@ietf.org; Mon, 17 Aug 2009 15:59:57 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOI008BSGVWVV@szxml04-in.huawei.com> for emu@ietf.org; Mon, 17 Aug 2009 15:59:57 +0800 (CST) Date: Mon, 17 Aug 2009 15:59:56 +0800 From: Qin Wu To: Alan DeKok , "Joseph Salowey (jsalowey)" Message-id: <020801ca1f10$b606fed0$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <012d01ca1763$496a12d0$dc3e3870$%yegin@yegin.org> <4A85013B.8060705@deployingradius.com> Cc: emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 08:02:25 -0000 Hi, Alan: ----- Original Message ----- From: "Alan DeKok" To: "Joseph Salowey (jsalowey)" Cc: Sent: Friday, August 14, 2009 2:16 PM Subject: Re: [Emu] EAP and authorization > Joseph Salowey (jsalowey) wrote: >> There are other ways in which EAP has proposed authorization >> enhancements. Other proposals have dealt with requesting authorizations >> for or providing authorization data to services other than the one that >> is performing the authentication. In addition proposals have discussed >> authorization after the initial authentication to the service. > > I think part of the concern here is that authorization has > traditionally involved the PDP telling the PEP how the user should be > treated. The proposals on the table for EAP do not communicate > authorization information over EAP to the PEP. As such, they do not fit > well into the traditional model. > >> I think carrying channel bindings within EAP is useful and necessary. I >> believe it is also reasonable to carry other exchanges to establish data >> for authorization. > > ... of who, to what? This could be made clearer in the document. > >> However, I think there are some limitations. For >> example carrying large amounts of data is probably not a good thing. I >> also think we have to be careful to not leave end stations with the only >> means to communicate is through EAP. I don't think we should be >> applying patches or browsing the web through EAP (I don't think anyone >> is proposing this, but I'm not certain). > > I can propose EAP-IP: carrying IP packets in EAP. It's crazy, but > possible. The main limitation on bulk data transfer is that most EAP to > RADIUS gateways (AP's, etc.) will terminate an EAP session after ~50 > packets. [Qin] Why not carry EAP over Http, in this way, you can browse Web through EAP. Actually there are still other way for Web Authentication, e.g., SIP. >> When we get into the realm of using EAP for establishing authorization >> data for other services, requesting authorization or invoking >> authorization at times other than authentication I think there is a much >> bigger gray area. > > ERP is leveraging EAP to obtain authentication and authorization at > later points in time. This seems to be acceptable. [Qin]: I agree that the authorization is well integrated into ERP authentication. However these authorization data (i.e., authorization indication described in section 5.3.4 of ERP) is only limited to Called-Station-Id ,Calling-Station-Id , NAS-Identifier, NAS-IP-address, NAS-IPv6-address which is listed in RFC3748. What's more, ERP has nothing to do with EAP method. > Alan DeKok. > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From sunseawq@huawei.com Mon Aug 17 01:29:24 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C52D3A67A6 for ; Mon, 17 Aug 2009 01:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.366 X-Spam-Level: * X-Spam-Status: No, score=1.366 tagged_above=-999 required=5 tests=[AWL=-0.739, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8O5dp67PWWW0 for ; Mon, 17 Aug 2009 01:29:23 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 4339D3A6C79 for ; Mon, 17 Aug 2009 01:29:15 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOI009YVI8LDB@szxga04-in.huawei.com> for emu@ietf.org; Mon, 17 Aug 2009 16:29:09 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOI00DD0I8LTS@szxga04-in.huawei.com> for emu@ietf.org; Mon, 17 Aug 2009 16:29:09 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOI00G2GI8KXP@szxml06-in.huawei.com> for emu@ietf.org; Mon, 17 Aug 2009 16:29:08 +0800 (CST) Date: Mon, 17 Aug 2009 16:29:07 +0800 From: Qin Wu To: "Joseph Salowey (jsalowey)" , Alper Yegin , emu@ietf.org Message-id: <022c01ca1f14$ca16a890$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <012d01ca1763$496a12d0$dc3e3870$%yegin@yegin.org> Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 08:29:24 -0000 > There have been a lot of proposals about EAP and authorization in the > past. At its very basis EAP performs authentication at the time of > service access and the data resulting from the authentication can then > be used for authorization and accounting purposes. [Qin]: So the data resulting from the authentication not only can be used in the authentication, but also can be used in authorization. I wonder what it is called as, authentication data or authorization data? On the other hand, the data resulting from authorization also can be used in the second authentication. e.g., PEAP uses TLS to create an encrypted tunnel from the authentication server to the supplicant after verifying the identity of the authentication server. Once the encrypted tunnel is established, a second EAP authorization process occurs inside the tunnel to extend the TLS connection. Any implemented EAP authorization type (tokens, passwords, certificates, etc.) can be used as the client is authenticated in the second EAP authentication process running inside the TLS connection. As regarding these data from authorization, what is it called as, authentication data or authorization data? >Some of the proposals attempt to enhance this in various ways. > One way is to carry additional data for use in the authorization > process. EAP channel bindings are perhaps the simplest form of > authorization data proposed for EAP. The authorization data is directly > related to the service which is performing the authentication, at the > time of authentication and the exchange is relatively simple; data sent > from client and result response from server. This exchange helps to > ensure that an authenticator isn't trying to provide services that it is > not authorized to. I don't see much purpose in channel bindings if > they are not used for authorization or accounting for later forensic > analysis of authorization after the event. > From glenzorn@comcast.net Mon Aug 17 09:19:55 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6A873A69CB for ; Mon, 17 Aug 2009 09:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ta3draemAvLM for ; Mon, 17 Aug 2009 09:19:55 -0700 (PDT) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id 107C93A6F48 for ; Mon, 17 Aug 2009 09:19:43 -0700 (PDT) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id VQq71c0030x6nqcA3UKpjt; Mon, 17 Aug 2009 16:19:49 +0000 Received: from gwzPC ([71.231.55.1]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id VUKn1c00j01ae1j8YUKo84; Mon, 17 Aug 2009 16:19:48 +0000 From: "Glen Zorn" To: "'Dan Harkins'" References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org><4A819BD1.90802@deployingradius.com> <008f01ca1aad$137353b0$3a59fb10$@net><4A81BA2B.1090400@deployingradius.com><00c201ca1ac1$64b9f800$2e2de800$@net><00e001ca1ad8$97a63230$c6f29690$@net> <64267BE4CECB4CAE83EFB0A6F5039285@NEWTON603> <561f44e6d5be23d9b92e24c47c241e43.squirrel@www.trepanning.net> In-Reply-To: <561f44e6d5be23d9b92e24c47c241e43.squirrel@www.trepanning.net> Date: Mon, 17 Aug 2009 09:19:30 -0700 Message-ID: <008101ca1f56$804b0890$80e119b0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoeqeJk+Fe/zYt4Rj2xwgXHyxsCuQAqVgmw Content-Language: en-us Cc: emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 16:19:55 -0000 Dan Harkins [mailto://dharkins@lounge.org] writes: ... > An EAP server asks "who are you?" and then > proceeds to prove the identity it is told using a method of its choice. > If the EAP method derives keys the keys have to be bound to a > consistent > view of the identities involved in the communication (including the NAS > identity). If the EAP server is successful in proving that the peer > really > is the identity it claimed (and the key is successfully bound to a > consistent view of all identities) there can still be other, > supplementary, > things to consider before deciding to grant access or not-- time-of- > day, > location, up-to-date anti-virus software, etc. But those other, > supplementary, things are not EAP, which is why you're mentioning a > "AAA > server" and not an "EAP server". > > We might want to make them part of EAP since EAP is the only protocol > allowed prior to the access decision being made Yes, it is, but it doesn't have to be. In IEEE 802.1X-2004, for example, the transition from the "Authenticating" state to the "Authenticated" state in the PAE machine is triggered by the reception of an Accept message from the Back-end authentication server, not by EAP-Success. In fact, great pains are taken to ensure that the "correct" EAP message (Success or Failure) is sent to the supplicant, the correctness being based not on the actual result of the EAP authentication but on the decision of the AAA server. > and it's attractive to > pass arbitrary data encapsulated in EAP. Actually, the only thing that's attractive about it (IMHO) is the fact that it is there. There are huge disadvantages to using EAP in this way that could be removed were a new protocol be designed for this purpose. ... From jsalowey@cisco.com Mon Aug 17 15:06:19 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 508A33A6AE4 for ; Mon, 17 Aug 2009 15:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owyiZnqjqekb for ; Mon, 17 Aug 2009 15:06:18 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 339143A69F0 for ; Mon, 17 Aug 2009 15:06:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAK9wiUqrR7PD/2dsb2JhbACPc614iC02AwSPBAWCMx6BSIFS X-IronPort-AV: E=Sophos;i="4.43,398,1246838400"; d="scan'208";a="369156177" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 17 Aug 2009 22:06:23 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7HM6N5v020926; Mon, 17 Aug 2009 15:06:23 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7HM6NGD014382; Mon, 17 Aug 2009 22:06:23 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 15:06:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Aug 2009 15:06:22 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] #18 Internationalization Thread-Index: Acocb0c0Eau8d8uKQzu3WQ/4eRlP9QDFh28g References: From: "Joseph Salowey (jsalowey)" To: "Bernard Aboba" , X-OriginalArrivalTime: 17 Aug 2009 22:06:23.0121 (UTC) FILETIME=[F512D010:01CA1F86] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4679; t=1250546783; x=1251410783; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Emu]=20#18=20Internationalization |Sender:=20; bh=Y/l+H1znP86xY6cKIBRnZMbUQFHmyNn9Q6A6k4h1C6o=; b=SZ5uL46SIB6XV6b18nJP8gmuxBcXUOl/Ht3Poh08f1Owc/7n1Oi7rOpdh/ csed8dqSvScvlLp9Si9wOnTLOue2AogPkBbvwiVagdVkr+T4QzM1GsmYJ7tM T5gO8NK5Cf; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Emu] #18 Internationalization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 22:06:19 -0000 The scope of the work is a method for transporting passwords. The requirements include appropriate internationalization support. =20 Section 4.6 covers requirements that existing EAP method not be modified by the tunnel. The sections that talk about internationalization are: 4.3.6 which discusses an optional requirement to have an attribute format for display strings that supports internationalization.=20 4.5.2 which discusses the internationalization requirements for a password exchange. =20 If existing mechanisms do not meet the requirements for internationalization then either they will need to be modified or new ones will need to be developed. =20 I'm not sure where the confusion exists, other than the requirements for internationalization themselves. =20 Joe > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Thursday, August 13, 2009 4:39 PM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] #18 Internationalization >=20 > Within Tunnel methods, exchanges of user names and passwords=20 > are often accomplished either > using TLS or existing EAP methods (e.g. Identity or inner=20 > authentication methods). There are > some tunnel methods that have their own native authentication=20 > methods (e.g. EAP-TTLSv0), but even those typically reuse=20 > functionality defined previously (e.g. Diameter AVPs for PAP,=20 > CHAP, etc.). =20 >=20 > Given that, I'd suggest that the scope of the requirements=20 > needs to be clarified. For example, support for negotiation=20 > of language tags might make sense for tunnel methods that=20 > carry such text in an EAP-method specific way. However, a=20 > method that relies solely on TLS or existing EAP methods=20 > would not benefit from this functionality, and the=20 > requirements document should not imply that it is within=20 > scope for proposals to change TLS, RFC 3748 or existing EAP=20 > methods so as to better support internationalization.=20 >=20 > > Subject: RE: [Emu] #18 Internationalization > > Date: Thu, 13 Aug 2009 12:31:59 -0700 > > From: jsalowey@cisco.com > > To: bernard_aboba@hotmail.com; emu@ietf.org > >=20 > > The core chartered requirements also include the use of the tunnel=20 > > method for password authentication, so it is important to consider=20 > > this case. > >=20 > > In addition, there is a proposal for defining conventions=20 > for defining=20 > > generic textual attributes within the tunnel. I think the main=20 > > advantage of doing this would be to have a consistent approach to=20 > > internationalization. If this is too difficult, perhaps it=20 > should be=20 > > dropped, although I'm not sure these requirements would be too=20 > > different form what is needed for password authentication. > >=20 > > Joe > >=20 > > > -----Original Message----- > > > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org]=20 > On Behalf=20 > > > Of Bernard Aboba > > > Sent: Monday, August 10, 2009 12:09 AM > > > To: emu@ietf.org > > > Subject: Re: [Emu] #18 Internationalization > > >=20 > > > Joe Salowey said: > > >=20 > > > " > > > #18: Internationalization > > >=20 > > > Is the use of UTF-8 sufficient or is other tagging necessary. The=20 > > > following cases need to be considered: > > >=20 > > > 1. Usernames and passwords > > > 2. Prompts and error associated with username and password=20 > > > authentication 3. Other textual data " > > >=20 > > > It's important to keep in mind that this is a tunnel method=20 > > > requirements document. The tunnel method will use TLS, so=20 > as far as=20 > > > bringing up the tunnel is concerned, it is TLS=20 > internationalization=20 > > > that is relevant here. With respect to inner=20 > authentication methods,=20 > > > it is the internationalization support of the inner method that=20 > > > matters. > > >=20 > > > Given this, what exactly is within the purview of the=20 > tunnel method=20 > > > with respect to internationalization? Clearly, the EMU WG is not=20 > > > chartered to change EAP itself, TLS or existing EAP methods. > > >=20 > > > Given that, what *exactly* does this requirement refer to?=20 > > > While it's certainly possible for a tunnel method to do language=20 > > > negotiation, given that such a negotiation wouldn't=20 > affect most of=20 > > > what goes on in the method (e.g. TLS or the inner=20 > method), I don't=20 > > > see what good it would do. > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > >=20 > > >=20 >=20 >=20 From jsalowey@cisco.com Mon Aug 17 16:32:22 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFAC33A6ACF for ; Mon, 17 Aug 2009 16:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJ36PoDz9Kpr for ; Mon, 17 Aug 2009 16:32:22 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 106963A6A2E for ; Mon, 17 Aug 2009 16:32:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAE+FiUqrR7O6/2dsb2JhbAC+Eogtj1UFgjMFgWE X-IronPort-AV: E=Sophos;i="4.43,399,1246838400"; d="scan'208";a="229083538" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 17 Aug 2009 23:32:27 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7HNWR1E001308; Mon, 17 Aug 2009 16:32:27 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7HNWRNd003235; Mon, 17 Aug 2009 23:32:27 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 16:32:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Aug 2009 16:32:26 -0700 Message-ID: In-Reply-To: <4A85013B.8060705@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EAP and authorization Thread-Index: AcocpsRakYuK5pkvTFCsXEY77wnwggC4FcxA References: <012d01ca1763$496a12d0$dc3e3870$@yegin@yegin.org> <4A85013B.8060705@deployingradius.com> From: "Joseph Salowey (jsalowey)" To: "Alan DeKok" X-OriginalArrivalTime: 17 Aug 2009 23:32:27.0001 (UTC) FILETIME=[FAFC5E90:01CA1F92] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3485; t=1250551947; x=1251415947; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Emu]=20EAP=20and=20authorization |Sender:=20; bh=snFiYODoZZ8B9dDZYxMO5qNZ/hELJOSRpLwVBwHJFLI=; b=k0O51++gpz0pxb4VKf1sInpvMQO4pJ5u/SQQktfN/PDjnft2TTCd7oX/cW hz/fJPnww5knielbc6JBqptkr5i0bRDqQIpLBmc2FvP5OsQqHCYOpTUbC9v8 LBp/R8bPFi; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 23:32:23 -0000 =20 > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com]=20 > Sent: Thursday, August 13, 2009 11:16 PM > To: Joseph Salowey (jsalowey) > Cc: Alper Yegin; emu@ietf.org > Subject: Re: [Emu] EAP and authorization >=20 > Joseph Salowey (jsalowey) wrote: > > There are other ways in which EAP has proposed authorization=20 > > enhancements. Other proposals have dealt with requesting=20 > > authorizations for or providing authorization data to=20 > services other=20 > > than the one that is performing the authentication. In addition=20 > > proposals have discussed authorization after the initial=20 > authentication to the service. >=20 > I think part of the concern here is that authorization has=20 > traditionally involved the PDP telling the PEP how the user=20 > should be treated. The proposals on the table for EAP do not=20 > communicate authorization information over EAP to the PEP. =20 > As such, they do not fit well into the traditional model. >=20 [Joe] In the traditional Model, peer entity authentication is performed and the identity information is communicated over EAP to the PDP. The PDP uses this information to make authorization decisions which are communicated to the PEP. I don't think the proposals of this type differ from this model except that the information that is established is not strictly identity information. The information collected may have different security properties than the authenticated data.=20 > > I think carrying channel bindings within EAP is useful and=20 > necessary. =20 > > I believe it is also reasonable to carry other exchanges to=20 > establish=20 > > data for authorization. >=20 > ... of who, to what? This could be made clearer in the document. >=20 [Joe] I don't think a general discussion of authorization belongs in the channel bindings document. Channel bindings is much smaller scope than the general authorization problem. Is there something about channel bindings that is unclear in the document? =20 > > However, I think there are some limitations. For example carrying=20 > > large amounts of data is probably not a good thing. I also=20 > think we=20 > > have to be careful to not leave end stations with the only means to=20 > > communicate is through EAP. I don't think we should be applying=20 > > patches or browsing the web through EAP (I don't think anyone is=20 > > proposing this, but I'm not certain). >=20 > I can propose EAP-IP: carrying IP packets in EAP. It's=20 > crazy, but possible. The main limitation on bulk data=20 > transfer is that most EAP to RADIUS gateways (AP's, etc.)=20 > will terminate an EAP session after ~50 packets. >=20 [Joe] There are a great many things that are possible and even practiced, this does not make them wise. We have several good transport protocols for carrying bulk data. EAP is not one of them. =20 > > When we get into the realm of using EAP for establishing=20 > authorization=20 > > data for other services, requesting authorization or invoking=20 > > authorization at times other than authentication I think there is a=20 > > much bigger gray area. >=20 > ERP is leveraging EAP to obtain authentication and=20 > authorization at later points in time. This seems to be acceptable. >=20 [Joe] Yes, I agree there seems to be some precedence here, but the use cases may vary from the handover case. =20 > Alan DeKok. >=20 From jsalowey@cisco.com Mon Aug 17 16:46:22 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AEB43A6ACF for ; Mon, 17 Aug 2009 16:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKeKOjqDS2pv for ; Mon, 17 Aug 2009 16:46:21 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3FB363A684A for ; Mon, 17 Aug 2009 16:46:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAB+IiUqrR7O6/2dsb2JhbAC+DIgtj1IFgjMFgWE X-IronPort-AV: E=Sophos;i="4.43,399,1246838400"; d="scan'208";a="369218895" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 17 Aug 2009 23:46:25 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7HNkQkg020064; Mon, 17 Aug 2009 16:46:26 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n7HNkQdj021206; Mon, 17 Aug 2009 23:46:26 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 16:46:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Aug 2009 16:46:25 -0700 Message-ID: In-Reply-To: <022c01ca1f14$ca16a890$260ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EAP and authorization Thread-Index: AcofFMy0iQSHEvAYQ5eOEB3MPURBGwAfjW0A References: <012d01ca1763$496a12d0$dc3e3870$%yegin@yegin.org> <022c01ca1f14$ca16a890$260ca40a@china.huawei.com> From: "Joseph Salowey (jsalowey)" To: "Qin Wu" , "Alper Yegin" , X-OriginalArrivalTime: 17 Aug 2009 23:46:25.0938 (UTC) FILETIME=[EF07FF20:01CA1F94] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2945; t=1250552786; x=1251416786; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Emu]=20EAP=20and=20authorization |Sender:=20; bh=jnYJZtrolQ8QGIDC3ZR8uQ8o4oxGM71FxPL4tPDJBkQ=; b=pkAgHPMzuH5+LonU0pUkO6FIT8y2a6JjqdRGIQ44c+/+Cqz7IdbnHKB6bA 0qRcq/IXZtRdq5DfzIjlCNbYKlSaUcLgmBVoHtWEJUGpRacX6uuHF/gH74eE 3XxZu105eK; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 23:46:22 -0000 =20 > -----Original Message----- > From: Qin Wu [mailto:sunseawq@huawei.com]=20 > Sent: Monday, August 17, 2009 1:29 AM > To: Joseph Salowey (jsalowey); Alper Yegin; emu@ietf.org > Subject: Re: [Emu] EAP and authorization >=20 > > There have been a lot of proposals about EAP and=20 > authorization in the=20 > > past. At its very basis EAP performs authentication at the time of=20 > > service access and the data resulting from the=20 > authentication can then=20 > > be used for authorization and accounting purposes. >=20 > [Qin]: So the data resulting from the authentication not only=20 > can be used in the authentication, but also can be used in=20 > authorization. I wonder what it is called as, authentication=20 > data or authorization data? > On the other hand, the data resulting from authorization also=20 > can be used in the second authentication. > e.g., PEAP uses TLS to create an encrypted tunnel from the=20 > authentication server to the supplicant after verifying the=20 > identity of the authentication server. > Once the encrypted tunnel is established, a second EAP=20 > authorization process occurs inside the tunnel to extend the=20 > TLS connection. Any implemented EAP authorization type=20 > (tokens, passwords, certificates, etc.) can be used as the=20 > client is authenticated in the second EAP authentication=20 > process running inside the TLS connection. > As regarding these data from authorization, what is it called=20 > as, authentication data or authorization data? >=20 [Joe] The differences are subtle and I have used the terms somewhat loosely. If you want to get detailed then authentication data is exchanged to validate data as originating from a particular source. Often what is authenticated is a peer's identity, but other attributes may be authenticated as well (attributes in a certificate for example). The authenticity of these attributes may be validated with varying degrees of certainty. The resulting information that is collected becomes the authorization data used to make authorization decisions. =20 > >Some of the proposals attempt to enhance this in various ways. =20 > > One way is to carry additional data for use in the authorization =20 > >process. EAP channel bindings are perhaps the simplest form of =20 > >authorization data proposed for EAP. The authorization data is=20 > >directly related to the service which is performing the=20 > >authentication, at the time of authentication and the exchange is=20 > >relatively simple; data sent from client and result response from=20 > >server. This exchange helps to ensure that an=20 > authenticator isn't trying to provide services that it is > > not authorized to. I don't see much purpose in channel bindings if > > they are not used for authorization or accounting for later=20 > forensic =20 > >analysis of authorization after the event. > >=20 >=20 From bernard_aboba@hotmail.com Mon Aug 17 22:20:19 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C0EB3A68DB for ; Mon, 17 Aug 2009 22:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.43 X-Spam-Level: X-Spam-Status: No, score=0.43 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+ZRa6or+Q2J for ; Mon, 17 Aug 2009 22:20:15 -0700 (PDT) Received: from blu0-omc3-s19.blu0.hotmail.com (blu0-omc3-s19.blu0.hotmail.com [65.55.116.94]) by core3.amsl.com (Postfix) with ESMTP id ACA1F3A68B5 for ; Mon, 17 Aug 2009 22:20:15 -0700 (PDT) Received: from BLU137-DS7 ([65.55.116.72]) by blu0-omc3-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 22:20:20 -0700 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Mon, 17 Aug 2009 22:20:22 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CA1F88.E9999410" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acofwxy8NhfxFWc/Qc2c6MCJcKYJ6wAAGnKw Content-Language: en-us X-OriginalArrivalTime: 18 Aug 2009 05:20:20.0869 (UTC) FILETIME=[94C7DB50:01CA1FC3] Subject: [Emu] Channel Bindings and Authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 05:20:19 -0000 ------=_NextPart_000_0001_01CA1F88.E9999410 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dan Harkins stated: " I don't think what you're talking about falls into the definition of "channel binding", at least not the one I have, and I wouldn't be surprised if others (like maybe people on the IESG) agree. And I agree with Dave, and Glen, that this isn't authentication either." RFC 3748 and RFC 5247 define Channel Bindings as well as describing their use within the EAP architecture. For example, RFC 5247 Section 1.4 defines discusses potential uses of Channel Bindings by EAP methods: " Channel Binding Channel binding is the process by which lower-layer parameters are verified for consistency between the EAP peer and server. In order to avoid introducing media dependencies, EAP methods that transport channel binding parameters MUST treat this data as opaque octets." Given that Channel Bindings are to be treated as opaque octets by the EAP method, and that they are Intended for use in encoding lower layer parameters, it's hard to see how Channel Bindings could be construed as a general authorization mechanism. ------=_NextPart_000_0001_01CA1F88.E9999410 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dan Harkins stated:

 

“  I don't think what you're talking about falls into =
the definition

of "channel binding", at least not the one I have, and I wouldn't = be

surprised if others (like maybe people on the IESG) agree. And = I

agree with Dave, and Glen, that this isn't authentication = either.”

 

RFC 3748 and RFC 5247 define Channel Bindings as = well as describing their use within the

EAP architecture.   For example, RFC 5247 = Section 1.4 defines discusses potential uses of

Channel Bindings by EAP methods:

 

“   Channel Binding

 

      Channel binding is the process by which lower-layer parameters = are

      verified for consistency between the EAP peer and server.  = In

      order to avoid introducing media dependencies, EAP methods = that

      transport channel binding parameters MUST treat this data as opaque = octets.”

 

 

Given that Channel Bindings are to be treated as = opaque octets by the EAP method,  and that they are

Intended for use in encoding lower layer = parameters, it’s hard to see how Channel Bindings could be

construed as a general authorization = mechanism. 

------=_NextPart_000_0001_01CA1F88.E9999410-- From bernard_aboba@hotmail.com Mon Aug 17 22:32:00 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6063A6F4E for ; Mon, 17 Aug 2009 22:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.417 X-Spam-Level: X-Spam-Status: No, score=0.417 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00ZWPSFpIgQD for ; Mon, 17 Aug 2009 22:31:57 -0700 (PDT) Received: from blu0-omc3-s35.blu0.hotmail.com (blu0-omc3-s35.blu0.hotmail.com [65.55.116.110]) by core3.amsl.com (Postfix) with ESMTP id BEA2E3A6B9D for ; Mon, 17 Aug 2009 22:31:56 -0700 (PDT) Received: from BLU137-DS2 ([65.55.116.72]) by blu0-omc3-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 22:31:57 -0700 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Mon, 17 Aug 2009 22:31:59 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01CA1F8A.892A0220" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcofxTVGbICRNLDbS4W/HOg0dG9r0Q== Content-Language: en-us X-OriginalArrivalTime: 18 Aug 2009 05:31:57.0680 (UTC) FILETIME=[341CC700:01CA1FC5] Subject: [Emu] AAA and EAP X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 05:32:00 -0000 ------=_NextPart_000_0006_01CA1F8A.892A0220 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Glen Zorn said: "Yes, it is, but it doesn't have to be. In IEEE 802.1X-2004, for example, the transition from the "Authenticating" state to the "Authenticated" state in the PAE machine is triggered by the reception of an Accept message from the Back-end authentication server, not by EAP-Success. In fact, great pains are taken to ensure that the "correct" EAP message (Success or Failure) is sent to the supplicant, the correctness being based not on the actual result of the EAP authentication but on the decision of the AAA server. " RFC 3579 makes it clear that the Accept/Reject sent by the AAA server controls the behavior of the AAA client, not the encapsulated EAP packet. This clarification was made in response to interoperability issues that arose in situations where Access-Reject/EAP-Success or Access-Accept/EAP-Failure packets were sent. While RFC 3579 does not forbid these packets, it does recommend against their use, since they can result in inconsistent interpretations of the authentication exchange between the EAP peer and authenticator. ------=_NextPart_000_0006_01CA1F8A.892A0220 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Glen Zorn said:

 

“Yes, it is, but it doesn't have to be.  In IEEE =
802.1X-2004, for example,
the transition from the =
"Authenticating" state to the "Authenticated" =
state
in the PAE machine is triggered by the =
reception of an Accept message from
the Back-end =
authentication server, not by EAP-Success.  In fact, =
great
pains are taken to ensure that the =
"correct" EAP message (Success =
or
Failure) is sent to the supplicant, the =
correctness being based not on the
actual result of =
the EAP authentication but on the decision of the =
AAA
server.

”

 

RFC 3579 makes it clear that the Accept/Reject sent by the AAA server =

controls the behavior of the AAA client, not the encapsulated EAP packet. =

This clarification was made in response to interoperability issues = that

arose in situations where Access-Reject/EAP-Success or

Access-Accept/EAP-Failure packets were sent.  While RFC 3579 does not

forbid these packets, it does recommend against their use, = since

they can result in inconsistent interpretations of the = authentication

exchange between the EAP peer and authenticator.  =    

------=_NextPart_000_0006_01CA1F8A.892A0220-- From bernard_aboba@hotmail.com Mon Aug 17 22:42:25 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 696C73A6B9D for ; Mon, 17 Aug 2009 22:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.312 X-Spam-Level: X-Spam-Status: No, score=0.312 tagged_above=-999 required=5 tests=[AWL=0.497, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pmv9QYnyM7UG for ; Mon, 17 Aug 2009 22:42:24 -0700 (PDT) Received: from blu0-omc3-s21.blu0.hotmail.com (blu0-omc3-s21.blu0.hotmail.com [65.55.116.96]) by core3.amsl.com (Postfix) with ESMTP id 74CB83A6914 for ; Mon, 17 Aug 2009 22:42:24 -0700 (PDT) Received: from BLU137-DS2 ([65.55.116.72]) by blu0-omc3-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 22:42:29 -0700 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: References: In-Reply-To: Date: Mon, 17 Aug 2009 22:42:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acocb0c0Eau8d8uKQzu3WQ/4eRlP9QDFh28gAA6iIiA= Content-Language: en-us X-OriginalArrivalTime: 18 Aug 2009 05:42:29.0729 (UTC) FILETIME=[ACD7CD10:01CA1FC6] Subject: [Emu] Impersonation and Lying NAS problem: two distinct issues (with different solutions) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 05:42:25 -0000 Dan Harkins said: "When there are 3 parties involved in this 2 party protocol it is justified by saying that the EAP server trusts the NAS so there is no security issue when MSK is disclosed to it. But what NAS identity does the EAP server trust? The peer and EAP server derive a shared key and for the key to be disclosed to another entity the peer and EAP server must have a consistent view of the identity of that entity. If they cannot arrive at a consistent view of all identities then the protocol deriving the key fails. That is not an authorization issue, it's an authentication issue." RFC 5247 Section 5.3.2 describes problems that can result from a NAS impersonating another NAS. Section 5.3.3 describes the Channel Binding problem, which is logically distinct. As noted in Section 5.3.2, it is not possible for a AAA server more than one hop from the NAS to verify the NAS Identity. This verification must be handled at the first hop proxy. Given this, it will typically be outside the scope of a Channel Binding Implementation to address the impersonation issue. From bernard_aboba@hotmail.com Mon Aug 17 23:02:47 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14F0B3A68AA for ; Mon, 17 Aug 2009 23:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.392 X-Spam-Level: X-Spam-Status: No, score=0.392 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1w7JifCQMwn for ; Mon, 17 Aug 2009 23:02:43 -0700 (PDT) Received: from blu0-omc3-s8.blu0.hotmail.com (blu0-omc3-s8.blu0.hotmail.com [65.55.116.83]) by core3.amsl.com (Postfix) with ESMTP id 0A72E3A697E for ; Mon, 17 Aug 2009 23:02:42 -0700 (PDT) Received: from BLU137-DS1 ([65.55.116.74]) by blu0-omc3-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 23:02:47 -0700 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Mon, 17 Aug 2009 23:02:48 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01CA1F8E.D759BCC0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcofyYNp08YpP87hR7Kc4GiZ7B3UXg== Content-Language: en-us X-OriginalArrivalTime: 18 Aug 2009 06:02:47.0210 (UTC) FILETIME=[8284A8A0:01CA1FC9] Subject: [Emu] Problems with the Channel Bindings document X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 06:02:47 -0000 ------=_NextPart_000_0018_01CA1F8E.D759BCC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Joe Salowey said: "[Joe] I don't think a general discussion of authorization belongs in the channel bindings document. Channel bindings is much smaller scope than the general authorization problem. Is there something about channel bindings that is unclear in the document? " I would agree that a general discussion of authorization does not belong in the Channel Bindings document, and that Channel Bindings has much smaller scope. However, the Channel Bindings document currently does discuss the generic authorization problem - suggesting that Channel Bindings is a solution to that problem in addition to the "Lying NAS" problem. This represents a basic misunderstanding of the nature of Channel Bindings that has lead to some of the confusion on the list. The problem begins in Section 1. Rather than summarizing the nature of Channel Bindings within the Introduction, the document launches into a discussion of the "lying NAS" problem, and then, within the same section, discusses "another current limitation of EAP" which is "minimal ability to perform authorization." The document defines EAP channel bindings as the solution to both of these problems. This is clearly wrong - EAP Channel Bindings as defined in RFC 3748 and 5247 is not a generic authorization mechanism, and the Channel Binding document should not assert that it is. In doing so, the Channel Bindings document is inconsistent with the RFC 3748 and RFC 5247 definitions of Channel Bindings. ------=_NextPart_000_0018_01CA1F8E.D759BCC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Joe Salowey said:

 

“[Joe] I don't think a general discussion of authorization =
belongs in the
channel bindings document.  =
Channel bindings is much smaller scope than
the =
general authorization problem. Is there something about =
channel
bindings that is unclear in the document? =
”
 
 

I would agree that a general discussion of = authorization does not belong in the Channel

Bindings document, and that Channel Bindings has = much smaller scope.   However, the

Channel Bindings document currently does discuss = the generic authorization

problem – suggesting that Channel Bindings is = a solution to that problem in addition

to the “Lying NAS” problem.  =   This represents a basic misunderstanding of the nature of = Channel

Bindings that has lead to some of the confusion on = the list.

 

The problem begins in Section 1.

 

Rather than summarizing the nature of Channel = Bindings within the Introduction, the

document launches into a discussion of the = “lying NAS” problem, and then, within the

same section, discusses “another current = limitation of EAP” which is “minimal ability to

perform authorization.”

 

The document defines EAP channel bindings as the = solution to both of these problems.

 

This is clearly wrong – EAP Channel Bindings = as defined in RFC 3748 and 5247

is not a generic authorization mechanism, and the = Channel Binding document should

not assert that it is.    In doing = so, the Channel Bindings document is inconsistent with

the RFC 3748 and RFC 5247 definitions of Channel = Bindings.

------=_NextPart_000_0018_01CA1F8E.D759BCC0-- From bernard_aboba@hotmail.com Mon Aug 17 23:41:20 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997033A659C for ; Mon, 17 Aug 2009 23:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.382 X-Spam-Level: X-Spam-Status: No, score=0.382 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXl1KxtqczQF for ; Mon, 17 Aug 2009 23:41:16 -0700 (PDT) Received: from blu0-omc3-s30.blu0.hotmail.com (blu0-omc3-s30.blu0.hotmail.com [65.55.116.105]) by core3.amsl.com (Postfix) with ESMTP id 1E3883A6845 for ; Mon, 17 Aug 2009 23:41:16 -0700 (PDT) Received: from BLU137-DS6 ([65.55.116.72]) by blu0-omc3-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 23:41:21 -0700 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Mon, 17 Aug 2009 23:41:23 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01CA1F94.3AE2E690" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acofzq9DCtzoi0mjT8yz6Z7qMRtqTwAAC90A Content-Language: en-us X-OriginalArrivalTime: 18 Aug 2009 06:41:21.0098 (UTC) FILETIME=[E5B3F2A0:01CA1FCE] Subject: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 06:41:20 -0000 ------=_NextPart_000_002F_01CA1F94.3AE2E690 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Steve Hanna said: "However, I agree that it would be better to get IESG clarification that carrying authorization data in EAP is permissible. As Alan suggested, the first step is probably to have a WG consensus check to verify that we have rough consensus that this should be permitted. After that, maybe we would ask the IESG for a clarification of the applicability statement for EAP. I will note that the IESG has already approved a change to the EMU charter to add a work item for channel bindings. So they have already indicated their support for that effort." Do we really need "IESG clarification" or a "consensus check" to verify that IESG approval of a work item for channel bindings should be interpreted as approval to actually work on channel bindings??? Given that Channel Bindings is discussed in both RFC 3748 and 5247, I think we can say definitively that regardless of whether Channel Bindings are actually useful (personally, I have doubts) that they are within the the scope of applicability of RFC 3748. However, since those documents make it clear that Channel Bindings were not intended as a generic authorization exchange (despite the confusion on that point within the Channel Bindings document). Therefore IESG approval of a Channel Bindings work item should not be construed as a license to change the definition of Channel Bindings to satisfy another distinct need. Doing so would require updating of RFC 3748 and 5247, which is not within the EMU WG charter. ------=_NextPart_000_002F_01CA1F94.3AE2E690 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Steve Hanna said:

 

“However, I agree that it would be better to get IESG =
clarification

that carrying authorization data in EAP is permissible. As = Alan

suggested, the first step is probably to have a WG consensus

check to verify that we have rough consensus that this = should

be permitted. After that, maybe we would ask the IESG for = a

clarification of the applicability statement for EAP.

 

I will note that the IESG has already approved a change to = the

EMU charter to add a work item for channel bindings. So = they

have already indicated their support for that = effort.”

 

Do we really need “IESG clarification” = or a “consensus check” to verify that

IESG approval of a work item for channel bindings = should be

interpreted as approval to actually work on channel bindings???

 

Given that Channel Bindings is discussed in both = RFC 3748 and 5247,  I

think we can say definitively that regardless of = whether Channel Bindings

are actually useful (personally, I have doubts) = that they are within the

the scope of applicability of RFC 3748.  =

 

However, since those documents make it clear that = Channel Bindings were

not intended as a generic authorization exchange = (despite the confusion on

that point within the Channel Bindings document).   Therefore IESG approval of

a Channel Bindings work item should not be = construed as a license to change

the definition of Channel Bindings to satisfy = another distinct need.   Doing

so would require updating of RFC 3748 and 5247, = which is not within the EMU

WG charter.

 

 

------=_NextPart_000_002F_01CA1F94.3AE2E690-- From sunseawq@huawei.com Mon Aug 17 23:59:41 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEE5B3A69CB for ; Mon, 17 Aug 2009 23:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[AWL=1.798, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23YQ-krYjOlR for ; Mon, 17 Aug 2009 23:59:41 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id DEA8728C148 for ; Mon, 17 Aug 2009 23:59:13 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOK00A9X8PT7T@szxga03-in.huawei.com> for emu@ietf.org; Tue, 18 Aug 2009 14:58:41 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOK00HIG8PSE6@szxga03-in.huawei.com> for emu@ietf.org; Tue, 18 Aug 2009 14:58:41 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOK006J88PQZ5@szxml04-in.huawei.com> for emu@ietf.org; Tue, 18 Aug 2009 14:58:40 +0800 (CST) Date: Tue, 18 Aug 2009 14:58:37 +0800 From: Qin Wu To: Bernard Aboba , emu@ietf.org Message-id: <012f01ca1fd1$4ff431f0$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [Emu] Impersonation and Lying NAS problem: two distinct issues (with different solutions) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 06:59:42 -0000 It seems to me, the consistency between EAP peer and EAP Server can be caused by the Lying NAS Even this NAS is not malicious authenticator who impersonates another authenticator, this NAS should be a stupid NAS or malfunctional NAS who make a mistake for some reason. Because this NAS distributes inconsistent data to the peer and server respectively. >From this aspect, the lying NAS can be understoond as ill NAS. am I right? On the other hand, as described in the section 5.3.3, " it is possible for a first-hop AAA proxy to detect a AAA client attempting to impersonate another authenticator. " Based on this, impersonation issue seems to overlap with channel binding or lying NAS issue. Regards! -Qin ----- Original Message ----- From: "Bernard Aboba" To: Sent: Tuesday, August 18, 2009 1:42 PM Subject: [Emu] Impersonation and Lying NAS problem: two distinct issues (with different solutions) > Dan Harkins said: > > "When there are 3 parties involved in this 2 party protocol it is > justified by saying that the EAP server trusts the NAS so there is no > security issue when MSK is disclosed to it. But what NAS identity does > the EAP server trust? The peer and EAP server derive a shared key and > for the key to be disclosed to another entity the peer and EAP server > must have a consistent view of the identity of that entity. If they cannot > arrive at a consistent view of all identities then the protocol deriving > the key fails. That is not an authorization issue, it's an authentication > issue." > > RFC 5247 Section 5.3.2 describes problems that can result from a NAS > impersonating another NAS. Section 5.3.3 describes the Channel > Binding problem, which is logically distinct. > > As noted in Section 5.3.2, it is not possible for a AAA server more > than one hop from the NAS to verify the NAS Identity. This verification > must be handled at the first hop proxy. > > Given this, it will typically be outside the scope of a Channel Binding > Implementation to address the impersonation issue. > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From aland@deployingradius.com Tue Aug 18 00:40:12 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F55C3A69FA for ; Tue, 18 Aug 2009 00:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.334 X-Spam-Level: X-Spam-Status: No, score=-2.334 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlZAL+y+d8D0 for ; Tue, 18 Aug 2009 00:40:11 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 5532D3A68AB for ; Tue, 18 Aug 2009 00:40:11 -0700 (PDT) Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 9DA1612342A5; Tue, 18 Aug 2009 09:40:07 +0200 (CEST) Message-ID: <4A8A5AD7.7030302@deployingradius.com> Date: Tue, 18 Aug 2009 09:40:07 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 07:40:12 -0000 Bernard Aboba wrote: > Do we really need “IESG clarification” or a “consensus check” to verify > that IESG approval of a work item for channel bindings should be > interpreted as approval to actually work on channel bindings??? No. > Given that Channel Bindings is discussed in both RFC 3748 and 5247, I > think we can say definitively that regardless of whether Channel Bindings > are actually useful (personally, I have doubts) that they are within the > the scope of applicability of RFC 3748. Yes. > However, since those documents make it clear that Channel Bindings were > not intended as a generic authorization exchange (despite the confusion on > that point within the Channel Bindings document). Therefore IESG > approval of > a Channel Bindings work item should not be construed as a license to change > the definition of Channel Bindings to satisfy another distinct need. Doing > so would require updating of RFC 3748 and 5247, which is not within the EMU > WG charter. The discussion here is (a) if we can get *some* generic authorization passed via methods used for Channel Bindings, and (b) is that a good idea. I think that the answer to (a) is "yes", and (b) is "some say yes, some say no". Alan DeKok. From hannes.tschofenig@nsn.com Tue Aug 18 00:44:40 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F35F53A6DE4 for ; Tue, 18 Aug 2009 00:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.161 X-Spam-Level: X-Spam-Status: No, score=-5.161 tagged_above=-999 required=5 tests=[AWL=1.438, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKVfLV2HHot8 for ; Tue, 18 Aug 2009 00:44:39 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id A98A53A6DDF for ; Tue, 18 Aug 2009 00:44:38 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n7I7K972019051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Aug 2009 09:20:09 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n7I7K8qJ031548; Tue, 18 Aug 2009 09:20:09 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 09:20:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Aug 2009 10:22:44 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45019A21B4@FIESEXC015.nsn-intra.net> In-Reply-To: <012f01ca1fd1$4ff431f0$260ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Impersonation and Lying NAS problem: two distinctissues (with different solutions) Thread-Index: Acof0YKTQF/dm3BGQRafy/aQS7NxtQAAk0GQ References: <012f01ca1fd1$4ff431f0$260ca40a@china.huawei.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Qin Wu" , "Bernard Aboba" , X-OriginalArrivalTime: 18 Aug 2009 07:20:08.0968 (UTC) FILETIME=[5138B880:01CA1FD4] Subject: Re: [Emu] Impersonation and Lying NAS problem: two distinctissues (with different solutions) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 07:44:40 -0000 There are 3 parties in the AAA/EAP exchange. Not every party is authenticated in the exchange (e.g. the NAS/AAA client is not authenticated by the EAP peer) -- there is only key confirmation taking place.=20 The NAS can therefore report different identities to the EAP client and to the AAA server.=20 To deal with this issue the solution of channel binding was proposed. There are, however, other solutions as well (theoretically at least).=20 The impersation aspect that is described in Section 5.3.2 of http://tools.ietf.org/html/rfc5247 is a very different thing, namely the case where one authenticator impersonates another authenticator towards the AAA server.=20 Since the identity reported within the channel binding solution is not related to the identity used for authenticating the AAA client to a AAA server (or to a proxy) the two aspects, as Bernard said, are unrelated.=20 Ciao Hannes >-----Original Message----- >From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On=20 >Behalf Of ext Qin Wu >Sent: 18 August, 2009 09:59 >To: Bernard Aboba; emu@ietf.org >Subject: Re: [Emu] Impersonation and Lying NAS problem: two=20 >distinctissues (with different solutions) > >It seems to me, the consistency between EAP peer and EAP=20 >Server can be caused by the Lying NAS Even this NAS is not=20 >malicious authenticator who impersonates another=20 >authenticator, this NAS should be a stupid NAS or=20 >malfunctional NAS who make a mistake for some reason. Because=20 >this NAS distributes inconsistent data to the peer and server=20 >respectively.=20 > >From this aspect, the lying NAS can be understoond as ill NAS.=20 >am I right? >On the other hand, as described in the section 5.3.3, " >it is possible for a first-hop AAA proxy to detect a AAA=20 >client attempting to impersonate another authenticator. >" >Based on this, impersonation issue seems to overlap with=20 >channel binding or lying NAS issue. > >Regards! > >-Qin >----- Original Message ----- >From: "Bernard Aboba" >To: >Sent: Tuesday, August 18, 2009 1:42 PM >Subject: [Emu] Impersonation and Lying NAS problem: two=20 >distinct issues (with different solutions) > > >> Dan Harkins said: >>=20 >> "When there are 3 parties involved in this 2 party protocol it is >> justified by saying that the EAP server trusts the NAS so there is no >> security issue when MSK is disclosed to it. But what NAS=20 >identity does >> the EAP server trust? The peer and EAP server derive a shared key and >> for the key to be disclosed to another entity the peer and EAP server >> must have a consistent view of the identity of that entity.=20 >If they cannot >> arrive at a consistent view of all identities then the=20 >protocol deriving >> the key fails. That is not an authorization issue, it's an=20 >authentication >> issue." >>=20 >> RFC 5247 Section 5.3.2 describes problems that can result from a NAS=20 >> impersonating another NAS. Section 5.3.3 describes the Channel >> Binding problem, which is logically distinct.=20 >>=20 >> As noted in Section 5.3.2, it is not possible for a AAA server more >> than one hop from the NAS to verify the NAS Identity. This=20 >verification >> must be handled at the first hop proxy.=20 >>=20 >> Given this, it will typically be outside the scope of a=20 >Channel Binding >> Implementation to address the impersonation issue. =20 >>=20 >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www.ietf.org/mailman/listinfo/emu > From bernard_aboba@hotmail.com Tue Aug 18 06:53:41 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F245B3A695F for ; Tue, 18 Aug 2009 06:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[AWL=0.741, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spWeqi6xjXOG for ; Tue, 18 Aug 2009 06:53:40 -0700 (PDT) Received: from blu0-omc2-s8.blu0.hotmail.com (blu0-omc2-s8.blu0.hotmail.com [65.55.111.83]) by core3.amsl.com (Postfix) with ESMTP id 050413A6C06 for ; Tue, 18 Aug 2009 06:53:39 -0700 (PDT) Received: from BLU137-W13 ([65.55.111.73]) by blu0-omc2-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 06:53:45 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_fcc1d0b3-76c2-4a84-818d-7fe24a834eda_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: Alan DeKok Date: Tue, 18 Aug 2009 06:53:45 -0700 Importance: Normal In-Reply-To: <4A8A5AD7.7030302@deployingradius.com> References: <4A8A5AD7.7030302@deployingradius.com> MIME-Version: 1.0 X-OriginalArrivalTime: 18 Aug 2009 13:53:45.0253 (UTC) FILETIME=[4D9FD550:01CA200B] Cc: emu@ietf.org Subject: Re: [Emu] EAP and authorization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 13:53:41 -0000 --_fcc1d0b3-76c2-4a84-818d-7fe24a834eda_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > The discussion here is (a) if we can get *some* generic authorization > passed via methods used for Channel Bindings=2C and (b) is that a good id= ea. >=20 > I think that the answer to (a) is "yes"=2C and (b) is "some say yes=2C > some say no". Existing RFCs are clear that Channel Bindings have a specific purpose and=20 are not a generic authorization mechanism. For example=2C RFC 3748=20 Section 7.15 states: " In order to address this vulnerability=2C EAP methods may support a protected exchange of channel properties such as endpoint identifiers=2C including (but not limited to): Called-Station-Id [RFC2865][RFC3580]=2C Calling-Station-Id [RFC2865][RFC3580]=2C NAS- Identifier [RFC2865]=2C NAS-IP-Address [RFC2865]=2C and NAS-IPv6-Address [RFC3162]. Using such a protected exchange=2C it is possible to match the channel properties provided by the authenticator via out-of-band mechanisms against those exchanged within the EAP method. Where discrepancies are found=2C these SHOULD be logged=3B additional actions MAY also be taken=2C such as denying access. " Given the above (and similar material in RFC 5247)=2C it would seem (surpr= ise!)=20 that channel bindings relate to properties of the channel. Despite the co= nfusion=20 introduced by Section 1 of the Channel Bindings document=2C the parameters= =20 actually discussed in the Channel Bindings document generally appear consis= tent=20 with existing work. =20 I say "generally" because the document does appear to need an update or two= . For example=2C Section 7.3.2 of the Channel Bindings document introduces the Mesh-Key-Distributor-Domain-Id. My understanding is that this parameter has been removed from 11s=2C so this section is now out of d= ate. --_fcc1d0b3-76c2-4a84-818d-7fe24a834eda_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=3B The discussion here is (a) if we can get *some* generic authorizat= ion
>=3B passed via methods used for Channel Bindings=2C and (b) is th= at a good idea.
>=3B
>=3B I think that the answer to (a) is "y= es"=2C and (b) is "some say yes=2C
>=3B some say no".

Existing = RFCs are clear that Channel Bindings have a specific purpose and
are no= t a generic authorization mechanism. =3B For example=2C RFC 3748
Se= ction 7.15 states:

"
   In order to address this vulnerability=
=2C EAP methods may support a
   protected exchange of channel propertie=
s such as endpoint
   identifiers=2C including (but not limited to): Cal=
led-Station-Id
   [RFC2865][RFC3580]=2C Calling-Station-Id [RFC2865][RFC=
3580]=2C NAS-
   Identifier [RFC2865]=2C NAS-IP-Address [RFC2865]=2C and=
 NAS-IPv6-Address
   [RFC3162].

   Using such a protected exchang=
e=2C it is possible to match the channel
   properties provided by the a=
uthenticator via out-of-band mechanisms
   against those exchanged withi=
n the EAP method.  Where discrepancies
   are found=2C these SHOULD be l=
ogged=3B additional actions MAY also be
   taken=2C such as denying acce=
ss.
"

Given the above (and similar material in RFC 5247)=2C=  =3B it would seem (surprise!)
that channel bindings relate to prop= erties of the channel. =3B =3B Despite the confusion
introduced= by Section 1 of the Channel Bindings document=2C the parameters
actual= ly discussed in the Channel Bindings document generally appear consistent <= br>with existing work. =3B

I say "generally" because the docume= nt does appear to need an update or two.
For example=2C =3B Section = 7.3.2 of the Channel Bindings document
introduces the Mesh-Key-Distribut= or-Domain-Id. =3B My understanding is that
this parameter has been r= emoved from 11s=2C so this section is now out of date.

= --_fcc1d0b3-76c2-4a84-818d-7fe24a834eda_-- From bernard_aboba@hotmail.com Tue Aug 18 06:59:25 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62C173A6DFB for ; Tue, 18 Aug 2009 06:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.946 X-Spam-Level: X-Spam-Status: No, score=-0.946 tagged_above=-999 required=5 tests=[AWL=1.652, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsxqTttosZ8J for ; Tue, 18 Aug 2009 06:59:24 -0700 (PDT) Received: from blu0-omc3-s38.blu0.hotmail.com (blu0-omc3-s38.blu0.hotmail.com [65.55.116.113]) by core3.amsl.com (Postfix) with ESMTP id B5C683A6E01 for ; Tue, 18 Aug 2009 06:58:55 -0700 (PDT) Received: from BLU137-W14 ([65.55.116.74]) by blu0-omc3-s38.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 06:59:01 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_8725fdba-6fb9-4a4f-955c-864a91ff290a_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: , , Date: Tue, 18 Aug 2009 06:59:01 -0700 Importance: Normal In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45019A21B4@FIESEXC015.nsn-intra.net> References: <012f01ca1fd1$4ff431f0$260ca40a@china.huawei.com> <3D3C75174CB95F42AD6BCC56E5555B45019A21B4@FIESEXC015.nsn-intra.net> MIME-Version: 1.0 X-OriginalArrivalTime: 18 Aug 2009 13:59:01.0673 (UTC) FILETIME=[0A39B190:01CA200C] Subject: Re: [Emu] Impersonation and Lying NAS problem: two distinctissues (with different solutions) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 13:59:25 -0000 --_8725fdba-6fb9-4a4f-955c-864a91ff290a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Qin said: "Based on this=2C impersonation issue seems to overlap with channel binding= or lying NAS issue." RFC 3748 Section 7.15 describes the distinction between the two problems: " Section 4.3.7 of [RFC3579] describes how an EAP pass-through authenticator acting as a AAA client can be detected if it attempts to impersonate another authenticator (such by sending incorrect NAS- Identifier [RFC2865]=2C NAS-IP-Address [RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the AAA protocol). However=2C it is possible for a pass-through authenticator acting as a AAA client to provide correct information to the AAA server while communicating misleading information to the EAP peer via a lower layer protocol. " --_8725fdba-6fb9-4a4f-955c-864a91ff290a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Qin said:

"Based on this=2C impersonation issue seems to overlap wit= h channel binding or lying NAS issue."

RFC 3748 Section 7.15 describ= es the distinction between the two problems:

"
   Section&nb=
sp=3B4.3.7 of [RFC3579] describes how an EAP pass-through
   authent=
icator acting as a AAA client can be detected if it attempts
   to imper=
sonate another authenticator (such by sending incorrect NAS-
   Identifi=
er [RFC2865]=2C NAS-I=
P-Address [RFC2865] o=
r NAS-IPv6-Address
   [RFC316=
2] attributes via the AAA protocol).  However=2C it is possible
   f=
or a pass-through authenticator acting as a AAA client to provide
   cor=
rect information to the AAA server while communicating misleading
   inf=
ormation to the EAP peer via a lower layer protocol.
"
= --_8725fdba-6fb9-4a4f-955c-864a91ff290a_-- From bernard_aboba@hotmail.com Tue Aug 18 07:10:55 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA7E03A6B08 for ; Tue, 18 Aug 2009 07:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.986 X-Spam-Level: X-Spam-Status: No, score=-0.986 tagged_above=-999 required=5 tests=[AWL=1.612, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRZUN+nlM2T7 for ; Tue, 18 Aug 2009 07:10:54 -0700 (PDT) Received: from blu0-omc4-s13.blu0.hotmail.com (blu0-omc4-s13.blu0.hotmail.com [65.55.111.152]) by core3.amsl.com (Postfix) with ESMTP id 092CE3A6B65 for ; Tue, 18 Aug 2009 07:10:53 -0700 (PDT) Received: from BLU137-W36 ([65.55.111.137]) by blu0-omc4-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 07:10:19 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_2795df89-58aa-4b3d-af36-186df731dd47_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: "Joseph Salowey (jsalowey)" , Date: Tue, 18 Aug 2009 07:10:19 -0700 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 18 Aug 2009 14:10:19.0697 (UTC) FILETIME=[9E5BF210:01CA200D] Subject: Re: [Emu] #18 Internationalization X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 14:10:55 -0000 --_2795df89-58aa-4b3d-af36-186df731dd47_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The problem is that the internationalization language is too general. =20 For example=2C Section 4.3.6 states: " Any strings sent by the server intended for display to the user MUST=20 be sent in UTF-8 format and SHOULD be able to be marked with language=20 information and adapted to the user's language preference. " This language applies to any string sent by the server=2C regardless of whe= ther it was sent as part of TLS=2C or an existing EAP method. Changing this to "String= s sent as part of the tunnel method (e.g. not part of the tunneling protocol or inner= method)" would make more sense.=20 Also=2C we probably should make a distinction between numeric and non-numer= ic=20 strings. Requiring numbers to be internationalized (e.g. use of Arabic ins= tead of ASCII digits) is not probably not what was intended here.=20 Also=2C there are issues in Section 4.5.2: " The password authentication exchange MUST support user names and passwords in international languages. It MUST support encoding of user name and password strings in UTF-8 [RFC3629] format. Any strings sent by the server during the password exchange and intended for display to the user MUST be sent in UTF-8 format and SHOULD be able to be marked with language information and adapted to the user's language preference. " Again=2C this section refers to "any strings sent by the server"=2C regardl= ess of whether those strings are sent within TLS or existing EAP methods. The scope of th= is requirement should be narrowed.=20 > Subject: RE: [Emu] #18 Internationalization > Date: Mon=2C 17 Aug 2009 15:06:22 -0700 > From: jsalowey@cisco.com > To: bernard_aboba@hotmail.com=3B emu@ietf.org >=20 > The scope of the work is a method for transporting passwords. The > requirements include appropriate internationalization support. =20 >=20 > Section 4.6 covers requirements that existing EAP method not be modified > by the tunnel. The sections that talk about internationalization are: >=20 > 4.3.6 which discusses an optional requirement to have an attribute > format for display strings that supports internationalization.=20 >=20 > 4.5.2 which discusses the internationalization requirements for a > password exchange. =20 >=20 > If existing mechanisms do not meet the requirements for > internationalization then either they will need to be modified or new > ones will need to be developed. =20 >=20 > I'm not sure where the confusion exists=2C other than the requirements fo= r > internationalization themselves. =20 >=20 > Joe >=20 > > -----Original Message----- > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > > Sent: Thursday=2C August 13=2C 2009 4:39 PM > > To: Joseph Salowey (jsalowey)=3B emu@ietf.org > > Subject: RE: [Emu] #18 Internationalization > >=20 > > Within Tunnel methods=2C exchanges of user names and passwords=20 > > are often accomplished either > > using TLS or existing EAP methods (e.g. Identity or inner=20 > > authentication methods). There are > > some tunnel methods that have their own native authentication=20 > > methods (e.g. EAP-TTLSv0)=2C but even those typically reuse=20 > > functionality defined previously (e.g. Diameter AVPs for PAP=2C=20 > > CHAP=2C etc.). =20 > >=20 > > Given that=2C I'd suggest that the scope of the requirements=20 > > needs to be clarified. For example=2C support for negotiation=20 > > of language tags might make sense for tunnel methods that=20 > > carry such text in an EAP-method specific way. However=2C a=20 > > method that relies solely on TLS or existing EAP methods=20 > > would not benefit from this functionality=2C and the=20 > > requirements document should not imply that it is within=20 > > scope for proposals to change TLS=2C RFC 3748 or existing EAP=20 > > methods so as to better support internationalization.=20 > >=20 > > > Subject: RE: [Emu] #18 Internationalization > > > Date: Thu=2C 13 Aug 2009 12:31:59 -0700 > > > From: jsalowey@cisco.com > > > To: bernard_aboba@hotmail.com=3B emu@ietf.org > > >=20 > > > The core chartered requirements also include the use of the tunnel=20 > > > method for password authentication=2C so it is important to consider= =20 > > > this case. > > >=20 > > > In addition=2C there is a proposal for defining conventions=20 > > for defining=20 > > > generic textual attributes within the tunnel. I think the main=20 > > > advantage of doing this would be to have a consistent approach to=20 > > > internationalization. If this is too difficult=2C perhaps it=20 > > should be=20 > > > dropped=2C although I'm not sure these requirements would be too=20 > > > different form what is needed for password authentication. > > >=20 > > > Joe > > >=20 > > > > -----Original Message----- > > > > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org]=20 > > On Behalf=20 > > > > Of Bernard Aboba > > > > Sent: Monday=2C August 10=2C 2009 12:09 AM > > > > To: emu@ietf.org > > > > Subject: Re: [Emu] #18 Internationalization > > > >=20 > > > > Joe Salowey said: > > > >=20 > > > > " > > > > #18: Internationalization > > > >=20 > > > > Is the use of UTF-8 sufficient or is other tagging necessary. The=20 > > > > following cases need to be considered: > > > >=20 > > > > 1. Usernames and passwords > > > > 2. Prompts and error associated with username and password=20 > > > > authentication 3. Other textual data " > > > >=20 > > > > It's important to keep in mind that this is a tunnel method=20 > > > > requirements document. The tunnel method will use TLS=2C so=20 > > as far as=20 > > > > bringing up the tunnel is concerned=2C it is TLS=20 > > internationalization=20 > > > > that is relevant here. With respect to inner=20 > > authentication methods=2C=20 > > > > it is the internationalization support of the inner method that=20 > > > > matters. > > > >=20 > > > > Given this=2C what exactly is within the purview of the=20 > > tunnel method=20 > > > > with respect to internationalization? Clearly=2C the EMU WG is not= =20 > > > > chartered to change EAP itself=2C TLS or existing EAP methods. > > > >=20 > > > > Given that=2C what *exactly* does this requirement refer to?=20 > > > > While it's certainly possible for a tunnel method to do language=20 > > > > negotiation=2C given that such a negotiation wouldn't=20 > > affect most of=20 > > > > what goes on in the method (e.g. TLS or the inner=20 > > method)=2C I don't=20 > > > > see what good it would do. > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > > >=20 > > > >=20 > >=20 > >=20 --_2795df89-58aa-4b3d-af36-186df731dd47_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The problem is that the internationalization language is too general. = =3B
For example=2C Section 4.3.6 states:

"  Any strings sen=
t by the server intended for display to the user MUST 
   be sent in UTF=
-8 format and SHOULD be able to be marked with language 
   information =
and adapted to the user's language preference.
"

This langu= age applies to any string sent by the server=2C regardless of whether it wa= s
sent as part of TLS=2C or an existing EAP method. =3B Changing thi= s to "Strings sent as
part of the tunnel method (e.g. not part of the tu= nneling protocol or inner method)"
would make more sense.

Also= =2C we probably should make a distinction between numeric and non-numeric <= br>strings. =3B Requiring numbers to be internationalized (e.g. use of = Arabic instead of
ASCII digits) is not probably not what was intended he= re.

Also=2C there are issues in Section 4.5.2:

"
   The =
password authentication exchange MUST support user names and
   password=
s in international languages.  It MUST support encoding of
   user name =
and password strings in UTF-8 [RFC3629] format.  Any
   strings sent by =
the server during the password exchange and intended
   for display to t=
he user MUST be sent in UTF-8 format and SHOULD be
   able to be marked =
with language information and adapted to the user's
   language preferen=
ce.
"

Again=2C this section refers to "any strings sent by = the server"=2C regardless of whether
those strings are sent within TLS o= r existing EAP methods. =3B The scope of this requirement
should be = narrowed.

>=3B Subject: RE: [Emu] #18 Internationalization
>= =3B Date: Mon=2C 17 Aug 2009 15:06:22 -0700
>=3B From: jsalowey@cisco.= com
>=3B To: bernard_aboba@hotmail.com=3B emu@ietf.org
>=3B
&= gt=3B The scope of the work is a method for transporting passwords. The>=3B requirements include appropriate internationalization support. >=3B
>=3B Section 4.6 covers requirements that existing EAP method= not be modified
>=3B by the tunnel. The sections that talk about int= ernationalization are:
>=3B
>=3B 4.3.6 which discusses an option= al requirement to have an attribute
>=3B format for display strings th= at supports internationalization.
>=3B
>=3B 4.5.2 which discuss= es the internationalization requirements for a
>=3B password exchange.=
>=3B
>=3B If existing mechanisms do not meet the requirements= for
>=3B internationalization then either they will need to be modifi= ed or new
>=3B ones will need to be developed.
>=3B
>=3B = I'm not sure where the confusion exists=2C other than the requirements for<= br>>=3B internationalization themselves.
>=3B
>=3B Joe
&g= t=3B
>=3B >=3B -----Original Message-----
>=3B >=3B From: Be= rnard Aboba [mailto:bernard_aboba@hotmail.com]
>=3B >=3B Sent: Thur= sday=2C August 13=2C 2009 4:39 PM
>=3B >=3B To: Joseph Salowey (jsal= owey)=3B emu@ietf.org
>=3B >=3B Subject: RE: [Emu] #18 International= ization
>=3B >=3B
>=3B >=3B Within Tunnel methods=2C exchang= es of user names and passwords
>=3B >=3B are often accomplished eit= her
>=3B >=3B using TLS or existing EAP methods (e.g. Identity or in= ner
>=3B >=3B authentication methods). There are
>=3B >=3B= some tunnel methods that have their own native authentication
>=3B &= gt=3B methods (e.g. EAP-TTLSv0)=2C but even those typically reuse
>= =3B >=3B functionality defined previously (e.g. Diameter AVPs for PAP=2C =
>=3B >=3B CHAP=2C etc.).
>=3B >=3B
>=3B >=3B Given= that=2C I'd suggest that the scope of the requirements
>=3B >=3B n= eeds to be clarified. For example=2C support for negotiation
>=3B &g= t=3B of language tags might make sense for tunnel methods that
>=3B &= gt=3B carry such text in an EAP-method specific way. However=2C a
>= =3B >=3B method that relies solely on TLS or existing EAP methods
>= =3B >=3B would not benefit from this functionality=2C and the
>=3B = >=3B requirements document should not imply that it is within
>=3B = >=3B scope for proposals to change TLS=2C RFC 3748 or existing EAP
&g= t=3B >=3B methods so as to better support internationalization.
>= =3B >=3B
>=3B >=3B >=3B Subject: RE: [Emu] #18 Internationaliza= tion
>=3B >=3B >=3B Date: Thu=2C 13 Aug 2009 12:31:59 -0700
>= =3B >=3B >=3B From: jsalowey@cisco.com
>=3B >=3B >=3B To: bern= ard_aboba@hotmail.com=3B emu@ietf.org
>=3B >=3B >=3B
>=3B &g= t=3B >=3B The core chartered requirements also include the use of the tun= nel
>=3B >=3B >=3B method for password authentication=2C so it is= important to consider
>=3B >=3B >=3B this case.
>=3B >=3B= >=3B
>=3B >=3B >=3B In addition=2C there is a proposal for def= ining conventions
>=3B >=3B for defining
>=3B >=3B >=3B g= eneric textual attributes within the tunnel. I think the main
>=3B &g= t=3B >=3B advantage of doing this would be to have a consistent approach = to
>=3B >=3B >=3B internationalization. If this is too difficult= =2C perhaps it
>=3B >=3B should be
>=3B >=3B >=3B dropped= =2C although I'm not sure these requirements would be too
>=3B >=3B= >=3B different form what is needed for password authentication.
>= =3B >=3B >=3B
>=3B >=3B >=3B Joe
>=3B >=3B >=3B
= >=3B >=3B >=3B >=3B -----Original Message-----
>=3B >=3B >= =3B >=3B From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org]
>= =3B >=3B On Behalf
>=3B >=3B >=3B >=3B Of Bernard Aboba
&g= t=3B >=3B >=3B >=3B Sent: Monday=2C August 10=2C 2009 12:09 AM
>= =3B >=3B >=3B >=3B To: emu@ietf.org
>=3B >=3B >=3B >=3B Su= bject: Re: [Emu] #18 Internationalization
>=3B >=3B >=3B >=3B >=3B >=3B >=3B >=3B Joe Salowey said:
>=3B >=3B >=3B >= =3B
>=3B >=3B >=3B >=3B "
>=3B >=3B >=3B >=3B #18: I= nternationalization
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B= >=3B Is the use of UTF-8 sufficient or is other tagging necessary. The <= br>>=3B >=3B >=3B >=3B following cases need to be considered:
&g= t=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B 1. Usernames and = passwords
>=3B >=3B >=3B >=3B 2. Prompts and error associated wi= th username and password
>=3B >=3B >=3B >=3B authentication 3. = Other textual data "
>=3B >=3B >=3B >=3B
>=3B >=3B >= =3B >=3B It's important to keep in mind that this is a tunnel method
= >=3B >=3B >=3B >=3B requirements document. The tunnel method will u= se TLS=2C so
>=3B >=3B as far as
>=3B >=3B >=3B >=3B br= inging up the tunnel is concerned=2C it is TLS
>=3B >=3B internatio= nalization
>=3B >=3B >=3B >=3B that is relevant here. With resp= ect to inner
>=3B >=3B authentication methods=2C
>=3B >=3B = >=3B >=3B it is the internationalization support of the inner method th= at
>=3B >=3B >=3B >=3B matters.
>=3B >=3B >=3B >=3B =
>=3B >=3B >=3B >=3B Given this=2C what exactly is within the pu= rview of the
>=3B >=3B tunnel method
>=3B >=3B >=3B >= =3B with respect to internationalization? Clearly=2C the EMU WG is not
= >=3B >=3B >=3B >=3B chartered to change EAP itself=2C TLS or existi= ng EAP methods.
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B >= =3B Given that=2C what *exactly* does this requirement refer to?
>=3B= >=3B >=3B >=3B While it's certainly possible for a tunnel method to = do language
>=3B >=3B >=3B >=3B negotiation=2C given that such = a negotiation wouldn't
>=3B >=3B affect most of
>=3B >=3B &= gt=3B >=3B what goes on in the method (e.g. TLS or the inner
>=3B &= gt=3B method)=2C I don't
>=3B >=3B >=3B >=3B see what good it w= ould do.
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B >=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B
>=3B >= =3B >=3B >=3B
>=3B >=3B <=3Bhttp://im.live.com/Messenger/IM/H= ome/?source=3DEML_WLHM_GreaterGood>=3B
>=3B >=3B >=3B >=3B >=3B >=3B >=3B >=3B
>=3B >=3B
>=3B >=3B
= --_2795df89-58aa-4b3d-af36-186df731dd47_-- From dharkins@lounge.org Fri Aug 28 13:35:21 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EF433A6F7A for ; Fri, 28 Aug 2009 13:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.319 X-Spam-Level: X-Spam-Status: No, score=-5.319 tagged_above=-999 required=5 tests=[AWL=-0.543, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inkki3m1Vxh2 for ; Fri, 28 Aug 2009 13:35:20 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id CB4813A6AF9 for ; Fri, 28 Aug 2009 13:35:20 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 4187E10224074 for ; Fri, 28 Aug 2009 13:35:27 -0700 (PDT) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 28 Aug 2009 13:35:27 -0700 (PDT) Message-ID: <3f215098658d3824ebbeaea33302d721.squirrel@www.trepanning.net> Date: Fri, 28 Aug 2009 13:35:27 -0700 (PDT) From: "Dan Harkins" To: emu@ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [Emu] where to exchange protected TLVs X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 20:35:21 -0000 Hi, During Last Call on draft-harkins-emu-eap-pwd a comment was made that this draft lacked the ability to do a protected exchange of TLVs the way EAP-GPSK does. Which got me to wondering. Is it the intention of the community that each individual EAP method will have to define ciphers to negotiate, how to negotiate a cipher, how to get a key for the cipher, how to use the cipher to protect a new payload that contains arbitrary TLVs? I personally think that's a bad idea. Each EAP method would have to basically duplicate a whole bunch of capabilities. Would it not be better to do this with two new EAP codes to pass TLVs in each direction and the have a single definition of the cipher and a single definition of how to get the key and a single definition of how to use the cipher and key to protect packets with these new EAP codes? That leaves EAP methods to do authentication and generation of the MSK and EMSK, period. The (optional) exchange of packets with these new EAP codes would happen after the EAP method has finished sending requests and responses and before "success" is declared. Disregarding the EMU charter for a minute, would this be a better architectural solution? regards, Dan. From aland@deployingradius.com Sun Aug 30 03:30:45 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC9963A6ACA for ; Sun, 30 Aug 2009 03:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.052 X-Spam-Level: X-Spam-Status: No, score=-1.052 tagged_above=-999 required=5 tests=[AWL=-1.053, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCYAs9yn7x7w for ; Sun, 30 Aug 2009 03:30:45 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 2643B3A68A8 for ; Sun, 30 Aug 2009 03:30:45 -0700 (PDT) Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 52F52123445D; Sun, 30 Aug 2009 12:30:52 +0200 (CEST) Message-ID: <4A9A54DB.9050902@deployingradius.com> Date: Sun, 30 Aug 2009 12:30:51 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dan Harkins References: <3f215098658d3824ebbeaea33302d721.squirrel@www.trepanning.net> In-Reply-To: <3f215098658d3824ebbeaea33302d721.squirrel@www.trepanning.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org Subject: Re: [Emu] where to exchange protected TLVs X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 10:30:46 -0000 Dan Harkins wrote: > Is it the intention of the community that each individual EAP method > will have to define ciphers to negotiate, how to negotiate a cipher, > how to get a key for the cipher, how to use the cipher to protect a new > payload that contains arbitrary TLVs? I personally think that's a bad > idea. Each EAP method would have to basically duplicate a whole bunch > of capabilities. I agree that it's a bad idea. Where additional data needs to be transferred, it would be best to have a way that is EAP method agnostic. > Would it not be better to do this with two new EAP codes to pass TLVs > in each direction and the have a single definition of the cipher and a > single definition of how to get the key and a single definition of how > to use the cipher and key to protect packets with these new EAP codes? > That leaves EAP methods to do authentication and generation of the MSK > and EMSK, period. The (optional) exchange of packets with these new EAP > codes would happen after the EAP method has finished sending requests > and responses and before "success" is declared. There are multiple ways of doing this. That is one approach. > Disregarding the EMU charter for a minute, would this be a better > architectural solution? Yes. Alan DeKok.