Re: Applicability (Was: authmeth review notes [long])

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

At 04:31 PM 3/9/2004, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>>At 01:23 PM 3/9/2004, Hallvard B Furuseth wrote:
>
>>>>> BTW, MUST they support unauthenticated binds?
>>>>
>>>> I believe consensus is that the unauthenticated mechanism of the simple
>>>> method is elective, (...)
>>>
>>>Then this is wrong:
>>>
>>> LDAP server implementations MUST support the anonymous mechanism of
>>> the simple Bind method.
>> 
>> No, that's talking about the anonymous mechanism, not the
>> unauthenticated mechanism.
>> 
>> Simple bind support three mechanisms: anonymous, unauthenticated,
>> and authenticated.  While the first two both result in an anonymous
>> associations, they are different mechanisms.
>
>Oh.  The problem is, the 'anonymous mechanism' of Simple Bind isn't
>defined anywhere,

It should be.  We need to be distinguish this mechanism from
other simple mechanisms and well as other mechanisms whose
purpose is to establish an anonymous association.

>so it can be read eather as your definition or as
>anonymous binds.  I see no reason to define it either, just to be able
>to use it here.  So I suggest again:

We need to precise in this area as we have different requirements
for different mechanisms.

>>> It should be 'support anonymous binds with...' (according to section 6),
>>> or 'anonymous authentication via the simple Bind method with no name or
>>> password'.
>
>Also, this text from your suggestion must be fixed in the same way:
>
>  LDAP implementations which support any authentication mechanism
>  (other than anonymous mechanism of the simple Bind method) MUST
>  support the DIGEST-MD5 (...)

I think it better to precisely define the "anonymous mechanism of
the simple Bind method".

>> I think we just need to be more precise when it comes to
>> distinguishing mechanisms from outcomes.  One could say
>> that the use of SASL/ANONYMOUS mechanism is an "anonymous
>> bind".  But it is a different mechanism from the simple
>> method's anonymous mechanism.
>
>My suggested texts do refer to anonymous simple bind, so they exclude
>SASL/ANONYMOUS.

Yes, but my point "anonymous simple bind" as you just used it
is ambiguous.  It could mean binding with the anonymous
mechanism of the simple method or binding with the unauthenticated
mechanism of the simple method.  I think the term "anonymous
simple bind" should be avoid.  We should, depending on the
circumstances, either talk in terms of what kinds of associations
will/have been established, or in terms the particular
mechanisms to used in establishing the association.


>>>>>>  Implementations MAY support additional authentication mechanisms of
>>>>>>  the simple and SASL bind methods, and/or mechanisms of other bind
>>>>>>  methods.  Some of these mechanisms are discussed below.
>>>>>
>>>>> I think this paragraph can be dropped.
>>>>
>>>> I think it is important to say that other mechanisms are elective.
>>>
>>>If you mean _all_ other mechanisms, the paragraph doesn't say that.
>>>It just says there are elective mechanisms.  But I agree such a statement
>>>would be nice.  As well as a similar statement for basic TLS features.
>> 
>> I rather not say _all_ other mechanisms, as some mechanisms have
>> very limited applicability (and some other mechanisms may actually
>> be deprecated (for very good reasons)).  So, I guess, it may be best
>> not to actually say other mechanisms are elective.
>
>This should cover both needs: 'Of the mechanisms defined in this
>document, only the above mechanisms are mandatory'.

I don't believe all the mechanisms "above" are mandatory.

>> Maybe we should just s/MAY/may/ (or s/MAY/can/) here.
>
>Also an improvement over your original text.

Okay.


>> It might be appropriate
>> to note that implementors considering supporting additional mechanisms
>> should carefully consider their applicability to LDAP and directory
>> applications they intend to support.
>
>I don't understand.  Are you talking about a security consideration, or
>something else?  Why and how would they consider it?

Applicability of a mechanism certain encompasses security
considerations, but can also encompass other factors.
Note that I use the term applicability in the RFC 2026 sense.

>>>These seem inconsistent to me:
>>>
>>>>>>  LDAP implementations which support any authentication mechanism
>>>>>>  (other than anonymous mechanism of the simple Bind method) MUST
>>>>>>  support the DIGEST-MD5 [RFC2831bis] mechanism of the SASL Bind
>>>>>>  method (as detailed in Section X).
>>>>>
>>>>> I preferred the authmeth-10 text which only required this of servers,
>>>>> not "implementations".  It should be OK to write thin clients.
>>>>
>>>> I believe similar concerns were previously discussed.  I believe
>>>> consensus supports the requirement as applying to both clients and
>>>> servers.
>>>
>>>Above, clients that do not use DIGEST-MD5 must support it anyway.
>>>Below, clients that do not use simple/anon need not support it.
>> 
>> Because the requirements address different concerns.
>> 
>> The former requirement is to ensure that all implementations
>> share a strong authentication mechanism.
>
>If this is to satisfy some formal IETF requirement that they must share
>such a mechanism, I'm with you.

There is a requirement for all IETF protocols to have a reasonable
strong authentication mechanism.  (I forget where it is formalized.)

> Otherwise I still don't see the
>difference between clients that don't need DIGEST-MD5 and clients that
>don't need discovery (below).

Maybe someone else can take a stab at explaining the difference
better than I.

>Also, that all implementations 'share'
>DIGEST-MD5 doesn't mean that one can bind with DIGEST-MD5 to all servers
>supporting it, for the reasons I meantioned before about DIGEST-MD5.

Assuming you are referring to interoperability issues
(as opposed to local policy/configuration issues), please
drop me a note with a quick summary of the reasons and
pointers to past discussions.

(I have some interoperability concerns with DIGEST-MD5,
especially with layers.  I intend to do a quick interop
study in this area in the next few weeks to ensure we
have (or likely will have) multiple independently developed
implementations of DIGEST-MD5 (including layers).)


>> The latter requirement is to ensure that all servers provide
>> adequate support for discovery.  Clients are not generally
>> required to use discovery (or use simple/anon with discovery),
>> but servers are generally required to support discovery (if
>> so configured).
>> 
>>>>>>  LDAP server implementations MUST support the anonymous mechanism of
>>>>>>  the simple Bind method.
>>>>>
>>>>> You changed this from "implementations" to "server implementations".
>>>>> I guess I agree with that.
>>>>
>>>> This is because servers need to support various initial operation
>>>> sequences discussed in [Protocol].  However, clients need not support
>>>> all of these.  For instance, a client is free to initially request
>>>> DIGEST-MD5 authentication.  Such a client need not support the
>>>> anonymous mechanism.  (...)
>
>-- 
>Hallvard