📄 rfc2265.txt
字号:
STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row. " DEFVAL { nonVolatile } ::= { vacmViewTreeFamilyEntry 5 }vacmViewTreeFamilyStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. The RowStatus TC [RFC1903] requires that this DESCRIPTION clause states under which circumstances other objects in this row can be modified: The value of this object has no effect on whether other objects in this conceptual row can be modified. " ::= { vacmViewTreeFamilyEntry 6 }-- Conformance information *******************************************Wijnen, et. al. Standards Track [Page 24]RFC 2265 VACM for SNMPv3 January 1998vacmMIBCompliances OBJECT IDENTIFIER ::= { vacmMIBConformance 1 }vacmMIBGroups OBJECT IDENTIFIER ::= { vacmMIBConformance 2 }-- Compliance statements *********************************************vacmMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP engines which implement the SNMP View-based Access Control Model configuration MIB. " MODULE -- this module MANDATORY-GROUPS { vacmBasicGroup } OBJECT vacmAccessContextMatch MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT vacmAccessReadViewName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT vacmAccessWriteViewName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT vacmAccessNotifyViewName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT vacmAccessStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT vacmAccessStatus MIN-ACCESS read-only DESCRIPTION "Create/delete/modify access to the vacmAccessTable is not required. " OBJECT vacmViewTreeFamilyMask WRITE-SYNTAX OCTET STRING (SIZE (0)) MIN-ACCESS read-only DESCRIPTION "Support for configuration via SNMP of subtree families using wild-cards is not required. " OBJECT vacmViewTreeFamilyType MIN-ACCESS read-onlyWijnen, et. al. Standards Track [Page 25]RFC 2265 VACM for SNMPv3 January 1998 DESCRIPTION "Write access is not required." OBJECT vacmViewTreeFamilyStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT vacmViewTreeFamilyStatus MIN-ACCESS read-only DESCRIPTION "Create/delete/modify access to the vacmViewTreeFamilyTable is not required. " ::= { vacmMIBCompliances 1 }-- Units of conformance **********************************************vacmBasicGroup OBJECT-GROUP OBJECTS { vacmContextName, vacmGroupName, vacmSecurityToGroupStorageType, vacmSecurityToGroupStatus, vacmAccessContextMatch, vacmAccessReadViewName, vacmAccessWriteViewName, vacmAccessNotifyViewName, vacmAccessStorageType, vacmAccessStatus, vacmViewSpinLock, vacmViewTreeFamilyMask, vacmViewTreeFamilyType, vacmViewTreeFamilyStorageType, vacmViewTreeFamilyStatus } STATUS current DESCRIPTION "A collection of objects providing for remote configuration of an SNMP engine which implements the SNMP View-based Access Control Model. " ::= { vacmMIBGroups 1 }END5. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rightsWijnen, et. al. Standards Track [Page 26]RFC 2265 VACM for SNMPv3 January 1998 might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. 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: Dave Battle (SNMP Research, Inc.) Uri Blumenthal (IBM T.J. Watson Research Center) Jeff Case (SNMP Research, Inc.) John Curran (BBN) T. Max Devlin (Hi-TECH Connections) John Flick (Hewlett Packard) David Harrington (Cabletron Systems Inc.) N.C. Hien (IBM T.J. Watson Research Center) Dave Levi (SNMP Research, Inc.) Louis A Mamakos (UUNET Technologies Inc.) Paul Meyer (Secure Computing Corporation) Keith McCloghrie (Cisco Systems) Russ Mundy (Trusted Information Systems, Inc.) Bob Natale (ACE*COMM Corporation) Mike O'Dell (UUNET Technologies Inc.) Dave Perkins (DeskTalk) Peter Polkinghorne (Brunel University) Randy Presuhn (BMC Software, Inc.) David Reid (SNMP Research, Inc.) Shawn Routhier (Epilogue) Juergen Schoenwaelder (TU Braunschweig) Bob Stewart (Cisco Systems) Bert Wijnen (IBM T.J. Watson Research Center)Wijnen, et. al. Standards Track [Page 27]RFC 2265 VACM for SNMPv3 January 1998 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 Considerations7.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.Wijnen, et. al. Standards Track [Page 28]RFC 2265 VACM for SNMPv3 January 1998 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 vacmViewFamiliyTreeTable it is important to do such in the sequence as recommended in the DESCRIPTION clause of the vacmViewFamilityTable 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. It also SHOULD implement the initial configuration, described in appendix A.8. References [RFC1902] Case, J., McCloghrie, K., Rose, M. and S., Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. [RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.Wijnen, et. al. Standards Track [Page 29]RFC 2265 VACM for SNMPv3 January 1998 [RFC2261] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for describing SNMP Management Frameworks", RFC 2261, January 1998. [RFC2262] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2262, January 1998. [RFC2264] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -