[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CVS gsasl/doc/specification
From: |
gsasl-commit |
Subject: |
CVS gsasl/doc/specification |
Date: |
Sat, 12 Nov 2005 00:17:45 +0100 |
Update of /home/cvs/gsasl/doc/specification
In directory dopio:/tmp/cvs-serv22779
Added Files:
draft-ietf-sasl-rfc2222bis-13.txt
Log Message:
Add.
--- /home/cvs/gsasl/doc/specification/draft-ietf-sasl-rfc2222bis-13.txt
2005/11/11 23:17:45 NONE
+++ /home/cvs/gsasl/doc/specification/draft-ietf-sasl-rfc2222bis-13.txt
2005/11/11 23:17:45 1.1
INTERNET-DRAFT A. Melnikov, Ed.
Intended Category: Standards Track ISODE Limited
Expires in six months K. Zeilenga, Ed.
Obsoletes: RFC 2222 OpenLDAP Project
10 November 2005
Simple Authentication and Security Layer (SASL)
<draft-ietf-sasl-rfc2222bis-13.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware
will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2005). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Abstract
The Simple Authentication and Security Layer (SASL) is a framework for
providing authentication and data security services in
connection-oriented protocols via replaceable mechanisms. It provides
a structured interface between protocols and mechanisms. The
resulting framework allows new protocols to reuse existing mechanisms
Melnikov & Zeilenga SASL [Page 1]
INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-13.txt 10 November 2005
and allows old protocols to make use of new mechanisms. The framework
also provides a protocol for securing subsequent protocol exchanges
within a data security layer.
This document describes how a SASL mechanism is structured, describes
how protocols include support for SASL, and defines the protocol for
carrying a data security layer over a connection. Additionally, this
document defines one SASL mechanism, the EXTERNAL mechanism.
This document obsoletes RFC 2222.
Table of Contents
[[Page numbers to be filled in by RFC-Editor]]
Status of this Memo
Abstract
1. Introduction
1.1. Document Audiences
1.2. Relationship to Other Documents
1.3. Conventions
2. Identity Concepts
3. The Authentication Exchange
3.1. Mechanism Naming
3.2. Mechanism Negotiation
3.3. Request Authentication Exchange
3.4. Challenges and Responses
3.4.1. Authorization Identity String
3.5. Aborting Authentication Exchanges
3.6. Authentication Outcome
3.7. Security Layers
3.8. Multiple Authentications
4. Protocol Requirements
5. Mechanism Requirements
6. Security Considerations
6.1. Active Attacks
6.1.1. Man-in-the-middle Attacks
6.1.2. Replay Attacks
6.1.3. Truncation Attacks
6.2. Passive Attacks
6.3. Re-keying
6.4. Other considerations
7. IANA Considerations
8. References
9. Editors' Address
10. Acknowledgments
A. The SASL EXTERNAL Mechanism
B. Changes since RFC 2222
Melnikov & Zeilenga SASL [Page 2]
INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-13.txt 10 November 2005
1. Introduction
The Simple Authentication and Security Layer (SASL) is a framework for
providing authentication and data security services in
connection-oriented protocols via replaceable mechanisms. SASL
provides a structured interface between protocols and mechanisms.
SASL also provides a protocol for securing subsequent protocol
exchanges within a data security layer. The data security layer can
provide data integrity, data confidentiality, and other services.
SASL's design is intended to allow new protocols to reuse existing
mechanisms without requiring redesign of the mechanisms and allows
existing protocols to make use of new mechanisms without redesign of
protocols.
SASL is conceptually a framework which provides an abstraction layer
between protocols and mechanisms as illustrated in the following
diagram.
SMTP LDAP XMPP Other protocols ...
\ | | /
\ | | /
SASL abstraction layer
/ | | \
/ | | \
EXTERNAL GSSAPI PLAIN Other mechanisms ...
It is through the interfaces of this abstraction layer that the
framework allows any protocol to utilize any mechanism. While this
layer does generally hide the particulars of protocols from mechanisms
and the particulars of mechanisms from protocols, this layer does not
generally hide the particulars of mechanisms from protocol
implementations. For example, different mechanisms require different
information to operate, some of them use password-based
authentication, some of then require realm information, others make
use of Kerberos tickets, certificates, etc.. Also, in order to
perform authorization, server implementations generally have to
implement identity mapping between authentication identities, whose
form is mechanism-specific, and authorization identities, whose form
is application protocol specific. Section 2 discusses identity
concepts.
It is possible to design and implement this framework in ways which do
abstract away particulars of similar mechanisms. Such a framework
implementation, as well as mechanisms implementations, could be
designed not only to be shared by multiple implementations of a
particular protocol, but be shared by implementations of multiple
protocols.
Melnikov & Zeilenga SASL [Page 3]
INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-13.txt 10 November 2005
The framework incorporates interfaces with both protocols and
mechanisms in which authentication exchanges are carried out. Section
3 discusses SASL authentication exchanges.
To use SASL, each protocol (amongst other items) provides a method for
identifying which mechanism is to be used, provides a method for
exchange of mechanism-specific server-challenges and client-responses,
and a method for communicating the outcome of the authentication
exchange. Section 4 discusses SASL protocol requirements.
Each SASL mechanism defines (amongst other items) a series of server
challenges and client responses which provide authentication services
and negotiate data security services. Section 5 discusses SASL
mechanism requirements.
Section 6 discusses security considerations. Section 7 discusses IANA
considerations. Appendix A defines the SASL EXTERNAL mechanism.
1.1. Document Audiences
This document is written to serve several different audiences:
- protocol designers using this specification to support
authentication in their protocol,
- mechanism designers that define new SASL mechanisms, and
- implementors of clients or servers for those protocols which
support SASL.
While the document organization is intended to allow readers to focus
on details relevant to their engineering, readers are encouraged to
read and understand all aspects of this document.
1.2. Relationship to other documents
This document obsoletes RFC 2222. It replaces all portions of RFC
2222 excepting sections 7.1 (the KERBEROS_IV mechanism), 7.2 (the
GSSAPI mechanism), 7.3 (the SKEY mechanism). The KERBEROS_IV and SKEY
mechanisms are now viewed as obsolete and their specifications
provided in RFC 2222 are Historic. The GSSAPI mechanism is now
separately specified [SASL-GSSAPI].
Appendix B provides a summary of changes since RFC 2222.
Melnikov & Zeilenga SASL [Page 4]
INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-13.txt 10 November 2005
1.3. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
Character names in this document use the notation for code points and
names from the Unicode Standard [Unicode]. For example, the letter
"a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
Note: a glossary of terms used in Unicode can be found in [Glossary].
Information on the Unicode character encoding model can be found in
[CharModel].
In examples, "C:" and "S:" indicate lines of data to be sent by the
client and server respectively. Lines have been wrapped for improved
readability.
2. Identity Concepts
In practice, authentication and authorization may involve multiple
identities, possibly in different forms (simple username, Kerberos
principal, X.500 Distinguished Name, etc.), possibly with different
representations (e.g.: ABNF-described UTF-8 encoded Unicode character
string, BER-encoded Distinguished Name). While technical
specifications often prescribe both the identity form and
representation used on the network, different identity forms and/or
representations may (and often are) used within implementations. How
identities of different forms relate to each other is, generally, a
local matter. Additionally, the forms and representations used within
an implementation is a local matter.
However, conceptually, SASL framework involves two identities:
1) an identity associated with the authentication credentials
(termed the authentication identity), and
2) an identity to act as (termed the authorization identity).
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 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)
Melnikov & Zeilenga SASL [Page 5]
INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-13.txt 10 November 2005
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
(e.g., the user is requesting to act as the authentication identity).
The server is responsible for verifying the client's credentials and
verifying that the client is allowed to act as the authorization
identity. A SASL exchange fails if either (or both) 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
within the server in its verifications, or otherwise) and the precise
form(s) of the authorization identities (used in making authorization
decisions, or otherwise) is beyond the scope of SASL and this
specification. In some circumstances, the precise identity forms used
in some context outside of the SASL exchange may be dictated by other
specifications. For instance, an identity assumption authorization
(proxy authorization) policy specification may dictate how
authentication and authorization identities are represented in policy
statements.
3. The Authentication Exchange
Each authentication exchange consists of a message from the client to
the server requesting authentication via a particular mechanism,
followed by one or more pairs of challenges from the server and
responses from the client, followed by a message from the server
indicating the outcome of the authentication exchange. (Note:
exchanges may also be aborted as discussed in Section 3.5.)
The following illustration provides a high-level overview of an
authentication exchange.
C: Request authentication exchange
S: Initial challenge
C: Initial response
<additional challenge/response messages>
S: Outcome of authentication exchange
If the outcome is successful and a security layer was negotiated, this
layer is then installed (see Section 3.7). This also applies to the
following illustrations.
Some mechanisms specify that the first data sent in the authentication
exchange is from the client to the server. Protocols may provide an
Melnikov & Zeilenga SASL [Page 6]
INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-13.txt 10 November 2005
optional initial response field in the request message to carry this
data. Where the mechanism specifies the first data sent in the
exchange is from the client to the server, the protocol provides an
optional initial response field, and the client uses this field, the
exchange is shortened by one round-trip:
C: Request authentication exchange + Initial response
<additional challenge/response messages>
S: Outcome of authentication exchange
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,
the client request is followed by an empty challenge.
C: Request authentication exchange
S: Empty Challenge
C: Initial Response
<additional challenge/response messages>
S: Outcome of authentication exchange
Should a client include an initial response in its request where the
mechanism does not allow the client to send data first, the
authentication exchange fails.
Some mechanisms specify that the server is to send additional data to
the client when indicating a successful outcome. Protocols may
provide an optional additional data field in the outcome message to
carry this data. Where the mechanism specifies the server is to
return additional data with the successful outcome, the protocol
provides an optional additional data field in the outcome message, and
the server uses this field, the exchange is shortened by one
round-trip:
C: Request authentication exchange
S: Initial challenge
C: Initial response
<additional challenge/response messages>
S: Outcome of authentication exchange with
additional data with success
Where the mechanism specifies the server is to return additional data
to the client with a successful outcome and this field is unavailable
or unused, the additional data is sent as a challenge whose response
is empty. After receiving this response, the server then indicates
the successful outcome.
C: Request authentication exchange
S: Initial challenge
Melnikov & Zeilenga SASL [Page 7]
INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-13.txt 10 November 2005
C: Initial response
<additional challenge/response messages>
[1283 lines skipped]
- CVS gsasl/doc/specification,
gsasl-commit <=