RFC3415- SNMP VACM 中文版(1)
2007-09-29 10:20:31
Network Working Group B. Wijnen
Request for Comments: 3415 Lucent Technologies
STD: 62 R. Presuhn
Obsoletes: 2575 BMC Software, Inc.
Category: Standards Track K. McCloghrie
Cisco Systems, Inc.
December 2002
译者：施磊 shilei_back06@yahoo.com.cn
基于视图的访问控制安全模型 (VACM) 适用于简单网络管理协议(SNMP)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
抽象描述
此文档描述了基于视图的访问控制安全模型 (VACM) 适用于简单网络管理协议 (SNMP)
的架构. 它定义了条件控制管理的基本执行过程. 此文档同时包括了远程管理基于视图
的条件控制模块配置参数的的管理信息库. 此文档废弃了RFC 2575.
Wijnen, et al. Standards Track [Page 1[
RFC 3415 VACM for the SNMP December 2002
目录
1. 概述 ................................................... 2
1.2. 条件控制 ............................................. 3
1.3. 本地配置存储 ......................................... 3
2. 模型的元素 ............................................. 4
2.1. 多组 ................................................. 4
2.2. 安全级别 ............................................. 4
2.3. 上下文 ............................................... 4
2.4. MIB 的视图和视图管理 ................................. 5
2.4.1. 子树的视图 ......................................... 5
2.4.2. 视图树的集合 ....................................... 6
2.5. 条件控制机制 ......................................... 6
3. 基本过程元素 ........................................... 7
3.1. isAccessAllowed 过程的概述 ........................... 8
3.2. 执行isAccessAllowed 的服务请求 ....................... 9
4. 定义 ................................................... 11
5. 智慧财产 ............................................... 28
6. 致谢.................................................... 28
7. 安全问题的考虑 ......................................... 30
7.1. 实践相关 ............................................. 30
7.2. 定义组 ............................................... 30
7.3. 一致性 ............................................... 31
7.4. 访问 SNMP-VIEW-BASED-ACM-MIB .......................... 31
8. 参考 ................................................... 31
A. 安装 ................................................... 33
B. 修改记录 ............................................... 36
作者地址 ................................................... 38
版权声明 ................................................... 39
1. 概述
SNMP 引擎架构及Internet管理架构[RFC3411] 的描述由以下模块组成:
1) 报文调度
2) 报文处理子系统,
3) 安全子系统, 和
4) 条件访问子系统.
应用程序系统应调研上述子系统的服务借口.
理解SNMP的架构和他的专业术语是非常重要的, 可以有助于将条件访问控制安全模块
设计融入SNMP的架构中, 同时与其他子系统可以顺利链接. 此文档的读者需要理解
RFC3411中描述的SNMP架构和专业术语。
Wijnen, et al. Standards Track [Page 2[
RFC 3415 VACM for the SNMP December 2002
SNMP引擎的条件访问控制子系统有责任检验是否授予特定对象的读，写，通知的访问
权限。
此文档的目的是定义一个特定的访问控制子系统模型，即基于视图的访问控制子系统模型。
当然需要指明的是这并不是唯一的访问控制子系统模型。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119.
1.2. 访问控制
当执行从SNMP实体中读取或修改的请求操作时，访问控制将在SNMP实体中
(粗略或精确地)运行。举个例子，当命令接收程序接收到指令时将执行
访问控制子模块。RFC3411定义了指令请求包含了读和写的报文格式(PDU)。
当SNMP的通报报文产生时，SNMP实体也将执行访问控制(在产生通报报文的程序中).
RFC3411定义了通报报文的格式.
基于视图的访问控制模型定义了一组服务借口, 应用程序(指令产生器和通报报文发生器)
将调用这些接口检测访问权限. 应用程序应调用正确的服务接口达到实现访问控制的实施.
1.3. 本地配置存储 Local Configuration Datastore
为了实现此文档中描述的安全模型， 一个SNMP实体应保存一定的信息，包括访问权限和
机制。这些信息包含在本地配置存储(LCD)中。 RFC中可以找到相关定义。
为了能够实现远程配置SNMP实体的LCD, LCD需包含能够访问的管理对象。这些对象定义了
管理对象的类型，此文档给出了 View-based Access Control Model Configuration MIB。
Wijnen, et al. Standards Track [Page 3[
RFC 3415 VACM for the SNMP December 2002
2. 模型的元素
这一章节给出了基于视图的访问控制模型中实现的访问控制接口的各项定义.
2.1. 组
组定义了SNMP管理对象的访问方式, 它由(<安全模型, 安全名字>)
组成, 或是空值. 组里包含了基于securityName的相关权限. securityModel 和securityName
的组合构成了组的概念, 组有唯一的标识groupName.
访问控制模型中, securityName 可以作为认证过的元素使用, 不需要额外的认证.
基于视图的访问控制模型将securityModel和securityName作为输入, 进行验证.
访问控制模型决定了groupName是securityModel和securityName的参量.
2.2. 安全级别 securityLevel
组中的成员将被赋予不同的访问权限，也就是设定安全等级，包括noAuthNoPriv, authNoPriv和
authPriv。 安全级别将被应用在检测访问控制权限过程中。参见RFC3411中的有关securityLevel
的定义。
基于视图的访问控制在检测访问权限时，需要将securityLevel作为访问控制模块的输入。
2.3. 上下文 Contexts
SNMP的上下文是指在一个SNMP实体中存储的管理信息。一条管理信息可以存储在多个
SNMP上下文中。 一个SNMP实体可以拥有多个上下文。详细描述可以参见RFC3411。
基于视图的访问控制定义了vacmContextTable，其中列出了与contextName相关的
本地的上下文。
Wijnen, et al. Standards Track [Page 4[
RFC 3415 VACM for the SNMP December 2002
2.4. MIB 视图和视图组
基于安区因素的考虑，在管理层的实施中，只授予部分组的非全部的访问权限。
为了实现这一功能，可以通过"MIB view"察看一个SNMP上下文, "MIB view"制定了
管理对象(有可能是实例化后对象)的类型。例如，在一个上下文中，通常有一
个MIB view, 它提供了访问控制的管理信息．此外，还有其他的"MIB view"，它们
只包含这些管理信息的一部分．因此，授予组的访问权限可以通过设定其组的
"MIB view"实现其需要的上下文．
由于管理对象(及其实例)的类型是通过ISO's OBJECT IDENTIFIERs [ISO-
ASN.1, RFC2578]的树型命名结构描述的，所以能够非常方便地用子视图组成
视图．因此，一个简单的MIB视图(例如所有的Internet Network Management Framework
管理对象)可以定义成为一个视图子树．而多个视图子树可以组成复杂的视图．
当管理对象通过视图子树的形式描述时，具备复杂格式的视图便由此产生．
同一概念的行中的列值可以出现在不同的视图子树中，他们的格式也十分相似．
当格式相同时，他们能够很容易的组合成表示同一概念的结构中．这种结构可以看成
视图子树的概念组合．一个视图子树的概念组合可以包含于或不包含于一个
视图中．
2.4.1. 视图子树
视图子树由MIB对象构成， 这些MIB是由ASN.1的描述语言表现的。视图子树
的识别符为OBJECT IDENTIFIER，它是视图子树的前缀描述符。
Wijnen, et al. Standards Track [Page 5[
RFC 3415 VACM for the SNMP December 2002
2.4.2. 视图树组合
视图树组合是由一对对对象描述符(叫视图树组合名)组合而成。视图树组合掩码指定
了子视图树组合名与视图树组合的关联关系。
每一个管理对象的实例，当满足下列条件时，它才能成为视图树组合(ViewTreeFamily):
- 管理对象的标识符(OBJECT IDENTIFIER name)包含子视图树组合名或视图树组合名
- 管理对象的标识符(OBJECT IDENTIFIER name)的子标识符与视图树组合名相匹配，如果
相关的视图树组合名的掩码不为空时。
当设定的视图树组合名掩码都为1时，视图子树组合名与视图树组合名的子树相吻合。
在上面的检验过程中，当设定的视图树组合名掩码的长度小于所需长度是，将全部补1。
同样的，视图子树组合的掩码为0时，它就指向单一的视图子树。
2.5. 访问机制
基于视图的访问控制模型决定了组的访问权限，组中即可能是空值或多个安全名
(securityNames). 在一个上下文(用contextName命名)中，通过设定读视图,写视图和
通报视图, securityModel和securityLevel, 组(groupName表示组名)被授予访问权限. ew.
读视图给出了允许组进行读的对象实例. 读的对象的运行发生在读的过程中
(当读的报文被处理时)
写视图给出了允许组进行写的对象实例. 写的对象的运行发生在写的过程中
(当写的报文被处理时)
通报视图给出了允许组进行通报的对象实例. 通报视图发生在通报的过程中.
(当通报报文被处理时)
Wijnen, et al. Standards Track [Page 6[
RFC 3415 VACM for the SNMP December 2002
3. 过程的基本元素
此章节描述了应用程序(命令产生器和通报产生器)中, 基于视图的访问控制模块
中, 访问权限检测的过程.
基本的服务元素为:
statusInformation = -- success or error Indication
isAccessAllowed(
securityModel -- Security Model in use
securityName -- principal who wants access
securityLevel -- Level of Security
viewType -- read, write, or notify view
contextName -- context containing variableName
variableName -- OID for the managed object
)
基本信息元素为:
statusInformation - 值为下面中的一种:
accessAllowed - 查找到MIB视图, 访问权限已经授予.
notInView - 查找到MIB视图, 访问权限未授予.
与viewType相关的variableName 不在MIB视图中
(即, 不在vacmAccessTable中)
noSuchView - 未查找到MIB视图, 没有与viewType相关的设定
(不在vacmAccessTable中).
noSuchContext - 未查找到MIB视图, 没有与contextName相关的设定.
noGroupName - 未查找到MIB视图, 在vacmSecurityToGroupTable没有
securityModel和securityName相关的组合.
noAccessEntry - 未查找到MIB视图, 在vacmSecurityToGroupTable没有
securityModel,securityName,securityModel和securityLevel
相关的组合.
otherError - 其它错误.
securityModel - 需要安全模型.
securityName - 需要用户的访问机制.
securityLevel - 需要安全级别.
viewType - 需要检验试图 (读,写,和通报).
contextName - 需要访问控制上下文.
variableName - 需要访问控制的对象实体.
Wijnen, et al. Standards Track [Page 7[
RFC 3415 VACM for the SNMP December 2002
3.1. isAccessAllowed 过程描述
下图显示了访问控制模型中访问控制检测的过程。
+--------------------------------------------------------------------+
| |
| +-> securityModel -+ |
| | (a) | |
| who -+ +-> groupName ----+ |
| (1) | | (x) | |
| +-> securityName --+ | |
| (b) | |
| | |
| where -> contextName ---------------------+ |
| (2) (e) | |
| | |
| | |
| +-> securityModel -------------------+ |
| | (a) | |
| how -+ +-> viewName -+ |
| (3) | | (y) | |
| +-> securityLevel -------------------+ | |
| (c) | +-> yes/no |
| | | decision |
| why ---> viewType (read/write/notify) ----+ | (z) |
| (4) (d) | |
| | |
| what --> object-type ------+ | |
| (5) (m) | | |
| +-> variableName (OID) ------+ |
| | (f) |
| which -> object-instance --+ |
| (6) (n) |
| |
+--------------------------------------------------------------------+
Wijnen, et al. Standards Track [Page 8[
RFC 3415 VACM for the SNMP December 2002
访问控制检测过程如下.
1) isAccessAllowed 服务接口的输入为:
(a) securityModel -- 安区模型
(b) securityName -- 访问主体
(c) securityLevel -- 安全级别
(d) viewType -- 读，写，和通报视图
(e) contextName -- variableName变量名的上下文
(f) variableName -- 管理对象的OID
-- this is made up of:
- object-type (m)
- object-instance (n)
2) "who" (1), 其识别符由securityModel (a) and
the securityName (b)构成, 作为它的索引值(a,b)，从
vacmSecurityToGroupTable 找出他的对应值group, 由groupName (x)表示.
3) "where" (2), 由contextName (e)表示, 结合"who"(上一步的groupName(x)),
连同"how" (3)(由securityModel (a) and securityLevel (c)表示),组成 (e,x,a,c),
从vacmAccessTable找出对应的三个视图.
4) "why" (4), 由viewType(d)表示, 用于选择正确的MIB视图(标识为viewName (y)),
在上一步中从vacmAccessEntry找出. viewName (y)是vacmViewTreeFamilyTable的
索引值, 然后选择MIB视图中包含或不包含的variableNames (由viewName (y)表示).
5) "what" (5) 表示管理的对象 和 "which" (6) 对象实例, 由variableName (f)表示,
最后由MIB试图表中的检验结果决定最终得yes/no决定 (z).
3.2. isAccessAllowed 服务请求的处理
此章节描述了访问控制模型接受到检测请求的处理过程.
1) 通过关键字contextName查阅vacmContextTable，可以得到SNMP上下文的信息.
当SNMP上下文的信息不在此表中时，将返回错误指示(noSuchContext).
Wijnen, et al. Standards Track [Page 9[
RFC 3415 VACM for the SNMP December 2002
2) vacmSecurityToGroupTable的查询发生在将securityModel和securityName
映射成groupName的时候. 如果没有找到，将返回错误指示(noGroupName).
3) vacmAccessTable的查询发生在查找groupName, contextName, securityModel
和securityLevel信息时. 如果没有找到，将返回错误指示(noAccessEntry).
4) a) 如果viewType为"read", 读视图被用于访问权限的检测。
b) 如果viewType为"write", 写视图被用于访问权限的检测。
c) 如果viewType为"notify", 通报视图被用于访问权限的检测.
当空视图(viewName长度为0)时，将返回错误指示(noSuchView).
5) a) 当viewType的视图设定值为空时, 将返回错误指示(noSuchView) .
b) 当 variableName (对象实例)不在MIB视图中(见第四章中有关vacmViewTreeFamilyTable
的描述), 将返回错误指示(notInView).
此外,
c) 当variableName存在于MIB视图中时, 将返回访问许可(accessAllowed).
Wijnen, et al. Standards Track [Page 10[
RFC 3415 VACM for the SNMP December 2002
4. 定义
SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
MODULE-IDENTITY, OBJECT-TYPE,
snmpModules FROM SNMPv2-SMI
TestAndIncr,
RowStatus, StorageType FROM SNMPv2-TC
SnmpAdminString,
SnmpSecurityLevel,
SnmpSecurityModel FROM SNMP-FRAMEWORK-MIB;
snmpVacmMIB MODULE-IDENTITY
LAST-UPDATED "200210160000Z" -- 16 Oct 2002, midnight
ORGANIZATION "SNMPv3 Working Group"
CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com
Subscribe: majordomo@lists.tislabs.com
In message body: subscribe snmpv3
Co-Chair: Russ Mundy
Network Associates Laboratories
postal: 15204 Omega Drive, Suite 300
Rockville, MD 20850-4601
USA
email: mundy@tislabs.com
phone: +1
