gsasl-commit
[Top][All Lists]
Advanced

[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]




reply via email to

[Prev in Thread] Current Thread [Next in Thread]