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

From: "Roger Harrison" <[email-masked]>
Date: Thu, 10 Jun 2004 15:34:06 -0600

I've reviewed your fairly lengthy debate on this subject and have made
the following adjustments to the next draft of authmeth:
 
1. I have decided to explicitly call out mechanism names. Although they
are a bit long, the names I've decided on (for consistency with the
protocol definition) are: Anonymous Authentication Mechanism of the
Simple Bind Choice, Unauthenticated Authentication Mechanism of the
Simple Bind Choice, and Simple Authentication Mechanism of the Simple
Bind Choice.  Each has its own section with parallel language regarding
the way the mechanism is used.
 
2. I will use parallel terminology for SASL mechanisms.
 
3. I have clarified that implementations supporting the Simple
Authentication Mechanism of the Simple Bind Choice MUST be *capable* of
protecting it via TLS or other suitable data confidentiality and data
integrity services (e.g. IPSec).
 
4. Other minor modifications needed to support the main issues above.
 
I'm probably still a day or two away from submitting the next draft of
authmeth, so if you have violent disagreements to any of this stuff, you
can probably catch me in time to make changes prior to publication if
you don't delay.
 
Thanks,
 
Roger

>>> "Kurt D. Zeilenga" <[email-masked]> 3/9/2004 6:03:27 PM >>>
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

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 11 Jun 2004 11:06:00 +0200

> the way the mechanism is used.

Whoops, I'd forgotten that debate.  Decided to sleep on some attempted
improvements which I wasn't satisfied with, and 'slept' too long.

I'm undecided about whether expanding the Bind terms is better than
defining shorter terms.  Fewer definitions to keep track of make it
easier to read the standard, but OTOH the above terms are too long for
everyday use, so people are going to abbreviate them anyway.  With
expanded names as above, preferably the mechanism names should at least
lend themselves to abbreviations that remain reasonably unambiguous.  If
I could just come up with an alternative for 'anonymous' bind which
can't be misunderstood to include 'unauthenticated':-( 'Unnamed' or
'nameless' are my best so far, but sound a bit strange to me.

Could the above terms at least be shortened a little, like
'xxx Authentication Mechanism of the Simple Bind Choice'
-> 'xxx mechanism of Simple Bind'?

Anyway: I dislike the 'anonymous' vs. 'unauthenticated' terminology,
with or without the above verbosity.  The two words keep getting
confused.  With good reason:

The 'unauthenticated' mechanism, spelled out or not, produces an
'anonymous' association.  OTOH, an LDAP 'anonymous' (neither DN nor
password) bind or 'anonymous' association can in non-LDAP terms be said
to be 'unauthenticated'.

Indeed, when I googled for 'unauthenticated bind', I found just as many
texts which meant one of the variants of 'anonymous'.  And a lot of
texts where I couldn't tell if they got it right or not.
And of course, some 'anonymous' binds out there mean both variants,
while others mean neither DN nor password.

It would be preferable if the binds that produce 'anonymous'
associations were the same binds that are called something with
'anonymous'.  However, that fits neither 'unauthenticated' simple binds
nor the SASL/ANONYMOUS mechanism.  So I think 'anonymous associations'
should be renamed, but I can't come up with a suggestion.  Still, it's a
new term, and thus should be easier to kill off than the established
Bind terms.

'Unauthenticated' binds could be renamed to e.g. 'informative' or
'informational' simple bind (possible expanded as Roger does above),
with a note that it was previously called 'unauthenticated' and this
caused confusion.

-- 
Hallvard