Re: authmeth review notes [long]

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

Kurt D. Zeilenga writes:
>> 1. Introduction
>> (...)
>>    LDAP offers the following security mechanisms:
>>
>>    (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 and which
>>        may be extended to support additional methods of authentication.
>
> s/./,/
> s/and which...//  (no need to discuss extensibility here)

Whoops, I seem to have lost the thread I started about this with my
earlier review notes.  ('authmeth-09 comments', ended by Kurt's message
<http://www.openldap.org/lists/ietf-ldapbis/200401/msg00073.html>.)

I do not think this list should talk about LDAP operations like Bind.
It should talk about features which LDAP makes use of, such as passwords
and SASL.  That's why I suggested

  (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,

Kurt replied,

  I rather drop the "as well as unauthenticated users" phrase (which
  actually is a problem in my suggestion as well) because we're talking
  about means for establishing the client identity, not means for
  establishing an anonymous association.

I'm fine with that (and maybe s/client//).  Kurt, I'm not sure if you
feel that argument still applies to the current [Authmeth] text, or if
my text - if it is used - should be expanded to mention anonymous and
unauthenticated associations?

>>    (2) Client authorization by means of access control based on the
>>        requestor's authenticated identity,
>
> Given that LDAP doesn't offer an authorization (access control)
> model, this seems dubious (even with the note below).  However, I
> don't have a suggestion (at the moment) on how to better address
> this.

Put "Servers are expected to support" in front of the sentence?

>>    Given the presence of the Directory, there is a strong desire to see
>>    mechanisms where identities take the form of an LDAP distinguished
>>    name [LDAPDN] and authentication data can be stored in the
>>    directory.
>
> s/see/use/
> s/take the form of an LDAP distinguished name/
> s/are represented as distinguished names [X.501][Models] in string
> form [LDAPDN]/.

>>                This means that this data must be updated outside the
>>    protocol or only updated in sessions well protected against
>>    snooping.
>
> s/snooping/eavesdropping/ (use RFC2828 term)

This sentence has nothing to do with DN identities and authentication
data in the directory.  It also applies if the server supports an
extended operation to modify passwords stored outside the directory,
with non-DN identities.  I think it belongs in Section 11 - unless
Section 11 is modified to only talk about authentication, like Kurt
suggested in thread 'authmeth: passwords in the clear', message
<http://www.openldap.org/lists/ietf-ldapbis/200402/msg00086.html>:-)
Also, it applies to any sensitive data, not just authentication data.
So I'm not sure that it is any need to mention this special case at all.

>>                It is also desirable to allow authentication methods to
>>    carry identities not represented as LDAP DNs that are familiar to
>>    the user or that are used in other systems.
>
> suggest:
> 	It is also desirable to allow authentication methods to
> 	carry identities (other than DNs) that are familiar to the
> 	user or that are used in other systems.

...and also to authenticate against existing credentials maintained and
stored outside the LDAP installation.

> 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.  However, you have made many 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.

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

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

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

>  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.  E.g., I disagree with the TLS requirement.
Other protection, like IPSec, ldap://localhost/, or a Unix filename
socket, is fine.  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. 

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

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

BTW, MUST they support unauthenticated binds?  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.

>> 3.1.1. Start TLS Request
>>
>>    A client may send the Start TLS extended request at any time after
>>    establishing an LDAP connection, except:
>>
>>       - when TLS is currently established on the connection,
>>       - when a multi-stage SASL negotiation is in progress on the
>>         connection, or
>>       - when there are outstanding LDAP operations on the connection.
>
> s/LDAP operations/responses for previously issued operations/
>
> This makes, I think, it clear that clients are to wait.

I don't see the difference; I liked the original better.  However, I
like your following change anyway:

> Hence,
> the following paragraph can be replaced with:
>
> 	As described in [Protocol, Section 4.13.2.2], a (detected)
> 	violation of any of these requirements results in return of
> 	the operationsError resultCode.


>> 6. Anonymous Authentication
>>
>>    Directory operations that modify entries or access protected
>>    attributes or entries generally require client authentication.
>>    Clients that do not intend to perform any of these operations
>>    typically use anonymous authentication.
>
> I hope this is not typical.

Why?

> I think this paragraph should simply be deleted.

Yes.

>> 7. Simple Authentication

>>    An LDAP client may establish an LDAP association by sending a Bind
>>    Request with a name value consisting of an LDAP distinguished name
>>    [LDAPDN] and specifying the simple authentication choice with a
>>    password value.
>
> s/an LDAP distinguished name/a distinguished name in LDAP string
> form [LDAPDN]/

I don't see why, except the [LDAPDN] reference.

> s/password value/password value, an OCTET STRING.

Why?

>>    DSAs that map the DN sent in the bind request to a directory entry
>>    with an associated set of one or more passwords will compare the
>>    presented password to the set of passwords associated with that
>>    entry.

> s/more passwords/more passwords, each an OCTET STRING,/
> s/compare/compare octet wise/

No!

- [SASLprep] may apply first.

- If the directory entry contains a password, how to compare the
  passwords should be defined by the password attribute's syntax.  For
  example, caseExactMatch would be appropriate if one uses long
  passwords that consist of several easy-to-remember words instead of
  short cryptic passwords.

- Even if DN is mapped to a directory entry, the entry's password
  attribute may refer to some user's password stored in the operating
  system, and one must use the operating system's routine to compare
  passwords.

-- 
Hallvard