XEP-0078：非SASL认证
2016-11-21 17:23 微服务专家 阅读(310) 评论(0) 编辑 收藏 举报XEP-0078：非SASL认证
| 抽象： | 这个文件规定了使用Jabber的Jabber的服务器和服务认证的协议：智商：AUTH命名空间。注意哦：本文规定的协议，取而代之的SASL认证的被取代，如RFC 3920 / RFC 6120规定，并且现在已经过时。 |
| 作者： | 彼得圣安德烈 |
| 版权： | ©1999至2016年XMPP标准基金会。请参见法律声明。 |
| 状态： | 过时的 |
| 类型： | 标准跟踪 |
| 版： | 2.5 |
| 最近更新时间： | 2008-10-29 |
警告：本文件已经被XMPP标准基金会废弃。不建议这里描述的协议的执行情况。开发者渴望类似的功能，宜实施取代这一个（如果有的话）的协议。
目录
1. 引言
2. 需求
3. 用例
3.1。 用户与服务器验证
4. 流功能
5. 错误处理
6. 截止日期
7. 安全考虑
8. IANA事项
9 XMPP注册事项
9.1。 协议命名空间
9.2。 流特点
10. XML架构
10.1。 胡言乱语：智商：AUTH
10.2。 流功能
附录
A：文档信息
B：作者信息
C：法律声明
D：关系到XMPP
E：讨论地点
F：需求一致性
G：备注
H：修订历史
1. 引言
注意：本文规定的协议已经过时，取而代之的SASL认证，其规定在RFC 3920[1]和RFC 6120[2]。
Jabber的技术早已包括了线协议，它允许客户端与服务器进行身份验证。[ 3 ]最初在Jabber社区中使用的方法利用了'jabber:iq:auth'的命名空间中，并已在互联网草案和其他地方的各种记录。当核心的Jabber协议是由IETF，形式化“jabber:iq:auth”协议是由简单身份验证和安全层（SASL）取代中规定RFC 4422 [ 5 ]。SASL被纳入XMPP，因为它通过使XMPP实体使用多种身份验证方法提供了更灵活的方法来验证（例如，平，DIGEST-MD5，外部的和匿名），其中一些比更安全“jabber:iq:auth“协议。
在'jabber:iq:auth“此处规定的协议现在已经过时。但是，因为它需要一定的时间对现有的实现和部署，升级到SASL，客户端和服务器软件的实现仍需要包括支持'jabber:iq:auth“，以实现互操作，而这个文件提供的规范文档'jabber:iq:auth“协议。尽管如此，执行SASL认证的部署，强烈推荐，因为'jabber:iq:auth“协议最终将完全废除。
2. 要求
在'jabber:iq:auth'命名空间必须有可能使一个Jabber客户端与服务器进行身份验证。尤其是，客户端必须为所使用的特定的认证方法的用户名和相应的凭据。这里所定义的方法是：
注意：本文档不包括所谓的“零知识”的方法; 这种方法并没有提供比摘要认证更强的安全性，因此是不必要的。
3. 使用案例
3.1 用户与服务器验证
为了确定需要与服务器的身份验证哪些字段，客户端应该先发送一个智商到达服务器。客户端不应该试图在必填字段猜测，因为所需数据的性质是受服务供应。
<iq type='get' to='shakespeare.lit' id='auth1'> <query xmlns='jabber:iq:auth'/> </iq>
<iq type='result' id='auth1'> <query xmlns='jabber:iq:auth'> <username/> <password/> <digest/> <resource/> </query> </iq>
如果客户端包含的用户名IQ-得到，但没有这样的用户名，在服务器不应该返回一个错误，而应该回归正常的认证领域（这有助于防止从发现未知用户该用户名是在使用）。如果服务器不支持非SASL认证（例如，因为它支持在定义只SASL认证RFC 6120），它必须返回<service-不可用/>错误。如果客户以前试图SASL认证但尝试失败，服务器必须返回<政策违反/>流错误（参见RFC 6120就流错误语法）。
无论是用户名和资源都需要使用客户端身份验证'jabber:iq:auth'命名空间; 如果有更多的灵活的身份验证和资源配置都需要，服务器应实现SASL验证和资源绑定中定义的RFC 6120（例如，使服务器能够提供的资源）。<用户名/>和<资源/>元素必须包括在服务器响应初始智商获取返回的智商结果，同时还必须包括在提供身份验证凭据时，由客户端发送的智商集。
前面节显示了服务器同时支持明文验证（通过<密码/>元素）和消化与SHA1加密的口令验证（通过<消化/>元素）。
因此，为了与本实施例的服务器成功验证，客户端必须提供用户名，一个资源，密码中的一个或消化。
<iq type='set' id='auth2'> <query xmlns='jabber:iq:auth'> <username>bill</username> <password>Calli0pe</password> <resource>globe</resource> </query> </iq>
明文密码是简单（很明显，映射到预定义的XML实体必须按照XML规范的第4.6节定义的规则进行转义字符，任何非US-ASCII字符必须编码根据XML流的编码按规定在RFC 6120，即，如在限定的UTF-8 的RFC 3269 [ 7 ]）。
在<消化/>元素的值必须根据下面的算法来计算：
- 串联从与密码服务器接收的流ID。[ 8 ]
- 根据SHA1算法，也就是说，SHA1（CONCAT（SID，密码）），散列连接字符串。
- 确保散列输出是十六进制格式，而不是二进制或Base64。
- 哈希输出转换为全部小写。
<iq type='set' id='auth2'> <query xmlns='jabber:iq:auth'> <username>bill</username> <digest>48fc78be9ec8f86d8ce1c39c320c97c21d62334d</digest> <resource>globe</resource> </query> </iq>
在<digest/>元素中所示的字符数据是当流ID是“3EE948B0'和口令是'Calli0pe'上面定义的算法以下的结果而产生的输出。
如果提供的凭证匹配服务器已知的，客户端将被成功认证。
<iq type='result' id='auth2'/>
替代地，验证可能会失败。失败的可能原因包括：
- 用户提供不正确的凭据。
- 有资源冲突（即，已经有与相同的用户名相关联的资源标识符活动会话）。推荐的行为是在服务器终止现有的会话，并创建新的之一; 然而，如果需要的话，导致一个冲突错误的新请求登录时，服务器可以提供相反的行为。
- 用户没有提供所有必需的信息（例如，没有提供用户名或资源）。
尽管RFC 6120规定了错误的节应该包括发送的原始XML，错误节由有资质的'jabber:iq:auth'命名空间不应该这样做，以便给出的信息的敏感性被交换。
<iq type='error' id='auth2'> <error code='401' type='auth'> <not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> </error> </iq>
<iq type='error' id='auth2'> <error code='409' type='cancel'> <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> </error> </iq>
<iq type='error' id='auth2'> <error code='406' type='modify'> <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> </error> </iq>
4. 流功能
RFC 6120流协商过程中定义了广告功能的支持方法。它可能需要为服务器做广告非SASL认证作为流功能的支持。报告中支持的命名空间的<stream：功能/>是“http://jabber.org/features/iq-auth”。在接收到流头由有资质的'胡言乱语：客户'命名空间，返回流的功能还应包括相关的流特性宣布非SASL认证支持的服务器。究竟当服务器通告IQ-AUTH流的特点是由实现或部署（例如，一台服务器只能成功后TLS协商做广告此功能或如果通道是通过旧SSL加密方法）。显然，这并不适用于那些不支持流功能（即不符合XMPP 1.0例如，旧服务器）的服务器。
例9. 广告非SASL认证作为流功能
<stream:features> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <mechanism>DIGEST-MD5</mechanism> <mechanism>PLAIN</mechanism> </mechanisms> <auth xmlns='http://jabber.org/features/iq-auth'/> </stream:features>
服务器不应该向另一台服务器公布SASL认证到（例如，如果初始流头限定命名空间是'jabber:server'）。
5. 错误处理
如本文所定义的，“闲聊：IQ：权威性'命名空间支持旧的（HTTP的样式）的错误代码和在指定的可扩展的错误类和条件的RFC 6120。一个兼容的服务器或服务的实现必须支持老式和新式的错误处理。一个兼容的客户端实现应该支持。
6. 截止日期
按照第8 XMPP扩展协议（XEP-0001） [ 9 ]，在本2004-10-20文件是先进到最终状态的理解是，将在六个月内到期。在2006-09-13，Jabber的理事会（现XMPP理事会）改变了这一文件已过时的状态。在Jabber理事会将审议这份文件，每半年以确定是否将其状态更改为作废或延长有效期限为延长六个月; 这个过程将一直持续到文件过时。为最新的到期日期，参考XEP信息块在该文件的开头。
7. 安全考虑
SASL认证的使用可以比'jabber:iq:auth“更安全的协议，根据该机制的SASL上使用。因为SASL提供了更大的灵活性和可提供更强的安全性，'jabber:iq:auth“协议现在已经过时。如果客户端和服务器实现SASL，他们必须喜欢SASL在'jabber:iq:auth“协议。如果客户端尝试使用认证通过返回<政策违反/>流错误的企图SASL认证的尝试失败，服务器必须拒绝“：智商权威性叽里咕噜”后的命名空间'胡言乱语：智商权威性“客户。
客户端的实现不能做出明文默认的机制，应该提醒的明文机制是不安全的用户。除非底层流加密（使用SSL或TLS）的明文机制不应该被用来和客户端已经验证服务器证书是由受信任的证书颁发机构签署。给定域中可以选择禁用明文登录，如果流不正确加密，或者完全禁用它们。如果一个客户端实现明文机构和一个服务器允许两个摘要机制和明文机构当信道加密是不使用时，一个降级攻击是可能的，其中一个人在这方面的中间人招数客户入显露用户的明文密码。
8. IANA考虑
该文档与没有互动互联网编号分配机构（IANA） [ 10 ]。
9. XMPP注册事项
10. XML模式
10.1 jabber:iq:auth
<?xml version='1.0' encoding='UTF-8'?> <xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' targetNamespace='jabber:iq:auth' xmlns='jabber:iq:auth' elementFormDefault='qualified'> <xs:annotation> <xs:documentation> NOTE WELL: Non-SASL Authentication via the jabber:iq:auth protocol has been superseded by SASL Authentication as defined in RFC 3920 and RFC 6120, and is now obsolete. For historical purposes, the protocol documented by this schema is defined in XEP-0078: http://www.xmpp.org/extensions/xep-0078.html </xs:documentation> </xs:annotation> <xs:element name='query'> <xs:complexType> <xs:sequence> <xs:element name='username' type='xs:string' minOccurs='0'/> <xs:choice> <xs:element name='password' type='xs:string' minOccurs='0'/> <xs:element name='digest' type='xs:string' minOccurs='0'/> </xs:choice> <xs:element name='resource' type='xs:string' minOccurs='0'/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>
10.2 流功能
<?xml version='1.0' encoding='UTF-8'?> <xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' targetNamespace='http://jabber.org/features/iq-auth' xmlns='http://jabber.org/features/iq-auth' elementFormDefault='qualified'> <xs:annotation> <xs:documentation> NOTE WELL: Non-SASL Authentication via the jabber:iq:auth protocol has been superseded by SASL Authentication as defined in RFC 3920 and RFC 6120, and is now obsolete. For historical purposes, the protocol documented by this schema is defined in XEP-0078: http://www.xmpp.org/extensions/xep-0078.html </xs:documentation> </xs:annotation> <xs:element name='auth' type='empty'/> <xs:simpleType name='empty'> <xs:restriction base='xs:string'> <xs:enumeration value=''/> </xs:restriction> </xs:simpleType> </xs:schema>
附录
附录A：文档信息
系列：XEP
编号：0078
发布者：XMPP标准基金会
状态： 过时的
类型： 标准跟踪
版本：2.5
更新时间：2008-10-29
批准机构：XMPP理事会
依赖关系：XMPP核心，RFC 3174
取代：无
下文：RFC 6120
短产品名称：IQ-auth的
架构：< http://www.xmpp.org/schemas/iq-auth.xsd >
源代码控制： HTML
本文的其它格式： XML PDF
附录B：作者信息
彼得圣安德烈
电子邮件： peter@andyet.net
JABBERID： stpeter@stpeter.im
URI： https://stpeter.im/
附录C：法律声明
版权
XMPP扩展协议的版权©1999 - 2016年的XMPP标准化基金会（XSF）。权限
特此授权，免费的，任何获得本协议（以下简称“规范”）的副本的人，尽量使用规范不受任何限制，包括但不限于执行软件程序的规范的权利，部署规格在网络服务，复制，修改，合并，发布，翻译，分发，或出售规格的副本，并允许向谁规格陈设这样做的人，受条件，上述版权通知和本许可声明应包括在所有副本或规范的重要部分。除非单独许可的，被重新分配修改的作品不得含有说明书关于作者误导性信息，名称，编号，或出版商，不得由作者声称的修改作品的代言，任何组织或项目其中作者属于，或XMPP标准基金会。担保免责声明
## WELL注：此规范提供的“原样”的基础，没有担保或任何形式的明示或暗示，包括条件，但不限于任何保证或条件的标题，非侵权，适销性或适用性特定用途的适用性。##责任限制
在任何情况下，任何法律，无论是因侵权（包括过失），合同或其他方式，除非以书面形式要求，适用的法律（如故意和重大过失行为）或同意，不得XMPP标准基金会或任何作者本规范的承担损害赔偿责任，包括所产生的，出，或与规格或执行，部署或其他用途的规范有关的任何性质的任何直接，间接，特殊，偶然或后果性损害（包括但不限于损害赔偿商誉损失，停工，电脑故障或失灵，或任何及所有其他商业损害或损失），即使已被告知XMPP标准基金会或作者此类损害的可能性。知识产权的一致性
XMPP扩展协议已完全遵守XSF的知识产权策略（副本里面可以发现<贡献http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/ >或获得通过写XMPP标准基金会，1899年温库普街，600套房，丹佛，CO 80202 USA）。附录D：关系到XMPP
可扩展消息处理现场协议（XMPP）在XMPP核心（RFC 6120）和XMPP IM（RFC 6121）规格的贡献由XMPP标准基金会的互联网标准程序，这是由互联网工程任务组按照管理规定符合RFC 2026在本文档中定义的任何协议已被开发的互联网标准程序以外，并且应被理解为扩展到XMPP而不是作为一个演进，开发或修改XMPP本身。
附录E：讨论地点
对于XMPP扩展协议讨论的主要场所是< standards@xmpp.org >讨论列表。
浅谈其他xmpp.org讨论列表也可能是适当的; 看< http://xmpp.org/about/discuss.shtml >的完整列表。
鉴于这XMPP扩展协议规范地引用了IETF技术，在<上讨论xsf-ietf@xmpp.org >列表也可能是适当的。
勘误表可以被发送到< editor@xmpp.org >。
附录F：需求一致性
本文档中使用的下列要求的关键字中的说明来解释RFC 2119：“必须”，“应该”，“要求”; “MUST NOT”，“不”; “应该”，“建议”; “不应该”，“不建议”; “五一”，“可选”。
附录G：备注
1。RFC 3920：扩展消息处理现场协议（XMPP）：核心< http://tools.ietf.org/html/rfc3920 >。
2。RFC 6120：扩展消息处理现场协议（XMPP）：核心< http://tools.ietf.org/html/rfc6120 >。
3。组件认证超出范围本文档，并且是单独指定的Jabber组件协议（XEP-0114） [ 4 ]。
4。XEP-0114：的Jabber组件协议< http://xmpp.org/extensions/xep-0114.html >。
5。RFC 4422：简单认证和安全层（SASL）< http://tools.ietf.org/html/rfc4422 >。
6。RFC 3174：美国安全散列算法1（SHA1）< http://tools.ietf.org/html/rfc3174 >。
7。RFC 3269：UTF-8，ISO 10646的转换格式< http://tools.ietf.org/html/rfc3269 >。
8。在摘要式身份验证，映射到预定义的XML实体密码字符不应被转义为它们是明文口令，但由于SHA-1散列算法的字节数组操作非US-ASCII字符必须被编码为UTF-8。
9。XEP-0001：XMPP扩展协议< http://xmpp.org/extensions/xep-0001.html >。
10。互联网编号分配机构（IANA）是唯一的参数值的互联网协议，如端口号和URI方案分配的中央协调。欲了解更多信息，请参见< http://www.iana.org/ >。
11。XMPP登记维护保留协议命名空间以及在由XMPP标准基金会批准的XMPP扩展协议的上下文中使用的参数登记列表。欲了解更多信息，请参阅< http://xmpp.org/registrar/ >。
附录H：修订历史
注：本规范的旧版本可能会提供在http://xmpp.org/extensions/attic/
版本2.5（2008-10-29）
每XMPP理事会表决，改变的状态已过时。
（PSA）2.4版（2008-01-30）
澄清采用SASL的背后的原因，并相应纠正安全方面的考虑。
（PSA）版本2.3（2006-09-13）
每Jabber的议会投票，改变的状态已过时。
（PSA）2.2版（2005-06-28）
在架构和纠正例如错误（用户名不是IQ-GET需要）。
（PSA）2.1版（2004-12-09）
改变应必须就SASL（RFC 3920）在叽里咕噜的优先级：智商：AUTH（XEP-0078）。
（PSA）2.0版（2004-10-20）
每Jabber的理事会，先进的地位，最终的投票。
（PSA）版本1.8（2004-10-18）
指定的广告IQ-AUTH流的特点是实现特定的; 在文中澄清了几个小问题。
（PSA）版本1.7（2004-07-27）
新增参考字符摘要式身份验证逃脱; 需要包容流功能，当服务器支持流的功能和它是安全的宣传非SASL认证。
（PSA）版本1.6（2004-07-21）
删除了对UTF-16，这是由XMPP核心不允许的; 除去参考字符转义的摘要式身份验证待定名单的讨论。
（PSA）版本1.5（2004-02-18）
增加了可选流功能。
（PSA）版本1.4（2004-02-03）
阐明了用户名和资源都需要进行身份验证。
（PSA）1.3版（2003-11-26）
新增XMPP错误处理。
（PSA）版本1.2（2003-11-06）
SASL失败后AUTH：智商：试图叽里咕噜的解决情况。
（PSA）版本1.1（2003年10月2日）
移动更改密码用例XEP-0077。
（PSA）版本1.0（2003-06-18）
每Jabber的议会投票，先进的地位草案。
（PSA）版本0.8（2003-06-18）
更改，以解决委员会的关注。
（PSA）版本0.7（2003-06-13）
增加了更改密码的用例; 添加了更多的细节，安全方面的考虑。
（PSA）版本0.6（2003-06-12）
新增消化例子; 澄清逃逸的要求; 进一步指明错误条件; 添加了更多的细节，安全方面的考虑。
（PSA）版本0.5（2003-06-06）
去除XMPP式的错误条件直到格式是稳定的。
（PSA）版本0.4（2003-05-30）
删除了“增强摘要”的内容，增加了有关有效期限的信息。
（PSA）版本0.3（2003-05-28）
增加了“增强消化”的方法。
（PSA）0.2版（2003-05-20）
轻微的编辑修改。
（PSA）0.1版（2003-04-10）
最初的版本。
（PSA）结束
