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

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

Kurt D. Zeilenga writes:
>At 10:09 AM 3/9/2004, Hallvard B Furuseth wrote:
>
>>>>    (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?
>
> I don't think servers are necessarily expected to support a means of
> access control.  There are, after all, servers which do not support
> any form of authentication.  But more importantly, this list is of
> security services LDAP provides.  I don't think LDAP provide this
> expectation and, even if it did, it's only an expectation.

All true, but on the other hand, parts of Authmeth - at least the
authorization identity - are mostly pointless without access control,
while Bind in general is mostly done for access control in many
situations.  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.

>>>>    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.  The same applies to passwords _not_
stored in the directory, 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.

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

-- 
Hallvard