XMPP--服务器回拨

Jabber协议接受的来自XMPP的包括“服务器回拨”方法，用于防治域名欺骗，使得欺骗XML节更为困难。服务器回拨不是一个安全机制，并且它的服务器身份认证结果很弱（参见服务器之间的通信（第十四章第四节）中关于这个方法的安全特性）。需要健壮的安全性的域名应该（SHOULD）使用TLS或SASL；细节参见服务器间的通信（第十四章第四节）。如果SASL用于服务器间通信，回拨就不需要用了（SHOULD NOT）。本文描述回拨的好处在于向后兼容现存的实现和部署。
服务器回拨方法由现存的DNS系统的存在而成为可能，因为一个服务器（通常）可以查询给定域的授权服务器。由于服务器回拨依赖于DNS，除非服务器宣称的DNS主机得到解析，域之间的通信无法进行（参见服务器间的通信（第十四章第四节））。
服务器回拨是单向性的，可在单一方向上对一个流进行（微弱的）身份验证．因为服务器回拨不是一个验证机制，通过回拨获得相互的认证是不可能的．因此，为了使得服务器之间的双向通信，服务器回拨必须（MUST）在每个方向上完成。
在服务器回拨中生成和检验密钥的方法必须（MUST）考虑计算被使用的主机名，由接收服务器生成的流ID，和只有授权服务器网络才知道的秘密。在服务器回拨中流ID是安全性的关键所以必须（MUST）是不可预知的和不可重复的（见\[RANDOM\]中关于使用随机数获得安全性的建议）．
任何回拨协商过程中发生的错误必须（MUST）被当成一个流错误，并导致流以及相关的TCP连接的终止．可能发生的错误情况协议中描述如下.
以下术语适用:
发起服务器 -- 尝试在两个域之间建立连接的那个服务器．
接收服务器 -- 尝试验证发起服务期声称的域名的那台服务器．
授权（权威？Authoritative） 服务器 -- 回答发起服务器声称的DNS主机名的服务器；基本上这应该是那台发起服务器，但是它也可能是一个在发起服务器网络中独立的服务器。

事件顺序

以下是回拨中的事件顺序的简介:
发起服务器和接收服务器建立一个连接。
发起服务器通过到连接发送一个 'key' 值给接收服务期。
接收服务器建立一个连接到授权服务器。
接收服务器发送一个相同的 'key' 值给授权服务器。
授权服务器回答这个key是否合法。
接收服务器通知发起服务器是否被验证通过。
我们用用以下图形展示这个事件流程(见附件s2s.png):
{image:img=s2s}

协议

服务器之间互动的细节协议如下:
1. 发起服务器和接受服务器建立TCP连接.
2. 发起服务器发送流头信息给接收服务器:
   <stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:server' xmlns:db='jabber:server:dialback'>
注意: 'to'和'from'属性在流的根元素是可选的(OPTIONAL). 其中包含的xmlns:db名字空间向接收服务器声明了发起服务器支持回拨. 如果名字空间不正确，接收实体必须（MUST）生成一个<invalid-namespace/>流错误条件并且终止XML流和相应的TCP连接.
3. 接收服务器应该（SHOULD）回送一个流头信息给发起服务器，为这次交互生成一个唯一性的ID :
   <stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:server' xmlns:db='jabber:server:dialback' id='457F9224A0...'>
注意: 'to'和'from'属性在流的根元素是可选的(OPTIONAL). 如果名字空间不正确，发起服务器必须生成一个<invalid-namespace/>流错误条件并且终止XML流和相应的TCP连接.也要注意，在这里接收服务器应该（SHOULD）应答但是可以(MAY)出于安全策略考虑只是悄悄地终止XML流和TCP连接；无论如何，如果接收服务器希望继续，它必须（MUST）回送一个流头信息给发起服务器.
4. 发起服务器发送一个回拨密钥给接收服务器:
   <db:result to='Receiving Server' from='Originating Server'>
     98AF014EDC0...
   </db:result>
注意: 这个密钥不由接收服务器检查，因为接收服务器在会话之间（between sessions）不保存发起服务器的信息. 这个由发起服务器生成的密钥必须（MUST）是基于接收服务器在上一步骤中提供的ID值，以及发起服务器与授权服务器共享的安全机制生成的。 如果 'to' 地址的值和接收服务器知道的主机名不匹配，接收服务器必须（MUST）生成一个<host-unknown/>流错误条件并且终止XML流和相应的TCP连接. 如果 'from' 地址和接收服务器已经建立的连接的域名相吻合,接收服务器必须(MUST)维护这个已经存在的连接,直到证明这个新的连接是合法的为止;另外,接收实体可以(MAY)选择生成一个<not- authorized/> 流错误条件给这个新的连接并且终止和新连接申请相关的XML流及相应的TCP连接.
5. 接收服务器向发起服务器声明的那个域建立一个 TCP 连接,作为结果它连接到授权服务器. (注意: 为了优化性能, 在这里一个实现可以(MAY)重用现有的连接.)
6. 接收服务器发送一个流头信息给授权服务器:
   <stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:server' xmlns:db='jabber:server:dialback'>
