Re: [Pana] Channel binding [ was Re: PANA relay draft]
Rafa Marin Lopez <rafa@um.es> Wed, 01 December 2010 14:30 UTC
Return-Path: <rafa@um.es>
X-Original-To: pana@core3.amsl.com
Delivered-To: pana@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2108E28C11B for <pana@core3.amsl.com>; Wed, 1 Dec 2010 06:30:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.599
X-Spam-Level:
X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3JRgg2GMxuc for <pana@core3.amsl.com>; Wed, 1 Dec 2010 06:30:32 -0800 (PST)
Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by core3.amsl.com (Postfix) with ESMTP id BA4C43A6D01 for <pana@ietf.org>; Wed, 1 Dec 2010 06:30:30 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 58F995D444; Wed, 1 Dec 2010 15:31:42 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon14.um.es
Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id b6I9K4xuCUGn; Wed, 1 Dec 2010 15:31:42 +0100 (CET)
Received: from inf-205-163.inf.um.es (inf-205-163.inf.um.es [155.54.205.163]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon14.um.es (Postfix) with ESMTPSA id 46A1C5D49B; Wed, 1 Dec 2010 15:31:33 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="iso-8859-1"
From: Rafa Marin Lopez <rafa@um.es>
In-Reply-To: <00a901cb912c$0ea9aae0$2bfd00a0$@yegin@yegin.org>
Date: Wed, 01 Dec 2010 15:31:32 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <314D995A-C614-4801-A6B6-942F93E4D5F1@um.es>
References: <317A507F-239C-4AAD-B88F-2D5744E7D5F2@gmail.com> <F75BDF80-67C2-4008-8DC1-6EA8E1C00088@um.es> <4CE6E4B1.1080007@toshiba.co.jp> <934C8E59-C49E-4D96-A311-FB48B3DACD78@um.es> <00d601cb8bd3$c1909730$44b1c590$%yegin@yegin.org> <B63989D4-BDD5-449A-8722-BA293988A6F4@um.es> <00b101cb8fbd$ee3ce430$cab6ac90$%yegin@yegin.org> <4CF45C72.1000303@toshiba.co.jp> <000101cb90d4$9caab210$d6001630$%yegin@yegin.org> <4CF58F97.4010209@toshiba.co.jp> <00a901cb912c$0ea9aae0$2bfd00a0$@yegin@yegin.org>
To: Alper Yegin <alper.yegin@yegin.org>
X-Mailer: Apple Mail (2.1082)
Cc: pana@ietf.org, robert.cragie@gridmerge.com, 'Ralph Droms' <rdroms.ietf@gmail.com>
Subject: Re: [Pana] Channel binding [ was Re: PANA relay draft]
X-BeenThere: pana@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Protocol for carrying Authentication for Network Access <pana.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pana>
List-Post: <mailto:pana@ietf.org>
List-Help: <mailto:pana-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Dec 2010 14:30:35 -0000
Hi Alper, all I am ok with this text. El 01/12/2010, a las 08:47, Alper Yegin escribió: > Yoshi, > > " the solution must ensure that both the EAP peer and the EAP server can use > the same PAA address" > > This text is suggesting some solution. We better not do that. We shall just > make the CB solution designer aware of this and request it be taken into > account. > > With that, I'd propose: > > > "In the relay operation, the IP address of PAA that is seen by the PaC > (i.e., an IP address of the PRE) is different from the IP address of the PAA > that is seen by the authentication server. If an EAP channel binding > solution uses the IP address of PAA as part of channel binding parameters, > such a solution must take this into account. Note that the same issue arises > even when non-relayed PANA is used and the PAA has one IP address configured > on its interface facing the PaC and another IP address on the other > interface facing the authentication server." > > Alper > > > > > > >> -----Original Message----- >> From: Yoshihiro Ohba [mailto:yoshihiro.ohba@toshiba.co.jp] >> Sent: Wednesday, December 01, 2010 1:58 AM >> To: Alper Yegin >> Cc: 'Rafa Marin Lopez'; pana@ietf.org; 'Ralph Droms'; >> robert.cragie@gridmerge.com; 'Samita Chakrabarti'; 'Paul Duffy >> (paduffy)' >> Subject: Re: Channel binding [ was Re: PANA relay draft] >> >> OK. >> >> Here is proposed text about channel binding, intended to be added to >> Security Considerations section: >> >> "In the relay operation, the IP address of PAA that is seen by the PaC >> (i.e., an IP address of the PRE) is different from that is used by the >> PAA to exchange PRY messages with the PRE. Therefore, if an EAP >> channel binding solution uses an IP address of PAA as part of channel >> binding parameters, the solution must ensure that both the EAP peer >> and the EAP server can use the same PAA address (i.e., either one of >> the above two addresses)." >> >> Yoshihiro Ohba >> >> >> (2010/12/01 6:21), Alper Yegin wrote: >>>> Let me create another thread specific to channel binding. >>>> >>>> - In pana-relay, what PaC uses to communicate with PAA is PRE's >>>> address, not PAA's address. >>>> >>>> - At the time of channel binding, if PAA's address is part of >> channel >>>> binding parameter, then channel binding parameter verification will >>>> fail because of the address difference. >>>> >>>> - Rafa suggested a remedy to use PRE's address as PAA's address for >>>> channel binding at both EAP peer and server, and Alper agreed on >> that. >>> >>> My point is, whatever channel binding solution is being used should >> be able >>> to handle this (what appears to be a) NAS with two IP addresses. >>> >>> Alper >>> >>> >>> >>> >>> >>>> >>>> Is this correct? >>>> >>>> Yoshihiro Ohba >>>> >>>> >>>> (2010/11/29 21:06), Alper Yegin wrote: >>>>> Hi Rafa, >>>>> >>>>>>> One way to look at this is the NAS is composed of the PRE and the >>>>>> PAA. >>>>>>> Or, think of it as the NAS has to IP interfaces, one with the IP >>>>>> address of >>>>>>> PRE, the other with the IP address of PAA. >>>>>> >>>>>> [Rafa] I think if that is the view I believe it should be >> reflected >>>>>> somehow. The reason is that until now in the I-D it seems the PRE >> is >>>> a >>>>>> completely different entity from the PAA. In other words, they do >>>> not >>>>>> part of the same NAS. In fact, the PaC will have a PANA session >>>> where >>>>>> the "IP address and UDP port number of the PAA" which is actually >>>> the >>>>>> "IP address and UDP port number of the PRE." >>>>>> >>>>>> >>>>>>> >>>>>>> Which channel binding solution are you considering that'd have a >>>>>> problem >>>>>>> with this? >>>>>> >>>>>> [Rafa] Basically, what I am thinking is that the PAA would send >> its >>>> IP >>>>>> address for example to the AAA server as part of channel binding >>>>>> parameter. The PaC however sees the IP address of the PRE. If the >>>> AAA >>>>>> informs to the PaC that PAA sent as channel binding parameter >> PAA's >>>> IP >>>>>> address, the PaC will contrast this parameter with what the PaC >> saw >>>>>> (the PRE IP address) which basically does not match. If we follow >>>> the >>>>>> idea of that PRE is an interface of the PAA, most probably what >> the >>>> PAA >>>>>> would have to send to the AAA is the PRE's IP address as channel >>>>>> binding parameter. >>>>> >>>>> Rafa, which specific channel binding solution are you referring to >>>> here? >>>>> And your proposed remedy above can handle the situation. >>>>> My point is, whatever the channel binding solution is, it can >> handle >>>> this >>>>> situation (which would also arise in the very simple case where a >>>> simple PAA >>>>> were using two different IP addresses -- one facing the PaC and the >>>> one >>>>> facing the PAA). >>>>> >>>>> >>>>>>>> What about allowing the PAA to answer the PaC (through the >>>>>>>> PRE) with the PAA's IP address? The PCI sent by the PaC will not >>>>>> carry >>>>>>>> that IP address but the PaC would see a PAR coming from a PAA >> and >>>> it >>>>>>>> would engage the PANA authentication with it. >>>>>>> >>>>>>> PRE sourcing IP packets with PAA's IP address, and accepting IP >>>>>> packets >>>>>>> destined to PAA, and PaC using its link-local address to >>>> communicate >>>>>> with >>>>>>> the PAA's global IP address... these are not trivial. >>>>>>> >>>>>>> I'd think a NAS with two IP addresses and using one at one phase >>>> and >>>>>> another >>>>>>> at a latter phase is not such a problem. >>>>>>> >>>>>>> We could have the same issue in another simpler case: consider >> PaC >>>>>> being >>>>>>> authenticated on one interface of PAA, and later PaC attaches to >>>>>> another >>>>>>> interface of the PAA. PAA may have two different IP addresses on >>>> each >>>>>>> interface. Yet, the same PANa sessions shall be available thru >> both >>>>>>> interfaces. >>>>>> >>>>>> [Rafa] But the PANA session has to change in the attribute "IP >>>> address >>>>>> and UDP port number of the PAA" and that change (I believe this is >>>>>> related with the recent Yoshi's e-mail) must happen in the PaC. >>>>> >>>>> We can mention that in the I-D. >>>>> >>>>>> In the >>>>>> RFC 5191 it is said: "In order to maintain the PANA session, the >> PAA >>>>>> needs to be notified about the change of PaC address." I would >>>> expect >>>>>> the same in the PaC (I will answer Yoshi's e-mail about this). >>>>> >>>>> If you are suggesting this be changed on PANA RFC 5191, I don't >> think >>>> this >>>>> is necessary. >>>>> A mention of that in the relay I-D makes sense. >>>>> >>>>> Regards, >>>>> >>>>> Alper >>>>> >>>>> >>>>>> >>>>>> Best regards. >>>>>> >>>>>>> >>>>>>> Alper >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> Yoshihiro Ohba >>>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------- >>>>>>>> Rafael Marin Lopez, PhD >>>>>>>> Dept. Information and Communications Engineering (DIIC) >>>>>>>> Faculty of Computer Science-University of Murcia >>>>>>>> 30100 Murcia - Spain >>>>>>>> Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es >>>>>>>> ------------------------------------------------------- >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> ------------------------------------------------------- >>>>>> Rafael Marin Lopez, PhD >>>>>> Dept. Information and Communications Engineering (DIIC) >>>>>> Faculty of Computer Science-University of Murcia >>>>>> 30100 Murcia - Spain >>>>>> Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es >>>>>> ------------------------------------------------------- >>>>>> >>>>>> >>>>> >>>>> >>>>> >>> >>> > ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es -------------------------------------------------------
- [Pana] PANA relay draft Ralph Droms
- Re: [Pana] PANA relay draft Rafa Marin Lopez
- Re: [Pana] PANA relay draft Yoshihiro Ohba
- Re: [Pana] PANA relay draft Rafa Marin Lopez
- Re: [Pana] PANA relay draft Alper Yegin
- [Pana] Switching to direct communication [was Re:… Yoshihiro Ohba
- Re: [Pana] Switching to direct communication [was… Alper Yegin
- Re: [Pana] PANA relay draft Rafa Marin Lopez
- Re: [Pana] Switching to direct communication [was… Rafa Marin Lopez
- Re: [Pana] PANA relay draft Alper Yegin
- Re: [Pana] Switching to direct communication [was… Alper Yegin
- Re: [Pana] Switching to direct communication [was… Yoshihiro Ohba
- [Pana] Channel binding [ was Re: PANA relay draft] Yoshihiro Ohba
- Re: [Pana] Switching to direct communication [was… Alper Yegin
- Re: [Pana] Channel binding [ was Re: PANA relay d… Alper Yegin
- Re: [Pana] Channel binding [ was Re: PANA relay d… Yoshihiro Ohba
- Re: [Pana] Channel binding [ was Re: PANA relay d… Alper Yegin
- Re: [Pana] Switching to direct communication [was… Alper Yegin
- Re: [Pana] Switching to direct communication [was… Rafa Marin Lopez
- Re: [Pana] Channel binding [ was Re: PANA relay d… Rafa Marin Lopez
- Re: [Pana] Switching to direct communication [was… Yoshihiro Ohba
- Re: [Pana] Switching to direct communication [was… Rafa Marin Lopez