XMPP 3920 最靠谱的中文翻译文档（五）

XMPP 3920 最靠谱的中文翻译文档（五）

2009-10-17 19:58

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连接。这两个检查有助于阻止关联到特别节的哄骗。

9．XML节
       TLS协商（5节）后，如果需要SASL协商（6节）与资源绑定（7节），XML节可通过流来发送。定义了三种XML节用于'jabber:client'与'jabber:server'命名空间：<message/>, <presence/>, and <iq/>。另外，这种节有五个通用属性。这些通用属性，像三种节的基本语义一样，都定义在此；与即时消息与表示应用相关的XML节的更详细信息在[XMPP-IM]中提供。

9．1通用属性
       以下五个属性对message, presence与IQ均通用：

9．1．1 to
       ‘to’属性指定接收节的JID。
       在‘jabber:client’命名空间中，节应当处理‘to’属性，虽然，由服务器处理的从客户端到服务器端的节不应该拥有‘to’属性。
       在'jabber:server'命名空间中，节必须拥有‘to’属性；如果服务器收到一个不满足此限制的节，它必须产生一个<improper-addressing/>流错误条件并终止两个XML流与错误服务器的潜在连接。
       如果‘to’属性无效或不能连接，发现此事实的（通常是发送的或接收的服务器）实体必须返回一个合适的错误给发送者，设置错误节的‘from’属性为错误服务器提供的‘to’属性值。

9．1．2 from
       ‘from’属性指明发送者的IID。
       当服务器收到一个在由'jabber:client'命名空间认证的已授权流的上下文中的XML节，它必须做以下事件之一：
1） 验证客户端提供的‘from’属性值就是用于联合实体的已连接资源的值。
2） 加一个‘from’地址值给节，此节的值是裸JID（<node@domain>）或全JID（<node@domain/resource>），这些JID由服务器决定用于产生节的已联接资源（看地址决定（3.5节））。

         如果一个客户端试图发送‘from’属性并不匹配实体的已联接资源的XML节，服务器应该返回一个<invalid-from/>流错误给客户端。如果一个客户端试图通过一个流来发送一个还未授权的XML节，服务器应当返回一个<not-authorized/>流错误给客户端。如果产生了，这些条件都必须关闭流并终止潜在的TCP连接；这有助于阻止来自于欺诈客户端的否认服务攻击。
         当一个服务器产生一个来自于服务器本身的节，用于传送到一个已连接的客户端（例如：在由服务器代表客户端提供的数据存储服务的上下文中），节必须既（1）不包括‘from’属性或（2）包括‘from’属性，其值是帐户的裸JID（<node@domain>）或客户的全JID（<node@domain/resource>）。服务器不准发送给客户端一个不包括‘from’属性的节，它必须设想节是从服务器到已连接客户端。
         在'jabber:server'命名空间中，一个节必须处理一个‘from’属性；如果服务器收到不满足此限制的节，它必须产生一个<improper-addressing/>流错误条件。更进一步，包含在‘from’属性中的JID的域标识符部分必须匹配发送服务器（或任何已认证相关域，如发送服务器的主机名或其它由发送服务器已认证域）的主机名，当在SASL协商或回叫协商通信中；如果一个服务器收到一个不满足此约束的节，它必须产生一个<invalid-from/>流错误条件。这些条件都必须关闭流并终止潜在的TCP连接；这有助于阻止欺诈服务器的否认服务攻击。

9．1．3 id
       可选‘id’属性可能由发送实体因内部跟踪收发（特别是跟踪固有在IQ节语义中的请求-响应交互）节而使用。对值‘id’属性来说，它是可选的唯一全局的，在域内的或流中的。IQ节语义强加了其它约束；看IQ语义（9.2.3）。

9．1．4 type
       类型域属性指定目的或消息上下文，出席或IQ节的详细信息。‘type’属性的特别允许值依赖节是否是一个消息，出席，或IQ；消息与出席节的值是特别用于即时消息与出席应用的，并因此定义义在[XMPP-IM]，然而IQ节的值特指IQ节在一个结构化的请求-响应“会话”中的角色，并因此定义在以下IQ语义（9.2.3节）。对三种节仅有的一个通用‘type’值是“error”；看节错误（9.3节）。

9．1．5 xml:lang
       此节应当处理一个‘xml:lang’属性（定义在[XML]2.2节），如果节包含倾向于表示到一个人类用户（RFC2277[CHARSET]中有解释，“对人的国际化”）的XML字符数据。‘xml:lang’属性值指定任意人类可读XML字符数据的缺省语言，可能被特定的子元素的‘xml:lang’属性覆盖。如果节没有‘xml:lang’属性，实现必须设想为流指定的缺省语言已在以下流属性（4。4节）中定义。‘xml:lang’属性的值必须是一个NMTOKEN并必须遵从定义在3066[LANGTAGS]中的格式。

