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

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

Hi,

On Thu, Sep 08, 2005 at 12:22:51PM -0700, Bernard Aboba wrote:

> > > The RADIUS server may REQUIRE location in order to evaluate a
> > > authentication/authorization policy.  That policy could state that if
> > > location is not provided then allow the user on with certain
> > > constraints.
> 
> Yes, but the RADIUS server can do this *after* it has indicated that it 
> requires the NAS to provide location information via an Access-Challenge. 
> 
> For example, the NAS initially does not send location information; the 
> RADIUS server sends an Access-Challenge asking for it;  the NAS still does 
> not send it, and then the RADIUS server sends an Access-Accept with 
> limited authorizations, instead of an Access-Reject.  
> 
> In this scenario, there is still no need for "capabilities advertisement" 
> by a NAS. 
> 
> > In the case of location information, what is the problem with the NAS
> > always providing any location information that it has to the RADIUS
> > server?
> 
> It may be undesirable for the NAS to send location by default.  But as 
> argued earlier, this is not a problem -- the RADIUS server can ask for the 
> information. 
> 
> > If the issue is that the User wants the NAS to only disclose location to
> > RADIUS servers that he trusts, I think there is a lot of heavy lifting
> > to do.  
> 
> I'd argue that the only RADIUS server that a user can trust is its home 
> RADIUS server. There can be no notion of a user trusting intermediate 
> proxies.  

If I ever understood RADIUS, trust has always been entirely hop-by-hop.
The user connects at the NAS and trusts it to make a decision. The NAS
sends a RADIUS request to a server it trusts to give it an accept or
reject. That server in turn may query a database it trusts, or another
RADIUS server that it trusts. 

Hiding credentials from proxies (by using a challenge-response protocol
or an encrypted tunnel such as TTLS) is an orthogonal matter. 

If a local NAS or AAA doesn't want to trust his upstream AAA's, then the
choice of authentication protocol would needs /very/ careful attention,
to say the least. That there can be no notion of trusting your proxies,
rules out every authentication protocol in current existence other than
EAP-TTLSv1 or EAP-PEAPv2, if I see it correctly, both of which are in
draft stage and hardly implemented yet.

There's a fundamental issue: how can you ever sensibly ask someone you
don't trust, whether or not to provide service to a user you don't know?

I'd say, never query a proxy you don't trust, /unless/ you're using an
EAP method that provides server authentication, message integrity,
confidentiality, cryptographic binding, you only rely on the
accept/reject messages inside the tunnel, and you've /thorougly/
verified your assumptions.

Cheers,


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