Subject: RE: [Pana] PANA and PaC-generated cookie AVP

From: "Susan Thomson \(sethomso\)" <[email-masked]>
Date: Fri, 15 Jul 2005 17:48:57 -0400

Hi Yoshi 

Inline ....

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: Monday, June 27, 2005 8:52 AM
> To: Susan Thomson (sethomso)
> Cc: Yoshihiro Ohba; [email-masked]
> Subject: Re: [Pana] PANA and PaC-generated cookie AVP
> 
> On Fri, Jun 24, 2005 at 08:17:12PM -0400, Susan Thomson 
> (sethomso) wrote:
> > Thanks for the quick response.
> > 
> > Not sure I understood you, so let me clarify one thing:
> > 
> > You mention that "the PaC does not need to communicate with 
> multiple 
> > PAAs in parallel."
> > 
> > But, with multi-hop support, it is possible that there will be 
> > multiple
> > PAA+EP at different hops on a path, and the PaC will need to 
> > PAA+communicate
> > with more than one?
> 
> Even in multi-hop case, the PaC does not need to communicate 
> with more than one PAA. 

Given support for multi-hop, there are deployment scenarios where a PaC
may come across different PAA+EPs (especially if co-located) on same or
different paths. 

With the exception of the Discovery mechanism you mention below, the
protocol design should not preclude such deployment scenarios. 

In any case, I don't think this really affects the need for a
PaC-generated cookie AVP.

Susan

> 
> There is text related to this in section 4.2:
> 
> "
>    There can be multiple PAAs on the link and the PaC may receive
>    multiple PANA-Start-Request messages from those PAAs.  The
>    authentication and authorization result does not depend on 
> which PAA
>    is chosen by the PaC.  By default the PaC MAY choose the PAA that
>    sent the first response.
> "
> 
> But I think this text needs to be revised to cover multi-hop 
> scenario as well as unsolicited discovery, something like:
> 
> "
>    There can be multiple PAAs in the access network and the PaC may
>    receive multiple PANA-Start-Request messages from those PAAs.  The
>    authentication and authorization result does not depend on 
> which PAA
>    is chosen by the PaC.  By default the PaC MAY choose the PAA that
>    sent the first PANA-Start-Request message.
> "
> 
> Regards,
> Yoshihiro Ohba
> 
> 
> 
> > 
> > Thanks
> > Susan
> > 
> > > -----Original Message-----
> > > From: Yoshihiro Ohba [mailto:[email-masked]]
> > > Sent: Friday, June 24, 2005 5:38 PM
> > > To: Susan Thomson (sethomso)
> > > Cc: [email-masked]
> > > Subject: Re: [Pana] PANA and PaC-generated cookie AVP
> > > 
> > > This was discussed in issue 55 and rejected.  Your 
> proposal might be 
> > > a bit different from the previous discussion in that 
> either PAA or 
> > > PaC is the generator of a cookie in your proposal, but 
> the same in 
> > > that the PaC does not need to communicate with multiple PAAs in 
> > > parallel.
> > > For this reason, effectiveness of having a client cookie is still 
> > > not clear to me.
> > > 
> > > http://danforsberg.info:8080/pana-issues/issue55
> > > 
> > > Yoshihiro Ohba
> > > 
> > > On Fri, Jun 24, 2005 at 04:04:54PM -0400, Susan Thomson
> > > (sethomso) wrote:
> > > > In the "solicited PANA-Start-Request" mode of operation,
> > > PANA supports
> > > > a PAA-generated cookie AVP to protect against blind
> > > attackers acting
> > > > as legitimate PaCs. It seems that, in the "unsolicited
> > > PANA-Start-Request"
> > > > mode of operation (no discovery), the protocol should also
> > > support a
> > > > cookie AVP that can be generated by the client so that 
> the PaC can 
> > > > protect itself from blind attackers acting as PAAs.
> > > >  
> > > > Client behavior would be similar to PAA usage of cookie 
> AVP, but a 
> > > > PaC-generated cookie AVP would be carried in 
> PANA-Start-Answer and 
> > > > first PANA-Auth-request messages.
> > > >  
> > > > The behavior would be something like the following:
> > > > 1. If NAD is responding to a client-initiated 
> Discovery, then PAA 
> > > > would send a cookie AVP in PANA-Start-Request message and
> > > only store
> > > > state when PaC responds.
> > > > 2. If NAD initiates PANA-Start-Request message without a 
> > > > client-initated Discovery, then the client responds with a
> > > Cookie-AVP
> > > > in the PANA-Start-Answer message and only stores state when
> > > NAD sends
> > > > the first PANA-Auth-Request message.
> > > >  
> > > > So only one peer is sending a cookie avp depending on 
> the mode of 
> > > > operation. The presence or absence of the cookie AVP in the 
> > > > PANA-Start-Request tells the client what mode  the PAA is
> > > operating in
> > > > (the text in the PANA spec says this, although the figure 
> > > > indicates that a cookie avp is sent from PAA regardless).
> > > >  
> > > > Comments?
> > > >  
> > > > Thanks
> > > > Susan
> > > 
> > > > _______________________________________________
> > > > Pana mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/pana
> > > 
> 

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 26 Jul 2005 13:58:45 -0400

Hi Susan,

> protocol design should not preclude such deployment scenarios. 

I think that the specification does not preclude such deployment
scenarios.  On the other hand, the specification does not explicitly
support the scenarios either.  It would make sense to have client
cookie in the base specification only if we have a protocol design
requirement on supporting simultanously communicating with multiple
PAAs.

> PaC-generated cookie AVP.

In the case where supporting simultanously communicating with multiple
PAAs is not a protocol design requirement, I am not sure what kind of
threat the use of client cookie can eliminate or mitigate.  For
example, an attacker (off-link or on-link) can spoof an IP address
that is valid in the attacker's link and send a PSR to a PaC.  The PaC
will return a PSA with a client cookie to be stateless. Then, the
attacker sends a PAR with echoing the cookie, the client creates a
state after receiving the PAR and returns a PAN to the attacker, and
the attacker suddenly becomes silent after receiving the PAN.  The
attacker can repeat this by changing IP addresses to keep the PaC from
establishing a PANA session with legitimate PAA.

Regards,
Yoshihiro Ohba