rfc1636.txt

RFC文档

我们得出结论，正确的短期行为是设计LLID，假定它们都公正的短期存在，在短期行运行，默许更长的有效期。这意味着我们可以得到一个适当的长期机制，首先，操作上将具备更低的安全级别。当我们有了更好的自动安装的工具，我们可以在个人基础上缩短有效期，而不需要在包的前进路径上替换机制。
* 安装反应时间
传统的互联网在终结点之间的通信路径上没有任何等待时间，支持快速处理的经典的数据模式等等都作为一项功能被保留了下来。
为使安装预先完成，双方都要通过管理接口或后台的终结点。反应时间一般在响应特殊应用请求的动态预约时发生。
我们观察到当反应时间是密钥的结果时，它不会被安全关系所影响。像RSVP和ST－II的资源附加协议的设计者现在争论协议的等待时间，缺少安全。作为证明人的补充请求消息需要增加使请求生效的加工，并且可能通过证明服务包含信息交换。但无法在安装阶段及时的完成实体交换。因为可能已经在安装阶段有了来回路程上的延迟。但对于安装协议的高级别的鉴定和授权方法必须了解这个过程，当不需要知道每一个包的处理级别的时候，有时仍然需要该过程。
处理安装过程的请求的方法是建立请求和在后台执行确认。这会在短时间内限制来自不利安装的破坏。注意，即使如此，系统对于一系列的安装请求仍然是脆弱的，在短时间内可能有未经授权的访问。
注意，使用无效的安装请求可能导致安装过程的溢出。所以过程都必须被处理或溢出。这可使有效使用者建立任何状态。即使如此，否定服务攻击建立在溢出级别的非常巨大的“指纹”：他们没有经常受到巨大的威胁。如果这是一个问题，等同于指纹的安装处理过程级别的机制上组成公司。限制在包装级别的破坏攻击。
4.5 接受端初始安装
最近工作在QOS Internet 扩展，补充了RSVP协议，使用接受者接收资源的模式。这种机制与现存的IP通讯机制相一致，需要接收人参加通讯组。接收方存储资源保证通讯运输达到接收方在预期的QOS下。在这种情况下，需要接收方的证书（HLIDs）提示进入安装阶段。
注意接收方初始化请求在显示安装阶段。假定是隐藏安装，且在现有的包内。通过特殊的接收方没有特定的关联包，在通讯中。接收方的地址不在包中出现。
进一步的说，没有可能在这种情况下执行“预先”安装。除非发送方和接收方非常紧密的协调。否则，接收方预先不知包中有LLID。的确可能的是，这种情况下，接收方为通讯传输建立半永久附加条款。不是安全发行；不存在补充的安全关系。但是安全建筑必须考虑在内。
4.6 其他问题
4.6.1加密防火墙和辅助通路
我们的安全观点，终接点和网络保护。包括防火墙的使用，需要或多或少的分配网络区域。在军事和信息组中加密防火墙模式的使用很普遍：红色（信任）网络从黑色（不信任）网络分开。非常有效的区别是，在军事模式中，分割使用加密编码通过黑色网络到红色网络是可能的。因此，加密目的单元，在其他中，提供非常高度的保护以防止在红色网络中泄漏数据。与之相反，我们的防火墙保护信任（红色）区域的范围免受攻击。当它进入和离开时。在网络信任部分的结点和不信任部分的结点不可以进行交流。
在军事加密防火墙的情况下，我们可以采用我们的安全QOS模式。即使如此，这种加密通过我们的安全资源管理仍然出现一个问题。讨论上面的内容，包括安全处理和分类两个阶段。这种结构是有问题的，因为它需要信息从红色区域到黑色区域清晰的通过。这些信息包括安装包本身，如果安装从终结点和数据包的分组区域（LLIDs）动态完成。显然，当信息从红色网络区域出来时不能加密，因为它对黑色区域是无意义的，因此黑色区域不能把资源分配决策建立在它的上面。
为了对控制方案进行分组，它需要加密设备执行特定的包裹和在包裹内区域来通过加密。加密操作的辅助通道极度不良。在安全要求很高的情况下，处理生成的辅助信息可能被破坏，所导致的结果是，可被控制的信息从安全网络中通过辅助通路区域包的隐藏删除。
我们因此得出结论，辅助通路问题是无论如何也不能克服的。关键是，对于所有情况的辅助通路来讲，限制比完全取缔要好。信息可以清晰的通过，为了限制信息需要辅助通路，在黑色环境中一个就可以作为管理程序完全执行安装，或者把处理分两步走。第一步，在黑色环境中再一次完全的定义安装情况的限制数目。第二步，包括发送来自红色网络一个非常小的信息用来选择一个请求在预先定义的设备中传送。
更麻烦的是包头的LLIDs，如果LLID 是一个明显区域（我们过去所讨论的，但是看下面），它在各个包中再提示一个新的区域，可能有32bits。因此限制路径的方法可以使用。但当终结点执行安装，它将指定LLID的使用。这种情况可在红色或黑色加密单元看见，这些单元能够限制构件区域到达正在使用的值。进一步改善的情况，加密单元可能被用于在黑色区域中一个流程到另一个流程总计出一个数量。这将进一步减少明显的LLIDs的数量，离开红色区域。
协议的细节，包括一些重要的发行例如LLIDs的持续时间，必须进一步考虑。即使如此，辅助通道的初始化结论可被引入到通常的资源控制机构，这是令人鼓舞的。因为它表明无论是军用还是民用安全构成都能在相同的建筑模块上建立。
4.6.2 相容特权的原理
比较好理解的安全原理是最新的特权原理。它表明当系统的组件需要最少的特权时它是最健壮的。
我们所观察的与之相关的规则原理是特权的一致性。这在拒绝服务时可被简单的说明。这里是特别相关的。对于单个规则，没有假定的服务能够分开，除非我们相信路由器发送包。如果一个路由器被破坏并且不能发送包，唯一的解决方法是找到另一个路由器。在协议中当一个路由器损坏时我们并不关心找到另一个路由器，因为这与我们的主题不符，网络安全构架。我们	仅仅关心是否从路由器得到服务。如果路由器损坏，并不关心是否会袭击我们。因此，路由器是转发路径的一部分（通常是多点传送转发树）。我们不能在其他方式取得信任，例如取得共享资源密钥或LLID验证。
这些说明了相容特权的原理。这些原理在通讯树中用于点对点或成对使LLIDs生效的机制。如果对一完整的树发行单一密钥，且特权不相容。我们只需相信树中路由器在它以下的结点。如果它在预期的传输中失效，它仅仅在这些结点中有效。但是如果我们给它一组密钥，然后它能够假的传输并能在树中任何结点注入，影响树中其他部分的传输。如果，另一方面，我们使用成对的密钥，然后一个被破坏的结点使用传输密钥产生一个假的它能直接收到的传输，它是树中能够被任何方式破坏的部分。
另一个我们必须放在网络设计的要求。如果一个防火墙安放后，我们必须相信没有构件绕过防火墙。一个方法是在区域内消除任何通过防火墙的物理路径。可以操作的技巧需要容许简单的物理限制。
4.6.3 隐含的LLID's
我们感觉到在包内地址和用于包分类的LLID间明显的概念区别。这种区别是非常重要的，但是在受限制的情况下是可以忽略一些包区域和当前包头所建立的LLID的。例如，当前包按IPv4分类，这是不安全的但是可以将包分为不同的服务类别，使用大量的包区域作为LLID：源及目的IP地址和协议类型的端口。
“隐含”的LLID分类必须是短期的，特别是如果主机能够在移动时改变IP地址。但是，如果LLID是通过一些动态安装协议建立的，如果需要，它可能会重新建立LLID。
当前的IPv4头没有认证者区域使LLID生效。一个认证者区域是可选择的；增加网络的稳定性。在建立认证者时任何机制描述都可以被用到，除了简单的密码认证者被使用，它必须是一个明显的分离区域，因为LLID不能随机选择。
4.6.4 不需要设置的安全
当我们描述构架时，安装步骤是基本的序列部分。这表明当前的Internet未安装的协议，不能抵抗拒绝服务的攻击。了解这些要点的限制是非常重要的。当我们强调上面时，安装出现在许多方式中。路由器现在建立在协议类型上提供管理选择区分包并且在头上找到其他区域，使用这个分类建立一个公平的队列级，这能够防止一种类相对于其他类超载。
这里有两个问题。第一个是对于一个完成的安装使用管理接口，在资源和路由器之间分享的使LLID有效的秘密必须在很长的一段时间内保持有效，且必须手工配置。第二个问题是种类的间隔尺寸必须近似。即使如此，它只是建议。在Radia Perlman的论文中，对每一个源地址都必须隐含的建立分离队列类。这种方法，作为隐含LLID使用地址，必须对健壮性有一定的构件形式。但是如果LLID可被信任，提供传输分类的机制仅仅建立在一个隐含安装操作上。对任何的QOS区别分类的间隔尺寸没有提供足够的支持。这个目标仅仅是保证从一个源到另一个源的传输。
4.6.5 生效的地址
我们在这里声明如果LLID和地址在包中只是概念上的区别，并且如果有合适的手段使LLID生效，且没有理由使地址生效。例如，一个失败的源地址的包不再提示任何安全问题，如果它的LLID可被置为有效。
一个意外可能会在与移动主机的交流中出现，但是它需要一个完全的威胁模式和在移动环境中确定的需求。即使如此，我们声明，作为讨论的起始点，如果LLIDs与地址区别开来，很多与移动安全相关的内容可能会减少并且被移除。这一点通过移动问题的细节考虑生效。
4.7结论
a） 从概念上区分LLID（低级标志符）在包内从地址携带。
b） 在每个包内都有一个单一的LLID。虽然与多重LLIDs相比可能会在路由器隐藏一些额   
外的情况，但是使用仅仅一个LLID选择是可伸缩的。
c） 连续跳跃的LLID机制可能提供一个高度的可伸缩的方法，这个方法限制秘密的分配。
即使如此，稳健性必须彻底的调查。
d） 统计抽样和背景探测机制可能会被路由器调用进行地址查询。
5.一个鉴定服务
一个鉴定服务的目的就像鉴定名字一样简单，或精确鉴定产地“信息”。与鉴定服务的区别决定了对加密名字有效。我们希望鉴定是世界范围内的服务，当鉴定相对于经过授权的访问资源来说是特殊的。
这种“识别”函数用于许多场合，例如：
* 一个时间口令：“对问题的反应是真实的<[e-mail]>”
* 访问防火墙：“对试图传送数据到主机A的a端口是真实的<[e-mail]>”
有许多Internet对象需要我们命名，例如：
主机名：sophia.inria.fr
机器名：jupiter.inria.fr
服务名：www.sophia.inria.fr（事实上的数据库）
使用者：[e-mail]
处理：[e-mail]    p112.sophia.inria.fr
通用资源定位器：http//www.sophia.inria.fr:222/tmp/foobar 
我们试图相信鉴定服务仅仅关心个人的名字，只有人是“有责任的”，一个处理过程获得访问权利因为它代表一个人。即使如此，这将导致潜在的误导。我们可能鉴定“机器”或者硬件组件。例如：
* 当机器引导为了配置自己访问资源时，但是它没有被任何一个人所“使用”：没有使用者。
* 在一个“分布式处理器”上，组件CPU可能需要彼此互相鉴定。
机器与使用者区分开来：机器不能像人那样保证它们的“秘密”。即使如此，使用一个简单的可扩充的名字空间是有巨大意义的。
5.1名字和证书
我们假设授权服务将使用“访问控制目录”（ACLs）。例如：一些关于一批授权用户的定义。一个用来描述允许使用“通配符”授权的这样一种设备的简洁的方法， 例如，“在 <Bellcore.com> 的任何人，或“<INRIA.FR> 的任何机器””。认证服务应被设计为便于授权服务的实现，并且应该支持“通配符”。
然而， 通配符一般是不够的。假设我们有一个分层的名字空间，限制命名层次的通配符的入口。例如，象 <[e-mail]> 一样的一个名字能由通配符<*@sophia.inria.frr> 匹配。只要一个通配符在 INRIA 中，这种情况成立，但是不能解决通用的问题。假定在 CNRI 的一个 IETF 文件服务器将由所有的 IAB 成员访问：它的 ACL 将明确地列出成员的名字。
命名的经典的途径，例如X.500 模型，是考虑那个人有一个“著名的名字”。一旦一个通配符通过一些这样的“白页” 服务，发现了一个名字，就能使用它作为一种全球名录的存取密钥。
个人可以从许多渠道获得授权。使用一个纯的、基于身份的存取控制系统， 用户将必须获得多重的身份 ( 即，特别的名字 )，相应地，它在其被授权存取不同的服务角色。我们在下一节讨论这个方法。
一条选择途径作为有身份的一个很小的数字的用户，并且有授权问题( 签名 )的授予者同意用户的凭证，连接到了它的 ID 。这些附加签署的凭证以“能力”被告之。然后，用户能通过一个通用的身份凭证建立它的身份， 例如，X.509 认证，并且作为请求的发送能力建立授权。在一个驱动程序的许可证上被连接到名字的信用卡的一个通配符，与此有点类似，并且发送合适的信用卡， 加上为身份的图像证实的许可证。
5.2  基于身份的授权
让我们打开一个普通人的钱包：我们从中发现若干“信用卡”。我们都有许多“信用卡”， 例如，公司卡， 信用卡， 航空公司的飞行会员卡， 驾驶许可证。这些卡事实上是的一种标志关系的联系：持有者填写的那张支票的银行证明可用于交易， 持有者了解了当局证明的车辆如何驾驶，等等。这是基于身份授权的一个例子，每个人通过不同关系相对应的不同名字进入。
如果我们想象名字空间基于 DNS ( 域 ) 名字之上，那么，涉及到以上的人与名字能被证实：
               [e-mail]
               [e-mail]
我们这里使用模型是“名字是一个协会”。这与名字证实过程是一致的， 从中一个人在用户和“资源代理人”之间建立“信任链”。由在信任图跟随一条特别的路径，一个人就能建立信任并且显示出用户属于一个“授权的组”。
一个人的“多重的名字”的存在可以暗示一个“等价”的存在关系。知道 <[e-mail]> 和 <[e-mail]> 是一样的人的 2 个名字，可以是有用的，但是有许多情况下用户不想要他的所有的标志可见。
5.3  选择凭证
让我们再考虑在 CNRI 中，克里斯琴·休泰马存取一个文件的的例子。他将必须与 Inria 的输出防火墙和 Cnri 的输入控制交流。不考虑是否授权依赖于能力或多重的协会名字，一个不同的凭证可以被路径上的每个防火墙所需要。例如，假定多重的名字被使用，他将使用一个 INRIA 名，<[e-mail]>，通过 INRIA 使用网络资源，并且他将使用一个 IAB 名字，<[e-mail]>， 来存取文件服务器。这样，显然有一个问题：他如何位特殊的防火选择特别的凭证？更确切地说，管理连接的计算机程序怎么发现这个凭证，即即将向 Inria 的防火墙挑战和另外一个到 Cnri 的请求的相应？有许多可能的答案。程序能简单地传递所有的用户凭证，并且让远程的机器选择其中一个。但是，该工作提出一些效率问题：传递所有的可能的名字是麻烦的， 浏览许多名字是累赘的。为许多名字做广告，也因为隐私和安全原因而很不受欢迎。一个人不想在远程服务器上，在一个特别的用户可以有的所有凭证上，收集统计。
另外的可能性是让请求一张授权通行证的代理人接受，愿意的凭证