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

From: "Susan Thomson \(sethomso\)" <[email-masked]>
Date: Fri, 24 Jun 2005 20:17:12 -0400

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 communicate
with more than one?

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: Mon, 27 Jun 2005 08:52:21 -0400

> PAA+EP at different hops on a path, and the PaC will need to communicate

Even in multi-hop case, the PaC does not need to communicate with more
than one PAA.  

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