authmeth-14 notes

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Some text about TLS in the draft should also apply to SASL layers.
I mention a few I noticed; I may have missed some.

I've suggested to change "successful" to the result code name "success"
a few places, since compareTrue/compareFalse/referral could also be
considered successful.  Not everywhere, since it's nitpicky and doing so
consistently would sometimes make for more cumbersome wordings (at least
the wordings I could think of).

> 1. Introduction

>    Considering the above requirements, experience has shown that simply
>    allowing implementations to pick and choose among the possible
>    alternatives is not a strategy that leads to interoperability.

Which "above requirements" are that?  The paragraph below, which comes
two pages earlier?  That's a bit far to look for it.  It's not "to
counter the section's list of basic threats", which one might expect if
one doesn't remember the wording of this paragraph.  DoS attacks, for
example, are not addressed by any MUST or SHOULD.

>    It is vital that these security functions be interoperable among all
>    LDAP clients and servers on the Internet; therefore there has to be
>    a minimum subset of security functions that is common to all
>    implementations that claim LDAP conformance.


> 1.2. Conventions
>
>

Spurious double newline.

>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

> 2. Implementation Requirements

>    LDAP implementations SHOULD support the simple (DN and password)
>    authentication mechanism of simple bind (section 8).
>    Implementations that support this authentication mechanism MUST be
>    capable of protecting

...it...

>    using TLS as established by the StartTLS
>    operation (section 3), SHOULD disallow the use of this

> 3.1.1. StartTLS Request

>    A client may send the StartTLS extended request at any time after
>    establishing an LDAP connection, except:
>       (...)
>       - when it has not yet received responses for all operation
>         requests previously issued on the connection.

Except for operations known to have been abandoned - e.g. by a Bind
request.  "Outstanding" was a better wording after all.  Or maybe
something like

        - when operations which were previously issued on the
          connection, remain and will receive responses.

I'm a bit dissatisfied with the distance (almost 2 pages) between these
two statements:

> 3.1.2. StartTLS Response
>    The state of the association is unaffected if a non-success
>    resultCode is returned.

> 3.2. Effects of TLS on a Client's Authorization Identity
>    The decision to keep or invalidate the established state of the
>    association (section 4.3) after TLS layer installation or removal is
>    a matter of local server policy.

Maybe that text from 3.1.2 shuld be moved to 3.2, and section 3.2
renamed to something like "TLS and the Client's Authorization Identity"
(since the effect of a failed StartTLS is not exactly "effect of TLS")?
I don't really know if that's an improvement.

If it is moved, maybe s/non-success resultCode/resultCode other than
success/ to make sure nobody takes it to mean 'non-error' (such as a
referral).  Also s/successful/success/ below for the same reason.

Also one might invalidate the association after TLS ciphersuite
renegotiation.

Or after StartTLS + a failed TLS negotiation which leaves the connection
open, if that can happen?  (I wonder if I've said that before and the
answer was no...)

The document is missing a rationale for _why_ one would want to
invalidate the connection in the listed circumstances.

Also, it might be worth mentioning that there can be valid reasons to
_not_ invalidate the association after TLS Closure.  E.g. StartTLS ->
DIGEST-MD5 (rather than Simple Bind because DIGEST-MD5 does not disclose
password to server; section 12.4) -> TLS closure -> continue protected
by SASL layer from DIGEST-MD5.

> 3.1.4. Client Certificate

>    If a client that has provided a suitable certificate subsequently
>    binds using the SASL EXTERNAL authentication mechanism (section 9),
>    information in the certificate may be used by the server to
>    establish the client's authorization identity.

This is technically true, but misleading since one can request a
different authz ID.  I'm not sure what to do about it, if anything.

"...client's authentication identity" would be more correct, but the
document hasn't defined "authentication identity" yet, and in any case
the authentication identity is not relevant to the protocol after Bind
success.  Is something vaguer like "...to identify and authenticate the
user" better, or should more text be added?

> 3.1.5. Discovery of Resultant Security Level

>    The client may then

