Subject: Re: [Isms] SNMP "access control" terminology

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 2 Jul 2006 22:14:18 +0200

On Sat, Jul 01, 2006 at 12:14:07AM +0200, Juergen Schoenwaelder wrote:
> On Wed, Jun 28, 2006 at 02:34:10PM -0400, David Harrington wrote:
> 
> > A little history:
> > 
> > The processIncomingMsg() ASI lacks the parameters to pass the
> > transportAddress information from an incoming message into the
> > security model. Wonder why? It was not an oversight.
> > 
> > During the discussions of SNMPv2 and SNMPv3 designs, there was a
> > persistent request by operators for support of an approach frequently
> > used as an authorization mechanism. This was the practice of only
> > allowing certain IP addresses (e.g. from the NOC) to perform SNMP at a
> > device.
> > 
> > This was deliberately excluded from the design of SNMPv3. The
> > authentication and the authorization aspects of that approach are much
> > weaker than the authentication provided by USM and the authorization
> > provided by VACM. SNMPv3 design exlicitly separates authentication of
> > the principal, and authorization to perform SNMP operations. There is
> > no authorization implied by the authentication of a principal.
> 
> So how do you think snmpCommunityTransportTag as defined in RFC 3587
> fits into the picture? I believe this object does authorization by
> matching IP addresses. And the way it is described, this happens in
> the message processing model (processIncomingMsg ASI, see RFC 3587
> section 5.2.1). Perhaps this RFC is wrong according to the
> architecture (or is the architecture wrong? ;-)
> 
> You like to see authorization in the ACM. I think authorization does
> not really exist as a concept - except perhaps in RFC 3587.

I got the RFC number wrong - I was referring to RFC 3584 and not RFC
3587. Sorry for the confusion.

/js

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

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 2 Jul 2006 22:40:02 -0700

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: <[email-masked]>
> Sent: Sunday, July 02, 2006 1:14 PM
> Subject: Re: [Isms] SNMP "access control" terminology
...
> 3587. Sorry for the confusion.
...

The function of snmpCommunityTransportTag is to to provide a bridge
of sorts between the SNMPv1/SNMPv2c world and the SNMPv3 world.
That it might exhibit some discrepancies from the SNMPv3 architecture
is not surprising, given that it processes incompatible message wrappers.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 3 Jul 2006 08:18:38 +0200

> is not surprising, given that it processes incompatible message wrappers.

Sure. But the point is that (a) a clean architecture and the real
world must align reasonably well to be useful and (b) that I consider
this IP address filtering in the community-based security model as a
kind of authorization step. You simply don't get into the SNMP engine
if this authorization step fails, regardless what VACM later on would
allow or disallow.

While having no authorization and having no access right might
practically mean the same thing, they are still different in terms of
how far you get into the system and so far I always considered
authorization as something that happens at the entrance. Once you have
passed authorization and you are inside, access control controls what
you can do.

While I might be wrong with my world model, I see the following
potential three usages of RADIUS in an ISMS environment:

a) authentication backend for password/keyboard-interactive
   (transparent for ISMS as far as I can tell, easy)

b) authorization (once authenticated)
   (easy when you use RADIUS for authentication, difficult when you
   use public keys or kerberos since in this case authorization is
   different from authentication and RADIUS does not seem to like
   it (and I still have to understand what the difference between
   RADIUS and DIAMETER is in this aspect since the later seems to
   like it better))

c) mapping of security names to group names (roles)
   (requires to call radius within VACM or cached information must be
   passed to VACM from somewhere, requires to work out how such
   dynamic information coexists with provisioned VACM security to
   group mappings)

I think this is what <draft-narayan-isms-sshsm-radius-00.txt>
discusses.

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 3 Jul 2006 00:16:21 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Sunday, July 02, 2006 11:18 PM
...
>    RADIUS and DIAMETER is in this aspect since the later seems to

Does the distinction between (a) and (b) matter?  It's a question
of what attacks would be possible by the set of users who could
be authenticated but not "authorized" who would somehow be able
to cause mischief despite being prevented from "doing" anything by
the access control model.  I think this boils down to DoS attacks,
and would perhaps be more interesting than in a USM world if
sessions consumed substantial resources.

...

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 3 Jul 2006 10:05:09 +0200

> sessions consumed substantial resources.

If RADIUS is used for both (a) and (b), my understanding (please
correct me) is that you get a negative reponse regardless whether
authentication or authorization fails. On the RADIUS server, you might
however be able to authenticate the user but then decide that this
user is not allowed to talk SNMP to a given router.

Similarily, if you use Kerberos for authentication, then your
authentication might be successful because you are a known entity in
the Kerberos realm. But the fact that you are authenticated does not
necessarily imply the authorization to talk to an SNMP agent on a
given router.

In the USM world, the underlying assumption has been that successful
authentication implies authorization to talk to the managed device and
you have to delete an USM user to essentially deny authorization to
talk to the managed device. With RADIUS in place, you can drop the
authorization without deleting the authentication for a given user
which makes sense since the same user may very well be authenticated
and authorized to use other services. Sure, you can try to configure
the ACM to ensure that all users who can be authenticated (might be a
large number) and who are not authorized to use the service can't get
any service. But practically speaking from my system administration
experience, I would prefer to drop unauthorized users as early as
possible (and not only because of DOS attacks and resource usage but
more practically speaking also for the risks associated with software
bugs and not-as-good ACM configurations that might be around).

Again, the text above reflects my yet limited understanding of the
RADIUS world and how it fits to ISMS - so if this is not correct or
nonsense, please RADIUS folks correct me.

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 3 Jul 2006 15:32:48 -0700

