draft-ietf-sasl-rfc2222bis-14.txt   draft-ietf-sasl-rfc2222bis-15.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: July 2006 K. Zeilenga, Ed.
Obsoletes: RFC 2222 OpenLDAP Project Obsoletes: RFC 2222 OpenLDAP Project
17 November 2005 23 January 2006
Simple Authentication and Security Layer (SASL) Simple Authentication and Security Layer (SASL)
<draft-ietf-sasl-rfc2222bis-14.txt> <draft-ietf-sasl-rfc2222bis-15.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware been or will be disclosed, and any of which he or she becomes aware
will be disclosed, in accordance with Section 6 of BCP 79. 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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
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
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2006). All Rights Reserved.
Please see the Full Copyright section near the end of this document Please see the Full Copyright section near the end of this document
for more information. for more information.
Abstract Abstract
The Simple Authentication and Security Layer (SASL) is a framework for The Simple Authentication and Security Layer (SASL) is a framework for
providing authentication and data security services in 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
skipping to change at page 5, line 45 skipping to change at page 5, line 45
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).
SASL mechanism specifications describe the credential form(s) (e.g., SASL mechanism specifications describe the credential form(s) (e.g.,
X.509 certificates, Kerberos tickets, simple username/password) used X.509 certificates, Kerberos tickets, simple username/password) used
to authenticate the client, including (where appropriate) the syntax to authenticate the client, including (where appropriate) the syntax
and semantics of associated authentication identities. SASL protocol and semantics of authentication identities carried in the credentials.
specifications describe the identity form(s) used in authorization SASL protocol specifications describe the identity form(s) used in
and, in particular, prescribe the syntax and semantics of the authorization and, in particular, prescribe the syntax and semantics
authorization identity character string to be transferred by of the authorization identity character string to be transferred by
mechanisms. mechanisms.
The client provides its credentials which (implicitly or explicitly) The client provides its credentials (which include or imply an
include an authentication identity and, optionally, a character string authentication identity) and, optionally, a character string
representing the requested authorization identity as part of the SASL representing the requested authorization identity as part of the SASL
exchange. When this character string is omitted or empty, the client exchange. When this character string is omitted or empty, the client
is requesting to act as the identity associated with the credentials is requesting to act as the identity associated with the credentials
(e.g., the user is requesting to act as the authentication identity). (e.g., the user is requesting to act as the authentication identity).
The server is responsible for verifying the client's credentials and The server is responsible for verifying the client's credentials and
verifying that the client is allowed to act as the authorization verifying that the identity it associates with the client's
identity. A SASL exchange fails if either (or both) of these credentials (e.g., the authentication identity) is allowed to act as
verifications fails. (The SASL exchange may fail for other reasons, the authorization identity. A SASL exchange fails if either (or both)
such as service authorization failure.) of these verifications fails. (The SASL exchange may fail for other
reasons, such as service authorization failure.)
However, the precise form(s) of the authentication identities (used 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 policy authentication and authorization identities are represented in policy
skipping to change at page 8, line 13 skipping to change at page 8, line 14
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
the client to the server and additional data is sent to the client the client to the server and additional data is sent to the client
along with indicating a successful outcome, and the protocol provides along with indicating a successful outcome, and the protocol provides
fields supporting both, the exchange can be shorted by two fields supporting both, then the exchange takes two fewer round-trips:
round-trips:
C: Request authentication exchange + Initial response C: Request authentication exchange + Initial response
<additional challenge/response messages> <additional challenge/response messages>
S: Outcome of authentication exchange S: Outcome of authentication exchange
with additional data with success with additional data with success
instead of: instead of:
C: Request authentication exchange C: Request authentication exchange
S: Empty Challenge S: Empty Challenge
skipping to change at page 14, line 46 skipping to change at page 14, line 46
function. function.
Specifications are encouraged to prescribe use of existing Specifications are encouraged to prescribe use of existing
authorization identity forms as well as existing string authorization identity forms as well as existing string
representations, such as simple user names [RFC4013]. representations, such as simple user names [RFC4013].
Where the specification does not precisely prescribe how identities Where the specification does not precisely prescribe how 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 can 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 identity
authentication identity used in making access control decisions) used in making access control decisions) about established
about established identities for these uses. 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
multiple authentications may require the client to close the multiple authentications may require the client to close the
connection and start over to abort an on-going authentication connection and start over to abort an on-going authentication
exchange. exchange.
skipping to change at page 16, line 28 skipping to change at page 16, line 28
SASL mechanism specifications MUST supply the following information: SASL mechanism specifications MUST supply the following information:
1) The name of the mechanism (see Section 3.1). This name MUST be 1) The name of the mechanism (see Section 3.1). This name MUST be
registered as discussed in Section 7.1. registered as discussed in Section 7.1.
2) A definition of the server-challenges and client-responses of the 2) A definition of the server-challenges and client-responses of the
authentication exchange, as well as: authentication exchange, as well as:
a) An indication whether mechanism is client-first, variable, or a) An indication whether mechanism is client-first, variable, or
server-first. If a SASL mechanism is defined as client-first server-first. If a SASL mechanism is defined as client-first
and the client does not send an initial response, then the first and the client does not send an initial response in the
server challenge MUST be empty (the EXTERNAL mechanism is an authentication request, then the first server challenge MUST be
example of this case). If a SASL mechanism is defined as empty (the EXTERNAL mechanism is an example of this case). If a
variable, then the specification needs to state how the server SASL mechanism is defined as variable, then the specification
behaves when the initial client response is omitted (the needs to state how the server behaves when the initial client
response in the authentication request is omitted (the
DIGEST-MD5 mechanism [DIGEST-MD5] is an example of this case). DIGEST-MD5 mechanism [DIGEST-MD5] is an example of this case).
If a SASL mechanism is defined as server-first then the client If a SASL mechanism is defined as server-first then the client
MUST NOT send an initial client response (the CRAM-MD5 mechanism MUST NOT send an initial client response in the authentication
[CRAM-MD5] is an example of this case). request (the CRAM-MD5 mechanism [CRAM-MD5] is an example of this
case).
b) An indication whether the server is expected to provide b) An indication whether the server is expected to provide
additional data when indicating a successful outcome. If so, if additional data when indicating a successful outcome. If so, if
the server sends the additional data as a challenge, the the server sends the additional data as a challenge, the
specification MUST indicate the response to this challenge is an specification MUST indicate the response to this challenge is an
empty response. empty response.
SASL mechanisms SHOULD be designed to minimize the number of SASL mechanisms SHOULD be designed to minimize the number of
challenges and responses necessary to complete the exchange. challenges and responses necessary to complete the exchange.
skipping to change at page 19, line 10 skipping to change at page 19, line 13
When the client selects a SASL security layer with at least integrity When the client selects a SASL security layer with at least integrity
protection, this protect serves as a counter-measure against an active protection, this protect serves as a counter-measure against an active
attacker hijacking the connection and modifying protocol data sent attacker hijacking the connection and modifying protocol data sent
after establishment of the security layer. Implementations should after establishment of the security layer. Implementations should
close the connection when the security services in an SASL security close the connection when the security services in an SASL security
layer report protocol data report lack of data integrity. layer report protocol data report lack of data integrity.
6.1.2. Downgrade Attacks 6.1.2. Downgrade Attacks
It is important that any security-sensitive protocol negotiations be It is important that any security-sensitive protocol negotiations be
performed after installation of security layer with data integrity performed after installation of a security layer with data integrity
protection. Protocols should be designed such that negotiations protection. Protocols should be designed such that negotiations
performed prior to this installation should be revalidated after performed prior to this installation should be revalidated after
installation is complete. Negotiation of the SASL mechanism is installation is complete. Negotiation of the SASL mechanism is
security-sensitive. security-sensitive.
When a client negotiates the authentication mechanism with the server When a client negotiates the authentication mechanism with the server
and/or other security features, it is possible for an active attacker and/or other security features, it is possible for an active attacker
to cause a party to use the least secure security services available. to cause a party to use the least secure security services available.
For instance, an attacker can modify the server-advertised mechanism For instance, an attacker can modify the server-advertised mechanism
list or can modify client-advertised security feature list within a list or can modify client-advertised security feature list within a
skipping to change at page 31, line 42 skipping to change at page 31, line 44
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). Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. 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
 End of changes. 13 change blocks. 
28 lines changed or deleted 30 lines changed or added

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