rfc4513.txt

samba最新软件

Harrison                    Standards Track                    [Page 16]

RFC 4513              LDAP Authentication Methods              June 2006


   saslBindInProgress.  This indicates that the server requires the
   client to send a new BindRequest message with the same SASL mechanism
   to continue the authentication process.

   To the LDAP message layer, these challenges and responses are opaque
   binary tokens of arbitrary length.  LDAP servers use the
   serverSaslCreds field (an OCTET STRING) in a BindResponse message to
   transmit each challenge.  LDAP clients use the credentials field (an
   OCTET STRING) in the SaslCredentials sequence of a BindRequest
   message to transmit each response.  Note that unlike some Internet
   protocols where SASL is used, LDAP is not text based and does not
   Base64-transform these challenge and response values.

   Clients sending a BindRequest message with the sasl choice selected
   SHOULD send a zero-length value in the name field.  Servers receiving
   a BindRequest message with the sasl choice selected SHALL ignore any
   value in the name field.

   A client may abort a SASL Bind negotiation by sending a BindRequest
   message with a different value in the mechanism field of
   SaslCredentials or with an AuthenticationChoice other than sasl.

   If the client sends a BindRequest with the sasl mechanism field as an
   empty string, the server MUST return a BindResponse with a resultCode
   of authMethodNotSupported.  This will allow the client to abort a
   negotiation if it wishes to try again with the same SASL mechanism.

   The server indicates completion of the SASL challenge-response
   exchange by responding with a BindResponse in which the resultCode
   value is not saslBindInProgress.

   The serverSaslCreds field in the BindResponse can be used to include
   an optional challenge with a success notification for mechanisms that
   are defined to have the server send additional data along with the
   indication of successful completion.

5.2.1.3.  Optional Fields

   As discussed above, LDAP provides an optional field for carrying an
   initial response in the message initiating the SASL exchange and
   provides an optional field for carrying additional data in the
   message indicating the outcome of the authentication exchange.  As
   the mechanism-specific content in these fields may be zero length,
   SASL requires protocol specifications to detail how an empty field is
   distinguished from an absent field.






Harrison                    Standards Track                    [Page 17]

RFC 4513              LDAP Authentication Methods              June 2006


   Zero-length initial response data is distinguished from no initial
   response data in the initiating message, a BindRequest PDU, by the
   presence of the SaslCredentials.credentials OCTET STRING (of length
   zero) in that PDU.  If the client does not intend to send an initial
   response with the BindRequest initiating the SASL exchange, it MUST
   omit the SaslCredentials.credentials OCTET STRING (rather than
   include an zero-length OCTET STRING).

   Zero-length additional data is distinguished from no additional
   response data in the outcome message, a BindResponse PDU, by the
   presence of the serverSaslCreds OCTET STRING (of length zero) in that
   PDU.  If a server does not intend to send additional data in the
   BindResponse message indicating outcome of the exchange, the server
   SHALL omit the serverSaslCreds OCTET STRING (rather than including a
   zero-length OCTET STRING).

5.2.1.4.  Octet Where Negotiated Security Layers Take Effect

   SASL layers take effect following the transmission by the server and
   reception by the client of the final BindResponse in the SASL
   exchange with a resultCode of success.

   Once a SASL layer providing data integrity or confidentiality
   services takes effect, the layer remains in effect until a new layer
   is installed (i.e., at the first octet following the final
   BindResponse of the Bind operation that caused the new layer to take
   effect).  Thus, an established SASL layer is not affected by a failed
   or non-SASL Bind.

5.2.1.5.  Determination of Supported SASL Mechanisms

   Clients may determine the SASL mechanisms a server supports by
   reading the 'supportedSASLMechanisms' attribute from the root DSE
   (DSA-Specific Entry) ([RFC4512], Section 5.1).  The values of this
   attribute, if any, list the mechanisms the server supports in the
   current LDAP session state.  LDAP servers SHOULD allow all clients --
   even those with an anonymous authorization -- to retrieve the
   'supportedSASLMechanisms' attribute of the root DSE both before and
   after the SASL authentication exchange.  The purpose of the latter is
   to allow the client to detect possible downgrade attacks (see Section
   6.4 and [RFC4422], Section 6.1.2).

   Because SASL mechanisms provide critical security functions, clients
   and servers should be configurable to specify what mechanisms are
   acceptable and allow only those mechanisms to be used.  Both clients
   and servers must confirm that the negotiated security level meets
   their requirements before proceeding to use the session.




Harrison                    Standards Track                    [Page 18]

RFC 4513              LDAP Authentication Methods              June 2006


5.2.1.6.  Rules for Using SASL Layers

   Upon installing a SASL layer, the client SHOULD discard or refresh
   all information about the server that it obtained prior to the
   initiation of the SASL negotiation and that it did not obtain through
   secure mechanisms.

   If a lower-level security layer (such as TLS) is installed, any SASL
   layer SHALL be layered on top of such security layers regardless of
   the order of their negotiation.  In all other respects, the SASL
   layer and other security layers act independently, e.g., if both a
   TLS layer and a SASL layer are in effect, then removing the TLS layer
   does not affect the continuing service of the SASL layer.

5.2.1.7.  Support for Multiple Authentications

   LDAP supports multiple SASL authentications as defined in [RFC4422],
   Section 4.

