非官方中文译本声明：本页为 IETF RFC 4422《Simple Authentication and Security Layer (SASL)》 的中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布，受 BCP 78 与 IETF 信托法律条款约束；本译本保留原文编号与结构，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc4422。

RFC 4422：简单认证与安全层（SASL）

标准跟踪 · A. Melnikov（主编）、K. Zeilenga（主编）· Isode Limited / OpenLDAP Foundation · 2006 年 6 月 · 类别：Standards Track（标准跟踪）· 替代 RFC 2222 · ISSN: 2070-1721

本备忘录的状态

本文档规定了面向 Internet 社区的一个 Internet 标准跟踪协议，并请求进行讨论以及提出改进建议。有关本协议的标准化状态与现状，请参考当前版本的《Internet 官方协议标准》(STD 1)。本备忘录的分发不受限制。

版权声明

摘要

简单认证与安全层（Simple Authentication and Security Layer，SASL）是一个通过可替换的机制，在面向连接的协议中提供认证与数据安全性服务的框架。它在协议与机制之间提供结构化的接口。由此得到的框架允许新协议复用既有机制，也允许旧协议利用新机制。该框架还提供用于在数据安全层中保护后续协议交换的协议。

本文档描述了 SASL 机制的结构，描述了协议如何包含对 SASL 的支持，并定义了在连接上承载数据安全层的协议。此外，本文档定义了一个 SASL 机制——EXTERNAL 机制。本文档废弃 RFC 2222。

1. 引言
- 1.1. 文档受众
- 1.2. 与其他文档的关系
- 1.3. 约定
2. 身份概念
3. 认证交换
- 3.1. 机制命名
- 3.2. 机制协商
- 3.3. 请求认证交换
- 3.4. 质询与响应
  - 3.4.1. 授权身份字符串
- 3.5. 中止认证交换
- 3.6. 认证结果
- 3.7. 安全层
- 3.8. 多次认证
4. 协议要求
5. 机制要求
6. 安全考量
- 6.1. 主动攻击
  - 6.1.1. 劫持攻击
  - 6.1.2. 降级攻击
  - 6.1.3. 重放攻击
  - 6.1.4. 截断攻击
  - 6.1.5. 其他主动攻击
- 6.2. 被动攻击
- 6.3. 重新生成密钥
- 6.4. 其他考量
7. IANA 考量
- 7.1. SASL 机制注册表
  - 7.1.1. 机制名称注册流程
  - 7.1.2. 族名称注册流程
  - 7.1.3. 关于 SASL 机制注册的评论
  - 7.1.4. 变更控制
- 7.2. 注册变更
8. 参考文献
- 8.1. 规范性参考文献
- 8.2. 资料性参考文献
9. 致谢
附录 A. SASL EXTERNAL 机制
- A.1. EXTERNAL 技术规范
- A.2. SASL EXTERNAL 示例
- A.3. 安全考量
附录 B. 自 RFC 2222 以来的变更
编辑地址
完整版权声明

1. 引言

简单认证与安全层（SASL）是一个通过可替换的机制，在面向连接的协议中提供认证与数据安全性服务的框架。SASL 在协议与机制之间提供结构化的接口。SASL 还提供用于在数据安全层中保护后续协议交换的协议。数据安全层可以提供数据完整性、数据机密性以及其他服务。

SASL 的设计旨在允许新协议复用既有机制而无需重新设计这些机制，并允许既有协议利用新机制而无需重新设计协议。

SASL 在概念上是一个位于协议与机制之间的抽象层框架，如下图所示。

                 SMTP    LDAP    XMPP   Other protocols ...
                    \       |    |      /
                     \      |    |     /
                    SASL abstraction layer
                     /      |    |     \
                    /       |    |      \
             EXTERNAL   GSSAPI  PLAIN   Other mechanisms ...

正是通过该抽象层的接口，框架才允许任意协议使用任意机制。虽然该层通常会向机制隐藏协议的细节、向协议隐藏机制的细节，但它通常并不会向协议实现隐藏机制的细节。例如，不同的机制需要不同的信息来运作：有些使用基于口令的认证，有些需要 realm 信息，还有些利用 Kerberos 票据、证书等。此外，为了执行授权，服务器实现通常必须在认证身份（其形式为机制所特有）与授权身份（其形式为应用协议所特有）之间进行身份映射。第 2 节讨论身份概念。

可以以抽象掉相似机制细节的方式来设计和实现此框架。这样的框架实现以及机制实现，不仅可以被某个特定协议的多个实现所共享，还可以被多个协议的实现所共享。

该框架包含与协议和机制进行交互的接口，认证交换即在这些接口中进行。第 3 节讨论 SASL 认证交换。

要使用 SASL，每个协议（除其他事项外）需提供：标识待使用机制的方法、交换机制特有的服务器质询与客户端响应的方法，以及传达认证交换结果的方法。第 4 节讨论 SASL 协议要求。

每个 SASL 机制定义（除其他事项外）一系列服务器质询与客户端响应，以提供认证服务并协商数据安全性服务。第 5 节讨论 SASL 机制要求。

第 6 节讨论安全考量。第 7 节讨论 IANA 考量。附录 A 定义 SASL EXTERNAL 机制。

1.1. 文档受众

本文档面向若干不同的受众撰写：

使用该规范在其协议中支持认证的协议设计者；
定义新 SASL 机制的机制设计者；
支持 SASL 的那些协议的客户端或服务端实现者。

虽然文档的组织方式旨在让读者聚焦于与其工程相关的细节，但仍鼓励读者阅读并理解本文档的所有方面。

1.2. 与其他文档的关系

本文档废弃 RFC 2222。它替换 RFC 2222 的全部内容，但第 7.1 节（KERBEROS_IV 机制）、第 7.2 节（GSSAPI 机制）、第 7.3 节（SKEY 机制）除外。KERBEROS_IV 与 SKEY 机制现被视为已废弃，RFC 2222 中提供的其规范属于历史性文档。GSSAPI 机制现由单独规范 [SASL-GSSAPI] 规定。

附录 B 提供了自 RFC 2222 以来的变更摘要。

1.3. 约定

本文档中的关键词 MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY 与 OPTIONAL，应按 BCP 14 [RFC2119] 中的描述进行解释。

本文档中的字符名称使用 Unicode 标准 [Unicode] 中的码点与名称记法。例如，字母 "a" 可表示为 <U+0061> 或 <LATIN SMALL LETTER A>。

注：Unicode 中使用的术语表见 [Glossary]。有关 Unicode 字符编码模型的信息见 [CharModel]。

在示例中，"C:" 与 "S:" 分别表示客户端与服务器应发送的数据行。为提升可读性，部分行已作折行处理。

2. 身份概念

在实践中，认证与授权可能涉及多个身份，其形式可能不同（简单用户名、Kerberos 主体名、X.500 可甄别名等），表示方式也可能不同（例如 ABNF 描述的 UTF-8 编码 Unicode 字符串、BER 编码的可甄别名）。虽然技术规范通常规定了在网络上使用的身份形式与表示方式，但不同的身份形式和/或表示方式可能（且经常）在实现内部使用。不同形式的身份如何相互关联通常是本地事务。此外，实现内部使用的形式与表示方式也是本地事务。

然而在概念上，SASL 框架涉及两个身份：

与认证凭据相关联的身份（称为认证身份）；以及
拟充当的身份（称为授权身份）。

SASL 机制规范描述用于认证客户端的凭据形式（例如 X.509 证书、Kerberos 票据、简单的用户名/口令），包括（在适用时）凭据中携带的认证身份的语法与语义。SASL 协议规范描述授权中使用的身份形式，尤其规定由机制传输的授权身份字符串的语法与语义。

客户端在 SASL 交换中提供其凭据（凭据包含或暗示一个认证身份），以及一个表示所请求授权身份的字符串（可选）。当该字符串被省略或为空时，客户端请求充当与凭据相关联的身份（例如，用户请求充当认证身份）。

服务器负责验证客户端的凭据，并验证其与客户端凭据相关联的身份（例如认证身份）是否被允许充当该授权身份。如果其中任一（或两者）验证失败，SASL 交换即告失败。（SASL 交换也可能因其他原因失败，例如服务授权失败。）

然而，认证身份的确切形式（服务器在验证中所使用的或其他用途）以及授权身份的确切形式（用于作出授权决策或其他用途），超出了 SASL 及本规范的范围。在某些情况下，SASL 交换之外某一上下文中使用的确切身份形式可能由其他规范规定。例如，身份假定授权（代理授权）策略规范可能规定认证身份与授权身份在策略语句中如何表示。

3. 认证交换

每次认证交换由一条从客户端发往服务器的消息组成，该消息请求通过某个特定机制进行认证；随后是一组或多组服务器质询与客户端响应；最后是服务器指示认证交换结果的消息。（注：如第 3.5 节所述，交换也可能被中止。）

下图从高层概览了一次认证交换。

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

如果结果成功且协商了安全层，则安装该层（见第 3.7 节）。这也适用于下列图示。

某些机制规定，认证交换中发送的第一份数据是从客户端到服务器。协议可在请求消息中提供一个可选的初始响应字段来携带该数据。在机制规定交换中发送的第一份数据是从客户端到服务器、协议提供了可选的初始响应字段、且客户端使用了该字段的情况下，交换减少一个往返：

      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

若客户端在其请求中包含了一个初始响应，而机制不允许客户端首先发送数据，则认证交换失败。

某些机制规定，服务器在指示成功结果时需向客户端发送附加数据。协议可在结果消息中提供一个可选的附加数据字段来携带该数据。在机制规定服务器需随成功结果返回附加数据、协议在结果消息中提供了可选的附加数据字段、且服务器使用了该字段的情况下，交换减少一个往返：

      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

在机制规定交换中发送的第一份数据是从客户端到服务器、且附加数据随成功结果一起发送给客户端、且协议提供了支持两者的字段时，交换减少两个往返：

      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 [ASCII] 大写字母、数字、连字符和/或下划线组成。在以下增广巴科斯-瑙尔范式（ABNF）[RFC4234] 语法中，<sasl-mech> 产生式定义了 SASL 机制名称的语法。

      sasl-mech    = 1*20mech-char
      mech-char    = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE
      ; mech-char is restricted to A-Z (uppercase only), 0-9, -, and _
      ; from ASCII character set.

      UPPER-ALPHA  = %x41-5A  ; A-Z (uppercase only)
      DIGIT        = %x30-39  ; 0-9
      HYPHEN       = %x2D ; hyphen (-)
      UNDERSCORE   = %x5F ; underscore (_)

SASL 机制名称按第 7.1 节所述进行注册。

3.2. 机制协商

机制协商是协议特有的。

通常，协议会规定：服务器通过协议提供的某种设施，向客户端广播所支持且可用的机制；然后客户端从该列表中选取它支持并认为合适的"最佳"机制。

注意，机制协商不受后续认证交换的保护，因此若未以其他方式保护，便容易遭受降级攻击。

