Re: [Pana] Channel binding [ was Re: PANA relay draft]

"Alper Yegin" <alper.yegin@yegin.org> Wed, 01 December 2010 07:46 UTC

Return-Path: <alper.yegin@yegin.org>
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 BFD613A6CF2 for <pana@core3.amsl.com>; Tue, 30 Nov 2010 23:46:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.15
X-Spam-Level:
X-Spam-Status: No, score=-101.15 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, USER_IN_WHITELIST=-100]
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 fjdMElGr3LMC for <pana@core3.amsl.com>; Tue, 30 Nov 2010 23:46:55 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 8712F3A6CFF for <pana@ietf.org>; Tue, 30 Nov 2010 23:46:55 -0800 (PST)
Received: from ibm (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LfTRR-1Od1nF2Jxp-00oiIJ; Wed, 01 Dec 2010 02:47:54 -0500
From: Alper Yegin <alper.yegin@yegin.org>
To: 'Yoshihiro Ohba' <yoshihiro.ohba@toshiba.co.jp>
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>
In-Reply-To: <4CF58F97.4010209@toshiba.co.jp>
Date: Wed, 01 Dec 2010 09:47:40 +0200
Message-ID: <00a901cb912c$0ea9aae0$2bfd00a0$@yegin>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcuQ6pBsHaXUdGy0S5Gh0O92tEswvgAQKnAA
Content-Language: en-us
X-Provags-ID: V02:K0:6v6ao9ywwq9e1mkRoOCfdeEU6QYfm2b2rdBjub8lNlT Ufxn+FAh4jefPpPMu6XyG5fkmRg/GOK17QghIi2HYTaMB1DyVq HXIq0qw9T9a08AYgXpYeFjK2fsRssXuAgOYcqJFf2Qm+0ISUO3 SFo+sG5DgAmG/ZKrn+b0CLQi3hIhOwJHzNw7uxR3Vy+sZrJ1zd UV+jX7cIYsLxUC1rpDbhsQG3o3Wu+byczN/SiW1lgY=
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 07:46:57 -0000

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