Subject: RE: [Isms] FW: RADIUS integration

From: "Nelson, David" <[email-masked]>
Date: Wed, 28 Jun 2006 11:18:30 -0400

Jeffrey Hutzelman writes...

> This can't and won't happen in the ACM; it needs to happen in the SSH
> layer.

Unless I'm mistaken, this is at variance with the recent posting from
Dave Harrington.  It appears that we need to have some further
discussion on this point.

> Until a client has successfully authenticated to the SSH server,
> it can't do anything that would be visible to the SNMP engine.

Yes, that's true.  Did it appear from my description that the
SNMP-driven authorization phase would occur before the SSH-driven
authentication phase?
 
> So, what we're really talking about in this scenario is
> 
> (1) RADIUS as an authentication backend for SSH
> (2) what you called "base-level" authorization to use SNMP
> (3) optionally, additional data for fine-grained access control

Yes, I think that's right.

> The data in step (3) would be used by the ACM, though getting it there
> might require a gross violation of modularity in the SNMP engine.

Why do you think so?  Is there anything in the SNMP architecture that
precludes any of the modules from using a "system service", external to
SNMP, such as AAA?  Perhaps simply the fact that no such dependency is
currently described?

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 28 Jun 2006 12:45:37 -0400

> SNMP-driven authorization phase would occur before the SSH-driven

Yes, because you made specific reference to the SNMP Access Control Module, 
which is responsible for authorization, but not authentication.

> Why do you think so?

Because unless _I'm_ terribly confused, the ACM doesn't do authentication. 
So if you can only talk to the RADIUS server if you do authentication, or 
use some form of cookie resulting from successfuly authentication (I don't 
know such a thing exists, but your previous writings have led me to believe 
there must be something like that), then _something_ has to make its way 
from the module that did authentication to the one that's going to make 
access control decisions.  Since SNMP has gone to a fair bit of trouble to 
define the abstractions between modules rather than leaving them up to the 
implementors, that information has to fit the abstraction.

I wonder if maybe we have some sort of disconnect here.  Maybe Dave H or 
one of the Juergen's can see what it is and tell us.

-- Jeff

---

From: "David Harrington" <[email-masked]>
Date: Wed, 28 Jun 2006 14:34:10 -0400

Hi,

I'll present my understanding of the RFCs and the intentions of the
authors to clarify this. This message is about the term "access
control" in SNMP.

-- terminology --
Let me make sure we are all using similar terminology. I think that is
a problem thus far.

In RFC3411, we define subsystems and models. There is a subsystem for
message handling, one for "security", one for applications, one for
access control, one for applications, and we are proposing a subsystem
for transport mapping.

Each subsystem is allowed multiple models. (Note that there is only
one dispatcher that coordinates between the subsystems, and there can
be only one dispatcher "model" per RFC3411.)

The messaging subsystem can support snmpv1, snmpv2c, and snmpv3 and
future message versions. This subsystem is all about knowing how to
create/extract the component parts of an an SNMP message - the global
stuff, the version-speciifc stuff, the (opaque) securityParameters,
and the scopedPDU. 

The security subsystem is designed to support models for USM, a
community-based authentication approach, and other security models;
the security subsystem is designed to handle message-related security,
such as authentication, encryption, timeliness/replay, and message
integrity.

The application subsytem defines supported operations, and the details
of how to perform them. Applications register themselves to be passed
messages for specific contextEngines and specific operations types.  

The access control subsystem, the ACM, permits multiple models of
access control. An access control model advises applications about who
is allowed to do what operations to which objects in which subsets of
data. 

The transport mapping subsystem handles the choice of port and
transport. It probably should not be involved in making decisions
about access to data (SNMP access control), message versions, or
message-specific parameters, although that may need to be discussed
further. 

--
SNMP traditionally has not worked with a session approach, so there is
no concept of authorizing an snmp session in RFC3411. It has been
argued that authentication via USM implies authorization to use SNMP
at that engine. I believe that is incorrect. SNMPv3 has no concept
that a user is "authorized" by USM to perform SNMP operations. 

For example, in an engine that only supports USM and VACM, "dbh" could
have an entry in the usmUserTable, and I might be able to authenticate
myself to an engine, but if VACM has no assignment for the
securityName "dbh" to an authorized group, then I am not authorized to
perform any SNMP operations on any objects in any contexts at that
entity. It is the VACM access control subsystem that makes this
determination, not the USM security model.

So, when we talk about access control in SNMP, we really should
restrict that terminology to refer to the functionality provided by
the ACM subsystem.

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