为检测降级攻击，协议可允许客户端在认证交换之后、并且安装了至少具有数据完整性保护的数据安全层之后，发现可用的机制。这使客户端能够检测服务器所支持机制列表的变更。

3.3. 请求认证交换

认证交换由客户端发起，即请求通过它指定的机制进行认证。客户端发送一条包含该机制名称的消息给服务器。消息的细节是协议特有的。

注意，机制名称不受机制本身保护，因此若未以其他方式作完整性保护，便可能被攻击者篡改。

在机制被定义为允许客户端首先发送数据、且协议的请求消息包含可选的初始响应字段时，客户端可在认证请求消息中包含对初始质询的响应。

3.4. 质询与响应

认证交换涉及一组或多组服务器质询与客户端响应，其细节是机制特有的。这些质询与响应封装在协议消息中，其细节是协议特有的。

通过这些质询与响应，机制可以：

向服务器认证客户端；
向客户端认证服务器；
传输授权身份字符串；
协商安全层；以及
提供其他服务。

安全层的协商可能涉及：协商该层中将提供的安全服务、这些服务将如何提供，以及协商每一方能够在层中接收的最大密文缓冲区大小（见第 3.6 节）。

在收到认证请求或任何客户端响应之后，服务器可发出质询、中止交换，或指示交换的结果。在收到质询之后，客户端机制可发出响应或中止交换。

3.4.1. 授权身份字符串

授权身份字符串是一个由零个或多个 Unicode [Unicode] 字符组成的序列，排除 NUL（U+0000）字符，表示拟充当的身份。

若授权身份字符串缺失，客户端请求充当服务器与其凭据相关联的身份。空字符串等同于缺失的授权身份。

非空的授权身份字符串表示客户端希望充当由该字符串所表示的身份。在这种情况下，该字符串所表示的身份形式，以及该字符串的确切语法与语义，是协议特有的。

虽然在认证交换中传输授权身份字符串所用的字符编码方案是机制特有的，但机制应当能够承载整个 Unicode 字符集（NUL 字符除外）。

3.5. 中止认证交换

客户端或服务器若不愿意或不能够继续（或进入）某个认证交换，可能希望中止它。

客户端可通过向服务器发送一条消息（其细节是协议特有的）来中止认证交换，表明该交换已被中止。协议可能要求服务器针对客户端的该中止消息返回一条消息作为响应。

类似地，服务器可通过向客户端发送一条消息（其细节是协议特有的）来中止认证交换，表明该交换已被中止。

3.6. 认证结果

在认证交换结束时，服务器向客户端发送一条消息（其细节是协议特有的），指示交换的结果。

在以下情况下，结果不成功：

认证交换因任何原因失败；
无法验证客户端的凭据；
服务器无法将某个身份与客户端凭据相关联；
客户端提供的授权身份字符串格式有误；
与客户端凭据相关联的身份未被授权充当所请求的授权身份；
协商得到的安全层（或其缺失）不合适；或
服务器因任何原因不愿意向客户端提供服务。

协议可在该结果消息中包含一个可选的附加数据字段。该字段仅当结果成功时方可包含附加数据。

若结果成功且协商了安全层，则安装该层。若结果不成功，或未协商安全层，则任何既有的安全层保持不变。

服务器提供的结果消息可以为客户端提供一种区分方式：哪些错误最好通过重新提示用户输入其凭据来处理，哪些错误最好通过告诉用户稍后重试来处理，哪些错误需要用户联系系统管理员解决（示例见 SYS 与 AUTH POP 响应码 [RFC3206] 规范）。这种区分在计划的服务器维护期间尤其有用，因为它降低了支持成本。同样重要的是，服务器可以被配置为：结果消息不会区分具有无效凭据的有效用户与无效用户。

3.7. 安全层

SASL 机制可在安全层中提供范围广泛的服务。典型服务包括数据完整性与数据机密性。不提供安全层的 SASL 机制被视为协商了无安全层。

若在认证协议交换中协商使用了安全层，则该层由服务器在指示认证交换结果之后安装，并由客户端在收到结果指示时安装。在这两种情况下，该层都在传输进一步协议数据之前安装。该层在协议数据流中生效的确切位置是协议特有的。

安全层一旦在协议数据流中生效，便一直有效，直到安装了后续协商的安全层，或底层传输连接被关闭。

生效时，安全层将协议数据处理为受保护数据的缓冲区。如果安全层在任何时候无法或不愿继续产生保护协议数据的缓冲区，则底层传输连接 MUST 被关闭。如果安全层无法解码收到的缓冲区，底层连接 MUST 被关闭。在这两种情况下，底层传输连接 SHOULD 被优雅地关闭。

每个受保护数据缓冲区在底层传输连接上传输时，是一个八位组序列，前面带有以网络字节序表示的四八位组字段，表示该缓冲区的长度。受保护数据缓冲区的长度 MUST 不大于对端所期望的最大大小。在收到其值大于最大大小的长度字段时，接收方 SHOULD 关闭连接，因为这可能是攻击的迹象。

每一方所期望的最大大小由机制固定，或通过协商、或由其规范确定。

3.8. 多次认证

除非协议明确允许（如协议技术规范中所述），在一个协议会话中只能有一次成功的 SASL 认证交换。在这种情况下，一旦认证交换成功完成，进一步发起认证交换的尝试将失败。

在协议允许进行多次成功的 SASL 认证交换时，任何情况下都不得使多个 SASL 安全层同时生效。若某安全层已生效，而后续的 SASL 协商选择了第二个安全层，则第二个安全层替换第一个。若某安全层已生效，而后续的 SASL 协商未选择安全层，则原先的安全层保持生效。

在协议允许进行多次成功的 SASL 协商时，失败的 SASL 认证交换对先前已建立的认证与授权状态的影响，是协议特有的。应查阅协议的技术规范，以确定先前的认证与授权状态是继续保持有效、变为匿名状态，还是以其他方式受到影响。不论对先前已建立的认证与授权状态有何协议特有的影响，先前协商的安全层保持生效。

4. 协议要求

为使协议能够提供 SASL 服务，其规范 MUST 提供以下信息：

一个服务名，从 [RFC2743] 第 4.1 节所述的、用于 GSSAPI 基于主机服务名形式的 "service" 元素注册表中选取。注意该注册表由所有 GSSAPI 与 SASL 机制共享。
详述协议提供的任何机制协商设施（见第 3.2 节）。
协议 SHOULD 规定一种设施，使客户端能够在发起 SASL 交换之前以及安装该交换协商出的安全层之后，发现服务器向客户端提供的 SASL 机制名称。后者对于让客户端检测降级攻击很重要。该设施通常通过协议的扩展或能力发现设施提供。
定义认证交换所需的消息，包括以下内容：
1. 发起认证交换的消息（见第 3.3 节）。
  该消息 MUST 包含用于携带客户端所选机制名称的字段。
  
  该消息 SHOULD 包含用于携带初始响应的可选字段。若该消息定义了此字段，规范 MUST 描述带有空初始响应的消息与不带初始响应的消息如何区分。该字段 MUST 能够携带任意八位组序列（包括零长度序列以及包含零值八位组的序列）。
2. 传输服务器质询与客户端响应的消息（见第 3.4 节）。
  这些消息中的每一个 MUST 能够携带任意八位组序列（包括零长度序列以及包含零值八位组的序列）。
3. 指示认证交换结果的消息（见第 3.6 节）。
  该消息 SHOULD 包含用于携带成功结果附加数据的可选字段。若该消息定义了此字段，规范 MUST 描述带有空附加数据的消息与不带附加数据的消息如何区分。该字段 MUST 能够携带任意八位组序列（包括零长度序列以及包含零值八位组的序列）。
规定非空授权身份字符串的语法与语义（见第 3.4.1 节）。
为避免由于不同的规范化处理导致的互操作问题，协议规范 MUST 精确详述非空授权身份字符串在何处（客户端或服务器）以及如何进行准备（包括所有规范化），以便进行比较及其他适用功能，确保正常运作。

鼓励规范规定使用既有的授权身份形式以及既有的字符串表示，例如简单用户名 [RFC4013]。

当规范未精确规定 SASL 中的身份如何与协议中其他位置（例如访问控制策略语句中）使用的身份相关联时，协议提供某种设施或许是适当的，使客户端能够发现关于这些已建立身份的（例如用于作出访问控制决策的身份的表示方式等）信息。
详述协议提供的、允许客户端和/或服务器中止认证交换的任何设施（见第 3.5 节）。
支持多次认证的协议通常允许客户端通过发起新的认证交换来中止正在进行的认证交换。不支持多次认证的协议可能要求客户端关闭连接并重新开始，以中止正在进行的认证交换。

协议通常允许服务器通过返回非成功结果消息来中止正在进行的认证交换。
精确标识新协商的安全层在双向上的何处开始生效（见第 3.7 节）。
通常，规范要求安全层在服务器所发送数据中、结果消息之后的第一个八位组处开始生效，在客户端所发送数据中、收到结果消息之后的第一个八位组处开始生效。
若协议支持其他分层安全服务，例如传输层安全（TLS）[RFC4346]，规范 MUST 规定安全层施加于协议数据的顺序。
例如，在协议同时支持 TLS 与 SASL 安全层时，规范可规定以下任一方式：
1. SASL 安全层始终先施加于发送数据，因此后施加于接收数据；
2. SASL 安全层始终后施加于发送数据，因此先施加于接收数据；
3. 层按安装顺序施加；
4. 层按安装顺序的逆序施加；或
5. TLS 与 SASL 安全层均不可安装。
指明协议是否支持多次认证（见第 3.8 节）。若支持，协议 MUST 详述失败的 SASL 认证交换对先前已建立的认证与授权状态的影响。

协议规范 SHOULD 避免规定会妨碍替换适用机制的实现要求。一般而言，协议规范 SHOULD 保持机制中立。对此建议存在若干合理的例外，包括：

详述凭据（机制特有）在协议中如何管理；
详述认证身份（机制特有）与授权身份（协议特有）如何相互关联；以及
详述哪些机制适用于该协议。

5. 机制要求

SASL 机制规范 MUST 提供以下信息：

机制名称（见第 3.1 节）。该名称 MUST 按第 7.1 节所述进行注册。
认证交换的服务器质询与客户端响应的定义，以及以下内容：
1. 指明机制是 client-first（客户端先）、variable（可变）还是 server-first（服务器先）。若 SASL 机制被定义为 client-first，而客户端未在认证请求中发送初始响应，则首个服务器质询 MUST 为空（EXTERNAL 机制即为此例）。若 SASL 机制被定义为 variable，则规范需要说明当认证请求中的初始客户端响应被省略时服务器的行为（DIGEST-MD5 机制 [DIGEST-MD5] 即为此例）。若 SASL 机制被定义为 server-first，则客户端 MUST NOT 在认证请求中发送初始客户端响应（CRAM-MD5 机制 [CRAM-MD5] 即为此例）。
2. 指明服务器在指示成功结果时是否预期提供附加数据。若是，且服务器将该附加数据作为质询发送，则规范 MUST 指明对该质询的响应为空响应。
SASL 机制 SHOULD 设计为尽量减少完成交换所需的质询与响应的数量。
指明机制是否能够传输授权身份字符串（见第 3.4.1 节）。虽然一些遗留机制无法传输授权身份（即对这些机制而言授权身份始终为空字符串），但新定义的机制 SHOULD 能够传输授权身份字符串。机制 SHOULD NOT 既能够传输无授权身份字符串、又能够传输空授权身份。
能够传输授权身份字符串的机制 MUST 能够传输任意非空的 Unicode 字符序列，但包含 NUL（U+0000）字符的除外。机制 SHOULD 使用 UTF-8 [RFC3629] 转换格式。规范 MUST 详述机制特有的、可能出现在授权身份字符串中的任何 Unicode 码点如何被转义，以避免在解码授权身份字符串时产生歧义。通常，带有特殊字符的机制要求这些特殊字符在字符串（以特定 Unicode 转换格式编码之后）中使用某种数据编码方案（例如 Base64 [RFC3548]）进行转义或编码。
规范 MUST 详述机制是否提供安全层。若提供，规范 MUST 详述该层提供的安全及其他服务，以及这些服务如何实现。
若机制所使用的底层加密技术支持数据完整性，则机制规范 MUST 对授权身份的传输以及安全层的协商进行完整性保护。

SASL 机制 SHOULD 保持协议中立。

SASL 机制 SHOULD 复用既有的凭据与身份形式，以及相关语法与语义。

SASL 机制 SHOULD 使用 UTF-8 转换格式 [RFC3629] 来编码待传输的 Unicode [Unicode] 码点。

为避免由于不同的规范化处理导致的互操作问题，当机制要求将字符数据（授权身份字符串除外）用作密码学函数和/或比较函数的输入时，规范 MUST 精确详述该字符数据在何处（客户端或服务器）以及如何进行准备（包括所有规范化），以便输入该函数，确保正常运行。

对于认证凭据中的简单用户名和/或口令，SHOULD 规定使用 SASLprep [RFC4013]（StringPrep [RFC3454] 准备算法的一个配置文件）作为准备算法。

机制 SHOULD NOT 将授权身份字符串用于生成任何长期密码学密钥或哈希，因为没有要求授权身份字符串是规范化的。这里的"长期"指长于其生成所在的认证交换的持续时间。也就是说，由于不同的客户端（同一或不同协议）可能提供语义上等价的、不同的授权身份字符串，将授权身份字符串用于生成密码学密钥与哈希很可能会导致互操作及其他问题。

6. 安全考量

安全问题在本文档通篇均有讨论。

许多既有 SASL 机制在认证交换中不能提供针对被动攻击（更不用说主动攻击）的充分保护。许多既有 SASL 机制不提供安全层。希望未来的 SASL 机制能够在认证交换中针对被动与主动攻击提供强力保护，并提供带有强基本数据安全特性（例如数据完整性与数据机密性）服务的安全层。也希望未来的机制能够提供更高级的数据安全服务，例如重新生成密钥（见第 6.3 节）。

无论如何，SASL 框架都容易受到降级攻击。第 6.1.2 节提供了多种预防或检测这些攻击的方法。在某些情况下，适合使用 SASL 之外的数据完整性保护服务（例如 TLS）来防范 SASL 中的降级攻击。当可用的机制本身不能对认证交换和/或协议数据提供足够的完整性及/或机密性保护时，使用外部保护性的安全服务也很重要。

6.1. 主动攻击

6.1.1. 劫持攻击

当客户端选择带有至少完整性保护的 SASL 安全层时，该保护可作为对抗主动攻击者劫持连接并修改安全层建立之后所发送协议数据的对策。当 SASL 安全层中的安全服务报告协议数据缺乏数据完整性时，实现 SHOULD 关闭连接。

6.1.2. 降级攻击

任何对安全性敏感的协议协商都应在安装了具有数据完整性保护的安全层之后进行，这一点很重要。协议的设计应使得在此安装之前进行的协商，在完成安装之后重新进行验证。SASL 机制的协商是对安全性敏感的。

当客户端与服务器协商认证机制和/或其他安全特性时，主动攻击者有可能使一方使用可用的最不安全的安全服务。例如，攻击者可以修改服务器广播的机制列表，或修改机制响应中客户端广播的安全特性列表。为防范此类攻击，实现 SHOULD NOT 广播无法满足其最低安全要求的机制和/或特性，SHOULD NOT 进入或继续无法满足其最低安全要求的认证交换，并 SHOULD 验证已完成的认证交换所产生的安全服务满足其最低安全要求。注意每一端都需要独立验证其安全要求是否得到满足。

为检测降级到（最或较）不安全的受支持机制，客户端可以通过协议的机制发现设施，在 SASL 认证交换之前以及安装了协商出的 SASL 安全层（至少具有数据完整性保护）之后，发现服务器向客户端提供的 SASL 机制。如果客户端发现完整性受保护的列表（安装安全层后获得的列表）包含比先前所获列表中更强的机制，客户端应假定先前获得的列表被攻击者修改，并 SHOULD 关闭底层传输连接。

客户端发起 SASL 交换（包括选择 SASL 机制）是以明文方式进行的，可能被主动攻击者修改。对于任何新的 SASL 机制，重要的一点是要将其设计为：主动攻击者无法通过修改 SASL 机制名称和/或质询与响应，来获得具有较弱安全属性的认证。

安全特性的多级协商容易遭受降级攻击。协议设计者应避免在协议中提供更高层的安全特性协商（例如在 SASL 机制协商之上），机制设计者应避免在机制中提供更低层的安全特性协商（例如在 SASL 机制协商之下）。

