Re: authmeth-12 review notes

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

Kurt D. Zeilenga writes:
>At 08:25 AM 9/27/2004, Hallvard B Furuseth wrote:
>> Authmeth-12 review notes follow.  I'm splitting some subjects out to
>> separate threads.
>
>>>  1. Introduction
>>
>> (...) How about
>>
>>      (3) Data integrity protection by means of security layers in TLS or
>>          SASL mechanisms,
>>
>>      (4) Data confidentiality protection which the TLS protocol and
>>          SASL mechanisms can provide,
>
>  I would that these be worded symmetrically.  That is, replace
>  your (4) with:
>          (4) Data confidentiality protection by means of security
>          layer in TLS and SASL mechanisms,

Right.  I have _no_ idea why I couldn't come up with that one myself; I
actually did try to fix it:-)

s/layer/layers/, though.

>>>  3.1.4. Client Certificate
>>
>>>     In an LDAP server requests a client to provide its certificate
>>>     during TLS negotiation and the client does not present a suitablle
>>>     certifcate (e.g. one that can be validated), the server MAY use a
>>>     local security policy to determine whether to successfully complete
>>>     TLS negotiation.
>>
>> s/MAY/may/?
>
>  Yes.
>
>>  What else than local security policy could the server use?
>> I guess the alternative is an implementation-specific setting; but I
>> would hope such a setting would just be a default - and using a default
>> would be a local security policy:-)
>
>   From a technical specification point of view, there is no
>  clear distinction between "local security policy" and
>  "implementation-specific setting" and rightly so.

OK.

>>>  3.1.5. Discovery of Resultant Security Level
>>
>>>     After a TLS connection is established on an LDAP connection, both
>>>     parties must individually decide whether or not to continue based on
>>>     the security level achieved.
>>
>> s/must/MUST/?
>
>  Would be better to s/must/are to/ IMO.

OK.

>>>  4.3. Invalidated Associations
>>
>>>     While the
>>>     association is invalidated, the server may reject any operation
>>>     request other than Bind, Unbind, and StartTLS by responding with a
>>>     resultCode of strongAuthRequired
>
>  I think this text is a bit misleading as it kind of implies
>  that only while the association is invalid this code may
>  be returned.

Yes, that's what my suggested text tried to solve.  Did I fail?
Here:
       Note that the server may in any case choose to return
       strongAuthRequired at nearly any time.  The above behavior
       is spelled out because it often makes sense and is simple for
       users [or "simple for clients"?] to understand.

Though as you say, there are problems with the whole invalidated
associations concept; see below before answering.

>  I also think this text is a bit too perspective.

s/perspective/prescriptive/:-)
Yes, agreed, if someone has a better wording.

>> Thus ensuring that "strong"AuthRequired is totally misnamed, since even
>> anonymous bind fixes this condition.
>
>  Not sure why a server would return strongAuthRequired for
>  a request then subsequently perform that operation under
>  an anonymous association.

I think we just didn't find any better result code.

  [Protocol] A.2 Result Codes
      strongAuthRequired (8)
         Indicates that the server has detected that an established
         security association between the client and server has
         unexpectedly failed or been compromised, or that the server
         now requires the client to authenticate using a strong(er)
         mechanism.

Without "unexpectedly", the part before the comma fits invalidated
associations just fine.  That part has been in [Protocol] since at least
version -02, but until -17 it only applied to Notice of Disconnection.

Also, since at least [Protocol] version 12, it was the one result code
which could be returned which required a future Bind (the part after the
comma) rather than reporting an error in the Bind it responded to.

If neither of these are good reasons to stay with strongAuthRequired,
I suggest invalidCredentials instead.  As far as I can tell it is even
unambiguous:  Today it is only returned by Bind, while invalidated
associations accept Bind - even a failed Bind.

>  We need to be clear that result codes are indications of
>  the outcome of a request and requests are generally independent
>  of each other.

You mean, clarify in the section about invalidated associations that
this condition is abnormal and not how LDAP normally does things?

>> I think that needs to be noted
>> either in [Authmeth] or [Protocol].
>
>  I wouldn't object to renaming the strongAuthRequired result
>  code to be strongerAuthRequired code.

Sounds good to me, but authRequired would be better - unless another
result code is used for that.

>>>     This behavior is
>>>     explained here to help client implementers properly understand and
>>>     react to this situation.
>
>  This is quite problematic.  LDAP requests are generally
>  independent of each other and result codes are generally
>  not indicative of what the client should do.  A result
>  code is indicative of the reason why the server was
>  unwilling or unable to perform the requested operation.

Yes.  I thought the idea was that invalidated associations are the least
bad solution, and that it helps somewhat to have a single recommended
way.

>>>  5. Bind Operation
>>
>>>     If the authorization identity is not
>>>     specified, the server derives it from the authentication identity in
>>>     an implementation-specific manner.
>>
>> Should this and "implementation-specific" in B.4 (Authorization
>> Identity) be "implementation-specific and/or according to local policy"?
>
>  No.  Whether or not local policy matters, and if so, how,
>  is itself implementation-specific.

OK.

>>>  8. Simple Authentication Mechanism of Simple Bind
>>
>>>     Servers that map the DN sent in the bind request to a directory
>>>     entry with an associated set of one or more passwords
>>
>> Maybe add "which can be used with this authentication mechanism" since
>> an entry could contain several password representations of different
>> types, where each mechanism can only use some of the types.
>
>  I think adding that would border being overly precise
>  in what is intended to be statement of how servers
>  typical behave.  Servers, historically and in this
>  specification, have lots of freedom here.

Right.

>  I think
>  many of these issues could be better addressed by
>  clearly stating the minimal steps a server undertakes,
>  providing an overview of a typical implementation,
>  note some of the many ways implementations may differ
>  from the typical.

That sounds very good, but it also sounds like a lot of work -- how long
time shall we give it?

>>>     , will compare
>>>     the presented password to the set of passwords associated with that
>>>     entry. The presented password is considered valid if it matches any
>>>     member of this set.
>>>
>>>     If the DN is not valid, or the password is not valid for the DN, or
>>>     the server otherwise considers the credentials to be invalid, the
>>>     server is to return the invalidCredentials result code.  The server
>>>     is only to return success result code when the credentials are valid
>>>     and the server is willing to provide service to the entity these
>>>     credentials identify.
>>
>> These two paragraphs mostly apply to other authentication mechanisms
>> too; though they would need to be generalized - some mechanisms do not
>> use a DN, others do not use a password, and some only work if there is
>> exactly one password which that mechanism can use.
>
>  Other mechanisms are not LDAP-specific and are, in fact,
>  specified elsewhere.

Eh?  Such mechanisms are specified elsewhere, but how LDAP uses them is
not.  That's why I'm suggesting to generalize this description, since we
have got it anyway.  Still, it's no big deal:

>> I don't remember if I'm trying to resurrect a dead horse with the two
>> above comments; if so do tell me to leave it dead.

>>>     Server behavior is undefined for Bind requests with a zero-length
>>>     name value and specifying the simple authentication choice with a
>>>     value of non-zero length.
>>
>> Is this totally undefined,
>
>  I think the above meant to say that the request had
>  no defined meaning.
>
>  Personally, I think it would be better to define such
>  requests as being invalid and require servers to
>  fail such requests with an appropriate result code.

Why was it made undefined in the first place, instead of a normal simple
bind?

-- 
Hallvard