Re: authmeth-09 comments

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

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.  Clients relate to specific identified servers,
but the reverse is not true.  Servers relate to authenticated users
and access control factors for the user and the connection.

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.

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

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,

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

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

>>> 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':-)

-- 
Hallvard