Re: [Isms] open issues
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Isms] open issues
Randy Presuhn wrote:
> > 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?
>
> Perhaps there's an implementation / deployment choice here,
> driven by the trust model. When a notification stream is
> presented to a management application, whose credentials
> would one want to use to decide whether to accept that stream?
> Ones associated with the subscriber, ones associated with the
> agent, or ones associated with both (i.e. that subscriber at that
> agent, as in a paranoid USM deployment)?
Perhaps we're discovering a limitation that RFC 341x didn't really
consider: when you use pairwise secret keys, the key (and its
securityName) always identifies (at least implicitly) both ends of the
relationship. In case of public key crypto, that's not the case.
> The second consideration is whether existing notification receiver
> applications are using securityName to figure out where to internally
> (within the management system) route notifications. This is outside
> the scope of what we nail down in the SNMP specifications, but would
> be a practical consideration. We need to hear from the management
> application people.
>
> ...
> > 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?
> ...
>
> RFC 3413 section 3.4 specifies that securityName is provided
> to the notification receiver application.
Yes.. but it's not clear whether this is always the same securityName
that was provided by the notification originator application
(identifying the receiver, used for access control on the originator
side), or a securityName identifying the originator.
For pairwise secret keys, it doesn't matter. For public keys, if it's
important to know the former on the notification receiver side, we
might need to pass it separately from the SSH user name.
Best regards,
Pasi
_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.