[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03                                                   
Network Working Group                                         S.E. Kille
INTERNET-DRAFT                                                Isode Ltd.
Expires in six months                                         July 1998
Intended Category: Standard

                  X.509 Authentication SASL Mechanism

1.  Status of this Memo

This document is an Internet-Draft.  Internet-Drafts are working docu-
ments 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."

To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).

2.  Abstract

This document defines a SASL [1] authentication mechanism based on X.509
strong authentication [3], providing two way authentication.  This
mechanism is only for authentication, and has no effect on the protocol
encodings and is not designed to provide integrity or confidentiality

3.  Model

The mechanism provides two way strong authentication as defined in
X.509.  The encoding is based on on that used by X.500 in the DAP, DSP,
and DISP protocols.

The mechanism is based on use of an assymetric (public key) signing
mechanism.  The SASL mechanism contains two symmetric authentication

-    Client authentication is where the client provides information to
     the server, so that the server can authenticate the client.

-    Server authentication is where the server provides information to

Kille                                                   [Page 1]

Expires January 1999  IP X.509 SASL Authentication        INTERNET DRAFT

     the client, so that the client can authenticate the server.

This mechanism is given three  SASL keys for different variants:

-    "X509-CLIENT-<algorithm>" for client authentication only.

-    "X509-SERVER-<algorithm>" for sever authentication only.

-    "X509-BOTH-<algorithm>" for client and server authentication.  In
     this case client authentication is done prior to server authentica-

Each SASL key may be used with a list of algorithms.  Supported algo-
rithms in this version are "DSS", "RSA", and "X-<private>".

For Client Authentication ("X509-CLIENT"):

1.   The client generates the credentials (SASLStrongCredentials) using
     local information, and signs the enclosed token with its own
     private key.

2.   The client sends credentials to the server.

3.   The server verifies these credentials using the client's public
     key, and the authentication is complete.

For Serever Authentication ("X509-SERVER"):

1.   The server generates the credentials (SASLStrongCredentials) using
     local information, and signs the enclosed token with its own
     private key.

2.   The server sends credentials to the client.

3.   The client verifies these credentials using the server's public
     key, and the authentication is complete.

For Client and Server Authentication ("X509-BOTH"), the procedure for
"X509-CLIENT" is performed and then followed by the procedure for

3.1.  Encoding

The SASLStrongCredentials, which is the definition of the data format
exchanged,  is encoded using ASN.1 Basic Encoding Rules (BER).

Kille                                                   [Page 2]

Expires January 1999  IP X.509 SASL Authentication        INTERNET DRAFT

4.  Why this SASL Mechanism is Needed

This section discusses the requirements for this SASL mechanism.

4.1.  Benefits of a Public Key Mechanism

The key benefit of assymetric (public key) security, is that the secret
only needs to be placed with the entity that is being authenticated.
Thus a secret key can be given to a client, which can then be authenti-
cated by ANY server.  Symmetric authentication requires a shared secret,
and the need to maintain it at both endpoints.  This means that a secret
key for the client needs to be maintained at every server which may need
to authenticate the client.

This is particularly an issue for protocols such as LDAP, where a client
may connect to and be authenticated by a large number of servers.  In
this situation, the requirement to maintain secret keys on all possible
servers is not practical, which makes authentication mechanisms such as
CRAM-MD5 unsuitable for LDAP in many situations.

4.2.  Why Authentication Only?

This service provides authentication only.   The primary reason for this
is that it makes the mechanism very simple.   It would be possible to
define a more complex mechanism which exchanged session keys and also
provided confidentiality and/or integrity.

There are a number of places where an authentication only service is

-    Where confidentiality and integrity are provided by lower layers
     (e.g., TLS or IPSec).

-    Where confidentialy or integrity services are provided by the
     application (e.g., X.500 signed operations).

-    Where physical and other security aspects of the environment do no
     require confidentiality and integrity services.

-    For legacy applications where changes to the data exchange would be
     difficult to integrate.

4.3.  Relatiohship to TLS

The functionality defined here can be provided by TLS, and it is impor-
tant to consider why it is useful to have it in both places.  There are
a number of reasons for this:

Kille                                                   [Page 3]

Expires January 1999  IP X.509 SASL Authentication        INTERNET DRAFT

-    SASL.  SASL also duplicates TLS functionality, and the rationale
     for this is clearly given in RFC 2222 [1].  These arguments apply

-    Simplicity.  This mechanism is a great deal simpler than TLS.  If
     there is only a requirement for this functionality (as distinct
     from all of TLS), this simplicity will facilitate deployment.

-    Layering.  The SASL mechanism to establish authentication works
     cleanly with most protocols.  TLS often layers awkwardly, and does
     not provide the authentication dialogue at the right stage in the
     protocol negotiation.

-    Proxy support.  Proxys can be cleanly supported with this mechan-
     ism, but not with TLS.   This works because the proxy can authenti-
     cate the client, and then simply pass the credentials on the the

-    No Data Confidentiality and integrity required.  In many situa-
     tions, the data confidentiality and integrity provided by TLS is
     not needed, and in this situation use of TLS provides an unecessary
     overhead and complexity.

-    Export.   Because of its data confidentiality functionality, TLS
     will often have export problems.   When used with a signing algo-
     rithm such as DSS that cannot be used for data confidentiality,
     export problems for this mechanism will be much less.   For this
     reason, it will be much easier to globally deploy this mechanism
     than TLS.   It is also useful that if an "export product" uses
     "weak" data confidentiality, that a separate authentication mechan-
     ism will mean that authentication does not need to be weakened.

5.  Token Definition

The SASLStrongCredentials defined here are based on the StrongCreden-
tials defined in X.511, making use of the SIGNED Macro and Certification
Path definitions of X.509.  Two optional fields have been added, the
second of which makes use of GeneralName defined in X.509 [6].  The
credentials definition is given here for clarity.  The formal defini-
tions of CertificationPath, AlgorithmIdentifier, and DistinguishedName
are by reference to X.511.  The formal definition of GeneralName is
given in X.509.

SASLStrongCredentials ::= SET {
    certification-path [0] CertificationPath OPTIONAL,
    bind-token         [1] SASLToken,
    name               [2] DistinguishedName OPTIONAL}

Kille                                                   [Page 4]

Expires January 1999  IP X.509 SASL Authentication        INTERNET DRAFT

    algorithm          [0] AlgorithmIdentifier,
    name               [1] DistinguishedName,
    time               [2] UTCTime,
    random             [3] BITSTRING,
    response           [4] BITSTRING OPTIONAL,
    generation-time    [20] UTCTime OPTIONAL,
    subject-name       [21] GeneralName OPTIONAL}}

GeneralName ::= CHOICE {
    otherName          [0] OtherName,
    rfc822Name         [1] IA5String,
    dNSName            [2] IA5String,
    x400Address        [3] ORAddress,
    directoryName      [4] Name,
    edipartyname       [5] EDIPartyName,
    uniformresouceidentifier [6] IA5String,
    iPAddress          [7] OCTET STRING,
    registeredID       [8] OBEJCT IDENTIFIER }

The elemements of SASLStrongCredentials are as follows:

     This provides a mechanism for exchange of certificates, which may
     help the recipient to verify the credentials.

     This is the signed token, which is the core of the credentials.

name:This is the name of the signer of the token.  For client authenti-
     cation, this will need to be included unless the information is
     carried in another protocol element of the exchange.  For server
     authentication, this will not normally be needed.

The signed token contains the following elements.

     This is the algorithm used to sign the token.

name:This is the name of the object that is verifying the token.   For
     client authentication, this will be the name of the server.

time:This is the time that the token expires.

     This is a random number, which should be unique for the target over
     the valid life of the token.    This is included to prevent replay

Kille                                                   [Page 5]

Expires January 1999  IP X.509 SASL Authentication        INTERNET DRAFT

items 6-19:
     There is a gap in the sequence numbering.  Items 6-9 are used in
     X.500 DAP, but are not appropriate here.

     This is used to carry a number derived from random if challenge
     response of authentication is required.  This shall be used in the
     client phase of X509-BOTH and in no other circumstances.

     This is the time that the token was generated.  It may be generated
     by the client.  It may be used by the entity verifying the token to
     not accept the token prior to its exiry time.

     This is a very general definition of a name, taken from X.509(v3).
     This definition is being used by ongoing work on PKI.  This enables
     authentication identifiers other than distinguished names to be

Note that this description is for tutorial purposes only, and the formal
definition is taken from X.511.

6.  Distinguished Names

The X.509 strong authentication mechanism makes use of distinguished
names to identify the target.  For some protocols, such as LDAP [2],
this is natural.   For protocols which make use of internet domain names
to identify objects, the representation defined in RFC 2247 [5] MAY be
used as an alternative to subject-name in the token.  For an Internet
Mailbox the local part should be encoded as a domain component.  For
example "J.Bloggs@widget.com" is represented as the distinguished name

7.  Supported Algorithms

The following algorithms are recognised for use with this mechanism:



The set of supported algorithms is handled by the SASL negotiation. Sup-
port of the DSS algorithm is recommended for use with this mechanism.

8.  Example

The following example shows use with IMAP4.  The example is designed to

Kille                                                   [Page 6]

Expires January 1999  IP X.509 SASL Authentication        INTERNET DRAFT

illustrate the protocol interaction and does not provide valid encoding

S: * OK IMAP4 server ready
S: A001 OK done
S: +
C: AE31FF05.......==
S: + 13c3FF44.......==
S: AOO3 OK Welcome, authenticated user: CN=Joe Bloggs,O=Widget,C=GB

9.  Security Considerations

These algorithms are designed to be used for authentication where the
underlying transport service cannot guarantee confidentiality.  These
mechanisms do not prevent an authenticated association from being

10.  Acknowledgements

Design ideas included in this document are based on those from ITU and
ISO, and the IETF ASID Working Groups. Useful ideas were taken from a
note "X.500 Strong Authentication Mechanisms for LDAPv3" by Mark Wahl.
The contributions of individuals in these working groups, including
Harald Alvestrand (Maxware), Alexis Bor (Directory Works), William Cur-
tin (DISA), Steve Hole (Esys), Tim Howes (Netscape), John Myers
(Netscape), and Sean Turner (IECA) are gratefully acknowledged.

11.  Bibliography

[1] J. Meyers, "Simple Authentication and Security Layer", RFC 2222,
October 1997.

[2] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol
(v3)", RFC 2252, December 1997.

[3] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1997, Information
Technology - Open Systems Interconnection - The Directory:  Authentica-
tion Framework.

[4] ITU-T Recommendation X.511 (1997) | ISO/IEC 9594-8:1997, Information
Technology - Open Systems Interconnection - The Directory:  Abstract
Service Definition.

[5] S. Kille, M.Wahl, A. Grimstad, R. Huber, S. Sataluri, "Using Domains
in LDAP/X.500 Distinguished Names", RFC 2247, January 1998.

Kille                                                   [Page 7]

Expires January 1999  IP X.509 SASL Authentication        INTERNET DRAFT

12.  Author's Address

  Steve Kille
  Isode Ltd
  The Dome, The Square
  Richmond, Surrey,
  TW9 1DT, UK

  Phone: +44-181-332-9091
  Email: S.Kille@isode.com

Kille                                                   [Page 8]