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

From: "Avi Lior" <[email-masked]>
Date: Wed, 21 Sep 2005 13:04:50 -0400

Hi Emile,
This is a late response sorry.

See inline..... 

> -----Original Message-----
> From: Emile van Bergen [mailto:[email-masked]] 
> Sent: Friday, September 09, 2005 7:04 PM
> To: Avi Lior
> Cc: Bernard Aboba; Nelson, David; [email-masked]; 
> [email-masked]
> 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           [email-masked]      
> tel. +31 (0)78 6136282           http://www.e-advies.nl    
> 

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Emile van Bergen <[email-masked]>
Date: Wed, 21 Sep 2005 22:35:49 +0200

Hi,

> See inline..... 

Same.

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

Ok, let me try and explain it better.

1. The positive case is where the NAS advertises that it WILL send
Location when asked for it. 

The server will need to send a challenge to tell the NAS that the user
allows Location to be sent. This is required by GEOPRIV; Location may
not be sent in the first access request, because Location may only be
sent if the NAS knows that the user's privacy policy allows it. 

If the only interface between users database and NAS is RADIUS, and it
does not seem reasonable to build two parallel interfaces if we're
specifically creating support for all this in RADIUS, then the only way
the NAS can learn about that policy is a RADIUS response (in practice, a
challenge or an accept).

2. The negative case is where the NAS advertises that it WILL NOT send
Location. 

The server may then skip the challenge step and proceed to accept,
accept with reduced authorization, or reject immediately. The server may
also do so if it does not care about Location.

3. A third case is where the NAS advertises capabilities in some form,
but does not know anything about Location or GEOPRIV, so it cannot say
that it supports Location, and it cannot say that it does not support
Location.

The server will then have to challenge. This can be avoided if the
capabilties advertising standard says that a server can infer
non-support for a feature if the server sees an advertisement without a
statement about that feature. 

That would mean that a NAS that supports advertising must be required to
advertise EVERYTHING it has support for, otherwise the server cannot
conclude non-support of a feature when the NAS omits it from the
advertisement. That may not be a bad thing for a capabilities
advertising standard to ask (arguably the only thing that would make it
worthwhile), but the current caps. draft doesn't go as far as that.

4. A fourth case is where the NAS does not know how to advertise
capabilities. 

The server will then have to challenge if it cares about Location,
unless it can conclude from the lack of advertisment that Location is
not supported. This can be avoided if the GEOPRIV standard rules that no
GEOPRIV support may exist without capability advertising, which would
allow a server to conclude from the lack of advertisement that GEOPRIV
is not supported.

As you can see, you need to be /very/ careful in defining such things
for maximum convergence, because without convergence, the number of
states raises exponentially for each case you introduce.

> access-request is not possible today.

And should not be possible tomorrow, especially not for per-session
policy. That makes no sense. 

I reiterate: the whole idea of RADIUS is offloading policy decisions to
a central place, by asking a server a question before each session
starts. Not by pushing the information needed to make policy decisions
outwards.

Take a look at DNS if publishing stuff is what you want.

> not challenge.  It will simply reject or accept based on its local

Exactly, and that's immediately the only case where the NEGATIVE
advertisement (does not support) adds something (efficiency).

> result in the NAS treating the challenge as a reject and terminating the

It's does not waste anything compared to the 'normal' case, where the
NAS advertises 'yes, I do support' and then the server challenges for
Location (because the NAS is not allowed to send Location immediately by
the PRIV part of GEOPRIV).

So let's please put the whole efficiency argument aside: even the most
positive case requires a challenge (accept with maximum privileges) if
the server /requires/ Location, so such a server may just as well use a
challenge in the other cases too.

The unintended reject, where a server learning that a NAS does not
support GEOPRIV would rather send a limited accept rather than a
challenge, causing a reject as per RFC2865 4.4 for NASes that do not
support Challenge (or for NASes that don't understand why they are
challenged) is the first sensible argument I hear for GEOPRIV requiring
capabilities advertisements.

> Draft-capexchange as proposes a way to signal this. 

True, but I'm arguing the case how GEOPRIV could be done without broad
capabilities advertising.

This is also a bit more specific; it's not about feature support, it's
about the user's privacy policy wrt. Location sending, which possibly
depends on the NAS that's used for that session.

Would you want to use the capabilities exchange to publish the user's
specific GEOPRIV policy for that specific session?

Then the capabilities exchange should be defined as a very loose
signaling mechanism, where the semantics of each capability value is
completely governed by the document describing the capability. 

