kerberos验证_使用Kerberos实现AIX的两因素身份验证

身份验证是任何给定系统中最关键的模块之一。 Kerberos是一种流行的安全机制，系统用于网络身份验证和数据的安全传输。 几乎所有支持可插拔身份验证模块的基于UNIX®的操作系统都包含基于Kerberos的身份验证。 IBM®AIX®V5.3具有Kerberos集成的登录名，并且具有许多其实用程序，例如SSH，rlogin，telnet等。 IBM AIX附带了自己的Kerberos风格，称为IBM Network Authentication Service，可在其扩展包CD中找到（请参阅参考资料 ）。

随着对安全环境的需求的增加，系统（包括操作系统）的身份验证模块已从传统的单因素身份验证（通常基于静态密码）转移到多因素身份验证。 两因素身份验证是一种实践流行的方法，用于提高安全性。 本文介绍了如何在两因素身份验证系统中使用Kerberos。 它详细介绍了如何在多因素身份验证方案中使用Kerberos和一次性密码（OTP）来拥有一个更高安全性的系统。 最后，本文为您提供了使用Kerberos和通用安全服务API（GSS-API）实现两因素身份验证系统的设计。

使用Kerberos和OTP进行两因素身份验证

身份验证是出于安全目的验证个人身份的过程，而身份验证因素是用于实现身份验证的信息。 两因素身份验证是一个过程，其中两个不同的因素用于身份验证，因此可提供更高级别的安全性。 通常，在两因素身份验证系统中，用于验证用户身份的第一个因素是用户知道的东西，例如静态密码或密码，第二个因素是用户拥有的东西，例如信用卡，手机，或生成一次性密码（OTP）令牌的硬件安全令牌。 OTP系统通常建立在客户端-服务器模型上，其中在给定的时间，对于给定的用户，在客户端会生成相同的一次性密码。 客户端可以是手持式硬件设备，通过诸如USB的电子接口连接到个人计算机的硬件设备，或者是驻留在个人计算机上的软件模块，以及进行验证的服务器端。 在这些系统中，密码不断更改，这大大降低了未经授权的入侵者带来的风险。 因此，它在两因素身份验证中的使用被认为更安全，并且适合许多需要高度安全的身份验证模块的系统。 有关OTP的更多信息，请参阅IETF RFC 2289（参见相关主题 ）。

Kerberos是用于网络身份验证的流行安全性机制。 诸如AIX，Linux®和Windows®之类的大多数操作系统登录模块都支持基于Kerberos的认证。 此外，在UNIX上可用的许多远程登录应用程序（如Open SSH，telnet，rlogin等）都具有Kerberized版本。 基于Kerberos的身份验证模块直接使用Kerberos API或使用GSS-API接口来实现。 随着Kerberos的使用不断增加，从业人员可能面临使Kerberos机制成为使用OTP的两因素身份验证系统一部分的需求。

在针对两因素身份验证系统的拟议设计中，本文将Kerberos用于第一因素身份验证，然后利用Kerberos基础结构（使用GSS-API接口）通过使用Kerberos安全地实现第二因素身份验证。 OTP令牌。 通过这种方式，您可以实现安全的两因素身份验证，其中Kerberos协议起着双重作用：

• 在第一因素身份验证中使用Kerberos作为身份验证协议。
• 在第二因素身份验证期间，使用Kerberos（使用GSS-API接口）作为在客户端和服务器之间与OTP及其验证结果进行通信的安全通道。

除了现有的Kerberized应用程序（具有单因素身份验证）之外，该设计还可以合并到基于网络的解决方案中，该解决方案需要两因素身份验证以及Kerberos协议。

GSS API

如IETF RFC 2078定义（参见相关主题 ）

通用安全服务应用程序接口（GSS-API）以通用方式向调用者提供安全服务，可通过一系列底层机制和技术来支持，从而允许应用程序在源级别移植到不同的环境。

Kerberos是GSS-API可用的最流行的基础安全机制。 适用于AIX的IBM Network Authentication Service V1.4实现了GSS-API标准，并使用支持Kerberos机制的GSS-API库导出其接口。 使用这些GSS-API接口，您可以实施安全的Keberized应用程序和系统。 通常，在GSS-API中，两个通信应用程序之间的安全连接由称为安全上下文的数据结构表示。 建立安全连接的应用程序称为上下文启动器。 接受安全连接的应用程序是上下文接受器。 发起方和接受方之间的上下文建立实际上是一个握手过程，涉及双方的身份验证。 成功建立GSS-API上下文后，可以得出结论，用户标识已成功验证。

重要的GSS-API接口

可以使用Kerberos GSS-API编程的两个重要方面是身份验证，然后是按消息加密。 以下是一些有助于实现上述要求的重要接口：

gss_init_sec_context（...）

在上下文发起者和上下文接受者之间建立安全上下文。

gss_accept_sec_context（...）

接受上下文发起者创建的安全上下文。

gss_wrap（...）

加密签名并可选地加密消息。

gss_unwrap（...）

解包由gss_wrap子例程密封的消息，并验证嵌入的签名。

有关GSS-API的更多信息，请参阅产品随附的IBM Network Authentication Service版本1.4 Application Development Reference。

使用GSS-API和OTP设计一个两因素身份验证系统

图1显示了配置为Kerberos服务器系统的Kerberized客户端。 这两个系统都可以是安装并配置了IBM Network Authentication Service的AIX机器。

图1.使用GSS-API和OTP实施两因素身份验证系统的设计步骤

下面说明了可以使用标准Kerberos GSS-API来实现以实现带有OTP的两要素身份验证登录模块的步骤。

步骤1-提示用户输入Kerberos用户名和Kerberos密码。

步骤 2、3、4、5、6、7-使用Kerberos用户名和相应的Kerberos密码（用户必须记住）来获取Kerberos凭证（TGT-Ticket授予票证）。 如果输入的密码不正确，则身份验证失败，并且不允许用户访问。 成功获取Kerberos票证（TGT）后，第一因素身份验证完成。 这类似于任何基于Kerberos身份验证的常规登录模块。

步骤9、10、11-使用上面获得的Kerberos凭据，并使用驻留在系统上的基于GSS-API的OTP应用服务器来建立安全的GSS-API上下文（假设OTP服务器已使用GSS-API进行了Kerberized）。 这涉及到客户端登录模块和基于GSS-API的一次性密码应用程序服务器之间的握手。 请注意，这里的登录模块和OTP应用程序服务器都是基于Kerberos机制运行的基于GSS-API的应用程序。 握手在客户端执行gss_init_sec_context（）和相关API，在服务器端执行gss_accept_sec_context（）和相关API。 成功握手后，将在基础Kerberos安全机制上建立经过安全身份验证的GSS-API上下文。 此上下文可帮助客户端登录模块和基于GSS-API的服务器进行安全通信。 如果握手失败，则终止登录程序。

步骤12-输入一次性密码。 OTP是用户拥有的身份验证信息（与用户需要记住Kerberos密码的早期身份信息不同）。

步骤 13、14-使用安全建立的GSS-API上下文对用户名和一次性密码进行加密，并将加密后的信息发送到服务器。 GSS-API接口（如gss_wrap（））有助于加密信息，该信息只能由基于GSS-API的OTP服务器应用程序解密。

步骤 15、16-基于GSS-API的OTP服务器应用程序解密身份验证信息，并向实际OTP服务器显示“用户名”和“一次性密码”。 （使用较早建立的安全GSS-API上下文，类似gss_unwrap（）的接口有助于解密信息）。 用户名和一次性密码将针对服务器数据库进行验证，验证结果（成功或失败）将被传递回基于GSS-API的OTP服务器应用程序。

步骤 17、18-基于GSS-API的OTP服务器应用程序对身份验证结果进行加密，并将其传递回客户端登录模块/应用程序。

步骤19-客户端登录模块/应用程序解密并解释结果。 （使用较早建立的安全GSS-API上下文，类似gss_unwrap（）的接口有助于解密信息）。 如果结果成功，则完成第二因素身份验证，并允许用户登录系统。 否则，客户端登录程序将终止，从而清理整个GSS-API上下文以及客户端和服务器端。

注意：这些步骤并不声称已在Kerberos协议中完全引入了两因素身份验证。 它们可以由需要两因素身份验证的从业人员实施，其中第一因素需要常规的Kerberos身份验证，第二因素需要OTP，或者可以作为应用程序或安全系统的登录模块的一部分来实施。

结论

本文重点介绍了GSS-API和Kerberos的使用。 它强调了在这种系统中对多因素身份验证和OTP的使用的日益增长的需求。 最后，它说明了可在高度安全的系统中使用Kerberos和OTP密码实施两因素身份验证的步骤。

---

翻译自: https://www.ibm.com/developerworks/aix/library/au-twofactors/index.html