RFC 4422翻译，有关SASL - tRavAsty/SASL GitHub Wiki

客户端提供它的凭据（这个凭据包含或站暗示了认证方法），可以可选择的带上一个代表要求认证身份的特征字符串。当特征字符串被忽略或者为空时，客户端是在请求这个凭据所代表的身份服务器要求认证客户端的凭据，并且验证这个凭据所代表的身份可以被用来当作授权身份。如果其中的任意一种认证失败，SASL交换就会失败但是，认证身份和授权身份的细节不是SASL协议规定的一部分 ##3.认证交换每一个认证交换都要求包含一条从客户端到服务器的消息，这个消息包含了特殊的机制，跟随着一对或者多对服务器到客户端的挑战和客户端对服务器的应答，同时还包含服务器对认证结果的指示 认证交换的概述

      C: Request authentication exchange
      S: Initial challenge
      C: Initial response
      <additional challenge/response messages>
      S: Outcome of authentication exchange

如果结果是正确的同时安全层被协商了出来，安全层就被安装了，这一条同样也适用于以下的发现有些机制规定了发送出的第一条消息是由客户端传给服务器的。协议也许会在请求消息中提供一个可选择的初始化应答域来带上这部分数据。在这种情况下，交换会被缩短到一个round-trip

      C: Request authentication exchange + Initial response
      <additional challenge/response messages>
      S: Outcome of authentication exchange

当这个机制规定了第一条消息是由客户端到服务器的并且这个域是不可用的的时候，客户端的请求之后会跟着一个空的挑战

      C: Request authentication exchange
      S: Empty Challenge
      C: Initial Response
      <additional challenge/response messages>
      S: Outcome of authentication exchange

在不允许客户端向服务器传输第一个消息的机制中，如果一个客户端在它的请求中包含初始挑战，那么这个认证交换就会失败

有些机制中规定了服务器在认证出现成功结果后要给客户端发送额外消息。协议可以在结果消息中提供一个选择域来包含这部分信息。在这种协议中，服务器使用这个额外域，消息交换也会被缩短成一个round-trip

      C: Request authentication exchange
      S: Initial challenge
      C: Initial response
      <additional challenge/response messages>
      S: Outcome of authentication exchange with
         additional data with success

当这个额外域无法使用时，额外的数据被当作一个应答为空的挑战。收到这条回应时，服务器要指示是否有一个成功的结果

      C: Request authentication exchange
      S: Initial challenge
      C: Initial response
      <additional challenge/response messages>
      S: Additional data challenge
      C: Empty Response
      S: Outcome of authentication exchange

当一个机制包含以上两种额外域的时候，交换会比一般少两个round-trip

      C: Request authentication exchange + Initial response
      <additional challenge/response messages>
      S: Outcome of authentication exchange
         with additional data with success

而不是：

      C: Request authentication exchange
      S: Empty Challenge
      C: Initial Response
      <additional challenge/response messages>
      S: Additional data challenge
      C: Empty Response
      S: Outcome of authentication exchange

###3.1交换命名 SASL的机制是由特征字符串命名的，特征字符串的长度由1到20，包含了大写的ASCII码，数字，连字符和/或者下划线 ###3.2机制协商机制的协商是由协议规定的

通常，一个协议会规定服务器用协议提供的某些设备告知客户端自己支持的和可用的机制，然后客户端会从这个列表中挑选出自己支持且合适的最好的机制

注意到机制协商是不被之后的认证交换保护的，所以如果没有被其他方法保护的话，机制协商容易受到降级攻击

如果要检测降级攻击的话，一个协议可以在认证交换后允许客户端发现合适的机制，而且起码要有数据完整性的保护。这样使得客户端可以去发现服务器提供的机制表的改变

###3.3 请求认证交换

客户端通过它规定的机制要求认证来发起认证交换。客户端发送包含了机制名称的消息给服务器。这种特殊消息的细节是被协议具体规定了的

