+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires: 20 July 2001 20 January 2001
-
-
-
- LDAP Authentication Password Attribute
- <draft-zeilenga-ldap-authpasswd-04.txt>
-
-
-1. Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with all
- provisions of Section 10 of RFC2026.
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as an Standard Track document.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Extension Working Group
- mailing list <ietf-ldapext@netscape.com>. Please send editorial
- comments directly to the author <Kurt@OpenLDAP.org>.
-
- 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.
-
- Copyright 2001, The Internet Society. All Rights Reserved.
-
- Please see the Copyright section near the end of this document for
- more information.
-
-
-2. Abstract
-
- This document describes schema in support of user/password
- authentication in a LDAP directory including the authPassword
- attribute type. This attribute type holds values derived from the
- user's password(s) (commonly using cryptographic strength one-way
- hash). authPassword is intended to used instead of userPassword.
-
-
-
-
-Zeilenga [Page 1]
-\f
-INTERNET-DRAFT LDAP AuthPassword 20 January 2001
-
-
- The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL
- NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', and ``MAY'' in
- this document are to be interpreted as described in RFC 2119
- [RFC2119].
-
-
-3. Background and Intended Use
-
- The userPassword attribute type [RFC 2256] is intended be used to used
- to support the LDAP [RFC2251] "simple" bind operation. However,
- values of userPassword must be clear text passwords. It is often
- desirable to store values derived from the user's password(s) instead
- of actual passwords.
-
- The authPassword attribute type is intended to be used to store
- information used to implement simple password based authentication.
- The attribute type may be used by LDAP servers to implement the LDAP
- Bind operation's "simple" authentication method.
-
- The attribute type supports multiple storage schemes. A matching rule
- is provided for use with extensible search filters to allow clients to
- assert that a clear text password "matches" one of the attribute's
- values.
-
- Storage schemes often use of cryptographic strength one-way hashing.
- Though the use of one-way hashing reduces the potential that exposed
- values will allow unauthorized access to the Directory (unless the
- hash algorithm/implementation is flawed), the hashing of passwords is
- intended to be as an additional layer of protection. It is
- RECOMMENDED that hashed values be protected as if they were clear text
- passwords.
-
- This attribute may be used in conjunction with server side password
- generation mechanisms (such as [PW-EXOP]).
-
- Access to this attribute may governed by administrative controls such
- as those which implement password change policies.
-
-
-4. Schema Definitions
-
- The following schema definitions are described in terms of LDAPv3
- Attribute Syntax Definitions [RFC2252] with specific syntax detailed
- using Augmented BNF [RFC2234].
-
- Editor's Note: object identifiers (OIDs) will be assigned before this
- document is published as an RFC.
-
-
-
-
-Zeilenga [Page 2]
-\f
-INTERNET-DRAFT LDAP AuthPassword 20 January 2001
-
-
-4.1. authPasswordSyntax
-
- ( authPasswordSyntaxOID
- DESC 'authentication password syntax' )
-
- Values of this syntax are encoded according to:
-
- authPasswordValue = w scheme s [authInfo] s authValue w
- scheme = %x30-39 / %x41-5A / %x2D-2F / %x5F
- ; 0-9, A-Z, "-", ".", "/", or "_"
- authInfo = schemeSpecificValue
- authValue = schemeSpecificValue
- schemeSpecificValue = *( %x21-23 / %25-7E )
- ; printable ascii less "$" and " "
- s = w sep w
- w = *sp
- sep = %x24 ; dollar sign
- sp = %x20 ; space
-
- where scheme describes the mechanism and authInfo and authValue are a
- scheme specific. The authInfo field is often a base64 encoded salt.
- The authValue field is often a base64 encoded value derived from a
- user's password(s). Values of this attribute are case sensitive.
-
- This document describes a number of schemes, as well as requirements
- for the scheme naming, in section 5.
-
-
-4.2. authPasswordMatch
-
- ( authPasswordMatchOID
- NAME 'authPasswordMatch'
- DESC 'authentication password matching rule'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
-
- This matching rule allows a client to assert that a password matches
- values of authPasswordSyntax using an extensibleMatch filter
- component. Each value is matched per its scheme. The assertion is
- TRUE if one or more attribute values matches the asserted value, FALSE
- if all values do not matches, and Undefined otherwise.
-
- Servers which support use of this matching rule SHOULD publish
- appropriate matchingRuleUse values per [RFC2252], 4.4.
-
- Transfer of authPasswordMatch assertion values is strongly discouraged
- where the underlying transport service cannot guarantee
- confidentiality and may result in disclosure of the values to
- unauthorized parties.
-
-
-
-Zeilenga [Page 3]
-\f
-INTERNET-DRAFT LDAP AuthPassword 20 January 2001
-
-
-4.3. supportedAuthPasswordSchemes
-
- ( supportedAuthPasswordSchemesOID
- NAME 'supportedAuthPasswordSchemes'
- DESC 'supported password storage schemes'
- EQUALITY caseExactIA5Match
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32}
- USAGE dSAOperation )
-
- The values of this attribute are names of supported authentication
- password schemes which the server supports. The syntax of a scheme
- name is described in section 4.1. This attribute may only be present
- in the root DSE. If the server does not support any password schemes,
- this attribute will not be present.
-
-
-4.4. authPassword
-
- ( authPasswordOID NAME 'authPassword'
- SYNTAX authPasswordSyntaxOID )
-
- The values of this attribute are representative of the user's
- password(s) and conform to the authPasswordSyntax described in 4.1.
- The values of this attribute may be used for authentication purposes.
-
- This attribute type is defined without any built-in matching rules.
- The absence of an EQUALITY matching rules disallows modification of
- individual values.
-
- Transfer of authPassword values is strongly discouraged where the
- underlying transport service cannot guarantee confidentiality and may
- result in disclosure of the values to unauthorized parties.
-
-
-4.5. authPasswordObject
-
- ( authPasswordObjectOID NAME 'authPasswordObject'
- DESC 'authentication password mix in class'
- MAY 'authPassword' AUXILIARY )
-
- Entries of this object class may contain authPassword attribute types.
-
-
-5. Schemes
-
- This section describes the "MD5" and "SHA1". Other schemes may be
- defined by other documents. Schemes which are not described by
- standard track documents SHOULD be named with a leading "X-" to
-
-
-
-Zeilenga [Page 4]
-\f
-INTERNET-DRAFT LDAP AuthPassword 20 January 2001
-
-
- indicate they are a private or implementation specific scheme, or may
- be named using the dotted-decimal representation [RFC2252] of an OID
- assigned to the scheme.
-
-
-5.1. MD5 scheme
-
- The MD5 [RFC1321] scheme name is "MD5".
-
- The authValue is the base64 encoding of an MD5 digest of the
- concatenation the user password and salt. The base64 encoding of the
- salt is provided in the authInfo field. The salt MUST be at least
- 64-bits long. Implementations of this scheme MUST support salts up to
- 128-bit in length.
-
- Example:
- Given a user "joe" who's password is "mary" and a salt of "salt",
- the authInfo field would be the base64 encoding of "salt" and the
- authValue field would be the base64 encoding of the MD5 digest of
- "marysalt".
-
- A match against an asserted password and an attribute value of this
- scheme SHALL be true if and only if the MD5 digest of concatenation of
- the asserted value and the salt is equal to the MD5 digest contained
- in AuthValue. The match SHALL be undefined if the server is unable to
- complete the equality test for any reason. Otherwise the match SHALL
- be false.
-
- Values of this scheme SHOULD only be used to implement simple
- user/password authentication.
-
-
-5.2. SHA1 scheme
-
- The SHA1 [SHA1] scheme name is "SHA1".
-
- The authValue is the base64 encoding of an SHA1 digest of the
- concatenation the user password and the salt. The base64 encoding of
- the salt is provided in the authInfo field. The salt MUST be at least
- 64-bits long. Implementations of this scheme MUST support salts up to
- 128-bit in length.
-
- Example:
- Given a user "joe" who's password is "mary" and a salt of "salt",
- the authInfo field would be the base64 encoding of "salt" and the
- authValue field would be the base64 encoding of the SHA1 digest of
- "marysalt".
-
-
-
-
-Zeilenga [Page 5]
-\f
-INTERNET-DRAFT LDAP AuthPassword 20 January 2001
-
-
- A match against an asserted password and an attribute value of this
- scheme SHALL be true if and only if the SHA1 digest of concatenation
- of the asserted value and the salt is equal to the SHA1 digest
- contained in AuthValue. The match SHALL be undefined if the server is
- unable to complete the equality test for any reason. Otherwise the
- match SHALL be false.
-
- Values of this scheme SHOULD only be used to implement simple
- user/password authentication.
-
-
-6. Implementation Issues
-
- For implementations of this specification:
-
- Servers MAY restrict which schemes are used in conjunction with a
- particular authentication process but SHOULD use all values of
- selected schemes. If the asserted password matches any of the
- stored values, the asserted password SHOULD be considered valid.
- Servers MAY use other authentication storage mechanisms, such as
- userPassword or an external password store, in conjunction with
- authPassword to support the authentication process.
-
- Servers that support simple bind MUST support the SHA1 scheme and
- SHOULD support the MD5 scheme.
-
- Servers SHOULD not publish values of authPassword nor allow
- operations which expose authPassword or AuthPasswordMatch values to
- unless confidentiality protection is in place.
-
- Clients SHOULD not initiate operations which provide or request
- values of authPassword or make authPasswordMatch assertions unless
- confidentiality protection is in place.
-
- Clients SHOULD not assume that a successful AuthPasswordMatch,
- whether by compare or search, is sufficient to gain directory
- access. The bind operation MUST be used to authentication to the
- directory.
-
-
-7. Security Considerations
-
- This document describes how authentication information may be stored
- in a directory. Authentication information MUST be adequately
- protected as unintended disclosure will allow attackers to gain
- immediate access to the directory as described by [RFC2829].
-
- As flaws may be discovered in the hashing algorithm or with a
-
-
-
-Zeilenga [Page 6]
-\f
-INTERNET-DRAFT LDAP AuthPassword 20 January 2001
-
-
- particular implementation of the algorithm or may be subjected to
- dictionary or other attacks if exposed, values of AuthPassword SHOULD
- be protected as if they were clear text passwords. When values are
- transferred, privacy protections, such as IPSEC or TLS, SHOULD be in
- place.
-
- Clients SHOULD use strong authentication mechanisms [RFC2829].
-
- AuthPasswordMatch matching rule allows applications to test the
- validity of a user password and, hence, may be used to mount an
- attack. Servers SHOULD take appropriate measures to protect the
- directory from such attacks.
-
- Some password schemes may require CPU intensive operations. Servers
- SHOULD take appropriate measures to protect against Denial of Service
- attacks.
-
- AuthPassword does not restrict an authentication identity to a single
- password. An attacker who gains write access to this attribute may
- store additional values without disabling the user's true password(s).
- Use of policy aware clients and servers is RECOMMENDED.
-
- The level of protection offered against various attacks differ from
- scheme to scheme. It is RECOMMENDED that servers support scheme
- selection as a configuration item. This allows for a scheme to be
- easily disabled if a significant security flaw is discovered.
-
-
-8. Copyright
-
- Copyright 2001, The Internet Society. All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published and
- distributed, in whole or in part, without restriction of any kind,
- provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be followed,
- or as required to translate it into languages other than English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
-
-
-
-Zeilenga [Page 7]
-\f
-INTERNET-DRAFT LDAP AuthPassword 20 January 2001
-
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIMS 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.
-
-
-9. Acknowledgment
-
- This document borrows from a number of IETF documents and is based
- upon input from the IETF LDAPext working group.
-
-
-10. Bibliography
-
- [RFC1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321,
- April 1992
-
- [RFC2219] S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997.
-
- [RFC2222] J. Myers, "Simple Authentication and Security Layer (SASL)",
- RFC 2222, October 1997.
-
- [RFC2234] D. Crocker (editor), P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
-
- [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
- Directory Access Protocol (v3): Attribute Syntax
- Definitions", RFC 2252, December 1997.
-
- [RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use
- with LDAPv3", RFC 2256, December 1997.
-
- [RFC2307] L. Howard, "An Approach for Using LDAP as a Network
- Information Service", RFC 2307, March 1998. (not normative)
-
- [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, RL "Bob" Morgan,
- "Authentication Methods for LDAP", RFC 2829, June 2000.
-
- [PW-EXOP] K. Zeilenga, "LDAP Password Modify Extended Operation"
- draft-zeilenga-ldap-passwd-exop-xx.txt, a work in progress.
-
- [SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
-
-
-
-Zeilenga [Page 8]
-\f
-INTERNET-DRAFT LDAP AuthPassword 20 January 2001
-
-
-11. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
- <Kurt@OpenLDAP.org>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga [Page 9]
-\f
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires: 4 January 2001 4 July 2000
-
-
- LDAPv3: Grouping of Related Operations
- <draft-zeilenga-ldap-grouping-00.txt>
-
-
-Status of Memo
-
- This document is an Internet-Draft and is in full conformance with all
- provisions of Section 10 of RFC2026.
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as a Standard Track document.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Extension Working Group
- mailing list <ietf-ldapext@netscape.com>. Please send editorial
- comments directly to the author <Kurt@OpenLDAP.org>.
-
- 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.
-
- Copyright 2000, The Internet Society. All Rights Reserved.
-
- Please see the Copyright section near the end of this document for
- more information.
-
-
-1. Abstract
-
- This document provides a general mechanisms for grouping related LDAP
- operations. Grouping of operations may be used to support
- replication, proxies, and higher level operations such as
- transactions. This document describes a set of LDAP [RFC2251]
- extended operations and other protocol and schema elements to support
- grouping of related operations.
-
-
-
-
-Zeilenga [Page 1]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-00 4 July 2000
-
-
-2. Overview
-
- This document provides a mechanism to allow clients to group
- operations.
-
- A group of operations is defined as a set of operations upon a common
- session identified by a unique cookie. All requests which are
- initiated with the same cookie belong to same grouping. The cookie is
- obtained using the create group operation and is normally valid until
- the end group operation is issued. A group may be ended by a server
- prematurely as noted described below.
-
- Operations regardless of their grouping (or lack of grouping) may be
- intermixed. Groups may be nested.
-
- Each group is of a particular type. This type defines the semantics
- of the group and is specified when the group is created.
-
- The key words "SHALL", "SHALL NOT", "MUST", "MUST NOT", "SHOULD",
- "SHOULD NOT", "MAY" and "MAY NOT" used in this document are to be
- interpreted as described in [RFC2119].
-
-
-3. Protocol Elements
-
- This document describes two extended operations, one unsolicited
- notification, and one control. Extended operations and controls are
- described by LDAP [RFC2251] as follows:
-
- ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
- requestName [0] LDAPOID,
- requestValue [1] OCTET STRING OPTIONAL
- }
-
- ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
- COMPONENTS of LDAPResult,
- responseName [10] LDAPOID OPTIONAL,
- response [11] OCTET STRING OPTIONAL
- }
-
- Control ::= SEQUENCE {
- controlType LDAPOID,
- criticality BOOLEAN DEFAULT FALSE,
- controlValue OCTET STRING OPTIONAL
- }
-
-
- Editor's Note:
-
-
-
-Zeilenga [Page 2]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-00 4 July 2000
-
-
- OID which appear in this document are fictious. Actual OIDs will be
- assigned before this document is progressed.
-
-3.1 Common Protocol Elements
-
- groupCookie :== OCTET STRING
-
- A groupCookie is an arbitrary octet string uniquely identify a
- grouping of related operations within the session.
-
- A groupCookie is a notational convenience.
-
-
-
-3.2 createGrouping Operation
-
- The createGrouping extended operation is used to create or start a
- grouping of related operations. The operation consists of the
- createGroupingRequest and the createGroupingResponse. The OID
- createGroupingOID identifies this operation and SHOULD be listed as a
- value of supportedExtensions in the root DSE of servers which support
- this operation.
-
- createGroupingOID ::= "1.1.1"
-
-
-3.2.1 createGroupingRequest
-
- The client initiates this operation by sending a
- createGroupingRequest. This request is an ExtendedRequest where the
- requestName is the value createGroupOID and requestValue is BER
- encoded createGroupingRequestValue
-
- createGroupingRequestValue ::= SEQUENCE {
- createGroupType [0] LDAPOID,
- createGroupValue [1] OCTET STRING OPTIONAL
- }
-
- where createGroupType is an OID that describes the specific type of
- grouping and createGroupValue contains a type specific payload.
-
-
-3.2.1 createGroupingResponse
-
- The createGroupingResponse is sent in response to a
- createGroupingRequest. This response is an ExtendedResponse where the
- responseName MUST be the value of the requestName provided in request
- and the response is a BER encoded createGroupingResponseValue.
-
-
-
-Zeilenga [Page 3]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-00 4 July 2000
-
-
- createGroupingResponseValue ::= SEQUENCE {
- createGroupCookie [0] groupCookie,
- createGroupValue [1] OCTET STRING OPTIONAL
- }
-
- where createGroupCookie is a cookie uniquely identifying the grouping
- and createGroupValue is a type specific payload.
-
-
-3.3 endGrouping Operation
-
- The endGrouping extended operation is used to end or stop a grouping
- of related operations. The operation consists of the
- endGroupingRequest and the endGroupingResponse. The OID
- endGroupingOID identifies this operation and SHOULD be listed as a
- value of supportedExtensions in the root DSE of servers which support
- this operation.
-
- endGroupingOID ::= "1.1.2"
-
-
-3.3.1 endGroupingRequest
-
- The client initiates this operation by sending an endGroupingRequest.
- This request is an ExtendedRequest where the requestName is the value
- endGroupOID and requestValue is BER encoded endGroupingRequestValue
-
- endGroupingRequestValue ::= SEQUENCE {
- endGroupCookie [0] groupCookie,
- groupValue [1] OCTET STRING OPTIONAL
- }
-
- where endGroupCookie is an cookie identifying the grouping and
- groupValue contains a type specific payload.
-
-
-3.3.2 endGroupingResponse
-
- The endGroupingResponse is sent in response to a endGroupingRequest.
- This response is an ExtendedResponse where the responseName MUST be
- the value of the requestName provided in request and the response is a
- BER encoded endGroupingResponseValue
-
- endGroupingResponseValue ::= SEQUENCE {
- groupValue [1] OCTET STRING OPTIONAL
- }
-
- where groupValue is a type specific payload.
-
-
-
-Zeilenga [Page 4]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-00 4 July 2000
-
-
-3.4 endGroupingNotice
-
- The endGroupingNotice is an LDAP unsolicited notification. The
- notification may be sent to the client to end a grouping which the
- server is unable or unwilling to continue to process. The notice is
- an extendedResponse where the responseName is the OID
- endGroupingNoticeOID and the response is a BER encoded
- endGroupingNoticeValue
-
- endGroupingNoticeOID ::= "1.1.3"
-
- endGroupingNoticeValue ::= SEQUENCE {
- endGroupingCookie [0] groupCookie,
- groupValue [1] OCTET STRING OPTIONAL
- }
-
- where endGroupingCookie is a cookie uniquely identifying the grouping
- and groupingValue contains a type specific payload.
-
-
-3.5 groupingControl
-
- The groupingControl is used to identify requests and responses as
- belonging to grouping of operations. The groupingControl is a Control
- where the controlType is the OID groupingControlOID and the
- criticalValue is a BER encoded groupingControlValue
-
- groupingControlOID ::= "1.1.4"
-
- groupingControlValue ::= SEQUENCE {
- groupingCookie [0] groupCookie,
- groupValue [1] OCTET STRING OPTIONAL
- }
-
- where groupingCookie is a cookie uniquely identifying the grouping,
- the critical is TRUE, and groupingValue contains a type specific
- payload.
-
- The value groupingControlOID SHOULD be listed as a value of
- supportedControls in the root DSE by servers which support this
- control.
-
- The control MAY be present on add, compare, delete, moddn, modify, and
- search requests and responses. The control SHALL NOT be present on a
- abandon, bind, unbind. The control SHALL NOT be present on any
- extended operation which affects the behavior of the session such as
- the Start TLS [RFC2830] operation. The control SHALL NOT be present
- if the operation includes any control which likewise causes the
-
-
-
-Zeilenga [Page 5]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-00 4 July 2000
-
-
- operation to affects the behavior of the session.
-
- The control SHALL NOT appear multiple times in the same LDAP PDU and.
- If multiple occurrences of the control are detected, the PDU MUST be
- treated as a protocol error.
-
-4. Schema Elements
-
-4.1. supportedGroupingTypes
-
- Servers SHOULD publish grouping types they support listing their OID
- as values of the supportedGrouping attribute type in the root DSE.
- The supportedGrouping attribute type is defined as:
-
- ( 1.1.5 NAME 'supportedGroupingTypes'
- DESC 'supported types of groupings of operations'
- EQUALITY objectIdentifierMatch
- SYNTAX ObjectIdentifierSyntax )
-
-
-5. Operational Semantics
-
- This section needs work.
-
-
-5.1 Grouping Operations
-
-
-5.1.1 createGrouping
-
- To group related operations, the client MUST request a groupCookie
- from the server by sending a createGroupingRequest as described in
- 3.2.1. The client SHALL provide type specific payload in
- createGroupValue if so required by the grouping type.
-
- The server SHALL respond with a createGroupingResponse as described in
- 3.2.2. If the server is willing and able to create the grouping as
- requested (and per type requirements), it SHALL respond with success,
- provide a session-unique groupCookie and, if appropriate, a type
- specific payload. Otherwise the server SHALL respond with a non-
- successful response and provide no groupCookie, but MAY, if
- appropriate, provide a type specific payload.
-
-
-5.1.2 endGrouping
-
- When the client wishes to end the grouping, the client SHALL send a
- endGroupingRequest as described in 3.3.1. The client SHALL provide
-
-
-
-Zeilenga [Page 6]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-00 4 July 2000
-
-
- the groupCookie of the grouping to be ended and MAY provided a type
- specific payload.
-
- The server SHALL respond with an endGroupingResponse as described in
- 3.3.2.
-
-
-5.1.3 endGroupNotice
-
- The server MAY end a group without solicitation for any reason but
- MUST send a endGrouping Notice, as described in 3.4, indicating this
- action. The server SHALL provide the groupCookie of the group it
- terminated and MAY provide a type specific payload. The notice SHALL
- have a non-success resultCode.
-
-
-5.1.4 grouped operations
-
- Operations with a group are carry a groupingControl as described in
- 3.5.
-
- Group type specifications MAY restrict the types and/or number of
- operations which may be related. Servers MAY also place restrictions
- upon groupings. Clients SHOULD NOT assume arbitrary support for
- grouping.
-
-
-5.1.5 nested groupings
-
- Groups of the same or different types may be nested. A nested group
- is instantiated by providing a groupingControl containing the parent
- group with the createGroupingRequest.
-
- Group type specifications MAY restrict the types of groupings which
- may be nested. Servers MAY also place restrictions upon nesting.
- Clients SHOULD NOT assume arbitrary support for nesting.
-
-
-5.3 Other Operations
-
- Upon issuing of any grouping operation, semantics of non-grouping
- operations listed is modified as described below.
-
-5.3.1 bind
-
- The client SHOULD end all outstanding groupings before issuing a bind
- request.
-
-
-
-
-Zeilenga [Page 7]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-00 4 July 2000
-
-
- The bind operation MUST, in addition to the behavior described in RFC
- 2251, must abandon all outstanding groups.
-
-
-5.3.2 unbind
-
- The unbind operation MUST, in addition to the behavior described in
- RFC 2251, must abandon all outstanding groups.
-
-
-5.3.3 Start TLS
-
- The client SHALL end all outstanding groupings before issuing a Start
- TLS request.
-
- The Start TLS operation MUST, in addition to the behavior described in
- RFC 2830, return operationsError if there are any outstanding
- groupings.
-
-
-7. Security Considerations
-
- This mechanism may be used to support complex groupings of related
- operations for arbitrary purposes. This document places no
- restrictions on how the grouped operations relate to each other.
-
- It is conceived that different groups of operations may have different
- authorization and/or access controls associated with them (when used
- to multiplex proxied directory sessions). Authors of specifications
- for such groupings take special care in addressing security issues.
-
- It is conceived that different groups of operations may form complex
- super-operations such as transactions. Authors of specifications for
- such groupings should take special care to address denial of service
- issues.
-
-
-8. References
-
- [RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate
- Requirement Levels", Harvard University, RFC 2119, March
- 1997.
-
- [RFC2251] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
-
-
-9. Acknowledgments
-
-
-
-Zeilenga [Page 8]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-00 4 July 2000
-
-
- The author gratefully acknowledge the contributions of the IETF LDUP
- and LDAPext working group.
-
-
-10. Additional Information
-
- Discussions regarding these suggestions may directed to the author:
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
- <Kurt@OpenLDAP.org>
-
- or the LDAPext Working Group mailing list:
-
- <ietf-ldapext@netscape.com>
-
-
-Copyright 2000, The Internet Society. All Rights Reserved.
-
- This document and translations of it may be copied and furnished
- to others, and derivative works that comment on or otherwise explain
- it or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph
- are included on all such copies and derivative works. However,
- this document itself may not be modified in any way, such as by
- removing the copyright notice or references to the Internet Society
- or other Internet organizations, except as needed for the purpose
- of developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not
- be revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on
- an "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE
- INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
-
-
-
-
-
-
-
-
-Zeilenga [Page 9]
-\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 3112 OpenLDAP Foundation
+Category: Informational May 2001
+
+
+ LDAP Authentication Password Schema
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Abstract
+
+ This document describes schema in support of user/password
+ authentication in a LDAP (Lightweight Directory Access Protocol)
+ directory including the authPassword attribute type. This attribute
+ type holds values derived from the user's password(s) (commonly using
+ cryptographic strength one-way hash). authPassword is intended to
+ used instead of userPassword.
+
+1. Background and Intended Use
+
+ The userPassword attribute type [RFC2256] is intended to be used to
+ support the LDAP [RFC2251] "simple" bind operation. However, values
+ of userPassword must be clear text passwords. It is often desirable
+ to store values derived from the user's password(s) instead of actual
+ passwords.
+
+ The authPassword attribute type is intended to be used to store
+ information used to implement simple password based authentication.
+ The attribute type may be used by LDAP servers to implement the LDAP
+ Bind operation's "simple" authentication method.
+
+ The attribute type supports multiple storage schemes. A matching
+ rule is provided for use with extensible search filters to allow
+ clients to assert that a clear text password "matches" one of the
+ attribute's values.
+
+ Storage schemes often use cryptographic strength one-way hashing.
+ Though the use of one-way hashing reduces the potential that exposed
+ values will allow unauthorized access to the Directory (unless the
+
+
+
+
+Zeilenga Informational [Page 1]
+\f
+RFC 3112 LDAP Authentication Password Schema May 2001
+
+
+ hash algorithm/implementation is flawed), the hashing of passwords is
+ intended to be as an additional layer of protection. It is
+ RECOMMENDED that hashed values be protected as if they were clear
+ text passwords.
+
+ This attribute may be used in conjunction with server side password
+ generation mechanisms (such as the LDAP Password Modify [RFC3062]
+ extended operation).
+
+ Access to this attribute may governed by administrative controls such
+ as those which implement password change policies.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
+ to be interpreted as described in RFC 2119 [RFC2119].
+
+2. Schema Definitions
+
+ The following schema definitions are described in terms of LDAPv3
+ Attribute Syntax Definitions [RFC2252] with specific syntax detailed
+ using Augmented BNF [RFC2234].
+
+2.1. authPasswordSyntax
+
+ ( 1.3.6.1.4.1.4203.1.1.2
+ DESC 'authentication password syntax' )
+
+ Values of this syntax are encoded according to:
+
+ authPasswordValue = w scheme s authInfo s authValue w
+ scheme = %x30-39 / %x41-5A / %x2D-2F / %x5F
+ ; 0-9, A-Z, "-", ".", "/", or "_"
+ authInfo = schemeSpecificValue
+ authValue = schemeSpecificValue
+ schemeSpecificValue = *( %x21-23 / %x25-7E )
+ ; printable ASCII less "$" and " "
+ s = w SEP w
+ w = *SP
+ SEP = %x24 ; "$"
+ SP = %x20 ; " " (space)
+
+ where scheme describes the mechanism and authInfo and authValue are a
+ scheme specific. The authInfo field is often a base64 encoded salt.
+ The authValue field is often a base64 encoded value derived from a
+ user's password(s). Values of this attribute are case sensitive.
+
+
+
+
+
+
+Zeilenga Informational [Page 2]
+\f
+RFC 3112 LDAP Authentication Password Schema May 2001
+
+
+ Transfer of values of this syntax is strongly discouraged where the
+ underlying transport service cannot guarantee confidentiality and may
+ result in disclosure of the values to unauthorized parties.
+
+ This document describes a number of schemes, as well as requirements
+ for the scheme naming, in section 3.
+
+2.2. authPasswordExactMatch
+
+ ( 1.3.6.1.4.1.4203.1.2.2
+ NAME 'authPasswordExactMatch'
+ DESC 'authentication password exact matching rule'
+ SYNTAX 1.3.6.1.4.1.4203.1.1.2 )
+
+ This matching rule allows a client to assert that an asserted
+ authPasswordSyntax value matches authPasswordSyntax values. It is
+ meant to be used as the EQUALITY matching rule of attributes whose
+ SYNTAX is authPasswordSyntax.
+
+ The assertion is "TRUE" if there is an attribute value which has the
+ same scheme, authInfo, and authValue components as the asserted
+ value; "FALSE" if no attribute value has the same components as the
+ asserted value; and "Undefined" otherwise.
+
+2.3. authPasswordMatch
+
+ ( 1.3.6.1.4.1.4203.1.2.3
+ NAME 'authPasswordMatch'
+ DESC 'authentication password matching rule'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
+
+ This matching rule allows a client to assert that a password matches
+ values of authPasswordSyntax using an extensibleMatch filter
+ component. Each value is matched per its scheme. The assertion is
+ "TRUE" if one or more attribute values matches the asserted value,
+ "FALSE" if all values do not matches, and "Undefined" otherwise.
+
+ Servers which support use of this matching rule SHOULD publish
+ appropriate matchingRuleUse values per [RFC2252], 4.4.
+
+ Transfer of authPasswordMatch assertion values is strongly
+ discouraged where the underlying transport service cannot guarantee
+ confidentiality and may result in disclosure of the values to
+ unauthorized parties.
+
+
+
+
+
+
+
+Zeilenga Informational [Page 3]
+\f
+RFC 3112 LDAP Authentication Password Schema May 2001
+
+
+2.4. supportedAuthPasswordSchemes
+
+ ( 1.3.6.1.4.1.4203.1.3.3
+ NAME 'supportedAuthPasswordSchemes'
+ DESC 'supported password storage schemes'
+ EQUALITY caseExactIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32}
+ USAGE dSAOperation )
+
+ The values of this attribute are names of supported authentication
+ password schemes which the server supports. The syntax of a scheme
+ name is described in section 2.1. This attribute may only be present
+ in the root DSE. If the server does not support any password
+ schemes, this attribute will not be present.
+
+2.5. authPassword
+
+ ( 1.3.6.1.4.1.4203.1.3.4 NAME 'authPassword'
+ DESC 'password authentication information'
+ EQUALITY 1.3.6.1.4.1.4203.1.2.2
+ SYNTAX 1.3.6.1.4.1.4203.1.1.2 )
+
+ The values of this attribute are representative of the user's
+ password(s) and conform to the authPasswordSyntax described in 2.1.
+ The values of this attribute may be used for authentication purposes.
+
+ Transfer of authPassword values is strongly discouraged where the
+ underlying transport service cannot guarantee confidentiality and may
+ result in disclosure of the values to unauthorized parties.
+
+2.6. authPasswordObject
+
+ ( 1.3.6.1.4.1.4203.1.4.7 NAME 'authPasswordObject'
+ DESC 'authentication password mix in class'
+ MAY 'authPassword'
+ AUXILIARY )
+
+ Entries of this object class may contain authPassword attribute
+ types.
+
+3. Schemes
+
+ This section describes the "MD5" and "SHA1" schemes. Other schemes
+ may be defined by other documents. Schemes which are not described
+ in an RFC SHOULD be named with a leading "X-" to indicate they are a
+ private or implementation specific scheme, or may be named using the
+ dotted-decimal representation [RFC2252] of an OID assigned to the
+ scheme.
+
+
+
+Zeilenga Informational [Page 4]
+\f
+RFC 3112 LDAP Authentication Password Schema May 2001
+
+
+3.1. MD5 scheme
+
+ The MD5 [RFC1321] scheme name is "MD5".
+
+ The authValue is the base64 encoding of an MD5 digest of the
+ concatenation the user password and salt. The base64 encoding of the
+ salt is provided in the authInfo field. The salt MUST be at least 64
+ bits long. Implementations of this scheme MUST support salts up to
+ 128 bits in length.
+
+ Example:
+ Given a user "joe" who's password is "mary" and a salt of "salt",
+ the authInfo field would be the base64 encoding of "salt" and the
+ authValue field would be the base64 encoding of the MD5 digest of
+ "marysalt".
+
+ A match against an asserted password and an attribute value of this
+ scheme SHALL be true if and only if the MD5 digest of concatenation
+ of the asserted value and the salt is equal to the MD5 digest
+ contained in AuthValue. The match SHALL be undefined if the server
+ is unable to complete the equality test for any reason. Otherwise
+ the match SHALL be false.
+
+ Values of this scheme SHOULD only be used to implement simple
+ user/password authentication.
+
+3.2. SHA1 scheme
+
+ The SHA1 [SHA1] scheme name is "SHA1".
+
+ The authValue is the base64 encoding of a SHA1 digest of the
+ concatenation the user password and the salt. The base64 encoding of
+ the salt is provided in the authInfo field. The salt MUST be at
+ least 64 bits long. Implementations of this scheme MUST support
+ salts up to 128 bits in length.
+
+ Example:
+ Given a user "joe" who's password is "mary" and a salt of "salt",
+ the authInfo field would be the base64 encoding of "salt" and the
+ authValue field would be the base64 encoding of the SHA1 digest of
+ "marysalt".
+
+ A match against an asserted password and an attribute value of this
+ scheme SHALL be true if and only if the SHA1 digest of concatenation
+ of the asserted value and the salt is equal to the SHA1 digest
+ contained in AuthValue. The match SHALL be undefined if the server
+ is unable to complete the equality test for any reason. Otherwise
+ the match SHALL be false.
+
+
+
+Zeilenga Informational [Page 5]
+\f
+RFC 3112 LDAP Authentication Password Schema May 2001
+
+
+ Values of this scheme SHOULD only be used to implement simple
+ user/password authentication.
+
+4. Implementation Issues
+
+ For all implementations of this specification:
+
+ Servers MAY restrict which schemes are used in conjunction with a
+ particular authentication process but SHOULD use all values of
+ selected schemes. If the asserted password matches any of the
+ stored values, the asserted password SHOULD be considered valid.
+ Servers MAY use other authentication storage mechanisms, such as
+ userPassword or an external password store, in conjunction with
+ authPassword to support the authentication process.
+
+ Servers that support simple bind MUST support the SHA1 scheme and
+ SHOULD support the MD5 scheme.
+
+ Servers SHOULD NOT publish values of authPassword nor allow
+ operations which expose authPassword values or AuthPasswordMatch
+ assertions to unless confidentiality protection is in place.
+
+ Clients SHOULD NOT initiate operations which provide or request
+ values of authPassword or make authPasswordMatch assertions unless
+ confidentiality protection is in place.
+
+ Clients SHOULD NOT assume that a successful AuthPasswordMatch,
+ whether by compare or search, is sufficient to gain directory
+ access. The bind operation MUST be used to authenticate to the
+ directory.
+
+5. Security Considerations
+
+ This document describes how authentication information may be stored
+ in a directory. Authentication information MUST be adequately
+ protected as unintended disclosure will allow attackers to gain
+ immediate access to the directory as described by [RFC2829].
+
+ As flaws may be discovered in the hashing algorithm or with a
+ particular implementation of the algorithm or values could be subject
+ to various attacks if exposed, values of AuthPassword SHOULD be
+ protected as if they were clear text passwords. When values are
+ transferred, privacy protections, such as IPSEC or TLS, SHOULD be in
+ place.
+
+ Clients SHOULD use strong authentication mechanisms [RFC2829].
+
+
+
+
+
+Zeilenga Informational [Page 6]
+\f
+RFC 3112 LDAP Authentication Password Schema May 2001
+
+
+ AuthPasswordMatch matching rule allows applications to test the
+ validity of a user password and, hence, may be used to mount an
+ attack. Servers SHOULD take appropriate measures to protect the
+ directory from such attacks.
+
+ Some password schemes may require CPU intensive operations. Servers
+ SHOULD take appropriate measures to protect against Denial of Service
+ attacks.
+
+ AuthPassword does not restrict an authentication identity to a single
+ password. An attacker who gains write access to this attribute may
+ store additional values without disabling the user's true
+ password(s). Use of policy aware clients and servers is RECOMMENDED.
+
+ The level of protection offered against various attacks differ from
+ scheme to scheme. It is RECOMMENDED that servers support scheme
+ selection as a configuration item. This allows for a scheme to be
+ easily disabled if a significant security flaw is discovered.
+
+6. Acknowledgment
+
+ This document borrows from a number of IETF documents and is based
+ upon input from the IETF LDAPext working group.
+
+7. Bibliography
+
+ [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+ April 1992
+
+ [RFC2219] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2234] Crocker, D., Editor, P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC2256] Wahl, A., "A Summary of the X.500(96) User Schema for use
+ with LDAPv3", RFC 2256, December 1997.
+
+ [RFC2307] Howard, L., "An Approach for Using LDAP as a Network
+ Information Service", RFC 2307, March 1998.
+
+
+
+
+Zeilenga Informational [Page 7]
+\f
+RFC 3112 LDAP Authentication Password Schema May 2001
+
+
+ [RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
+ "Authentication Methods for LDAP", RFC 2829, June 2000.
+
+ [RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation",
+ RFC 3062, February 2001.
+
+ [SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
+
+8. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Informational [Page 8]
+\f
+RFC 3112 LDAP Authentication Password Schema May 2001
+
+
+9. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Informational [Page 9]
+\f
projects / openldap / commitdiff