[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01 02 03                                                   
Network Working Group                                            M. Wahl
Internet-Draft                                     Informed Control Inc.
Intended status: Informational                             July 28, 2006
Expires: January 29, 2007


                     LDAP Session Tracking Control
                       draft-wahl-ldap-session-00

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/ietf/1id-abstracts.txt.

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

   This Internet-Draft will expire on January 29, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).














Wahl                    Expires January 29, 2007                [Page 1]


Internet-Draft        LDAP Session Tracking Control            July 2006


Abstract

   Many network devices, application servers, and middleware components
   of a enterprise software infrastructure generate some form of session
   tracking identifiers, which are useful when analyzing activity and
   accounting logs to group activity relating to a particular session.
   This document discusses how Lightweight Directory Access Protocol
   version 3 (LDAP) clients can include session tracking identifiers
   with their LDAP requests.  This information is provided through
   controls in the requests the clients send to LDAP servers.  The LDAP
   server receiving these controls can include the session tracking
   identifiers the the log messages it writes, enabling LDAP requests in
   the LDAP server's logs to be correlated with activity in logs of
   other components in the infrastructure.  Three formats of session
   tracking identifiers are defined in this document.




































Wahl                    Expires January 29, 2007                [Page 2]


Internet-Draft        LDAP Session Tracking Control            July 2006


1.  Introduction

   The majority of directory server implementations produce access logs
   detailing each request they receive.  These logs can be read using
   log parsing tools or specialized log viewer applications.  Typically
   it will be possible, for each request logged by a directory server,
   to determine the bind DN (or possibly another form of authentication
   identity) of the client which sent the request to the server, and
   many servers also log the IP address of the client that sent the
   request.

   In the original OSI architecture, it was envisaged that users might
   interact with a directory service through specialized applications,
   known as Directory User Agents, that were the clients of the
   Directory Access Protocol.  Similarly, in early Internet directory
   deployments, a majority of LDAP clients were desktop applications,
   that used the LDAP protocol to search an enterprise directory for
   address book/contact information.

   Today, the majority of LDAP clients are embedded within middleware
   and server applications.  Legacy address book protocols might be
   gatewayed into LDAP, or a server might consult an LDAP server in
   order to check a user's password or obtain their preferences.  While
   the LDAP requests might result from a user's activity somewhere on
   the network, it is rare for the user to be 'driving' the LDAP client,
   and in most cases the user performing the activity is unaware that
   LDAP requests are being generated on their behalf.

   However, this information is important to directory system
   administrators and auditors.  They may wish to determine who is
   making use of the directory service, or track the source of unusual
   requests.

   When a directory server administrator reviews a log file produced by
   a directory server that has been accessed only by clients that are
   themselves middleware, where the end user does not interact with the
   middleware directly, only through other kinds of servers (e.g.
   application servers or remote access servers), it will be difficult
   to correlate between the directory server's log and the logs of the
   servers which made use of this directory to determine why the LDAP
   requests were made and who were responsible for causing them.










Wahl                    Expires January 29, 2007                [Page 3]


Internet-Draft        LDAP Session Tracking Control            July 2006


   Reasons for this include:

    - Directory servers are capable of performing many hundreds
      of requests per second or more, and even with time synch-
      ronization between the systems on which the directory
      server and middleware are deployed, times of requests might
      not be logged accurately enough to be able to correlate
      based on time: the server's logs might be only to
      1-second resolution.

    - a single function on a middleware server, such as
      "authenticate a user", may result in multiple LDAP requests
      being generated in order to perform that request.

    - Many high performance middleware servers implement
      connection pooling, managing a set of persistent connections
      to each directory server and multiplexing operations across
      the connections. Each connection will have the same source
      IP address and bind DN.  If a particular activity causes
      multiple LDAP requests to be generated, each LDAP request
      might be sent on a different connection.  Also, as LDAP
      is an asynchronous protocol, middleware servers may have
      more than one request in progress on each connection,
      asynchronously sending requests to the directory server on
      each connection and processing the responses in whatever
      order they are received.


   This document defines a new control for use in LDAPv3 [1] operation
   requests.  This control contains session tracking information that
   can be used to correlate log information present in the directory
   server's log with the logs of other middleware servers.

   The words "MUST" and "MAY" are used as defined in RFC 2119 [2].

   Please send comments to the author at mark.wahl@informed-control.com.















