draft-ietf-sasl-rfc2222bis-11.txt   draft-ietf-sasl-rfc2222bis-12.txt 
INTERNET-DRAFT A. Melnikov, Ed. INTERNET-DRAFT A. Melnikov, Ed.
Intended Category: Standards Track ISODE Limited Intended Category: Standards Track ISODE Limited
Expires in six months K. Zeilenga, Ed. Expires in six months K. Zeilenga, Ed.
Obsoletes: RFC 2222 OpenLDAP Project Obsoletes: RFC 2222 OpenLDAP Project
1 June 2005 28 October 2005
Simple Authentication and Security Layer (SASL) Simple Authentication and Security Layer (SASL)
<draft-ietf-sasl-rfc2222bis-11.txt> <draft-ietf-sasl-rfc2222bis-12.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I accept the provisions of Section By submitting this Internet-Draft, each author represents that any
3 of BCP 78. By submitting this Internet-Draft, each author applicable patent or other IPR claims of which he or she is aware have
represents that any applicable patent or other IPR claims of which he been or will be disclosed, and any of which he or she becomes aware
or she is aware have been or will be disclosed, and any of which he or will be disclosed, in accordance with Section 6 of BCP 79.
she becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
skipping to change at page 5, line 45 skipping to change at page 5, line 42
representations may (and often are) used within implementations. How representations may (and often are) used within implementations. How
identities of different forms relate to each other is, generally, a identities of different forms relate to each other is, generally, a
local matter. Additionally, the forms and representations used within local matter. Additionally, the forms and representations used within
an implementation is a local matter. an implementation is a local matter.
However, conceptually, 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).
The client provides its credentials and, optionally, a character SASL mechanism specifications describe the credential form(s) (e.g.,
string representing the requested authorization identity as part of X.509 certificates, Kerberos tickets, simple username/password) used
the SASL exchange. When this string is omitted or empty, the client to authenticate the client, including (where appropriate) the syntax
and semantics of associated authentication identities. SASL protocol
specifications describe the identity form(s) used in authorization
and, in particular, prescribe the syntax and semantics of the
authorization identity character string to be transferred by
mechanisms.
The client provides its credentials which (implicitly or explicitly)
include an authentication identity and, optionally, a character string
representing the requested authorization identity as part of the SASL
exchange. When this character string is omitted or empty, the client
is requesting to act as the identity associated with the credentials 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 client is allowed to act as the authorization verifying that the client is allowed to act as the authorization
identity. A SASL exchange fails if either (or both) of these identity. A SASL exchange fails if either (or both) of these
verifications fails. (The SASL exchange may fail for other reasons, verifications fails. (The SASL exchange may fail for other reasons,
such as service authorization failure.) such as service authorization failure.)
SASL mechanism specifications describe the credential form(s) (e.g.,
X.509 certificates, Kerberos tickets, simple username/password) used
to authenticate the client, including (where appropriate) the syntax
and semantics of associated identities. SASL protocol specifications
describe the identity form(s) used in authorization and, in
particular, prescribe the syntax and semantics of the authorization
identity character string to be transferred by mechanisms.
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) is beyond the scope of SASL and this
specification. In some circumstances, the precise identity forms used specification. In some circumstances, the precise identity forms used
in some context outside of the SASL exchange may be dictated by other in some context outside of the SASL exchange may be dictated by other
specifications. For instance, an identity assumption authorization specifications. For instance, an identity assumption authorization
(proxy authorization) policy specification may dictate how (proxy authorization) policy specification may dictate how
authentication and authorization identities are represented in the authentication and authorization identities are represented in policy
policy statement. 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 pairs of challenges from servers and responses from followed by one or more pairs of challenges from servers and responses
clients, followed by a message from the server indicating the outcome from clients, followed by a message from the server indicating the
of the authentication exchange. (Note: exchanges may also be aborted outcome of the authentication exchange. (Note: exchanges may also be
as discussed in Section 3.5.) 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 data layer was negotiated, this If the outcome is successful and a security layer was negotiated, this
layer is then installed. Protocols may allow this data to be carried layer is then installed (see Section 3.7). This applies as well to
in the request message. This applies as well to the following the following illustrations.
illustrations.
Some mechanisms specify that the first data sent in the authentication Some mechanisms specify that the first data sent in the authentication
exchange is from the client to the server. Protocols may provide an exchange is from the client to the server. Protocols may provide an
optional initial response field in the request message to carry this optional initial response field in the request message to carry this
data. Where the mechanism specifies the first data data sent in the data. Where the mechanism specifies the first data sent in the
exchange is from the client to the server, the protocol provides an exchange is from the client to the server, the protocol provides an
optional initial response field, and the client uses this field, the optional initial response field, and the client uses this field, the
exchange is shortened by one round-trip: 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 the first data sent in the exchange is
from the client to the server and this field is unavailable or unused, from the client to the server and this field is unavailable or unused,
skipping to change at page 7, line 48 skipping to change at page 7, line 45
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 the server is to return additional data
to the client with a successful outcome and and this field is to the client with a successful outcome and this field is unavailable
unavailable or unused, the additional data is sent as a challenge or unused, the additional data is sent as a challenge whose response
whose response is empty. After receiving this response, the server is empty. After receiving this response, the server then indicates
then indicates the successful outcome. 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 the first data sent in the exchange is from
skipping to change at page 9, line 21 skipping to change at page 9, line 20
and available mechanisms to the client via some facility provided by and available mechanisms to the client via some facility provided by
the protocol and the client will then select the "best" mechanism from the protocol and the client will then select the "best" mechanism from
this list which its supports and finds suitable. this list which its supports and finds suitable.
It is noted that the mechanism negotiation is not protected by the It is noted 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 may allow the client to To detect downgrade attacks, a protocol may allow the client to
discover available mechanism subsequent to the authentication exchange discover available mechanism subsequent to the authentication exchange
(and, hence, protected by any data security layer provided by and installation of data security layers with at least integrity
mechanism) so that downgrade attacks can be detected. protection. This allows the client to detect changes to 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 It is noted 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 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 first,
and the protocol's request message includes an optional initial and the protocol's request message includes an optional initial
response field, the client may include the response to the initial response field, the client may include the response to the initial
challenge in the authentication request message. challenge in the authentication request message.
3.4. Challenges and Responses 3.4. Challenges and Responses
The authentication exchange involves pairs of server-challenges and The authentication exchange involves one or more pairs of
client-responses, the particulars of which are mechanism specific. server-challenges and client-responses, the particulars of which are
These challenges and responses are enclosed in protocol messages, the mechanism specific. These challenges and responses are enclosed in
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 will
be provided, and negotiation of a maximum cipher-text buffer size each be provided, and negotiation of a maximum cipher-text buffer size each
size is able to receive in the layer (see Section 3.6). 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,
skipping to change at page 10, line 35 skipping to change at page 10, line 33
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 Non-empty authorization identity string indicates the client wishes to
act as the identity represented by the string. In this case, the form act as the identity represented by the string. In this case, the form
of identity represented by the string, as well as the precise syntax of identity represented by the string, as well as the precise syntax
and semantics of the string, is protocol specific. and semantics of the string, is protocol specific.
While character encoding schema used to transfer the authorization While the character encoding schema used to transfer the authorization
identity string in the authentication exchange is mechanism specific, identity string in the authentication exchange is mechanism specific,
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). 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,
skipping to change at page 11, line 29 skipping to change at page 11, line 27
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 are not - the identity associated with the client's credentials are 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, - the negotiated security layer (or lack thereof) is not suitable,
or or
- the server is not willing to provide service to the client for any - the server is not willing to provide service to the client for any
reason. 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. outcome message. This field can only include additional data when the
outcome is successful.
If the outcome is successful and a security layer was negotiated, this If the outcome is successful and a security layer was negotiated, this
layer is then installed. If the outcome is unsuccessful, or a 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.
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 confidentiality. Typical services include data integrity and data confidentiality.
skipping to change at page 12, line 11 skipping to change at page 12, line 11
layer is installed before transfer of further protocol data. The layer is installed before transfer of further protocol data. The
precise position that the layer takes effect in the protocol data precise position that the layer takes effect in the protocol data
stream is protocol specific. 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 to continue producing buffers protecting protocol data, the unable or unwilling to continue producing buffers protecting protocol
underlying transport connection MUST be closed. If the security layer data, the underlying transport connection MUST be closed. If the
is not able to decode a received buffer, the underlying connection security layer is not able to decode a received buffer, the underlying
MUST be closed. In both cases the underlying transport connection connection MUST be closed. In both cases the underlying transport
SHOULD be closed gracefully. 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 the other side expects. Upon the receipt of a
length field whose value is greater than maximum size, the receiver length field whose value is greater than maximum size, the receiver
SHOULD close the connection, as this might be a sign of an attack. SHOULD close the connection, as this might be a sign of an attack.
The maximum size for each side expects is fixed by the mechanism, The maximum size for each side expects is fixed by the mechanism,
skipping to change at page 13, line 11 skipping to change at page 13, line 11
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 effected. Regardless of the protocol-specific
effect upon previously established authentication and authorization effect upon previously established authentication and authorization
state, the previously negotiated security layer remains in effect. 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 MUST
supply the following information: supply the following information:
1) A service name, to be selected from the IANA registry of "service" 1) A service name, to be selected from registry of "service" elements
elements for the GSSAPI host-based service name form [RFC2743]. for the GSSAPI host-based service name form, as described in
Section 4.1 of [RFC2743]. Note that this registry is shared by all
GSSAPI and SASL mechanisms.
2) Detail any mechanism negotiation facility the protocol provides 2) Detail any mechanism negotiation facility the protocol provides
(see Section 3.2). (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 of
the SASL mechanisms the server makes available to the client. The the SASL mechanisms the server makes available to the client. The
latter is important to allow the client to detect downgrade latter is important to allow the client to detect downgrade
attacks. This facility is typically provided through the attacks. This facility is typically provided through the
skipping to change at page 14, line 19 skipping to change at page 14, line 19
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 of
carrying arbitrary sequences of octets (including zero length carrying arbitrary sequences of octets (including zero length
sequences and sequences containing zero-valued octets). 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
normalizations, the protocol specification MUST detail precisely
the how and where (client or server) non-\mpty authorization
identity strings are prepared, including all normalizations, for
comparison and other applicable functions to ensure proper
function.
Specifications are encouraged to prescribe use of existing 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]. Protocols representations, such as simple user names [RFC4013].
whose authorization identities are simple user names SHOULD use of
SASLprep [RFC4013] (a profile of the StringPrep [RFC3454]
preparation algorithm) as their preparation algorithm.
Where the specification does not precisely prescribe how identities Where the specification does not precisely prescribe how identities
in SASL relate to identities used elsewhere in the protocol, for in SASL relate to identities used elsewhere in the protocol, for
instance in access control policy statements, it may be appropriate instance in access control policy statements, it may be appropriate
for the protocol to provide a facility by which the client may for the protocol to provide a facility by which the client can
discover information (such as the representation of the discover information (such as the representation of the
authentication identity used in making access control decisions) authentication identity used in making access control decisions)
about established identities for these uses. about 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 which support multiple authentications typically allow a
client to abort an on-going authentication exchange by initiating a client to abort an on-going authentication exchange by initiating a
new authentication exchange. Protocols which do not support new authentication exchange. Protocols which do not support
skipping to change at page 17, line 16 skipping to change at page 17, line 19
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 UTF-8 transformation format [RFC3629] for
encoding Unicode [Unicode] code points for transfer. 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 is to be normalizations, when a mechanism calls for character data (other than
used as input to a cryptographic and/or comparison function, the the authorization identity string) is to be used as input to a
specification MUST detail precisely how and where (client or server) cryptographic and/or comparison function, the specification MUST
the character data is to be prepared, including all normalizations, detail precisely how and where (client or server) the character data
for input into the function to ensure proper operation. is to be prepared, including all normalizations, for input into the
function to ensure proper operation.
For simple user names and/or passwords in authentication credentials, 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 be no requirement that the authorization identity string be canonical.
non-canonical. Long-term, here, means a term longer than the duration Long-term, here, means a term longer than the duration of the
of the authentication exchange in which they were generated in. That authentication exchange in which they were generated in. That is, as
is, as different clients (of the same or different protocol) may different clients (of the same or different protocol) may provide
provide different authorization identity strings which are different authorization identity strings which are semantically
semantically equivalent, use of authorization identity strings in equivalent, use of authorization identity strings in generation of
generation of cryptographic keys and hashes will likely lead to cryptographic keys and hashes will likely lead to interoperability and
interoperability and other problems. 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, against the against passive attacks, let alone active attacks, against the
authentication exchange. Many existing SASL mechanisms do not offer authentication exchange. Many existing SASL mechanisms do not offer
any security layers. It is hoped that future SASL mechanisms will any security layers. It is hoped that future SASL mechanisms will
provide strong protection against passive and active attacks in the provide strong protection against passive and active attacks in the
skipping to change at page 18, line 18 skipping to change at page 18, line 21
protective services (e.g., TLS) external to SASL to protect against protective services (e.g., TLS) external to SASL to protect against
downgrade attacks in SASL. This is especially true when the downgrade attacks in SASL. This is especially true when the
mechanisms available to the client do not themselves offer adequate mechanisms available to the client do not themselves offer adequate
integrity or confidentiality protection of the authentication exchange integrity or confidentiality protection of the authentication exchange
and/or protocol data. and/or protocol data.
6.1. Active Attacks 6.1. Active Attacks
6.1.1. Man-in-the-middle Attacks 6.1.1. Man-in-the-middle Attacks
When the client selects a security layer with at least integrity When the client selects a SASL 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 protocol data sent after the authentication
plain-text connection. In this case, it is important that any exchange. In this case, it is important that any security-sensitive
security-sensitive protocol negotiations be performed after protocol negotiations be performed after the security layer is
authentication is complete. Protocols should be designed such that installed. Protocols should be designed such that negotiations
negotiations performed prior to authentication should be either performed prior to the installation should be either ignored or
ignored or revalidated once authentication is complete. revalidated once installation is complete. Negotiation of the SASL
mechanism is a security-sensitive negotiations.
Negotiation of the SASL mechanism, initiation of the SASL exchange,
and portions of the SASL authentication exchange itself are
security-sensitive negotiations.
When a server or client allows negotiation of authentication When a server or client negotiates the authentication mechanisms
mechanisms and/or other security features, it is possible for an and/or other security features, it is possible for an active attacker
active attacker to cause a party to use the least secure services to cause a party to use the least secure security services available.
supported. For instance, an attacker can modify the server-advertised For instance, an attacker can modify the server-advertised mechanism
mechanism list or can modify client-advertised security feature list list or can modify client-advertised security feature list within a
within a mechanism response. To protect against this sort of attack, 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 which
cannot meet their minimum security requirements, should not enter into cannot meet their minimum security requirements, should not enter into
or continue authentication exchanges which cannot meet their minimum or continue authentication exchanges which cannot meet their minimum
security requirements, and should verify that completed authentication security requirements, and should verify that completed authentication
exchanges meets their minimum security requirements. Note that each exchanges result in security services that meet their minimum security
endpoint needs to independently verify that its security requirements requirements. Note that each endpoint needs to independently verify
are met. 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 may discover the SASL mechanisms the
server makes available both before the SASL authentication exchange server makes available both before the SASL authentication exchange
and after the negotiated SASL security layer (with at least integrity and after the negotiated SASL security layer (with at least integrity
protection) has been installed through the protocol's mechanism protection) has been installed through the protocol's mechanism
discovery facility. If the client finds that the integrity protected discovery facility. If the client finds that the integrity protected
list (the list obtained after the security layer was installed) list (the list obtained after the security layer was installed)
contains a stronger mechanism than those in the previously obtained contains a stronger mechanism than those in the previously obtained
list, the client should assume the previously obtained list was list, the client should assume the previously obtained list was
skipping to change at page 20, line 43 skipping to change at page 20, line 44
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 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.
This approach requires support for reauthentication in the application This approach requires support for reauthentication in the application
protocols (see Section 3.8). protocols (see Section 3.8).
6.5. Other Considerations 6.5. Other Considerations
Unicode security considerations [UTR36] apply to authorization
identity strings, and well as UTF-8 [RFC3629] security considerations
where UTF-8 is used. SASLprep [RFC4013] and StringPrep [RFC3454]
security considerations also apply where used.
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 which are
applicable to their needs. applicable to their needs.
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 SASL
mechanism negotiation). mechanism negotiation).
Unicode security considerations [UTR36] apply to authorization
identity strings, and well as UTF-8 [RFC3629] security considerations
where UTF-8 is used. SASLprep [RFC4013] and StringPrep [RFC3454]
security considerations also apply where used.
7. IANA Considerations 7. IANA Considerations
7.1. SASL Mechanism Registry 7.1. SASL Mechanism Registry
SASL mechanism registry is maintained by IANA. The registry is SASL mechanism registry is maintained by IANA. The registry is
currently available at currently available at
<http://www.iana.org/assignments/sasl-mechanisms>. <http://www.iana.org/assignments/sasl-mechanisms>.
It is requested update this registry to reflect that this document
provides the definitive technical specification for SASL and that this
section provides the registration procedures for this registry.
7.1.1. Registration Procedure 7.1.1. Registration Procedure
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:
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):
skipping to change at page 29, line 28 skipping to change at page 29, line 32
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 Full Copyright
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2005).
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. 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 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.
 End of changes. 30 change blocks. 
96 lines changed or deleted 107 lines changed or added

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