[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: |
Mon, 21 Feb 2005 01:27:24 +0100 |
Update of /home/cvs/gsasl/doc/specification
In directory dopio:/tmp/cvs-serv12482
Added Files:
draft-ietf-sasl-rfc2222bis-10.txt
Log Message:
Add.
--- /home/cvs/gsasl/doc/specification/draft-ietf-sasl-rfc2222bis-10.txt
2005/02/21 00:27:24 NONE
+++ /home/cvs/gsasl/doc/specification/draft-ietf-sasl-rfc2222bis-10.txt
2005/02/21 00:27:24 1.1
Network Working Group A. Melnikov
Internet Draft Editor
Document: draft-ietf-sasl-rfc2222bis-10.txt February 2005
Obsoletes: RFC 2222 Expires in six months
Simple Authentication and Security Layer (SASL)
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
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
RFC 3668.
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. Internet Drafts may be updated, replaced, or obsoleted
by other documents at any time. It is not appropriate 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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
A revised version of this draft document will be submitted to the RFC
editor as a Standards Track RFC for the Internet Community.
Discussion and suggestions for improvement are requested.
Distribution of this draft is unlimited.
When published as an RFC this document will obsolete RFC 2222.
A. Melnikov FORMFEED[Page i]
Internet DRAFT SASL 16 February 2005
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
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 add 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.
1. Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
in this document are to be interpreted as defined in "Key words for
use in RFCs to Indicate Requirement Levels" [KEYWORDS].
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>.
This document uses terms "integrity protection" and "confidentiality
protection". The former refers to a security layer (see Section
"Introduction" below for the definition) designed to provide "data
integrity service" as defined in [Sec-Glossary]. Confidentiality
protection is a security layer that provides "data confidentiality
service" as defined in [Sec-Glossary]. The term "confidentiality
protection" implies "integrity protection". Security layers may offer
other kinds of security services, for example re-keying, truncation
detection, as well as other services, e.g. compression.
2. 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
A. Melnikov FORMFEED[Page 2]
Internet DRAFT SASL 16 February 2005
exchanges within a data security layer.
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.
The SASL is conceptually a framework which provides a layer between
protocols and mechanisms, as illustrated in the following diagram.
SMTP Protocol LDAP Protocol Other Protocols
Profile Profile . . .
\----- | -----/
\ | /
SASL framework
/ | \
/----- | -----\
DIGEST-MD5 EXTERNAL Other Mechanisms
SASL mechanism SASL mechanism . . .
It is through the interfaces of this layer that the framework allows
any protocol to be utilized with any mechanism. While the layer does
generally hide the particulars of protocols from mechanisms and the
particulars of mechanisms from protocols, the 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 have to implement a
mapping from a mechanism-specific authentication identity format to a
protocol-specific format.
It is possible to design and implement this framework in ways which
do abstract away particulars of similar mechanisms. Such
implementation could also be designed to be shared by multiple
implementations of various protocols.
As illustrated above, the SASL framework interfaces with both
protocols and mechanisms.
To use SASL, a protocol includes a command for identifying and
authenticating a user to a server and for optionally negotiating a
security layer for subsequent protocol interactions. If the use of a
security layer is negotiated, that security layer is inserted between
the protocol and the connection. Section 4 ("Protocol profile
requirements") profiles the requirements that a protocol
A. Melnikov FORMFEED[Page 3]
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.
A SASL mechanism is a series of server challenges and client
responses specific to the mechanism. Each SASL mechanism is
identified by a registered name. Section 5 ("Mechanism profile
guidelines") profiles the requirements that a mechanism specification
must fulfill to define a SASL mechanism.
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 using this
specification.
The sections "Authentication mechanisms", "Protocol profile
requirements", "Specific issues", and "Security considerations" cover
issues that protocol designers need to understand and address in
profiling this specification for use in a specific protocol.
The sections "Authentication mechanisms", "Mechanism profile
guidelines", "Security considerations" and "Registration procedure"
cover issues that mechanism designers need to understand and address
in designing new SASL mechanisms.
The sections "Authentication mechanisms", "Protocol profile
requirements", "Specific issues" and "Security considerations" cover
issues that implementors of a protocol that uses SASL framework need
to understand. The implementors will also need to understand a
specification of a SASL profile specific to the protocol, as well as
aspects of mechanism specifications they intend to use (regardless of
whether they are implementing the mechanisms themselves or using an
existing implementation) to understand, for instance, the mechanism-
specific authentication identity forms, the offered services, and
security and other considerations.
2.1. Relationship to other documents
This document obsoletes RFC 2222. It replaces all portions of RFC
2222 excepting sections 7.1 (Kerberos version 4 mechanism), 7.2
(GSSAPI mechanism), 7.3 (S/Key mechanism). The Kerberos version 4
(KERBEROS_IV) and S/Key (SKEY) mechanisms are now viewed as obsolete.
The GSSAPI mechanism is now separately specified [SASL-GSSAPI].
A. Melnikov FORMFEED[Page 4]
Internet DRAFT SASL 16 February 2005
3. Authentication mechanisms
SASL mechanisms are named by strings, from 1 to 20 characters in
length, consisting of ASCII [ASCII] upper-case letters, digits,
hyphens, and/or underscores. Names of SASL mechanisms or families of
mechanisms must be registered with the Internet Assigned Numbers
Authority (IANA) as described in section 8.2.
The "sasl-mech" ABNF production below defines the syntax of a SASL
mechanism name. This uses the Augmented Backus-Naur Form (ABNF)
notation as specified in [ABNF].
sasl-mech = 1*20mech-char
mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE
; mech-char is restricted to "A"-"Z", "0"-"9", "-",
; and "_" from ASCII character set.
UPPER-ALPHA = %x41-5A
; "A"-"Z"
DIGIT = %x30-39
; "0"-"9"
HYPHEN = %x2D
; "-"
UNDERSCORE = %x5F
; "_"
3.1. Authentication Exchange
A SASL mechanism is responsible for conducting an authentication
exchange. This consists of a series of server challenges and client
responses, the contents of which are specific to and defined by the
mechanism. To the application protocol, the challenges and responses
are opaque binary tokens of arbitrary length (including 0-length).
The protocol's profile then specifies how these binary tokens are
encoded for transfer over the connection.
After receiving an authentication command or any client response, a
server mechanism may issue a challenge, indicate failure, or indicate
completion. The server mechanism may return additional data with a
completion indication. The protocol's profile specifies how each of
these is then represented over the connection.
After receiving a challenge, a client mechanism may issue a response
or abort the exchange. The protocol's profile specifies how each of
A. Melnikov FORMFEED[Page 5]
Internet DRAFT SASL 16 February 2005
these are then represented over the connection.
During the authentication exchange, the mechanism performs
authentication, transmits an authorization identity (sometimes known
as a username) from the client to server, and may negotiate the use
of a mechanism-specific security layer. If the use of a security
layer is agreed upon, then the mechanism must also define or
negotiate the maximum security layer buffer size that each side is
able to receive.
3.2. Identity Concepts
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).
The client provides its credentials and, optionally, a string
representing the requested authorization identity as part of the SASL
exchange. When this 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.
SASL mechanism specifications describe the form of credentials used
to authenticate clients, and SASL application profiles describe the
form of authorization identities transferred as part of
authentication exchange. 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 the SASL and this specification.
In some circumstances, the precise identity forms used outside of the
SASL exchange may be dictated by other 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.
<<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
A. Melnikov FORMFEED[Page 6]
Internet DRAFT SASL 16 February 2005
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
authorization identity (e.g. the mechanism can't apply any form of
normalization).
3.2.1. Authorization identities and proxy authentication
A mechanism which is incapable of transmitting an authorization
identity must be treated as if it always transmits an authorization
identity of an empty string.
If the authorization identity transmitted during the authentication
exchange is not the empty string, this is typically referred to as
"proxy authentication". This feature permits agents such as proxy
servers to authenticate using their own credentials, yet request the
access privileges of the identity for which they are proxying.
The server makes an implementation-defined policy decision as to
whether the authentication identity is permitted to have the access
privileges of the authorization identity and whether the
authorization identity is permitted to receive service. If it is
not, the server indicates failure of the authentication exchange.
As a client might not have the same information as the server,
clients SHOULD NOT derive authorization identities from
authentication identities. Instead, clients SHOULD provide no (or
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
[1395 lines skipped]
- CVS gsasl/doc/specification,
gsasl-commit <=