--
RADIUS has the ability to advise a server which services shoud be
permitted when a client connects to a server. I think referring to
this as "access control" within an SNMP engine will cause nothing but
problems. The decision to permit access to an SSH subsytem called
"snmp" is based on a transaction between a RADIUS advisor, and an SSH
enforcer (or "snmp" service provider). 

SNMP does not enter into this decision at all. SNMP will never even
see a message that comes to an SSH server, if the SSH server does not
permit the "snmp" service. The decision to permit opening an SSH
subsystem called "snmp" certainly does NOT happen in the security
subsystem of an SNMP engine. The decision to close an existing
subsystem at the advice of RADIUS should NOT happen in the ACM
subsystem; it should happen only in the SSH server that provides the
"snmp" service.

Conclusion: let us not use the term "access control" to refer to the
decision made by SSH to allow or reject a request for an "snmp"
subsystem. 

dbh

> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:[email-masked]] 
> Sent: Wednesday, June 28, 2006 12:46 PM
> To: Nelson, David; [email-masked]
> Cc: Jeffrey Hutzelman
> Subject: RE: [Isms] FW: RADIUS integration
> 
> 
>

---

From: "David Harrington" <[email-masked]>
Date: Wed, 28 Jun 2006 15:30:43 -0400

Hi,

There are a number of potential solutions for using RADIUS for SNMP
authorization. Some have been discussed to a degree. There seem to be
two general things to consider:
1) what does the AAA server provide?
2) how does the server get contacted?

-- what gets provided --
One approach would use AAA to actually populate the VACM tables with
all the details needed to support a specific securityName. To use
RADIUS, for example, would require the development of attributes to
carry this information. 

(To me, this seems like using RADIUS to perform SNMP operations to
configure the ACM model's MIB module, and it would require lots of
info to be passed when the user initially makes a request. It also
seems to imply that every user needs a customized VACM configuration,
which I doubt is likely in real world deployments.)

A second approach to using the AAA-provided attributes works on the
assumption that the VACM filters are statically configured at system
boot or management system startup or by a management application, and
the AAA server will simply provide late binding between a securityname
and a GroupName. This is similar to the RADIUS FilterID usage, where
the AAA server only provides the name (or number) of a filter when the
user requests access, and the details of the filter have already been
configured on the system.

-- how does the server get contacted? --

     -- ACM subsystem add-on --
In the interim meeting one approach we discussed was an add-on to the
ACM subsystem, in which the ACM subsystem extension is a AAA client
whose job is to contact a AAA server and ask for the SNMP
authorization information for a specified securityName. There is a
security association between this client and the server that may be
totally independent of any security association between the SSH
transport-mapping's SSH client and any AAA server it uses.

It would be best if we did not need to store credentials within the
ACM subsystem to authenticate the securityName to the RADIUS server.
There is already a SA between the client and server, and we want to
simply use that SA to get the AAA server to tell us the SNMP filters
to apply for that securityName.

     -- cached info --

Another approach works only when the same AAA server is advising a
secure transport protocol (e.g. SSH) for the SNMP messages. When SSH
user-auth is performed to establish a secure connection and an "snmp"
SSH subsystem, the AAA server also passes along the information about
the SNMP-ACM policies to apply to the SSH-specified user-name for the
session. The AAA attributes get cached and passed to the ACM subsystem
(or model) for subsequent use.

We do not have an ASI parameter to pass this info, so either we need
to modify the ASIs as is done with TMSM, or we pass the stuff in an
implementation-dependent manner in the background. For example, if
VACM is the ACM model, then the VACM tables get populated for a
specific securityName when that securityName is determined in the SSH
transport mapping.

I hope this helps to identify the aspects of the problem better.
dbh

---

From: "David Harrington" <[email-masked]>
Date: Wed, 28 Jun 2006 15:51:24 -0400

Hi,

It was suggested that an ACM model querying a RADIUS service might be
advised that a principal is not permitted to perform SNMP to the
device, and that the ACM model should request that the SSH subsystem
be closed.

I strongly disagree with this.

We want a separation between authentication and authorization. And we
want ACM models to be independent of the transport used. 

If an implementer wants to optimize their implementation to do this,
fine, but it should not be part of the standard.

An important part of the goal of the separation of authentication and
authorization is the desire to mix-and-match to meet operational
requirements. Some want to authenticate via kerberos but use RADIUS
for centralized authorization. In one approach, in which an ACM
extension AAA-client talks directly with a RADIUS server, there may
not even be an SSH "snmp" subsystem to close.

dbh

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 1 Jul 2006 00:14:07 +0200

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

/js

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