draft-ietf-sasl-rfc2222bis-09.txt   draft-ietf-sasl-rfc2222bis-10.txt 
Network Working Group A. Melnikov Network Working Group A. Melnikov
Internet Draft Editor Internet Draft Editor
Document: draft-ietf-sasl-rfc2222bis-09.txt October 2004 Document: draft-ietf-sasl-rfc2222bis-10.txt February 2005
Obsoletes: RFC 2222 Expires in six months Obsoletes: RFC 2222 Expires in six months
Simple Authentication and Security Layer (SASL) Simple Authentication and Security Layer (SASL)
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 2, line ? skipping to change at page 2, line ?
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
A revised version of this draft document will be submitted to the RFC A revised version of this draft document will be submitted to the RFC
editor as a Standards Track RFC for the Internet Community. editor as a Standards Track RFC for the Internet Community.
Discussion and suggestions for improvement are requested. Discussion and suggestions for improvement are requested.
Distribution of this draft is unlimited. Distribution of this draft is unlimited.
When published as an RFC this document will obsolete RFC 2222. When published as an RFC this document will obsolete RFC 2222.
Internet DRAFT SASL 25 October 2004 Internet DRAFT SASL 16 February 2005
Abstract Abstract
The Simple Authentication and Security Layer (SASL) is a framework The Simple Authentication and Security Layer (SASL) is a framework
for 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 provides
a structured interface between protocols and mechanisms. The a structured interface between protocols and mechanisms. The
resulting framework allows new protocols to reuse existing mechanisms resulting framework allows new protocols to reuse existing mechanisms
and allows old protocols to make use of new mechanisms. The and allows old protocols to make use of new mechanisms. The
framework also provides a protocol for securing subsequent protocol framework also provides a protocol for securing subsequent protocol
skipping to change at page 2, line ? skipping to change at page 2, line ?
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>.
This document uses terms "integrity protection" and "confidentiality This document uses terms "integrity protection" and "confidentiality
protection". The former refers to a security layer (see Section protection". The former refers to a security layer (see Section
"Introduction" below for the definition) designed to provide "data "Introduction" below for the definition) designed to provide "data
integrity service" as defined in [Sec-Glossary]. Confidentiality integrity service" as defined in [Sec-Glossary]. Confidentiality
protection is a security layer that provides "data confidentiality protection is a security layer that provides "data confidentiality
service" as defined in [Sec-Glossary]. The term "confidentiality service" as defined in [Sec-Glossary]. The term "confidentiality
protection" implies "integrity protection". Security layers may offer protection" implies "integrity protection". Security layers may offer
other kinds of security services. other kinds of security services, for example re-keying, truncation
detection, as well as other services, e.g. compression.
2. Introduction 2. Introduction
The Simple Authentication and Security Layer (SASL) is a framework The Simple Authentication and Security Layer (SASL) is a framework
for 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.
Internet DRAFT SASL 25 October 2004 Internet DRAFT SASL 16 February 2005
exchanges within a data security layer.
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.
The SASL is conceptually a framework which provides a layer between The SASL is conceptually a framework which provides a layer between
protocols and mechanisms, as illustrated in the following diagram. protocols and mechanisms, as illustrated in the following diagram.
SMTP Protocol LDAP Protocol Other Protocols SMTP Protocol LDAP Protocol Other Protocols
skipping to change at page 3, line 52 skipping to change at page 4, line 4
As illustrated above, the SASL framework interfaces with both As illustrated above, the SASL framework interfaces with both
protocols and mechanisms. protocols and mechanisms.
To use SASL, a protocol includes a command for identifying and To use SASL, a protocol includes a command for identifying and
authenticating a user to a server and for optionally negotiating a authenticating a user to a server and for optionally negotiating a
security layer for subsequent protocol interactions. If the use of a security layer for subsequent protocol interactions. If the use of a
security layer is negotiated, that security layer is inserted between security layer is negotiated, that security layer is inserted between
the protocol and the connection. Section 4 ("Protocol profile the protocol and the connection. Section 4 ("Protocol profile
requirements") profiles the requirements that a protocol requirements") profiles the requirements that a protocol
specification must fulfill to make use of SASL. A SASL protocol
profile is a part of the protocol specification that satisfies the
Internet DRAFT SASL 25 October 2004 Internet DRAFT SASL 16 February 2005
specification must fulfill to make use of SASL. A SASL protocol
profile is a part of the protocol specification that satisfies the
requirements of Section 4. requirements of Section 4.
A SASL mechanism is a series of server challenges and client A SASL mechanism is a series of server challenges and client
responses specific to the mechanism. Each SASL mechanism is responses specific to the mechanism. Each SASL mechanism is
identified by a registered name. Section 5 ("Mechanism profile identified by a registered name. Section 5 ("Mechanism profile
guidelines") profiles the requirements that a mechanism specification guidelines") profiles the requirements that a mechanism specification
must fulfill to define a SASL mechanism. must fulfill to define a SASL mechanism.
This document is written to serve several different audiences: This document is written to serve several different audiences:
skipping to change at page 5, line 5 skipping to change at page 5, line 5
security and other considerations. security and other considerations.
2.1. Relationship to other documents 2.1. 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 (Kerberos version 4 mechanism), 7.2 2222 excepting sections 7.1 (Kerberos version 4 mechanism), 7.2
(GSSAPI mechanism), 7.3 (S/Key mechanism). The Kerberos version 4 (GSSAPI mechanism), 7.3 (S/Key mechanism). The Kerberos version 4
(KERBEROS_IV) and S/Key (SKEY) mechanisms are now viewed as obsolete. (KERBEROS_IV) and S/Key (SKEY) mechanisms are now viewed as obsolete.
The GSSAPI mechanism is now separately specified [SASL-GSSAPI]. The GSSAPI mechanism is now separately specified [SASL-GSSAPI].
Internet DRAFT SASL 25 October 2004 Internet DRAFT SASL 16 February 2005
3. Authentication mechanisms 3. Authentication mechanisms
SASL mechanisms are named by strings, from 1 to 20 characters in SASL mechanisms are named by strings, from 1 to 20 characters in
length, consisting of ASCII [ASCII] upper-case letters, digits, length, consisting of ASCII [ASCII] upper-case letters, digits,
hyphens, and/or underscores. Names of SASL mechanisms or families of hyphens, and/or underscores. Names of SASL mechanisms or families of
mechanisms must be registered with the Internet Assigned Numbers mechanisms must be registered with the Internet Assigned Numbers
Authority (IANA) as described in section 8.2. Authority (IANA) as described in section 8.2.
The "sasl-mech" ABNF production below defines the syntax of a SASL The "sasl-mech" ABNF production below defines the syntax of a SASL
skipping to change at page 6, line 5 skipping to change at page 6, line 5
After receiving an authentication command or any client response, a After receiving an authentication command or any client response, a
server mechanism may issue a challenge, indicate failure, or indicate server mechanism may issue a challenge, indicate failure, or indicate
completion. The server mechanism may return additional data with a completion. The server mechanism may return additional data with a
completion indication. The protocol's profile specifies how each of completion indication. The protocol's profile specifies how each of
these is then represented over the connection. these is then represented over the connection.
After receiving a challenge, a client mechanism may issue a response After receiving a challenge, a client mechanism may issue a response
or abort the exchange. The protocol's profile specifies how each of or abort the exchange. The protocol's profile specifies how each of
Internet DRAFT SASL 25 October 2004 Internet DRAFT SASL 16 February 2005
these are then represented over the connection. these are then represented over the connection.
During the authentication exchange, the mechanism performs During the authentication exchange, the mechanism performs
authentication, transmits an authorization identity (sometimes known authentication, transmits an authorization identity (sometimes known
as a username<<>>) from the client to server, and may negotiate the as a username) from the client to server, and may negotiate the use
use of a mechanism-specific security layer. If the use of a security of a mechanism-specific security layer. If the use of a security
layer is agreed upon, then the mechanism must also define or layer is agreed upon, then the mechanism must also define or
negotiate the maximum security layer buffer size that each side is negotiate the maximum security layer buffer size that each side is
able to receive. able to receive.
3.2. Identity Concepts 3.2. Identity Concepts
Conceptually, SASL framework involves two identities: Conceptually, SASL framework involves two identities:
1) an identity associated with the authentication 1) an identity associated with the authentication
credentials (termed the authentication identity), and credentials (termed the authentication identity), and
2) an identity to act as (termed the authorization 2) an identity to act as (termed the authorization
identity). identity).
The client provides its credentials and, optionally, a The client provides its credentials and, optionally, a string
string representing the requested authorization identity representing the requested authorization identity as part of the SASL
as part of the SASL exchange. When this string is omitted or empty, exchange. When this string is omitted or empty, the client is
the client is requesting to act as the identity requesting to act as the identity associated with the credentials
associated with the credentials (e.g., the user is (e.g., the user is requesting to act as the authentication identity).
requesting to act as the authentication identity).
The server is responsible for verifying the client's The server is responsible for verifying the client's credentials and
credentials and verifying that the client is allowed to verifying that the client is allowed to act as the authorization
act as the authorization identity. A SASL exchange identity. A SASL exchange fails if either (or both) of these
fails if either (or both) of these verifications fails. verifications fails.
SASL mechanism specifications describe the form of credentials SASL mechanism specifications describe the form of credentials used
used to authenticate clients, and SASL application to authenticate clients, and SASL application profiles describe the
profiles describe the form of authorization identities form of authorization identities transferred as part of
transferred as part of authentication exchange. authentication exchange. However, the precise form(s) of the
However, the authentication identities (used within the server in its
precise form(s) of the authentication identities (used verifications, or otherwise) and the precise form(s) of the
within the server in its verifications, or otherwise) authorization identities (used in making authorization decisions, or
and the precise form(s) of the authorization identities otherwise) is beyond the scope of the SASL and this specification.
(used in making authorization decisions, or otherwise) is In some circumstances, the precise identity forms used outside of the
beyond the scope of the SASL and this specification. In SASL exchange may be dictated by other specifications. For instance,
some circumstances, the precise identity forms used the authorization policy specification for an application protocol
outside of the SASL exchange may be dictated by other may dictate the precise form that an authorization identity is to be
specifications. For instance, the authorization policy
specification for an application protocol may dictate the
precise form that an authorization identity is to be
represented in the authorization policy. represented in the authorization policy.
Internet DRAFT SASL 25 October 2004 <<Need to address few issues in the two remaining paragraphs>> Any
normalization of the authentication identity (for the purposes of
conducting authentication exchange) is defined by a particular SASL
mechanism, the protocol profile doesn't influence it. Note, that the
<<Need to address few issues in the two remaining paragraphs>> Internet DRAFT SASL 16 February 2005
Any normalization of the authentication identity (for the purposes
of conducting authentication exchange) is defined by a particular mechanism specification doesn't control how authentication identity
SASL mechanism, the protocol profile doesn't influence it. information is represented elsewhere <<need to add few examples>>.
Note, that the mechanism specification doesn't control how
authentication identity information is represented elsewhere
<<need to add few examples>>.
The mechanism MUST preserve Unicode codepoints when transferring The mechanism MUST preserve Unicode codepoints when transferring
authorization identity (e.g. the mechanism can't apply any form authorization identity (e.g. the mechanism can't apply any form of
of normalization). normalization).
3.2.1. Authorization identities and proxy authentication 3.2.1. Authorization identities and proxy authentication
A mechanism which is incapable of transmitting an authorization identity A mechanism which is incapable of transmitting an authorization
must be treated as if it always transmits an authorization identity of an identity must be treated as if it always transmits an authorization
empty string. <<Is this redundant?>> identity of an empty string.
If the authorization identity transmitted during the authentication If the authorization identity transmitted during the authentication
exchange is not the empty string, this is typically referred exchange is not the empty string, this is typically referred to as
to as "proxy authentication". This feature permits agents such as "proxy authentication". This feature permits agents such as proxy
proxy servers to authenticate using their own credentials, yet request servers to authenticate using their own credentials, yet request the
the access privileges of the identity for which they are proxying. access privileges of the identity for which they are proxying.
The server makes an implementation-defined policy decision as to The server makes an implementation-defined policy decision as to
whether the authentication identity is permitted to have the access whether the authentication identity is permitted to have the access
privileges of the authorization identity and whether the authorization privileges of the authorization identity and whether the
identity is permitted to receive service. If it is not, the server authorization identity is permitted to receive service. If it is
indicates failure of the authentication exchange. not, the server indicates failure of the authentication exchange.
As a client might not have the same information as the server, As a client might not have the same information as the server,
clients SHOULD NOT derive authorization identities from authentication clients SHOULD NOT derive authorization identities from
identities. Instead, clients SHOULD provide no (or empty) authorization authentication identities. Instead, clients SHOULD provide no (or
identity when the user<<client?>> has not provided an authorization identity. empty) authorization identity when the user has not provided an
authorization identity.
The server SHOULD verify that a received authorization identity is in the
correct form. Protocol profiles whose authorization identities are simple user
names (e.g. IMAP [RFC 3501]) SHOULD use "SASLprep"
profile [SASLprep] of the "stringprep" algorithm [StringPrep] to prepare
these names for matching. The profiles MAY use a stringprep profile
that is more strict than "SASLprep". If the preparation of
the authorization identity fails or results in an empty string,
the server MUST fail the authentication exchange. The only exception to
this rule is when the received authorization identity is already the empty
string.
Internet DRAFT SASL 25 October 2004 The server SHOULD verify that a received authorization identity is in
the correct form. Protocol profiles whose authorization identities
are simple user names (e.g. IMAP [RFC 3501]) SHOULD use "SASLprep"
profile [SASLprep] of the "stringprep" algorithm [StringPrep] to
prepare these names for matching. The profiles MAY use a stringprep
profile that is more strict than "SASLprep". If the preparation of
the authorization identity fails or results in an empty string, the
server MUST fail the authentication exchange. The only exception to
this rule is when the received authorization identity is already the
empty string.
3.2.2. Authorization Identity Format 3.2.2. Authorization Identity Format
An authorization identity is a string of zero or more Unicode [Unicode] An authorization identity is a string of zero or more Unicode
coded characters. The NUL <U+0000> character is prohibited [Unicode] coded characters. The NUL <U+0000> character is prohibited
Internet DRAFT SASL 16 February 2005
in authorization identities. in authorization identities.
The character encoding scheme used for transmitting an authorization The character encoding scheme used for transmitting an authorization
identity over the protocol is specified in each authentication mechanism. identity over the protocol is specified in each authentication
All IETF-defined mechanisms MUST, and all other mechanisms SHOULD, mechanism. All IETF-defined mechanisms MUST, and all other
use UTF-8 [UTF-8]. (See [CHARSET-POLICY] for IETF policy regarding character mechanisms SHOULD, use UTF-8 [UTF-8]. (See [CHARSET-POLICY] for IETF
sets and encoding schemes.) policy regarding character sets and encoding schemes.)
Mechanisms are expected to be capable of carrying the entire Unicode Mechanisms are expected to be capable of carrying the entire Unicode
repertoire (with the exception of the NUL character). An authorization repertoire (with the exception of the NUL character). An
identity of the empty string and an absent authorization identity authorization identity of the empty string and an absent
MUST be treated as equivalent. A mechanism authorization identity MUST be treated as equivalent. A mechanism
which provides an optional field for an authorization identity, which provides an optional field for an authorization identity,
SHOULD NOT allow that field, when present, to be empty. SHOULD NOT allow that field, when present, to be empty. The meaning
The meaning of the empty string as an authorization identity is described of the empty string as an authorization identity is described in
in Section 3.2. Section 3.2.
3.3. Security layers 3.3. Security layers
SASL mechanisms may offer a wide range of services in "security
layers". Typical examples of such services are data integrity, data
confidentiality, re-keying, truncation detection and compression.
If use of a security layer is negotiated by the authentication If use of a security layer is negotiated by the authentication
protocol exchange, the security layer is applied to all subsequent protocol exchange, the security layer is applied to all subsequent
data sent over the connection (until another security layer is negotiated ( data sent over the connection (until another security layer is
see also section 6.3) or underlying connection is closed). The security negotiated ( see also section 6.3) or underlying connection is
layer takes effect closed). The security layer takes effect immediately following the
immediately following the last response of the authentication exchange last response of the authentication exchange for data sent by the
for data sent by the client and the completion indication for data client and the completion indication for data sent by the server. The
sent by the server. The exact position MUST be defined by the protocol profile exact position MUST be defined by the protocol profile (see section 4
(see section 4 part 5). part 5).
Once the security layer is in effect the Once the security layer is in effect the protocol stream is processed
protocol stream is processed by the security layer into buffers of by the security layer into buffers of protected data. If the
protected data. If the security layer is not able to produce a buffer, security layer is not able to produce a buffer, the connection MUST
the connection MUST be closed. If the security layer is not able to be closed. If the security layer is not able to decode a received
decode a received buffer, the connection MUST be closed. In both cases the buffer, the connection MUST be closed. In both cases the underlying
underlying connection SHOULD be closed gracefully. connection SHOULD be closed gracefully.
Each buffer of protected data is Each buffer of protected data is transferred over the connection as a
transferred over the connection as a stream of octets prepended with a stream of octets prepended with a four octet field in network byte
four octet field in network byte order that represents the length of order that represents the length of the buffer. The length of the
the buffer. The length of the protected data buffer protected data buffer MUST be no larger than the maximum size that
MUST be no larger than the maximum size that was either defined in the was either defined in the mechanism specification or negotiated by
mechanism specification or negotiated by the other side during the authentication exchange. Upon the receipt
the other side during the authentication exchange. of a data buffer which is larger than the defined/negotiated maximal
Upon the receipt of a data buffer which is larger than the defined/negotiated
Internet DRAFT SASL 25 October 2004 Internet DRAFT SASL 16 February 2005
maximal buffer size the receiver SHOULD close the connection, buffer size the receiver SHOULD close the connection, as this might
as this might be a sign of an attack. be a sign of an attack.
SASL mechanisms which are unable to negotiate a security layer SASL mechanisms which are unable to negotiate a security layer are
are treated as selecting no security layer. treated as selecting no security layer.
4. Protocol profile requirements 4. Protocol profile requirements
In order to use this specification, a protocol definition MUST supply In order to use this specification, a protocol definition MUST supply
the following information: the following information:
1) A service name, to be selected from the IANA registry of "service" 1) A service name, to be selected from the IANA registry of
elements for the GSSAPI host-based service name form [GSSAPI]. This "service" elements for the GSSAPI host-based service name form
service name is made available to the authentication mechanism. [GSSAPI]. This service name is made available to the authentication
mechanism.
The registry is available at the URL The registry is available at the URL
<http://www.iana.org/assignments/gssapi-service-names>. <http://www.iana.org/assignments/gssapi-service-names>.
2) A definition of the command to initiate the authentication protocol 2) A definition of the command to initiate the authentication
exchange. This command must have as a parameter the protocol exchange. This command must have as a parameter the name
name of the mechanism being selected by the client. of the mechanism being selected by the client.
The command SHOULD have an optional parameter giving an initial The command SHOULD have an optional parameter giving an initial
response. If the protocol allows for the initial response, response. If the protocol allows for the initial response, the
the protocol profile MUST also describe how an empty initial response is protocol profile MUST also describe how an empty initial response
encoded. This optional parameter allows the client to avoid a round is encoded. This optional parameter allows the client to avoid a
trip when using a mechanism which is defined to have the client send round trip when using a mechanism which is defined to have the
data first. When this initial response is sent by the client and the client send data first. When this initial response is sent by the
selected mechanism is defined to have the server start with an initial client and the selected mechanism is defined to have the server
challenge, the command fails. See section 6.1 of this document for start with an initial challenge, the command fails. See section
further information. 6.1 of this document for further information.
3) A definition of the method by which the authentication protocol 3) A definition of the method by which the authentication protocol
exchange is carried out, including how the challenges and responses exchange is carried out, including how the challenges and responses
are encoded, how the server indicates completion or failure of the are encoded, how the server indicates completion or failure of the
exchange, how the client aborts an exchange, and how the exchange method exchange, how the client aborts an exchange, and how the exchange
interacts with any line length limits in the protocol. method interacts with any line length limits in the protocol.
The exchange method SHOULD allow the server to include an The exchange method SHOULD allow the server to include an optional
optional data ("optional challenge") with a success notification. This allows the data ("optional challenge") with a success notification. This
server to avoid a round trip when using a mechanism which is defined allows the server to avoid a round trip when using a mechanism
to have the server send additional data along with the indication of which is defined to have the server send additional data along with
successful completion. Note that if additional data is sent with success, the indication of successful completion. Note that if additional
it can not be empty. See section 6.2 of this document for further information. data is sent with success, it can not be empty. See section 6.2 of
this document for further information.
4) A protocol profile SHOULD specify a mechanism through 4) A protocol profile SHOULD specify a mechanism through which a
which a client may obtain the names of the SASL mechanisms available
to it. This is typically done through the protocol's extensions or
Internet DRAFT SASL 25 October 2004 Internet DRAFT SASL 16 February 2005
client may obtain the names of the SASL mechanisms available to it.
This is typically done through the protocol's extensions or
capabilities mechanism. capabilities mechanism.
5) Identification of the octet where any negotiated security layer starts 5) Identification of the octet where any negotiated security layer
to take effect, in both directions. starts to take effect, in both directions.
6) Specify if the protocol profile supports "multiple authentications" 6) Specify if the protocol profile supports "multiple
(see section 6.3). authentications" (see section 6.3).
7) If both a Transport Layer Security [TLS] and a SASL security layer are 7) If both a Transport Layer Security [TLS] and a SASL security
allowed to be negotiated by layer are allowed to be negotiated by the protocol, the protocol
the protocol, the protocol profile MUST define in which order they are profile MUST define in which order they are applied to a cleartext
applied to a cleartext data sent over the connection. data sent over the connection.
8) A protocol profile MAY further refine the definition of an 8) A protocol profile MAY further refine the definition of an
authorization identity by adding additional syntactic restrictions and authorization identity by adding additional syntactic restrictions
protocol-specific semantics. A protocol profile MUST specify the form and protocol-specific semantics. A protocol profile MUST specify
of the authorization identity (since it is protocol-specific, as opposed the form of the authorization identity (since it is protocol-
to the authentication identity, which is mechanism-specific) and how specific, as opposed to the authentication identity, which is
authorization identities are to be compared. Profiles whose authorization mechanism-specific) and how authorization identities are to be
identities are simple user names (e.g. IMAP [RFC 3501]) SHOULD use compared. Profiles whose authorization identities are simple user
"SASLprep" profile [SASLprep] of the "stringprep" algorithm [StringPrep] names (e.g. IMAP [RFC 3501]) SHOULD use "SASLprep" profile
to prepare these names for matching. The profiles MAY use a stringprep profile [SASLprep] of the "stringprep" algorithm [StringPrep] to prepare
these names for matching. The profiles MAY use a stringprep profile
that is more strict than SASLprep. that is more strict than SASLprep.
9) Where the application-layer protocol does not precisely state 9) Where the application-layer protocol does not precisely state
how identities established through SASL relate to identities how identities established through SASL relate to identities used
used elsewhere (e.g., access controls) in the application-layer elsewhere (e.g., access controls) in the application-layer
protocol, it may be useful for the application-layer protocol protocol, it may be useful for the application-layer protocol to
to provide a facility which the client may use to discover the provide a facility which the client may use to discover the
identity used. identity used.
A protocol profile SHOULD NOT attempt to amend the definition of A protocol profile SHOULD NOT attempt to amend the definition of
mechanisms or create mechanism-specific encodings. This breaks the mechanisms or create mechanism-specific encodings. This breaks the
separation between protocol and mechanism that is fundamental to the separation between protocol and mechanism that is fundamental to the
design of SASL. (Likewise, SASL mechanisms are intended to be profile neutral.) design of SASL. (Likewise, SASL mechanisms are intended to be profile
neutral.)
5. Mechanism profile guidelines 5. Mechanism profile guidelines
Designers of new SASL mechanism should be aware of the following issues: Designers of new SASL mechanism should be aware of the following
issues:
1) Authorization identity 1) Authorization identity
While some legacy mechanisms are incapable of transmitting an authorization Internet DRAFT SASL 16 February 2005
identity (which means that for these mechanisms the authorization identity
is always the empty string), newly defined mechanisms SHOULD be
capable of transmitting a non-empty authorization identity. See also section 3.2.
Internet DRAFT SASL 25 October 2004 While some legacy mechanisms are incapable of transmitting an
authorization identity (which means that for these mechanisms the
authorization identity is always the empty string), newly defined
mechanisms SHOULD be capable of transmitting a non-empty
authorization identity. See also section 3.2.
2) Character string issues 2) Character string issues
Authentication mechanisms SHOULD encode character strings in UTF-8 [UTF-8] Authentication mechanisms SHOULD encode character strings in UTF-8
(see [CHARSET-POLICY] for IETF policy regarding character sets in IETF protocols). [UTF-8] (see [CHARSET-POLICY] for IETF policy regarding character
In order to avoid interoperability problems due to differing normalizations, sets in IETF protocols). In order to avoid interoperability problems
when a mechanism specifies that character data is to be used as input to a due to differing normalizations, when a mechanism specifies that
cryptographic and/or comparison function, the mechanism specification MUST character data is to be used as input to a cryptographic and/or
detail how the data is to be represented, including any normalizations or comparison function, the mechanism specification MUST detail how the
other preparations, to ensure proper function. Designers of mechanisms SHOULD use data is to be represented, including any normalizations or other
the "SASLprep" profile [SASLprep] of the "stringprep" algorithm [StringPrep] where applicable. preparations, to ensure proper function. Designers of mechanisms
This recommendation does not apply to authorization identities as their handling is protocol-specific. SHOULD use the "SASLprep" profile [SASLprep] of the "stringprep"
algorithm [StringPrep] where applicable. This recommendation does
The preparation can be potentially performed on the client side (upon getting user input not apply to authorization identities as their handling is protocol-
or retrieving a value from configuration) or on the server side (upon receiving the value specific.
from the client, retrieving a value from its authentication database or generating a
new value in order to store in in the authentication database).
SASL mechanisms MUST define which entity (or entities) must perform the
preparation. If preparation fails or turns a non-empty string into the empty string, the entity
doing the preparation MUST fail the authentication exchange.
Implementation note:
A server side can be represented by multiple processes. For example, the server side may
consist of the server process itself that communicated with a client and a
utility (a server agent) that is able to store passwords/hashes (or derivitives) in a
database that can be later used by the server. For the server agent the
requirement to "fail the authentication exchange" should be interpreted
as a requirement to refuse to store the data in the database.
3) If the underlying cryptographic technology used by a mechanism supports The preparation can be potentially performed on the client side (upon
data integrity, then the mechanism specification MUST integrity protect getting user input or retrieving a value from configuration) or on
the transmission of an authorization identity and the negotiation of the server side (upon receiving the value from the client, retrieving
the security layer. a value from its authentication database or generating a new value in
order to store in in the authentication database). SASL mechanisms
MUST define which entity (or entities) must perform the preparation.
If preparation fails or turns a non-empty string into the empty
string, the entity doing the preparation MUST fail the authentication
exchange.
4) The mechanism SHOULD NOT use the authorization identity in generation of any Implementation note: A server side can be represented by multiple
long-term cryptographic keys/hashes. The reason is that different protocols processes. For example, the server side may consist of the server
(and sometimes even different implementations of the same protocol) may use process itself that communicated with a client and a utility (a
multiple forms of an authorization identity that are semantically equivalent server agent) that is able to store passwords/hashes (or derivitives)
and some clients may use one form while other clients use a different form. in a database that can be later used by the server. For the server
agent the requirement to "fail the authentication exchange" should be
interpreted as a requirement to refuse to store the data in the
database.
5) SASL mechanisms should be designed to minimize the number of round 3) The mechanism specification MUST detail whether or not it offers a
trips required, because SASL can be used with protocols where connections security layer. If it does, it MUST detail the security and other
are short-lived. services offered in the layer as well as how these services are to be
implemented.
6) SASL does not provide for re-keying (see Section 9.1), but SASL mechanisms may. 4) If the underlying cryptographic technology used by a mechanism
supports data integrity, then the mechanism specification MUST
integrity protect the transmission of an authorization identity and
<<Original Nico's text follows:>> Internet DRAFT SASL 16 February 2005
SASL mechanisms that support re-keying SHOULD:
- indicate that re-keying is or will be needed immediately; <<Alexey: HOW?>>
Internet DRAFT SASL 25 October 2004 the negotiation of the security layer.
- provide re-keying messages or transparently include re-keying 5) The mechanism SHOULD NOT use the authorization identity in
messages in the security layers; the latter can happen without generation of any long-term cryptographic keys/hashes. The reason is
application involvement, but only as long as the application is that different protocols (and sometimes even different
engaged in timely bidirectional exchanges with its peer. implementations of the same protocol) may use multiple forms of an
authorization identity that are semantically equivalent and some
clients may use one form while other clients use a different form.
<<Alternative text by Alexey:>> 6) SASL mechanisms should be designed to minimize the number of round
A SASL mechanism supports re-keying if it is able to generate/process trips required, because SASL can be used with protocols where
messages that request immediate re-keying and it is able to carry out connections are short-lived.
re-keying exchange. (Note that the mechanism MAY use a single message
type to do both). SASL mechanisms that support re-keying MAY also be
able to indicate that re-keying will be needed in the future.
A re-keying exchange can be conducted transparently by the mechanism,
or the mechanism should be able to provide/accept re-keying messages
to/from the application. The former can happen without application
involvement, but only as long as the application is engaged in timely
bidirectional exchanges with its peer.
7) SASL mechanisms SHOULD be profile neutral. 7) SASL mechanisms SHOULD be profile neutral.
6. Specific issues 6. Specific issues
6.1. Client sends data first 6.1. Client sends data first
Some mechanisms specify that the first data sent in the Some mechanisms specify that the first data sent in the
authentication exchange is from the client to the server. authentication exchange is from the client to the server.
If a protocol's profile permits the command which initiates an If a protocol's profile permits the command which initiates an
authentication exchange to contain an initial client authentication exchange to contain an initial client response, this
response, this parameter SHOULD be used with such mechanisms. parameter SHOULD be used with such mechanisms.
If the initial client response parameter is not given, or if a If the initial client response parameter is not given, or if a
protocol's profile does not permit the command which initiates an protocol's profile does not permit the command which initiates an
authentication exchange to contain an initial client authentication exchange to contain an initial client response, then
response, then the server issues a challenge with no data. The the server issues a challenge with no data. The client's response to
client's response to this challenge is then used as the initial client this challenge is then used as the initial client response. (The
response. (The server then proceeds to send the next challenge, server then proceeds to send the next challenge, indicates
indicates completion, or indicates failure.) completion, or indicates failure.)
6.1.1. Client sends data first examples 6.1.1. Client sends data first examples
The following are two examples of the SECURID authentication [SASL-SECURID] in the SMTP The following are two examples of the SECURID authentication [SASL-
protocol [SMTP]. In the first example below, the client is trying fast reauthentication SECURID] in the SMTP protocol [SMTP]. In the first example below,
by sending the initial response: the client is trying fast reauthentication by sending the initial
response:
S: 220-smtp.example.com ESMTP Server S: 220-smtp.example.com ESMTP Server
C: EHLO client.example.com C: EHLO client.example.com
S: 250-smtp.example.com Welcome client.example.com S: 250-smtp.example.com Welcome client.example.com
Internet DRAFT SASL 25 October 2004
S: 250-AUTH GSSAPI SECURID S: 250-AUTH GSSAPI SECURID
S: 250 DSN S: 250 DSN
C: AUTH SECURID AG1hZ251cwAxMjM0NTY3OAA= C: AUTH SECURID AG1hZ251cwAxMjM0NTY3OAA=
Internet DRAFT SASL 16 February 2005
S: 235 Authentication successful S: 235 Authentication successful
The example below is almost identical to the previous, but here the The example below is almost identical to the previous, but here the
client chooses not to use the initial response parameter. client chooses not to use the initial response parameter.
S: 220-smtp.example.com ESMTP Server S: 220-smtp.example.com ESMTP Server
C: EHLO client.example.com C: EHLO client.example.com
S: 250-smtp.example.com Welcome client.example.com S: 250-smtp.example.com Welcome client.example.com
S: 250-AUTH GSSAPI SECURID S: 250-AUTH GSSAPI SECURID
S: 250 DSN S: 250 DSN
skipping to change at page 14, line 4 skipping to change at page 13, line 51
data with success. Imagine that an active attacker is trying to data with success. Imagine that an active attacker is trying to
impersonate the server and sends faked data, which should be used to impersonate the server and sends faked data, which should be used to
authenticate the server to the client, with success. (A similar authenticate the server to the client, with success. (A similar
situation can happen when either the server and/or the client has a situation can happen when either the server and/or the client has a
bug and they calculate different responses.) After checking the data, bug and they calculate different responses.) After checking the data,
the client will think that the authentication exchange has failed, the client will think that the authentication exchange has failed,
however the server will think that the authentication exchange has however the server will think that the authentication exchange has
completed successfully. At this point the client can not abort the completed successfully. At this point the client can not abort the
authentication exchange; it SHOULD close the connection instead. authentication exchange; it SHOULD close the connection instead.
However, if the profile did not support sending of additional data However, if the profile did not support sending of additional data
Internet DRAFT SASL 25 October 2004
with success, the client could have aborted the exchange at the very with success, the client could have aborted the exchange at the very
last step of the authentication exchange. last step of the authentication exchange.
Internet DRAFT SASL 16 February 2005
6.2.1. Server returns success with additional data examples 6.2.1. Server returns success with additional data examples
The following are two examples of a DIGEST-MD5 authentication [SASL- The following are two examples of a DIGEST-MD5 authentication [SASL-
DIGEST] in the Extensible Messaging and Presence Protocol [XMPP]. In DIGEST] in the Extensible Messaging and Presence Protocol [XMPP]. In
the first example below, the server is sending mutual authentication the first example below, the server is sending mutual authentication
data with success. data with success.
C: <stream:stream C: <stream:stream
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'
skipping to change at page 15, line 5 skipping to change at page 14, line 51
LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo
YXJzZXQ9dXRmLTgK YXJzZXQ9dXRmLTgK
</response> </response>
S: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> S: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo=
</success> </success>
The example below is almost identical to the previous, but here The example below is almost identical to the previous, but here
the server chooses not to use the additional data with success. the server chooses not to use the additional data with success.
Internet DRAFT SASL 25 October 2004
C: <stream:stream C: <stream:stream
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'
Internet DRAFT SASL 16 February 2005
to='example.com' to='example.com'
version='1.0'> version='1.0'>
S: <stream:stream S: <stream:stream
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'
id='c2s_234' id='c2s_234'
from='example.com' from='example.com'
version='1.0'> version='1.0'>
S: <stream:features> S: <stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
skipping to change at page 15, line 54 skipping to change at page 15, line 51
Unless otherwise stated by the protocol's profile, only one Unless otherwise stated by the protocol's profile, only one
successful SASL negotiation may occur in a protocol session. In this successful SASL negotiation 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.
If a profile explicitly permits multiple successful SASL negotiations If a profile explicitly permits multiple successful SASL negotiations
to occur, then in no case may multiple security layers be to occur, then in no case may multiple 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; this can be used as a form second security layer replaces the first. If a security layer is in
effect and a subsequent SASL negotiation selects no security layer,
Internet DRAFT SASL 25 October 2004 the original security layer remains in effect.
of re-keying, where SASL mechanisms that provide security layers fail Internet DRAFT SASL 16 February 2005
to provide for re-keying, provided that the authenticated identity
remains the same. If a security layer is in effect and a subsequent
SASL negotiation selects no security layer, the original security
layer remains in effect.
Where a protocol profile permits multiple successful SASL Where a protocol profile permits multiple successful SASL
negotiations, the profile MUST detail the effect of a failed SASL negotiations, the profile MUST detail the effect of a failed SASL
negotiation upon the previously established authentication state. negotiation upon the previously established authentication state.
In particular, it MUST state whether the previously established In particular, it MUST state whether the previously established
authenticated state remains in force or whether the connection is to authenticated state remains in force or whether the connection is to
revert to an non-authenticated state. Regardless of the specified revert to an non-authenticated state. Regardless of the specified
effect upon authentication state, the previously negotiated security effect upon authentication state, the previously negotiated security
layer remains in effect. layer remains in effect.
skipping to change at page 17, line 4 skipping to change at page 16, line 49
doesn't mean that the server will use the information provided by doesn't mean that the server will use the information provided by
TLS. TLS.
7.1. Formal syntax 7.1. Formal syntax
The following syntax specification uses the augmented Backus-Naur The following syntax specification uses the augmented Backus-Naur
Form (BNF) notation as specified in [ABNF]. Non-terminals referenced Form (BNF) notation as specified in [ABNF]. Non-terminals referenced
but not defined below are as defined by [UTF-8]. but not defined below are as defined by [UTF-8].
The "extern-resp" rule below defines the message sent from client to The "extern-resp" rule below defines the message sent from client to
Internet DRAFT SASL 25 October 2004
server. server.
extern-resp = *( UTF8-char-no-nul ) extern-resp = *( 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
Internet DRAFT SASL 16 February 2005
UTF8-1-no-nul = %x01-7F UTF8-1-no-nul = %x01-7F
7.2. Examples of SASL EXTERNAL 7.2. Examples of SASL EXTERNAL
The following is an example of an EXTERNAL authentication in the SMTP The following is an example of an EXTERNAL authentication in the SMTP
protocol [SMTP]. In this example, the client is proxy authenticating, protocol [SMTP]. In this example, the client is proxy authenticating,
sending the authorization identity "fred@example.com" in the sending the authorization identity "fred@example.com" in the
(optional) initial response. The server has obtained the client's (optional) initial response. The server has obtained the client's
(authentication) identity from an external service, such as IPsec, (authentication) identity from an external service, such as IPsec,
and has a security policy that permits that identity to assume the and has a security policy that permits that identity to assume the
skipping to change at page 18, line 4 skipping to change at page 17, line 48
S: 250 AUTH DIGEST-MD5 EXTERNAL S: 250 AUTH DIGEST-MD5 EXTERNAL
C: AUTH EXTERNAL C: AUTH EXTERNAL
S: 235 Authentication successful. S: 235 Authentication successful.
The following is an example of an EXTERNAL authentication in the The following is an example of an EXTERNAL authentication in the
IMAP4 protocol [IMAP]. IMAP4 doesn't support the initial response IMAP4 protocol [IMAP]. IMAP4 doesn't support the initial response
feature of SASL. As in the previous example, the client doesn't feature of SASL. As in the previous example, the client doesn't
request proxy authentication. request proxy authentication.
S: * OK IMAP4rev1 Server S: * OK IMAP4rev1 Server
Internet DRAFT SASL 25 October 2004
C: C01 CAPABILITY C: C01 CAPABILITY
S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=DIGEST-MD5 AUTH=EXTERNAL S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=DIGEST-MD5 AUTH=EXTERNAL
[...] [...]
C: A01 AUTHENTICATE EXTERNAL C: A01 AUTHENTICATE EXTERNAL
(note that there is a space following the "+" in the following line) (note that there is a space following the "+" in the following line)
S: + S: +
Internet DRAFT SASL 16 February 2005
C: C:
S: A01 OK Success S: A01 OK Success
8. IANA Considerations 8. IANA Considerations
8.1. Guidelines for IANA 8.1. Guidelines for IANA
It is requested that IANA updates the SASL mechanisms registry as It is requested that IANA updates the SASL mechanisms registry as
follows: follows:
skipping to change at page 19, line 4 skipping to change at page 18, line 44
SASL mechanism namespace ("family of SASL mechanisms") for its own SASL mechanism namespace ("family of SASL mechanisms") for its own
use, amending the registration rules for that portion of the use, amending the registration rules for that portion of the
namespace. Each family of SASL mechanisms MUST be identified by a namespace. Each family of SASL mechanisms MUST be identified by a
prefix. prefix.
While the registration procedures do not require expert review, While the registration procedures do not require expert review,
authors of SASL mechanisms are encouraged to seek community review authors of SASL mechanisms are encouraged to seek community review
and comment whenever that is feasible. Authors may seek community and comment whenever that is feasible. Authors may seek community
review 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 Internet-Draft. SASL mechanisms intended for widespread use should
Internet DRAFT SASL 25 October 2004
be standardized through the normal IETF process, when appropriate. be standardized through the normal IETF process, when appropriate.
8.3. Comments on SASL mechanism registrations 8.3. Comments on SASL mechanism registrations
Comments on registered SASL mechanisms should first be sent to the Comments on registered SASL mechanisms should first be sent to the
"owner" of the mechanism and/or to the SASL WG mailing list. "owner" of the mechanism and/or to the SASL WG mailing list.
Internet DRAFT SASL 16 February 2005
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. If IANA approves of this, the comment will be registration itself. If IANA approves of this, the comment will be
made accessible in conjunction with the SASL mechanism registration made accessible in conjunction with the SASL mechanism registration
itself. itself.
8.4. Change control 8.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
skipping to change at page 20, line 5 skipping to change at page 19, line 49
Subject: Registration of SASL mechanism X Subject: Registration of SASL mechanism X
Family of SASL mechanisms: (YES or NO) Family of SASL mechanisms: (YES or NO)
SASL mechanism name (or prefix for the family): SASL mechanism name (or prefix for the family):
Security considerations: Security considerations:
Published specification (optional, recommended): Published specification (optional, recommended):
Internet DRAFT SASL 25 October 2004
Person & email address to contact for further information: Person & email address to contact for further information:
Intended usage: Intended usage:
(One of COMMON, LIMITED USE or OBSOLETE) (One of COMMON, LIMITED USE or OBSOLETE)
Internet DRAFT SASL 16 February 2005
Owner/Change controller: Owner/Change controller:
(Any other information that the author deems interesting may be (Any other information that the author deems interesting may be
added below this line.) added below this line.)
8.6. The EXTERNAL mechanism registration 8.6. The EXTERNAL mechanism registration
It is requested that the SASL Mechanism registry [IANA-SASL] entry It is requested that the SASL Mechanism registry [IANA-SASL] entry
for the EXTERNAL mechanism be updated to reflect that this document for the EXTERNAL mechanism be updated to reflect that this document
now provides its technical specification. now provides its technical specification.
skipping to change at page 21, line 4 skipping to change at page 20, line 47
9. Security considerations 9. Security considerations
Security issues are discussed throughout this memo. Security issues are discussed throughout this memo.
When the client selects a security layer with at least integrity When the client selects a security layer with at least integrity
protection, this protects against an active attacker hijacking the protection, this protects against an active attacker hijacking the
connection and modifying the authentication exchange to negotiate a connection and modifying the authentication exchange to negotiate a
plaintext connection. plaintext connection.
When a server or client supports multiple authentication mechanisms, When a server or client supports multiple authentication mechanisms,
Internet DRAFT SASL 25 October 2004
each of which has a different security strength, it is possible for each of which has a different security strength, it is possible for
an active attacker to cause a party to use the least secure mechanism an active attacker to cause a party to use the least secure mechanism
supported. To protect against this sort of attack, a client or supported. To protect against this sort of attack, a client or
server which supports mechanisms of different strengths should have a server which supports mechanisms of different strengths should have a
configurable minimum strength that it will use. It is not sufficient configurable minimum strength that it will use. It is not sufficient
for this minimum strength check to only be on the server, since an for this minimum strength check to only be on the server, since an
Internet DRAFT SASL 16 February 2005
active attacker can change which mechanisms the client sees as being active attacker can change which mechanisms the client sees as being
supported, causing the client to send authentication credentials for supported, causing the client to send authentication credentials for
its weakest supported mechanism. its weakest supported mechanism.
The client's selection of a SASL mechanism is done in the clear and The client's selection of a SASL mechanism is done in the clear and
may be modified by an active attacker. It is important for any new may be modified by an active attacker. It is important for any new
SASL mechanisms to be designed such that an active attacker cannot SASL mechanisms to be designed such that an active attacker cannot
obtain an authentication with weaker security properties by modifying obtain an authentication with weaker security properties by modifying
the SASL mechanism name and/or the challenges and responses. the SASL mechanism name and/or the challenges and responses.
skipping to change at page 22, line 4 skipping to change at page 21, line 49
Clients should be admonished to validate TLS server IDs to prevent Clients should be admonished to validate TLS server IDs to prevent
MITM attacks when using SASL-over-TLS. The same recommendation MITM attacks when using SASL-over-TLS. The same recommendation
applies to other protocols providing security services. applies to other protocols providing security services.
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 protocol exchange, the receiver should handle gracefully any
protected data buffer larger than the defined/negotiated maximal protected data buffer larger than the defined/negotiated maximal
size. In particular, it must not blindly allocate the amount of size. In particular, it must not blindly allocate the amount of
memory specified in the buffer size field, as this might cause the memory specified in the buffer size field, as this might cause the
"out of memory" condition. If the receiver detects a large block, it "out of memory" condition. If the receiver detects a large block, it
SHOULD close the connection.
Internet DRAFT SASL 25 October 2004 Most of the currently available mechanisms that provide security
layers only provide basic data security services, such as data
integrity and data privacy services. It is hoped that future
mechanisms will provide more advance data security services like re-
SHOULD close the connection. Internet DRAFT SASL 16 February 2005
keying and truncation attack detection.
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 manner acceptable to disclosing party. Applications
using SASL assume that SASL security layers providing data using SASL assume that SASL security layers providing data
confidentiality are secure even when an attacker chooses the text to confidentiality are secure even when an attacker chooses the text to
be protected by the security layer. Similarly applications assume be protected by the security layer. Similarly applications assume
that the SASL security layer is secure even if the attacker can that the SASL security layer is secure even if the attacker can
manipulate the ciphertext output of the security layer. New SASL manipulate the ciphertext output of the security layer. New SASL
skipping to change at page 22, line 38 skipping to change at page 22, line 38
9.1. Re-keying 9.1. Re-keying
The secure or administratively permitted lifetimes of SASL The secure or administratively permitted lifetimes of SASL
mechanisms' security layers are finite. Cryptographic keys weaken as mechanisms' security layers are finite. Cryptographic keys weaken as
they are used and as time passes; the more time and/or ciphertext they are used and as time passes; the more time and/or ciphertext
that a cryptanalyst has after the first use of the a key, the easier that a cryptanalyst has after the first use of the a key, the easier
it is for the cryptanalyst to mount attacks on the key. it is for the cryptanalyst to mount attacks on the key.
Administrative limits on security layers lifetime may take the form Administrative limits on security layers lifetime may take the form
of time limits expressed in x.509 certificates, Kerberos V tickets, of time limits expressed in x.509 certificates, Kerberos V tickets,
or in directories, and are often desired. <<In practice one likely or in directories, and are often desired. In practice one likely
effect of administrative security layers lifetime limits is that effect of administrative security layers lifetime limits is that
applications may find that security layers stop working in the middle applications may find that security layers stop working in the middle
of application protocol operation, such as, perhaps, during large of application protocol operation, such as, perhaps, during large
data transfers. As the result of this the connection will be closed data transfers. As the result of this the connection will be closed
(see section 3.3), which will result in unpleasant user experience.>> (see section 3.3), which will result in 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 provide for weakening of cryptographic keys. SASL framework does not itself
re-keying. SASL mechanisms may; all future SASL mechanisms that provide for re-keying. SASL mechanisms may. Designers of future SASL
provide security layers should provide for re-keying. mechanisms should consider providing re-keying services.
Applications that wish to re-key SASL security layers where the Applications 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.
Internet DRAFT SASL 25 October 2004 Internet DRAFT SASL 16 February 2005
This approach requires support for re-keying in the application This approach requires support for reauthentication in the
protocols. See section 6.3. application protocols. See section 6.3.
10. References 10. References
10.1. Normative References 10.1. Normative References
[ABNF] Crocker, D. (Ed.), Overell, P., "Augmented BNF for Syntax [ABNF] Crocker, D. (Ed.), Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997 Specifications: ABNF", RFC 2234, November 1997
[ASCII] American National Standards Institute, "Code Extension [ASCII] American National Standards Institute, "Code Extension
Techniques for Use with the 7-bit Coded Character Set of American Techniques for Use with the 7-bit Coded Character Set of American
skipping to change at page 24, line 5 skipping to change at page 24, line 5
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 3629, STD 63, November 2003. RFC 3629, STD 63, November 2003.
10.2. Informative References 10.2. Informative References
[SASL-GSSAPI] Melnikov, A., "SASL GSSAPI mechanisms", work in [SASL-GSSAPI] Melnikov, A., "SASL GSSAPI mechanisms", work in
progress, draft-ietf-sasl-gssapi-XX.txt, November 2003 progress, draft-ietf-sasl-gssapi-XX.txt, November 2003
[SASL-DIGEST] Leach, P., Newman, C., Melnikov, A., "Using Digest [SASL-DIGEST] Leach, P., Newman, C., Melnikov, A., "Using Digest
Internet DRAFT SASL 25 October 2004 Internet DRAFT SASL 16 February 2005
Authentication as a SASL Mechanism", work in progress, draft-ietf- Authentication as a SASL Mechanism", work in progress, draft-ietf-
sasl-rfc2831bis-XX.txt, replaces RFC 2831 sasl-rfc2831bis-XX.txt, replaces RFC 2831
[SASL-OTP] Newman, C., "The One-Time-Password SASL Mechanism", RFC [SASL-OTP] Newman, C., "The One-Time-Password SASL Mechanism", RFC
2444, October 1998. 2444, October 1998.
[SASL-SECURID] Nystrom, M., "The SecurID(r) SASL Mechanism", RFC [SASL-SECURID] Nystrom, M., "The SecurID(r) SASL Mechanism", RFC
2808, April 2000. 2808, April 2000.
skipping to change at page 25, line 5 skipping to change at page 25, line 5
May 2000. May 2000.
11. Editor's Address 11. Editor's Address
Alexey Melnikov Alexey Melnikov
Isode Limited Isode Limited
5 Castle Business Village 5 Castle Business Village
36 Station Road 36 Station Road
Hampton, Middlesex, Hampton, Middlesex,
Internet DRAFT SASL 25 October 2004 Internet DRAFT SASL 16 February 2005
TW12 2BX, United Kingdom TW12 2BX, United Kingdom
Email: Alexey.Melnikov@isode.com Email: Alexey.Melnikov@isode.com
URI: http://www.melnikov.ca/ URI: http://www.melnikov.ca/
12. Acknowledgments 12. Acknowledgments
This document is a revision of RFC 2222 written by John G. Myers. He This document is a revision of RFC 2222 written by John G. Myers. He
also contributed significantly to this revision. also contributed significantly to this revision.
skipping to change at page 26, line 5 skipping to change at page 26, line 5
framing of SASL and some method of providing these important SASL framing of SASL and some method of providing these important SASL
features would have to be devised. features would have to be devised.
Sometimes it is desired to enable within an existing connection the Sometimes it is desired to enable within an existing connection the
use of a security service which does not fit the SASL model. (TLS is use of a security service which does not fit the SASL model. (TLS is
an example of such a service.) This can be done by adding a command, an example of such a service.) This can be done by adding a command,
for example "STARTTLS", to the protocol. Such a command is outside for example "STARTTLS", to the protocol. Such a command is outside
the scope of SASL, and should be different from the command which the scope of SASL, and should be different from the command which
starts a SASL authentication protocol exchange. starts a SASL authentication protocol exchange.
Internet DRAFT SASL 25 October 2004 Internet DRAFT SASL 16 February 2005
In certain situations, it is reasonable to use SASL underneath one of In certain situations, it is reasonable to use SASL underneath one of
these Transport Security services. The transport service would these Transport Security services. The transport service would
secure the connection, either service would authenticate the client, secure the connection, either service would authenticate the client,
and SASL would negotiate the authorization identity. The SASL and SASL would negotiate the authorization identity. The SASL
negotiation would be what moves the protocol from "unauthenticated" negotiation would be what moves the protocol from "unauthenticated"
to "authenticated" state. The "EXTERNAL" SASL mechanism is to "authenticated" state. The "EXTERNAL" SASL mechanism is
explicitly intended to handle the case where the transport service explicitly intended to handle the case where the transport service
secures the connection and authenticates the client and SASL secures the connection and authenticates the client and SASL
negotiates the authorization identity. negotiates the authorization identity.
skipping to change at page 27, line 5 skipping to change at page 27, line 5
in the base SASL spec. in the base SASL spec.
Added a requirement discouraging protocol profiles from breaking the Added a requirement discouraging protocol profiles from breaking the
separation between protocol and mechanism. separation between protocol and mechanism.
Mentioned that standards track documents may carve out their own Mentioned that standards track documents may carve out their own
portions of the SASL mechanism namespace and may amend registration portions of the SASL mechanism namespace and may amend registration
rules for the portion. However registration of individual SASL rules for the portion. However registration of individual SASL
mechanisms is still required. mechanisms is still required.
Internet DRAFT SASL 25 October 2004 Internet DRAFT SASL 16 February 2005
Clarified that authorization identity should be encoded in UTF-8. Clarified that authorization identity should be encoded in UTF-8.
Specified that the authorization identity in the EXTERNAL mechanism Specified that the authorization identity in the EXTERNAL mechanism
is encoded in UTF-8. is encoded in UTF-8.
Added a statement that a protocol profile SHOULD allow challenge data Added a statement that a protocol profile SHOULD allow challenge data
to be sent with a success indication. to be sent with a success indication.
Added a security consideration for the EXTERNAL mechanism. Added a security consideration for the EXTERNAL mechanism.
skipping to change at page 28, line 5 skipping to change at page 28, line 5
Clarified that each SASL mechanism must decide where SASLprep is Clarified that each SASL mechanism must decide where SASLprep is
taking place. taking place.
Added 4 new examples for initial response and additional data with Added 4 new examples for initial response and additional data with
success. success.
Added text on checking the list of available SASL mechanisms after Added text on checking the list of available SASL mechanisms after
negotiating a security layer. negotiating a security layer.
Internet DRAFT SASL 25 October 2004 Internet DRAFT SASL 16 February 2005
Added definition of "integrity protection" and "confidentiality Added definition of "integrity protection" and "confidentiality
protection". protection".
Added warning about negotiating no layer once a security layer is Added warning about negotiating no layer once a security layer is
negotiated. negotiated.
Added new section with guidelines to a SASL mechanism designer. Added new section with guidelines to a SASL mechanism designer.
Added a requirement to specify how an empty initial challenge is Added a requirement to specify how an empty initial challenge is
skipping to change at page 28, line 29 skipping to change at page 28, line 29
Replaced "buffers of cipher-text" with "buffers of protected data" Replaced "buffers of cipher-text" with "buffers of protected data"
for clarity. for clarity.
Clarified that SASL EXTERNAL can be used even with SASL profiles that Clarified that SASL EXTERNAL can be used even with SASL profiles that
don't support initial client response. don't support initial client response.
Changed "authentication protocol exchange" to "authentication Changed "authentication protocol exchange" to "authentication
exchange" everywhere. exchange" everywhere.
Added some text about re-keying and other services that can be
provided by a security layer.
Appendix C. Full Copyright Statement and Intellectual Property Statement Appendix C. Full Copyright Statement and Intellectual Property Statement
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
skipping to change at page 28, line 51 skipping to change at page 29, line 5
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
Internet DRAFT SASL 16 February 2005
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
Internet DRAFT SASL 25 October 2004
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
skipping to change at line 1419 skipping to change at line 1423
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification 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 ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Internet DRAFT SASL 25 October 2004 Internet DRAFT SASL 16 February 2005
Status of this Memo ..... i
Abstract . 2
1. Conventions used in this document .. 2
2. Introduction . 2
2.1. Relationship to other documents .. 4
3. Authentication mechanisms ... 5
3.1. Authentication Exchange ..... 5
3.2. Identity Concepts . 6
3.2.1. Authorization identities and proxy authentication
..... 7
3.2.2. Authorization Identity Format
..... 8
3.3. Security layers
..... 8
4. Protocol profile requirements
..... 9
5. Mechanism profile guidelines
..... 10
6. Specific issues
..... 12
6.1. Client sends data first
..... 12
6.1.1. Client sends data first examples
..... 12
6.2. Server returns success with additional data ..... 13
6.2.1. Server returns success with additional data examples .... 14
6.3. Multiple authentications .... 15
7. The EXTERNAL mechanism . 16
7.1. Formal syntax ..... 16
7.2. Examples of SASL EXTERNAL ... 17
8. IANA Considerations .... 18
8.1. Guidelines for IANA .... 18
8.2. Registration procedure . 18
8.3. Comments on SASL mechanism registrations ... 19
8.4. Change control .... 19
8.5. Registration template .. 19
8.6. The EXTERNAL mechanism registration ... 20
9. Security considerations . 20
9.1. Re-keying .... 22
10. References .. 23
10.1. Normative References .. 23
10.2. Informative References ..... 23
11. Editor's Address .. 24
12. Acknowledgments ... 25
Appendix A. Relation of SASL to transport security .... 25
Appendix B. Changes since RFC 2222 ..... 26
Appendix C. Full Copyright Statement and Intellectual Property Statement
..... 28
Internet DRAFT SASL 25 October 2004
Full Copyright Statement ..... 28 Status of this Memo .......................................... i
Intellectual Property ... 29 Abstract ..................................................... 2
1. Conventions used in this document ........................ 2
2. Introduction ........................................... 2
2.1. Relationship to other documents ........................ 4
3. Authentication mechanisms .............................. 5
3.1. Authentication Exchange ................................ 5
3.2. Identity Concepts ...................................... 6
3.2.1. Authorization identities and proxy authentication .... 7
3.2.2. Authorization Identity Format ........................ 7
3.3. Security layers ........................................ 8
4. Protocol profile requirements .......................... 9
5. Mechanism profile guidelines .......................... 10
6. Specific issues ....................................... 12
6.1. Client sends data first ............................... 12
6.1.1. Client sends data first examples .................... 12
6.2. Server returns success with additional data ........... 13
6.2.1. Server returns success with additional data examples. 14
6.3. Multiple authentications .............................. 15
7. The EXTERNAL mechanism ................................ 16
7.1. Formal syntax ......................................... 16
7.2. Examples of SASL EXTERNAL ............................. 17
8. IANA Considerations ................................... 18
8.1. Guidelines for IANA ................................... 18
8.2. Registration procedure ................................ 18
8.3. Comments on SASL mechanism registrations .............. 18
8.4. Change control ........................................ 19
8.5. Registration template ................................. 19
8.6. The EXTERNAL mechanism registration ................... 20
9. Security considerations ................................ 20
9.1. Re-keying ............................................. 22
10. References ........................................... 23
10.1. Normative References ................................. 23
10.2. Informative References ............................... 23
11. Editor's Address ...................................... 24
12. Acknowledgments ....................................... 25
Appendix A. Relation of SASL to transport security .......... 25
Appendix B. Changes since RFC 2222 .......................... 26
Appendix C. Full Copyright Statement and Intellectual
Property Statement .............................. 28
Full Copyright Statement .................................... 28
Intellectual Property ....................................... 29
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/