TLS

概览

　　XMPP包含的一个保证流安全的方法（传输层安全协议[TLS]的频道加密方法）来防止篡改和偷听.

　　一个给定域的管理员可以要求客户端和服务器通信以及服务器之间通信时使用TLS，或者两者都要求。客户端应该在尝试完成 SASL握手之前使用 TLS，服务器应该在两个域之间使用 TLS 以保证服务器间通信的安全。

使用规则:

1. 一个遵守本协议的初始化实体必须在初始化流的头信息中包含一个'version'属性并把值设为“1.0”。
2. 如果TLS握手发生在两个服务器之间，除非服务器声称的DNS主机名已经被解析，通信不能继续进行。
3. 当一个遵守本协议的接收实体接收了一个初始化流（它的头信息中包含一个'version'属性并且值设为“1.0”），在发送应答流的的头信息（其中包含版本标记）之后，它必须发送<starttls/>元素（名字空间为 'urn:ietf:params:xml:ns:xmpp-tls'）以及其他它支持的流特性 。
4. 如果初始化实体选择使用TLS,TLS握手必须在SASL握手之前完成；这个顺序用于帮助保护SASL握手时发送的认证信息的安全，同时可以在必要的时候在TLS握手之前为SASL外部机制提供证书。
5. TLS握手期间,一个实体不能在流的根元素中发送任何空格符号作为元素的分隔符（在下面的TLS示例中的任何空格符都仅仅是为了便于阅读）；这个禁令用来帮助确保安全层字节精度。
6. 接收实体必须（MUST）在发送<PRoceed/> 元素的关闭符号">" 之后立刻开始TLS协商。初始化实体必须（MUST）在从接收实体接收到<proceed/> 元素的关闭符号">" 之后立刻开始TLS协商。
7. 初始化实体必须验证接收实体出示的证书.
8. 证书必须检查初始化实体(比如一个用户)提供的主机名；而不是通过DNS系统解析出来的主机名；例如，如果用户指定一个主机名"example.com"而一个DNS SRV [SRV]查询返回"im.example.com"，证书必须检查"example.com".如果任何种类的XMPP实体（例如客户端或服务器）的JID出现在一个证书里，它必须表现为一个别名实体里面的UTF8字符串，存在于subjectAltName之中。如何使用 [ASN.1] 对象标识符 "id-on-xmppAddr" 定义在本文的第五章第一节第一小节。
9. 如果 TLS 握手成功了，接收实体必须丢弃TLS 生效之前从初始化实体得到的任何不可靠的信息.
10. 如果 TLS 握手成功了，初始化实体必须丢弃TLS 生效之前从接收实体得到的任何不可靠的信息. 
11. 如果 TLS 握手成功了，接收实体不能在流重新开始的时候通过提供其他的流特性来向初始化实体提供 STARTTLS 扩展.
12. 如果 TLS 握手成功了，初始化实体必须继续进行SASL握手。
13. 如果 TLS 握手失败了，接收实体必须终止XML流和相应的TCP连接。

简要描述

　　当一个初始化实体用TLS保护一个和接收实体之间的流，其步骤如下:

1. 初始化实体打开一个TCP连接，发送一个打开的XML流头信息（其'version'属性设置为"1.0"）给接收实体以初始化一个流。
2. 接收实体打开一个TCP连接，发送一个XML流头信息（其'version'属性设置为"1.0"）给初始化实体作为应答。
3. 接收实体向初始化实体提议STARTTLS范围（包括其他支持的流特性），如果TLS对于和接收实体交互是必需的，它应该（SHOULD）在<starttls/>元素中包含子元素<required/>.
4. 初始化实体发出STARTTLS命令(例如, 一个符合'urn:ietf:params:xml:ns:xmpp-tls'名字空间的 <starttls/> 元素) 以通知接收实体它希望开始一个TLS握手来保护流。
5. 接收实体必须（MUST）以'urn:ietf:params:xml:ns:xmpp-tls'名字空间中的<proceed/>元素或<failure/>元素应答。如果失败，接收实体必须（MUST）终止XML流和相应的TCP连接。如果继续进行，接收实体必须（MUST）尝试通过TCP连接完成TLS握手并且在TLS握手完成之前不能（MUST NOT）发送任何其他XML数据。
6. 初始化实体和接收实体尝试完成TLS握手。（要符合[TLS]规范）
7. 如果 TLS 握手不成功, 接收实体必须（MUST）终止 TCP 连接. 如果 TLS 握手成功, 初始化实体必须（MUST）发送给接收实体一个打开的XML流头信息来初始化一个新的流（先发送一个关闭标签</stream>是不必要的,因为接收实体和初始化实体必须(MUST)确保原来的流在TLS握手成功之后被关闭） 。
8. 在从初始化实体收到新的流头信息之后，接收实体必须（MUST）发送一个新的XML流头信息给初始化实体作为应答，其中应包含可用的特性但不包含STATRTTLS特性。

具体步骤（客户端－服务器）

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

<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' to='example.com' version='1.0'>

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

<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='c2s_123' from='example.com' version='1.0'>

　　步骤3:服务器发送 STARTTLS 范围给客户端（包括验证机制和任何其他流特性）

<stream:features>
     <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
       <required/>
     </starttls>
     <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
       <mechanism>DIGEST-md5</mechanism>
       <mechanism>PLAIN</mechanism>
     </mechanisms>
</stream:features>

　　 步骤4:客户端发送 STARTTLS 命令给服务器

<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>

　　步骤5:服务器通知客户端可以继续进行

<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>

　　步骤 5 (或者): 服务器通知客户端 TLS 握手失败并关闭流和TCP连接

<failure xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
</stream:stream>

　　步骤 6: 客户端和服务器尝试通过已有的TCP连接完成 TLS 握手.

　　步骤 7: 如果 TLS 握手成功, 客户端初始化一个新的流给服务器

<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' from='example.com' id='c2s_234' version='1.0'>
   <stream:features>
     <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
       <mechanism>DIGEST-MD5</mechanism>
       <mechanism>PLAIN</mechanism>
       <mechanism>EXTERNAL</mechanism>
     </mechanisms>
</stream:features>

　　步骤 9: 客户端继续 SASL 握手

具体步骤（服务器－服务器）

　　步骤1:Server1 初始化流给 Server2

<stream:stream xmlns='jabber:server' xmlns:stream='http://etherx.jabber.org/streams' to='example.com' version='1.0'>

　　步骤2:Server2 发送一个流标签给 Server1 作为应答

<stream:stream xmlns='jabber:server' xmlns:stream='http://etherx.jabber.org/streams' from='example.com' id='s2s_123' version='1.0'>

　　步骤3:Server2 发送 STARTTLS 范围给 Server1 ，包括验证机制和任何其他流特性

<stream:features>
     <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
       <required/>
     </starttls>
     <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
       <mechanism>DIGEST-MD5</mechanism>
       <mechanism>KERBEROS_V4</mechanism>
     </mechanisms>
</stream:features>

　　步骤 4: Server1 发送 STARTTLS 命令给 Server2

<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>

　　步骤5:Server2 通知 Server1 允许继续进行

<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>

　　步骤 6: Server1 和 Server2 尝试通过 TCP 完成 TLS 握手.

　　步骤 7: 如果 TLS 握手成功, Server1 初始化一个新的流给 Server2

<stream:stream xmlns='jabber:server' xmlns:stream='http://etherx.jabber.org/streams' to='example.com' version='1.0'>

　　步骤7（或者）: 如果 TLS 握手不成功, Server2 关闭 TCP 连接.

　　步骤8 : Server2 发送一个包含任何可用流特性的流头信息给 Server1 

