XMPP翻译：RFC 3920[6]（Chapter8）

本篇翻译了XMPP核心协议RFC 3920的第八章。

内容提要：

Server Dialback //服务器回拨

Overview //概述
Order of Events //事件顺序
Protocol //协议

8.1. 概述

XMPP的来源，Jabber协议，包含一个“服务器回拨（dialback）”方法来防止域欺骗，使假冒XML节更加的困难。服务器回拨不是一个安全机制，且只导致了服务器身份认证的弱化（参见S/S的通信中有关这个方法的安全特性）。需要强安全性的域应该（SHOULD）使用TLS和SASL；详见S/S的通信。如果SASL用在了S/S的认证上，不应该（SHOULD NOT）使用回拨，因为这不需要。包含了回拨的文档主要是为了向后兼容已存在的实现和配置。

DNS的存在使得服务器回拨方法成为可能，因为服务器（通常）可以在给定的域发现可信的服务器。由于回拨依靠DNS，域内通信禁止（MUST NOT）进行直到决定了服务器声称的DNS主机名（参见S/S的通信）。

服务器回拨是单方向的，这导致了在一个方向上流的身份认证弱化。因为服务器回拨不是一个安全机制，也不可能通过回拨进行相互的认证。因此，必须（MUST）完成各个方向上的服务器回拨，为了在两域间双向通信。

用于生成和校验在服务器回拨中所使用的密钥的方法必须（MUST）考虑到所使用主机名，由接收实体产生的流ID以及可信的服务器网络所认知的一个secret。在服务器回拨中，流ID是与安全极其相关的，所以必须（MUST）是不可预知和不重复的。

回拨协商期间发生的任何错误必须（MUST）被当作流错误，且这使得流和underlying TCP连接终止。可能出现的错误因素在之后的协议描述中有详细说明。

下面术语的表意：

Originating Server -- 尝试在两个域间建立连接的服务器
Receiving Server -- 该服务器设法验证Originating Server是否呈现它所承认的域
Authoritative Server -- 响应了Originating Server所声称的DNS主机名的服务器；在基础的环境中可能会是Originating Server，但可能是Originating Server网络中单独的一台机器。

8.2. 事件顺序

下面是在回拨中事件顺序的主要摘要：

Originating Server与Receiving Server建立一个连接。
Originating Server通过该连接发送一个‘key’值到Receiving Server。
Receiving Server与Authoritative Server建立一个连接。
Receiving Server通过该连接发送一个‘key’值到Authoritative Server。
Authoritative Server回复key是否有效。
Receiving Server将是否认证告知Originating Server。

我们用图来描述这个事件流程，如下:

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. 协议

服务器间交互协议的详细描述如下:

Originating Server与Receiving Server建立TCP连接。
Originating Server发送一个stream header到Receiving Server：
```
<stream:stream
    xmlns:stream='http://etherx.jabber.org/streams'
    xmlns='jabber:server'
    xmlns:db='jabber:server:dialback'>
    
```
注意：流的根元素上的‘to’和‘from’属性是可选的。xmlns:db 命名空间声明所包含数据和该命名空间名向Receiving Server显示了Originating Server支持回拨。如果命名空间名不正确，Receiving Server必须（MUST）产生一个<invalid-namespace/>流错误，并且终止XML流和underlying TCP连接

Receiving Server应该（SHOULD）回发一个stream header给Originating Server，包含用于此次交互的唯一的ID：

<stream:stream
    xmlns:stream='http://etherx.jabber.org/streams'
    xmlns='jabber:server'
    xmlns:db='jabber:server:dialback'
    id='457F9224A0...'>
    注意：流的根元素上的‘to’和‘from’属性是可选的。如果命名空间名不正确，Originating Server必须（MUST）产生一个<invalid-namespace/>流错误，并且终止XML流和underlying TCP连接。注意到Receiving Server应该（SHOULD）回复，但它也可能（MAY）毫无动静的终止XML流和underlying TCP连接，这取决于各处的安全策略；然而如果Receiving Server希望继续，那么它就必须（MUST）回发一个stream header到Originating Server.

