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

From: "Nelson, David" <[email-masked]>
Date: Thu, 13 Jul 2006 16:59:18 -0400

Juergen Quittek writes...

> Finally, the WG discussed RADIUS integration of the SSH security
model.
> There seems to be different positions in the security community about
> whether or not 'authorization only' requests harmonize or
dis-harmonize
> with the Kerberos architecture.

We had a lunchtime meeting today to discuss this issue, with Jeff
Hutzelman, Bernard Aboba, Russ Housley and myself.  The problem turns
out to be more with the RADIUS architecture and the trust models than an
issue with the Kerberos architecture.  This issue was not brought up in
RADEXT on Monday, and the issues that were brought up in RADEXT on this
point seem to have been addressed.

The remaining issue, in a nutshell, with the desired Authorize Only
usage is as follows.

In RADIUS, Access-Request messages can be authenticated by two means,
the user credentials, e.g. User-Password or CHAP-Password, or
Message-Authenticator.  All of these are based on the RADIUS client and
server sharing a secret.  One major difference between the user
credentials and the Message-Authenticator is that that former provide
proof to the RADIUS server that the given user is "present" at the NAS.
The latter only provides proof to the RADIUS server that the NAS is
trusted.   

In an Access-Accept message, the NAS is trusted to have authorization
information for the user because (a) the NAS is trusted and (b) the user
is present at the NAS, so the NAS has a "need to know".  The concerns
with Authorize Only operations, that do not have a previous successful
RADIUS authentication as a prerequisite, is that when the user is not
present at the NAS, the NAS does not have a "need to know" the user's
authorization status.  Information might be leaked to a NAS about users,
that the NAS would not otherwise be entitled to have.

IN RFC 3576, the requirement for a previous RADIUS authentication is met
by requiring a server State attribute t be in the Access-Request
message, which provides that binding for Authorize Only operation.

The only form of RADIUS operation that currently provides authorization
information on a "user" without user credentials is the call check
operation.  In these cases the actual user is not identified, but rather
the user's phone number (or similar network address information).

For the SSHSM usage case, the question is whether it is an unacceptable
security risk for a trusted NAS to be able to obtain authorization
information about a user that is not actually "present" at the NAS?

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 15 Jul 2006 21:29:20 +0200

> that the NAS would not otherwise be entitled to have.

Thanks, I think I understand this. Now I wonder how other AAA systems
which I have been told to support authorize only deal with this issue.
Can someone please explain?
 
> message, which provides that binding for Authorize Only operation.

If I understand this correctly, then you have (a) the NAS is trusted
and (b) the user was previously present at the NAS here. Correct?

> information about a user that is not actually "present" at the NAS?

This probably needs more thought and discussion.

Thanks for discussing this issue and writing things up in a way that I
seem to understand.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: "Alan DeKok" <[email-masked]>
Date: Fri, 14 Jul 2006 14:22:10 -0400

> information about a user that is not actually "present" at the NAS?

  i.e. "present" as in "the RADIUS server performed the
authentication, and verified that the user is present".

  Is there any *other* authentication credentials that can be sent to
the RADIUS server, to mitigate the issue?  e.g. A kerberos ticket?

  The RADIUS server could either validate the kerberos ticket itself,
or log the ticket for later auditing.  If it's too hard to send the
ticket, maybe a hash of the ticket, or ticket ID (I'm not sure if this
is available or useful in Kerberos..)

  If the server had some auditing capability for Authorize-Only
requests, an admin could correlate that information with
authentication performed by non-RADIUS servers.  That would mitigate
the concerns over the RADIUS server not performing the authorization.

  Alan DeKok.

---

From: "Alan DeKok" <[email-masked]>
Date: From [email-masked] Mon Jul 17 22:06:15 2006

Alan DeKok.

---

From: "Alan DeKok" <[email-masked]>
Date: Fri, 14 Jul 2006 14:28:46 -0400

> the concerns over the RADIUS server not performing the authorization.
                                                         ^^^^^^^^^^^^^

  "authentication".

  Alan DeKok.

 Fri, 14 Jul 2006 14:28:46 -0400
Cc: 

> the concerns over the RADIUS server not performing the authorization.
                                                         ^^^^^^^^^^^^^

  "authentication".

  Alan DeKok.

---

From: "Avi Lior" <[email-masked]>
Date: Tue, 18 Jul 2006 17:29:29 -0400

Hi

> > 
> > For the SSHSM usage case, the question is whether it is an 
> > unacceptable security risk for a trusted NAS to be able to obtain 
> > authorization information about a user that is not actually 
> "present" at the NAS?
> 
I am having trouble understanding "..user that is not actually present"

Why are we sending authorization attributes to a NAS where the user is
not actually present.

I have seen scenarios where we push authorization attributes to a NAS
and hence that creates a Session for a user using COA for example. 

> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>