Re: [Isms] open issues

["Pasi.Eronen at nokia.com" <Pasi.Eronen at nokia.com>]

Randy Presuhn wrote:

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

I guess in case of SSH, this would mean that the notification
originator (acting as SSH client) needs to know:

in the application:
- transportAddress (of the destination)
- securityName (used primarily to determine whether this 
  information should be allowed to leave the box)

in SSHTM (or somewhere): for each (transportAddress, securityName) 
pair, how to do authentication in ssh client role:
- user name to send in SSH
- authentication method (e.g., password or publickey)
- the secret to use (e.g., password, private key)

in SSH:
- for each transportAddress, the host public key

It seems that in this direction, the securityName and SSH user name
won't be the same: securityName would identify someone who's allowed
to see the information ("researchDeptAdmins" or "John"), but SSH user
name would identify the notification originator ("router37" or
"switch12.44.subunit7.example.com"), right?

(In the command generator case, the securityName and SSH user
name identify the same principal, so they could be the same.)

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

BTW, is the securityName only handled solely by the security model, 
or is it included somewhere inside the PDU even when you're using
SSHTM? 

If it's not, could we somehow include it just for this purpose 
(allowing notification receiver to do internal processing)?

Best regards,
Pasi
_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms