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

Versions: 00                                                            
Individual Submission                                      Vesna Hassler
INTERNET-DRAFT                            Technical University of Vienna
Expires six months from                                    March 1, 1998

                   LDAPv3 Security Parameters
               <draft-hassler-ldapv3-secparam-00.txt>


1. Status of this Memo


   This document is an Internet-Draft.  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."

   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 (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).


2. Abstract


   Two security services that are required in many applications but have
   not been addressed by LDAPv3 [ldapv3] in a satisfactory manner yet
   are integrity and non-repudiation. According to the latest LDAPv3
   security draft [ldapv3-auth] integrity can be achieved within a
   secure association only. Non-repudiation, and by this we mean digital
   signing of operations, is mentioned in [ldapv3] as an example of the
   use of the LDAPv3 extended operation mechanism.
   A disadvantage of this approach is that it would be necessary
   to define a new Extended Request/Response pair for
   each basic operation that should be signed.

   This document defines an LDAP control called LDAPSecurityParameters
   for transferring security parameters with LDAP operations.
   With this control it is possible to append digital signature
   to LDAP operations and in this way provide for message
   authenticity, message integrity, non-repudiation of message
   origin and message freshness.











INTERNET-DRAFT          LDAPv3 Security Parameters         March 1, 1998

3. Table of Contents


   1. Introduction

   2. The Control

     2.1. Encoding Requirements

   3. Client-Server Interaction

     3.1. Client's Signature

     3.2. Server's Signature

     3.3. Client's and Server's Signature

   4. Attributes in the Root DSE

   5. Security Considerations

   6. References

   7. Author's Address


1. Introduction


   The Lightweight Directory Access Protocol (LDAP) [ldapv3] is rapidly
   becoming the ubiquitous mechanism for accessing and manipulating
   directory data. Many diverse directory implementations, data stores,
   client applications, and API suites are acquiring LDAP interfaces and
   functionality.

   Two security services that are required in many applications but have
   not been addressed by LDAPv3 [ldapv3] in a satisfactory manner yet
   are integrity and non-repudiation. According to the latest LDAPv3
   security draft [ldapv3-auth] integrity can be achieved within a
   secure association only. Non-repudiation, and by this we mean
   digital signature of operations, is mentioned in [ldapv3] as an
   example of the use of the LDAPv3 extended operation mechanism.
   A disadvantage of this approach is that it would be necessary to
   define a new Extended Request/Response pair for each basic operation
   that should be signed. We propose another mechanism that requires
   less changes in the protocol and causes less overhead. This mechanism
   is based on LDAP controls which provide a general way to specify
   extension information. They are sent as a part of an operation
   and apply only to that operation. In the proposed
   solution we follow the X.511 security parameters concept [x511] as
   closely as possible.


INTERNET-DRAFT          LDAPv3 Security Parameters         March 1, 1998

   This document defines an LDAP control called LDAPSecurityParameters
   for transferring security parameters with LDAP operations.
   With this control it is possible to append digital signature
   to LDAP operations and in this way provide for message
   authenticity, message integrity, non-repudiation of message
   origin and message freshness.


2. The Control


   This control MAY be included in each LDAP operation
   as a part of the controls field of the LDAPMessage, as defined
   in Section 4.1.12 of [ldapv3]. The structure of the control is as
   follows:

   LDAPSecurityParameters ::= SEQUENCE {
                controlType             LDAPOID -- to be assigned,
                criticality             BOOLEAN DEFAULT FALSE,
                controlValue            SecurityParameters}

   SecurityParameters  :=      SET {
        certification-path      [0]     AF.CertificationPath OPTIONAL,
        name                    [1]     LDAPDN OPTIONAL,
        time                    [2]     UTCTime OPTIONAL,
        random                  [3]     BIT STRING OPTIONAL,
        target                  [4]     ProtectionRequest OPTIONAL}
        signature               [4]     AF.Signature OPTIONAL}

   ProtectionRequest       :=      INTEGER { none(0), signed(1) }

   The control type MUST be set to an OBJECT IDENTIFIER for
   LDAPSecurityParameters (not yet assigned). The control SHOULD be
   critical.

   The control is specified based on the X.511 Security Parameters,
   which are an optional part of the X.511 Common Arguments [x511].
   The use of the certification-path, name, time random and target
   fields are as defined in [x511] for X.511 Security Parameters.

   The ASN.1 type AF.Signature (AF stands for "Authentication Framework")
   is defined in [x509] as follows:

   AF.Signature            :=      SEQUENCE {
        algorithmIdentifier     AlgorithmIdentifier,
        encrypted               BIT STRING}

   The value of the encrypted field is computed over the
   entire LDAPMessage with the encrypted field set to NULL (i.e. absent).
   The ASN.1 type AF.CertificationPath is defined in [x509].

   The algorithmIdentifier must be an entirely numeric string
   representation of an OBJECT IDENTIFIER.



INTERNET-DRAFT          LDAPv3 Security Parameters         March 1, 1998

2.1. Encoding Requirements


   (This section is identical to Section 4 in [ldapv3-strong].)
   This document describes data elements using ASN.1 structures, which
   are encoded using a subset of the Basic Encoding Rules, as done in
   LDAPv3 [ldapv3]. Implementations must follow the encoding
   restrictions of LDAPv3, and additional encoding restrictions apply
   to the elements defined in this specification:

   - BIT STRING values are to be encoded in primitive form only.
     Unused bits in the final octet of the encoding of a BIT STRING
     value, if there are any, should always be set to zero.

   - UTC Times must be encoded with the "Z" suffix, not as a local time.


3. Client-Server Interaction


   The control MAY be used in all LDAPv3 operations (note the difference
   from X.511, where it cannot be used in the bind request/response).
   In this section we describe some of the possible use scenarios.


3.1. Client's Signature


   If the server sends the control in the bind response,
   with the target field set to signed(1), the client MUST
   sign all subsequent requests until the next unbind request.
   If the server does not insist on signing its own messages
   (i.e. responses), the certification-path field in the control
   MUST be absent. Note that the control is not signed and
   therefore can be tampered with.

   With this mechanism all client requests can be
   authenticated using a strong authentication mechanism,
   and the signature can be for non-repudiation of message origin.
   However, this mechanism alone does not provide for either
   confidentiality of any data transferred between the client
   and the server, or for the authenticity of the data transferred
   from the server to the client.

   If the server sends the control in any response message
   except the bind response, with the target field set to signed(1),
   the client MUST resend the request with the control carrying
   the signature. The security considerations are the same as
   in the previous paragraph.

   If the client sends a request (i.e. any request except the bind
   request) without the control carrying the signature, and the server
   requires the request be signed, the server MUST return
   inappropriateAuthentication as a result code, and the control with
   the target field set to signed(1).



INTERNET-DRAFT          LDAPv3 Security Parameters         March 1, 1998

3.2. Server's Signature


   If the client sends the control in the bind request,
   with the target field set to signed(1), the server MUST either return
   unavailableCriticalExtension as a result code,
   or sign all subsequent responses until the next unbind request.
   If the client does not insist on signing its own messages
   (i.e. requests), the certification-path field MUST be absent.
   If the server's certificate has been sent in the bind response,
   it MAY be omitted in the subsequent server responses.
   The server MAY set the time field of the control to
   currentTime (see Section 4.). Note that the control is not signed and
   therefore can be tampered with.

   With this mechanism all server responses can be authenticated
   using a strong authentication mechanism,
   and the signature can be used for non-repudiation of message origin.
   However, this mechanism alone does not provide for either
   confidentiality of any data transferred between the client
   and the server, or for the authenticity of the data transferred
   from the client to the server.

   If the client sends the control, with the target field
   set to signed(1), as part of any request except the bind request, the
   server MUST either return unavailableCriticalExtension as a result
   code, or sign the corresponding responses.

3.3. Client's and Server's Signature


   To provide for authenticity and non-repudiation (which
   also implies integrity) of all data transferred between
   the client and the server, both the client and the server MUST
   sign their messages. If the time and random field of the control are
   used in an appropriate way, the protection against reply attacks
   (i.e. message freshness) can be provided.

   If the signed operations requestor (i.e. client or server)
   sends its certification-path in the control with the target
   field set to signed(1), both the receiver (i.e. server or client)
   and the requestor MUST sign the messages as defined in Sections 3.1.
   and 3.2. The requestor SHOULD sign the message carrying the control,
   otherwise the sign request can be tampered with.


4. Attributes in the Root DSE


   [ldapv3-strong] defines four attributes which MAY be present in the
   server's root DSE:


INTERNET-DRAFT          LDAPv3 Security Parameters         March 1, 1998

   currentTime - for checking the current time
   serverName - for validating the name of the server
   certificationPath - for obtaining the certification path from
                       the server
   supportedAlgorithms - for determining the supported signature
                         algorithms


5. Security Considerations


   This document describes a new security mechanism for LDAPv3.
   Security is discussed in the previous sections.


6. References


   [ldapv3]
       M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
       Protocol (v3), RFC 2251,
       http://ds.internic.net/rfc/rfc2251.txt

   [ldapv3-strong]
       M. Wahl, "X.500 Strong Authentication Mechanisms for
       LDAPv3", INTERNET-DRAFT <draft-ietf-asid-ldapv3-strong-00.txt>,
     March 1997,
       ftp://ietf.org/internet-drafts/draft-ietf-asid-ldapv3-strong-00.txt

   [ldapv3-auth]
       M. Wahl, H. Alvestrand, "Authentication Methods for LDAP",
       INTERNET-DRAFT <draft-ietf-ldapext-authmeth-01.txt>, Jan 1998,
       ftp://ietf.org/internet-drafts/draft-ietf-ldapext-authmeth-01.txt

   [x509]
       ISO/IEC 9594-8 (ITU-T X.509), "Information technology -
       Open Systems Interconnection - The Directory: Authentication
       framework", 1995,
       http://www.iso.ch/

   [x511]
       ISO/IEC 9594-3 (ITU-T X.511), "Information technology - Open Systems
       Interconnection - The Directory: Abstract service definition", 1995,
       http://www.iso.ch/



INTERNET-DRAFT          LDAPv3 Security Parameters         March 1, 1998

7. Author's Address


   Vesna Hassler
   Technical University of Vienna
   Distributed Systems Group 184-1
   Argentinierstrasse 8/3rd floor
   A-1040 Vienna
   Austria

   Phone: +43 1 58801 4426
   Fax:   +43 1 5058453
   Email: hassler@infosys.tuwien.ac.at

   Expires six months from                                 March 1, 1998