draft-ietf-sasl-rfc2222bis-15.txt   rfc4422.txt 
INTERNET-DRAFT A. Melnikov, Ed. Network Working Group A. Melnikov, Ed.
Intended Category: Standards Track ISODE Limited Request for Comments: 4422 Isode Limited
Expires: July 2006 K. Zeilenga, Ed. Obsoletes: 2222 K. Zeilenga, Ed.
Obsoletes: RFC 2222 OpenLDAP Project Category: Standards Track OpenLDAP Foundation
23 January 2006
Simple Authentication and Security Layer (SASL) Simple Authentication and Security Layer (SASL)
<draft-ietf-sasl-rfc2222bis-15.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any Status of This Memo
applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware
will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/shadow.html 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 (C) The Internet Society (2006). All Rights Reserved. Copyright Notice
Please see the Full Copyright section near the end of this document Copyright (C) The Internet Society (2006).
for more information.
Abstract Abstract
The Simple Authentication and Security Layer (SASL) is a framework for The Simple Authentication and Security Layer (SASL) is a framework
providing authentication and data security services in for providing authentication and data security services in
connection-oriented protocols via replaceable mechanisms. It provides connection-oriented protocols via replaceable mechanisms. It
a structured interface between protocols and mechanisms. The provides a structured interface between protocols and mechanisms.
resulting framework allows new protocols to reuse existing mechanisms The resulting framework allows new protocols to reuse existing
and allows old protocols to make use of new mechanisms. The framework mechanisms and allows old protocols to make use of new mechanisms.
also provides a protocol for securing subsequent protocol exchanges The framework also provides a protocol for securing subsequent
within a data security layer. protocol exchanges within a data security layer.
This document describes how a SASL mechanism is structured, describes This document describes how a SASL mechanism is structured, describes
how protocols include support for SASL, and defines the protocol for how protocols include support for SASL, and defines the protocol for
carrying a data security layer over a connection. Additionally, this carrying a data security layer over a connection. In addition, this
document defines one SASL mechanism, the EXTERNAL mechanism. document defines one SASL mechanism, the EXTERNAL mechanism.
This document obsoletes RFC 2222. This document obsoletes RFC 2222.
Table of Contents Table of Contents
[[Page numbers to be filled in by RFC-Editor]] 1. Introduction ....................................................3
1.1. Document Audiences .........................................4
Status of this Memo 1.2. Relationship to Other Documents ............................4
Abstract 1.3. Conventions ................................................5
1. Introduction 2. Identity Concepts ...............................................5
1.1. Document Audiences 3. The Authentication Exchange .....................................6
1.2. Relationship to Other Documents 3.1. Mechanism Naming ...........................................8
1.3. Conventions 3.2. Mechanism Negotiation ......................................9
2. Identity Concepts 3.3. Request Authentication Exchange ............................9
3. The Authentication Exchange 3.4. Challenges and Responses ...................................9
3.1. Mechanism Naming 3.4.1. Authorization Identity String ......................10
3.2. Mechanism Negotiation 3.5. Aborting Authentication Exchanges .........................10
3.3. Request Authentication Exchange 3.6. Authentication Outcome ....................................11
3.4. Challenges and Responses 3.7. Security Layers ...........................................12
3.4.1. Authorization Identity String 3.8. Multiple Authentications ..................................12
3.5. Aborting Authentication Exchanges 4. Protocol Requirements ..........................................13
3.6. Authentication Outcome 5. Mechanism Requirements .........................................16
3.7. Security Layers 6. Security Considerations ........................................18
3.8. Multiple Authentications 6.1. Active Attacks ............................................19
4. Protocol Requirements 6.1.1. Hijack Attacks .....................................19
5. Mechanism Requirements 6.1.2. Downgrade Attacks ..................................19
6. Security Considerations 6.1.3. Replay Attacks .....................................20
6.1. Active Attacks 6.1.4. Truncation Attacks .................................20
6.1.1. Man-in-the-middle Attacks 6.1.5. Other Active Attacks ...............................20
6.1.2. Replay Attacks 6.2. Passive Attacks ...........................................20
6.1.3. Truncation Attacks 6.3. Re-keying .................................................21
6.2. Passive Attacks 6.4. Other Considerations ......................................21
6.3. Re-keying 7. IANA Considerations ............................................22
6.4. Other considerations 7.1. SASL Mechanism Registry ...................................22
7. IANA Considerations 7.2. Registration Changes ......................................26
8. References 8. References .....................................................26
9. Editors' Address 8.1. Normative References ......................................26
10. Acknowledgments 8.2. Informative References ....................................27
A. The SASL EXTERNAL Mechanism 9. Acknowledgements ...............................................28
B. Changes since RFC 2222 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 1. Introduction
The Simple Authentication and Security Layer (SASL) is a framework for The Simple Authentication and Security Layer (SASL) is a framework
providing authentication and data security services in for providing authentication and data security services in
connection-oriented protocols via replaceable mechanisms. SASL connection-oriented protocols via replaceable mechanisms. SASL
provides a structured interface between protocols and mechanisms. provides a structured interface between protocols and mechanisms.
SASL also provides a protocol for securing subsequent protocol SASL also provides a protocol for securing subsequent protocol
exchanges within a data security layer. The data security layer can exchanges within a data security layer. The data security layer can
provide data integrity, data confidentiality, and other services. provide data integrity, data confidentiality, and other services.
SASL's design is intended to allow new protocols to reuse existing SASL's design is intended to allow new protocols to reuse existing
mechanisms without requiring redesign of the mechanisms and allows mechanisms without requiring redesign of the mechanisms and allows
existing protocols to make use of new mechanisms without redesign of existing protocols to make use of new mechanisms without redesign of
protocols. protocols.
SASL is conceptually a framework which provides an abstraction layer SASL is conceptually a framework that provides an abstraction layer
between protocols and mechanisms as illustrated in the following between protocols and mechanisms as illustrated in the following
diagram. diagram.
SMTP LDAP XMPP Other protocols ... SMTP LDAP XMPP Other protocols ...
\ | | / \ | | /
\ | | / \ | | /
SASL abstraction layer SASL abstraction layer
/ | | \ / | | \
/ | | \ / | | \
EXTERNAL GSSAPI PLAIN Other mechanisms ... EXTERNAL GSSAPI PLAIN Other mechanisms ...
It is through the interfaces of this abstraction layer that the It is through the interfaces of this abstraction layer that the
framework allows any protocol to utilize any mechanism. While this framework allows any protocol to utilize any mechanism. While this
layer does generally hide the particulars of protocols from mechanisms layer does generally hide the particulars of protocols from
and the particulars of mechanisms from protocols, this layer does not mechanisms and the particulars of mechanisms from protocols, this
generally hide the particulars of mechanisms from protocol layer does not generally hide the particulars of mechanisms from
implementations. For example, different mechanisms require different protocol implementations. For example, different mechanisms require
information to operate, some of them use password-based different information to operate, some of them use password-based
authentication, some of then require realm information, others make authentication, some of then require realm information, others make
use of Kerberos tickets, certificates, etc.. Also, in order to use of Kerberos tickets, certificates, etc. Also, in order to
perform authorization, server implementations generally have to perform authorization, server implementations generally have to
implement identity mapping between authentication identities, whose implement identity mapping between authentication identities, whose
form is mechanism-specific, and authorization identities, whose form form is mechanism specific, and authorization identities, whose form
is application protocol specific. Section 2 discusses identity is application protocol specific. Section 2 discusses identity
concepts. concepts.
It is possible to design and implement this framework in ways which do It is possible to design and implement this framework in ways that do
abstract away particulars of similar mechanisms. Such a framework abstract away particulars of similar mechanisms. Such a framework
implementation, as well as mechanisms implementations, could be implementation, as well as mechanisms implementations, could be
designed not only to be shared by multiple implementations of a designed not only to be shared by multiple implementations of a
particular protocol, but be shared by implementations of multiple particular protocol but to be shared by implementations of multiple
protocols. protocols.
The framework incorporates interfaces with both protocols and The framework incorporates interfaces with both protocols and
mechanisms in which authentication exchanges are carried out. Section mechanisms in which authentication exchanges are carried out.
3 discusses SASL authentication exchanges. Section 3 discusses SASL authentication exchanges.
To use SASL, each protocol (amongst other items) provides a method for To use SASL, each protocol (amongst other items) provides a method
identifying which mechanism is to be used, provides a method for for identifying which mechanism is to be used, a method for exchange
exchange of mechanism-specific server-challenges and client-responses, of mechanism-specific server-challenges and client-responses, and a
and a method for communicating the outcome of the authentication method for communicating the outcome of the authentication exchange.
exchange. Section 4 discusses SASL protocol requirements. Section 4 discusses SASL protocol requirements.
Each SASL mechanism defines (amongst other items) a series of server Each SASL mechanism defines (amongst other items) a series of
challenges and client responses which provide authentication services server-challenges and client-responses that provide authentication
and negotiate data security services. Section 5 discusses SASL services and negotiate data security services. Section 5 discusses
mechanism requirements. SASL mechanism requirements.
Section 6 discusses security considerations. Section 7 discusses IANA Section 6 discusses security considerations. Section 7 discusses
considerations. Appendix A defines the SASL EXTERNAL mechanism. IANA considerations. Appendix A defines the SASL EXTERNAL mechanism.
1.1. Document Audiences 1.1. Document Audiences
This document is written to serve several different audiences: This document is written to serve several different audiences:
- protocol designers using this specification to support - protocol designers using this specification to support
authentication in their protocol, authentication in their protocol,
- mechanism designers that define new SASL mechanisms, and - mechanism designers that define new SASL mechanisms, and
- implementors of clients or servers for those protocols which - implementors of clients or servers for those protocols that
support SASL. support SASL.
While the document organization is intended to allow readers to focus While the document organization is intended to allow readers to focus
on details relevant to their engineering, readers are encouraged to on details relevant to their engineering, readers are encouraged to
read and understand all aspects of this document. read and understand all aspects of this document.
1.2. Relationship to other documents 1.2. Relationship to Other Documents
This document obsoletes RFC 2222. It replaces all portions of RFC This document obsoletes RFC 2222. It replaces all portions of RFC
2222 excepting sections 7.1 (the KERBEROS_IV mechanism), 7.2 (the 2222 excepting sections 7.1 (the KERBEROS_IV mechanism), 7.2 (the
GSSAPI mechanism), 7.3 (the SKEY mechanism). The KERBEROS_IV and SKEY GSSAPI mechanism), 7.3 (the SKEY mechanism). The KERBEROS_IV and
mechanisms are now viewed as obsolete and their specifications SKEY mechanisms are now viewed as obsolete and their specifications
provided in RFC 2222 are Historic. The GSSAPI mechanism is now provided in RFC 2222 are Historic. The GSSAPI mechanism is now
separately specified [SASL-GSSAPI]. separately specified [SASL-GSSAPI].
Appendix B provides a summary of changes since RFC 2222. Appendix B provides a summary of changes since RFC 2222.
1.3. Conventions 1.3. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119]. document are to be interpreted as described in BCP 14 [RFC2119].
Character names in this document use the notation for code points and Character names in this document use the notation for code points and
names from the Unicode Standard [Unicode]. For example, the letter names from the Unicode Standard [Unicode]. For example, the letter
"a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>. "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]. Note: a glossary of terms used in Unicode can be found in [Glossary].
Information on the Unicode character encoding model can be found in Information on the Unicode character encoding model can be found in
[CharModel]. [CharModel].
In examples, "C:" and "S:" indicate lines of data to be sent by the In examples, "C:" and "S:" indicate lines of data to be sent by the
client and server respectively. Lines have been wrapped for improved client and server, respectively. Lines have been wrapped for
readability. improved readability.
2. Identity Concepts 2. Identity Concepts
In practice, authentication and authorization may involve multiple In practice, authentication and authorization may involve multiple
identities, possibly in different forms (simple username, Kerberos identities, possibly in different forms (simple username, Kerberos
principal, X.500 Distinguished Name, etc.), possibly with different principal, X.500 Distinguished Name, etc.), possibly with different
representations (e.g.: ABNF-described UTF-8 encoded Unicode character representations (e.g., ABNF-described UTF-8 encoded Unicode character
string, BER-encoded Distinguished Name). While technical string, BER-encoded Distinguished Name). While technical
specifications often prescribe both the identity form and specifications often prescribe both the identity form and
representation used on the network, different identity forms and/or representation used on the network, different identity forms and/or
representations may (and often are) used within implementations. How representations may be (and often are) used within implementations.
identities of different forms relate to each other is, generally, a How identities of different forms relate to each other is, generally,
local matter. Additionally, the forms and representations used within a local matter. In addition, the forms and representations used
an implementation is a local matter. within an implementation are a local matter.
However, conceptually, the SASL framework involves two identities:
However, conceptually, SASL framework involves two identities:
1) an identity associated with the authentication credentials 1) an identity associated with the authentication credentials
(termed the authentication identity), and (termed the authentication identity), and
2) an identity to act as (termed the authorization identity). 2) an identity to act as (termed the authorization identity).
SASL mechanism specifications describe the credential form(s) (e.g., SASL mechanism specifications describe the credential form(s) (e.g.,
X.509 certificates, Kerberos tickets, simple username/password) used X.509 certificates, Kerberos tickets, simple username/password) used
to authenticate the client, including (where appropriate) the syntax to authenticate the client, including (where appropriate) the syntax
and semantics of authentication identities carried in the credentials. and semantics of authentication identities carried in the
SASL protocol specifications describe the identity form(s) used in credentials. SASL protocol specifications describe the identity
authorization and, in particular, prescribe the syntax and semantics form(s) used in authorization and, in particular, prescribe the
of the authorization identity character string to be transferred by syntax and semantics of the authorization identity character string
mechanisms. to be transferred by mechanisms.
The client provides its credentials (which include or imply an The client provides its credentials (which include or imply an
authentication identity) and, optionally, a character string authentication identity) and, optionally, a character string
representing the requested authorization identity as part of the SASL representing the requested authorization identity as part of the SASL
exchange. When this character string is omitted or empty, the client exchange. When this character string is omitted or empty, the client
is requesting to act as the identity associated with the credentials is requesting to act as the identity associated with the credentials
(e.g., the user is requesting to act as the authentication identity). (e.g., the user is requesting to act as the authentication identity).
The server is responsible for verifying the client's credentials and The server is responsible for verifying the client's credentials and
verifying that the identity it associates with the client's verifying that the identity it associates with the client's
credentials (e.g., the authentication identity) is allowed to act as credentials (e.g., the authentication identity) is allowed to act as
the authorization identity. A SASL exchange fails if either (or both) the authorization identity. A SASL exchange fails if either (or
of these verifications fails. (The SASL exchange may fail for other both) of these verifications fails. (The SASL exchange may fail for
reasons, such as service authorization failure.) other reasons, such as service authorization failure.)
However, the precise form(s) of the authentication identities (used However, the precise form(s) of the authentication identities (used
within the server in its verifications, or otherwise) and the precise within the server in its verifications, or otherwise) and the precise
form(s) of the authorization identities (used in making authorization form(s) of the authorization identities (used in making authorization
decisions, or otherwise) is beyond the scope of SASL and this decisions, or otherwise) are beyond the scope of SASL and this
specification. In some circumstances, the precise identity forms used specification. In some circumstances, the precise identity forms
in some context outside of the SASL exchange may be dictated by other used in some context outside of the SASL exchange may be dictated by
specifications. For instance, an identity assumption authorization other specifications. For instance, an identity assumption
(proxy authorization) policy specification may dictate how authorization (proxy authorization) policy specification may dictate
authentication and authorization identities are represented in policy how authentication and authorization identities are represented in
statements. policy statements.
3. The Authentication Exchange 3. The Authentication Exchange
Each authentication exchange consists of a message from the client to Each authentication exchange consists of a message from the client to
the server requesting authentication via a particular mechanism, the server requesting authentication via a particular mechanism,
followed by one or more pairs of challenges from the server and followed by one or more pairs of challenges from the server and
responses from the client, followed by a message from the server responses from the client, followed by a message from the server
indicating the outcome of the authentication exchange. (Note: indicating the outcome of the authentication exchange. (Note:
exchanges may also be aborted as discussed in Section 3.5.) exchanges may also be aborted as discussed in Section 3.5.)
The following illustration provides a high-level overview of an The following illustration provides a high-level overview of an
authentication exchange. authentication exchange.
C: Request authentication exchange C: Request authentication exchange
S: Initial challenge S: Initial challenge
C: Initial response C: Initial response
<additional challenge/response messages> <additional challenge/response messages>
S: Outcome of authentication exchange S: Outcome of authentication exchange
If the outcome is successful and a security layer was negotiated, this If the outcome is successful and a security layer was negotiated,
layer is then installed (see Section 3.7). This also applies to the this layer is then installed (see Section 3.7). This also applies to
following illustrations. the following illustrations.
Some mechanisms specify that the first data sent in the authentication Some mechanisms specify that the first data sent in the
exchange is from the client to the server. Protocols may provide an authentication exchange is from the client to the server. Protocols
optional initial response field in the request message to carry this may provide an optional initial response field in the request message
data. Where the mechanism specifies the first data sent in the to carry this data. Where the mechanism specifies that the first
exchange is from the client to the server, the protocol provides an data sent in the exchange is from the client to the server, the
optional initial response field, and the client uses this field, the protocol provides an optional initial response field, and the client
exchange is shortened by one round-trip: uses this field, the exchange is shortened by one round-trip:
C: Request authentication exchange + Initial response C: Request authentication exchange + Initial response
<additional challenge/response messages> <additional challenge/response messages>
S: Outcome of authentication exchange S: Outcome of authentication exchange
Where the mechanism specifies the first data sent in the exchange is Where the mechanism specifies that the first data sent in the
from the client to the server and this field is unavailable or unused, exchange is from the client to the server and this field is
the client request is followed by an empty challenge. unavailable or unused, the client request is followed by an empty
challenge.
C: Request authentication exchange C: Request authentication exchange
S: Empty Challenge S: Empty Challenge
C: Initial Response C: Initial Response
<additional challenge/response messages> <additional challenge/response messages>
S: Outcome of authentication exchange S: Outcome of authentication exchange
Should a client include an initial response in its request where the Should a client include an initial response in its request where the
mechanism does not allow the client to send data first, the mechanism does not allow the client to send data first, the
authentication exchange fails. authentication exchange fails.
Some mechanisms specify that the server is to send additional data to Some mechanisms specify that the server is to send additional data to
the client when indicating a successful outcome. Protocols may the client when indicating a successful outcome. Protocols may
provide an optional additional data field in the outcome message to provide an optional additional data field in the outcome message to
carry this data. Where the mechanism specifies the server is to carry this data. Where the mechanism specifies that the server is to
return additional data with the successful outcome, the protocol return additional data with the successful outcome, the protocol
provides an optional additional data field in the outcome message, and provides an optional additional data field in the outcome message,
the server uses this field, the exchange is shortened by one and the server uses this field, the exchange is shortened by one
round-trip: round-trip:
C: Request authentication exchange C: Request authentication exchange
S: Initial challenge S: Initial challenge
C: Initial response C: Initial response
<additional challenge/response messages> <additional challenge/response messages>
S: Outcome of authentication exchange with S: Outcome of authentication exchange with
additional data with success additional data with success
Where the mechanism specifies the server is to return additional data Where the mechanism specifies that the server is to return additional
to the client with a successful outcome and this field is unavailable data to the client with a successful outcome and this field is
or unused, the additional data is sent as a challenge whose response unavailable or unused, the additional data is sent as a challenge
is empty. After receiving this response, the server then indicates whose response is empty. After receiving this response, the server
the successful outcome. then indicates the successful outcome.
C: Request authentication exchange C: Request authentication exchange
S: Initial challenge S: Initial challenge
C: Initial response C: Initial response
<additional challenge/response messages> <additional challenge/response messages>
S: Additional data challenge S: Additional data challenge
C: Empty Response C: Empty Response
S: Outcome of authentication exchange S: Outcome of authentication exchange
Where mechanisms specify the first data sent in the exchange is from Where mechanisms specify that the first data sent in the exchange is
the client to the server and additional data is sent to the client from the client to the server and additional data is sent to the
along with indicating a successful outcome, and the protocol provides client along with indicating a successful outcome, and the protocol
fields supporting both, then the exchange takes two fewer round-trips: provides fields supporting both, then the exchange takes two fewer
round-trips:
C: Request authentication exchange + Initial response C: Request authentication exchange + Initial response
<additional challenge/response messages> <additional challenge/response messages>
S: Outcome of authentication exchange S: Outcome of authentication exchange
with additional data with success with additional data with success
instead of: instead of:
C: Request authentication exchange C: Request authentication exchange
S: Empty Challenge S: Empty Challenge
skipping to change at page 8, line 49 skipping to change at page 8, line 52
sasl-mech = 1*20mech-char sasl-mech = 1*20mech-char
mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE
; mech-char is restricted to A-Z (uppercase only), 0-9, -, and _ ; mech-char is restricted to A-Z (uppercase only), 0-9, -, and _
; from ASCII character set. ; from ASCII character set.
UPPER-ALPHA = %x41-5A ; A-Z (uppercase only) UPPER-ALPHA = %x41-5A ; A-Z (uppercase only)
DIGIT = %x30-39 ; 0-9 DIGIT = %x30-39 ; 0-9
HYPHEN = %x2D ; hyphen (-) HYPHEN = %x2D ; hyphen (-)
UNDERSCORE = %x5F ; underscore (_) UNDERSCORE = %x5F ; underscore (_)
SASL mechanisms names are registered as discussed in Section 7.1. SASL mechanism names are registered as discussed in Section 7.1.
3.2. Mechanism Negotiation 3.2. Mechanism Negotiation
Mechanism negotiation is protocol-specific. Mechanism negotiation is protocol specific.
Commonly, a protocol will specify that the server advertises supported Commonly, a protocol will specify that the server advertises
and available mechanisms to the client via some facility provided by supported and available mechanisms to the client via some facility
the protocol and the client will then select the "best" mechanism from provided by the protocol, and the client will then select the "best"
this list which its supports and finds suitable. mechanism from this list that it supports and finds suitable.
It is noted that the mechanism negotiation is not protected by the Note that the mechanism negotiation is not protected by the
subsequent authentication exchange and hence is subject to downgrade subsequent authentication exchange and hence is subject to downgrade
attacks if not protected by other means. attacks if not protected by other means.
To detect downgrade attacks, a protocol can allow the client to To detect downgrade attacks, a protocol can allow the client to
discover available mechanisms subsequent to the authentication discover available mechanisms subsequent to the authentication
exchange and installation of data security layers with at least data exchange and installation of data security layers with at least data
integrity protection. This allows the client to detect changes to the integrity protection. This allows the client to detect changes to
list of mechanisms supported by the server. the list of mechanisms supported by the server.
3.3. Request Authentication Exchange 3.3. Request Authentication Exchange
The authentication exchange is initiated by the client by requesting The authentication exchange is initiated by the client by requesting
authentication via a mechanism it specifies. The client sends a authentication via a mechanism it specifies. The client sends a
message that contains the name of the mechanism to the server. The message that contains the name of the mechanism to the server. The
particulars of the message are protocol specific. particulars of the message are protocol specific.
It is noted that the name of the mechanism is not protected by the Note that the name of the mechanism is not protected by the
mechanism, and hence subject to alteration by an attacker if not mechanism, and hence is subject to alteration by an attacker if not
integrity protected by other means. integrity protected by other means.
Where the mechanism is defined to allow the client to send data first, Where the mechanism is defined to allow the client to send data
and the protocol's request message includes an optional initial first, and the protocol's request message includes an optional
response field, the client may include the response to the initial initial response field, the client may include the response to the
challenge in the authentication request message. initial challenge in the authentication request message.
3.4. Challenges and Responses 3.4. Challenges and Responses
The authentication exchange involves one or more pairs of The authentication exchange involves one or more pairs of server-
server-challenges and client-responses, the particulars of which are challenges and client-responses, the particulars of which are
mechanism specific. These challenges and responses are enclosed in mechanism specific. These challenges and responses are enclosed in
protocol messages, the particulars of which are protocol specific. protocol messages, the particulars of which are protocol specific.
Through these challenges and responses, the mechanism may: Through these challenges and responses, the mechanism may:
- authenticate the client to the server, - authenticate the client to the server,
- authenticate the server to the client, - authenticate the server to the client,
- transfer an authorization identity string, - transfer an authorization identity string,
- negotiate a security layer, and - negotiate a security layer, and
- provide other services. - provide other services.
The negotiation of the security layer may involve negotiation of the The negotiation of the security layer may involve negotiation of the
security services to be provided in the layer, how these services will security services to be provided in the layer, how these services
be provided, and negotiation of a maximum cipher-text buffer size each will be provided, and negotiation of a maximum cipher-text buffer
side is able to receive in the layer (see Section 3.6). size each side is able to receive in the layer (see Section 3.6).
After receiving an authentication request or any client response, the After receiving an authentication request or any client response, the
server may issue a challenge, abort the exchange, or indicate the server may issue a challenge, abort the exchange, or indicate the
outcome of an exchange. After receiving a challenge, a client outcome of an exchange. After receiving a challenge, a client
mechanism may issue a response or abort the exchange. mechanism may issue a response or abort the exchange.
3.4.1. Authorization Identity String 3.4.1. Authorization Identity String
The authorization identity string is a sequence of zero or more The authorization identity string is a sequence of zero or more
Unicode [Unicode] characters, excluding the NUL (U+0000) character, Unicode [Unicode] characters, excluding the NUL (U+0000) character,
representing the identity to act as. representing the identity to act as.
If the authorization identity string is absent, the client is If the authorization identity string is absent, the client is
requesting to act as the identity the server associates with the requesting to act as the identity the server associates with the
client's credentials. An empty string is equivalent to an absent client's credentials. An empty string is equivalent to an absent
authorization identity. authorization identity.
Non-empty authorization identity string indicates the client wishes to A non-empty authorization identity string indicates that the client
act as the identity represented by the string. In this case, the form wishes to act as the identity represented by the string. In this
of identity represented by the string, as well as the precise syntax case, the form of identity represented by the string, as well as the
and semantics of the string, is protocol specific. precise syntax and semantics of the string, is protocol specific.
While the character encoding schema used to transfer the authorization While the character encoding schema used to transfer the
identity string in the authentication exchange is mechanism specific, authorization identity string in the authentication exchange is
mechanisms are expected to be capable of carrying the entire Unicode mechanism specific, mechanisms are expected to be capable of carrying
repertoire (with the exception of the NUL character). the entire Unicode repertoire (with the exception of the NUL
character).
3.5. Aborting Authentication Exchanges 3.5. Aborting Authentication Exchanges
A client or server may desire to abort an authentication exchange if A client or server may desire to abort an authentication exchange if
it is unwilling or unable to continue (or enter into). it is unwilling or unable to continue (or enter into).
A client may abort the authentication exchange by sending a message, A client may abort the authentication exchange by sending a message,
the particulars of which are protocol-specific, to the server, the particulars of which are protocol specific, to the server,
indicating the exchange is aborted. The server may be required by the indicating that the exchange is aborted. The server may be required
protocol to return a message in response to the client's abort by the protocol to return a message in response to the client's abort
message. message.
Likewise, a server may abort the authentication exchange by sending a Likewise, a server may abort the authentication exchange by sending a
message, the particulars of which are protocol-specific, to the message, the particulars of which are protocol specific, to the
client, indicating the exchange is aborted. client, indicating that the exchange is aborted.
3.6. Authentication Outcome 3.6. Authentication Outcome
At the conclusion of the authentication exchange, the server sends a At the conclusion of the authentication exchange, the server sends a
message, the particulars of which are protocol specific, to the client message, the particulars of which are protocol specific, to the
indicating the outcome of the exchange. client indicating the outcome of the exchange.
The outcome is not successful if The outcome is not successful if
- the authentication exchange failed for any reason, - the authentication exchange failed for any reason,
- the clients credentials could not be verified,
- the client's credentials could not be verified,
- the server cannot associate an identity with the client's - the server cannot associate an identity with the client's
credentials, credentials,
- the client-provided authorization identity string is malformed, - the client-provided authorization identity string is malformed,
- the identity associated with the client's credentials is not - the identity associated with the client's credentials is not
authorized to act as the requested authorization identity, authorized to act as the requested authorization identity,
- the negotiated security layer (or lack thereof) is not suitable,
or - the negotiated security layer (or lack thereof) is not
- the server is not willing to provide service to the client for any suitable, or
reason.
- 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 The protocol may include an optional additional data field in this
outcome message. This field can only include additional data when the outcome message. This field can only include additional data when
outcome is successful. the outcome is successful.
If the outcome is successful and a security layer was negotiated, this If the outcome is successful and a security layer was negotiated,
layer is then installed. If the outcome is unsuccessful, or a this layer is then installed. If the outcome is unsuccessful, or a
security layer was not negotiated, any existing security is left in security layer was not negotiated, any existing security is left in
place. place.
The outcome message provided by the server can provide a way for the The outcome message provided by the server can provide a way for the
client to distinguish between errors which are best dealt with by re- client to distinguish between errors that are best dealt with by re-
prompting the user for her credentials, errors which are best dealt 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 with by telling the user to try again later, and errors where the
must contact a system administrator for resolution (see The SYS and user must contact a system administrator for resolution (see the SYS
AUTH POP Response Codes [RFC3206] specification for an example). This and AUTH POP Response Codes [RFC3206] specification for an example).
distinction is particularly useful during scheduled server maintenance This distinction is particularly useful during scheduled server
periods as it reduces support costs. It is also important that the maintenance periods as it reduces support costs. It is also
server can be configured such that the outcome message will not important that the server can be configured such that the outcome
distinguish between a valid user with invalid credentials and an message will not distinguish between a valid user with invalid
invalid user. credentials and an invalid user.
3.7. Security Layers 3.7. Security Layers
SASL mechanisms may offer a wide range of services in security layers. SASL mechanisms may offer a wide range of services in security
layers. Typical services include data integrity and data
Typical services include data integrity and data confidentiality. confidentiality. SASL mechanisms that do not provide a security
SASL mechanisms which do not provide a security layer are treated as layer are treated as negotiating no security layer.
negotiating no security layer.
If use of a security layer is negotiated in the authentication If use of a security layer is negotiated in the authentication
protocol exchange, the layer is installed by the server after protocol exchange, the layer is installed by the server after
indicating the outcome of the authentication exchange and installed by indicating the outcome of the authentication exchange and installed
the client upon receipt the outcome indication. In both cases, the by the client upon receipt of the outcome indication. In both cases,
layer is installed before transfer of further protocol data. The the layer is installed before transfer of further protocol data. The
precise position that the layer takes effect in the protocol data precise position upon which the layer takes effect in the protocol
stream is protocol specific. data stream is protocol specific.
Once the security layer is in effect in the protocol data stream, it Once the security layer is in effect in the protocol data stream, it
remains in effect until either a subsequently negotiated security remains in effect until either a subsequently negotiated security
layer is installed, or the underlying transport connection is closed. layer is installed or the underlying transport connection is closed.
When in effect, the security layer processes protocol data into When in effect, the security layer processes protocol data into
buffers of protected data. If at any time the security layer is buffers of protected data. If at any time the security layer is
unable or unwilling to continue producing buffers protecting protocol unable or unwilling to continue producing buffers protecting protocol
data, the underlying transport connection MUST be closed. If the data, the underlying transport connection MUST be closed. If the
security layer is not able to decode a received buffer, the underlying security layer is not able to decode a received buffer, the
connection MUST be closed. In both cases the underlying transport underlying connection MUST be closed. In both cases, the underlying
connection SHOULD be closed gracefully. transport connection SHOULD be closed gracefully.
Each buffer of protected data is transferred over the underlying Each buffer of protected data is transferred over the underlying
transport connection as a sequence of octets prepended with a four transport connection as a sequence of octets prepended with a four-
octet field in network byte order that represents the length of the octet field in network byte order that represents the length of the
buffer. The length of the protected data buffer MUST be no larger buffer. The length of the protected data buffer MUST be no larger
than the maximum size the other side expects. Upon the receipt of a than the maximum size that the other side expects. Upon the receipt
length field whose value is greater than maximum size, the receiver of a length field whose value is greater than the maximum size, the
SHOULD close the connection, as this might be a sign of an attack. receiver SHOULD close the connection, as this might be a sign of an
attack.
The maximum size each side expects is fixed by the mechanism, either The maximum size that each side expects is fixed by the mechanism,
through negotiation or by its specification. either through negotiation or by its specification.
3.8. Multiple Authentications 3.8. Multiple Authentications
Unless explicitly permitted in the protocol (as stated in the Unless explicitly permitted in the protocol (as stated in the
protocol's technical specification), only one successful SASL protocol's technical specification), only one successful SASL
authentication exchange may occur in a protocol session. In this authentication exchange may occur in a protocol session. In this
case, once an authentication exchange has successfully completed, case, once an authentication exchange has successfully completed,
further attempts to initiate an authentication exchange fail. further attempts to initiate an authentication exchange fail.
Where multiple successful SASL authentication exchanges are permitted Where multiple successful SASL authentication exchanges are permitted
in the protocol, then in no case may multiple SASL security layers be 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 simultaneously in effect. If a security layer is in effect and a
subsequent SASL negotiation selects a second security layer, then the subsequent SASL negotiation selects a second security layer, then the
second security layer replaces the first. If a security layer is in second security layer replaces the first. If a security layer is in
effect and a subsequent SASL negotiation selects no security layer, effect and a subsequent SASL negotiation selects no security layer,
the original security layer remains in effect. the original security layer remains in effect.
Where multiple successful SASL negotiations are permitted in the Where multiple successful SASL negotiations are permitted in the
protocol, the effect of a failed SASL authentication exchange upon the protocol, the effect of a failed SASL authentication exchange upon
previously established authentication and authorization state is the previously established authentication and authorization state is
protocol specific. The protocol's technical specification should be protocol specific. The protocol's technical specification should be
consulted to determine whether the previous authentication and consulted to determine whether the previous authentication and
authorization state remains in force, or changed to an anonymous authorization state remains in force, or changed to an anonymous
state, or otherwise effected. Regardless of the protocol-specific state, or otherwise was affected. Regardless of the protocol-
effect upon previously established authentication and authorization specific effect upon previously established authentication and
state, the previously negotiated security layer remains in effect. authorization state, the previously negotiated security layer remains
in effect.
4. Protocol Requirements 4. Protocol Requirements
In order for a protocol to offer SASL services, its specification MUST In order for a protocol to offer SASL services, its specification
supply the following information: MUST supply the following information:
1) A service name, to be selected from registry of "service" elements 1) A service name, to be selected from registry of "service" elements
for the GSSAPI host-based service name form, as described in for the Generic Security Service Application Program Interface
Section 4.1 of [RFC2743]. Note that this registry is shared by all (GSSAPI) host-based service name form, as described in Section 4.1
GSSAPI and SASL mechanisms. of [RFC2743]. Note that this registry is shared by all GSSAPI and
SASL mechanisms.
2) Detail any mechanism negotiation facility the protocol provides 2) Detail any mechanism negotiation facility that the protocol
(see Section 3.2). provides (see Section 3.2).
A protocol SHOULD specify a facility through which the client may A protocol SHOULD specify a facility through which the client may
discover, both before initiation of the SASL exchange and after discover, both before initiation of the SASL exchange and after
installing security layers negotiated by the exchange, the names of installing security layers negotiated by the exchange, the names
the SASL mechanisms the server makes available to the client. The of the SASL mechanisms that the server makes available to the
latter is important to allow the client to detect downgrade client. The latter is important to allow the client to detect
attacks. This facility is typically provided through the downgrade attacks. This facility is typically provided through
protocol's extensions or capabilities discovery facility. the protocol's extensions or capabilities discovery facility.
3) Definition of the messages necessary for authentication exchange, 3) Definition of the messages necessary for authentication exchange,
including: including the following:
a) A message to initiate the authentication exchange (see Section a) A message to initiate the authentication exchange (see Section
3.3). 3.3).
This message MUST contain a field for carrying the name of the This message MUST contain a field for carrying the name of the
mechanism selected by the client. mechanism selected by the client.
This message SHOULD contain an optional field for carrying an This message SHOULD contain an optional field for carrying an
initial response. If the message is defined with this field, initial response. If the message is defined with this field,
the specification MUST describe how messages with an empty the specification MUST describe how messages with an empty
initial response are distinguished from messages with no initial initial response are distinguished from messages with no
response. This field MUST be capable of carrying arbitrary initial response. This field MUST be capable of carrying
sequences of octets (including zero length sequences and arbitrary sequences of octets (including zero-length sequences
sequences containing zero-valued octets). and sequences containing zero-valued octets).
b) Messages to transfer server challenges and client responses. b) Messages to transfer server challenges and client responses
(see Section 3.4). (see Section 3.4).
Each of these messages MUST be capable of carrying arbitrary Each of these messages MUST be capable of carrying arbitrary
sequences of octets (including zero length sequences and sequences of octets (including zero-length sequences and
sequences containing zero-valued octets). sequences containing zero-valued octets).
c) A message to indicate the outcome of the authentication exchange c) A message to indicate the outcome of the authentication
(see Section 3.6). exchange (see Section 3.6).
This message SHOULD contain an optional field for carrying This message SHOULD contain an optional field for carrying
additional data with a successful outcome. If the message is additional data with a successful outcome. If the message is
defined with this field, the specification MUST describe how defined with this field, the specification MUST describe how
messages with an empty additional data are distinguished from messages with an empty additional data are distinguished from
messages with no additional data. This field MUST be capable of messages with no additional data. This field MUST be capable
carrying arbitrary sequences of octets (including zero length of carrying arbitrary sequences of octets (including zero-
sequences and sequences containing zero-valued octets). length sequences and sequences containing zero-valued octets).
4) Prescribe the syntax and semantics of non-empty authorization 4) Prescribe the syntax and semantics of non-empty authorization
identity strings (see Section 3.4.1). identity strings (see Section 3.4.1).
In order to avoid interoperability problems due to differing In order to avoid interoperability problems due to differing
normalizations, the protocol specification MUST detail precisely normalizations, the protocol specification MUST detail precisely
the how and where (client or server) non-empty authorization how and where (client or server) non-empty authorization identity
identity strings are prepared, including all normalizations, for strings are prepared, including all normalizations, for comparison
comparison and other applicable functions to ensure proper and other applicable functions to ensure proper function.
function.
Specifications are encouraged to prescribe use of existing Specifications are encouraged to prescribe use of existing
authorization identity forms as well as existing string authorization identity forms as well as existing string
representations, such as simple user names [RFC4013]. representations, such as simple user names [RFC4013].
Where the specification does not precisely prescribe how identities Where the specification does not precisely prescribe how
in SASL relate to identities used elsewhere in the protocol, for identities in SASL relate to identities used elsewhere in the
instance in access control policy statements, it may be appropriate protocol, for instance, in access control policy statements, it
for the protocol to provide a facility by which the client can may be appropriate for the protocol to provide a facility by which
discover information (such as the representation of the identity the client can discover information (such as the representation of
used in making access control decisions) about established the identity used in making access control decisions) about
identities for these uses. established identities for these uses.
5) Detail any facility the protocol provides that allows the client 5) Detail any facility the protocol provides that allows the client
and/or server to abort authentication exchange (see Section 3.5). and/or server to abort authentication exchange (see Section 3.5).
Protocols which support multiple authentications typically allow a Protocols that support multiple authentications typically allow a
client to abort an on-going authentication exchange by initiating a client to abort an ongoing authentication exchange by initiating a
new authentication exchange. Protocols which do not support new authentication exchange. Protocols that do not support
multiple authentications may require the client to close the multiple authentications may require the client to close the
connection and start over to abort an on-going authentication connection and start over to abort an ongoing authentication
exchange. exchange.
Protocols typically allow the server to abort on-going Protocols typically allow the server to abort ongoing
authentication exchanges by returning a non-successful outcome authentication exchanges by returning a non-successful outcome
message. message.
6) Identify precisely where newly negotiated security layers start to 6) Identify precisely where newly negotiated security layers start to
take effect, in both directions (see Section 3.7). take effect, in both directions (see Section 3.7).
Typically, specifications require security layer to start taking Typically, specifications require security layers to start taking
effect, in data being sent by the server, on the first octet effect on the first octet following the outcome message in data
following the outcome message and, in data being sent by the being sent by the server and on the first octet sent after receipt
client, on the first octet sent after receipt of the outcome of the outcome message in data being sent by the client.
message.
7) If the protocol supports other layered security services, such as 7) If the protocol supports other layered security services, such as
Transport Layer Security (TLS) [RFC2246], the specification MUST Transport Layer Security (TLS) [RFC4346], the specification MUST
prescribe the order in which security layers are applied to prescribe the order in which security layers are applied to
protocol data. protocol data.
For instance, where a protocol supports both TLS and SASL security For instance, where a protocol supports both TLS and SASL security
layers, the specification could prescribe any of the following: layers, the specification could prescribe any of the following:
a) SASL security layer is always applied first to data being sent a) SASL security layer is always applied first to data being sent
and, hence, applied last to received data, and, hence, applied last to received data,
b) SASL security layer is always applied last to data being sent b) SASL security layer is always applied last to data being sent
and, hence, applied first to received data, and, hence, applied first to received data,
c) Layers are applied in the order in which they were installed, c) Layers are applied in the order in which they were installed,
d) Layers are applied in the reverse order in which they were d) Layers are applied in the reverse order in which they were
installed, or installed, or
e) Both TLS and SASL security layers cannot be installed. e) Both TLS and SASL security layers cannot be installed.
8) Indicate whether the protocol supports multiple authentications 8) Indicate whether the protocol supports multiple authentications
(see Section 3.8). If so, the protocol MUST detail the effect a (see Section 3.8). If so, the protocol MUST detail the effect a
failed SASL authentication exchange will have upon previously failed SASL authentication exchange will have upon a previously
established authentication and authorization state. established authentication and authorization state.
Protocol specifications SHOULD avoid stating implementation Protocol specifications SHOULD avoid stating implementation
requirements which would hinder replacement of applicable mechanisms. requirements that would hinder replacement of applicable mechanisms.
In general, protocol specification SHOULD be mechanism neutral. There In general, protocol specifications SHOULD be mechanism neutral.
are a number reasonable exceptions to this recommendation, including: There are a number of reasonable exceptions to this recommendation,
- detailing how credentials (which are mechanism-specific) are including
- detailing how credentials (which are mechanism specific) are
managed in the protocol, managed in the protocol,
- detailing how authentication identities (which are
mechanism-specific) and authorization identities (which are - detailing how authentication identities (which are mechanism
protocol-specific) relate to each other, and specific) and authorization identities (which are protocol
specific) relate to each other, and
- detailing which mechanisms are applicable to the protocol. - detailing which mechanisms are applicable to the protocol.
5. Mechanism Requirements 5. Mechanism Requirements
SASL mechanism specifications MUST supply the following information: SASL mechanism specifications MUST supply the following information:
1) The name of the mechanism (see Section 3.1). This name MUST be 1) The name of the mechanism (see Section 3.1). This name MUST be
registered as discussed in Section 7.1. registered as discussed in Section 7.1.
2) A definition of the server-challenges and client-responses of the 2) A definition of the server-challenges and client-responses of the
authentication exchange, as well as: authentication exchange, as well as the following:
a) An indication whether mechanism is client-first, variable, or a) An indication of whether the mechanism is client-first,
server-first. If a SASL mechanism is defined as client-first variable, or server-first. If a SASL mechanism is defined as
and the client does not send an initial response in the client-first and the client does not send an initial response
authentication request, then the first server challenge MUST be in the authentication request, then the first server challenge
empty (the EXTERNAL mechanism is an example of this case). If a MUST be empty (the EXTERNAL mechanism is an example of this
SASL mechanism is defined as variable, then the specification case). If a SASL mechanism is defined as variable, then the
needs to state how the server behaves when the initial client specification needs to state how the server behaves when the
response in the authentication request is omitted (the initial client response in the authentication request is
DIGEST-MD5 mechanism [DIGEST-MD5] is an example of this case). omitted (the DIGEST-MD5 mechanism [DIGEST-MD5] is an example of
If a SASL mechanism is defined as server-first then the client this case). If a SASL mechanism is defined as server-first,
MUST NOT send an initial client response in the authentication then the client MUST NOT send an initial client response in the
request (the CRAM-MD5 mechanism [CRAM-MD5] is an example of this authentication request (the CRAM-MD5 mechanism [CRAM-MD5] is an
case). example of this case).
b) An indication whether the server is expected to provide b) An indication of whether the server is expected to provide
additional data when indicating a successful outcome. If so, if additional data when indicating a successful outcome. If so,
the server sends the additional data as a challenge, the if the server sends the additional data as a challenge, the
specification MUST indicate the response to this challenge is an specification MUST indicate that the response to this challenge
empty response. is an empty response.
SASL mechanisms SHOULD be designed to minimize the number of SASL mechanisms SHOULD be designed to minimize the number of
challenges and responses necessary to complete the exchange. challenges and responses necessary to complete the exchange.
3) An indication of whether the mechanism is capable of transferring 3) An indication of whether the mechanism is capable of transferring
authorization identity strings (see Section 3.4.1). While some authorization identity strings (see Section 3.4.1). While some
legacy mechanisms are incapable of transmitting an authorization legacy mechanisms are incapable of transmitting an authorization
identity (which means that for these mechanisms the authorization identity (which means that for these mechanisms, the authorization
identity is always the empty string), newly defined mechanisms identity is always the empty string), newly defined mechanisms
SHOULD be capable of transferring authorization identity strings. SHOULD be capable of transferring authorization identity strings.
The mechanism SHOULD NOT be capable of transferring both no The mechanism SHOULD NOT be capable of transferring both no
authorization identity string and an empty authorization identity. authorization identity string and an empty authorization identity.
Mechanisms which are capable of transferring an authorization Mechanisms that are capable of transferring an authorization
identity string MUST be capable of transferring arbitrary non-empty identity string MUST be capable of transferring arbitrary non-
sequences of Unicode characters, excluding those which contain the empty sequences of Unicode characters, excluding those that
NUL (U+0000) character. Mechanisms SHOULD use the UTF-8 [RFC3629] contain the NUL (U+0000) character. Mechanisms SHOULD use the
transformation format. The specification MUST detail how any UTF-8 [RFC3629] transformation format. The specification MUST
Unicode code points special to the mechanism which might appear in detail how any Unicode code points special to the mechanism that
the authorization identity string are escaped to avoid ambiguity might appear in the authorization identity string are escaped to
during decoding of the authorization identity string. Typically, avoid ambiguity during decoding of the authorization identity
mechanisms which have special characters require these special string. Typically, mechanisms that have special characters
characters to be escaped or encoded in the character string (after require these special characters to be escaped or encoded in the
encoding it a particular Unicode transformation format) using a character string (after encoding it in a particular Unicode
data encoding scheme such as Base64 [RFC3548]. transformation format) using a data encoding scheme such as Base64
[RFC3548].
4) The specification MUST detail whether or not the mechanism offers a 4) The specification MUST detail whether the mechanism offers a
security layer. If the mechanism does, the specification MUST security layer. If the mechanism does, the specification MUST
detail the security and other services offered in the layer as well detail the security and other services offered in the layer as
as how these services are to be implemented. well as how these services are to be implemented.
5) If the underlying cryptographic technology used by a mechanism 5) If the underlying cryptographic technology used by a mechanism
supports data integrity, then the mechanism specification MUST supports data integrity, then the mechanism specification MUST
integrity protect the transmission of an authorization identity and integrity protect the transmission of an authorization identity
the negotiation of the security layer. and the negotiation of the security layer.
SASL mechanisms SHOULD be protocol neutral. SASL mechanisms SHOULD be protocol neutral.
SASL mechanisms SHOULD reuse existing credential and identity forms, SASL mechanisms SHOULD reuse existing credential and identity forms,
as well as associated syntaxes and semantics. as well as associated syntaxes and semantics.
SASL mechanisms SHOULD use UTF-8 transformation format [RFC3629] for SASL mechanisms SHOULD use the UTF-8 transformation format [RFC3629]
encoding Unicode [Unicode] code points for transfer. for encoding Unicode [Unicode] code points for transfer.
In order to avoid interoperability problems due to differing In order to avoid interoperability problems due to differing
normalizations, when a mechanism calls for character data (other than normalizations, when a mechanism calls for character data (other than
the authorization identity string) to be used as input to a the authorization identity string) to be used as input to a
cryptographic and/or comparison function, the specification MUST cryptographic and/or comparison function, the specification MUST
detail precisely how and where (client or server) the character data detail precisely how and where (client or server) the character data
is to be prepared, including all normalizations, for input into the is to be prepared, including all normalizations, for input into the
function to ensure proper operation. function to ensure proper operation.
For simple user names and/or passwords in authentication credentials, For simple user names and/or passwords in authentication credentials,
SASLprep [RFC4013] (a profile of the StringPrep [RFC3454] preparation SASLprep [RFC4013] (a profile of the StringPrep [RFC3454] preparation
algorithm), SHOULD be specified as the preparation algorithm. algorithm), SHOULD be specified as the preparation algorithm.
The mechanism SHOULD NOT use the authorization identity string in The mechanism SHOULD NOT use the authorization identity string in
generation of any long-term cryptographic keys or hashes as there is generation of any long-term cryptographic keys or hashes as there is
no requirement that the authorization identity string be canonical. no requirement that the authorization identity string be canonical.
Long-term, here, means a term longer than the duration of the Long-term, here, means a term longer than the duration of the
authentication exchange in which they were generated in. That is, as authentication exchange in which they were generated. That is, as
different clients (of the same or different protocol) may provide different clients (of the same or different protocol) may provide
different authorization identity strings which are semantically different authorization identity strings that are semantically
equivalent, use of authorization identity strings in generation of equivalent, use of authorization identity strings in generation of
cryptographic keys and hashes will likely lead to interoperability and cryptographic keys and hashes will likely lead to interoperability
other problems. and other problems.
6. Security Considerations 6. Security Considerations
Security issues are discussed throughout this memo. Security issues are discussed throughout this memo.
Many existing SASL mechanisms do not provide adequate protection Many existing SASL mechanisms do not provide adequate protection
against passive attacks, let alone active attacks, in the against passive attacks, let alone active attacks, in the
authentication exchange. Many existing SASL mechanisms do not offer authentication exchange. Many existing SASL mechanisms do not offer
security layers. It is hoped that future SASL mechanisms will provide security layers. It is hoped that future SASL mechanisms will
strong protection against passive and active attacks in the provide strong protection against passive and active attacks in the
authentication exchange, as well as security layers with strong basic authentication exchange, as well as security layers with strong basic
data security features (e.g., data integrity and data confidentiality) data security features (e.g., data integrity and data
services. It is also hoped that future mechanisms will provide more confidentiality) services. It is also hoped that future mechanisms
advanced data security services like re-keying (see Section 6.3). will provide more advanced data security services like re-keying (see
Section 6.3).
Regardless, the SASL framework is suspectable to downgrade attacks. Regardless, the SASL framework is susceptible to downgrade attacks.
Section 6.1.2 offers a variety of approaches for preventing or Section 6.1.2 offers a variety of approaches for preventing or
detecting these attacks. In some cases, it is appropriate to use data detecting these attacks. In some cases, it is appropriate to use
integrity protective services external to SASL (e.g., TLS [TLS]) to data integrity protective services external to SASL (e.g., TLS) to
protect against downgrade attacks in SASL. Use of external protective protect against downgrade attacks in SASL. Use of external
security services is also important when the mechanisms available do protective security services is also important when the mechanisms
not themselves offer adequate integrity and/or confidentiality available do not themselves offer adequate integrity and/or
protection of the authentication exchange and/or protocol data. confidentiality protection of the authentication exchange and/or
protocol data.
6.1. Active Attacks 6.1. Active Attacks
6.1.1. Hijack Attacks 6.1.1. Hijack Attacks
When the client selects a SASL security layer with at least integrity When the client selects a SASL security layer with at least integrity
protection, this protect serves as a counter-measure against an active protection, this protection serves as a counter-measure against an
attacker hijacking the connection and modifying protocol data sent active attacker hijacking the connection and modifying protocol data
after establishment of the security layer. Implementations should sent after establishment of the security layer. Implementations
close the connection when the security services in an SASL security SHOULD close the connection when the security services in a SASL
layer report protocol data report lack of data integrity. security layer report protocol data report lack of data integrity.
6.1.2. Downgrade Attacks 6.1.2. Downgrade Attacks
It is important that any security-sensitive protocol negotiations be It is important that any security-sensitive protocol negotiations be
performed after installation of a security layer with data integrity performed after installation of a security layer with data integrity
protection. Protocols should be designed such that negotiations protection. Protocols should be designed such that negotiations
performed prior to this installation should be revalidated after performed prior to this installation should be revalidated after
installation is complete. Negotiation of the SASL mechanism is installation is complete. Negotiation of the SASL mechanism is
security-sensitive. security sensitive.
When a client negotiates the authentication mechanism with the server When a client negotiates the authentication mechanism with the server
and/or other security features, it is possible for an active attacker and/or other security features, it is possible for an active attacker
to cause a party to use the least secure security services available. to cause a party to use the least secure security services available.
For instance, an attacker can modify the server-advertised mechanism For instance, an attacker can modify the server-advertised mechanism
list or can modify client-advertised security feature list within a list or can modify the client-advertised security feature list within
mechanism response. To protect against this sort of attack, a mechanism response. To protect against this sort of attack,
implementations should not advertise mechanisms and/or features which implementations SHOULD NOT advertise mechanisms and/or features that
cannot meet their minimum security requirements, should not enter into cannot meet their minimum security requirements, SHOULD NOT enter
or continue authentication exchanges which cannot meet their minimum into or continue authentication exchanges that cannot meet their
security requirements, and should verify that completed authentication minimum security requirements, and SHOULD verify that completed
exchanges result in security services that meet their minimum security authentication exchanges result in security services that meet their
requirements. Note that each endpoint needs to independently verify minimum security requirements. Note that each endpoint needs to
that its security requirements are met. independently verify that its security requirements are met.
In order to detect downgrade attacks to the least (or less) secure In order to detect downgrade attacks to the least (or less) secure
mechanism supported, the client may discover the SASL mechanisms the mechanism supported, the client can discover the SASL mechanisms that
server makes available both before the SASL authentication exchange the server makes available both before the SASL authentication
and after the negotiated SASL security layer (with at least data exchange and after the negotiated SASL security layer (with at least
integrity protection) has been installed through the protocol's data integrity protection) has been installed through the protocol's
mechanism discovery facility. If the client finds that the integrity mechanism discovery facility. If the client finds that the
protected list (the list obtained after the security layer was integrity-protected list (the list obtained after the security layer
installed) contains a stronger mechanism than those in the previously was installed) contains a stronger mechanism than those in the
obtained list, the client should assume the previously obtained list previously obtained list, the client should assume that the
was modified by an attacker and should close the underlying transport previously obtained list was modified by an attacker and SHOULD close
connection. the underlying transport connection.
The client's initiation of the SASL exchange, including the selection 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 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 active attacker. It is important for any new SASL mechanisms to be
designed such that an active attacker cannot obtain an authentication designed such that an active attacker cannot obtain an authentication
with weaker security properties by modifying the SASL mechanism name with weaker security properties by modifying the SASL mechanism name
and/or the challenges and responses. and/or the challenges and responses.
Multi-level negotiation of security features is prone to downgrade Multi-level negotiation of security features is prone to downgrade
attack. Protocol designers should avoid offering higher level attack. Protocol designers should avoid offering higher-level
negotiation of security features in protocols (e.g., above SASL negotiation of security features in protocols (e.g., above SASL
mechanism negotiation) and mechanism designers should avoid lower mechanism negotiation) and mechanism designers should avoid lower-
level negotiation of security features in mechanisms (e.g., below SASL level negotiation of security features in mechanisms (e.g., below
mechanism negotiation). SASL mechanism negotiation).
6.1.3. Replay Attacks 6.1.3. Replay Attacks
Some mechanisms may be subject to replay attacks unless protected by Some mechanisms may be subject to replay attacks unless protected by
external data security services (e.g., TLS). external data security services (e.g., TLS).
6.1.4. Truncation Attacks 6.1.4. Truncation Attacks
Most existing SASL security layers do not themselves offer protection Most existing SASL security layers do not themselves offer protection
against truncation attack. In a truncation attack, the active against truncation attack. In a truncation attack, the active
attacker causes the protocol session to be closed, causing a attacker causes the protocol session to be closed, causing a
truncation of the possibly integrity protected data stream that leads truncation of the possibly integrity-protected data stream that leads
to behavior of one or both the protocol peers that inappropriately to behavior of one or both the protocol peers that inappropriately
benefits the attacker. Truncation attacks are fairly easy to defend benefits the attacker. Truncation attacks are fairly easy to defend
against in connection-oriented application-level protocols. A against in connection-oriented application-level protocols. A
protocol can defend against these attacks by ensuring that each protocol can defend against these attacks by ensuring that each
information exchange has a clear final result and that each protocol information exchange has a clear final result and that each protocol
session has a graceful closure mechanism, and that these are integrity session has a graceful closure mechanism, and that these are
protected. integrity protected.
6.1.5. Other Active Attacks 6.1.5. Other Active Attacks
When use of a security layer is negotiated by the authentication When use of a security layer is negotiated by the authentication
protocol exchange, the receiver should handle gracefully any protected protocol exchange, the receiver SHOULD handle gracefully any
data buffer larger than the defined/negotiated maximal size. In protected data buffer larger than the defined/negotiated maximal
particular, it must not blindly allocate the amount of memory size. In particular, it MUST NOT blindly allocate the amount of
specified in the buffer size field, as this might cause the "out of memory specified in the buffer size field, as this might cause the
memory" condition. If the receiver detects a large block, it should "out of memory" condition. If the receiver detects a large block, it
close the connection. SHOULD close the connection.
6.2. Passive Attacks 6.2. Passive Attacks
Many mechanisms are subject to various passive attacks, including Many mechanisms are subject to various passive attacks, including
simple eavesdropping of unprotected credential information as well as simple eavesdropping of unprotected credential information as well as
online and offline dictionary attacks of protected credential online and offline dictionary attacks of protected credential
information. information.
6.3. Re-keying 6.3. Re-keying
The secure or administratively permitted lifetimes of SASL mechanisms' The secure or administratively permitted lifetimes of SASL
security layers are finite. Cryptographic keys weaken as they are mechanisms' security layers are finite. Cryptographic keys weaken as
used and as time passes; the more time and/or cipher-text that a they are used and as time passes; the more time and/or cipher-text
cryptanalyst has after the first use of the a key, the easier it is that a cryptanalyst has after the first use of the a key, the easier
for the cryptanalyst to mount attacks on the key. it is for the cryptanalyst to mount attacks on the key.
Administrative limits on a security layer's lifetime may take the form Administrative limits on a security layer's lifetime may take the
of time limits expressed in X.509 certificates, Kerberos V tickets, or form of time limits expressed in X.509 certificates, in Kerberos V
in directories, and are often desired. In practice one likely effect tickets, or in directories, and are often desired. In practice, one
of administrative lifetime limits is that applications may find that likely effect of administrative lifetime limits is that applications
security layers stop working in the middle of application protocol may find that security layers stop working in the middle of
operation, such as, perhaps, during large data transfers. As the application protocol operation, such as, perhaps, during large data
result of this the connection will be closed (see Section 3.7), which transfers. As the result of this, the connection will be closed (see
will result in unpleasant user experience. Section 3.7), which will result in an unpleasant user experience.
Re-keying (key renegotiation process) is a way of addressing the Re-keying (key renegotiation process) is a way of addressing the
weakening of cryptographic keys. SASL framework does not itself weakening of cryptographic keys. The SASL framework does not itself
provide for re-keying, SASL mechanisms may. Designers of future SASL provide for re-keying; SASL mechanisms may. Designers of future SASL
mechanisms should consider providing re-keying services. mechanisms should consider providing re-keying services.
Applications that wish to re-key SASL security layers where the Implementations that wish to re-key SASL security layers where the
mechanism does not provide for re-keying should reauthenticate the mechanism does not provide for re-keying SHOULD reauthenticate the
same IDs and replace the expired or soon-to-expire security layers. same IDs and replace the expired or soon-to-expire security layers.
This approach requires support for reauthentication in the application This approach requires support for reauthentication in the
protocols (see Section 3.8). application protocols (see Section 3.8).
6.4. Other Considerations 6.4. Other Considerations
Protocol designers and implementors should understand the security Protocol designers and implementors should understand the security
considerations of mechanisms so they may select mechanisms which are considerations of mechanisms so they may select mechanisms that are
applicable to their needs. applicable to their needs.
Distributed server implementations need to be careful in how they Distributed server implementations need to be careful in how they
trust other parties. In particular, authentication secrets should trust other parties. In particular, authentication secrets should
only be disclosed to other parties that are trusted to manage and use only be disclosed to other parties that are trusted to manage and use
those secrets in manner acceptable to disclosing party. Applications those secrets in a manner acceptable to the disclosing party.
using SASL assume that SASL security layers providing data Applications using SASL assume that SASL security layers providing
confidentiality are secure even when an attacker chooses the text to data confidentiality are secure even when an attacker chooses the
be protected by the security layer. Similarly applications assume text to be protected by the security layer. Similarly, applications
that the SASL security layer is secure even if the attacker can assume that the SASL security layer is secure even if the attacker
manipulate the cipher-text output of the security layer. New SASL can manipulate the cipher-text output of the security layer. New
mechanisms are expected to meet these assumptions. SASL mechanisms are expected to meet these assumptions.
Unicode security considerations [UTR36] apply to authorization Unicode security considerations [UTR36] apply to authorization
identity strings, and well as UTF-8 [RFC3629] security considerations identity strings, as well as UTF-8 [RFC3629] security considerations
where UTF-8 is used. SASLprep [RFC4013] and StringPrep [RFC3454] where UTF-8 is used. SASLprep [RFC4013] and StringPrep [RFC3454]
security considerations also apply where used. security considerations also apply where used.
7. IANA Considerations 7. IANA Considerations
7.1. SASL Mechanism Registry 7.1. SASL Mechanism Registry
SASL mechanism registry is maintained by IANA. The registry is The SASL mechanism registry is maintained by IANA. The registry is
currently available at currently available at <http://www.iana.org/assignments/sasl-
<http://www.iana.org/assignments/sasl-mechanisms>. mechanisms>.
The purpose of this registry is not only to ensure uniqueness of The purpose of this registry is not only to ensure uniqueness of
values used to name SASL mechanisms, but to provide a definitive values used to name SASL mechanisms, but also to provide a definitive
references to technical specifications detailing each SASL mechanism reference to technical specifications detailing each SASL mechanism
available for use on the Internet. available for use on the Internet.
There is no naming convention for SASL mechanisms; any name that There is no naming convention for SASL mechanisms; any name that
conforms to the syntax of a SASL mechanism name can be registered. 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 The procedure detailed in Section 7.1.1 is to be used for
of a value naming a specific individual mechanism. registration of a value naming a specific individual mechanism.
The procedure detailed in Section 7.1.2 is to be used for registration The procedure detailed in Section 7.1.2 is to be used for
of a value naming a family of related mechanisms. registration of a value naming a family of related mechanisms.
Comments may be included in the registry as discussed in Section 7.1.3 Comments may be included in the registry as discussed in Section
and may be changed as discussed in Section 7.1.4. 7.1.3 and may be changed as discussed in Section 7.1.4.
It is requested that the SASL mechanism registry be updated to reflect The SASL mechanism registry has been updated to reflect that this
that this document provides the definitive technical specification for document provides the definitive technical specification for SASL and
SASL and that this section provides the registration procedures for that this section provides the registration procedures for this
this registry. registry.
7.1.1. Mechanism Name Registration Procedure 7.1.1. Mechanism Name Registration Procedure
IANA will register new SASL mechanism names on a First Come First 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 Served basis, as defined in BCP 26 [RFC2434]. IANA has the right to
reject obviously bogus registration requests, but will perform no reject obviously bogus registration requests, but will perform no
review of claims made in the registration form. review of claims made in the registration form.
Registration of a SASL mechanism is requested by filling in the Registration of a SASL mechanism is requested by filling in the
following template: following template:
skipping to change at page 23, line 11 skipping to change at page 23, line 25
Subject: Registration of SASL mechanism X Subject: Registration of SASL mechanism X
SASL mechanism name (or prefix for the family): SASL mechanism name (or prefix for the family):
Security considerations: Security considerations:
Published specification (recommended): Published specification (recommended):
Person & email address to contact for further information: Person & email address to contact for further information:
Intended usage: (One of COMMON, LIMITED USE or OBSOLETE) Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
Owner/Change controller: Owner/Change controller:
Note: (Any other information that the author deems relevant may be Note: (Any other information that the author deems relevant may be
added here .) added here .)
and sending it via electronic mail to IANA at <iana@iana.org>. and sending it via electronic mail to IANA at <iana@iana.org>.
While this registration procedures do not require expert review, While this registration procedure does not require expert review,
authors of SASL mechanisms are encouraged to seek community review and authors of SASL mechanisms are encouraged to seek community review
comment whenever that is feasible. Authors may seek community review and comment whenever that is feasible. Authors may seek community
by posting a specification of their proposed mechanism as an review by posting a specification of their proposed mechanism as an
Internet-Draft. SASL mechanisms intended for widespread use should be Internet-Draft. SASL mechanisms intended for widespread use should
standardized through the normal IETF process, when appropriate. be standardized through the normal IETF process, when appropriate.
7.1.2. Family Name Registration Procedure 7.1.2. Family Name Registration Procedure
As noted above, there is no general naming convention for SASL As noted above, there is no general naming convention for SASL
mechanisms. However, specifications may reserve a portion of the SASL mechanisms. However, specifications may reserve a portion of the
mechanism namespace for a set of related SASL mechanisms, a "family" SASL mechanism namespace for a set of related SASL mechanisms, a
of SASL mechanisms. Each family of SASL mechanisms is identified by a "family" of SASL mechanisms. Each family of SASL mechanisms is
unique prefix, such as X-. Registration of new SASL mechanism family identified by a unique prefix, such as X-. Registration of new SASL
names requires Expert Review as defined in BCP 26 [RFC2434]. mechanism family names requires expert review as defined in BCP 26
[RFC2434].
Registration of a SASL family name is requested by filling in the Registration of a SASL family name is requested by filling in the
following template: following template:
Subject: Registration of SASL mechanism family X Subject: Registration of SASL mechanism family X
SASL family name (or prefix for the family): SASL family name (or prefix for the family):
Security considerations: Security considerations:
Published specification (recommended): Published specification (recommended):
Person & email address to contact for further information: Person & email address to contact for further information:
Intended usage: (One of COMMON, LIMITED USE or OBSOLETE) Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
Owner/Change controller: Owner/Change controller:
Note: (Any other information that the author deems relevant may be Note: (Any other information that the author deems relevant may be
added here .) added here .)
and sending it via electronic mail to the IETF SASL mailing list at and sending it via electronic mail to the IETF SASL mailing list at
<ietf-sasl@imc.org> with copy to IANA at <iana@iana.org>. After <ietf-sasl@imc.org> and carbon copying IANA at <iana@iana.org>.
allowing two weeks for community input on the IETF SASL mailing list, After allowing two weeks for community input on the IETF SASL mailing
the expert will determine the appropriateness of the registration list, the expert will determine the appropriateness of the
request and either approve or disappove the request with notice to registration request and either approve or disapprove the request
requestor, the mailing list, and IANA. with notice to the requestor, the mailing list, and IANA.
The review should focus on the appropriateness of the requested family The review should focus on the appropriateness of the requested
name for the proposed use and the appropriateness of the proposed family name for the proposed use and the appropriateness of the
naming and registration plan for existing and future mechanism names proposed naming and registration plan for existing and future
in the family. The scope of this request review may entail mechanism names in the family. The scope of this request review may
consideration of relevant aspects of any provided technical entail consideration of relevant aspects of any provided technical
specification, such as their IANA Considerations section. However specification, such as their IANA Considerations section. However,
this review is narrowly focused on the appropriateness of the this review is narrowly focused on the appropriateness of the
requested registration and not on the overall soundness of any requested registration and not on the overall soundness of any
provided technical specification. provided technical specification.
Authors are encouraged to community review by posting the technical Authors are encouraged to pursue community review by posting the
specification as an Internet-Draft and soliciting comment by posting technical specification as an Internet-Draft and soliciting comment
to appropriate IETF mailing lists. by posting to appropriate IETF mailing lists.
7.1.3. Comments on SASL Mechanism Registrations 7.1.3. Comments on SASL Mechanism Registrations
Comments on a registered SASL mechanism/family should first be sent to Comments on a registered SASL mechanism/family should first be sent
the "owner" of the mechanism/family and/or to the <ietf-sasl@imc.org> to the "owner" of the mechanism/family and/or to the <ietf-
mailing list. sasl@imc.org> mailing list.
Submitters of comments may, after a reasonable attempt to contact the Submitters of comments may, after a reasonable attempt to contact the
owner, request IANA to attach their comment to the SASL mechanism owner, request IANA to attach their comment to the SASL mechanism
registration itself by sending mail to <iana@iana.org>. At IANA's registration itself by sending mail to <iana@iana.org>. At IANA's
sole discretion, IANA may attach the comment to the SASL mechanism's sole discretion, IANA may attach the comment to the SASL mechanism's
registration. registration.
7.1.4. Change Control 7.1.4. Change Control
Once a SASL mechanism registration has been published by IANA, the Once a SASL mechanism registration has been published by IANA, the
author may request a change to its definition. The change request author may request a change to its definition. The change request
follows the same procedure as the registration request. follows the same procedure as the registration request.
The owner of a SASL mechanism may pass responsibility for the SASL The owner of a SASL mechanism may pass responsibility for the SASL
mechanism to another person or agency by informing IANA; this can be mechanism to another person or agency by informing IANA; this can be
done without discussion or review. done without discussion or review.
The IESG may reassign responsibility for a SASL mechanism. The most The IESG may reassign responsibility for a SASL mechanism. The most
common case of this will be to enable changes to be made to mechanisms common case of this will be to enable changes to be made to
where the author of the registration has died, moved out of contact or mechanisms where the author of the registration has died, has moved
is otherwise unable to make changes that are important to the out of contact, or is otherwise unable to make changes that are
community. important to the community.
SASL mechanism registrations may not be deleted; mechanisms which are SASL mechanism registrations may not be deleted; mechanisms that are
no longer believed appropriate for use can be declared OBSOLETE by a no longer believed appropriate for use can be declared OBSOLETE by a
change to their "intended usage" field; such SASL mechanisms will be change to their "intended usage" field; such SASL mechanisms will be
clearly marked in the lists published by IANA. clearly marked in the lists published by IANA.
The IESG is considered to be the owner of all SASL mechanisms which The IESG is considered to be the owner of all SASL mechanisms that
are on the IETF standards track. are on the IETF standards track.
7.2. Registration Changes 7.2. Registration Changes
It is requested that IANA update the SASL mechanisms registry as The IANA has updated the SASL mechanisms registry as follows:
follows:
1) Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism 1) Changed the "Intended usage" of the KERBEROS_V4 and SKEY mechanism
registrations to OBSOLETE. registrations to OBSOLETE.
2) Change the "Published specification" of the EXTERNAL mechanism to 2) Changed the "Published specification" of the EXTERNAL mechanism to
this document as indicated below: this document as indicated below:
Subject: Updated Registration of SASL mechanism EXTERNAL Subject: Updated Registration of SASL mechanism EXTERNAL
Family of SASL mechanisms: NO Family of SASL mechanisms: NO
SASL mechanism name: EXTERNAL SASL mechanism name: EXTERNAL
Security considerations: See A.3 of RFC XXXX Security considerations: See A.3 of RFC 4422
Published specification (optional, recommended): RFC XXXX Published specification (optional, recommended): RFC 4422
Person & email address to contact for further information: Person & email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com> Alexey Melnikov <Alexey.Melnikov@isode.com>
Intended usage: COMMON Intended usage: COMMON
Owner/Change controller: IESG <iesg@ietf.org> Owner/Change controller: IESG <iesg@ietf.org>
Note: Updates existing entry for EXTERNAL Note: Updates existing entry for EXTERNAL
8. References 8. References
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn where
possible.]]
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2244] Newman, C. and J. G. Myers, "ACAP -- Application
IANA Considerations Section in RFCs", BCP 26 (also RFC Configuration Access Protocol", RFC 2244, November
2434), October 1998. 1997.
[RFC2743] Linn, J., "Generic Security Service [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
Application Program Interface, Version 2, Update 1", RFC an IANA Considerations Section in RFCs", BCP 26, RFC
2743, January 2000. 2434, October 1998.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ('stringprep')", RFC 3454, Internationalized Strings ("stringprep")", RFC 3454,
December 2002. December 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629 (also STD 63), November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
Names and Passwords", RFC 4013, February 2005. Names and Passwords", RFC 4013, February 2005.
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 4234, October 2005.
[ASCII] Coded Character Set--7-bit American Standard Code for [ASCII] Coded Character Set--7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986. Information Interchange, ANSI X3.4-1986.
[Unicode] The Unicode Consortium, "The Unicode Standard, Version [Unicode] The Unicode Consortium, "The Unicode Standard, Version
3.2.0" is defined by "The Unicode Standard, Version 3.0" 3.2.0" is defined by "The Unicode Standard, Version
(Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
as amended by the "Unicode Standard Annex #27: Unicode 61633-5), as amended by the "Unicode Standard Annex
3.1" (http://www.unicode.org/reports/tr27/) and by the #27: Unicode 3.1"
(http://www.unicode.org/reports/tr27/) and by the
"Unicode Standard Annex #28: Unicode 3.2" "Unicode Standard Annex #28: Unicode 3.2"
(http://www.unicode.org/reports/tr28/). (http://www.unicode.org/reports/tr28/).
[CharModel] Whistler, K. and M. Davis, "Unicode Technical Report [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
#17, Character Encoding Model", UTR17, #17, Character Encoding Model", UTR17,
<http://www.unicode.org/unicode/reports/tr17/>, August <http://www.unicode.org/unicode/reports/tr17/>, August
2000. 2000.
[Glossary] The Unicode Consortium, "Unicode Glossary", [Glossary] The Unicode Consortium, "Unicode Glossary",
<http://www.unicode.org/glossary/>. <http://www.unicode.org/glossary/>.
8.2. Informative References 8.2. Informative References
[RFC2246] Dierks, T. and, C. Allen, "The TLS Protocol Version [RFC3206] Gellens, R., "The SYS and AUTH POP Response Codes", RFC
1.0", RFC 2246, January 1999. 3206, February 2002.
[RFC2401] Kent, S., and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003. Encodings", RFC 3548, July 2003.
[TLS] Dierks, T. and, E. Rescorla, "The TLS Protocol Version [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in Internet Protocol", RFC 4301, December 2005.
progress.
[SASL-GSSAPI] Melnikov, A. (Editor), "SASL GSSAPI mechanisms",
draft-ietf-sasl-gssapi-XX.txt, a work in progress.
[UTR36] Davis, M., "(Draft) Unicode Technical
Report #36, Character Encoding Model", UTR17,
<http://www.unicode.org/unicode/reports/tr36/>, February
2005.
[CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism",
draft-ietf-sasl-crammd5-xx.txt, a work in progress.
[DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest
Authentication as a SASL Mechanism",
draft-ietf-sasl-rfc2831bis-xx.txt, a work in progress.
9. Editors' Address [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.1", RFC 4346, April
2006.
Alexey Melnikov [SASL-GSSAPI] Melnikov, A. (Editor), "The Kerberos V5 ("GSSAPI") SASL
Isode Limited Mechanism", Work in Progress, May 2006.
5 Castle Business Village
36 Station Road
Hampton, Middlesex,
TW12 2BX, United Kingdom
Email: Alexey.Melnikov@isode.com [UTR36] Davis, M., "(Draft) Unicode Technical Report #36,
URI: http://www.melnikov.ca/ Character Encoding Model", UTR17,
<http://www.unicode.org/unicode/reports/tr36/>,
February 2005.
Kurt D. Zeilenga [CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", Work in
OpenLDAP Foundation Progress.
Email: Kurt@OpenLDAP.org [DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest
Authentication as a SASL Mechanism", Work in Progress,
March 2006.
10. Acknowledgments 9. Acknowledgements
This document is a revision of RFC 2222 written by John Myers. This document is a revision of RFC 2222 written by John Myers.
This revision is a product of the IETF Simple Authentication and This revision is a product of the IETF Simple Authentication and
Security Layer (SASL) Working Group. Security Layer (SASL) Working Group.
The following individuals contributed significantly to this revision: The following individuals contributed significantly to this revision:
Abhijit Menon-Sen, Hallvard B Furuseth, Jeffrey Hutzelman, John Myers, Abhijit Menon-Sen, Hallvard Furuseth, Jeffrey Hutzelman, John Myers,
Luke Howard, Magnus Nystrom, Nicolas Williams, Peter Saint-Andre, RL Luke Howard, Magnus Nystrom, Nicolas Williams, Peter Saint-Andre, RL
'Bob' Morgan, Rob Siemborski, Sam Hartman, Simon Josefsson, Tim Alsop, 'Bob' Morgan, Rob Siemborski, Sam Hartman, Simon Josefsson, Tim
and Tony Hansen. Alsop, and Tony Hansen.
Appendix A. The SASL EXTERNAL Mechanism Appendix A. The SASL EXTERNAL Mechanism
This appendix is normative. This appendix is normative.
The EXTERNAL mechanism allows a client to request the server to use The EXTERNAL mechanism allows a client to request the server to use
credentials established by means external to the mechanism to credentials established by means external to the mechanism to
authenticate the client. The external means may be, for instance, IP authenticate the client. The external means may be, for instance, IP
Security [RFC2401] or TLS [RFC2246] services. In absence of some Security [RFC4301] or TLS [RFC4346] services. In absence of some a
apriori agreement between the client and the server, the client cannot priori agreement between the client and the server, the client cannot
make any assumption as to what external means the server has used to make any assumption as to what external means the server has used to
obtain the client's credentials, nor make an assumption as to the form obtain the client's credentials, nor make an assumption as to the
of credentials. For example, the client cannot assume the server will form of credentials. For example, the client cannot assume that the
use the credentials the client has established via TLS. server will use the credentials the client has established via TLS.
A.1. EXTERNAL Technical Specification A.1. EXTERNAL Technical Specification
The name of this mechanism is "EXTERNAL". The name of this mechanism is "EXTERNAL".
The mechanism does not provide a security layer. The mechanism does not provide a security layer.
The mechanism is capable of transferring an authorization identity The mechanism is capable of transferring an authorization identity
string. If empty, the client is requesting to act as the identity the string. If empty, the client is requesting to act as the identity
server has associated with the client's credentials. If non-empty, the server has associated with the client's credentials. If non-
the client is requesting to act as the identity represented by the empty, the client is requesting to act as the identity represented by
string. the string.
The client is expected to send data first in the authentication The client is expected to send data first in the authentication
exchange. Where the client does not provide an initial response data exchange. Where the client does not provide an initial response data
in its request to initiate the authentication exchange, the server is in its request to initiate the authentication exchange, the server is
to respond to the request with an empty initial challenge and then the to respond to the request with an empty initial challenge and then
client is to provide its initial response. the client is to provide its initial response.
The client sends the initial response containing the UTF-8 [RFC3629] The client sends the initial response containing the UTF-8 [RFC3629]
encoding of the requested authorization identity string. This encoding of the requested authorization identity string. This
response is non-empty when the client is requesting to act as the response is non-empty when the client is requesting to act as the
identity represented by the (non-empty) string. This response is identity represented by the (non-empty) string. This response is
empty when the client is requesting to act as the identity the server empty when the client is requesting to act as the identity the server
associated with its authentication credentials. associated with its authentication credentials.
The syntax of the initial response is specified as a value of the The syntax of the initial response is specified as a value of the
<extern-initial-resp> production detailed below using the Augmented <extern-initial-resp> production detailed below using the Augmented
skipping to change at page 29, line 13 skipping to change at page 30, line 4
associated with its authentication credentials. associated with its authentication credentials.
The syntax of the initial response is specified as a value of the The syntax of the initial response is specified as a value of the
<extern-initial-resp> production detailed below using the Augmented <extern-initial-resp> production detailed below using the Augmented
Backus-Naur Form (ABNF) [RFC4234] notation. Backus-Naur Form (ABNF) [RFC4234] notation.
external-initial-resp = authz-id-string external-initial-resp = authz-id-string
authz-id-string = *( UTF8-char-no-nul ) authz-id-string = *( UTF8-char-no-nul )
UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4 UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4
UTF8-1-no-nul = %x01-7F UTF8-1-no-nul = %x01-7F
where the <UTF8-2>, <UTF8-3>, and <UTF8-4> productions are as defined where the <UTF8-2>, <UTF8-3>, and <UTF8-4> productions are as defined
in [RFC3629]. in [RFC3629].
There are no additional challenges and responses. There are no additional challenges and responses.
Hence, the server is to return the outcome of the authentication Hence, the server is to return the outcome of the authentication
exchange. exchange.
The exchange fails if The exchange fails if
- the client has not established its credentials via external means, - the client has not established its credentials via external means,
- the client's credentials are inadequate, - the client's credentials are inadequate,
- The client provided an empty authorization identity string and the
server is unwilling or unable to associate an authorization identity - the client provided an empty authorization identity string and the
with the client's credentials, server is unwilling or unable to associate an authorization
- The client provided a non-empty authorization identity string which identity with the client's credentials,
is invalid per the syntax requirements of the applicable application
protocol specification, - the client provided a non-empty authorization identity string that
- The client provided a non-empty authorization identity string is invalid per the syntax requirements of the applicable
representing an identity which the client is not allowed to act as, application protocol specification,
- the client provided a non-empty authorization identity string
representing an identity that the client is not allowed to act as,
or or
- the server is unwilling or unable to provide service to the client - the server is unwilling or unable to provide service to the client
for any other reason. for any other reason.
Otherwise the exchange is successful. When indicating a successful Otherwise the exchange is successful. When indicating a successful
outcome, additional data is not provided. outcome, additional data is not provided.
A.2. SASL EXTERNAL Examples A.2. SASL EXTERNAL Examples
This section provides examples of EXTERNAL authentication exchanges. This section provides examples of EXTERNAL authentication exchanges.
The examples are intended to help the readers under the above text. The examples are intended to help the readers understand the above
The examples are not definitive. The Application Configuration text. The examples are not definitive. The Application
Access Protocol (ACAP) [RFC2244] is used in the examples. Configuration Access Protocol (ACAP) [RFC2244] is used in the
examples.
The first example shows use of EXTERNAL with an empty authorization The first example shows use of EXTERNAL with an empty authorization
identity. In this example, the initial response is not sent in the identity. In this example, the initial response is not sent in the
client's request to initiate authentication exchange. client's request to initiate the authentication exchange.
S: * ACAP (SASL "DIGEST-MD5") S: * ACAP (SASL "DIGEST-MD5")
C: a001 STARTTLS C: a001 STARTTLS
S: a001 OK "Begin TLS negotiation now" S: a001 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer> <TLS negotiation, further commands are under TLS layer>
S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL") S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL")
C: a002 AUTHENTICATE "EXTERNAL" C: a002 AUTHENTICATE "EXTERNAL"
S: + "" S: + ""
C: + "" C: + ""
S: a002 OK "Authenticated" S: a002 OK "Authenticated"
In second example shows use of EXTERNAL with an authorization identity The second example shows use of EXTERNAL with an authorization
of "fred@example.com". In this example, the initial response is sent identity of "fred@example.com". In this example, the initial
with the client's request to initiate the authentication exchange. response is sent with the client's request to initiate the
This saves a round-trip. authentication exchange. This saves a round-trip.
S: * ACAP (SASL "DIGEST-MD5") S: * ACAP (SASL "DIGEST-MD5")
C: a001 STARTTLS C: a001 STARTTLS
S: a001 OK "Begin TLS negotiation now" S: a001 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer> <TLS negotiation, further commands are under TLS layer>
S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL") S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL")
C: a002 AUTHENTICATE "EXTERNAL" {16+} C: a002 AUTHENTICATE "EXTERNAL" {16+}
C: fred@example.com C: fred@example.com
S: a002 NO "Cannot assume requested authorization identity" S: a002 NO "Cannot assume requested authorization identity"
A.3. Security Considerations A.3. Security Considerations
The EXTERNAL mechanism provides no security protection; it is The EXTERNAL mechanism provides no security protection; it is
vulnerable to spoofing by either client or server, active attack, and vulnerable to spoofing by either client or server, active attack, and
eavesdropping. It should only be used when adequate security services eavesdropping. It should only be used when adequate security
have been established. services have been established.
Appendix B. Changes since RFC 2222 Appendix B. Changes since RFC 2222
This appendix is non-normative. This appendix is non-normative.
The material in RFC 2222 was significantly rewritten in the production The material in RFC 2222 was significantly rewritten in the
of this document. production of this document.
RFC 2222, by not stating the authorization identity string was a RFC 2222, by not stating that the authorization identity string was a
string of Unicode characters, let alone character data, implied the string of Unicode characters, let alone character data, implied that
authorization identity string was a string of octets. the authorization identity string was a string of octets.
- The authorization identity string is now defined as a string of - The authorization identity string is now defined as a string of
Unicode characters. The NUL (U+0000) character is prohibited. Unicode characters. The NUL (U+0000) character is prohibited.
While protocol specifications are responsible for defining the While protocol specifications are responsible for defining the
authorization identity form, as well as the Unicode string syntax authorization identity form, as well as the Unicode string syntax
and related semantics, mechanism specifications are responsible for and related semantics, mechanism specifications are responsible
defining how the Unicode string is carried in the authentication for defining how the Unicode string is carried in the
exchange. authentication exchange.
- Deleted "If so, when the client does not send data first, the - Deleted "If so, when the client does not send data first, the
initial challenge MUST be specified as being an empty challenge." initial challenge MUST be specified as being an empty challenge."
The following technical change was made to the EXTERNAL mechanism: The following technical change was made to the EXTERNAL mechanism:
- The authorization identity string is to be UTF-8 encoded. - The authorization identity string is to be UTF-8 encoded.
It is noted that protocol and mechanism specification requirements Note that protocol and mechanism specification requirements have
have been significant tightened. Existing protocol and mechanism been significantly tightened. Existing protocol and mechanism
specifications will need to be updated to meet these requirements. specifications will need to be updated to meet these requirements.
Intellectual Property Rights Editors' Addresses
Alexey Melnikov
Isode Limited
5 Castle Business Village
36 Station Road
Hampton, Middlesex,
TW12 2BX, United Kingdom
EMail: Alexey.Melnikov@isode.com
URI: http://www.melnikov.ca/
Kurt D. Zeilenga
OpenLDAP Foundation
EMail: Kurt@OpenLDAP.org
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be found on the procedures with respect to rights in RFC documents can be
in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this specification such proprietary rights by implementers or users of this
can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Full Copyright Acknowledgement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an Funding for the RFC Editor function is provided by the IETF
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS Administrative Support Activity (IASA).
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 192 change blocks. 
571 lines changed or deleted 601 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/