6.1.3. 重放攻击

某些机制可能遭受重放攻击，除非受到外部数据安全服务（例如 TLS）的保护。

6.1.4. 截断攻击

大多数既有 SASL 安全层本身不提供针对截断攻击的保护。在截断攻击中，主动攻击者导致协议会话被关闭，造成可能被完整性保护的、可能被截断的数据流，导致一方或双方协议对等方出现有利于攻击者的不当行为。在面向连接的、应用层协议中，截断攻击相当容易防御。协议可通过确保每次信息交换都有明确的最终结果、每个协议会话都有优雅的关闭机制，并且这些都被完整性保护，来防范此类攻击。

6.1.5. 其他主动攻击

当认证协议交换协商使用安全层时，接收方 SHOULD 优雅地处理任何大于已定义/协商的最大大小的受保护数据缓冲区。特别是，它 MUST NOT 盲目分配缓冲区大小字段所指定的内存数量，因为这可能导致"内存不足"状况。如果接收方检测到大块数据，SHOULD 关闭连接。

6.2. 被动攻击

许多机制会遭受各种被动攻击，包括对未受保护的凭据信息的简单窃听，以及对受保护凭据信息的在线与离线字典攻击。

6.3. 重新生成密钥

SASL 机制安全层的、安全的或管理上允许的生命周期是有限的。密码学密钥会随着使用和时间推移而变弱；密码分析者在某个密钥首次使用之后所拥有的时间与/或密文越多，就越容易对该密钥发起攻击。

对安全层生命周期的管理限制可采用 X.509 证书、Kerberos V 票据或目录中表达的时间限制形式，且常常是所期望的。在实践中，管理生命周期限制的一个可能后果是，应用可能在应用协议运行中途（例如可能在大数据传输过程中）发现安全层停止工作。其结果将是连接被关闭（见第 3.7 节），从而导致不愉快的用户体验。

重新生成密钥（密钥重新协商过程）是解决密码学密钥变弱的一种方法。SASL 框架本身不提供重新生成密钥的能力；SASL 机制可以提供。未来的 SASL 机制设计者应考虑提供重新生成密钥的服务。

对于希望在机制不提供重新生成密钥能力的情况下重新生成 SASL 安全层密钥的实现，SHOULD 重新认证相同的标识并替换已过期或即将过期的安全层。此方法需要应用协议对重新认证的支持（见第 3.8 节）。

6.4. 其他考量

协议设计者与实现者应当理解机制的安全考量，以便能够选择适用于其需求的机制。

分布式服务器实现在如何信任其他方方面需要谨慎。特别是，认证秘密只应披露给那些被信任、会以披露方可接受的方式管理和使用这些秘密的其他方。使用 SASL 的应用假定：即使攻击者选择了要由安全层保护的数据，提供数据机密性的 SASL 安全层也是安全的。类似地，应用假定 SASL 安全层是安全的，即使攻击者能够操纵安全层的密文输出。期望新的 SASL 机制满足这些假设。

Unicode 安全考量 [UTR36] 适用于授权身份字符串；在使用了 UTF-8 [RFC3629] 的情况下，UTF-8 的安全考量也适用。SASLprep [RFC4013] 与 StringPrep [RFC3454] 的安全考量在适用时也适用。

7. IANA 考量

IANA 维护 SASL 机制注册表。该注册表当前位于 <http://www.iana.org/assignments/sasl-mechanisms>。

该注册表的目的不仅在于确保用于命名 SASL 机制的值的唯一性，还在于提供一个权威参考，指向详述每个可在 Internet 上使用的 SASL 机制的技术规范。

SASL 机制没有命名约定；任何符合 SASL 机制名称语法的名称都可以注册。

第 7.1.1 节详述的流程用于注册命名特定单个机制的值。

第 7.1.2 节详述的流程用于注册命名一组相关机制的值。

如第 7.1.3 节所述，可在注册表中加入注释；如第 7.1.4 节所述，注释可更改。

SASL 机制注册表已更新，以反映本文档提供了 SASL 的权威技术规范，且本节提供了该注册表的注册流程。

7.1. SASL 机制注册表

7.1.1. 机制名称注册流程

IANA 将基于"先到先得"（First Come First Served）原则注册新的 SASL 机制名称，如 BCP 26 [RFC2434] 所定义。IANA 有权拒绝明显虚假的注册请求，但不会对注册表中所作声明进行任何审查。

      Subject: Registration of SASL mechanism X

      SASL mechanism name (or prefix for the family):

      Security considerations:

      Published specification (recommended):

      Person & email address to contact for further information:

      Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)

      Owner/Change controller:

      Note: (Any other information that the author deems relevant may be
      added here.)

并通过电子邮件发送至 IANA，地址为 <iana@iana.org>。

虽然此注册流程不要求专家审查，但仍鼓励 SASL 机制的作者在任何可行时寻求社区的审查与评论。作者可以通过将所提议机制的规范作为 Internet-Draft 发布来寻求社区审查。旨在广泛使用的 SASL 机制应在适当时通过常规 IETF 流程实现标准化。

7.1.2. 族名称注册流程

如上所述，SASL 机制没有通用的命名约定。但是，规范可以为一组相关的 SASL 机制（一个 SASL 机制的"族"）保留 SASL 机制命名空间的一部分。每个 SASL 机制族由一个唯一前缀（例如 X-）标识。注册新的 SASL 机制族名称需要专家审查，如 BCP 26 [RFC2434] 所定义。

      Subject: Registration of SASL mechanism family X

      SASL family name (or prefix for the family):

      Security considerations:

      Published specification (recommended):

      Person & email address to contact for further information:

      Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)

      Owner/Change controller:

      Note: (Any other information that the author deems relevant may be
      added here.)

