[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Review: IESG Agenda and Package for January 22, 2004 Telechat
- To: pekkas@netcore.fi (Pekka Savola)
- Subject: Re: Review: IESG Agenda and Package for January 22, 2004 Telechat
- From: Keith McCloghrie <kzm@cisco.com>
- Date: Thu, 22 Jan 2004 11:52:33 -0800 (PST)
- Cc: kzm@cisco.com (Keith McCloghrie), j.schoenwaelder@iu-bremen.de, dromasca@avaya.com ("\"Romascanu, Dan (Dan)\""), bwijnen@lucent.com ("\"Wijnen, Bert (Bert)\""), mreview@ops.ietf.org ("\"Mreview (E-mail)\""), ops-area@ops.ietf.org
- In-reply-to: <Pine.LNX.4.44.0401222114380.6729-100000@netcore.fi> from "Pekka Savola" at Jan 22, 2004 09:16:57 PM
> > But, I can't agree that commuinity string is close to the more technical
> > definition of a password where each user has a different password, and
> > knowing the password serves to authenticate you as that user. In this
> > technical sense, a community string is closer to a username. If you
> > had "realized that they are just" usernames, would that similarly
> > have triggered the understanding ??
> >
> > So, my assertion is that describing an SNMP community string as a
> > password is only OK if the document in question is aimed at a
> > non-technical audience.
>
> You don't assume usernames are confidential. However, you do assume
> the passwords are. Community strings are supposed to be confidential
> (except when explicitly deciding they should be public knowledge).
> Therefore community strings act like passwords, authenticating a user
> or a group of users.
I'm sorry, but that is a second order effect, which is not part of the
architecture. Effectively, it's like a "secret society" which keeps
its membership secret (i.e,. the users which belong to it), and
doesn't admit to its own existence.
First order effects can be found by reading the specifications, and to
say community strings are passwords is inconsistent:
a) with the SNMPv1 specification,
b) with the way that many SNMP agents are implemented, and
c) with how RFC 3584 defines Co-Existence between SNMPv1/v2c/v3.
Specifically, the SNMPv1 specification says that a message which claims
to be from one of the users in the community (i.e., in the usergroup) is
automatically authentic. That is, the purpose of a community string is
to identify, not to authenticate.
A common scenario for SNMPv1/v2c agent configuration is to define a
read community string and a read-write community string. How many
systems do you know where a single user has two passwords and gets
different access privileges based on what password that user logins
with ?
RFC 3584 contains the SNMP-COMMUNITY-MIB, which defines snmpCommunityTable
to list the "community strings configured in the SNMP engine's Local
Configuration Datastore" and each row provides "information about a
particular community string". Please note that the information in the
table includes an SNMPv3 user name, and an SNMPv3 context. If
community string were passwords, why would you map them to SNMPv3 user
names ??
Keith.