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

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