注意到机制名称是不被保护的，所以如果没有加上完整性保护或者其他方法保护的话易于受到攻击者的消息篡改攻击

当机制允许额外域的时候，客户端可以在认证请求消息中加入对初始挑战的应答

###3.4 挑战和应答

认证交换包含了一对或者多对挑战应答，具体数目由协议规定。通过这些挑战和应答，机制可以

——让服务器认证客户端

——让客户端认证服务器

——传输授权方法字符串

——协商安全曾并且提供其他服务

安全曾的协商也许会包含安全层提供的安全服务的协商，这些服务会被怎样提供，并且协商两侧的最大密文缓冲大小使其能够在这一层接受消息

在收到认证请求或者任何的客户端应答之后，服务器可能会发起一个挑战，终止挑战，或者表明交换的结果。收到挑战后，客户端可能发起应答或者放弃挑战

###3.4.1 授权身份字符串

授权身份字符串是一系列0或者更多的Unicode字符，排除掉NUL字符，这个字符代表着身份要表现的

如果授权身份字符串为空的话，客户端要求表现的像服务器联系客户端的凭证的实体一样。一个空的字符串和一个空的授权身份一样

一个非空的授权身份字符串代表着客户端期望表现得像字符串代表的身份一样。在这种情况下，协议需要规定字符串代表的身份的形式，和精确的文法以及字符串的语义

当机制明确规定了传输认证身份字符串的字符加密策略时，机制需要包含整个Unicode条目

###3.5 终止认证交换

一个客户端或者服务器在不愿意或者不能继续的时候也许想要中断一个认证交换

客户端也许会通过发送一个消息来中断认证，这个消息的细节是协议具体规定的。对于服务器来说，代表着交换被中断了。服务器也许会被协议要求返回一个消息给客户端的中断消息来作为回应

同样的，一个服务器也许会通过发送消息来中断一个认证交换，具体细节会被协议规定，对客户端来说这代表着交换被中断了

###3.6 认证结果

在认证交换的结束部分，服务器会发送消息，协议规定具体细节，对于客户端来说这代表着交换的结果

在以下条件成立的情况下结果是不成功的：

——认证交换失败

——客户端的凭据无法被认证

——服务器不能联系到展开凭据的身份

——客户端提供的授权方法字符串是格式错误的

——客户端凭据的身份并没有授权客户端要求的授权身份

——协商的安全层并不合适

——或者服务器并不愿意给客户端提供服务

如果结果是成功的并且安全层被协商，安全层就被安装了。如果结果不成功或者安全层并未被协商，一切不懂

服务器提供的结果消息可以给客户端辨识错误提供一种方法，无论是需要再次提供凭证的错误还是提示用户重试的错误，还是用户需要联系管理员解决的错误。这种机制在规定的服务器维护时间尤其有用，因为它会降低支持成本。服务器确定结果消息不会区分有效用户的非法凭证和一个非法用户也同样重要

###3.7 安全层

SASL机制可以提供一个广泛的安全层的服务。典型的服务包括数据完整性和数据加密。不提供安全层的SASL机制就像不协商安全层一样被对待

如果认证交换使用了安全层的话，苏武器在知道了认证交换的结果后安装安全层，客户端在收到结果的收据后安装安全层。在两个例子中，安全层在传输其他消息之前建立。安全层的具体位置由协议自己规定

一旦安全层被建立，它直到协商一个新的安全层或者连接终止了之后才会被关闭

如果安全层底层无法加密或者无法解密，安全层一定要被关掉！而且底层连接一定要被优雅地关掉

每一个加密数据的缓冲表现成字节流的形式，并且预留了4个字节来表示双方期待的大小。字节流的大小必须小于另一方期待的大小，一旦接受到超过期待大小的消息，连接必须被关闭

最大大小被机制规定，要么是通过协商要么是通过细节来规定

###3.8 多重认证

