Re: authmeth-09 comments

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

At 07:35 AM 1/3/2004, Hallvard B Furuseth wrote:
>authmeth-09 says:
>
>> 1. Introduction
>
>>    (6) Unauthorized or excessive use of resources (denial of service),
>>        and
>
>Remove 'or', and maybe 'unauthorized' as well.  Unauthorized use of
>resources need not be denial of service, and in any case I'm not
>sure if it's relevant whether the use of resources is unauthorized
>or not.

I think (6) should be the DoS threat, maybe worded:
        (6) Denial of Service: Use of resources (commonly in excess)
            in a manner intended to denial service to others. 

I think it might be wise to switch 2 and 3 since 1 and 3 are both
cases of unauthorized access to directory data and hence should
placed next to each other.

>>    (7) Spoofing of directory: Tricking a client into believing that
>>        information came from the directory when in fact it did not,
>>        either by modifying data in transit or misdirecting the client's
>>        connection. Also, tricking a client into sending privileged
>>        information to a hostile entity that appears to be the directory
>>        but is not.
>
>s/tricking a client/tricking a user or client/.  I believe tricking
>users is the worst problem of the two, or at least the one which is
>hardest to prevent.

We also should mention spoofing of a client to trick a server
into something.

And:
     (8)  Hijacking of protocol sessions.


>>    Threats (1), (4), (5) and (6) are due to hostile clients. Threats
>>    (2), (3) and (7) are due to hostile agents on the path between
>>    client and server or hostile agents posing as a server.
>
>I think it should be mentioned that threat (7) - and maybe (2) and
>(3)? - can also be in part due to IP spoofing.

I think we should also distinguish between between active and passive
attacks.

>>    LDAP can be protected with the following security mechanisms:

This is odd wording.  It is not the protocol that is being protected,
but the service.  This would be better worded:
        LDAP offers the following security mechanisms:

>>    (1) Client authentication by means of the Secure Authentication and
>>        Security Layer (SASL) [SASL] mechanism set
>
>...or LDAP's simple password mechanism...
>
>(or maybe you should just delete the part about SASL and just say
>'Client authentication'.)

I think this can be worded:
        1) Authentication by means of the Bind operation.  The Bind
        operation provides a simple method which supports anonymous,
        unauthenticated, and authenticated with password mechanisms,
       and the Secure Authentication and Security Layer (SASL) method
        which supports a wide variety of authentication mechanisms.
        The Bind operation may be extended to support additional
        methods of authentication.


>>    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 mechanisms like the LDAP
>>    simple bind using clear text passwords that provide inadequate
>>    security for most circumstances.
>
>Hey, don't hassle Simple Bind!  It's fine with TLS, and the best
>alternative for a lot of us.  I suggest:
>
>     or worse, they will support only clear text passwords that
>     provide inadequate security for most circumstances.

I'm fine with this rewording.


>> 3. Bind Operation
>
>>    The new LDAP association
>>    is established upon successful completion of the authentication
>>    exchange.
>
>Remove 'successful'.  A failed bind establishes a new association
>too.

I think we need to careful here...

Maybe something like:
   The Bind operation defined in section 4.2 of [Protocol] allows
   authentication information to be exchanged between the client and
   server to establish a new LDAP association.  Upon receipt of
   a Bind request, the LDAP association moved to an anonymous
   state and only upon successful completion of the authentication
   exchange (and the Bind operation) is the association moved to
   an authenticated state.

>> 3.3.3. Octet where negotiated security mechanisms take effect
>>
>>    When negotiated, SASL security layers take effect following the
>>    transmission by the server and reception by the client of the final
>
>...success...?

I think the "when negotiated" can be dropped.

>>    BindResponse in the exchange.
>
>> 4.1.3. TLS Version Negotiation
>>
>>    Negotiating the version of TLS or SSL to be used is a part of the
>>    [TLS] Handshake Protocol. Please refer to that document for details.
>
>SSL is not mentioned elsewhere in the document.  Either remove it,

yes.

>or explain.

no.

>Is SSL a TLS version now?

Unqualified, the terms generally refer to different versions of
the same protocol (or are used interchangeable).  They can be
qualified to refer to same version of the same protocol.

>> 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.
>
>As Kurt and I said in the thread about this, 'invalidating' the
>association belongs in a separate section, not a TLS-specific one.
>Also, the "MUST" above should be removed - there should simply be
>an explanation of how invalidated associations (normally?) behave.
>The same goes for invalidation after TLS closure below.

I concur.  This because strongAuthRequired means that the
server requires strong(er) authentication for THIS operation.
The client only needs to establish strong(er) association to
perform THIS operation.  The server may be willing to allow
a wide variety of other operations to proceeded.

>> 8. LDAP Association State Transition Tables
>
>The more I look at this section, the less I like it...  How about
>moving it to a non-normative appendix?  I *really* hope this section
>doesn't contain any information which must be read and can't be seen
>elsewhere in the draft.

I concur that these tables should be moved to an Informative
appendix (or section).  Implementators should not need to grok
these tables to properly implement the protocol.  The tables
should be informative, provided to help the implementor to
understand the prose.

>> 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
>>    offering equivalent or better protection.
>
>Previously I asked if this implied that implementations MUST NOT
>support weaker ciphersuites.  Kurt later mentioned use of null
>ciphersuites, so I don't think so.  Therefore, I assume 'offering
>equivalent or better protection' should be removed, though maybe you
>should add "SHOULD NOT support weaker ciphersuites unless other
>protection (such as a SASL security layer) is in place"?

I think the whole MAY should be dropped.  It should be obvious
that implementations are free to implement whatever additional
ciphersuites they choose (especially given the ciphersuite
recommendations in 9.1).

Kurt