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,

Comments inline. 

> -----Original Message-----
> From: Fleischman, Eric [mailto:eric.fleischman at boeing.com] 

> I propose that we support a wide
> variety of authentication alternatives and that those alternatives
are
> then mapped to various authorization results via locally defined
> policies. 

In SNMPv3, we have an authentication subsystem and an access control
subsystem. It will always be that an entity that is authenticated (or
not, using noAuthNpPriv) will then be mapped to authorization policies
using securityName.

Personally, rather than seeing support for a wide variety of
authentication alternatives, I'd like to see us support the
widely-deployed SSH authentication mechanisms that serve SNMP needs. I
am willing to accept that we should support any authentication
mechanism REQUIRED or RECOMMENDED for use with the SecSH standard.

Is anonymous SSH authentication supported by the secsh standards?

The question is really, does SSHSM need to support an authentication
mechanism so anonymous entities can have access to raw SNMP data?

I can see use-cases for anonymous access to a system, such as for FTP
downloads of publicly accessible information, but I have difficulty
seeing use-cases for anonymous SNMP access to a system, and I am
concerned that adding this feature that has never existed in SNMP
(although "public" is pretty close to anonymous) will increase the
complexity of SSHSM with no real benefit to justify the added
complexity.

I personally believe it is NOT important to support anonymous SNMP
access to SNMP data, and it is not important that SSHSM support this.

David Harrington
dbharrington at comcast.net




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