When in effect, the security layer processes protocol data into
buffers of protected data. If at any time the security layer is
unable or unwilling to continue producing buffers protecting protocol
data, the underlying transport connection MUST be closed. If the
security layer is not able to decode a received buffer, the
underlying connection MUST be closed. In both cases, the underlying
transport connection SHOULD be closed gracefully.
Each buffer of protected data is transferred over the underlying
transport connection as a sequence of octets prepended with a four-
octet field in network byte order that represents the length of the
buffer. The length of the protected data buffer MUST be no larger
than the maximum size that the other side expects. Upon the receipt
of a length field whose value is greater than the maximum size, the
receiver SHOULD close the connection, as this might be a sign of an
attack.
The maximum size that each side expects is fixed by the mechanism,
either through negotiation or by its specification.
3.8. Multiple Authentications
Unless explicitly permitted in the protocol (as stated in the
protocol’s technical specification), only one successful SASL
authentication exchange may occur in a protocol session. In this
case, once an authentication exchange has successfully completed,
further attempts to initiate an authentication exchange fail.
Where multiple successful SASL authentication exchanges are permitted
in the protocol, then in no case may multiple SASL security layers be
simultaneously in effect. If a security layer is in effect and a
subsequent SASL negotiation selects a second security layer, then the
second security layer replaces the first. If a security layer is in
effect and a subsequent SASL negotiation selects no security layer,
the original security layer remains in effect.
Where multiple successful SASL negotiations are permitted in the
protocol, the effect of a failed SASL authentication exchange upon
the previously established authentication and authorization state is
protocol specific. The protocol’s technical specification should be
consulted to determine whether the previous authentication and
authorization state remains in force, or changed to an anonymous
state, or otherwise was affected. Regardless of the protocol-
specific effect upon previously established authentication and
authorization state, the previously negotiated security layer remains
in effect.
4. Protocol Requirements
In order for a protocol to offer SASL services, its specification
MUST supply the following information:
1) A service name, to be selected from registry of "service" elements
for the Generic Security Service Application Program Interface
(GSSAPI) host-based service name form, as described in Section 4.1
of [RFC2743]. Note that this registry is shared by all GSSAPI and
SASL mechanisms.
2) Detail any mechanism negotiation facility that the protocol
provides (see Section 3.2).
A protocol SHOULD specify a facility through which the client may
discover, both before initiation of the SASL exchange and after
installing security layers negotiated by the exchange, the names
of the SASL mechanisms that the server makes available to the
client. The latter is important to allow the client to detect
downgrade attacks. This facility is typically provided through
the protocol’s extensions or capabilities discovery facility.
3) Definition of the messages necessary for authentication exchange,
including the following:
a) A message to initiate the authentication exchange (see Section
3.3).
This message MUST contain a field for carrying the name of the
mechanism selected by the client.
This message SHOULD contain an optional field for carrying an
initial response. If the message is defined with this field,
the specification MUST describe how messages with an empty
initial response are distinguished from messages with no
initial response. This field MUST be capable of carrying
arbitrary sequences of octets (including zero-length sequences
and sequences containing zero-valued octets).
b) Messages to transfer server challenges and client responses
(see Section 3.4).
Each of these messages MUST be capable of carrying arbitrary
sequences of octets (including zero-length sequences and
sequences containing zero-valued octets).
c) A message to indicate the outcome of the authentication
exchange (see Section 3.6).
This message SHOULD contain an optional field for carrying
additional data with a successful outcome. If the message is
defined with this field, the specification MUST describe how
messages with an empty additional data are distinguished from
messages with no additional data. This field MUST be capable
of carrying arbitrary sequences of octets (including zero-
length sequences and sequences containing zero-valued octets).
4) Prescribe the syntax and semantics of non-empty authorization
identity strings (see Section 3.4.1).
In order to avoid interoperability problems due to differing
normalizations, the protocol specification MUST detail precisely
how and where (client or server) non-empty authorization identity
strings are prepared, including all normalizations, for comparison
and other applicable functions to ensure proper function.
Specifications are encouraged to prescribe use of existing
authorization identity forms as well as existing string
representations, such as simple user names [RFC4013].
Where the specification does not precisely prescribe how
identities in SASL relate to identities used elsewhere in the
protocol, for instance, in access control policy statements, it
may be appropriate for the protocol to provide a facility by which
the client can discover information (such as the representation of
the identity used in making access control decisions) about
established identities for these uses.
5) Detail any facility the protocol provides that allows the client
and/or server to abort authentication exchange (see Section 3.5).
Protocols that support multiple authentications typically allow a
client to abort an ongoing authentication exchange by initiating a
new authentication exchange. Protocols that do not support
multiple authentications may require the client to close the
connection and start over to abort an ongoing authentication
exchange.
Protocols typically allow the server to abort ongoing
authentication exchanges by returning a non-successful outcome
message.
6) Identify precisely where newly negotiated security layers start to
take effect, in both directions (see Section 3.7).
Typically, specifications require security layers to start taking
effect on the first octet following the outcome message in data
being sent by the server and on the first octet sent after receipt
of the outcome message in data being sent by the client.
7) If the protocol supports other layered security services, such as
Transport Layer Security (TLS) [RFC4346], the specification MUST
prescribe the order in which security layers are applied to
protocol data.
For instance, where a protocol supports both TLS and SASL security
layers, the specification could prescribe any of the following:
a) SASL security layer is always applied first to data being sent
and, hence, applied last to received data,
b) SASL security layer is always applied last to data being sent
and, hence, applied first to received data,
c) Layers are applied in the order in which they were installed,
d) Layers are applied in the reverse order in which they were
installed, or
e) Both TLS and SASL security layers cannot be installed.
8) Indicate whether the protocol supports multiple authentications
(see Section 3.8). If so, the protocol MUST detail the effect a
failed SASL authentication exchange will have upon a previously
established authentication and authorization state.
Protocol specifications SHOULD avoid stating implementation
requirements that would hinder replacement of applicable mechanisms.
In general, protocol specifications SHOULD be mechanism neutral.
There are a number of reasonable exceptions to this recommendation,
including
- detailing how credentials (which are mechanism specific) are
managed in the protocol,
- detailing how authentication identities (which are mechanism
specific) and authorization identities (which are protocol
specific) relate to each other, and
- detailing which mechanisms are applicable to the protocol.
5. Mechanism Requirements
SASL mechanism specifications MUST supply the following information:
1) The name of the mechanism (see Section 3.1). This name MUST be
registered as discussed in Section 7.1.
2) A definition of the server-challenges and client-responses of the
authentication exchange, as well as the following:
a) An indication of whether the mechanism is client-first,
variable, or server-first. If a SASL mechanism is defined as
client-first and the client does not send an initial response
in the authentication request, then the first server challenge
MUST be empty (the EXTERNAL mechanism is an example of this
case). If a SASL mechanism is defined as variable, then the
specification needs to state how the server behaves when the
initial client response in the authentication request is
omitted (the DIGEST-MD5 mechanism [DIGEST-MD5] is an example of
this case). If a SASL mechanism is defined as server-first,
then the client MUST NOT send an initial client response in the
authentication request (the CRAM-MD5 mechanism [CRAM-MD5] is an
example of this case).
b) An indication of whether the server is expected to provide
additional data when indicating a successful outcome. If so,
if the server sends the additional data as a challenge, the
specification MUST indicate that the response to this challenge
is an empty response.
SASL mechanisms SHOULD be designed to minimize the number of
challenges and responses necessary to complete the exchange.
3) An indication of whether the mechanism is capable of transferring
authorization identity strings (see Section 3.4.1). While some
legacy mechanisms are incapable of transmitting an authorization
identity (which means that for these mechanisms, the authorization
identity is always the empty string), newly defined mechanisms
SHOULD be capable of transferring authorization identity strings.
The mechanism SHOULD NOT be capable of transferring both no
authorization identity string and an empty authorization identity.
Mechanisms that are capable of transferring an authorization
identity string MUST be capable of transferring arbitrary non-
empty sequences of Unicode characters, excluding those that
contain the NUL (U+0000) character. Mechanisms SHOULD use the
UTF-8 [RFC3629] transformation format. The specification MUST
detail how any Unicode code points special to the mechanism that
might appear in the authorization identity string are escaped to
avoid ambiguity during decoding of the authorization identity
string. Typically, mechanisms that have special characters
require these special characters to be escaped or encoded in the
character string (after encoding it in a particular Unicode
transformation format) using a data encoding scheme such as Base64
[RFC3548].
4) The specification MUST detail whether the mechanism offers a
security layer. If the mechanism does, the specification MUST
detail the security and other services offered in the layer as
well as how these services are to be implemented.
5) If the underlying cryptographic technology used by a mechanism
supports data integrity, then the mechanism specification MUST
integrity protect the transmission of an authorization identity
and the negotiation of the security layer.
SASL mechanisms SHOULD be protocol neutral.
SASL mechanisms SHOULD reuse existing credential and identity forms,
as well as associated syntaxes and semantics.
SASL mechanisms SHOULD use the UTF-8 transformation format [RFC3629]
for encoding Unicode [Unicode] code points for transfer.
In order to avoid interoperability problems due to differing
normalizations, when a mechanism calls for character data (other than
the authorization identity string) to be used as input to a
cryptographic and/or comparison function, the specification MUST
detail precisely how and where (client or server) the character data
is to be prepared, including all normalizations, for input into the
function to ensure proper operation.
For simple user names and/or passwords in authentication credentials,
SASLprep [RFC4013] (a profile of the StringPrep [RFC3454] preparation
algorithm), SHOULD be specified as the preparation algorithm.
The mechanism SHOULD NOT use the authorization identity string in
generation of any long-term cryptographic keys or hashes as there is
no requirement that the authorization identity string be canonical.
Long-term, here, means a term longer than the duration of the
authentication exchange in which they were generated. That is, as
different clients (of the same or different protocol) may provide
different authorization identity strings that are semantically
equivalent, use of authorization identity strings in generation of
cryptographic keys and hashes will likely lead to interoperability
and other problems.
6. Security Considerations
Security issues are discussed throughout this memo.
Many existing SASL mechanisms do not provide adequate protection
against passive attacks, let alone active attacks, in the
authentication exchange. Many existing SASL mechanisms do not offer
security layers. It is hoped that future SASL mechanisms will
provide strong protection against passive and active attacks in the
authentication exchange, as well as security layers with strong basic
data security features (e.g., data integrity and data
confidentiality) services. It is also hoped that future mechanisms
will provide more advanced data security services like re-keying (see
Section 6.3).
Regardless, the SASL framework is susceptible to downgrade attacks.
Section 6.1.2 offers a variety of approaches for preventing or
detecting these attacks. In some cases, it is appropriate to use
data integrity protective services external to SASL (e.g., TLS) to
protect against downgrade attacks in SASL. Use of external
protective security services is also important when the mechanisms
available do not themselves offer adequate integrity and/or
confidentiality protection of the authentication exchange and/or
protocol data.
6.1. Active Attacks
6.1.1. Hijack Attacks
When the client selects a SASL security layer with at least integrity
protection, this protection serves as a counter-measure against an
active attacker hijacking the connection and modifying protocol data
sent after establishment of the security layer. Implementations
SHOULD close the connection when the security services in a SASL
security layer report protocol data report lack of data integrity.
6.1.2. Downgrade Attacks
It is important that any security-sensitive protocol negotiations be
performed after installation of a security layer with data integrity
protection. Protocols should be designed such that negotiations
performed prior to this installation should be revalidated after
installation is complete. Negotiation of the SASL mechanism is
security sensitive.
When a client negotiates the authentication mechanism with the server
and/or other security features, it is possible for an active attacker
to cause a party to use the least secure security services available.
For instance, an attacker can modify the server-advertised mechanism
list or can modify the client-advertised security feature list within
a mechanism response. To protect against this sort of attack,
implementations SHOULD NOT advertise mechanisms and/or features that
cannot meet their minimum security requirements, SHOULD NOT enter
into or continue authentication exchanges that cannot meet their
minimum security requirements, and SHOULD verify that completed
authentication exchanges result in security services that meet their
minimum security requirements. Note that each endpoint needs to
independently verify that its security requirements are met.
In order to detect downgrade attacks to the least (or less) secure
mechanism supported, the client can discover the SASL mechanisms that
the server makes available both before the SASL authentication
exchange and after the negotiated SASL security layer (with at least
data integrity protection) has been installed through the protocol’s
mechanism discovery facility. If the client finds that the
integrity-protected list (the list obtained after the security layer
was installed) contains a stronger mechanism than those in the
previously obtained list, the client should assume that the
previously obtained list was modified by an attacker and SHOULD close
the underlying transport connection.
The client’s initiation of the SASL exchange, including the selection
of a SASL mechanism, is done in the clear and may be modified by an
active attacker. It is important for any new SASL mechanisms to be
designed such that an active attacker cannot obtain an authentication
with weaker security properties by modifying the SASL mechanism name
and/or the challenges and responses.
Multi-level negotiation of security features is prone to downgrade
attack. Protocol designers should avoid offering higher-level
negotiation of security features in protocols (e.g., above SASL
mechanism negotiation) and mechanism designers should avoid lower-
level negotiation of security features in mechanisms (e.g., below
SASL mechanism negotiation).
6.1.3. Replay Attacks
Some mechanisms may be subject to replay attacks unless protected by
external data security services (e.g., TLS).
6.1.4. Truncation Attacks
Most existing SASL security layers do not themselves offer protection
against truncation attack. In a truncation attack, the active
attacker causes the protocol session to be closed, causing a
truncation of the possibly integrity-protected data stream that leads
to behavior of one or both the protocol peers that inappropriately
benefits the attacker. Truncation attacks are fairly easy to defend
against in connection-oriented application-level protocols. A
protocol can defend against these attacks by ensuring that each
information exchange has a clear final result and that each protocol
session has a graceful closure mechanism, and that these are
integrity protected.
6.1.5. Other Active Attacks
When use of a security layer is negotiated by the authentication
protocol exchange, the receiver SHOULD handle gracefully any
protected data buffer larger than the defined/negotiated maximal
size. In particular, it MUST NOT blindly allocate the amount of
memory specified in the buffer size field, as this might cause the
"out of memory" condition. If the receiver detects a large block, it
SHOULD close the connection.
6.2. Passive Attacks
Many mechanisms are subject to various passive attacks, including
simple eavesdropping of unprotected credential information as well as
online and offline dictionary attacks of protected credential
information.
6.3. Re-keying
The secure or administratively permitted lifetimes of SASL
mechanisms’ security layers are finite. Cryptographic keys weaken as
they are used and as time passes; the more time and/or cipher-text
that a cryptanalyst has after the first use of the a key, the easier
it is for the cryptanalyst to mount attacks on the key.
Administrative limits on a security layer’s lifetime may take the
form of time limits expressed in X.509 certificates, in Kerberos V
tickets, or in directories, and are often desired. In practice, one
likely effect of administrative lifetime limits is that applications
may find that security layers stop working in the middle of
application protocol operation, such as, perhaps, during large data
transfers. As the result of this, the connection will be closed (see
Section 3.7), which will result in an unpleasant user experience.
Re-keying (key renegotiation process) is a way of addressing the
weakening of cryptographic keys. The SASL framework does not itself
provide for re-keying; SASL mechanisms may. Designers of future SASL
mechanisms should consider providing re-keying services.
Implementations that wish to re-key SASL security layers where the
mechanism does not provide for re-keying SHOULD reauthenticate the
same IDs and replace the expired or soon-to-expire security layers.
This approach requires support for reauthentication in the
application protocols (see Section 3.8).
6.4. Other Considerations
Protocol designers and implementors should understand the security
considerations of mechanisms so they may select mechanisms that are
applicable to their needs.
Distributed server implementations need to be careful in how they
trust other parties. In particular, authentication secrets should
only be disclosed to other parties that are trusted to manage and use
those secrets in a manner acceptable to the disclosing party.
Applications using SASL assume that SASL security layers providing
data confidentiality are secure even when an attacker chooses the
text to be protected by the security layer. Similarly, applications
assume that the SASL security layer is secure even if the attacker
can manipulate the cipher-text output of the security layer. New
SASL mechanisms are expected to meet these assumptions.
Unicode security considerations [UTR36] apply to authorization
identity strings, as well as UTF-8 [RFC3629] security considerations
where UTF-8 is used. SASLprep [RFC4013] and StringPrep [RFC3454]
security considerations also apply where used.
7. IANA Considerations
7.1. SASL Mechanism Registry
The SASL mechanism registry is maintained by IANA. The registry is
currently available at <http://www.iana.org/assignments/sasl-
mechanisms>.
The purpose of this registry is not only to ensure uniqueness of
values used to name SASL mechanisms, but also to provide a definitive
reference to technical specifications detailing each SASL mechanism
available for use on the Internet.
There is no naming convention for SASL mechanisms; any name that
conforms to the syntax of a SASL mechanism name can be registered.
The procedure detailed in Section 7.1.1 is to be used for
registration of a value naming a specific individual mechanism.
The procedure detailed in Section 7.1.2 is to be used for
registration of a value naming a family of related mechanisms.
Comments may be included in the registry as discussed in Section
7.1.3 and may be changed as discussed in Section 7.1.4.
The SASL mechanism registry has been updated to reflect that this
document provides the definitive technical specification for SASL and
that this section provides the registration procedures for this
registry.
7.1.1. Mechanism Name Registration Procedure
IANA will register new SASL mechanism names on a First Come First
Served basis, as defined in BCP 26 [RFC2434]. IANA has the right to
reject obviously bogus registration requests, but will perform no
review of claims made in the registration form.
Registration of a SASL mechanism is requested by filling in the
following template:
Subject: Registration of SASL mechanism X
SASL mechanism name (or prefix for the family):
Security considerations:
Published specification (recommended):
Person & email address to contact for further information:
Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)