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

使用新的 GSS-API 安全机制来定制 IBM® DB2® Universal　Database™ (DB2 UDB) 安全插件，以实现基于公钥技术的身份验证。

　　简介

　　DB2 UDB 提供一种框架，用于编写定制的安全插件，管理员可使用这些插件进行 DB2 UDB 身份验证。该框架是在 DB2 UDB V8.2 中引入的，也支持基于通用安全服务应用程序编程接口（Generic Security Service Application Programming Interface，GSS-API）的插件身份验证。

　　许多 DB2 UDB 管理员利用 GSS-API 插件进行基于 Kerberos 的身份验证。由于 NFS V4（Network File System Version 4, [IETF RFC-3530]）的顺利开发，以及 RFC 要求使用较新的 GSS-API 机制，如 SPKM（Simple Public Key Mechanism, [IETF RFC-2025]）和 LIPKEY（A Low Infrastructure Public Key Mechanism Using SPKM, [IETF RFC-2847]），DB2 UDB 很快会具有支持这些新的安全机制的 GSS-API 产品。

　　DB2 UDB 安全性系列文章 第 2 部分 介绍并解释了用于身份验证的 DB2 UDB 安全插件架构。本文将进一步介绍有关新的 GSS-API 安全机制的信息。然后还将描述：如何通过使用新的具有可定制的 DB2 UDB 安全插件的 GSS-API 安全机制来实现基于公钥技术的身份验证。

　　用于身份验证的 DB2 UDB 安全插件

　　身份验证是使用安全机制对用户提供的凭证进行确认的过程，这已在 DB2 安全系列文章的 第 1 部分 中进行了讨论。在 DB2 UDB 中，用户和组身份验证由 DB2 UDB 的外部设备以插件的形式来管理，如操作系统、域控制器或者 Kerberos 安全系统。

　　安全插件是 DB2 UDB 所加载的动态可加载库，用来提供以下功能：

• 组检索插件：检索给定用户的组成员信息。
• 客户机身份验证插件：管理 DB2 客户机上的身份验证。
• 服务器身份验证插件：管理 DB2 服务器上的身份验证。

 

　　DB2 UDB 支持两种插件身份验证机制：

• 使用用户 ID 和口令的身份验证。
• 使用 GSS-API 的身份验证，其正式称法为 Generic Security Service Application Program Interface Version 2 [IETF RFC2743] 和 Generic Security Service API Version 2: C-Binding [IETF RFC2744]。

 

　　在 DB2 Version 8.2 中，默认行为是使用在操作系统级别实现身份验证机制的用户 ID/口令插件。下图提供了 DB2 UDB 安全插件基础设施的高级视图：

图 1. DB2 UDB 安全插件基础设施的高级视图

　　利用 DB2 UDB 安全插件架构，您可以通过开发自己的插件或从第三方购买插件的方式来定制身份验证行为。为了允许定制 DB2 UDB 身份验证行为，DB2 UDB 提供了可用来修改现有插件或构建新的安全插件的 API。本文将集中讨论使用 GSS-API 进行身份验证，并展示如何利用新的 GSS-API 安全机制，如 SPKM（Simple Public Key Mechanism, [IETF RFC-2025]）和 LIPKEY（A Low Infrastructure Public Key Mechanism Using SPKM, [IETF RFC-2847]）进行 DB2 UDB 身份验证。

　　GSS-API 及其未来对 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（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（参阅 参考资料）。

　　LIPKEY（A Low Infrastructure Public Key Mechanism using SPKM, IETF RFC-2847）：

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

　　使用较新的受支持的 GSS-API 机制的 DB2 UDB 身份验证

