Re: authmeth-12 review notes

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 08:25 AM 9/27/2004, Hallvard B Furuseth wrote:
>Authmeth-12 review notes follow.  I'm splitting some subjects out to
>separate threads.

I tried to only respond here to those subjects which weren't split out.

>A number of the issues are copied (and sometimes
>modified a bit) from earlier review notes which as far as I can remember
>have not received responses; I don't know if they have been forgotten or
>rejected.  In the latter case, I'd like to know that, and except for
>minor matters why.  Or if I'm the one who has forgotten what happened
>with some of them, feel free to jump on me.
>
>> 1. Introduction
>
>>    LDAP offers the following security mechanisms:
>
>>    (3) Data integrity protection by means of TLS or SASL mechanisms
>>        with security layers that provide data integrity protection,
>>
>>    (4) Data confidentiality protection by means of the TLS protocol or
>>        SASL mechanisms that provide data confidentiality protection,
>
>These seem a bit redundant.  How about
>
>     (3) Data integrity protection by means of security layers in TLS or
>         SASL mechanisms,
>
>     (4) Data confidentiality protection which the TLS protocol and
>         SASL mechanisms can provide,

I would that these be worded symmetrically.  That is, replace
your (4) with:
        (4) Data confidentiality protection by means of security
        layer in TLS and SASL mechanisms,

>Except, the rest of the draft says just "confidentiality protection",
>not "data confidentiality protection".

The latter should generally be used.


>>    It seems clear that allowing implementations, faced with the above
>>    requirements, to simply pick and choose among the possible
>>    alternatives is not a strategy that is likely to lead to
>>    interoperability. In the absence of mandates, clients will be
>>    written that do not support any security function supported by the
>>    server, or worse, they will support only clear text passwords that
>>    provide inadequate security for most circumstances.
>
>Implementations have had these choices for a while now.  Can we replace
>"It seems clear" ... "[not] likely to lead to interoperability" ...
>"clients will be written" with statements that this DID happen?
>
>The end of the next paragraph also gives me a vague "we are working on
>this"-feeling rather than "we have done this":
>
>>    it is desirable to ensure secure interopability
>>    by indentifying a mandatory-to-implement mechanism for establishing
>>    transport-layer security services.
>
>The start of the following sentence is not right; there are exceptions:
>
>>    Because
>>    these authentication mechanisms transmit credentials in plain text
>>    form and other authentication mechanisms do not provide data
>>    security services,
>
>I suggest:
>replace "Because these" with "Because many", (or several, some, ...?)
>replace "and other authentication mechanisms" with "and/or".
>
>> 1.2.1. Glossary of Terms
>
>>      - "connection" and "LDAP connection" both refer to the underlying
>>        transport protocol connection between two protocol peers.
>>
>>      - "TLS connection" refers to an LDAP connection with TLS
>>        protection [TLS].
>>
>>      - "association" and "LDAP association" both refer to the
>>        association of the LDAP connection and its current
>>        authentication and authorization state.
>
>Switch to new [Protocol] terminology: "connection", "TLS-protected
>LDAP exchange", "association" (not "LDAP association").
>
>Though maybe the latter should get a bit more explanation in Authmeth:
>
>("I.e. the client's current authentication and authorization identity"
>-- and possibly other factors such as strength of bind method etc.?)
>
>> 2. Implementation Requirements
>
>>    Implementations MAY support additional mechanisms of the simple and
>>    SASL bind choices.  Some of these mechanisms are discussed below.
>
>I would replace "additional mechanisms of the simple and SASL bind
>choices" with "additional authentication mechanisms".
>
>> 3.1.4. Client Certificate
>
>>    In an LDAP server requests a client to provide its certificate
>>    during TLS negotiation and the client does not present a suitablle
>>    certifcate (e.g. one that can be validated), the server MAY use a
>>    local security policy to determine whether to successfully complete
>>    TLS negotiation.
>
>s/MAY/may/?

Yes.

> What else than local security policy could the server use?
>I guess the alternative is an implementation-specific setting; but I
>would hope such a setting would just be a default - and using a default
>would be a local security policy:-)

 From a technical specification point of view, there is no
clear distinction between "local security policy" and
"implementation-specific setting" and rightly so.

>> 3.1.5. Discovery of Resultant Security Level
>
>>    After a TLS connection is established on an LDAP connection, both
>>    parties must individually decide whether or not to continue based on
>>    the security level achieved.
>
>s/must/MUST/?

Would be better to s/must/are to/ IMO.


>> 4.3. Invalidated Associations
>
>>    While the
>>    association is invalidated, the server may reject any operation
>>    request other than Bind, Unbind, and StartTLS by responding with a
>>    resultCode of strongAuthRequired

I think this text is a bit misleading as it kind of implies
that only while the association is invalid this code may
be returned.

I also think this text is a bit too perspective.

The point is that the server is free to change the association
at its will.  How the server behaves in response to future
operations depends on the association in place at that
time.  The client has, in general, treat responses as indicative
only of the requested operation's outcome and not necessarily
indicative of what it needs to do before submitting some
other operation.

strongAuthRequired means simply that the server is requires
strong(er) authentication to perform the request operation.

>Thus ensuring that "strong"AuthRequired is totally misnamed, since even
>anonymous bind fixes this condition.

Not sure why a server would return strongAuthRequired for
a request then subsequently perform that operation under
an anonymous association.

We need to be clear that result codes are indications of
the outcome of a request and requests are generally independent
of each other.

>I think that needs to be noted
>either in [Authmeth] or [Protocol].

I wouldn't object to renaming the strongAuthRequired result
code to be strongerAuthRequired code.   Don't think [protocol]
needs to enumerate all the instances in which a server might
choose to return this code, but instead be clear on what
that code means (strong(er) authentication is required).
I think [Protocol] does that already.

Again: less prescriptive, more descriptive.


>>    This behavior is
>>    explained here to help client implementers properly understand and
>>    react to this situation.

This is quite problematic.  LDAP requests are generally
independent of each other and result codes are generally
not indicative of what the client should do.  A result
code is indicative of the reason why the server was
unwilling or unable to perform the requested operation.

>Also, I suggest to add:
>
>     Note that the server may in any case choose to return
>     strongAuthRequired at nearly any time.  The above behavior
>     is spelled out because it often makes sense and is simple for
>     users [or "simple for clients"?] to understand.
>
>Or explicitly say the opposite, if that has been decided.  I seem to
>remember a mention that someone disliked that the server could do this,
>but I cannot find that now.
>
>> 5. Bind Operation
>
>>    If the authorization identity is not
>>    specified, the server derives it from the authentication identity in
>>    an implementation-specific manner.
>
>Should this and "implementation-specific" in B.4 (Authorization
>Identity) be "implementation-specific and/or according to local policy"?

No.  Whether or not local policy matters, and if so, how,
is itself implementation-specific.


>> 8. Simple Authentication Mechanism of Simple Bind
>
>>    Servers that map the DN sent in the bind request to a directory
>>    entry with an associated set of one or more passwords
>
>Maybe add "which can be used with this authentication mechanism" since
>an entry could contain several password representations of different
>types, where each mechanism can only use some of the types.

I think adding that would border being overly precise
in what is intended to be statement of how servers
typical behave.  Servers, historically and in this
specification, have lots of freedom here.  I think
many of these issues could be better addressed by
clearly stating the minimal steps a server undertakes,
providing an overview of a typical implementation,
note some of the many ways implementations may differ
from the typical.

>>    , will compare
>>    the presented password to the set of passwords associated with that
>>    entry. The presented password is considered valid if it matches any
>>    member of this set.
>>
>>    If the DN is not valid, or the password is not valid for the DN, or
>>    the server otherwise considers the credentials to be invalid, the
>>    server is to return the invalidCredentials result code.  The server
>>    is only to return success result code when the credentials are valid
>>    and the server is willing to provide service to the entity these
>>    credentials identify.
>
>These two paragraphs mostly apply to other authentication mechanisms
>too; though they would need to be generalized - some mechanisms do not
>use a DN, others do not use a password, and some only work if there is
>exactly one password which that mechanism can use.

Other mechanisms are not LDAP-specific and are, in fact,
specified elsewhere.  This mechanism needs to adequately
specified here, using LDAP-specific terms as appropriate.

>I don't remember if I'm trying to resurrect a dead horse with the two
>above comments; if so do tell me to leave it dead.
>
>>    Server behavior is undefined for Bind requests with a zero-length
>>    name value and specifying the simple authentication choice with a
>>    value of non-zero length.
>
>Is this totally undefined,

I think the above meant to say that the request had
no defined meaning.

Personally, I think it would be better to define such
requests as being invalid and require servers to
fail such requests with an appropriate result code.

>in that it may succeed but do something else
>than what the simple authentication mechanism does?  If so, it is not
>that mechanism and does not belong in this section, but in section 5.1;
>and the Simple Authentication Mechanism should be redefined to be
>specified by a non-empty DN and a non-empty password.  That would
>require updates other places too, at least in the Security
>Considerations section which refers to this mechanism.
>
>If it is only undefined whether or not it succeeds as the Simple
>Authentication Mechanism, that should be clarified here.
>
>>    LDAP implementations MUST be
>>    capable of protecting it by establish::qment of TLS (as discussed in
>>    section 3) or other suitable data confidentiality and data integrity
>>    protection(e.g. IPSec).
>
>Maybe this should be turned around, since the section is about Bind and
>not TLS:
>
>     LDAP implementations SHALL NOT support this mechanism unless they
>     can protect it by TLS.
>
>(I removed "or other..."; see my 'TLS issues' message.)