Wahl                    Expires January 29, 2007                [Page 4]


Internet-Draft        LDAP Session Tracking Control            July 2006


2.  Session tracking

   A typical enterprise deployment with a an application indirectly
   relying upon the directory might resemble:


       +------+     +--------+       +----------+      +--------+
       | User |     | Appli- |       | Auth./   | LDAP |  LDAP  |
       |      +-----+ cation +-------+ Identity +------+ Server |
       |      |     | Server |       | Provider |      |        |
       |  A   |     |   B    |       |    C     |      |   D    |
       +------+     +--------+       +----------+      +--------+


   In this diagram, a user (A) makes some request of an application
   server (B).  The application server might rely on an integrated or
   external authentication provider in order to check the user's
   authentication credentials, or might use an identity provider to
   obtain profile information about the user.  This request might be
   made through an API or a protocol other than LDAP, e.g.  RADIUS,
   Kerberos, SMB, etc.  The authentication/identity provider (C) would
   generate one or more LDAP requests and send them to an LDAP server
   (D).

   The LDAP server has the following information already available to it
   through the LDAP protocol: the IP address and authentication
   credentials of (C).  If the provider has included the Proxy
   Authorization Control [11], then it may also receive the
   Distinguished Name (DN) or authorization identity of either (A) or
   (B), depending on how (C) uses the directory.  In order to obtain
   this DN, however, (C) might need to perform one or more LDAP search
   or bind requests.  If there is no entry in the directory
   corresponding to the identity of (A) or (B), then there is no way in
   the base LDAP specification or the Proxy Authorization Control for
   (C) to describe (A) or (B) to (D).

   If either (B) or (C) have generated a session identifier for tracking
   the interactions of (A) for a particular session, then it is useful
   to include this information with the requests made to the directory
   server, so that this session identifier will show up in the directory
   server's logs.  That is the purpose of the control defined in the
   next section.









Wahl                    Expires January 29, 2007                [Page 5]


Internet-Draft        LDAP Session Tracking Control            July 2006


3.  Description of the control

   There is currently no standard way of describing a session: there are
   many different formats for a session identifier, and each application
   that tracks sessions typically has its own semantics for what a
   session means.  Thus, a control is defined using an extensible model,
   in order to incorporate many different application's concepts and
   formats of a session tracking identifier.

   The value of the session tracking identifier control encapsulates the
   following four pieces of information: sessionSourceIp,
   sessionSourceName, formatOID and sessionTrackingIdentifier.

   The sessionSourceIp field is a US-ASCII string encoding of an IPv4 or
   IPv6 [3] address of the component of the system which has generated a
   session tracking identifier.  The purpose of this field is to enable
   the directory server administrator, even if they do not have a log
   parser that understands a particular session tracking identifier
   format, to at least be able to identify the server that manages the
   session.

   The sessionSourceName field is a UTF-8 [4] encoded ISO 10646 [5]
   string.  This field describes the component of the system which has
   generated a session tracking identifier.  The format of this field is
   determined by the formatOID (discussed below); examples of contents
   of a sessionSourceName field might be a hostname, a distinguished
   name, a web service address.  It does not identify the end user;
   instead it identifies the server using a naming scheme other than IP
   address.

   The formatOID is an UTF-8 encoded dotted decimal representation of an
   OBJECT IDENTIFIER.  The OBJECT IDENTIFIER indicates the scheme that
   is used to generate the sessionSourceName and
   sessionTrackingIdentifier fields.  As there is currently no standard
   scheme for session information, it is expected that there will be
   many different formats carried within this control.  Three possible
   format OIDs are presented later in this document.

   The sessionTrackingIdentifier field is a UTF-8 encoded ISO 10646
   string.  The session identifier SHOULD be limited to whitespace
   printable characters; non-printing and control characters SHOULD NOT
   be used, and byte sequences that are not legal UTF-8 MUST NOT be
   used.  The syntax of the session identifier and its semantics are
   governed by the formatOID.  It might be a simple string encoding of a
   decimal counter, a username, a timestamp, a fragment of XML, or
   something else, depending on the format.





