Re: [Isms] #8: Do we need a mapping between the SSH key and SNMP engineID?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Isms] #8: Do we need a mapping between the SSH key and SNMP engineID?



>>>>> "David" == David B Harrington <dbharrington at comcast.net> writes:

    David> #8: Do we need a mapping between the SSH key (or other SSH
    David> engine identifier) and SNMP engineID? What happens if an
    David> agent "spoofs" another engineID, and an NMS perfoms a SET
    David> of sensitive parameters to the agent?

I cannot answer this question because I don't have enough
understanding of SNMP.  I can answer a related question.

You must authenticate each party  back to some name the user provided.

On the server: you will get a username out of ssh's user
authentication step.  You need to make an access control decision and
assign access rights based on that username.  (I'd argue that as a
general rule, that username is the only thing that in practice should
matter in terms of assigning those access rights.  The particular
credentials presented and the particular authentication type used
should not in general matter.  )

On the client, it is more tricky.  You need to securely map
information provided by the user into an ssh service to contact and a
username to present to that service.  Then, you need to make an access
control decision and determine if the credentials presented by that
service are acceptable.  If so, you need to decide as an access
control matter what PDUs are acceptable to send to the server.

The above is not SNMP specific.  The above is true of any ssh
application.  One of the primary challenges of this working group is
transalting that requirement into SNMP, possibly changing the
architecture in the process.

This will become more complicated because of notifications.


_______________________________________________
Isms mailing list
Isms at lists.ietf.org
https://www1.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.