GS2 类型的SASL 2010.7 RFC5801翻译 - tRavAsty/SASL GitHub Wiki
这个文档描述了如何在SASL中使用通用安全服务应用程序接口机制(GSS-API)。通过定义一个新的SASL机制家族，叫做GS2。这个机制提供了一系列基于以前的GSSAPI机制的提高；它更加通用，在某些情况下用更少的消息来认证，并且支持管道绑定的协商使用（shenmegui）
##1 介绍 GSS-API是RFC2743提供的一个框架，这个框架可以提供认证和基于连接的协议的安全层的服务，同样使用了非常多的机制。这个文件描述了如何使用一个GSS-API机制就好像它是一个SASL机制一样。这种设施就叫做GS2
GS1桥没能得到广泛的使用除了"the kerberos version 5 GSS-API Mechanism",而且有一系列问题使得想要设计一个新的桥。
特别的，目前SASL团体看起来好像一致同意SASL的安全层非常复杂而且冗余因为SASL应用往往可以选择运行在TLS上。SASL的安全层的使用最好能和TLS管道进行管道绑定
GS2被设计得尽可能简单。特别的，GS2增加了一个小的头标（一些比特和客户端请求的SASL认证身份）到初始的GSS-API内容令牌和应用管道绑定的数据。GS2使用SASL机制协商来实施管道绑定协商。安全相关的GS2明文通过GSS-API的管道绑定使用来保护。除此之外,为了简化不会使用GSS-API框架的GS2机制的实施，我们压缩了初始安全内容令牌头通过RFC2743.Section 3.1方法
GS2并不保护GS2以外的任何明文，例如SASL机制协商明文，或者认证之后的应用消息。但是使用管道绑定到一个安全的管道上所有的SASL和应用明文会让所有明文被认证
##3 机制名称 有两个SASL机制名称给任何使用这套设施的GSS-API机制。一个表示服务器支持管道绑定，另一个表示不支持
SASL机制名称是当它被指定时的机制提供的。这个名字表明了服务器不支持管道绑定。加上一个后缀"-PLUS"之后的名字表明服务器支持管道绑定。
如果GSS_Inquire_SASLname_for_mech接口没有被使用的话，GS2需要用其他的方法来内部联系机制对象标识符和SASL名称。如果这个常识失败了，那么GS2不能被使用
###3.1 从GSS-API 对象标识符产生SASL机制名称
SASL机制名称是一个字符串“GS2-”和字符串通过ASN.1 DER加密的二进制哈希值的前55位的Base32加密，包括GSS-API Oid的tag和长度字节。Base32字母表外的字母和本次使用的Base32方法不相关。 如果任何填充或者非法字符出现了，那么这个名字就不是GS2家族中的机制名字。后缀“-PLUS”表示服务器支持管道绑定
###3.2 手动计算机制名称
哈希衍生的GS2 SASL机制名称可以被手动计算。这在知道会使用的机制表示会很有用。它消灭了实行Base-32，SHA-1和DER在SASL机制中的要求，而且如果它是机制家族中的一员的话那么它的实施不需要担心
###3.3 例子
简单公钥GSS-API机制（SPKM-1）的OID是1.3.6.1.5.5.1,这个OID的ASN.1 DER加密的十六进制是06 07 2b 06 01 05 05 01 01.这个ANS.1 DER加密的SHA-1哈希值是1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56 27 86 61 ad。吧前7个字节转化成二进制，丢弃最后一位，通过5位一组来分组，再把他们转成10进制，会有如下计算
前7个字节的16进制:
1c f8 f4 2b 5a 9f 80
前7个字节的二进制:
00011100 11111000 11110100 00101011 01011010
10011111 1000000
5个一组的二进制:
00011 10011 11100 01111 01000 01010 11010 11010
10011 11110 00000
每一组的十进制表示:
3 19 28 15 8 10 26 26 19 30 0
base32 加密:
D T 4 P I K 2 2 T 6 A
最后一步的翻译使用了Base32的表3
Table 3: The Base 32 Alphabet
Value Encoding Value Encoding Value Encoding Value Encoding
0 A 9 J 18 S 27 3
1 B 10 K 19 T 28 4
2 C 11 L 20 U 29 5
3 D 12 M 21 V 30 6
4 E 13 N 22 W 31 7
5 F 14 O 23 X
6 G 15 P 24 Y (pad) =
7 H 16 Q 25 Z
8 I 17 R 26 2
因此，SPKM-1 GSSAPI的SASL机制名称就叫作"GS2-DT4PIK22T6A" 同理Kerberos V5 GSS-API mechanism的SASL机制名称叫做"GS2-QLJHGJLWNPL"，又因为她支持管道绑定，所以它的名称叫做"GS2-QLJHGJLWNPL-PLUS"
###3.4 爷爷机制名称（我想静静）
有一些古老的GSS-API机制并没有制定的SASL GS2名称。使用一个短名字可以有效。我们指定"GS2-KRB5" 和"GS2-KRB5-PLUS"给Kerberos V5机制的名称
##4 SASL认证交换消息格式
在GS2的SASL认证交换中，一大堆遵守下列格式的消息会在客户端和服务器之间发送。 一旦成功，这个数字就是GSS-API通常会要求来建立安全内容的内容令牌的数字；一旦是被，这个交换就会被任意一方提前终止
当使用GS2机制时SASL客户端总是一个GSS-API初始者而SASL服务器也总是一个GSS-API的接受者。客户端叫做GSS_Init_sec_context，服务器端叫做GSS_Accept_sec_context
所有的SASL认证消息交换和GSS-API机制中的安全内容令牌一样，除了初始安全内容令牌
客户端和服务器也许会发送GSS-API错误令牌。这个指示了一个错误的状态，在发送这个令牌之后，发送端会认证失败
初始安全内容令牌按照如下的方法修饰：
初始内容令牌头必须被移除。如果投标不存在，那么客户端必须发送一个“"gs2-nonstd-flag”标志。在服务器端，这个投标需要被重新计算并且在 GSS_Accept_sec_context令牌前储存，除非接受到gs2-nonstd-flag
一个GS2头标必须是结果初始内容令牌的前缀
以下数据描述了允许的属性,他们的用法，以及他们值得格式。所有的属性名称都是单个US-ASCII字符并且大小写敏感
UTF8-1-safe = %x01-2B / %x2D-3C / %x3E-7F
;; As UTF8-1 in RFC 3629 except
;; NUL, "=", and ",".
UTF8-2 = <as defined in RFC 3629 (STD 63)>
UTF8-3 = <as defined in RFC 3629 (STD 63)>
UTF8-4 = <as defined in RFC 3629 (STD 63)>
UTF8-char-safe = UTF8-1-safe / UTF8-2 / UTF8-3 / UTF8-4
saslname = 1*(UTF8-char-safe / "=2C" / "=3D")
gs2-authzid = "a=" saslname
;; GS2 has to transport an authzid since
;; the GSS-API has no equivalent
gs2-nonstd-flag = "F"
;; "F" means the mechanism is not a
;; standard GSS-API mechanism in that the
;; RFC 2743, Section 3.1 header was missing
cb-name = 1*(ALPHA / DIGIT / "." / "-")
;; See RFC 5056, Section 7.
gs2-cb-flag = ("p=" cb-name) / "n" / "y"
;; GS2 channel binding (CB) flag
;; "p" -> client supports and used CB
;; "n" -> client does not support CB
;; "y" -> client supports CB, thinks the server
;; does not
gs2-header = [gs2-nonstd-flag ","] gs2-cb-flag "," [gs2-authzid] ","
;; The GS2 header is gs2-header.
当gs2-nonstd-flag旗帜出现的时候，客户端不会从初始的GSS_Init_sec_context返回的令牌寻找/移除一个令牌头。这告诉服务器说它不能重新增加已经被客户端正常移除的数据
gs2-cb-flag显示在管道绑定模式。"p", "n" 和 "y"中的一个会被使用。"p"意味着客户端支持并且使用了管道绑定，而且管道绑定类型的名字已经被指示了；"n"意味着客户端不支持管道绑定;"y"意味着客户端支持管道绑定，但是认为服务器不支持，所以它没使用管道绑定。接下来的章节会详细的说明
"gs2-authzid"保留SASL认证身份。它通过UTF-8字符，除了以下三种：
NUL禁止使用
服务器必须把所有的","替换成字符串"=2C"
服务器必须把所有的"="替换成字符串"=3D"
在这个值得收据中，服务器会由使用过的SASL协议文件验证它的正确性。失败的认证导致失败的认证交换
##5 管道绑定
GS2 支持管道绑定到外部的安全管道中，比如说TLS。客户端和服务器也许支持或者不支持管道绑定；因此，管道绑定的使用是可协商的。然而，GS2不提供安全层；因此，GS2必须提供管道协商的完整性安全保护
管道绑定的协商如下：
支持管道绑定的服务器应该告知non-PLUS名称和PLUS变量名称。如果服务器不能支持管道绑定，它应该只告知
non-PLUS变量。如果服务器因为政策原因从来没有在non-PLUS变量下成功过，那么它就只能告知PLUS变量
如果客户端支持管道绑定但是服务器好像不支持，那么客户端不能在"gs2-cb-flag"中使用"n"
支持机制协商和管道绑定的客户端在服务器提供PLUS变量的时候必须在"gs2-cb-flag"中使用"p"
如果客户端不支持管道绑定，那么它必须在"gs2-authzid"中使用"n"，反过来，如果客户端要求使用管道绑定的话那么它必须在"gs2-authzid"中使用"p"。不支持机制协商的客户端不能在"gs2-authzid"中使用"y"
客户端产生chan_bindings输入参数给GSS_Init_sec_context
如果服务器提供了管道绑定服务但是得到"gs2-authzid"的回复"y"，那么服务器必须终端这次认证协商。如果服务器得到"p"，但是不支持管道绑定，服务器也同样得终止这次协商
###5.1 GSS-CHANNEL-BINDINGS结构的内容
GSS_Init_sec_context和GSS_Accept_sec_context的调用需要使用一个chan_bindings parameter参数。
GSS-CHANNEL-BINDINGS结构中的initiator-address-type域和acceptor-address-type域必须为0。The initiator-address和acceptor-address域必须为空字符串
application-data field域必须设置gs2-头标，
###5.2 默认的管道绑定
给所有不提供自己的管道绑定类型的SASL应用协议的默认协议描述如下
'tls-unique'是没有特别标明管道绑定的应用的默认绑定
服务器支持管道绑定的话，就必须支持"tls-unique"管道绑地，客户端也同理。客户端和服务器应该选择最高级的端到端的TLS管道作为被绑定的管道
##6 例子
GSS-API认证总是由客户端发起的，而SASL允许任意一端发起