Wahl                    Expires January 29, 2007                [Page 6]


Internet-Draft        LDAP Session Tracking Control            July 2006


4.  Use in LDAP

   The controlType is 1.3.6.1.4.1.21008.108.63.1, the criticality MUST
   be either FALSE or absent, and the controlValue MUST be present.  The
   controlValue OCTET STRING contains the bytes of the BER [6]encoding
   of a value of the ASN.1 data type SessionIdentifierControlValue,
   defined as follows:

      LDAP-Session-Identifier-Control
      DEFINITIONS IMPLICIT TAGS ::=

      BEGIN

      SessionIdentifierControlValue ::= SEQUENCE {
           sessionSourceIp                 LDAPString,
           sessionSourceName               LDAPString,
           formatOID                       LDAPOID,
           sessionTrackingIdentifier       LDAPString
      }

      END

   The sessionSourceIp element SHOULD NOT be longer than 42 characters.
   If the IP address of the system which generated the session tracking
   identifier is not known, the sessionSourceIp element SHOULD be of
   zero length.

   The sessionSourceName element SHOULD NOT be longer than 1024
   characters.  If no other addressing information about that system is
   known or relevant to the format, the sessionSourceName element SHOULD
   be of zero length.

   The formatOID element SHOULD NOT be longer than 1024 characters.  The
   formatOID element MUST NOT be of zero length.

   The sessionTrackingIdentifier field MAY be of zero length.  There is
   no upper bound on the sessionTrackingIdentifier, but it is suggested
   that values SHOULD NOT be longer than 65536 characters without prior
   agreement with the directory server administrator.

   The control MAY be included in any LDAP operation, and will typically
   be expected to be present on the bindRequest, searchRequest,
   modifyRequest, addRequest, delRequest, modDNRequest, compareRequest
   or extendedReq requests.

   A client MAY include multiple controls of this type in a single
   request.  This enables the client to incorporate multiple distinct
   session tracking identifiers with different formats.



Wahl                    Expires January 29, 2007                [Page 7]


Internet-Draft        LDAP Session Tracking Control            July 2006


5.  Extensibility considerations

   The following sections of this document define several possible
   formats, and it is expected that applications MAY define their own
   formats to represent session tracking identifiers already
   implemented.

   An application developer that wishes to transfer their applications'
   format for session tracking identifier within an LDAP control MUST
   choose a new, unique, OBJECT IDENTIFIER to represent this format.

   The format determines the semantics of the sessionSourceName string,
   and the sessionTrackingIdentifier string.

   In general, when an LDAP server that has session tracking logging
   enabled receives one or more of these controls with a request, the
   server SHOULD include all fields of all of the controls with the
   logging information for the request.

   A LDAP server that supports third-party or extensible log parsing
   tools need not reject or ignore a control if the formatOID value is
   not recognized, as it is expected that applications may include
   session tracking identifiers and want to make this information
   available to log parsers for correlation purposes, even if the
   directory server does not need to make any use of this information.

   However, if the LDAP server does not recognize the control or it is
   not properly formatted, the LDAP server SHOULD ignore the control and
   process the request as if the control had not been included.






















Wahl                    Expires January 29, 2007                [Page 8]


Internet-Draft        LDAP Session Tracking Control            July 2006


