Re: [Isms] open issues

[Juergen Schoenwaelder <j.schoenwaelder at jacobs-university.de>]

On Mon, Apr 21, 2008 at 07:35:32PM +0300, Pasi.Eronen at nokia.com wrote:
> Juergen Schoenwaelder wrote:
> 
> > > #6 is about whether the access controls applied are for the same
> > > authenticated identity (client vs server) as in USM. I think this
> > > needs further research of who must be authenticated for each
> > > operation type, and whether the security rules about which
> > > identity must be authenticated when using an operation are
> > > consistent with SSH and USM and the architecture.
> > 
> > How can we make progress on this? Would a conference call help? We
> > have gone through this before; perhaps we need to revisit the options
> > we have and come up with pro/con criterias to select one.
> 
> As I'm new to this topic, could you provide e.g. some links to the
> options that have been discussed before?

Let me try to summarize what I think is our main problem. A
traditional SNMP agent has two "modes" of operation:

a) Management applications can query agents or modify state of an
   agent.

b) An agent can generate notifications in order to asynchronously
   notify a manager that a certain event has happened.

For the rest of the discussion, it is only important to remember that
a) implies that the manager is taking the initiative and b) implies
that the agent is taking the initiative. Once we talk about SSH as a
secure transport for SNMP, "mode" (a) implies the manager is becoming
an SSH client initiating a connection to the agent, acting as an SSH
server, while "mode" (b) implies that the agent initiates a connection
to the manager, acting as an SSH server.

The SNMP architecture includes an access control subsystem which
resides on the agent and which is called whenever information is
communicated to the outside world. In "mode" a), all attempts to
read/write information have to pass the access control subsystem.  In
"mode" b), all outgoing notifications have to pass the access control
subsystem as well. The idea is ensure that a principal can only get
access to the information he is authorized to receive, regardless
whether the information is read, written, or communicated via a
notification.

Our problem now is that SSH authentication is asymmetric - the SSH
client authenticates the SSH server while the SSH server authenticates
an SSH user identity residing on the SSH client. As a consequence, in
"mode" a) the agent has an authenticated SSH user name to base its
access control decision on while in "mode" b), the agent has an
authenticated host identity to base its access control decision on. It
may be important to note that on a given host, there can be multiple
notification receivers with different access control requirements.

Several options were investigated how to address this issue and so far
we have not found one that is really making people happy. Some options
considered:

A) A notification originator may initiates the underlying TCP
   connection but then the roles are swapped before the SSH exchange
   beginns. This "solution" has security problems and does not work.

B) Notifications always travel over an SSH connection that has been
   initiated by a "manager" application, so we always have an
   authenticated user identity for access control to work as expected.
   If there is no suitable SSH connection, one can either revert to
   SNMPv3/USM (means ISMS looses its value since you still need a
   fully configured SNMPv3/USM infrastructure) or one can use an
   unauthenticated notification to let the manager initiate a suitable
   SSH connection (ugly and likely has similar security issues like
   A). Furthermore, in many implementations, command generators and
   notification receivers are not really tight together so using a
   shared SSH connection may simply not be realistic for a large range
   of existing code bases.

C) Work around the issue by using SSH host-based authentication. This
   option has issues with situations where a single host may contain
   multiple notification receivers that are authorized to receive only
   different subsets of notifications, see above.

There might be more options or variations we have considered and which
I have forgotton to mention in this email.

Was this explanation understandable? If not, keep asking questions.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms