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

[Yoshihiro Ohba <yohba at tari.toshiba.com>]

I thought more about this, and the new attribute corresponds 
to the 'E' bit setting.  

Attached=Yes <-> 'E' bit cleared
Attached=No  <-> 'E' bit set

So I think what we need to define as a new PANA session attribute is
the 'E' bit value.

Yoshihiro Ohba


On Fri, Mar 13, 2009 at 11:19:26AM +0200, Alper Yegin wrote:
> Hi Yoshi,
> 
> What I'm thinking is, there'd be a new attribute associated with the PANA
> session: 
> 
> 	Attached: Yes/No. Indicates whether the PaC is attached to the
> access network or not.
> 
> At the time of pre-auth and up until the PaC moves to the target network,
> this attribute is set to No. If the network detects that PaC has detached
> (via some lower-layer indications), it can set this to No again. If the PaC
> moves and performs pre-auth to maintain its session, it shall be set to No
> again.
> 
> So, at any time a PaC is:
> 
> - authenticated/authorized and attached, or
> - authenticated/authorized and not attached, or
> 
> Does this make sense?
> 
> Alper
> 
> 
> 
> 
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Yoshihiro Ohba [mailto:yohba at tari.toshiba.com]
> > Sent: Wednesday, March 11, 2009 11:12 PM
> > To: Alper Yegin
> > Cc: 'Glen Zorn'; 'Glen Zorn'; pana at ietf.org; Basavaraj.Patil at nokia.com
> > Subject: Re: WGLC comments on draft-ietf-pana-preauth-04
> > 
> > On Fri, Feb 13, 2009 at 11:36:38AM +0200, Alper Yegin wrote:
> > > > > > 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).
> > 
> > Commenting as editor, I need more specific guidances on text changes
> > with regard to which terms should be used instead of
> > pre-authz/post-authz.  Can you help?
> > 
> > Regards,
> > Yoshihiro Ohba
> 
> 
> _______________________________________________
> Pana mailing list
> Pana at ietf.org
> https://www.ietf.org/mailman/listinfo/pana
>