6.  Formats for use with RADIUS accounting

   This section defines two possible session tracking formats, that can
   be used in LDAP clients that are part of or used by RADIUS servers
   [7].

   With formatOID set to 1.3.6.1.4.1.21008.108.63.1.1 within the control
   value, the sessionTrackingIdentifier SHOULD contain the value of the
   Acct-Session-Id RADIUS attribute (type 44), as defined in RFC 2866
   [8].  (RFC 2866 section 5.5 states that the Acct-Session-Id SHOULD
   contain UTF-8 encoded 10646 characters.)

   With formatOID set to 1.3.6.1.4.1.21008.108.63.1.2 within the control
   value, the sessionTrackingIdentifier SHOULD contain the value of the
   Acct-Multi-Session-Id RADIUS attribute (type 50), as defined in RFC
   2866 [8].  (RFC 2866 section 5.11 states that the
   Acct-Multi-Session-Id SHOULD contain UTF-8 encoded 10646 characters.)

   In both of these two formats, the value of the sessionSourceIp field
   SHOULD contain either a string encoding value of the IPv4 address
   from the NAS-IP-Address RADIUS attribute (type 4), or a string
   encoding of the IPv6 address from the value of the NAS-IPv6-Address
   RADIUS attribute (type 95) as defined in RFC 3162 [9].  The value of
   the sessionSourceName field SHOULD contain a string encoding the
   value of the NAS-Identifier RADIUS attribute (type 32), if present,
   or be of zero length if the NAS-Identifier RADIUS attribute is was
   not provided or was not in a recognized format.
























Wahl                    Expires January 29, 2007                [Page 9]


Internet-Draft        LDAP Session Tracking Control            July 2006


7.  Formats for username accounting

   This section defines another possible session tracking formation,
   that can be used in LDAP clients that are part of applications which
   identify users with simple string usernames.

   With formatOID set to 1.3.6.1.4.1.21008.108.63.1.3 within the control
   value, the sessionTrackingIdentifier SHOULD contain a username that
   has already been authenticated by the application that is generating
   the session.  This format SHOULD NOT be used for purported names,
   where the application has not verified that the username is valid.

   The sessionSourceName field SHOULD contain the hostname where that
   application is running, or be of zero length if the hostname is not
   known.

   The username SHOULD be a SASL authorization identity string, as
   described in section 3.4.1 of RFC 4422 [10].  It is expected that
   these usernames are not globally unique, but are only unique within
   the context of a particular application or particular enterprise.

   A control with this format differs from the Proxied Authorization
   Control as defined in RFC 4370 [11], as the presence of this session
   identifier control on a request SHOULD NOT influence the directory
   server's access control decision of whether or how to perform that
   request.

   Note that this format does not provide any information to
   differentiate between multiple sessions or periods of interaction by
   the same user.  It is primarily intended for deployments which merely
   need to be able to tie each directory operation to they identity of
   the user whose activities caused the operation request to be
   generated, even if the user might not even be represented in the
   directory where the operations are being performed.

   For example, if an application server "app.example.com" with IPv4
   address "192.0.2.1" had authenticated an user with name "bloggs", and
   then sent a search request to the LDAP directory in order to obtain
   some public information on service configuration intending to provide
   it to that user, the application might include a session tracking
   identifier control, with controlType 1.3.6.1.4.1.21008.108.63.1,
   criticality FALSE, and the controlValue the BER encoding of the
   following ASN.1 value:








Wahl                    Expires January 29, 2007               [Page 10]


Internet-Draft        LDAP Session Tracking Control            July 2006


      {  -- SEQUENCE
         "192.0.2.1",                    -- sessionSourceIp
         "app.example.com",              -- sessionSourceName
         "1.3.6.1.4.1.21008.108.63.1.3", -- formatOID
         "bloggs"                        -- sessionTrackingIdentifier
      }













































Wahl                    Expires January 29, 2007               [Page 11]


Internet-Draft        LDAP Session Tracking Control            July 2006


