[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Applicability (Was: authmeth review notes [long])
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, 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:
>> 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 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.
>>>>> 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'.
> Maybe we should just s/MAY/may/ (or s/MAY/can/) here.
Also an improvement over your original text.
> 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?
>>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. Otherwise I still don't see the
difference between clients that don't need DIGEST-MD5 and clients that
don't need discovery (below). 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.
> 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