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

["Nelson, David" <dnelson@enterasys.com>]

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?




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