GSS-API 令牌

GSS-API 中的基本“流通”(currency) 单位是令牌 (token)。 使用 GSS-API 的应用程序可以借助令牌来相互通信。 使用令牌可以交换数据并创建安全布局。 令牌声明为 gss_buffer_t 数据类型。 令牌对于应用程序是不透明的。

令牌的类型包括上下文级别的令牌和每消息令牌两种。 上下文级别的令牌主要在建立（即启动和接受）上下文时使用。 另外，还可以在以后通过传递上下文级别的令牌来管理上下文。

每消息令牌在建立了上下文之后使用。 每消息令牌用于为数据提供保护服务。 例如，请考虑一个希望将消息发送到另一个应用程序的应用程序。 该应用程序可能会使用 GSS-API 来生成随该消息传递的加密标识符。 该标识符可存储在令牌中。

可以考虑按如下方式针对消息使用每消息令牌。 消息是应用程序发送到其对等应用程序的一段数据。 例如，ls 命令可以是发送到 ftp 服务器的消息。 每消息令牌是 GSS-API 为该消息生成的对象。 每消息令牌可以是加密标记，也可以是加密形式的消息。 请注意，最后一个示例不太准确。 加密消息仍是消息，而不是令牌。 令牌仅是指 GSS-API 生成的信息。 但是，在非正式情况下，消息和每消息令牌通常可以互换使用。

应用程序负责进行以下活动：

1. 收发令牌。 开发者通常需要编写一般性的读写函数来执行这些操作。 send_token() 和 recv_token() 函数在各种 GSS-API 样例函数中进行介绍。

2. 区分不同类型的令牌并相应地处理这些令牌。

   由于令牌对于应用程序来说是不透明的，因此应用程序不会对不同的令牌加以区分。 如果不知道令牌的内容，则应用程序必须能够区分令牌的类型才能将令牌传递到相应的 GSS-API 函数。 应用程序可以通过以下方法来区分令牌类型：

   • 按状态。 通过程序的控制流程。 例如，等待接受上下文的应用程序可能会假设收到的任何令牌都与所建立的上下文有关。 对等应用程序应当等到上下文完全建立之后才发送消息令牌（即数据）。 建立上下文之后，正在等待接受上下文的应用程序会假设新令牌即是消息令牌。 这是处理令牌的相当常见的方法。 本书中的样例程序会使用此方法。

   • 按标志。 例如，如果某个应用程序包含用于向对等应用程序发送令牌的函数，则该应用程序可以引入一个标志，用于指示令牌类型。 请考虑以下代码：

     gss_buffer_t token;     /* declare the token */
     
     OM_uint32 token_flag       /* flag for describing the type of token */
     
     
     
     <get token from a GSS-API function>
     
     
     
     token_flag = MIC_TOKEN;     /* specify what kind of token it is */
     
     send_a_token(&token, token_flag);

     接收应用程序可包含用于检查 token_flag 参数的接收函数，例如 get_a_token()。

   • 通过明确使用标记。 应用程序可以使用元令牌。 元令牌是一种用户定义的结构，其中包含从 GSS-API 函数收到的令牌。 元令牌包括用户定义的字段，这些字段指示如何使用 GSS-API 提供的令牌。

GSS-API 中的进程间令牌

GSS-API 允许在多进程应用程序中的进程之间传递安全上下文。 通常，应用程序已经接受了客户机的上下文， 然后，应用程序将在其进程之间共享该上下文。 有关多进程应用程序的信息，请参见在 GSS-API 中导出和导入上下文。

gss_export_context() 函数可用于创建进程间令牌。 使用此令牌中包含的信息，另一个进程可以重建该上下文。 应用程序负责在进程之间传递进程间令牌， 这与应用程序负责将令牌传递到其他应用程序情况相似。

进程间令牌可能包含密钥或其他敏感信息。 并非所有的 GSS-API 实现都以加密方式保护进程间令牌。 因此，在进行交换之前，应用程序必须保护进程间令牌。 这种保护可能涉及到使用 gss_wrap() 对令牌进行加密（如果加密机制可用）。

请勿假设进程间令牌可以在不同的 GSS-API 实现之间传送。