1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/docs/rfc/rfc4422.txt	Mon Sep 14 15:17:45 2009 +0900
     1.3 @@ -0,0 +1,1851 @@
     1.4 +
     1.5 +
     1.6 +
     1.7 +
     1.8 +
     1.9 +
    1.10 +Network Working Group                                   A. Melnikov, Ed.
    1.11 +Request for Comments: 4422                                 Isode Limited
    1.12 +Obsoletes: 2222                                         K. Zeilenga, Ed.
    1.13 +Category: Standards Track                            OpenLDAP Foundation
    1.14 +                                                               June 2006
    1.15 +
    1.16 +
    1.17 +            Simple Authentication and Security Layer (SASL)
    1.18 +
    1.19 +Status of This Memo
    1.20 +
    1.21 +   This document specifies an Internet standards track protocol for the
    1.22 +   Internet community, and requests discussion and suggestions for
    1.23 +   improvements.  Please refer to the current edition of the "Internet
    1.24 +   Official Protocol Standards" (STD 1) for the standardization state
    1.25 +   and status of this protocol.  Distribution of this memo is unlimited.
    1.26 +
    1.27 +Copyright Notice
    1.28 +
    1.29 +   Copyright (C) The Internet Society (2006).
    1.30 +
    1.31 +Abstract
    1.32 +
    1.33 +   The Simple Authentication and Security Layer (SASL) is a framework
    1.34 +   for providing authentication and data security services in
    1.35 +   connection-oriented protocols via replaceable mechanisms.  It
    1.36 +   provides a structured interface between protocols and mechanisms.
    1.37 +   The resulting framework allows new protocols to reuse existing
    1.38 +   mechanisms and allows old protocols to make use of new mechanisms.
    1.39 +   The framework also provides a protocol for securing subsequent
    1.40 +   protocol exchanges within a data security layer.
    1.41 +
    1.42 +   This document describes how a SASL mechanism is structured, describes
    1.43 +   how protocols include support for SASL, and defines the protocol for
    1.44 +   carrying a data security layer over a connection.  In addition, this
    1.45 +   document defines one SASL mechanism, the EXTERNAL mechanism.
    1.46 +
    1.47 +   This document obsoletes RFC 2222.
    1.48 +
    1.49 +
    1.50 +
    1.51 +
    1.52 +
    1.53 +
    1.54 +
    1.55 +
    1.56 +
    1.57 +
    1.58 +
    1.59 +
    1.60 +
    1.61 +Melnikov & Zeilenga         Standards Track                     [Page 1]
    1.62 +
    1.63 +RFC 4422                          SASL                         June 2006
    1.64 +
    1.65 +
    1.66 +Table of Contents
    1.67 +
    1.68 +   1. Introduction ....................................................3
    1.69 +      1.1. Document Audiences .........................................4
    1.70 +      1.2. Relationship to Other Documents ............................4
    1.71 +      1.3. Conventions ................................................5
    1.72 +   2. Identity Concepts ...............................................5
    1.73 +   3. The Authentication Exchange .....................................6
    1.74 +      3.1. Mechanism Naming ...........................................8
    1.75 +      3.2. Mechanism Negotiation ......................................9
    1.76 +      3.3. Request Authentication Exchange ............................9
    1.77 +      3.4. Challenges and Responses ...................................9
    1.78 +           3.4.1. Authorization Identity String ......................10
    1.79 +      3.5. Aborting Authentication Exchanges .........................10
    1.80 +      3.6. Authentication Outcome ....................................11
    1.81 +      3.7. Security Layers ...........................................12
    1.82 +      3.8. Multiple Authentications ..................................12
    1.83 +   4. Protocol Requirements ..........................................13
    1.84 +   5. Mechanism Requirements .........................................16
    1.85 +   6. Security Considerations ........................................18
    1.86 +      6.1. Active Attacks ............................................19
    1.87 +           6.1.1. Hijack Attacks .....................................19
    1.88 +           6.1.2. Downgrade Attacks ..................................19
    1.89 +           6.1.3. Replay Attacks .....................................20
    1.90 +           6.1.4. Truncation Attacks .................................20
    1.91 +           6.1.5. Other Active Attacks ...............................20
    1.92 +      6.2. Passive Attacks ...........................................20
    1.93 +      6.3. Re-keying .................................................21
    1.94 +      6.4. Other Considerations ......................................21
    1.95 +   7. IANA Considerations ............................................22
    1.96 +      7.1. SASL Mechanism Registry ...................................22
    1.97 +      7.2. Registration Changes ......................................26
    1.98 +   8. References .....................................................26
    1.99 +      8.1. Normative References ......................................26
   1.100 +      8.2. Informative References ....................................27
   1.101 +   9. Acknowledgements ...............................................28
   1.102 +   Appendix A.  The SASL EXTERNAL Mechanism ..........................29
   1.103 +      A.1. EXTERNAL Technical Specification ..........................29
   1.104 +      A.2. SASL EXTERNAL Examples ....................................30
   1.105 +      A.3. Security Considerations ...................................31
   1.106 +   Appendix B.  Changes since RFC 2222 ...............................31
   1.107 +
   1.108 +
   1.109 +
   1.110 +
   1.111 +
   1.112 +
   1.113 +
   1.114 +
   1.115 +
   1.116 +
   1.117 +Melnikov & Zeilenga         Standards Track                     [Page 2]
   1.118 +
   1.119 +RFC 4422                          SASL                         June 2006
   1.120 +
   1.121 +
   1.122 +1.  Introduction
   1.123 +
   1.124 +   The Simple Authentication and Security Layer (SASL) is a framework
   1.125 +   for providing authentication and data security services in
   1.126 +   connection-oriented protocols via replaceable mechanisms.  SASL
   1.127 +   provides a structured interface between protocols and mechanisms.
   1.128 +   SASL also provides a protocol for securing subsequent protocol
   1.129 +   exchanges within a data security layer.  The data security layer can
   1.130 +   provide data integrity, data confidentiality, and other services.
   1.131 +
   1.132 +   SASL's design is intended to allow new protocols to reuse existing
   1.133 +   mechanisms without requiring redesign of the mechanisms and allows
   1.134 +   existing protocols to make use of new mechanisms without redesign of
   1.135 +   protocols.
   1.136 +
   1.137 +   SASL is conceptually a framework that provides an abstraction layer
   1.138 +   between protocols and mechanisms as illustrated in the following
   1.139 +   diagram.
   1.140 +
   1.141 +                  SMTP    LDAP    XMPP   Other protocols ...
   1.142 +                     \       |    |      /
   1.143 +                      \      |    |     /
   1.144 +                     SASL abstraction layer
   1.145 +                      /      |    |     \
   1.146 +                     /       |    |      \
   1.147 +              EXTERNAL   GSSAPI  PLAIN   Other mechanisms ...
   1.148 +
   1.149 +   It is through the interfaces of this abstraction layer that the
   1.150 +   framework allows any protocol to utilize any mechanism.  While this
   1.151 +   layer does generally hide the particulars of protocols from
   1.152 +   mechanisms and the particulars of mechanisms from protocols, this
   1.153 +   layer does not generally hide the particulars of mechanisms from
   1.154 +   protocol implementations.  For example, different mechanisms require
   1.155 +   different information to operate, some of them use password-based
   1.156 +   authentication, some of then require realm information, others make
   1.157 +   use of Kerberos tickets, certificates, etc.  Also, in order to
   1.158 +   perform authorization, server implementations generally have to
   1.159 +   implement identity mapping between authentication identities, whose
   1.160 +   form is mechanism specific, and authorization identities, whose form
   1.161 +   is application protocol specific.  Section 2 discusses identity
   1.162 +   concepts.
   1.163 +
   1.164 +   It is possible to design and implement this framework in ways that do
   1.165 +   abstract away particulars of similar mechanisms.  Such a framework
   1.166 +   implementation, as well as mechanisms implementations, could be
   1.167 +   designed not only to be shared by multiple implementations of a
   1.168 +   particular protocol but to be shared by implementations of multiple
   1.169 +   protocols.
   1.170 +
   1.171 +
   1.172 +
   1.173 +Melnikov & Zeilenga         Standards Track                     [Page 3]
   1.174 +
   1.175 +RFC 4422                          SASL                         June 2006
   1.176 +
   1.177 +
   1.178 +   The framework incorporates interfaces with both protocols and
   1.179 +   mechanisms in which authentication exchanges are carried out.
   1.180 +   Section 3 discusses SASL authentication exchanges.
   1.181 +
   1.182 +   To use SASL, each protocol (amongst other items) provides a method
   1.183 +   for identifying which mechanism is to be used, a method for exchange
   1.184 +   of mechanism-specific server-challenges and client-responses, and a
   1.185 +   method for communicating the outcome of the authentication exchange.
   1.186 +   Section 4 discusses SASL protocol requirements.
   1.187 +
   1.188 +   Each SASL mechanism defines (amongst other items) a series of
   1.189 +   server-challenges and client-responses that provide authentication
   1.190 +   services and negotiate data security services.  Section 5 discusses
   1.191 +   SASL mechanism requirements.
   1.192 +
   1.193 +   Section 6 discusses security considerations.  Section 7 discusses
   1.194 +   IANA considerations.  Appendix A defines the SASL EXTERNAL mechanism.
   1.195 +
   1.196 +1.1.  Document Audiences
   1.197 +
   1.198 +   This document is written to serve several different audiences:
   1.199 +
   1.200 +      -  protocol designers using this specification to support
   1.201 +         authentication in their protocol,
   1.202 +
   1.203 +      -  mechanism designers that define new SASL mechanisms, and
   1.204 +
   1.205 +      -  implementors of clients or servers for those protocols that
   1.206 +         support SASL.
   1.207 +
   1.208 +   While the document organization is intended to allow readers to focus
   1.209 +   on details relevant to their engineering, readers are encouraged to
   1.210 +   read and understand all aspects of this document.
   1.211 +
   1.212 +1.2.  Relationship to Other Documents
   1.213 +
   1.214 +   This document obsoletes RFC 2222.  It replaces all portions of RFC
   1.215 +   2222 excepting sections 7.1 (the KERBEROS_IV mechanism), 7.2 (the
   1.216 +   GSSAPI mechanism), 7.3 (the SKEY mechanism).  The KERBEROS_IV and
   1.217 +   SKEY mechanisms are now viewed as obsolete and their specifications
   1.218 +   provided in RFC 2222 are Historic.  The GSSAPI mechanism is now
   1.219 +   separately specified [SASL-GSSAPI].
   1.220 +
   1.221 +   Appendix B provides a summary of changes since RFC 2222.
   1.222 +
   1.223 +
   1.224 +
   1.225 +
   1.226 +
   1.227 +
   1.228 +
   1.229 +Melnikov & Zeilenga         Standards Track                     [Page 4]
   1.230 +
   1.231 +RFC 4422                          SASL                         June 2006
   1.232 +
   1.233 +
   1.234 +1.3.  Conventions
   1.235 +
   1.236 +   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   1.237 +   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   1.238 +   document are to be interpreted as described in BCP 14 [RFC2119].
   1.239 +
   1.240 +   Character names in this document use the notation for code points and
   1.241 +   names from the Unicode Standard [Unicode].  For example, the letter
   1.242 +   "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
   1.243 +
   1.244 +   Note: a glossary of terms used in Unicode can be found in [Glossary].
   1.245 +   Information on the Unicode character encoding model can be found in
   1.246 +   [CharModel].
   1.247 +
   1.248 +   In examples, "C:" and "S:" indicate lines of data to be sent by the
   1.249 +   client and server, respectively.  Lines have been wrapped for
   1.250 +   improved readability.
   1.251 +
   1.252 +2.  Identity Concepts
   1.253 +
   1.254 +   In practice, authentication and authorization may involve multiple
   1.255 +   identities, possibly in different forms (simple username, Kerberos
   1.256 +   principal, X.500 Distinguished Name, etc.), possibly with different
   1.257 +   representations (e.g., ABNF-described UTF-8 encoded Unicode character
   1.258 +   string, BER-encoded Distinguished Name).  While technical
   1.259 +   specifications often prescribe both the identity form and
   1.260 +   representation used on the network, different identity forms and/or
   1.261 +   representations may be (and often are) used within implementations.
   1.262 +   How identities of different forms relate to each other is, generally,
   1.263 +   a local matter.  In addition, the forms and representations used
   1.264 +   within an implementation are a local matter.
   1.265 +
   1.266 +   However, conceptually, the SASL framework involves two identities:
   1.267 +
   1.268 +      1) an identity associated with the authentication credentials
   1.269 +         (termed the authentication identity), and
   1.270 +
   1.271 +      2) an identity to act as (termed the authorization identity).
   1.272 +
   1.273 +   SASL mechanism specifications describe the credential form(s) (e.g.,
   1.274 +   X.509 certificates, Kerberos tickets, simple username/password) used
   1.275 +   to authenticate the client, including (where appropriate) the syntax
   1.276 +   and semantics of authentication identities carried in the
   1.277 +   credentials.  SASL protocol specifications describe the identity
   1.278 +   form(s) used in authorization and, in particular, prescribe the
   1.279 +   syntax and semantics of the authorization identity character string
   1.280 +   to be transferred by mechanisms.
   1.281 +
   1.282 +
   1.283 +
   1.284 +
   1.285 +Melnikov & Zeilenga         Standards Track                     [Page 5]
   1.286 +
   1.287 +RFC 4422                          SASL                         June 2006
   1.288 +
   1.289 +
   1.290 +   The client provides its credentials (which include or imply an
   1.291 +   authentication identity) and, optionally, a character string
   1.292 +   representing the requested authorization identity as part of the SASL
   1.293 +   exchange.  When this character string is omitted or empty, the client
   1.294 +   is requesting to act as the identity associated with the credentials
   1.295 +   (e.g., the user is requesting to act as the authentication identity).
   1.296 +
   1.297 +   The server is responsible for verifying the client's credentials and
   1.298 +   verifying that the identity it associates with the client's
   1.299 +   credentials (e.g., the authentication identity) is allowed to act as
   1.300 +   the authorization identity.  A SASL exchange fails if either (or
   1.301 +   both) of these verifications fails.  (The SASL exchange may fail for
   1.302 +   other reasons, such as service authorization failure.)
   1.303 +
   1.304 +   However, the precise form(s) of the authentication identities (used
   1.305 +   within the server in its verifications, or otherwise) and the precise
   1.306 +   form(s) of the authorization identities (used in making authorization
   1.307 +   decisions, or otherwise) are beyond the scope of SASL and this
   1.308 +   specification.  In some circumstances, the precise identity forms
   1.309 +   used in some context outside of the SASL exchange may be dictated by
   1.310 +   other specifications.  For instance, an identity assumption
   1.311 +   authorization (proxy authorization) policy specification may dictate
   1.312 +   how authentication and authorization identities are represented in
   1.313 +   policy statements.
   1.314 +
   1.315 +3.  The Authentication Exchange
   1.316 +
   1.317 +   Each authentication exchange consists of a message from the client to
   1.318 +   the server requesting authentication via a particular mechanism,
   1.319 +   followed by one or more pairs of challenges from the server and
   1.320 +   responses from the client, followed by a message from the server
   1.321 +   indicating the outcome of the authentication exchange.  (Note:
   1.322 +   exchanges may also be aborted as discussed in Section 3.5.)
   1.323 +
   1.324 +   The following illustration provides a high-level overview of an
   1.325 +   authentication exchange.
   1.326 +
   1.327 +      C: Request authentication exchange
   1.328 +      S: Initial challenge
   1.329 +      C: Initial response
   1.330 +      <additional challenge/response messages>
   1.331 +      S: Outcome of authentication exchange
   1.332 +
   1.333 +   If the outcome is successful and a security layer was negotiated,
   1.334 +   this layer is then installed (see Section 3.7).  This also applies to
   1.335 +   the following illustrations.
   1.336 +
   1.337 +
   1.338 +
   1.339 +
   1.340 +
   1.341 +Melnikov & Zeilenga         Standards Track                     [Page 6]
   1.342 +
   1.343 +RFC 4422                          SASL                         June 2006
   1.344 +
   1.345 +
   1.346 +   Some mechanisms specify that the first data sent in the
   1.347 +   authentication exchange is from the client to the server.  Protocols
   1.348 +   may provide an optional initial response field in the request message
   1.349 +   to carry this data.  Where the mechanism specifies that the first
   1.350 +   data sent in the exchange is from the client to the server, the
   1.351 +   protocol provides an optional initial response field, and the client
   1.352 +   uses this field, the exchange is shortened by one round-trip:
   1.353 +
   1.354 +      C: Request authentication exchange + Initial response
   1.355 +      <additional challenge/response messages>
   1.356 +      S: Outcome of authentication exchange
   1.357 +
   1.358 +   Where the mechanism specifies that the first data sent in the
   1.359 +   exchange is from the client to the server and this field is
   1.360 +   unavailable or unused, the client request is followed by an empty
   1.361 +   challenge.
   1.362 +
   1.363 +      C: Request authentication exchange
   1.364 +      S: Empty Challenge
   1.365 +      C: Initial Response
   1.366 +      <additional challenge/response messages>
   1.367 +      S: Outcome of authentication exchange
   1.368 +
   1.369 +   Should a client include an initial response in its request where the
   1.370 +   mechanism does not allow the client to send data first, the
   1.371 +   authentication exchange fails.
   1.372 +
   1.373 +   Some mechanisms specify that the server is to send additional data to
   1.374 +   the client when indicating a successful outcome.  Protocols may
   1.375 +   provide an optional additional data field in the outcome message to
   1.376 +   carry this data.  Where the mechanism specifies that the server is to
   1.377 +   return additional data with the successful outcome, the protocol
   1.378 +   provides an optional additional data field in the outcome message,
   1.379 +   and the server uses this field, the exchange is shortened by one
   1.380 +   round-trip:
   1.381 +
   1.382 +      C: Request authentication exchange
   1.383 +      S: Initial challenge
   1.384 +      C: Initial response
   1.385 +      <additional challenge/response messages>
   1.386 +      S: Outcome of authentication exchange with
   1.387 +         additional data with success
   1.388 +
   1.389 +   Where the mechanism specifies that the server is to return additional
   1.390 +   data to the client with a successful outcome and this field is
   1.391 +   unavailable or unused, the additional data is sent as a challenge
   1.392 +   whose response is empty.  After receiving this response, the server
   1.393 +   then indicates the successful outcome.
   1.394 +
   1.395 +
   1.396 +
   1.397 +Melnikov & Zeilenga         Standards Track                     [Page 7]
   1.398 +
   1.399 +RFC 4422                          SASL                         June 2006
   1.400 +
   1.401 +
   1.402 +      C: Request authentication exchange
   1.403 +      S: Initial challenge
   1.404 +      C: Initial response
   1.405 +      <additional challenge/response messages>
   1.406 +      S: Additional data challenge
   1.407 +      C: Empty Response
   1.408 +      S: Outcome of authentication exchange
   1.409 +
   1.410 +   Where mechanisms specify that the first data sent in the exchange is
   1.411 +   from the client to the server and additional data is sent to the
   1.412 +   client along with indicating a successful outcome, and the protocol
   1.413 +   provides fields supporting both, then the exchange takes two fewer
   1.414 +   round-trips:
   1.415 +
   1.416 +      C: Request authentication exchange + Initial response
   1.417 +      <additional challenge/response messages>
   1.418 +      S: Outcome of authentication exchange
   1.419 +         with additional data with success
   1.420 +
   1.421 +   instead of:
   1.422 +
   1.423 +      C: Request authentication exchange
   1.424 +      S: Empty Challenge
   1.425 +      C: Initial Response
   1.426 +      <additional challenge/response messages>
   1.427 +      S: Additional data challenge
   1.428 +      C: Empty Response
   1.429 +      S: Outcome of authentication exchange
   1.430 +
   1.431 +3.1.  Mechanism Naming
   1.432 +
   1.433 +   SASL mechanisms are named by character strings, from 1 to 20
   1.434 +   characters in length, consisting of ASCII [ASCII] uppercase letters,
   1.435 +   digits, hyphens, and/or underscores.  In the following Augmented
   1.436 +   Backus-Naur Form (ABNF) [RFC4234] grammar, the <sasl-mech> production
   1.437 +   defines the syntax of a SASL mechanism name.
   1.438 +
   1.439 +      sasl-mech    = 1*20mech-char
   1.440 +      mech-char    = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE
   1.441 +      ; mech-char is restricted to A-Z (uppercase only), 0-9, -, and _
   1.442 +      ; from ASCII character set.
   1.443 +
   1.444 +      UPPER-ALPHA  = %x41-5A  ; A-Z (uppercase only)
   1.445 +      DIGIT        = %x30-39  ; 0-9
   1.446 +      HYPHEN       = %x2D ; hyphen (-)
   1.447 +      UNDERSCORE   = %x5F ; underscore (_)
   1.448 +
   1.449 +   SASL mechanism names are registered as discussed in Section 7.1.
   1.450 +
   1.451 +
   1.452 +
   1.453 +Melnikov & Zeilenga         Standards Track                     [Page 8]
   1.454 +
   1.455 +RFC 4422                          SASL                         June 2006
   1.456 +
   1.457 +
   1.458 +3.2.  Mechanism Negotiation
   1.459 +
   1.460 +   Mechanism negotiation is protocol specific.
   1.461 +
   1.462 +   Commonly, a protocol will specify that the server advertises
   1.463 +   supported and available mechanisms to the client via some facility
   1.464 +   provided by the protocol, and the client will then select the "best"
   1.465 +   mechanism from this list that it supports and finds suitable.
   1.466 +
   1.467 +   Note that the mechanism negotiation is not protected by the
   1.468 +   subsequent authentication exchange and hence is subject to downgrade
   1.469 +   attacks if not protected by other means.
   1.470 +
   1.471 +   To detect downgrade attacks, a protocol can allow the client to
   1.472 +   discover available mechanisms subsequent to the authentication
   1.473 +   exchange and installation of data security layers with at least data
   1.474 +   integrity protection.  This allows the client to detect changes to
   1.475 +   the list of mechanisms supported by the server.
   1.476 +
   1.477 +3.3.  Request Authentication Exchange
   1.478 +
   1.479 +   The authentication exchange is initiated by the client by requesting
   1.480 +   authentication via a mechanism it specifies.  The client sends a
   1.481 +   message that contains the name of the mechanism to the server.  The
   1.482 +   particulars of the message are protocol specific.
   1.483 +
   1.484 +   Note that the name of the mechanism is not protected by the
   1.485 +   mechanism, and hence is subject to alteration by an attacker if not
   1.486 +   integrity protected by other means.
   1.487 +
   1.488 +   Where the mechanism is defined to allow the client to send data
   1.489 +   first, and the protocol's request message includes an optional
   1.490 +   initial response field, the client may include the response to the
   1.491 +   initial challenge in the authentication request message.
   1.492 +
   1.493 +3.4.  Challenges and Responses
   1.494 +
   1.495 +   The authentication exchange involves one or more pairs of server-
   1.496 +   challenges and client-responses, the particulars of which are
   1.497 +   mechanism specific.  These challenges and responses are enclosed in
   1.498 +   protocol messages, the particulars of which are protocol specific.
   1.499 +
   1.500 +   Through these challenges and responses, the mechanism may:
   1.501 +
   1.502 +      -  authenticate the client to the server,
   1.503 +
   1.504 +      -  authenticate the server to the client,
   1.505 +
   1.506 +
   1.507 +
   1.508 +
   1.509 +Melnikov & Zeilenga         Standards Track                     [Page 9]
   1.510 +
   1.511 +RFC 4422                          SASL                         June 2006
   1.512 +
   1.513 +
   1.514 +      -  transfer an authorization identity string,
   1.515 +
   1.516 +      -  negotiate a security layer, and
   1.517 +
   1.518 +      -  provide other services.
   1.519 +
   1.520 +   The negotiation of the security layer may involve negotiation of the
   1.521 +   security services to be provided in the layer, how these services
   1.522 +   will be provided, and negotiation of a maximum cipher-text buffer
   1.523 +   size each side is able to receive in the layer (see Section 3.6).
   1.524 +
   1.525 +   After receiving an authentication request or any client response, the
   1.526 +   server may issue a challenge, abort the exchange, or indicate the
   1.527 +   outcome of an exchange.  After receiving a challenge, a client
   1.528 +   mechanism may issue a response or abort the exchange.
   1.529 +
   1.530 +3.4.1.  Authorization Identity String
   1.531 +
   1.532 +   The authorization identity string is a sequence of zero or more
   1.533 +   Unicode [Unicode] characters, excluding the NUL (U+0000) character,
   1.534 +   representing the identity to act as.
   1.535 +
   1.536 +   If the authorization identity string is absent, the client is
   1.537 +   requesting to act as the identity the server associates with the
   1.538 +   client's credentials.  An empty string is equivalent to an absent
   1.539 +   authorization identity.
   1.540 +
   1.541 +   A non-empty authorization identity string indicates that the client
   1.542 +   wishes to act as the identity represented by the string.  In this
   1.543 +   case, the form of identity represented by the string, as well as the
   1.544 +   precise syntax and semantics of the string, is protocol specific.
   1.545 +
   1.546 +   While the character encoding schema used to transfer the
   1.547 +   authorization identity string in the authentication exchange is
   1.548 +   mechanism specific, mechanisms are expected to be capable of carrying
   1.549 +   the entire Unicode repertoire (with the exception of the NUL
   1.550 +   character).
   1.551 +
   1.552 +3.5.  Aborting Authentication Exchanges
   1.553 +
   1.554 +   A client or server may desire to abort an authentication exchange if
   1.555 +   it is unwilling or unable to continue (or enter into).
   1.556 +
   1.557 +   A client may abort the authentication exchange by sending a message,
   1.558 +   the particulars of which are protocol specific, to the server,
   1.559 +   indicating that the exchange is aborted.  The server may be required
   1.560 +   by the protocol to return a message in response to the client's abort
   1.561 +   message.
   1.562 +
   1.563 +
   1.564 +
   1.565 +Melnikov & Zeilenga         Standards Track                    [Page 10]
   1.566 +
   1.567 +RFC 4422                          SASL                         June 2006
   1.568 +
   1.569 +
   1.570 +   Likewise, a server may abort the authentication exchange by sending a
   1.571 +   message, the particulars of which are protocol specific, to the
   1.572 +   client, indicating that the exchange is aborted.
   1.573 +
   1.574 +3.6.  Authentication Outcome
   1.575 +
   1.576 +   At the conclusion of the authentication exchange, the server sends a
   1.577 +   message, the particulars of which are protocol specific, to the
   1.578 +   client indicating the outcome of the exchange.
   1.579 +
   1.580 +   The outcome is not successful if
   1.581 +
   1.582 +      -  the authentication exchange failed for any reason,
   1.583 +
   1.584 +      -  the client's credentials could not be verified,
   1.585 +
   1.586 +      -  the server cannot associate an identity with the client's
   1.587 +         credentials,
   1.588 +
   1.589 +      -  the client-provided authorization identity string is malformed,
   1.590 +
   1.591 +      -  the identity associated with the client's credentials is not
   1.592 +         authorized to act as the requested authorization identity,
   1.593 +
   1.594 +      -  the negotiated security layer (or lack thereof) is not
   1.595 +         suitable, or
   1.596 +
   1.597 +      -  the server is not willing to provide service to the client for
   1.598 +         any reason.
   1.599 +
   1.600 +   The protocol may include an optional additional data field in this
   1.601 +   outcome message.  This field can only include additional data when
   1.602 +   the outcome is successful.
   1.603 +
   1.604 +   If the outcome is successful and a security layer was negotiated,
   1.605 +   this layer is then installed.  If the outcome is unsuccessful, or a
   1.606 +   security layer was not negotiated, any existing security is left in
   1.607 +   place.
   1.608 +
   1.609 +   The outcome message provided by the server can provide a way for the
   1.610 +   client to distinguish between errors that are best dealt with by re-
   1.611 +   prompting the user for her credentials, errors that are best dealt
   1.612 +   with by telling the user to try again later, and errors where the
   1.613 +   user must contact a system administrator for resolution (see the SYS
   1.614 +   and AUTH POP Response Codes [RFC3206] specification for an example).
   1.615 +   This distinction is particularly useful during scheduled server
   1.616 +   maintenance periods as it reduces support costs.  It is also
   1.617 +   important that the server can be configured such that the outcome
   1.618 +
   1.619 +
   1.620 +
   1.621 +Melnikov & Zeilenga         Standards Track                    [Page 11]
   1.622 +
   1.623 +RFC 4422                          SASL                         June 2006
   1.624 +
   1.625 +
   1.626 +   message will not distinguish between a valid user with invalid
   1.627 +   credentials and an invalid user.
   1.628 +
   1.629 +3.7.  Security Layers
   1.630 +
   1.631 +   SASL mechanisms may offer a wide range of services in security
   1.632 +   layers.  Typical services include data integrity and data
   1.633 +   confidentiality.  SASL mechanisms that do not provide a security
   1.634 +   layer are treated as negotiating no security layer.
   1.635 +
   1.636 +   If use of a security layer is negotiated in the authentication
   1.637 +   protocol exchange, the layer is installed by the server after
   1.638 +   indicating the outcome of the authentication exchange and installed
   1.639 +   by the client upon receipt of the outcome indication.  In both cases,
   1.640 +   the layer is installed before transfer of further protocol data.  The
   1.641 +   precise position upon which the layer takes effect in the protocol
   1.642 +   data stream is protocol specific.
   1.643 +
   1.644 +   Once the security layer is in effect in the protocol data stream, it
   1.645 +   remains in effect until either a subsequently negotiated security
   1.646 +   layer is installed or the underlying transport connection is closed.
   1.647 +
   1.648 +   When in effect, the security layer processes protocol data into
   1.649 +   buffers of protected data.  If at any time the security layer is
   1.650 +   unable or unwilling to continue producing buffers protecting protocol
   1.651 +   data, the underlying transport connection MUST be closed.  If the
   1.652 +   security layer is not able to decode a received buffer, the
   1.653 +   underlying connection MUST be closed.  In both cases, the underlying
   1.654 +   transport connection SHOULD be closed gracefully.
   1.655 +
   1.656 +   Each buffer of protected data is transferred over the underlying
   1.657 +   transport connection as a sequence of octets prepended with a four-
   1.658 +   octet field in network byte order that represents the length of the
   1.659 +   buffer.  The length of the protected data buffer MUST be no larger
   1.660 +   than the maximum size that the other side expects.  Upon the receipt
   1.661 +   of a length field whose value is greater than the maximum size, the
   1.662 +   receiver SHOULD close the connection, as this might be a sign of an
   1.663 +   attack.
   1.664 +
   1.665 +   The maximum size that each side expects is fixed by the mechanism,
   1.666 +   either through negotiation or by its specification.
   1.667 +
   1.668 +3.8.  Multiple Authentications
   1.669 +
   1.670 +   Unless explicitly permitted in the protocol (as stated in the
   1.671 +   protocol's technical specification), only one successful SASL
   1.672 +   authentication exchange may occur in a protocol session.  In this
   1.673 +
   1.674 +
   1.675 +
   1.676 +
   1.677 +Melnikov & Zeilenga         Standards Track                    [Page 12]
   1.678 +
   1.679 +RFC 4422                          SASL                         June 2006
   1.680 +
   1.681 +
   1.682 +   case, once an authentication exchange has successfully completed,
   1.683 +   further attempts to initiate an authentication exchange fail.
   1.684 +
   1.685 +   Where multiple successful SASL authentication exchanges are permitted
   1.686 +   in the protocol, then in no case may multiple SASL security layers be
   1.687 +   simultaneously in effect.  If a security layer is in effect and a
   1.688 +   subsequent SASL negotiation selects a second security layer, then the
   1.689 +   second security layer replaces the first.  If a security layer is in
   1.690 +   effect and a subsequent SASL negotiation selects no security layer,
   1.691 +   the original security layer remains in effect.
   1.692 +
   1.693 +   Where multiple successful SASL negotiations are permitted in the
   1.694 +   protocol, the effect of a failed SASL authentication exchange upon
   1.695 +   the previously established authentication and authorization state is
   1.696 +   protocol specific.  The protocol's technical specification should be
   1.697 +   consulted to determine whether the previous authentication and
   1.698 +   authorization state remains in force, or changed to an anonymous
   1.699 +   state, or otherwise was affected.  Regardless of the protocol-
   1.700 +   specific effect upon previously established authentication and
   1.701 +   authorization state, the previously negotiated security layer remains
   1.702 +   in effect.
   1.703 +
   1.704 +4.  Protocol Requirements
   1.705 +
   1.706 +   In order for a protocol to offer SASL services, its specification
   1.707 +   MUST supply the following information:
   1.708 +
   1.709 +   1) A service name, to be selected from registry of "service" elements
   1.710 +      for the Generic Security Service Application Program Interface
   1.711 +      (GSSAPI) host-based service name form, as described in Section 4.1
   1.712 +      of [RFC2743].  Note that this registry is shared by all GSSAPI and
   1.713 +      SASL mechanisms.
   1.714 +
   1.715 +   2) Detail any mechanism negotiation facility that the protocol
   1.716 +      provides (see Section 3.2).
   1.717 +
   1.718 +      A protocol SHOULD specify a facility through which the client may
   1.719 +      discover, both before initiation of the SASL exchange and after
   1.720 +      installing security layers negotiated by the exchange, the names
   1.721 +      of the SASL mechanisms that the server makes available to the
   1.722 +      client.  The latter is important to allow the client to detect
   1.723 +      downgrade attacks.  This facility is typically provided through
   1.724 +      the protocol's extensions or capabilities discovery facility.
   1.725 +
   1.726 +   3) Definition of the messages necessary for authentication exchange,
   1.727 +      including the following:
   1.728 +
   1.729 +
   1.730 +
   1.731 +
   1.732 +
   1.733 +Melnikov & Zeilenga         Standards Track                    [Page 13]
   1.734 +
   1.735 +RFC 4422                          SASL                         June 2006
   1.736 +
   1.737 +
   1.738 +      a) A message to initiate the authentication exchange (see Section
   1.739 +         3.3).
   1.740 +
   1.741 +         This message MUST contain a field for carrying the name of the
   1.742 +         mechanism selected by the client.
   1.743 +
   1.744 +         This message SHOULD contain an optional field for carrying an
   1.745 +         initial response.  If the message is defined with this field,
   1.746 +         the specification MUST describe how messages with an empty
   1.747 +         initial response are distinguished from messages with no
   1.748 +         initial response.  This field MUST be capable of carrying
   1.749 +         arbitrary sequences of octets (including zero-length sequences
   1.750 +         and sequences containing zero-valued octets).
   1.751 +
   1.752 +      b) Messages to transfer server challenges and client responses
   1.753 +         (see Section 3.4).
   1.754 +
   1.755 +         Each of these messages MUST be capable of carrying arbitrary
   1.756 +         sequences of octets (including zero-length sequences and
   1.757 +         sequences containing zero-valued octets).
   1.758 +
   1.759 +      c) A message to indicate the outcome of the authentication
   1.760 +         exchange (see Section 3.6).
   1.761 +
   1.762 +         This message SHOULD contain an optional field for carrying
   1.763 +         additional data with a successful outcome.  If the message is
   1.764 +         defined with this field, the specification MUST describe how
   1.765 +         messages with an empty additional data are distinguished from
   1.766 +         messages with no additional data.  This field MUST be capable
   1.767 +         of carrying arbitrary sequences of octets (including zero-
   1.768 +         length sequences and sequences containing zero-valued octets).
   1.769 +
   1.770 +   4) Prescribe the syntax and semantics of non-empty authorization
   1.771 +      identity strings (see Section 3.4.1).
   1.772 +
   1.773 +      In order to avoid interoperability problems due to differing
   1.774 +      normalizations, the protocol specification MUST detail precisely
   1.775 +      how and where (client or server) non-empty authorization identity
   1.776 +      strings are prepared, including all normalizations, for comparison
   1.777 +      and other applicable functions to ensure proper function.
   1.778 +
   1.779 +      Specifications are encouraged to prescribe use of existing
   1.780 +      authorization identity forms as well as existing string
   1.781 +      representations, such as simple user names [RFC4013].
   1.782 +
   1.783 +      Where the specification does not precisely prescribe how
   1.784 +      identities in SASL relate to identities used elsewhere in the
   1.785 +      protocol, for instance, in access control policy statements, it
   1.786 +
   1.787 +
   1.788 +
   1.789 +Melnikov & Zeilenga         Standards Track                    [Page 14]
   1.790 +
   1.791 +RFC 4422                          SASL                         June 2006
   1.792 +
   1.793 +
   1.794 +      may be appropriate for the protocol to provide a facility by which
   1.795 +      the client can discover information (such as the representation of
   1.796 +      the identity used in making access control decisions) about
   1.797 +      established identities for these uses.
   1.798 +
   1.799 +   5) Detail any facility the protocol provides that allows the client
   1.800 +      and/or server to abort authentication exchange (see Section 3.5).
   1.801 +
   1.802 +      Protocols that support multiple authentications typically allow a
   1.803 +      client to abort an ongoing authentication exchange by initiating a
   1.804 +      new authentication exchange.  Protocols that do not support
   1.805 +      multiple authentications may require the client to close the
   1.806 +      connection and start over to abort an ongoing authentication
   1.807 +      exchange.
   1.808 +
   1.809 +      Protocols typically allow the server to abort ongoing
   1.810 +      authentication exchanges by returning a non-successful outcome
   1.811 +      message.
   1.812 +
   1.813 +   6) Identify precisely where newly negotiated security layers start to
   1.814 +      take effect, in both directions (see Section 3.7).
   1.815 +
   1.816 +      Typically, specifications require security layers to start taking
   1.817 +      effect on the first octet following the outcome message in data
   1.818 +      being sent by the server and on the first octet sent after receipt
   1.819 +      of the outcome message in data being sent by the client.
   1.820 +
   1.821 +   7) If the protocol supports other layered security services, such as
   1.822 +      Transport Layer Security (TLS) [RFC4346], the specification MUST
   1.823 +      prescribe the order in which security layers are applied to
   1.824 +      protocol data.
   1.825 +
   1.826 +      For instance, where a protocol supports both TLS and SASL security
   1.827 +      layers, the specification could prescribe any of the following:
   1.828 +
   1.829 +      a) SASL security layer is always applied first to data being sent
   1.830 +         and, hence, applied last to received data,
   1.831 +
   1.832 +      b) SASL security layer is always applied last to data being sent
   1.833 +         and, hence, applied first to received data,
   1.834 +
   1.835 +      c) Layers are applied in the order in which they were installed,
   1.836 +
   1.837 +      d) Layers are applied in the reverse order in which they were
   1.838 +         installed, or
   1.839 +
   1.840 +      e) Both TLS and SASL security layers cannot be installed.
   1.841 +
   1.842 +
   1.843 +
   1.844 +
   1.845 +Melnikov & Zeilenga         Standards Track                    [Page 15]
   1.846 +
   1.847 +RFC 4422                          SASL                         June 2006
   1.848 +
   1.849 +
   1.850 +   8) Indicate whether the protocol supports multiple authentications
   1.851 +      (see Section 3.8).  If so, the protocol MUST detail the effect a
   1.852 +      failed SASL authentication exchange will have upon a previously
   1.853 +      established authentication and authorization state.
   1.854 +
   1.855 +   Protocol specifications SHOULD avoid stating implementation
   1.856 +   requirements that would hinder replacement of applicable mechanisms.
   1.857 +   In general, protocol specifications SHOULD be mechanism neutral.
   1.858 +   There are a number of reasonable exceptions to this recommendation,
   1.859 +   including
   1.860 +
   1.861 +      -  detailing how credentials (which are mechanism specific) are
   1.862 +         managed in the protocol,
   1.863 +
   1.864 +      -  detailing how authentication identities (which are mechanism
   1.865 +         specific) and authorization identities (which are protocol
   1.866 +         specific) relate to each other, and
   1.867 +
   1.868 +      -  detailing which mechanisms are applicable to the protocol.
   1.869 +
   1.870 +5.  Mechanism Requirements
   1.871 +
   1.872 +   SASL mechanism specifications MUST supply the following information:
   1.873 +
   1.874 +   1) The name of the mechanism (see Section 3.1).  This name MUST be
   1.875 +      registered as discussed in Section 7.1.
   1.876 +
   1.877 +   2) A definition of the server-challenges and client-responses of the
   1.878 +      authentication exchange, as well as the following:
   1.879 +
   1.880 +      a) An indication of whether the mechanism is client-first,
   1.881 +         variable, or server-first.  If a SASL mechanism is defined as
   1.882 +         client-first and the client does not send an initial response
   1.883 +         in the authentication request, then the first server challenge
   1.884 +         MUST be empty (the EXTERNAL mechanism is an example of this
   1.885 +         case).  If a SASL mechanism is defined as variable, then the
   1.886 +         specification needs to state how the server behaves when the
   1.887 +         initial client response in the authentication request is
   1.888 +         omitted (the DIGEST-MD5 mechanism [DIGEST-MD5] is an example of
   1.889 +         this case).  If a SASL mechanism is defined as server-first,
   1.890 +         then the client MUST NOT send an initial client response in the
   1.891 +         authentication request (the CRAM-MD5 mechanism [CRAM-MD5] is an
   1.892 +         example of this case).
   1.893 +
   1.894 +      b) An indication of whether the server is expected to provide
   1.895 +         additional data when indicating a successful outcome.  If so,
   1.896 +         if the server sends the additional data as a challenge, the
   1.897 +
   1.898 +
   1.899 +
   1.900 +
   1.901 +Melnikov & Zeilenga         Standards Track                    [Page 16]
   1.902 +
   1.903 +RFC 4422                          SASL                         June 2006
   1.904 +
   1.905 +
   1.906 +         specification MUST indicate that the response to this challenge
   1.907 +         is an empty response.
   1.908 +
   1.909 +      SASL mechanisms SHOULD be designed to minimize the number of
   1.910 +      challenges and responses necessary to complete the exchange.
   1.911 +
   1.912 +   3) An indication of whether the mechanism is capable of transferring
   1.913 +      authorization identity strings (see Section 3.4.1).  While some
   1.914 +      legacy mechanisms are incapable of transmitting an authorization
   1.915 +      identity (which means that for these mechanisms, the authorization
   1.916 +      identity is always the empty string), newly defined mechanisms
   1.917 +      SHOULD be capable of transferring authorization identity strings.
   1.918 +      The mechanism SHOULD NOT be capable of transferring both no
   1.919 +      authorization identity string and an empty authorization identity.
   1.920 +
   1.921 +      Mechanisms that are capable of transferring an authorization
   1.922 +      identity string MUST be capable of transferring arbitrary non-
   1.923 +      empty sequences of Unicode characters, excluding those that
   1.924 +      contain the NUL (U+0000) character.  Mechanisms SHOULD use the
   1.925 +      UTF-8 [RFC3629] transformation format.  The specification MUST
   1.926 +      detail how any Unicode code points special to the mechanism that
   1.927 +      might appear in the authorization identity string are escaped to
   1.928 +      avoid ambiguity during decoding of the authorization identity
   1.929 +      string.  Typically, mechanisms that have special characters
   1.930 +      require these special characters to be escaped or encoded in the
   1.931 +      character string (after encoding it in a particular Unicode
   1.932 +      transformation format) using a data encoding scheme such as Base64
   1.933 +      [RFC3548].
   1.934 +
   1.935 +   4) The specification MUST detail whether the mechanism offers a
   1.936 +      security layer.  If the mechanism does, the specification MUST
   1.937 +      detail the security and other services offered in the layer as
   1.938 +      well as how these services are to be implemented.
   1.939 +
   1.940 +   5) If the underlying cryptographic technology used by a mechanism
   1.941 +      supports data integrity, then the mechanism specification MUST
   1.942 +      integrity protect the transmission of an authorization identity
   1.943 +      and the negotiation of the security layer.
   1.944 +
   1.945 +   SASL mechanisms SHOULD be protocol neutral.
   1.946 +
   1.947 +   SASL mechanisms SHOULD reuse existing credential and identity forms,
   1.948 +   as well as associated syntaxes and semantics.
   1.949 +
   1.950 +   SASL mechanisms SHOULD use the UTF-8 transformation format [RFC3629]
   1.951 +   for encoding Unicode [Unicode] code points for transfer.
   1.952 +
   1.953 +
   1.954 +
   1.955 +
   1.956 +
   1.957 +Melnikov & Zeilenga         Standards Track                    [Page 17]
   1.958 +
   1.959 +RFC 4422                          SASL                         June 2006
   1.960 +
   1.961 +
   1.962 +   In order to avoid interoperability problems due to differing
   1.963 +   normalizations, when a mechanism calls for character data (other than
   1.964 +   the authorization identity string) to be used as input to a
   1.965 +   cryptographic and/or comparison function, the specification MUST
   1.966 +   detail precisely how and where (client or server) the character data
   1.967 +   is to be prepared, including all normalizations, for input into the
   1.968 +   function to ensure proper operation.
   1.969 +
   1.970 +   For simple user names and/or passwords in authentication credentials,
   1.971 +   SASLprep [RFC4013] (a profile of the StringPrep [RFC3454] preparation
   1.972 +   algorithm), SHOULD be specified as the preparation algorithm.
   1.973 +
   1.974 +   The mechanism SHOULD NOT use the authorization identity string in
   1.975 +   generation of any long-term cryptographic keys or hashes as there is
   1.976 +   no requirement that the authorization identity string be canonical.
   1.977 +   Long-term, here, means a term longer than the duration of the
   1.978 +   authentication exchange in which they were generated.  That is, as
   1.979 +   different clients (of the same or different protocol) may provide
   1.980 +   different authorization identity strings that are semantically
   1.981 +   equivalent, use of authorization identity strings in generation of
   1.982 +   cryptographic keys and hashes will likely lead to interoperability
   1.983 +   and other problems.
   1.984 +
   1.985 +6.  Security Considerations
   1.986 +
   1.987 +   Security issues are discussed throughout this memo.
   1.988 +
   1.989 +   Many existing SASL mechanisms do not provide adequate protection
   1.990 +   against passive attacks, let alone active attacks, in the
   1.991 +   authentication exchange.  Many existing SASL mechanisms do not offer
   1.992 +   security layers.  It is hoped that future SASL mechanisms will
   1.993 +   provide strong protection against passive and active attacks in the
   1.994 +   authentication exchange, as well as security layers with strong basic
   1.995 +   data security features (e.g., data integrity and data
   1.996 +   confidentiality) services.  It is also hoped that future mechanisms
   1.997 +   will provide more advanced data security services like re-keying (see
   1.998 +   Section 6.3).
   1.999 +
  1.1000 +   Regardless, the SASL framework is susceptible to downgrade attacks.
  1.1001 +   Section 6.1.2 offers a variety of approaches for preventing or
  1.1002 +   detecting these attacks.  In some cases, it is appropriate to use
  1.1003 +   data integrity protective services external to SASL (e.g., TLS) to
  1.1004 +   protect against downgrade attacks in SASL.  Use of external
  1.1005 +   protective security services is also important when the mechanisms
  1.1006 +   available do not themselves offer adequate integrity and/or
  1.1007 +   confidentiality protection of the authentication exchange and/or
  1.1008 +   protocol data.
  1.1009 +
  1.1010 +
  1.1011 +
  1.1012 +
  1.1013 +Melnikov & Zeilenga         Standards Track                    [Page 18]
  1.1014 +
  1.1015 +RFC 4422                          SASL                         June 2006
  1.1016 +
  1.1017 +
  1.1018 +6.1.  Active Attacks
  1.1019 +
  1.1020 +6.1.1.  Hijack Attacks
  1.1021 +
  1.1022 +   When the client selects a SASL security layer with at least integrity
  1.1023 +   protection, this protection serves as a counter-measure against an
  1.1024 +   active attacker hijacking the connection and modifying protocol data
  1.1025 +   sent after establishment of the security layer.  Implementations
  1.1026 +   SHOULD close the connection when the security services in a SASL
  1.1027 +   security layer report protocol data report lack of data integrity.
  1.1028 +
  1.1029 +6.1.2.  Downgrade Attacks
  1.1030 +
  1.1031 +   It is important that any security-sensitive protocol negotiations be
  1.1032 +   performed after installation of a security layer with data integrity
  1.1033 +   protection.  Protocols should be designed such that negotiations
  1.1034 +   performed prior to this installation should be revalidated after
  1.1035 +   installation is complete.  Negotiation of the SASL mechanism is
  1.1036 +   security sensitive.
  1.1037 +
  1.1038 +   When a client negotiates the authentication mechanism with the server
  1.1039 +   and/or other security features, it is possible for an active attacker
  1.1040 +   to cause a party to use the least secure security services available.
  1.1041 +   For instance, an attacker can modify the server-advertised mechanism
  1.1042 +   list or can modify the client-advertised security feature list within
  1.1043 +   a mechanism response.  To protect against this sort of attack,
  1.1044 +   implementations SHOULD NOT advertise mechanisms and/or features that
  1.1045 +   cannot meet their minimum security requirements, SHOULD NOT enter
  1.1046 +   into or continue authentication exchanges that cannot meet their
  1.1047 +   minimum security requirements, and SHOULD verify that completed
  1.1048 +   authentication exchanges result in security services that meet their
  1.1049 +   minimum security requirements.  Note that each endpoint needs to
  1.1050 +   independently verify that its security requirements are met.
  1.1051 +
  1.1052 +   In order to detect downgrade attacks to the least (or less) secure
  1.1053 +   mechanism supported, the client can discover the SASL mechanisms that
  1.1054 +   the server makes available both before the SASL authentication
  1.1055 +   exchange and after the negotiated SASL security layer (with at least
  1.1056 +   data integrity protection) has been installed through the protocol's
  1.1057 +   mechanism discovery facility.  If the client finds that the
  1.1058 +   integrity-protected list (the list obtained after the security layer
  1.1059 +   was installed) contains a stronger mechanism than those in the
  1.1060 +   previously obtained list, the client should assume that the
  1.1061 +   previously obtained list was modified by an attacker and SHOULD close
  1.1062 +   the underlying transport connection.
  1.1063 +
  1.1064 +   The client's initiation of the SASL exchange, including the selection
  1.1065 +   of a SASL mechanism, is done in the clear and may be modified by an
  1.1066 +
  1.1067 +
  1.1068 +
  1.1069 +Melnikov & Zeilenga         Standards Track                    [Page 19]
  1.1070 +
  1.1071 +RFC 4422                          SASL                         June 2006
  1.1072 +
  1.1073 +
  1.1074 +   active attacker.  It is important for any new SASL mechanisms to be
  1.1075 +   designed such that an active attacker cannot obtain an authentication
  1.1076 +   with weaker security properties by modifying the SASL mechanism name
  1.1077 +   and/or the challenges and responses.
  1.1078 +
  1.1079 +   Multi-level negotiation of security features is prone to downgrade
  1.1080 +   attack.  Protocol designers should avoid offering higher-level
  1.1081 +   negotiation of security features in protocols (e.g., above SASL
  1.1082 +   mechanism negotiation) and mechanism designers should avoid lower-
  1.1083 +   level negotiation of security features in mechanisms (e.g., below
  1.1084 +   SASL mechanism negotiation).
  1.1085 +
  1.1086 +6.1.3.  Replay Attacks
  1.1087 +
  1.1088 +   Some mechanisms may be subject to replay attacks unless protected by
  1.1089 +   external data security services (e.g., TLS).
  1.1090 +
  1.1091 +6.1.4.  Truncation Attacks
  1.1092 +
  1.1093 +   Most existing SASL security layers do not themselves offer protection
  1.1094 +   against truncation attack.  In a truncation attack, the active
  1.1095 +   attacker causes the protocol session to be closed, causing a
  1.1096 +   truncation of the possibly integrity-protected data stream that leads
  1.1097 +   to behavior of one or both the protocol peers that inappropriately
  1.1098 +   benefits the attacker.  Truncation attacks are fairly easy to defend
  1.1099 +   against in connection-oriented application-level protocols.  A
  1.1100 +   protocol can defend against these attacks by ensuring that each
  1.1101 +   information exchange has a clear final result and that each protocol
  1.1102 +   session has a graceful closure mechanism, and that these are
  1.1103 +   integrity protected.
  1.1104 +
  1.1105 +6.1.5.  Other Active Attacks
  1.1106 +
  1.1107 +   When use of a security layer is negotiated by the authentication
  1.1108 +   protocol exchange, the receiver SHOULD handle gracefully any
  1.1109 +   protected data buffer larger than the defined/negotiated maximal
  1.1110 +   size.  In particular, it MUST NOT blindly allocate the amount of
  1.1111 +   memory specified in the buffer size field, as this might cause the
  1.1112 +   "out of memory" condition.  If the receiver detects a large block, it
  1.1113 +   SHOULD close the connection.
  1.1114 +
  1.1115 +6.2.  Passive Attacks
  1.1116 +
  1.1117 +   Many mechanisms are subject to various passive attacks, including
  1.1118 +   simple eavesdropping of unprotected credential information as well as
  1.1119 +   online and offline dictionary attacks of protected credential
  1.1120 +   information.
  1.1121 +
  1.1122 +
  1.1123 +
  1.1124 +
  1.1125 +Melnikov & Zeilenga         Standards Track                    [Page 20]
  1.1126 +
  1.1127 +RFC 4422                          SASL                         June 2006
  1.1128 +
  1.1129 +
  1.1130 +6.3.  Re-keying
  1.1131 +
  1.1132 +   The secure or administratively permitted lifetimes of SASL
  1.1133 +   mechanisms' security layers are finite.  Cryptographic keys weaken as
  1.1134 +   they are used and as time passes; the more time and/or cipher-text
  1.1135 +   that a cryptanalyst has after the first use of the a key, the easier
  1.1136 +   it is for the cryptanalyst to mount attacks on the key.
  1.1137 +
  1.1138 +   Administrative limits on a security layer's lifetime may take the
  1.1139 +   form of time limits expressed in X.509 certificates, in Kerberos V
  1.1140 +   tickets, or in directories, and are often desired.  In practice, one
  1.1141 +   likely effect of administrative lifetime limits is that applications
  1.1142 +   may find that security layers stop working in the middle of
  1.1143 +   application protocol operation, such as, perhaps, during large data
  1.1144 +   transfers.  As the result of this, the connection will be closed (see
  1.1145 +   Section 3.7), which will result in an unpleasant user experience.
  1.1146 +
  1.1147 +   Re-keying (key renegotiation process) is a way of addressing the
  1.1148 +   weakening of cryptographic keys.  The SASL framework does not itself
  1.1149 +   provide for re-keying; SASL mechanisms may.  Designers of future SASL
  1.1150 +   mechanisms should consider providing re-keying services.
  1.1151 +
  1.1152 +   Implementations that wish to re-key SASL security layers where the
  1.1153 +   mechanism does not provide for re-keying SHOULD reauthenticate the
  1.1154 +   same IDs and replace the expired or soon-to-expire security layers.
  1.1155 +   This approach requires support for reauthentication in the
  1.1156 +   application protocols (see Section 3.8).
  1.1157 +
  1.1158 +6.4.  Other Considerations
  1.1159 +
  1.1160 +   Protocol designers and implementors should understand the security
  1.1161 +   considerations of mechanisms so they may select mechanisms that are
  1.1162 +   applicable to their needs.
  1.1163 +
  1.1164 +   Distributed server implementations need to be careful in how they
  1.1165 +   trust other parties.  In particular, authentication secrets should
  1.1166 +   only be disclosed to other parties that are trusted to manage and use
  1.1167 +   those secrets in a manner acceptable to the disclosing party.
  1.1168 +   Applications using SASL assume that SASL security layers providing
  1.1169 +   data confidentiality are secure even when an attacker chooses the
  1.1170 +   text to be protected by the security layer.  Similarly, applications
  1.1171 +   assume that the SASL security layer is secure even if the attacker
  1.1172 +   can manipulate the cipher-text output of the security layer.  New
  1.1173 +   SASL mechanisms are expected to meet these assumptions.
  1.1174 +
  1.1175 +
  1.1176 +
  1.1177 +
  1.1178 +
  1.1179 +
  1.1180 +
  1.1181 +Melnikov & Zeilenga         Standards Track                    [Page 21]
  1.1182 +
  1.1183 +RFC 4422                          SASL                         June 2006
  1.1184 +
  1.1185 +
  1.1186 +   Unicode security considerations [UTR36] apply to authorization
  1.1187 +   identity strings, as well as UTF-8 [RFC3629] security considerations
  1.1188 +   where UTF-8 is used.  SASLprep [RFC4013] and StringPrep [RFC3454]
  1.1189 +   security considerations also apply where used.
  1.1190 +
  1.1191 +7.  IANA Considerations
  1.1192 +
  1.1193 +7.1.  SASL Mechanism Registry
  1.1194 +
  1.1195 +   The SASL mechanism registry is maintained by IANA.  The registry is
  1.1196 +   currently available at <http://www.iana.org/assignments/sasl-
  1.1197 +   mechanisms>.
  1.1198 +
  1.1199 +   The purpose of this registry is not only to ensure uniqueness of
  1.1200 +   values used to name SASL mechanisms, but also to provide a definitive
  1.1201 +   reference to technical specifications detailing each SASL mechanism
  1.1202 +   available for use on the Internet.
  1.1203 +
  1.1204 +   There is no naming convention for SASL mechanisms; any name that
  1.1205 +   conforms to the syntax of a SASL mechanism name can be registered.
  1.1206 +
  1.1207 +   The procedure detailed in Section 7.1.1 is to be used for
  1.1208 +   registration of a value naming a specific individual mechanism.
  1.1209 +
  1.1210 +   The procedure detailed in Section 7.1.2 is to be used for
  1.1211 +   registration of a value naming a family of related mechanisms.
  1.1212 +
  1.1213 +   Comments may be included in the registry as discussed in Section
  1.1214 +   7.1.3 and may be changed as discussed in Section 7.1.4.
  1.1215 +
  1.1216 +   The SASL mechanism registry has been updated to reflect that this
  1.1217 +   document provides the definitive technical specification for SASL and
  1.1218 +   that this section provides the registration procedures for this
  1.1219 +   registry.
  1.1220 +
  1.1221 +
  1.1222 +
  1.1223 +
  1.1224 +
  1.1225 +
  1.1226 +
  1.1227 +
  1.1228 +
  1.1229 +
  1.1230 +
  1.1231 +
  1.1232 +
  1.1233 +
  1.1234 +
  1.1235 +
  1.1236 +
  1.1237 +Melnikov & Zeilenga         Standards Track                    [Page 22]
  1.1238 +
  1.1239 +RFC 4422                          SASL                         June 2006
  1.1240 +
  1.1241 +
  1.1242 +7.1.1.  Mechanism Name Registration Procedure
  1.1243 +
  1.1244 +   IANA will register new SASL mechanism names on a First Come First
  1.1245 +   Served basis, as defined in BCP 26 [RFC2434].  IANA has the right to
  1.1246 +   reject obviously bogus registration requests, but will perform no
  1.1247 +   review of claims made in the registration form.
  1.1248 +
  1.1249 +   Registration of a SASL mechanism is requested by filling in the
  1.1250 +   following template:
  1.1251 +
  1.1252 +      Subject: Registration of SASL mechanism X
  1.1253 +
  1.1254 +      SASL mechanism name (or prefix for the family):
  1.1255 +
  1.1256 +      Security considerations:
  1.1257 +
  1.1258 +      Published specification (recommended):
  1.1259 +
  1.1260 +      Person & email address to contact for further information:
  1.1261 +
  1.1262 +      Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
  1.1263 +
  1.1264 +      Owner/Change controller:
  1.1265 +
  1.1266 +      Note: (Any other information that the author deems relevant may be
  1.1267 +      added here.)
  1.1268 +
  1.1269 +   and sending it via electronic mail to IANA at <iana@iana.org>.
  1.1270 +
  1.1271 +   While this registration procedure does not require expert review,
  1.1272 +   authors of SASL mechanisms are encouraged to seek community review
  1.1273 +   and comment whenever that is feasible.  Authors may seek community
  1.1274 +   review by posting a specification of their proposed mechanism as an
  1.1275 +   Internet-Draft.  SASL mechanisms intended for widespread use should
  1.1276 +   be standardized through the normal IETF process, when appropriate.
  1.1277 +
  1.1278 +
  1.1279 +
  1.1280 +
  1.1281 +
  1.1282 +
  1.1283 +
  1.1284 +
  1.1285 +
  1.1286 +
  1.1287 +
  1.1288 +
  1.1289 +
  1.1290 +
  1.1291 +
  1.1292 +
  1.1293 +Melnikov & Zeilenga         Standards Track                    [Page 23]
  1.1294 +
  1.1295 +RFC 4422                          SASL                         June 2006
  1.1296 +
  1.1297 +
  1.1298 +7.1.2.  Family Name Registration Procedure
  1.1299 +
  1.1300 +   As noted above, there is no general naming convention for SASL
  1.1301 +   mechanisms.  However, specifications may reserve a portion of the
  1.1302 +   SASL mechanism namespace for a set of related SASL mechanisms, a
  1.1303 +   "family" of SASL mechanisms.  Each family of SASL mechanisms is
  1.1304 +   identified by a unique prefix, such as X-.  Registration of new SASL
  1.1305 +   mechanism family names requires expert review as defined in BCP 26
  1.1306 +   [RFC2434].
  1.1307 +
  1.1308 +   Registration of a SASL family name is requested by filling in the
  1.1309 +   following template:
  1.1310 +
  1.1311 +      Subject: Registration of SASL mechanism family X
  1.1312 +
  1.1313 +      SASL family name (or prefix for the family):
  1.1314 +
  1.1315 +      Security considerations:
  1.1316 +
  1.1317 +      Published specification (recommended):
  1.1318 +
  1.1319 +      Person & email address to contact for further information:
  1.1320 +
  1.1321 +      Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
  1.1322 +
  1.1323 +      Owner/Change controller:
  1.1324 +
  1.1325 +      Note: (Any other information that the author deems relevant may be
  1.1326 +      added here.)
  1.1327 +
  1.1328 +   and sending it via electronic mail to the IETF SASL mailing list at
  1.1329 +   <ietf-sasl@imc.org> and carbon copying IANA at <iana@iana.org>.
  1.1330 +   After allowing two weeks for community input on the IETF SASL mailing
  1.1331 +   list, the expert will determine the appropriateness of the
  1.1332 +   registration request and either approve or disapprove the request
  1.1333 +   with notice to the requestor, the mailing list, and IANA.
  1.1334 +
  1.1335 +   The review should focus on the appropriateness of the requested
  1.1336 +   family name for the proposed use and the appropriateness of the
  1.1337 +   proposed naming and registration plan for existing and future
  1.1338 +   mechanism names in the family.  The scope of this request review may
  1.1339 +   entail consideration of relevant aspects of any provided technical
  1.1340 +   specification, such as their IANA Considerations section.  However,
  1.1341 +   this review is narrowly focused on the appropriateness of the
  1.1342 +   requested registration and not on the overall soundness of any
  1.1343 +   provided technical specification.
  1.1344 +
  1.1345 +
  1.1346 +
  1.1347 +
  1.1348 +
  1.1349 +Melnikov & Zeilenga         Standards Track                    [Page 24]
  1.1350 +
  1.1351 +RFC 4422                          SASL                         June 2006
  1.1352 +
  1.1353 +
  1.1354 +   Authors are encouraged to pursue community review by posting the
  1.1355 +   technical specification as an Internet-Draft and soliciting comment
  1.1356 +   by posting to appropriate IETF mailing lists.
  1.1357 +
  1.1358 +7.1.3.  Comments on SASL Mechanism Registrations
  1.1359 +
  1.1360 +   Comments on a registered SASL mechanism/family should first be sent
  1.1361 +   to the "owner" of the mechanism/family and/or to the <ietf-
  1.1362 +   sasl@imc.org> mailing list.
  1.1363 +
  1.1364 +   Submitters of comments may, after a reasonable attempt to contact the
  1.1365 +   owner, request IANA to attach their comment to the SASL mechanism
  1.1366 +   registration itself by sending mail to <iana@iana.org>.  At IANA's
  1.1367 +   sole discretion, IANA may attach the comment to the SASL mechanism's
  1.1368 +   registration.
  1.1369 +
  1.1370 +7.1.4.  Change Control
  1.1371 +
  1.1372 +   Once a SASL mechanism registration has been published by IANA, the
  1.1373 +   author may request a change to its definition.  The change request
  1.1374 +   follows the same procedure as the registration request.
  1.1375 +
  1.1376 +   The owner of a SASL mechanism may pass responsibility for the SASL
  1.1377 +   mechanism to another person or agency by informing IANA; this can be
  1.1378 +   done without discussion or review.
  1.1379 +
  1.1380 +   The IESG may reassign responsibility for a SASL mechanism.  The most
  1.1381 +   common case of this will be to enable changes to be made to
  1.1382 +   mechanisms where the author of the registration has died, has moved
  1.1383 +   out of contact, or is otherwise unable to make changes that are
  1.1384 +   important to the community.
  1.1385 +
  1.1386 +   SASL mechanism registrations may not be deleted; mechanisms that are
  1.1387 +   no longer believed appropriate for use can be declared OBSOLETE by a
  1.1388 +   change to their "intended usage" field; such SASL mechanisms will be
  1.1389 +   clearly marked in the lists published by IANA.
  1.1390 +
  1.1391 +   The IESG is considered to be the owner of all SASL mechanisms that
  1.1392 +   are on the IETF standards track.
  1.1393 +
  1.1394 +
  1.1395 +
  1.1396 +
  1.1397 +
  1.1398 +
  1.1399 +
  1.1400 +
  1.1401 +
  1.1402 +
  1.1403 +
  1.1404 +
  1.1405 +Melnikov & Zeilenga         Standards Track                    [Page 25]
  1.1406 +
  1.1407 +RFC 4422                          SASL                         June 2006
  1.1408 +
  1.1409 +
  1.1410 +7.2.  Registration Changes
  1.1411 +
  1.1412 +   The IANA has updated the SASL mechanisms registry as follows:
  1.1413 +
  1.1414 +   1) Changed the "Intended usage" of the KERBEROS_V4 and SKEY mechanism
  1.1415 +      registrations to OBSOLETE.
  1.1416 +
  1.1417 +   2) Changed the "Published specification" of the EXTERNAL mechanism to
  1.1418 +      this document as indicated below:
  1.1419 +
  1.1420 +      Subject: Updated Registration of SASL mechanism EXTERNAL
  1.1421 +      Family of SASL mechanisms: NO
  1.1422 +      SASL mechanism name: EXTERNAL
  1.1423 +      Security considerations: See A.3 of RFC 4422
  1.1424 +      Published specification (optional, recommended): RFC 4422
  1.1425 +      Person & email address to contact for further information:
  1.1426 +          Alexey Melnikov <Alexey.Melnikov@isode.com>
  1.1427 +      Intended usage: COMMON
  1.1428 +      Owner/Change controller: IESG <iesg@ietf.org>
  1.1429 +      Note: Updates existing entry for EXTERNAL
  1.1430 +
  1.1431 +8.  References
  1.1432 +
  1.1433 +8.1.  Normative References
  1.1434 +
  1.1435 +   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
  1.1436 +                 Requirement Levels", BCP 14, RFC 2119, March 1997.
  1.1437 +
  1.1438 +   [RFC2244]     Newman, C. and J. G. Myers, "ACAP -- Application
  1.1439 +                 Configuration Access Protocol", RFC 2244, November
  1.1440 +                 1997.
  1.1441 +
  1.1442 +   [RFC2434]     Narten, T. and H. Alvestrand, "Guidelines for Writing
  1.1443 +                 an IANA Considerations Section in RFCs", BCP 26, RFC
  1.1444 +                 2434, October 1998.
  1.1445 +
  1.1446 +   [RFC2743]     Linn, J., "Generic Security Service Application Program
  1.1447 +                 Interface Version 2, Update 1", RFC 2743, January 2000.
  1.1448 +
  1.1449 +   [RFC3454]     Hoffman, P. and M. Blanchet, "Preparation of
  1.1450 +                 Internationalized Strings ("stringprep")", RFC 3454,
  1.1451 +                 December 2002.
  1.1452 +
  1.1453 +   [RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
  1.1454 +                 10646", STD 63, RFC 3629, November 2003.
  1.1455 +
  1.1456 +   [RFC4013]     Zeilenga, K., "SASLprep: Stringprep Profile for User
  1.1457 +                 Names and Passwords", RFC 4013, February 2005.
  1.1458 +
  1.1459 +
  1.1460 +
  1.1461 +Melnikov & Zeilenga         Standards Track                    [Page 26]
  1.1462 +
  1.1463 +RFC 4422                          SASL                         June 2006
  1.1464 +
  1.1465 +
  1.1466 +   [RFC4234]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
  1.1467 +                 Specifications: ABNF", RFC 4234, October 2005.
  1.1468 +
  1.1469 +   [ASCII]       Coded Character Set--7-bit American Standard Code for
  1.1470 +                 Information Interchange, ANSI X3.4-1986.
  1.1471 +
  1.1472 +   [Unicode]     The Unicode Consortium, "The Unicode Standard, Version
  1.1473 +                 3.2.0" is defined by "The Unicode Standard, Version
  1.1474 +                 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
  1.1475 +                 61633-5), as amended by the "Unicode Standard Annex
  1.1476 +                 #27: Unicode 3.1"
  1.1477 +                 (http://www.unicode.org/reports/tr27/) and by the
  1.1478 +                 "Unicode Standard Annex #28: Unicode 3.2"
  1.1479 +                 (http://www.unicode.org/reports/tr28/).
  1.1480 +
  1.1481 +   [CharModel]   Whistler, K. and M. Davis, "Unicode Technical Report
  1.1482 +                 #17, Character Encoding Model", UTR17,
  1.1483 +                 <http://www.unicode.org/unicode/reports/tr17/>, August
  1.1484 +                 2000.
  1.1485 +
  1.1486 +   [Glossary]    The Unicode Consortium, "Unicode Glossary",
  1.1487 +                 <http://www.unicode.org/glossary/>.
  1.1488 +
  1.1489 +8.2.  Informative References
  1.1490 +
  1.1491 +   [RFC3206]     Gellens, R., "The SYS and AUTH POP Response Codes", RFC
  1.1492 +                 3206, February 2002.
  1.1493 +
  1.1494 +   [RFC3548]     Josefsson, S., "The Base16, Base32, and Base64 Data
  1.1495 +                 Encodings", RFC 3548, July 2003.
  1.1496 +
  1.1497 +   [RFC4301]     Kent, S. and K. Seo, "Security Architecture for the
  1.1498 +                 Internet Protocol", RFC 4301, December 2005.
  1.1499 +
  1.1500 +   [RFC4346]     Dierks, T. and E. Rescorla, "The Transport Layer
  1.1501 +                 Security (TLS) Protocol Version 1.1", RFC 4346, April
  1.1502 +                 2006.
  1.1503 +
  1.1504 +   [SASL-GSSAPI] Melnikov, A. (Editor), "The Kerberos V5 ("GSSAPI") SASL
  1.1505 +                 Mechanism", Work in Progress, May 2006.
  1.1506 +
  1.1507 +   [UTR36]       Davis, M., "(Draft) Unicode Technical Report #36,
  1.1508 +                 Character Encoding Model", UTR17,
  1.1509 +                 <http://www.unicode.org/unicode/reports/tr36/>,
  1.1510 +                 February 2005.
  1.1511 +
  1.1512 +   [CRAM-MD5]    Nerenberg, L., "The CRAM-MD5 SASL Mechanism", Work in
  1.1513 +                 Progress.
  1.1514 +
  1.1515 +
  1.1516 +
  1.1517 +Melnikov & Zeilenga         Standards Track                    [Page 27]
  1.1518 +
  1.1519 +RFC 4422                          SASL                         June 2006
  1.1520 +
  1.1521 +
  1.1522 +   [DIGEST-MD5]  Leach, P., C. Newman, and A. Melnikov, "Using Digest
  1.1523 +                 Authentication as a SASL Mechanism", Work in Progress,
  1.1524 +                 March 2006.
  1.1525 +
  1.1526 +9.  Acknowledgements
  1.1527 +
  1.1528 +   This document is a revision of RFC 2222 written by John Myers.
  1.1529 +
  1.1530 +   This revision is a product of the IETF Simple Authentication and
  1.1531 +   Security Layer (SASL) Working Group.
  1.1532 +
  1.1533 +   The following individuals contributed significantly to this revision:
  1.1534 +   Abhijit Menon-Sen, Hallvard Furuseth, Jeffrey Hutzelman, John Myers,
  1.1535 +   Luke Howard, Magnus Nystrom, Nicolas Williams, Peter Saint-Andre, RL
  1.1536 +   'Bob' Morgan, Rob Siemborski, Sam Hartman, Simon Josefsson, Tim
  1.1537 +   Alsop, and Tony Hansen.
  1.1538 +
  1.1539 +
  1.1540 +
  1.1541 +
  1.1542 +
  1.1543 +
  1.1544 +
  1.1545 +
  1.1546 +
  1.1547 +
  1.1548 +
  1.1549 +
  1.1550 +
  1.1551 +
  1.1552 +
  1.1553 +
  1.1554 +
  1.1555 +
  1.1556 +
  1.1557 +
  1.1558 +
  1.1559 +
  1.1560 +
  1.1561 +
  1.1562 +
  1.1563 +
  1.1564 +
  1.1565 +
  1.1566 +
  1.1567 +
  1.1568 +
  1.1569 +
  1.1570 +
  1.1571 +
  1.1572 +
  1.1573 +Melnikov & Zeilenga         Standards Track                    [Page 28]
  1.1574 +
  1.1575 +RFC 4422                          SASL                         June 2006
  1.1576 +
  1.1577 +
  1.1578 +Appendix A.  The SASL EXTERNAL Mechanism
  1.1579 +
  1.1580 +   This appendix is normative.
  1.1581 +
  1.1582 +   The EXTERNAL mechanism allows a client to request the server to use
  1.1583 +   credentials established by means external to the mechanism to
  1.1584 +   authenticate the client.  The external means may be, for instance, IP
  1.1585 +   Security [RFC4301] or TLS [RFC4346] services.  In absence of some a
  1.1586 +   priori agreement between the client and the server, the client cannot
  1.1587 +   make any assumption as to what external means the server has used to
  1.1588 +   obtain the client's credentials, nor make an assumption as to the
  1.1589 +   form of credentials.  For example, the client cannot assume that the
  1.1590 +   server will use the credentials the client has established via TLS.
  1.1591 +
  1.1592 +A.1.  EXTERNAL Technical Specification
  1.1593 +
  1.1594 +   The name of this mechanism is "EXTERNAL".
  1.1595 +
  1.1596 +   The mechanism does not provide a security layer.
  1.1597 +
  1.1598 +   The mechanism is capable of transferring an authorization identity
  1.1599 +   string.  If empty, the client is requesting to act as the identity
  1.1600 +   the server has associated with the client's credentials.  If non-
  1.1601 +   empty, the client is requesting to act as the identity represented by
  1.1602 +   the string.
  1.1603 +
  1.1604 +   The client is expected to send data first in the authentication
  1.1605 +   exchange.  Where the client does not provide an initial response data
  1.1606 +   in its request to initiate the authentication exchange, the server is
  1.1607 +   to respond to the request with an empty initial challenge and then
  1.1608 +   the client is to provide its initial response.
  1.1609 +
  1.1610 +   The client sends the initial response containing the UTF-8 [RFC3629]
  1.1611 +   encoding of the requested authorization identity string.  This
  1.1612 +   response is non-empty when the client is requesting to act as the
  1.1613 +   identity represented by the (non-empty) string.  This response is
  1.1614 +   empty when the client is requesting to act as the identity the server
  1.1615 +   associated with its authentication credentials.
  1.1616 +
  1.1617 +   The syntax of the initial response is specified as a value of the
  1.1618 +   <extern-initial-resp> production detailed below using the Augmented
  1.1619 +   Backus-Naur Form (ABNF) [RFC4234] notation.
  1.1620 +
  1.1621 +      external-initial-resp = authz-id-string
  1.1622 +      authz-id-string       = *( UTF8-char-no-nul )
  1.1623 +      UTF8-char-no-nul      = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4
  1.1624 +      UTF8-1-no-nul         = %x01-7F
  1.1625 +
  1.1626 +
  1.1627 +
  1.1628 +
  1.1629 +Melnikov & Zeilenga         Standards Track                    [Page 29]
  1.1630 +
  1.1631 +RFC 4422                          SASL                         June 2006
  1.1632 +
  1.1633 +
  1.1634 +   where the <UTF8-2>, <UTF8-3>, and <UTF8-4> productions are as defined
  1.1635 +   in [RFC3629].
  1.1636 +
  1.1637 +   There are no additional challenges and responses.
  1.1638 +
  1.1639 +   Hence, the server is to return the outcome of the authentication
  1.1640 +   exchange.
  1.1641 +
  1.1642 +   The exchange fails if
  1.1643 +
  1.1644 +   -  the client has not established its credentials via external means,
  1.1645 +
  1.1646 +   -  the client's credentials are inadequate,
  1.1647 +
  1.1648 +   -  the client provided an empty authorization identity string and the
  1.1649 +      server is unwilling or unable to associate an authorization
  1.1650 +      identity with the client's credentials,
  1.1651 +
  1.1652 +   -  the client provided a non-empty authorization identity string that
  1.1653 +      is invalid per the syntax requirements of the applicable
  1.1654 +      application protocol specification,
  1.1655 +
  1.1656 +   -  the client provided a non-empty authorization identity string
  1.1657 +      representing an identity that the client is not allowed to act as,
  1.1658 +      or
  1.1659 +
  1.1660 +   -  the server is unwilling or unable to provide service to the client
  1.1661 +      for any other reason.
  1.1662 +
  1.1663 +   Otherwise the exchange is successful.  When indicating a successful
  1.1664 +   outcome, additional data is not provided.
  1.1665 +
  1.1666 +A.2.  SASL EXTERNAL Examples
  1.1667 +
  1.1668 +   This section provides examples of EXTERNAL authentication exchanges.
  1.1669 +   The examples are intended to help the readers understand the above
  1.1670 +   text.  The examples are not definitive.  The Application
  1.1671 +   Configuration Access Protocol (ACAP) [RFC2244] is used in the
  1.1672 +   examples.
  1.1673 +
  1.1674 +   The first example shows use of EXTERNAL with an empty authorization
  1.1675 +   identity.  In this example, the initial response is not sent in the
  1.1676 +   client's request to initiate the authentication exchange.
  1.1677 +
  1.1678 +      S: * ACAP (SASL "DIGEST-MD5")
  1.1679 +      C: a001 STARTTLS
  1.1680 +      S: a001 OK "Begin TLS negotiation now"
  1.1681 +      <TLS negotiation, further commands are under TLS layer>
  1.1682 +
  1.1683 +
  1.1684 +
  1.1685 +Melnikov & Zeilenga         Standards Track                    [Page 30]
  1.1686 +
  1.1687 +RFC 4422                          SASL                         June 2006
  1.1688 +
  1.1689 +
  1.1690 +      S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL")
  1.1691 +      C: a002 AUTHENTICATE "EXTERNAL"
  1.1692 +      S: + ""
  1.1693 +      C: + ""
  1.1694 +      S: a002 OK "Authenticated"
  1.1695 +
  1.1696 +   The second example shows use of EXTERNAL with an authorization
  1.1697 +   identity of "fred@example.com".  In this example, the initial
  1.1698 +   response is sent with the client's request to initiate the
  1.1699 +   authentication exchange.  This saves a round-trip.
  1.1700 +
  1.1701 +      S: * ACAP (SASL "DIGEST-MD5")
  1.1702 +      C: a001 STARTTLS
  1.1703 +      S: a001 OK "Begin TLS negotiation now"
  1.1704 +      <TLS negotiation, further commands are under TLS layer>
  1.1705 +      S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL")
  1.1706 +      C: a002 AUTHENTICATE "EXTERNAL" {16+}
  1.1707 +      C: fred@example.com
  1.1708 +      S: a002 NO "Cannot assume requested authorization identity"
  1.1709 +
  1.1710 +A.3.  Security Considerations
  1.1711 +
  1.1712 +   The EXTERNAL mechanism provides no security protection; it is
  1.1713 +   vulnerable to spoofing by either client or server, active attack, and
  1.1714 +   eavesdropping.  It should only be used when adequate security
  1.1715 +   services have been established.
  1.1716 +
  1.1717 +Appendix B.  Changes since RFC 2222
  1.1718 +
  1.1719 +   This appendix is non-normative.
  1.1720 +
  1.1721 +   The material in RFC 2222 was significantly rewritten in the
  1.1722 +   production of this document.
  1.1723 +
  1.1724 +   RFC 2222, by not stating that the authorization identity string was a
  1.1725 +   string of Unicode characters, let alone character data, implied that
  1.1726 +   the authorization identity string was a string of octets.
  1.1727 +
  1.1728 +   -  The authorization identity string is now defined as a string of
  1.1729 +      Unicode characters.  The NUL (U+0000) character is prohibited.
  1.1730 +      While protocol specifications are responsible for defining the
  1.1731 +      authorization identity form, as well as the Unicode string syntax
  1.1732 +      and related semantics, mechanism specifications are responsible
  1.1733 +      for defining how the Unicode string is carried in the
  1.1734 +      authentication exchange.
  1.1735 +
  1.1736 +   -  Deleted "If so, when the client does not send data first, the
  1.1737 +      initial challenge MUST be specified as being an empty challenge."
  1.1738 +
  1.1739 +
  1.1740 +
  1.1741 +Melnikov & Zeilenga         Standards Track                    [Page 31]
  1.1742 +
  1.1743 +RFC 4422                          SASL                         June 2006
  1.1744 +
  1.1745 +
  1.1746 +   The following technical change was made to the EXTERNAL mechanism:
  1.1747 +
  1.1748 +      - The authorization identity string is to be UTF-8 encoded.
  1.1749 +
  1.1750 +      Note that protocol and mechanism specification requirements have
  1.1751 +      been significantly tightened.  Existing protocol and mechanism
  1.1752 +      specifications will need to be updated to meet these requirements.
  1.1753 +
  1.1754 +Editors' Addresses
  1.1755 +
  1.1756 +   Alexey Melnikov
  1.1757 +   Isode Limited
  1.1758 +   5 Castle Business Village
  1.1759 +   36 Station Road
  1.1760 +   Hampton, Middlesex,
  1.1761 +   TW12 2BX, United Kingdom
  1.1762 +
  1.1763 +   EMail: Alexey.Melnikov@isode.com
  1.1764 +   URI:   http://www.melnikov.ca/
  1.1765 +
  1.1766 +
  1.1767 +   Kurt D. Zeilenga
  1.1768 +   OpenLDAP Foundation
  1.1769 +
  1.1770 +   EMail: Kurt@OpenLDAP.org
  1.1771 +
  1.1772 +
  1.1773 +
  1.1774 +
  1.1775 +
  1.1776 +
  1.1777 +
  1.1778 +
  1.1779 +
  1.1780 +
  1.1781 +
  1.1782 +
  1.1783 +
  1.1784 +
  1.1785 +
  1.1786 +
  1.1787 +
  1.1788 +
  1.1789 +
  1.1790 +
  1.1791 +
  1.1792 +
  1.1793 +
  1.1794 +
  1.1795 +
  1.1796 +
  1.1797 +Melnikov & Zeilenga         Standards Track                    [Page 32]
  1.1798 +
  1.1799 +RFC 4422                          SASL                         June 2006
  1.1800 +
  1.1801 +
  1.1802 +Full Copyright Statement
  1.1803 +
  1.1804 +   Copyright (C) The Internet Society (2006).
  1.1805 +
  1.1806 +   This document is subject to the rights, licenses and restrictions
  1.1807 +   contained in BCP 78, and except as set forth therein, the authors
  1.1808 +   retain all their rights.
  1.1809 +
  1.1810 +   This document and the information contained herein are provided on an
  1.1811 +   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
  1.1812 +   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
  1.1813 +   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
  1.1814 +   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
  1.1815 +   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
  1.1816 +   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  1.1817 +
  1.1818 +Intellectual Property
  1.1819 +
  1.1820 +   The IETF takes no position regarding the validity or scope of any
  1.1821 +   Intellectual Property Rights or other rights that might be claimed to
  1.1822 +   pertain to the implementation or use of the technology described in
  1.1823 +   this document or the extent to which any license under such rights
  1.1824 +   might or might not be available; nor does it represent that it has
  1.1825 +   made any independent effort to identify any such rights.  Information
  1.1826 +   on the procedures with respect to rights in RFC documents can be
  1.1827 +   found in BCP 78 and BCP 79.
  1.1828 +
  1.1829 +   Copies of IPR disclosures made to the IETF Secretariat and any
  1.1830 +   assurances of licenses to be made available, or the result of an
  1.1831 +   attempt made to obtain a general license or permission for the use of
  1.1832 +   such proprietary rights by implementers or users of this
  1.1833 +   specification can be obtained from the IETF on-line IPR repository at
  1.1834 +   http://www.ietf.org/ipr.
  1.1835 +
  1.1836 +   The IETF invites any interested party to bring to its attention any
  1.1837 +   copyrights, patents or patent applications, or other proprietary
  1.1838 +   rights that may cover technology that may be required to implement
  1.1839 +   this standard.  Please address the information to the IETF at
  1.1840 +   ietf-ipr@ietf.org.
  1.1841 +
  1.1842 +Acknowledgement
  1.1843 +
  1.1844 +   Funding for the RFC Editor function is provided by the IETF
  1.1845 +   Administrative Support Activity (IASA).
  1.1846 +
  1.1847 +
  1.1848 +
  1.1849 +
  1.1850 +
  1.1851 +
  1.1852 +
  1.1853 +Melnikov & Zeilenga         Standards Track                    [Page 33]
  1.1854 +