xmpp协议5
内容提示：
* Use of SASL //简单验证和安全层的应用
1. Overview //概述
2. Narrative //详述
3. SASL //定义
4. SASL //错误
5. Client-to-Server Example //客户端到服务器的例子
6. Server-to-Server Example //服务器到服务器的例子
* Resource Binding //资源绑定
6.1. 概述
XMPP包含一个用于认证流的方法，该方法依靠一个特定于XMPP的SASL协议的profile。SASL提供了一个通用的方法，用于给基于连接的协议添加认证支持，而XMPP为SASL使用了一个通用的XML命名空间profile，其与SASL的profile的必要条件相一致。
应用以下规则：
1. 如果SASL协商发生在两个服务器之间，通信不能（MUST NOT）继续，直到服务器所持有的DNS主机名被确定（参见14.4.节： 服务器到服务器通信）。
2. 如果初始实体能够进行SASL协商，它必须（MUST）在初始流header中包含一个值至少设置为“1.0”的‘version’属性。
3. 如果接收实体能够进行SASL协商，在回应从初始实体发来的开的流标识的流中，它必须（MUST）在一个<mechanisms/>元素中注册一个或多个认证机制，该<mechanisms/>元素在‘urn:ietf:params:xml:ns:xmpp-sasl’命名空间下。
4. 在SASL协商期间，实体不能（MUST NOT）在流的根元素间发送任何空字符（matching production [3] content of XML）来作为元素的间隔（在后面的TLS例子中出现的任何空字符只是为了可读性）；这个禁令有助于确保彻底的安全层的字节精确度。
5. 在SASL协商期间使用的XML元素中所包含的任何XML字符数据必须（MUST）使用base64进行编码，其中的编码技术在RFC 3548[BASE64]第3部分的定义中。
6. 如果被选的SASL机制支持“simple username”这样的（例如，DIGEST-MD5和CRAM-MD5机制支持，而EXTERNAL和GSSAPI机制不支持），在认证期间，初始实体应该（SHOULD）提供在S/S通信的情况中作为发送域（IP地址或包含于域标识符中的完全限定的域名）的简单用户名，或者在C/S通信的情况中它所注册的帐户名（一个XMPP节点标识符中包含的用户名或节点名）。
7. 如果初始实体希望代表另一个实体起作用，且所选择的SASL机制能够支持对一个授权实体的的转播，初始实体必须（MUST）在SASL协商期间提供一个授权实体。如果初始实体没想要代表其他实体起作用，它禁止（MUST NOT）提供一个授权实体。正如SASL中定义的，初始实体禁止（MUST NOT）体噢能够一个授权实体，除非此授权实体与由授权实体衍生而来的默认实体不同（在SASL中有描述）。如果提供了，授权实体的值必须（MUST）在服务器那为<domain>（即只有一个域标识符）的形式，在客户端那为<node@domain>（即节点标识符和域标识符）。
8. 在包含了一个安全层协商的SASL协商的成功后，接收实体必须（MUST）丢弃任何从初始实体获得的，而并非SASL协商本身所获得的信息。
9. 在包含了一个安全层协商的SASL协商的成功后，初始实体必须（MUST）丢弃任何从接收实体获得的，而并非SASL协商本身所获得的信息。
10. 参见14.7节（执行托管技术）中有关必须提供的一些（MUST）机制。
6.2. 详述
当一个初始实体与一个接收实体使用SASL进行认证，相关的步骤如下：
1. 初始实体通过在发送到接收实体的开的XML流header中包含一个值为“1.0”的‘version’属性来请求SASL认证。
2. 在发送了一个回应的XML流header后，接收实体注册了一列可用的SASL认证机制；每个都是一个被<mechanisms/>容器元素作为子元素包含的<mechanism/>元素，这个容器元素命名空间为‘urn:ietf:params:xml:ns:xmpp- sasl’，在流命名空间里的次序上是一个<features/>元素的子元素。如果在可能使用某个特定的认证机制前，需要配置好TLS的使用，接收实体禁止（MUST NOT）在TLS制定前，规定可用的SASL认证机制列表中的那些机制。如果初始实体在优先制定TLS协商期间给出了一个有效的证书，接收实体应该（SHOULD）在SASL协商期间，提供SASL EXTERNAL机制给初始实体（参考SASL），即使EXTERNAL机制也可能（MAY）在其他情况下被给出。
3. 初始实体通过发送一个在‘urn:ietf:params:xml:ns:xmpp-sasl’ 命名空间下的<auth/>元素给接收实体以及包含一个一个适当的‘mechanism’属性值来选择一个机制。如果机制支持或需要，这个元素可以包含XML字符数据（在SASL术语中叫‘initial response’）；如果初始实体需要发送一个0长度的初始响应，它必须（MUST）把响应作为一个相等符“=”传输，这样可以表明响应出席了，但是没有带数据。
4. 如果必需的话，接收实体通过发送一个‘urn:ietf:params:xml:ns:xmpp-sasl’命名空间下的 <challenge/>元素给初始实体来召唤（challenge）初始实体；这个元素可以（MAY）包含字符数据（必须（MUST）确定与初始实体选择的SASL机制的定义相一致）。
5. 初始实体通过发送一个在‘urn:ietf:params:xml:ns:xmpp-sasl’命名空间下的< response/>元素给接收实体来回应这个召唤；这个元素可以（MAY）包含字符数据（必须（MUST）确定与初始实体选择的SASL机制的定义相一致）。
6. 如果必需的话，接收实体发送更多的召唤，而初始实体则发送更多的回应。
这个召唤/回应对的系列一直持续到下面事件之一发生：
1. 初始实体通过发送一个在‘urn:ietf:params:xml:ns:xmpp-sasl’命名空间下的< abort/>元素给接收实体来中断这个握手（handshake）。在接收到一个<abort/>元素后，接收实体应该（SHOULD）允许一个可配置且合理的重试次数（至少为2），之后它必须（MUST）终止TCP连接；这样使初始实体能够不用被迫去重新连接，而容忍被错误提供的凭证（例如，一个输错的密码）。
2. 接收实体通过发送一个在‘urn:ietf:params:xml:ns:xmpp-sasl’命名空间下的< failure/>元素给初始实体来报告握手失败（特定的失败原因应该（SHOULD）在<failure/>元素的一个适当的子节点中传达，定义在SASL Errors中）。如果错误的情况发生，接收实体应该（SHOULD）允许一个可配置且合理的重试次数（至少为2），之后它必须（MUST）终止TCP连接；这样使初始实体（如，一个目标用户客户端）能够不用被迫去重新连接，而容忍被错误提供的凭证（例如，一个输错的密码）。
3. 接收实体通过发送一个在‘urn:ietf:params:xml:ns:xmpp-sasl’命名空间下的< success/>元素给初始实体来报告握手成功；如果被选择的SASL机制需要，这个元素可以（MAY）包含XML字符数据（在SASL术语中，叫作“additional data with success”）。在接收到<success/>元素后，初始实体必须（MUST）初始化一个新流，通过发送一个开的XML流header 给接收实体（没必要先发送一个闭的</stream>标识，因为接收实体与发送实体必须（MUST）考虑初始流在发送或接收了< success/>元素后再关闭）。在接收到了来自初始实体的新的流header，接收实体必须（MUST）通过发送一个新的XML流header 给初始实体来响应，连同任何可用的特性（不包括STARTLLS和SASL特性）或一个空的<features/>元素（指明没有附加的特性可用）；任何这里没有定义的附加特性，必须（MUST）由XMPP相关的扩展定义。
* Use of SASL //简单验证和安全层的应用
1. Overview //概述
2. Narrative //详述
3. SASL //定义
4. SASL //错误
5. Client-to-Server Example //客户端到服务器的例子
6. Server-to-Server Example //服务器到服务器的例子
* Resource Binding //资源绑定
6.1. 概述
XMPP包含一个用于认证流的方法，该方法依靠一个特定于XMPP的SASL协议的profile。SASL提供了一个通用的方法，用于给基于连接的协议添加认证支持，而XMPP为SASL使用了一个通用的XML命名空间profile，其与SASL的profile的必要条件相一致。
应用以下规则：
1. 如果SASL协商发生在两个服务器之间，通信不能（MUST NOT）继续，直到服务器所持有的DNS主机名被确定（参见14.4.节： 服务器到服务器通信）。
2. 如果初始实体能够进行SASL协商，它必须（MUST）在初始流header中包含一个值至少设置为“1.0”的‘version’属性。
3. 如果接收实体能够进行SASL协商，在回应从初始实体发来的开的流标识的流中，它必须（MUST）在一个<mechanisms/>元素中注册一个或多个认证机制，该<mechanisms/>元素在‘urn:ietf:params:xml:ns:xmpp-sasl’命名空间下。
4. 在SASL协商期间，实体不能（MUST NOT）在流的根元素间发送任何空字符（matching production [3] content of XML）来作为元素的间隔（在后面的TLS例子中出现的任何空字符只是为了可读性）；这个禁令有助于确保彻底的安全层的字节精确度。
5. 在SASL协商期间使用的XML元素中所包含的任何XML字符数据必须（MUST）使用base64进行编码，其中的编码技术在RFC 3548[BASE64]第3部分的定义中。
6. 如果被选的SASL机制支持“simple username”这样的（例如，DIGEST-MD5和CRAM-MD5机制支持，而EXTERNAL和GSSAPI机制不支持），在认证期间，初始实体应该（SHOULD）提供在S/S通信的情况中作为发送域（IP地址或包含于域标识符中的完全限定的域名）的简单用户名，或者在C/S通信的情况中它所注册的帐户名（一个XMPP节点标识符中包含的用户名或节点名）。
7. 如果初始实体希望代表另一个实体起作用，且所选择的SASL机制能够支持对一个授权实体的的转播，初始实体必须（MUST）在SASL协商期间提供一个授权实体。如果初始实体没想要代表其他实体起作用，它禁止（MUST NOT）提供一个授权实体。正如SASL中定义的，初始实体禁止（MUST NOT）体噢能够一个授权实体，除非此授权实体与由授权实体衍生而来的默认实体不同（在SASL中有描述）。如果提供了，授权实体的值必须（MUST）在服务器那为<domain>（即只有一个域标识符）的形式，在客户端那为<node@domain>（即节点标识符和域标识符）。
8. 在包含了一个安全层协商的SASL协商的成功后，接收实体必须（MUST）丢弃任何从初始实体获得的，而并非SASL协商本身所获得的信息。
9. 在包含了一个安全层协商的SASL协商的成功后，初始实体必须（MUST）丢弃任何从接收实体获得的，而并非SASL协商本身所获得的信息。
10. 参见14.7节（执行托管技术）中有关必须提供的一些（MUST）机制。
6.2. 详述
当一个初始实体与一个接收实体使用SASL进行认证，相关的步骤如下：
1. 初始实体通过在发送到接收实体的开的XML流header中包含一个值为“1.0”的‘version’属性来请求SASL认证。
2. 在发送了一个回应的XML流header后，接收实体注册了一列可用的SASL认证机制；每个都是一个被<mechanisms/>容器元素作为子元素包含的<mechanism/>元素，这个容器元素命名空间为‘urn:ietf:params:xml:ns:xmpp- sasl’，在流命名空间里的次序上是一个<features/>元素的子元素。如果在可能使用某个特定的认证机制前，需要配置好TLS的使用，接收实体禁止（MUST NOT）在TLS制定前，规定可用的SASL认证机制列表中的那些机制。如果初始实体在优先制定TLS协商期间给出了一个有效的证书，接收实体应该（SHOULD）在SASL协商期间，提供SASL EXTERNAL机制给初始实体（参考SASL），即使EXTERNAL机制也可能（MAY）在其他情况下被给出。
3. 初始实体通过发送一个在‘urn:ietf:params:xml:ns:xmpp-sasl’ 命名空间下的<auth/>元素给接收实体以及包含一个一个适当的‘mechanism’属性值来选择一个机制。如果机制支持或需要，这个元素可以包含XML字符数据（在SASL术语中叫‘initial response’）；如果初始实体需要发送一个0长度的初始响应，它必须（MUST）把响应作为一个相等符“=”传输，这样可以表明响应出席了，但是没有带数据。
4. 如果必需的话，接收实体通过发送一个‘urn:ietf:params:xml:ns:xmpp-sasl’命名空间下的 <challenge/>元素给初始实体来召唤（challenge）初始实体；这个元素可以（MAY）包含字符数据（必须（MUST）确定与初始实体选择的SASL机制的定义相一致）。
5. 初始实体通过发送一个在‘urn:ietf:params:xml:ns:xmpp-sasl’命名空间下的< response/>元素给接收实体来回应这个召唤；这个元素可以（MAY）包含字符数据（必须（MUST）确定与初始实体选择的SASL机制的定义相一致）。
6. 如果必需的话，接收实体发送更多的召唤，而初始实体则发送更多的回应。
这个召唤/回应对的系列一直持续到下面事件之一发生：
1. 初始实体通过发送一个在‘urn:ietf:params:xml:ns:xmpp-sasl’命名空间下的< abort/>元素给接收实体来中断这个握手（handshake）。在接收到一个<abort/>元素后，接收实体应该（SHOULD）允许一个可配置且合理的重试次数（至少为2），之后它必须（MUST）终止TCP连接；这样使初始实体能够不用被迫去重新连接，而容忍被错误提供的凭证（例如，一个输错的密码）。
2. 接收实体通过发送一个在‘urn:ietf:params:xml:ns:xmpp-sasl’命名空间下的< failure/>元素给初始实体来报告握手失败（特定的失败原因应该（SHOULD）在<failure/>元素的一个适当的子节点中传达，定义在SASL Errors中）。如果错误的情况发生，接收实体应该（SHOULD）允许一个可配置且合理的重试次数（至少为2），之后它必须（MUST）终止TCP连接；这样使初始实体（如，一个目标用户客户端）能够不用被迫去重新连接，而容忍被错误提供的凭证（例如，一个输错的密码）。
3. 接收实体通过发送一个在‘urn:ietf:params:xml:ns:xmpp-sasl’命名空间下的< success/>元素给初始实体来报告握手成功；如果被选择的SASL机制需要，这个元素可以（MAY）包含XML字符数据（在SASL术语中，叫作“additional data with success”）。在接收到<success/>元素后，初始实体必须（MUST）初始化一个新流，通过发送一个开的XML流header 给接收实体（没必要先发送一个闭的</stream>标识，因为接收实体与发送实体必须（MUST）考虑初始流在发送或接收了< success/>元素后再关闭）。在接收到了来自初始实体的新的流header，接收实体必须（MUST）通过发送一个新的XML流header 给初始实体来响应，连同任何可用的特性（不包括STARTLLS和SASL特性）或一个空的<features/>元素（指明没有附加的特性可用）；任何这里没有定义的附加特性，必须（MUST）由XMPP相关的扩展定义。
