doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc6880.txt b/doc/rfc/rfc6880.txt
new file mode 100644
index 0000000..18ccd24
--- /dev/null
+++ b/doc/rfc/rfc6880.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      L. Johansson
+Request for Comments: 6880                                         SUNET
+Category: Standards Track                                     March 2013
+ISSN: 2070-1721
+
+
+              An Information Model for Kerberos Version 5
+
+Abstract
+
+   This document describes an information model for Kerberos version 5
+   from the point of view of an administrative service.  There is no
+   standard for administrating a Kerberos 5 Key Distribution Center
+   (KDC).  This document describes the services exposed by an
+   administrative interface to a KDC.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6880.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johansson                    Standards Track                    [Page 1]
+
+RFC 6880                  KDC Information Model               March 2013
+
+
+Copyright Notice
+
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johansson                    Standards Track                    [Page 2]
+
+RFC 6880                  KDC Information Model               March 2013
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Requirements Notation ...........................................4
+   3. Information Model Demarcation ...................................5
+   4. Information Model Specification .................................6
+      4.1. Principal ..................................................6
+           4.1.1. Principal: Attributes ...............................6
+           4.1.2. Principal: Associations .............................7
+      4.2. KeySet .....................................................8
+           4.2.1. KeySet: Attributes ..................................8
+           4.2.2. KeySet: Associations ................................8
+      4.3. Key ........................................................9
+           4.3.1. Key: Attributes .....................................9
+           4.3.2. Key: Associations ..................................10
+           4.3.3. Key: Remarks .......................................10
+      4.4. Policy ....................................................10
+           4.4.1. Policy: Attributes .................................10
+           4.4.2. Mandatory-to-Implement Policy ......................11
+   5. Implementation Scenarios .......................................11
+      5.1. LDAP Backend to KDC .......................................12
+      5.2. LDAP Frontend to KDC ......................................12
+      5.3. SOAP ......................................................12
+      5.4. NETCONF ...................................................12
+   6. Security Considerations ........................................12
+   7. Acknowledgments ................................................13
+   8. References .....................................................13
+      8.1. Normative References ......................................13
+      8.2. Informative References ....................................14
+
+1.  Introduction
+
+   The Kerberos version 5 authentication service described in [RFC4120]
+   describes how a Key Distribution Center (KDC) provides authentication
+   to clients.  RFC 4120 does not stipulate how a KDC is managed, and
+   several "kadmin" servers have evolved since RFC 4120 was written.
+   This document describes the services required to administer a KDC and
+   the underlying information model assumed by a kadmin-type service.
+
+   The information model is written in terms of "attributes" and either
+   "services" or "interfaces", but the use of these particular words
+   must not be taken to imply any particular modeling paradigm.  Neither
+   an object-oriented model nor a Lightweight Directory Access Protocol
+   (LDAP) [RFC4510] schema is intended.  The author has attempted to
+   describe, in prose, the intended semantics and syntax of the
+   components of the model.  For instance, an LDAP schema based on this
+   model will be more precise in the expression of the syntax while
+   preserving the semantics of this model.
+
+
+
+Johansson                    Standards Track                    [Page 3]
+
+RFC 6880                  KDC Information Model               March 2013
+
+
+   Implementations of this document MAY decide to change the names used
+   (e.g., principalName).  If so, an implementation MUST provide a name-
+   to-name mapping to this document.  In particular, schema languages
+   may have different typographical conventions, e.g., the use of an
+   uppercase letter (as seen in camelCase) versus the use of '_' and '-'
+   to separate 'words' in a name.  Implementations MUST call out such
+   conventions explicitly.
+
+   Implementations of this document MUST be able to support default
+   values for attributes and have the ability to specify syntax for
+   attribute values.
+
+2.  Requirements Notation
+
+   This document uses the standard key words ("MUST", "MUST NOT",
+   "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
+   "RECOMMENDED", "MAY", and "OPTIONAL") that are defined in [RFC2119],
+   but with modifications to those definitions as described below.  The
+   reason for this (which was discussed extensively in the Kerberos
+   working group) is as follows:
+
+   This document describes an information model for Kerberos 5, but it
+   does not directly describe any mapping onto a particular schema or
+   modeling language.  Hence, an implementation of this model consists
+   of a mapping to such a language, e.g., an LDAP or SQL schema.
+   Therefore, the standard normative key words require precise
+   definition.
+
+   The terms "MUST" and "REQUIRED" mean that a schema implementing this
+   model must have a way to represent a feature (i.e., that it is
+   mandatory to implement it in the schema), but that, unless otherwise
+   specified, the feature may represent an optional element in the
+   chosen schema definition language.
+
+   However, "MUST" also means that a KDC or administrative interface
+   implementing this information model has to provide the feature and
+   associated behavior consistent with the schema.
+
+   For instance, principalName (see Section 4.1.1.1) represents the name
+   of a principal.  In an LDAP schema (for instance), this may be
+   represented as an optional attribute even though all KDCs
+   implementing this specification must support this attribute.
+
+   The terms "MAY" and "OPTIONAL" mean that it is optional for a KDC or
+   administrative interface implementing this information model to
+   implement this feature.  These terms also mean that implementing the
+   feature in the schema is optional.
+
+
+
+
+Johansson                    Standards Track                    [Page 4]
+
+RFC 6880                  KDC Information Model               March 2013
+
+
+   Implementers of the schema should be aware that, unless the schema
+   definition can represent critical but optional elements, language
+   confusion may arise when optional elements are used but not
+   understood by all implementations in a particular deployment.
+
+   The expression "MUST NOT be OPTIONAL" means that it is mandatory that
+   a feature be implemented ("MUST" per the definition in [RFC2119]) and
+   additionally that it must not be marked as optional in the schema
+   language.  In particular, this expression means that the feature is
+   both mandatory to implement and must be present in all
+   representations of the object to which it applies.
+
+   The terms "SHOULD" and "RECOMMENDED" mean that the consequences of
+   not implementing the feature as if it were described with the "MUST"
+   keyword must be carefully weighed before choosing a different course.
+   In particular, these terms imply that interoperability concerns may
+   arise from not following the recommended practice in schema that
+   implement this model.
+
+   Context will determine whether the "SHOULD" key word applies to the
+   schema, to the underlying behavior of the KDC, or both.  For
+   instance, when this document states that principalIsDisabled (see
+   Section 4.1.1.4) SHOULD default to FALSE, this statement implies both
+   a recommendation for the behavior of KDCs as well as a recommendation
+   for the representation of that behavior in schema.
+
+3.  Information Model Demarcation
+
+   The information model specified in Section 4 describes objects, their
+   properties, and the relationships between the objects.  These
+   elements comprise an abstract view of the data represented in a KDC.
+   It is important to understand that the information model is not a
+   schema.  In particular, the way objects are compared for equality
+   beyond that which is implied by the specification of a syntax is not
+   part of this specification, nor is the ordering specified between the
+   elements of a particular syntax.
+
+   Further work on Kerberos will undoubtedly prompt updates to this
+   information model to reflect changes in the functions performed by
+   the KDC.  Such extensions to the information model should always use
+   a normative reference to the relevant RFCs in detailing the change in
+   KDC function.
+
+   This model describes a number of elements related to password policy
+   management.  Not all of the elements in this model are unique to
+   Kerberos.  For example, an LDAP implementation of this model should
+   incorporate existing LDAP schema where functional overlap exists,
+   rather than defining additional Kerberos-specific elements.
+
+
+
+Johansson                    Standards Track                    [Page 5]
+
+RFC 6880                  KDC Information Model               March 2013
+
+
+4.  Information Model Specification
+
+4.1.  Principal
+
+   The fundamental entity stored in a KDC is the principal.  The
+   principal is associated with keys and generalizes the "user" concept.
+   The principal MUST be implemented in full and MUST NOT be OPTIONAL in
+   an implementation
+
+4.1.1.  Principal: Attributes
+
+4.1.1.1.  principalName
+
+   The principalName MUST uniquely identify the principal within the
+   administrative context of the KDC.  The principalName MUST be
+   equivalent to the string representation of the principal name (see
+   Section 2.1.1 of [RFC1964]), including, if applicable for the name
+   type, the realm.
+
+   The attribute MAY be multivalued if the implementation supports
+   aliases, enterprise names, or both.  In this case, exactly one of the
+   principalName values MAY be designated as the canonical
+   principalName.  If the implementation supports encryption types
+   (enctypes) that require salt, exactly one of the values of
+   principalName MAY be designated as the canonical salting
+   principalName.
+
+   Implementations (i.e., schema) that support enterprise names,
+   aliases, or both, SHOULD provide for efficient lookup of principal
+   objects based on the alias or enterprise name.
+
+4.1.1.2.  principalNotUsedBefore
+
+   The principal MUST NOT be used before this date.  The syntax of the
+   attribute MUST be Internet date/time format from [RFC3339].  The
+   attribute MUST be single-valued.
+
+4.1.1.3.  principalNotUsedAfter
+
+   The principal MUST NOT be used after this date.  The syntax of the
+   attribute MUST be Internet date/time format from [RFC3339].  The
+   attribute MUST be single-valued.
+
+4.1.1.4.  principalIsDisabled
+
+   A boolean attribute used to disable a principal.  The attribute
+   SHOULD default to boolean FALSE.
+
+
+
+
+Johansson                    Standards Track                    [Page 6]
+
+RFC 6880                  KDC Information Model               March 2013
+
+
+4.1.1.5.  principalLastCredentialChangeTime
+
+   This single-valued attribute contains the time of the last successful
+   change of credentials (e.g., password or private key) associated with
+   this principal.  The syntax of the attribute MUST be Internet
+   date/time format from [RFC3339].
+
+4.1.1.6.  principalCreateTime
+
+   This single-valued attribute contains the time and date when this
+   principal was created.  The syntax of the attribute MUST be Internet
+   date/time format from [RFC3339].
+
+4.1.1.7.  principalModifyTime
+
+   This single-valued attribute contains the time and date when this
+   principal was last modified, excluding changes to credentials.  The
+   syntax of the attribute MUST be Internet date/time format from
+   [RFC3339].
+
+4.1.1.8.  principalMaximumTicketLifetime
+
+   This single-valued attribute contains the time, in seconds,
+   representing the maximum lifetime of a ticket issued for this
+   principal.
+
+4.1.1.9.  principalMaximumRenewableTicketLifetime
+
+   This single-valued attribute contains the delta time, in seconds,
+   representing the maximum amount of time a ticket may be renewed for
+   this principal.
+
+4.1.1.10.  principalAllowedEnctype
+
+   This OPTIONAL multivalued attribute lists the enctypes allowed for
+   this principal.  If empty or absent, any enctype supported by the
+   implementation is allowed for this principal.
+
+   This attribute is intended as a policy attribute and restricts all
+   uses of enctypes, including server, client, and session keys.  Data
+   models MAY choose to use policy objects in order to represent more
+   complex decision mechanisms.
+
+4.1.2.  Principal: Associations
+
+   Each principal MAY be associated with 0 or more KeySets and MAY be
+   associated with 0 or more Policies.  The KeySet is represented as an
+   object in this model, because it has attributes associated with it
+
+
+
+Johansson                    Standards Track                    [Page 7]
+
+RFC 6880                  KDC Information Model               March 2013
+
+
+   (the key version number).  In typical situations, the principal is
+   associated with exactly one KeySet, but implementations MUST NOT
+   assume this case.  That is, an implementation of this standard MUST
+   be able to handle the general case of multiple KeySets associated
+   with each principal.  Multiple KeySets may, for instance, be useful
+   when performing a key rollover for a principal.
+
+4.2.  KeySet
+
+   In Kerberos, principals are associated with zero or more symmetric
+   secret keys, and each key has a key version number (kvno) and an
+   enctype.  In this model, we group keys by kvno into KeySet objects.
+   A principal can have zero or more KeySet objects associated with it,
+   each of which MUST have one or more keys.  Each KeySet is associated
+   with exactly one principal.  A schema derived from this model MAY
+   lack a direct analogue of KeySet, as described in this document.
+
+   It is expected that most Kerberos implementations will use a special-
+   purpose interface for setting and changing principal passwords and
+   keys.
+
+   If a server supports an enctype for a principal, that enctype must be
+   present in at least one key for the principal in question.  For any
+   given enctype, a KeySet MUST NOT contain more than one key with that
+   enctype.
+
+   The security of Kerberos 5 depends absolutely on the confidentiality
+   and integrity of the key objects stored in the KDC.  Implementations
+   of this standard MUST facilitate, to the extent possible, an
+   administrator's ability to place more restrictive access controls on
+   KeySets than on other principal data, and to arrange for more secure
+   backup for KeySets.
+
+4.2.1.  KeySet: Attributes
+
+4.2.1.1.  kvno
+
+   The key version number.  This is a single-valued attribute containing
+   a non-negative integer.  This number is incremented by one each time
+   a key in the KeySet is changed.
+
+4.2.2.  KeySet: Associations
+
+   Each KeySet MUST be associated with a set of one or more Keys.
+
+
+
+
+
+
+
+Johansson                    Standards Track                    [Page 8]
+
+RFC 6880                  KDC Information Model               March 2013
+
+
+4.3.  Key
+
+   Implementations of this model MUST NOT force keys to be represented.
+   That is, a schema that REQUIRED a key to be present would not meet
+   this constraint.
+
+4.3.1.  Key: Attributes
+
+4.3.1.1.  keyEncryptionType
+
+   The enctype SHOULD be represented as an enumeration of the enctypes
+   supported by the KDC using the string name ("encryption type") of the
+   enctype from the IANA registry of Kerberos Encryption Type Numbers.
+   One example is "aes128-cts-hmac-sha1-96".
+
+4.3.1.2.  keyValue
+
+   The binary representation of the key data.  This MUST be a single-
+   valued octet string.
+
+4.3.1.3.  keySaltValue
+
+   The binary representation of the key salt.  This MUST be a single-
+   valued octet string.
+
+4.3.1.4.  keyStringToKeyParameter
+
+   This MUST be a single-valued octet string representing an opaque
+   parameter associated with the enctype.  This parameter is specified
+   using the string-to-key method defined in Section 3 of [RFC3961].
+
+4.3.1.5.  keyNotUsedBefore
+
+   The key MUST NOT be used before this date.  The syntax of the
+   attribute MUST be semantically equivalent to the standard ISO date
+   format ([RFC3339]).  This attribute MUST be single-valued.
+
+4.3.1.6.  keyNotUsedAfter
+
+   The key MUST NOT be used after this date.  The syntax of the
+   attribute MUST be semantically equivalent to the standard ISO date
+   format ([RFC3339]).  This attribute MUST be single-valued.
+
+4.3.1.7.  keyIsDisabled
+
+   This is a boolean attribute that SHOULD be set to FALSE by default.
+   If this attribute is TRUE, the key MUST NOT be used.  The
+   keyIsDisabled attributed is used to temporarily disable a key.
+
+
+
+Johansson                    Standards Track                    [Page 9]
+
+RFC 6880                  KDC Information Model               March 2013
+
+
+4.3.2.  Key: Associations
+
+   None
+
+4.3.3.  Key: Remarks
+
+   The security of the keys is an absolute requirement for the operation
+   of Kerberos 5.  If keys are implemented, adequate protection from
+   unauthorized modification and disclosure MUST be available and is
+   REQUIRED of the implementation.
+
+4.4.  Policy
+
+   Implementations SHOULD implement policies, but MAY allow them to be
+   OPTIONAL.  The policy should be thought of as a "typed hole", i.e.,
+   as an opaque binary value paired with an identifier of the type of
+   data contained in the binary value.  Both attributes (type and value)
+   must be present.
+
+4.4.1.  Policy: Attributes
+
+4.4.1.1.  policyIdentifier
+
+   The policyIdentifier MUST be globally unique.  Possible types of
+   identifiers include:
+
+   o  An Object Identifier (OID) [RFC4517]
+
+   o  A URI [RFC3986]
+
+   o  A UUID [RFC4122]
+
+   Implementations of this specification are expected to assign globally
+   unique identifiers to the list of the standard policy below in
+   accordance with best practices for identifier management for the
+   schema language used.
+
+4.4.1.2.  policyIsCritical
+
+   This boolean attribute indicates that the KDC MUST be able to
+   correctly interpret and apply the policy for the principal to be
+   used.
+
+4.4.1.3.  policyContent
+
+   This optional single opaque binary value is used to store a
+   representation of the policy.  In general, a policy cannot be fully
+   expressed using attribute-value pairs.  The policyContent is OPTIONAL
+
+
+
+Johansson                    Standards Track                   [Page 10]
+
+RFC 6880                  KDC Information Model               March 2013
+
+
+   in the sense that an implementation MAY use it to store an opaque
+   value for the policy types that are not directly representable in
+   that implementation.
+
+4.4.1.4.  policyUse
+
+   This optional single enumerated string value is used to describe the
+   use of the policy.  Implementations SHOULD provide this attribute and
+   MUST (if the attribute is implemented) describe the enumerated set of
+   possible values.  The intent is that this attribute provide an
+   initial context-based filtering.
+
+4.4.2.  Mandatory-to-Implement Policy
+
+   All implementations that represent policy objects MUST be able to
+   represent the policies listed in this section.  Implementations are
+   not required to use the same underlying data representation for the
+   policyContent binary value, but SHOULD use the same OIDs as the
+   policyIdentifier.  In general, the expression of policy may require a
+   Turing-complete language.  This specification does not attempt to
+   model policy-expression language.
+
+4.4.2.1.  Password Quality Policy
+
+   Password quality policy controls the requirements placed by the KDC
+   on new passwords.
+
+4.4.2.2.  Password Management Policy
+
+   Password management policy controls how passwords are changed.
+
+4.4.2.3.  Keying Policy
+
+   A keying policy specifies the association of enctypes with new
+   principals.  For example, when a principal is created, one of the
+   applicable keying policies is used to determine the set of keys to
+   associate with the principal.
+
+4.4.2.4.  Ticket Flag Policy
+
+   A ticket flag policy specifies the ticket flags allowed for tickets
+   issued for a principal.
+
+5.  Implementation Scenarios
+
+   There are several ways to implement an administrative service for
+   Kerberos 5 based on this information model.  In this section, we list
+   a few of them.
+
+
+
+Johansson                    Standards Track                   [Page 11]
+
+RFC 6880                  KDC Information Model               March 2013
+
+
+5.1.  LDAP Backend to KDC
+
+   Given an LDAP schema implementation of this information model, it
+   would be possible to build an administrative service by backending
+   the KDC to a directory server where principals and keys are stored.
+   Using the security mechanisms available on the directory, server keys
+   are protected from access by anyone apart from the KDC.
+   Administration of the principals, policy, and other non-key data is
+   done through the directory server, while the keys are modified using
+   the set/change password protocol [PASSWORD].
+
+5.2.  LDAP Frontend to KDC
+
+   An alternative way to provide a directory interface to the KDC is to
+   implement an LDAP frontend to the KDC that exposes all non-key
+   objects as entries and attributes.  As in the example above, all keys
+   are modified using the set/change password protocol [PASSWORD].  In
+   this scenario, the implementation would typically not use a
+   traditional LDAP implementation, but would treat LDAP as a protocol
+   to access data in the native KDC database.
+
+5.3.  SOAP
+
+   Given an XML schema implementation of this information model, it
+   would be possible to build a SOAP interface to the KDC.  This
+   situation demonstrates the value of creating an abstract information
+   model that is mappable to multiple schema representations.
+
+5.4.  NETCONF
+
+   Given a YAML (YAML Ain't Markup Language) implementation of this
+   information model, it would be possible to create a NETCONF-based
+   interface to the KDC, enabling management of the KDC from standard
+   network management applications.
+
+6.  Security Considerations
+
+   This document describes an abstract information model for Kerberos 5.
+   The Kerberos 5 protocol depends on the security of the keys stored in
+   the KDC.  The model described here assumes that keys MUST NOT be
+   transported in the clear over the network and furthermore that keys
+   be treated as write-only attributes that SHALL be modified (using the
+   administrative interface) only by the change-password protocol
+   [PASSWORD].
+
+   Exposing the object model of a KDC typically implies that objects can
+   be modified, deleted, or both.  In a KDC, not all principals are
+   created equal.  For instance, deleting krbtgt/EXAMPLE.COM@EXAMPLE.COM
+
+
+
+Johansson                    Standards Track                   [Page 12]
+
+RFC 6880                  KDC Information Model               March 2013
+
+
+   effectively disables the EXAMPLE.COM realm.  Hence, access control is
+   paramount to the security of any implementation.  This document does
+   not mandate access control.  This situation implies only that access
+   control is beyond the scope of the standard information model, i.e.,
+   that access control may not be accessible via any protocol based on
+   this model.  If access control objects are exposed via an extension
+   to this model, the presence of access control may in itself provide
+   points of attack by giving away information about principals that
+   have elevated rights.
+
+7.  Acknowledgments
+
+   The author wishes to extend his thanks to Love Hoernquist-Aestrand
+   and Sam Hartman for their important contributions to this document.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
+              1964, June 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3339]  Klyne, G., Ed. and C. Newman, "Date and Time on the
+              Internet: Timestamps", RFC 3339, July 2002.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66, RFC
+              3986, January 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
+              Unique IDentifier (UUID) URN Namespace", RFC 4122, July
+              2005.
+
+   [RFC4517]  Legg, S., "Lightweight Directory Access Protocol (LDAP):
+              Syntaxes and Matching Rules", RFC 4517, June 2006.
+
+
+
+
+
+
+Johansson                    Standards Track                   [Page 13]
+
+RFC 6880                  KDC Information Model               March 2013
+
+
+8.2.  Informative References
+
+   [PASSWORD] Williams, N., "Kerberos Set/Change Key/Password Protocol
+              Version 2", Work in Progress, November 2008.
+
+   [RFC4510]  Zeilenga, K., "Lightweight Directory Access Protocol
+              (LDAP): Technical Specification Road Map", RFC 4510, June
+              2006.
+
+Author's Address
+
+   Leif Johansson
+   Swedish University Network
+   Thulegatan 11
+   Stockholm
+   Sweden
+
+   EMail: leifj@sunet.se
+   URI:   http://www.sunet.se
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johansson                    Standards Track                   [Page 14]
+