RFC1961中文翻译 GSS-API对SOCKS V5 的认证方法(GSS-API Authentication Method for SOCKS Version 5)

原创 2006年05月23日 20:31:00
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: p.v.mcmahon@rea0803.wins.icl.co.uk
   Phone: +44 1734 634882
   Fax:   +44 1734 855106
 
 

相关文章推荐

(RFC1928)SOCKS V5.doc

  • 2007年06月01日 10:23
  • 58KB
  • 下载

Socks5协议中文文档(RFC1928)

转自:http://blog.chinaunix.net/uid-26548237-id-3434356.html(侵删) RFC1928文档    最近,需要用到socks5协议,实现与代理...

SPOJ GSS5 Can you answer these queries V(区间合并)

Can you answer these queries V Description You are given a sequence A[1], A[2], ..., A[N] . ( |...

SPOJ GSS5 Can you answer these queries V

题意: 给定一个序列和m个询问, 每次询问左端点在[x1,y1],右端点在[x2,y2]的最大连续子段和。 思路: 还是用线段树跟GSS1差不多的搞,如果两个区间不相交的话,就求出[x1,y1]...

SPOJ 2916 Can you answer these queries V(GSS5 线段树)

转载请注明出处,谢谢http://blog.csdn.net/acm_cxlove/article/details/7854526       by---cxlove 题目:和GSS3类似,只不...

[资料整理]四种代理服务器的原理(二)——SOCKS v5代理服务器的原理

本文由TZWSOHO通过收集网络资料整理而成(百度百科和英文维基百科),文中某些地方可能由于笔者本人技术水平有限而造成翻译上甚至是个人理解上的错漏,欢迎路过本文的各路英雄斧正。另若有需要转载时请高抬贵...
  • tzwsoho
  • tzwsoho
  • 2011年01月09日 16:15
  • 1712

[资料整理]四种代理服务器的原理(二)——SOCKS v5代理服务器的原理

SOCKS v5的原理与SOCKS v4/v4a的原理大致相同,但增加了对UDP协议的支持、安全验证机制及IPv6的支持。客户端通过SOCKS v5代理服务器与外部建立连接的流程如下:1、  客户端尝...

Socks5协议中文文档

译者:Radeon(Radeon bise@cmmail.com) 译文发布时间:2001-6-18 目录 1.介绍 2.现有的协议 3.基于TCP协议的客户 4.请求 5.地址 6....

Socks5代理(SSH)转国内PPTP的方法

SSH这种Socks5代理工具最常用的一种使用方法是在浏览器上配置代理端口,然后指向该工具监听的1080端口的方式进行代理,这是Windows系统用户最常见的方式,这样无法进行全局代理和UDP代理。而...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:RFC1961中文翻译 GSS-API对SOCKS V5 的认证方法(GSS-API Authentication Method for SOCKS Version 5)
举报原因:
原因补充:

(最多只允许输入30个字)