XEP-0115

来自Jabber/XMPP中文翻译计划

2010年6月23日 (三) 06:37How (讨论 | 贡献)的版本

本文的英文原文来自XEP-0115

XEP-0115: 实体能力

摘要: 本文定义了一个XMPP协议扩展, 用于广播和动态查询客户端,设备,或通用实体的能力. 为了最小化网络冲击, 传输机制采用标准的XMPP出席信息广播(从而防止和服务发现数据相关的数据轮询的需要), 能力信息可被缓存在单个会话中也可以贯穿多个会话,并且格式已经尽可能保持最小.

作者: Joe Hildebrand, Peter Saint-Andre, Remko Tronçon, Jacek Konieczny

状态: 草案

类型: 标准跟踪

版本: 1.5

最后更新日期: 2008-02-26

注意: 这里定义的协议是XMPP标准化基金会的一个草案标准.对本协议的执行是被鼓励的,也适于布署到生产系统,但是在它成为最终标准之前可能还会有一些变动.

绪论

动机

对于一个XMPP应用程序，经常需要(通常但不一定是一个客户端)根据从另一个应用收到的出席信息所了解到的能力采取不同的动作。例如：

根据其他实体的能力显示不同系列的图标。

不发送XHTML-IM[1]或者其他富文本给只支持纯文本的客户端比如手机。

只有当客户端支持Jingle[2] 和Jingle RTP Sessions [3]时，才允许VoIP的初始化

如果另一个用户客户端不支持SI File Transfer,那么不显示“发送文件”按钮。

基于声明的订阅者兴趣，过滤Publish-Subscribe [5] 通知。

过去，对于一些Jabber客户端，在登录了之后会发送服务发现\[6\]和软件版本\[7\]请求给每个收到出席信息的实体。disco/version流信息会过度的使用带宽在大规模情况下，不实用，特别是对于有很多联系人的用户。因此本文档定义了一个健壮的、可实现的解决方案：即，基于出席信息机制\[8\]交换实体能力信息。客户端不应该遵循旧的“disco/version流”行为，而应该使用在此处定义的实体能力。

如何工作

这一节提供了关于实体能力(“caps”)的友好介绍。

想象你就是莎士比亚作品中的朱丽叶，你的一个联系人，一个帅小伙罗密欧，现在上线了。他的客户端想要发布他的能力，通过在出席信息中加入含有指定属性的<c/>元素来发布能力。结果，你的客户端受到如下出席信息：

<presence from='romeo@montague.lit/orchard'>
  <c xmlns='http://jabber.org/protocol/caps' 
     hash='sha-1'
     node='http://code.google.com/p/exodus'
     ver='QgayPKawpkPSDYmwT/WM94uAlu0='/>
</presence>