9．2基本语义
9．2．1消息语义
       <message/>节种类可被看作“推”机制，一个实体推信息给其它实体，与EMAIL系统中发生的通信类似。所有消息节应该拥有‘to’属性，指定有意的消息接收者；根据接收到那样的一个节，服务器应该路由或传送它到有意的接收者（参考服务器处理用于相关XML节的通用路由与传送规则XML节的规则（10节））。

9．2．2 出席语义
       <presence/>元素可被看作基本广播或“出版-订阅”机制，多实体收到他们已订阅（在这种情况下，网络可利用信息）实体的信息。总的来说，出版实体应该发送一个不带‘to’属性的出席节，在这种情况下，与此实体相连的服务器应该广播或复用节给所有订阅实体。然而，一个出版实体也可能发送一个带有‘to’属性的出席节，此种情况下，服务器应该路由或传送节到有意的接收者。参考处理XML节（10节）的服务器规则，用于通用路由与相关XML节的传送规则，并且用于即时消息与出席应用的出席-特定规则[XMPP-IM]。

9．2．3 IQ语义
       信息/请求，或IQ，是一个请求-响应机制，与[HTTP]在某些方面相似。IQ语义让一个实体向其它实体请求或接收其它实体的响应成为可能。请求与响应的数据内容由IQ无素的直接子元素的命名空间声明定义，并且，交互由请求实体通过使用‘id’属性来跟踪。因此，IQ交互遵从结构化数据交换的一个通用模式，此交换例如得到/结果或设置/结果（虽然如果合适的话，对一个请求的响应可能会以错误返回）：

   Requesting                 Responding
     Entity                     Entity
   ----------                 ----------
       |                           |
       | <iq type='get' id='1'>     |
       | ------------------------> |
       |                           |
       | <iq type='result' id='1'> |
       | <------------------------ |
       |                           |
       | <iq type='set' id='2'>     |
       | ------------------------> |
       |                           |
       | <iq type='error' id='2'>   |
       | <------------------------ |
       |                           |

       为了加强这些语义，以下规则应用：
1） 对IQ节来说，‘id’属性是REQUIRED。
2） 对IQ节来说。‘type’属性是需要的。值必须是以下之一：
*get——节是一个用于信息或需求的请求。
*set——节提供所需数据，设置新值，或替换现存值。
*result——节是成功得到或设置请求的响应。
*error——先前发送得到或设置的相关过程或传送的错误（参考节错误（9.3节））。
3） 收到类型为“get”或“set”的IQ请求的实体必须以类型为“result”或“error”的IQ响应来响应（响应必须保留请求的‘id’属性）。
4） 收到类型为“result”或“error”的节不准靠发送一个进一步的类型为“result”或“error”的IQ响应节来响应；然而，如以上显示，请求实体可能发送另一个请求（如：一个类型为“set”的IQ，为了提供通过得到/结果对发现的所需的信息）。
5） 类型为“get”或“set”的IQ节必须包含一个并仅有一个子元素，指定特别的请求或响应语义。
6） 一个类型为“result”的IQ节必须包含0或一个子元素。
7） 类型为“error”类型的IQ节应当包含在相关“get”或“set”子元素中，并且，必须包含一个<error/>子元素；详细信息，参考节错误（9.3节）。

9．3 节错误
       节相关错误以类似流错误（4.7节）的方式处理。然而，不像流错误，节错误不可是不可恢复的；因此，暗含相关源发送者行为的错误节能按顺序纠正错误。

9．3．1 规则
       以下规则应用于节相关错误：
1） 检测相关节错误条件的接收或处理实体必须返回给发送实体一个同种节（消息，出席或IQ），它的‘type’属性被设置成值“error”（那样的节在此被称为“错误节”）。
2） 产生错误节的实体应当包含被送的源XML，为了发送者能够检测，并且，如果必要的话，在试图重送前纠正XML。
3） 一个错误节必须包含一个<error/>子元素。
4） 一个<error/>子元素不准被包括，如果‘type’属性有不止一个“错误”值（或无‘类型’属性）。
5） 接收一个错误节的实体不准响应带有进一步错误节的节；这有助于阻止循环。

9．3．2 语法
       节相关错误语法如下：
   <stanza-kind to='sender' type='error'>
     [RECOMMENDED to include sender XML here]
     <error type='error-type'>
       <defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
       <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'
             xml:lang='langcode'>
         OPTIONAL descriptive text
       </text>
       [OPTIONAL application-specific condition element]
     </error>
   </stanza-kind>

       节种类是消息、出席或iq之一。
