RFC3920可扩展消息出席协议（XMPP）：核心 8 服务器回叫

最新推荐文章于 2024-11-11 00:11:39 发布

enfeeling

最新推荐文章于 2024-11-11 00:11:39 发布

阅读量744

点赞数

文章标签：服务器 xmpp 扩展 stream server xml

8．服务器回叫

8．1概述
        Jabber协议来自于XMPP适用的，包含一个“服务器回叫”方法，用以保护免受域哄骗，因此，使哄骗XML节更困难。服务器回叫并不是一个安全机制，并且仅导致服务器身份弱验证（参考服务器到服务器的通信（14.4）相关方法的安全特性）。域需要健壮的安全性，应当使用TLS与SASL；参考服务器到服务器通信（4.4）细节。如果SASL用于服务器到服务器的认证，回叫不应当使用，因为它是不必要的。包含回叫文档主要是出于与现存实现与部署向后兼容的原因。

        服务器回叫方法因域名系统（DNS）存在而成为可能，由于一个服务器能够（正常的）对一个给定域发现授权服务器。因为回叫依靠DNS，域内通信不准处理，直到由服务器宣称的域名系统（DNS）的主机名被解析（参考服务器到服务器的通信（14.4））。

        服务器回叫是单向的，导致一个方向上一个流身份的（弱）验证。因为服务器回叫不是一个认证机制，通过回叫是不可能进行双向认证的。因此，服务器回叫必须在每个方向上完成，为了使在两个域间进行双向通信成为可能。

        产生与验证密钥的方法用于服务器回叫，必须考虑被用的主机名，由接收服务器产生的流ID，和由授权服务器的网络秘密知道。流ID在服务器回叫中是严格安全的，并且因此必须是即不可预测也不可重复的（参考[RANDOM]推荐资料相关用于安全观点的随机性。）

        任何在回叫协商期间发生的错误必须考虑一个流错误，导致终止流与潜在的TCP连接。协议描述中说明的可能的错误条件如下。

        以下术语应用：
1）源服务器——试图在两个域间建立连接的服务器。
2）接收服务器——尝试认证源服务器是否按它声明的那样去表达。
3）授权服务器——回答由源服务器宣称的DNS主机名；对基本环境来说是源服务器，但在源服务器网络中可以是一个分离的机器。

8．2事件顺序
        以下是回叫事件顺序的简单总结：
1）源服务器建立到接收服务器的连接。
2）源服务器通过连接，给接收服务器发送‘key’值。
3）接收服务器建立到认证服务器的连接。
4）接收服务器向授权服务器发送相同的‘key’值。
5）授权服务器回答密钥值是否有效。
6）接收服务器通知源服务器授权是否通过。

        我们可以将事件顺序以下图表示：
   Originating               Receiving
     Server                    Server
   -----------               ---------
       |                         |
       |   establish connection |
       | ----------------------> |
       |                         |
       |   send stream header    |
       | ----------------------> |
       |                         |
       |   send stream header    |
       | <---------------------- |
       |                         |                   Authoritative
       |   send dialback key     |                       Server
       | ----------------------> |                   -------------
       |                         |                         |
                                 |   establish connection |
                                 | ----------------------> |
                                 |                         |
                                 |   send stream header    |
                                 | ----------------------> |
                                 |                         |
                                 |   send stream header    |
                                 | <---------------------- |
                                 |                         |
                                 |   send verify request   |
                                 | ----------------------> |
                                 |                         |
                                 |   send verify response |
                                 | <---------------------- |
                                 |
       | report dialback result |
       | <---------------------- |
       |                         |

8．3协议
        服务器间具体协议交互如下：
1）源服务器建立TCP连接到接收服务器。
2）源服务器发送流头给接收服务器：
   <stream:stream
       xmlns:stream='http://etherx.jabber.org/streams'
       xmlns='jabber:server'
       xmlns:db='jabber:server:dialback'>
      注：‘to’与‘from’属性在根流元素中是可选的。包含xmlns:db命名空间声明，名字显示向接收实体指示源服务器支持回叫。如果命名空间名不正确，那么，接收服务器必须产生一个<invalid-namespace/>流错误条件并终止XML流与TCP连接。
3）接收服务器应当发送一个流头返回给源服务器，包含一个用于交互的唯一的ID：
   <stream:stream
       xmlns:stream='http://etherx.jabber.org/streams'
       xmlns='jabber:server'
       xmlns:db='jabber:server:dialback'
       id='457F9224A0...'>
      注：‘to’与‘from’属性在根流元素中是可选的。如果命名空间名不正确，那么源服务器必须产生一个<invalid-namespace/>流错误条件，并终止XML流与TCP连接。而且，接收服务器应当回应，但可能根据适当的安全策略默默终止XML流与TCP连接。然而，如果接收服务器想要处理，它必须发送一个流头返回给源服务器。
