rfc4422.txt

广泛使用的邮件服务器！同时

Network Working Group                                   A. Melnikov, Ed.
Request for Comments: 4422                                 Isode Limited
Obsoletes: 2222                                         K. Zeilenga, Ed.
Category: Standards Track                            OpenLDAP Foundation
                                                               June 2006


            Simple Authentication and Security Layer (SASL)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

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 include support for SASL, and defines the protocol for
   carrying a data security layer over a connection.  In addition, this
   document defines one SASL mechanism, the EXTERNAL mechanism.

   This document obsoletes RFC 2222.













Melnikov & Zeilenga         Standards Track                     [Page 1]

RFC 4422                          SASL                         June 2006


Table of Contents

   1. Introduction ....................................................3
      1.1. Document Audiences .........................................4
      1.2. Relationship to Other Documents ............................4
      1.3. Conventions ................................................5
   2. Identity Concepts ...............................................5
   3. The Authentication Exchange .....................................6
      3.1. Mechanism Naming ...........................................8
      3.2. Mechanism Negotiation ......................................9
      3.3. Request Authentication Exchange ............................9
      3.4. Challenges and Responses ...................................9
           3.4.1. Authorization Identity String ......................10
      3.5. Aborting Authentication Exchanges .........................10
      3.6. Authentication Outcome ....................................11
      3.7. Security Layers ...........................................12
      3.8. Multiple Authentications ..................................12
   4. Protocol Requirements ..........................................13
   5. Mechanism Requirements .........................................16
   6. Security Considerations ........................................18
      6.1. Active Attacks ............................................19
           6.1.1. Hijack Attacks .....................................19
           6.1.2. Downgrade Attacks ..................................19
           6.1.3. Replay Attacks .....................................20
           6.1.4. Truncation Attacks .................................20
           6.1.5. Other Active Attacks ...............................20
      6.2. Passive Attacks ...........................................20
      6.3. Re-keying .................................................21
      6.4. Other Considerations ......................................21
   7. IANA Considerations ............................................22
      7.1. SASL Mechanism Registry ...................................22
      7.2. Registration Changes ......................................26
   8. References .....................................................26
      8.1. Normative References ......................................26
      8.2. Informative References ....................................27
   9. Acknowledgements ...............................................28
   Appendix A.  The SASL EXTERNAL Mechanism ..........................29
      A.1. EXTERNAL Technical Specification ..........................29
      A.2. SASL EXTERNAL Examples ....................................30
      A.3. Security Considerations ...................................31
   Appendix B.  Changes since RFC 2222 ...............................31










Melnikov & Zeilenga         Standards Track                     [Page 2]

RFC 4422                          SASL                         June 2006


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 that 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 that 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 to be shared by implementations of multiple
   protocols.



Melnikov & Zeilenga         Standards Track                     [Page 3]

RFC 4422                          SASL                         June 2006


   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, 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 that 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 that
         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         Standards Track                     [Page 4]

RFC 4422                          SASL                         June 2006


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 be (and often are) used within implementations.
   How identities of different forms relate to each other is, generally,
   a local matter.  In addition, the forms and representations used
   within an implementation are a local matter.

   However, conceptually, the 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 authentication identities carried in the
   credentials.  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.




Melnikov & Zeilenga         Standards Track                     [Page 5]

RFC 4422                          SASL                         June 2006


   The client provides its credentials (which include or imply 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 identity it associates with the client's
   credentials (e.g., the authentication identity) 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) are 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.