...either...
(because it's many words before we see if an "or" or "and" is coming).

>    close the transport connection, attempt to StartTLS again,
>    send an unbind request, or send any other LDAP request.

> 3.1.6. Server Identity Check

>   Matching is performed according to these rules:

Can someone remind me why this is specified here instead of in [TLS]?
It doesn't look LDAP-specific.  I can't find the answer in the archive.

Is this procedure a refinement of a procedure from [TLS]?  If so, a
reference would be welcome.

>      - If a subjectAltName extension of type dNSName is present in the
>        certificate, it SHOULD be used as the source of the server's
>        identity.

>      - The "*" wildcard character is allowed.  If present, it applies
>        only to the left-most name component.
>
>        For example, *.bar.com would match a.bar.com and b.bar.com, but
>        it would not match a.x.bar.com nor would it match bar.com.

If the following has anything with to do with wildcards, I don't see
it from the text.  Looks like it should be a separate list item:

>                                                                   If
>        more than one identity of a given type is present in the
>        certificate (e.g. more than one dNSName name), a match with any
>        one of the set is considered acceptable.

However, if so this looks inconsistent with the subjectAltName item
above.  That implies that _only_ dNSName:subjectAltName should be used
when available, while the above sentence seems to allow us to pick the
name from other dNSName things if subjectAltName is present but does not
match.  Or is that just because I don't know X.509?

> 3.3. TLS Ciphersuites

>      - The ciphersuite's vulnerability (or lack thereof) to man-in-the-
>        middle attacks. Ciphersuites vulnerable to man-in-the-middle
>        attacks SHOULD NOT be used to protect passwords or sensitive
>        data, unless the network configuration is such that the danger
>        of a man-in-the-middle attack is tolerable.

That's rather at odds with the text about DIGEST-MD5, which is also
vulnerable to man-in-the-middle.  Maybe one SHOULD NOT use DIGEST-MD5
without better protection either...

> 3.3.1. TLS Ciphersuites Recommendations

s/Ciphersuites/Ciphersuite/.

>    The following ciphersuites defined in [TLS] can be cracked easily
>    (less than a day of CPU time on a standard CPU in 2000) and are NOT
>    RECOMMENDED for use in confidentiality protection of passwords or
>    data:

If anyone has the number, maybe "< 1 day in 2000" should be updated to
2005 timing.

> 4.3. Invalidated Associations
>
>    The server may move the association to an invalidated state at any
>    time, e.g. if an established security layer between the client and
>    server has unexpectedly failed or been compromised.  While the LDAP
>    session has an invalidated association, the server may reject any
>    operation request other than Bind, Unbind, and StartTLS by
>    responding with a resultCode of strongerAuthRequired to indicate
>    that the server requires stronger authentication before it will
>    attempt to perform the requested operation. In practice, this means
>    that the client needs to bind to(re)establish a suitably strong
>    authorization state on the association before the server will
>    attempt to perform the requested operation.

The last I remember, we gave up on having invalidated associations
return a result to a rejected request: thread 'Result code for
invalidated associations', 2004.  The whole mess about them doing so
just got too ugly.  Instead, if a request is rejected because the
association is invalidated, just send Notice of Disconnection and
terminate the session.  I don't remember which result code we ended
up with; I think that issue came up in several threads.

BTW, this section might refer to 'operations that depend on the
authorization state' in general, and just list Bind, Unbind and StartTLS
as the ones that occur in [Protocol].  Consider extended operations that
could also be safe, or controls that modify Bind or StartTLS in a way
which is not safe for invalidated associations.

> 5. Bind Operation

>    If the authorization identity is specified

comma

>    the server MUST verify
>    that the client's authentication identity is permitted to assume

> 7. Unauthenticated Authentication Mechanism of Simple Bind
>
>    An LDAP client may use the unauthenticated authentication mechanism
>    of the simple Bind choice to establish an anonymous association by
>    sending a Bind request with a name value, a distinguished name in
>    LDAP string form [LDAPDN] of non-zero length, and specifying the the
>    simple authentication choice containing a password value of zero
>    length.

Maybe clarify the latter:

     Thus the DN is NOT the new authentication identity, but it can
     e.g. be used for tracing.

> 8. Simple Authentication Mechanism of Simple Bind

>    but not valid for purposes of authentication, or the password is not
>    valid for the DN, or the server otherwise considers the credentials
>    to be invalidA

Missing period before "A".

>    resultCode of success indicates that the credentials

>    The simple authentication mechanism of simple bind is not suitable
>    for authentication in environments where there is no network or
>    transport layer confidentiality.x
     ^^^^^^^^^^^^^^^

...nor SASL layer.

Maybe add "Implementations SHOULD by default reject attemts to use the
mechanism in such situations."

Remove the spurious "x".

> 9.2. SASL Authentication Initiation and Protocol Exchange

>       - 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 5.1).

s/may/MAY/ to emphasize that this is optional?

>    In general, a SASL authentication protocol exchange consists of a
>    series of server challenges and client responses, the contents of
>    which are specific to and defined by the SASL mechanism. Thus for
>    some SASL authentication mechanisms, it may be necessary for the
>    client to respond to one or more server challenges by invoking the
>    Bind operation multiple times. A challenge is indicated by the
>    server sending a BindResponse PDU with the resultCode set to
>    saslBindInProgress. This indicates that the server requires the
>    client to send a new BindRequest PDU 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 PDU
>    message to transmit each challenge.

"BindResponse PDU message" seems a bit excessive.  Drop "PDU" and/or
"message"?  Also on the next page in the same paragraph.

>    LDAP clients use the credentials
>    field, an OCTET STRING, in the SaslCredentials sequence of a
>    BindRequest PDU message to transmit each response. Note that unlike
>    some Internet protocols where SASL is used, LDAP is not text based,
>    thus no Base64 transformations are performed on these challenge and
>    response values.

Unless the mechanism says so.  I suggest
    s/, thus ... performed on/and does not Base64-transform/
to reduce the chance of confusing the mechanism's encoding with
LDAP's encoding of such values.

>    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.
>
>

Spurious double newline.

>    The server indicates completion of the SASL challenge-response
>    exchange by responding with a BindResponse in which the resultCode
>    is not saslBindInProgress (either success or another error
>    indication).

s/another error indication/another result code/.

(success is not an error indication, and there are also other codes
that are not error indications - in particular referral.)

>    The serverSaslCreds field in the BindResponse can be used to include
>    an optional challenge with a success notification for mechanisms
>    which are defined to have the server send additional data along with
>    the indication of successful completion. If a server does not intend
>    to send a challenge value in a BindResponse message, the server

s/challenge value/challenge/?

>    SHALL omit the serverSaslCreds field (rather than including the
>    field with a zero-length value).

> 9.3. Octet Where Negotiated Security Mechanisms Take Effect
>
>    SASL layers take effect following the transmission by the server and
>    reception by the client of the final successful BindResponse in the
>    exchange.

s/successful/success/.  Referral is successful too.

>    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.

> 9.4. Determination of Supported SASL Mechanisms

>    LDAP servers SHOULD allow a client with
>    an anonymous association to retrieve the supportedSASLMechanisms
>    attribute of the root DSE.

s/a client/even a client/?
Or is this "SHOULD" only intended to apply to anonymous clients?

> 9.5. Rules for Using SASL Layers

>    If a SASL layer is installed, the client SHOULD discard information
>    about the server it obtained prior to the initiation of the SASL
>    negotiation and not obtained through secure mechanisms.

I suggest to dupliate the wording from 3.1.7 (about TLS):
     s/If a SASL layer is installed/Upon installing a SASL layer/
     s/discard information/discard or refresh all information/
Or maybe do change #2 in the other direction in 3.1.7.

> 9.7. SASL Authorization Identities

>    authzId ::= dnAuthzId / uAuthzId

s/::=/=/.  "::=" is ASN.1 notation.
Sorry, my mistake (from previous authmeth comments).

>    DNCOLON  ::= %x64 %x6e %x3a ; "dn:"
>    UCOLON ::= %x75 %x3a ; "u:"

That's case-sensitive.  RFC 2829 says "dn:" and "u:", which are
case-insensitive in ABNF [RFC2234].

Kurt mentioned this in 'authmeth review notes [long]' of 27 Feb 2004:
   http://www.openldap.org/lists/ietf-ldapbis/200402/msg00083.html
but I see no reply in the archive.  He suggested

   DNCOLON = ( %x44 / %x64 ) ( %4E / %x6E ) %x3A ; "dn:"
   UCOLON = ( %x55 / %x75 ) %x3A ; "u:"

but I don't see the point of "simulating" case-insensitive tokens
that way instead of just reverting to the old notation.