<error/>元素的‘type’属性值必须是以下之一：
*cancel——不重试（错误不可恢复）
*continue——进行（仅是一个警告条件）
*modify——改变数据发送后重试
*auth——提供信任后重试
*wait——等待之后重试（错误是临时的）

       <error/>元素：
       必须包含一个子元素，此子元素与以下指定的已定义的节错误条件一致；此元素必须被'urn:ietf:params:xml:ns:xmpp-stanzas'命名空间所认证。
       可能包含<text/>子元素，此子元素包含XML字符数据，用于描绘更细节的错误；此元素必须被'urn:ietf:params:xml:ns:xmpp-stanzas'命名空间所认证，并且应该拥有一个'xml:lang'属性。
       可能包含一个子元素，用于特殊-应用错误条件；此元素必须由一个已定义-应用命名空间认证，并且，它的结构由此命名空间定义。

       <text/>元素是可选的。如果包括在内，它应当仅用于提供描述性或诊断性信息，这些信息用于补充已定义条件或特殊-应用条件的意思。它不应当由应用程序性的描述。它不应当用作向用户表达的错误信息，但可能显示除与包含条件元素（或元素们）相关的错误消息。

       最后，为维护向后兼容性，此方案（在[XMPP-IM]中指定的）允许可选的在<error/>元素中包含‘code’属性。

9．3．3 已定义条件
       以下条件被定义用于节错误。

<bad-request/>——发送者已发送畸形的或不能被处理的（例如，一个包含未识别‘type’属性值的IQ节）XML；相关错误类型应当是“modify”。

<conflict/>——访问不被授权，因为一个现存资源或会话以同样名字或地址存在；相关错误类型应当是“cancel”。

<feature-not-implemented/>——被请求特征未被接收者或服务器实现，并且因此不能被处理；相关错误类型应当是“cancel”。

<forbidden/>——请求实体不拥有执行行为的所需许可；相关错误类型应当是“auth”。

<gone/>——接收者或服务器不在以此地址联系（错误节可能包含一个新地址在<gone/>元素的XML字符数据中）；相关错误类型应当是“modify”。

<internal-server-error/>——服务器不能处理节，因为错误配置或一个另外-未定义内部服务器错误；相关错误类型应当是“wait”。

<item-not-found/>——JID地址或被请求项不能被发现；相关错误类型应当是“cancel”。

<jid-malformed/>——已提供的发送实体或与一个XMLL地址（例：‘to’属性值）通信或其它方面（例：资源标识符）与地址方案（3节）中定义的语法不符；相关错误类型应当是“modify”。

<not-acceptable/>——接收者或服务器理解请求，但拒绝处理它，因为它不满足由接收者或服务器（例：消息中相关可接受字的本地策略）所定义的标准；相关错误类型应当是“modify”。

<not-allowed/>——接收者或服务器不允许任何实体执行动作；相关错误类型应当是“cancel”。

<not-authorized/>——发送者必须在被允许执行动作前提供合适的信任，或已经提供不合适的信任；相关错误类型应当是“auth”。

<payment-required/>——请求实体未授权去访问被需求服务，因为需要付费；相关错误类型应当是“auth”。

<recipient-unavailable/>——有意的接收者临时不可用；相关错误类型应当是“wait”（注：一个应用不准返回此错误，如果这样做将提供关于意向接收 者对未授权知道此类信息的实体的网络可利用性信息）。

<redirect/>——接收者或服务器为此信息重定向请求到其他实体，通常是临时的（错误节应当包含可替换地址，必须是一个有效的JID，在<redirect/>元素的XML字符数据中）；相关错误类型应当是“modify”。

<registration-required/>——请求实体未被授权访问所请求服务，因为需要注册；相关错误类型应当是“auth”。

<remote-server-not-found/>——一个指定作为意向接收者的部分或全部的JID的远程服务器或服务不存在；相关错误类型应当是“cancel”。

<remote-server-timeout/>——一个指定作为意向接收者（或被请求去执行一个请求）的部分或全部的JID的远程服务器或服务不能在一个合理的时间内被联系到；相关错误类型应当是“wait”。

<resource-constraint/>——服务器或接收者缺少必要的系统资源去服务请求；相关错误类型应当是“wait”。

<service-unavailable/>——服务器或接收者当前并不提供所请求的服务；相关错误类型应当是“cancel”。

<subscription-required/>——请求实体不被授权访问被请求服务，因为需要订阅；相关错误类型应当是“auth”。

<undefined-condition/>——错误条件并不是此列表中由其它条件定义的那些之一；任何错误类型可能与此条件相关，并且，它应当仅用于与一个特殊-应用条件相连。

<unexpected-request/>——接收者或服务器理解请求，但此时（例：请求无序/请求不在状态）并不期望它；相关错误类型应当是“wait”。

9．3．4 特殊-应用条件
       像所知道的，一个应用可能靠包含一个错误元素中的合适的-命名空间的子元素来提供特殊-应用节错误信息。特殊-应用元素应当补充或进一步认证一个已定义元素。因此，<error/>元素将包含两个或三个子元素：

   <iq type='error' id='some-id'>
     <error type='modify'>
       <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
       <too-many-parameters xmlns='application-ns'/>
     </error>
   </iq>

   <message type='error' id='another-id'>
     <error type='modify'>
       <undefined-condition
             xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
       <text xml:lang='en'
             xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
         Some special application diagnostic information...
       </text>
       <special-application-condition xmlns='application-ns'/>
     </error>
   </message>

http://hi.baidu.com/xboxsky/blog/item/1aebf3de3d26d25e95ee370a.html