并通过电子邮件发送至 IETF SASL 邮件列表 <ietf-sasl@imc.org>，并抄送 IANA <iana@iana.org>。在 IETF SASL 邮件列表上留出两周社区意见征询期后，专家将确定注册请求的适当性，并通知请求者、邮件列表与 IANA，批准或驳回该请求。

审查应聚焦于所请求的族名称对于拟议用途的适当性，以及所提议的命名与注册计划对于该族中既有与未来机制名称的适当性。此请求审查的范围可能涉及对所提供的任何技术规范的相关方面（例如其 IANA 考量一节）的考量。但是，此审查仅聚焦于所请求注册的适当性，而非所提供的任何技术规范的全面健全性。

鼓励作者通过将技术规范作为 Internet-Draft 发布、并向适当的 IETF 邮件列表征集意见来寻求社区审查。

7.1.3. 关于 SASL 机制注册的评论

对已注册的 SASL 机制/族的评论，应首先发送给该机制/族的"所有者"和/或 <ietf-sasl@imc.org> 邮件列表。

评论提交者在合理尝试联系所有者之后，可通过向 <iana@iana.org> 发送邮件，请求 IANA 将其评论附于 SASL 机制注册本身。由 IANA 自行决定，IANA 可将该评论附于 SASL 机制的注册。

7.1.4. 变更控制

一旦 SASL 机制注册由 IANA 发布，作者可以请求对其定义进行变更。变更请求遵循与注册请求相同的流程。

SASL 机制的所有者可通过通知 IANA，将 SASL 机制的责任移交给其他个人或机构；这无需讨论或审查即可进行。

IESG 可重新分配 SASL 机制的责任。最常见的情况是为了对以下机制进行变更：其注册作者已去世、失去联系，或因其他原因无法做出对社区重要的变更。

SASL 机制注册不得删除；被认为不再适合使用的机制可通过对"预期用途"字段的变更被声明为 OBSOLETE；此类 SASL 机制将在 IANA 发布的列表中明确标注。

IESG 被视为所有处于 IETF 标准跟踪上的 SASL 机制的所有者。

7.2. 注册变更

IANA 已对 SASL 机制注册表作如下更新：

将 KERBEROS_V4 与 SKEY 机制注册的"预期用途"变更为 OBSOLETE。

将 EXTERNAL 机制的"已发布规范"变更为本文档，如下所示：

      Subject: Updated Registration of SASL mechanism EXTERNAL
      Family of SASL mechanisms: NO
      SASL mechanism name: EXTERNAL
      Security considerations: See A.3 of RFC 4422
      Published specification (optional, recommended): RFC 4422
      Person & email address to contact for further information:
          Alexey Melnikov <Alexey.Melnikov@isode.com>
      Intended usage: COMMON
      Owner/Change controller: IESG <iesg@ietf.org>
      Note: Updates existing entry for EXTERNAL

8. 参考文献