5.2.1.8.  SASL Authorization Identities

   Some SASL mechanisms allow clients to request a desired authorization
   identity for the LDAP session ([RFC4422], Section 3.4).  The decision
   to allow or disallow the current authentication identity to have
   access to the requested authorization identity is a matter of local
   policy.  The authorization identity is a string of UTF-8 [RFC3629]
   encoded [Unicode] characters corresponding to the following Augmented
   Backus-Naur Form (ABNF) [RFC4234] grammar:

      authzId = dnAuthzId / uAuthzId

      ; distinguished-name-based authz id
      dnAuthzId =  "dn:" distinguishedName

      ; unspecified authorization id, UTF-8 encoded
      uAuthzId = "u:" userid
      userid = *UTF8 ; syntax unspecified

   where the distinguishedName rule is defined in Section 3 of [RFC4514]
   and the UTF8 rule is defined in Section 1.4 of [RFC4512].

   The dnAuthzId choice is used to assert authorization identities in
   the form of a distinguished name to be matched in accordance with the
   distinguishedNameMatch matching rule ([RFC4517], Section 4.2.15).
   There is no requirement that the asserted distinguishedName value be
   that of an entry in the directory.





Harrison                    Standards Track                    [Page 19]

RFC 4513              LDAP Authentication Methods              June 2006


   The uAuthzId choice allows clients to assert an authorization
   identity that is not in distinguished name form.  The format of
   userid is defined only as a sequence of UTF-8 [RFC3629] encoded
   [Unicode] characters, and any further interpretation is a local
   matter.  For example, the userid could identify a user of a specific
   directory service, be a login name, or be an email address.  A
   uAuthzId SHOULD NOT be assumed to be globally unique.  To compare
   uAuthzId values, each uAuthzId value MUST be prepared as a "query"
   string ([RFC3454], Section 7) using the SASLprep [RFC4013] algorithm,
   and then the two values are compared octet-wise.

   The above grammar is extensible.  The authzId production may be
   extended to support additional forms of identities.  Each form is
   distinguished by its unique prefix (see Section 3.12 of [RFC4520] for
   registration requirements).

5.2.2.  SASL Semantics within LDAP

   Implementers must take care to maintain the semantics of SASL
   specifications when handling data that has different semantics in the
   LDAP protocol.

   For example, the SASL DIGEST-MD5 authentication mechanism
   [DIGEST-MD5] utilizes an authentication identity and a realm that are
   syntactically simple strings and semantically simple username
   [RFC4013] and realm values.  These values are not LDAP DNs, and there
   is no requirement that they be represented or treated as such.

5.2.3.  SASL EXTERNAL Authentication Mechanism

   A client can use the SASL EXTERNAL ([RFC4422], Appendix A) mechanism
   to request the LDAP server to authenticate and establish a resulting
   authorization identity using security credentials exchanged by a
   lower security layer (such as by TLS authentication).  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.  Although this situation
   has the effect of leaving the LDAP session in an anonymous state
   (Section 4), the state of any installed security layer is unaffected.

   A client may either request that its authorization identity be
   automatically derived from its authentication credentials exchanged
   at a lower security layer, or it may explicitly provide a desired
   authorization identity.  The former is known as an implicit
   assertion, and the latter as an explicit assertion.






Harrison                    Standards Track                    [Page 20]

RFC 4513              LDAP Authentication Methods              June 2006


5.2.3.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 does not include the optional credentials field (found within
   the SaslCredentials sequence in the BindRequest).  The server will
   derive the client's authorization identity from the authentication
   identity supplied by a security layer (e.g., a public key certificate
   used during TLS layer installation) according to local policy.  The
   underlying mechanics of how this is accomplished are implementation
   specific.

5.2.3.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 includes the credentials field (found within the SaslCredentials
   sequence in the BindRequest).  The value of the credentials field (an
   OCTET STRING) is the asserted authorization identity and MUST be
   constructed as documented in Section 5.2.1.8.

6.  Security Considerations

   Security issues are discussed throughout this document.  The
   unsurprising conclusion is that security is an integral and necessary
   part of LDAP.  This section discusses a number of LDAP-related
   security considerations.

6.1.  General LDAP Security Considerations

   LDAP itself provides no security or protection from accessing or
   updating the directory by means other than through the LDAP protocol,
   e.g., from inspection of server database files by database
   administrators.

   Sensitive data may be carried in almost any LDAP message, and its
   disclosure may be subject to privacy laws or other legal regulation
   in many countries.  Implementers should take appropriate measures to
   protect sensitive data from disclosure to unauthorized entities.

   A session on which the client has not established data integrity and
   privacy services (e.g., via StartTLS, IPsec, or a suitable SASL
   mechanism) is subject to man-in-the-middle attacks to view and modify
   information in transit.  Client and server implementers SHOULD take
   measures to protect sensitive data in the LDAP session from these
   attacks by using data protection services as discussed in this
   document.  Clients and servers should provide the ability to be
   configured to require these protections.  A resultCode of



Harrison                    Standards Track                    [Page 21]

RFC 4513              LDAP Authentication Methods              June 2006


   confidentialityRequired indicates that the server requires
   establishment of (stronger) data confidentiality protection in order
   to perform the requested operation.

   Access control should always be applied when reading sensitive
   information or updating directory information.

   Various security factors, including authentication and authorization
   information and data security services may change during the course
   of the LDAP session, or even during the performance of a particular
   operation.  Implementations should be robust in the handling of
   changing security factors.

6.2.  StartTLS Security Considerations