Re: Intro issues (Was: authmeth review notes [long])

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

At 01:24 PM 4/4/2004, Hallvard B Furuseth wrote:
>So I think we do need to mention it somehow.
>
>Maybe
>
>   (2) Servers can implement client authorization by means of access
>       control based on the requestor's authenticated identity, though
>       this is not part of this standard,
>
>or turn it around a bit:
>
>   (2) Server implementations can make use of the requestor's
>       authenticated identity to implement client authorization by
>       means of access control, though how to do so is not part of
>       this standard,
>
>Anyway, I've said my piece now and won't kick if (2) is deleted.

Each of the paragraphs should be something which LDAP, as defined in this
specification, offers.  While it is true that LDAP implementations can
offer access controls, LDAP doesn't.  However, it can be said that LDAP
offers facilities to support local access control mechanisms (e.g.,
insufficientAccessRights result code).  So, maybe:
    (2) mechanisms to support vendor-specific access control facilities
       (LDAP does not offer a standard access control facility)

Alternatively, we could expand (1) to note that authentication methods
can be used in support of vendor-specific access control facilities.

>>>>>    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
>>
>> This section is introductory.  It's providing some background as to
>> why particular security services are offered and why particular
>> applicability statements have been made.  Section 11 is basically
>> stating a security consideration.
>
>OK.  But then 'This means that' should be removed, and that sentence be
>moved out of that paragraph.  At least I don't see the logic of why it
>follows from the previous sentence.

I think it kind of follows from the concern "or worse, they will support
only clear text passwords that provide inadequate security for most
circumstances."   However, it's weak in that implies the mechanism
be used doesn't provide adequate protection itself (and not only for
itself, but also the session).

>The same applies to passwords _not_
>stored in the directory,

as well as to cases were the authentication identity is not in the form
of a DN.

>if there is an extended operation which can
>update non-directory passwords.  Maybe the sentence should go to Section
>11, maybe just to the next paragraph, I don't know.

I think it appropriate in the Introduction to state that because of the
strong desire to use simple DN+password, other plain text authentication
mechanisms, or mechanisms which do not provide data security services
for the session, it is desirable to define a mechanism for establishing
data security services at the transport layer.

Then in security considerations, we can focus on particular cases where
it important to establish data security services.

>>>> 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.
>>
>> It can be argued that "used" encompasses both "maintained" and "stored".
>
>True, but since this is an introductory text and not a text for
>implementors to carefully interpret, it's better to be clear.
>"used and/or stored" should be ample, though.

I think "and/or stored" is distracting and hence less clear.  (It seems
quite irrelevant whether or not the identity used is ever stored.)  Are
just concerned that "used" is somehow more restrictive than
"used and/or stored"? A different wording might better address that
concern.  How about?
        It is also desirable to allow authentication methods to carry
        identities other than DNs, including ones familiar to the user
        or ones used in another system.