8.1. 规范性参考文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2244] Newman, C. and J. G. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings (stringprep)", RFC 3454, December 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ASCII] Coded Character Set--7-bit American Standard Code for Information Interchange, ANSI X3.4-1986.
[Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the "Unicode Standard Annex #27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
[CharModel] Whistler, K. and M. Davis, "Unicode Technical Report #17, Character Encoding Model", UTR17, <http://www.unicode.org/unicode/reports/tr17/>, August 2000.
[Glossary] The Unicode Consortium, "Unicode Glossary", <http://www.unicode.org/glossary/>.

8.2. 资料性参考文献

[RFC3206] Gellens, R., "The SYS and AUTH POP Response Codes", RFC 3206, February 2002.
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[SASL-GSSAPI] Melnikov, A. (Editor), "The Kerberos V5 (GSSAPI) SASL Mechanism", Work in Progress, May 2006.
[UTR36] Davis, M., "(Draft) Unicode Technical Report #36, Character Encoding Model", UTR17, <http://www.unicode.org/unicode/reports/tr36/>, February 2005.
[CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", Work in Progress.
[DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest Authentication as a SASL Mechanism", Work in Progress, March 2006.

9. 致谢

本文档是对 John Myers 所撰写的 RFC 2222 的修订。

本次修订是 IETF 简单认证与安全层（SASL）工作组的产品。

以下个人对本次修订作出了重大贡献：Abhijit Menon-Sen、Hallvard Furuseth、Jeffrey Hutzelman、John Myers、Luke Howard、Magnus Nystrom、Nicolas Williams、Peter Saint-Andre、RL 'Bob' Morgan、Rob Siemborski、Sam Hartman、Simon Josefsson、Tim Alsop 与 Tony Hansen。

附录 A. SASL EXTERNAL 机制

本附录为规范性。

EXTERNAL 机制允许客户端请求服务器使用机制之外的手段所建立的凭据来认证客户端。该外部手段可以是，例如，IP 安全 [RFC4301] 或 TLS [RFC4346] 服务。在客户端与服务器之间没有事先约定时，客户端无法对服务器使用了何种外部手段获取客户端凭据作出任何假设，也无法对凭据的形式作出假设。例如，客户端不能假定服务器将使用客户端通过 TLS 建立的凭据。

A.1. EXTERNAL 技术规范

该机制的名称为 "EXTERNAL"。

该机制不提供安全层。

该机制能够传输授权身份字符串。若为空，客户端请求充当服务器已与其凭据相关联的身份。若非空，客户端请求充当由该字符串所表示的身份。

客户端应在认证交换中首先发送数据。当客户端在其发起认证交换的请求中未提供初始响应数据时，服务器应以一个空的初始质询回应该请求，然后客户端提供其初始响应。

客户端发送包含所请求授权身份字符串的 UTF-8 [RFC3629] 编码的初始响应。当客户端请求充当由（非空的）字符串所表示的身份时，该响应非空。当客户端请求充当服务器与其认证凭据相关联的身份时，该响应为空。

初始响应的语法以下文详述的 <extern-initial-resp> 产生式的值规定，使用增广巴科斯-瑙尔范式（ABNF）[RFC4234] 记法。

      external-initial-resp = authz-id-string
      authz-id-string       = *( UTF8-char-no-nul )
      UTF8-char-no-nul      = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4
      UTF8-1-no-nul         = %x01-7F

其中 <UTF8-2>、<UTF8-3> 与 <UTF8-4> 产生式如 [RFC3629] 中所定义。

没有额外的质询与响应。

因此，服务器返回认证交换的结果。

在以下情况下交换失败：

客户端尚未通过外部手段建立其凭据；
客户端的凭据不充分；
客户端提供了空的授权身份字符串，而服务器不愿意或无法将授权身份与其凭据相关联；
客户端提供的非空授权身份字符串，按适用应用协议规范的语法要求属无效；
客户端提供的非空授权身份字符串所表示的身份，客户端不被允许充当；或
服务器因任何其他原因不愿意或无法向客户端提供服务。

否则交换成功。在指示成功结果时，不提供附加数据。

A.2. SASL EXTERNAL 示例

本节提供 EXTERNAL 认证交换的示例。这些示例旨在帮助读者理解上述文字。这些示例并非定论。示例中使用应用配置访问协议（ACAP）[RFC2244]。

第一个示例展示使用空授权身份的 EXTERNAL。在此示例中，初始响应未随客户端发起认证交换的请求一起发送。

      S: * ACAP (SASL "DIGEST-MD5")
      C: a001 STARTTLS
      S: a001 OK "Begin TLS negotiation now"
      <TLS negotiation, further commands are under TLS layer>

      S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL")
      C: a002 AUTHENTICATE "EXTERNAL"
      S: + ""
      C: + ""
      S: a002 OK "Authenticated"

第二个示例展示使用授权身份 "fred@example.com" 的 EXTERNAL。在此示例中，初始响应随客户端发起认证交换的请求一起发送。这节省了一个往返。

      S: * ACAP (SASL "DIGEST-MD5")
      C: a001 STARTTLS
      S: a001 OK "Begin TLS negotiation now"
      <TLS negotiation, further commands are under TLS layer>
      S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL")
      C: a002 AUTHENTICATE "EXTERNAL" {16+}
      C: fred@example.com
      S: a002 NO "Cannot assume requested authorization identity"

A.3. 安全考量

EXTERNAL 机制不提供安全保护；它容易受到客户端或服务器的欺骗、主动攻击以及窃听。只有当已建立适当的安全服务时，才应使用它。

附录 B. 自 RFC 2222 以来的变更

本附录为非规范性。

在制作本文档时，RFC 2222 中的材料被大幅重写。

RFC 2222 未声明授权身份字符串是 Unicode 字符（更不用说字符数据）的字符串，这暗示授权身份字符串是八位组字符串。

授权身份字符串现被定义为 Unicode 字符的字符串。禁止 NUL（U+0000）字符。虽然协议规范负责定义授权身份形式以及 Unicode 字符串语法与相关语义，机制规范负责定义 Unicode 字符串如何在认证交换中承载。
删除了如下规定："在此情况下，若客户端不首先发送数据，则初始质询 MUST 被规定为空质询。"

对 EXTERNAL 机制作了以下技术变更：

授权身份字符串应采用 UTF-8 编码。

注意，协议与机制规范的要求已被大幅收紧。既有协议与机制规范需要更新以满足这些要求。

编辑地址

Alexey Melnikov
Isode Limited
5 Castle Business Village
36 Station Road
Hampton, Middlesex,
TW12 2BX, United Kingdom

EMail: Alexey.Melnikov@isode.com
URI: http://www.melnikov.ca/

Kurt D. Zeilenga
OpenLDAP Foundation

EMail: Kurt@OpenLDAP.org

完整版权声明

本文档受 BCP 78 所含的权利、许可与限制约束，除其中另有规定外，作者保留其全部权利。

本文档及其所含信息按"现状"（AS IS）提供，贡献者、其所代表或赞助（若有）的组织、Internet 协会与 Internet 工程任务组否认所有明示或暗示的担保，包括但不限于：关于使用本文档信息不会侵犯任何权利的任何担保，以及关于适销性或特定用途适用性的任何暗示担保。

知识产权

IETF 对于可能声称与本文档所描述技术的实施或使用相关、或与之有关的任何知识产权或其他权利的有效性或范围不持立场，也不表示其已作出任何独立努力来识别任何此类权利。关于 RFC 文档中权利相关程序的更多信息，见 BCP 78 与 BCP 79。

向 IETF 秘书处作出的知识产权披露副本、以及关于将可提供的许可的保证，或实施者或用户为获得使用此类专有权利的通用许可或授权而进行尝试的结果，可从 IETF 在线知识产权仓库 http://www.ietf.org/ipr 获取。

IETF 邀请任何利害关系方提请其注意任何可能涵盖实施本标准所需技术的版权、专利或专利申请，或其他专有权利。请将相关信息发送至 IETF，地址 ietf-ipr@ietf.org。

致谢

RFC 编辑职能的经费由 IETF 行政支持活动（IASA）提供。