[Pana] Channel binding [ was Re: PANA relay draft]
Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp> Tue, 30 November 2010 02:06 UTC
Return-Path: <yoshihiro.ohba@toshiba.co.jp>
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 04F843A6C52 for <pana@core3.amsl.com>; Mon, 29 Nov 2010 18:06:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.089
X-Spam-Level:
X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbQpTJT0pvHU for <pana@core3.amsl.com>; Mon, 29 Nov 2010 18:06:47 -0800 (PST)
Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by core3.amsl.com (Postfix) with ESMTP id 4046F3A6C4F for <pana@ietf.org>; Mon, 29 Nov 2010 18:06:47 -0800 (PST)
Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id oAU27oSc010579; Tue, 30 Nov 2010 11:07:50 +0900 (JST)
Received: (from root@localhost) by arc1.toshiba.co.jp id oAU27ofu017979; Tue, 30 Nov 2010 11:07:50 +0900 (JST)
Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id MAA17974; Tue, 30 Nov 2010 11:07:50 +0900
Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id oAU27nrg028924; Tue, 30 Nov 2010 11:07:49 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id oAU27mZO018979; Tue, 30 Nov 2010 11:07:48 +0900 (JST)
Received: from [133.196.17.40] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LCO00393DX0N8J0@mail.po.toshiba.co.jp>; Tue, 30 Nov 2010 11:07:48 +0900 (JST)
Date: Tue, 30 Nov 2010 11:07:46 +0900
From: Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp>
In-reply-to: <00b101cb8fbd$ee3ce430$cab6ac90$%yegin@yegin.org>
To: Alper Yegin <alper.yegin@yegin.org>
Message-id: <4CF45C72.1000303@toshiba.co.jp>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-2022-JP"
Content-transfer-encoding: 7bit
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>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
Cc: pana@ietf.org, robert.cragie@gridmerge.com, 'Ralph Droms' <rdroms.ietf@gmail.com>
Subject: [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: Tue, 30 Nov 2010 02:06:49 -0000
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. 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 >> ------------------------------------------------------- >> >> > > >
- [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