8.  Security Considerations

   The session identifier controls used in this document are not
   intended as a security control or proxy authentication mechanism, and
   SHOULD NOT be used within the server to influence behavior.

   Malicious clients might attempt to provide false or misleading
   information in directory server logs through the use of this control.
   LDAP servers SHOULD implement access checks which limit whether
   session identifier information provided by a client is logged.  These
   checks might include validating that the request is received from an
   authenticated client, or perhaps that the client is authorized to use
   related controls, such as the Proxied Authorization Control [11].
   Session identifier information from clients which do not meet the
   server's access check requirement SHOULD be silently discarded.

   Correlation of activities across multiple servers may enable
   administrators and monitoring tools to construct a more accurate
   picture of user behavior.  In particular, this tracking control could
   be used to determine the set of applications and services with which
   a particular user has had interactions.  Thus, this control MAY NOT
   be appropriate to deployments intending to anonymize directory
   requests.




























Wahl                    Expires January 29, 2007               [Page 12]


Internet-Draft        LDAP Session Tracking Control            July 2006


9.  IANA Considerations

   This control will be registered as follows:

      Subject: Request for LDAP Protocol Mechanism Registration

      Object Identifier: 1.3.6.1.4.1.21008.108.63.1

      Description: Session Tracking Identifier

      Person & email address to contact for further information:
      Mark Wahl <Mark.Wahl@informed-control.com>

      Usage: Control

      Specification: (I-D) RFC XXXX

      Author/Change Controller: Mark Wahl


   The OBJECT IDENTIFIER for particular session identifier formats
   defined for other applications need not be registered with IANA.





























Wahl                    Expires January 29, 2007               [Page 13]


Internet-Draft        LDAP Session Tracking Control            July 2006


10.  References

10.1.  Normative References

   [1]   Zeilenga, K., "Lightweight Directory Access Protocol (LDAP):
         Technical Specification Road Map", RFC 4510, June 2006.

   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", RFC 2119, BCP 14, March 1997.

   [3]   Hinden, R., "IP Version 6 Addressing Architecture", RFC 1884,
         January 1996.

   [4]   Yergeau, F., "UTF-8, a transformation format of ISO 10646",
         RFC 3629, November 2003.

   [5]   "Universal Multiple-Octet Coded Character Set (UCS) -
         Architecture and Basic Multilingual Plane, ISO/IEC 10646-1:
         1993".

   [6]   "ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002, "Information
         technology - ASN.1 encoding rules: Specification of Basic
         Encoding Rules (BER), Canonical Encoding Rules (CER) and
         Distinguished Encoding Rules (DER)", 2002.".

   [7]   Rigney, C., "Remote Authentication Dial In User Service
         (RADIUS)", RFC 2865, June 2000.

   [8]   Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

   [9]   Aboba, B., "RADIUS and IPv6", RFC 3162, August 2001.

   [10]  Melnikov, A., "Simple Authentication and Security Layer
         (SASL)", RFC 4422, June 2006.

10.2.  Informative References

   [11]  Weltman, R., "Lightweight Directory Access Protocol (LDAP)
         Proxied Authorization Control", RFC 4370, February 2006.












Wahl                    Expires January 29, 2007               [Page 14]


Internet-Draft        LDAP Session Tracking Control            July 2006


Appendix A.  Copyright

   Copyright (C) The Internet Society 2006.  This document is subject to
   the rights, licenses and restrictions contained in BCP 78, and except
   as set forth therein, the authors retain all their rights.  This
   document and the information contained herein are provided on an "AS
   IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
   IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.







































Wahl                    Expires January 29, 2007               [Page 15]


Internet-Draft        LDAP Session Tracking Control            July 2006


Author's Address

   Mark Wahl
   Informed Control Inc.
   PO Box 90626
   Austin, TX  78709
   US

   Email: mark.wahl@informed-control.com










































Wahl                    Expires January 29, 2007               [Page 16]


Internet-Draft        LDAP Session Tracking Control            July 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Wahl                    Expires January 29, 2007               [Page 17]