Re: authmeth-09 comments

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

At 02:34 PM 1/8/2004, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>>At 07:35 AM 1/3/2004, Hallvard B Furuseth wrote:
>>>authmeth-09 says:
>
>> We also should mention spoofing of a client to trick a server
>> into something.
>
>I don't understand.

Maybe just a terminology thing...

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

Replace each use of 'directory' above with 'client' and every use of
'client' with 'server', you get:

>>    (7) Spoofing of client: Tricking a server into believing that
>>        information came from the client when in fact it did not,
>>        either by modifying data in transit or misdirecting the server's
>>        connection. Also, tricking a server into sending privileged
>>        information to a hostile entity that appears to be the directory
>>        but is not.

The only bit of that seems a little odd to me is "misdirecting the
server's connection".  But just ignore that.

My point is that an attacker can, by modifying data in transit or
other means, trick the server into disclosing information
inappropriately.

>Clients relate to specific identified servers, but the reverse is not true.

Typically, maybe.  But note that the protocol model nor the
TCP mapping does not say that LDAP connections are always
client initiated.  It only says that clients are to support
initiation and server should support a listener.  There is
nothing that prevents a server (presumedly under some
agreement it has with the client) to initiate the connect
to the client.  I wouldn't be surprised to hear of implementation
and real-world use of this (considering mobile servers and
NAT/Firewalls issues).  (But I wasn't thinking of any particular
attack when I said this.)

>Servers relate to authenticated users and access control factors
>for the user and the connection.

Clients relate to 'authenticated services".  Both are "authenticated
entities" which can be spoofed.

>Those may include the DNS domain or IP address of the client, so we
>should mention that as a threat to servers as well as clients.  Is
>that what you mean?
>
>Or if you mean client certificates - I'm not sure if a server may
>refuse access to clients without known certificates, but stealing a
>certificate seems in any case no different from stealing a password
>to me.

I wasn't thinking of any particular attack when I said this.

>>         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.
>
>I think that's too long and too detailed for this section, which is
>just a summary.  It's already a problem that the draft keeps
>repeating itself.  No need to add to that.

Well, you could delete the last sentence or two.

>Now that I think of it, I think this is enough:
>
>       (1) Client authentication by various means, including a
>           simple password mechanism and the Secure Authentication
>           and Security Layer (SASL) [SASL] mechanism set, as well
>           as unauthenticated users,

I rather drop the "as well as unauthenticated users" phrase (which
actually is a problem in my suggestion as well) because we're
talking about means for establishing the client identity, not
means for establishing an anonymous association.

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

s/LDAP association moved/LDAP association is moved/


>Fine.  (It's not entirely correct, since successful Bind can move
>the association to an anonymous state too, but other parts of the
>draft deal with that.)

(Well, it's correct in the sense that the association is already
in an anonymous state upon receipt and hence the subsequent move
is moot.)

>>>> 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.
>
>So far, I find the prose far easier to track than the table, so my
>_real_ preference is for the table to be deleted.  Roger didn't
>dignify that suggestion with a reply when he replied to the message
>suggesting that, though...  OTOH, nobody spoke up and said 'yes, I
>find the table useful':-)

I believe some find the table useful.  Personally, I worry that the
table might not accurately reflect the prose.  (As co-chair, I'm
concerned by the lack of attention the tables are getting.)

Kurt