RFC1961

Network Working Group                                       P. McMahon

Request for Comments: 1961                                         ICL

Category: Standards Track                                    June 1996

           GSS-API对SOCKS V5 的认证方法

目录

         1. Purpose ............................................ 1

         2. Introduction ....................................... 1

         3. GSS-API Security Context Establishment ............. 2

         4. GSS-API Protection-level Options ................... 5

         5. GSS-API Per-message Protection ..................... 7

         6. GSS-API Security Context Termination ............... 8

         7. References ......................................... 8

         8. Acknowledgments .................................... 8

         9. Security Considerations ............................ 8

         10. Author's Address .................................. 9

1.      目的

   本协议为SOCKS V5连接过程指定一个通用认证框架。本文档描述了用于SOCKS V5的GSS-API认证协议，定义了基于GSS-API封装的完整性、认证、可选的机密性定义。

2.      介绍

   GSS-API为分布式应用提供一个抽象接口，该接口提供安全服务。调用者可以是各种特定的安全机制和实现。

   GSS-API的两端通过建立通用的上下文安全机制来实现互操作，这种机制的建立可以通过管理的动作（administrative action）或是协商。GSS-API描述于RFC1508和RFC1509.

   The approach for use of GSS-API in SOCKS V5 is to authenticate the

   client and server by successfully establishing a GSS-API security

   context - such that the GSS-API encapsulates any negotiation protocol

   for mechanism selection, and the agreement of security service

   options.

   SOCKS V5实现GSS-API的方式是通过成功建立一个GSS-API安全上下文来实现客户端与服务器端的认证。

   The GSS-API enables the context initiator to know what security

   services the target supports for the chosen mechanism. The required

   level of protection is then agreed by negotiation.

   GSS-API使能上下文初始器（context initiator）来知道使用什么安全服务，该内容通过协商来得到。

   GSS-API per-message protection call随后用来封装以后服务器与客户端之间的TCP和UDP的流量。

3.      GSS-API安全上下文的建立

3.1 准备

   Prior to use of GSS-API primitives, the client and server should be

   locally authenticated, and have established default GSS-API

   credentials.

   在使用GSS-API primitives以前，客户端和服务器应当被本地认证，并建立缺省的GSS-API信任证书（credentials）

   客户端应当调用gss-import_name来得到服务器名字的内部表示。为了最大限度的可移植性，缺省名字空间应当使用缺省name_type GSS_C_NULL_OID，同时输入的name_string应当当成不透明的name-space.

   比如：当使用Kerberos V5命名，导入的名字格式为"SERVICE:socks@socks_server_hostname","socks_server_hostname"是服务器主机名的全称，并全部是小写字母。另外的机制，可能使用另外的命名方法，所以客户端不应假设命名的格式。

3.2 客户端上下文的建立

   客户端调用gss_init_sec_context，典型的传递：

         GSS_C_NO_CREDENTIAL into cred_handle to specify the default

         credential (for initiator usage),

         GSS_C_NULL_OID into mech_type to specify the default

         mechanism,

         GSS_C_NO_CONTEXT into context_handle to specify a NULL

         context (initially), and,

         the previously imported server name into target_name.

   客户端口同时必须通过gss_init_sec_context req_flags参数指定其对应答保护，委托和序号保护。本规范要求客户端总是要求这些的服务参数（比如在req_flags传递GSS_C_MUTUAL_FLAG | GSS_C_REPLAY_FLAG | GSS_C_DELEG_FLAG | GSS_C_SEQUENCE_FLAG）

然而，GSS_C_SEQUENCE_FLAG只应由基于TCP的客户端传递，基于UDP的客户端不应传递。

