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