XMPP翻译：RFC 3920[4]（Chapter5）

本篇翻译了XMPP核心协议RFC 3920的第五章，由于时间有限，所以今天就翻译一篇。

内容提示：

  • Use of TLS 使用运输层安全协议
    1. Overview //概述
      •  用于XMPP地址的ASN.1对象识别器
    2. Narrative //描述
    3. Client-to-Server Example //客户端到服务器的例子
    4. Server-to-Server Example //服务器到服务器的例子

 

5.1. 概述

XMPP包含一个方法来保护流不受干扰与窃听。这个信道加密技术使用到了TSL（传输层安全）协议，连同一个“STARTLLS”扩展，这个扩展是模仿了定义在RFC 2595中用于IMAP、POP3、和ACAP协议的类似的扩展。该STARTTLS扩展的命名空间名为“urn:ietf:params:xml:ns:xmpp-tls”。

一个给定域的管理者可能（MAY）需要在客户端到服务器的通信、服务器到服务器的通信或两者同时应用到TLS。客户端应该（SHOULD）在尝试完成协商SASL之前使用TLS来保护流的安全，而服务器则应该（SHOULD）在两个域之间使用TLS来保护服务器到服务器的通信。

应用以下规则：

  1. 使用了这个规范的发送实体必须（MUST）在其初始流header中包含值为“1.0”的‘version’属性。
  2. 如果TLS协商发生在两个服务器之间，通信不能（MUST NOT）继续，直到服务器所持有的DNS主机名被确定（参见14.4.节： 服务器到服务器通信）
  3. 当一个使用了这个规范的接收实体收到一个包含了值至少为“1.0”的‘version’属性的初始流header时，在响应了一个带有version标记的流header后，必须（MUST）包含一个<starttls/>（限定在‘urn:ietf:params:xml:ns:xmpp-tls’命名空间下）元素与它所支持的其它流特性序列一起发送。
  4. 如果发送实体选择使用TLS，TLS协商必须在进行SASL协商之前完成；这样的协商顺序有助于保护在协商SASL期间所发送的认证信息，同时，在优先协商TLS的情况下，也使得可以在认证上使用基于SASL EXTERNAL的机制。
  5. 在TLS协商期间，实体不能（MUST NOT）在流的根元素间发送任何空字符（matching production [3] content of XML）来作为元素的间隔（在后面的TLS例子中出现的任何空字符只是为了可读性）；这个禁令有助于确保彻底的安全层的字节精确度。
  6. 接收实体必须（MUST）认为在<proceed/>元素的“>”字符发送出后TLS协商已立刻开始了。发送实体必须（MUST）认为在接收到来自接收实体的<proceed/>元素的“>”字符之后TLS协商已立刻开始了。
  7. 发送实体必须（MUST）验证接收实体所呈现的证书；参见14.2. 验证证书一节中关于验证证书的程序。
  8. 证书必须（MUST）靠发送实体所规定的主机名来验证（如：一个用户），而不是通过DNS确定的主机名；例如，如果用户协商一个主机名“example.com”，但是DNS SRV查找返回“im.example.com”，那么证书必须（MUST）以“example.com”的情况来验证。如果证书中出现一个任何类别XMPP实体的JID（如：客户端或是服务器），该JID必须（MUST）在另一个处于subjectAltName中的异名实体内被转化为UTF8字符形式，这要使用本文档5.1.1节中定义的[ASN.1]对象识别器“id-on-xmppAddr”。
  9. 如果TLS协商成功了，接收实体必须（MUST）丢弃任何在TLS生效之前，在以非安全的发式从发送实体获得的信息。
  10. 如果TLS协商成功了，发送实体必须（MUST）丢弃任何在TLS生效之前，在以非安全的发式从接收实体获得的信息。
  11. 如果TLS协商成功了，接收实体不能（MUST NOT）向发送实体提供STARLLS扩展，连同流重起时出现的那些流特性。
  12. 如果TLS协商成功了，发送实体必须（MUST）继续协商SASL。
  13. 如果TLS协商失败了，接收实体必须（MUST）终止XML流以及underlyingTCP连接。
  14. 参见14.7节（执行托管技术）中有关必须提供的一些（MUST）机制。

5.1.1 用于XMPP地址的ASN.1对象识别器

前面说到的ASN.1对象识别器定义如下：

id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-on  OBJECT IDENTIFIER ::= { id-pkix 8 }  -- other name forms
id-on-xmppAddr  OBJECT IDENTIFIER ::= { id-on 5 }
XmppAddr ::= UTF8String
对象识别器也可以（MAY）用点表示格式表现为：“1.3.6.1.5.5.7.8.5”。
 

5.2. 描述

