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

[Emile van Bergen <openradius-radextwg@e-advies.nl>]

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. 

   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. 

   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. 
   
   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.

   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.

   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.

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).
   
   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.

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

> > > 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.

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.

> 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.

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/>