(See my "TLS issues" response)


>> 10. SASL EXTERNAL Mechanism
>> 11. SASL DIGEST-MD5 Mechanism
>
>I suggest s/Mechanism/Authentication Mechanism/ in these titles.
>
>> 12.1. General LDAP Security Considerations
>
>>    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.
>
>OpenLDAP returns adminLimitExceeded in some cases - e.g. if too many
>entries are left to check after the indexes have been used.  That seems
>reasonable to me, though I'm not sure what adminLimitExceeded originally
>means (in X.500).
>
>> 12.2. StartTLS Security Considerations
>
>>    The goals of using the TLS [TLS] protocol with LDAP are to ensure
>>    connection confidentiality and integrity, and to optionally provide
>>    for authentication. TLS expressly provides these capabilities
>>    (although the authentication services of TLS are available to LDAP
>>    only in combination with the SASL EXTERNAL authentication method,
>>    and then only if the SASL EXTERNAL implementation chooses to make
>>    use of the TLS credentials).
>
>That does not look like a security consideration to me.
>
>>     Clients SHOULD either warn the user when the security level
>>    achieved does not provide data confidentiality and/or integrity
>>    protection, or be configurable to refuse to proceed without an
>>    acceptable level of security.
>
>I think this implies the wrong default.  I suggest s/SHOULD/SHOULD by
>default/, and they may then be configurable to be _willing_ to proceed
>anyway.
>
>However, that 'acceptable level' is a moving target.  Maybe this should
>be added somewhere (not under StartTLS):
>
>   Unfortunately, old implementations are (at least by default) likely
>   to consider poor security acceptable, since new attacks are regularly
>   being discovered and increasing computing power makes more attacks
>   practical.
>
>>    Server implementors SHOULD allow server administrators to elect
>>    whether and when data confidentiality and integrity are required, as
>>    well as elect whether TLS authentication of the client is required.
>
>"TLS authentication" = "demand a client certificate which the server can
>verify", not "demand SASL/EXTERNAL afterwards"?
>
>I asked for clarification, and I notice the wording has changed in that
>direction, but I don't know if that was in response to my request.  I
>would prefer more clearer words that "authentication" does not refer to
>LDAP authentication (even to someone who has not read [TLS]), but if
>others feel that the current wording is sufficient, that's OK.
>
>> 12.3. Unauthenticated Mechanism Security Considerations
>
>>    LDAP server
>>    implementations will return a success response to an unauthenticated
>>    bind request
>
>s/LDAP server implementations will/LDAP servers may/.
>
>> 13. IANA Considerations
>>
>>    The following IANA considerations apply to this document:
>>
>>    Please update the GSSAPI service name registry to point
>
>"ldap"
>
>>    to [Roadmap]
>>    and this document.
>
>> A.2. Actions that Affect LDAP Association State
>
>>    A2  Client successfully performs anonymous simple bind
>>    A3  Client successfully performs unauthenticated simple bind
>
>I would merge these.  I previously suggested to also merge
>SASL/ANONYMOUS, but if I remember correctly from the sasl list, that's
>not anonymous in LDAP sense after all.
>
>> A.4. LDAP Association State Transition Table
>
>>    S1, the initial state for the state machine described in this table,
>>    is the authentication state when an LDAP connection is initially
>>    established.
>
>Actually you could make that a separate action A0: "Connecting to the
>LDAP server".
>
>BTW, I noted previously that it would be easier to read the table if the
>actions and/or states have names rather than numbers.  It's less
>important now that the table is so much smaller, but it would still be
>nice.
>
>> Appendix B. Authentication and Authorization Concepts
>
>Maybe "Data integrity protection" and "Confidentiality protection"
>should also be explained?  (And the section would be renamed.)
>
>> B.2. Access Control Factors
>>
>>    They might include
>
>the association's authorization identity,
>
>(That was actually not obvious to me at first; I wondered if ACFs were
>more magical than that:-)
>
>>    source IP address, encryption strength,
>>    (...)
>
>========
>
>Editorial comments:
>
>> 1. Introduction
>
>s/indentifying/identifying/.
>
>> 1.2.2. Security Terms and Concepts
>> 3.2. Effects of TLS on a Client's Authorization Identity
>
>"Appendix C" should be "Appendix B".
>
>
>> 3.1.4. Client Certificate
>
>s/suitablle/suitable/.
>s/certifcate/certificate/.
>s/external/EXTERNAL/.
>
>> 3.2.1. TLS Connection Establishment Effects
>
>>    The decision to keep or invalidate the established LDAP association
>>    (section 12) after TLS connection establishment is a matter of local
>>    server policy.
>
>s/section 12/section 4.3/.
>
>> 3.2.2. Client Assertion of Authorization Identity
>
>>    specifying a SASL mechanism of EXTERNAL [SASL] (section 9).
>
>s/section 9/section 10/.
>
>> 5.1. Simple Authentication Choice
>
>>     3. a simple authentication mechanism using credentials consisting
>>        of a name (in the form of an LDAP distinguished name [LDAPDN])
>>        and a password (section X).
>
>I don't think that's the right section:-)
>
>> 7. Unauthenticated Authentication Mechanism of Simple Bind
>
>>    Unauthenticated binds can have significant security issues (see
>>    section 14).
>
>Section 12.3.  And maybe s/./:/.
>
>> 8. Simple Authentication Mechanism of Simple Bind
>
>>    capable of protecting it by establish::qment of TLS (as discussed in
>Garbage:                         ^^^^^^^^^^^^^^^^
>
>>    LDAP implementations
>>    SHOULD support authentication with the "simple" authentication
>>    choice when the connection is protected against eavesdropping using
>>    TLS, as defined in section 4.
>
>Section 3.
>
>> 9.1. SASL Service Name for LDAP
>
>>    The SASL service name for LDAP is "ldap", which has been registered
>>    with the IANA as a GSSAPI service name.
>
>Add a reference to the definition of "GSSAPI"?
>
>> 10.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 octet string. This
>>    string MUST be constructed as documented in section 3.4.1.
>
>Section 10.4.
>
>> 10.4. SASL Authorization Identity Syntax
>
>>    authzId = dnAuthzId / uAuthzId
>
>Use '::=' instead of '=', like the other ldapbis drafts.
>
>>    DNCOLON  = %x64 %x6e %x3a ; "dn:"
>>    UCOLON = %x75 %x3a ; "u:"
>
>I would put these at the end of the grammar, so all definitions are
>found below their use.
>
>> 12.1.1.Password-related Security Considerations
>
>Missing space after "12.1.1.".
>
>> 12.2. StartTLS Security Considerations
>
>>     Clients SHOULD either warn the user when the security level
>>    achieved does not provide data confidentiality and/or integrity
>
>Unindent "Clients".
>
>> 12.4. Simple Mechanism Security Considerations
>>
>>    The simple authentication mechanism of simple bind discloses the
>>    password to
>
>the
>
>>    server,
>
>> 12.5. SASL DIGEST-MD5 Mechanism Security Considerations
>>
>>    The SASL DIGEST-MD5 mechanism is prone to the qop substitution
>>    attack, as discussed in 6.2 of RFC 2831.  The qop substitution
>>    attack can be mitigated (as discussed in 6.2 of RFC 2831).
>
>RFC 2831 Section 6 is "Authors' Addresses".  Besides, I would think RFC
>2831 should be [DIGEST-MD5] which will replace it, but its section 6 is
>also "Authors' Addresses".
>
>> 12.6. Related Security Considerations
>
>Missing newline after header.
>
>> Normative References
>
>>    [StringPrep]         M. Blanchet, "Preparation of Internationalized
>
>Unindent description.
>
>> Appendix A. LDAP Association State Transition Tables
>>
>>    This section provides a state transition table to represent a state
>>    diagram for the various authentication and TLS states
>
>There are no TLS states in the table now.
>
>> A.2. Actions that Affect LDAP Association State
>
>Remove spurious "]"s in actions A5 and A6.
>
>> A.4. LDAP Association State Transition Table
>
>>    Action   State  Comment
>>    -------  -----  -------------------------------------------------
>
>If you expand the "Action" field, you can put things like
>"A6, D1 or D2 = no" and "A6, D1 = D2 = yes" on a single line.
>
>>    A8         no   [Protocol] section 4.14.2.1
>>              change
>
>I suggest to call that A8 "no change[*]" and add
>
>[*] The server may invalidated the association after TLS
>    establishment/closure; section 3.2.
>
>> F.8. Changes for draft-ldapbis-authmeth-09
>
>>      - Reworded sentence beginning, "It is also desirable to allow
>>        authentication methods to carry identities based on existingù
>>        non-LDAP DN-forms..."
>
>s/ù//.  8-bit character.
>
>-- 
>Hallvard