4）源服务器发送一个回叫密钥给接收服务器：
   <db:result
       to='Receiving Server'
       from='Originating Server'>
     98AF014EDC0...
   </db:result>
      注：此密钥并不被接收服务器所检查，因为接收服务器并不保存相关源服务器间会话信息。由源服务器产生的密钥必须部分基于接收服务器在先前步骤提供的ID值，并部分基于源服务器与授权服务器的保密共享。如果‘to’地址值并不与接收服务器所识别的主机名匹配，那么，接收服务器必须产生一个<host-unknown/>流错误条件并终止XML流与潜在的TCP连接。如果‘from’地址值与带有接收服务器已经建立的连接的域匹配，那么，接收服务器可能选择为新连接产生一个<not-authorized/>流错误条件，然后终止XML流与潜在的与新请求相关的TCP连接。
5）接收服务器建立一个TCP连接支持由源服务器宣称的域，作为它连接到授权服务器的结果。（注意：作为优化，一个实现可能重用一个现存的连接。）
6）接收服务器发送给授权服务器一个流头：
   <stream:stream
       xmlns:stream='http://etherx.jabber.org/streams'
       xmlns='jabber:server'
       xmlns:db='jabber:server:dialback'>
注：在根流元素中，‘to’与‘from’属性是可选的。如果命名空间名不正确，则授权服务器必须产生一个<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连接。如果流错误发生在接收服务器与授权服务器间，则接收服务器必须产生一个<remote-connection-failed/>流错误条件并终止它与发起服务器间的两个XML流与潜在的TCP连接。
8）接收服务器发给授权服务器要求认证密钥的请求：
   <db:verify
       from='Receiving Server'
       to='Originating Server'
       id='457F9224A0...'>
     98AF014EDC0...
   </db:verify>
      注：经过这儿的是来自接收服务器的流头的主机名、源标识符，到步骤3中的发起服务器，源服务器发送给接收服务器的密钥在步骤4。根据这些信息，还有授权服务器网络中的共享密钥信息，密钥被验证。任何验证方法可能用于产生密钥。如果‘to’地址值与授权服务器识别的主机名不匹配，那么，授权服务器必须产生一个<host-unknown/>流错误条件并终止两个XML与潜在的TCP连接。如果‘from’地址值与源服务器打开TCP连接时（或任意相关有效域，例如接收服务器的主机名或其它有效域一个有效子域）所表示的主机名不匹配，则授权服务器必须产生一个<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与步骤3中的接收服务器不匹配，那么接收服务器必须产生一个<invalid-id/>流错误条件并终止两个XML流与潜在的TCP连接。如果‘to’地址值与接收服务器所识别的主机名不匹配，则接收服务器必须产生一个<host-unknown/>流错误条件并终止两个XML流与潜在的TXP连接。如果‘from’地址值与源服务器打开TCP连接时（或任意相关有效域，例如接收服务器的主机名或其它有效域一个有效子域）所表示的主机名不匹配，则接收服务器必须产生一个<invalid-from/>流错误条件并终止两个XML流与潜在的TCP连接。返回认证信息给接收服务器之后，授权服务器应当终止他们之间的流。
10）接收服务器通知源服务器结果：
   <db:result
       from='Receiving Server'
       to='Originating Server'
type='valid'/>
      注：在这里，连接可通过一个type='valid'或报告为无效来被认证。如果连接无效，则接收服务器必须终止两个XML流与潜在的TCP连接。如果连接被认证，数据可被源服务器发送并被接收服务器读取；在此这前，所有发送给接收服务器的XML节应该默默被扔掉。

      前述结果是接收服务器已经认证了源服务器的身份，为了节通过“初始流”（如，从源服务器到接收服务器的流）的XML能被源服务器发送与接收服务器能接收，为了验证使用“响应流”（如，从接收服务器到源服务器）实体的身份，回叫必须以相反方向完成。

      成功回叫协调后，接收服务器应当接收来自通过现存已认证连接的源服务器的子序列<db:result/>包（例如，认证需求发送到子域或其它由接收服务器服务主机名）；这使在一个方向上的原来的已认证连接的"piggybacking"成为可能。

      即使回叫协调成功，服务器必须认证从其它服务器接收的XML节，包括‘from’属性与‘to’属性；如果一个节并不满足此限制，接收节的服务器必须产生一个<improper-addressing/>流错误条件并终止两个XML流与潜在的TCP连接。进一步讲，服务器必须认证从其它服务器，包括流的一个已验证域的‘from’属性；如果节并不满足此限制，收到节的服务器必须产生一个<invalid-from/>流错误条件并终止两个XML流与潜在的TCP连接。这两个检查有助于阻止关联到特别节的哄骗。