From pana-request@research.telcordia.com Wed Jan 8 09:51:06 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21460 for ; Wed, 8 Jan 2003 09:51:05 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h08EneBV017599; Wed, 8 Jan 2003 09:49:40 -0500 (EST) Resent-Date: Wed, 8 Jan 2003 09:49:40 -0500 (EST) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="euc-jp" Subject: RE: About the NAP/ISP distinction in the usage-scenarios draft... Date: Wed, 8 Jan 2003 16:45:20 +0200 Message-ID: Thread-Topic: About the NAP/ISP distinction in the usage-scenarios draft... Thread-Index: AcKneyGJVC2Bw+nRQgKmjz30gmFd5ALoebZA From: To: , Cc: , , X-OriginalArrivalTime: 08 Jan 2003 14:45:21.0693 (UTC) FILETIME=[920E94D0:01C2B724] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id JAA21460 Hi all and Happy New Year! The multi-method authentication happens in serial and in the same "session", thus it doesn't fit for all cases. As PANA is carried over IP, I never really understood the requirement for the PAA to be in the same link than PaC. For discovery purposes this is not necessary, especially in cases where PAA initiates the authentication/authorization. Usage scenario below. When PaC utilizes multiple ISPs, the auth. happens when PaC starts to access the ISP's network. . . . . . . . . . . . . . . . . . PaC . . . AR--PAA | AR--PAA | AR--PAA | | | | | | | AAA | AAA | AAA | (NAP) | (ISP) | (ISP) | - Dan > -----Original Message----- > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: 19 December, 2002 18:19 > To: Alper E. YEGIN > Cc: MORAND Lionel FTRD/DAC/ISS; Yoshihiro Ohba; Patil > Basavaraj (NET/Dallas); pana@research.telcordia.com > Subject: Re: About the NAP/ISP distinction in the > usage-scenarios draft... > > > I have one additional issue in mind that would affect the requirements > for EAP authentication policy. > > Assume that multi-method EAP authentication is used for providing > multi-level authentication (i.e., NAP authentication and ISP > authentication). If the EAP method performed for ISP authentication > fails, but the other EAP method performed for NAP authentication > succeeds, should the entire EAP conversation fail? I think EAP should > be flexible enough to allow the policy in which EAP-Success message is > returned even when some of the methods fails. > > Yoshihiro Ohba > > > On Fri, Dec 13, 2002 at 03:19:28PM -0800, Alper E. YEGIN wrote: > > > > Lionel, > > > > I think it'd be useful to understand the semantics of each > authentication, > > and the expected actions taken by the client and the > network after each one > > is > > completed. > > > > For example: > > 1- what does it mean to the NAP when a client gets > authenticated? What > > actions > > should be taken (e.g., how are the filters updated, where > are they updated, > > etc.)? > > > > 2- What can or cannot the client do after this first round of > > authentication? > > > > 3- same question as 1, but for ISP authentication. > > > > 4- same question as 2, but for ISP authentication. > > > > > > alper > > > > > > > > > Hi Alper, > > > > > > I think that, in the described scenario, the principle of > two successive > > authentications (one per AAA backend) may appear obvious. However, > > considering a single PAA handling the both authentication > procedures, there > > is an issue concerning the use of the DI. > > > > > > The most intuitive idea is to reuse the same DI for both > authentications > > and to use different sets of credentials > (identifier,authenticator) supplied > > by the client. But according to the current draft on the > PANA requirements > > and as Yoshihiro said, it seems that it should not be possible. > > > > > > On the other hand, the alternative would be to use > different DIs but the > > PAA would create distinct bindings, and so distinct > instances in this case, > > that would make the network access control more complex. > > > > > > A simple solution here could be to allow in the PANA > requirements the > > association of one single DI with different PaCs, but this > may raise up some > > other previous/new concerns. > > > > > > What do you think about this? > > > > > > Best Regards, > > > > > > Lionel > > > > > > > > > >-----Message d'origine----- > > > >De : Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > > > >Envoy”© : jeudi 12 d”©cembre 2002 00:16 > > > >”© : MORAND Lionel FTRD/DAC/ISS; > pana@research.telcordia.com; Yoshihiro > > > >Ohba; basavaraj.Patil@nokia.com > > > >Objet : Re: About the NAP/ISP distinction in the usage-scenarios > > > >draft... > > > > > > > > > > > > > > > >Hello Lionel, > > > > > > > >Thanks for bringing this scenario up. > > > > > > > >In the case both NAP and ISP requires their own independent > > > >client authentication, I presume we can still envision both > > > >using the same PAA on the BAS (broadband access server). > Does this > > > >makes sense? > > > > > > > >For NAP authentication, PAA consults with AAA backend in NAP > > > >network. For ISP authentication, PAA consults with AAA backend > > > >in ISP network. > > > > > > > >Somehow the client needs to know (or discover??) that it has > > > >to go through the authentication twice. Discovery might be tricky > > > >because something has to tell the client that the second one > > > >is meant for the ISP, etc.... If the client knows it has > to do both, > > > >it can differentiate the authentication process by using > different > > > >client identifiers in each. Therefore PAA can demultiplex the > > > >authentication request to the right backend. > > > > > > > >So, running PANA twice between the PaC and the same PAA maybe one > > > >approach. Each time PaC can use a different set of > credentials. If the > > > >same credentials are used, then we need something else > in the process > > > >to indicate which one is for NAP authentication vs for ISP > > > >authentication. > > > > > > > >When two different set of credentials are used, if PaC > uses the same > > > >DI, this might be an issue. Normally they would appear > as two separate > > > >clients to the PAA, but since the network is aware of this > > > >dual-authentication > > > >scheme, and the requests are coming from the same > circuit, maybe this > > > >can be handled. And than, how will these DIs be used with service > > > >provisioning, after each authentication? Is EP still co-located > > > >with BAS here? How should the NAP authentication update > EP, and ISP > > > >authentication update EP? These are general questions > about the model > > > >you are describing.. > > > > > > > > > > > >alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >----- Original Message ----- > > > >From: MORAND Lionel FTRD/DAC/ISS > > > >To: pana@research.telcordia.com ; Yoshihiro Ohba ; > > > >basavaraj.Patil@nokia.com > > > >; Alper E. YEGIN > > > >Sent: Monday, December 09, 2002 5:59 AM > > > >Subject: About the NAP/ISP distinction in the > usage-scenarios draft... > > > > > > > > > > > >Hi folks, > > > > > > > >In the current version of the Usage-Scenario draft, in > the section 3: > > > >Problem Statement, the distinction between NAP (Network Acces > > > >Provider) and > > > >ISP (Internet Service Provider) is pointing out. > > > > > > > >[...An important aspect of an authentication protocol is > the ability to > > > >provide dynamic service provider selection to the clients. > > > >Regardless of > > > >their network access provider (NAP), clients should be able to > > > >select an > > > >Internet access provider (ISP) of their choice. This is > > > >usually achieved by > > > >clients presenting an identifier which carries domain > > > >information during the > > > >authentication process. ] > > > > > > > >This distinction is particularly true in the case of DSL > > > >networks where NAP > > > >and ISP are often two different players. Besides traditional > > > >"package" offer > > > >(access + Internet provided by the ISP), NAP are able to > > > >provide broadband > > > >access services directly to the user, regardless of the ISP > > > >selected by the > > > >user. Moreover, different access network configurations may be > > > >provide to an > > > >xDSL client, based on the access service subscribed to the > > > >NAP. We could > > > >also imagine the provision of some local services in the > > > >short/medium term. > > > > > > > >In order to provide such a "customized" service, the NAP needs to > > > >identify/authenticate the user that logs on to the > access network. This > > > >authentication is independent from the authentication achieved > > > >by the ISP > > > >and so not necessarily based on the same user credentials. > > > >This induces a > > > >requirement for two levels of authentication: one at the NAP > > > >level, one at > > > >the ISP level. I think that this requirement is not only > > > >restricted to xDSL > > > >network and be generalized on the contrary. > > > > > > > >For the time being, if PPP is used to carry user > information for ISP > > > >authentication, NAP identification is mainly based on > > > >information on the > > > >physical link used for the connection (phone line number, ATM > > > >link, etc.) > > > >and not according to the user using the connection. So it is > > > >not possible to > > > >distinguish two consecutive users using the same link > and the network > > > >configuration is only based on the service subscribed for the > > > >access link. > > > > > > > >and now I wonder: > > > >How the PANA protocol could fulfil such a requirement on two > > > >authentication > > > >levels (NAP, ISP)? > > > >What would be the consequences on the general PANA requirements? > > > >Would it be useful to include/precise this scenario be > in the current > > > >usage-scenarios draft? > > > >Any comment/reaction from the mailing list? > > > > > > > >Lionel. > > > > > > > > > > > > > > > > > From pana-request@research.telcordia.com Thu Jan 9 13:01:52 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19295 for ; Thu, 9 Jan 2003 13:01:46 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h09Hu9P1019952; Thu, 9 Jan 2003 12:56:09 -0500 (EST) Resent-Date: Thu, 9 Jan 2003 12:56:09 -0500 (EST) Old-Return-Path: Date: Thu, 9 Jan 2003 12:55:51 -0500 To: Dan.Forsberg@nokia.com Cc: yohba@tari.toshiba.com, alper@docomolabs-usa.com, lionel.morand@rd.francetelecom.com, Basavaraj.Patil@nokia.com, pana@research.telcordia.com Subject: Re: About the NAP/ISP distinction in the usage-scenarios draft... Message-ID: <20030109175551.GA1305@catfish> Mail-Followup-To: Dan.Forsberg@nokia.com, yohba@tari.toshiba.com, alper@docomolabs-usa.com, lionel.morand@rd.francetelecom.com, Basavaraj.Patil@nokia.com, pana@research.telcordia.com References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20021213(IM143) Lines: 1209 X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline On Wed, Jan 08, 2003 at 04:45:20PM +0200, Dan.Forsberg@nokia.com wrote: > Hi all and Happy New Year! > > The multi-method authentication happens in serial and in the same "session", thus it doesn't fit for all cases. > > As PANA is carried over IP, I never really understood the requirement for the PAA to be in the same link than PaC. For discovery purposes this is not necessary, especially in cases where PAA initiates the authentication/authorization. Usage scenario below. > > When PaC utilizes multiple ISPs, the auth. happens when PaC starts to access the ISP's network. The usage scenario team actually considered that scenario before submitting the current version. But we concluded we should not describe it due to the difficulty of supporting multihomed single-interface hosts. I attach related email discussion in IPv6 WG (sorry for long attachment). > > . . . . . . . . . . . . . . > . . . > PaC . . . AR--PAA | AR--PAA | AR--PAA | > | | | | | | > AAA | AAA | AAA | > (NAP) | (ISP) | (ISP) | > > - Dan > > Yoshihiro Ohba --EeQfGwPcQSOJBaQU Content-Type: message/rfc822 Content-Disposition: inline Date: Wed, 9 Oct 2002 15:28:41 -0400 To: ipng@sunroof.eng.sun.com, multi6@ops.ietf.org Subject: multihomed host Message-ID: <20021009192841.GI2310@catfish> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline User-Agent: Mutt/1.4i Hi, I have one question about multihomed host. In the multi6 WG charter, there is the following definition for multihomed "site": A multihomed site is a site that has more than one connection to the public internet with those connections through either the same or different ISPs. Sites choose to multihome for several reasons, especially to improve fault tolerence, perform load balancing, etc. Is there any definition for multihomed "host"? Of cource, a definition would be quickly made by just replacing a word "site" in the above definition with "host", but please let me know if there is other definition. Regards, Yoshihiro Ohba --EeQfGwPcQSOJBaQU Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id PAA02178 for ; Wed, 9 Oct 2002 15:38:14 -0400 (EDT) Received: from smtp.tari.toshiba.com ([208.192.119.195]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g99Jb6sn016512 for ; Wed, 9 Oct 2002 15:37:07 -0400 (EDT) Received: from tai.toshiba.com by smtp.tari.toshiba.com (8.9.1/3.7W-020529) with ESMTP id OAA09992 for ; Wed, 9 Oct 2002 14:36:33 -0400 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by tai.toshiba.com (8.7.3/8.7.5) with ESMTP id PAA03757 for ; Wed, 9 Oct 2002 15:30:34 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08531; Wed, 9 Oct 2002 12:31:01 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g99JUTN0011816; Wed, 9 Oct 2002 12:30:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99JSu29012521; Wed, 9 Oct 2002 12:28:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g99JSune012520; Wed, 9 Oct 2002 12:28:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99JSr29012513 for ; Wed, 9 Oct 2002 12:28:53 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g99JSwMq011379 for ; Wed, 9 Oct 2002 12:28:59 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28627 for ; Wed, 9 Oct 2002 12:28:53 -0700 (PDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g99JShsn015656; Wed, 9 Oct 2002 15:28:45 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id PAA02144; Wed, 9 Oct 2002 15:29:14 -0400 (EDT) Date: Wed, 9 Oct 2002 15:28:41 -0400 To: ipng@sunroof.eng.sun.com, multi6@ops.ietf.org Subject: multihomed host Message-ID: <20021009192841.GI2310@catfish> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Content-Type: text/plain; charset=iso-2022-jp X-UIDL: 58e4b18f8f2923ea4ce8895db61bc631 Hi, I have one question about multihomed host. In the multi6 WG charter, there is the following definition for multihomed "site": A multihomed site is a site that has more than one connection to the public internet with those connections through either the same or different ISPs. Sites choose to multihome for several reasons, especially to improve fault tolerence, perform load balancing, etc. Is there any definition for multihomed "host"? Of cource, a definition would be quickly made by just replacing a word "site" in the above definition with "host", but please let me know if there is other definition. Regards, Yoshihiro Ohba -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- --EeQfGwPcQSOJBaQU Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id PAA02231 for ; Wed, 9 Oct 2002 15:51:33 -0400 (EDT) Received: from smtp.tari.toshiba.com ([208.192.119.195]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g99JoQsn018171 for ; Wed, 9 Oct 2002 15:50:27 -0400 (EDT) Received: from tai.toshiba.com by smtp.tari.toshiba.com (8.9.1/3.7W-020529) with ESMTP id OAA10041 for ; Wed, 9 Oct 2002 14:46:40 -0400 Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by tai.toshiba.com (8.7.3/8.7.5) with ESMTP id PAA03859 for ; Wed, 9 Oct 2002 15:40:41 -0400 (EDT) Received: from kenawang.windriver.com ([147.11.233.40]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA00648; Wed, 9 Oct 2002 12:42:36 -0700 (PDT) Message-Id: <5.1.0.14.2.20021009154140.04f9dec0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 09 Oct 2002 15:42:47 -0400 To: Yoshihiro Ohba From: Margaret Wasserman Subject: Re: multihomed host Cc: ipng@sunroof.eng.sun.com, multi6@ops.ietf.org In-Reply-To: <20021009192841.GI2310@catfish> Mime-Version: 1.0 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: e3287a8cf2ddf272d76d6492782e451c > > >Is there any definition for multihomed "host"? I don't know if there is an official definition, but I have usually heard the term "multihomed host" used to refer to multi-interface systems that do not function as routers (i.e. they don't forward packets). Margaret --EeQfGwPcQSOJBaQU Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id QAA02334 for ; Wed, 9 Oct 2002 16:17:28 -0400 (EDT) Received: from smtp.tari.toshiba.com ([208.192.119.195]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g99KGIsn020142 for ; Wed, 9 Oct 2002 16:16:19 -0400 (EDT) Received: from tai.toshiba.com by smtp.tari.toshiba.com (8.9.1/3.7W-020529) with ESMTP id PAA10235 for ; Wed, 9 Oct 2002 15:15:45 -0400 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by tai.toshiba.com (8.7.3/8.7.5) with ESMTP id QAA03999 for ; Wed, 9 Oct 2002 16:09:44 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA17141; Wed, 9 Oct 2002 14:11:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g99KB0N0021894; Wed, 9 Oct 2002 13:11:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99KA729012813; Wed, 9 Oct 2002 13:10:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g99KA7kL012812; Wed, 9 Oct 2002 13:10:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99KA329012805 for ; Wed, 9 Oct 2002 13:10:04 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g99KA9Mq021718 for ; Wed, 9 Oct 2002 13:10:09 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16377 for ; Wed, 9 Oct 2002 14:10:03 -0600 (MDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g99K9Ssn019746; Wed, 9 Oct 2002 16:09:28 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id QAA02292; Wed, 9 Oct 2002 16:09:58 -0400 (EDT) Date: Wed, 9 Oct 2002 16:09:20 -0400 To: Margaret Wasserman Cc: Yoshihiro Ohba , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org Subject: Re: multihomed host Message-ID: <20021009200920.GK2310@catfish> References: <20021009192841.GI2310@catfish> <5.1.0.14.2.20021009154140.04f9dec0@mail.windriver.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20021009154140.04f9dec0@mail.windriver.com> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Content-Type: text/plain; charset=iso-2022-jp X-UIDL: 0d1aea9095cfc9461219de638a631d4d Thanks for your quick response. There may be some scenario in which a single-interface host is connected to multiple ISPs on the same link, which seems to be not covered in the usual definition for "multihomed host". I don't know what to call the model, but is such a model already common? Or is there any ongoing work on this model? On Wed, Oct 09, 2002 at 03:42:47PM -0400, Margaret Wasserman wrote: > > > > > > >Is there any definition for multihomed "host"? > > I don't know if there is an official definition, but I > have usually heard the term "multihomed host" used to > refer to multi-interface systems that do not function > as routers (i.e. they don't forward packets). > > Margaret > Thanks, Yoshihiro Ohba -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- --EeQfGwPcQSOJBaQU Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id QAA02389 for ; Wed, 9 Oct 2002 16:39:31 -0400 (EDT) Received: from smtp.tari.toshiba.com ([208.192.119.195]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g99KcGsn021778 for ; Wed, 9 Oct 2002 16:38:17 -0400 (EDT) Received: from tai.toshiba.com by smtp.tari.toshiba.com (8.9.1/3.7W-020529) with ESMTP id PAA10306 for ; Wed, 9 Oct 2002 15:34:18 -0400 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by tai.toshiba.com (8.7.3/8.7.5) with ESMTP id QAA04102 for ; Wed, 9 Oct 2002 16:28:18 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00294; Wed, 9 Oct 2002 14:31:29 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA24133; Wed, 9 Oct 2002 16:31:29 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g99KVSgu023997; Wed, 9 Oct 2002 16:31:28 -0400 (EDT) Message-Id: <200210092031.g99KVSgu023997@thunk.east.sun.com> From: Bill Sommerfeld To: Margaret Wasserman cc: Yoshihiro Ohba , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org Subject: Re: multihomed host In-Reply-To: Your message of "Wed, 09 Oct 2002 15:42:47 EDT." <5.1.0.14.2.20021009154140.04f9dec0@mail.windriver.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 09 Oct 2002 16:31:28 -0400 Sender: sommerfeld@thunk.east.sun.com X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Content-Type: text X-UIDL: d8772a06fa1159bd26c871bffbc8d3c7 MIME-Version: 1.0 > I don't know if there is an official definition, but I > have usually heard the term "multihomed host" used to > refer to multi-interface systems that do not function > as routers (i.e. they don't forward packets). For what it's worth, I've occasionally heard the term used in an application-layer context to refer to hosts having multiple IP addresses rather than/in addition to multiple interfaces. - Bill --EeQfGwPcQSOJBaQU Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id OAA04971 for ; Thu, 10 Oct 2002 14:50:06 -0400 (EDT) Received: from smtp.tari.toshiba.com ([208.192.119.195]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g9AImxsn013413 for ; Thu, 10 Oct 2002 14:49:00 -0400 (EDT) Received: from tai.toshiba.com by smtp.tari.toshiba.com (8.9.1/3.7W-020529) with ESMTP id NAA14110 for ; Thu, 10 Oct 2002 13:48:27 -0400 Received: from STYX.ORG (STYX.ORG [205.189.139.145]) by tai.toshiba.com (8.7.3/8.7.5) with ESMTP id OAA01638 for ; Thu, 10 Oct 2002 14:42:25 -0400 (EDT) Received: by STYX.ORG (Postfix, from userid 1001) id F38984CF3; Thu, 10 Oct 2002 14:44:54 -0400 (EDT) Sender: bitbucket@styx.org To: Bill Sommerfeld Cc: Margaret Wasserman , Yoshihiro Ohba , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org Subject: Re: multihomed host References: <200210092031.g99KVSgu023997@thunk.east.sun.com> Organization: Idiosyntactix Research Laboratories From: William Waites Date: 10 Oct 2002 14:44:54 -0400 In-Reply-To: <200210092031.g99KVSgu023997@thunk.east.sun.com> Message-ID: <86smzecevt.fsf@styx.org> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Content-Type: text/plain; charset=us-ascii X-UIDL: 4617170ae0ffcb605665a837a07ae5f3 >>> "Bill" == Bill Sommerfeld writes: Bill> For what it's worth, I've occasionally heard the term used Bill> in an application-layer context to refer to hosts having Bill> multiple IP addresses rather than/in addition to multiple Bill> interfaces. This just looks like the degenerate case -- multiple addresses, multiple interfaces, except that each of the multiple interfaces happen to be the same. It seems to me that the network layer code should treat both cases identically. Does this make sense? -w -- William Waites Idiosyntactix Research Laboratories Any sufficiently advanced technology http://www.irl.styx.org is indistinguishable from a rigged demo. --EeQfGwPcQSOJBaQU Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id NAA07251 for ; Fri, 11 Oct 2002 13:08:31 -0400 (EDT) Received: from smtp.tari.toshiba.com ([208.192.119.195]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g9BH7JSL001952 for ; Fri, 11 Oct 2002 13:07:20 -0400 (EDT) Received: from tai.toshiba.com by smtp.tari.toshiba.com (8.9.1/3.7W-020529) with ESMTP id MAA17542 for ; Fri, 11 Oct 2002 12:06:48 -0400 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by tai.toshiba.com (8.7.3/8.7.5) with ESMTP id NAA11921 for ; Fri, 11 Oct 2002 13:00:43 -0400 (EDT) Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20803; Fri, 11 Oct 2002 08:11:14 -0700 (PDT) Received: from localhost (lillen.France.Sun.COM [129.157.212.23]) by jurassic.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with SMTP id g9BFBBQl732575; Fri, 11 Oct 2002 08:11:12 -0700 (PDT) Date: Fri, 11 Oct 2002 15:15:30 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: multihomed host To: William Waites Cc: Bill Sommerfeld , Margaret Wasserman , Yoshihiro Ohba , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org In-Reply-To: "Your message with ID" <86smzecevt.fsf@styx.org> Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-UIDL: 1d094a26907d56cdd5b3b4175aa7d5df > This just looks like the degenerate case -- multiple addresses, > multiple interfaces, except that each of the multiple interfaces > happen to be the same. It seems to me that the network layer code > should treat both cases identically. Does this make sense? There are some important differences when it comes to the relationship between IP source address and routes that are used. draft-ietf-ipv6-default-addr-select-09.txt specifies that the candidate source address are related to the interface on which a packet is sent. Hence there is a difference between case 1: Host with one interface, two routers, two global addresses with different prefixes (whether one router advertises each addrconf prefix or both routers advertise both prefixes). In this case the candidate source address will be both global addresses, and the other rules in the source address selection will determine which source address is used. Note that there is no relationship between the source address selected and which (default) router is used for sending packets. case 2: Host with two interface, one router on each interface, one global address being configured on each interface with different prefixes (each router advertises a single addrconf prefix) In this case the candidate source address set will be coupled to the (default) route used to send the packet, since there are two interfaces. In both cases there are issues of what happens when e.g. one of the routers fail, which have to do with not only how the host behaves but also how routing works beyond the first hop routers. Erik --EeQfGwPcQSOJBaQU Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id SAA02729 for ; Wed, 9 Oct 2002 18:28:56 -0400 (EDT) Received: from smtp.tari.toshiba.com ([208.192.119.195]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g99MRmsn029900 for ; Wed, 9 Oct 2002 18:27:49 -0400 (EDT) Received: from tai.toshiba.com by smtp.tari.toshiba.com (8.9.1/3.7W-020529) with ESMTP id RAA10703 for ; Wed, 9 Oct 2002 17:27:16 -0400 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by tai.toshiba.com (8.7.3/8.7.5) with ESMTP id SAA04581 for ; Wed, 9 Oct 2002 18:21:15 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19961; Wed, 9 Oct 2002 15:22:11 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g99MLiPO002217; Wed, 9 Oct 2002 15:22:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99MKr29013706; Wed, 9 Oct 2002 15:20:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g99MKqPP013705; Wed, 9 Oct 2002 15:20:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99MKn29013698 for ; Wed, 9 Oct 2002 15:20:49 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g99MKsMq026038 for ; Wed, 9 Oct 2002 15:20:55 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA29165 for ; Wed, 9 Oct 2002 15:20:49 -0700 (PDT) content-class: urn:content-classes:message Subject: RE: multihomed host MIME-Version: 1.0 Date: Wed, 9 Oct 2002 15:21:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <2B81403386729140A3A899A8B39B046405E365@server2000> Thread-Topic: multihomed host Thread-Index: AcJv03CVWgQrBF9MSVe0fEonzBlzQAAC4vzw From: "Michel Py" To: , "Margaret Wasserman" Cc: "Yoshihiro Ohba" , , X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g99MKn29013699 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Content-Type: text/plain; charset="US-ASCII" X-UIDL: 56757ac1d1c5c05c13189cba379afcb4 Content-Transfer-Encoding: 8bit > Yoshihiro Ohba wrote: > I don't know if there is an official definition, but I > have usually heard the term "multihomed host" used to > refer to multi-interface systems that do not function > as routers (i.e. they don't forward packets). Here is my reading of this: 1. Multi-interface host: > Margaret Wasserman wrote: > I don't know if there is an official definition, but I > have usually heard the term "multihomed host" used to > refer to multi-interface systems that do not function > as routers (i.e. they don't forward packets). I agree with Margaret. A host that has multiple interfaces connected to multiple subnets *is* a multihomed host, but... 2. A host that has multiple interfaces with addresses in the same subnet (either to increase throughput or to provide redundancy) is *not* a multihomed host. 3. Single interface, multiple address host: > Bill Sommerfeld wrote: > For what it's worth, I've occasionally heard the > term used in an application-layer context to refer > to hosts having multiple IP addresses rather than/in > addition to multiple interfaces. For v4, I agree with Bill *if* the multiple addresses belong to different subnets. For v6, this is blurry. Would you call multihomed a host that has both a link-local and a regular unicast address on the same interface? I don't think so. On the other hand, > Yoshihiro Ohba wrote: > There may be some scenario in which a single-interface > host is connected to multiple ISPs on the same link, which > seems to be not covered in the usual definition for > "multihomed host". I don't know what to call the model, > but is such a model already common? Or is there any > ongoing work on this model? This is possible as of today; a host that has multiple PA addresses is certainly considered a multihomed host. However, this alone is not a multihoming solution. 4. A host that has a single address but is part of a multihomed site: This would be the case for hosts belonging to a multihomed LIR, or the case of hosts connecting to a MHAP network. I do not call these hosts multihomed. In other words: semantically speaking, the fact that the host is connected to a multihomed router does not make the host itself multihomed, IMHO. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- --EeQfGwPcQSOJBaQU Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id SAA02813 for ; Wed, 9 Oct 2002 18:56:35 -0400 (EDT) Received: from smtp.tari.toshiba.com ([208.192.119.195]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g99MtQsn001684 for ; Wed, 9 Oct 2002 18:55:27 -0400 (EDT) Received: from tai.toshiba.com by smtp.tari.toshiba.com (8.9.1/3.7W-020529) with ESMTP id RAA10827 for ; Wed, 9 Oct 2002 17:51:26 -0400 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by tai.toshiba.com (8.7.3/8.7.5) with ESMTP id SAA04682 for ; Wed, 9 Oct 2002 18:45:25 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09704; Wed, 9 Oct 2002 16:48:33 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA27727; Wed, 9 Oct 2002 18:48:32 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g99MmWgu025186; Wed, 9 Oct 2002 18:48:32 -0400 (EDT) Message-Id: <200210092248.g99MmWgu025186@thunk.east.sun.com> From: Bill Sommerfeld To: "Michel Py" cc: sommerfeld@east.sun.com, "Margaret Wasserman" , "Yoshihiro Ohba" , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org Subject: Re: multihomed host In-Reply-To: Your message of "Wed, 09 Oct 2002 15:21:34 PDT." <2B81403386729140A3A899A8B39B046405E365@server2000> Reply-to: sommerfeld@east.sun.com Date: Wed, 09 Oct 2002 18:48:32 -0400 Sender: sommerfeld@thunk.east.sun.com X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Content-Type: text X-UIDL: 2db79751ff76ba7b4f73b7cff6a18085 MIME-Version: 1.0 > For v4, I agree with Bill *if* the multiple addresses belong to > different subnets. > > For v6, this is blurry. Would you call multihomed a host that has both a > link-local and a regular unicast address on the same interface? I don't > think so. >From the point of view of what applications need to do, it's safest to assume that all V6 hosts are multiaddressed. - Bill --EeQfGwPcQSOJBaQU Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id TAA02918 for ; Wed, 9 Oct 2002 19:26:00 -0400 (EDT) Received: from smtp.tari.toshiba.com ([208.192.119.195]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g99NOrsn002998 for ; Wed, 9 Oct 2002 19:24:54 -0400 (EDT) Received: from tai.toshiba.com by smtp.tari.toshiba.com (8.9.1/3.7W-020529) with ESMTP id SAA11002 for ; Wed, 9 Oct 2002 18:24:20 -0400 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by tai.toshiba.com (8.7.3/8.7.5) with ESMTP id TAA05169 for ; Wed, 9 Oct 2002 19:18:19 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g99NKwsn002797; Wed, 9 Oct 2002 19:20:58 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id TAA02904; Wed, 9 Oct 2002 19:21:29 -0400 (EDT) Date: Wed, 9 Oct 2002 19:20:56 -0400 To: Michel Py Cc: sommerfeld@East.sun.com, Margaret Wasserman , Yoshihiro Ohba , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org Subject: Re: multihomed host Message-ID: <20021009232056.GN2310@catfish> References: <2B81403386729140A3A899A8B39B046405E365@server2000> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <2B81403386729140A3A899A8B39B046405E365@server2000> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Content-Type: text/plain; charset=iso-2022-jp X-UIDL: d4cc6f07a4ae1284ad59dcd37ce00aeb Thank you all for helping me understand. I have additional question below. On Wed, Oct 09, 2002 at 03:21:34PM -0700, Michel Py wrote: > On the other hand, > > Yoshihiro Ohba wrote: > > There may be some scenario in which a single-interface > > host is connected to multiple ISPs on the same link, which > > seems to be not covered in the usual definition for > > "multihomed host". I don't know what to call the model, > > but is such a model already common? Or is there any > > ongoing work on this model? > > This is possible as of today; a host that has multiple PA addresses is > certainly considered a multihomed host. However, this alone is not a > multihoming solution. > What additional things need to be considered for this usage to become a multihoming solution? Yoshihiro Ohba --EeQfGwPcQSOJBaQU Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id DAA03526 for ; Thu, 10 Oct 2002 03:10:38 -0400 (EDT) Received: from smtp.tari.toshiba.com ([208.192.119.195]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g9A79Vsn023612 for ; Thu, 10 Oct 2002 03:09:32 -0400 (EDT) Received: from tai.toshiba.com by smtp.tari.toshiba.com (8.9.1/3.7W-020529) with ESMTP id CAA12255 for ; Thu, 10 Oct 2002 02:05:49 -0400 Received: from sequoia.muada.com (sequoia.muada.com [213.156.1.123]) by tai.toshiba.com (8.7.3/8.7.5) with ESMTP id CAA07332 for ; Thu, 10 Oct 2002 02:59:48 -0400 (EDT) Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9A72YS88790; Thu, 10 Oct 2002 09:02:34 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 10 Oct 2002 09:02:34 +0200 (CEST) From: Iljitsch van Beijnum To: Yoshihiro Ohba cc: , Subject: Re: multihomed host In-Reply-To: <20021009232056.GN2310@catfish> Message-ID: <20021010084219.O85622-100000@sequoia.muada.com> MIME-Version: 1.0 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 8305ef508694841925f9ab01942f63d6 On Wed, 9 Oct 2002, Yoshihiro Ohba wrote: > > This is possible as of today; a host that has multiple PA addresses is > > certainly considered a multihomed host. However, this alone is not a > > multihoming solution. > What additional things need to be considered for this usage to become > a multihoming solution? A good multihoming solution keeps working if there are failures. So the applications must be smart enough to try all the addresses rather than just one. Telnet and FTP do this, WWW clients typically don't. Unfortunately, this must be done at the remote end and not on the multi(homed|addressed) host itself. When there is a session, and the path over one ISP becomes unavailable, the multihomed host must switch to the path over the other ISP. There are many problems with this. First of all, the failure must be detected. Then the host can reroute outgoing packets. But if the host still uses the same source address (from the address space from the failed ISP), it is likely the packets won't be accepted by the alternate ISP because the source addresses are "spoofed". And even if they are, the communications partner keeps sending packets back to th source address tied to the first ISP, which isn't reachable any more. One solution for the address problem would be the adoption of new or improved transport protocols that can handle this. There have been experiments with modifications to TCP to support this, and the new SCTP protocol can also handle this. However, modifying all transport protocols might be problematic. Another solution is tunnelling/aliasing the packet to hide the original address while the packet is rerouted over the alternative path. The destination host or a box very close to the destination host strips of the tunnel header or replaces the original address so TCP and other transport protocols don't see the change in address. Some of us are working on this stuff on a non-IETF mailinglist. The latest idea is to come up with a common tunnelling/aliasing framework so different solutions in this area may interoperate. --EeQfGwPcQSOJBaQU Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id MAA04520 for ; Thu, 10 Oct 2002 12:27:19 -0400 (EDT) Received: from smtp.tari.toshiba.com ([208.192.119.195]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g9AGQ8sn002294 for ; Thu, 10 Oct 2002 12:26:09 -0400 (EDT) Received: from tai.toshiba.com by smtp.tari.toshiba.com (8.9.1/3.7W-020529) with ESMTP id LAA13342 for ; Thu, 10 Oct 2002 11:22:11 -0400 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by tai.toshiba.com (8.7.3/8.7.5) with ESMTP id MAA00493 for ; Thu, 10 Oct 2002 12:16:07 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g9AFKdsn026792; Thu, 10 Oct 2002 11:20:40 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id LAA04301; Thu, 10 Oct 2002 11:21:08 -0400 (EDT) Date: Thu, 10 Oct 2002 11:20:35 -0400 To: Iljitsch van Beijnum , Michel Py Cc: Yoshihiro Ohba , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org, sommerfeld@East.sun.com, Margaret Wasserman Subject: Re: multihomed host Message-ID: <20021010152035.GB682@catfish> References: <2B81403386729140A3A899A8B39B046405E369@server2000> <20021009232056.GN2310@catfish> <20021010084219.O85622-100000@sequoia.muada.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <2B81403386729140A3A899A8B39B046405E369@server2000> <20021010084219.O85622-100000@sequoia.muada.com> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Content-Type: text/plain; charset=iso-2022-jp X-UIDL: 76bee8a5c95d11254d9d1f7be8aa729d Thanks Iljitsch for detailed answer and Michel for the pointer. Actually, I'm working in the PANA WG and viewing this kind of multihomed host scenario from network access authentication perspective, and wondering whether the PANA WG needs to consider this scenario for now. (My impression is that there is a lot of work to consider before considering network access authentication) Yoshihiro Ohba On Thu, Oct 10, 2002 at 09:02:34AM +0200, Iljitsch van Beijnum wrote: > On Wed, 9 Oct 2002, Yoshihiro Ohba wrote: > > > > This is possible as of today; a host that has multiple PA addresses is > > > certainly considered a multihomed host. However, this alone is not a > > > multihoming solution. > > > What additional things need to be considered for this usage to become > > a multihoming solution? > > A good multihoming solution keeps working if there are failures. So the > applications must be smart enough to try all the addresses rather than > just one. Telnet and FTP do this, WWW clients typically don't. > Unfortunately, this must be done at the remote end and not on the > multi(homed|addressed) host itself. > > When there is a session, and the path over one ISP becomes unavailable, > the multihomed host must switch to the path over the other ISP. There are > many problems with this. First of all, the failure must be detected. Then > the host can reroute outgoing packets. But if the host still uses the same > source address (from the address space from the failed ISP), it is likely > the packets won't be accepted by the alternate ISP because the source > addresses are "spoofed". And even if they are, the communications partner > keeps sending packets back to th source address tied to the first ISP, > which isn't reachable any more. > > One solution for the address problem would be the adoption of new or > improved transport protocols that can handle this. There have been > experiments with modifications to TCP to support this, and the new SCTP > protocol can also handle this. However, modifying all transport protocols > might be problematic. > > Another solution is tunnelling/aliasing the packet to hide the original > address while the packet is rerouted over the alternative path. The > destination host or a box very close to the destination host strips of the > tunnel header or replaces the original address so TCP and other transport > protocols don't see the change in address. > > Some of us are working on this stuff on a non-IETF mailinglist. The latest > idea is to come up with a common tunnelling/aliasing framework so > different solutions in this area may interoperate. > > On Wed, Oct 09, 2002 at 11:11:09PM -0700, Michel Py wrote: > >>> Yoshihiro Ohba wrote: > >>> There may be some scenario in which a single-interface > >>> host is connected to multiple ISPs on the same link, which > >>> seems to be not covered in the usual definition for > >>> "multihomed host". I don't know what to call the model, > >>> but is such a model already common? Or is there any > >>> ongoing work on this model? > > >> Michel Py wrote: > >> This is possible as of today; a host that has multiple PA > >> addresses is certainly considered a multihomed host. > >> However, this alone is not a multihoming solution. > > > What additional things need to be considered for this > > usage to become a multihoming solution? > > There is no simple answer to this question. Here is one approach: > http://arneill-py.sacramento.ca.us/ipv6mh/draft-bagnulo-mhExtHdr-00.txt > > Michel. > > --EeQfGwPcQSOJBaQU Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id TAA02847 for ; Wed, 9 Oct 2002 19:00:04 -0400 (EDT) Received: from smtp.tari.toshiba.com ([208.192.119.195]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g99Mwvsn001882 for ; Wed, 9 Oct 2002 18:58:58 -0400 (EDT) Received: from tai.toshiba.com by smtp.tari.toshiba.com (8.9.1/3.7W-020529) with ESMTP id RAA10856 for ; Wed, 9 Oct 2002 17:58:24 -0400 Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by tai.toshiba.com (8.7.3/8.7.5) with ESMTP id SAA04708 for ; Wed, 9 Oct 2002 18:52:24 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: multihomed host MIME-Version: 1.0 Date: Wed, 9 Oct 2002 15:55:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <2B81403386729140A3A899A8B39B04640BD192@server2000> Thread-Topic: multihomed host Thread-Index: AcJv5i+GBJC2QX20Qf+uo/e21ejqigAAGxoA From: "Michel Py" To: Cc: "Margaret Wasserman" , "Yoshihiro Ohba" , , X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Content-Type: text/plain; charset="US-ASCII" X-UIDL: bb020c8c99e934a47a53dc0f78b6ec2c Content-Transfer-Encoding: quoted-printable > Bill Sommerfeld wrote: > From the point of view of what applications need to do, > it's safest to assume that all V6 hosts are multiaddressed. Strongly agree. Although multiaddressed does not necessarily mean multihomed, it is likely that part of the multihoming solution is multiadressed hosts. Michel. --EeQfGwPcQSOJBaQU Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id TAA02855 for ; Wed, 9 Oct 2002 19:02:27 -0400 (EDT) Received: from smtp.tari.toshiba.com ([208.192.119.195]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g99N1Ksn001964 for ; Wed, 9 Oct 2002 19:01:21 -0400 (EDT) Received: from tai.toshiba.com by smtp.tari.toshiba.com (8.9.1/3.7W-020529) with ESMTP id SAA10900 for ; Wed, 9 Oct 2002 18:00:42 -0400 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by tai.toshiba.com (8.7.3/8.7.5) with ESMTP id SAA04729 for ; Wed, 9 Oct 2002 18:54:41 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA27849; Wed, 9 Oct 2002 16:56:25 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g99Mu0N0005476; Wed, 9 Oct 2002 15:56:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99MtL29014192; Wed, 9 Oct 2002 15:55:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g99MtLWA014191; Wed, 9 Oct 2002 15:55:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99MtI29014184 for ; Wed, 9 Oct 2002 15:55:18 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g99MtNMq005333 for ; Wed, 9 Oct 2002 15:55:23 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA28835 for ; Wed, 9 Oct 2002 16:55:11 -0600 (MDT) content-class: urn:content-classes:message Subject: RE: multihomed host MIME-Version: 1.0 Date: Wed, 9 Oct 2002 15:55:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <2B81403386729140A3A899A8B39B04640BD192@server2000> Thread-Topic: multihomed host Thread-Index: AcJv5i+GBJC2QX20Qf+uo/e21ejqigAAGxoA From: "Michel Py" To: Cc: "Margaret Wasserman" , "Yoshihiro Ohba" , , X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g99MtI29014185 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Content-Type: text/plain; charset="US-ASCII" X-UIDL: 93d9b9d95ca16c45766ab4aa33b15e83 Content-Transfer-Encoding: 8bit > Bill Sommerfeld wrote: > From the point of view of what applications need to do, > it's safest to assume that all V6 hosts are multiaddressed. Strongly agree. Although multiaddressed does not necessarily mean multihomed, it is likely that part of the multihoming solution is multiadressed hosts. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- --EeQfGwPcQSOJBaQU Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id CAA03473 for ; Thu, 10 Oct 2002 02:18:29 -0400 (EDT) Received: from smtp.tari.toshiba.com ([208.192.119.195]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g9A6HMsn021551 for ; Thu, 10 Oct 2002 02:17:23 -0400 (EDT) Received: from tai.toshiba.com by smtp.tari.toshiba.com (8.9.1/3.7W-020529) with ESMTP id BAA12195 for ; Thu, 10 Oct 2002 01:13:36 -0400 Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by tai.toshiba.com (8.7.3/8.7.5) with ESMTP id CAA07275 for ; Thu, 10 Oct 2002 02:07:36 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: multihomed host MIME-Version: 1.0 Date: Wed, 9 Oct 2002 23:11:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <2B81403386729140A3A899A8B39B046405E369@server2000> Thread-Topic: multihomed host Thread-Index: AcJv6s3SpmocDFsoSuG9IRHUzk8BuwAN8WZA From: "Michel Py" To: "Yoshihiro Ohba" Cc: , "Margaret Wasserman" , , X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Content-Type: text/plain; charset="US-ASCII" X-UIDL: 5ae168dd85974171a6b76f29df576f39 Content-Transfer-Encoding: quoted-printable >>> Yoshihiro Ohba wrote: >>> There may be some scenario in which a single-interface >>> host is connected to multiple ISPs on the same link, which >>> seems to be not covered in the usual definition for >>> "multihomed host". I don't know what to call the model, >>> but is such a model already common? Or is there any >>> ongoing work on this model? =20 >> Michel Py wrote: >> This is possible as of today; a host that has multiple PA >> addresses is certainly considered a multihomed host. >> However, this alone is not a multihoming solution. > What additional things need to be considered for this > usage to become a multihoming solution? There is no simple answer to this question. Here is one approach: http://arneill-py.sacramento.ca.us/ipv6mh/draft-bagnulo-mhExtHdr-00.txt Michel. --EeQfGwPcQSOJBaQU Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id SAA05605 for ; Thu, 10 Oct 2002 18:46:53 -0400 (EDT) Received: from smtp.tari.toshiba.com ([208.192.119.195]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g9AMk1sn000562 for ; Thu, 10 Oct 2002 18:46:02 -0400 (EDT) Received: from tai.toshiba.com by smtp.tari.toshiba.com (8.9.1/3.7W-020529) with ESMTP id RAA14902 for ; Thu, 10 Oct 2002 17:42:20 -0400 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by tai.toshiba.com (8.7.3/8.7.5) with ESMTP id SAA02793 for ; Thu, 10 Oct 2002 18:36:19 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9AMdFKV012071; Fri, 11 Oct 2002 00:39:15 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <44LQ3NKS>; Fri, 11 Oct 2002 00:39:15 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0B2D@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'William Waites'" , Bill Sommerfeld Cc: Margaret Wasserman , Yoshihiro Ohba , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org Subject: RE: multihomed host Date: Fri, 11 Oct 2002 00:39:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 6094237f62b0cab9c4a07da6705d9bd1 > >>> "Bill" == Bill Sommerfeld writes: > > Bill> For what it's worth, I've occasionally heard > the term used > Bill> in an application-layer context to refer to > hosts having > Bill> multiple IP addresses rather than/in addition > to multiple > Bill> interfaces. > > This just looks like the degenerate case -- multiple > addresses, > multiple interfaces, except that each of the multiple > interfaces > happen to be the same. It seems to me that the network > layer code > should treat both cases identically. Does this make sense? => I don't think so. There is a difference in existing standards (2461) and implementations between the 2 cases. A multiaddressed node with a single interface assumes that any address can be used as a source address with any default router. This is clearly not a good assumption for multi-interfaced (multihomed) nodes Hesham --EeQfGwPcQSOJBaQU-- From pana-request@research.telcordia.com Fri Jan 10 03:19:32 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20524 for ; Fri, 10 Jan 2003 03:19:11 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0A8JxFq005075; Fri, 10 Jan 2003 03:19:59 -0500 (EST) Resent-Date: Fri, 10 Jan 2003 03:19:59 -0500 (EST) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: About the NAP/ISP distinction in the usage-scenarios draft... Date: Fri, 10 Jan 2003 10:19:45 +0200 Message-ID: Thread-Topic: About the NAP/ISP distinction in the usage-scenarios draft... Thread-Index: AcK4CG5Rg5VJQGYnQ1OR0iarnxBfqwAc+Vlg From: To: Cc: , , , X-OriginalArrivalTime: 10 Jan 2003 08:19:47.0950 (UTC) FILETIME=[0A1908E0:01C2B881] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Ohba, Thank you for these email attachements. I read them through and they described the multihoming problem, but I didn't mean multihoming. The PaC doesn't have to get an IP address from the SP network if NAP provides it (I don't know if I'm using the right terms). Anyway, IP address allocation is out of the scope. My picture is probably limited, because AR in the SP network could be a GW too. So, PaC can use the existing IP address and request access to the SP network. This kind of scenario could support VPN networks too (PPVPN?). Generally speaking, there could be multiple hops between EP and PaC. So, why to limit this with a requirement. A more general requirement could be to limit the number of hops between PAA and it's related EPs, if that is really needed. - Dan > -----Original Message----- > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: 09 January, 2003 19:56 > To: Forsberg Dan (NRC/Helsinki) > Cc: yohba@tari.toshiba.com; alper@docomolabs-usa.com; > lionel.morand@rd.francetelecom.com; Patil Basavaraj > (NET/Dallas); pana@research.telcordia.com > Subject: Re: About the NAP/ISP distinction in the > usage-scenarios draft... > > > On Wed, Jan 08, 2003 at 04:45:20PM +0200, > Dan.Forsberg@nokia.com wrote: > > Hi all and Happy New Year! > > > > The multi-method authentication happens in serial and in > the same "session", thus it doesn't fit for all cases. > > > > As PANA is carried over IP, I never really understood the > requirement for the PAA to be in the same link than PaC. For > discovery purposes this is not necessary, especially in cases > where PAA initiates the authentication/authorization. Usage > scenario below. > > > > When PaC utilizes multiple ISPs, the auth. happens when PaC > starts to access the ISP's network. > > The usage scenario team actually considered that scenario before > submitting the current version. But we concluded we should not > describe it due to the difficulty of supporting multihomed > single-interface hosts. I attach related email discussion in IPv6 > WG (sorry for long attachment). > > > > > . . . . . . . . . . . . . . > > . . . > > PaC . . . AR--PAA | AR--PAA | AR--PAA | > > | | | | | | > > AAA | AAA | AAA | > > (NAP) | (ISP) | (ISP) | > > > > - Dan > > > > > > Yoshihiro Ohba > From pana-request@research.telcordia.com Fri Jan 10 13:10:14 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08158 for ; Fri, 10 Jan 2003 13:10:10 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0AIAHE8012114; Fri, 10 Jan 2003 13:10:17 -0500 (EST) Resent-Date: Fri, 10 Jan 2003 13:10:17 -0500 (EST) Old-Return-Path: Message-ID: <004401c2b8d3$2a398c60$1d6015ac@AlperVAIO> From: "Alper E. YEGIN" To: , Cc: , , References: Subject: Re: About the NAP/ISP distinction in the usage-scenarios draft... Date: Fri, 10 Jan 2003 10:07:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > Generally speaking, there could be multiple hops between EP and PaC. So, why to limit this with a requirement. A more general requirement could be to limit the number of hops between PAA and it's related EPs, if that is really needed. > There is no requirement regarding the number of hops between the EP and PaC. But there is one for between PAA and PaC. The decision was to require them to be one hop away, because having multiple hops incurs complexity which was not justified by an essential usage scenario. alper From pana-request@research.telcordia.com Fri Jan 10 14:30:52 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13404 for ; Fri, 10 Jan 2003 14:30:52 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0AJVArA018040; Fri, 10 Jan 2003 14:31:10 -0500 (EST) Resent-Date: Fri, 10 Jan 2003 14:31:10 -0500 (EST) Old-Return-Path: content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: About the NAP/ISP distinction in the usage-scenarios draft... Date: Fri, 10 Jan 2003 20:30:12 +0100 Message-ID: Thread-Topic: About the NAP/ISP distinction in the usage-scenarios draft... Thread-Index: AcKi/lBiC0v4KAmNSxmw6uxzC0zk3AV2AUQQ From: "MORAND Lionel FTRD/DAC/ISS" To: "Alper E. YEGIN" , "Yoshihiro Ohba" , Cc: X-OriginalArrivalTime: 10 Jan 2003 19:30:12.0882 (UTC) FILETIME=[B2068F20:01C2B8DE] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA13404 Hi Alper and Happy new Year to the PANA folks! I will try (with some delay) to answer to your request using a suitable scenario. One basic objective of multiple-level authentication could be to allow the NAP to distinguish different users and to be able then to provide distinct network configurations to those clients (with different classes of Service (CoS) for instance). On this basis, two different users may subscribe to: - two different CoS offered by the NAP, - two different ISPs, and they may be able to use the same access link but at different time (in this example). If one user would like to browse the Web, the client will be first authenticated by the NAP in order to determine what Cos the client has subscribed to. Once authenticated by the NAP, the client will be authenticated by his/her ISP as usual. - If the first authentication failed (but the second one succeded), a per-default network configuration could be selected for the current connection or the NAP could decide to reject the access request. - If the second authentication failed (but the first one succeded), the client will not be allowed to browse the Web but some local services (provided by the NAP) could be nevertheless offered. Several other combinations are also possible. Does this scenario answer correctly to your questions, Alper? >-----Message d'origine----- >De : Alper E. YEGIN [mailto:alper@docomolabs-usa.com] >Envoyé : samedi 14 décembre 2002 00:19 >Ą : MORAND Lionel FTRD/DAC/ISS; Yoshihiro Ohba; >basavaraj.Patil@nokia.com >Cc : pana@research.telcordia.com >Objet : Re: About the NAP/ISP distinction in the usage-scenarios >draft... > > > >Lionel, > >I think it'd be useful to understand the semantics of each >authentication, >and the expected actions taken by the client and the network >after each one >is >completed. > >For example: >1- what does it mean to the NAP when a client gets authenticated? What >actions >should be taken (e.g., how are the filters updated, where are >they updated, >etc.)? > >2- What can or cannot the client do after this first round of >authentication? > >3- same question as 1, but for ISP authentication. > >4- same question as 2, but for ISP authentication. > > >alper > > > >> Hi Alper, >> >> I think that, in the described scenario, the principle of >two successive >authentications (one per AAA backend) may appear obvious. However, >considering a single PAA handling the both authentication >procedures, there >is an issue concerning the use of the DI. >> >> The most intuitive idea is to reuse the same DI for both >authentications >and to use different sets of credentials >(identifier,authenticator) supplied >by the client. But according to the current draft on the PANA >requirements >and as Yoshihiro said, it seems that it should not be possible. >> >> On the other hand, the alternative would be to use different >DIs but the >PAA would create distinct bindings, and so distinct instances >in this case, >that would make the network access control more complex. >> >> A simple solution here could be to allow in the PANA requirements the >association of one single DI with different PaCs, but this may >raise up some >other previous/new concerns. >> >> What do you think about this? >> >> Best Regards, >> >> Lionel >> >> >> >-----Message d'origine----- >> >De : Alper E. YEGIN [mailto:alper@docomolabs-usa.com] >> >Envoyé : jeudi 12 décembre 2002 00:16 >> >Ą : MORAND Lionel FTRD/DAC/ISS; >pana@research.telcordia.com; Yoshihiro >> >Ohba; basavaraj.Patil@nokia.com >> >Objet : Re: About the NAP/ISP distinction in the usage-scenarios >> >draft... >> > >> > >> > >> >Hello Lionel, >> > >> >Thanks for bringing this scenario up. >> > >> >In the case both NAP and ISP requires their own independent >> >client authentication, I presume we can still envision both >> >using the same PAA on the BAS (broadband access server). Does this >> >makes sense? >> > >> >For NAP authentication, PAA consults with AAA backend in NAP >> >network. For ISP authentication, PAA consults with AAA backend >> >in ISP network. >> > >> >Somehow the client needs to know (or discover??) that it has >> >to go through the authentication twice. Discovery might be tricky >> >because something has to tell the client that the second one >> >is meant for the ISP, etc.... If the client knows it has to do both, >> >it can differentiate the authentication process by using different >> >client identifiers in each. Therefore PAA can demultiplex the >> >authentication request to the right backend. >> > >> >So, running PANA twice between the PaC and the same PAA maybe one >> >approach. Each time PaC can use a different set of >credentials. If the >> >same credentials are used, then we need something else in >the process >> >to indicate which one is for NAP authentication vs for ISP >> >authentication. >> > >> >When two different set of credentials are used, if PaC uses the same >> >DI, this might be an issue. Normally they would appear as >two separate >> >clients to the PAA, but since the network is aware of this >> >dual-authentication >> >scheme, and the requests are coming from the same circuit, >maybe this >> >can be handled. And than, how will these DIs be used with service >> >provisioning, after each authentication? Is EP still co-located >> >with BAS here? How should the NAP authentication update EP, and ISP >> >authentication update EP? These are general questions about >the model >> >you are describing.. >> > >> > >> >alper >> > >> > >> > >> > >> > >> > >> > >> > >> >----- Original Message ----- >> >From: MORAND Lionel FTRD/DAC/ISS >> >To: pana@research.telcordia.com ; Yoshihiro Ohba ; >> >basavaraj.Patil@nokia.com >> >; Alper E. YEGIN >> >Sent: Monday, December 09, 2002 5:59 AM >> >Subject: About the NAP/ISP distinction in the >usage-scenarios draft... >> > >> > >> >Hi folks, >> > >> >In the current version of the Usage-Scenario draft, in the >section 3: >> >Problem Statement, the distinction between NAP (Network Acces >> >Provider) and >> >ISP (Internet Service Provider) is pointing out. >> > >> >[...An important aspect of an authentication protocol is >the ability to >> >provide dynamic service provider selection to the clients. >> >Regardless of >> >their network access provider (NAP), clients should be able to >> >select an >> >Internet access provider (ISP) of their choice. This is >> >usually achieved by >> >clients presenting an identifier which carries domain >> >information during the >> >authentication process. ] >> > >> >This distinction is particularly true in the case of DSL >> >networks where NAP >> >and ISP are often two different players. Besides traditional >> >"package" offer >> >(access + Internet provided by the ISP), NAP are able to >> >provide broadband >> >access services directly to the user, regardless of the ISP >> >selected by the >> >user. Moreover, different access network configurations may be >> >provide to an >> >xDSL client, based on the access service subscribed to the >> >NAP. We could >> >also imagine the provision of some local services in the >> >short/medium term. >> > >> >In order to provide such a "customized" service, the NAP needs to >> >identify/authenticate the user that logs on to the access >network. This >> >authentication is independent from the authentication achieved >> >by the ISP >> >and so not necessarily based on the same user credentials. >> >This induces a >> >requirement for two levels of authentication: one at the NAP >> >level, one at >> >the ISP level. I think that this requirement is not only >> >restricted to xDSL >> >network and be generalized on the contrary. >> > >> >For the time being, if PPP is used to carry user information for ISP >> >authentication, NAP identification is mainly based on >> >information on the >> >physical link used for the connection (phone line number, ATM >> >link, etc.) >> >and not according to the user using the connection. So it is >> >not possible to >> >distinguish two consecutive users using the same link and >the network >> >configuration is only based on the service subscribed for the >> >access link. >> > >> >and now I wonder: >> >How the PANA protocol could fulfil such a requirement on two >> >authentication >> >levels (NAP, ISP)? >> >What would be the consequences on the general PANA requirements? >> >Would it be useful to include/precise this scenario be in >the current >> >usage-scenarios draft? >> >Any comment/reaction from the mailing list? >> > >> >Lionel. >> > >> > >> > > From pana-request@research.telcordia.com Fri Jan 10 17:48:26 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19034 for ; Fri, 10 Jan 2003 17:48:16 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0AMlxF8001776; Fri, 10 Jan 2003 17:47:59 -0500 (EST) Resent-Date: Fri, 10 Jan 2003 17:47:59 -0500 (EST) Old-Return-Path: Message-ID: <00a301c2b8fa$01dcfd70$096015ac@AlperVAIO> From: "Alper E. YEGIN" To: "MORAND Lionel FTRD/DAC/ISS" , "Yoshihiro Ohba" , Cc: References: Subject: Re: About the NAP/ISP distinction in the usage-scenarios draft... Date: Fri, 10 Jan 2003 14:45:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit Hi Lionel, One way to achieve this scenario is to: - let a user have two identifiers. E.g.: user1@NAP.com, and user1@ISP.com - Single PAA co-located with the BAS (broadband access server). - PaC either performs single PANA authentication in which two subsequent authentication methods are executed, one with each PaC identifier; or it performs one PANA authentication after another, again each with different PaC identifier. - One set of filters should be set on the EP, which will be a product of the successful authentication methods. If two PANA authentications take place, then PAA should be able to associate both with the same entity. Note that they would have different PaC identifier, but since they are coming from the same device (circuit id) in particular order with close proximity, this is possible. One change needed on the current set of assumptions and requirements would be to relax one2one mapping between PaC and device identifiers. Can anyone think of other ways to implement this scenario? alper ----- Original Message ----- From: "MORAND Lionel FTRD/DAC/ISS" To: "Alper E. YEGIN" ; "Yoshihiro Ohba" ; Cc: Sent: Friday, January 10, 2003 11:30 AM Subject: RE: About the NAP/ISP distinction in the usage-scenarios draft... > Hi Alper and Happy new Year to the PANA folks! > > I will try (with some delay) to answer to your request using a suitable scenario. > > One basic objective of multiple-level authentication could be to allow the NAP to distinguish different users and to be able then to provide distinct network configurations to those clients (with different classes of Service (CoS) for instance). > > On this basis, two different users may subscribe to: > > - two different CoS offered by the NAP, > - two different ISPs, > > and they may be able to use the same access link but at different time (in this example). > > If one user would like to browse the Web, the client will be first authenticated by the NAP in order to determine what Cos the client has subscribed to. Once authenticated by the NAP, the client will be authenticated by his/her ISP as usual. > > - If the first authentication failed (but the second one succeded), a per-default network configuration could be selected for the current connection or the NAP could decide to reject the access request. > > - If the second authentication failed (but the first one succeded), the client will not be allowed to browse the Web but some local services (provided by the NAP) could be nevertheless offered. > > Several other combinations are also possible. > > Does this scenario answer correctly to your questions, Alper? > > > >-----Message d'origine----- > >De : Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > >Envoyé : samedi 14 décembre 2002 00:19 > >Ą : MORAND Lionel FTRD/DAC/ISS; Yoshihiro Ohba; > >basavaraj.Patil@nokia.com > >Cc : pana@research.telcordia.com > >Objet : Re: About the NAP/ISP distinction in the usage-scenarios > >draft... > > > > > > > >Lionel, > > > >I think it'd be useful to understand the semantics of each > >authentication, > >and the expected actions taken by the client and the network > >after each one > >is > >completed. > > > >For example: > >1- what does it mean to the NAP when a client gets authenticated? What > >actions > >should be taken (e.g., how are the filters updated, where are > >they updated, > >etc.)? > > > >2- What can or cannot the client do after this first round of > >authentication? > > > >3- same question as 1, but for ISP authentication. > > > >4- same question as 2, but for ISP authentication. > > > > > >alper > > > > > > > >> Hi Alper, > >> > >> I think that, in the described scenario, the principle of > >two successive > >authentications (one per AAA backend) may appear obvious. However, > >considering a single PAA handling the both authentication > >procedures, there > >is an issue concerning the use of the DI. > >> > >> The most intuitive idea is to reuse the same DI for both > >authentications > >and to use different sets of credentials > >(identifier,authenticator) supplied > >by the client. But according to the current draft on the PANA > >requirements > >and as Yoshihiro said, it seems that it should not be possible. > >> > >> On the other hand, the alternative would be to use different > >DIs but the > >PAA would create distinct bindings, and so distinct instances > >in this case, > >that would make the network access control more complex. > >> > >> A simple solution here could be to allow in the PANA requirements the > >association of one single DI with different PaCs, but this may > >raise up some > >other previous/new concerns. > >> > >> What do you think about this? > >> > >> Best Regards, > >> > >> Lionel > >> > >> > >> >-----Message d'origine----- > >> >De : Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > >> >Envoyé : jeudi 12 décembre 2002 00:16 > >> >Ą : MORAND Lionel FTRD/DAC/ISS; > >pana@research.telcordia.com; Yoshihiro > >> >Ohba; basavaraj.Patil@nokia.com > >> >Objet : Re: About the NAP/ISP distinction in the usage-scenarios > >> >draft... > >> > > >> > > >> > > >> >Hello Lionel, > >> > > >> >Thanks for bringing this scenario up. > >> > > >> >In the case both NAP and ISP requires their own independent > >> >client authentication, I presume we can still envision both > >> >using the same PAA on the BAS (broadband access server). Does this > >> >makes sense? > >> > > >> >For NAP authentication, PAA consults with AAA backend in NAP > >> >network. For ISP authentication, PAA consults with AAA backend > >> >in ISP network. > >> > > >> >Somehow the client needs to know (or discover??) that it has > >> >to go through the authentication twice. Discovery might be tricky > >> >because something has to tell the client that the second one > >> >is meant for the ISP, etc.... If the client knows it has to do both, > >> >it can differentiate the authentication process by using different > >> >client identifiers in each. Therefore PAA can demultiplex the > >> >authentication request to the right backend. > >> > > >> >So, running PANA twice between the PaC and the same PAA maybe one > >> >approach. Each time PaC can use a different set of > >credentials. If the > >> >same credentials are used, then we need something else in > >the process > >> >to indicate which one is for NAP authentication vs for ISP > >> >authentication. > >> > > >> >When two different set of credentials are used, if PaC uses the same > >> >DI, this might be an issue. Normally they would appear as > >two separate > >> >clients to the PAA, but since the network is aware of this > >> >dual-authentication > >> >scheme, and the requests are coming from the same circuit, > >maybe this > >> >can be handled. And than, how will these DIs be used with service > >> >provisioning, after each authentication? Is EP still co-located > >> >with BAS here? How should the NAP authentication update EP, and ISP > >> >authentication update EP? These are general questions about > >the model > >> >you are describing.. > >> > > >> > > >> >alper > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> >----- Original Message ----- > >> >From: MORAND Lionel FTRD/DAC/ISS > >> >To: pana@research.telcordia.com ; Yoshihiro Ohba ; > >> >basavaraj.Patil@nokia.com > >> >; Alper E. YEGIN > >> >Sent: Monday, December 09, 2002 5:59 AM > >> >Subject: About the NAP/ISP distinction in the > >usage-scenarios draft... > >> > > >> > > >> >Hi folks, > >> > > >> >In the current version of the Usage-Scenario draft, in the > >section 3: > >> >Problem Statement, the distinction between NAP (Network Acces > >> >Provider) and > >> >ISP (Internet Service Provider) is pointing out. > >> > > >> >[...An important aspect of an authentication protocol is > >the ability to > >> >provide dynamic service provider selection to the clients. > >> >Regardless of > >> >their network access provider (NAP), clients should be able to > >> >select an > >> >Internet access provider (ISP) of their choice. This is > >> >usually achieved by > >> >clients presenting an identifier which carries domain > >> >information during the > >> >authentication process. ] > >> > > >> >This distinction is particularly true in the case of DSL > >> >networks where NAP > >> >and ISP are often two different players. Besides traditional > >> >"package" offer > >> >(access + Internet provided by the ISP), NAP are able to > >> >provide broadband > >> >access services directly to the user, regardless of the ISP > >> >selected by the > >> >user. Moreover, different access network configurations may be > >> >provide to an > >> >xDSL client, based on the access service subscribed to the > >> >NAP. We could > >> >also imagine the provision of some local services in the > >> >short/medium term. > >> > > >> >In order to provide such a "customized" service, the NAP needs to > >> >identify/authenticate the user that logs on to the access > >network. This > >> >authentication is independent from the authentication achieved > >> >by the ISP > >> >and so not necessarily based on the same user credentials. > >> >This induces a > >> >requirement for two levels of authentication: one at the NAP > >> >level, one at > >> >the ISP level. I think that this requirement is not only > >> >restricted to xDSL > >> >network and be generalized on the contrary. > >> > > >> >For the time being, if PPP is used to carry user information for ISP > >> >authentication, NAP identification is mainly based on > >> >information on the > >> >physical link used for the connection (phone line number, ATM > >> >link, etc.) > >> >and not according to the user using the connection. So it is > >> >not possible to > >> >distinguish two consecutive users using the same link and > >the network > >> >configuration is only based on the service subscribed for the > >> >access link. > >> > > >> >and now I wonder: > >> >How the PANA protocol could fulfil such a requirement on two > >> >authentication > >> >levels (NAP, ISP)? > >> >What would be the consequences on the general PANA requirements? > >> >Would it be useful to include/precise this scenario be in > >the current > >> >usage-scenarios draft? > >> >Any comment/reaction from the mailing list? > >> > > >> >Lionel. > >> > > >> > > >> > > > > > > From pana-request@research.telcordia.com Fri Jan 10 19:35:58 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20936 for ; Fri, 10 Jan 2003 19:35:58 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0B0aNYA007593; Fri, 10 Jan 2003 19:36:23 -0500 (EST) Resent-Date: Fri, 10 Jan 2003 19:36:23 -0500 (EST) Old-Return-Path: Date: Fri, 10 Jan 2003 19:36:15 -0500 To: "Alper E. YEGIN" Cc: MORAND Lionel FTRD/DAC/ISS , Yoshihiro Ohba , basavaraj.Patil@nokia.com, pana@research.telcordia.com Subject: Re: About the NAP/ISP distinction in the usage-scenarios draft... Message-ID: <20030111003615.GC5095@catfish> Mail-Followup-To: "Alper E. YEGIN" , MORAND Lionel FTRD/DAC/ISS , Yoshihiro Ohba , basavaraj.Patil@nokia.com, pana@research.telcordia.com References: <00a301c2b8fa$01dcfd70$096015ac@AlperVAIO> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <00a301c2b8fa$01dcfd70$096015ac@AlperVAIO> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20021213(IM143) Lines: 59 X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Lionel and Alper, On Fri, Jan 10, 2003 at 02:45:39PM -0800, Alper E. YEGIN wrote: > > Hi Lionel, > > One way to achieve this scenario is to: > - let a user have two identifiers. E.g.: user1@NAP.com, and user1@ISP.com > - Single PAA co-located with the BAS (broadband access server). > - PaC either performs single PANA authentication in which two > subsequent authentication methods are executed, one with each PaC > identifier; or it performs one PANA authentication after another, again > each with different PaC identifier. > - One set of filters should be set on the EP, which will be a product > of the successful authentication methods. > > If two PANA authentications take place, then PAA should be able > to associate both with the same entity. Note that they would have > different PaC identifier, but since they are coming from the same > device (circuit id) in particular order with close proximity, this > is possible. In the case of two PANA authentications, it seems that there is an assumption that the client uses the same username part (i.e., "user1" in the above example) of the two identifiers. If this is not the case (I think NAP and ISP identifiers can be independently assigned), how can the PAA tell whether different identifiers are used by the same client or or by different clients? Note that the device ID may be spoofed or may be re-assigned to other device before the second PANA authentication occurs. On the other hand, if we use single PANA authentication with two subsequent authentication methods, the two identifiers are associated within the single PANA authentication, so the two identifiers can be independently assigned. However, a PaC may not be able to know the authentication result of each method (this could happen in EAP), (though it can know the final authentication result of the single EAP sequence), and someone might not feel convenient about this restriction. Fortunately, there is another usage. That is, running two EAP sequences in a single PANA authentication, i.e., one EAP method is performed in each EAP sequence in order to generate Success/Failure message per each method. Note that PANA over TLS works with this usage. > > One change needed on the current set of assumptions and requirements > would be to relax one2one mapping between PaC and device identifiers. I don't think we should relax the requirement for the above reason. > > Can anyone think of other ways to implement this scenario? > > alper > Yoshihiro Ohba From pana-request@research.telcordia.com Fri Jan 10 20:13:19 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21832 for ; Fri, 10 Jan 2003 20:13:18 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0B1DPl0009203; Fri, 10 Jan 2003 20:13:25 -0500 (EST) Resent-Date: Fri, 10 Jan 2003 20:13:25 -0500 (EST) Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: About the NAP/ISP distinction in the usage-scenarios draft... Date: Fri, 10 Jan 2003 17:12:46 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6EAB6FC1@TNEXVS02.tahoenetworks.com> Thread-Topic: About the NAP/ISP distinction in the usage-scenarios draft... Thread-Index: AcK4/aK3r5G/1cJcT8KIChtxnsyJxwAEHxKg From: "Mohan Parthasarathy" To: "Alper E. YEGIN" , "MORAND Lionel FTRD/DAC/ISS" , "Yoshihiro Ohba" , Cc: X-OriginalArrivalTime: 11 Jan 2003 01:12:46.0894 (UTC) FILETIME=[8D2BE4E0:01C2B90E] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA21832 > > One way to achieve this scenario is to: > - let a user have two identifiers. E.g.: user1@NAP.com, and > user1@ISP.com > - Single PAA co-located with the BAS (broadband access server). > - PaC either performs single PANA authentication in which two > subsequent authentication methods are executed, one with each PaC > identifier; or it performs one PANA authentication after > another, again > each with different PaC identifier. > - One set of filters should be set on the EP, which will be a product > of the successful authentication methods. > Why is this required to setup filters in one set ? > If two PANA authentications take place, then PAA should be able > to associate both with the same entity. Note that they would have > different PaC identifier, but since they are coming from the same > device (circuit id) in particular order with close proximity, this > is possible. > Why aren't these two authentications independent of one another i.e why do we have to link them together ? -mohan > One change needed on the current set of assumptions and requirements > would be to relax one2one mapping between PaC and device identifiers. > > Can anyone think of other ways to implement this scenario? > > alper > > > > > > > > > ----- Original Message ----- > From: "MORAND Lionel FTRD/DAC/ISS" > > To: "Alper E. YEGIN" ; "Yoshihiro Ohba" > ; > Cc: > Sent: Friday, January 10, 2003 11:30 AM > Subject: RE: About the NAP/ISP distinction in the > usage-scenarios draft... > > > > Hi Alper and Happy new Year to the PANA folks! > > > > I will try (with some delay) to answer to your request > using a suitable > scenario. > > > > One basic objective of multiple-level authentication could > be to allow the > NAP to distinguish different users and to be able then to > provide distinct > network configurations to those clients (with different > classes of Service > (CoS) for instance). > > > > On this basis, two different users may subscribe to: > > > > - two different CoS offered by the NAP, > > - two different ISPs, > > > > and they may be able to use the same access link but at > different time (in > this example). > > > > If one user would like to browse the Web, the client will be first > authenticated by the NAP in order to determine what Cos the client has > subscribed to. Once authenticated by the NAP, the client will be > authenticated by his/her ISP as usual. > > > > - If the first authentication failed (but the second one > succeded), a > per-default network configuration could be selected for the current > connection or the NAP could decide to reject the access request. > > > > - If the second authentication failed (but the first one > succeded), the > client will not be allowed to browse the Web but some local services > (provided by the NAP) could be nevertheless offered. > > > > Several other combinations are also possible. > > > > Does this scenario answer correctly to your questions, Alper? > > > > > > >-----Message d'origine----- > > >De : Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > > >Envoyé : samedi 14 décembre 2002 00:19 > > >Ą : MORAND Lionel FTRD/DAC/ISS; Yoshihiro Ohba; > > >basavaraj.Patil@nokia.com > > >Cc : pana@research.telcordia.com > > >Objet : Re: About the NAP/ISP distinction in the usage-scenarios > > >draft... > > > > > > > > > > > >Lionel, > > > > > >I think it'd be useful to understand the semantics of each > > >authentication, > > >and the expected actions taken by the client and the network > > >after each one > > >is > > >completed. > > > > > >For example: > > >1- what does it mean to the NAP when a client gets > authenticated? What > > >actions > > >should be taken (e.g., how are the filters updated, where are > > >they updated, > > >etc.)? > > > > > >2- What can or cannot the client do after this first round of > > >authentication? > > > > > >3- same question as 1, but for ISP authentication. > > > > > >4- same question as 2, but for ISP authentication. > > > > > > > > >alper > > > > > > > > > > > >> Hi Alper, > > >> > > >> I think that, in the described scenario, the principle of > > >two successive > > >authentications (one per AAA backend) may appear obvious. However, > > >considering a single PAA handling the both authentication > > >procedures, there > > >is an issue concerning the use of the DI. > > >> > > >> The most intuitive idea is to reuse the same DI for both > > >authentications > > >and to use different sets of credentials > > >(identifier,authenticator) supplied > > >by the client. But according to the current draft on the PANA > > >requirements > > >and as Yoshihiro said, it seems that it should not be possible. > > >> > > >> On the other hand, the alternative would be to use different > > >DIs but the > > >PAA would create distinct bindings, and so distinct instances > > >in this case, > > >that would make the network access control more complex. > > >> > > >> A simple solution here could be to allow in the PANA > requirements the > > >association of one single DI with different PaCs, but this may > > >raise up some > > >other previous/new concerns. > > >> > > >> What do you think about this? > > >> > > >> Best Regards, > > >> > > >> Lionel > > >> > > >> > > >> >-----Message d'origine----- > > >> >De : Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > > >> >Envoyé : jeudi 12 décembre 2002 00:16 > > >> >Ą : MORAND Lionel FTRD/DAC/ISS; > > >pana@research.telcordia.com; Yoshihiro > > >> >Ohba; basavaraj.Patil@nokia.com > > >> >Objet : Re: About the NAP/ISP distinction in the usage-scenarios > > >> >draft... > > >> > > > >> > > > >> > > > >> >Hello Lionel, > > >> > > > >> >Thanks for bringing this scenario up. > > >> > > > >> >In the case both NAP and ISP requires their own independent > > >> >client authentication, I presume we can still envision both > > >> >using the same PAA on the BAS (broadband access > server). Does this > > >> >makes sense? > > >> > > > >> >For NAP authentication, PAA consults with AAA backend in NAP > > >> >network. For ISP authentication, PAA consults with AAA backend > > >> >in ISP network. > > >> > > > >> >Somehow the client needs to know (or discover??) that it has > > >> >to go through the authentication twice. Discovery might > be tricky > > >> >because something has to tell the client that the second one > > >> >is meant for the ISP, etc.... If the client knows it > has to do both, > > >> >it can differentiate the authentication process by > using different > > >> >client identifiers in each. Therefore PAA can demultiplex the > > >> >authentication request to the right backend. > > >> > > > >> >So, running PANA twice between the PaC and the same PAA > maybe one > > >> >approach. Each time PaC can use a different set of > > >credentials. If the > > >> >same credentials are used, then we need something else in > > >the process > > >> >to indicate which one is for NAP authentication vs for ISP > > >> >authentication. > > >> > > > >> >When two different set of credentials are used, if PaC > uses the same > > >> >DI, this might be an issue. Normally they would appear as > > >two separate > > >> >clients to the PAA, but since the network is aware of this > > >> >dual-authentication > > >> >scheme, and the requests are coming from the same circuit, > > >maybe this > > >> >can be handled. And than, how will these DIs be used > with service > > >> >provisioning, after each authentication? Is EP still co-located > > >> >with BAS here? How should the NAP authentication update > EP, and ISP > > >> >authentication update EP? These are general questions about > > >the model > > >> >you are describing.. > > >> > > > >> > > > >> >alper > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> >----- Original Message ----- > > >> >From: MORAND Lionel FTRD/DAC/ISS > > >> >To: pana@research.telcordia.com ; Yoshihiro Ohba ; > > >> >basavaraj.Patil@nokia.com > > >> >; Alper E. YEGIN > > >> >Sent: Monday, December 09, 2002 5:59 AM > > >> >Subject: About the NAP/ISP distinction in the > > >usage-scenarios draft... > > >> > > > >> > > > >> >Hi folks, > > >> > > > >> >In the current version of the Usage-Scenario draft, in the > > >section 3: > > >> >Problem Statement, the distinction between NAP (Network Acces > > >> >Provider) and > > >> >ISP (Internet Service Provider) is pointing out. > > >> > > > >> >[...An important aspect of an authentication protocol is > > >the ability to > > >> >provide dynamic service provider selection to the clients. > > >> >Regardless of > > >> >their network access provider (NAP), clients should be able to > > >> >select an > > >> >Internet access provider (ISP) of their choice. This is > > >> >usually achieved by > > >> >clients presenting an identifier which carries domain > > >> >information during the > > >> >authentication process. ] > > >> > > > >> >This distinction is particularly true in the case of DSL > > >> >networks where NAP > > >> >and ISP are often two different players. Besides traditional > > >> >"package" offer > > >> >(access + Internet provided by the ISP), NAP are able to > > >> >provide broadband > > >> >access services directly to the user, regardless of the ISP > > >> >selected by the > > >> >user. Moreover, different access network configurations may be > > >> >provide to an > > >> >xDSL client, based on the access service subscribed to the > > >> >NAP. We could > > >> >also imagine the provision of some local services in the > > >> >short/medium term. > > >> > > > >> >In order to provide such a "customized" service, the > NAP needs to > > >> >identify/authenticate the user that logs on to the access > > >network. This > > >> >authentication is independent from the authentication achieved > > >> >by the ISP > > >> >and so not necessarily based on the same user credentials. > > >> >This induces a > > >> >requirement for two levels of authentication: one at the NAP > > >> >level, one at > > >> >the ISP level. I think that this requirement is not only > > >> >restricted to xDSL > > >> >network and be generalized on the contrary. > > >> > > > >> >For the time being, if PPP is used to carry user > information for ISP > > >> >authentication, NAP identification is mainly based on > > >> >information on the > > >> >physical link used for the connection (phone line number, ATM > > >> >link, etc.) > > >> >and not according to the user using the connection. So it is > > >> >not possible to > > >> >distinguish two consecutive users using the same link and > > >the network > > >> >configuration is only based on the service subscribed for the > > >> >access link. > > >> > > > >> >and now I wonder: > > >> >How the PANA protocol could fulfil such a requirement on two > > >> >authentication > > >> >levels (NAP, ISP)? > > >> >What would be the consequences on the general PANA requirements? > > >> >Would it be useful to include/precise this scenario be in > > >the current > > >> >usage-scenarios draft? > > >> >Any comment/reaction from the mailing list? > > >> > > > >> >Lionel. > > >> > > > >> > > > >> > > > > > > > > > > > > From pana-request@research.telcordia.com Fri Jan 10 20:27:19 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22008 for ; Fri, 10 Jan 2003 20:27:18 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0B1Ras1010210; Fri, 10 Jan 2003 20:27:36 -0500 (EST) Resent-Date: Fri, 10 Jan 2003 20:27:36 -0500 (EST) Old-Return-Path: Message-ID: <029d01c2b910$4d4ca880$096015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Mohan Parthasarathy" , "MORAND Lionel FTRD/DAC/ISS" , "Yoshihiro Ohba" , Cc: References: <416B5AF360DED54088DAD3CA8BFBEA6EAB6FC1@TNEXVS02.tahoenetworks.com> Subject: Re: About the NAP/ISP distinction in the usage-scenarios draft... Date: Fri, 10 Jan 2003 17:25:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit > > One way to achieve this scenario is to: > > - let a user have two identifiers. E.g.: user1@NAP.com, and > > user1@ISP.com > > - Single PAA co-located with the BAS (broadband access server). > > - PaC either performs single PANA authentication in which two > > subsequent authentication methods are executed, one with each PaC > > identifier; or it performs one PANA authentication after > > another, again > > each with different PaC identifier. > > - One set of filters should be set on the EP, which will be a product > > of the successful authentication methods. > > > Why is this required to setup filters in one set ? > > > If two PANA authentications take place, then PAA should be able > > to associate both with the same entity. Note that they would have > > different PaC identifier, but since they are coming from the same > > device (circuit id) in particular order with close proximity, this > > is possible. > > > Why aren't these two authentications independent of one another i.e > why do we have to link them together ? The two authentications should take place independently. But at the end they are used to authorize some (combination) service to a single device. Access network should be able to look at an incoming packet and be able to identify a filtering rule to apply without any ambiguity. The filtering rules might be result of one or more authentications, that's fine. If a device is going through multiple authentications with the access network, we need to know how to treat the result of each one. In the case Lionel is describing, the final service authorization is a combination of each authentication/authorization. In another (simpler) case the latest authentication/authorization may override the previous one. (as if the client is either getting service associated with user1@NAP or user1@ISP) alper > > -mohan > > > One change needed on the current set of assumptions and requirements > > would be to relax one2one mapping between PaC and device identifiers. > > > > Can anyone think of other ways to implement this scenario? > > > > alper > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > From: "MORAND Lionel FTRD/DAC/ISS" > > > > To: "Alper E. YEGIN" ; "Yoshihiro Ohba" > > ; > > Cc: > > Sent: Friday, January 10, 2003 11:30 AM > > Subject: RE: About the NAP/ISP distinction in the > > usage-scenarios draft... > > > > > > > Hi Alper and Happy new Year to the PANA folks! > > > > > > I will try (with some delay) to answer to your request > > using a suitable > > scenario. > > > > > > One basic objective of multiple-level authentication could > > be to allow the > > NAP to distinguish different users and to be able then to > > provide distinct > > network configurations to those clients (with different > > classes of Service > > (CoS) for instance). > > > > > > On this basis, two different users may subscribe to: > > > > > > - two different CoS offered by the NAP, > > > - two different ISPs, > > > > > > and they may be able to use the same access link but at > > different time (in > > this example). > > > > > > If one user would like to browse the Web, the client will be first > > authenticated by the NAP in order to determine what Cos the client has > > subscribed to. Once authenticated by the NAP, the client will be > > authenticated by his/her ISP as usual. > > > > > > - If the first authentication failed (but the second one > > succeded), a > > per-default network configuration could be selected for the current > > connection or the NAP could decide to reject the access request. > > > > > > - If the second authentication failed (but the first one > > succeded), the > > client will not be allowed to browse the Web but some local services > > (provided by the NAP) could be nevertheless offered. > > > > > > Several other combinations are also possible. > > > > > > Does this scenario answer correctly to your questions, Alper? > > > > > > > > > >-----Message d'origine----- > > > >De : Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > > > >Envoyé : samedi 14 décembre 2002 00:19 > > > >Ą : MORAND Lionel FTRD/DAC/ISS; Yoshihiro Ohba; > > > >basavaraj.Patil@nokia.com > > > >Cc : pana@research.telcordia.com > > > >Objet : Re: About the NAP/ISP distinction in the usage-scenarios > > > >draft... > > > > > > > > > > > > > > > >Lionel, > > > > > > > >I think it'd be useful to understand the semantics of each > > > >authentication, > > > >and the expected actions taken by the client and the network > > > >after each one > > > >is > > > >completed. > > > > > > > >For example: > > > >1- what does it mean to the NAP when a client gets > > authenticated? What > > > >actions > > > >should be taken (e.g., how are the filters updated, where are > > > >they updated, > > > >etc.)? > > > > > > > >2- What can or cannot the client do after this first round of > > > >authentication? > > > > > > > >3- same question as 1, but for ISP authentication. > > > > > > > >4- same question as 2, but for ISP authentication. > > > > > > > > > > > >alper > > > > > > > > > > > > > > > >> Hi Alper, > > > >> > > > >> I think that, in the described scenario, the principle of > > > >two successive > > > >authentications (one per AAA backend) may appear obvious. However, > > > >considering a single PAA handling the both authentication > > > >procedures, there > > > >is an issue concerning the use of the DI. > > > >> > > > >> The most intuitive idea is to reuse the same DI for both > > > >authentications > > > >and to use different sets of credentials > > > >(identifier,authenticator) supplied > > > >by the client. But according to the current draft on the PANA > > > >requirements > > > >and as Yoshihiro said, it seems that it should not be possible. > > > >> > > > >> On the other hand, the alternative would be to use different > > > >DIs but the > > > >PAA would create distinct bindings, and so distinct instances > > > >in this case, > > > >that would make the network access control more complex. > > > >> > > > >> A simple solution here could be to allow in the PANA > > requirements the > > > >association of one single DI with different PaCs, but this may > > > >raise up some > > > >other previous/new concerns. > > > >> > > > >> What do you think about this? > > > >> > > > >> Best Regards, > > > >> > > > >> Lionel > > > >> > > > >> > > > >> >-----Message d'origine----- > > > >> >De : Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > > > >> >Envoyé : jeudi 12 décembre 2002 00:16 > > > >> >Ą : MORAND Lionel FTRD/DAC/ISS; > > > >pana@research.telcordia.com; Yoshihiro > > > >> >Ohba; basavaraj.Patil@nokia.com > > > >> >Objet : Re: About the NAP/ISP distinction in the usage-scenarios > > > >> >draft... > > > >> > > > > >> > > > > >> > > > > >> >Hello Lionel, > > > >> > > > > >> >Thanks for bringing this scenario up. > > > >> > > > > >> >In the case both NAP and ISP requires their own independent > > > >> >client authentication, I presume we can still envision both > > > >> >using the same PAA on the BAS (broadband access > > server). Does this > > > >> >makes sense? > > > >> > > > > >> >For NAP authentication, PAA consults with AAA backend in NAP > > > >> >network. For ISP authentication, PAA consults with AAA backend > > > >> >in ISP network. > > > >> > > > > >> >Somehow the client needs to know (or discover??) that it has > > > >> >to go through the authentication twice. Discovery might > > be tricky > > > >> >because something has to tell the client that the second one > > > >> >is meant for the ISP, etc.... If the client knows it > > has to do both, > > > >> >it can differentiate the authentication process by > > using different > > > >> >client identifiers in each. Therefore PAA can demultiplex the > > > >> >authentication request to the right backend. > > > >> > > > > >> >So, running PANA twice between the PaC and the same PAA > > maybe one > > > >> >approach. Each time PaC can use a different set of > > > >credentials. If the > > > >> >same credentials are used, then we need something else in > > > >the process > > > >> >to indicate which one is for NAP authentication vs for ISP > > > >> >authentication. > > > >> > > > > >> >When two different set of credentials are used, if PaC > > uses the same > > > >> >DI, this might be an issue. Normally they would appear as > > > >two separate > > > >> >clients to the PAA, but since the network is aware of this > > > >> >dual-authentication > > > >> >scheme, and the requests are coming from the same circuit, > > > >maybe this > > > >> >can be handled. And than, how will these DIs be used > > with service > > > >> >provisioning, after each authentication? Is EP still co-located > > > >> >with BAS here? How should the NAP authentication update > > EP, and ISP > > > >> >authentication update EP? These are general questions about > > > >the model > > > >> >you are describing.. > > > >> > > > > >> > > > > >> >alper > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> >----- Original Message ----- > > > >> >From: MORAND Lionel FTRD/DAC/ISS > > > >> >To: pana@research.telcordia.com ; Yoshihiro Ohba ; > > > >> >basavaraj.Patil@nokia.com > > > >> >; Alper E. YEGIN > > > >> >Sent: Monday, December 09, 2002 5:59 AM > > > >> >Subject: About the NAP/ISP distinction in the > > > >usage-scenarios draft... > > > >> > > > > >> > > > > >> >Hi folks, > > > >> > > > > >> >In the current version of the Usage-Scenario draft, in the > > > >section 3: > > > >> >Problem Statement, the distinction between NAP (Network Acces > > > >> >Provider) and > > > >> >ISP (Internet Service Provider) is pointing out. > > > >> > > > > >> >[...An important aspect of an authentication protocol is > > > >the ability to > > > >> >provide dynamic service provider selection to the clients. > > > >> >Regardless of > > > >> >their network access provider (NAP), clients should be able to > > > >> >select an > > > >> >Internet access provider (ISP) of their choice. This is > > > >> >usually achieved by > > > >> >clients presenting an identifier which carries domain > > > >> >information during the > > > >> >authentication process. ] > > > >> > > > > >> >This distinction is particularly true in the case of DSL > > > >> >networks where NAP > > > >> >and ISP are often two different players. Besides traditional > > > >> >"package" offer > > > >> >(access + Internet provided by the ISP), NAP are able to > > > >> >provide broadband > > > >> >access services directly to the user, regardless of the ISP > > > >> >selected by the > > > >> >user. Moreover, different access network configurations may be > > > >> >provide to an > > > >> >xDSL client, based on the access service subscribed to the > > > >> >NAP. We could > > > >> >also imagine the provision of some local services in the > > > >> >short/medium term. > > > >> > > > > >> >In order to provide such a "customized" service, the > > NAP needs to > > > >> >identify/authenticate the user that logs on to the access > > > >network. This > > > >> >authentication is independent from the authentication achieved > > > >> >by the ISP > > > >> >and so not necessarily based on the same user credentials. > > > >> >This induces a > > > >> >requirement for two levels of authentication: one at the NAP > > > >> >level, one at > > > >> >the ISP level. I think that this requirement is not only > > > >> >restricted to xDSL > > > >> >network and be generalized on the contrary. > > > >> > > > > >> >For the time being, if PPP is used to carry user > > information for ISP > > > >> >authentication, NAP identification is mainly based on > > > >> >information on the > > > >> >physical link used for the connection (phone line number, ATM > > > >> >link, etc.) > > > >> >and not according to the user using the connection. So it is > > > >> >not possible to > > > >> >distinguish two consecutive users using the same link and > > > >the network > > > >> >configuration is only based on the service subscribed for the > > > >> >access link. > > > >> > > > > >> >and now I wonder: > > > >> >How the PANA protocol could fulfil such a requirement on two > > > >> >authentication > > > >> >levels (NAP, ISP)? > > > >> >What would be the consequences on the general PANA requirements? > > > >> >Would it be useful to include/precise this scenario be in > > > >the current > > > >> >usage-scenarios draft? > > > >> >Any comment/reaction from the mailing list? > > > >> > > > > >> >Lionel. > > > >> > > > > >> > > > > >> > > > > > > > > > > > > > > > > > > > From pana-request@research.telcordia.com Mon Jan 13 04:48:52 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06017 for ; Mon, 13 Jan 2003 04:48:36 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0D9mapX019534; Mon, 13 Jan 2003 04:48:36 -0500 (EST) Resent-Date: Mon, 13 Jan 2003 04:48:36 -0500 (EST) Old-Return-Path: content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: About the NAP/ISP distinction in the usage-scenarios draft... Date: Mon, 13 Jan 2003 10:46:55 +0100 Message-ID: Thread-Topic: About the NAP/ISP distinction in the usage-scenarios draft... Thread-Index: AcK4+kC3aI/MvMmfRBa+B+Y7Rz6DHQB7g3mw From: "MORAND Lionel FTRD/DAC/ISS" To: "Alper E. YEGIN" , "Yoshihiro Ohba" , Cc: X-OriginalArrivalTime: 13 Jan 2003 09:46:56.0640 (UTC) FILETIME=[B5E11000:01C2BAE8] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA06017 Hi Alper, It was actually one of my previous conclusions. But maybe there are other points of view... >-----Message d'origine----- >De : Alper E. YEGIN [mailto:alper@docomolabs-usa.com] >Envoyé : vendredi 10 janvier 2003 23:46 >Ą : MORAND Lionel FTRD/DAC/ISS; Yoshihiro Ohba; >basavaraj.Patil@nokia.com >Cc : pana@research.telcordia.com >Objet : Re: About the NAP/ISP distinction in the usage-scenarios >draft... > > > >Hi Lionel, > >One way to achieve this scenario is to: >- let a user have two identifiers. E.g.: user1@NAP.com, and >user1@ISP.com >- Single PAA co-located with the BAS (broadband access server). >- PaC either performs single PANA authentication in which two > subsequent authentication methods are executed, one with each PaC > identifier; or it performs one PANA authentication after >another, again > each with different PaC identifier. >- One set of filters should be set on the EP, which will be a product > of the successful authentication methods. > >If two PANA authentications take place, then PAA should be able >to associate both with the same entity. Note that they would have >different PaC identifier, but since they are coming from the same >device (circuit id) in particular order with close proximity, this >is possible. > >One change needed on the current set of assumptions and requirements >would be to relax one2one mapping between PaC and device identifiers. > >Can anyone think of other ways to implement this scenario? > >alper > > > > > > > > >----- Original Message ----- >From: "MORAND Lionel FTRD/DAC/ISS" >To: "Alper E. YEGIN" ; "Yoshihiro Ohba" >; >Cc: >Sent: Friday, January 10, 2003 11:30 AM >Subject: RE: About the NAP/ISP distinction in the >usage-scenarios draft... > > >> Hi Alper and Happy new Year to the PANA folks! >> >> I will try (with some delay) to answer to your request using >a suitable >scenario. >> >> One basic objective of multiple-level authentication could >be to allow the >NAP to distinguish different users and to be able then to >provide distinct >network configurations to those clients (with different >classes of Service >(CoS) for instance). >> >> On this basis, two different users may subscribe to: >> >> - two different CoS offered by the NAP, >> - two different ISPs, >> >> and they may be able to use the same access link but at >different time (in >this example). >> >> If one user would like to browse the Web, the client will be first >authenticated by the NAP in order to determine what Cos the client has >subscribed to. Once authenticated by the NAP, the client will be >authenticated by his/her ISP as usual. >> >> - If the first authentication failed (but the second one succeded), a >per-default network configuration could be selected for the current >connection or the NAP could decide to reject the access request. >> >> - If the second authentication failed (but the first one >succeded), the >client will not be allowed to browse the Web but some local services >(provided by the NAP) could be nevertheless offered. >> >> Several other combinations are also possible. >> >> Does this scenario answer correctly to your questions, Alper? >> >> >> >-----Message d'origine----- >> >De : Alper E. YEGIN [mailto:alper@docomolabs-usa.com] >> >Envoyé : samedi 14 décembre 2002 00:19 >> >Ą : MORAND Lionel FTRD/DAC/ISS; Yoshihiro Ohba; >> >basavaraj.Patil@nokia.com >> >Cc : pana@research.telcordia.com >> >Objet : Re: About the NAP/ISP distinction in the usage-scenarios >> >draft... >> > >> > >> > >> >Lionel, >> > >> >I think it'd be useful to understand the semantics of each >> >authentication, >> >and the expected actions taken by the client and the network >> >after each one >> >is >> >completed. >> > >> >For example: >> >1- what does it mean to the NAP when a client gets >authenticated? What >> >actions >> >should be taken (e.g., how are the filters updated, where are >> >they updated, >> >etc.)? >> > >> >2- What can or cannot the client do after this first round of >> >authentication? >> > >> >3- same question as 1, but for ISP authentication. >> > >> >4- same question as 2, but for ISP authentication. >> > >> > >> >alper >> > >> > >> > >> >> Hi Alper, >> >> >> >> I think that, in the described scenario, the principle of >> >two successive >> >authentications (one per AAA backend) may appear obvious. However, >> >considering a single PAA handling the both authentication >> >procedures, there >> >is an issue concerning the use of the DI. >> >> >> >> The most intuitive idea is to reuse the same DI for both >> >authentications >> >and to use different sets of credentials >> >(identifier,authenticator) supplied >> >by the client. But according to the current draft on the PANA >> >requirements >> >and as Yoshihiro said, it seems that it should not be possible. >> >> >> >> On the other hand, the alternative would be to use different >> >DIs but the >> >PAA would create distinct bindings, and so distinct instances >> >in this case, >> >that would make the network access control more complex. >> >> >> >> A simple solution here could be to allow in the PANA >requirements the >> >association of one single DI with different PaCs, but this may >> >raise up some >> >other previous/new concerns. >> >> >> >> What do you think about this? >> >> >> >> Best Regards, >> >> >> >> Lionel >> >> >> >> >> >> >-----Message d'origine----- >> >> >De : Alper E. YEGIN [mailto:alper@docomolabs-usa.com] >> >> >Envoyé : jeudi 12 décembre 2002 00:16 >> >> >Ą : MORAND Lionel FTRD/DAC/ISS; >> >pana@research.telcordia.com; Yoshihiro >> >> >Ohba; basavaraj.Patil@nokia.com >> >> >Objet : Re: About the NAP/ISP distinction in the usage-scenarios >> >> >draft... >> >> > >> >> > >> >> > >> >> >Hello Lionel, >> >> > >> >> >Thanks for bringing this scenario up. >> >> > >> >> >In the case both NAP and ISP requires their own independent >> >> >client authentication, I presume we can still envision both >> >> >using the same PAA on the BAS (broadband access server). >Does this >> >> >makes sense? >> >> > >> >> >For NAP authentication, PAA consults with AAA backend in NAP >> >> >network. For ISP authentication, PAA consults with AAA backend >> >> >in ISP network. >> >> > >> >> >Somehow the client needs to know (or discover??) that it has >> >> >to go through the authentication twice. Discovery might be tricky >> >> >because something has to tell the client that the second one >> >> >is meant for the ISP, etc.... If the client knows it has >to do both, >> >> >it can differentiate the authentication process by using >different >> >> >client identifiers in each. Therefore PAA can demultiplex the >> >> >authentication request to the right backend. >> >> > >> >> >So, running PANA twice between the PaC and the same PAA maybe one >> >> >approach. Each time PaC can use a different set of >> >credentials. If the >> >> >same credentials are used, then we need something else in >> >the process >> >> >to indicate which one is for NAP authentication vs for ISP >> >> >authentication. >> >> > >> >> >When two different set of credentials are used, if PaC >uses the same >> >> >DI, this might be an issue. Normally they would appear as >> >two separate >> >> >clients to the PAA, but since the network is aware of this >> >> >dual-authentication >> >> >scheme, and the requests are coming from the same circuit, >> >maybe this >> >> >can be handled. And than, how will these DIs be used with service >> >> >provisioning, after each authentication? Is EP still co-located >> >> >with BAS here? How should the NAP authentication update >EP, and ISP >> >> >authentication update EP? These are general questions about >> >the model >> >> >you are describing.. >> >> > >> >> > >> >> >alper >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> >----- Original Message ----- >> >> >From: MORAND Lionel FTRD/DAC/ISS >> >> >To: pana@research.telcordia.com ; Yoshihiro Ohba ; >> >> >basavaraj.Patil@nokia.com >> >> >; Alper E. YEGIN >> >> >Sent: Monday, December 09, 2002 5:59 AM >> >> >Subject: About the NAP/ISP distinction in the >> >usage-scenarios draft... >> >> > >> >> > >> >> >Hi folks, >> >> > >> >> >In the current version of the Usage-Scenario draft, in the >> >section 3: >> >> >Problem Statement, the distinction between NAP (Network Acces >> >> >Provider) and >> >> >ISP (Internet Service Provider) is pointing out. >> >> > >> >> >[...An important aspect of an authentication protocol is >> >the ability to >> >> >provide dynamic service provider selection to the clients. >> >> >Regardless of >> >> >their network access provider (NAP), clients should be able to >> >> >select an >> >> >Internet access provider (ISP) of their choice. This is >> >> >usually achieved by >> >> >clients presenting an identifier which carries domain >> >> >information during the >> >> >authentication process. ] >> >> > >> >> >This distinction is particularly true in the case of DSL >> >> >networks where NAP >> >> >and ISP are often two different players. Besides traditional >> >> >"package" offer >> >> >(access + Internet provided by the ISP), NAP are able to >> >> >provide broadband >> >> >access services directly to the user, regardless of the ISP >> >> >selected by the >> >> >user. Moreover, different access network configurations may be >> >> >provide to an >> >> >xDSL client, based on the access service subscribed to the >> >> >NAP. We could >> >> >also imagine the provision of some local services in the >> >> >short/medium term. >> >> > >> >> >In order to provide such a "customized" service, the NAP needs to >> >> >identify/authenticate the user that logs on to the access >> >network. This >> >> >authentication is independent from the authentication achieved >> >> >by the ISP >> >> >and so not necessarily based on the same user credentials. >> >> >This induces a >> >> >requirement for two levels of authentication: one at the NAP >> >> >level, one at >> >> >the ISP level. I think that this requirement is not only >> >> >restricted to xDSL >> >> >network and be generalized on the contrary. >> >> > >> >> >For the time being, if PPP is used to carry user >information for ISP >> >> >authentication, NAP identification is mainly based on >> >> >information on the >> >> >physical link used for the connection (phone line number, ATM >> >> >link, etc.) >> >> >and not according to the user using the connection. So it is >> >> >not possible to >> >> >distinguish two consecutive users using the same link and >> >the network >> >> >configuration is only based on the service subscribed for the >> >> >access link. >> >> > >> >> >and now I wonder: >> >> >How the PANA protocol could fulfil such a requirement on two >> >> >authentication >> >> >levels (NAP, ISP)? >> >> >What would be the consequences on the general PANA requirements? >> >> >Would it be useful to include/precise this scenario be in >> >the current >> >> >usage-scenarios draft? >> >> >Any comment/reaction from the mailing list? >> >> > >> >> >Lionel. >> >> > >> >> > >> >> >> > >> > >> >> > > From pana-request@research.telcordia.com Mon Jan 13 07:22:42 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09337 for ; Mon, 13 Jan 2003 07:22:32 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0DCNNlF002084; Mon, 13 Jan 2003 07:23:23 -0500 (EST) Resent-Date: Mon, 13 Jan 2003 07:23:23 -0500 (EST) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: About the NAP/ISP distinction in the usage-scenarios draft... Date: Mon, 13 Jan 2003 14:23:15 +0200 Message-ID: Thread-Topic: About the NAP/ISP distinction in the usage-scenarios draft... Thread-Index: AcK402yqkmqCHcl1QvWCbJv8VA2FJACKEDmw From: To: , Cc: , , X-OriginalArrivalTime: 13 Jan 2003 12:23:16.0135 (UTC) FILETIME=[8C7E6B70:01C2BAFE] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA09337 > -----Original Message----- > From: ext Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > Sent: 10 January, 2003 20:07 > To: Forsberg Dan (NRC/Helsinki); yohba@tari.toshiba.com > Cc: lionel.morand@rd.francetelecom.com; Patil Basavaraj (NET/Dallas); > pana@research.telcordia.com > Subject: Re: About the NAP/ISP distinction in the usage-scenarios > draft... > > > > Generally speaking, there could be multiple hops between EP > and PaC. So, > why to limit this with a requirement. A more general > requirement could be to > limit the number of hops between PAA and it's related EPs, if > that is really > needed. > > > > There is no requirement regarding the number of hops between > the EP and PaC. > But there is one for between PAA and PaC. The decision was to require > them to be one hop away, because having multiple hops incurs > complexity > which > was not justified by an essential usage scenario. > > alper > This requirement means that a PaC client can't use PANA protocol from an access network (AN) that doesn't support PANA, even if there were networks that support PANA behind the AN :). This is an issue that affects the transition period. Anyway, keeping this requirement prevents walled garden networks. And for me it doesn't make sense, since we are using IP as the transport mechanism. Do you mean the PAA discovery with the incurring complexity? It would be nice to know (maybe I haven't read all the docs, though). HTTP redirect is used for authentication. With this requirement PANA will not be in the same scope. On the second hand in the access networks EAP over Ethernet is pretty strong. So, where is PANA going to be if it doesn't even make it theoretically possible to combine these too.. there are VPNs too. - Dan From pana-request@research.telcordia.com Mon Jan 13 15:13:19 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22438 for ; Mon, 13 Jan 2003 15:13:17 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0DKD58G002694; Mon, 13 Jan 2003 15:13:05 -0500 (EST) Resent-Date: Mon, 13 Jan 2003 15:13:05 -0500 (EST) Old-Return-Path: Message-ID: <018f01c2bb3f$d86ed0b0$096015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Yoshihiro Ohba" Cc: "MORAND Lionel FTRD/DAC/ISS" , "Yoshihiro Ohba" , , References: <00a301c2b8fa$01dcfd70$096015ac@AlperVAIO> <20030111003615.GC5095@catfish> Subject: Re: About the NAP/ISP distinction in the usage-scenarios draft... Date: Mon, 13 Jan 2003 12:10:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hi Yoshihiro, > > One way to achieve this scenario is to: > > - let a user have two identifiers. E.g.: user1@NAP.com, and user1@ISP.com > > - Single PAA co-located with the BAS (broadband access server). > > - PaC either performs single PANA authentication in which two > > subsequent authentication methods are executed, one with each PaC > > identifier; or it performs one PANA authentication after another, again > > each with different PaC identifier. > > - One set of filters should be set on the EP, which will be a product > > of the successful authentication methods. > > > > If two PANA authentications take place, then PAA should be able > > to associate both with the same entity. Note that they would have > > different PaC identifier, but since they are coming from the same > > device (circuit id) in particular order with close proximity, this > > is possible. > > In the case of two PANA authentications, it seems that there is an > assumption that the client uses the same username part (i.e., "user1" > in the above example) of the two identifiers. If this is not the case > (I think NAP and ISP identifiers can be independently assigned), how > can the PAA tell whether different identifiers are used by the same > client or or by different clients? Note that the device ID may be > spoofed or may be re-assigned to other device before the second PANA > authentication occurs. I agree this gets tricky than. Depending on the environment, two subsequent authentication requests may or may not come from the same "client". > > On the other hand, if we use single PANA authentication with two > subsequent authentication methods, the two identifiers are associated > within the single PANA authentication, so the two identifiers can be > independently assigned. However, a PaC may not be able to know the > authentication result of each method (this could happen in EAP), > (though it can know the final authentication result of the single EAP > sequence), and someone might not feel convenient about this > restriction. > > Fortunately, there is another usage. That is, running two EAP > sequences in a single PANA authentication, i.e., one EAP method is > performed in each EAP sequence in order to generate Success/Failure > message per each method. Note that PANA over TLS works with this > usage. Yes, running two independent EAP sequences (each with its own success/failure messages) inside a single PANA sequence is a good idea. but.... > > > > > One change needed on the current set of assumptions and requirements > > would be to relax one2one mapping between PaC and device identifiers. > > I don't think we should relax the requirement for the above reason. ....but your recommended method still doesn't cure the mapping problem between the client ID and the device ID. If we run two EAP sequences with two different client identifiers, PAA will still have two PaC ID that maps to a device ID. alper > > > > > Can anyone think of other ways to implement this scenario? > > > > alper > > > > Yoshihiro Ohba > > From pana-request@research.telcordia.com Mon Jan 13 15:21:20 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22728 for ; Mon, 13 Jan 2003 15:21:15 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0DKMblx003315; Mon, 13 Jan 2003 15:22:37 -0500 (EST) Resent-Date: Mon, 13 Jan 2003 15:22:37 -0500 (EST) Old-Return-Path: Message-ID: <019401c2bb41$38a60d30$096015ac@AlperVAIO> From: "Alper E. YEGIN" To: , Cc: , , References: Subject: Re: About the NAP/ISP distinction in the usage-scenarios draft... Date: Mon, 13 Jan 2003 12:20:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > > There is no requirement regarding the number of hops between > > the EP and PaC. > > But there is one for between PAA and PaC. The decision was to require > > them to be one hop away, because having multiple hops incurs > > complexity > > which > > was not justified by an essential usage scenario. > > > > alper > > > > This requirement means that a PaC client can't use PANA protocol from an access network (AN) that doesn't support PANA, even if there were networks that support PANA behind the AN :). This is an issue that affects the transition period. > Yes, if an access network wants to use PPP, or 802.1x, or PANA for authentication, it has to place the right set of protocol entities in the right place on the network. Enabling use of PANA thorugh access networks that are not aware of this protocol does not sound too practical (or needed) to me. > Anyway, keeping this requirement prevents walled garden networks. And for me it doesn't make sense, since we are using IP as the transport mechanism. > I'm not sure I understand this. Are you talking about the limited free access networks as described in section 4.6 of the usage scenarios draft? If so, implementation of that scenario doesn't necessarily require the PAA to be multiple hops away from the PaC. > Do you mean the PAA discovery with the incurring complexity? It would be nice to know (maybe I haven't read all the docs, though). > Yes. Requiring PAA be on the same hop enables a tighter system that has less problems to worry about (security threats, discovery, IP address configuration required, etc.) > HTTP redirect is used for authentication. With this requirement PANA will not be in the same scope. On the second hand in the access networks EAP over Ethernet is pretty strong. So, where is PANA going to be if it doesn't even make it theoretically possible to combine these too.. there are VPNs too. > I think the problem statement and usage scenarios draft answers this question. alper > - Dan > From pana-request@research.telcordia.com Mon Jan 13 15:31:22 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23022 for ; Mon, 13 Jan 2003 15:31:21 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0DKWrCl004416; Mon, 13 Jan 2003 15:32:53 -0500 (EST) Resent-Date: Mon, 13 Jan 2003 15:32:53 -0500 (EST) Old-Return-Path: Date: Mon, 13 Jan 2003 15:32:42 -0500 To: "Alper E. YEGIN" Cc: Yoshihiro Ohba , MORAND Lionel FTRD/DAC/ISS , basavaraj.Patil@nokia.com, pana@research.telcordia.com Subject: Re: About the NAP/ISP distinction in the usage-scenarios draft... Message-ID: <20030113203242.GA2727@catfish> Mail-Followup-To: "Alper E. YEGIN" , Yoshihiro Ohba , MORAND Lionel FTRD/DAC/ISS , basavaraj.Patil@nokia.com, pana@research.telcordia.com References: <00a301c2b8fa$01dcfd70$096015ac@AlperVAIO> <20030111003615.GC5095@catfish> <018f01c2bb3f$d86ed0b0$096015ac@AlperVAIO> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <018f01c2bb3f$d86ed0b0$096015ac@AlperVAIO> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20021213(IM143) Lines: 18 X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: <-WIR4D.A.4EB.1JyI-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Mon, Jan 13, 2003 at 12:10:39PM -0800, Alper E. YEGIN wrote: > ....but your recommended method still doesn't cure the mapping problem > between > the client ID and the device ID. If we run two EAP sequences with two > different > client identifiers, PAA will still have two PaC ID that maps to a > device ID. I think the two EAP identities used in a single PANA authentication can be handled as a single PaC ID that is a concatination of the two. > > alper > > Yoshihiro Ohba From pana-request@research.telcordia.com Tue Jan 14 19:18:54 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16978 for ; Tue, 14 Jan 2003 19:18:54 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0F0JpId009708; Tue, 14 Jan 2003 19:19:51 -0500 (EST) Resent-Date: Tue, 14 Jan 2003 19:19:51 -0500 (EST) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: About the NAP/ISP distinction in the usage-scenarios draft... Date: Tue, 14 Jan 2003 18:14:25 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF4401752DAA@daebe007.americas.nokia.com> Thread-Topic: About the NAP/ISP distinction in the usage-scenarios draft... Thread-Index: AcK7QXt8WKU6wJQ9SLyHwBEofx4zwwA6QAzg From: To: , , Cc: , X-OriginalArrivalTime: 15 Jan 2003 00:14:26.0144 (UTC) FILETIME=[1036D600:01C2BC2B] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA16978 > > This requirement means that a PaC client can't use PANA > > protocol from an > > access network (AN) that doesn't support PANA, even if there > > were networks > > that support PANA behind the AN :). This is an issue that affects the > > transition period. > > > > Yes, if an access network wants to use PPP, or 802.1x, or PANA for > authentication, it has to place the right set of protocol entities in > the right place on the network. Enabling use of PANA thorugh > access networks that are not aware of this protocol does not sound too > practical (or needed) to me. But from the EAP analogy, the access network can be considered simply as a passthrough. In EAP the access network does not have to understand or support the actual EAP methods. The same approach may be considered as viable for PANA in certain scenarios. I believe the point is that the access network or EP needs to be somehow informed about the success or failure of the authentication of a PaC which results in an ACK or NAK for IP connectivity being sought by the client. -Basavaraj From pana-request@research.telcordia.com Tue Jan 14 22:01:35 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20190 for ; Tue, 14 Jan 2003 22:01:34 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0F31hfI017109; Tue, 14 Jan 2003 22:01:43 -0500 (EST) Resent-Date: Tue, 14 Jan 2003 22:01:43 -0500 (EST) Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: comments on draft-ietf-pana-threats-01.txt Date: Tue, 14 Jan 2003 19:01:18 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A395@TNEXVS02.tahoenetworks.com> Thread-Topic: comments on draft-ietf-pana-threats-01.txt Thread-Index: AcK8B2qzM4ZNYPphTNuxocTMljfX0wAMBjhA From: "Mohan Parthasarathy" To: "Bernard Aboba" , Cc: "Mohan Parthasarathy" X-OriginalArrivalTime: 15 Jan 2003 03:01:18.0431 (UTC) FILETIME=[600096F0:01C2BC42] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA20190 Bernard, Thanks for your comments. See below.. > > Section 3.0 > > Device Identifier > > "PANA authentication agent keeps a table for binding device > identifiers to > the PANA clients" > > How is this binding done, exactly? Binding the > authenticated identity to a device identifier requires that either the > medium be physically secure (e.g. a wired link) or an underlying L2 > ciphersuite that provides support for per-packet authentication and > integrity. Is this a requirement for PANA? > If the path between PAA and EP can be secured which is quite possible, it will be used by the yet-to-be defined protocol that distributes the information from PAA to EP. Perhaps, we need to reflect this in the PANA requirements that path PAA and EP should be secured rather than stating it as an assumption in this draft. > Section 6 > > "The path between the PAA and AS" > > While it is reasonable to assume that the AAA protocol > provides per-packet > authentication and integrity protection, it may *not* provide > confidentiality. So we need to be more specific about what it > means to say > that the path is "secure". For example, it is generally > considered that > RADIUS is *not* secure against an attacker who can snoop a > large number of > packets, where the PAA shares a RADIUS shared secret with a > NAS that uses > PAP. Also, within RADIUS an attack snooping on the PAA/AS path can > determine the location of users at any point in time (via accounting > records). > > In this section I'd include other attacks, such as session hijacking, > downgrade attacks, etc. A sample threat analysis is > included within Section 7 of RFC 2284bis-09: > > http://www.drizzle.com/~aboba/EAP/draft-ietf-pppext-rfc2284bis-09 > Ok. I did not find any attacks specific to NAS-AAA path in section 7. Would it be better if it can reference the above draft for threats in this path ? > Section 7 > > In IEEE 802.11i discovery (Beacon, Probe Request/Response) > doesn't need to > be protected because the discovered capabilities are included in a > subsequent secured exchange, allowing spoofing to be > discovered after the > fact. That exchange (the 4-way handshake) supports both protected > ciphersuite & capabilities negotiation as well as transient > session key > derivation and "liveness" guarantees. You might think about the > requirements for detection of spoofing after the fact. > Ok. The requirements does not state that the discovery process must be protected. It just states that PANA cannot assume it and hence you need the ability like in 802.11i to verify it. The above one assumes that you can derive keys so that you can do a secure exchange later. It may not be possible with all EAP methods. So, it may not be always possible. Correct ? Do you want me to include the above scenario as an example to make it more clear ? > "If mutual authentication is performed i.e., client to AS and AS to > client, via the PAA, the successful authentication > response from the > AS can be used to validate the authenticity of the PAA." > > This isn't really true -- you need to provide mutual authentication > between all entities in the protocol; transitive trust > between PAA and PAC > can't be assumed just because the PAC and AS have mutually > authenticated > and the AS and PAA have mutually authenticated. See the EAP Keying > Framework for details: > > http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-pro > blem-05.txt > The above text was in the "PAA discovery" section. I think i will remove it from here as it is more talking about solution here. > 7.2.1 Spoofing success or failure > > There is a new section in RFC 2284bis (4.2.1) that deals with > this. Please > read it and tell us (eap@frascone.com) whether it is helpful: > > http://www.drizzle.com/~aboba/EAP/draft-ietf-pppext-rfc2284bis-09.txt > On a quick look, Where a lower layer ciphersuite is in use that provides per-packet integrity and authentication protection, or where the lower layer is considered physically secure, EAP may be considered secure from tamper- ing, and EAP Success and Failure packets may qualify as protected indi- cations. When EAP is used at the IP level, having lower layer ciphersuite that provides per-packet protection is not sufficient as any node can still spoof a success or failure. So, there should be a MIC as part of EAP itself. Correct ? > 7.2.2 MiTM > > MiTM actually requires cryptographic binding between the keys and the > endpoints. This is typically accomplished in mutual > authentication, but > *not* by two independent one-way authentications as occurs in > some of the > tunneled EAP methods. Some more detail here or a reference might be > appropriate, such as to: > > http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-bind > ing-01.txt > The reason i was not referring to this is because it was getting specific to the details like tunneled EAP methdod. This draft was supposed to more generic. I can still add it if it would help. > 7.2.3 > > Authentication and integrity protection doesn't provide > replay protection > -- this is a special property of the L2 ciphersuite. > I am not sure i understand this comment. I was only making a point that even if layer 2 provides replay protection (which is what i was trying to say but it says different) it is not sufficient, as PANA messages can potentially still be replayed. Could you clarify your comment ? > 7.2.4 > > What specifically provides protection against address > spoofing is where a > key has been derived that is bound to the MAC address. Then if the MAC > address is changed, a different key will be used to attempt > to verify the > MIC, and this verification will fail. So the implication is that the > underlying ciphersuite MUST have a MIC (not all do, such as WEP). > Ok, i will add that. But you still need to prevent yourself from the attack of someone modifying the IP address. POTLS prevents it by having a separate exchange after a secure session is setup between PaC and PAA. > 7.3. Spoofed disconnect > > Not all disconnect messages are protectable. For example, in 802.11, > Disassociate and Deauthenticate are not protected even in > IEEE 802.11i. > This is also discussed in RFC 2284bis-09. > This was more talking about the PANA disconnect notification mechanism as mentioned in the PANA requirements. So, even if layer 2 does not have one, PaC will still generate a disconnect at the PANA level which should be protected. > 7.4. Service theft > > Ultimately, this is about linking the authentication to > subsequent data > traffic. Access control itself cannot provide this assurance I agree that access control in terms of filtering IP/MAC address will not provide this. But the requirement states that PAA can provide access control information like "keys" to EP which in turn can enforce the service theft. The idea is that these keys can be used further to establish an SA between PaC and EP that can prevent service theft. > -- it needs > to come either from physical security or an L2 ciphersuite. I > think more > detail is needed on this point. > L2 ciphersuite will prevent unauthorized access but not injecting false data. Ok, i will try to expand this section a bit more. > 7.5 DoS resilience > > I think you need to be very clear on the types of DoS attack > that you want > to protect against. In practice, DoS attacks are hard to > protect against, > so saying "PANA MUST be resistant to DoS attacks" is not very > practical. > Ok. I am planning to remove it from the requirements. > Instead, I would argue that you need to distinguish the types of DoS > attack: > > a. Attacks that require the attacker to be within range of an > access point > b. Attacks that can be carried out from afar > c. Attacks that allow an attacker to consume signfiicant > resources on the > PAA or AS with relatively minimal effort (e.g. forcing a public key > calculation on the PAA or AS) > Ok. thanks mohan > > From pana-request@research.telcordia.com Wed Jan 15 21:21:44 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18191 for ; Wed, 15 Jan 2003 21:21:39 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0G2MYJu004608; Wed, 15 Jan 2003 21:22:34 -0500 (EST) Resent-Date: Wed, 15 Jan 2003 21:22:34 -0500 (EST) Old-Return-Path: Message-ID: <010201c2bd05$d6db5620$296015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Pana \(E-mail\)" Subject: Fw: comments on draft-ietf-pana-usage-scenarios-03.txt Date: Wed, 15 Jan 2003 18:20:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit I suspect this message didn't appear on the PANA mailing list because Bernard is not subscribed (?). Anyways, until the problem is fixed, here is a copy... ----- Original Message ----- From: "Bernard Aboba" To: Cc: ; Sent: Tuesday, January 14, 2003 11:02 AM Subject: comments on draft-ietf-pana-usage-scenarios-03.txt > Section 1 > > "IEEE 802.1x" - the X is capitalized. Also IEEE 802.1X only applies to > wired IEEE 802 networks. IEEE 802.11i is the standard describing how IEEE > 802.1X is adapted to use on IEEE 802.11. > > "This has the advantage of decoupling the association of > authentication from the access technology." > > It's not clear to me that this is completely achievable. For > example, in order to protect against spoofing it's necessary to tie the > authentication to subsequent data traffic. Where physical security can't > be assumed, this is done via key derivation and subsequent per-packet > integrity and authentication. That also implies that transient session > keys need to be derived for use with an L2 ciphersuite. The details of EAP > key derivation and transient session key adaptation need to be addressed > somewhere -- but I haven't seen a discussion anywhere in the PANA > documents. This could represent a major flaw in the architecture, so I > think that more attention needs to be paid to nailing this down. > > "Binding device identifiers to PANA clients" > > It is not clear to me how this is done without either physical security or > an L2 ciphersuite supporting per-packet integrity and authentication (and > keys derived from the authentication). > > Section 3 > > " Access networks which are not physically secured from unintended > usage usually require clients to go through an authentication and > authorization process." > > Even if they are physically secured this is often required. But if they > are not, then I'd claim that this is not enough -- you need to bind the > authentication to subsequent data traffic. It's not clear to me in reading > these documents how this is accomplished. > > "An important aspect of an authentication protocol is the ability to > provide dynamic service provider selection to the clients." > > This isn't part of EAP, since it's assumed that the choice is done out of > band. For example in IEEE 802.11, the SSID is indicated in the > Association/Reassociation Request. > > "This is > usually achieved by clients presenting an identifier which carries > domain information during the authentication process." > > The choice of identity is not the same as the choice of network to > connect to, and can't be assumed from it. I could use the same id > (fred@bigco.com) to access 3 different networks, all advertised on the > same access point. > > "Support for various authentication methods, including the ones that > can provide dynamic service provider selection and roaming can be > achieved by using an authentication protocol that can carry EAP > [RFC2284]. " > > EAP doesn't provide service provider selection. > > " Defining a network-layer transport for EAP would provide a cleaner > solution to this problem." > > Assuming that the EAP lower layer requirements are met. Please see RFC > 2284bis-09, Section 3: > > http://www.drizzle.com/~aboba/EAP/draft-ietf-pppext-rfc2284bis-09.txt > > 4.1 > > "A standard, L2 agnostic network > access authentication is needed for this type of DSL networks and > PANA can be used to fill the demand." > > Or Ethernet Last Mile could be run over the DSL PHY and IEEE 802.1X could > be used instead. Not sure this scenario is very convincing. > > 4.2 > > "One can enable > WEP security to protect the authentication messages." > > Not sure what "protect" means here -- WEP has no per-packet authentication > or integrity protection, just (weak) confidentiality. > > 4.3 > > " Ethernet links composed of legacy hubs and switches and early > deployment of Wi-Fi networks (802.11b) do not use link layer > authentication or security mechanisms such as, 802.1X." > > IEEE 802.11b does support link-layer authentication -- that's what > Authentication frames are for. I think you mean that per-packet integrity > and authentication aren't supported. > > Since IEEE 802.1X is typically a firmware upgrade, "legacy" switches are > indeed supported. Hubs aren't supported, whether legacy or new ones. > > " In such scenarios, a standard network layer solution such as, PANA is > suitable since it provides link-layer agnostic network access > authentication. " > > It isn't clear to me that PANA is suitable for such scenarios unless the link > is physically secure, because: > > " Although PANA does not define key distribution protocol or mechanism, > it is possible to use PANA to enable per-packet protection mechanism > such as, IPsec and WEP, to secure communication in the edge subnet." > > Not sure how this can be done if a "key distribution protocol" isn't > defined. Can you clarify? > > Using PANA to key IPsec isn't a good idea. EAP keying doesn't provide the > facilities required for IPsec keying, such as Phase 2 SA negotiation, > rekey support, etc. See: > > http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-05.txt > > "where lower layer authentication and key distribution mechanisms are > absent PANA could be very useful." > > Since PANA doesn't define key distribution, how is the required > functionality provided? I'm not clear on this. > > > > From pana-request@research.telcordia.com Wed Jan 15 21:22:18 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18205 for ; Wed, 15 Jan 2003 21:22:17 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0G2NtUc004681; Wed, 15 Jan 2003 21:23:55 -0500 (EST) Resent-Date: Wed, 15 Jan 2003 21:23:55 -0500 (EST) Old-Return-Path: Message-ID: <010701c2bd06$07a12550$296015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Pana \(E-mail\)" Subject: Fw: comments on draft-ietf-pana-threats-01.txt Date: Wed, 15 Jan 2003 18:21:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit And this is the second message from Bernard. His comments on the security threats draft.. (this is what Mohan had responded to..) alper > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Tuesday, January 14, 2003 10:36 AM > To: pana@research.telcordia.com > Cc: Mohan Parthasarathy > Subject: comments on draft-ietf-pana-threats-01.txt > > > Section 3.0 > > Device Identifier > > "PANA authentication agent keeps a table for binding device identifiers to > the PANA clients" > > How is this binding done, exactly? Binding the > authenticated identity to a device identifier requires that either the > medium be physically secure (e.g. a wired link) or an underlying L2 > ciphersuite that provides support for per-packet authentication and > integrity. Is this a requirement for PANA? > > Section 6 > > "The path between the PAA and AS" > > While it is reasonable to assume that the AAA protocol provides per-packet > authentication and integrity protection, it may *not* provide > confidentiality. So we need to be more specific about what it means to say > that the path is "secure". For example, it is generally considered that > RADIUS is *not* secure against an attacker who can snoop a large number of > packets, where the PAA shares a RADIUS shared secret with a NAS that uses > PAP. Also, within RADIUS an attack snooping on the PAA/AS path can > determine the location of users at any point in time (via accounting > records). > > In this section I'd include other attacks, such as session hijacking, > downgrade attacks, etc. A sample threat analysis is > included within Section 7 of RFC 2284bis-09: > > http://www.drizzle.com/~aboba/EAP/draft-ietf-pppext-rfc2284bis-09 > > Section 7 > > In IEEE 802.11i discovery (Beacon, Probe Request/Response) doesn't need to > be protected because the discovered capabilities are included in a > subsequent secured exchange, allowing spoofing to be discovered after the > fact. That exchange (the 4-way handshake) supports both protected > ciphersuite & capabilities negotiation as well as transient session key > derivation and "liveness" guarantees. You might think about the > requirements for detection of spoofing after the fact. > > "If mutual authentication is performed i.e., client to AS and AS to > client, via the PAA, the successful authentication response from the > AS can be used to validate the authenticity of the PAA." > > This isn't really true -- you need to provide mutual authentication > between all entities in the protocol; transitive trust between PAA and PAC > can't be assumed just because the PAC and AS have mutually authenticated > and the AS and PAA have mutually authenticated. See the EAP Keying > Framework for details: > > http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-05.txt > > 7.2.1 Spoofing success or failure > > There is a new section in RFC 2284bis (4.2.1) that deals with this. Please > read it and tell us (eap@frascone.com) whether it is helpful: > > http://www.drizzle.com/~aboba/EAP/draft-ietf-pppext-rfc2284bis-09.txt > > 7.2.2 MiTM > > MiTM actually requires cryptographic binding between the keys and the > endpoints. This is typically accomplished in mutual authentication, but > *not* by two independent one-way authentications as occurs in some of the > tunneled EAP methods. Some more detail here or a reference might be > appropriate, such as to: > > http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-01.txt > > 7.2.3 > > Authentication and integrity protection doesn't provide replay protection > -- this is a special property of the L2 ciphersuite. > > 7.2.4 > > What specifically provides protection against address spoofing is where a > key has been derived that is bound to the MAC address. Then if the MAC > address is changed, a different key will be used to attempt to verify the > MIC, and this verification will fail. So the implication is that the > underlying ciphersuite MUST have a MIC (not all do, such as WEP). > > 7.3. Spoofed disconnect > > Not all disconnect messages are protectable. For example, in 802.11, > Disassociate and Deauthenticate are not protected even in IEEE 802.11i. > This is also discussed in RFC 2284bis-09. > > 7.4. Service theft > > Ultimately, this is about linking the authentication to subsequent data > traffic. Access control itself cannot provide this assurance -- it needs > to come either from physical security or an L2 ciphersuite. I think more > detail is needed on this point. > > 7.5 DoS resilience > > I think you need to be very clear on the types of DoS attack that you want > to protect against. In practice, DoS attacks are hard to protect against, > so saying "PANA MUST be resistant to DoS attacks" is not very practical. > > Instead, I would argue that you need to distinguish the types of DoS > attack: > > a. Attacks that require the attacker to be within range of an access point > b. Attacks that can be carried out from afar > c. Attacks that allow an attacker to consume signfiicant resources on the > PAA or AS with relatively minimal effort (e.g. forcing a public key > calculation on the PAA or AS) > > > > From pana-request@research.telcordia.com Thu Jan 16 14:30:29 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21671 for ; Thu, 16 Jan 2003 14:30:28 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0GJUU1H028642; Thu, 16 Jan 2003 14:30:30 -0500 (EST) Resent-Date: Thu, 16 Jan 2003 14:30:30 -0500 (EST) Old-Return-Path: Message-ID: <006701c2bd95$74e337e0$696015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Pana \(E-mail\)" Subject: Fw: I-D ACTION:draft-ietf-pppext-rfc2284bis-09.txt Date: Thu, 16 Jan 2003 11:28:27 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0064_01C2BD52.634995D0" X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com This is a multi-part message in MIME format. ------=_NextPart_000_0064_01C2BD52.634995D0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit This is the new version of the EAP-bis draft. Please check it out. alper ----- Original Message ----- From: To: Cc: Sent: Thursday, January 16, 2003 5:07 AM Subject: I-D ACTION:draft-ietf-pppext-rfc2284bis-09.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. > > Title : Extensible Authentication Protocol (EAP) > Author(s) : L. Blunk, J. Vollbrecht, B. Aboba, J. Carlson > Filename : draft-ietf-pppext-rfc2284bis-09.txt > Pages : 39 > Date : 2003-1-15 > > This document defines the Extensible Authentication Protocol (EAP), an > authentication framework which supports multiple authentication mecha- > nisms. EAP typically runs directly over the link layer without requiring > IP, but is reliant on lower layer ordering guarantees as in PPP and IEEE > 802. EAP does provide its own support for duplicate elimination and > retransmission. Fragmentation is not supported within EAP itself; how- > ever, individual EAP methods may support this. While EAP was originally > developed for use with PPP, it is also now in use with IEEE 802. > > > This document obsoletes RFC 2284. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-09.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-pppext-rfc2284bis-09.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-pppext-rfc2284bis-09.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > ------=_NextPart_000_0064_01C2BD52.634995D0 Content-Type: application/octet-stream; name="ATT00095.dat" Content-Disposition: attachment; filename="ATT00095.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-1-15130925.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-rfc2284bis-09.txt ------=_NextPart_000_0064_01C2BD52.634995D0 Content-Type: text/plain; name="draft-ietf-pppext-rfc2284bis-09.txt" Content-Disposition: attachment; filename="draft-ietf-pppext-rfc2284bis-09.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-1-15130925.I-D@ietf.org> ------=_NextPart_000_0064_01C2BD52.634995D0-- From pana-request@research.telcordia.com Fri Jan 17 20:59:22 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08920 for ; Fri, 17 Jan 2003 20:59:11 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0I1xuE4008616; Fri, 17 Jan 2003 20:59:56 -0500 (EST) Resent-Date: Fri, 17 Jan 2003 20:59:56 -0500 (EST) Old-Return-Path: Message-ID: <002001c2be95$01e19240$416015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Bernard Aboba" , Cc: References: Subject: Re: comments on draft-ietf-pana-usage-scenarios-03.txt Date: Fri, 17 Jan 2003 17:57:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Thank you Bernard, for the review and useful comments. Follow up comments inlined below... > Section 1 > > "IEEE 802.1x" - the X is capitalized. Also IEEE 802.1X only applies to > wired IEEE 802 networks. IEEE 802.11i is the standard describing how IEEE > 802.1X is adapted to use on IEEE 802.11. OK, we shall fix the terminology. > > "This has the advantage of decoupling the association of > authentication from the access technology." > > It's not clear to me that this is completely achievable. For > example, in order to protect against spoofing it's necessary to tie the > authentication to subsequent data traffic. Where physical security can't > be assumed, this is done via key derivation and subsequent per-packet > integrity and authentication. That also implies that transient session > keys need to be derived for use with an L2 ciphersuite. The details of EAP > key derivation and transient session key adaptation need to be addressed > somewhere -- but I haven't seen a discussion anywhere in the PANA > documents. This could represent a major flaw in the architecture, so I > think that more attention needs to be paid to nailing this down. Physical security, L2 ciphesuites, and IPsec are the tools for protecting subsequent data traffic after PANA. Details are not really suitable for this usage scenarios draft, but yes, we should capture these at a high level in this document. > > "Binding device identifiers to PANA clients" > > It is not clear to me how this is done without either physical security or > an L2 ciphersuite supporting per-packet integrity and authentication (and > keys derived from the authentication). There are three types of environments that PANA can be used. One is where there is physical security. When it is not available, L2 ciphersuites can be used instead. And in the (worst) case L2 doesn't have that support either, IPsec can be used. We should capture these better in the document, I agree. > > Section 3 > > " Access networks which are not physically secured from unintended > usage usually require clients to go through an authentication and > authorization process." > > Even if they are physically secured this is often required. But if they > are not, then I'd claim that this is not enough -- you need to bind the > authentication to subsequent data traffic. It's not clear to me in reading > these documents how this is accomplished. > > "An important aspect of an authentication protocol is the ability to > provide dynamic service provider selection to the clients." > > This isn't part of EAP, since it's assumed that the choice is done out of > band. For example in IEEE 802.11, the SSID is indicated in the > Association/Reassociation Request. It isn't really part of EAP, but some uses of EAP relies on presence of domain information as part of the client identifier. For example use of EAP with PPP in DSL networks. Subscriber does not have the facilities to convey its choice of ISP before the authentication, hence it does so during the authentication. IEEE 802.11 could do the same (maybe), but it's taking advantage of some L2 features instead. > > "This is > usually achieved by clients presenting an identifier which carries > domain information during the authentication process." > > The choice of identity is not the same as the choice of network to > connect to, and can't be assumed from it. I could use the same id > (fred@bigco.com) to access 3 different networks, all advertised on the > same access point. It depends on the application of EAP. You are right for IEEE 802.11 links, but usage of EAP over PPP over DSL lines is different. > > "Support for various authentication methods, including the ones that > can provide dynamic service provider selection and roaming can be > achieved by using an authentication protocol that can carry EAP > [RFC2284]. " > > EAP doesn't provide service provider selection. Yes, we should clarify this.. > > " Defining a network-layer transport for EAP would provide a cleaner > solution to this problem." > > Assuming that the EAP lower layer requirements are met. Please see RFC > 2284bis-09, Section 3: > > http://www.drizzle.com/~aboba/EAP/draft-ietf-pppext-rfc2284bis-09.txt Good point. As far as I can see, our current assumptions are aligned with these requirements. Do you (or anyone else) see any issues here? > > 4.1 > > "A standard, L2 agnostic network > access authentication is needed for this type of DSL networks and > PANA can be used to fill the demand." > > Or Ethernet Last Mile could be run over the DSL PHY and IEEE 802.1X could > be used instead. Not sure this scenario is very convincing. I guess there are multiple alternatives, even including using captive portal scheme on DSL. Each has pros and cons, various cost/benefit factors. > > 4.2 > > "One can enable > WEP security to protect the authentication messages." > > Not sure what "protect" means here -- WEP has no per-packet authentication > or integrity protection, just (weak) confidentiality. OK, this paragraph is not clear. And at least we should replace WEP by TKIP/WRAP/AES CCMP. > > 4.3 > > " Ethernet links composed of legacy hubs and switches and early > deployment of Wi-Fi networks (802.11b) do not use link layer > authentication or security mechanisms such as, 802.1X." > > IEEE 802.11b does support link-layer authentication -- that's what > Authentication frames are for. I think you mean that per-packet integrity > and authentication aren't supported. > > Since IEEE 802.1X is typically a firmware upgrade, "legacy" switches are > indeed supported. Hubs aren't supported, whether legacy or new ones. OK. > > " In such scenarios, a standard network layer solution such as, PANA is > suitable since it provides link-layer agnostic network access > authentication. " > > It isn't clear to me that PANA is suitable for such scenarios unless the link > is physically secure, because: > > " Although PANA does not define key distribution protocol or mechanism, > it is possible to use PANA to enable per-packet protection mechanism > such as, IPsec and WEP, to secure communication in the edge subnet." > > Not sure how this can be done if a "key distribution protocol" isn't > defined. Can you clarify? > PANA should not define its own key distribution/derivation. Instead, users of PANA should rely on appropriate EAP methods to provide these functionalities. When needed (i.e., when there is no physical security), EAP methods that can derive/distribute keys should be used for network access authentication. And following this initial authentication, L2 ciphersuites (if available), or IPsec should be enabled for authentication and integrity check of data traffic. > Using PANA to key IPsec isn't a good idea. EAP keying doesn't provide the > facilities required for IPsec keying, such as Phase 2 SA negotiation, > rekey support, etc. See: > > http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-05.txt The keys provided by an EAP method cannot be readily used with IPsec. The newly-generated trust relation between the PaC and PAA needs to be turned into an IPsec SA, and for that IKE can be used. This sounds like a heavy weight operation, but note that this is used when there is no L2 ciphersuite available. We should provide guidelines for how this is done, as well. Maybe in the form of an informational RFC... > > "where lower layer authentication and key distribution mechanisms are > absent PANA could be very useful." > > Since PANA doesn't define key distribution, how is the required > functionality provided? I'm not clear on this. We should clarify that this is not accomplished by PANA, but by particular EAP methods. PANA indirectly enables this by carrying EAP that can carry such authentication methods. alper From pana-request@research.telcordia.com Fri Jan 17 21:13:16 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09235 for ; Fri, 17 Jan 2003 21:13:16 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0I2Ejvk009191; Fri, 17 Jan 2003 21:14:45 -0500 (EST) Resent-Date: Fri, 17 Jan 2003 21:14:45 -0500 (EST) Old-Return-Path: Message-ID: <002f01c2be97$1276f440$416015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Mohan Parthasarathy" , "Bernard Aboba" , References: <416B5AF360DED54088DAD3CA8BFBEA6E0134A395@TNEXVS02.tahoenetworks.com> Subject: Re: comments on draft-ietf-pana-threats-01.txt Date: Fri, 17 Jan 2003 18:12:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: <3Yo75D.A.fPC.ViLK-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > > Section 3.0 > > > > Device Identifier > > > > "PANA authentication agent keeps a table for binding device > > identifiers to > > the PANA clients" > > > > How is this binding done, exactly? Binding the > > authenticated identity to a device identifier requires that either the > > medium be physically secure (e.g. a wired link) or an underlying L2 > > ciphersuite that provides support for per-packet authentication and > > integrity. Is this a requirement for PANA? Just to clarify one point... In the absence of physical security or L2 ciphersuite capabilities, IPsec can be used to provide per-packet authentication and integrity check following the initial authentication. alper From pana-request@research.telcordia.com Sun Jan 19 22:45:52 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00526 for ; Sun, 19 Jan 2003 22:45:48 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0K3jRM4017725; Sun, 19 Jan 2003 22:45:27 -0500 (EST) Resent-Date: Sun, 19 Jan 2003 22:45:27 -0500 (EST) Old-Return-Path: Message-ID: <3E2B70C5.1D9BE2CB@research.telcordia.com> Date: Sun, 19 Jan 2003 22:45:09 -0500 From: Subir Das X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: pana@research.telcordia.com Subject: [Fwd: RE: comments on draft-ietf-pana-threats-01.txt] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: RE: comments on draft-ietf-pana-threats-01.txt Date: Sun, 19 Jan 2003 21:57:24 -0500 (EST) From: Bernard Aboba To: Mohan Parthasarathy CC: pana@research.telcordia.com On Tue, 14 Jan 2003, Mohan Parthasarathy wrote: > If the path between PAA and EP can be secured which is quite possible, > it will be used by the yet-to-be defined protocol that distributes the > information from PAA to EP. Perhaps, we need to reflect this in the > PANA requirements that path PAA and EP should be secured rather than > stating it as an assumption in this draft. Yes, I think that makes sense. > > http://www.drizzle.com/~aboba/EAP/draft-ietf-pppext-rfc2284bis-09 > > > Ok. I did not find any attacks specific to NAS-AAA path in section 7. > Would it be better if it can reference the above draft for threats > in this path ? For threats in the NAS-AAA path, you might look at: http://www.ietf.org/internet-drafts/draft-congdon-radius-8021x-21.txt http://www.ietf.org/internet-drafts/draft-aboba-radius-rfc2869bis-06.txt > Ok. The requirements does not state that the discovery process > must be protected. It just states that PANA cannot assume it and hence > you need the ability like in 802.11i to verify it. The above one > assumes that you can derive keys so that you can do a secure exchange > later. It may not be possible with all EAP methods. So, it may not > be always possible. Correct ? Do you want me to include the above > scenario as an example to make it more clear ? I think there is a question of whether methods which don't mutually authenticate or use keys are usable with PANA. I'd suggest that the requirements should say something about that. One important assumption for EAP keying and security is that for physically insecure media there is a "third leg" -- mutual authentication between the NAS and client. If PANA does not assume physical security, then I think it may have to define a third leg running over IP. If so, this is an important requirement. > The above text was in the "PAA discovery" section. I think i will remove > it from here as it is more talking about solution here. The question about the PANA trust model remains. As mentioned above, transitive trust probably isn't a strong enough model when dealing with media which aren't physically secure. > When EAP is used at the IP level, having lower layer ciphersuite that > provides per-packet protection is not sufficient as any node can still > spoof a success or failure. So, there should be a MIC as part of EAP itself. > Correct ? Yes. We've attempted to clarify this in -10: http://www.drizzle.com/~aboba/EAP/draft-ietf-pppext-rfc2284bis-10.txt > The reason i was not referring to this is because it was getting specific > to the details like tunneled EAP methdod. This draft was supposed to > more generic. I can still add it if it would help. Even in a generic framework you still need to understand what the requirements are for EAP transport and method use, and what the trust model is. If these questions are not answered now they will come back again and again (we've been there with IEEE 802.11i). > I am not sure i understand this comment. I was only making a point that > even if layer 2 provides replay protection (which is what i was trying to > say but it says different) it is not sufficient, as PANA messages can > potentially still be replayed. Could you clarify your comment ? OK. Yes, they could be replayed at L3. I think this translates into an EAP method requirement for replay protection, because EAP itself doesn't provide replay protection (the Identifier value is not required to be monotonically increasing). > Ok, i will add that. But you still need to prevent yourself from the attack > of someone modifying the IP address. POTLS prevents it by having a separate > exchange after a secure session is setup between PaC and PAA. Actually, I'm not sure you really need to prevent that. For example, in POTL, a fast resume could occur from another IP address -- is this forbidden? > This was more talking about the PANA disconnect notification mechanism as mentioned > in the PANA requirements. So, even if layer 2 does not have one, PaC will still > generate a disconnect at the PANA level which should be protected. Not sure what security value this has -- POTLS can of course be disconnected by an attacker by spoofing a RST. > I agree that access control in terms of filtering IP/MAC address will > not provide this. But the requirement states that PAA can provide access > control information like "keys" to EP which in turn can enforce the > service theft. The idea is that these keys can be used further to establish > an SA between PaC and EP that can prevent service theft. If PANA is generating keys then you definitely need to be very clear about what kinds of keys they are and the trust relationships between the entities. Or does PANA inherit the EAP keying framework? The problem is that PANA has more entities, so it isn't entirely clear to me that this framework can be applied to PANA, since it only covers 2-way and 3-way exchanges, not 4-way. > L2 ciphersuite will prevent unauthorized access but not injecting false > data. Ok, i will try to expand this section a bit more. It can, if the L2 ciphersuite includes per-packet authentication and integrity protection. For example on 802.11 TKIP, WRAP and CCMP do provide this, but WEP doesn't. On PPP none of the ciphersuites provide this (though they do provide confidentiality). From pana-request@research.telcordia.com Mon Jan 20 04:40:21 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15129 for ; Mon, 20 Jan 2003 04:40:06 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0K9evQZ029736; Mon, 20 Jan 2003 04:40:57 -0500 (EST) Resent-Date: Mon, 20 Jan 2003 04:40:57 -0500 (EST) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: preserving packet order in EAP? Date: Mon, 20 Jan 2003 11:36:59 +0200 Message-ID: Thread-Topic: preserving packet order in EAP? Thread-Index: AcLAZ3qMp/Uyff0DQkSwnshmog1qtA== From: To: Cc: X-OriginalArrivalTime: 20 Jan 2003 09:37:00.0344 (UTC) FILETIME=[7B59C380:01C2C067] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: <6HM4C.A.gQH.pQ8K-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA15129 Hi, EAP requires that packet order is maintained by the lower layer. My concern is that EAP can't be carried by UDP or IP alone, because these protocols do not preserve the packet order? This becomes an issue in the PANA wg. TCP/SCTP would be another option to carry EAP, but EAP detects duplicates and does re-transmissions already. Another comment/question: Isn't EAP request-response style protocol, so what are the possibilites/consequences for packet order mismatch? - Dan From pana-request@research.telcordia.com Mon Jan 20 09:17:31 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20748 for ; Mon, 20 Jan 2003 09:17:31 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0KEHLBM015953; Mon, 20 Jan 2003 09:17:21 -0500 (EST) Resent-Date: Mon, 20 Jan 2003 09:17:21 -0500 (EST) Old-Return-Path: Date: Mon, 20 Jan 2003 09:17:14 -0500 To: Dan.Forsberg@nokia.com Cc: pana@research.telcordia.com Subject: Re: [eap] preserving packet order in EAP? Message-ID: <20030120141639.GA740@catfish> Mail-Followup-To: Dan.Forsberg@nokia.com, pana@research.telcordia.com References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="z6Eq5LdranGa6ru8" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i From: Yoshihiro Ohba X-Dispatcher: imput version 20021213(IM143) Lines: 174 X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: <61EGtB.A.G5D.xTAL-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com --z6Eq5LdranGa6ru8 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline Dan, Let me attach James Carlson's email which contains a good example for why packet order for EAP must be maintained by the lower layer. Yoshihiro Ohba On Mon, Jan 20, 2003 at 11:36:59AM +0200, Dan.Forsberg@nokia.com wrote: > Hi, > > EAP requires that packet order is maintained by the lower layer. My concern is that EAP can't be carried by UDP or IP alone, because these protocols do not preserve the packet order? This becomes an issue in the PANA wg. TCP/SCTP would be another option to carry EAP, but EAP detects duplicates and does re-transmissions already. Another comment/question: Isn't EAP request-response style protocol, so what are the possibilites/consequences for packet order mismatch? > > - Dan > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > --z6Eq5LdranGa6ru8 Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id LAA06133 for ; Mon, 6 Jan 2003 11:09:39 -0500 (EST) Received: from smtp.tari.toshiba.com ([208.192.119.195]) by thumper.research.telcordia.com (8.12.6/8.12.1) with ESMTP id h06G866o014170 for ; Mon, 6 Jan 2003 11:08:07 -0500 (EST) Received: from tai.toshiba.com by smtp.tari.toshiba.com (8.9.1/3.7W-020529) with ESMTP id KAA23791 for ; Mon, 6 Jan 2003 10:08:50 -0500 Received: from frascone.com (goaway@adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by tai.toshiba.com (8.7.3/8.7.5) with SMTP id KAA27345 for ; Mon, 6 Jan 2003 10:59:39 -0500 (EST) Received: (qmail 3660 invoked from network); 6 Jan 2003 16:04:04 -0000 Received: from localhost (HELO newman.frascone.com) (goaway@127.0.0.1) by localhost with SMTP; 6 Jan 2003 16:04:04 -0000 Delivered-To: eap@frascone.com Received: (qmail 3639 invoked from network); 6 Jan 2003 16:03:59 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by adsl-66-137-237-97.dsl.rcsntx.swbell.net with SMTP; 6 Jan 2003 16:03:59 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26255; Mon, 6 Jan 2003 08:03:32 -0800 (PST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h06G3V5f009023; Mon, 6 Jan 2003 11:03:31 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6) with ESMTP id h06G3VxO039418; Mon, 6 Jan 2003 11:03:31 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6/Submit) id h06G3Vpc039415; Mon, 6 Jan 2003 11:03:31 -0500 (EST) MIME-Version: 1.0 Message-ID: <15897.43219.520135.258707@gargle.gargle.HOWL> From: James Carlson To: Nick Petroni Cc: Subject: Re: [eap] Strawman rewrite of Section 4.1 In-Reply-To: Nick Petroni's message of 5 January 2003 16:46:39 References: <15896.41449.806785.993398@gargle.gargle.HOWL> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 6 Jan 2003 11:03:31 -0500 X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Content-Type: text/plain; charset=us-ascii X-UIDL: fb581ef4ff7af449ca7efdf8cf94d5cd Content-Transfer-Encoding: 7bit Nick Petroni writes: > > > In that case, how will the peer know which track the > > > conversation is following since the original requests could have arrived > > > out of order? > > > > EAP was originally defined to run on PPP and RFC 1661 has the > > necessary ordering requirement: > Originally, yes. But, 2284bis extends the applicability of EAP. From > section 3 of 2284bis: > [4] Possible reordering. EAP provides its own mechanisms to detect > reordering and so does not assume that the lower layer provides > ordering guarantees. This part is false. EAP as defined in the draft simply cannot detect all possible cases of reordering. Consider the following case: Authenticator Authenticatee Request ID=1 >--------> (got req 1) ----< Response ID=1 (timeout) / Request ID=1 >--/ /\ (got resp 1) <- | Request ID=2 >--------> (got req 2) | --< Response ID=2 | / (got resp 2) <----- \ ---> (got req 1) (disc bad id) <-------< Response ID=1 At this point, the session is completely scrazzled. Authenticatee is unable to tell that the second "Request ID=1" message it got was actually just a retransmission, so it must treat it as a new Request, and must reinvoke whatever process was used to generate the Response. Besides being just wasteful, this also means that (1) any saved state on the Authenticatee side (e.g., values used to compute shared keys) is now trashed and (2) the actual Response data may differ from the original Response data, leading to chaos. EAP as currently defined can't do what you want here. If the RFC had defined a sequence space with a "less than" comparison operation, then you could probably do it, but that's no longer the same as RFC 2284 EAP. > EAP is a "lockstep" protocol, so that the > Authenticator MUST NOT send a new Request until a Response is > received to an outstanding Request. Since the Peer should not > expect a new Request until it has sent a Response, if it receives a > new Request with a different Identifier before sending a Response > to the outstanding Request, the new Request MUST be silently > discarded. That's not compatible with 2284, which has no such restriction. > > All that any EAP authenticatee has to do is to respond to the Request > > messages that come in. It doesn't have to "track" any conversations. > Methods may rely on messages being presented to them in a certain order, > if EAP does not guarantee this order much more work needs to be put into > method design. I don't think the case can be made that EAP just shouldn't > be run over out-of-order protocols. Really? Why not? That was the original intent of RFC 2284. It was modeled on PPP negotiation, and PPP negotiation most explicitly does *not* survive out-of-order delivery. If there's some transport being planned for EAP that does present the possibility of out-of-order delivery, then I think that probably needs a little more careful examination. > Perhaps method designers can weigh-in > on this a little, but I would think problems do arise without in-order > presentation. Those problems certainly do arise. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap --z6Eq5LdranGa6ru8-- From pana-request@research.telcordia.com Mon Jan 20 11:16:50 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23014 for ; Mon, 20 Jan 2003 11:16:31 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0KGHsei021513; Mon, 20 Jan 2003 11:17:54 -0500 (EST) Resent-Date: Mon, 20 Jan 2003 11:17:54 -0500 (EST) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: [eap] preserving packet order in EAP? Date: Mon, 20 Jan 2003 18:13:45 +0200 Message-ID: Thread-Topic: [eap] preserving packet order in EAP? Thread-Index: AcLAjyLGIGzQ7I62QKqci8ZO8K77BgABPF+w From: To: Cc: , X-OriginalArrivalTime: 20 Jan 2003 16:13:45.0609 (UTC) FILETIME=[E864EF90:01C2C09E] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: <-I1-7D.A._PF.wECL-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit One possible solution for this problem is to require the Authenticatee to remember the ID numbers inside the EAP method (message id's between the initial request and Success/Failure msgs). This would imply that no EAP method should produce more than 256 requests per authentication. Another solution to this problem is to prohibit simultaneous *same type* of authentications. Currently in the -10 spec: "Once a peer has sent a Response of the same Type as a Request, some existing peer implementations might expect the method to run to completion. As a result, these implementations silently discard EAP Requests of a Type different from the method in progress, despite the requirement for a Response in section 2.2.1. For this reason, EAP authenticators that must interoperate with these peers are discouraged from switching methods before the final round of a given method has completed." I couldn't find section 2.2.1? So, the Authenticatee could drop the duplicate request (1) because it would restart the authentication method and thus the "first" method would not "run to completion". Anyway, I think this should be fixed in the EAP protocol simply because it is standardized here in the IETF. A new issue perhaps? EAP already provides retransmission and "duplicate" detection. Making the duplicate detection work within this example, would make EAP suitable for carriers such as UDP, ICMP, and IP. This would increase the possibilities for EAP in the Internet. Authenticator Authenticatee Request ID=1 >--------> (got req 1) -----< Response ID=1 (timeout) / Request ID=1 >--/ /\ (got resp 1) <- | Request ID=2 >--------> (got req 2) | --< Response ID=2 | / (got resp 2) <----- \ ---> (got req 1) (disc bad id) <-------< Response ID=1 > -----Original Message----- > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: 20 January, 2003 16:17 > To: Forsberg Dan (NRC/Helsinki) > Cc: pana@research.telcordia.com > Subject: Re: [eap] preserving packet order in EAP? > > > Dan, > > Let me attach James Carlson's email which contains a good example for > why packet order for EAP must be maintained by the lower layer. > > Yoshihiro Ohba > > > On Mon, Jan 20, 2003 at 11:36:59AM +0200, > Dan.Forsberg@nokia.com wrote: > > Hi, > > > > EAP requires that packet order is maintained by the lower > layer. My concern is that EAP can't be carried by UDP or IP > alone, because these protocols do not preserve the packet > order? This becomes an issue in the PANA wg. TCP/SCTP would > be another option to carry EAP, but EAP detects duplicates > and does re-transmissions already. Another comment/question: > Isn't EAP request-response style protocol, so what are the > possibilites/consequences for packet order mismatch? > > > > - Dan > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > From pana-request@research.telcordia.com Mon Jan 20 12:48:26 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25300 for ; Mon, 20 Jan 2003 12:48:25 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0KHng5q026104; Mon, 20 Jan 2003 12:49:42 -0500 (EST) Resent-Date: Mon, 20 Jan 2003 12:49:42 -0500 (EST) Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: comments on draft-ietf-pana-threats-01.txt Date: Mon, 20 Jan 2003 09:49:22 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6EAB6FFE@TNEXVS02.tahoenetworks.com> Thread-Topic: comments on draft-ietf-pana-threats-01.txt Thread-Index: AcK+oMWnrw/MRNbLRsOzReKXAGgcFQCCwB9w From: "Mohan Parthasarathy" To: "Bernard Aboba" , "Alper E. YEGIN" Cc: X-OriginalArrivalTime: 20 Jan 2003 17:49:22.0861 (UTC) FILETIME=[44101DD0:01C2C0AC] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA25300 Bernard, > > > Just to clarify one point... In the absence of physical security or > > L2 ciphersuite capabilities, IPsec can be used to provide > > per-packet authentication and integrity check following the > > initial authentication. > > That's fine, but then the binding has nothing to do with > PANA, per se but > rather is established via IKE, no? > Yes, that is my understanding as per the discussion sometime back in this group. But there may be lot of details missing like how IKE (between PaC and EP) uses the information like keys, credentials etc. that was used during the PANA exchange to set up a SA to secure further communication. We thought that this was outside the scope of PANA working group but an informational draft on how this can be done might be produced by this group. -mohan From pana-request@research.telcordia.com Mon Jan 20 13:31:37 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26617 for ; Mon, 20 Jan 2003 13:31:36 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0KIWV6n028287; Mon, 20 Jan 2003 13:32:31 -0500 (EST) Resent-Date: Mon, 20 Jan 2003 13:32:31 -0500 (EST) Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: comments on draft-ietf-pana-threats-01.txt Date: Mon, 20 Jan 2003 10:31:44 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A39C@TNEXVS02.tahoenetworks.com> Thread-Topic: comments on draft-ietf-pana-threats-01.txt Thread-Index: AcLAL5rSNZmOjf9FSLCmqEadBrs7QAAfMK9A From: "Mohan Parthasarathy" To: "Bernard Aboba" Cc: X-OriginalArrivalTime: 20 Jan 2003 18:31:44.0972 (UTC) FILETIME=[2F4778C0:01C2C0B2] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA26617 Bernard, Thanks again for your comments. > > On Tue, 14 Jan 2003, Mohan Parthasarathy wrote: > > > If the path between PAA and EP can be secured which is > quite possible, > > it will be used by the yet-to-be defined protocol that > distributes the > > information from PAA to EP. Perhaps, we need to reflect this in the > > PANA requirements that path PAA and EP should be secured rather than > > stating it as an assumption in this draft. > > Yes, I think that makes sense. > Ok, we will clarify this in the PANA requirements draft. > > > http://www.drizzle.com/~aboba/EAP/draft-ietf-pppext-rfc2284bis-09 > > > > > Ok. I did not find any attacks specific to NAS-AAA path in > section 7. > > Would it be better if it can reference the above draft for threats > > in this path ? > > For threats in the NAS-AAA path, you might look at: > > http://www.ietf.org/internet-drafts/draft-congdon-radius-8021x-21.txt > http://www.ietf.org/internet-drafts/draft-aboba-radius-rfc2869 > bis-06.txt > Thanks for the pointer. I will add the reference and some text also. > > Ok. The requirements does not state that the discovery process > > must be protected. It just states that PANA cannot assume > it and hence > > you need the ability like in 802.11i to verify it. The above one > > assumes that you can derive keys so that you can do a > secure exchange > > later. It may not be possible with all EAP methods. So, it may not > > be always possible. Correct ? Do you want me to include the above > > scenario as an example to make it more clear ? > > I think there is a question of whether methods which don't mutually > authenticate or use keys are usable with PANA. I'd suggest that the In the past discussion, when this came up some folks thought that PANA itself will not restrict the use of EAP methods. This means if you choose method X, then you get some level of protection i.e still vulnerable to certain attacks. > requirements should say something about that. One important > assumption for > EAP keying and security is that for physically insecure media > there is a > "third leg" -- mutual authentication between the NAS and > client. If PANA > does not assume physical security, then I think it may have > to define a > third leg running over IP. If so, this is an important requirement. > You bring up an important point. When i read the EAP-keying framework document section 1, it says "The primary purpose of EAP is to authenticate an EAP client to an EAP server, as well as to PROVIDE KEYS FOR USE WITH A LINK LAYER CIPHERSUITE NEGOTIATED BETWEEN AN EAP CLIENT AND A NETWORK ACCESS SERVER". I guess you are talking specifically about providing keys to secure the link layer communication. Correct ? For PANA, as far as i can tell, it is not a requirement to provide keys for the link layer ciphersuite. From what i understand, the details of how this will be done are outside the scope of PANA. May be this should be clarified. Perhaps we need something like EAP-keying framework for PANA also and some informational document on how to secure the communication. > > The above text was in the "PAA discovery" section. I think > i will remove > > it from here as it is more talking about solution here. > > The question about the PANA trust model remains. As mentioned above, > transitive trust probably isn't a strong enough model when > dealing with > media which aren't physically secure. > Ok, i will clarify this. > > When EAP is used at the IP level, having lower layer > ciphersuite that > > provides per-packet protection is not sufficient as any > node can still > > spoof a success or failure. So, there should be a MIC as > part of EAP itself. > > Correct ? > > Yes. We've attempted to clarify this in -10: > > http://www.drizzle.com/~aboba/EAP/draft-ietf-pppext-rfc2284bis-10.txt > Ok. I will go over it again. > > The reason i was not referring to this is because it was > getting specific > > to the details like tunneled EAP methdod. This draft was supposed to > > more generic. I can still add it if it would help. > > Even in a generic framework you still need to understand what the > requirements are for EAP transport and method use, and what the trust > model is. If these questions are not answered now they will come back > again and again (we've been there with IEEE 802.11i). Ok. > > I am not sure i understand this comment. I was only making > a point that > > even if layer 2 provides replay protection (which is what i > was trying to > > say but it says different) it is not sufficient, as PANA > messages can > > potentially still be replayed. Could you clarify your comment ? > > OK. Yes, they could be replayed at L3. I think this > translates into an EAP > method requirement for replay protection, because EAP itself doesn't > provide replay protection (the Identifier value is not required to be > monotonically increasing). > If the method itself protects itself from replay, and not the EAP itself, are there any vulnerabilities still ? > > Ok, i will add that. But you still need to prevent yourself > from the attack > > of someone modifying the IP address. POTLS prevents it by > having a separate > > exchange after a secure session is setup between PaC and PAA. > > Actually, I'm not sure you really need to prevent that. For > example, in > POTL, a fast resume could occur from another IP address -- is this > forbidden? > I am not aware of this. Could the POTL authors comment on this ? > > This was more talking about the PANA disconnect > notification mechanism as mentioned > > in the PANA requirements. So, even if layer 2 does not have > one, PaC will still > > generate a disconnect at the PANA level which should be protected. > > Not sure what security value this has -- POTLS can of course be > disconnected by an attacker by spoofing a RST. > Ah! missed that completely..It is useless to provide layer 3 protection if layer 2 can be used to disconnected. Ok, i will have to redo the requirement on this one. > > I agree that access control in terms of filtering IP/MAC > address will > > not provide this. But the requirement states that PAA can > provide access > > control information like "keys" to EP which in turn can enforce the > > service theft. The idea is that these keys can be used > further to establish > > an SA between PaC and EP that can prevent service theft. > > If PANA is generating keys then you definitely need to be > very clear about > what kinds of keys they are and the trust relationships between the > entities. Or does PANA inherit the EAP keying framework? The > problem is > that PANA has more entities, so it isn't entirely clear to me > that this > framework can be applied to PANA, since it only covers 2-way and 3-way > exchanges, not 4-way. > The difference i see is this: In EAP-keying framework, the trust relationships involved are Client-NAS, NAS-AAA, Client-AAA. In PANA, we have PaC-PAA, PAA-AAA, PaC-AAA and the fourth one i think you mention is PAA-EP. Note that it is still possible to have PAA and EP co-located in which case it will boil down to the same as EAP-keying framework. If not we may have to produce another document similar to EAP-keying framework document to expand on the key derivation. I will add some text to this effect. Does that make sense ? > > L2 ciphersuite will prevent unauthorized access but not > injecting false > > data. Ok, i will try to expand this section a bit more. > > It can, if the L2 ciphersuite includes per-packet authentication and > integrity protection. For example on 802.11 TKIP, WRAP and > CCMP do provide > this, but WEP doesn't. On PPP none of the ciphersuites provide this > (though they do provide confidentiality). > What i meant was spoofing at layer 3. I can send packets meant for IP address X, from IP address Y. Per-packet auth and integrity will pass through but still the packets are spoofed at layer 3. -mohan > > From pana-request@research.telcordia.com Mon Jan 20 17:32:11 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03075 for ; Mon, 20 Jan 2003 17:32:11 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0KMXS9r009757; Mon, 20 Jan 2003 17:33:28 -0500 (EST) Resent-Date: Mon, 20 Jan 2003 17:33:28 -0500 (EST) Old-Return-Path: Message-ID: <3E2C7924.A71AE958@research.telcordia.com> Date: Mon, 20 Jan 2003 17:33:08 -0500 From: Subir Das X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: pana@research.telcordia.com Subject: [Fwd: RE: comments on draft-ietf-pana-threats-01.txt] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: RE: comments on draft-ietf-pana-threats-01.txt Date: Mon, 20 Jan 2003 17:18:17 -0500 (EST) From: Bernard Aboba To: Mohan Parthasarathy CC: pana@research.telcordia.com > In the past discussion, when this came up some folks thought that PANA itself > will not restrict the use of EAP methods. This means if you choose method X, > then you get some level of protection i.e still vulnerable to certain attacks. Since PANA is used in many scenarios, it might not be appropriate to add restrictions that apply to only some cases. But guidance seems appropriate -- wireless media are very different from wired media in the security requirements and they can't be treated the same way. > I guess you are talking specifically about providing keys to secure > the link layer communication. Correct ? Yes. This allows the authentication to be bound to subsequent per-packet integrity and authentication, preventing hijacking. It also enables features such as fast handoff. > For PANA, as far as i can tell, > it is not a requirement to provide keys for the link layer ciphersuite. So how do you prevent hijacking? > Perhaps we need something like EAP-keying framework for PANA also and > some informational document on how to secure the communication. I think so. As it stands, it is not at all clear to me what security assurance PANA provides, if any. > > The question about the PANA trust model remains. As mentioned above, > > transitive trust probably isn't a strong enough model when > > dealing with > > media which aren't physically secure. > > > Ok, i will clarify this. This is part of the overall security framework, I think. You need to know what threats PANA is trying to address on various media, and what the requirements are. > If the method itself protects itself from replay, and not the EAP > itself, are there any vulnerabilities still ? There could be. I think it depends on the method behavior. For example, a method that silently discards a replayed packet should be ok. But if it aborts on MIC failure or replay then it could be disabled by a single forged packet. That would enable an attacker to force multiple authentication operations as the result of a single forgery -- good leverage for a DoS attack. > Ah! missed that completely..It is useless to provide layer 3 protection > if layer 2 can be used to disconnected. Ok, i will have to redo the > requirement on this one. Not quite useless... but vulnerabilities will remain. > The difference i see is this: > In EAP-keying framework, the trust relationships involved are Client-NAS, > NAS-AAA, Client-AAA. > In PANA, we have PaC-PAA, PAA-AAA, PaC-AAA and the fourth one i think > you mention is PAA-EP. Note that it is still possible to have PAA and > EP co-located in which case it will boil down to the same as EAP-keying > framework. If not we may have to produce another document similar > to EAP-keying framework document to expand on the key derivation. > I will add some text to this effect. Does that make sense ? Yes, it does. But adding another party adds a *lot* of complexity. We are having some trouble nailing down the EAP 2-way and 3-way exchanges. Trying to prove the security of a PANA 4-way exchange could be very difficult. From pana-request@research.telcordia.com Mon Jan 20 17:33:31 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03109 for ; Mon, 20 Jan 2003 17:33:31 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0KMZO36009901; Mon, 20 Jan 2003 17:35:24 -0500 (EST) Resent-Date: Mon, 20 Jan 2003 17:35:24 -0500 (EST) Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: comments on draft-ietf-pana-threats-01.txt Date: Mon, 20 Jan 2003 14:34:47 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A39D@TNEXVS02.tahoenetworks.com> Thread-Topic: comments on draft-ietf-pana-threats-01.txt Thread-Index: AcLAz/u5FSEidqDQSmK3DNXBUftGggAAXE+A From: "Mohan Parthasarathy" To: "Bernard Aboba" Cc: X-OriginalArrivalTime: 20 Jan 2003 22:34:48.0767 (UTC) FILETIME=[23E5FCF0:01C2C0D4] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA03109 > > > In the past discussion, when this came up some folks > thought that PANA itself > > will not restrict the use of EAP methods. This means if you > choose method X, > > then you get some level of protection i.e still vulnerable > to certain attacks. > > Since PANA is used in many scenarios, it might not be > appropriate to add > restrictions that apply to only some cases. But guidance > seems appropriate > -- wireless media are very different from wired media in the security > requirements and they can't be treated the same way. > Ok. > > I guess you are talking specifically about providing keys to secure > > the link layer communication. Correct ? > > Yes. This allows the authentication to be bound to subsequent > per-packet > integrity and authentication, preventing hijacking. It also enables > features such as fast handoff. > > > For PANA, as far as i can tell, > > it is not a requirement to provide keys for the link layer > ciphersuite. > > So how do you prevent hijacking? > By setting up SAs. Once the authentication is complete, it is assumed that keys can be derived using the EAP framework (this is where PANA needs to provide additional details for 4-way) and that can be used as input to securing the future communications. I agree that these details are missing as to how this will happen. The service theft section discusses this to the extent that there are vulnerabilities but it does not go into details about what could be done as it was outside the scope of the threats evaluation document itself. It says ".... PANA should be able to provide keys...". I will clarify this further. > > Perhaps we need something like EAP-keying framework for > PANA also and > > some informational document on how to secure the communication. > > I think so. As it stands, it is not at all clear to me what security > assurance PANA provides, if any. > Ok. > > > The question about the PANA trust model remains. As > mentioned above, > > > transitive trust probably isn't a strong enough model when > > > dealing with > > > media which aren't physically secure. > > > > > Ok, i will clarify this. > > This is part of the overall security framework, I think. You > need to know > what threats PANA is trying to address on various media, and what the > requirements are. > Ok. > > If the method itself protects itself from replay, and not the EAP > > itself, are there any vulnerabilities still ? > > There could be. I think it depends on the method behavior. > For example, a > method that silently discards a replayed packet should be ok. > But if it > aborts on MIC failure or replay then it could be disabled by a single > forged packet. That would enable an attacker to force multiple > authentication operations as the result of a single forgery -- good > leverage for a DoS attack. > Ok. > > Ah! missed that completely..It is useless to provide layer > 3 protection > > if layer 2 can be used to disconnected. Ok, i will have to redo the > > requirement on this one. > > Not quite useless... but vulnerabilities will remain. > > > The difference i see is this: > > In EAP-keying framework, the trust relationships involved > are Client-NAS, > > NAS-AAA, Client-AAA. > > In PANA, we have PaC-PAA, PAA-AAA, PaC-AAA and the fourth > one i think > > you mention is PAA-EP. Note that it is still possible to > have PAA and > > EP co-located in which case it will boil down to the same > as EAP-keying > > framework. If not we may have to produce another document similar > > to EAP-keying framework document to expand on the key derivation. > > I will add some text to this effect. Does that make sense ? > > Yes, it does. But adding another party adds a *lot* of > complexity. We are > having some trouble nailing down the EAP 2-way and 3-way > exchanges. Trying > to prove the security of a PANA 4-way exchange could be very > difficult. > Ok. Perhaps, we should revisit to see why PAA and EP cannot be always co-located. thanks mohan > > From pana-request@research.telcordia.com Mon Jan 20 17:45:05 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03347 for ; Mon, 20 Jan 2003 17:44:57 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0KMkmjE010361; Mon, 20 Jan 2003 17:46:48 -0500 (EST) Resent-Date: Mon, 20 Jan 2003 17:46:48 -0500 (EST) Old-Return-Path: Message-ID: <3E2C7C48.69D50AAD@research.telcordia.com> Date: Mon, 20 Jan 2003 17:46:32 -0500 From: Subir Das X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: pana@research.telcordia.com Subject: [Fwd: RE: comments on draft-ietf-pana-threats-01.txt] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: RE: comments on draft-ietf-pana-threats-01.txt Date: Mon, 20 Jan 2003 17:43:14 -0500 (EST) From: Bernard Aboba To: Mohan Parthasarathy CC: pana@research.telcordia.com > > So how do you prevent hijacking? > > > By setting up SAs. Once the authentication is complete, it is assumed that > keys can be derived using the EAP framework (this is where PANA needs to > provide additional details for 4-way) and that can be used as input to > securing the future communications. I agree that these details > are missing as to how this will happen. The service theft section discusses > this to the extent that there are vulnerabilities but it does not > go into details about what could be done as it was outside the scope of > the threats evaluation document itself. It says ".... PANA should be able > to provide keys...". I will clarify this further. EAP is not a good mechanism for keying IPsec SAs -- unless perhaps you were to run IKE over EAP. > Ok. Perhaps, we should revisit to see why PAA and EP cannot be always > co-located. That would be better. From pana-request@research.telcordia.com Mon Jan 20 17:51:55 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03511 for ; Mon, 20 Jan 2003 17:51:55 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0KMrgXk010682; Mon, 20 Jan 2003 17:53:42 -0500 (EST) Resent-Date: Mon, 20 Jan 2003 17:53:42 -0500 (EST) Old-Return-Path: Message-ID: <3E2C7DE1.1EA65ABB@research.telcordia.com> Date: Mon, 20 Jan 2003 17:53:21 -0500 From: Subir Das X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: pana@research.telcordia.com Subject: [Fwd: [eap] Re: preserving packet order in EAP] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: [eap] Re: preserving packet order in EAP Date: Mon, 20 Jan 2003 12:46:19 -0800 (PST) From: Bernard Aboba To: eap@frascone.com CC: pana@research.telcordia.com On Monday, January 20, 2003 Dan Forsberg wrote: > EAP requires that packet order is maintained by the lower layer. My > concern is that EAP can't be carried by UDP or IP alone, because these > protocols do not preserve the packet order? Those transports are illegal, because they don't preserve order, correct. > TCP/SCTP would be another option to carry EAP, but EAP detects > duplicates and does re-transmissions already. Yes, those transports would be fine, providing that they provide the appropriate security -- namely per-packet integrity and authentication. > Another comment/question: > Isn't EAP request-response style protocol, so what are the > possibilites/consequences for packet order mismatch? The issue comes up since RFC 2284 doesn't require the Identifier space to be monotonically increasing. That means that if a Request packet with ID 1 were retransmitted, and arrived *after* a Request packet with ID 2, it could be erroneously thought by the peer to represent a new Request, rather than a retransmission. > One possible solution for this problem is to require the Authenticatee to remember > the ID numbers inside the EAP method (message id's between the initial > request and Success/Failure msgs). This would imply that no EAP method > should produce more than 256 requests per authentication. That would be incompatible with existing implementations, would impact re-authentication and would enable new DoS attacks. > Another solution to this problem is to prohibit simultaneous *same type* of > authentications. Again, that is incompatible with existing implementations, which can authenticate multiple users at a time. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From pana-request@research.telcordia.com Mon Jan 20 17:52:28 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03531 for ; Mon, 20 Jan 2003 17:52:28 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0KMsGej010712; Mon, 20 Jan 2003 17:54:16 -0500 (EST) Resent-Date: Mon, 20 Jan 2003 17:54:16 -0500 (EST) Old-Return-Path: Message-ID: <3E2C7E04.E84877F0@research.telcordia.com> Date: Mon, 20 Jan 2003 17:53:56 -0500 From: Subir Das X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: pana@research.telcordia.com Subject: [Fwd: Re: preserving packet order in EAP] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: Re: preserving packet order in EAP Date: Mon, 20 Jan 2003 17:10:05 -0500 (EST) From: Bernard Aboba To: eap@frascone.com CC: pana@research.telcordia.com On Monday, January 20, 2003 Dan Forsberg wrote: > EAP requires that packet order is maintained by the lower layer. My > concern is that EAP can't be carried by UDP or IP alone, because these > protocols do not preserve the packet order? Those transports are illegal, because they don't preserve order, correct. > TCP/SCTP would be another option to carry EAP, but EAP detects > duplicates and does re-transmissions already. Yes, those transports would be fine, providing that they provide the appropriate security -- namely per-packet integrity and authentication. > Another comment/question: > Isn't EAP request-response style protocol, so what are the > possibilites/consequences for packet order mismatch? The issue comes up since RFC 2284 doesn't require the Identifier space to be monotonically increasing. That means that if a Request packet with ID 1 were retransmitted, and arrived *after* a Request packet with ID 2, it could be erroneously thought by the peer to represent a new Request, rather than a retransmission. > One possible solution for this problem is to require the Authenticatee to remember > the ID numbers inside the EAP method (message id's between the initial > request and Success/Failure msgs). This would imply that no EAP method > should produce more than 256 requests per authentication. That would be incompatible with existing implementations, would impact re-authentication and would enable new DoS attacks. > Another solution to this problem is to prohibit simultaneous *same type* of > authentications. Again, that is incompatible with existing implementations, which can authenticate multiple users at a time. From pana-request@research.telcordia.com Tue Jan 21 02:19:31 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22822 for ; Tue, 21 Jan 2003 02:19:23 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0L7I4SU000975; Tue, 21 Jan 2003 02:18:04 -0500 (EST) Resent-Date: Tue, 21 Jan 2003 02:18:04 -0500 (EST) Old-Return-Path: Date: Mon, 20 Jan 2003 23:14:05 -0800 Subject: Re: [eap] Re: preserving packet order in EAP From: Alper Yegin To: Bernard Aboba , CC: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit On 1/20/03 12:46 PM, "Bernard Aboba" wrote: > On Monday, January 20, 2003 Dan Forsberg wrote: > >> EAP requires that packet order is maintained by the lower layer. My >> concern is that EAP can't be carried by UDP or IP alone, because these >> protocols do not preserve the packet order? > > Those transports are illegal, because they don't preserve order, correct. If UDP or ICMP is used as transport, couldn't an identifier field in the PANA header be a solution to this problem? > >> TCP/SCTP would be another option to carry EAP, but EAP detects >> duplicates and does re-transmissions already. > > Yes, those transports would be fine, providing that they provide the > appropriate security -- namely per-packet integrity and authentication. > Assuming we are talking about per-(data-)packet integrity and authentication after the initial authentication, how is this related to the EAP transport? Regardless of the EAP transport, that protection should be provided by physical, link-layer or network-layer mechanisms. alper >> Another comment/question: >> Isn't EAP request-response style protocol, so what are the >> possibilites/consequences for packet order mismatch? > > The issue comes up since RFC 2284 doesn't require the Identifier space to > be monotonically increasing. That means that if a Request packet with ID 1 > were retransmitted, and arrived *after* a Request packet with ID 2, it > could be erroneously thought by the peer to represent a new Request, > rather than a retransmission. > >> One possible solution for this problem is to require the Authenticatee to >> remember >> the ID numbers inside the EAP method (message id's between the initial >> request and Success/Failure msgs). This would imply that no EAP method >> should produce more than 256 requests per authentication. > > That would be incompatible with existing implementations, would > impact re-authentication and would enable new DoS attacks. > >> Another solution to this problem is to prohibit simultaneous *same type* of >> authentications. > > Again, that is incompatible with existing implementations, which can > authenticate multiple users at a time. > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From pana-request@research.telcordia.com Tue Jan 21 02:38:38 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23067 for ; Tue, 21 Jan 2003 02:38:38 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0L7eD47001961; Tue, 21 Jan 2003 02:40:13 -0500 (EST) Resent-Date: Tue, 21 Jan 2003 02:40:13 -0500 (EST) Old-Return-Path: Date: Mon, 20 Jan 2003 23:39:04 -0800 Subject: Re: [Fwd: RE: comments on draft-ietf-pana-threats-01.txt] From: Alper Yegin To: Bernard Aboba , Message-ID: In-Reply-To: <3E2C7C48.69D50AAD@research.telcordia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit On 1/20/03 2:46 PM, "Subir Das" wrote: >>> So how do you prevent hijacking? >>> >> By setting up SAs. Once the authentication is complete, it is assumed that >> keys can be derived using the EAP framework (this is where PANA needs to >> provide additional details for 4-way) and that can be used as input to >> securing the future communications. I agree that these details >> are missing as to how this will happen. The service theft section discusses >> this to the extent that there are vulnerabilities but it does not >> go into details about what could be done as it was outside the scope of >> the threats evaluation document itself. It says ".... PANA should be able >> to provide keys...". I will clarify this further. > > EAP is not a good mechanism for keying IPsec SAs -- unless perhaps you > were to run IKE over EAP. When needed (that is, in the absence of phy and L2 protection), the current thinking is to run IKE after PANA... PANA would help create (bootstrap) a shared secret for IKE to build the needed SAs for IPsec.. alper From pana-request@research.telcordia.com Tue Jan 21 03:30:02 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23581 for ; Tue, 21 Jan 2003 03:30:02 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0L8VQpj004236; Tue, 21 Jan 2003 03:31:26 -0500 (EST) Resent-Date: Tue, 21 Jan 2003 03:31:26 -0500 (EST) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [eap] Re: preserving packet order in EAP Date: Tue, 21 Jan 2003 10:31:03 +0200 Message-ID: Thread-Topic: [eap] Re: preserving packet order in EAP Thread-Index: AcLBI5MP8g5rcy7ER0G8hincW7tIhwAAhSuQ From: To: , Cc: X-OriginalArrivalTime: 21 Jan 2003 08:31:04.0311 (UTC) FILETIME=[6FC8C870:01C2C127] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: <5CX2wD.A.FCB.eVQL-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA23581 removed eap mailing list from cc. comments below. > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 21 January, 2003 08:52 > To: Alper Yegin > Cc: eap@frascone.com; pana@research.telcordia.com > Subject: Re: [eap] Re: preserving packet order in EAP > > > > > Those transports are illegal, because they don't preserve > order, correct. > > > > If UDP or ICMP is used as transport, couldn't an identifier field > > in the PANA header be a solution to this problem? > > If you're saying that PANA would define its own transport > over UDP that > preserved ordering, yes that would work. > > > > Yes, those transports would be fine, providing that they > provide the > > > appropriate security -- namely per-packet integrity and > authentication. > > > > > > > Assuming we are talking about per-(data-)packet integrity > and authentication > > after the initial authentication, how is this related to the EAP > > transport? Regardless of the EAP transport, that protection should > > be provided by physical, link-layer or network-layer mechanisms. > > It is related because otherwise you have not tied the key > that is derived > in EAP to subsequent data and you have a vulnerability to > hijacking. So > you might have used EAP for authentication -- but security > has not been > achieved. I don't know if I understood all, but if EAP key derivation is used to bootstrap (IKE) the per-packet protection, then this would not be the case (Alper mentioned this previously in PANA list). Similar to PIC, for example, which is vulnerable to the MitM, though. > > There are also issues relating to protection of the EAP > exchange itself. > Those can presumably be solved by choice of method -- but if PANA also > does not make any recommendations in that department, then > that is also a > vulnerability. > EAP methods are required to clarify their security level. It would make sense for PANA to clarify what security level is needed with PANA protocol. PANA could also have security enhancing features, that require less security from EAP methods. One example could be replay and integrity protection. - Dan From pana-request@research.telcordia.com Tue Jan 21 14:51:37 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10310 for ; Tue, 21 Jan 2003 14:51:37 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0LJppf2029082; Tue, 21 Jan 2003 14:51:51 -0500 (EST) Resent-Date: Tue, 21 Jan 2003 14:51:51 -0500 (EST) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: FW: Usage Scenarios I-D - Review comments Date: Tue, 21 Jan 2003 13:46:08 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF4401752E37@daebe007.americas.nokia.com> Thread-Topic: [PANA] Review Request of the Usage Scenarios I-D Thread-Index: AcK9Gxq23o0CqdZlQ8asdlbJONUcywEanGLw From: To: Cc: , X-OriginalArrivalTime: 21 Jan 2003 19:46:09.0690 (UTC) FILETIME=[BEDF1FA0:01C2C185] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA10310 Review of Pana Usage Scenarios Draft, dated October 25, 2002. Reviewed by John Vollbrect Comments. 1. The draft makes a good start at defining a set of possible applications for a protocol that supports a standard way of authenticating network access. The list of applications is useful in understanding the range of what PANA will be expected to support. The list is impressive in its scope and the knowledge the authors have of requirements and implementations in very diverse areas. In general it seems to be saying that authenticating network access is always a good thing, and it should not be necessary to reinvent a method to do that for every new media/ link layer that is implemented. I agree. 2. One application not included in the list of applications - and I think should be - is network to network connections. There is some discussion of connecting PANs (personal area Networks) to a net, but the concept of connecting two large subnets was not addressed. If this is included, it will impact some of the naming considerations as well as helping to point out the need for mutual authentication between what is now called the Device and the PAA. 3. The draft suggests that PANA can be used to support a number of applications, but does not say why existing solutions are not useful. In particular, it seems that 802.1x attempts to do much of what PANA is describing at the link layer. While the draft describes overhead for PPP as a drawback, it does not address deficiencies in 802.1x that would be addressed by PANA. Perhaps this is ok - PANA may decide to use 802.1x? 4. I think the trust relationships expected in the PANA environment need to be clearer. In particular the relationship between the PaC, the PAA, the EP, the Access Point or Access Router and the Device should be described. There are a number of relationships that are discussed in the document that are possible individually, but without some clearer indication of the model for trust relationships that are expected in the PANA environment as well as thosed created by PANA protocol transactions, the discussion is hard to follow. 5. The assertion is made (p.4) that a network layer transport for EAP would be better than PPP because it would not have the PPP overhead. This may be true, but it is not clear to me that a network layer transport would not have similar overhead. 6. PANA is suggested as an alternative to WEB based authentication. My understanding of why the HTTPS authentication schemes have been developed is that there are no EAP clients universally available to support an equivalent user interaction. Making PaC software available everywhere that allowed authentication by prompting the user for id/pw would be very popular, but it does not show what PANA provides that existing protocols don't or couldn't by extension. Again this is not a bad thing if PANA might choose existing protocols. 7. One of the things I have thought to be a characteristic of PANA goals, the ability to authenticate before having a permanent IP address, does not seem to be mentioned. 8. The document uses the term "link layer agnostic". I am not sure what this means exactly. One discussion I have had with some of the PANA group indicated that the idea is to force a level 2 connection and then do PANA over that. If this is the idea, it would be better said explicitly. If not, it would be good to say what link layer agnostic means in practice. 802 is trying to use 802.1x as its link layer agnostic authentication protocol. It also is developing Key Exchange Protocols for establishing session keys where necessary. They are different but related protocols. Summary/ Recommendation I think this document provides a good starting point for an architecture design group. PANA does have initial architecture with elements like PaC, PAA, etc. I would like to see it also describe trust relationships and transactions that create new "access session trust". If this is not what PANA does, then a clearer definition of what PANA will do is needed. My suggestion is that the applications in this draft be used as the basis for a next draft which describes these applications in terms of the PANA elements and transactions. Once that is done it would be possible to describe specific protocols required to support specific transactions. There is parallel work being done in a number of places. For example access control protocol work is being done in IEEE 802.1x, 802.11i, and EAP working groups. Some helpful work has been done in the AAAArch Research group - RFCs 2904 and 2905 could be good background material. PANA might provide some architectural support for these groups rather than define a new protocol. In my opinion PANA has staked out an interesting problem space, but has not made clear why a new protocol is needed. The applications described in the draft all require authentication and some require access management or provisioning. It is an impressive list, and if it can be shown that a single Protocol/architecture could support all of them that would be a major step forward. John Vollbrecht jrv@umich.edu From pana-request@research.telcordia.com Tue Jan 21 21:06:45 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18607 for ; Tue, 21 Jan 2003 21:06:44 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0M27CtG022716; Tue, 21 Jan 2003 21:07:12 -0500 (EST) Resent-Date: Tue, 21 Jan 2003 21:07:12 -0500 (EST) Old-Return-Path: Date: Tue, 21 Jan 2003 21:06:57 -0500 To: Basavaraj.Patil@nokia.com Cc: pana@research.telcordia.com, jrv@umich.edu, narten@us.ibm.com Subject: Re: FW: Usage Scenarios I-D - Review comments Message-ID: <20030122020657.GE2170@catfish> Mail-Followup-To: Basavaraj.Patil@nokia.com, pana@research.telcordia.com, jrv@umich.edu, narten@us.ibm.com References: <697DAA22C5004B4596E033803A7CEF4401752E37@daebe007.americas.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <697DAA22C5004B4596E033803A7CEF4401752E37@daebe007.americas.nokia.com> User-Agent: Mutt/1.5.3i From: Yoshihiro Ohba X-Dispatcher: imput version 20021213(IM143) Lines: 180 X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: <3bAd2B.A.0iF.PzfL-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com This is my attempt to respond to John Vollbrect's comments. Thanks, Yoshihiro Ohba On Tue, Jan 21, 2003 at 01:46:08PM -0600, Basavaraj.Patil@nokia.com wrote: > > Review of Pana Usage Scenarios Draft, > dated October 25, 2002. > > Reviewed by John Vollbrect > > Comments. > > 1. The draft makes a good start at defining a set of possible applications > for a protocol that supports a standard way of authenticating network > access. The list of applications is useful in understanding the range of > what PANA will be expected to support. The list is impressive in its scope > and the knowledge the authors have of requirements and implementations in > very diverse areas. In general it seems to be saying that authenticating > network access is always a good thing, and it should not be necessary to > reinvent a method to do that for every new media/ link layer that is > implemented. I agree. OK. > > 2. One application not included in the list of applications - and I think > should be - is network to network connections. There is some discussion of > connecting PANs (personal area Networks) to a net, but the concept of > connecting two large subnets was not addressed. If this is included, it > will impact some of the naming considerations as well as helping to point > out the need for mutual authentication between what is now called the > Device and the PAA. In the case of connecting two large subnets, I think the connection is static in most current usages, so this scenario might be supported by simply using IPsec tunnel mode with IKE for mutually authenticating the peering gateways and establishing an appropriate IPsec SA, based on a shared secret or digital certificates for IKE to be set up when installing the peering gateways. So I think PANA might not be useful for the proposed scenario. > > 3. The draft suggests that PANA can be used to support a number of > applications, but does not say why existing solutions are not useful. In > particular, it seems that 802.1x attempts to do much of what PANA is > describing at the link layer. While the draft describes overhead for PPP > as a drawback, it does not address deficiencies in 802.1x that would be > addressed by PANA. Perhaps this is ok - PANA may decide to use 802.1x? Replacing 802.1X is not a goal of PANA, but this does not necessary mean that PANA may decide to use 802.1X. This is because (1) IEEE 802 is not the only link layer on which IP is expected to run, and (2) even in IEEE 802 networks, if 802.1X is not deployed yet but authentication is somehow needed (the statement is applicable to some DSL networks), then a protocol like PANA might be useful. We can clarify this in the next version of the draft. > > 4. I think the trust relationships expected in the PANA environment need to > be clearer. In particular the relationship between the PaC, the PAA, the > EP, the Access Point or Access Router and the Device should be described. > There are a number of relationships that are discussed in the document that > are possible individually, but without some clearer indication of the model > for trust relationships that are expected in the PANA environment as well > as thosed created by PANA protocol transactions, the discussion is hard to > follow. I agree. We will mention the trust relationships expected among entities related to PANA in the next version. > > 5. The assertion is made (p.4) that a network layer transport for EAP would > be better than PPP because it would not have the PPP overhead. This may be > true, but it is not clear to me that a network layer transport would not > have similar overhead. If we just consider the overhead of carrying EAP, we might argue "EAP over IP over link-layer" vs "EAP over PPP over link-layer". But if we also consider the overhead of carrying data traffic, "IP over link-layer" has always less overhead than "IP over PPP over link-layer". Does this clarify the point? > > 6. PANA is suggested as an alternative to WEB based authentication. My > understanding of why the HTTPS authentication schemes have been developed > is that there are no EAP clients universally available to support an > equivalent user interaction. Making PaC software available everywhere that > allowed authentication by prompting the user for id/pw would be very > popular, but it does not show what PANA provides that existing protocols > don't or couldn't by extension. Again this is not a bad thing if PANA > might choose existing protocols. I think PAA discovery and authentication initiation from PAA is difficult with using https solely. It might be possible to use https to carry EAP but define a new protocol only for PAA discovery. However, I don't think just running EAP over https is enough. We might need to define additional rules such as when TLS connection needs to shutdown or in which case TLS connection can (or must) be persistently open, how a device identifier is protected from man-in-the-middle attack during authentication conversation, as well as message formats. But isn't it almost equivalent to define a new protocol on top of http over TLS rather than extension, and isn't http just another overhead for carrying EAP? > > 7. One of the things I have thought to be a characteristic of PANA goals, > the ability to authenticate before having a permanent IP address, does not > seem to be mentioned. I'm not sure what a permanent IP address exactly mean, but at least a temporary IP address can be used to autenticate before having a globally routable IP address. > > 8. The document uses the term "link layer agnostic". I am not sure what > this means exactly. One discussion I have had with some of the PANA group > indicated that the idea is to force a level 2 connection and then do PANA > over that. If this is the idea, it would be better said explicitly. If > not, it would be good to say what link layer agnostic means in practice. > 802 is trying to use 802.1x as its link layer agnostic authentication > protocol. It also is developing Key Exchange Protocols for establishing > session keys where necessary. They are different but related protocols. I agree that the term "link layer agnostic" is not clear. We will revise the term in the next version. We will also state that PANA is to be performed after layer-2 connection is established. > > > > Summary/ Recommendation > > I think this document provides a good starting point for an architecture > design group. PANA does have initial architecture with elements like PaC, > PAA, etc. I would like to see it also describe trust relationships and > transactions that create new "access session trust". If this is not what > PANA does, then a clearer definition of what PANA will do is needed. OK. > > My suggestion is that the applications in this draft be used as the basis > for a next draft which describes these applications in terms of the PANA > elements and transactions. Once that is done it would be possible to > describe specific protocols required to support specific transactions. I think ongoing work on PANA framework could serve for that purpose. > > There is parallel work being done in a number of places. For example > access control protocol work is being done in IEEE 802.1x, 802.11i, and EAP > working groups. Some helpful work has been done in the AAAArch Research > group - RFCs 2904 and 2905 could be good background material. PANA > might provide some architectural support for these groups rather than > define a new protocol. Please see my above comments on https. > > In my opinion PANA has staked out an interesting problem space, but has not > made clear why a new protocol is needed. The applications described in the > draft all require authentication and some require access management or > provisioning. It is an impressive list, and if it can be shown that a > single Protocol/architecture could support all of them that would be a > major step forward. We'll try to reflect all of your comments to make specific points clearer. > > John Vollbrecht > jrv@umich.edu > Thanks again. From pana-request@research.telcordia.com Tue Jan 21 21:13:32 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18733 for ; Tue, 21 Jan 2003 21:13:27 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0M2EwZC022996; Tue, 21 Jan 2003 21:14:58 -0500 (EST) Resent-Date: Tue, 21 Jan 2003 21:14:58 -0500 (EST) Old-Return-Path: Date: Tue, 21 Jan 2003 18:14:05 -0800 Subject: Re: Usage Scenarios I-D - Review comments From: Alper Yegin To: , CC: , Message-ID: In-Reply-To: <697DAA22C5004B4596E033803A7CEF4401752E37@daebe007.americas.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Thank you John for your review and comments. I have some responses inlined below. > 2. One application not included in the list of applications - and I think > should be - is network to network connections. There is some discussion of > connecting PANs (personal area Networks) to a net, but the concept of > connecting two large subnets was not addressed. If this is included, it > will impact some of the naming considerations as well as helping to point > out the need for mutual authentication between what is now called the > Device and the PAA. This is interesting. The current scheme might be fine as long as there is a client-master relation between the two networks (like one is an access network, the other is an mobile network). But when it's peer-to-peer, this might not be true. > > 3. The draft suggests that PANA can be used to support a number of > applications, but does not say why existing solutions are not useful. In > particular, it seems that 802.1x attempts to do much of what PANA is > describing at the link layer. While the draft describes overhead for PPP > as a drawback, it does not address deficiencies in 802.1x that would be > addressed by PANA. Perhaps this is ok - PANA may decide to use 802.1x? We should clarify this better in the draft. 802.1x is not link-agnostic, as it only runs over IEEE 802 types. PANA is aiming at running over any link that IP can run. > > 4. I think the trust relationships expected in the PANA environment need to > be clearer. In particular the relationship between the PaC, the PAA, the > EP, the Access Point or Access Router and the Device should be described. > There are a number of relationships that are discussed in the document that > are possible individually, but without some clearer indication of the model > for trust relationships that are expected in the PANA environment as well > as thosed created by PANA protocol transactions, the discussion is hard to > follow. Good point. Discussing the trust relations would help in explaining the scenarios. > > 5. The assertion is made (p.4) that a network layer transport for EAP would > be better than PPP because it would not have the PPP overhead. This may be > true, but it is not clear to me that a network layer transport would not > have similar overhead. > In cases where PPP is used just as a carrier for authentication, its presence even after the authentication phase is unnecessary (but you cannot get rid of it). Carrying EAP above IP won't incur this additional (and persistent) layer. > 6. PANA is suggested as an alternative to WEB based authentication. My > understanding of why the HTTPS authentication schemes have been developed > is that there are no EAP clients universally available to support an > equivalent user interaction. Making PaC software available everywhere that > allowed authentication by prompting the user for id/pw would be very > popular, but it does not show what PANA provides that existing protocols > don't or couldn't by extension. Again this is not a bad thing if PANA > might choose existing protocols. Web based authentication is a temporary solution to the problem, I agree. People would like to migrate to better solutions from there as they become available. PANA can be one of the candidates depending on the scenario. Please note that web based authentication is not only applicable/used/considered for WLAN. People are considering it (if not deploying already) even for DSL access when no proper authentication protocol is present. > > 7. One of the things I have thought to be a characteristic of PANA goals, > the ability to authenticate before having a permanent IP address, does not > seem to be mentioned. We can mention this, although none of the scenarios is really capturing this feature. > > 8. The document uses the term "link layer agnostic". I am not sure what > this means exactly. One discussion I have had with some of the PANA group > indicated that the idea is to force a level 2 connection and then do PANA > over that. Assumption is that Layer-2 connection is allowed for a limited access to enable PANA exchange. This assumption means different things in different scenarios. for example in DSL scenarios where PANA is needed, subscriber can already send and receive IP packets. Or in 3GPP2, radio link is already established. > If this is the idea, it would be better said explicitly. If > not, it would be good to say what link layer agnostic means in practice. > 802 is trying to use 802.1x as its link layer agnostic authentication > protocol. I suspect the scope is important here. 802.1x might be called "link layer agnostic" with respect to IEEE 802 links, but not necessarily for all links that IP can run on. > It also is developing Key Exchange Protocols for establishing > session keys where necessary. They are different but related protocols. > > > > Summary/ Recommendation > > I think this document provides a good starting point for an architecture > design group. PANA does have initial architecture with elements like PaC, > PAA, etc. I would like to see it also describe trust relationships and > transactions that create new "access session trust". If this is not what > PANA does, then a clearer definition of what PANA will do is needed. > > My suggestion is that the applications in this draft be used as the basis > for a next draft which describes these applications in terms of the PANA > elements and transactions. Once that is done it would be possible to > describe specific protocols required to support specific transactions. > > There is parallel work being done in a number of places. For example > access control protocol work is being done in IEEE 802.1x, 802.11i, and EAP > working groups. Some helpful work has been done in the AAAArch Research > group - RFCs 2904 and 2905 could be good background material. PANA > might provide some architectural support for these groups rather than > define a new protocol. There are clearly some relations between PANA and the above mentioned components. But I'm not sure if any of them is a substitue for what PANA is aiming at. > In my opinion PANA has staked out an interesting problem space, but has not > made clear why a new protocol is needed. The applications described in the > draft all require authentication and some require access management or > provisioning. It is an impressive list, and if it can be shown that a > single Protocol/architecture could support all of them that would be a > major step forward. For that, we are identifying various scenarios and breaking down the problem into managable, modular components. Carrying EAP above IP seems like a common component that is needed by all, and that can satisfy some scenarios on its own, but not all of the scenarios of course. alper > > John Vollbrecht > jrv@umich.edu > > > From pana-request@research.telcordia.com Wed Jan 22 06:09:56 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21778 for ; Wed, 22 Jan 2003 06:09:38 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0MB9EMe017663; Wed, 22 Jan 2003 06:09:14 -0500 (EST) Resent-Date: Wed, 22 Jan 2003 06:09:14 -0500 (EST) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [eap] Re: preserving packet order in EAP Date: Wed, 22 Jan 2003 13:05:20 +0200 Message-ID: Thread-Topic: [eap] Re: preserving packet order in EAP Thread-Index: AcLBM/SlHWo9cJD4R4im0yQCN219FgAxkEVw From: To: Cc: , X-OriginalArrivalTime: 22 Jan 2003 11:05:22.0332 (UTC) FILETIME=[28686DC0:01C2C206] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA21778 > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 21 January, 2003 10:50 > To: Forsberg Dan (NRC/Helsinki) > Cc: alper@docomolabs-usa.com; pana@research.telcordia.com > Subject: RE: [eap] Re: preserving packet order in EAP > > > > I don't know if I understood all, but if EAP key derivation > is used to > > bootstrap (IKE) the per-packet protection, then this would > not be the > > case (Alper mentioned this previously in PANA list). > Similar to PIC, for > > example, which is vulnerable to the MitM, though. > > I think it is a bit different because in that case, the EAP > derived keys > are used as a bootstrap, but the EAP exchange itself does not > occur within > a tunnel. Is there a MiTM attack that is possible in such a situation? > If this is the scheme that PANA is recommending, then I would > recommend a > security analysis be done so that the properties of the > scheme are well > understood from the start. > > > EAP methods are required to clarify their security level. > It would make > > sense for PANA to clarify what security level is needed with PANA > > protocol. > > Yes. My guess is that in wireless scenarios, PANA would probably have > requirements equivalent to IEEE 802.11i. In wired scenarios, the > requirements might be considerably less. > > > PANA could also have security enhancing features, that require > > less security from EAP methods. One example could be replay and > > integrity protection. > > This is where the MiTM issue rears its head. You might think > that because > the lower layer provides confidentiality, integrity and > replay protection > that the EAP method can be less secure. But > draft-puthenkulam-eap-binding-01.txt shows that the opposite > is true -- > that without crytpographic binding (only achievable for > methods that are > mutually authenticating and derive keys), a MiTM attack can > be mounted. > > So, it wouldn't appear that lower layer security has that much > effect on EAP method requirements. > TLS requires certificate from the server (AN). PaC could use a PK to authenticate/verify the AN certificate and further authenticate the AN. If PaC has the PK of the AAAH/AS, it can use it to encrypt the TLS session key and a shared secret (password etc.) plus random/nonce/timestamp etc. to create a cryptographic binding between the tunnel and something that the PaC and AAAH/AS only knows (shared secret). PAA would then send the TLS Session key (or hash of it) to the AAAH in a secure way. In this way weak EAP methods can also be used in a more secure way. This requires that the AAAH can verify the data from PaC (i.e. needs to fetch the shared secret from the AS or let the AS do the verification) and that the PaC is able to use the shared secret for this purpose. - Dan From pana-request@research.telcordia.com Wed Jan 22 12:54:05 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02251 for ; Wed, 22 Jan 2003 12:53:49 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0MHsj9M015015; Wed, 22 Jan 2003 12:54:45 -0500 (EST) Resent-Date: Wed, 22 Jan 2003 12:54:45 -0500 (EST) Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C23F.3F35FE92" Subject: draft-pana-threats-eval-01.txt Date: Wed, 22 Jan 2003 09:54:01 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A3A1@TNEXVS02.tahoenetworks.com> Thread-Topic: draft-pana-threats-eval-01.txt Thread-Index: AcLCP0Ne4YbbbuptSpGrDORQcd8ouw== From: "Mohan Parthasarathy" To: X-OriginalArrivalTime: 22 Jan 2003 17:54:02.0077 (UTC) FILETIME=[3F5098D0:01C2C23F] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com This is a multi-part message in MIME format. ------_=_NextPart_001_01C2C23F.3F35FE92 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I never saw the announcement on the list the next revision of pana = threats document. This is the one that Bernard sent his comments about : http://www.ietf.org/internet-drafts/draft-ietf-pana-threats-eval-01.txt Your feedback is welcome. FYI mohan ------_=_NextPart_001_01C2C23F.3F35FE92 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-pana-threats-eval-01.txt

I never saw the announcement on the = list the next revision of pana threats document.
This is the one that Bernard sent his = comments about :

http://www.ietf.org/internet-drafts/draft-ietf-pana-threats-eval-= 01.txt

Your feedback is welcome.

FYI
mohan

------_=_NextPart_001_01C2C23F.3F35FE92-- From pana-request@research.telcordia.com Wed Jan 22 16:50:02 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08647 for ; Wed, 22 Jan 2003 16:50:02 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0MLov8H001548; Wed, 22 Jan 2003 16:50:57 -0500 (EST) Resent-Date: Wed, 22 Jan 2003 16:50:57 -0500 (EST) Old-Return-Path: Date: Wed, 22 Jan 2003 13:50:17 -0800 Subject: FW: [eap] Re: preserving packet order in EAP From: Alper Yegin To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit There are few more e-mails that escaped the mailing list. Let me forward them here... This problem should be fixed, hopefully no more forwards are necessary after these few.. alper ------ Forwarded Message From: Bernard Aboba Date: Mon, 20 Jan 2003 22:52:19 -0800 (PST) To: Alper Yegin Cc: eap@frascone.com, Subject: Re: [eap] Re: preserving packet order in EAP > > Those transports are illegal, because they don't preserve order, correct. > > If UDP or ICMP is used as transport, couldn't an identifier field > in the PANA header be a solution to this problem? If you're saying that PANA would define its own transport over UDP that preserved ordering, yes that would work. > > Yes, those transports would be fine, providing that they provide the > > appropriate security -- namely per-packet integrity and authentication. > > > > Assuming we are talking about per-(data-)packet integrity and authentication > after the initial authentication, how is this related to the EAP > transport? Regardless of the EAP transport, that protection should > be provided by physical, link-layer or network-layer mechanisms. It is related because otherwise you have not tied the key that is derived in EAP to subsequent data and you have a vulnerability to hijacking. So you might have used EAP for authentication -- but security has not been achieved. There are also issues relating to protection of the EAP exchange itself. Those can presumably be solved by choice of method -- but if PANA also does not make any recommendations in that department, then that is also a vulnerability. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap ------ End of Forwarded Message From pana-request@research.telcordia.com Wed Jan 22 16:50:10 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08660 for ; Wed, 22 Jan 2003 16:50:09 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0MLpijB001600; Wed, 22 Jan 2003 16:51:44 -0500 (EST) Resent-Date: Wed, 22 Jan 2003 16:51:44 -0500 (EST) Old-Return-Path: Date: Wed, 22 Jan 2003 13:50:48 -0800 Subject: FW: [eap] Re: preserving packet order in EAP From: Alper Yegin To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit another one... ------ Forwarded Message From: Bernard Aboba Date: Mon, 20 Jan 2003 22:59:56 -0800 (PST) To: Alper Yegin Cc: eap@frascone.com, , Subject: Re: [eap] Re: preserving packet order in EAP Overall, it is important to understand that PANA (and IEEE 802.11i for that matter) represent very major extensions to the existing EAP usage model. RFC 2284 was created with the assumption that the underlying physical medium was secure, as was IEEE 802.1X (which was created for use with wired networks only). Where EAP is run over wireless that is not the case. This greatly expands the potential security vulnerabilities. IEEE 802.11i has put in substantial effort to address these issues: addition of a "third leg" of mutual auth and key derivation between the NAS and client; proper key wrapping between the AAA server and NAS; definition of the key hierarchy, both for individual sessions, and for fast handoff; support for pre-authentication; EAP method requirements. To get an idea of what you're up against, I would suggest a careful reading of IEEE 802.11i. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap ------ End of Forwarded Message From pana-request@research.telcordia.com Wed Jan 22 16:51:29 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08713 for ; Wed, 22 Jan 2003 16:51:28 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0MLr1Og001691; Wed, 22 Jan 2003 16:53:01 -0500 (EST) Resent-Date: Wed, 22 Jan 2003 16:53:01 -0500 (EST) Old-Return-Path: Date: Wed, 22 Jan 2003 13:52:08 -0800 Subject: FW: [eap] Re: preserving packet order in EAP From: Alper Yegin To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit and this is the last one... sorry for the inconvenience these out-of-order fwds created. alper ------ Forwarded Message From: Bernard Aboba Date: Tue, 21 Jan 2003 00:50:10 -0800 (PST) To: Dan.Forsberg@nokia.com Cc: alper@docomolabs-usa.com, Subject: RE: [eap] Re: preserving packet order in EAP > I don't know if I understood all, but if EAP key derivation is used to > bootstrap (IKE) the per-packet protection, then this would not be the > case (Alper mentioned this previously in PANA list). Similar to PIC, for > example, which is vulnerable to the MitM, though. I think it is a bit different because in that case, the EAP derived keys are used as a bootstrap, but the EAP exchange itself does not occur within a tunnel. Is there a MiTM attack that is possible in such a situation? If this is the scheme that PANA is recommending, then I would recommend a security analysis be done so that the properties of the scheme are well understood from the start. > EAP methods are required to clarify their security level. It would make > sense for PANA to clarify what security level is needed with PANA > protocol. Yes. My guess is that in wireless scenarios, PANA would probably have requirements equivalent to IEEE 802.11i. In wired scenarios, the requirements might be considerably less. > PANA could also have security enhancing features, that require > less security from EAP methods. One example could be replay and > integrity protection. This is where the MiTM issue rears its head. You might think that because the lower layer provides confidentiality, integrity and replay protection that the EAP method can be less secure. But draft-puthenkulam-eap-binding-01.txt shows that the opposite is true -- that without crytpographic binding (only achievable for methods that are mutually authenticating and derive keys), a MiTM attack can be mounted. So, it wouldn't appear that lower layer security has that much effect on EAP method requirements. ------ End of Forwarded Message From pana-request@research.telcordia.com Wed Jan 22 17:00:07 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09097 for ; Wed, 22 Jan 2003 17:00:07 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0MM1qMS002214; Wed, 22 Jan 2003 17:01:52 -0500 (EST) Resent-Date: Wed, 22 Jan 2003 17:01:52 -0500 (EST) Old-Return-Path: Date: Wed, 22 Jan 2003 14:01:02 -0800 Subject: Re: [eap] Re: preserving packet order in EAP From: Alper Yegin To: Bernard Aboba CC: , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit >>> Those transports are illegal, because they don't preserve order, correct. >> >> If UDP or ICMP is used as transport, couldn't an identifier field >> in the PANA header be a solution to this problem? > > If you're saying that PANA would define its own transport over UDP that > preserved ordering, yes that would work. > Yes, that's one possibility. >>> Yes, those transports would be fine, providing that they provide the >>> appropriate security -- namely per-packet integrity and authentication. >>> >> >> Assuming we are talking about per-(data-)packet integrity and authentication >> after the initial authentication, how is this related to the EAP >> transport? Regardless of the EAP transport, that protection should >> be provided by physical, link-layer or network-layer mechanisms. > > It is related because otherwise you have not tied the key that is derived > in EAP to subsequent data and you have a vulnerability to hijacking. So > you might have used EAP for authentication -- but security has not been > achieved. Definitely agreed. My point was, regardless of whether EAP was carried over UDP, or ICMP, or TCP, I suspect this tying of key to subsequent data would happen the same way. > > There are also issues relating to protection of the EAP exchange itself. > Those can presumably be solved by choice of method -- but if PANA also > does not make any recommendations in that department, then that is also a > vulnerability. Agreed. alper > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > > ------ End of Forwarded Message > > From pana-request@research.telcordia.com Wed Jan 22 17:33:13 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10055 for ; Wed, 22 Jan 2003 17:33:04 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0MMYU0q004365; Wed, 22 Jan 2003 17:34:30 -0500 (EST) Resent-Date: Wed, 22 Jan 2003 17:34:30 -0500 (EST) Old-Return-Path: Date: Wed, 22 Jan 2003 14:33:34 -0800 Subject: Re: [eap] Re: preserving packet order in EAP From: Alper Yegin To: Bernard Aboba CC: , , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > ------ Forwarded Message > From: Bernard Aboba > Date: Mon, 20 Jan 2003 22:59:56 -0800 (PST) > To: Alper Yegin > Cc: eap@frascone.com, , > Subject: Re: [eap] Re: preserving packet order in EAP > > Overall, it is important to understand that PANA (and IEEE 802.11i for > that matter) represent very major extensions to the existing EAP usage > model. RFC 2284 was created with the assumption that the underlying > physical medium was secure, as was IEEE 802.1X (which was created for use > with wired networks only). Where EAP is run over wireless that is not the > case. This greatly expands the potential security vulnerabilities. > > IEEE 802.11i has put in substantial effort to address these issues: > addition of a "third leg" of mutual auth and key derivation > between the NAS and client; proper key wrapping between the AAA server and > NAS; definition of the key hierarchy, both for individual sessions, and > for fast handoff; support for pre-authentication; EAP method requirements. > > To get an idea of what you're up against, I would suggest a careful > reading of IEEE 802.11i. Obviously this is not a task that should be underestimated. But there are few things that needs to be noted here. The case 802.11i handles is the hardest case that PANA can be used for. That is: using PANA in the absence of any lower layer security. Before that case there are two other simpler ones. Namely, using PANA over physically secure links (e.g., DSL), and over already secured link-layers (e.g., 3GPP/3GPP2). One possible approach is to identify the common element among all these scenarios and develop a modular solution set. Developing an EAP carrier above IP seems to be the common denominator among these three. This piece by itself should be sufficient to handle two of the cases, but not the hardest one. The solution to first two cases can be developed first. For the last case, there needs to be additional pieces in place (how to bind outcome of EAP, keys, to subsequent data by using IPsec or L2 ciphers). But that should not hold solving other cases back. As long as we keep an eye on the last case as we develop the basic building block, we shall be fine. alper From pana-request@research.telcordia.com Wed Jan 22 18:10:59 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10808 for ; Wed, 22 Jan 2003 18:10:58 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0MNCJ2J006569; Wed, 22 Jan 2003 18:12:19 -0500 (EST) Resent-Date: Wed, 22 Jan 2003 18:12:19 -0500 (EST) Old-Return-Path: Date: Wed, 22 Jan 2003 14:01:20 -0800 (PST) From: Bernard Aboba To: Alper Yegin cc: eap@frascone.com, , Subject: Re: [eap] Re: preserving packet order in EAP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com > Obviously this is not a task that should be underestimated. > > But there are few things that needs to be noted here. > > The case 802.11i handles is the hardest case that PANA can be used for. > That is: using PANA in the absence of any lower layer security. Before that > case there are two other simpler ones. Namely, using PANA over physically > secure links (e.g., DSL), and over already secured link-layers (e.g., > 3GPP/3GPP2). Yes, cases in which the link is physically secure are *much* simpler. > One possible approach is to identify the common element among > all these scenarios and develop a modular solution set. Developing an EAP > carrier above IP seems to be the common denominator among these three. This > piece by itself should be sufficient to handle two of the cases, but not the > hardest one. Yes. > The solution to first two cases can be developed first. For the last case, > there needs to be additional pieces in place (how to bind outcome of EAP, > keys, to subsequent data by using IPsec or L2 ciphers). But that should not > hold solving other cases back. As long as we keep an eye on the last case as > we develop the basic building block, we shall be fine. Yes. What I am suggesting is that there may be a need for an IP-layer equivalent to the IEEE 802.11i 4-way handshake, to secure the "third leg". From pana-request@research.telcordia.com Thu Jan 23 08:16:22 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06575 for ; Thu, 23 Jan 2003 08:16:21 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0NDGkPi017920; Thu, 23 Jan 2003 08:16:46 -0500 (EST) Resent-Date: Thu, 23 Jan 2003 08:16:46 -0500 (EST) Old-Return-Path: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15919.59782.784045.436440@gargle.gargle.HOWL> Date: Thu, 23 Jan 2003 08:09:26 -0500 From: James Carlson To: Cc: , , Subject: RE: [eap] preserving packet order in EAP? In-Reply-To: Dan.Forsberg@nokia.com's message of 20 January 2003 18:13:45 References: X-Mailer: VM 7.01 under Emacs 21.2.1 X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Dan.Forsberg@nokia.com writes: > One possible solution for this problem is to require the > Authenticatee to remember the ID numbers inside the EAP method > (message id's between the initial request and Success/Failure > msgs). This would imply that no EAP method should produce more than > 256 requests per authentication. That doesn't work because of rechallenge. (Well, unless you're willing to drop the link when you run out of ID space for rechallenges ...) > Anyway, I think this should be fixed in the EAP protocol simply > because it is standardized here in the IETF. A new issue perhaps? > EAP already provides retransmission and "duplicate" > detection. Making the duplicate detection work within this example, > would make EAP suitable for carriers such as UDP, ICMP, and IP. This > would increase the possibilities for EAP in the Internet. EAP has no problem with retransmission or duplicates (or other bad packets, for that matter). It does have a problem with reordering, and that can't actually be fixed without making the "new" version incompatible with the old. If you're going to make it incompatible, I'd suggest starting with a blank slate. EAP just wasn't designed to be used as you suggest. It needs an order-preserving peer-to-peer link. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From pana-request@research.telcordia.com Thu Jan 23 08:24:51 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06778 for ; Thu, 23 Jan 2003 08:24:50 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0NDQalx018416; Thu, 23 Jan 2003 08:26:36 -0500 (EST) Resent-Date: Thu, 23 Jan 2003 08:26:36 -0500 (EST) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [eap] preserving packet order in EAP? Date: Thu, 23 Jan 2003 15:26:28 +0200 Message-ID: Thread-Topic: [eap] preserving packet order in EAP? Thread-Index: AcLC4bBOR+NTzQq/T3qWqdMJoMjXMwAAEKug From: To: Cc: , , X-OriginalArrivalTime: 23 Jan 2003 13:26:29.0211 (UTC) FILETIME=[097962B0:01C2C2E3] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA06778 Thank you for your comments. Just a quick question. What if PANA would specify a "EAPv2" that wasn't backwards compatible with EAP but better suitable for UDP/ICMP or TCP/SCTP? This new version could carry EAP methods specified in the current EAP wg. For my understanding this wasn't the intention of PANA wg, but it would make things simpler/easier for PANA(?). Just an idea. - Dan > -----Original Message----- > From: ext James Carlson [mailto:james.d.carlson@east.sun.com] > Sent: 23 January, 2003 15:09 > To: Forsberg Dan (NRC/Helsinki) > Cc: yohba@tari.toshiba.com; pana@research.telcordia.com; > eap@frascone.com > Subject: RE: [eap] preserving packet order in EAP? > > > Dan.Forsberg@nokia.com writes: > > One possible solution for this problem is to require the > > Authenticatee to remember the ID numbers inside the EAP method > > (message id's between the initial request and Success/Failure > > msgs). This would imply that no EAP method should produce more than > > 256 requests per authentication. > > That doesn't work because of rechallenge. (Well, unless you're > willing to drop the link when you run out of ID space for rechallenges > ...) > > > Anyway, I think this should be fixed in the EAP protocol simply > > because it is standardized here in the IETF. A new issue perhaps? > > EAP already provides retransmission and "duplicate" > > detection. Making the duplicate detection work within this example, > > would make EAP suitable for carriers such as UDP, ICMP, and IP. This > > would increase the possibilities for EAP in the Internet. > > EAP has no problem with retransmission or duplicates (or other bad > packets, for that matter). It does have a problem with reordering, > and that can't actually be fixed without making the "new" version > incompatible with the old. If you're going to make it incompatible, > I'd suggest starting with a blank slate. > > EAP just wasn't designed to be used as you suggest. It needs an > order-preserving peer-to-peer link. > > -- > James Carlson, Solaris Networking > > Sun Microsystems / 1 Network Drive 71.234W Vox +1 > 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 > 781 442 1677 > From pana-request@research.telcordia.com Thu Jan 23 08:51:47 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07603 for ; Thu, 23 Jan 2003 08:51:46 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0NDp298020006; Thu, 23 Jan 2003 08:51:02 -0500 (EST) Resent-Date: Thu, 23 Jan 2003 08:51:02 -0500 (EST) Old-Return-Path: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15919.62260.336710.649460@gargle.gargle.HOWL> Date: Thu, 23 Jan 2003 08:50:44 -0500 From: James Carlson To: Dan.Forsberg@nokia.com Cc: , Subject: RE: [eap] preserving packet order in EAP? In-Reply-To: Dan.Forsberg@nokia.com's message of 23 January 2003 15:26:28 References: X-Mailer: VM 7.01 under Emacs 21.2.1 X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Dan.Forsberg@nokia.com writes: > Thank you for your comments. Just a quick question. What if PANA > would specify a "EAPv2" that wasn't backwards compatible with EAP > but better suitable for UDP/ICMP or TCP/SCTP? This new version could > carry EAP methods specified in the current EAP wg. For my > understanding this wasn't the intention of PANA wg, but it would > make things simpler/easier for PANA(?). Just an idea. That's basically what I was suggesting -- if you're going to make it incompatible, then it's not EAP anymore and isn't suitable for the EAP RFC update, but it might work for some particular domain. It seems to me that there are other issues that need to be solved, and might as well be solved while the patient is on the table. For instance, EAP assumes a peer-to-peer link. PANA and 802.11 [1] have a common problem -- the use of multiaccess media. (Note that both PPP and 802.1X are just point-to-point.) It's not the wireless aspect that's really a special problem; it's the multiaccess nature that causes all the additional security headache. Why not define something that's specific to use on multiaccess networks and that can handle bootstrapping the security association required? That new protocol (MEAP?) can certainly carry EAP-formatted messages if it wants -- after all, AAA protocols aren't EAP, but do carry EAP- formatted messages, so it's not a new concept -- but it needn't be compatible with EAP in any other way, so it doesn't need the same retransmission mechanism. I think that'd be a happier result than contorting EAP to fit into a non-EAP-shaped hole. [1] Minor digression: I leave DSL out of that list quite intentionally. DSL is most certainly a point-to-point technology, and it's made to appear to be multiaccess only by error. If you could yank out the Ethernet-over-ATM baggage and run plain PPP over HDLC on the raw bit pipe between CPE and CO, then all of the current problems -- including PPPoE and PANA -- disappear (and overhead is reduced as well). Bridged Ethernet with DHCP or routed point-to-point link: pick *one*. (It also doesn't actually require the authentication in the plain point-to-point case, since you know where the wires go physically, but it doesn't hurt.) -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From pana-request@research.telcordia.com Thu Jan 23 09:25:03 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08394 for ; Thu, 23 Jan 2003 09:25:01 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0NEQlmI022389; Thu, 23 Jan 2003 09:26:47 -0500 (EST) Resent-Date: Thu, 23 Jan 2003 09:26:47 -0500 (EST) Old-Return-Path: Date: Thu, 23 Jan 2003 09:25:59 -0500 To: James Carlson Cc: Dan.Forsberg@nokia.com, pana@research.telcordia.com, eap@frascone.com Subject: Re: [eap] preserving packet order in EAP? Message-ID: <20030123142559.GC704@catfish> Mail-Followup-To: James Carlson , Dan.Forsberg@nokia.com, pana@research.telcordia.com, eap@frascone.com References: <15919.62260.336710.649460@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <15919.62260.336710.649460@gargle.gargle.HOWL> User-Agent: Mutt/1.5.3i From: Yoshihiro Ohba X-Dispatcher: imput version 20021213(IM143) Lines: 65 X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: <6NX14B.A.tdF.mu_L-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com I agree with James, and the following is just a clarification. PIC and PoTLS are aiming to serve for carrying EAP-formatted messges over multiaccess (and any other type of) link, by logically establishing a secure, order-preserved, logical point-to-point communication channel before starting EAP conversation, based on anonymous key exchange. This is a different approach from which 802.11i is taking. Yoshihiro Ohba On Thu, Jan 23, 2003 at 08:50:44AM -0500, James Carlson wrote: > Dan.Forsberg@nokia.com writes: > > Thank you for your comments. Just a quick question. What if PANA > > would specify a "EAPv2" that wasn't backwards compatible with EAP > > but better suitable for UDP/ICMP or TCP/SCTP? This new version could > > carry EAP methods specified in the current EAP wg. For my > > understanding this wasn't the intention of PANA wg, but it would > > make things simpler/easier for PANA(?). Just an idea. > > That's basically what I was suggesting -- if you're going to make it > incompatible, then it's not EAP anymore and isn't suitable for the EAP > RFC update, but it might work for some particular domain. > > It seems to me that there are other issues that need to be solved, and > might as well be solved while the patient is on the table. For > instance, EAP assumes a peer-to-peer link. PANA and 802.11 [1] have a > common problem -- the use of multiaccess media. (Note that both PPP > and 802.1X are just point-to-point.) It's not the wireless aspect > that's really a special problem; it's the multiaccess nature that > causes all the additional security headache. Why not define something > that's specific to use on multiaccess networks and that can handle > bootstrapping the security association required? > > That new protocol (MEAP?) can certainly carry EAP-formatted messages > if it wants -- after all, AAA protocols aren't EAP, but do carry EAP- > formatted messages, so it's not a new concept -- but it needn't be > compatible with EAP in any other way, so it doesn't need the same > retransmission mechanism. > > I think that'd be a happier result than contorting EAP to fit into a > non-EAP-shaped hole. > > [1] Minor digression: I leave DSL out of that list quite > intentionally. DSL is most certainly a point-to-point technology, > and it's made to appear to be multiaccess only by error. If you > could yank out the Ethernet-over-ATM baggage and run plain PPP > over HDLC on the raw bit pipe between CPE and CO, then all of the > current problems -- including PPPoE and PANA -- disappear (and > overhead is reduced as well). Bridged Ethernet with DHCP or > routed point-to-point link: pick *one*. > > (It also doesn't actually require the authentication in the plain > point-to-point case, since you know where the wires go physically, > but it doesn't hurt.) > > -- > James Carlson, Solaris Networking > Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From pana-request@research.telcordia.com Thu Jan 23 14:34:12 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17973 for ; Thu, 23 Jan 2003 14:33:53 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0NJXoAT015177; Thu, 23 Jan 2003 14:33:50 -0500 (EST) Resent-Date: Thu, 23 Jan 2003 14:33:50 -0500 (EST) Old-Return-Path: Date: Thu, 23 Jan 2003 11:32:59 -0800 Subject: Re: [eap] preserving packet order in EAP? From: Alper Yegin To: , CC: , , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit On 1/23/03 5:26 AM, "Dan.Forsberg@nokia.com" wrote: > Thank you for your comments. Just a quick question. What if PANA would specify > a "EAPv2" that wasn't backwards compatible with EAP but better suitable for > UDP/ICMP or TCP/SCTP? This new version could carry EAP methods specified in > the current EAP wg. For my understanding this wasn't the intention of PANA wg, > but it would make things simpler/easier for PANA(?). Just an idea. First we really need to understand what problems arise from carrying EAP above IP. Re-ordering was brought up, but that can be handled by including an identifier field in a PANA header. So I don't see this as a requirement for a new version of EAP. Is there anything else? Let's think... Also let's note that if modifications to EAP are needed, PANA is not the right WG to take over this. We need to bring it up to the EAP WG. alper > > - Dan > > >> -----Original Message----- >> From: ext James Carlson [mailto:james.d.carlson@east.sun.com] >> Sent: 23 January, 2003 15:09 >> To: Forsberg Dan (NRC/Helsinki) >> Cc: yohba@tari.toshiba.com; pana@research.telcordia.com; >> eap@frascone.com >> Subject: RE: [eap] preserving packet order in EAP? >> >> >> Dan.Forsberg@nokia.com writes: >>> One possible solution for this problem is to require the >>> Authenticatee to remember the ID numbers inside the EAP method >>> (message id's between the initial request and Success/Failure >>> msgs). This would imply that no EAP method should produce more than >>> 256 requests per authentication. >> >> That doesn't work because of rechallenge. (Well, unless you're >> willing to drop the link when you run out of ID space for rechallenges >> ...) >> >>> Anyway, I think this should be fixed in the EAP protocol simply >>> because it is standardized here in the IETF. A new issue perhaps? >>> EAP already provides retransmission and "duplicate" >>> detection. Making the duplicate detection work within this example, >>> would make EAP suitable for carriers such as UDP, ICMP, and IP. This >>> would increase the possibilities for EAP in the Internet. >> >> EAP has no problem with retransmission or duplicates (or other bad >> packets, for that matter). It does have a problem with reordering, >> and that can't actually be fixed without making the "new" version >> incompatible with the old. If you're going to make it incompatible, >> I'd suggest starting with a blank slate. >> >> EAP just wasn't designed to be used as you suggest. It needs an >> order-preserving peer-to-peer link. >> >> -- >> James Carlson, Solaris Networking >> >> Sun Microsystems / 1 Network Drive 71.234W Vox +1 >> 781 442 2084 >> MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 >> 781 442 1677 >> > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From pana-request@research.telcordia.com Wed Jan 29 02:06:08 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25785 for ; Wed, 29 Jan 2003 02:05:48 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h0T76e3K018375; Wed, 29 Jan 2003 02:06:40 -0500 (EST) Resent-Date: Wed, 29 Jan 2003 02:06:40 -0500 (EST) Old-Return-Path: Date: Wed, 29 Jan 2003 02:06:15 -0500 To: Mohan Parthasarathy Cc: Bernard Aboba , pana@research.telcordia.com Subject: Re: comments on draft-ietf-pana-threats-01.txt Message-ID: <20030129070615.GA698@catfish> Mail-Followup-To: Mohan Parthasarathy , Bernard Aboba , pana@research.telcordia.com References: <416B5AF360DED54088DAD3CA8BFBEA6E0134A39C@TNEXVS02.tahoenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E0134A39C@TNEXVS02.tahoenetworks.com> User-Agent: Mutt/1.5.3i From: Yoshihiro Ohba X-Dispatcher: imput version 20021213(IM143) Lines: 31 X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Mon, Jan 20, 2003 at 10:31:44AM -0800, Mohan Parthasarathy wrote: > > > Ok, i will add that. But you still need to prevent yourself > > from the attack > > > of someone modifying the IP address. POTLS prevents it by > > having a separate > > > exchange after a secure session is setup between PaC and PAA. > > > > Actually, I'm not sure you really need to prevent that. For > > example, in > > POTL, a fast resume could occur from another IP address -- is this > > forbidden? > > > I am not aware of this. Could the POTL authors comment on this ? > In PANA over TLS, session resumption from another IP address is also possible. In this case, DeviceID exchange over the TLS connection is performed immediately after the session resumption in order to make sure that there is no attacker sitting in the middle and has been involved in the session resumption exchange. By doing this, the two entities can stop further negotiation performed for establishing an SA for data traffic protection (e.g., IKE for establishing an IPsec SA) which typically uses a device id as the SA identifier. Of course, the further negotiation to be performed after successful PANA authentication needs to have its own device id protection mechanism. Note that as a result of the recent discusion on the mailing list, the protected DeviceID exchange can be optional when lower layer is assumed to be secure. Yoshihiro Ohba