The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
6. Acknowledgements
This document is the result of the efforts of the SNMPv3 Working
Group. Some special thanks are in order to the following SNMPv3 WG
members:
Harald Tveit Alvestrand (Maxware)
Dave Battle (SNMP Research, Inc.)
Alan Beard (Disney Worldwide Services)
Paul Berrevoets (SWI Systemware/Halcyon Inc.)
Martin Bjorklund (Ericsson)
Uri Blumenthal (IBM T.J. Watson Research Center)
Jeff Case (SNMP Research, Inc.)
John Curran (BBN)
Mike Daniele (Compaq Computer Corporation)
T. Max Devlin (Eltrax Systems)
John Flick (Hewlett Packard)
Rob Frye (MCI)
Wes Hardaker (U.C.Davis, Information Technology - D.C.A.S.)
David Harrington (Cabletron Systems Inc.)
Lauren Heintz (BMC Software, Inc.)
N.C. Hien (IBM T.J. Watson Research Center)
Michael Kirkham (InterWorking Labs, Inc.)
Dave Levi (SNMP Research, Inc.)
Louis A Mamakos (UUNET Technologies Inc.)
Joe Marzot (Nortel Networks)
Paul Meyer (Secure Computing Corporation)
Keith McCloghrie (Cisco Systems)
Bob Moore (IBM)
Russ Mundy (TIS Labs at Network Associates)
Bob Natale (ACE*COMM Corporation)
Mike O'Dell (UUNET Technologies Inc.)
Dave Perkins (DeskTalk)
Peter Polkinghorne (Brunel University)
Randy Presuhn (BMC Software, Inc.)
David Reeder (TIS Labs at Network Associates)
David Reid (SNMP Research, Inc.)
Aleksey Romanov (Quality Quorum)
Shawn Routhier (Epilogue)
Juergen Schoenwaelder (TU Braunschweig)
Bob Stewart (Cisco Systems)
Mike Thatcher (Independent Consultant)
Bert Wijnen (IBM T.J. Watson Research Center)
The document is based on recommendations of the IETF Security and
Administrative Framework Evolution for SNMP Advisory Team. Members
of that Advisory Team were:
David Harrington (Cabletron Systems Inc.)
Jeff Johnson (Cisco Systems)
David Levi (SNMP Research Inc.)
John Linn (Openvision)
Russ Mundy (Trusted Information Systems) chair
Shawn Routhier (Epilogue)
Glenn Waters (Nortel)
Bert Wijnen (IBM T. J. Watson Research Center)
As recommended by the Advisory Team and the SNMPv3 Working Group
Charter, the design incorporates as much as practical from previous
RFCs and drafts. As a result, special thanks are due to the authors
of previous designs known as SNMPv2u and SNMPv2*:
Jeff Case (SNMP Research, Inc.)
David Harrington (Cabletron Systems Inc.)
David Levi (SNMP Research, Inc.)
Keith McCloghrie (Cisco Systems)
Brian O'Keefe (Hewlett Packard)
Marshall T. Rose (Dover Beach Consulting)
Jon Saperia (BGS Systems Inc.)
Steve Waldbusser (International Network Services)
Glenn W. Waters (Bell-Northern Research Ltd.)
7. Security Considerations
7.1. Recommended Practices
This document is meant for use in the SNMP architecture. The View-
based Access Control Model described in this document checks access
rights to management information based on:
- contextName, representing a set of management information at the
managed system where the Access Control module is running.
- groupName, representing a set of zero or more securityNames. The
combination of a securityModel and a securityName is mapped into a
group in the View-based Access Control Model.
- securityModel under which access is requested.
- securityLevel under which access is requested.
- operation performed on the management information.
- MIB views for read, write or notify access.
When the User-based Access Control module is called for checking
access rights, it is assumed that the calling module has ensured the
authentication and privacy aspects as specified by the securityLevel
that is being passed.
When creating entries in or deleting entries from the
vacmViewTreeFamilyTable it is important to do such in the sequence as
recommended in the DESCRIPTION clause of the vacmViewTreeFamilyTable
definition. Otherwise unwanted access may be granted while changing
the entries in the table.
7.2. Defining Groups
The groupNames are used to give access to a group of zero or more
securityNames. Within the View-Based Access Control Model, a
groupName is considered to exist if that groupName is listed in the
vacmSecurityToGroupTable.
By mapping the combination of a securityModel and securityName into a
groupName, an SNMP Command Generator application can add/delete
securityNames to/from a group, if proper access is allowed.
Further it is important to realize that the grouping of
<securityModel, securityName> tuples in the vacmSecurityToGroupTable
does not take securityLevel into account. It is therefore important
that the security administrator uses the securityLevel index in the
vacmAccessTable to separate noAuthNoPriv from authPriv and/or
authNoPriv access.
7.3. Conformance
For an implementation of the View-based Access Control Model to be
conformant, it MUST implement the SNMP-VIEW-BASED-ACM-MIB according
to the vacmMIBCompliance. It also SHOULD implement the initial
configuration, described in appendix A.
7.4. Access to the SNMP-VIEW-BASED-ACM-MIB
The objects in this MIB control the access to all MIB data that is
accessible via the SNMP engine and they may be considered sensitive
in many environments. It is important to closely control (both read
and write) access to these to these MIB objects by using
appropriately configured Access Control models (for example the
View-based Access Control Model as specified in this document).
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC2578, April
1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC2580, April 1999.
[RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An
Architecture for describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC3411,
December 2002.
[SNMP3412] Case, J., Harrington, D., Presuhn, R. and B. Wijnen,
"Message Processing and Dispatching for the Simple
Network Management Protocol (SNMP)", STD 62, RFC3412,
December 2002.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC3414, December 2002.
8.2. Informative References
[ISO-ASN.1] Information processing systems - Open Systems
Interconnection - Specification of Abstract Syntax
Notation One (ASN.1), International Organization for
Standardization. International Standard 8824, (December,
1987).
Appendix A - Installation
A.1. Installation Parameters
During installation, an authoritative SNMP engine which supports this
View-based Access Control Model SHOULD be configured with several
initial parameters. These include for the View-based Access Control
Model:
1) A security configuration
The choice of security configuration determines if initial
configuration is implemented and if so how. One of three possible
choices is selected:
- initial-minimum-security-configuration
- initial-semi-security-configuration
- initial-no-access-configuration
In the case of a initial-no-access-configuration, there is no
initial configuration, and so the following steps are irrelevant.
2) A default context
One entry in the vacmContextTable with a contextName of "" (the
empty string), representing the default context. Note that this
table gets created automatically if a default context exists.
vacmContextName ""
3) An initial group
One entry in the vacmSecurityToGroupTable to allow access to group
"initial".
vacmSecurityModel 3 (USM)
vacmSecurityName "initial"
vacmGroupName "initial"
vacmSecurityToGroupStorageType anyValidStorageType
vacmSecurityToGroupStatus active
4) Initial access rights
Three entries in the vacmAccessTable as follows:
- read-notify access for securityModel USM, securityLevel
"noAuthNoPriv" on behalf of securityNames that belong to the
group "initial" to the <restricted> MIB view in the default
context with contextName "".
- read-write-notify access for securityModel USM, securityLevel
"authNoPriv" on behalf of securityNames that belong to the
group "initial" to the <internet> MIB view in the default
context with contextName "".
- if privacy is supported, read-write-notify access for
securityModel USM, securityLevel "authPriv" on behalf of
securityNames that belong to the group "initial" to the
<internet> MIB view in the default context with contextName "".
That translates into the following entries in the vacmAccessTable.
- One entry to be used for unauthenticated access (noAuthNoPriv):
vacmGroupName "initial"
vacmAccessContextPrefix ""
vacmAccessSecurityModel 3 (USM)
vacmAccessSecurityLevel noAuthNoPriv
vacmAccessContextMatch exact
vacmAccessReadViewName "restricted"
vacmAccessWriteViewName ""
vacmAccessNotifyViewName "restricted"
vacmAccessStorageType anyValidStorageType
vacmAccessStatus active
- One entry to be used for authenticated access (authNoPriv) with
optional privacy (authPriv):
vacmGroupName "initial"
vacmAccessContextPrefix ""
vacmAccessSecurityModel 3 (USM)
vacmAccessSecurityLevel authNoPriv
vacmAccessContextMatch exact
vacmAccessReadViewName "internet"
vacmAccessWriteViewName "internet"
vacmAccessNotifyViewName "internet"
vacmAccessStorageType anyValidStorageType
vacmAccessStatus active
5) Two MIB views, of which the second one depends on the security
configuration.
- One view, the <internet> view, for authenticated access:
- the <internet> MIB view is the following subtree:
"internet" (subtree 1.3.6.1)
- A second view, the <restricted> view, for unauthenticated
access. This view is configured according to the selected
security configuration:
- For the initial-no-access-configuration there is no default
initial configuration, so no MIB views are pre-scribed.
- For the initial-semi-secure-configuration:
the <restricted> MIB view is the union of these subtrees:
(a) "system" (subtree 1.3.6.1.2.1.1) [RFC3918]
(b) "snmp" (subtree 1.3.6.1.2.1.11) [RFC3918]
(c) "snmpEngine" (subtree 1.3.6.1.6.3.10.2.1) [RFC3411]
(d) "snmpMPDStats" (subtree 1.3.6.1.6.3.11.2.1) [RFC3412]
(e) "usmStats" (subtree 1.3.6.1.6.3.15.1.1) [RFC3414]
- For the initial-minimum-secure-configuration:
the <restricted> MIB view is the following subtree.
"internet" (subtree 1.3.6.1)
This translates into the following "internet" entry in the
vacmViewTreeFamilyTable:
minimum-secure semi-secure
---------------- ---------------
vacmViewTreeFamilyViewName "internet" "internet"
vacmViewTreeFamilySubtree 1.3.6.1 1.3.6.1
vacmViewTreeFamilyMask "" ""
vacmViewTreeFamilyType 1 (included) 1 (included)
vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType
vacmViewTreeFamilyStatus active active
In addition it translates into the following "restricted" entries in
the vacmViewTreeFamilyTable:
minimum-secure semi-secure
---------------- ---------------
vacmViewTreeFamilyViewName "restricted" "restricted"
vacmViewTreeFamilySubtree 1.3.6.1 1.3.6.1.2.1.1
vacmViewTreeFamilyMask "" ""
vacmViewTreeFamilyType 1 (included) 1 (included)
vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType
vacmViewTreeFamilyStatus active active
vacmViewTreeFamilyViewName "restricted"
vacmViewTreeFamilySubtree 1.3.6.1.2.1.11
vacmViewTreeFamilyMask ""
vacmViewTreeFamilyType 1 (included)
vacmViewTreeFamilyStorageType anyValidStorageType
vacmViewTreeFamilyStatus active
vacmViewTreeFamilyViewName "restricted"
vacmViewTreeFamilySubtree 1.3.6.1.6.3.10.2.1
vacmViewTreeFamilyMask ""
vacmViewTreeFamilyType 1 (included)
vacmViewTreeFamilyStorageType anyValidStorageType
vacmViewTreeFamilyStatus active
vacmViewTreeFamilyViewName "restricted"
vacmViewTreeFamilySubtree 1.3.6.1.6.3.11.2.1
vacmViewTreeFamilyMask ""
vacmViewTreeFamilyType 1 (included)
vacmViewTreeFamilyStorageType anyValidStorageType
vacmViewTreeFamilyStatus active
vacmViewTreeFamilyViewName "restricted"
vacmViewTreeFamilySubtree 1.3.6.1.6.3.15.1.1
vacmViewTreeFamilyMask ""
vacmViewTreeFamilyType 1 (included)
vacmViewTreeFamilyStorageType anyValidStorageType
vacmViewTreeFamilyStatus active
B. Change Log
Changes made since RFC2575:
- Removed reference from abstract as per RFC-Editor guidelines
- Updated references
Changes made since RFC2275:
- Added text to vacmSecurityToGroupStatus DESCRIPTION clause to
clarify under which conditions an entry in the
vacmSecurityToGroupTable can be made active.
- Added REVISION clauses to MODULE-IDENTITY
- Clarified text in vacmAccessTable DESCRIPTION clause.
- Added a DEFVAL clause to vacmAccessContextMatch object.
- Added missing columns in Appendix A and re-arranged for
clarity.
- Fixed oids in appendix A.
- Use the PDU Class terminology instead of RFC1905 PDU types.
- Added section 7.4 about access control to the MIB.
- Fixed references to new/revised documents
- Fix Editor contact information.
- fixed spelling errors
- removed one vacmAccesEntry from sample in appendix A.
- made some more clarifications.
- updated acknowledgement section.
Editors' Addresses
Bert Wijnen
Lucent Technologies
Schagen 33
3461 GL Linschoten
Netherlands
Phone: +31-348-480-685
EMail: bwijnen@lucent.com
Randy Presuhn
BMC Software, Inc.
2141 North First Street
San Jose, CA 95131
USA
Phone: +1 408-546-1006
EMail: randy_presuhn@bmc.com
Keith McCloghrie
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
Phone: +1-408-526-5260
EMail: kzm@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.