除非协议允许，否则只有一个成功的SASL认证消息出现在一个协议会话中。在这种情况下，一旦一个认证消息建立，其他初始化认证交换的尝试都会失败

当SASL中多重认证成功之后，多重的SASL的安全层不会被同时使用。如果一个安全层正在被使用但是客户端选择了第二种安全层，第二种就会取代第一种。如果接下来的协商没有选择安全层，那么初始的安全层还是在使用当中

……

##4 协议要求

一个支持SASL的协议需要包含以下信息

1、服务名称

2、机制协商的细节

3、认证交换中消息的定义
   a)初始化认证交换的消息
   b)传输服务器挑战和客户端应答的消息
   c)指示认证交换结果的消息

4、规定非空授权身份字符串的语法和语义

5、规定允许服务器或者客户端终止认证交换的方法的细节

6、精确规定新协商好的安全层在双方的方向上什么时候生效

7、如果协议支持其他安全层的协议，例如TLS，协议必须规定安全层适用在协议数据中的顺序

    举个例子，如果一个协议同时支持TLS和SASL安全层的话，细节需要按一下来描述
    
    a)SASL安全层总是在TLS之前加密，因此相应的在TLS后解密
    b)SASL安全层总是在TLS后加密，因此相应的在TLS之前解密
    c)层的顺序由他们安装的顺序决定
    d)层的顺序由他们安装时相反的顺序决定
    e)不能同时安装TLS和SASL安全层

8、指示协议是否支持多重认证交换。如果支持，协议必须详细描述一个失败的SASL认证交换对以前建立的认证和授权状态的影响

协议细节必须避免一些会阻止应用层机制的替换的实现机制，协议的规定必须是中性的。不支持这种建议的例子有

细节说明一个凭证应该如何组织
详细说明认证实体和授权实体是怎么互相联系的
细节说明哪一个机制适用于这个协议

##5 机制要求

SASL机制必须提供以下信息

1) 机制的名称。名称必须被注册

2) 服务器的挑战和客户端的应答的定义，以及以下内容
    
    a)机制是否是客户端先，可选还是服务器先的说明

    b)服务器是否应该提供额外数据来指示成功结果的说明（机制需要最小化必要的挑战应答数目）
3) 机制是否能够传输授权身份字符串的说明

4) 说明机制是否提供安全层

5) 如果机制所使用的底层的加密方法支持数据完整性，那么机制必须保护授权实体的传输以及安全层协商的完整性

##6 安全考虑

许多现存的SASL机制在认证交换中并不提供防止被动攻击的保护，更不用说主动攻击了。许多现存的SASL机制不提供安全层。希望在未来SASL可以实现对主动和被动攻击强烈的保护，和安全层的基本数据安全特征。也希望未来安全层可以提供更高级的数据安全例如re-keying

就算不考虑这些，SASL框架也易于受到降级攻击，但是6.1.2提供了许多方法来阻止或者检测这样的攻击。在一些例子中，可以通过外部的数据完整性保护（例如TLS）来防止降级攻击。当机制本身不提供足够的完整和保密性的时候外部的安全协议也是十分重要的

###6.1 主动攻击

6.1.1 劫持攻击

当客户端至少选择了提供数据完整性保护的安全层时候，可以防止或者检测劫持。当安全层检测到数据完整性缺失时需要关闭连接

6.1.2 降级攻击

任何安全敏感的协议数据的协商需要在有数据完整性保护的安全层的建立之后进行，这是非常必要的。或者在这样的安全层建立之前的协商需要在安全层建立之后重新认证。
攻击者可能会选择安全性非常低的方法，因此安全性在最低要求以下的安全方法需要从表上清除，不能继续一个不能满足最低安全的协商

6.1.3 重放攻击

一些机制可能易于受到重放攻击除非被外部数据安全服务绑定(TLS)

6.1.4 截断攻击

每一个连接都有优雅的关闭机制就可以避免，并且是被完整性保护的

6.1.5 其它主动攻击