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

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

BTW this trust issue is also an issue with Diameter

Both are hop-by-hop secure so have the same issues.  Although Diameter
has a redirection capability as a work around - which will be
interesting to see if it ever gets deployed in high transaction
environments.

Even using EAP. Although the authentication is End-to-End the result of
the authenticaiton, typically a key is sent back to the NAS through
proxies.  The proxies see the Key.
 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Emile van Bergen
> Sent: Friday, September 09, 2005 2:48 PM
> To: Bernard Aboba
> Cc: Nelson, David; radiusext@ops.ietf.org
> Subject: Re: Capabilities (was Re: AW: Review of 
> draft-ietf-geopriv-radius-lo-04.txt )
> 
> 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/>
> 

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