Take Up With Web Technology–坏坏的网志

6.1. 概览
XMPP 有一个验证流的方法，即XMPP特定的SASL（简单验证和安全层）[SASL]。SASL提供了一个通用的方法为基于连接的协议增加验证支持，而XMPP使用了一个普通的XML名字空间来满足SASL的需要。

以下规则应用于:

1. 如果SASL协商发生在两台服务器之间，除非服务器宣称的DNS主机名得到解析，不能（MUST NOT）进行通信。(参见 服务器间的通信(第十四章第四节)).
2. 如果初始化实体有能力使用 SASL 协商, 它必须（MUST）在初始化流的头信息中包含一个值为"1.0"的属性'version'。
3. 如果接收实体有能力使用 SASL 协商, 它必须（MUST）在应答从初始化实体收到的打开流标签时(如果打开的流标签包含一个值为"1.0"的'version'属性),通过'urn:ietf:params:xml:ns:xmpp-sasl'名字空间中的<mechanisms/>元素声明一个或多个验证机制.
4. 当 SASL 协商时, 一个实体不能（MUST NOT）在流的根元素中发送任何空格符号(匹配 production [3] content of [XML])作为元素之间的分隔符(在以下的SASL例子中任何空格符号的出现仅仅是为了增加可读性); 这条禁令帮助确保安全层字节的精确度。
5. 当SASL握手时，在XML元素中使用的任何 XML 字符数据必须被编码成 base64, 编码遵循 RFC 3548 第三章的规定。
6. 如果一个 简单名字"simple username" 规范被选定的SASL机制所支持，(比如, 这被 DIGEST-MD5 和 CRAM-MD5 机制支持但不被 EXTERNAL 和 GSSAPI 机制支持), 验证的时候初始化实体应该（SHOULD）在服务器间通信时提供 简单名字 自身的发送域（IP地址或包含在一个域标识符中的域名全称），在客户端与服务器之间通信时提供注册用户名（包含在一个XMPP节点标识符中的用户或节点名）。
7. 如果初始化实体希望以另一个实体的身份出现并且SASL机制支持授权ID的传输，初始化实体在SASL握手时必须（MUST）提供一个授权ID。如果初始化实体不希望以另一个实体的身份出现，初始化实体在SASL握手时不能（MUST NOT）提供一个授权ID。在 [SASL] 的定义中,除非授权ID不同于从验证ID（详见[SASL]）中得到的缺省的授权ID，初始化实体不能（MUST NOT）提供授权ID。如果提供了，这个授权ID的值必须（MUST）是<domain>的格式(对于服务器来说)或<node@domain>的格式(对于客户端来说).
8. 在成功进行包括安全层的SASL握手之后，接收实体必须（MUST）丢弃任何从初始化实体得到的而不是从SASL协商本身获得的信息。
9. 在成功进行包括安全层的SASL握手之后，初始化实体必须（MUST）丢弃任何从接收实体得到的而不是从SASL协商本身获得的信息。
10. 参看 强制执行的技术 (第十四章第七届) ，了解关于必须（MUST）支持的机制.

--------------------------------------------------------------------------------
6.2. 叙述
一个初始化实体使用SASL和接收实体做验证的步骤如下:

1. 初始化实体请求SASL验证，它发送一个打开的XML流头信息给接收实体，其'version'属性的值为"1.0".
2. 在发送一个XML流头回复之后，接收实体声明一个可用的SASL验证机制清单；每个机制作为一个<mechanism/>元素，作为子元素包含在<mechanisms/>容器元素（其名字空间为'urn:ietf:params:xml:ns:xmpp-sasl'）中，而<mechanisms/>则包含在流名字空间中的<features/>元素中。如果在使用任何验证机制之前需要使用TLS（见第五章），接收实体不能（MUST NOT）在TLS握手之前提供可用的SASL验证机制清单。如果初始化实体在优先的TLS协商过程中呈现了一个合法的证书，接收实体应该（SHOULD）在SASL握手中提出一个SASL外部机制给初始化实体，尽管这个外部机制可以（MAY）在其它环境下提供。
3. 初始化实体发送一个符合'urn:ietf:params:xml:ns:xmpp-sasl'名字空间的<auth/>元素（其中包含了适当的'mechanism'属性值）给接收实体，以选择一个机制。如果这个机制支持或需要，这个元素可以（MAY）包含XML字符数据（在SASL术语中，即“初始化应答”）；如果初始化实体需要发送一个零字节的初始化应答，它必须（MUST）传输一个单独的等号作为应答，这表示应答有效但不包含数据。
4. 如果必要，接收实体向初始化实体发送一个符合'urn:ietf:params:xml:ns:xmpp-sasl'名字空间的<challenge/>元素来发出挑战；这个元素可以（MAY）包含XML字符数据（必须按照初始化实体选择的SASL机制进行一致性运算）。
5. 初始化实体向接收实体发送符合'urn:ietf:params:xml:ns:xmpp-sasl'名字空间的<response/>元素作为应答；这个元素可以（MAY）包含XML字符数据（必须按照初始化实体选择的SASL机制进行一致性运算）。
6. 如果必要，接收实体发送更多的挑战给初始化实体，初始化实体发送更多的回应。

