Re: [Isms] #1: is it important to support anonymous user accesstoSNMP?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Isms] #1: is it important to support anonymous user accesstoSNMP?
Hi -
Perhaps we can distill the what the use cases are asking for:
- that the user of the command generator application does
not need to be known to to the administration. (the security
administrator may, of course, choose to prohibit such access)
This isn't necessarily true anonymity, and I'm sure it would help
if someone could suggest a term from the security community
that means what we intend.
- the request will be encrypted, if the user wants privacy. Other
"anonymous" users will have no advantage in attempting to
decrypt such a request.
- the command responder will have reasonable confidence
that the request has not been modified en route, even by another
"anonymous" users.
- the "anonymous" user making such a request can be referred
to in a VACM policy
- if the request was encrypted, the response will also be encrypted, so
that only the intended recipient (and possibly the sender) will be able to
decrypt it. In particular, other "anonymous" users will NOT have any
advantage in attempting to decrypt the response.
- the user of the command generator application will be able to be
reasonably confident that the response came from the intended
command responder, and was not modified in transit.
(The reason for wanting integrity on the request is due to the way
getNext and getBulk work in SNMP. With a simple get request,
the response would make it clear whether the request had been
mangled in any significant way. With getNext and getBulk, one
can massively change the request, and the response would give
no clue that this had happen, even though the information returned
could indeed be different.)
Randy
_______________________________________________
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.