Re: [Isms] open issues

["Randy Presuhn" <randy_presuhn at mindspring.com>]

Hi -

> From: "Juergen Schoenwaelder" <j.schoenwaelder at jacobs-university.de>
> To: <Pasi.Eronen at nokia.com>
> Cc: <dbharrington at comcast.net>; <isms at ietf.org>
> Sent: Tuesday, April 22, 2008 3:03 PM
> Subject: Re: [Isms] open issues
>

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

While not disagreeing with Juergen's analysis, I think it might be helpful to
look at the problem in a slightly different way.

Think of a notification subscription as an information retrieval request,
and the notification as the (potentially much-delayed) response.  How
do we know the "response" (the notification) is going to the party that
requested it and not someone else?  After all, *anything* could have
been configured as the notification destination.  In the case of USM,
it's the symmetric key used by the notification subscriber that implicitly
makes this binding, and prevents anyone else from getting at the data first.
(If the data isn't encrypted, the whole question is really moot.)

With USM, there's a reasonable argument for using a separate identity
for notifications for each manager/agent pair.  Otherwise, the compromise
of one managed element would permit the impersonation of others as
notification generators.  (This is discussed in RFC 3414.)  Perhaps
this same approach (keeping the nofitication identities distinct from those
used for monitoring and configuration) might be helpful here.

Randy

_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms