翻译:中国科学技术大学信息安全专业老师 第三部分分布式系统 第10章分布式系统安全 如果存在一个单一的策略,一个单一的系统管理,一个单一的安全执行系统,则计算机 安全就容易实现。但是,正如你已经注意到的,即使在相当有利的环境下,直截了当地实现 计算机安全也是不实际的。当然,集中式的安全要比分布式的情况好得多 在这一章里,我们使用“分布式系统”(异构或者联合系统)作为通过网络连接的计算 机集合( collection,集合,聚集:收集,汇集:【ST】类集)的模型。分布式系统的各个组 成部分可能分布在不同的组织机构里,在不同的职权管理下,且使用不同的安全策略进行管 理。在一个真正的分布式系统中,用户并不想知道服务的位置,也不想知道他们正在使用的 对象所在的地点。 本章内容 了解在分布式系统中发生的基本安全问题 说明在过去几年来分布式系统安全发生的变化,未来要达到的目标。 考察在分布式系统的哪一个系统层次上实现安全机制最合适 理解当前引入的分布式系统安全机制的承诺和缺陷。 10.1概述 无论何时,你改变了计算机的运行环境,都必须对已经建立的安全机制的适用性进行重 新评估。当你把计算机从集中式系统移植到一个分布式系统的时候,对于安全来说,存在 个很明显的冲击。当检查分布式系统安全的时候,有必要理解所有的在集中式系统中内含的 安全假设,这些假设是实现集中式系统安全的基础。 为了了解这些改变会怎样影响你,让我们看一下通过口令的身份认证。当用户在一个终 端上工作,并且这个终端固定地连接到一台主机上的时候,口令是非常有用的。在这种情况 下,你可以有正当的理由相信,在终端和主机之间的连接是安全的,并且不可能窃听口令, 更改或插入消息,或者被别人接管一次会话。而在分布式系统中,对于通信链路安全这样基 本的假设几乎是不成立的。然而,口令认证仍然是分布式系统最常用的认证机制 十几年前,分布式系统安全主要关注的是认证机制。今天,你可以用防火墙来保护你的 内部网络的周边环境,用安全体系来保护对分布式对象的访问。从分布式系统的特征来看, 些更深一层的问题出现了:对用户权限的授予或者撤销、信任机制、安全性和其他的分布 式系统的特性(如可靠性和可用性)之间的相互作用。为了综述分布式系统安全的现状,我 们从研究分布式系统中的一般安全策略和安全实施开始 10.1.1安全策略 在分布式系统中,当用户访问一个对象的时候,他们不需要登录到被访问对象所在的结 点上。这就出现了一些问题 第1页共16页 创建时间:2002/223152100
翻译：中国科学技术大学信息安全专业老师 第 1 页 共 16 页 创建时间：2002/12/23 15:21:00 第三部分 分布式系统 第 10 章 分布式系统安全 如果存在一个单一的策略，一个单一的系统管理，一个单一的安全执行系统，则计算机 安全就容易实现。但是，正如你已经注意到的，即使在相当有利的环境下，直截了当地实现 计算机安全也是不实际的。当然，集中式的安全要比分布式的情况好得多。 在这一章里，我们使用“分布式系统”（异构或者联合系统）作为通过网络连接的计算 机集合（collection，集合，聚集；收集，汇集；【ST】类集）的模型。分布式系统的各个组 成部分可能分布在不同的组织机构里，在不同的职权管理下，且使用不同的安全策略进行管 理。在一个真正的分布式系统中，用户并不想知道服务的位置，也不想知道他们正在使用的 对象所在的地点。 本章内容 ·了解在分布式系统中发生的基本安全问题。 ·说明在过去几年来分布式系统安全发生的变化，未来要达到的目标。 ·考察在分布式系统的哪一个系统层次上实现安全机制最合适。 ·理解当前引入的分布式系统安全机制的承诺和缺陷。 10.1 概 述 无论何时，你改变了计算机的运行环境，都必须对已经建立的安全机制的适用性进行重 新评估。当你把计算机从集中式系统移植到一个分布式系统的时候，对于安全来说，存在一 个很明显的冲击。当检查分布式系统安全的时候，有必要理解所有的在集中式系统中内含的 安全假设，这些假设是实现集中式系统安全的基础。 为了了解这些改变会怎样影响你，让我们看一下通过口令的身份认证。当用户在一个终 端上工作，并且这个终端固定地连接到一台主机上的时候，口令是非常有用的。在这种情况 下，你可以有正当的理由相信，在终端和主机之间的连接是安全的，并且不可能窃听口令， 更改或插入消息，或者被别人接管一次会话。而在分布式系统中，对于通信链路安全这样基 本的假设几乎是不成立的。然而，口令认证仍然是分布式系统最常用的认证机制。 十几年前，分布式系统安全主要关注的是认证机制。今天，你可以用防火墙来保护你的 内部网络的周边环境，用安全体系来保护对分布式对象的访问。从分布式系统的特征来看， 一些更深一层的问题出现了：对用户权限的授予或者撤销、信任机制、安全性和其他的分布 式系统的特性（如可靠性和可用性）之间的相互作用。为了综述分布式系统安全的现状，我 们从研究分布式系统中的一般安全策略和安全实施开始。 10.1.1 安全策略 在分布式系统中，当用户访问一个对象的时候，他们不需要登录到被访问对象所在的结 点上。这就出现了一些问题：
翻译:中国科学技术大学信息安全专业老师 你怎样认证用户? 什么是访问控制判决的基础? 为了回答这两个问题,可以有三种选择。用户认证和特殊访问控制可以基于 用户身份 用户操作来源的网络地址 用户正在使用的分布式服务,即访问操作 Unⅸx在像印或者 telnet远程访问服务中采取了第一种选择。fp程序在两个Unⅸ系统 之间传输文件。 telnet程序创建一个远程的虚拟终端。这两种程序都提示用户输入用户名和 口令。 rlogin程序的工作过程类似于 telnet;它自动传送当前用户的用户名,仅仅提示用户 输入口令。在所有这三种情况下,可以使用正常的Unⅸx访问控制,但是网络通信引入了新 的脆弱性。在这一章,我们将讨论一些更加有效的认证方案 如果访问控制的决策是基于用户身份的,那么用户的身份和访问权限是怎样联系在一起 传播呢?在Unix环境下,你必须决定对于用户(比如,root)的特权可以做什么,以及来 自远程结点的程序(例如,一个SUID程序)的特权和所有权可以做什么?在多级安全的情 况下,你可能发现在分布式系统的结点之间,这些标签方案表示的意思是不相同的。因此橙 皮书( Orange book)和红皮书( Red book)给出了在结点之间数据传输的策略,这将维护 安全标签的不同粒度( granularities) 在有些糟糕的情况下,分布式系统中的访问操作可能呈现出新的含义( meaning)。想象 如下一种情况,当你发送一个读远程服务器上数据的请求时,服务器将把数据写到连接到你 的系统的输出通道上。服务器应该用哪种访问规则,哪些用来读访问或者哪些用来写访问 你可以决定来自于系统中的某些结点的用户不必再次进行认证。在Unix中,你可以在 rhosts文件中详细说明这些可信任的主机。你也可以定义可信任用户,他们不必提供口令且 允许使用rsh(远程shel)命令。这些特点提供了一个非常简单的单站式签到( single sign on) 系统,但是它严酷地依赖于消息认证的质量和初始化时允许用户进入一个可信任域的主体认 证,如同8.7.1节示例说明的那样。在 Windows ni中,这种信任关系提供了一种更完善的 方式,它使得在可信任域中的用户可以访问信任域中的任何资源(见7.54节)。 10.1.2授权 在分布式系统中,受控调用照字面上的意义( literally,,字面上(简直))呈现出新的特性 ( dimension,尺寸(量纲,维数)。一个用户可以在本地结点登录,然后在远程结点上执行一 个程序。为了获得对远程结点上资源的访问,这个程序将需要相关的访问权限。在典型情况 下( typically,代表性地,作为特色地),程序将被赋予( endow)用户的访问权限,然后以 这个权限在远程结点上运行。这个过程称为授权( delegation,授权:代理)。 在远程结点上的程序,现在以用户授予的所有访问权限运行。在一个分布式系统中,用 户对于把他所有的权限给予到一个没有什么控制权的结点上,可能会感觉到不太舒服。如果 远程结点上存在弱保护,攻击者就可能攫取用户的访问权限,并且为了一些非法的目的使用 这些权限。因此,你可能更喜欢这样的系统,在系统中用户自己可以控制那种他们授予的权 限,责任机制能够用来鉴别访问权限的授权使用 对于流行的服务来说,你可以创建代理用户( proxy user)来处理远程服务请求。你首 先检査远程用户是否被授予了( entitle,给与权利(命名),(常与to连用)授权)运行这种服 务的权限,然后让代理执行请求的动作,且用代理自己的权限而不是远程用户授予的权限运 10.1.3安全执行 第2页共16页 创建时间:2002/223152100
翻译：中国科学技术大学信息安全专业老师 第 2 页 共 16 页 创建时间：2002/12/23 15:21:00 ·你怎样认证用户？ ·什么是访问控制判决的基础？ 为了回答这两个问题，可以有三种选择。用户认证和特殊访问控制可以基于： ·用户身份； ·用户操作来源的网络地址； ·用户正在使用的分布式服务，即访问操作。 Unix 在像 ftp 或者 telnet 远程访问服务中采取了第一种选择。ftp 程序在两个 Unix 系统 之间传输文件。telnet 程序创建一个远程的虚拟终端。这两种程序都提示用户输入用户名和 口令。rlogin 程序的工作过程类似于 telnet；它自动传送当前用户的用户名，仅仅提示用户 输入口令。在所有这三种情况下，可以使用正常的 Unix 访问控制，但是网络通信引入了新 的脆弱性。在这一章，我们将讨论一些更加有效的认证方案。 如果访问控制的决策是基于用户身份的，那么用户的身份和访问权限是怎样联系在一起 传播呢？在 Unix 环境下，你必须决定对于用户（比如，root）的特权可以做什么，以及来 自远程结点的程序（例如，一个 SUID 程序）的特权和所有权可以做什么？在多级安全的情 况下，你可能发现在分布式系统的结点之间，这些标签方案表示的意思是不相同的。因此橙 皮书（Orange Book）和红皮书（Red Book）给出了在结点之间数据传输的策略，这将维护 安全标签的不同粒度（granularities）。 在有些糟糕的情况下，分布式系统中的访问操作可能呈现出新的含义(meaning)。想象 如下一种情况，当你发送一个读远程服务器上数据的请求时，服务器将把数据写到连接到你 的系统的输出通道上。服务器应该用哪种访问规则，哪些用来读访问或者哪些用来写访问？ 你可以决定来自于系统中的某些结点的用户不必再次进行认证。在 Unix 中，你可以在 rhosts 文件中详细说明这些可信任的主机。你也可以定义可信任用户，他们不必提供口令且 允许使用 rsh（远程 shell）命令。这些特点提供了一个非常简单的单站式签到（single sign on） 系统，但是它严酷地依赖于消息认证的质量和初始化时允许用户进入一个可信任域的主体认 证，如同 8.7.1 节示例说明的那样。在 Windows NT 中，这种信任关系提供了一种更完善的 方式，它使得在可信任域中的用户可以访问信任域中的任何资源（见 7.5.4 节）。 10.1.2 授权 在分布式系统中，受控调用照字面上的意义（literally，字面上(简直)）呈现出新的特性 （dimension，尺寸(量纲,维数)）。一个用户可以在本地结点登录，然后在远程结点上执行一 个程序。为了获得对远程结点上资源的访问，这个程序将需要相关的访问权限。在典型情况 下（typically，代表性地, 作为特色地），程序将被赋予（endow）用户的访问权限，然后以 这个权限在远程结点上运行。这个过程称为授权（delegation，授权；代理）。 在远程结点上的程序，现在以用户授予的所有访问权限运行。在一个分布式系统中，用 户对于把他所有的权限给予到一个没有什么控制权的结点上，可能会感觉到不太舒服。如果 远程结点上存在弱保护，攻击者就可能攫取用户的访问权限，并且为了一些非法的目的使用 这些权限。因此，你可能更喜欢这样的系统，在系统中用户自己可以控制那种他们授予的权 限，责任机制能够用来鉴别访问权限的授权使用。 对于流行的服务来说，你可以创建代理用户（proxy user）来处理远程服务请求。你首 先检查远程用户是否被授予了（entitle，给与权利(命名)，（常与 to 连用）授权）运行这种服 务的权限，然后让代理执行请求的动作，且用代理自己的权限而不是远程用户授予的权限运 行。 10.1.3 安全执行
翻译:中国科学技术大学信息安全专业老师 旦你解决( sort out)了你的策略,你就已经决定了如何执行他们。必须回答下面的显 而易见的问题: ·在哪儿认证一个用户 ·在哪儿做访问控制的决策? 这些“哪儿”可以用两种方式来解释。你可以考虑在1.4.4节提到的第五个设计决策:决 定是否执行集中安全或者局部安全。在第一种情况下,你可以采用像 Kerberos(1022节) 样的认证服务器( authentication servers)和通行票授予服务器( ticket-granting servers), 或者安装一个防火墙来控制对内部网络的访问(134节)。在第二种方式中,各个结点的操 作系统负责安全执行,比如数字设备公司ODEC)的分布式系统安全体系结构(10.22节)。另 外一个可选方案是,你可以从1.42节提出的第二种设计决策中获得启示,然后决定在最合 适的层次上实现分布式系统的安全。我们在104节中讨论这个问题。 102认证 不经过任何保护的口令在网络上传输是一个非常明显的脆弱性。发掘这种脆弱性可以容 易地自动实现。口令嗅探器 sniffers是一个网络程序,它可以侦听通信流,从中提取出包含 口令的包和其他与安全相关的信息。因此。作为走向分布式系统安全的第一步,我们应该考 察更好的认证方案。下面介绍的这两种方案是集中安全实施方案和局部安全实施方案的实 例 10.2.1 Kerberos认证 Kerberos系统是美国麻省理工学院MT在二十世纪80年代的雅典娜( Athena)项目中 开发出来的。雅典娜为MT的校园学生提供了计算资源,但是它的范围已经超出了MT的 校园范围,包括了一些附加的管理功能,比如财会功能。由 Kerberos声明的危险和威胁, 如在文献【103】中描述的,有: 这种环境对敏感数据或者高度风险(risk,危险;风险)的操作是不适合的,如银行事 务处理、机密的政府数据、学生成绩、对危险实验的控制等等。这些危险主要是不能控制非 授权的当事人使用资源,对系统或用户资源完整性的破坏,大规模地侵犯个人隐私,比如偶 然地完全浏览个人文件。 因此 Kerberos在其后被广泛地接受了。有几个工业标准采用了 Kerberos作为分布式系 统的认证系统,值得注意地是作为RFC151080发布。 Kerberos在分布式系统中认证需要 服务的客户( client)。认证是围绕通行票( ticket,票(标签,证明书);票证,入场券)和集中 式安全服务器的概念建立的。术语“主体”(“ principals”)代表客户(用户)和参与网络通 信的服务器 Kerberos认证服务器(KAS):认证登录的主体,然后发给其通行票。在一般情况 下,通行票只在一次登录会话中有效,可以让主体从通行票授予服务器获得其他的通行票 认证服务器有时也被称为“密钥分发中心”(KDC) 通行票授予服务器(TGSs):向主体发布通行票,用来访问要求认证的网络服务 Kerberos来自于 Needham- -Schroeder密钥交换协议(12.3.2节)。像DES这样的对称密 码系统常常被用来加密数据。用户名和口令用来认证用户,但是口令不能通过网络进行传输 因特网RFC1510给出了 Kerberos版本5的一个详细规范说明,包括当一个协议运行不能继 续时发出的出错信息等。下面的简单描述省略了在 Kerberos消息中的一些数据域,并且仅 仅处理了协议运行成功地完成时的情况。将使用下面列出的约定: 第3页共16页 创建时间:2002/223152100
翻译：中国科学技术大学信息安全专业老师 第 3 页 共 16 页 创建时间：2002/12/23 15:21:00 一旦你解决（sort out）了你的策略，你就已经决定了如何执行他们。必须回答下面的显 而易见的问题： ·在哪儿认证一个用户？ ·在哪儿做访问控制的决策？ 这些“哪儿”可以用两种方式来解释。你可以考虑在 1.4.4 节提到的第五个设计决策；决 定是否执行集中安全或者局部安全。在第一种情况下，你可以采用像 Kerberos（10.2.2 节） 一样的认证服务器（authentication servers）和通行票授予服务器（ticket-granting servers）， 或者安装一个防火墙来控制对内部网络的访问（13.4 节）。在第二种方式中，各个结点的操 作系统负责安全执行，比如数字设备公司(DEC)的分布式系统安全体系结构（10.2.2 节）。另 外一个可选方案是，你可以从 1.4.2 节提出的第二种设计决策中获得启示，然后决定在最合 适的层次上实现分布式系统的安全。我们在 10.4 节中讨论这个问题。 10.2 认 证 不经过任何保护的口令在网络上传输是一个非常明显的脆弱性。发掘这种脆弱性可以容 易地自动实现。口令嗅探器 sniffers 是一个网络程序，它可以侦听通信流，从中提取出包含 口令的包和其他与安全相关的信息。因此。作为走向分布式系统安全的第一步，我们应该考 察更好的认证方案。下面介绍的这两种方案是集中安全实施方案和局部安全实施方案的实 例。 10.2.1 Kerberos 认证 Kerberos 系统是美国麻省理工学院 MIT 在二十世纪 80 年代的雅典娜（Athena）项目中 开发出来的。雅典娜为 MIT 的校园学生提供了计算资源，但是它的范围已经超出了 MIT 的 校园范围，包括了一些附加的管理功能，比如财会功能。由 Kerberos 声明的危险和威胁， 如在文献【103】中描述的，有： 这种环境对敏感数据或者高度风险（risk，危险；风险）的操作是不适合的，如银行事 务处理、机密的政府数据、学生成绩、对危险实验的控制等等。这些危险主要是不能控制非 授权的当事人使用资源，对系统或用户资源完整性的破坏，大规模地侵犯个人隐私，比如偶 然地完全浏览个人文件。 因此 Kerberos 在其后被广泛地接受了。有几个工业标准采用了 Kerberos 作为分布式系 统的认证系统，值得注意地是作为 RFC 1510[80] 发布。Kerberos 在分布式系统中认证需要 服务的客户（client）。认证是围绕通行票（ticket，票(标签,证明书)；票证, 入场券）和集中 式安全服务器的概念建立的。术语“主体”（“principals”）代表客户（用户）和参与网络通 信的服务器。 ·Kerberos 认证服务器（KAS）：认证登录的主体，然后发给其通行票。在一般情况 下，通行票只在一次登录会话中有效，可以让主体从通行票授予服务器获得其他的通行票。 认证服务器有时也被称为“密钥分发中心”（KDC）。 ·通行票授予服务器（TGSs）：向主体发布通行票，用来访问要求认证的网络服务。 Kerberos 来自于 Needham-Schroeder 密钥交换协议（12.3.2 节）。像 DES 这样的对称密 码系统常常被用来加密数据。用户名和口令用来认证用户，但是口令不能通过网络进行传输。 因特网 RFC 1510 给出了 Kerberos 版本 5 的一个详细规范说明，包括当一个协议运行不能继 续时发出的出错信息等。下面的简单描述省略了在 Kerberos 消息中的一些数据域，并且仅 仅处理了协议运行成功地完成时的情况。将使用下面列出的约定：
翻译:中国科学技术大学信息安全专业老师 用户A的秘密( cryptographic,【修】密码,加密)密钥, 它是从用户A的口令通过单向算法计算得到的:KAS有一个K的备份 由TGS和KAS共享的秘密密钥 K 由服务器B和TGsS共享的秘密密钥 由KAS创建,在A和TGS之间使用的会话密钥 由TGS创建,在A和B之间使用的会话密钥 ek(x) 使用密钥K加密后的数据包X ounces(随机难题),用于阻止重放攻击的序列号 通行票的截止日期(使用期限) T,T2,T3,T:通行票或者认证者的创建时间 A对TGS使用的通行票,由KAS创建 Ticket,b A对B使用的通行票,由TGS创建 图10.1 Kerberos认证协议 图101表明了当客户( client)A要访问服务器B,在A和B之间建立相互认证时必须 发生的步骤: 消息(1)A→KAS A,IGS,L, N 消息(2)KAS→A eka(TGs,Ka/gs Tickera, /gs, L1 N1) 消息(3)A→TGs A,B, L,, N2, Ticket, g, eKargs (A, 3) 消息(4)TGS→ A eK、(B,Kab, Ticket,L2,N2) 消息(5)A→B kab(a, t), Ticket. b 消息(6)B→A kab(l4) 为了开始一次会话,用户A在本地主机上登录,他输入用户名和口令,然后向通行票 授予服务器请求服务。包含A的标识、TGS的名字、请求的通行票的截止日期和序列号 ( nonce)的消息(1),然后以明文的形式发送到KAS。KAS生成会话密钥K.ts和通行票 第4页共16页 创建时间:2002/223152100
翻译：中国科学技术大学信息安全专业老师 第 4 页 共 16 页 创建时间：2002/12/23 15:21:00 Ka ： 用户 A 的秘密（cryptographic，【修】密码，加密）密钥， 它是从用户 A 的口令通过单向算法计算得到的；KAS 有一个 Ka 的备份 Ktgs ： 由 TGS 和 KAS 共享的秘密密钥 Kb ： 由服务器 B 和 TGS 共享的秘密密钥 Ka,tgs ： 由 KAS 创建，在 A 和 TGS 之间使用的会话密钥 Ka,b ： 由 TGS 创建，在 A 和 B 之间使用的会话密钥 eK(X ) ： 使用密钥 K 加密后的数据包 X N1， N2： nounces（随机难题），用于阻止重放攻击的序列号 L1， L2： 通行票的截止日期（使用期限） T1，T2 ，T3 ，T4 ： 通行票或者认证者的创建时间 Ticketa,tgs： A 对 TGS 使用的通行票，由 KAS 创建 Ticketa,b ： A 对 B 使用的通行票，由 TGS 创建 图 10.1 Kerberos 认证协议 图 10.1 表明了当客户（client）A 要访问服务器 B，在 A 和 B 之间建立相互认证时必须 发生的步骤： 消息（1）A → KAS A ,TGS , L1 , N1 消息（2）KAS → A ( , , , , ) TGS K , Ticket , L1 N1 eKa a tgs a tgs 消息（3）A → TGS A ， B ， L2， N2 ，Ticketa,tgs， ( , ) , A T3 eKa tgs 消息（4）TGS → A ( , , , , ) , B K , Ticket , L2 N2 eKa tgs a b a b 消息（5）A → B ( , ) , A T4 eKa b ,Ticketa,b 消息（6）B → A ( ) , T4 eKa b 为了开始一次会话，用户 A 在本地主机上登录，他输入用户名和口令，然后向通行票 授予服务器请求服务。包含 A 的标识、TGS 的名字、请求的通行票的截止日期和序列号 （nonce）的消息（1），然后以明文的形式发送到 KAS。KAS 生成会话密钥 Ka,tgs 和通行票
翻译:中国科学技术大学信息安全专业老师 (Ka,/gs,A, 1,L) 使用用户A的秘密密钥Ka对会话密钥、通行票、和序列号N进行加密,而且在消息(2) 中返回给A。在A的主机端,K。可以从口令重建,并得到会话密钥Kag客户A然后创 建一个认证符( authenticator,,鉴别码)Ka,g(A,7),而且在消息(3)中把这个认证符、 通行票、要求的截止日期L2、下一步的序列号N2和服务器的名字都发送到TGS。TGS用 密钥K来解密通行票,并且与本地时钟比较验证通行票的有效性。然后,他用从通行票 中得到的密钥K。检查认证符。如果所有的验证都成功了,TGS生成会话密钥K和通行 票 Ticket=ek,(Kab, A, T2, L) 在消息(4)中,会话密钥K,和通行票 Ticket被送到A,使用A和TGS共享的会话密 钥加密。客户A存储该加密的通行票,解密新的会话密钥Kab。在消息(5)中,A要求B 有一个认证会话。这个消息包含 Ticket和一个由会话密钥kab构造的认证符。B解密通 行票,检查它的有效性,提取出会话密钥Kab。下一步,B用密钥Ka,b解密出认证符。在 成功的解密和验证时间有效的情况下,B在消息(6)中用接收到的最后时间标记给出应答, 采用会话密钥进行加密。A解密时间标记,将它同自己保存的备份T进行比较。如果相等, 则B就被认证了 撤销 如何撤销主体的访问权限呢?KAS和TGS的系统管理员必须更新他们的数据库,这样 访问权限对主体来说不再有效。这个访问权限对下一次的会话无效,即这个主体再次登录系 统,或者从TGS请求一个通行票时。而这个主体已经拥有的通行票在超时以前都有效。例 如,KAS通行票通常有大约一天的生存期。这是另外一个 TOCTTOU问题的例子 现在你不得不面临一个在方便和安全两个方面平衡的问题。如果TGS给出一个失效期 太迟的通行票,主体则不需要频繁访问TGS,同时TGS可以偶尔离线,对用户方面也没有 什么影响。然而,访问权限的撤销将有一个较长的时延影响。如果TGS提供的通行票具有 个较短的生命期,主体必须更有规律地更新他们的通行票,安全服务器的可用性对于系统 性能来说变得越来越重要了 邻域 Kerberos认证服务器是 Kerberos领域的核心。一个 Kerberos领域( realm),就是一个单 一的管理范围,控制着对一个服务器集合的访问。为了准备和运行 Kerberos,主体必须向 第5页共16页 创建时间:2002/223152100
翻译：中国科学技术大学信息安全专业老师 第 5 页 共 16 页 创建时间：2002/12/23 15:21:00 ( , , , ) , K , A T1 L1 Ticketa tgs = eKtgs a tgs 。 使用用户 A 的秘密密钥 Ka 对会话密钥、通行票、和序列号 N1 进行加密，而且在消息（2） 中返回给 A。在 A 的主机端， Ka 可以从口令重建，并得到会话密钥 Ka,tgs 。客户 A 然后创 建一个认证符（authenticator，鉴别码） ( , ) Ka,tgs A T3 ，而且在消息（3）中把这个认证符、 通行票、要求的截止日期 L2 、下一步的序列号 N2 和服务器的名字都发送到 TGS。TGS 用 密钥 Ktgs 来解密通行票，并且与本地时钟比较验证通行票的有效性。然后，他用从通行票 中得到的密钥 Ka,tgs 检查认证符。如果所有的验证都成功了，TGS 生成会话密钥 Ka,b 和通行 票 ( , , , ) , K , A T2 L2 Ticketa b = eKb a b 。 在消息（4）中，会话密钥 Ka,b 和通行票 Ticketa,b 被送到 A，使用 A 和 TGS 共享的会话密 钥加密。客户 A 存储该加密的通行票，解密新的会话密钥 Ka,b 。在消息（5）中，A 要求 B 有一个认证会话。这个消息包含 Ticketa,b 和一个由会话密钥 Ka,b 构造的认证符。B 解密通 行票，检查它的有效性，提取出会话密钥 Ka,b 。下一步，B 用密钥 Ka,b 解密出认证符。在 成功的解密和验证时间有效的情况下，B 在消息（6）中用接收到的最后时间标记给出应答， 采用会话密钥进行加密。A 解密时间标记，将它同自己保存的备份 T4 进行比较。如果相等， 则 B 就被认证了。 撤销 如何撤销主体的访问权限呢？KAS 和 TGS 的系统管理员必须更新他们的数据库，这样， 访问权限对主体来说不再有效。这个访问权限对下一次的会话无效，即这个主体再次登录系 统，或者从 TGS 请求一个通行票时。而这个主体已经拥有的通行票在超时以前都有效。例 如，KAS 通行票通常有大约一天的生存期。这是另外一个 TOCTTOU 问题的例子。 现在你不得不面临一个在方便和安全两个方面平衡的问题。如果 TGS 给出一个失效期 太迟的通行票，主体则不需要频繁访问 TGS，同时 TGS 可以偶尔离线，对用户方面也没有 什么影响。然而，访问权限的撤销将有一个较长的时延影响。如果 TGS 提供的通行票具有 一个较短的生命期，主体必须更有规律地更新他们的通行票，安全服务器的可用性对于系统 性能来说变得越来越重要了。 邻域 Kerberos 认证服务器是 Kerberos 领域的核心。一个 Kerberos 领域（realm），就是一个单 一的管理范围，控制着对一个服务器集合的访问。为了准备和运行 Kerberos，主体必须向
翻译:中国科学技术大学信息安全专业老师 KAS注册,TGS必须接收访问控制信息,所有需要的密钥必须由安全管理员存放在适当的 位置。 Kerberos具有集中式安全系统所有的优点。单个的安全策略通过有限数量的安全服务 器来实施。因此,检査系统安装时是否遵守了安全策略,以及在需要的时候作某些变更还是 相当容易的 为了在 Kerberos领域之间允许相互访问,你可以建立一个领域的层次。这导致在认证 处理过程中增加了工作强度,因为不同的会话密钥要沿着认证服务器的连接链成对的交换。 小结 为了对 Kerberos有一个全面的评估,你就必须超出分析认证协议和理解密码算法强度。 你也必须考察它的非密码的( non-cryptographic)安全特征。下列观点是一些这样调查研究 部分 消息的及时( timeliness)由时间标记( time stamp)来检查。因此,在整个系统 中要求合理的时钟同步,而且时钟自身必须被保护,以便防止攻击。安全时钟同步在本质 上也要求认证。 时间标记检查允许一些时钟有偏差。典型的采用五分钟的窗口是相当大的,且可能 比较容易遭受重放攻击 服务器必须在线,在登录时KAS需要在线;请求通行票时也需要TGS。如在上面所 说明的,TGS这种可使用性的要求可能被缓和。 会话密钥(用于对称密码( cipher)由 Kerberos服务器(认证服务器和通行票授 予服务器)生成。当这个会话密钥在主体之间的后继通信中使用时,对服务器的信任必须 包含信任:服务器将不会滥用他们的能力去窃听。 · Kerberos没有解决特权(通行票)的授予。 口令猜测和口令欺骗攻击是可能的 ·密钥和通行票保存在客户的机器上。因此,你依赖于这个结点上的保护机制去维护 Kerberos的安全性。只要 Kerberos用户工作在简单终端上,这不是什么大不了的问题。 旦用户在PC机或者在多用户工作站上运行 Kerberos,那么情况就发生了改变。 区别 Kerberos协议自身的安全性和 Kerberos实现的安全性是非常重要的。例如, Kerberos版本4的一个实现据说使用了一个弱随机数产生器作为密钥生成器。因此,采用 穷举法可以很容易地找到密钥 10.2.2 DSSA/SPX SPX是数字设备公司( Digital Equipment Corporation)开发的分布式系统安全体系结构 (DSSA)的一个部分。DSSA是一个工作站网络的安全体系结构,由认证和其他的安全设 施组成615460。每一个结点都执行它自己的安全策略,用户必须信任他们登录的每个结点 的操作系统。这样,用户授予特权给正在使用的结点的断言证明是正确的。 DSSA/SPX使得 “分布式认证安全服务”已经被纳为RFC1507 在SPX的认证中包括证书( credential),证书包含主体的名字和长期使用的私有密钥。 证书把主体的名字同他的公开密钥和认证标记( authentication token)绑定在一起。在SPX 中证书代表一个用户。证书可以被存储在一个服务器上,初始化时要求用户的口令。作为选 择,证书也可以存储在用户携带的智能卡( smart cards)上。在一个会话期间,最初的用户 注册和认证是通过不同的服务器来执行的 证书管理机构(CA):提供公开密钥证书( certificate),可以脱机处理。仅在发布有 效证书时,CA必须是可信任的 证书分发中心(CDC):存储由CA发行的证书。CDC的功能可以由命名服务提供 第6页共16页 创建时间:2002/223152100
翻译：中国科学技术大学信息安全专业老师 第 6 页 共 16 页 创建时间：2002/12/23 15:21:00 KAS 注册，TGS 必须接收访问控制信息，所有需要的密钥必须由安全管理员存放在适当的 位置。Kerberos 具有集中式安全系统所有的优点。单个的安全策略通过有限数量的安全服务 器来实施。因此，检查系统安装时是否遵守了安全策略，以及在需要的时候作某些变更还是 相当容易的。 为了在 Kerberos 领域之间允许相互访问，你可以建立一个领域的层次。这导致在认证 处理过程中增加了工作强度，因为不同的会话密钥要沿着认证服务器的连接链成对的交换。 小结 为了对 Kerberos 有一个全面的评估，你就必须超出分析认证协议和理解密码算法强度。 你也必须考察它的非密码的（non-cryptographic）安全特征。下列观点是一些这样调查研究 部分。 ·消息的及时（timeliness）由时间标记（time stamp）来检查。因此，在整个系统 中要求合理的时钟同步，而且时钟自身必须被保护，以便防止攻击。安全时钟同步在本质 上也要求认证。 ·时间标记检查允许一些时钟有偏差。典型的采用五分钟的窗口是相当大的，且可能 比较容易遭受重放攻击。 ·服务器必须在线，在登录时 KAS 需要在线；请求通行票时也需要 TGS。如在上面所 说明的，TGS 这种可使用性的要求可能被缓和。 ·会话密钥（用于对称密码（cipher））由 Kerberos 服务器（认证服务器和通行票授 予服务器）生成。当这个会话密钥在主体之间的后继通信中使用时，对服务器的信任必须 包含信任：服务器将不会滥用他们的能力去窃听。 ·Kerberos 没有解决特权（通行票）的授予。 ·口令猜测和口令欺骗攻击是可能的。 ·密钥和通行票保存在客户的机器上。因此，你依赖于这个结点上的保护机制去维护 Kerberos 的安全性。只要 Kerberos 用户工作在简单终端上，这不是什么大不了的问题。一 旦用户在 PC 机或者在多用户工作站上运行 Kerberos，那么情况就发生了改变。 ·区别 Kerberos 协议自身的安全性和 Kerberos 实现的安全性是非常重要的。例如， Kerberos 版本 4 的一个实现据说使用了一个弱随机数产生器作为密钥生成器。因此，采用 穷举法可以很容易地找到密钥。 10.2.2 DSSA/SPX SPX 是数字设备公司（Digital Equipment Corporation）开发的分布式系统安全体系结构 （DSSA）的一个部分。DSSA 是一个工作站网络的安全体系结构，由认证和其他的安全设 施组成[116,151,160]。每一个结点都执行它自己的安全策略，用户必须信任他们登录的每个结点 的操作系统。这样，用户授予特权给正在使用的结点的断言证明是正确的。DSSA/SPX 使得 “分布式认证安全服务”已经被采纳为 RFC 1507。 在 SPX 的认证中包括证书（credential），证书包含主体的名字和长期使用的私有密钥。 证书把主体的名字同他的公开密钥和认证标记（authentication token）绑定在一起。在 SPX 中证书代表一个用户。证书可以被存储在一个服务器上，初始化时要求用户的口令。作为选 择，证书也可以存储在用户携带的智能卡（smart cards）上。在一个会话期间，最初的用户 注册和认证是通过不同的服务器来执行的。 ·证书管理机构（CA）：提供公开密钥证书（certificate），可以脱机处理。仅在发布有 效证书时，CA 必须是可信任的。 ·证书分发中心（CDC）：存储由 CA 发行的证书。CDC 的功能可以由命名服务提供
翻译:中国科学技术大学信息安全专业老师 CDC在认证期间必须是联机的 CDC不能损害认证协议的安全。如果它分发了无效的证书,协议运行将报错后终止。在 这种考虑上,CDC不一定是可信任的,但是对于认证服务的可用性来说,它却是至关重要的。 在实际实现时,CDC可以是分布式的 证书的撤销可以通过维护一张证书撤销表实现,或者直接从CDC数据库中删除证书。在 这种情况下,必须相信CDC正确地删除了证书。如果没有要求CDC进行在线认证,证书在截 止日期前都是有效的。访问权限可以在单个结点上取消。 关于SPX的描述,我们将采用下面的约定 主体P的私有签名密钥 Pn,Sa:A的长期公开密钥和长期私有密钥 A的短期公开密钥和短期私有密钥,当A登录时生成 4,6 在对称加密算法中,用作A、B之间的会话密钥,由A生成; eK(x) 采用密钥K对数据包X进行加密; (Y):用密钥K生成的数据包X的数字签名;为了描述简单起见,我们假 设,无论何时传送一个数字签名时,已经被签名的数据也包含在消息中;因此sK(X)将表 示数据包X和对X的签名两种数据 时间戳 证书或者通行票的终止日期 在该表示中,公开密钥被用于加密和对签名的验证,而私有密钥用于解密和签名。这只 是为了简化描述,并不建议在实际中也这样实现。使用短期的公开密钥/私有密钥对可以避 免长期密钥对的过分暴露。授权可以采用生成新的证书来实现。证书将用户身份绑定在一个 短期私有密钥上。这个密钥对用户调用的服务必须是有效的。 图10.2 DSSA/SPX认证协议 在主体A、B之间的相互认证处理如图102所示。主体B的证书,由A所信任的证书 管理机构CAa发布。证书采用这种形式 Certificate(B, CA)=SSc(Caa, B, L, P) 交换的消息如下所示151 消息(1)A→CDC: B 消息(2)CDC→A: Certificate(B.CA) 消息(3)A→B: A,eka,b(,A),sSa(L,, A, Pa),ePi(ka,b),eka. S 消息(4)B→CDC: 第7页共16页 创建时间:2002/223152100
翻译：中国科学技术大学信息安全专业老师 第 7 页 共 16 页 创建时间：2002/12/23 15:21:00 CDC 在认证期间必须是联机的。 CDC 不能损害认证协议的安全。如果它分发了无效的证书，协议运行将报错后终止。在 这种考虑上，CDC 不一定是可信任的，但是对于认证服务的可用性来说，它却是至关重要的。 在实际实现时，CDC 可以是分布式的。 证书的撤销可以通过维护一张证书撤销表实现，或者直接从 CDC 数据库中删除证书。在 这种情况下，必须相信 CDC 正确地删除了证书。如果没有要求 CDC 进行在线认证，证书在截 止日期前都是有效的。访问权限可以在单个结点上取消。 关于 SPX 的描述，我们将采用下面的约定： · p S ： 主体 P 的私有签名密钥； · Pa ， a S ： A 的长期公开密钥和长期私有密钥； · ' Pa , ' a S ： A 的短期公开密钥和短期私有密钥，当 A 登录时生成； · Ka,b ： 在对称加密算法中，用作 A、B 之间的会话密钥，由 A 生成； · eK(X ) ： 采用密钥 K 对数据包 X 进行加密； · sK(X ) ： 用密钥 K 生成的数据包 X 的数字签名；为了描述简单起见，我们假 设，无论何时传送一个数字签名时，已经被签名的数据也包含在消息中；因此 sK(X ) 将表 示数据包 X 和对 X 的签名两种数据。 ·T ： 时间戳； · Lc ， Lt ： 证书或者通行票的终止日期。 在该表示中，公开密钥被用于加密和对签名的验证，而私有密钥用于解密和签名。这只 是为了简化描述，并不建议在实际中也这样实现。使用短期的公开密钥/私有密钥对可以避 免长期密钥对的过分暴露。授权可以采用生成新的证书来实现。证书将用户身份绑定在一个 短期私有密钥上。这个密钥对用户调用的服务必须是有效的。 图 10.2 DSSA/SPX 认证协议 在主体 A、B 之间的相互认证处理如图 10.2 所示。主体 B 的证书，由 A 所信任的证书 管理机构 CAa 发布。证书采用这种形式： ( , ) ( , , , ) a CA CAa B Lc Pb Certificate B CA sS a = 。 交换的消息如下所示[151]： 消息（1）A → CDC： B 消息（2）CDC → A： ( , ) B CAa Certificate 消息（3）A →B： A ， ( , ) eKa,b T A , ( , , ) ' a Lt A Pa sS , ( ) b Ka,b eP , ( ) ' a,b Sa eK 消息（4）B→CDC： A
翻译:中国科学技术大学信息安全专业老师 消息(5)CDC→B: Certificate(A, CA, 消息(6)B→A: 在第一个消息中,申请者A向CDC请求验证者B的长期公开密钥。在消息(2)中, CDC用一个绑定了B的身份和它的公开密钥的P证书来响应这个消息。这个密钥由A用 CAa中的公开验证密钥来验证。现在A生成了一个会话密钥Ka.。这个密钥被用来生成一 个认证符( authenticator)eka.b(T,A)、一个A的短期公开密钥P的签名通行票,即 sSa(L,A,P),和授杈书( delegator)eP(Ka)、eKab(Sa)。如果不想要授权,可用授 权书S(ePB(k)作替代,于是密钥S对于B来说是不可见的。这些数据域在步骤(3) 的消息中被送到验证者。 在第4,5步中,验证者从CDC取回对于申请者长期公开密钥的证书。在有证书的情况 下,B就可以认证申请者A的长期公开密钥P,B用它自己的长期私有密钥S解密数据, 从授权书( delegator)中重新获得会话密钥Ka,b。然后B使用会话密钥解密认证符,把它 的时间标记同本地时钟相比较。下一步,B使用有书面证明的验证密钥P,检查含有P的 通行票sS2(L2,A,P)的签名 最后的检查依赖于授权书( delegator)的格式。使用eP(Ka)和eK。(S),验证者 ( verifier)重新获得Sa,且确认S。和P是正确的密钥对。如果授权书sS。(eP(k。)已 经被发送,验证者利用P检查关于eP(Kab)的签名。如果所有的检查都成功了,B完成在 第6步中的相互认证,通过发送一个认证符eKab(⑦)作为响应。A使用会话密钥解密认证符 通过保存在本地的副本T来验证T。 10.2.3个人加密设备 在 Kerberos系统中,用户仅仅必须记住他们自己的口令,应用服务器也只需要同通行 票授予服务器共享一个密钥,其他所有与安全相关的信息都保存在几个中央服务器上。在 DSSA系统中,用户(必须能够获得)保存一个私有密钥,几乎所有其他与安全相关的信息 都由本地服务器管理。中央服务器仅仅是证书的储存库。 我们能够更进一步采用分散的方式,且在用户方存储更多的与安全相关的信息。用户可 以携带个人加密设备(PCPs),即随身带的像智能卡或者 PCMCIA卡那样的设备,使用这个 设备从任何结点来访问分布式系统。PCP应该包含与用户关联的加密密钥、进一步的访问控 制参数,和加密算法的实现等信息。 第8页共16页 创建时间:2002/223152100
翻译：中国科学技术大学信息安全专业老师 第 8 页 共 16 页 创建时间：2002/12/23 15:21:00 消息（5）CDC→B： ( , ) A CAb Certificate 消息（6）B→A： ( ) eKa,b T 在第一个消息中，申请者 A 向 CDC 请求验证者 B 的长期公开密钥。在消息（2）中， CDC 用一个绑定了 B 的身份和它的公开密钥的 Pb 证书来响应这个消息。这个密钥由 A 用 CAa 中的公开验证密钥来验证。现在 A 生成了一个会话密钥 Ka,b 。这个密钥被用来生成一 个认证符（authenticator） ( , ) eKa,b T A 、一个 A 的短期公开密钥 ' Pa 的签名通行票，即 ( , , ) ' a Lt A Pa sS ，和授权书（delegator） ( ) b Ka,b eP 、 ( ) ' a,b Sa eK 。如果不想要授权，可用授 权书 ( ( )) , ' a b a b sS eP k 作替代，于是密钥 ' a S 对于 B 来说是不可见的。这些数据域在步骤（3） 的消息中被送到验证者。 在第 4，5 步中，验证者从 CDC 取回对于申请者长期公开密钥的证书。在有证书的情况 下，B 就可以认证申请者 A 的长期公开密钥 Pa ，B 用它自己的长期私有密钥 b S 解密数据， 从授权书（delegator）中重新获得会话密钥 Ka,b 。然后 B 使用会话密钥解密认证符，把它 的时间标记同本地时钟相比较。下一步，B 使用有书面证明的验证密钥 Pa ，检查含有 ' Pa 的 通行票 ( , , ) ' a Lt A Pa sS 的签名。 最后的检查依赖于授权书（delegator）的格式。使用 ( ) b Ka,b eP 和 ( ) ' a,b Sa eK ，验证者 （verifier）重新获得 ' a S ，且确认 ' a S 和 ' Pa 是正确的密钥对。如果授权书 ( ( )) , ' a b a b sS eP k 已 经被发送，验证者利用 ' Pa 检查关于 ( ) b Ka,b eP 的签名。如果所有的检查都成功了，B 完成在 第 6 步中的相互认证，通过发送一个认证符 ( ) eKa,b T 作为响应。A 使用会话密钥解密认证符， 通过保存在本地的副本 T 来验证 T 。 10.2.3 个人加密设备 在 Kerberos 系统中，用户仅仅必须记住他们自己的口令，应用服务器也只需要同通行 票授予服务器共享一个密钥，其他所有与安全相关的信息都保存在几个中央服务器上。在 DSSA 系统中，用户（必须能够获得）保存一个私有密钥，几乎所有其他与安全相关的信息 都由本地服务器管理。中央服务器仅仅是证书的储存库。 我们能够更进一步采用分散的方式，且在用户方存储更多的与安全相关的信息。用户可 以携带个人加密设备（PCPs），即随身带的像智能卡或者 PCMCIA 卡那样的设备，使用这个 设备从任何结点来访问分布式系统。PCP 应该包含与用户关联的加密密钥、进一步的访问控 制参数，和加密算法的实现等信息
翻译:中国科学技术大学信息安全专业老师 Fortezza卡,是为美国国防应用开发的 PCMCIA卡,说明了这种方法。当颁发给用户 张卡时,在卡成为用户模式前,场地安全管理员装入用户的私有密钥。该卡将通过个人身份 识别号码PIN机制被激活。通过用户在他们自己的 PCMCIA卡上执行与安全相关的操作 Fortezza使得各个用户以安全的方式从任何一个结点访问分布式系统 10.3安全AP|s 为了向更深一步提高分布式系统安全的综合体系结构,下面的三个问题必须被提出来 1.分布式系统中的安全要求常常超过了纯粹的认证。 2.在分布式系统中不同的组件不必使用相同的安全机制(在本章中,你已经了解了作 为用户认证的两种不同的体系结构)。因此,安全必须在各种各样的安全机制上实施 3.用户和应用程序员不必是安全专家。你必须找到一个可行的方法给那些不知道安全 的用户提供安全服务。 软件工程提出了能处理所有这些问题的一个非常确实的( well-established,)策略。系统 被分解成多层。应用程序接口(APls)允许应用程序在某一层调用底层的服务。通过隐藏实 现的细节,API可以减轻应用程序员的与安全相关的任务,比如实现或者甚至选择加密算法。 所需的安全专家的水平(安全意识, securIty awareness),是比较安全APls的一个很好的尺 度标准( yardstick) 10.3. 1 GSS-API 通用安全服务应用程序接口(GSS-API)最初被设计用来提高在基于 Kerberos或基于分 布式认证安全服务(DASS)的分布式安全体系结构之间的可移植性。GSS-AP提供了面向 连接应用的安全服务的简单接口。这些服务都可以在一定的底层机制和协议范围内实现,所 以对不同的环境可以提高应用程序源级的可移植性。指导GSS-API设计的主要目标是 机制独立:GSS-API在通用级上定义了对强安全认证和其他安全服务的接口,它独 立于特定的底层机制。安全服务可以通过对称密钥加密(例如, Kerberos)或者公开密钥加 密(例如,X509)实现 协议环境独立: GSS-API独立于使用的通信协议,允许在宽的协议范围内使用。 对实现位置范围的适用性:在GSS-AP实现的系统中,GSS-AP客户不被限制驻留 在系统定义的任何可信计算基( trusted computing base,TcB)的周边( perimeter)内 对GSS-AP来说有两个逻辑部分:与安全服务集合的通用接口,即完全的AP,和提 供安全服务机制的集合。 GSs-AP的特征和概念 个典型的GSS-API调用者本身就是一个通信协议,调用 GSS-AP服务就是为了用认 证、完整性和/或者机密性安全服务保护它的通信。接口驻留在本地系统中,通过一个库提 供对GSS-API调用的入口。接口实现数据转换和对每一个已知的机制调用其接口的任务 ( roles),而对应用程序隐藏了机制的细节。GSS-API的基本安全元素是证书、标记( token)、 安全上下文( context)和状态码。在对等层间初始化安全上下文的操作实现对等实体的认证, 与提供每一个消息数据源的认证和数据完整性保护相分离 过去习惯于提供安全服务的机制在每一次会话开始时选择,且在整个会话期间都保持不 变。对GSS-AP可利用的机制影响了这种机制的选择。在 GSS-API那里多种机制是可利用 的,调用者可以说明一个优先选择的列表。否则,系统选择一种缺省机制 证书 第9页共16页 创建时间:2002/223152100
翻译：中国科学技术大学信息安全专业老师 第 9 页 共 16 页 创建时间：2002/12/23 15:21:00 Fortezza 卡，是为美国国防应用开发的 PCMCIA 卡，说明了这种方法。当颁发给用户一 张卡时，在卡成为用户模式前，场地安全管理员装入用户的私有密钥。该卡将通过个人身份 识别号码 PIN 机制被激活。通过用户在他们自己的 PCMCIA 卡上执行与安全相关的操作， Fortezza 使得各个用户以安全的方式从任何一个结点访问分布式系统。 10.3 安全 APIs 为了向更深一步提高分布式系统安全的综合体系结构，下面的三个问题必须被提出来。 1．分布式系统中的安全要求常常超过了纯粹的认证。 2．在分布式系统中不同的组件不必使用相同的安全机制（在本章中，你已经了解了作 为用户认证的两种不同的体系结构）。因此，安全必须在各种各样的安全机制上实施。 3．用户和应用程序员不必是安全专家。你必须找到一个可行的方法给那些不知道安全 的用户提供安全服务。 软件工程提出了能处理所有这些问题的一个非常确实的（well-established，）策略。系统 被分解成多层。应用程序接口（APIs）允许应用程序在某一层调用底层的服务。通过隐藏实 现的细节，API 可以减轻应用程序员的与安全相关的任务，比如实现或者甚至选择加密算法。 所需的安全专家的水平（安全意识，security awareness），是比较安全 APIs 的一个很好的尺 度标准(yardstick)。 10.3.1 GSS-API 通用安全服务应用程序接口（GSS-API）最初被设计用来提高在基于 Kerberos 或基于分 布式认证安全服务（DASS）的分布式安全体系结构之间的可移植性。GSS-API 提供了面向 连接应用的安全服务的简单接口。这些服务都可以在一定的底层机制和协议范围内实现，所 以对不同的环境可以提高应用程序源级的可移植性。指导 GSS-API 设计的主要目标是： ·机制独立： GSS-API 在通用级上定义了对强安全认证和其他安全服务的接口，它独 立于特定的底层机制。安全服务可以通过对称密钥加密（例如，Kerberos）或者公开密钥加 密（例如，X.509）实现。 ·协议环境独立： GSS-API 独立于使用的通信协议，允许在宽的协议范围内使用。 ·对实现位置范围的适用性： 在 GSS-API 实现的系统中，GSS-API 客户不被限制驻留 在系统定义的任何可信计算基（trusted computing base，TCB）的周边（perimeter）内。 对 GSS-API 来说有两个逻辑部分：与安全服务集合的通用接口，即完全的 API，和提 供安全服务机制的集合。 GSS-API 的特征和概念 一个典型的 GSS-API 调用者本身就是一个通信协议，调用 GSS-API 服务就是为了用认 证、完整性和/或者机密性安全服务保护它的通信。接口驻留在本地系统中，通过一个库提 供对 GSS-API 调用的入口。接口实现数据转换和对每一个已知的机制调用其接口的任务 （roles），而对应用程序隐藏了机制的细节。GSS-API 的基本安全元素是证书、标记（token）、 安全上下文（context）和状态码。在对等层间初始化安全上下文的操作实现对等实体的认证， 与提供每一个消息数据源的认证和数据完整性保护相分离。 过去习惯于提供安全服务的机制在每一次会话开始时选择，且在整个会话期间都保持不 变。对 GSS-API 可利用的机制影响了这种机制的选择。在 GSS-API 那里多种机制是可利用 的，调用者可以说明一个优先选择的列表。否则，系统选择一种缺省机制。 证书
翻译:中国科学技术大学信息安全专业老师 证书( credential)包括与安全相关的数据,这些数据都是在对等实体相互之间建立安全 上下文要求的信息。没有标准的证书结构。由底层定义证书的内容,但是相同的结构可以由 不同的机制使用。证书必须由底层系统正确操作,这样才能维护应用的安全。证书不作为 GSS-API的调用参数传递,而是通过证书句柄的引用 标记 由调用者供给GSS-API接口调用的数据,转换成特定于机制格式的标记( Token) SsS-API调用者接收这些由它的本地GSS-API实现程序提供给它的标记,再将这些标记传 送给远程系统的一个同等层(peer)。这个同等层然后传送接收到的标记给它本地的GSS-API 实现处理。这些标记对于调用者来说通常是没有含义的,它们的具体格式高度依赖于所使用 的特殊机制。 安全上下文 安全上下文( contexts)记录与安全服务管理有关的信息。使用证书在对等层(per)之 间建立安全上下文。在一对对等层之间多重上下文可能同时存在,使用相同的或者不同的证 书集合。当证书过期的时候,使用不同证书的多种上下文共存允许适度的翻转。 状态码 设置状态标志,以指出哪种特征是期望的,例如,指出相互认证是要求的状态标志 MUTUAL REQ FLAG。状态码也支持安全上下文的设置,例如,指示一个安全上下文的初 始化尚未完成的 GSS CONTINUE NEEDED状态标志。大多数状态码是独立于机制的,而 少数状态码可能特定于底层的安全机制。这些状态信息给GSS-AP调用者一个机会,使得 调用者根据与安全有关的调用执行有限制的因果关系检查。确信调用在正确的安全上下文中 发出是调用者的责任。为了阐述调用者在管理任务中包含的范围,下面的表给出了在RFC 2078中规定的重要的状态返回值 GSS S BAD BINDINGS 信道绑定失配 GSS S BAD MECH 不支持请求的机制 GSS S BAD NAME 提供了无效的名字 GSS S BAD NAMETYPE 提供了不支持类型的名字 GSS S BAD STATUS 无效的输入状态选择符( selector) GSS S BAD SIG 标记完整性检查无效 GSS S CONTEXT EXPIRED 规定的安全上下文过期 GSS S CREDENTIALS EXPIRED检测出过期的证书 GSS S DEFECTⅤ E CREDEN∏AL检测到损坏的证书 GSS S DEFECTIVE TOKEN 检查到损坏的标记 GSS S FAILURE 在 GSS API层失败,或是未指定的 GSS S NO CONTEXT 规定了无效的安全上下文 GSS S NO CRED 提供了无效的证书 SS S BAD QOP 不支持的QOP值 GSS S UNAUTHORIZED 未授权的操作 GSS S UNAVAILABLE 无效的操作 GSS S DUPLICATE ELEMENT复写了要求的证书元素 GSS S NAME NOT MN 名字包含了多种机制元素 GSS S COMPLETE 正常完成 第10页共16页 创建时间:2002/122315:21:00
翻译：中国科学技术大学信息安全专业老师 第 10 页 共 16 页 创建时间：2002/12/23 15:21:00 证书（credential）包括与安全相关的数据，这些数据都是在对等实体相互之间建立安全 上下文要求的信息。没有标准的证书结构。由底层定义证书的内容，但是相同的结构可以由 不同的机制使用。证书必须由底层系统正确操作，这样才能维护应用的安全。证书不作为 GSS-API 的调用参数传递，而是通过证书句柄的引用。 标记 由调用者供给 GSS-API 接口调用的数据，转换成特定于机制格式的标记（Token）。 GSS-API 调用者接收这些由它的本地 GSS-API 实现程序提供给它的标记，再将这些标记传 送给远程系统的一个同等层（peer）。这个同等层然后传送接收到的标记给它本地的 GSS-API 实现处理。这些标记对于调用者来说通常是没有含义的，它们的具体格式高度依赖于所使用 的特殊机制。 安全上下文 安全上下文（contexts）记录与安全服务管理有关的信息。使用证书在对等层（peer）之 间建立安全上下文。在一对对等层之间多重上下文可能同时存在，使用相同的或者不同的证 书集合。当证书过期的时候，使用不同证书的多种上下文共存允许适度的翻转。 状态码 设置状态标志，以指出哪种特征是期望的，例如，指出相互认证是要求的状态标志 MUTUAL_REQ_FLAG。状态码也支持安全上下文的设置，例如，指示一个安全上下文的初 始化尚未完成的 GSS_CONTINUE_NEEDED 状态标志。大多数状态码是独立于机制的，而 少数状态码可能特定于底层的安全机制。这些状态信息给 GSS-API 调用者一个机会，使得 调用者根据与安全有关的调用执行有限制的因果关系检查。确信调用在正确的安全上下文中 发出是调用者的责任。为了阐述调用者在管理任务中包含的范围，下面的表给出了在 RFC 2078 中规定的重要的状态返回值。 GSS_S_BAD_BINDINGS 信道绑定失配 GSS_S_BAD_MECH 不支持请求的机制 GSS_S_BAD_NAME 提供了无效的名字 GSS_S_BAD_NAMETYPE 提供了不支持类型的名字 GSS_S_BAD_STATUS 无效的输入状态选择符（selector） GSS_S_BAD_SIG 标记完整性检查无效 GSS_S_CONTEXT_EXPIRED 规定的安全上下文过期 GSS_S_CREDENTIALS_EXPIRED 检测出过期的证书 GSS_S_DEFECTIVE_CREDENTIAL 检测到损坏的证书 GSS_S_DEFECTIVE_TOKEN 检查到损坏的标记 GSS_S_FAILURE 在 GSS_API 层失败，或是未指定的 GSS_S_NO_CONTEXT 规定了无效的安全上下文 GSS_S_NO_CRED 提供了无效的证书 GSS_S_BAD_QOP 不支持的 QOP 值 GSS_S_UNAUTHORIZED 未授权的操作 GSS_S_UNAVAILABLE 无效的操作 GSS_S_DUPLICATE_ELEMENT 复写了要求的证书元素 GSS_S_NAME_NOT_MN 名字包含了多种机制元素 GSS_S_COMPLETE 正常完成