随笔- 1  评论- 21  文章- 16 

XMPP翻译:RFC 3920[6](Chapter8)

 

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

内容提要

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连接。

  5. Receiving Server与Originating Server声称的域名回建一个TCP连接,然后连接到上了Authoritative Server。 (注意:优化考虑,实现中也可能(MAY)重用这里已存在的一个连接。) 
  6. 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连接。

  7. 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连接。

  8. 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连接。

  9. 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)终止它们之间的流。

  10. 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 阅读(...) 评论(...) 编辑 收藏