📄 rfc1445.txt
字号:
指一个这样的关系:参与者harpo感到满意的关系.(这个代理的目的地的参与者的
传输域决定了代理源的解释和代理上下文的确认---在这种情况下,用
acmeMgmtPrtcl表明代理源和上下文是可以忽略的)
为了询问与参与者harpo相关的私有设备,管理站的groucho构造了一个SNMPv2
的GetNext 请求,其中包含一个SnmpMgmtCom的值,该值是参考SNMPv2的上下文
ducksoup,并且传输它给在IP地址为1.2.3.5、UDP端口为161的参与者chico.该请求
是用私有认证密钥“0123456789ABCDEF”来认证的.
当该请求被参与者chico接收到后,消息的发起者作为参与者groucho通过使用
本地信息(见表9 )的私有密钥“0123456789ABCDEF”来效验.由于参与者groucho
通过发布一个通过访问控制策略(见表12)对参与者chico和SNMPv2的上下文
ducksoup 的GetNext(也可以是Get、GetBulk)请求来获得认证.从而该请求获得认
可.由于上下文信息的本地数据库指明了SNMPv2的上下文 ducksoup是参考了一个代
理关系,这个请求可通过直接翻译到参与者harpo的合适的操作acmeMgmtPrtcl上来
获得确认.这些新的操作传输到参与者harpo的acmeMgmtPrtcl的域上的0x98765432
地址上.
代理和私有设备之间私有协议的交流要求:一个SNMPv2响应管理操作是通过参
与者chico转发参与者grpucho的结果而不是参考SNMPv2的上下文ducksoup.这个响
应通讯是为了原始的和完整性的认证,可通过在参与者chico的传输中指明使用认证
协议“v2md5AuthProtocol”和私有认证密钥“GHIJKL0123456789”来实现.它传输
给在管理站点的SNMPv2参与者groucho,其IP地址为1.2.3.4、UDP端口为2002(相应
请求的源地址).
当参与者groucho接受到这个响应后,参与者chico通过使用本地私有认证密钥
信息(见表 11)“GHIJKL0123456789”来效验发起者的信息.由于参与者chico可根
据相关访问策略(见表12),再通过发布关于参与者groucho和SNMPv2上下文ducksoup
的响应通讯来认证,其响应获得认可,同时结束对私有设备的询问.
通过观察记录管理站在代理机构(表9 )上既不是静态的、也不是专有配置的
本地数据库的参与者信息是很重要的.例如,在这个例子中,假设acmeMgmtPrtcl是
一个管理站连接到局域网上的私有的MAC-layer机构.在这样的环境下,SNMPv2参与
者chico想驻留在连接到LAN的SNMPv2代理机构,通过局域网协议的参与,去发现附
件和未连接到局域网上的各类站点.在这中情况下,SNMPv2代理很容易调整它的本地
参与者的数据库信息,达到通过SNMPv2管理站点来支持不是直接受局域网管理的站
点.对每个新发现的局域网站点,SNMPv2代理可以把它作为一个类似于参与者harpo
(代表局域网本身的)的条目添加它到参与者信息的本地数据库中,也可以添加它
到上下文信息的本地数据库中,作为一个类似于SNMPv2的上下文ducksoup(代表在
SNMPv2域中新站点的代理关系)的条目来处理.
由SNMPv2代理机构通过使用SNMPv2来询问参与者的本地数据库信息,只要有新
站点连接到局域网上来.一个SNMPv2管理站能够发现和影响它们,
4.4.2 本地代理配置
该段介绍了一个关于配置支持SMPv2本地代理操作的例子.即在一个SNMPv2代理
和一个要通过次要SNMPv2代理仲裁的管理站之间进行非直接交互的操作.
该例子的配置和上面的外部代理的介绍是类似的.在这个例子中,无论如何,与
身份为harpo相关的参与者通过SNMPv2接收消息,并且和SNMPv2代理chico用认证的
SNMPv2通讯来进行交互.
表13介绍了关于SNMPv2参与者的信息,它记录在SNMPv2代理的代理信息的本地
数据库中.表14介绍了关于记录在SNMPv2代理的上下文信息的本地数据库中的代理
关系信息.表11介绍了关于记录在SNMPv2管理站点的参与者信息的本地数据库中
SNMPv2参与者信息.表15介绍了关于在本地管理中指明的访问策略的数据库信息.
身份 groucho chico
(管理者) (代理)
域 snmpUDPDomain snmpUDPDomain
地址 1.2.3.4, 2002 1.2.3.5, 161
认证端口 v2md5AuthProtocol v2md5AuthProtocol
认证私有密钥 "0123456789ABCDEF" "GHIJKL0123456789"
认证公开密钥 "" ""
认证时钟 0 0
Auth Lifetime 300 300
Priv Prot noPriv noPriv
Priv Priv Key "" ""
Priv Pub Key "" ""
Identity harpo zeppo
(代理目的) (代理源)
Domain snmpUDPDomain snmpUDPDomain
Address 1.2.3.6, 161 1.2.3.5, 161
Auth Prot v2md5AuthProtocol v2md5AuthProtocol
Auth Priv Key "MNOPQR0123456789" "STUVWX0123456789"
Auth Pub Key "" ""
Auth Clock 0 0
Auth Lifetime 300 300
Priv Prot noPriv noPriv
Priv Priv Key "" ""
Priv Pub Key "" ""
表 13: 代理的参与者信息
上下文 代理目的 代理源 代理上下文
ducksoup harpo zeppo bigstore
bigstore groucho chico ducksoup
表14: 代理的代理关系
目标 主体 Context Privileges
chico groucho ducksoup 35 (Get, GetNext & GetBulk)
groucho chico ducksoup 132 (Response & SNMPv2-Trap)
harpo zeppo bigstore 35 (Get, GetNext & GetBulk)
zeppo harpo bigstore 132 (Response & SNMPv2-Trap)
表 15: 本地代理的访问信息
在表13中介绍说,代理的参与者在IP地址为1.2.3.5、UDP端口为161上用身份
chico来操作的.该例子的管理者在IP地址为1.2.3.4、UDP端口为2002上用身份
groucho来操作的.;代理源参与者在IP地址为1.2.3.5、UDP端口为161上用身份zeppo
来操作的.;代理目的参与者在IP地址为1.2.3.6、UDP端口为161上用身份harpo来操
作的.4个SNMPv2参与者的认证产生的信息是为了保证原始性和完整性,他们使用了
认证协议 v2md5AuthProtocol 和不同的私有认证密钥.虽然这些私有认证密钥的值
("0123456789ABCDEF","GHIJKL0123456789", "MNOPQR0123456789"和
"STUVWX0123456789")在这里描述出来了,但私有密钥的信息一般是不能告诉人们
的,同时要限制一些请求它协议操作.
表14 介绍了相互了解的代理机构间代理关系,更具体的讲,SNMPv2上下文
ducksoup是参考这样一个关系的:被SNMPv2参与者zeppo和SNMPv2参与者harpo的通
讯认可了,同时也参考了SNMPv2的上下文bigstore.
为了询问与参与者harpo相关的代理设备,管理站点groucho构造一个SNMPv2的
GetNext请求,该请求中包含了参考SNMPv2的上下文ducksoup的SnmpMgmtCom值,并
且传输给在IP为1.2.3.5、UDP端口为161的(见表11)参与者chico,这个请求是用
私有认证密钥“0123456789ABCDEF”来认证的.
当参与者chico收到请求时,消息的发起者是通过参与者grouhco使用本地信息
(见表13)关于私有认证密钥“0123456789ABCDEF”来校验的.由于参与者groucho
是通过发布GetNext(也可以是get和getbulk)请求来认证的,该发布是参考了参与
者chico和相关访问控制策略(见表15)的SNMPv2上下文ducksoup,故该请求被接受.
由于上下文信息的本地数据库指明了参考代理关系的SNMPv2上下文ducksoup,这个
通过翻译为一个从参与者zeppo到参与者harpo的相应SNMPv2的 GetNext请求,同时
也参考了SNMPv2的上下文bigstore的请求,是可以得到确认的.通过使用私有认证
“STUVWX0123456789”来认证新的通讯和传输到IP地址为1.2.3.6的参与者harpo.
当新的请求被参与者harpo收到时,消息的发起者是通过参与者zeppo使用本地
信息(见表13)关于私有认证密钥“STUVWX0123456789”来校验的.由于参与者zeppo
是通过发布GetNext(也可以是get和getbulk)请求来认证的,该发布参考了参与者
harpo和相关访问控制策略(见表15)的SNMPv2上下文ducksoup,故该请求被接受.
描述了询问结果的SNMPv2响应消息是通过参与者harpo到参与者zeppo来生成的.并
参考了SNMPv2的上下文bigstore.这个响应通讯也是使用私有认证密钥
“MNOPQR0123456789”来认证的,并传输给IP地址为1.2.3.5的参与者zeppo(相应
的请求的源地址)
当这个响应被参与者zeppo收到时,信息的发起者是通过参与者harpo使用本地
信息(见表13)关于私有认证密钥“MNOPQR0123456789”来校验的.由于参与者harpo
是通过发布和响应通讯来认证的,该通讯参考了参与者zeppo和通过相关的访问控制
策略(表15)SNMPv2的上下文bigstore ,响应是可以接受的.并且它是对原始的
GetNext请求构造响应,表明为一个ducksoup的SNMPv2上下文.从参与者chico到参与
者groucho响应的原始性和完整性通过使用私有认证密钥“GHIJKL0123456789”来认
证的,并传输给IP地址为1.2.3.5的参与者groucho(相应原始请求的源地址).
当这个响应被参与者groucho收到时,消息的发起者是通过参与者chico使用本
地信息(见表13)关于私有认证密钥“GHIJKL0123456789”来校验的.由于参与者chico
是通过了发布和响应通讯来认证的,该通讯又参考了参与者groucho和通过相关的访
问控制策略(表15)SNMPv2的上下文ducksoup,故响应是可以接受的.并且可完成询
问.
4.5 公共密钥配置
这段介绍了一个关于假设的安全协议的配置的例子.这个假设协议将基于不对
称(公开密钥)的密码技术,把它作为一个提供数据原始性的认证(不保证会保护
不被暴光).这个例子说明了用公开密钥技术的管理模型的一致性,并且在例子范围
内支持保护不被暴光.
身份 ollie stan
(代理t) (管理者)
域 snmpUDPDomain snmpUDPDomain
地址 1.2.3.4, 161 1.2.3.5, 2004
Auth Prot pkAuthProtocol pkAuthProtocol
Auth Priv Key "0123456789ABCDEF" ""
Auth Pub Key "0123456789abcdef" "ghijkl0123456789"
Auth Clock 0 0
Auth Lifetime 300 300
Priv Prot noPriv noPriv
Priv Priv Key "" ""
Priv Pub Key "" ""
表 16: 公开密钥代理的参与者信息
这个例子的配置由单一的SNMPv2代理组成,它是和单一的SNMPv2管理站点相互
作用影响的.表16和17介绍了关于SNMPv2的参与者通过代理和管理者的信息,另外表
5介绍的关于对管理者和代理的本地访问策略的信息.
身份 ollie stan
(agent) (manager)
域 snmpUDPDomain snmpUDPDomain
Address 1.2.3.4, 161 1.2.3.5, 2004
Auth Prot pkAuthProtocol pkAuthProtocol
Auth Priv Key "" "GHIJKL0123456789"
Auth Pub Key "0123456789abcdef" "ghijkl0123456789"
Auth Clock 0 0
Auth Lifetime 300 300
Priv Prot noPriv noPriv
Priv Priv Key "" ""
Priv Pub Key "" ""
表 17: 公开密钥管理站点的参与者信息
在表16中,使用身份为ollie的代理的参与者在IP为1.2.3.4、UDP的端口为161
上上操作;使用身份stan的管理者的参与者在IP为1.2.3.5、UDP的端口为2004上操
作;ollie和stan认证所有由他们生成的信息,通过用假设的SNMPv2认证协议与他们
截然不同的私有认证密钥来保证其原始性和完整性.这些私有认证密钥的值
("0123456789ABCDEF" 和"GHIJKL0123456789")在这里说明仅仅是为了解释的目
的,私有密钥通常是不能告诉人们的,并且访问它们协议的执行也有部分限制.
在更多的方面,在上述的这个小的安全SNMPv2代理中,管理和代理之间的相互
影响在它们的配置中总是同样的.最主要的不同不是SNMPv2的参与者在公共密钥的
配置中有这样的信息:可以通过其他参与者来认证其通讯来了解关于私有密钥的信
息,相反的,对每个收到的认证SNMPv2信息,发起者的身份是通过应用一个不对称
加密技术算法对收到的信息和发起者的公开密钥一起来确认的.因此,在配置中,代
理知道管理的公开密钥(“ghijkl0123456789”)但不知道它的私有密钥
("GHIJKL0123456789");类似地,管理者知道代理的公开密钥
(“0123456789abcdef”)而不知道自己的私有密钥("0123456789ABCDEF").
5. 安全考虑
为了参与在管理模型中说明这个备忘录,SNMPv2的执行必须支持在参与者信息
的本地数据库方面具有本地的、稳定存储的能力.相应地,每次尝试的操作必须小到
稳定存储的数目之内.
6. 感谢
该文档是基本上基于RFC1351而来的.
7. 参考
[1] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple
Network Management Protocol", STD 15, RFC 1157, SNMP
Research, Performance Systems International, MIT
Laboratory for Computer Science, May 1990.
[2] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Protocol Operations for version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 14
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -