RE: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )

["Avi Lior" <avi@bridgewatersystems.com>]

Hi Emile,
This is a late response sorry.

See inline..... 

> -----Original Message-----
> From: Emile van Bergen [mailto:openradius-radextwg@e-advies.nl] 
> Sent: Friday, September 09, 2005 7:04 PM
> To: Avi Lior
> Cc: Bernard Aboba; Nelson, David; radiusext@ops.ietf.org; 
> geopriv@ietf.org
> Subject: Re: Capabilities (was Re: AW: Review of 
> draft-ietf-geopriv-radius-lo-04.txt )
> 
> Hi,
> 
> (Cross posting to GEOPRIV-WG; this discussion pertains to 
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-
> lo-04.txt,
> in particular section 8).
> 
> On Fri, Sep 09, 2005 at 04:49:09PM -0400, Avi Lior wrote:
> 
> > > The question is why GEOPRIV has decided not to send location by 
> > > default.
> > 
> > Initially we did exactly that we sent the location 
> information in the 
> > Access-Request.  But Geopriv being about privacy, was 
> concerned what 
> > if the user did not want to have their location exposed.
> > 
> > So now we have the case where in some systems, the user's policy of 
> > whether or not to expose location is stored in the a database and 
> > during authentication the AAA learns that policy.
> 
> Presumably you mean that the NAS learns the user's policy 
> from the home server, who has access to the user's profile.
> 
> I see that your position is in line with that, but I still do 
> not see the point.
> 
> 1. If the home AAA makes access or billing conditional on 
> Location, the
>    user's own policy is irrelevant; the home AAA will only 
> list the user
>    in his database if the user agrees with his location being
>    transmitted to the home AAA. 

It could do that but it may also limit what it authorizes the user to do
if the user doesn't agree to location,

> 
>    So if that is the case, if the home AAA doesn't see Location in a
>    request without State, it challenges. If it sees no Location in a
>    request with State, it rejects. 

See above comment.
 
>    Advertising the positive case (NAS supports GEOPRIV and will send
>    Location when challenged) in the access request does not 
> prevent the
>    challenge.
> 
>    Advertising the negative case (NAS supports GEOPRIV but 
> will not send
>    Location when challenged) will prevent the challenge and allow the
>    home AAA to send a reject immediately. 

Reject or Accept with limited access etc....
    
>    But that's a corner case that seems hardly worth dealing 
> with. You'll
>    either have a NAS that supports it and needs a challenge, or a
>    pre-GEOPRIV NAS that won't do any negative GEOPRIV-advertising
>    either.

I don't follow/understand the "negative case"

>    Only the home AAA advertising to its upstream the policy that it
>    needs Location, else don't bother sending an access request, would
>    prevent the access request and the challenge. But the general idea
>    with RADIUS is not that home AAA push their policies 
> downstream, but
>    that downstream queries upstream in the individual case.

The RADIUS server pushing their policy to the NAS before the
access-request is not possible today.

 
>    In short: if Location is /needed/ by the home AAA, then you need a
>    Challenge step anyway, a. for the NAS to learn about the user's
>    policy, and b. for the AAA server to postpone its decision until it
>    learns the presence or value of Location.

You miss my point.  If the AAA server requires Location information and
it knows that the NAS does not support Location information then it will
not challenge.  It will simply reject or accept based on its local
policies.

If the AAA server requires location information but it does not know
whether or not the NAS supports location information -- it has no option
but to challenge for the information.  This is wasteful and worse can
result in the NAS treating the challenge as a reject and terminating the
session.

 
> 2. If Location is optional, and only used for statistics, marketing,
>    and other shady purposes, then NAS can learn from the access accept
>    whether the user allows Location to be included in accounting
>    packets (start, interim and stop).

Sure....
    
>    The access accept could include a dummy Location value in 
> that case,
>    and we could have language saying that the NAS MUST NOT 
> send Location
>    in accounting unless an empty Location attribute is present in the
>    access accept.

Draft-capexchange as proposes a way to signal this. 

 
> In both cases: no advertising needed. Or even helpful.

I don't agree!!!

> > > > But that advertisement is also an extra transaction. What's
> > > the home
> > > > AAA supposed to do, keep state from separate 
> > > > pseudo-authentications that include the advertised 
> information for 
> > > > later use? That doesn't sound like RADIUS, at all.
> > > Right. 
> > 
> > Wrong.
> > 
> > No the advertizement is not an extra transaction.  It comes in the 
> > Access-Request.
> 
> But if the NAS may only include Location if it learns the 
> user's policy first, for privacy reason, then telling the NAS 
> about the user's policy /is/ an extra transaction. You need 
> that one, too.

The extra message is required because Geopriv wants to have a mode where
by the location is not provided automatically.
So we cant help but using a Challenge. 

However, what is being debated is whether it is helpful to have the NAS
tell the AAA server in the initial Access-Request whether or not the NAS
supports location information.

I say it is helpful. Since as I stated above, if the NAS does not
support location information, then the AAA can simply reject or accept
the session without sending a challenge.

 
> You're not advocating (phew) that each user is to advertise 
> his policy towards each NAS in advance, and no other form of 
> advertising would prevent that step.

I am not advocating any such thing. I never have and I don't see how you
come to the above statement.

> > And by the way, RADIUS does keep transactional state.  
> 
> Please see my other post. 
> 
> The NAS does not keep state about users after they log off, 
> so it can't cache the user's policy, and the home AAA does 
> not keep state per NAS, so it can't use information about a 
> NAS (negative support) from earlier authentications, unless 
> you add a whole new dimension to building a compliant RADIUS server.

Can you please show me where I claim or require that the NAS keep state
after the user logs off?

> Kind regards,
> 
> 
> Emile.
> 
> -- 
> E-Advies - Emile van Bergen           emile@e-advies.nl      
> tel. +31 (0)78 6136282           http://www.e-advies.nl    
> 

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>