<stream:stream xmlns='jabber:server' xmlns:stream='http://etherx.jabber.org/streams' from='example.com' id='s2s_234' version='1.0'>
   <stream:features>
     <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
       <mechanism>DIGEST-MD5</mechanism>
       <mechanism>KERBEROS_V4</mechanism>
       <mechanism>EXTERNAL</mechanism>
     </mechanisms>
</stream:features>

　　步骤9:Server1 继续进行 SASL 握手

SASL

概览

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

以下规则应用于:

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

简要描述

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

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

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

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

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/>元素时发送。

具体步骤（客户端－服务器）

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

<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' to='example.com' version='1.0'>

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

<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='c2s_234' from='example.com' version='1.0'>

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

 <stream:features>
     <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
       <mechanism>DIGEST-MD5</mechanism>
       <mechanism>PLAIN</mechanism>
     </mechanisms>
</stream:features>

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

<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='DIGEST-MD5'/>

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

<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
　　cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg==
</challenge>

　　解码后的挑战信息是: 

  realm="somerealm",nonce="OA6MG9tEQGm2hh",\
  qop="auth",charset=utf-8,algorithm=md5-sess

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

<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
     <incorrect-encoding/>
</failure>
</stream:stream>

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

<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
   dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i
   T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw
   MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i
   LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo
   YXJzZXQ9dXRmLTgK
</response>

　　解码后的回应信息是

   username="somenode",realm="somerealm",\
   nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\
   nc=00000001,qop=auth,digest-uri="xmpp/example.com",\
   response=d388dad90d4bbd760a152321f2143af7,charset=utf-8

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

<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
   cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo=
</challenge>

　　解码后的挑战信息是:

rspauth=ea40f60335c427b5527b84dbabcdfffd

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

<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
     <temporary-auth-failure/>
   </failure>
</stream:stream>

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

<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>

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

<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>

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

<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
     <temporary-auth-failure/>
   </failure>
</stream:stream>

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

<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' to='example.com' version='1.0'>

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

<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='c2s_345' from='example.com' version='1.0'>
   <stream:features>
     <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
     <session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
</stream:features>

具体步骤（服务器－服务器）

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

<stream:stream xmlns='jabber:server' xmlns:stream='http://etherx.jabber.org/streams' to='example.com' version='1.0'>

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

<stream:stream xmlns='jabber:server' xmlns:stream='http://etherx.jabber.org/streams' from='example.com' id='s2s_234' version='1.0'>

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

<stream:features>
     <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
       <mechanism>DIGEST-MD5</mechanism>
       <mechanism>KERBEROS_V4</mechanism>
     </mechanisms>
</stream:features>

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

<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='DIGEST-MD5'/>

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

 <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
   cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9
   ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz
</challenge>

　　解码后的挑战信息是

realm="somerealm",nonce="OA6MG9tEQGm2hh",\
qop="auth",charset=utf-8,algorithm=md5-sess

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

 <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
     <incorrect-encoding/>
   </failure>
</stream:stream>

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

<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
   dXNlcm5hbWU9ImV4YW1wbGUub3JnIixyZWFsbT0ic29tZXJlYWxtIixub25j
   ZT0iT0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5j
   PTAwMDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5v
   cmciLHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3
   LGNoYXJzZXQ9dXRmLTgK
</response>

　　解码后的应答信息是

   username="example.org",realm="somerealm",\
   nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\
   nc=00000001,qop=auth,digest-uri="xmpp/example.org",\
   response=d388dad90d4bbd760a152321f2143af7,charset=utf-8

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

<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
   cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo=
</challenge>

　　解码后的挑战信息是

rspauth=ea40f60335c427b5527b84dbabcdfffd

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

<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
     <invalid-authzid/>
   </failure>
</stream:stream>

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

 <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>

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

 <abort xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>

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

<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>

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

<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
     <aborted/>
   </failure>
</stream:stream>

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

<stream:stream xmlns='jabber:server' xmlns:stream='http://etherx.jabber.org/streams' to='example.com' version='1.0'>

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

<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' from='example.com' id='s2s_345' version='1.0'>
<stream:features/>