xmpp协议8
Server Dialback //服务器回拨
1. Overview //概述
2. Order of Events //事件顺序
3. 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. 事件顺序
下面是在回拨中事件顺序的主要摘要：
1. Originating Server与Receiving Server建立一个连接。
2. Originating Server通过该连接发送一个‘key’值到Receiving Server。
3. Receiving Server与Authoritative Server建立一个连接。
4. Receiving Server通过该连接发送一个‘key’值到Authoritative Server。
5. Authoritative Server回复key是否有效。
6. 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. 协议
服务器间交互协议的详细描述如下:
1. Originating Server与Receiving Server建立TCP连接。
2. 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连接
3. 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.
4. 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连接。
1. Overview //概述
2. Order of Events //事件顺序
3. 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. 事件顺序
下面是在回拨中事件顺序的主要摘要：
1. Originating Server与Receiving Server建立一个连接。
2. Originating Server通过该连接发送一个‘key’值到Receiving Server。
3. Receiving Server与Authoritative Server建立一个连接。
4. Receiving Server通过该连接发送一个‘key’值到Authoritative Server。
5. Authoritative Server回复key是否有效。
6. 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. 协议
服务器间交互协议的详细描述如下:
1. Originating Server与Receiving Server建立TCP连接。
2. 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连接
3. 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.
4. 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连接。