Originating Server发送一个回拨key到Receiving Server:：
```
<db:result
    to='Receiving Server'
    from='Originating Server'>
    98AF014EDC0...
    </db:result>
    
```
注意：Receiving Server不检查这个key，因为Receiving Server在会话期间不保存有关Originating Server的信息。Originating Server产生的这个key必须（MUST）部分基于上一步中Receiving Server提供的ID值，部分基于Originating Server与Authoritative Server共享的一个secret。如果‘to’地址值与Receiving Server承认的主机名不符, Receiving Server必须（MUST）生成一个<host-unknown/>流错误因素终止XML流和underlying TCP连接。如果‘from’地址值符合一个已经与Receiving Server建立连接的域，那么Receiving Server必须（MUST）维持已存在的连接知道它验证过新的连接是否合法；另外，Receiving Server可能选择为新的连接生成一个<not-authorized/>流错误因素并且终止与新请求相关的XML流和underlying TCP连接。
Receiving Server与Originating Server声称的域名回建一个TCP连接，然后连接到上了Authoritative Server。 (注意：优化考虑，实现中也可能（MAY）重用这里已存在的一个连接。）
Receiving Server向Authoritative Server发送一个stream header：
```
<stream:stream
    xmlns:stream='http://etherx.jabber.org/streams'
    xmlns='jabber:server'
    xmlns:db='jabber:server:dialback'>
    
```
注意：流的根元素上的‘to’和‘from’属性是可选的。如果命名空间名不正确，则Originating Server必须（MUST）产生一个<invalid-namespace/>流错误，并且终止XML流和underlying TCP连接。
Authoritative Server向Receiving Server发送一个stream header：
```
<stream:stream
    xmlns:stream='http://etherx.jabber.org/streams'
    xmlns='jabber:server'
    xmlns:db='jabber:server:dialback'
    id='1251A342B...'>
    
```
注意：如果命名空间名不正确，那么Receiving Server则必须（MUST）生成一个<invalid-namespace/>流错误因素并且终止它与Authoritative Server之间的XML流和underlying TCP连接。如果流错误发生在Receiving Server和Authoritative Server之间，那么Receiving Server则必须（MUST）生成一个<remote-connection-failed/>流错误因素并且终止它与Originating Server之间的XML流和underlying TCP连接。
Receiving Server向Authoritative Server发送一个确认key的请求：
```
<db:verify
    from='Receiving Server'
    to='Originating Server'
    id='457F9224A0...'>
    98AF014EDC0...
    </db:verify>
    
```
注意：这里流过的是主机名，此主机名是在第三步中从Receiving Server的stream header到Originating Server的初始标识符，而key则是第四步中Originating Server发给Receiving Server的。基于这个信息，连同Authoritative Server网络中共享的secret信息，key得到了验证。任何可检验的方法都可被用于生成key。如果‘to’地址的值与Authoritative Server承认的主机名不符，那Authoritative Server就必须（MUST）生成一个<host-unknown/>流错误因素终止XML流和underlying TCP连接。如果‘from’地址的值与在打开TCP连接时Receiving Server呈现的主机名不符（或者它的任何有效的域，例如Receiving Server主机名的一个有效的子域或Receiving Server持有的其它有效的域），那么Authoritative Server则必须（MUST）生成一个<invalid-from/>流错误因素并终止XML流和underlying TCP连接。
Authoritative Server 验证是否有效：
```
<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与第三步中Receiving Server所提供的ID不相符，那么Receiving Server必须（MUST）生成一个<invalid-id/>流错误因素并终止XML流和underlying TCP连接。如果‘to’地址的值与Receiving Server承认的主机名不符，那Receiving Server就必须（MUST）生成一个<host-unknown/>流错误因素终止XML流和underlying TCP连接。如果‘from’地址的值与在打开TCP连接时Originating Server呈现的主机名不符（或者它的任何有效的域，例如Receiving Server主机名的一个有效的子域或Originating Server持有的其它有效的域），那Receiving Server就必须（MUST）生成一个<invalid-from/>流错误因素并终止XML流和underlying TCP连接。在对Receiving Server进行了确认，Authoritative Server应该（SHOULD）终止它们之间的流。
Receiving Server告知Originating Server 验证结果：
```
<db:result
    from='Receiving Server'
    to='Originating Server'
    type='valid'/>
    
```
注意：在这里，连接或者是通过type='valid'来证实其有效，或者报告连接无效invalid。如果连接无效，那Receiving Server 必须（MUST）终止XML流及underlying TCP连接。如果连接有效，Originating Server便可以发送数据Receiving Server则可以读取数据了；在此之前，所有发送给Receiving Server的XML节应该（SHOULD）被默认丢弃。

前面所述的结果是Receiving Server核实了Originating Server的身份，所以Originating Server能够发送，而Receiving Server则可以接收，在“初始流”（即，从Originating Server到Receiving Server的流）上的XML节。为了验证使用“响应流”（即，从Receiving Server到Originating Server的流）的实体的身份，必须（MUST）也完成在反方向上的回拨。

在成功的回拨协商后，Receiving Server应该（SHOULD）承认后来的由Originating Server通过已存在的有效连接发送的<db:result/>信息包（例如，发送给Receiving Server提供的子域或其他主机名的有效请求）；这使在一个方向上的初始的有效连接能够进行“捎带确认”。

即使回拨协商成功了，服务器还必须（MUST）验证从其它服务器接收的所有XML节是否包含有一个‘from’属性和一个‘to’属性；如果节不满足这个约束，接收这节的服务器必须（MUST）生成一个<improper-addressing/>流错误因素并终止XML流和underlying TCP连接。此外，服务器必须验证接收自其它服务器的节的‘from’属性包含一个提供给流的有效的域，如果节不满足这个约束，接收这节的服务器必须（MUST）生成一个<invalid-from/>流错误因素并终止XML流和underlying TCP连接。这两个核查都有助于防止与特定节相关的欺骗发生。

XMPP翻译：RFC 3920[6]到此结束，请继续关注 XMPP翻译：RFC 3920[7]

posted on 2006-11-14 20:27 Hunts.C 阅读(882) 评论(0) 编辑收藏举报