--- /dev/null
+
+
+
+Network Working Group M. Wahl
+Internet-Draft Informed Control Inc.
+Intended status: Standards Track May 9, 2007
+Expires: November 10, 2007
+
+
+ LDAP Session Tracking Control
+ draft-wahl-ldap-session-03
+
+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 November 10, 2007.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl Expires November 10, 2007 [Page 1]
+\f
+Internet-Draft LDAP Session Tracking Control May 2007
+
+
+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 in 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. The control also enables
+ session tracking information to be generated by LDAP servers and
+ returned to clients and other servers. Three formats of session
+ tracking identifiers are defined in this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl Expires November 10, 2007 [Page 2]
+\f
+Internet-Draft LDAP Session Tracking Control May 2007
+
+
+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, which 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.
+
+ Reasons for this include:
+
+ o Directory servers are capable of performing many hundreds of
+ requests per second or more, and even with time synchronization
+ between the systems on which the directory server and middleware
+ are deployed, times of requests might not be logged accurately
+
+
+
+Wahl Expires November 10, 2007 [Page 3]
+\f
+Internet-Draft LDAP Session Tracking Control May 2007
+
+
+ enough to be able to correlate based on time: the server's logs
+ might be only to 1-second resolution.
+
+ o 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.
+
+ o 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", "SHOULD" and "MAY" are used as defined in RFC 2119
+ [2].
+
+1.1. Motivation for session tracking
+
+ A typical enterprise deployment with 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
+
+
+
+Wahl Expires November 10, 2007 [Page 4]
+\f
+Internet-Draft LDAP Session Tracking Control May 2007
+
+
+ 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 the authentication/identity provider (C). If the
+ provider has included the Proxy Authorization Control [11], then the
+ LDAP server might also receive the Distinguished Name or
+ authorization identity of either the user (A) or the application
+ server (B), depending on how the authentication/identity provider (C)
+ uses the directory. In order to obtain this distinguished name
+ however, the authentication/identity provider (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 the user (A)
+ or the application server (B), then there is no way in the base LDAP
+ specification or the Proxy Authorization Control for the
+ authentication/identity provider (C) to describe the user (A) or the
+ application server (B) to the LDAP server (D).
+
+ If either the application server (B) or the authentication/identity
+ provider (C) have generated a session identifier for tracking the
+ interactions of the user (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 November 10, 2007 [Page 5]
+\f
+Internet-Draft LDAP Session Tracking Control May 2007
+
+
+2. Control definition
+
+ 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 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. Note that there is no guarantee of IP-level connectivity
+ between the directory server and the system which generated the
+ tracking identifier, and if Network Address Translation is being
+ used, the IP address in this field might be from a private use
+ address range.
+
+ The sessionSourceName field is a UTF-8 [4] encoded ISO 10646 [5] text
+ 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, or a web service address. This contents of this field is not
+ intended to identify an end user; instead it identifies the server
+ using a name other than the server's IP address.
+
+ The formatOID is a US-ASCII 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. The OBJECT
+ IDENTIFIERs for three formats are presented in this document.
+
+ The sessionTrackingIdentifier field is a UTF-8 encoded ISO 10646
+ string. The session identifier SHOULD be limited to whitespace and
+ 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 (e.g.,
+ how values are compared for equality) are governed by the formatOID.
+
+
+
+Wahl Expires November 10, 2007 [Page 6]
+\f
+Internet-Draft LDAP Session Tracking Control May 2007
+
+
+ For example, the session identifier might be a simple string encoding
+ of a decimal counter, a username, a timestamp, a fragment of XML, or
+ it might be something else, depending on the format.
+
+2.1. Formal definition
+
+ This document defines a single LDAP control.
+
+ 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 is always present and 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
+
+ LDAPString ::= OCTET STRING -- UTF-8 encoded
+ LDAPOID ::= OCTET STRING -- Constrained to numericoid
+
+ SessionIdentifierControlValue ::= SEQUENCE {
+ sessionSourceIp LDAPString,
+ sessionSourceName LDAPString,
+ formatOID LDAPOID,
+ sessionTrackingIdentifier LDAPString
+ }
+
+ END
+
+ The sessionSourceIp element SHOULD NOT be longer than 42 characters
+ (the length necessary for a string representation of an IPv6
+ address), and MUST NOT be longer than 128 characters. Each character
+ will be encoded into a single byte. 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, and MUST NOT be longer than 65536 bytes. Note that in
+ the UTF-8 encoding a character MAY be encoded into more than one
+ byte. 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 MUST contain only the US-ASCII encodings of the
+ ISO 10646 characters FULL STOP and DIGIT ZERO through DIGIT NINE
+ (0x2E, 0x30-0x39). The formatOID element MUST NOT be of zero length,
+ and SHOULD NOT be longer than 1024 characters.
+
+
+
+Wahl Expires November 10, 2007 [Page 7]
+\f
+Internet-Draft LDAP Session Tracking Control May 2007
+
+
+ The sessionTrackingIdentifier field MAY be of zero length (although
+ this might not be useful). 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. Note that in the UTF-8 encoding a
+ character MAY be encoded into more than one byte.
+
+2.2. Use in LDAP
+
+ The control MAY be included in any LDAP operation. The control has
+ order-dependent semantics.
+
+ A client might place the control on a message with a bindRequest,
+ searchRequest, modifyRequest, addRequest, delRequest, modDNRequest,
+ compareRequest or extendedReq. 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.
+
+ When a network service is proxying or chaining LDAP, in which the
+ service receives an incoming LDAP request from a client and from this
+ generates one or more requests to other LDAP servers, the service
+ SHOULD include any controls of this type that it received from
+ clients in requests it generates, without modification. A service
+ MAY silently remove a control if that control would violate security
+ policy. If the service has its own session state identifier, it
+ SHOULD include the session identifier control it generates in the
+ Controls SEQUENCE after any session identifier controls received by
+ clients. (If there are multiple proxies involved, each will add
+ their own session state to the end of the controls list).
+
+ A server might place the control on message with a bindResponse,
+ searchResDone, modifyResponse, addResponse, delResponse,
+ modDNResponse, compareResponse, extendedResp or intermediateResponse.
+ The server can include the control in the response regardless of
+ whether the client included a control in the request or not. (The
+ control in a response is unsolicited, and a client which does not
+ recognize the control or a session tracking format can safely ignore
+ the control, as discussed in the following section). A server MAY
+ include multiple controls of this type in a response.
+
+2.3. Extensibility considerations
+
+ The following section of this document defines 3 possible formats,
+ and it is expected that applications MAY define their own formats to
+ represent session tracking identifiers already implemented.
+
+ An application developer or server developer who wishes to transfer
+
+
+
+Wahl Expires November 10, 2007 [Page 8]
+\f
+Internet-Draft LDAP Session Tracking Control May 2007
+
+
+ their implementation's 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 SHOULD 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, the
+ control is not properly formatted, or the LDAP client is not
+ authorized to use this control, the LDAP server SHOULD ignore the
+ control and process the request as if the control had not been
+ included.
+
+ When an LDAP client receives a response that includes this control,
+ the behavior depends on the client implementation. Clients SHOULD
+ silently ignore controls with formats they do not recognize, and
+ process the response as if the control had not been included.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl Expires November 10, 2007 [Page 9]
+\f
+Internet-Draft LDAP Session Tracking Control May 2007
+
+
+3. Session tracking format definitions
+
+ This section defines three session tracking formats that can be used
+ within the session tracking control: two for RADIUS accounting, and
+ one based on usernames. Other formats can be defined in other
+ documents.
+
+3.1. 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 ISO 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 ISO 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 was not
+ provided or was not in a recognized format.
+
+3.2. Format for username accounting
+
+ This section defines another possible session tracking format 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.
+
+
+
+
+Wahl Expires November 10, 2007 [Page 10]
+\f
+Internet-Draft LDAP Session Tracking Control May 2007
+
+
+ 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
+ username need not be a distinguished name, and an implementation
+ receiving a control in this format MUST NOT assume that the contents
+ of the sessionTrackingIdentifier can be parsed as a distinguished
+ name.
+
+ 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.
+
+3.2.1. Example
+
+ 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 identifier
+ control. The SessionIdentifierControlValue would have the following
+ ASN.1 value prior to encoding:
+
+
+ { -- 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 November 10, 2007 [Page 11]
+\f
+Internet-Draft LDAP Session Tracking Control May 2007
+
+
+ The session identifier control would be sent with controlType
+ 1.3.6.1.4.1.21008.108.63.1, criticality FALSE, and the controlValue
+ the BER encoding of the SessionIdentifierControlValue. The control
+ included with the LDAP request would resemble:
+
+
+ { -- SEQUENCE
+ "1.3.6.1.4.1.21008.108.63.1", -- controlType
+ FALSE, -- criticality
+ '304204093139322e302e322e31040f6170702e6578616d706c652e636f6d
+ 041c312e332e362e312e342e312e32313030382e3130382e36332e312e33
+ 0406626c6f676773'H -- controlValue
+ }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl Expires November 10, 2007 [Page 12]
+\f
+Internet-Draft LDAP Session Tracking Control May 2007
+
+
+4. 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 a directory server to influence the
+ operation processing 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. LDAP
+ servers which implement this control SHOULD permit the administrator
+ of the directory server to configure that this control is ignored
+ unless the request containing the control was received from a client
+ that been authenticated. LDAP servers which implement this control
+ SHOULD permit the administrator of the directory server to configure
+ that this control is ignored unless the client is authorized to use
+ this or 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.
+
+ In some formats, session tracking identifiers may contain personal-
+ identifiable information, such as usernames or client IP addresses.
+ Unless data link, network or transport level encryption is being
+ used, this information might be visible to attackers monitoring the
+ network segments across which this information is being transmitted.
+ Implementations of LDAP clients which include this control in
+ requests sent to directory servers SHOULD support the use of
+ underlying security services that establish connection
+ confidentiality before the control is sent, such as a SASL mechanism
+ that negotiates a security layer, or the Start TLS operation.
+
+ Correlation of activities across multiple servers can 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 would not
+ be appropriate to deployments intending to anonymize directory
+ requests. Session formats containing personal identifiable
+ information SHOULD NOT be used between systems in different
+ organizations where there is no existing agreement between those
+ organizations on privacy protection.
+
+ A value of the session tracking control might contain internal IP
+ addresses, hostnames and other identifiers that reveal the structure
+ of an enterprise network. A network service that generates its own
+ sessions SHOULD NOT send a session tracking control to a directory
+ server that is under different administration or in a different
+
+
+
+Wahl Expires November 10, 2007 [Page 13]
+\f
+Internet-Draft LDAP Session Tracking Control May 2007
+
+
+ security enclave from itself. A network service that is an LDAP
+ client and also either receives requests over another protocol that
+ contains session tracking identifiers or is proxying incoming LDAP
+ requests SHOULD NOT forward received session tracking identifiers to
+ a directory server that is under different administration or in a
+ different security enclave from itself. A packet inspecting firewall
+ that permits outgoing LDAP requests from an enterprise network SHOULD
+ silently remove any session tracking controls from requests that are
+ being sent to directory servers outside of the enterprise network for
+ which there is not a preexisting policy configured to allow the
+ session tracking control to be sent to that directory server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl Expires November 10, 2007 [Page 14]
+\f
+Internet-Draft LDAP Session Tracking Control May 2007
+
+
+5. 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 November 10, 2007 [Page 15]
+\f
+Internet-Draft LDAP Session Tracking Control May 2007
+
+
+6. Acknowledgments
+
+ This control was inspired by conversations with Greg Lavender. Neil
+ Wilson provided useful feedback on this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl Expires November 10, 2007 [Page 16]
+\f
+Internet-Draft LDAP Session Tracking Control May 2007
+
+
+7. References
+
+7.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.
+
+7.2. Informative References
+
+ [11] Weltman, R., "Lightweight Directory Access Protocol (LDAP)
+ Proxied Authorization Control", RFC 4370, February 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl Expires November 10, 2007 [Page 17]
+\f
+Internet-Draft LDAP Session Tracking Control May 2007
+
+
+Appendix A. Copyright
+
+ Copyright (C) The IETF Trust (2007). 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 November 10, 2007 [Page 18]
+\f
+Internet-Draft LDAP Session Tracking Control May 2007
+
+
+Author's Address
+
+ Mark Wahl
+ Informed Control Inc.
+ PO Box 90626
+ Austin, TX 78709
+ US
+
+ Email: mark.wahl@informed-control.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl Expires November 10, 2007 [Page 19]
+\f
+Internet-Draft LDAP Session Tracking Control May 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ 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, THE IETF TRUST 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 November 10, 2007 [Page 20]
+\f
projects / openldap / commitdiff