简单认证与安全层-SASL
2021-03-06 15:35:46 
阿炯
简单认证与安全层(SASL)，[全称：Simple Authentication and Security Layer]是一个在网络协议中用来认证和数据加密的构架。它把认证机制从程序中分离开，理论上使用SASL的程序协议都可以使用SASL所支持的全部认证机制。认证机制可支持代理认证，这让一个用户可以承担另一个用户的认证。SASL同样提供数据安全层，这提供了数据完整验证和数据加密。DIGEST-MD5 提供了数据加密层，这是机制中的一个例子。支持SASL的应用程序通常也支持 传输层安全 (TLS) 作为对SASL提供的服务的补充。这是一种用来扩充C/S模式验证能力的机制。
在1997年 John Gardiner Myers 在卡内基梅隆大学时写下了最初的SASL说明文件(RFC 2222)。在2006年Alexey Melnikov 和 Kurt Zeilenga 写的 RFC 4422 取代了那个文件。SASL 是IETF的标准规格协议，而且也是截至2016年互联网标准中的一项。
在Postfix可以利用SASL来判断用户是否有权使用转发服务，或是辨认谁在使用你的服务器。SASL还提供了一个通用的方法为基于连接的协议增加验证支持，而XMPP使用了一个普通的XML名字空间来满足SASL的需要。
SASL机制
一个SASL机制实现了一系列的要求和特性，已经制定的SASL机制包括：
"EXTERNAL"，认证信息在内容中(例如已经使用IPsec或传输层安全的协议)
"ANONYMOUS"，对与未认证的客人的访问
"PLAIN"，一个简单明文密码机制。PLAIN取代了LOGIN 机制。
"OTP"，一个临时密码机制。 OTP取代了SKEY机制。
"SKEY"，一个S/KEY机制
"CRAM-MD5"，一个简单的基于HMAC-MD5的询问应答机制。
"DIGEST-MD5"， 是一个HTTP兼容的，基于MD5的询问应答机制。DIGEST-MD5提供了数据层安全。
"NTLM"，一个 NT LAN Manager认证机制。
"GSSAPI"，通过通用安全服务应用程序层的Kerberos V5 协议的安全认证。GSSAPI 提供了数据安全层。
GateKeeper Microsoft为Windows Live Messenger开发的一个询问应答机制。
在SASL中的GS2协议家族支持任意的GSSAPI机制，现在在RFC 5801中标准化。
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 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/>；
⒌初始化实体向接收实体发送符合'urn:ietf:params:xml:ns:xmpp-sasl'名字空间的<response/>；元素作为应答；
⒍如果必要，接收实体发送更多的挑战给初始化实体，初始化实体发送更多的回应。
定义
[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相关的错误条件定义如下：
⒈<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/>；元素时发送。
参考来源
sasl
简单认证与安全层
Introduction to Simple Authentication Security Layer (SASL)
在1997年 John Gardiner Myers 在卡内基梅隆大学时写下了最初的SASL说明文件(RFC 2222)。在2006年Alexey Melnikov 和 Kurt Zeilenga 写的 RFC 4422 取代了那个文件。SASL 是IETF的标准规格协议，而且也是截至2016年互联网标准中的一项。
在Postfix可以利用SASL来判断用户是否有权使用转发服务，或是辨认谁在使用你的服务器。SASL还提供了一个通用的方法为基于连接的协议增加验证支持，而XMPP使用了一个普通的XML名字空间来满足SASL的需要。
SASL机制
一个SASL机制实现了一系列的要求和特性，已经制定的SASL机制包括：
"EXTERNAL"，认证信息在内容中(例如已经使用IPsec或传输层安全的协议)
"ANONYMOUS"，对与未认证的客人的访问
"PLAIN"，一个简单明文密码机制。PLAIN取代了LOGIN 机制。
"OTP"，一个临时密码机制。 OTP取代了SKEY机制。
"SKEY"，一个S/KEY机制
"CRAM-MD5"，一个简单的基于HMAC-MD5的询问应答机制。
"DIGEST-MD5"， 是一个HTTP兼容的，基于MD5的询问应答机制。DIGEST-MD5提供了数据层安全。
"NTLM"，一个 NT LAN Manager认证机制。
"GSSAPI"，通过通用安全服务应用程序层的Kerberos V5 协议的安全认证。GSSAPI 提供了数据安全层。
GateKeeper Microsoft为Windows Live Messenger开发的一个询问应答机制。
在SASL中的GS2协议家族支持任意的GSSAPI机制，现在在RFC 5801中标准化。
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 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/>；
⒌初始化实体向接收实体发送符合'urn:ietf:params:xml:ns:xmpp-sasl'名字空间的<response/>；元素作为应答；
⒍如果必要，接收实体发送更多的挑战给初始化实体，初始化实体发送更多的回应。
定义
[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相关的错误条件定义如下：
⒈<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/>；元素时发送。
参考来源
sasl
简单认证与安全层
Introduction to Simple Authentication Security Layer (SASL)