BTW, in case this was lost: I suggest to have those productions at the
end of this section's grammar, so the grammar refers strictly downwards.

> 11. SASL EXTERNAL Authentication Mechanism

Message 'authmeth review notes [long]' from Kurt at 27 Feb 2004:
  http://www.openldap.org/lists/ietf-ldapbis/200402/msg00083.html
lists several problems with this section (at that time, Section 9).
At least some have not been adressed - 'lower lever security layer' and
'MUST fail with ... inappropriateAuthentication'.  He said he'd offer
replacement text, but I could not find that.  Maybe it was forgotten in
the middle of all the other discussion going on at the time.

>    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 an
>    authorization identity desired for the association.  The former is
>    known as an implicit assertion, and the latter as an explicit
>    assertion.

This paragraph, and the two following sections:

> 11.1. Implicit Assertion
> 11.2. Explicit Assertion

...apply to SASL in general, not to just SASL EXTERNAL (Section 11).  If
it needs be explained here, that implies to me that it's equally needed
about other SASL methods.  If it is stated here, it should be enough to
say that EXTERNAL supports both variants, and that they are called
Implicit Assertion and Explicit Assertion (yes, I've finally learned
that these terms come from RFC 2830 - LDAP TLS extension:-).

> 12.1. General LDAP Security Considerations
>
>    LDAP itself provides no security or protection from accessing or
>    updating the directory by other means than through the LDAP
>    protocol, e.g. from inspection

"of its database files"?

> by database administrators.

>    Servers can minimize denial of service attacks by providing the
>    ability to configure and enforce administrative limits on
>    operations, timing out idle connections and returning the
>    unwillingToPerform resultCode rather than performing computationally
>    expensive operations requested by unauthorized clients.

I seem to remember someone mentioned this is rather primitive DoS
protection by today's standards?

> 12.1.1. Password-related Security Considerations

>    The use of clear text passwords and other unprotected authentication
>    credentials is strongly discouraged over open networks when the
>    underlying transport service cannot guarantee confidentiality.  LDAP
>    implementations SHOULD NOT support authentication methods using
>    cleartext passwords and other unprotected authentication credentials
>    unless the data on the connection is protected using TLS or other
>    data confidentiality and data integrity protection.

This is too strong, since the implementation may not be aware that the
connection is secure.  E.g. that a "connection" to localhost is normally
not a network connection and cannot be snooped.  I suggest "SHOULD NOT
by default support...".

>    To mitigate the security risks associated with the transfer of
>    passwords, a server implementation that supports any password-based
>    authentication mechanism that transmits passwords in the clear MUST
>    support a policy mechanism that at the time of authentication or
>    password modification, requires:
>
>         A TLS layer has been successfully installed.

Or a SASL layer from a previous Bind.  That's covered by the next point,
but it might make sense to split this in 'LDAP-specified protection'
vs. 'other protection'.

>       OR
>       (...)