3.3 客户端上下文建立主状态码

    gss_init_sec_context返回两种成功的状态码值：

   - If gss_init_sec_context returns GSS_S_CONTINUE_NEEDED, then the

      client should expect the server to issue a token in the

      subsequent subnegotiation response. The client must pass the

      token to another call to gss_init_sec_context, and repeat this

      procedure until "continue" operations are complete.

    - 如果gss_init_sec_context返回GSS_S_CONTINUE_NEEDED，然后客户端应当期望服务器发布一个token在后续的子协商响应（subnegotiation response）。客户端必须传递这个token，在调用另外一个gss_init_sec_context的时候，并重复这个过程直到"continue"操作结束。

    - 如果gss_init_sec_context返回GSS_S_COMPLETE，则客户端应当响应服务器任意output_token

      如果没有output_token，客户端应当发送保护请求细节，包括下面节4和5即将描述要求的信息。

3.4 客户端初始化Token

   客户端的GSS-API实现然后通常响应服务器resulting output_token。

    +------+------+------+.......................+

    + ver | mtyp | len |       token           |

    +------+------+------+.......................+

    + 0x01 | 0x01 | 0x02 | up to 2^16 - 1 octets |

    +------+------+------+.......................+

    Where:

    - "ver" 协议版本号, 1 代表第一个版本的SOCKS/GSS-API protocol

    - "mtyp" 消息类型, 1 代表一个认证消息

    - "len" 表示"token" 域的字节数

    - "token" 表示通过GSS-API发行的不透明的认证token

3.5 客户端GSS-API初始化失败

   当客户端GSS-API实现发现在gss_init_sec_context失败，客户端必须关闭其对服务器的连接。

3.6服务器上下文建立

   当客户端成功的发送一个由gss_init_sec_context()发布的token到服务器时，服务器必须传递token给gss_accept_sec_context，当成input_token。

   当第一次调用gss_accept_sec_context()的时候，context_handle参数初始化为GSS_C_NO_CONTEXT

   为了可移植，verifier_cred_handle设置为GSS_C_NO_CREDENTIAL，为了指定缺省信任证书（credentials）（给接收者使用）

   如果gss_accept_sec_context返回GSS_CONTINUE_NEEDED，服务器应当返回产生的output_token给客户端，并把客户端返回的token传递给另外一次gss_accept_sec_context调用

   如果gss_accept_sec_context返回GSS_S_COMPLETE，则如果一个output_token返回，服务器应当将其返回给客户端。

   如果没有token返回，则服务器应当发送一个0长度的token给客户端，表示其已经准备号接收客户端的请求

3.7 Server Reply服务器应答

   In all continue/confirmation cases, the server uses the same message

   type as for the client -> server interaction.

   在整个continue/confirmation阶段，服务使用同样的消息格式来和客户端交互。

    +------+------+------+.......................+

    + ver | mtyp | len |       token           |

    +------+------+------+.......................+

    + 0x01 | 0x01 | 0x02 | up to 2^16 - 1 octets |

    +------+------+------+.......................+

3.8安全上下文失败

   如果服务器因为各种原因拒绝客户端的连接，服务器返回：

    +------+------+

    + ver | mtyp |

    +------+------+

    + 0x01 | 0xff |

    +------+------+

    - "ver" 协议版本号, 1 代表第一个版本的SOCKS/GSS-API protocol

    - "mtyp" 消息类型, 0xff 表示异常中断消息

4. GSS-API保护层次选项

4.1 消息保护

   Establishment of a GSS-API security context enables comunicating

   peers to determine which per-message protection services are

   available to them through the gss_init_sec_context() and

   gss_accept_sec_context() ret_flags GSS_C_INTEG_FLAG and

   GSS_C_CONF_FLAG which respectively indicate message integrity and

   confidentiality services.

   It is necessary to ensure that the message protection applied to the

   traffic is appropriate to the sensitivity of the data, and the

   severity of the threats.

