Re: [Isms] open issues

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

Hi -

> From: "David B. Nelson" <d.b.nelson at comcast.net>
> To: <isms at ietf.org>
> Sent: Wednesday, April 23, 2008 5:13 PM
> Subject: Re: [Isms] open issues
>
> Randy Presuhn writes...
> 
> > Our architecture, both on the manager and on the agent ends,
> > strongly assumes that security mechanisms are able to authenticate
> > to the granularity of a principal.  RFC 3411 sections 3.2.1 and 3.2.2
> > should make that clear.  If SSH doesn't provide (or can't be made to
> > provide) that service, then it's not suitable.
> 
> The authentication inherent to SSH is asymmetric.  It was originally
> designed to facilitate users logging into remote hosts.  An SSH client is
> able (by various SSH Authentication Methods) to authenticate to an SSH
> server at the granularity of a principal.  An SSH server authenticates to
> the SSH client at the granularity of a host (i.e. the host identity of the
> SSH server).
> 
> If you assume that the shared keys of USM are shared at the granularity of a
> principal at both the agent and management station ends on an SNMP
> connection, then USM provides symmetric authentication at the granularly of
> a principal.

With key localization, this is indeed how it works for command generators
and responders.  For the notification case it *can* work the same way,
though with an unfortunate proliferation of securityNames and associated
keys.  (Keeping it simple opens the possibility that a compromised
notification generator could impersonate another.)

> In order to provide authentication at the granularity of a principal in the
> notification case for SSHTM, one would presumably require that the agent act
> as an SSH client and present principal granularity credentials for
> authentication by the SSH server, i.e. the management station.

This sounds fine.

> The fly in the ointment here is that one of the primary reasons for having
> SSHTM is to avoid the need to provision credentials (at principal
> granularity) on all the managed entities in an organization.  In the case of
> a management station sending SNMP commands to an agent, we assume that the
> management station application, or the user invoking that application, has
> an identity that can be validated via some method such as AAA, at the agent.
> That identity may become from some non-volatile configuration store, or it
> may come from the user's login credentials.  I think that the latter case is
> more common.
> 
> It is perfectly possible to provision device credentials in the non-volatile
> configuration store of the managed entities (notification generators) if you
> are willing to experience USM-like scaling properties.

It'd be no worse than USM.  That sounds like a victory.  :-)

Before descending into gloom it might be helpful to carefully think through
the trust model for notification receivers in USM, to understand whether it
is really necessary to go that far.

In the USM world, the transmitting SNMP engine uses the securityName to
determine whether the information in the notification should be allowed to
leave the box.  The SNMP engine receiving that notification uses the
authentication information to make sure the information is genuine.  How
does the sender know the notification has gone to the "right" user?  All it
*really* knows is that the SNMP engine for the notification receiver has
to have that shared key in order to decrypt the payload, and that the
notification's ultimate consumer must have entrusted that engine with
the key.  This gives us an implicit two-way authentication, at least as far
as the protocol engines. In terms of demultiplexing incoming notification streams to
the correct user of the management system, whether based on securityName
or something else, all RFC 3413 has to say in section 3.4 (3) is "After this,
processing depends on the particular implementation."

Consequently, I think whether collapsing things down to a single securityName
per agent for incoming notifications would be adequate depends on
the extent to which implementations of notification receiver applications
rely on securityName to demultiplex notifications corresponding to
different "subscriptions."

Randy

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