【YD通讯标准】 面向即时通信互通的扩展消息与表示协议(XMPP)技术要求

ICS33.040.30
中华人民共和国通信行业标准
YD/T2943-2015
面向即时通信互通的扩展消息与表示协议（XMPP）技术要求
XMPPprotocoltechnical requirementforinstantcommunicationinterworking2015-07-14发布
2015-10-01实施
中华人民共和国工业和信息化部发布前言：
1范围
规范性引用文件，
3术语、定义和缩略语·
3.1术语和定义·
3.2缩略语*
4XMPP协议结构.·
协议基本要求
5.1XML流.
5.2STARTTLS握手.
5.3SASL握手
5.4XML节·
呈现业务互通的协议要求·
Presence语法
互通中呈现业务订阅管理
6.3互通中呈现信息的交换*
6.4好友搜索中的呈现信息探查
7即时消息互通的协议要求
7.1对—聊天会话
7.2Message语法
YD/T2943-2015
YD/T2943-2015
本标准为网间即时消息互联互通系列标准之一。本系列标准预计的名称如下：即时消息互通技术要求：
一基于会话初始协议（SIP)的即时通信互通协议研究：一面向即时通信互通的扩展消息与表示协议（XMPP）技术要求。本标准按照GB/T1.1-2009给出的规则起草。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由中国通信标准化协会提出并归口。本标准起草单位：中国信息通信研究院、中国移动通信集团公司、中国电信集团公司、中国联合网络通信集团有限公司。
本标准主要起草人：罗松、付国强、蔡旭辉、王文超、戴军尧、邓勇、何育芬、张强。
YD/T2943-2015
面向即时通信互通的扩展消息与表示协议（XMPP）技术要求1范围
本标准规定了基于XMPP协议进行互通过程中所涉及协议的技术要求，包括呈现业务互通对XMPP协议的要求和即时消息业务互通的XMPP协议要求等。本标准适用于运营商、互联网业务提供商等即时通信业务互通的网络和设备。2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。YD/TXXXX-201X即时通信互通技术要求IETFRFC2831一种使用Digest认证的SASL机制(UsingDigestAuthenticationasaSASLMechanism）IETFRFC3920可扩展的消息和出席信息协议（XMPP)：核心协议，(ExtensibleMessagingandPresenceProtocol (XMPP): Core)
IETFRFC4480呈现信息数据格式扩展，(RPID：RichPresenceExtensionstothePresenceInformationData Format (PIDF))
IETFRFC5746重新协商TLS指示的扩展，(TransportLayerSecurity（TLS）RenegotiationIndicationExtension)
IETFRFC6120可扩展的消息和出席信息协议（XMPP）：核心协议（ExtensibleMessagingandPresenceProtocol (XMPP): Core)
IETFRFC6121可扩展的消息和出席信息协议（XMPP）：即时消息和呈现(ExtensibleMessagingandPresenceProtocol (XMPP):InstantMessaging andPresence)3术语、定义和缩略语
3.1术语和定义
下列术语和定义适用于本文件。3.1.1
XMPP服务器XMPPServer
是XMPP通信的一个智能抽象层，它主要负责：对受验证的客户端、服务器以及其他实体之间以XML流形式的连接和会话进行管理。在实体间使用XML流对合理编址的XML节进行路由。大部分的XMPP服务器负责存储客户端使用的数据（比如基于XMPP协议的即时消息应用中的联系人名单）。在这种情况下，XML数据直接由服务器来处理，而不需要转发到其他实体。3.1.2
XMPP互通网关XMPPInterworkingGatewayYD/T2943-2015
在即时通信互通中完成即时通信服务提供商内部协议与XMPP之间的相互转换，并利用XMPP协议进行互通的功能实体。为了完成即时通信的互通功能，XMIPP互通网关要求能够完成三方面的功能：地址格式转换、呈现业务的XMPP协议交换和即时消息的XMPP协议交换。3.1.3
XMPP实体地址XMPPEntityAddress指一组排列好的元素，包括域名（domainidentifier）、节点名（nodeidentifier）和资源名（resourceidentifier)。
3.2缩略语
下列缩略语适用于本文件。
SIMPLE
FullyQualifiedDomainName
Instant Messaging
Presence Server
Resource List Server
Simple Authentication and Security LayerSIPforInstantMessagingandPresenceLeveragingExtensions
Session Initiate Protocol
Transport Layer Security
Extensible Markup Language
ExtensibleMessagingandPresenceProtocol4XMPP协议结构
完全合格域名
即时消息
呈现服务器
资源列表服务器
简单认证和安全层
面向即时消息和呈现业务SIP扩展协议会话初始协议
传输层安全
可扩展标记语言
扩展的消息和呈现协议
呈现、即时消息等业务要求支持XMPP协议，其中XMPP支持TLS和SASL作为加密和身份认证协议。XMPP协议的具体参数要求见IETFRFC6120和IETFRFC6121。协议结构如图1所示。XMPP
TCP协议
IP协议
图1XMPP实现互通的协议结构
TLS应用于XMPP应用中的一个单一流。因为XMPP的典型架构是分布式的客户端一服务器模型。个节会贯穿多个流，其中不是所有的流都受到TLS机制的保护。例如，一个服务器下的某个客户端（）想要同另一个服务器下的一个客户端（）会话而发送的一个节将会贯穿三个流：（1）发送节的客户端与自己服务器之间的流：（2）发送端服务器与接收端服务器之间的流；（3）接收端服务器到接收端客户端的流。在发送端服务器与接收端服务器之间的节应用明文处理，因此，即使发送端的客户端到自己服务器之间的流是受保护的，在发送端服务器处理节，从发送端服务器发往接收端服务器、从接收端服务器发送到接收端客户端几种情况下，经过这个受保护系统的节的保密性和完整性还是不能够被保证。只有一个端到端的强健的加密技术可以保证2
YD/T2943-2015
一个节贯穿整个通信路径上每一跳的保密性和完整性。（到目前为止XMPP组织还没有广泛的应用和推广一个端到端的加密技术，而且这些也不属于本标准的范畴）即时消息互通的要求见YD/TXXXX-201X《即时通信互通技术要求》。5协议基本要求
5.1XML流
5.1.1流基本要求
XML流是一个容器，包含两个实体之间通过网络交换的XML元素。一个XML流是由一个打开标签“流头部”(如以)作为开始标签，以作为关闭标签的XML流。在流的整个生命周期中，初始化实体可以通过流发送无限制数量的XML元素，这些元素或用于协商流（如完整的TLS握手或SASL握手)：或用于协商XML节。“初始的流”用于从初始实体（互通网关）到接收实体（互通网关）的握手。初始流允许从初始实体到接收实体的单向通信。为了使接收实体能够和初始实体交换消息，接收实体应发起一个反向的应答流。
XML节是XMPP协议元素的基本单元。一个节是一个一级元素（流的深度为1），它的元素名是“message”、“presence”或“iq”，它符合的名字空间是“jabber:client'或“jabber:server”。一个XML节通常有必要包含一个或多个子元素（包括属性、元素和XML字符数据）以传送所需的消息。在即时消息互通中共存在三种类型的节：message、presence和IQ（Info/Query的简写）。这些节类型提供了三种不同的通信原语：普通类型的“推送”机制、网络可靠性的广播消息的“发布一订阅”机制和结构化交换数据的“请求一响应”机制。部分XML流的功能就如同在一个会话期间发送的XML节的一个封装，并且另一部分的XML流的功能如同一个会话期间接收的XML节的一个封装，可描述为如表1所示。表1XML节封装
初始流
下载标准就来标准下载网