当发送实体要使用TLS来使其与接收实体的流安全，相关步骤如下：

  1. 发送实体打开一个TCP连接，通过发送开的XML流header给接收实体来初始化一个流，其中包含了值至少被设置为“1.0”的‘version’属性。
  2. 接收实体通过打开一个TCP来接并发送一个XML流header给发送实体来响应，其中也包含了值至少被设置为“1.0”的‘version’属性。
  3. 接收实体向发送实体提供了STAERRLS扩展，将其包含在其它所支持的流特性序列里（如果需要TLS与接收实体交互，它需要通过包含一个<required/>元素作为<starttls/>的子元素，来指明这个事件）。
  4. 发送实体发出STARLLS命令（例如，由‘urn:ietf:params:xml:ns:xmpp-tls’限定的<starttls/>元素）来通知接收实体，它要开始定制一个TLS来使流安全。
  5. 接收实体必须（MUST）反馈一个在‘urn:ietf:params:xml:ns:xmpp-tls’命名空间下的<proceed/>元素或是一个<failure/>元素。如果错误情况发生，两个实体必须（MUST）终止双方的XML流及underlyingTCP连接，且不能（MUST NOT）再发送任何的XML数据，直到TLS协商完成。
  6. 发送实体与接收实体尝试依照TLS完成一个TLS协商。
  7. 如果TLS协商没成功，接收实体必须（MUST）终止TCP连接。如果TLS协商成功，发送实体必须（MUST）初始一个新的流，通过给接收实体发送一个开的XML流header（最初没有必要发送一个闭的</stream>标识，因为接收实体与发送实体必须（MUST）考虑在TLS协商成功的条件下关闭初始的流）。
  8. 在接收到发送实体发来的新的流header后，接收实体必须（MUST）响应一个新的XML流header给发送流，连同可用的特性（不包括STARTTLS特性）。

 

5.3. 客户端到服务器的例子

 

The following example shows the data flow for a client securing a stream using STARTTLS (note: the alternate steps shown below are provided to illustrate the protocol for failure cases; they are not exhaustive and would not necessarily be triggered by the data sent in the example).

Step 1: 客户端发送流到服务器： 

<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>

Step 2: 服务器通过发送一个stream标识响应客户端： 

<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='c2s_123'
from='example.com'
version='1.0'>

Step 3: 服务器向客户端发送STARTTLS扩展，连同认证机制和任何其它流特性： 

<stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
<required/>
</starttls>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
</mechanisms>
</stream:features>

Step 4: 客户端向服务器发送STARTLLS命令： 

<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>

Step 5: 服务器告知客户端可以继续： 

<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>

Step 5 (alt): 服务器告知客户端TLS协商失败了，关闭双方的流及TCP连接： 

<failure xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
</stream:stream>

Step 6: 客户端与服务器尝试通过已存在的TCP连接完成TLS协商：

Step 7: 如果TLS协商成功，客户端初始化一个新的流给服务器： 

<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>

Step 7 (alt): 如果TLS定制失败，服务器关闭TCP连接：

Step 8: 服务器通过发送一个流header来响应客户端，连同任何可用的流特性： 

<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
from='example.com'
id='c2s_234'
version='1.0'>
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
<mechanism>EXTERNAL</mechanism>
</mechanisms>
</stream:features>

Step 9: 客户端继续协商SASL

 

5.4. 一个服务器到服务器的例子

下面的例子展示两个服务器使用STARTTLS保护一个流的数据流（注意：下面展现的交替的步骤是用于阐明在失败情况中的协议；不是很详尽，且错误不必要一定是例子中发送的数据引发的）。

Step 1: 服务器1初始化流到服务器2： 

<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>

Step 2: 服务器2通过发送一个stream标识响应服务器1： 

<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
from='example.com'
id='s2s_123'
version='1.0'>

Step 3: 服务器2向服务器1发送STARTTLS扩展，连同认证机制和任何其它流特性： 

<stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
<required/>
</starttls>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>KERBEROS_V4</mechanism>
</mechanisms>
</stream:features>

Step 4: 服务器1向服务器2发送STARTLLS命令： 

<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>

Step 5:服务器2告知服务器1可以继续： 

<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>

Step 5 (alt): 服务器2告知服务器1TLS协商失败了，关闭双方的流： 

<failure xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
</stream:stream>

Step 6: 服务器1与服务器2尝试通过TCP连接完成TLS协商：

Step 7: 如果TLS协商成功，服务器1初始化一个新的流给服务器2： 

<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>

Step 7 (alt): 如果TLS定制失败，服务器2关闭TCP连接：.

Step 8: 服务器通过发送一个流header来响应服务器1，连同任何可用的流特性： 

<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
from='example.com'
id='s2s_234'
version='1.0'>
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>KERBEROS_V4</mechanism>
<mechanism>EXTERNAL</mechanism>
</mechanisms>
</stream:features>

Step 9: 服务器1继续协商SASL

 

几个问题
  1. TLS negotiation 不知道怎么翻译，又是我译成协商，有时是制定；
  2. underlying TCP 不知道怎么翻译；
  3. 如果您知道这些，请留言。我只是想通过翻译学习，本身水平不足，所以很渴望您的指教；
  4. 等我把所有的翻译完了，我会回头修改一遍的。

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

posted on 2006-11-07 19:59  Hunts.C  阅读(1195)  评论(1)  编辑  收藏  举报

Powered by: 博客园 Copyright © 2024 Hunts.C
Powered by .NET 9.0 on Kubernetes