注意: 'to'和'from'属性在流的根元素是可选的(OPTIONAL). 如果名字空间不正确，授权服务器必须生成一个<invalid-namespace/>流错误条件并且终止XML流和相应的TCP连接.
7. 授权服务器发送流头信息给接收服务器:
   <stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:server' xmlns:db='jabber:server:dialback' id='1251A342B...'>
注意: 如果名字空间不正确，接收服务器必须生成一个<invalid-namespace/>流错误条件并且终止它和授权服务器之间的XML流和相应的TCP连接. 如果一个流错误发生在接收服务器和 授权服务器 之间,接收服务器必须(MUST)生成一个 <remote-connection- failed/> 流错误条件并且终止它和 发起服务器 之间的XML流和相应的TCP连接.
8. 接收服务器发送一个密钥检查请求给授权服务器:
   <db:verify from='Receiving Server' to='Originating Server' id='457F9224A0...'>
     98AF014EDC0...
   </db:verify>
注意: 现在这里已经有了主机名,第三步中接收服务器发送给发起服务器的原始，第四步中发起服务器发送给接收服务器的密钥. 基于这些信息, 加上授权服务器网络共享的安全信息, 这个密钥被证实了.任何可用于验证的办法都可以（MAY）用于生成密钥. 如果 'to' 地址的值和授权服务器知道的主机名不匹配，授权服务器必须（MUST）生成一个<host-unknown/>流错误条件并且终止XML流和相应的TCP连接. 打开这个连接时，如果 'from' 地址和接收服务器声明的主机名（或任何合法的域，如验证过的接收服务器的子域名或寄宿在接收服务器上的其他经过验证的域）不符,授权服务器必须(MUST)生成一个<invalid-from/>流错误条件并且终止XML流和相应的TCP连接.
9. 授权服务器检查密钥是否合法:
   <db:verify from='Originating Server' to='Receiving Server' type='valid' id='457F9224A0...'/>
或
   <db:verify from='Originating Server' to='Receiving Server' type='invalid' id='457F9224A0...'/>
注意: 如果 ID 和第三步中接收服务器提供的不符，接收服务器必须（MUST）生成一个<invalid-id/>流错误条件并且终止XML流和相应的TCP连接. 如果 'to' 地址的值和接收服务器知道的主机名不匹配，接收服务器必须（MUST）生成一个<host-unknown/>流错误条件并且终止XML流和相应的TCP连接. 打开这个连接时，如果 'from' 地址和发起服务器声明的主机名（或任何合法的域，如验证过的发起服务器的子域名或寄宿在发起服务器上的其他经过验证的域）不符,接收服务器必须(MUST)生成一个<invalid-from/>流错误条件并且终止XML流和相应的TCP连接. 在返回验证信息给接收服务器之后，授权服务器应该（SHOULD）终止它们之间的流.
10. 接收服务器通知发起服务器结果:
   <db:result from='Receiving Server'to='Originating Server' type='valid'/>
注意: 在这一个点上, 连接已经由 type='valid' 确认验证是通过了，还是没通过. 如果连接是非法的，接收服务器必须（MUST）终止XML流和相应的TCP连接. 如果连接是合法的, 数据可以从发起服务器发送由接收服务器读取；在此之前，所有发送给接收服务器的XML节应该（SHOULD）被丢弃.
进一步的结果是，接收服务器已经验证了发起服务器的ID，所以通过初始化流("initial stream"，例如从发起服务器到接收服务器的流)发起服务器可以发送，接收服务器可以接受XML节. 为了使用应答流（"response stream"，例如从接收服务器到发起服务器的流）验证实体ID，回拨必须（MUST）在相对的两个方向上都完成.
在成功的回拨协商之后, 接收服务器应该（SHOULD）接受接下来发起服务器通过当前的合法连接发送的 <db:result/> 包 (例如, 发送给子域或其他寄宿在接收服务器上的主机名的验证请求); 这在单一方向上激活了原始合法连接的 "piggybacking" .
即使回拨协商成功了, 服务器仍然必须（MUST）检查从其他服务器接收的所有XML节的'from'和'to'属性; 如果一个节不符合这些限定, 收到这些节的服务器必须（MUST）生成一个<improper-addressing/> 流错误条件并终止XML流和相应的TCP连接. 而且, 一个服务器也必须(MUST)检查从其他的有合法域名的服务器的流中收到的节的'from'属性; 如果一个节不符合这一限定, 接收节的服务器必须(MUST)生成一个 <invalid-from/> 流错误条件并终止XML流和相应的TCP连接. 所有这些检查都用来帮助防止特定的节伪造行为.