这一系列的 挑战/应答 组，持续进行直到发生以下三件事中的一件为止：

1. 初始化实体向接收实体发送符合'urn:ietf:params:xml:ns:xmpp-sasl'名字空间的<abort/>元素以中止握手。在接收到<abort/>元素之后，接收实体应该（SHOULD）允许一个可配置的但是合理的重试次数（至少2次），然后它必须（MUST）终止TCP连接；这使得初始化实体（如一个最终用户客户端）能够容忍可能不正确的credentials（如密码输入错误）而不用强制重新连接。
2. 接收实体向初始化实体发送符合'urn:ietf:params:xml:ns:xmpp-sasl'名字空间的<failure/>元素以报告握手失败（详细的失败原因应该在<failure/>的一个适当的子元素中沟通，在第六章第四节中的SASL Errors中定义）。如果失败的情况发生了，接收实体应该（SHOULD）允许一个可配置的但是合理的重试次数（至少2次）， 然后它必须（MUST）终止TCP连接；这使得初始化实体（如一个最终用户客户端）能够容忍可能不正确的credentials（如密码输入错误）而不用强制重新连接。
3. 接收实体向初始化实体发送符合'urn:ietf:params:xml:ns:xmpp-sasl'名字空间的<success/>元素以报告握手成功；如果所选择的SASL机制要求，这个元素可以（MAY）包含XML字符数据（见SASL术语,“成功的额外数据”）。接收到<success/> 元素之后，初始化实体必须（MUST）发送一个打开的XML流头信息给接收实体以发起一个新的的流（不需要先发送一个 </stream>标签，因为在发送和接收到<success/>元素之后，接收实体和初始化实体必须确认原来的流被关闭了）。从初始化实体接收到新的流头信息之后，接收实体必须（MUST）发送一个新的流头信息给初始化实体作为回应，附上任何可用的特性（但不包括 STARTTLS 和 SASL 特性）或一个空的 <features/> 元素（这表示没有更多的特性可用）；任何没有在本文定义的附加特性必须（MUST）在XMPP的相关扩展中定义。

--------------------------------------------------------------------------------
6.3. SASL 定义
[SASL]的必要条件要求通过协议定义来提供以下信息:

service name（服务名）: "xmpp"

initiation sequence（开始序列）: 当初始化实体提供一个打开的XML流头信息并且接收实体善意回应之后，接收实体提供一个可接受的验证方法清单。初始化实体从这个清单中选择一个方法，把它作为 <auth/> 元素的 'mechanism' 属性的值发送给接收实体，也可以选择发送一个初始化应答以避免循环。

exchange sequence（交换序列）: 挑战和回应的交换，从接收实体发送给初始化实体的 <challenge/> 元素和从初始化实体发送给接收实体的 <response/> 元素信息。接收实体通过发送 <failure/>元素报告失败，发送<success/>元素报告成功；初始化实体通过发送<abort/> 元素中止交换。成功的协商之后，两边都认为原来的XML流已经关闭并且都开始发送新的流头信息。

security layer negotiation（安全层协商）: 安全层在接收实体发送 <success/> 元素的关闭字符">"之后立刻生效，在初始化实体发送 <success/> 元素的关闭字符">"之后也立刻生效。层的顺序是 [TCP]，[TLS]，然后是 [SASL]，然后是 [XMPP]。

use of the authorization identity（授权ID的使用）: 授权ID可在xmpp中用于表示一个客户端的非缺省的<node@domain>，或一个服务器的<domain> 。

--------------------------------------------------------------------------------
6.4. SASL 错误
SASL相关的错误条件定义如下:

• <aborted/> -- 接收实体认可由初始化实体发送的<abort/>元素；在回应一个<abort/>元素时发送。
• <incorrect-encoding/> -- 由初始化实体提供的数据无法处理，因为[BASE64]编码不正确（例如，因为编码不符合[BASE64]的第三章）; 在回应一个包含初始化响应数据的<response/> 元素或<auth/>元素时发送.
• <invalid-authzid/> -- 由初始化实体提供的授权id是非法的，因为它的格式不正确或初始化实体无权给那个ID授权；在回应一个包含初始化响应数据的<response/> 元素或<auth/>元素时发送。
• <invalid-mechanism/> -- 初始化实体不能提供一个机制活、或请求一个不被接受实体支持的机制；在回应一个<auth/>元素时发送。
• <mechanism-too-weak/> -- 初始化实体请求的机制比服务器策略对它的要求弱；在回应一个包含初始化响应数据的<response/> 元素或<auth/>元素时发送。
• <not-authorized/> -- 验证失败，因为初始化实体没有提供合法的credentials（这包括但不限于未知用户名等情形）；在回应一个包含初始化响应数据的<response/> 元素或<auth/>元素时发送。
• <temporary-auth-failure/> -- 验证失败，因为接收实体出现了临时的错误；在回应一个<response/> 元素或<auth/>元素时发送。

--------------------------------------------------------------------------------
6.5. 客户端-服务器 示例

以下例子展示了一个客户端和一个服务器使用SASL作验证的数据流，通常是在成功的TLS握手之后（注意：以下显示的替代步骤仅用于举例说明协议的失败情形；它们不够详尽也不需要由例子中的数据传送来触发）。

步骤 1: 客户端初始化流给服务器:

 

步骤 2: 服务器向客户端发送流标签作为应答:

 

步骤 3: 服务器通知客户端可用的验证机制:

步骤 4: 客户端选择一个验证机制:

步骤 5: 服务器发送一个 [BASE64] 编码的挑战给客户端:

解码后的挑战信息是:

步骤 5 (替代): 服务器返回一个错误给客户端:

步骤 6: 客户端发送一个[BASE64]编码的回应这个挑战: 

解码后的回应信息是:

步骤 7: 服务器发送另一个[BASE64]编码的挑战给客户端:

解码后的挑战信息是:

步骤 7 (或者): 服务器返回一个错误给客户端:

步骤 8: 客户端应答这个挑战:

步骤 9: 服务器通知客户端验证成功:

步骤 9 (或者): 服务器通知客户端验证失败:

步骤 10: 客户端发起一个新的流给服务器: 

步骤 11: 服务器发送一个流头信息回应客户端,并附上任何可用的特性(或空的features元素):

--------------------------------------------------------------------------------
6.6. 服务器-服务器 示例

以下例子展示了一个服务器和另一个服务器使用SASL作验证的数据流，通常是在成功的TLS握手之后（注意：以下显示的替代步骤仅用于举例说明协议的失败情形；它们不够详尽也不需要由例子中的数据传送来触发）。

步骤 1: 服务器1 发起一个流给 服务器2 :

步骤 2: 服务器2 回应一个流标签给 服务器1:

步骤 3: 服务器2 通知 服务器1 可用的验证机制:

步骤 4: 服务器1 选择一个验证机制:

步骤 5: 服务器2 发送一个[BASE64]编码的挑战给 服务器1:

解码后的挑战信息是:

 

步骤 5 (替代): 服务器2 返回一个错误给 服务器1:

步骤 6: 服务器1 发送一个[BASE64]编码的回应这个挑战: 

解码后的应答信息是:

步骤 7: 服务器2 发送另外一个[BASE64]编码的挑战给 服务器1:

解码后的挑战信息是:

步骤 7 (或者): 服务器2 返回一个错误给 服务器1:

步骤 8: 服务器1 回应挑战:

步骤 8 (或者): 服务器1 中止协商:

步骤 9: 服务器2 通知 服务器1 验证成功:

步骤 9 (或者): 服务器2 通知 服务器1 验证失败:

步骤 10: 服务器1 重新发起一个新的流给 服务器2: 

 

Step 11: 服务器2 发送一个流头信息应答 服务器1 ,并附上任何可用的特性(或一个空的features元素).:

 

 

 

RFC3920 XMPP Core--Use of TLS