Re: [Pana] WGLC comments on draft-ietf-pana-preauth-04

["Alper Yegin" <alper.yegin at yegin.org>]

> > > In the same section, it appears that "pre-authorization" is simply
> a
> > > pre-provisioned filter applied to all traffic but that is not
> > actually
> > > clear
> > > from the document.
> >
> > Document says:
> >
> > 	Pre-authorization:  An authorization for a PaC, made by a CPAA
> > for
> >       the PaC at the time of pre-authentication.
> >
> > Not sure where a "pre-provisioned" filter comes into play. Basically
> > pre-authorization is the state a PaC reaches when it completes a
> > successful
> > pre-authentication. And post-authorization is the state a PaC reaches
> > when
> > it attaches to one of the candidate networks with whom it has reached
> > pre-authorization state.
> 
> OK, so what relation do these states have to the arrival of AAA
> authorization?  My comment about pre-provisioned filters pertained to
> the
> authorization state before the arrival of a RADIUS Access-Accept
> message,
> for example.  As I noted later, the transition between the
> "pre-authorization" & "post-authorization" states doesn't appear to
> actually
> have anything to do with authorization.  In any case, this whole thing
> is
> pretty confusing & I think that it would be a good idea to clarify it.

I agree. 

There are no two separate AAA authorizations taking place. There is only one
RADIUS Access-Accept.

I wonder if we lose anything if we were to drop these new terms: pre-authz,
post-authz.

What we really mean to convey is: A PaC is authorized on the candidate PAA
by means of pre-authentication procedure prior to the PaC's attachment to
the PAA's network (candidate network). 


> > > I don't understand what a "pre-authorization SA" is, exactly, maybe
> > > because
> > > it is misleadingly named: it doesn't appear that the transition
> > between
> > > a
> > > "pre-authorization SA" & a "post-authorization SA" has anything to
> do
> > > with
> > > the arrival of keying material (before which no PANA SA can exist,
> if
> > I
> > > understand RFC 5191 correctly) and dynamic authorization parameters
> > at
> > > the
> > > CPAA.  The transition actually appears to be triggered by
> successful
> > IP
> > > address update, but isn't this unnecessary in the case when Mobile
> IP
> > > is in
> > > use or movement is within the same subnet?
> >
> > I'm also thinking that the pre-auth SA and post-auth SA terms are not
> > useful. There is only one SA, it is called PANA SA. And that SA stays
> > the
> > same before and after attachment to the candidate network.
> >
> > I'm unclear about the Mobile IP relevance.
> 
> My point was that (last time I checked, anyway -- things may have
> changed
> ;-) the idea behind Mobile IP was that the MN didn't have to change IP
> addresses while moving about.  In any case, that would certainly be
> true in
> the case of movement between access points in the same subnet;
> therefore IP
> address update would be unnecessary.  I see (I think) that the actual
> purpose of the IP address update message isn't to update the IP address
> in
> this case but it's not completely clear what that purpose might be...
> 
> ...

OK, I see where the confusion is coming from.

All we really need is a handshake between the PaC and CPAA so that PaC
signals its arrival at the CPAA's network. We use PANA-Ping for that.
Whether the IP address of PaC changes or not is not important. We shall
remove any text that talks about the change of IP address. 



> 
> > > In addition, RFC 5191 seems to say that a PANA
> > > session is initiated with the "Authentication and authorization
> > phase"
> > > (although it's not really clear what the starting point for a
> session
> > > is
> > > since this may consist of multiple message exchanges).  For the
> > > purposes of
> > > this document, is the transmission of a PANA-Client-Initiation
> (PCI)
> > > message
> > > with the 'E' bit set or a PAR message with the 'S' (Start) and 'E'
> > > (prE-authentication) bits set considered to initiate the
> > Authentication
> > > and
> > > authorization phase?
> >
> > Yes.
> 
> OK, it might be nice to make that a bit more explicit; maybe even add
> "Updates: RFC 5191" to the first page header, though I'm not sure that
> that
> is really necessary.


Alper



> 
> ...
> 
> ~gwz
> 
> Washing one's hands of the conflict between the powerful and the
> powerless
> means to side with the powerful, not to be neutral.
>   -- Paolo Freire
> 
> 
>