　　DB2 UDB V8.2 支持 GSS-API 身份验证机制。事实上，IBM 为 DB2 UDB 提供的示例 Kerberos 安全插件是基于 GSS-API 的。换言之，IBM 的 Kerberos 支持是作为一个 GSS-API 安全插件来提供的，您可将该插件用于服务器身份验证和用户身份验证。此外，用于 DB2 UDB 的 GSS-API 安全插件可以带来更大的价值，因为 NFS V2 的实现使您将会具有这样的 GSS-API 库：其既支持传统的对称密钥安全机制（即 Kerberos），又支持未来的非对称密钥安全机制，如 SPKM 和 LIPKEY。

　　要允许 DB2 UDB 使用 SPKM/LIPEY 机制进行身份验证：

1. 编写支持 SPKM/LIPKEY 安全机制的定制的 GSS-API 安全插件。当然，这将需要支持 SPKM/LIPKEY 机制的 GSS-API 产品。为了定制身份验证，DB2 UDB 通过向开发人员提供某些 API 使其可以编写自己的身份验证插件，从而提供一种框架。在开发安全插件时，需要实现 DB2 UDB 调用的标准身份验证函数。编写支持 SPKM/LIPKEY 的 GSS-API 插件非常类似于编写 Kerberos 安全插件，只是存在非常微小的差别，后面将进行说明。为了更好地理解如何编写 GSS-API 安全插件，应阅读并且理解 IBM 提供的用于 DB2 UDB 的 Kerberos 安全插件，其基于 GSS-API（参阅 参考资料）。
2. 为了进行基于 SPKM 的身份验证，通常需要：
   • 在 DB2 UDB 服务器中：一张 X.509 证书，一个 PKI（Public Key Infrastructure）环境，以及一个支持 SPKM 的服务器端 GSS-API 安全插件。
   • 在 DB2 UDB 客户机中：一张 X.509 证书，一个 PKI 环境，以及一个支持 SPKM 的客户端 GSS-API 安全插件。
3. 为了进行基于 LIPKEY 的身份验证，通常需要：
   • 在 DB2 UDB 服务器中：一张 X.509 证书，一个 PKI 环境，以及一个支持 LIPKEY 的服务器端 GSS-API 安全插件。DB2 服务器还需要具有对用户 ID/口令数据库的访问权，以进行客户端身份验证。通常，支持 LIPKEY 机制的 GSS-API 产品会提供用户 ID/口令数据库的详细信息。
   • 在 DB2 UDB 客户机中：一个支持 LIPKEY 的客户端 GSS-API 安全插件。注意，客户机不需要具有任何 X.509 证书，但是可能需要具有 PKI 环境，以确认服务器的 X.509 证书。通常，这将由支持 LIPKEY 机制的 GSS-API 产品进行详细记载。

　　下图描绘的高级视图是，当使用支持 SPKM 或 LIPKEY 的 GSS-API 插件时，DB2 UDB 身份验证的工作原理。

图 2. 使用 SPKM 安全机制的 DB2 UDB 身份验证的高级视图


图 3. 使用 LIPKEY 安全机制的 DB2 UDB 身份验证的高级视图

　　由上面两图可知：身份验证是通过交换 GSS-API 令牌来实现，这对于 GSS-API 安全模型非常典型。提请大家注意的关键点是：

• 对于 SPKM 安全机制，DB2 UDB 客户机和 DB2 UDB 服务器是基于其所持有的 X.509 证书来完成身份验证的。
• 对于 LIPKEY 机制，X.509 证书仅用于服务器身份验证，而客户机身份验证是通过由客户输入的用户 ID 和口令来完成的（因此将其视为一种低基础设施公钥机制）。而且，LIPKEY 机制被设计成使用户 ID、口令及身份验证结果的数据交换均在客户机和服务器之间的安全网络通道上进行。

 

　　除了将在本节列出的少数修改内容之外，开发支持 SPKM 或 LIPKEY 的 GSS-API 插件类似于开发用于 DB2 UDB 的 Kerberos 安全插件。下面的讨论假设您熟悉 DB2 UDB 安全插件编程以及与 DB2 UDB 一起发布的 Kerberos 安全插件。关于更多信息，请参阅 DB2 UDB 文档（参见 参考资料）。