presence>




Type-\get\


5.1.2打开和关闭流
5.1.2.1打开流
应答流


Type\'result


YD/T2943-2015
在连接到合适的接收实体的IP地址和端口后，XMPP互通网关通过发送一个流头部到接收实体以打开一个流。
I:
Cstream:stream
[email protected]
to-im.example.com'
version=1.0
xml:lang-en'
xmlns-jabber:client
xmlns:stream-\http:/etherx.jabber.org/streams>接收实体通过发送它自已拥有的流头部（“回应流头部”）回复给XMPP互通网关。R:
from-im.example.com
[email protected]'
version=\1.0\
xml:lang-'en
xmlns-\jabber:client
xmlns:stream-\http://etherx.jabber.org/streams>实体接着处理流握手进程的余下部分。5.1.2.2关闭流
从一个实体到另一个实体的XML流可能会在任何时候被关闭。一个流通过一个关闭标签被关闭。E:
如果各方使用通过单个TCP连接的两个流或通过两个TCP连接的两个流，实体发送关闭流标签应符合以下几点：
·在终止底层TCP连接之前等待对方也关闭其出站流：避免在其出站流上发送任何更多的数据到其它实体，但继续接收来自其它实体的进程数据。。在一个合理的时间内（具体时间在部署中确定），如果对方没有发送它的关闭流标签，则认为流是无效的。
在从对方接收到一个相互的关闭流标签或等待一个合理的时间却没有响应之后，终止底层的TCP连接。
为了阻止截断攻击方关闭流，应在终止底层TCP连接之前发送一个TLS关闭通告提醒，并应接收一个来自其它方的响应关闭通告提醒。5.1.3流握手
5.1.3.1基本概念
YD/T2943-2015
对于互通网关，至少初始化实体在允许向接收实体发送节之前需要被接收实体验证。接收实体通过“流特性”通信告知初始实体以下条件：特定协议集的交互，协议的交互进行自愿协商，但可以改进XML流的处理。
连接条件意味着流需要被协商。协议层的顺序（依次为TCP、TLS、SASL、XMPP）暗示流的协商是一个多层处理。进一步的结构包括两个因素：（1）一个给定的流特性只能给特定的实体或者在其它特性协商后提供（如只有在SASL验证后才能提供资源绑定）。
（2）流特性可以进行强制协商或者自愿协商。为了安全考虑，流的发送/接收方需丢弃特定协议交互（如所有情况下使用TLS，当安全层可能建立时使用SASL，见相关的SASL机制的规范定义）后获得的消息。5.1.3.2流特性格式
如果初始化的实体在初始化流的头消息中设置“版本”属性的值为\1.0\，在发送回应流头之后，接收实体应发送一个子元素（置于流名字空间前的前缀）到初始化实体，声明流握手过程继续进行的任何条件。每一个条件采取元素的子元素的形式，可包含一个、多个或没有子元素。元素下的子元素的顺序可不固定。如果一个特殊的流特性被强制握手，此特性的定义需要遵循下面中的一种：（1）宜布此特性总是强制握手。（2）为接收实体标签特性指定一种方法作为此交互的强制-握手（如对于STARTTLS，通过为那些流特性在广播中包含一个空的元素来实现，但对于所有的流特性，这不是一个通用的格式）：为新的强制握手特性定义流特性就如同通过包含一个空的元素实现STARTTLS一样，这种方法是被推荐的。
消息要求：因为没有通用的格式来表明一个特性就是强制握手，一个不被初始化实体理解的特性可能被考患成接收实体的强制握手是有可能的，这就导致了流握手进程的失败。虽然那样的结果是无法预料的，工作组坚持认为那种通用格式不是必须的。由于安全性原因，初始化实体在特性的成功握手上发送一个新的初始化流头的某种流特性是有必要的（如所有例子中的TLS和当一个安全层可能被建立的例子中的SASL）。如果给定的流特性是正确的，在特性协商之后，这些特性的定义需要指定一个流的重启是被期望的。包含至少一个强制握手特性的一个元素指示流握手是不完全的和初始化实体应协商进一步的特性。
R:



一个元素也许包含超过一个强制握手特性。这意味着初始化实体在流握手进程的这个状态下可能在强制握手特性中选择。举一个例子，也许一个将来的技术将会扮演与TLS同样的功能，因此接收实体在流握手进程中的同一个阶段可能广播同时支持TLS和将来的技术。然而，这仅适用于流握手进程中的一个已给定的阶段，不适用于在不同阶段下的强制握手特性（如接收实体不会同时广播STARTTLS和5
YD/T2943-2015
SASL作为强制握手，或SASL和资源绑定作为强制握手，因为TLS在SASL之前需要被协商和SASL在资源绑定之前需要被协商）。
一个包含强制握手和自愿握手特性的元素表明握手是不完全的，但是初始化实体在它试图协商强制握手特性之前也许就完成了自愿握手。R:
从初始化实体的角度出发，总结前述规则，对流握手进程可用非规范的流程，如图2所示。打开TCP连接
发送初始流头
接收应答流头
可选的
空的？
5.1.4根元素属性
5.1.4.1概述
接收流特性
有自愿握手
也许握手任何
实体或空的
重新启动
强制握手
图2流握手流程
某些强制择手？
必须协商
个握手
YD/T2943-2015
根元素的属性描述如下。安全性注意事项：直到和除非流的保密性和完整性被通过4.2定义的TLS或一个同等的安全层（如SASLGSSAPI机制）所保护，否则在流头消息中所提供的属性可能被攻击者篡改。应用要求：根元素的属性没有被名字空间的前缀优先，其解释见[XML-NAMESI，缺省名字空间声明不会直接申请names属性；没有预定义属性的说明由其中出现的元素来确认。5.1.4.2From
“from'属性指定了一个正在发送流元素的XMPPID。对于互通网关之间的通信中的初始化流头消息，“from属性是互通网关配置的FQDN中的其中一个，例如，形如格式的一个JID。由于一个互通网关在XMPP网络中是一个“公共实体”，它应在流的保密性和完整性被通过TLS或一个同等的安全层保护之后包含“from'属性。I:
from-example.net'
to-'im.example.com
version=-'1.0\
xml:lang-'en'
xmlns-'jabber:server
xmlns:stream-\http:/etherx.jabber.org/streams>不管“from\属性是否被包含，每一个实体都应在和它交换XML节之前验证其它实体的ID。兼容性要求：基于IETFRFC3920的实现在任何流头消息（甚至是它的保密性和完整性是被保护的）中不包含“from地址是有可能的。一个实体接收那样的流头消息应该是自由的。5.1.4.3To
对于互通网关之间通信的初始化流头消息，初始化实体应包含to属性和应设置其值为初始化实体知晓的或接收实体期望服务的域部分。I:
[email protected]'
to=\im.example.com'
version=1.0*
xml:lang'en
xmlns-jabber:client
xmlns:stream=http://etherx.jabber.org/streams>对于互通网关之间通信中的响应流头消息，接收实体应在响应流头消息中包含一个“to属性，并设置其值为初始化流头消息的“from'属性中所定义的域部分。R:
from-im.example.com'
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。