Non-modify operations should also be restricted, such as a client which
authenticates the user locally (instead of authenticating to LDAP) by
reading the hopefully encrypted password from LDAP and comparing it
locally.  (Kurt and I discussed some of this section a bit in thread
'authmeth: passwords in the clear', 27 Feb - 11 Mar 2004, but didn't
reach a clear conclusion.  I don't remember if it was discussed since.)

> 12.2. StartTLS Security Considerations

>    The level of security provided though the use of TLS depends
>    directly on both the quality of the TLS implementation used and the
>    style of usage of that implementation. Additionally, a man-in-the-
>    middle attacker can remove the StartTLS extended operation from the
>    supportedExtension attribute of the root DSE. Both parties SHOULD
>    independently ascertain and consent to the security level achieved
>    once TLS is established and before beginning use of the TLS
>    connection. For example, the security level of the TLS layer might
>    have been negotiated down to plaintext.

Should the example be an attacker might have caused the security level
to be negotiated down to plaintext?  (I don't know TLS that well.)

>    Implementers should be aware of and understand TLS security
>    considerations as discussed in the TLS specification [TLS].
>
> 12.3. Unauthenticated Mechanism Security Considerations
>
>    Operational experience shows that clients can (and frequently do)
>    misuse the unauthenticated authentication mechanism of simple bind
>    (see section 7).  For example, a client program might make a
>    decision to grant access to non-directory information on the basis
>    of completing a successful bind operation. LDAP server

s/completing a successful bind/successfully completing a bind/,
since referral is also sucessful.

>    implementations may return a success response to an unauthenticated
>    bind request thus leaving the client with the impression that the
>    server has successfully authenticated the identity represented by
>    the user name when in reality, an anonymous association has been
>    established.

Split up that sentence a bit.  E.g. comma before "thus" and move the
comma after "when in reality" in fron to that phrase.

> Appendix A. Association State Transition Tables

Maybe I should bring up again the suggestion to use named instead of
numbered actions and states, now that there are few enough of them to
give them sensible names.  E.g:

S1 -> Sanon, S2 -> Sauth, S3 -> Sinval (or Sinv if Sinval is too long),

A1 -> ABfail, A2 -> ABanon, A3 -> ABauth,
A4 -> ATfail, A5 -> ATprot, A6 -> ATunprot (any better name? ATundo?),
A7 -> Ainv(al).

> A.1. Association States

These states still contain an associated Authentication ID.  I'm
not sure if that's intentional or if they were missed when the
authentication ID was decoupled from association states elsewhere.

> A.2. Actions that Affect Association State

>    A6  Client or Server: graceful TLS layer removal

Or ciphersuite renegotiation, or maybe SASL "ciphersuite renegotiation"
too (but clarify that [SASL] itself specifies no no such thing).
Or maybe some of that should be a comment to A7, since TLS layer
removal is specified by the LDAP standard and the rest is not.

>    A7  Server decides to invalidate current association state

> A.3. Association State Transition Table

>    S1, the initial state for the state machine described in this table,
>    is the association state when an LDAP connection is initially
>    established.

That paragraph can be removed in favor of an action:
    A0 (or "Aconn")      Client connects to server
and a state transition:
    Action: A0 -> Section: S1; Comment: Section 4.1

>                         Next State
>         Action                                     Comment

Move "Next State" one line down.

>    ----------------  ---------------  -------------------------------
>    A6                no change or S3* [Protocol] section 4.14.3.1
>    A7                       S3

Comment: "Section 4.3"

>      * The server may invalidate the association after installing or
>        removing a TLS layer (section 3.2).

Or renegotiating.  Also I suggest s/may/may e.g./

> B.2. Access Control Factors

>    Access control policies are expressed in terms of access control
>    factors. E.g., a request having ACFs i,j,k can perform operation Y
>    on resource Z. The set of ACFs that a server makes available for
>    such expressions is implementation-specific.

I suggest quotes around "a request having ... resource Z"

> B.4. Authorization Identity

>    An authorization identity is one kind of access control factor. It
>    is the name of the user or other entity that requests that
>    operations be performed. Access control policies are often expressed
>    in terms of authorization identities; e.g., entity X can perform
>    operation Y on resource Z.

...and quotes around "entity X ... resource Z".

>    The authorization identity bound to an association is often exactly
>    the same as the authentication identity presented by the client, but
>    it may be different.

Nitpick: they won't have the same string representation with an LDAP DN
authentication ID and a SASL "dn:" authorization ID, since the the LDAP
DN does not contain the "dn:" part.  Though they can be representations
of the same abstract DN.  (Copied from memory from something Kurt said
in the sasl list:-)

>    The method by which a server composes and validates an
>    authorization identity from the authentication credentials supplied
>    by a client is performed in an implementation-specific manner.

Bad sentence.  Remove "performed in an" and "manner".

===

More updates of Kurt's 'authmeth review notes [long]' of 27 Feb 2004,
http://www.openldap.org/lists/ietf-ldapbis/200402/msg00083.html

> 1. Introduction

>   (3) Data integrity protection by means of security layers in TLS or
>       SASL mechanisms,

s/protection/service/ (use RFC2828 term)

>   (4) Data confidentiality protection by means of security layers in
>       TLS or SASL mechanisms,

s/protection/service/ (use RFC2828 term)

Also, this has arrived since then (inspired by Kurt's message):

> 12.1.1. Password-related Security Considerations

>        Some other data confidentiality mechanism that protects the
>        password value from snooping has been provided.

s/snooping/eavesdropping/ (use RFC2828 term)

-- 
Hallvard