Hi -

> Sent: Monday, July 03, 2006 1:05 AM
...
...

It's important to remember that in VACM, the only access control model
we have, if a user has no entry in the vacmSecurityToGroupTable [RFC 3415],
then no operations of any kind are permitted.  I haven't been able to think
of a reason why one might want to create VACM entries for users who have
no access rights to a system.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 6 Jul 2006 13:48:49 +0200

On Mon, Jul 03, 2006 at 03:32:48PM -0700, Randy Presuhn wrote:
 
> then no operations of any kind are permitted.

Why should a user who is not authorized to use the system be allowed
to create and keep an open SSH session? And why should such a user be
allowed to send SNMP packets even if they will return just exceptions?

I consider an SSH connection establishment failure a clearer signal
that someone is not authorized to talk to a system than letting the
establishment of the secure channel succeed and then get just
application layer access exceptions.

> I haven't been able to think of a reason why one might want to
> create VACM entries for users who have no access rights to a system.

You might have VACM entries for users which currently do not have
authorization to access the agents but which had authorization in the
past (and which might get it again in the future - e.g. a third party
company helping an organization to manage boxes). But yes, there are
surely different approaches to deal with this today. (Either you
change the security name to group name mapping or you change the USM
password, which means to deny authentication and entrance into the
system - it might be interesting to find out what operators actually
do in such cases - or whether such cases exist at all in reality).

The motivation for RADIUS is to be able to control from a centralized
system which authenticated user has the right to manage a device.

Another motivation was to be able to control from a centralized system
which role an authenticated user has once he is allowed to access a
device.

Both are related in the sense that being able to map an authenticated
user into a "noaccess" role/group may achieve the first requirement
but I think both share the same fundamental problem that we would need
to get information from RADIUS for already authenticated users if we
consider the case where authentication is not done via RADIUS.

I also believe that the desire to get centralized authorization
information is actually not limited to ISMS but equally applies to
NETCONF and other protocols that are able to authenticate users via
backend systems that do not provide authorization information.

Since an authorize only solution requires support from RADEXT, I would
prefer to not get ISMS blocked due to this particular feature. Still,
I think we should try to find agreement what authorization means
architecturally in the context of SNMP and TMSM next week.

/js

---

From: Eliot Lear <[email-masked]>
Date: Thu, 06 Jul 2006 14:13:38 +0200

> allowed to send SNMP packets even if they will return just exceptions?

Right.

> application layer access exceptions.

There are two analogies that can be applied, each of them to some degree
or another valid:

1.  The UNIX "Permission Denied" error, which doesn't tell you why
permission was denied, but simply that it was.  This is very similar to
USM, and has the benefit of not providing many clues to a potential
attacker, in and of itself.

2.  The dual model of a session and an action, where someone is
authenticated and authorized for two-way communications and is
separately authenticated for specific actions.  A level of trust is
associated with this that someone who is authenticating will not try to
do bad things.  That trust only has to extend so far, however, because
actions can be audited.

To get to (1) one needs to take the intersection of sets of those
allowed to login, in this case held in an external database, and those
authorized to access certain objects, still held in VACM.  That would
require some sort of callout to the SNMP subsystem from the SSH
subsystem that assuredly does not exist today.  Moreover it shouldn't. 
It's simple enough to indicate by port and authentication attribute or
server the use of the connection.

Eliot

---

From: "David Harrington" <[email-masked]>
Date: Thu, 6 Jul 2006 12:19:09 -0400

Hi,

I suggest we all step back from this discussion.

We obviously have issues with terminology here. The overlap of
terminology for the different pieces is causing a lot of confusion.

Let's approach this proactively.
I recommend that the document be modified to better distinguish the
functionality provided by the different pieces and the terminology.

In particular, I sugggest that the first three chapters introduce the
technologies that will be integrated, and set the terminology that
will be used when referring to similar concepts while discussiing
specific portions of the integration:

1. Introduction
1.1 An introduction to RADIUS functionality (with no mention of SSH or
SNMP)
	identify the terms that will be used to reference the
functionality of RADIUS
1.2 An introduction to SSH functionality (with no mention of RADIUS or
SNMP)
	identify the terms that will be used to reference the
functionality of SSH
1.3 An introduction to SNMP transport security (with no mention of
SSH, RADIUS, or VACM)
	identify the terms that will be used to reference the
functionality of SNMP transport security
1.4 An introduction to SNMP operations access control
	identify the terms that will be used to reference the
functionality of SNMP operations access control

2. Integration for transport security
	why integration for transport security is desired
2.1 How SNMP will use SSH to provide transport security (with no
mention of RADIUS)
	to authenticate clients
	to establish a session-level subsystem for SNMP message
security
2.2 How SSH frequently uses RADIUS (with no mention of SNMP)
	to suthenticate clients
	to authorize an SSH subsystem
2.3 How SSH can use RADIUS when SSH is providing transport security
for SNMP
	to authenticate clients
	to authorize an SSH subsystem called "snmp"

3. Integration for SNMP operations access control
	why integration for SNMP operations access control is desired
	two main ways to approach getting the information from RADIUS:
3.1 using an ACM subsystem add-on to act as a RADIUS client 
	directly contact the RADIUS server (without using SSHSM)
3.2 using SSH to gather and cache RADIUS attributes 
	3.2.1 attributes to specify SNMP operations access control
parameters 
	3.2.2 having SSH or SSHSM cache the information 
	3.2.3 subsequent use of the cached attributes by an ACM
subsystem add-on.

dbh

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: Thursday, July 06, 2006 7:49 AM
> To: Randy Presuhn
> Cc: [email-masked]