4.8简化的流例子
5 使用TLS
5.1 概述 XMPP包含一个方法,用于保护流不被篡改和偷听。此信道加密方法利用传输层安全(TLS)协议[TLS],连同“STARTTLS”扩展,在为描述在RFC 2595[USINGTLS]中的IMAP[IMAP],POP3[POP3],ACAP[ACAP]等相似协议扩展模型。用于STARTTLS扩展的命名空间名是'urn:ietf:params:xml:ns:xmpp-tls'。 一个给定域的管理者可能需要使用TLS来进行客户端到服务器的通信,服务器到服务器的通信,或二者兼有。客户端应使用TLS去保护流,在企图完成SASL协商之前,而且,服务器出于保护服务器到服务器的通信的考虑,应在两个域间使用TLS。 应用以下规则: 1) 遵从此说明的初始实体必须包含版本属性,并在初始流头中将其值设为“1.0”。 2) 如果两服务器间的TLS协商发生,直到服务器宣称的域名系统(DNS)主机名被决定(参考服务器到服务器的通信(14.4))后,才能处理通信。 3) 当与此说明一致的接收实体收到一个包含版本属性设为至少“1.0”的初始化流时,发送一个流头作响应(包含版本标记)后,必须包含一个<starttls/>元素(由'urn:ietf:params:xml:ns:xmpp-tls'命名空间认证)并带有它所支持的其它流特征的列表。[服务器以<starttls/>响应] 4) 如果初始实体选择使用TLS,TLS协商必须在SASL协商处理之前完成;这种协商顺序是必要的,用于帮助保护SASL协商期间发送认证信息,并在TLS协商之前这段时间,使基于使用认证的SASL EXTERNAL机制成为可能。 5) 在TLS协商期间,实体不准在根流元素中发送任何空白字符(匹配[XML]内容,产品[3])作为元素间(任何在TLS例子中的空白字符都只是为了便于阅读)的分隔符;这种限制有助于确保合适的安全层字节精度。 6) 接收实体必须考虑TLS协商在发送<proceed/>元素的关闭“>”字符之后立即开始。初始实体必须考虑TLS协商在收到来自于接收实体的<proceed/>元素的关闭“>”字符之后立即开始。 7) 初始实体必须验证由接收实体表示的证书;参考证书验证(14.2)相关证书验证步骤。 8) 证书必须根据初始实体(例如:一个用户)提供的主机名来检查,而不是通过域名系统解析的主机名;例如:如果用户指定一个"example.com"的主机名,而DNS SRV[SRV]查找并返回"im.example.com",证书必须作为"example.com"被检查。如果对任何此种XMPP实体(例如,客户端或服务器)的一个JID在一个证书中被表示,它必须作为一个UTF8String来表示,UTF8String在位于subjiectAltName中的一个otherName实体中,使用[ASN.1]对象标识符"id-on-xmppAddr",在本文档5.1.1中说明。 9) 如果TLS协商成功,接收实体必须抛弃TLS生效之前,来自初始实体的任何非安全格式的知识。 10) 如果TLS协商成功,初始实体必须抛弃TLS生效之前,来自接收实体的任何非安全格式知识。 11) 如果TLS协商成功,接收实体不准提供STARTTLS扩展给当流重新开如时被提供的带有其他流特征的初始实体。 12) 如果TLS协商成功,初始实体必须继续SASL协商。 13) 如果TLS协商结果失败,接收实体必须终止XML流与潜在的TCP连接。 14) 参考强制实施技术(14.7)相关的必须被支持的机制。 5.1.1 ASN.1用于XMPP地址的对象标识符 上述[ASN.1]对象标识符"id-on-xmppAddr"定义如下: 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 对象标识符可能也以点分制显示,格式为"1.3.6.1.5.5.7.8.5" 5.2 叙述 当初始实体使用TLS保护一个带有接收实体的流时,步骤如下: 1) 初始实体打开一个TCP连接,靠发送开放XML流头给接收实体,此流头包含版本属性,并设其值至少为“1.0”,来初始化流。 2) 接收实体以打开一个TCP连接并发送一个XML流头给初始实体作为响应,此流头包含值至少为“1.0”版本属性。 3) 接收实体靠包含带有其它支持流特征(如果TLS需要与接收实体交互,它应当靠包含一个<required/>元素作为<starttls/>的子元素来标记此事实)的列表来为初始实体提供STARTTLS扩展。 4) 初始实体发起STARTTLS命令(例:由 'urn:ietf:params:xml:ns:xmpp-tls' 命名空间确认的<starttls/>元素)去指导希望开始TLS协商去保护流的接收实体。 5) 接收实体必须以由命名空间'urn:ietf:params:xml:ns:xmpp-tls'认证了的<proceed/>元素或<failure/>元素响应。如果有失败情况发生,接收实体必须终止双方的XML流与潜在的TCP连接。如果接着向下进行,实体必须尝试通过TCP连接完成TLS协商,并不准发送任何进一步的XML数据,直到TLS协商完成。 6) 初始实体与接收实体尝试依据[TLS]完成TLS协商。 7) 如果TLS协商不成功,接收实体必须终止TCP连接。如果TLS协商成功,初始实体必须靠发送一个开始XML流头给接收实体(它并不需要先发送一个关闭</stream>标记,因为接收实体与初始实体必须考虑到原始流根据成功的TLS协商而被关闭),以初始一个新流。 8) 根据从初始实体接收的新流头,接收实体必须靠发送一个新XML流头给有可利用特征(不包括STARTTLS特征)的初始实体来响应。 5.3客户端到服务器的例子 下面例子显示了一个客户端保护使用STARTTLS(注:替换步骤显示在下一行,用来解释协议失败的情况;他们在本例中并不详尽也不是必须的由数据发送而触发)流的数据流。 1步:客户端初始流给服务器: <stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' to='example.com' version='1.0'> 步2:服务器以发送给客户端一个流标记作为响应: <stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='c2s_123' from='example.com' version='1.0'> 步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> 步4:客户端发送STARTTLS命令给服务器: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> 步5:服务器通知客户端它被允许处理 <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> 步5(替代):服务器通知客户端TLS协商失败,并关闭流与TCP连接: <failure xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> </stream:stream> 步6:客户端与服务器试图协商通过现存的TCP连接 完成TLS协商。 步7:如果TLS协商成功,客户端初始化一个新流给服务器: <stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' to='example.com' version='1.0'> 步7(代替 ):如果TLS协商不成功,服务器关闭TCP连接。 步8:服务器靠发送带有任何可利用流特征的流头给客户端作为响应。 <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> 步9:客户端继续SASL协商(6) |
http://hi.baidu.com/xboxsky/blog/item/070dd0a264526fa7caefd00f.html