Re: [Isms] open issues

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

Hi -

> From: "Juergen Schoenwaelder" <j.schoenwaelder at jacobs-university.de>
> To: "Randy Presuhn" <randy_presuhn at mindspring.com>
> Cc: <isms at ietf.org>
> Sent: Wednesday, April 23, 2008 12:45 AM
> Subject: Re: [Isms] open issues
...
> I guess you talk about this option:
> 
> D) The notification receiver establishes an SSH connection (acting as
>    an SSH client) and configures the SNMP agent (acting as an SSH
>    server) to send notifications via this SSH connection. This plays
>    nicely with the way SNMP access control works.
> 
>    The drawbacks of this approach are that (i) you have to have a
>    command responder co-located with a notification originator, (ii)
>    it won't work with short-lived notification originators, such as
>    snmptrap commandline utilities, (iii) you have to keep SSH
>    connection alive to all notification receivers, and (iv) the
>    garbage collection of notification target configurations when the
>    SSH sessions disappear needs to be worked out (but that seems to be
>    a minor issue).
> 
> If you have something else in mind, let me know.
...

That's not what I intended.  My point was that in the USM world,
the agent will have been configured with information that (1)
allows an access control policy to be applied before allowing
information to leave the box in a notification, and (2) prevents
that information from being used by anyone else without having
first passed through something that has the right key.  Also of
interest is (3) that the identity used for sending the notification
isn't necessarily the identity used to create the subscription.

(2) is *logically* authentication, but in fact in USM it's the symmetric
encryption key that makes it work.

I think it's pretty clear that session management for notification
streams should be handled by the notification originator, short-lived
or not.  For the notification receiver to be responsible for creation
and teardown would be much less robust and not scale as well.

So if the manager is an SSH server as far as notification streams
are concerned, I think things work out about as well as they do with
USM (if one has configured USM to not be vulnerable to the potential
compromise of an agent system.)  Specifically, it means that for a 
notification user, a separate securityName would need to be created
for each manager/agent pair.  (Otherwise one agent could impersonate
another.) Though the access control policy is applied on the agent,
that securityName is also what would be needed to establish the
SSH connection with whatever manager is to be used as the trap
destination, thus giving the desired authentication, or at least as
much authentication as a manger gets when it sends configuration
data to an agent.

Randy

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