xmpp协议4
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）靠发送实体所规定的主机名来验证（如：一个用户），而不是通过DN*确定的主机名；例如，如果用户协商一个主机名 “**ample.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. 客户端到服务器的例子
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. 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）靠发送实体所规定的主机名来验证（如：一个用户），而不是通过DN*确定的主机名；例如，如果用户协商一个主机名 “**ample.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. 客户端到服务器的例子
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