4.2 消息保护子协商

   对TCP和UDP客户端与服务器，在SOCKS V5协议可能有不同级别的保护，所以需要一个附加子协商来协商消息保护级别。在子协商成功结束后，TCP和UDP客户端与服务器使用定义在节5.1中GSS-API封装。

   成功的建立GSS-API安全上下文后，客户端GSS-API发送其需要的安全上下文保护基本给服务器，服务器随后返回其同意的安全上下文保护级别。

   客户端与服务器端发送的安全上下文保护级别必须时下面的值之一：

         1 required per-message integrity

         2 required per-message integrity and confidentiality

         3 selective per-message integrity or confidentiality based on

           local client and server configurations

   大部分实现都支持level 1 或 2，因为level 3实现困难。

4.3消息保护协商消息格式

    +------+------+------+.......................+

    + ver | mtyp | len |   token               |

    +------+------+------+.......................+

    + 0x01 | 0x02 | 0x02 | up to 2^16 - 1 octets |

    +------+------+------+.......................+

    Where:

    - "ver" 协议版本号, 1 代表第一个版本的SOCKS/GSS-API protocol

    - "mtyp" 消息类型, 这里的2代表保护级别协商消息

    - "len"  长度

    - "token" is the GSS-API encapsulated protection level

4.4消息保护子协商消息产生

   The token is produced by encapsulating an octet containing the

   required protection level using gss_seal()/gss_wrap() with conf_req

   set to FALSE. The token is verified using gss_unseal()/

   gss_unwrap().

   If the server's choice of protection level is unacceptable to the

   client, then the client must close its connection to the server

5. GSS-API Per-Message保护

   对TCP和UDP客户端和服务器，封装和解封装的GSS-API功能函数应当被使用，如gss_seal()/gss_wrap(), and gss_unseal()/ gss_unwrap()

   缺省的保护级别应当被指定，并且如何使用conf_req_flag应当由上一个子协商来决定。如果保护级别为1，则conf_req_flag必须总是为FALSE；如果保护级别为2，则conf_req_flag必须总是为TRUE；如果保护级别为3，则conf_req由客户端与服务器本地配置的per-message来决定。

   所有封装消息使用如下的前缀：

    +------+------+------+.......................+

    + ver | mtyp | len |       token           |

    +------+------+------+.......................+

    + 0x01 | 0x03 | 0x02 | up to 2^16 - 1 octets |

    +------+------+------+.......................+

    - "ver" 协议版本号, 1 代表第一个版本的SOCKS/GSS-API protocol

    - "mtyp" 消息类型, 这里的3代表封装用户数据

    - "len" 长度

    - "token" is the user data encapsulated by GSS-API

6. GSS-API Security Context TerminationGSS-API安全上下文终结

   安全上下文终结消息（由gss_delete_sec_context发布）不在本协议中使用

   当连接关闭时，每一端调用gss_delete_sec_context，传递GSS_C_NO_BUFFER给output_token参数。

7. References

    [RFC 1508] Linn, J., "Generic Security Service API",

               September 1993.

    [RFC 1509] Wray, J., "Generic Security Service API : C-bindings",

               September 1993.

    [SOCKS V5] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D.,

               and L. Jones, "SOCKS Protocol V5", RFC 1928, April

               1996.

8. 感谢

   This document builds from a previous memo produced by Marcus Leech

   (BNR) - whose comments are gratefully acknowleged. It also reflects

   input from the AFT WG, and comments arising from implementation

   experience by Xavier Gosselin (IUT Lyons).

9. Security Considerations

   The security services provided through the GSS-API are entirely

   dependent on the effectiveness of the underlying security mechanisms,

   and the correctness of the implementation of the underlying

   algorithms and protocols.

   The user of a GSS-API service must ensure that the quality of

   protection provided by the mechanism implementation is consistent

   with their security policy.

   In addition, where negotiation is supported under the GSS-API,

   constraints on acceptable mechanisms may be imposed to ensure

   suitability for application to authenticated firewall traversal.

10. Author's Address

   P. V. McMahon

   ICL Enterprises

   Kings House

   33 Kings Road

   Reading, RG1 3PX

   UK

   EMail: [e-mail]

   Phone: [phone]

   Fax:   [phone]