From 6e077505e94046320d756e6e41cefac5430121c3 Mon Sep 17 00:00:00 2001 From: Kurt Zeilenga Date: Thu, 31 May 2001 20:36:30 +0000 Subject: [PATCH] Replace authpasswd I-D with RFC Remove grouping I-D until ready to implement --- .../draft-zeilenga-ldap-authpasswd-xx.txt | 507 ------------------ .../draft-zeilenga-ldap-grouping-xx.txt | 507 ------------------ doc/rfc/rfc3112.txt | 507 ++++++++++++++++++ 3 files changed, 507 insertions(+), 1014 deletions(-) delete mode 100644 doc/drafts/draft-zeilenga-ldap-authpasswd-xx.txt delete mode 100644 doc/drafts/draft-zeilenga-ldap-grouping-xx.txt create mode 100644 doc/rfc/rfc3112.txt diff --git a/doc/drafts/draft-zeilenga-ldap-authpasswd-xx.txt b/doc/drafts/draft-zeilenga-ldap-authpasswd-xx.txt deleted file mode 100644 index 123f9bec35..0000000000 --- a/doc/drafts/draft-zeilenga-ldap-authpasswd-xx.txt +++ /dev/null @@ -1,507 +0,0 @@ - - - - - - -INTERNET-DRAFT Kurt D. Zeilenga -Intended Category: Standard Track OpenLDAP Foundation -Expires: 20 July 2001 20 January 2001 - - - - LDAP Authentication Password Attribute - - - -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 . Please send editorial - comments directly to the author . - - 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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -INTERNET-DRAFT LDAP AuthPassword 20 January 2001 - - -11. Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Zeilenga [Page 9] - diff --git a/doc/drafts/draft-zeilenga-ldap-grouping-xx.txt b/doc/drafts/draft-zeilenga-ldap-grouping-xx.txt deleted file mode 100644 index 8b06d906cc..0000000000 --- a/doc/drafts/draft-zeilenga-ldap-grouping-xx.txt +++ /dev/null @@ -1,507 +0,0 @@ - - - - - - -INTERNET-DRAFT Kurt D. Zeilenga -Intended Category: Standard Track OpenLDAP Foundation -Expires: 4 January 2001 4 July 2000 - - - LDAPv3: Grouping of Related Operations - - - -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 . Please send editorial - comments directly to the author . - - 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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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 - - - or the LDAPext Working Group mailing list: - - - - -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] - diff --git a/doc/rfc/rfc3112.txt b/doc/rfc/rfc3112.txt new file mode 100644 index 0000000000..decdd9ae0b --- /dev/null +++ b/doc/rfc/rfc3112.txt @@ -0,0 +1,507 @@ + + + + + + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + -- 2.39.5