标题：sasl
简介
SASL全称Simple Authentication and Security Layer，是一种用来扩充C/S模式验证能力的机制。在Postfix可以利用SASL来判断用户是否有权使用转发服务，或是辨认谁在使用你的服务器。
SASL提供了一个通用的方法为基于连接的协议增加验证支持，而XMPP使用了一个普通的XML名字空间来满足SASL的需要。
SASL的使用
规则⒈如果SASL协商发生在两台服务器之间，除非服务器宣称的DNS主机名得到解析，不能（MUST NOT）进行通信。
⒉如果初始化实体有能力使用SASL 协商，它必须（MUST）在初始化流的头信息中包含一个值为"1.0"的属性'version'。
⒊如果接收实体有能力使用SASL协商，它必须（MUST）在应答从初始化实体收到的打开流标签时（如果打开的流标签包含一个值为"1.0"的'version'属性），通过'urn:ietf:params:xml:ns:xmpp-sasl'名字空间中的<mechanisms/>元素声明一个或多个验证机制. 
⒋当SASL 协商时，一个实体不能（MUST NOT）在流的根元素中发送任何空格符号（匹配production [3] content of [XML]）作为元素之间的分隔符（在以下的SASL例子中任何空格符号的出现仅仅是为了增加可读性）； 这条禁令帮助确保安全层字节的精确度。
⒌当SASL握手时，在XML元素中使用的任何XML 字符数据必须被编码成base64，编码遵循RFC 3548 第三章的规定。
⒍如果一个 简单名字"simple username" 规范被选定的SASL机制所支持，（比如，这被DIGEST-MD5 和CRAM-MD5 机制支持但不被EXTERNAL 和GSSAPI 机制支持），验证的时候初始化实体应该（SHOULD）在服务器间通信时提供简单名字 自身的发送域（IP地址或包含在一个域标识符中的域名全称），在客户端与服务器之间通信时提供注册用户名（包含在一个XMPP节点标识符中的用户或节点名）。
⒎如果初始化实体希望以另一个实体的身份出现并且SASL机制支持授权ID的传输，初始化实体在SASL握手时必须（MUST）提供一个授权ID。如果初始化实体不希望以另一个实体的身份出现，初始化实体在SASL握手时不能（MUST NOT）提供一个授权ID。在[SASL] 的定义中，除非授权ID不同于从验证ID（详见[SASL]）中得到的缺省的授权ID，初始化实体不能（MUST NOT）提供授权ID。如果提供了，这个授权ID的值必须（MUST）是<domain>；的格式（对于服务器来说）或<node@domain>；的格式（对于客户端来说）. 
⒏在成功进行包括安全层的SASL握手之后，接收实体必须（MUST）丢弃任何从初始化实体得到的而不是从SASL协商本身获得的信息。
⒐在成功进行包括安全层的SASL握手之后，初始化实体必须（MUST）丢弃任何从接收实体得到的而不是从SASL协商本身获得的信息。
⒑参看 强制执行的技术，了解关于必须（MUST）支持的机制.
叙述⒈初始化实体请求SASL验证，它发送一个打开的XML流头信息给接收实体，其'version'属性的值为"1.0".
⒉在发送一个XML流头回复之后，接收实体声明一个可用的SASL验证机制清单；每个机制作为一个<mechanism/>；元素，作为子元素包含在<mechanisms/>；容器元素（其名字空间为'urn:ietf:params:xml:ns:xmpp-sasl'）中，而<mechanisms/>；则包含在流名字空间中的<features/>；元素中。如果在使用任何验证机制之前需要使用TLS（见第五章），接收实体不能（MUST NOT）在TLS握手之前提供可用的SASL验证机制清单。如果初始化实体在优先的TLS协商过程中呈现了一个合法的证书，接收实体应该（SHOULD）在SASL握手中提出一个SASL外部机制给初始化实体，尽管这个外部机制可以（MAY）在其它环境下提供。
⒊初始化实体发送一个符合'urn:ietf:params:xml:ns:xmpp-sasl'名字空间的<auth/>；元素（其中包含了适当的'mechanism'属性值）给接收实体，以选择一个机制。如果这个机制支持或需要，这个元素可以（MAY）包含XML字符数据（在SASL术语中，即“初始化应答”）；如果初始化实体需要发送一个零字节的初始化应答，它必须（MUST）传输一个单独的等号作为应答，这表示应答有效但不包含数据。
⒋如果必要，接收实体向初始化实体发送一个符合'urn:ietf:params:xml:ns:xmpp-sasl'名字空间的<challenge/>；元素来发出挑战；这个元素可以（MAY）包含XML字符数据（必须按照初始化实体选择的SASL机制进行一致性运算）。
⒌初始化实体向接收实体发送符合'urn:ietf:params:xml:ns:xmpp-sasl'名字空间的<response/>；元素作为应答；这个元素可以（MAY）包含XML字符数据（必须按照初始化实体选择的SASL机制进行一致性运算）。
⒍如果必要，接收实体发送更多的挑战给初始化实体，初始化实体发送更多的回应。
SASL定义[SASL]的必要条件要求通过协议定义来提供以下信息： 
⒈service name（服务名）： "xmpp" 
⒉initiation sequence（开始序列）： 当初始化实体提供一个打开的XML流头信息并且接收实体善意回应之后，接收实体提供一个可接受的验证方法清单。初始化实体从这个清单中选择一个方法，把它作为<auth/> 元素的'mechanism' 属性的值发送给接收实体，也可以选择发送一个初始化应答以避免循环。
⒊exchange sequence（交换序列）： 挑战和回应的交换，从接收实体发送给初始化实体的<challenge/> 元素和从初始化实体发送给接收实体的<response/> 元素信息。接收实体通过发送<failure/>；元素报告失败，发送<success/>；元素报告成功；初始化实体通过发送<abort/> 元素中止交换。成功的协商之后，两边都认为原来的XML流已经关闭并且都开始发送新的流头信息。
⒋security layer negotiation（安全层协商）： 安全层在接收实体发送<success/> 元素的关闭字符">"之后立刻生效，在初始化实体发送<success/> 元素的关闭字符">"之后也立刻生效。层的顺序是[TCP]，[TLS]，然后是[SASL]，然后是[XMPP]。
⒌useof the authorization identity（授权ID的使用）： 授权ID可在xmpp中用于表示一个客户端的非缺省的<node@domain>；，或一个服务器的<domain>；。
SASL错误SASL相关的错误条件定义如下： 
⒈<aborted/>-- 接收实体认可由初始化实体发送的<abort/>；元素；在回应一个<abort/>；元素时发送。
⒉<incorrect-encoding/>-- 由初始化实体提供的数据无法处理，因为[BASE64]编码不正确（例如，因为编码不符合[BASE64]的第三章）； 在回应一个包含初始化响应数据的<response/> 元素或<auth/>；元素时发送.
⒊<invalid-authzid/>-- 由初始化实体提供的授权id是非法的，因为它的格式不正确或初始化实体无权给那个ID授权；在回应一个包含初始化响应数据的<response/> 元素或<auth/>；元素时发送。
⒋<invalid-mechanism/>-- 初始化实体不能提供一个机制活、或请求一个不被接受实体支持的机制；在回应一个<auth/>；元素时发送。
⒌<mechanism-too-weak/>-- 初始化实体请求的机制比服务器策略对它的要求弱；在回应一个包含初始化响应数据的<response/> 元素或<auth/>；元素时发送。
⒍<not-authorized/>-- 验证失败，因为初始化实体没有提供合法的credentials（这包括但不限于未知用户名等情形）；在回应一个包含初始化响应数据的<response/> 元素或<auth/>；元素时发送。
⒎<temporary-auth-failure/>-- 验证失败，因为接收实体出现了临时的错误；在回应一个<response/> 元素或<auth/>；元素时发送。