　　在开发 DB2 UDB 安全插件时，需要实现 DB2 UDB 将会调用的标准身份验证函数：db2secClientAuthPluginInit()、db2secClientAuthPluginTerm()、db2secServerAuthPluginInit()、db2secServerAuthPluginTerm()，等等。对于 GSS-API 身份验证插件，也需要实现在 DB2 UDB 文档中所提及的 GSS-API 函数：gss_init_sec_context()、gss_aclearcase/" target="_blank" >ccept_sec_context()、gss_acquire_cred()，等等。您可在 IBMkrb5.c 中找到一个示例实现，IBMkrb5.c 与 DB2 UDB 一起发布的一个示例 Kerberos 安全插件。下面几点说明了在开发用于 DB2 UDB 支持 SPKM 或 LIPKEY 的 GSS-API 插件时需要考虑的关键问题。

1. 获得一份支持 SPKM 或 LIPKEY 机制（或同时支持两者）的 GSS-API 产品的副本，并设置所需的 PKI 环境。
2. 在实现用于插件的 db2secServerAuthPluginInit() 函数时：
   • 请确保明确地获得了用于所希望的安全机制的凭证。为此，请向 gss_acquire_cred() 传递适当的机制 OID（如在 GSS-API 产品的头文件中所定义的）。注意，若指定 GSS_C_NO_OID_SET 作为所希望机制的 OID，那么 gss_acquire_cred() 将会为默认的安全机制（通常是 Kerberos）取得凭证。
   • 对于 LIPKEY 和 SPKM 机制，请确保用与 DB2 服务器相关联的 X.509 证书的主题名称填充服务器主名称（将为它获得凭证）。通常，DB2 实例名称会被假定为服务器名称。在这种情况下，应确保与 DB2 服务器相关联的 X.509 证书中的主题名称（或者至少是主题名称的公共名称组件）与 DB2 实例名称相匹配。否则，gss_acquire_cred() 函数将不能取得服务器凭证。
3. 在 db2secGenerateInitialCred() 函数的实现中，请确保明确地获得了用于所希望的安全机制的凭证。为此，请向 gss_acquire_cred() 传递适当的机制 OID（如在 GSS-API 产品的头文件中所定义的）。尤其对于 LIKEY 机制而言，在执行 db2secGenerateInitialCred() 的过程中，客户将被要求输入用户 ID 和口令，以用于客户端身份验证。
4. 在 db2secProcessServerPrincipalName() 函数的实现中，将会把一个文本服务主名称转换为 GSS-API 的内部格式，以用于其他 API。为此，请使用 gss_import_name() 函数。通常，文本服务主名称应该与同 DB2 服务器相关联的 X.509 证书中的主题名称（或者至少是主题名称的公共名称组件）相匹配，或者与在服务器端获得凭证的服务器主名称相匹配。
5. 需要封装或覆盖 gss_init_sec_context() 函数，以确保传递正确的所希望机制的 OID，从而为它启动安全上下文。GSS-API 的默认行为是为 Kerberos 安全机制启动上下文。

　　实现其余的 DB2 UDB API 函数类似于编写 DB2 UDB 文档中所描述的 GSS-API 安全插件，并且这些函数已经在与 DB2 UDB 一起发布的示例 Kerberos 安全插件中实现了。

　　结束语

　　有了诸如 SPKM 和 LIPKEY 之类的由 GSS-API 所支持的附加安全机制，DB2 UDB 管理员/程序员就应该考虑实现支持这些机制的较新的 GSS-API 安全插件。有了对这些未来的 GSS-API 机制（SPKM3 和 LIPKEY）的支持，使用 GSS-API 插件将有利于 DB2 UDB 管理员基于公钥技术或传统对称密钥机制进行 DB2 UDB 身份验证，而不需要做太多的代码修改。

原文转自：http://www.ltesting.net