Request for Comments: 4422 Isode Limited
Obsoletes: 2222 K. Zeilenga, Ed.
Category: Standards Track OpenLDAP Foundation
June 2006
Simple Authentication and Security Layer (SASL)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Simple Authentication and Security Layer (SASL) is a framework
for providing authentication and data security services in
connection-oriented protocols via replaceable mechanisms. It
provides a structured interface between protocols and mechanisms.
The resulting framework allows new protocols to reuse existing
mechanisms and allows old protocols to make use of new mechanisms.
The framework also provides a protocol for securing subsequent
protocol exchanges within a data security layer.
This document describes how a SASL mechanism is structured, describes
how protocols include support for SASL, and defines the protocol for
carrying a data security layer over a connection. In addition, this
document defines one SASL mechanism, the EXTERNAL mechanism.
This document obsoletes RFC 2222.
Table of Contents
1. Introduction ....................................................3
1.1. Document Audiences .........................................4
1.2. Relationship to Other Documents ............................4
1.3. Conventions ................................................5
2. Identity Concepts ...............................................5
3. The Authentication Exchange .....................................6
3.1. Mechanism Naming ...........................................8
3.2. Mechanism Negotiation ......................................9
3.3. Request Authentication Exchange ............................9
3.4. Challenges and Responses ...................................9
3.4.1. Authorization Identity String ......................10
3.5. Aborting Authentication Exchanges .........................10
3.6. Authentication Outcome ....................................11
3.7. Security Layers ...........................................12
3.8. Multiple Authentications ..................................12
4. Protocol Requirements ..........................................13
5. Mechanism Requirements .........................................16
6. Security Considerations ........................................18
6.1. Active Attacks ............................................19
6.1.1. Hijack Attacks .....................................19
6.1.2. Downgrade Attacks ..................................19
6.1.3. Replay Attacks .....................................20
6.1.4. Truncation Attacks .................................20
6.1.5. Other Active Attacks ...............................20
6.2. Passive Attacks ...........................................20
6.3. Re-keying .................................................21
6.4. Other Considerations ......................................21
7. IANA Considerations ............................................22
7.1. SASL Mechanism Registry ...................................22
7.2. Registration Changes ......................................26
8. References .....................................................26
8.1. Normative References ......................................26
8.2. Informative References ....................................27
9. Acknowledgements ...............................................28
Appendix A. The SASL EXTERNAL Mechanism ..........................29
A.1. EXTERNAL Technical Specification ..........................29
A.2. SASL EXTERNAL Examples ....................................30
A.3. Security Considerations ...................................31
Appendix B. Changes since RFC 2222 ...............................31
1. Introduction
The Simple Authentication and Security Layer (SASL) is a framework
for providing authentication and data security services in
connection-oriented protocols via replaceable mechanisms. SASL
provides a structured interface between protocols and mechanisms.
SASL also provides a protocol for securing subsequent protocol
exchanges within a data security layer. The data security layer can
provide data integrity, data confidentiality, and other services.
SASL’s design is intended to allow new protocols to reuse existing
mechanisms without requiring redesign of the mechanisms and allows
existing protocols to make use of new mechanisms without redesign of
protocols.
SASL is conceptually a framework that provides an abstraction layer
between protocols and mechanisms as illustrated in the following
diagram.
SMTP LDAP XMPP Other protocols ...
\ | | /
\ | | /
SASL abstraction layer
/ | | \
/ | | \
EXTERNAL GSSAPI PLAIN Other mechanisms ...
It is through the interfaces of this abstraction layer that the
framework allows any protocol to utilize any mechanism. While this
layer does generally hide the particulars of protocols from
mechanisms and the particulars of mechanisms from protocols, this
layer does not generally hide the particulars of mechanisms from
protocol implementations. For example, different mechanisms require
different information to operate, some of them use password-based
authentication, some of then require realm information, others make
use of Kerberos tickets, certificates, etc. Also, in order to
perform authorization, server implementations generally have to
implement identity mapping between authentication identities, whose
form is mechanism specific, and authorization identities, whose form
is application protocol specific. Section 2 discusses identity
concepts.
It is possible to design and implement this framework in ways that do
abstract away particulars of similar mechanisms. Such a framework
implementation, as well as mechanisms implementations, could be
designed not only to be shared by multiple implementations of a
particular protocol but to be shared by implementations of multiple
protocols.
The framework incorporates interfaces with both protocols and
mechanisms in which authentication exchanges are carried out.
Section 3 discusses SASL authentication exchanges.
To use SASL, each protocol (amongst other items) provides a method
for identifying which mechanism is to be used, a method for exchange
of mechanism-specific server-challenges and client-responses, and a
method for communicating the outcome of the authentication exchange.
Section 4 discusses SASL protocol requirements.
Each SASL mechanism defines (amongst other items) a series of
server-challenges and client-responses that provide authentication
services and negotiate data security services. Section 5 discusses
SASL mechanism requirements.
Section 6 discusses security considerations. Section 7 discusses
IANA considerations. Appendix A defines the SASL EXTERNAL mechanism.
1.1. Document Audiences
This document is written to serve several different audiences:
- protocol designers using this specification to support
authentication in their protocol,
- mechanism designers that define new SASL mechanisms, and
- implementors of clients or servers for those protocols that
support SASL.
While the document organization is intended to allow readers to focus
on details relevant to their engineering, readers are encouraged to
read and understand all aspects of this document.
1.2. Relationship to Other Documents
This document obsoletes RFC 2222. It replaces all portions of RFC
2222 excepting sections 7.1 (the KERBEROS_IV mechanism), 7.2 (the
GSSAPI mechanism), 7.3 (the SKEY mechanism). The KERBEROS_IV and
SKEY mechanisms are now viewed as obsolete and their specifications
provided in RFC 2222 are Historic. The GSSAPI mechanism is now
separately specified [SASL-GSSAPI].
Appendix B provides a summary of changes since RFC 2222.
1.3. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
Character names in this document use the notation for code points and
names from the Unicode Standard [Unicode]. For example, the letter
"a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
Note: a glossary of terms used in Unicode can be found in [Glossary].
Information on the Unicode character encoding model can be found in
[CharModel].
In examples, "C:" and "S:" indicate lines of data to be sent by the
client and server, respectively. Lines have been wrapped for
improved readability.
2. Identity Concepts
In practice, authentication and authorization may involve multiple
identities, possibly in different forms (simple username, Kerberos
principal, X.500 Distinguished Name, etc.), possibly with different
representations (e.g., ABNF-described UTF-8 encoded Unicode character
string, BER-encoded Distinguished Name). While technical
specifications often prescribe both the identity form and
representation used on the network, different identity forms and/or
representations may be (and often are) used within implementations.
How identities of different forms relate to each other is, generally,
a local matter. In addition, the forms and representations used
within an implementation are a local matter.
However, conceptually, the SASL framework involves two identities:
1) an identity associated with the authentication credentials
(termed the authentication identity), and
2) an identity to act as (termed the authorization identity).
SASL mechanism specifications describe the credential form(s) (e.g.,
X.509 certificates, Kerberos tickets, simple username/password) used
to authenticate the client, including (where appropriate) the syntax
and semantics of authentication identities carried in the
credentials. SASL protocol specifications describe the identity
form(s) used in authorization and, in particular, prescribe the
syntax and semantics of the authorization identity character string
to be transferred by mechanisms.
The client provides its credentials (which include or imply an
authentication identity) and, optionally, a character string
representing the requested authorization identity as part of the SASL
exchange. When this character string is omitted or empty, the client
is requesting to act as the identity associated with the credentials
(e.g., the user is requesting to act as the authentication identity).
The server is responsible for verifying the client’s credentials and
verifying that the identity it associates with the client’s
credentials (e.g., the authentication identity) is allowed to act as
the authorization identity. A SASL exchange fails if either (or
both) of these verifications fails. (The SASL exchange may fail for
other reasons, such as service authorization failure.)
However, the precise form(s) of the authentication identities (used
within the server in its verifications, or otherwise) and the precise
form(s) of the authorization identities (used in making authorization
decisions, or otherwise) are beyond the scope of SASL and this
specification. In some circumstances, the precise identity forms
used in some context outside of the SASL exchange may be dictated by
other specifications. For instance, an identity assumption
authorization (proxy authorization) policy specification may dictate
how authentication and authorization identities are represented in
policy statements.
3. The Authentication Exchange
Each authentication exchange consists of a message from the client to
the server requesting authentication via a particular mechanism,
followed by one or more pairs of challenges from the server and
responses from the client, followed by a message from the server
indicating the outcome of the authentication exchange. (Note:
exchanges may also be aborted as discussed in Section 3.5.)
The following illustration provides a high-level overview of an
authentication exchange.
C: Request authentication exchange
S: Initial challenge
C: Initial response
<additional challenge/response messages>
S: Outcome of authentication exchange
If the outcome is successful and a security layer was negotiated,
this layer is then installed (see Section 3.7). This also applies to
the following illustrations.
Some mechanisms specify that the first data sent in the
authentication exchange is from the client to the server. Protocols
may provide an optional initial response field in the request message
to carry this data. Where the mechanism specifies that the first
data sent in the exchange is from the client to the server, the
protocol provides an optional initial response field, and the client
uses this field, the exchange is shortened by one round-trip:
C: Request authentication exchange + Initial response
<additional challenge/response messages>
S: Outcome of authentication exchange
Where the mechanism specifies that the first data sent in the
exchange is from the client to the server and this field is
unavailable or unused, the client request is followed by an empty
challenge.
C: Request authentication exchange
S: Empty Challenge
C: Initial Response
<additional challenge/response messages>
S: Outcome of authentication exchange
Should a client include an initial response in its request where the
mechanism does not allow the client to send data first, the
authentication exchange fails.
Some mechanisms specify that the server is to send additional data to
the client when indicating a successful outcome. Protocols may
provide an optional additional data field in the outcome message to
carry this data. Where the mechanism specifies that the server is to
return additional data with the successful outcome, the protocol
provides an optional additional data field in the outcome message,
and the server uses this field, the exchange is shortened by one
round-trip:
C: Request authentication exchange
S: Initial challenge
C: Initial response
<additional challenge/response messages>
S: Outcome of authentication exchange with
additional data with success
Where the mechanism specifies that the server is to return additional
data to the client with a successful outcome and this field is
unavailable or unused, the additional data is sent as a challenge
whose response is empty. After receiving this response, the server
then indicates the successful outcome.
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
Where mechanisms specify that the first data sent in the exchange is
from the client to the server and additional data is sent to the
client along with indicating a successful outcome, and the protocol
provides fields supporting both, then the exchange takes two fewer
round-trips:
C: Request authentication exchange + Initial response
<additional challenge/response messages>
S: Outcome of authentication exchange
with additional data with success
instead of:
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. Mechanism Naming
SASL mechanisms are named by character strings, from 1 to 20
characters in length, consisting of ASCII [ASCII] uppercase letters,
digits, hyphens, and/or underscores. In the following Augmented
Backus-Naur Form (ABNF) [RFC4234] grammar, the <sasl-mech> production
defines the syntax of a SASL mechanism name.
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 mechanism names are registered as discussed in Section 7.1.
3.2. Mechanism Negotiation
Mechanism negotiation is protocol specific.
Commonly, a protocol will specify that the server advertises
supported and available mechanisms to the client via some facility
provided by the protocol, and the client will then select the "best"
mechanism from this list that it supports and finds suitable.
Note that the mechanism negotiation is not protected by the
subsequent authentication exchange and hence is subject to downgrade
attacks if not protected by other means.
To detect downgrade attacks, a protocol can allow the client to
discover available mechanisms subsequent to the authentication
exchange and installation of data security layers with at least data
integrity protection. This allows the client to detect changes to
the list of mechanisms supported by the server.
3.3. Request Authentication Exchange
The authentication exchange is initiated by the client by requesting
authentication via a mechanism it specifies. The client sends a
message that contains the name of the mechanism to the server. The
particulars of the message are protocol specific.
Note that the name of the mechanism is not protected by the
mechanism, and hence is subject to alteration by an attacker if not
integrity protected by other means.
Where the mechanism is defined to allow the client to send data
first, and the protocol’s request message includes an optional
initial response field, the client may include the response to the
initial challenge in the authentication request message.
3.4. Challenges and Responses
The authentication exchange involves one or more pairs of server-
challenges and client-responses, the particulars of which are
mechanism specific. These challenges and responses are enclosed in
protocol messages, the particulars of which are protocol specific.
Through these challenges and responses, the mechanism may:
- authenticate the client to the server,
- authenticate the server to the client,
- transfer an authorization identity string,
- negotiate a security layer, and
- provide other services.
The negotiation of the security layer may involve negotiation of the
security services to be provided in the layer, how these services
will be provided, and negotiation of a maximum cipher-text buffer
size each side is able to receive in the layer (see Section 3.6).
After receiving an authentication request or any client response, the
server may issue a challenge, abort the exchange, or indicate the
outcome of an exchange. After receiving a challenge, a client
mechanism may issue a response or abort the exchange.
3.4.1. Authorization Identity String
The authorization identity string is a sequence of zero or more
Unicode [Unicode] characters, excluding the NUL (U+0000) character,
representing the identity to act as.
If the authorization identity string is absent, the client is
requesting to act as the identity the server associates with the
client’s credentials. An empty string is equivalent to an absent
authorization identity.
A non-empty authorization identity string indicates that the client
wishes to act as the identity represented by the string. In this
case, the form of identity represented by the string, as well as the
precise syntax and semantics of the string, is protocol specific.
While the character encoding schema used to transfer the
authorization identity string in the authentication exchange is
mechanism specific, mechanisms are expected to be capable of carrying
the entire Unicode repertoire (with the exception of the NUL
character).
3.5. Aborting Authentication Exchanges
A client or server may desire to abort an authentication exchange if
it is unwilling or unable to continue (or enter into).
A client may abort the authentication exchange by sending a message,
the particulars of which are protocol specific, to the server,
indicating that the exchange is aborted. The server may be required
by the protocol to return a message in response to the client’s abort
message.
Likewise, a server may abort the authentication exchange by sending a
message, the particulars of which are protocol specific, to the
client, indicating that the exchange is aborted.
3.6. Authentication Outcome
At the conclusion of the authentication exchange, the server sends a
message, the particulars of which are protocol specific, to the
client indicating the outcome of the exchange.
The outcome is not successful if
- the authentication exchange failed for any reason,
- the client’s credentials could not be verified,
- the server cannot associate an identity with the client’s
credentials,
- the client-provided authorization identity string is malformed,
- the identity associated with the client’s credentials is not
authorized to act as the requested authorization identity,
- the negotiated security layer (or lack thereof) is not
suitable, or
- the server is not willing to provide service to the client for
any reason.
The protocol may include an optional additional data field in this
outcome message. This field can only include additional data when
the outcome is successful.
If the outcome is successful and a security layer was negotiated,
this layer is then installed. If the outcome is unsuccessful, or a
security layer was not negotiated, any existing security is left in
place.
The outcome message provided by the server can provide a way for the
client to distinguish between errors that are best dealt with by re-
prompting the user for her credentials, errors that are best dealt
with by telling the user to try again later, and errors where the
user must contact a system administrator for resolution (see the SYS
and AUTH POP Response Codes [RFC3206] specification for an example).
This distinction is particularly useful during scheduled server
maintenance periods as it reduces support costs. It is also
important that the server can be configured such that the outcome
message will not distinguish between a valid user with invalid
credentials and an invalid user.
3.7. Security Layers
SASL mechanisms may offer a wide range of services in security
layers. Typical services include data integrity and data
confidentiality. SASL mechanisms that do not provide a security
layer are treated as negotiating no security layer.
If use of a security layer is negotiated in the authentication
protocol exchange, the layer is installed by the server after
indicating the outcome of the authentication exchange and installed
by the client upon receipt of the outcome indication. In both cases,
the layer is installed before transfer of further protocol data. The
precise position upon which the layer takes effect in the protocol
data stream is protocol specific.
Once the security layer is in effect in the protocol data stream, it
remains in effect until either a subsequently negotiated security
layer is installed or the underlying transport connection is closed.