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.o...@toshiba.co.jp] >> Sent: Wednesday, December 01, 2010 1:58 AM >> To: Alper Yegin >> Cc: 'Rafa Marin Lopez'; pana@ietf.org; 'Ralph Droms'; >> robert.cra...@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: r...@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: r...@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: r...@um.es ------------------------------------------------------- _______________________________________________ Pana mailing list Pana@ietf.org https://www.ietf.org/mailman/listinfo/pana
