Subject: RE: [Isms] I-D ACTION:draft-narayan-isms-sshsm-radius-00.txt

From: "Nelson, David" <[email-masked]>
Date: Fri, 23 Jun 2006 19:05:41 -0400

David Harrington writes...

> I started to read this draft. Unfortunately, this is not what was
> supposed to be written.

That is one opinion.

> The consensus was that we wanted an "authorize-only" RADIUS extension,
> to make RADIUS authorization independent of the authentication phase.

The consensus was that would be a preferred, but optional, feature it if
fit within the RADIUS architecture.  It is not clear that it does,
although that avenue has not been fully explored.  RADIUS by design
tightly couples authentication and authorization.  There is a limited
form of "authorize only" service already defined that relies on a
previous RADIUS authentication.  We may be able to extend RADIUS to
provide an autonomous authorization service, independent of
authentication. That changes some fundamental assumptions in RADIUS, and
would likely result in a change to RADIUS server implementations that
could not be implemented simply by means of adding new attributes to a
data dictionary.  This has yet to be fully analyzed, however.

> The authorize-only should be accessible from the access control
> subsystem; the rest of the SNMP engine knows nothing about this RADIUS
> support for data access control (e.g. VACM). We explicitly did not
> want a RADIUS integration with SSHSM because that would violate the
> RFC3411 modularity and its separation of authentication and
> authorization.

As I've said in another note, you may be able to satisfy this goal and
you may not.  Especially if re-use of existing AAA infrastructure is a
critical factor.

> 1) If an operator wants RADIUS integration with SSH, that happens
> outside the SNMP engine. SSHSM and other security models should not
> need to know that SSH used RADIUS to authorize a session of SNMP
> management.

I think this is incorrect or at least incomplete.  Here's why.
SSH/RADIUS integration today does not typically take into account
whether or not an authenticated user is authorized to use a particular
service, such as SNMP.  This is not a problem when SSH is using separate
RADIUS servers that are limited to authenticating and authorizing
management access to network devices.  In a single-sign-on environment,
the fact that you can authenticate to log onto a PC or workstation does
not mean you should be able to log on to manage network infrastructure
devices.

With USM, authentication and authorization aren't so entirely separate
as you claim.  The fact that a username and key are in the local USM
store are implicit authorization that the user is allowed access to the
SNMP engine.  With general AAA systems like RADIUS there may be lots of
users that can authenticate (e.g. for other purposes, like logging onto
workstations) who should not be allowed to connect to an SNMP engine.

> 2) If an operator wants to use RADIUS to determine which VACM group to
> use for this user, that is handled strictly within the access control
> subsystem, using an authorize-only RADIUS extension, independently of
> the authentication provided via a security model, such as USM or SSHSM
> or USM/Kerberos.

That is a nice model, and may be achievable, if we can extend RADIUS to
operate in that mode.  It does not do so today.  Initial discussion of
adding that mode of operation on the RADEXT WG mailing list met with
some push-back.  Further work needs to be done here.

> Some operators want to authenticate their users with
> Kerberos, but then as a separate step ask RADIUS what data access
> control policies to apply to that user.

I'm sure that's true.

> The interim meeting requirements for an authorize-only RADIUS
> extension was recapped in a mail message dated 3/16/06.

Yes, but it was *not* a requirement.  It was a nice to have.  That
doesn't mean we should give up too easily on achieving this goal.

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

---

From: "Nelson, David" <[email-masked]>
Date: Mon, 26 Jun 2006 18:36:15 -0400

> There are basically two ways to use RADIUS with an SNMP engine.

I think there are probably three ways.

> The first is a relationship between RADIUS and SSH.

My question is whether this is really one "way" or two?  If all the SSH
server is doing is "pure" authentication, then what component is doing
"base level" authorization?  RADIUS is basically a service provisioning
protocol.  For example, the client says "Hey, here's Alice, and she
wants access."  The server responds "Oh, I know Alice.  Start a Telnet
session to host foo.example.com for her."  That's a bit different from
simply authenticating the user and delivering a default service, e.g.
the CLI prompt of some OS shell.

We have talked about authentication.  We have talked about authorization
to provide optional access control, e.g. VACM or some other method.  It
is clear that the SSH server performs the authentication.  It is clear
that the Access Control Module performs the "granular" authorization.
What hasn't been answered to my satisfaction is which component or
module decides that the user is authorized to "start" an SNMPv3 session
to begin with (what I called the "base level" authorization)?  I suppose
this might logically be the responsibility of the SSH server.  I don't
think that SSH does this today, especially since the RADIUS attributes
that describe this authorization don't exist, except in the RADIUS
NAS-Management draft.  Worrying about which VACM table entry to use,
before you've even established that the user should be doing SNMP access
at all, bothers me.

Now, there is (at least) one way to solve this issue.  If the
authentication of the user implicitly provides the "base level"
authorization to use SNMPv3 access to the managed entity, then we're all
set.  This is the way USM works today.  This can be achieved with RADIUS
(or any other AAA) if (and only if) the data base of users who can
authenticate is limited to only those users authorized to gain SNMPv3
management access.  In practical terms, this can easily be accomplished
by having a separate RADIUS server (or servers) for the network
management staff.  No other employees would be in that data base.  Some
operators may configure their AAA infrastructure that way.  A variation
on this theme is when a single RADIUS server, which is used to
authenticate all employees, uses some "hint" information in the RADIUS
Access-Request message, together with group membership or other access
rights in the user data base, to decide when the access should be
granted and when it should be denied.  For example,
[email-masked] might be granted access for PPTP service through a
VPN gateway but denied access for SNMPv3 management of that same VPN
gateway.

All of this needs to be described, somewhere.
 
> The other usage deals with a relationship between an SNMP access
> control model, like VACM, and RADIUS. In this case, VACM (or its
> encompassing ACM subsystem) talks directly to RADIUS to determine the
> VACM (or other) configuration, such as Groupname to associate with the
> known security-model-independent securityName.

I think we basically agree here, and that relationship needs to be
clarified in the subject draft.  Assuming that RADIUS can be modified to
deliver the autonomous authorization service that is being requested,
this should be easy. If it cannot, for some reason, then we need to
decide what, if anything, is an acceptable second best.