对于许多应用程序来说,建立基本的上下文足以确保对上下文启动器进行正确的验证。如果需要实现额外的安全性,则可以使用 GSS-API 所提供的通道绑定功能。通道绑定是用于标识所使用的特定数据通道的标记。具体来说,通道绑定可标识起点和终点,即上下文的启动器和接受器。由于标记特定于始发者应用程序和接收者应用程序,因此此类标记可为有效标识提供更多证明。
gss_channel_bindings_t 数据类型是一个指针,它指向如下所示的作为通道绑定的 gss_channel_bindings_struct 结构。
typedef struct gss_channel_bindings_struct { OM_uint32 initiator_addrtype; gss_buffer_desc initiator_address; OM_uint32 acceptor_addrtype; gss_buffer_desc acceptor_address; gss_buffer_desc application_data; } *gss_channel_bindings_t;
第一个字段表示地址类型,用于标识所发送的启动器地址采用的格式。第二个字段表示启动器的地址。例如,initiator_addrtype 可能会发送到 GSS_C_AF_INET
,表示 initiator_address 采用的是 Internet 地址(即 IP 地址)形式。同样,第三和第四个字段分别表示接受器的地址类型和接受器的地址。应用程序可以根据需要使用最后一个字段 application_data。如果不打算使用 application_data,请将 application_data 设置为 GSS_C_NO_BUFFER
。如果没有为某个应用程序指定地址,则应当将该应用程序的地址类型字段设置为 GSS_C_AF_NULLADDR
。通道绑定的地址类型一节提供了有效地址类型值的列表。
地址类型用于表示地址族,而不是表示特定的寻址格式。 对于包含多种替换地址形式的地址族,initiator_address 和 acceptor_address 字段中必须包含足够的信息才能确定所使用的形式。 除非另行指定,否则应当以网络字节顺序(即地址族的本机字节排序)指定地址。
要建立使用通道绑定的上下文,gss_init_sec_context() 的 input_chan_bindings 参数应当指向所分配的通道绑定结构。该结构的字段将连接到一个八位字节字符串,并将派生一个 MIC。该 MIC 随后会绑定到输出令牌。然后,应用程序会将该令牌发送到上下文接受器。接受器在收到该令牌之后将调用 gss_accept_sec_context()。有关更多信息,请参见在 GSS-API 中接受上下文。gss_accept_sec_context() 会针对所收到的通道绑定计算 MIC。如果 MIC 不匹配,gss_accept_sec_context() 随后将返回 GSS_C_BAD_BINDINGS。
由于 gss_accept_sec_context() 会返回已传送的通道绑定,因此接受器可以使用这些值来执行安全检查。例如,接受器可以针对保留在安全数据库中的代码字检查 application_data 的值。
基础机制可能不会为通道绑定信息提供保密性。因此,除非确保能够实现保密性,否则应用程序不应当在通道绑定中包括敏感信息。要测试保密性,应用程序可以检查 gss_init_sec_context() 或 gss_accept_sec_context() 的 ret_flags 参数。值 GSS_C_CONF_FLAG 和 GSS_C_PROT_READY_FLAG 可用于指示保密性。有关 ret_flags 的信息,请参见在 GSS-API 中启动上下文或在 GSS-API 中接受上下文。
单个机制可以针对出现在通道绑定中的地址和地址类型施加额外的约束。 例如,一个机制可能会验证通道绑定的 initiator_address 字段是否返回到 gss_init_sec_context()。因此,具有可移植性的应用程序应当为地址字段提供正确的信息。如果无法确定正确的信息,则应当将 GSS_C_AF_NULLADDR
指定为地址类型。