“node”属性代表了罗密欧正使用的客户端软件。“ver”属性是一个指定的构造的字符串(被称为“验证”字符串)，代表了实体服务发现的标识(目录和类型在<http://www.xmpp.org/registrar/disco-categories.html>注册，同样，xml:lang和name是可选的)以及支持的特性(在<http://www.xmpp.org/registrar/disco-features.html>中注册，同样，可选的，扩展服务发现信息在<http://www.xmpp.org/registrar/formtypes.html>注册)。

此时，你的客户端根据'QgayPKawpkPSDYmwT/WM94uAlu0='字符串还不知道对方的能力。因此你的客户端发送服务发现来查询罗密欧，询问他的客户端能做什么。

<iq from='juliet@capulet.lit/chamber' 
    id='disco1'
    to='romeo@montague.lit/orchard' 
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='http://code.google.com/p/exodus#QgayPKawpkPSDYmwT/WM94uAlu0='/>
</iq>

应答是:

<iq from='romeo@montague.lit/orchard' 
    id='disco1'
    to='juliet@capulet.lit/chamber' 
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='http://code.google.com/p/exodus#QgayPKawpkPSDYmwT/WM94uAlu0='>
    <identity category='client' name='Exodus 0.9.1' type='pc'/>
    <feature var='http://jabber.org/protocol/caps'/>
    <feature var='http://jabber.org/protocol/disco#info'/>
    <feature var='http://jabber.org/protocol/disco#items'/>
    <feature var='http://jabber.org/protocol/muc'/>
  </query>
</iq>

此时，你的客户端知道声明版本字符串'QgayPKawpkPSDYmwT/WM94uAlu0='的联系人支持Multi-User Chat\[9\]以及其他罗密欧返回的特性，因为联系人事实上使用了和罗密欧同一个客户端的相同版本，相同的特性，插件，以及现在的客户端名称，就像(比如，相同的验证字符串的生成方法的输入)。你的客户端记录这些信息，所以不需要再显式地使用相同版本的字符串来查询联系人能力。例如:你的护士可以使用和罗密欧相同的客户端:

<presence from='nurse@capulet.lit/chamber'>
  <c xmlns='http://jabber.org/protocol/caps' 
     hash='sha-1'
     node='http://code.google.com/p/exodus'
     ver='QgayPKawpkPSDYmwT/WM94uAlu0='/>
</presence>

因此你了解到她也支持和罗密欧相同的特性。

另一方面,对于一个以下出席信息的人 ...

<presence from='benvolio@capulet.lit/230193'>
  <c xmlns='http://jabber.org/protocol/caps' 
     hash='sha-1'
     node='http://psi-im.org'
     ver='q07IKJEyjvHSyhy//CH0CxmKi8w='/>
</presence>

... 或者如下出席信息 ...

<presence from='bard@shakespeare.lit/globe'>
  <c xmlns='http://jabber.org/protocol/caps' 
     hash='sha-1'
     node='http://www.chatopus.com'
     ver='zHyEOgxTrkpSdGcQKH8EFPLsriY='/>
</presence>

... 你不知道联系人的客户端的能力除非你缓存了先前的实体能力信息；因此你需要再次通过服务发现查询能力。

假设

本文档做了几个假设：

花名册的联系人对于我正使用的客户端标识感兴趣。

我花名册上的联系人的客户端可能需要基于我的能力来构建用户界面。

社区的成员趋向集中使用少部分的客户端并使用少部分的实体能力。更特殊的，在花名册里多人使用相同客户端，他们相对地升级版本较慢(通常一年好几次，可能大部分一星期一次，肯定不是每分钟一次)。

一些客户端在不需要服务器与服务器连接的网络上运行，并且不需要通过HTTP访问Internet。

2个互相都不在对方花名册里的人互相聊天是有可能的。

客户端能力可能在交换出席信息的过程中改变，比如特性被允许或禁止。

要求

此处定义的协议满足以下要求：

客户端必须支持即使他们只支持XMPP Core \[11\], XMPP IM \[12\]和XEP-0030
客户端必须参与,即使他们所在的网络无法连接其他XMPP服务器，提供特定XMPP扩展的服务，或者HTTP服务器\[13\]。
客户端必有能力接收信息,即使没有查询他们通讯的每一个实体。
由于出席信息通常会广播给很多联系人，建议的扩展信息的字节数必须尽可能小。
必须能够编写一个XEP-0045服务实现用来单独传递给定的信息。
必须能够使用一个单独的出席信息会话来发布能力的变化。
为了完成以上工作而超过XMPP Core和XMPP IM定义的服务器基础架构不是必需的，尽管附加的服务器架构可以被用来出于优化目标。
在此定义的机制不仅限于客户端,但是对于服务器,组件或其他网络实体也必须是有用的。

协议

实体能力封装在<c/>元素中并且被'http://jabber.org/protocol/caps'限定。<c/>元素的属性如下。

表格 1: 属性

名称	定义	是否包含
ext	nametaokens集合制定了附加的特性；该属性是不鼓励的(参考本文档的“合法的格式”部分)	不鼓励的
hash	该哈希算法被用来生成验证字符串；参考关于哈希算法的“强制实现的技术”部分。	必需的
node	标识了软件的唯一的URI，典型的，URL可以是生产该软件的项目主页或者公司主页。*	必需的
ver	一个字符串,用于核查身份以及实体支持的特性. **	必需的

注意：'node'属性的值是推荐的，可以是找到软件产品的更多信息的HTTP URL，比如Psi客户端的URL"http://psi-im.org"；这允许应用程序为了该程序生成一个唯一字符串，它能够维护一个已知的实现的软件的列表(比如，通过disco#info接收到的URL的名称

- 注意：在这份说明的1.4版本之前，'ver'属性用来指出软件的发布版本；'ver'属性的值取决于在这里使用的向后兼容的算法，应用程序应该(SHOULD)适当的处理遗留格式。

认证字符串

生成方法

为了帮助防止实体信息的损坏，认证字符串的值必须(MUST)根据以下方法生成。

注意：所有排序操作必须(MUST)使用在9.3部分的RFC 4790\[14\]指定的"i;octet"集合来排序。

1. 初始化一个空的字符串 S 。

2. 先根据目录再根据类型来排序服务发现标识，然后再根据xml:lang(如果存在)，根据CATEGORY '/' [TYPE] '/' [LANG] '/' [NAME]格式化。注意每条斜杠都必须包含，即使TYPE, LANG,或者NAM没有被包含。

3. 对于每个标识，在'<'字符后添加'category/type/lang/name'到字符串S。

4. 排序支持的服务发现特性\[17\]。

5. 对于每个特性，在'<'字符后添加特性到字符串S。

6. 如果服务发现信息响应中包含XEP-0128数据表单，那么根据FORM_TYPE排序表单(换言之，根据<value/>元素的字符数据)。

7. 对于每个扩展的服务发现信息表单：

在'<'字符后面，添加FORM_TYPE字段<value/>元素的XML字符。
根据"var"属性的值排序字段
对于每个字段：

在'<'字符之后添加"var"属性的值。

根据<value/>元素的xml字符排序。

对于每个<value/>元素，在'<'字符后，添加XML字符。

8. 确保S是使用UTF-8编码的(RFC 3269\[18\])。

9. 使用'hash'属性指定的算法计算S的认证字符串(比如，RFC 3174\[19\]定义的SHA-1)。哈希值必须(MUST)根据二进制输出和RFC 4648\[20\]第四部分指定的Base64编码生成(注意：Base64输出不许(MUST NOT)包含空白字符和必须(MUST)设置填充字符为0)。\[21\]

简单的生成示例

考虑一个实体，它的目录是"client"，服务发现类型是"pc"，服务发现名称是"Exodus 0.9.1"，支持的特性是"http://jabber.org/protocol/disco#info","http://jabber.org/protocol/disco#items", 和"http://jabber.org/protocol/muc"。使用SHA-1算法，认证字符串就会按如下步骤生成(注意：在认证字符串的换行符是用来提高可读性)：

S =
只有一个标识："client/pc"
S = 'client/pc//Exodus 0.9.1<'
排序特性："http://jabber.org/protocol/caps", "http://jabber.org/protocol/disco#info", "http://jabber.org/protocol/disco#items", "http://jabber.org/protocol/muc"。
S = 'client/pc//Exodus 0.9.1<http://jabber.org/protocol/caps<http://jabber.org/protocol/disco#info< http://jabber.org/protocol/disco#items<http://jabber.org/protocol/muc<'
S = 'client/pc//Exodus 0.9.1<http://jabber.org/protocol/caps<http://jabber.org/protocol/disco#info< http://jabber.org/protocol/disco#items<http://jabber.org/protocol/muc<’
ver = QgayPKawpkPSDYmwT/WM94uAlu0=

复杂的生成示例

考虑一个复杂的例子，实体包含了几个标识(用不同的语言表示的服务发现)，同样是根据XEP-0128格式的扩展信息。

<iq from='benvolio@capulet.lit/230193'>
    id='disco1'
    to='juliet@capulet.lit/chamber' 
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='http://psi-im.org#q07IKJEyjvHSyhy//CH0CxmKi8w='>
    <identity xml:lang='en' category='client' name='Psi 0.11' type='pc'/>
    <identity xml:lang='el' category='client' name='Ψ 0.11' type='pc'/>
    <feature var='http://jabber.org/protocol/caps'/>
    <feature var='http://jabber.org/protocol/disco#info'/>
    <feature var='http://jabber.org/protocol/disco#items'/>
    <feature var='http://jabber.org/protocol/muc'/>
    <x xmlns='jabber:x:data' type='result'>
      <field var='FORM_TYPE' type='hidden'>
        <value>urn:xmpp:dataforms:softwareinfo</value>
      </field>
      <field var='ip_version'>
        <value>ipv4</value>
        <value>ipv6</value>
      </field>
      <field var='os'>
        <value>Mac</value>
      </field>
      <field var='os_version'>
        <value>10.5.1</value>
      </field>
      <field var='software'>
        <value>Psi</value>
      </field>
      <field var='software_version'>
        <value>0.11</value>
      </field>
    </x>
  </query>
</iq>

使用SHA-1算法，认证字符串将会按如下步骤生成(注意：认证字符串中的换行符只是为了提高可读性)：

S =
2个标识符："client/pc/Psi"和"client/pc/Ψ"
S = 'client/pc/el/Ψ 0.11<client/pc/en/Psi 0.11<’
排序特性："http://jabber.org/protocol/caps", http://jabber.org/protocol/disco#info", "http://jabber.org/protocol/disco#items", "http://jabber.org/protocol/muc"。
S = 'client/pc/el/Ψ 0.11<client/pc/en/Psi 0.11<http://jabber.org/protocol/caps<http://jabber.org/protocol/disco#info<

http://jabber.org/protocol/disco#items<http://jabber.org/protocol/muc<'.

根据FORM_TYPE对扩展服务发现表单排序(这里只有一个："urn:xmpp:dataforms:softwareinfo")。
S = 'client/pc/el/Ψ 0.11<client/pc/en/Psi 0.11<http://jabber.org/protocol/caps<http://jabber.org/protocol/disco#info<

http://jabber.org/protocol/disco#items<http://jabber.org/protocol/muc<urn:xmpp:dataforms:softwareinfo<’

根据var对字段排序并且添加值："ip_version<ipv4<ipv6", "os<Mac", "os_version<10.5.1", "software<Psi", "software_version<0.11"。
S = 'client/pc/el/Ψ 0.11<client/pc/en/Psi 0.11<http://jabber.org/protocol/caps<http://jabber.org/protocol/disco#info<

http://jabber.org/protocol/disco#items<http://jabber.org/protocol/muc<urn:xmpp:dataforms:softwareinfo< ip_version<ipv4<ipv6<os<Mac<os_version<10.5.1<software<Psi<software_version<0.11<’

ver = q07IKJEyjvHSyhy//CH0CxmKi8w=

处理方法

当实体收到根据本文档定义的生成方法生成的认证字符串中的'ver'属性值时，他必须(MUST)根据如下方法处理'ver'：

1. 验证<c/>元素包含的hash属性。如果没有包含，忽略'ver'或者将其视作遗留格式生成的(如果支持的话)。

2. 如果'hash'属性的值不匹配应用程序的支持的功能，那么按如下步骤处理：

发送服务发现请求给生成该哈希的实体。
从生成该哈希的实体接收服务发现信息。
不要按上面提到的进行验证或者在全局范围内缓存验证字符串；相反的，应用程序应该(SHOULD)仅将发现的标识+特性和生成实体的JabberID关联

3. 如果'hash'值与应用程序的支持的哈希函数匹配，那么根据如下步骤验证该认证字符串：

发送服务发现请求给生成字符串的实体。
从生成字符串的实体那接收服务发现信息。
如果响应中在同一个category/type/lang/name中包含了超过一个服务发现标识，那么考虑该完整的响应的格式是不正确的。
如果响应格式是正确的，根据服务发现信息和Generation Method重新构建本地的哈希值
如果收到的值和重新构建的哈希值匹配，那么对于和其交流的所有的JabberID的应用程序必须(MUST)视其已被验证并且应该(SHOULD)全局缓存。
如果收到的值和重新构建的哈希值不匹配，那么应用程序必须(MUST)将结果是为验证失败的并且不能(MUST NOT)全局缓存该验证字符串；然而，它应该(SHOULD)检查生成和发送该值的实体的服务发现标识和支持的特性。

用例

声明能力

生成字符串的实体每次发送出席信息时，该出席信息包含了一个实体标识符('node'属性)和identity和feature标识符('ver'属性)。所以服务器会记录最后一次出席信息以应答探测，客户端应该(SHOULD)在其发送的每个出席通知中包含实体能力。

例子1. 带有能力的出席信息

<presence>
  <c xmlns='http://jabber.org/protocol/caps'
     hash='sha-1'
     node='http://code.google.com/p/exodus'
     ver='QgayPKawpkPSDYmwT/WM94uAlu0='/>
</presence>

如果在生成实体的出席信息会话期间，支持的特性改变了(例如，用户安装了一个插件的更新版本)，应用程序必须(MUST)重新计算认证字符串并且应该(SHOULD)发送新的出席信息广播。

例子2. 重新计算ver属性出席信息

<presence>
  <c xmlns='http://jabber.org/protocol/caps'
     hash='sha-1'
     node='http://code.google.com/p/exodus'
     ver='66/0NaeaBKkwk85efJTGmU47vXI='/>
</presence>

发现服务

应用程序(请求的实体)可以通过发送disco#info请求(参考XEP-0030)给生成能力信息的实体(生成的实体)来了解实体支持的特征。

例子3. Disco#info请求

<iq from='juliet@capulet.lit/balcony' 
    id='disco1'
    to='romeo@montague.lit/orchard' 
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='http://code.google.com/p/exodus#QgayPKawpkPSDYmwT/WM94uAlu0='/>
</iq>

disco#info请求是由请求实体发送到生成实体。'to'属性的值必须(MUST)是生成实体的精确JID，对于客户端是全JID<localpart@domain.tld/resource>。

注意：生成实体不应该(SHOULD NOT)在disco#items响应中的实体列表中包"caps node"；换言之，是一种虚拟的能力节点，不是一个为了服务发现目的的实体有关的确实的节点。

disco的'node'属性必须(MUST)包含了向后兼容的特性。'node'属性的值应该(SHOULD)是将实体提供的'node'属性的值(比如，"http://code.google.com/p/exodus")和"#"字符和生成实体提供的'ver'属性的值(比如，"QgayPKawpkPSDYmwT/WM94uAlu0=")连接后生成的。

生成实体返回它所支持的所有能力。

例子4. Disco#info响应

<iq from='romeo@montague.lit/orchard' 
    id='disco1'
    to='juliet@capulet.lit/balcony' 
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='http://code.google.com/p/exodus#QgayPKawpkPSDYmwT/WM94uAlu0='>
    <identity category='client' type='pc'/>
    <feature var='http://jabber.org/protocol/disco#info'/>
    <feature var='http://jabber.org/protocol/disco#items'/>
    <feature var='http://jabber.org/protocol/muc'/>
  </query>
</iq>

注意：如果生成字串的实体结合了不同xml:lang的标识符在它的认证字符串中，它必须(MUST)返回所有标识符，即使请求中指定了xml:lang。

流特性

服务器可能(MAY)在流特性中包含实体能力，所以连接客户端和对等点服务器的时候不需要在每次连接时发送服务发现请求

例子5. 包含了能力的流特性

<stream:features>
 
  <c xmlns='http://jabber.org/protocol/caps'
     hash='sha-1'
     node='http://jabberd.org'
     ver='ItBTI0XLDFvVxZ72NQElAzKS9sU='>
 
</stream:features>

当一个已连接的客户端或者对等服务器发送一个服务发现信息请求以确定那个通过流特性来发布能力的服务器的实体能力时，请求实体必须(MUST)发送disco#info请求给流响应的'from'属性的提供的服务器JID('from'属性在RFC 3920推荐，在rfc3920bis中被要求)。为了允许这样功能，发布支持实体能力的服务器必须(MUST)根据rfc3920bis，在初始流响应中提供一个'from'地址。

确定是否支持

如果一个实体支持实体能力协议，它必须(MUST)在服务发现请求中返回一个'http://jabber.org/protocol/caps'的特性来反映该事实。

例子6. 服务发现请求

<iq from='romeo@montague.lit/orchard'
    id='disco2'
    to='juliet@capulet.lit/balcony'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

例子7. 服务发现响应

<iq from='juliet@capulet.lit/balcony'
    id='disco2'
    to='romeo@montague.lit/orchard'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <feature var='http://jabber.org/protocol/caps'/>
    ...
  </query>
</iq>

如果服务器支持Caps Optimization功能，它还必须(MUST)在服务发现请求中返回'http://jabber.org/protocol/caps#optimize'特性。

例子8. 服务发现请求

<iq from='juliet@capulet.lit/balcony'
    id='disco3'
    to='capulet.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

例子9. 服务发现响应

<iq from='capulet.lit'
    id='disco3'
    to='juliet@capulet.lit/balcony'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <feature var='http://jabber.org/protocol/caps#optimize'/>
    ...
  </query>
</iq>

实现注意

哈希算法支持

应用程序应该(SHOULD)维护它支持的哈希算法列表，必须(MUST)包含文本档强制实现的技术中的算法或者算法列表。

缓存

对于一个能处理实体能力的应用程序,在单次出席信息会话中缓存认证字符串和发现的identity+features之间的关联关系是被推荐的(RECOMMENDED)。这可以在一次会话中省去不必要的服务发现请求。

对于一个应用程序，在跨越多个出席会话中缓存关联是被推荐的(RECOMMENDED)，因为可以在会话开始时避免不必要的服务发现请求。

直接出席信息

如果2个实体交换消息，但是没有正常的交换出席出席消息(即，出席消息的订阅)，实体可能(MAY)选择直接发送出席消息给对方，出席消息应该(SHOULD)标注同样的实体能力的信息就如广播的出席消息一样。除非收到对方的实体能力的消息，否则应用程序必须(MUST)假设对方不支持实体能力。

能力优化

管理已连接的客户端的出席会话的服务器可能(MAY)优化出席通知，去除冗余的能力标注。因此，出席通知的接收者不能(MUST NOT)期望在每个收到的出席通知中收到标注。如果服务器优化了实体能力，它必须(MUST)确保订阅了出席信息的双方收到的第一条出席信息中包含标注(比如，带有'ver'属性的更新出席信息发送给所有订阅者)。

如果一个已连接的客户端确定它的客户端支持能力优化，它可能(MAY)选择只在第一次出席消息中发送能力信息，同样在能力变化时也会发送。

安全事项

强制实现的技术

SHA-1哈希算法是强制实现的。所有协议的实现都必须(MUST)支持SHA-1。

具体的实现可能(MAY)支持其他算法。任何其他的算法都应该(SHOULD)在IANA Hash Function Textual Names Registry 中注册。

在未来，XMPP理事会可能出于谨慎考虑，如果SHA-1被确认为容易受到原像攻击，会修改强制实现的哈希算法。

原像攻击

就如RFC 4270描述的，使用如MD5或者SHA-1算法输出的协议容易受到碰撞攻击或者原像攻击或者同时受到2种攻击。因为只是在实体能力中使用哈希输出，本协议将不会受到碰撞攻击，即使使用的算法容易受到碰撞攻击。然而，如果使用的哈希函数受到了原像攻击，那么协议就可能受到原像攻击。

理论上，原像攻击将会采用以下其中的一种方式：

对于已知的'ver'属性的值V，那么攻击者就能找到一个输入消息，比如哈希值X而不是V(这就是第一次原像攻击)

对于已知的输入消息S,攻击者就能够找到S’而不是V（这就是“第二次原像攻击”）。

在实践中，原像攻击为了能在实体能力协议中起到作用，会采用以下方法：

被使用的哈希算法以后不仅是理论上，在实际中也是容易遭到第一次或者第二次原像攻击(比如，对现在来说MD5或者SHA-1算法还不容易遭到攻击，但是以后可能会容易遭到攻击)。
攻击者可能找到匹配V或者S的哈希值的输入消息X或者S’，该值可能不是根据实体能力计算出的哈希值，该值相对较短并且容易破解，这也暗示了现存的函数不太容易受到原像攻击除了相对较长的输入消息(255顺序块)。
输入讯息 X 或 S' 将需要符合S的结构, 如认证字符串中定义的，包括服务发现标识的排序，以及服务发现特性标识的排序，由'<'分隔的字符以及使用"i;octet"集合的排序规则。
输入的信息X 或 S'将需要让它们看起来象不支持一个理想的特性(例如,点对点加密),即使其他实体和它的hash 同样是V，但是实际上是支持这个特性的(也就是说,攻击者需要返回一组吻合X或S‘ 的服务发现标识和特性,并且用这个似是而非的冬冬通过XMPP联系实体),或看起来它支持某个特性,即使其他和它的hash同为V的实体实际上不支持.
攻击者将需要宣传这个哈希V, 在其他一些拥有真正的输入讯息S的实体广播包含有关实体能力数据的出席信息并提供真正的服务发现应答之前（因此，攻击者可能需要颠覆特定软件的开发过程或颠覆名字空间的XMPP注册项的发行过程，或两者）。

在可预见的将来，攻击者可满足所有前述条件，似乎极不可能。不过， XMPP理事会会继续监察强制实现的哈希函数的密码的状态，以及那个函数可能的任何漏洞，以及可能会导致对实体能力协议的实际威胁。如果并且当它能现实的（或甚至可能的）开展有效的原像攻击实体能力协议， XMPP理事会将考虑更新此规格把强制实现的哈希算法改成一个更安全的技术。

能力毒药

坚持以本文的"认证字符串"章节所定义的方法来生成和处理'ver'属性，有助于防范恶意或不当实施实体所导致的实体能力信息毒药。

如果'ver'属性的值是一个这里所定义的认证字符串（即，如果'ver'属性不是根据遗留格式生成的），列入'hash'属性是必需的。明确知道'ver'属性的值是一个认证字符串，使得接收者避免无效或中毒的哈希的杂散通知。

信息暴露

利用实体的能力，攻击者可能更容易发起针对某些特定应用的攻击，因为攻击者就可以更容易确定客户端的类型以及其能力。不过，由于大多数客户端回应服务发现和软件版本的请求都不需要进行访问控制检查，所以并没有增加新的威胁。实体想限制访问能力信息，应使用基于服务器的隐私规则\[28\] ，以确定适当的通信阻断（例如，一个实体可能会选择只允许从“受信任”的实体发送的IQ请求，如那些与他们互相订阅了了出席信息的实体）; 不过，请注意，这样的限制可能不兼容直接的出席信息。

IANA事项

本文和(IANA)没有交互.

XMPP注册事项

协议命名空间

The XMPP Registrar [30] includes 'http://jabber.org/protocol/caps' in its registry of protocol namespaces (see <http://www.xmpp.org/registrar/namespaces.html>).

服务发现特性

The XMPP Registrar shall include "http://jabber.org/protocol/caps#optimize" in its registry of service discovery features (see <http://www.xmpp.org/registrar/disco-features.html>).

XML Schema

<?xml version='1.0' encoding='UTF-8'?>
 
<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://jabber.org/protocol/caps'
    xmlns='http://jabber.org/protocol/caps'
    elementFormDefault='qualified'>
 
  <xs:annotation>
    <xs:documentation>
      The protocol documented by this schema is defined in
      XEP-0115: http://www.xmpp.org/extensions/xep-0115.html
    </xs:documentation>
  </xs:annotation>
 
  <xs:element name='c'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='ext' type='xs:NMTOKENS' use='optional'/>
          <xs:attribute name='hash' type='xs:NMTOKEN' use='required'/>
          <xs:attribute name='node' type='xs:string' use='required'/>
          <xs:attribute name='ver' type='xs:string' use='required'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>
 
  <xs:simpleType name='empty'>
    <xs:restriction base='xs:string'>
      <xs:enumeration value=''/>
    </xs:restriction>
  </xs:simpleType>
 
</xs:schema>

遗留格式

在本协议的1.4版之前, 'ver'属性的生成方法是不同的, 'ext'属性的使用更广泛, 'hash'属性则没有. 为了保护历史, 本协议的 1.3版收藏在<http://www.xmpp.org/extensions/attic/xep-0115-1.3.html>. 为了遗留格式的向后兼容, 'node'属性是必需的(REQUIRED)并且'ext'属性可以(MAY)被包括.

一个应用可以通过检查出席信息的'hash'属性(它在当前格式中是必需的)来确定是否使用遗留格式.

如果一个可处理实体能力的应用支持遗留格式,它应该(SHOULD)检查 'node', 'ver', 和 'ext' 综合起来是否和本协议的1.3版相符, 并且可以(MAY)缓存结果.

如果一个可处理实体能力的应用不支持遗留格式, 它应该完全忽略'ver'值(因为这个值无法认证) 并且不应该(SHOULD NOT)缓存它, 因为应用无法通过检查哈希值来验证其标识和特性.

致谢

感谢 Rachel Blackman, Dave Cridland, Richard Dobson, Olivier Goffart, Sergei Golovan, Justin Karneges, Ralph Meijer, Ian Paterson, Kevin Smith, Tomasz Sterna, Michal Vaner, and Matt Yacobucci for comments and suggestions.

附录

附录A:文档信息

系列：XEP

序号：0115

发布者：XMPP标准基金会

状态：草案

类型：标准跟踪

版本：1.5

最后更新：2008-02-26

批准机构：XMPP理事会

依赖标准：XMPP Core, XMPP IM, XEP-0030

替代标准：无

被替代标准：无

缩略名：caps

XML架构(Schema): <http://www.xmpp.org/schemas/caps.xsd>

原文控制： HTML RSS

本文的其它格式： XML PDF

附录B:作者信息

Joe Hildebrand

Email: jhildebrand@jabber.com

JabberID: hildjj@jabber.org

Peter Saint-Andre

Email: stpeter@jabber.org

JabberID: stpeter@jabber.org

URI: <https://stpeter.im/>

Remko Tronçon

URI: <http://el-tramo.be/>

Jacek Konieczny

Email: jajcus@jajcus.net

JabberID: jajcus@jabber.bnet.pl

附录C:法律通告

版权

XMPP扩展协议的版权(1999-2008)归XMPP标准化基金会(XSF)所有.

权限

特此授权,费用全免,对任何获得本协议副本的人,对使用本协议没有限制,包括不限制在软件程序中实现本协议,不限制在网络服务中布署本协议,不限制拷贝,修改,合并,发行,翻译,分发,转授,或销售本协议的副本,被允许使用本协议做了以上工作的人士,应接受前述的版权声明和本许可通知并且必须包含在所有的副本或实质性部分的规格中.除非单独的许可，被重新分发的修改工作，不得含有关于作者，标题，编号，或出版者的规格的误导性资料，并不得宣称修改工作是由本文的作者，作者所属的任何组织或项目，或XMPP标准基金会签注。

免责声明'

## 特别注意：本协议是提供的“原样”的基础，没有担保或任何形式的条件，明示或暗示，包括，但不限于任何担保或关于名称，非侵权性，适销性或适合作某一特定目的的条件. ##

责任限制

在任何情况下以及没有任何法律规定时，不论是侵权行为（包括疏忽），合同或其它方面，除非根据适用法律的要求（如蓄意和有严重疏忽行为）或以书面形式同意，XMPP标准基金会或任何作者不对本协议所造成的损失承担责任，包括任何直接，间接，特殊，偶发，或任何从本协议出，入，连接的字符产生的或实现，布署或其他对本协议的使用导致的相应的损害赔偿（包括但不限于善意的损失，停止作业，电脑失灵或故障，或任何和所有其他商业损害或损失），即使XMPP标准基金会或作者已被告知此类损害的可能性。

知识产权的一致性

XMPP扩展协议完全遵守XSF的知识产权策略(可在<http://www.xmpp.org/extensions/ipr-policy.shtml>找到副本或写信给XMPP标准基金会, 1899 Wynkoop Street, Suite 600, Denver, CO 80202 USA).

附录D:和XMPP的关系

可扩展的消息和出席信息协议 (XMPP) 定义于 XMPP Core (RFC 3920) 和 XMPP IM (RFC 3921) 规范里，由 XMPP标准基金会贡献到由依据RFC 2026成立的互联网工程人物组管理的互联网标准流程 Internet Standards Process. 本文定义的任何协议已在互联网标准流程之外开发，并且被理解为 XMPP 的扩展而不是一个XMPP本身的演化, 开发, 或修改.

附录E:讨论地点

主要的XMPP扩展协议讨论地点是 <standards@xmpp.org> 讨论列表.

在 xmpp.org 的其它讨论列表中的讨论可能也有合适的; 所有的列表见 <http://xmpp.org/about/discuss.shtml> .

勘误表可以发送邮件到 <editor@xmpp.org>.

附录F:需求一致性

以下用于本文的需求关键字的解释见于 RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

附录G:备注

XEP-0071: XHTML-IM <http://www.xmpp.org/extensions/xep-0071.html>.
XEP-0166: Jingle <http://www.xmpp.org/extensions/xep-0166.html>.
XEP-0167: Jingle RTP Sessions <http://www.xmpp.org/extensions/xep-0167.html>.
XEP-0096: SI File Transfer <http://www.xmpp.org/extensions/xep-0096.html>.
XEP-0060: Publish-Subscribe <http://www.xmpp.org/extensions/xep-0060.html>.
XEP-0030: Service Discovery <http://www.xmpp.org/extensions/xep-0030.html>.
XEP-0092: Software Version <http://www.xmpp.org/extensions/xep-0092.html>.
Entity capabilities is not limited to clients, and can be used by any entity that exchanges presence with another entity, e.g., a gateway. However, this specification mainly uses the example of clients.
XEP-0045: Multi-User Chat <http://www.xmpp.org/extensions/xep-0045.html>.
The string can be relied upon because of how it is generated and checked, as explained later in this document.
RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc3920>.
RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc3921>.
These first two requirements effectively eliminated XEP-0060 as a possible implementation of entity capabilities.
RFC 4790: Internet Application Protocol Collation Registry <http://tools.ietf.org/html/rfc4790>.
A registry of service discovery identities is located at <http://www.xmpp.org/registrar/disco-categories.html>.
The combination of category, type, and xml:lang forms a unique combination, so it is not necessary to also sort by name (the name merely provides some human-readable text associated with a category/type/lang).
A registry of service discovery features is located at <http://www.xmpp.org/registrar/disco-features.html>.
RFC 3269: UTF-8, a transformation format of ISO 10646 <http://tools.ietf.org/html/rfc3269>.
RFC 3174: US Secure Hash Algorithm 1 (SHA1) <http://tools.ietf.org/html/rfc3174>.
RFC 4648: The Base16, Base32, and Base64 Data Encodings <http://tools.ietf.org/html/rfc4648>.
The OpenSSL command for producing such output with SHA-1 is "echo -n 'S' | openssl dgst -binary -sha1 | openssl enc -nopad -base64".
RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc3920>.
rfc3920bis: proposed revisions to Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/draft-saintandre-rfc3920bis>. (work in progress)
IANA registry of Hash Function Textual Names <http://www.iana.org/assignments/hash-function-text-names>.
The XMPP Council is a technical steering committee, authorized by the XSF Board of Directors and elected by XSF members, that approves of new XMPP Extensions Protocols and oversees the XSF's standards process. For further information, see <http://www.xmpp.org/council/>.
RFC 4270: Attacks on Cryptographic Hashes in Internet Protocols <http://tools.ietf.org/html/rfc4270>.
The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <http://www.xmpp.org/registrar/>.
XEP-0016: Server-Based Privacy Rules <http://www.xmpp.org/extensions/xep-0016.html>.
The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <http://www.xmpp.org/registrar/>.

附录H:修订历史

注意: 本协议的旧版本可能在 http://xmpp.org/extensions/attic/ 还可用

Version 1.5 (2008-02-26)

Defined SHA-1 as mandatory to implement

Specified that inclusion of hash attribute is required

Defined the nature of possible preimage attacks

More clearly specified security considerations

More clearly specified implementation notes

Modified generation method to incorporate service discovery extensions

More clearly specified processing method

Clarified meaning and construction of caps node attribute and disco node attribute

Specified that node attribute shall be included in disco#info request for backwards-compatibility

Clarified handling of the legacy format to assist developers

Added service discovery feature for caps optimization to prevent confusion regarding server support of caps vs. caps optimization

(jjh/psa)

Version 1.4 (2007-08-13)

In response to persistent security concerns over caps poisoning, redefined ver attribute to be a hash of the service discovery identity and features in a way that is backwards-compatible with the legacy format.

(psa/jk/jjh)

Version 1.3 (2007-04-10)

Added developer-friendly introduction; specified that ext names must be stable across application versions; further clarified examples; added stream feature

use case; removed message example (send directed presence instead).

(psa/rt/jjh)

Version 1.2 (2007-02-15)

Clarified motivation and handling of service discovery requests.

(psa)

Version 1.1 (2004-10-29)

Clarified meaning of service discovery results for client#ver and client#ext.

(psa)

Version 1.0 (2004-08-01)

Per a vote of the Jabber Council, advanced status to Draft.

(psa)

Version 0.7 (2004-06-29)

Added several items to the Security Considerations; clarified naming requirements regarding 'node', 'ver', and 'ext' attributes.

(jjh/psa)

Version 0.6 (2004-04-25)

Made a number of editorial adjustments.

(psa)

Version 0.5 (2004-01-05)

Specified that the protocol can be used whenever presence is used (e.g., by gateways); improved the XML schema; made several editorial adjustments.

(psa)

Version 0.4 (2003-09-04)

IQ eets must be to a resource, since they are intended to go to a particular session.

(jjh)

Version 0.3 (2003-09-02)

Servers MUST strip extras changed to MAY, due to implementer feedback.

(jjh)

Version 0.2 (2003-08-28)

Add more clarifying assumptions and requirements, make it clear that clients don't have to send capabilities every time if the server is optimizing.

(jjh)

Version 0.1 (2003-08-27)

Initial version.

(jjh)

结束

XEP-0115

目录

绪论

动机

如何工作

假设

要求

协议

认证字符串

生成方法

简单的生成示例

复杂的生成示例

处理方法

用例

声明能力

发现服务

流特性

确定是否支持

实现注意

哈希算法支持

缓存

直接出席信息

能力优化

安全事项

强制实现的技术

原像攻击

能力毒药

信息暴露

IANA事项

XMPP注册事项

协议命名空间

服务发现特性

XML Schema

遗留格式

致谢

附录

附录A:文档信息

附录B:作者信息

附录C:法律通告

附录D:和XMPP的关系

附录E:讨论地点

附录F:需求一致性

附录G:备注

附录H:修订历史

查看

个人工具

导航

XMPP资源

搜索

工具箱