[Search] [txt|pdfized|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
Service Location Working Group                             Jonathan Wood
INTERNET DRAFT                                               Roberto Tam
                                                  Sun Microsystems, Inc.
                                                            25 June 1999

                          The LDAP Service Type
                   draft-ieft-svrloc-ldap-scheme-02.txt

Status of This Memo

   This document is a submission by the Service Location Working Group
   of the Internet Engineering Task Force (IETF).  Comments should be
   submitted to the srvloc@srvloc.org mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. 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/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

   This document describes the LDAP service type. This service type
   defines the service: URL and attributes necessary for discovering
   LDAP servers.

1. Introduction

   This document describes a template providing a service: URL and
   attributes useful for dynamically discovering LDAP servers; this type
   can be used with SLP [1]. Service templates and service: schemes are
   defined in [2].

   LDAP (Lightweight Directory Access Protocol) [3] directories are



Wood, Tam                expires December 1999                  [Page 1]


INTERNET DRAFT                                                 June 1999


   now being used as repositories for UNIX-style system information.
   As such, LDAP service is suitable to be included in the naming-
   directory class. This type is intended to be used as a concrete
   portion of the abstract naming-directory type defined in [4]. The
   LDAP type includes all attributes from the naming-directory abstract
   type, and defines new attributes pertaining to security and access
   protocols.

   For usage examples for non-LDAP specific scenarios, refer to [4].

2. Differentiating Servers by Authentication Mechanisms

   Possible means of authenticating LDAP transactions are defined
   in [5]. In order to agree on a particular authentication mechanism,
   a client and server might need to go through a number of iterations
   and levels of negotiation. Currently there are three levels of
   mechanisms: The first level consists of the basic mechanisms,
   anonymous, simple, and TLS. The second layer consists of the SASL
   negotiation layer [6]. The third layer consists of GSSAPI [7]
   mechanisms, and possible the GSS-SPNEGO negotiation sequence [8].
   Thus it is possible that a client wishing to use the Kerberos V5
   GSSAPI mechanism may need to negotiate its way through SASL and
   GSS-SPNEGO before coming to an agreement with the server.

   Since LDAP clients are already aware of what mechanisms they have
   been configured to use when connecting to an LDAP server, the
   attributes in this template have been designed to allow clients to
   optimize both their search for servers and the following negotiation
   sequence for authentication mechanisms. Clients may specify as
   little or as much of their desired negotiation path. For example,
   all of the following SLP [1] search filters are valid:

   (security=sasl)

   (&(security=sasl)(|(sasl-mechs=cram-md5)(sasl-mechs=external)))

   (&(security=sasl)(sasl-mechs=GSSAPI)(gss-mechs=1.3.5.1.5.2))

   The more fully a client specifies the negotiation path, the greater
   the likelihood that the client will discover a server which
   supports the same mechanisms as the client. If a server does not
   support the required mechanisms, clients will need to move on to
   other discovered servers, and repeat the negotiation process. This
   can be a costly process. Additionally, clients should be able to
   optimize the resulting negotiation, bypassing mechanisms which are
   not acceptable to one of the parties.

   The allowable values for the "security" attribute follows those



Wood, Tam                expires December 1999                  [Page 2]


INTERNET DRAFT                                                 June 1999


   defined in [5].

   The allowable values for the "sasl-mechs" and "gss-mechs"
   attributes are meant to be fluid, following the decisions of their
   respective working groups.

3. The LDAP Service Type

Names of submitters: Jonathan Wood <jonathan.wood@eng.sun.com>
                     Roberto Tam <roberto.tam@eng.sun.com>
Language of service template: en
Security Considerations:
  This LDAP service type inherits the security considerations from the
  naming-directory service type [4], the SLP specification [1].
  Implementors should also be aware of the security considerations
  discussed in [5].

Template text:
-------------------------template begins here-----------------------
template-type=naming-directory:ldap

template-version=0.0

template-description=
  This is a concrete type; the abstract type for this service
  is naming-directory (described in [4]). This type is used
  by LDAP servers to advertise their services and LDAP clients
  which wish to discover LDAP servers.

template-url=syntax=
  url-path = ldap URL as defined in [9]

security=string M
  # Security mechanisms supported by this server. Permitted values
  # are drawn from draft-ietf-ldapext-authmeth-03 (Authentication
  # Methods for LDAP). If SASL is supported, clients may further
  # differentiate servers with the sasl-mechs attribute.
anonymous,simple,tls,sasl

sasl-mechs=string M
  # SASL mechanisms supported by this server. If the GSSAPI or GSS-SPNEGO
  # mechanisms are supported, clients may further differentiate servers
  # with the gss-mechs attribute. SASL mechanisms are registered with
  # IANA; legal values of this attribute are the mechanism keywords
  # registered with IANA. SASL is defined in RFC 2222.

gss-mechs=string M
  # GSSAPI mechanisms supported by this server. The mechanisms are



Wood, Tam                expires December 1999                  [Page 3]


INTERNET DRAFT                                                 June 1999


  # named by their object identifiers (OIDs). GSSAPI is defined
  # in RFC 2078, and GSS-SPNEGO is defined in RFC 2478.

qop= string
  # quality of protection. The refers to how strongly messages are
  # protected. There are three possibilities: none, integrity
  # (meaning that the integrity and endpoints of the message can
  # be guaranteed), and privacy (meaning that the message is
  # encrypted).
none,integrity,privacy

transport= string
  # the transport used to communicate with this server. Possible
  # values are connection-oriented (cots) and connectionless
  # (clts).
cots,clts

version= string M
  # Which version(s) of LDAP this server supports. "v3" corresponds to
  # the protocol as defined by RFC 2251, and "v2" corresponds to the
  # protocol as defined by RFC 1777.
v2,v3

extensions= string M
  # This is an open-ended attribute intended to contain any standard or
  # non-standard (i.e. vendor-specific) extensions this server supports.

--------------------------template ends here------------------------


References:

  [1] E. Guttman, C. Perkins, J. Veizades, M. Day.  Service Location
      Protocol. RFC 2608, April 1999

  [2] E. Guttman, C. Perkins, J. Kempf, Service Templates and service:
      Schemes. RFC 2609, February 1999

  [3] W. Yeong, T. Howes, S. Kille, Lightweight Directory Access
      Protocol, RFC 1777 March 1995

  [4] J. Wood, R. Tam, The Naming and Directory Service Abstract Type.
      draft-ietf-svrloc-naming-directory-01.txt, June 1999 (work in
      progress)

  [5] M. Wahl, H. Alvestrand, J. Hodges, RL Morgan. Authentication
      Methods for LDAP, draft-ietf-ldapext-authmeth-04.txt, November
      1998 (work in progress)



Wood, Tam                expires December 1999                  [Page 4]


INTERNET DRAFT                                                 June 1999


  [6] J. Meyers, Simple Authentication and Security Layer (SASL)
      RFC 2222 October 1997

  [7] J. Linn, Generic Security Service Application Program Interface,
      Version 2, RFC 2078 January 1997

  [8] E. Baize, D. Pinkas, The Simple and Protected GSS-API Negotiation
      Mechanism, RFC 2478 December 1998

  [9] T. Howes, M. Smith, The LDAP URL Format, RFC 2255 December 1997









































Wood, Tam                expires December 1999                  [Page 5]