관리-도구

편집 파일: draft-wahl-ldap-session-xx.txt

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]  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]  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]  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]  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]  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]  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]  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]  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]  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]  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]  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]  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]  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]  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]  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]  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]  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]  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]  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]