This rules out the strict modes where the server may conclude
non-support from a default value.

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

OK, I concede that advertising allows servers whose policy REQUIRES
Location for full access to provide more limited access if the user's
policy WOULD allow the sending of Location from that NAS, but Location
is not sent.

The question is whether this, plus the efficiency gain in the case where
the NAS supports challenges but not GEOPRIV, warrants a capability
advertisement feature.

If one could be developed that's generic enough to support both this
case and the "NAS-and-proxies-will-heed-limit-X" case, while being
/extemely/ careful to avoid an explosion of states (see above how easy
this is), then I would agree that it would make sense for GEOPRIV to
require that.

GEOPRIV requiring specific advertisements without a good capability
mechanism already defined and accepted, or an overly broad advertising
mechanism without very clear semantics and well defined convergence of
states is what I object to.

> So we cant help but using a Challenge. 

Agreed. So I take it you agree that you need the Challenge in all cases
where the server wants Location, and that no amount of advertising up
front will remedy that?

> the session without sending a challenge.

Which seems useful only when it wants to offer limited access in that
case. And I agree, that /is/ useful.

Prescience, I think, considering what you wrote in this post. I wrote:

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

> access-request is not possible today.

I read the "today" as that you think it might be useful. Or am I wrong?

Best regards,

Emile.

---

From: "Carl Reed OGC" <[email-masked]>
Date: Thu, 22 Sep 2005 08:51:12 -0600

> Interesting new patent:
>
> NSA granted Net location-tracking patent
> By Declan McCullagh, CNET News.com
> Published on ZDNet News: September 21, 2005, 1:49 PM PT
>
>       Forward in
>       EMAIL
>       Format for
>       PRINT
>
>
> The National Security Agency has obtained a patent on a method of figuring
> out an Internet user's geographic location.
>
>
> Patent 6,947,978, granted Tuesday, describes a way to discover someone's
> physical location by comparing it to a "map" of Internet addresses with
> known locations.
>
>
> The NSA did not respond Wednesday to an interview request, and the patent
> description talks only generally about the technology's potential uses. It
> says the geographic location of Internet users could be used to "measure
> the effectiveness of advertising across geographic regions" or flag a
> password that "could be noted or disabled if not used from or near the
> appropriate location."
>
>
> Other applications of the geo-location patent, invented by Stephen Huffman
> and Michael Reifer of Maryland, could relate to the NSA's signals
> intelligence mission--which is, bluntly put, spying on the communications
> of non-U.S. citizens.
>
>
> "If someone's engaged in a dialogue or frequenting a 'bad' Web site, the
> NSA might want to know where they are," said Mike Liebhold, a senior
> researcher at the Institute for the Future who has studied geo-location
> technology. "It wouldn't give them precision, but it would give them a 
> clue
> that they could use to narrow down the location with other intelligence
> methods."
>
>
> The NSA's patent relies on measuring the latency, meaning the time lag
> between computers exchanging data, of "numerous" locations on the Internet
> and building a "network latency topology map." Then, at least in theory,
> the Internet address to be identified can be looked up on the map by
> measuring how long it takes known computers to connect to the unknown one.
>
>
> The technique isn't foolproof. People using a dial-up connection can't be
> traced beyond their Internet service provider--which could be in an
> different area of the country--and it doesn't account for proxy services
> like Anonymizer.
>
>
> Geo-location, sometimes called "geo-targeting" when used to deliver
> advertising, is an increasingly attractive area for Internet businesses.
> DoubleClick has licensed geo-location technology to deliver
> location-dependent advertising, and Visa has signed a deal to use the
> concept to identify possible credit card fraud in online orders.
>
>
> Digital Envoy holds a patent on geo-location, and Quova, a privately held
> firm in Mountain View, Calif., holds three more, one shared with 
> Microsoft.
>
>
> "It's honestly not clear that there's anything special or technically
> advanced about what they're describing," Quova Vice President Gary Jackson
> said, referring to the NSA's patent. "I'd have to have our technical guys
> read it, but I don't think it impacts us in any way."

----- Original Message ----- 
From: "Avi Lior" <[email-masked]>
To: "Emile van Bergen" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Bernard Aboba" 
<[email-masked]>
Sent: Wednesday, September 21, 2005 11:04 AM
Subject: [Geopriv] RE: Capabilities (was Re: AW: Review 
ofdraft-ietf-geopriv-radius-lo-04.txt )