摘要

  • RFC 1507 将远程认证拆成两个主体：提出请求的用户，以及替用户承载请求的主机。两者可以分别出示凭据。
  • DASS 让证书链沿着 X.500 命名层级组织，使接收方能够追溯公钥由谁认证；树状层级限制了一部分 CA 失陷的范围，却也使目录成为证书查询和撤销的关键依赖。
  • 该 RFC 的状态是 Experimental。它记录的是一套架构设想，没有提供部署规模或实际运行效果的证据。

一台机器代表不了一个人

RFC 1507 的问题不是“如何给用户起一个更好听的名字”，而是不同机器上的本地账户如何指向同一个人。若某人有十个系统账户，远端资源就可能需要逐个记录这些账户；新增机器或账号，又要更新授权关系。DASS 想让网络先识别一个全局主体，再由资源决定是否允许该主体使用本地账户。

这个顺序避免把身份和落地权限混为一谈。一个用户可以从不同节点登录，但某个资源仍可限定“此用户只能经由某台机器访问”。本地操作系统也不会立刻消失。RFC 仍预期主机将远端身份映射到本地账号，并以 .rhosts 一类规则作为过渡。DASS改变的是远端请求携带的身份凭据，并没有替每台服务器作出具体的访问决定。

两个主体，一份请求

DASS 将用户和计算机都视为 principal。典型凭据中可以有两组秘密：一组属于用户，一组属于节点。发起认证时，两者可以分别对请求签名。接收端于是能确认请求声称的用户，也能确认是哪台机器在替他发起请求。

这对跨主机服务尤其重要。单看用户身份，可能漏掉发起节点的风险；只看主机身份，则无法分辨当前登录者。两个身份同时出现，资源可以把它们组合成一条更窄的规则，而不是把机器上的所有用户都视为同一主体。

用户登录时，系统会为其进程建立凭据，并把凭据关联到由用户启动或代表用户运行的进程。如果远端服务需要再调用另一项服务，DASS可以把凭据委托给该服务。系统应在用户退出时丢弃相应秘密。凭据因此不只是握手中的证明，也成为进程执行远程操作时可继续使用的能力。

不过，这种委托在 RFC 1507 中主要由时间限制。服务能够在一段时间内代表用户行动，却无法只获得完成某一项任务所需的最小权限。文档把更精细的委托作为未来可能。它也承认，智能卡尚未普及前，用户首次通过密码登录节点时仍可能暴露于窃听；密码不再继续穿过后续网络，并不等于第一个环节已消除风险。

名字树也画出了信任边界

签名只能说明某把私钥参与了请求，接收方还需要知道公钥属于谁。DASS用证书把 principal 名称与公钥绑定，再由认证机构（CA）签名。若每台服务器都要预先安装所有用户的公钥，系统无法扩展。因此它把 CA 的职责连接到 X.500 命名树：一个目录对应一组由本地 CA 负责的主体，父子证书和交叉证书可以把不同分支连起来。

这套层级并不意味着所有人都信任一个万能根。RFC 描述了本地 CA、跨层级证书，以及若干独立命名“岛屿”通过交叉认证相连的可能。它试图缩小失陷的波及面：某个下层 CA 被攻破，主要会影响对应目录及其相关信任路径；更高层 CA 的影响范围则更广。

这种限制是结构性的，不是绝对保证。处在某一分支的 CA 仍可为其范围内的名字签发错误证书。目录管理员还必须验证新主体的身份、保护 CA 私钥并把证书发布到可查询的位置。验证器可以检查签名链，却不能只凭数学验证判断最初的身份登记是否可靠。

目录同时决定证书是否还应被相信

RFC 1507 把证书撤销列为核心难题。第一种办法是等证书到期并在正常周期内续签。文档预计普通证书约一年到期，并指出续签周期可能按月计算，以免 CA 和用户承担过重的管理负担。代价是：如果密钥已经泄露，旧证书可能仍被接受相当一段时间。

第二种办法是只在命名服务中保留仍有效的证书，验证者只接受目录中能找到的那一份。它可以更快地反映撤销，但“更快”依赖目录传播与缓存状态。RFC 也明说，这样一来，认证服务的可用性会受命名服务可用性限制，而撤销的安全性会受命名服务安全性限制。DASS 当时尚不支持 X.509 撤销列表。

时间机制又增加一层依赖。DASS用时间戳抵御重放：验证者检查请求是否落在允许窗口内，并记住近期已接收的认证消息。证书有效期核验可容忍数小时的误差；重放检测则需要分钟级的网络时间协调和严格递增的时钟。时钟漂移可能拒绝合法请求，时钟回拨则可能让过期消息重新有效。验证器还须保存窗口内的消息状态。

因此，远程认证并非只发生在用户与服务器之间。请求依赖用户和节点凭据，证书依赖 CA 链，撤销依赖目录更新，重放保护依赖时钟和验证器记忆。任何一个环节都可能改变“这个签名有效”在执行层面的含义。

规范状态不能代替部署证据

RFC 1507 明确把 DASS 标为 Experimental，并说明它不是 Internet Standard。它的附录讨论如何支持 Generic Security Service API；RFC 1508 则单独定义了可由不同底层机制实现的通用接口，RFC 1509规定相应的 C 语言绑定。相关文档表明，DASS被设计成可供应用调用的安全机制，但它们没有说明实际有多少应用采用了它。

同期还存在其他思路。RFC 1510 描述了 Kerberos V5，其信任结构依靠密钥分发中心；RFC 1704随后梳理了互联网认证方式。仅凭这些文档，不能给不同方案排出实际部署的先后，也不能断言 DASS为何没有成为主流。

DASS的历史意义在于它把身份验证拆成可辨认的对象：用户、节点、命名主体、证书、委托进程和本地账号各有其位置。它尝试让身份跨机器移动，同时不把资源授权交给一个单独的全局裁决者。要判断一次远程访问究竟意味着什么，必须沿着这条链逐项核对，而不能把全局名字当成已经获准的动作。

来源