[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
>> -------------------------------------------------------
>>
>>
> 
> 
>