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

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Tue, 25 Jul 2006 12:46:42 -0700

Avi Lior <mailto:[email-masked]> supposedly scribbled:

> Hi,
> 
> If I was specifying how this is done:
> 
> It would be nice if the AAA client could return some sort of token to
> the AAA server to assert that the user has been authenticated by an
> entity that it trusts. The token can be generated by the
> Authentication Server.   
> 
> We need this assertion to make sure we deliver the correct profile.

I disagree: the fact that the message is being sent by an authenticated client at all says that the user has been authenticated elsewhere.  Note that safety requires the inclusion of a MAC (either the Message-Authenticator or preferably the Message-Authentication-Code Attribute) in the Access-Request.  

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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

---

From: "Avi Lior" <[email-masked]>
Date: Tue, 25 Jul 2006 17:40:00 -0400

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.

> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:[email-masked]] 
> Sent: Tuesday, July 25, 2006 3:47 PM
> To: Avi Lior; David Harrington; Eliot Lear
> Cc: [email-masked]; [email-masked]
> Subject: RE: Follow up on Authorize Only issue (was RE: 
> [Isms] ISMS session
> 
> I disagree: the fact that the message is being sent by an 
> authenticated client at all says that the user has been 
> authenticated elsewhere.  Note that safety requires the 
> inclusion of a MAC (either the Message-Authenticator or 
> preferably the Message-Authentication-Code Attribute) in the 
> Access-Request.  
> 
> Hope this helps,
> 
> ~gwz
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 25 Jul 2006 18:42:48 -0400

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

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.

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.

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.

-- Jeff

---

From: "Avi Lior" <[email-masked]>
Date: Wed, 26 Jul 2006 14:09:37 -0400

Hi Jeffrey.

> From: Jeffrey Hutzelman [mailto:[email-masked]] 
> Sent: Tuesday, July 25, 2006 6:43 PM
> To: Avi Lior; Glen Zorn (gwz); David Harrington; Eliot Lear
> Cc: [email-masked]; [email-masked]; Jeffrey Hutzelman
> > When the NAS sends the Access-Request Auth-Only message I 
> agree that 
> > it MUST contain Message-Authenticator(80) etc...
> >
> 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?  

> 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 

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.