RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session

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

Hi Jeffrey.
 

> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] 
> Sent: Tuesday, July 25, 2006 6:43 PM
> To: Avi Lior; Glen Zorn (gwz); David Harrington; Eliot Lear
> Cc: isms@ietf.org; radiusext@ops.ietf.org; Jeffrey Hutzelman
> Subject: RE: Follow up on Authorize Only issue (was RE: 
> [Isms] ISMS session
> 
> 
> 
> On Tuesday, July 25, 2006 05:40:00 PM -0400 Avi Lior 
> <avi@bridgewatersystems.com> wrote:
> 
> > I proably did not make myself clear....or maybe I did and I 
> am missing 
> > something.
> >
> > When the NAS sends the Access-Request Auth-Only message I 
> agree that 
> > it MUST contain Message-Authenticator(80) etc...
> >
> > What I meant is that it would be nice if there was a token or an 
> > assertion that came from the place that did authenticate 
> the user  to 
> > indicate in a cryptographic way that this user was authenticated.
> >
> > The AAA server can use that token to verify that the user was 
> > authenticated by an entity that it trusts.  Like a kerberose ticket.
> 
> First, the user was authenticated by the NAS.  That is all 
> the RADIUS server needs to know.  The RADIUS server provides 
> service to the NAS, not the user, and the NAS has asked for 
> information about what the user is allowed to do.  Either the 
> RADIUS server is willing to give that information to the NAS 
> or it is not, but it is the NAS that is making the request, 
> not the user.

I don't have a problem with that.  But it would be better if the NAS can
prove to the AAA server that the user was authenticated.  Normally it is
the AAA that authenticates the user and provides authorization
attributes.

> 
> RADIUS servers provide authentication as a _service_ to the 
> NAS, not as a means of determining whether the NAS is 
> legitimate or should be given information.  A NAS that is not 
> interested in that service should not be required to use it 
> in order to make use of the other services that the RADIUS 
> server can provide, such as provisioning and accounting.  
> Once again, the RADIUS server's relationship is with the NAS, 
> not the user.

Not true.  Normally the RADIUS server (in particular the home RADIUS
server) owns the user. Therefore it has a trust relationship with the
user.  The mechanism for that trust relationship is a credential
(password or shared key) known only to those two parties.

The RADIUS server trusts the NAS directly or via a trust chain.  The
trust mechanism is a shared secret or in the case of a trust chain, a
set of trust secrets.

> 
> Secondly, as I already said, the sort of token you describe 
> simply does not exist for most authentication mechanisms.  A 
> Kerberos ticket is not cryptographic proof that a user has 
> authenticated.  It is an encrypted message from the Kerberos 
> server to a particular service, and is useless to anyone 
> else.  And, it's not a message saying "this user authenticated". 
> It's a message telling the service the keys it needs to know 
> in order to conduct an exchange with a user and determine 
> whether that user is real.

Well if that token did exist then it will be useful to use it. 

I stand corrected on Kerberose.

However, there are tokens that are used for single-sign-on that do prove
the authenticity of the token holder.  Why can't something like that be
used?  


> 
> Thirdly, as I've also said before, this is a serious 
> abstraction violation. 
> Even if every service had such a magic cookie, what you're 
> suggesting would require defining what it is, for RADIUS, for 
> every authentication mechanism that might be used by a NAS 
> using authorize-only.  What magic token are you going to use 
> for TLS?  What about USM?  GSS-spkm?  SSH public key? 
> one-time passwords?  SSH host-based public key?  NTLM?  
> IPsec?  How about the Frobozz protocol I referred to in an 
> earlier message?  You don't even know how that works, so 
> you'd basically guarantee that when I get a NAS that supports 
> the Frobozz protocol, I can't use it until I define an 
> extension to the RADIUS protocol and upgrade my server.

Perhaps I missled you and I am sorry. So let me clarify...

First and foremost I am in favour of supporting the scheme that a NAS
ought to be able to peform an Authorize-Only to a AAA sever regardless
if that AAA server has authenticated the user or not.  There are a huge
security issues but so be it.  Those security issue can be managed in
many ways.

The scheme is useful!!!

The second part of my email was about one method of managing that
security.  Again, I would not want to mandate that method and mandate
that that would be the only way to design such a system.

In general my philosophy is that the IETF should build tools.  Some of
these tools can be dangerous if not used properly.  The IETF should
provide its wisdom on how one may use these tools and identify the risks
as best it can.

  







> 
> -- Jeff
> 

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