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

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

Hi,

On Wed, Sep 21, 2005 at 01:04:50PM -0400, Avi Lior wrote:

> See inline..... 

Same.

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

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.

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

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.

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

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

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

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.

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

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.
> 
> I don't agree!!!

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.

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

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?

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

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

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

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

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

and you answered:

> The RADIUS server pushing their policy to the NAS before the
> 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.

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