Kerberos SPKM/LIPKEY安全机制的区别

Generic Security Service Application Program Interface 简称为 GSS-API，如在 [IETF RFC-2743] 中所定义：“以一般的形式向调用者提供安全服务，可由广泛的底层机制和技术所支持，从而允许应用程序到不同环境的源代码级可移植性。”（参见 参考资料 中的（RFC）2743）。 这是一套编程接口，抽象了身份验证、消息源验证和完整性。因此，用 GSS-API 开发的安全应用程序可以在不同的安全机制上运行，不用改变应用程序。

到 目前为止，大部分 GSS-API 产品所支持的惟一的安全机制就是名为 Kerberos [IETF RFC-1964] 的流行的基于对称密钥的机制。但是，随着 NFS V4[IETF RFC-3530] 的开发势头日益加强，程序员们不久将会看到出现这样的供应商：他们的 GSS-API 产品支持诸如 SPKM 和 LIPKEY 这样的附加安全机制。这种支持增长的主要原因是，NFS V4 [IETF RFC-3530] 强制规定其安全模块使用 SPKM 和 LIPKEY 安全机制。因此，上述要求会迫使供应商扩展 GSS-API 框架，以支持 Kerberos 之外还支持 SPKM 和 LIPKEY，而 Kerberos 将继续作为默认的 GSS-API 机制。Kerberos 和 SPKM-3/LIPKEY 的主要区别是：前者只是基于对称密钥的安全机制，而后者则是基于对称密钥的安全机制与公钥技术的混合体。下文对 SPKM 和 LIPKEY 机制的概述，有助于了解其为应用程序带来的好处。

SPKM 是一种 GSS-API 机制，其基于公钥而非对称密钥基础设施。SPKM 使用公钥基础设施在一个联机分布式应用程序环境下提供身份验证、密钥设立、数据完整性和数据机密性。它不需使用安全时间戳即可完成单向和双向身份验证。 SPKM 使用算法标识符（Algorithm Identifier）来指定各个通信方所使用的不同算法。它允许基于真正的不对称算法在与签署和加密消息有关的 GSS-API 函数中——比如 gss_sign() 和 gss_seal() 操作（目前在 [GSSv2] 中称之为 gss_getMIC() 和 gss_wrap()）—— 选择数字签名，而不是基于使用对称算法（如 DES）得出的 MAC 来选择完整性校验和。SPKM 的数据格式和过程被设计成在实用性方面与 Kerberos 机制的类似。这样做的目的是为了使 SPKM 容易在已实现了 Kerberos 的环境中实现。因此，当应用程序需要一种基于公共密钥基础设施的 GSS-API 机制时，SPKM 就能满足它的要求。关于 SPKM 的更多信息，请参阅 IETF RFC 2025（参阅 参考资料）。

诸 如 Kerberos V5[IETF RFC-1964] 和 SPKM [IETF RFC-2025] 之类的 GSS-API 机制需要大量的基础设施。正如在 IETF RFC 2847 中所提到的，LIPKEY 是一种基于 GSS-API 安全机制的低基础设施，该安全机制对应于典型的 TLS（Transport Layer Security）部署场景。其包括一台没有公钥证书的客户机，该客户机通过公钥证书访问服务器。

在该机制中，客户机：

1. 获得服务器证书。
2. 核实证书是由受信任的认证权威（Certification Authority ，CA）所签署的。
3. 生成随机会话对称密钥。
4. 使用服务器公钥对会话密钥进行加密。
5. 将加密的会话密钥发送给服务器。

此 时，客户机和服务器有了一条安全通道。然后，客户机就可以向服务器提供用户名称和口令，以验证客户机身份。当发起者（客户机）没有证书而是使用用户 ID 和口令进行验证身份时，就可以使用 LIPKEY 机制。关于 LIPKEY 的更多信息，可参阅 IETF RFC 2847（参阅 参考资料）。