From 30bd8ce3c6143eb7acd6b05d65018f52086a0f67 Mon Sep 17 00:00:00 2001 From: Kurt Zeilenga Date: Thu, 18 Dec 2003 00:36:45 +0000 Subject: [PATCH] Latest --- doc/drafts/draft-ietf-ldapbis-authmeth-xx.txt | 1504 +++++++++-------- 1 file changed, 813 insertions(+), 691 deletions(-) diff --git a/doc/drafts/draft-ietf-ldapbis-authmeth-xx.txt b/doc/drafts/draft-ietf-ldapbis-authmeth-xx.txt index 4b2fff9ce8..e4ed2a4dff 100644 --- a/doc/drafts/draft-ietf-ldapbis-authmeth-xx.txt +++ b/doc/drafts/draft-ietf-ldapbis-authmeth-xx.txt @@ -1,7 +1,7 @@ INTERNET-DRAFT Editor: R. Harrison -draft-ietf-ldapbis-authmeth-08.txt Novell, Inc. -Obsoletes: 2251, 2829, 2830 26 October 2003 +draft-ietf-ldapbis-authmeth-09.txt Novell, Inc. +Obsoletes: 2251, 2829, 2830 5 December 2003 Intended Category: Draft Standard @@ -53,9 +53,9 @@ Abstract mechanisms. -Harrison Expires April 2004 [Page 1] +Harrison Expires June 2004 [Page 1] -Internet-Draft LDAP Authentication Methods 7 October 2003 +Internet-Draft LDAP Authentication Methods 5 December 2003 This document also details establishment of TLS (Transport Layer Security) using the Start TLS operation. @@ -63,9 +63,6 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 This document describes various authentication and authorization states through which a connection to an LDAP server may pass and the actions that trigger these state changes. - - This document also prescribes DIGEST-MD5 as LDAP's mandatory-to- - implement strong authentication mechanism. 1. Introduction @@ -110,17 +107,16 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 LDAP can be protected with the following security mechanisms: - - -Harrison Expires April 2004 [Page 2] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - (1) Client authentication by means of the Secure Authentication and Security Layer (SASL) [SASL] mechanism set, possibly backed by the Transport Layer Security (TLS) [TLS] credentials exchange mechanism, +Harrison Expires June 2004 [Page 2] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + + (2) Client authorization by means of access control based on the requestor's authenticated identity, @@ -155,27 +151,33 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 directory. This means that this data must be updated outside the protocol or only updated in sessions well protected against snooping. It is also desirable to allow authentication methods to - carry authorization identities based on existing--non-LDAP DN--forms - of user identities for backwards compatibility with non-LDAP-based - authentication services. - - The set of security mechanisms provided in LDAP and described in - this document is intended to meet the security needs for a wide - range of deployment scenarios and still provide a high degree of - interoperability among various LDAP implementations and deployments. - Appendix A contains example deployment scenarios that list the - mechanisms that might be used to achieve a reasonable level of - security in various circumstances. + carry identities not represented as LDAP DNs that are familiar to + the user or that are used in other systems. + The set of security mechanisms provided in LDAP and described in + this document is intended to meet the security needs for a wide + range of deployment scenarios and still provide a high degree of + interoperability among various LDAP implementations and + deployments. Appendix A contains example deployment scenarios that + list the mechanisms that might be used to achieve a reasonable + level of security in various circumstances. + +1.1. Relationship to Other Documents + This document is an integral part of the LDAP Technical - Specification [Roadmap]. This document replaces RFC 2829 and - portions of RFC 2830 and RFC 2251. + Specification [Roadmap]. + + This document obsoletes RFC 2829. + + -Harrison Expires April 2004 [Page 3] +Harrison Expires June 2004 [Page 3] -Internet-Draft LDAP Authentication Methods 7 October 2003 - +Internet-Draft LDAP Authentication Methods 5 December 2003 + Sections 2 and 4 of RFC 2830 are obsoleted by [Protocol]. The + remainder of RFC 2830 is obsoleted by this document. + 2. Conventions Used in this Document 2.1. Glossary of Terms @@ -221,18 +223,16 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 authentication information to be exchanged between the client and server to establish a new LDAP association. The new LDAP association is established upon successful completion of the authentication - exchange. - - + exchange. 3.1. Implied Anonymous Bind on LDAP Association Prior to the successful completion of a Bind operation and during any subsequent authentication exchange, the session has an anonymous -Harrison Expires April 2004 [Page 4] +Harrison Expires June 2004 [Page 4] -Internet-Draft LDAP Authentication Methods 7 October 2003 +Internet-Draft LDAP Authentication Methods 5 December 2003 LDAP association. Among other things this implies that the client need not send a Bind Request in the first PDU of the connection. The @@ -250,7 +250,7 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 The simple authentication choice provides two different methods for establishing an anonymous association: anonymous bind and - unauthenticated bind (see section 6.1). + unauthenticated bind (see section 5.1). The simple authentication choice provides one method for establishing a non-anonymous association: simple password bind. @@ -259,7 +259,7 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 LDAP allows authentication via any SASL mechanism [SASL]. As LDAP includes native anonymous and plaintext authentication methods, the - "ANONYMOUS" [ANONYMOUS] and "PLAIN" [PLAIN] SASL mechanisms are + ANONYMOUS [ANONYMOUS] and PLAIN [PLAIN] SASL mechanisms are typically not used with LDAP. Each protocol that utilizes SASL services is required to supply @@ -284,14 +284,14 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 - The optional credentials field of the SaslCredentials sequence may be used to provide an initial client response for mechanisms that are defined to have the client send data first - (see [SASL] sections 5 and 6.1). + (see [SASL] sections 5 and 5.1). In general, a SASL authentication protocol exchange consists of a series of server challenges and client responses, the contents of -Harrison Expires April 2004 [Page 5] +Harrison Expires June 2004 [Page 5] -Internet-Draft LDAP Authentication Methods 7 October 2003 +Internet-Draft LDAP Authentication Methods 5 December 2003 which are specific to and defined by the SASL mechanism. Thus for some SASL authentication mechanisms, it may be necessary for the @@ -308,9 +308,9 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 to transmit each challenge. LDAP clients use the credentials field, an OCTET STRING, in the SaslCredentials sequence of a bind request message to transmit each response. Note that unlike some Internet - application protocols where SASL is used, LDAP is not text-based, - thus no Base64 transformations are performed on these challenge and - response values. + protocols where SASL is used, LDAP is not text-based, thus no Base64 + transformations are performed on these challenge and response + values. Clients sending a bind request with the sasl choice selected SHOULD NOT send a value in the name field. Servers receiving a bind request @@ -348,11 +348,11 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 BindResponse of the bind operation that caused the new layer to take effect). -Harrison Expires April 2004 [Page 6] +Harrison Expires June 2004 [Page 6] -Internet-Draft LDAP Authentication Methods 7 October 2003 +Internet-Draft LDAP Authentication Methods 5 December 2003 - + 3.3.4. Determination of supported SASL mechanisms An LDAP client may determine the SASL mechanisms a server supports @@ -363,57 +363,85 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 3.3.5. Rules for using SASL security layers If a SASL security layer is negotiated, the client SHOULD discard - information about the server fetched prior to the initiation of the - SASL negotiation and not obtained through secure mechanisms. - - If the client is configured to support multiple SASL mechanisms, it - SHOULD fetch the supportedSASLmechanisms list both before and after - the SASL security layer is negotiated. This allows the client to - detect active attacks that remove supported SASL mechanisms from the - supportedSASLMechanisms list and allows the client to ensure that it - is using the best mechanism supported by both client and server. (In - particular, this allows for environments where the - supportedSASLMechanisms list is provided to the client through a - different trusted source, e.g. as part of a digitally signed - object.) + information about the server it obtained prior to the initiation of + the SASL negotiation and not obtained through secure mechanisms. If a lower level security layer (such as TLS) is negotiated, any SASL security services SHALL be layered on top of such security - layers regardless of the order of their negotiation. + layers regardless of the order of their negotiation. In all other + respects, SASL security services and other security layers act + independently, e.g. if both TLS and SASL security service are in + effect removing the SASL security service does not affect the + continuing service of TLS and vice versa. + + Because SASL mechanisms provide critical security functions, clients + and servers should allow the user to specify what mechanisms are + acceptable and allow only those mechanisms to be used. 3.3.6. Use of EXTERNAL SASL Mechanism - A client can use the "EXTERNAL" SASL mechanism to request the LDAP - server to make use of security credentials exchanged by a lower - layer. If authentication credentials have not been established at a - lower level (such as by TLS authentication or IP-level security - [RFC2401]), the SASL EXTERNAL bind MUST fail with a resultCode of - inappropriateAuthentication. Any client authentication and - authorization state of the LDAP association is lost, so the LDAP - association is in an anonymous state after the failure (see - [Protocol] section 4.2.1). + A client can use the EXTERNAL SASL [SASL] mechanism to request the + LDAP server to make use of security credentials exchanged by a lower + security layer (such as by TLS authentication or IP-level security + [RFC2401]). + + If the client's authentication credentials have not been established + at a lower security layer, the SASL EXTERNAL bind MUST fail with a + resultCode of inappropriateAuthentication. Any client + authentication and authorization state of the LDAP association is + lost, so the LDAP association is in an anonymous state after the + failure (see [Protocol] section 4.2.1). In such a situation, the + state of any established security layer is unaffected. + + A client may either implicitly request that its LDAP authorization + identity be derived from a lower layer or it may explicitly provide + an authorization identity and assert that it be used in combination + with its authenticated TLS credentials. The former is known as an + implicit assertion, and the latter as an explicit assertion. + +3.3.6.1. Implicit Assertion + + An implicit authorization identity assertion is performed by + invoking a Bind request of the SASL form using the EXTERNAL + mechanism name that SHALL NOT include the optional credentials octet + string (found within the SaslCredentials sequence in the Bind + Request). The server will derive the client's authorization identity -3.4. SASL Authorization Identity +Harrison Expires June 2004 [Page 7] + +Internet-Draft LDAP Authentication Methods 5 December 2003 - When the "EXTERNAL" SASL mechanism is being negotiated, if the + from the authentication identity supplied by the security layer + (e.g., a public key certificate used during TLS establishment) + according to local policy. The underlying mechanics of how this is + accomplished are implementation specific. + +3.3.6.2. Explicit Assertion + + An explicit authorization identity assertion is performed by + invoking a Bind request of the SASL form using the EXTERNAL + mechanism name that SHALL include the credentials octet string. This + string MUST be constructed as documented in section 3.4.1. + + The server MUST that the client's authentication identity as + supplied in its TLS credentials is permitted to be mapped to the + asserted authorization identity. The server MUST reject the Bind + operation with an invalidCredentials resultCode in the Bind response + if the client is not so authorized. + +3.3.6.3. SASL Authorization Identity + + When the EXTERNAL SASL mechanism is being negotiated, if the SaslCredentials credentials field is present, it contains an authorization identity. Other mechanisms define the location of the authorization identity in the credentials field. In either case, the authorization identity is represented in the authzId form described below. -3.4.1. Authorization Identity Syntax +3.3.6.4 Authorization Identity Syntax The authorization identity is a string of [UTF-8] encoded [Unicode] - characters corresponding to the following ABNF grammar [RFC2234]: - -Harrison Expires April 2004 [Page 7] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - - - ; Specific predefined authorization (authz) id schemes are - ; defined below -- new schemes may be defined in the future. + characters corresponding to the following [ABNF] grammar: authzId = dnAuthzId / uAuthzId @@ -421,43 +449,50 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 UCOLON = %x75 %x3a ; "u:" ; distinguished-name-based authz id. - dnAuthzId = DNCOLON dn - dn = utf8string ; with syntax defined in [LDAPDN] section 3. - + dnAuthzId = DNCOLON distinguishedName ; unspecified authorization id, UTF-8 encoded. uAuthzId = UCOLON userid - userid = utf8string ; syntax unspecified - - The dnAuthzId choice allows client applications to assert - authorization identities in the form of a distinguished name to be - matched in accordance with the distinguishedName matching rule - [Syntaxes]. The decision to allow or disallow an authentication - identity to have access to the requested authorization identity is a - matter of local policy ([SASL] section 4.2). For this reason there - is no requirement that the asserted dn be that of an entry in - directory. - - The uAuthzId choice allows for compatibility with client - applications that wish to assert an authorization identity to a - local directory but do not have that identity in distinguished name - form. The value contained within a uAuthzId MUST be prepared using - SASLprep before being compared octet-wise. The format of utf8string - is defined as only a sequence of of [UTF-8] encoded [Unicode] - characters, and further interpretation is subject to prior agreement - between the client and server. + userid = *UTF8 ; syntax unspecified + + where the production is defined in section 3 of + [LDAPDN] and production is defined in section 1.3 of + [Models]. + + In order to support additional specific authorization identity + forms, future updates to this specification may add new choices + supporting other forms may be added to the authzId production. + + The dnAuthzId choice allows clients to assert authorization + identities in the form of a distinguished name to be matched in + +Harrison Expires June 2004 [Page 8] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + + accordance with the distinguishedName matching rule [Syntaxes]. The + decision to allow or disallow an authentication identity to have + access to the requested authorization identity is a matter of local + policy ([SASL] section 4.2). For this reason there is no requirement + that the asserted dn be that of an entry in directory. + + The uAuthzId choice allows for compatibility with clients that wish + to assert an authorization identity to a local directory but do not + have that identity in distinguished name form. The value contained + within a uAuthzId MUST be prepared using [SASLPrep] before being + compared octet-wise. The format of utf8string is defined as only a + sequence of [UTF-8] encoded [Unicode] characters, and further + interpretation is subject to prior agreement between the client and + server. For example, the userid could identify a user of a specific directory service or be a login name or the local-part of an RFC 822 email address. A uAuthzId SHOULD NOT be assumed to be globally unique. - Additional authorization identity schemes may be defined in future - versions of this document. - 4. Start TLS Operation - The Start Transport Layer Security (StartTLS) operation defined in + The Start Transport Layer Security (Start TLS) operation defined in section 4.13 of [Protocol] provides the ability to establish [TLS] on an LDAP association. @@ -465,11 +500,6 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 This section describes the overall procedures clients and servers must follow for TLS establishment. These procedures take into - -Harrison Expires April 2004 [Page 8] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - consideration various aspects of the overall security of the LDAP association including discovery of resultant security level and assertion of the client's authorization identity. @@ -478,7 +508,7 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 of establishing TLS on an LDAP association are described in detail in section 4.2. -4.1.1. Requesting to Start TLS on an LDAP Connection +4.1.1. Start TLS Request The client MAY send the Start TLS extended request at any time after establishing an LDAP connection, except: @@ -494,10 +524,14 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 implementers should note that it is possible to receive a resultCode of success for a Start TLS operation that is sent on a connection with outstanding LDAP operations and the server has sufficient time + +Harrison Expires June 2004 [Page 9] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + to process them prior to its receiving the Start TLS request. - Implementors should ensure that they do not inadvertently depend - upon this race condition for proper functioning of their - applications. + Implementors of clients should ensure that they do not inadvertently + depend upon this race condition. In particular, there is no requirement that the client have or have not already performed a Bind operation before sending a Start TLS @@ -511,12 +545,12 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 MUST reject that request by sending a resultCode of confidentialityRequired or strongAuthRequired. -4.1.2. Starting TLS +4.1.2. Start TLS Response The server will return an extended response with the resultCode of success if it is willing and able to negotiate TLS. It will return - other resultCodes (documented in [Protocol] section 4.13.2.2) if it - is unable to do so. + other resultCode values (documented in [Protocol] section 4.13.2.2) + if it is unwilling or unable to do so. In the successful case, the client (which has ceased to transfer LDAP requests on the connection) MUST either begin a TLS negotiation @@ -524,11 +558,6 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 Protocol directly over the underlying transport connection to the server to initiate [TLS] negotiation. - -Harrison Expires April 2004 [Page 9] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - 4.1.3. TLS Version Negotiation Negotiating the version of TLS or SSL to be used is a part of the @@ -537,7 +566,7 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 4.1.4. Discovery of Resultant Security Level After a TLS connection is established on an LDAP association, both - parties MUST individually decide whether or not to continue based on + parties must individually decide whether or not to continue based on the security level achieved. Ascertaining the TLS connection's security level is implementation dependent and accomplished by communicating with one's respective local TLS implementation. @@ -552,6 +581,13 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 4.1.5. Server Identity Check + + + +Harrison Expires June 2004 [Page 10] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + The client MUST check its understanding of the server's hostname against the server's identity as presented in the server's Certificate message in order to prevent man-in-the-middle attacks. @@ -567,7 +603,7 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 - If a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity. - + - Matching is case-insensitive. - The "*" wildcard character is allowed. If present, it applies @@ -583,11 +619,6 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 certificate per the above check, user-oriented clients SHOULD either notify the user (clients may give the user the opportunity to continue with the connection in any case) or terminate the - -Harrison Expires April 2004 [Page 10] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - connection and indicate that the server's identity is suspect. Automated clients SHOULD close the connection, returning and/or logging an error indicating that the server's identity is suspect. @@ -601,17 +632,23 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 4.1.6. Refresh of Server Capabilities Information Upon TLS session establishment, the client SHOULD discard or refresh - all information about the server fetched prior to the initiation of - the TLS negotiation and not obtained through secure mechanisms. This - protects against active-intermediary attacks that may have altered - any server capabilities information retrieved prior to TLS + all information about the server it obtained prior to the initiation + of the TLS negotiation and not obtained through secure mechanisms. + This protects against active-intermediary attacks that may have + altered any server capabilities information retrieved prior to TLS establishment. The server may advertise different capabilities after TLS establishment. In particular, the value of supportedSASLMechanisms may be different after TLS has been negotiated (specifically, the - EXTERNAL and [PLAIN] mechanisms are likely to be listed only after a - TLS negotiation has been performed). + + +Harrison Expires June 2004 [Page 11] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + + EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed only + after a TLS negotiation has been performed). 4.2. Effects of TLS on a Client's Authorization Identity @@ -625,331 +662,92 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 Authorization identities and related concepts are described in Appendix B. -4.2.1. Default Effects - - Upon establishment of the TLS session onto the LDAP association, any - previously established authentication and authorization identities - MUST remain in force, including anonymous state. This holds even in - the case where the server requests client authentication via TLS -- - e.g. requests the client to supply its certificate during TLS - negotiation. +4.2.1. TLS Connection Establishment Effects + The decision to keep or invalidate the established authentication + and authorization identities in place after TLS is negotiated is a + matter of local server policy. If a server chooses to invalidate + established authentication and authorization identities after TLS is + negotiated, it MUST reply to subsequent valid operation requests + until the next TLS closure or successful bind request with a + resultCode of strongAuthRequired to indicate that the client needs + to bind to reestablish its authentication. If the client attempts to + bind using a method the server is unwilling to support, it responds + to the with a resultCode of authMethodNotSupported (per [Protocol]) + to indicate that a different authentication method should be used. + 4.2.2. Client Assertion of Authorization Identity - The client MAY, upon receipt of a Start TLS response indicating - success, assert that a specific authorization identity be utilized - in determining the client's authorization status. The client + After successfully establishing a TLS session, a client may request + that its credentials exchanged during the TLS establishment be + utilized to determine the client's authorization status. The client accomplishes this via an LDAP Bind request specifying a SASL - mechanism of "EXTERNAL" [SASL]. A client may either implicitly - request that its LDAP authorization identity be derived from its - -Harrison Expires April 2004 [Page 11] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - - authenticated TLS credentials or it may explicitly provide an - authorization identity and assert that it be used in combination - with its authenticated TLS credentials. The former is known as an - implicit assertion, and the latter as an explicit assertion. - -4.2.2.1. Implicit Assertion - - An implicit authorization identity assertion is accomplished after - TLS establishment by invoking a Bind request of the SASL form using - the "EXTERNAL" mechanism name [SASL] [Protocol] that SHALL NOT - include the optional credentials octet string (found within the - SaslCredentials sequence in the Bind Request). The server will - derive the client's authorization identity from the authentication - identity supplied in the client's TLS credentials (typically a - public key certificate) according to local policy. The underlying - mechanics of how this is accomplished are implementation specific. - -4.2.2.2. Explicit Assertion - - An explicit authorization identity assertion is accomplished after - TLS establishment by invoking a Bind request of the SASL form using - the "EXTERNAL" mechanism name [SASL] [Protocol] that SHALL include - the credentials octet string. This string MUST be constructed as - documented in section 3.4.1. - - The server MUST verify that the client's authentication identity as - supplied in its TLS credentials is permitted to be mapped to the - asserted authorization identity. The server MUST reject the Bind - operation with an invalidCredentials resultCode in the Bind response - if the client is not so authorized. - -4.2.2.3. Error Conditions - - Additionally, with either form of assertion, if a TLS session has - not been established between the client and server prior to making - the SASL EXTERNAL Bind request and there is no other external source - of authentication credentials (e.g. IP-level security [RFC2401]), or - if during the process of establishing the TLS session, the server - did not request the client's authentication credentials, the SASL - EXTERNAL bind MUST fail with a resultCode of - inappropriateAuthentication. - - After the above Bind operation failures, any client authentication - and authorization state of the LDAP association is lost (see - [Protocol] section 4.2.1), so the LDAP association is in an - anonymous state after the failure. The TLS session state is - unaffected, though a server MAY end the TLS session, via a TLS - close_notify message, based on the Bind failure (as it MAY at any - time). + mechanism of EXTERNAL [SASL]. See section 3.3.6 for additional + details. 4.2.3. TLS Connection Closure Effects - Closure of the TLS session MUST cause the LDAP association to move - to an anonymous authentication and authorization state regardless of - -Harrison Expires April 2004 [Page 12] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - - the state established over TLS and regardless of the authentication - and authorization state prior to TLS session establishment. - -5. LDAP Association State Transition Tables - - To comprehensively diagram the various authentication and TLS states - through which an LDAP association may pass, this section provides a - state transition table to represent a state diagram for the various - states through which an LDAP association may pass during the course - of its existence and the actions that cause these changes in state. - -5.1. LDAP Association States - - The following table lists the valid LDAP association states and - provides a description of each state. The ID for each state is used - in the state transition table in section 5.4. - - ID State Description - -- -------------------------------------------------------------- - S1 Anonymous - no Authentication ID is associated with the LDAP connection - no Authorization ID is in force - No security layer is in effect. - No TLS credentials have been provided - TLS: no Creds, OFF] - S2 no Auth ID - no AuthZ ID - [TLS: no Creds, ON] - S3 no Auth ID - no AuthZ ID - [TLS: Creds Auth ID "I", ON] - S4 Auth ID = Xn - AuthZ ID= Y - [TLS: no Creds, OFF] - S5 Auth ID = Xn - AuthZ ID= Yn - [TLS: no Creds, ON] - S6 Auth ID = Xn - AuthZ ID= Yn - [TLS: Creds Auth ID "I", ON] - S7 Auth ID = I - AuthZ ID= J - [TLS: Creds Auth ID "I", ON] - S8 Auth ID = I - AuthZ ID= K - [TLS: Creds Auth ID "I", ON] - -5.2. Actions that Affect LDAP Association State - - The following table lists the actions that can affect the state of - an LDAP association. The ID for each action is used in the state - transition table in section 5.4. - - -Harrison Expires April 2004 [Page 13] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - - - ID Action - -- ------------------------------------------------ - A1 Client binds anonymously - A2 Inappropriate authentication: client attempts an anonymous - bind or a bind without supplying credentials to a server that - requires the client to provide some form of credentials. - A3 Client Start TLS request - Server: client auth NOT required - A4 Client: Start TLS request - Server: client creds requested - Client: [TLS creds: Auth ID "I"] - A5 Client or Server: send TLS closure alert ([Protocol] section - X) - A6 Client: Bind w/simple password or SASL mechanism (e.g. DIGEST- - MD5 password, Kerberos, etc., except EXTERNAL [Auth ID "X" - maps to AuthZ ID "Y"] - A7 Client Binds SASL EXTERNAL with credentials: AuthZ ID "J" - [Explicit Assertion (section 4.2.1.2.2)] - A8 Client Bind SASL EXTERNAL without credentials [Implicit - Assertion (section 4.2.1.2.1)] - A9 Client abandons a bind operation or bind operation fails - -5.3. Decisions Used in Making LDAP Association State Changes - - Certain changes in the state of an LDAP association are only allowed - if the server can affirmatively answer a question. These questions - are applied as part of the criteria for allowing or disallowing a - state change in the state transition table in section 5.4. + The decision to keep or invalidate the established authentication + and authorization identities in place after TLS closure is a matter + of local server policy. If a server chooses to invalidate + established authentication and authorization identities after TLS is + negotiated, it MUST reply to subsequent valid operation requests + until the next TLS closure or successful bind request with a + resultCode of strongAuthRequired to indicate that the client needs + to bind to reestablish its authentication. If the client attempts to + bind using a method the server is unwilling to support, it responds + to the with a resultCode of authMethodNotSupported (per [Protocol]) + to indicate that a different authentication method should be used. - ID Decision Question - -- -------------------------------------------------------------- - D1 Can TLS Credentials Auth ID "I" be mapped to AuthZ ID "J"? - D2 Can a valid AuthZ ID "K" be derived from TLS Credentials Auth - ID "I"? +5. Anonymous Authentication -5.4. LDAP Association State Transition Table - - The LDAP Association table below lists the valid states for an LDAP - association and the actions that could affect them. For any given - row in the table, the Current State column gives the state of an - LDAP association, the Action column gives an action that could - affect the state of an LDAP assocation, and the Next State column - gives the resulting state of an LDAP association after the action - occurs. - - The initial state for the state machine described in this table is - S1. - Current Next - State Action State Comment - ------- ------------- ----- ----------------------------------- - S1 A1 S1 - -Harrison Expires April 2004 [Page 14] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - - S1 A2 S1 Error: Inappropriate authentication - S1 A3 S2 - S1 A4 S3 - S1 A6 S4 - S1 A7 ? identity could be provided by - another underlying mechanism such - as IPSec. - S1 A8 ? identity could be provided by - another underlying mechanism such - as IPSec. - S2 A1 S2 - S2 A2 S2 Error: Inappropriate authentication - S2 A5 S1 - S2 A6 S5 - S2 A7 ? identity could be provided by - another underlying mechanism such - as IPSec. - S2 A8 ? identity could be provided by - another underlying mechanism such - as IPSec. - S3 A1 S3 - S3 A2 S3 Error: Inappropriate authentication - S3 A5 S1 - S3 A6 S6 - S3 A7 and D1=NO S3 Error: InvalidCredentials - S3 A7 and D1=YES S7 - S3 A8 and D2=NO S3 Error: InvalidCredentials - S3 A8 and D2=YES S8 - S4 A1 S1 - S4 A2 S1 Error: Inappropriate Authentication - S4 A3 S5 - S4 A4 S6 - S4 A5 S1 - S4 A6 S4 - S4 A7 ? identity could be provided by - another underlying mechanism such - as IPSec. - S4 A8 ? identity could be provided by - another underlying mechanism such - as IPSec. - S5 A1 S2 - S5 A2 S2 Error: Inappropriate Authentication - S5 A5 S1 - S5 A6 S5 - S5 A7 ? identity could be provided by - another underlying mechanism such - as IPSec. - S5 A8 ? identity could be provided by - another underlying mechanism such - as IPSec. - S6 A1 S3 - S6 A2 S2 Error: Inappropriate Authentication - -Harrison Expires April 2004 [Page 15] +Harrison Expires June 2004 [Page 12] -Internet-Draft LDAP Authentication Methods 7 October 2003 - - S6 A5 S1 - S6 A6 S6 - S6 A7 and D1=NO S6 Error: InvalidCredentials - S6 A7 and D1=YES S7 - S6 A8 and D2=NO S3 Error: InvalidCredentials - S6 A8 and D2=YES S8 - S7 A1 S3 - S7 A2 S2 Error: Inappropriate Authentication - S7 A5 S1 - S7 A6 S6 - S7 A7 S7 - S7 A8 and D2=NO S3 Error: InvalidCredentials - S7 A8 and D2=YES S8 - S8 A1 S3 - S8 A2 S2 Error: Inappropriate Authentication - S8 A5 S1 - S8 A6 S6 - S8 A7 and D1=NO S6 Error: InvalidCredentials - S8 A7 and D1=YES S7 - S8 A8 S8 - Any A9 S1 See [Protocol] section 4.2.1. - - -6. Anonymous Authentication +Internet-Draft LDAP Authentication Methods 5 December 2003 Directory operations that modify entries or access protected attributes or entries generally require client authentication. Clients that do not intend to perform any of these operations - typically use anonymous authentication. Servers SHOULD NOT allow - clients with anonymous authentication to modify directory entries or - access sensitive information in directory entries. + typically use anonymous authentication. LDAP implementations MUST support anonymous authentication, as - defined in section 6.1. + defined in section 5.1. LDAP implementations MAY support anonymous authentication with TLS, - as defined in section 6.2. + as defined in section 5.2. - While there MAY be access control restrictions to prevent access to + While there may be access control restrictions to prevent access to directory entries, an LDAP server SHOULD allow an anonymously-bound client to retrieve the supportedSASLMechanisms attribute of the root DSE. - An LDAP server MAY use other information about the client provided + An LDAP server may use other information about the client provided by the lower layers or external means to grant or deny access even to anonymously authenticated clients. -6.1. Anonymous Authentication Procedure +5.1. Anonymous Authentication Procedure Prior to successfully completing a Bind operation, the LDAP association is anonymous. See section 3.1. - - -Harrison Expires April 2004 [Page 16] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - An LDAP client may also explicitly establish an anonymous - association. A client that wishes to do so MUST choose the simple - authentication option in the Bind Request and set the password to be - of zero length. (This is often done by LDAPv2 clients.) Typically - the name is also of zero length. A bind request where both the name - and password are of zero length is said to be an anonymous bind. A - bind request where the name, a DN, is of non-zero length, and the - password is of zero length is said to be an unauthenticated bind. - Both variations produce an anonymous association. - -6.2. Anonymous Authentication and TLS - - An LDAP client MAY use the Start TLS operation (section 5) to + association by sending a Bind Request with the simple authentication + option and a password of zero length. A bind request where both the + name and password are of zero length is said to be an anonymous + bind. A bind request where the name, a DN, is of non-zero length, + and the password is of zero length is said to be an unauthenticated + bind. Both variations produce an anonymous association. + + Unauthenticated binds can have significant security issues (see + section 10). Servers SHOULD by default reject unauthenticated bind + requests with a resultCode of invalidCredentials, and clients may + need to actively detect situations where they would make an + unauthenticated bind request. + +5.2. Anonymous Authentication and TLS + + An LDAP client may use the Start TLS operation (section 5) to negotiate the use of [TLS] security. If the client has not bound beforehand, then until the client uses the EXTERNAL SASL mechanism to negotiate the recognition of the client's certificate, the client @@ -962,13 +760,44 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 whether to successfully complete TLS negotiation if the client did not present a certificate which could be validated. -7. Password-based Authentication + +Harrison Expires June 2004 [Page 13] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + +6. Password-based Authentication This section discusses various options for performing password-based authentication to LDAP compliant servers and the environments suitable for their use. + + The transmission of passwords in the clear--typically for + authentication or modification--poses a significant security risk. + This risk can be avoided by using SASL bind [SASL] mechanisms that + do not transmit passwords in the clear and by negotiating transport + or session layer confidentiality services before transmitting + password values. + + To mitigate the security risks associated with the use of passwords, + a server implementation MUST implement a configuration that at the + time of authentication or password modification, requires: + + 1) A Start TLS encryption layer has been successfully negotiated. + + OR + + 2) Some other confidentiality mechanism that protects the password + value from snooping has been provided. + + OR + + 3) The server returns a resultCode of confidentialityRequired for + the operation (i.e. simple bind with password value, SASL bind + transmitting a password value in the clear, add or modify + including a userPassword value, etc.), even if the password + value is correct. -7.1. Simple Authentication +6.1. Simple Authentication The LDAP "simple" authentication choice is not suitable for authentication in environments where there is no network or @@ -980,22 +809,25 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 connection is protected using TLS or other data confidentiality and data integrity protection. -7.2. Digest Authentication +6.2. Digest Authentication LDAP servers that implement any authentication method or mechanism (other than simple anonymous bind) MUST implement the SASL - DIGEST-MD5 mechanism [DigestAuth]. + DIGEST-MD5 mechanism [DIGEST-MD5]. This provides client + authentication with protection against passive eavesdropping + attacks, but does not provide protection against active intermediary + attacks. DIGEST-MD5 also provides data integrity and data + confidentiality capabilities. - Support for subsequent authentication is OPTIONAL in clients and - servers. - - - -Harrison Expires April 2004 [Page 17] +Harrison Expires June 2004 [Page 14] -Internet-Draft LDAP Authentication Methods 7 October 2003 +Internet-Draft LDAP Authentication Methods 5 December 2003 + + Support for subsequent authentication is OPTIONAL in clients and + servers. + Implementors must take care to ensure that they maintain the semantics of the DIGEST-MD5 specification even when handling data that has different semantics in the LDAP protocol. @@ -1004,18 +836,17 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 syntactically simple strings and semsantically simple realm and username values. These values are not LDAP DNs, and there is no requirement that they be represented or treated as such. Username - and realm values that look like LDAP DNs in form, e.g. "cn=bob, - o=Ace Industry ", are syntactically allowed, however DIGEST-MD5 + and realm values that look like LDAP DNs in form, e.g. , are syntactically allowed, however DIGEST-MD5 treats them as simple strings for comparison purposes. To illustrate - further, the two DNs "cn=bob, o=Ace Industry" (space between RDNs) - and "cn=bob,o=Ace Industry" (no space between RDNs) would be - equivalent when being compared semantically as LDAP DNs, however - they are not equivalent if they were used to represent username - values in DIGEST-MD5 because simple octet-wise comparision semantics - are used by DIGEST-MD5. - + further, the two DNs (upper case "B") and + (lower case "b") are equivalent when + being compared semantically as LDAP DNs because the cn attribute is + defined to be case insensitive, however the two values are not + equivalent if they represent username values in DIGEST-MD5 because + [SASLPrep] semantics are used by DIGEST-MD5. -7.3. "simple" authentication choice under TLS encryption +6.3. simple authentication choice under TLS encryption Following the negotiation of an appropriate TLS ciphersuite providing connection confidentiality, a client MAY authenticate to a @@ -1038,24 +869,24 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 2. Following the successful completion of TLS negotiation, the client MUST send an LDAP bind request with the version number - of 3, the name field containing a DN, and the "simple" + of 3, the name field containing a DN, and the simple authentication choice, containing a password. -7.3.1. "simple" Authentication Choice +6.3.1. simple Authentication Choice DSAs that map the DN sent in the bind request to a directory entry with an associated set of one or more passwords will compare the presented password to the set of passwords associated with that entry. If the presented password matches any member of that set, - then the server will respond with a success resultCode, otherwise - the server will respond with an invalidCredentials resultCode. - -Harrison Expires April 2004 [Page 18] +Harrison Expires June 2004 [Page 15] -Internet-Draft LDAP Authentication Methods 7 October 2003 +Internet-Draft LDAP Authentication Methods 5 December 2003 -7.4. Other authentication choices with TLS + then the server will respond with a success resultCode, otherwise + the server will respond with an invalidCredentials resultCode. + +6.4. Other authentication choices with TLS It is also possible, following the negotiation of TLS, to perform a SASL authentication that does not involve the exchange of plaintext @@ -1063,12 +894,12 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 negotiate a ciphersuite that provides confidentiality if the only service required is data integrity. -8. Certificate-based authentication +7. Certificate-based authentication LDAP server implementations SHOULD support authentication via a - client certificate in TLS, as defined in section 8.1. + client certificate in TLS, as defined in section 7.1. -8.1. Certificate-based authentication with TLS +7.1. Certificate-based authentication with TLS A user who has a public/private key pair in which the public key has been signed by a Certification Authority may use this key pair to @@ -1105,15 +936,142 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 the client's certificate chain are invalid or revoked. There are several procedures by which the server can perform these checks. + + +Harrison Expires June 2004 [Page 16] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + Following the successful completion of TLS negotiation, the client - will send an LDAP bind request with the SASL "EXTERNAL" mechanism. + will send an LDAP bind request with the SASL EXTERNAL mechanism. -9. TLS Ciphersuites +8. LDAP Association State Transition Tables + + To comprehensively diagram the various authentication and TLS states + through hich an LDAP association may pass, this section provides a + state transition table to represent a state diagram for the various + states through which an LDAP association may pass during the course + of its existence and the actions that cause these changes in state. + +8.1. LDAP Association States + + The following table lists the valid LDAP association states and + provides a description of each state. The ID for each state is used + in the state transition table in section 8.4. -Harrison Expires April 2004 [Page 19] + ID State Description + -- -------------------------------------------------------------- + S1 Anonymous + no Authentication ID is associated with the LDAP connection + no Authorization ID is in force + S2 Authenticated + Authentication ID = I + Authorization ID = X + S3 Authenticated SASL EXTERNAL, implicit authorization ID + Authentication ID = J + Authorization ID = Y + S4 Authenticated SASL EXTERNAL, explicit authorization ID + Authentication ID = J + Authorization ID = Z + +8.2. Actions that Affect LDAP Association State + + The following table lists the actions that can affect the + authentication and authorization state of an LDAP association. The + ID for each action is used in the state transition table in section + 8.4. + + ID Action + -- -------------------------------------------------------------- + A1 Client bind request fails + A2 Client successfully performs anonymous simple bind + A3 Client successfully performs unauthenticated simple bind + A4 Client successfully performs simple bind with name and + password OR SASL bind with any mechanism except EXTERNAL using + an authentication ID = I that maps to authorization ID X + A5 Client Binds SASL EXTERNAL with implicit assertion of + authorization ID (section 3.3.6.1)]. The current + authentication ID maps to authorization ID = Y. + A6 Client Binds SASL EXTERNAL with explicit assertion of + authorization ID = Z (section 3.3.6.2)] + + +Harrison Expires June 2004 [Page 17] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + + A7 Client abandons a bind operation, and server processes the + abandon + A8 Client abandons a bind operation, and server does not process + the abandon + A9 Client Start TLS request fails + A10 Client Start TLS request succeeds + A11 Client or Server: graceful TLS closure ([Protocol] section + 4.13.3.1.) + +8.3. Decisions Used in Making LDAP Association State Changes + + Certain changes in the authentication and authorization state of an + LDAP association are only allowed if the server can affirmatively + answer a question. These questions are applied as part of the + criteria for allowing or disallowing a state transition in the state + transition table in section 8.4. + + ID Decision Question + -- -------------------------------------------------------------- + D1 Are lower-layer credentials available? + D2 Can lower-layer credentials for Auth ID "K" be mapped asserted + AuthZID "L"? + +8.4. LDAP Association State Transition Table + + The LDAP Association table below lists the valid authentication and + authorization states for an LDAP association and the actions that + could affect them. For any given row in the table, the Current State + column gives the state of an LDAP association, the Action column + gives an action that could affect the state of an LDAP assocation, + and the Next State column gives the resulting state of an LDAP + association after the action occurs. + + S1, the initial state for the state machine described in this table, + is the authentication state when an LDAP connection is initially + established. + + Current Next + State Action State Comment + ------- ------- ----- --------------------------------------- + Any A1 S1 [Protocol] section 4.2.1 + Any A2 S1 Section 6 + Any A3 S1 Section 6 + Any A4 S2 Sections 6.1, 6.2 + Any A5, S1 Failed bind, section 3.3.6 + D1=no + Any A5, S3 + D1=yes + Any A6, S1 failed bind, section 3.3.6 + D1=no + Any A6, S1 failed bind, section 3.3.6.2 + D1=yes, + D2=no + +Harrison Expires June 2004 [Page 18] -Internet-Draft LDAP Authentication Methods 7 October 2003 +Internet-Draft LDAP Authentication Methods 5 December 2003 + + Any A6, S4 + D1=yes, + D2=yes + Any A7 S1 [Protocol] section 4.2.1. Clients + cannot detect this state. + Any A8 no [Protocol] section 4.2.1. Clients + change cannot detect this state. + Any A9 no [Protocol] section 4.13.2.2 + change + Any A10 no Section 4.2.1 + change + Any A11 S1 Section 4.2.3 +9. TLS Ciphersuites A client or server that supports TLS MUST support TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and MAY support other ciphersuites @@ -1152,6 +1110,12 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 but is hoped that it will serve as a useful starting point for implementers. + + +Harrison Expires June 2004 [Page 19] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + The following ciphersuites defined in [TLS] MUST NOT be used for confidentiality protection of passwords or data: @@ -1168,11 +1132,6 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA - -Harrison Expires April 2004 [Page 20] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA @@ -1199,43 +1158,42 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 Servers are encouraged to prevent modifications by anonymous users. - Servers may also wish to minimize denial of service attacks by - timing out idle connections, and returning the unwillingToPerform - resultCode rather than performing computationally expensive - operations requested by unauthorized clients. - - The use of cleartext passwords is strongly discouraged over open - networks when the underlying transport service cannot guarantee - confidentiality. - - Operational experience shows that clients can misuse unauthenticated - access (simple bind with name but no password). For example, a - client program might authenticate a user via LDAP and then grant - access to information not stored in the directory on the basis of - completing a successful bind. Some implementations will return a - success response to a simple bind that consists of a user name and - an empty password thus leaving the impression that the client has - successfully authenticated the identity represented by the user - name, when in reality, the directory server has simply performed an - anonymous bind. For this reason, servers SHOULD by default reject - authentication requests that have a DN with an empty password with - an error of invalidCredentials. + Servers can minimize denial of service attacks by timing out idle + connections, and returning the unwillingToPerform resultCode rather + than performing computationally expensive operations requested by + unauthorized clients. + + The use of cleartext passwords and other unprotected authentication + credentials is strongly discouraged over open networks when the + underlying transport service cannot guarantee confidentiality. + + Operational experience shows that clients can (and frequently do) + misuse unauthenticated bind (see section 5.1). For example, a + client program might make a decision to grant access to non- + +Harrison Expires June 2004 [Page 20] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + + directory information on the basis of completing a successful bind + operation. Some LDAP server implementations will return a success + response to an unauthenticated bind thus leaving the client with the + impression that the server has successfully authenticated the + identity represented by the user name, when in effect, an anonymous + LDAP association has been created. Clients that use the results from + a simple bind operation to make authorization decisions should + actively detect unauthenticated bind requests (via the empty + password value) and react appropriately. Access control SHOULD always be applied when reading sensitive information or updating directory information. A connection on which the client has not performed the Start TLS operation or negotiated a suitable SASL mechanism for connection - - -Harrison Expires April 2004 [Page 21] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - integrity and encryption services is subject to man-in-the-middle attacks to view and modify information in transit. -10.1. Start TLS Security Considerations +10.1. Start TLS Security Considerations The goals of using the TLS protocol with LDAP are to ensure connection confidentiality and integrity, and to optionally provide @@ -1271,6 +1229,11 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 Client and server implementors SHOULD take measures to ensure proper protection of credentials and other confidential data where such measures are not otherwise provided by the TLS implementation. + +Harrison Expires June 2004 [Page 21] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + Server implementors SHOULD allow for server administrators to elect whether and when connection confidentiality and/or integrity is @@ -1286,22 +1249,15 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 Please update the GSSAPI service name registry to point to [Roadmap] and this document. - -Harrison Expires April 2004 [Page 22] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - [To be completed] -Contributors +Acknowledgements This document combines information originally contained in RFC 2829 and RFC 2830. The editor acknowledges the work of Harald Tveit Alvestrand, Jeff Hodges, Tim Howes, Steve Kille, RL "Bob" Morgan , and Mark Wahl, each of whom authored one or more of these documents. - -Acknowledgements This document is based upon input of the IETF LDAP Revision working group. The contributions and suggestions made by its members in @@ -1313,10 +1269,10 @@ Normative References [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. - [DigestAuth] Leach, P. C. Newman, and A. Melnikov, "Using Digest + [DIGEST-MD5] Leach, P. C. Newman, and A. Melnikov, "Using Digest Authentication as a SASL Mechanism", draft-ietf-sasl-rfc2831bis- xx.txt, a work in progress. @@ -1324,7 +1280,7 @@ Normative References Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work in progress. - [Model] Zeilenga, Kurt D. (editor), "LDAP: Directory Information + [Models] Zeilenga, Kurt D. (editor), "LDAP: Directory Information Models", draft-ietf-ldapbis-models-xx.txt, a work in progress. [Protocol] Sermersheim, J., "LDAP: The Protocol", draft-ietf- @@ -1332,11 +1288,24 @@ Normative References [Roadmap] K. Zeilenga, "LDAP: Technical Specification Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. + +Harrison Expires June 2004 [Page 22] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + [SASL] Melnikov, A. (editor), "Simple Authentication and Security Layer (SASL)", draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress. + [SASLPrep] Zeilenga, K., "Stringprep profile for user names and + passwords", draft-ietf-sasl-saslprep-xx.txt, (a work in + progress). + + [StringPrep] Hoffman P. and M. Blanchet, "Preparation of + Internationalized Strings ('stringprep')", draft-hoffman- + rfc3454bis-xx.txt, a work in progress. + [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules", draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. @@ -1344,17 +1313,16 @@ Normative References draft-ietf-tls-rfc2246-bis-xx.txt, a work in progress. [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", - RFC 2279, January 1998. - -Harrison Expires April 2004 [Page 23] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - + RFC 3629, STD 63, November 2003. - [Unicode] International Organization for Standardization, "Universal - Multiple-Octet Coded Character Set (UCS) - Architecture and - Basic Multilingual Plane", ISO/IEC 10646-1 : 1993. - + [Unicode] The Unicode Consortium, "The Unicode Standard, Version + 3.2.0" is defined by "The Unicode Standard, Version 3.0" + (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as + amended by the "Unicode Standard Annex #27: Unicode 3.1" + (http://www.unicode.org/reports/tr27/) and by the öUnicode + Standard Annex #28: Unicode 3.2" + (http://www.unicode.org/reports/tr28/). + Informative References [ANONYMOUS] Zeilenga, K.,"Anonymous SASL Mechanism", draft-zeilenga- @@ -1379,39 +1347,11 @@ Author's Address +1 801 861 2642 roger_harrison@novell.com -Full Copyright Statement - - Copyright (C) The Internet Society (2003). 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 -Harrison Expires April 2004 [Page 24] +Harrison Expires June 2004 [Page 23] -Internet-Draft LDAP Authentication Methods 7 October 2003 +Internet-Draft LDAP Authentication Methods 5 December 2003 - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - Appendix A. Example Deployment Scenarios The following scenarios are typical for LDAP directories on the @@ -1463,14 +1403,14 @@ B.1. Access Control Policy An access control policy is a set of rules defining the protection of resources, generally in terms of the capabilities of persons or other entities accessing those resources. A common expression of an - -Harrison Expires April 2004 [Page 25] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - access control policy is an access control list. Security objects and mechanisms, such as those described here, enable the expression of access control policies and their enforcement. Access control + +Harrison Expires June 2004 [Page 24] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + policies are typically expressed in terms of access control factors as described below. @@ -1522,14 +1462,14 @@ B.4. Authorization Identity identity distinct from the authentication identity asserted by the client's credentials. This permits agents such as proxy servers to authenticate using their own credentials, yet request the access - -Harrison Expires April 2004 [Page 26] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - privileges of the identity for which they are proxying [SASL]. Also, the form of authentication identity supplied by a service like TLS may not correspond to the authorization identities used to express a + +Harrison Expires June 2004 [Page 25] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + server's access control policy, requiring a server-specific mapping to be done. The method by which a server composes and validates an authorization identity from the authentication credentials supplied @@ -1581,14 +1521,14 @@ C.4 Changes to Section 4 - Changed "Distinguished Name" to "LDAP distinguished name". C.5. Changes to Section 5 - -Harrison Expires April 2004 [Page 27] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - Version -00 + +Harrison Expires June 2004 [Page 26] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + - Added the following sentence: "Servers SHOULD NOT allow clients with anonymous authentication to modify directory entries or access sensitive information in directory entries." @@ -1640,13 +1580,14 @@ C.6.2. Changes to Section 6.2 Version -00 + - Renamed section to 6.3 + + -Harrison Expires April 2004 [Page 28] +Harrison Expires June 2004 [Page 27] -Internet-Draft LDAP Authentication Methods 7 October 2003 +Internet-Draft LDAP Authentication Methods 5 December 2003 - - Renamed section to 6.3 - - Reworded first paragraph to remove reference to user and the userPassword password attribute Made the first paragraph more general by simply saying that if a directory supports simple @@ -1700,12 +1641,12 @@ C.8. Changes to section 8. for Other Security Services) to bring material on SASL mechanisms together into one location. -Harrison Expires April 2004 [Page 29] - -Internet-Draft LDAP Authentication Methods 7 October 2003 +C.9. Changes to section 9. +Harrison Expires June 2004 [Page 28] + +Internet-Draft LDAP Authentication Methods 5 December 2003 -C.9. Changes to section 9. Version -00 @@ -1758,13 +1699,13 @@ C.12. Changes to Section 12. - Inserted new section 12 that specifies when SASL protections begin following SASL negotiation, etc. The original section 12 is renumbered to become section 13. + + Version -01 -Harrison Expires April 2004 [Page 30] +Harrison Expires June 2004 [Page 29] -Internet-Draft LDAP Authentication Methods 7 October 2003 +Internet-Draft LDAP Authentication Methods 5 December 2003 - - Version -01 - Moved to section 3.7 to be with other SASL material. @@ -1817,12 +1758,13 @@ Appendix F. Change History to Combined Document F.1. Changes for draft-ldap-bis-authmeth-02 General + + -Harrison Expires April 2004 [Page 31] +Harrison Expires June 2004 [Page 30] -Internet-Draft LDAP Authentication Methods 7 October 2003 +Internet-Draft LDAP Authentication Methods 5 December 2003 - - Added references to other LDAP standard documents, to sections within the document, and fixed broken references. @@ -1876,12 +1818,12 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 - Brought security terminology in line with IETF security glossary throughout the appendix. +F.2. Changes for draft-ldap-bis-authmeth-03 -Harrison Expires April 2004 [Page 32] +Harrison Expires June 2004 [Page 31] -Internet-Draft LDAP Authentication Methods 7 October 2003 +Internet-Draft LDAP Authentication Methods 5 December 2003 -F.2. Changes for draft-ldap-bis-authmeth-03 General @@ -1934,14 +1876,13 @@ F.3. Changes for draft-ldap-bis-authmeth-04 General - + - Changed references to use [RFCnnnn] format wherever possible. + (References to works in progress still use [name] format.) -Harrison Expires April 2004 [Page 33] +Harrison Expires June 2004 [Page 32] -Internet-Draft LDAP Authentication Methods 7 October 2003 +Internet-Draft LDAP Authentication Methods 5 December 2003 - - Changed references to use [RFCnnnn] format wherever possible. - (References to works in progress still use [name] format.) - Various edits to correct typos and bring field names, etc. in line with specification in [Protocol] draft. @@ -1993,15 +1934,14 @@ F.4. Changes for draft-ldap-bis-authmeth-05 several changes to correct improper usage. Abstract - - -Harrison Expires April 2004 [Page 34] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - - Updated to match current contents of documents. This was needed due to movement of material on Bind and Start TLS operations to [Protocol] in this revision. + +Harrison Expires June 2004 [Page 33] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + Section 3. @@ -2053,12 +1993,14 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 section. Section 5.1.7. + + + -Harrison Expires April 2004 [Page 35] +Harrison Expires June 2004 [Page 34] -Internet-Draft LDAP Authentication Methods 7 October 2003 +Internet-Draft LDAP Authentication Methods 5 December 2003 - - Wording from section 3 paragraph beginning " If TLS is negotiated, the client MUST discard all information..." was moved to this section and integrated with existing text. @@ -2112,12 +2054,12 @@ F.5. Changes for draft-ldap-bis-authmeth-06 discussion. Section 1 + -Harrison Expires April 2004 [Page 36] +Harrison Expires June 2004 [Page 35] -Internet-Draft LDAP Authentication Methods 7 October 2003 +Internet-Draft LDAP Authentication Methods 5 December 2003 - - Added additional example of spoofing under threat (7). Section 2.1 @@ -2170,14 +2112,13 @@ F.6. Changes for draft-ldap-bis-authmeth-07 Section 3 - + - Rewrote much of section 3.3 to meet the SASL profile + requirements of draft-ietf-sasl-rfc2222bis-xx.txt section 5. -Harrison Expires April 2004 [Page 37] +Harrison Expires June 2004 [Page 36] -Internet-Draft LDAP Authentication Methods 7 October 2003 +Internet-Draft LDAP Authentication Methods 5 December 2003 - - Rewrote much of section 3.3 to mee the SASL profile requirements - of draft-ietf-sasl-rfc2222bis-xx.txt section 5. - Changed treatement of SASL ANONYMOUS and PLAIN mechanisms to bring in line with WG consensus. @@ -2214,6 +2155,7 @@ F.6. Changes for draft-ldap-bis-authmeth-08 - Changed usage from LDAPv3 to LDAP for usage consistency across LDAP technical specification. + - Fixed a number of usage nits for consistency and to bring doc in conformance with publication guidelines. @@ -2230,18 +2172,18 @@ F.6. Changes for draft-ldap-bis-authmeth-08 - Added 1.5 sentences at end of introductory paragraph indicating the effect of the Bind op on the LDAP association. + -Harrison Expires April 2004 [Page 38] +Harrison Expires June 2004 [Page 37] -Internet-Draft LDAP Authentication Methods 7 October 2003 +Internet-Draft LDAP Authentication Methods 5 December 2003 - Section 3.1 - Retitled section and clarified wording Section 3.2 - + - Clarified that simple authentication choice provides three types of authentication: anonymous, unauthenticated, and simple password. @@ -2254,7 +2196,7 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 Section 3.3.5 - Changed requirement to discard information about server fetched - prior to SASL negotion from MUST to SHOULD to allow for + prior to SASL negotiation from MUST to SHOULD to allow for information obtained through secure mechanisms. Section 3.3.6 @@ -2268,7 +2210,7 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 Section 3.4.1 - - Minor larifications in wording in first sentence. + - Minor clarifications in wording in first sentence. - Explicitly called out that the DN value in the dnAuthzID form is to be matched using DN matching rules. - Called out that the uAuthzID MUST be prepared using SASLprep @@ -2289,12 +2231,12 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 Section 4.1.6 + - Renumbered to 4.1.5. -Harrison Expires April 2004 [Page 39] +Harrison Expires June 2004 [Page 38] -Internet-Draft LDAP Authentication Methods 7 October 2003 +Internet-Draft LDAP Authentication Methods 5 December 2003 - - Renumbered to 4.1.5. - Updated server identity check rules for server's name based on WG list discussion. @@ -2321,6 +2263,106 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 - Added an IANA consideration to update GSSAPI service name registry to point to [Roadmap] and [Authmeth] +F.7. Changes for draft-ldap-bis-authmeth-09 + + + General + + - Updated section references within document + - Changed reference tags to match other docs in LDAP TS + - Used non-quoted names for all SAL mechanisms + + Abstract + + - Inspected keyword usage and removed several improper usages. + + - Removed sentence saying DIGEST-MD5 is LDAP's mandatory-to- + implement mechanism. This is covered elsewhere in document. + + - Moved section 5, authentication state table, of -08 draft to + section 8 of -09 and completely rewrote it. + + Section 1 + + - Reworded sentence beginning, "It is also desireable to allow + authentication methods to carry identities based on existingù + non-LDAP DNùforms..." + - Clarified relationship of this document to other documents in + the LDAP TS. + + Section 3.3.5 + +Harrison Expires June 2004 [Page 39] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + + + - Removed paragraph beginning,"If the client is configured to + support multiple SASL mechanisms..." because the actions + specified in the paragraph do not provide the protections + indicated. Added a new paragraph indicating that clients and + server should allow specification of acceptable mechanisms and + only allow those mechanisms to be used. + + - Clarified independent behavior when TLS and SASL security layers + are both in force (e.g. one being removed doesn't affect the + other). + + Section 3.3.6 + + - Moved most of section 4.2.2, Client Assertion of Authorization + Identity, to sections 3.3.6, 3.3.6.1, and 3.3.6.2. + + Section 3.3.6.4 + + - Moved some normative comments into text body. + + Section 4.1.2 + + - Non success resultCode values are valid if server is *unwilling* + or unable to negotiate TLS. + + Section 4.2.1 + + - Rewrote entire section based on WG feedback. + + Section 4.2.2 + + - Moved most of this section to 3.3.6 for better document flow. + + Section 4.2.3 + + - Rewrote entire section based on WG feedback. + + Section 5.1 + + - Moved imperative language regarding unauthenticated access from + security considerations to here. + + Section 6 + + - Added several paragraphs regarding the risks of transmitting + passwords in the clear and requiring server implementations to + provide a specific configuration that reduces these risks. + + Section 6.2 + + - Added sentence describing protections provided by DIGEST-MD5 + method. + - Changed DNs in exmple to be dc=example,dc=com. + +Harrison Expires June 2004 [Page 40] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + + + Section 10 + + - Updated consideration on use of cleartext passwords to include + other unprotected authentication credentials + - Substantial rework of consideration on misuse of unauthenticated + bind. + Appendix G. Issues to be Resolved This appendix lists open questions and issues that need to be @@ -2348,11 +2390,6 @@ G.3. Section 2, deployment scenario 2: What is meant by the term "secure authentication function?" - -Harrison Expires April 2004 [Page 40] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - Status: resolved. Based on the idea that a "secure authentication function" could be provided by TLS, I changed the wording to require @@ -2370,6 +2407,13 @@ G.4. G.5. + + + +Harrison Expires June 2004 [Page 41] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + Section 4 paragraph 3: What is meant by the phrase, "this means that either this data is useless for faking authentication (like the Unix "/etc/passwd" file format used to be)?" @@ -2394,10 +2438,9 @@ G.6. G.7. Section 4 paragraph 8 indicates that "information about the server - fetched fetched prior to the TLS negotiation" must be discarded. Do - we want to explicitly state that this applies to information fetched - prior to the *completion* of the TLS negotiation or is this going - too far? + fetched prior to the TLS negotiation" must be discarded. Do we want + to explicitly state that this applies to information fetched prior + to the *completion* of the TLS negotiation or is this going too far? Status: resolved. Based on comments in the IETF 51 LDAPBIS WG meeting, this has been changed to explicitly state, "fetched prior @@ -2407,11 +2450,6 @@ G.8. Section 4 paragraph 9 indicates that clients SHOULD check the supportedSASLMechanisms list both before and after a SASL security - -Harrison Expires April 2004 [Page 41] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - layer is negotiated to ensure that they are using the best available security mechanism supported mutually by the client and server. A note at the end of the paragraph indicates that this is a SHOULD @@ -2429,6 +2467,12 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 Approach 2: Clients MUST check the supportedSASLMechanisms list both before and after SASL negotiation UNLESS they use a + + +Harrison Expires June 2004 [Page 42] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + different trusted source to determine available supported SASL mechanisms. @@ -2466,11 +2510,6 @@ G.10 userPassword and simple bind the bind request. G.11. Meaning of LDAP Association - -Harrison Expires April 2004 [Page 42] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - The original RFC 2830 uses the term "LDAP association" in describing a connection between an LDAP client and server regardless of the @@ -2488,6 +2527,11 @@ G.12. Is DIGEST-MD5 mandatory for all implementations? Reading 2829bis I think DIGEST-MD5 is mandatory ONLY IF your server supports password based authentication...but the following makes it sound mandatory to provide BOTH password authentication AND DIGEST- + +Harrison Expires June 2004 [Page 43] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + MD5: "6.2. Digest authentication @@ -2525,11 +2569,6 @@ G.14. Document vulnerabilities of various mechanisms While I'm here...in 2829, I think it would be good to have some comments or explicit reference to a place where the security properties of the particular mandatory authentication schemes are - -Harrison Expires April 2004 [Page 43] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - outlined. When I say "security properties" I mean stuff like "This scheme is vulnerable to such and such attacks, is only safe if the key size is > 50, this hash is widely considered the best, etc...". @@ -2540,7 +2579,7 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 Status: out of scope. This is outside the scope of this document and will not be addressed. -G.15. Include a StartTLS state transition table +G.15. Include a Start TLS state transition table The pictoral representation it is nominally based on is here (URL possibly folded): @@ -2548,12 +2587,23 @@ G.15. Include a StartTLS state transition table http://www.stanford.edu/~hodges/doc/LDAPAssociationStateDiagram- 1999-12-14.html +Harrison Expires June 2004 [Page 44] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + + (Source: Jeff Hodges) - Status: In Process. Table provided in -03. Review of content for - accuracy in -04. Additional review is needed, plus comments from WG - members indicate that additional description of each state's meaning - would be helpful. + Status: Resolved. + + Table provided in -03. Review of content for accuracy in -04. + Additional review is needed, plus comments from WG members indicate + that additional description of each state's meaning would be + helpful. + + Did a significant revision of state transition table in -09. Changes + were based on suggestions from WG and greatly simplified overall + table. G.16. Empty sasl credentials question @@ -2584,11 +2634,6 @@ G.17. Hostname check from MUST to SHOULD? solution! Wildcard match does not solve this problem. For these reasons I am inclined to argue for 'SHOULD' instead of 'MUST' in paragraph... - -Harrison Expires April 2004 [Page 44] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - Also, The hostname check against the name in the certificate is a very weak means of preventing man-in-the-middle attacks; the proper @@ -2600,6 +2645,11 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 Status: resolved. Based on discussion at IETF 52 ldapbis WG meeting, this text will stand as it is. The check is a MUST, but the behavior + +Harrison Expires June 2004 [Page 45] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + afterward is a SHOULD. This gives server implementations the room to maneuver as needed. @@ -2643,11 +2693,6 @@ G.19. DN used in conjunction with SASL mechanism G.20. Bind states - -Harrison Expires April 2004 [Page 45] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - Differences between unauthenticated and anonymous. There are four states you can get into. One is completely undefined (this is now explicitly called out in [Protocol]). This text needs to be moved @@ -2659,6 +2704,11 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 called out in [AuthMeth]. State 3 is called out in [Protocol]; this seems appropriate based on review of alternatives. + +Harrison Expires June 2004 [Page 46] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + G.21. Misuse of unauthenticated access Add a security consideration that operational experience shows that @@ -2669,7 +2719,7 @@ G.21. Misuse of unauthenticated access Status: Resolved. Added to security considerations in -03. -G.22. Need to move StartTLS protocol information to [Protocol] +G.22. Need to move Start TLS protocol information to [Protocol] Status: Resolved. Removed Sections 5.1, 5.2, and 5.4 for -04 and they are [Protocol] -11. @@ -2702,11 +2752,6 @@ canonical DNS name in Server Identity Check? man-in-the-middle attacks). But what is the subtle difference between the "server hostname" and the "server's canonical DNS name"? (Source: Tim Hahn) - -Harrison Expires April 2004 [Page 46] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - Status: Resolved. @@ -2718,6 +2763,11 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 (11/21/02): RL Bob Morgan will provide wording that allows derivations of the name that are provided securely. + +Harrison Expires June 2004 [Page 47] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + (6/28/03): posted to the WG list asking Bob or any other WG member who is knowledgeable about the issues involved to help me with wording or other information I can use to make this change and close @@ -2760,12 +2810,6 @@ G.27 Inconsistency in effect of TLS closure on LDAP association. "Either the client or server MAY terminate the TLS connection on an LDAP association by sending a TLS closure alert. The LDAP connection remains open for further communication after TLS closure - - -Harrison Expires April 2004 [Page 47] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - occurs although the authentication state of the LDAP connection is affected (see [AuthMeth] section 4.2.2). @@ -2778,6 +2822,11 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 G.28 Ordering of external sources of authorization identities + +Harrison Expires June 2004 [Page 48] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + Section 4.3.2 implies that external sources of authorization identities other than TLS are permitted. What is the behavior when two external sources of authentication credentials are available @@ -2819,11 +2868,6 @@ G.31 Use of PLAIN SASL Mechanism section, (c) ensure wording of last sentence regarding non-DN AuthZIDs is consistent with rest of the section. - -Harrison Expires April 2004 [Page 48] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - Status: Resolved. (6/28/03): email to WG list stating issue and asking if we should @@ -2837,6 +2881,11 @@ G.32 Clarification on use of SASL mechanisms Section 3.3.1: BTW, what _are_ the "ANONYMOUS" and "PLAIN" SASL mechanisms? They are not defined in RFC2222. If you refer to other + +Harrison Expires June 2004 [Page 49] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + SASL mechanisms than those in rfc2222, Maybe you should only list which mechanisms _are_used, instead of which ones are _not. (Source: Hallvard Furuseth) @@ -2865,6 +2914,11 @@ G.33 Clarification on use of password protection based on AuthZID form A mechanism that protects the password in transit should be used in any case, shouldn't it? + Status: Resolved. + + In -08 draft this text was removed. There is already a general + security consideration that covers this issue. + G.34 Clarification on use of matching rules in Server Identity Check @@ -2878,11 +2932,6 @@ G.35 Requested Additions to Security Considerations Requested to mention hostile servers which the user might have been fooled to into contacting. Which mechanisms that are standardized by - -Harrison Expires April 2004 [Page 49] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - the LDAP standard do/do not disclose the user's password to the server? (Or to servers doing man-in-the-middle attack? Or is that a stupid question?) @@ -2891,6 +2940,11 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 Requested list of methods that need/don't need the server to know the user's plaintext password. (I say 'know' instead of 'store' + +Harrison Expires June 2004 [Page 50] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + because it could still store the password encrypted, but in a way which it knows how to decrypt.) @@ -2913,10 +2967,10 @@ G.37 Clarification on procedure for certificate-based authentication immediately following, or just some time later? Should the wording, "the client will send..." actually read, "the client MUST send..."? -G.38 Effect of StartTLS on authentication state +G.38 Effect of Start TLS on authentication state Should the server drop all knowledge of connection, i.e. return to - anonymous state, if it gets a StartTLS request on a connection that + anonymous state, if it gets a Start TLS request on a connection that has successfully bound using the simple method? G.39 Be sure that there is a consideration in [SCHEMA] that discusses @@ -2937,11 +2991,6 @@ and resulting authorization identity on implicit assertion of AuthZID. 4.2.2.3. Error Conditions "For either form of assertion, the server MUST verify that the - -Harrison Expires April 2004 [Page 50] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - client's authentication identity as supplied in its TLS credentials is permitted to be mapped to the asserted authorization identity." @@ -2950,6 +2999,11 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 IMHO, the mapping can be done as two steps: a). deriving LDAP authentication identity from TLS credentials; If t this steps fails, EXTERNAL mechanism returns failure. + +Harrison Expires June 2004 [Page 51] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + b). verify that the authorization identity is allowed for the derived authentication identity. This is always "noop" for the implicit case. @@ -2963,7 +3017,7 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 This text has been moved to apply only to the explicit assertion case. -G.41. Section 7.2 contains unnecessary and misleading detail. +G.41. Section 7.2 contains unnecessary and misleading detail. " I am not sure why this section is required in the document. DIGEST-MD5 is defined in a separate document and there should be @@ -2995,12 +3049,6 @@ G.42. Does change for G.41 cause interoperability issue? Status: Resolved - - -Harrison Expires April 2004 [Page 51] - -Internet-Draft LDAP Authentication Methods 7 October 2003 - (10/08/03) This item was discussed on the WG list between 5/2/03 and 5/9/03. Consensus apppears to support the notion that RFC 2829 was in error and that the semantics of RFC 2831 are correct and should @@ -3009,6 +3057,12 @@ Internet-Draft LDAP Authentication Methods 7 October 2003 G.43. DIGEST-MD5 Realms recommendations for LDAP + + +Harrison Expires June 2004 [Page 52] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + From http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis- 02.txt: A protocol profile SHOULD provide a guidance how realms are to be constructed and used in the protocol and MAY further restrict @@ -3046,6 +3100,14 @@ G.43. DIGEST-MD5 Realms recommendations for LDAP John McMeeking (5/12/2003) + Status: Resolved. + + draft-ietf-sasl-rfc2222bis-03.txt no longer requires this + information in a SASL protocol. In addition, the ldapbis WG chairs + have ruled this work out of scope. Individuals are welcome to make + submissions to provide guidance on the use of realm and realm values + in LDAP. + G.44. Use of DNs in usernames and realms in DIGEST-MD5 In reading the discussion on the mailing list, I reach the following @@ -3056,9 +3118,9 @@ G.44. Use of DNs in usernames and realms in DIGEST-MD5 DIGEST-MD5 treats them a simple strings for comparision purposes. For example, the DNs cn=roger, o=US and cn=roger,o=us are equivalent -Harrison Expires April 2004 [Page 52] +Harrison Expires June 2004 [Page 53] -Internet-Draft LDAP Authentication Methods 7 October 2003 +Internet-Draft LDAP Authentication Methods 5 December 2003 when being compared semantically as DNs, however, these would be considered two different username values in DIGEST-MD5 because @@ -3088,7 +3150,66 @@ G.45: Open Issue: Is Simple+TLS mandatory to implement? there has been significant discussion on the use of DN values as the username for DIGEST-MD5. + Status: Resolved. + + Based on WG list discussion, Kurt Zeilenga has gaged a lack of WG + consensus that Simple+TLS should be mandatory to implement. No + further discussion is necessary. + +Intellectual Property Rights + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances + of licenses to be made available, or the result of an attempt made + to obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification + can be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + +Harrison Expires June 2004 [Page 54] + +Internet-Draft LDAP Authentication Methods 5 December 2003 + + this standard. Please address the information to the IETF Executive + Director. + +Full Copyright + + Copyright (C) The Internet Society (2003). 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. + + + + + + + + + @@ -3115,5 +3236,6 @@ G.45: Open Issue: Is Simple+TLS mandatory to implement? -Harrison Expires April 2004 [Page 53] +Harrison Expires June 2004 [Page 55] + -- 2.39.5