Applicability (Was: authmeth review notes [long])

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

At 10:09 AM 3/9/2004, Hallvard B Furuseth wrote:
>> I would like to add a new section (or possible placed subsequent
>> to the technical specification of these features) which gathers the
>> high level implementation requirements.
>
>Good idea, if you mean to move the requirements to this section,
>rather than to copy them.

The idea is to provide a brief general "applicability statement"
which details which security services are required, recommended,
or elective (but not detailing how those services are to be
implemented).  That is, it details the what should be implemented,
not the how they should be implemented.

It might be best to title the section "General Applicability Statement"

>However, you have made many changes:

Yes.  authmeth-10, I believe, is not fully consistent with the WG
consensus as previously gauged.  Hence, the changes.

>> 2.  Implementation Requirements
>
>>  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.

>Also, the original text from Section 10 (quoted below) seems clear
>enough to me, I don't see why you spelled it out more than this?
>
>   LDAP servers that implement any authentication method or mechanism 
>   other than simple anonymous bind MUST implement the SASL 
>   DIGEST-MD5 mechanism [DIGEST-MD5].

I have tried to be more precise regarding Bind methods and
authentication mechanisms.  Each Bind method can support multiple
mechanisms.  I hope that we can carry this precision into
the rest of the specification.

>(Well, I liked your s/method or mechanism/mechanism/, and I'd suggest
>s/DIGEST-MD5 mechanism/DIGEST-MD5 authentication mechanism/ if that
>text is moved the new section.)

I actually had in a rough draft written "authentication mechanism"
in the second sentence.  I removed it because, without it, it should
be clear I'm referring to mechanisms of the first sentence but
with it, it **could** be viewed as referring to only the authentication
aspects of the DIGEST-MD5 mechanism.  (English is a fun language.)

However, I'm fine either way.  Just wanted to let you know that I
had considered that wording and why I opted for this instead.

>>  That is, excepting those
>>  implementations which only support anonymous connections, all
>>  implementations MUST support DIGEST-MD5.
>
>Strike this, it is clear enough from the first sentence.

We've had a bit of confusion here, I added this statement to
really drive it home.  That is, while I agree that the first
sentence should be clear enough, it seems some are having a
hard time understanding its meaning.  So I think reenforcement
here is good.

>Though we
>could rearrange that sentence a bit to emphasize the DIGEST-MD5
>requirement, if we keep your spelled-out version:
>
>   LDAP {servers/implementations} MUST support the DIGEST-MD5
>   [DIGEST-MD5] mechanism of the SASL Bind method (as detailed in
>   Section X) if they support any authentication mechanism other than
>   the anonymous mechanism of the Simple Bind method.

I prefer my wording.  It avoids the "if ... other than" construction
(which I think was causing some of the confusion).

>>  LDAP implementations SHOULD support the simple DN/password mechanism
>>  of the simple Bind method (as detailed in Section X).  Implementations
>>  which support this mechanism MUST be capable of protecting it by
>>  establishment (as discussed in Section 3) of TLS.
>
>This has several differences from the requirements in Section 7.  I seem
>to remember there have been previous discussions about just what bind
>methods should be supported when.  I don't think this should be changed
>without more discussion.

Actually, I think we've discussed this in gory detail repeatedly.
While I put forth this text as what I believe the consensus to be,
wether or not the text actually does reflects consensus is certain
a matter for discussion.  That is, the chairs have declared consensus
in a number of related issues here, but have not yet declared the
text as being consistent with that consensus.  It is hoped we can
fine tune the text without having to reopen previously hashed issues.

>E.g., I disagree with the TLS requirement.

I think it would be fine to extend this with something like:
"or other suitable means (e.g., IPSec)".

>Other protection, like IPSec, ldap://localhost/, or a Unix filename
>socket, is fine.

I assume you meant ldaps://.


>Also note section H.45:
>
>   Based on WG list discussion, Kurt Zeilenga has gaged a lack of WG 
>   consensus that Simple+TLS should be mandatory to implement. No 
>   further discussion is necessary. 

Simple+TLS is not mandatory to implement.  But if you implement
Simple, you must implement a means to protect Simple.  This comes
from concerns raised at IETF#58 (and, if I recall correctly, on list).

>BTW, I can't find any requirement that TLS be supported.

It's not.  DIGEST-MD5 is LDAP's strong authentication mechanism
(which provides adequate data security services).  There is no
interop or security reason to mandate or recommend more (except
in limited cases, such as when Simple is to be used).

>>  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.  But because a client might attempt discovery
and hence might anonymously bind first, servers need to be capable
of supporting this (even though the only thing they might allow
an anonymous client to do is discovery).

>BTW, MUST they support unauthenticated binds?

I believe consensus is that the unauthenticated mechanism of the simple
method is elective, but those implementations which do support this
mechanism should, by default, have it disabled (e.g., reject such
requests).

I didn't enumerate elective mechanisms... nor attempt to discuss how
any mechanism should be implemented.

>Section 6 says those
>SHOULD by default be rejected; I'm not sure if that means it MUST be
>possible to turn the default off.
>
>>  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.