DB2 UDB 安全性: 使用 GSS-API 安全机制（SPKM/LIPKEY）的安全插件

核心提示： 到目前为止，大部分 GSS-API 产品所支持的惟一的安全机制就是名为 Kerberos [IETF RFC-1964] 的流行的基于对称密钥的机制，DB2 UDB 安全性: 使用 GSS-API 安全机制（SPKM/LIPKEY）的安全插件(3)，但是，随着 NFS V4[IETF RF

到目前为止，大部分 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（Simple Public Key Mechanism, IETF RFC-2025）

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（参阅 参考资料）。