Subject: authmeth-12 review notes

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 27 Sep 2004 17:25:24 +0200

Authmeth-12 review notes follow.  I'm splitting some subjects out to
separate threads.  A number of the issues are copied (and sometimes
modified a bit) from earlier review notes which as far as I can remember
have not received responses; I don't know if they have been forgotten or
rejected.  In the latter case, I'd like to know that, and except for
minor matters why.  Or if I'm the one who has forgotten what happened
with some of them, feel free to jump on me.

> 1. Introduction

>    LDAP offers the following security mechanisms:

>    (3) Data integrity protection by means of TLS or SASL mechanisms
>        with security layers that provide data integrity protection,
>
>    (4) Data confidentiality protection by means of the TLS protocol or
>        SASL mechanisms that provide data confidentiality protection,

These seem a bit redundant.  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,

Except, the rest of the draft says just "confidentiality protection",
not "data confidentiality protection".

>    It seems clear that allowing implementations, faced with the above
>    requirements, to simply pick and choose among the possible
>    alternatives is not a strategy that is likely to lead to
>    interoperability. In the absence of mandates, clients will be
>    written that do not support any security function supported by the
>    server, or worse, they will support only clear text passwords that
>    provide inadequate security for most circumstances.

Implementations have had these choices for a while now.  Can we replace
"It seems clear" ... "[not] likely to lead to interoperability" ...
"clients will be written" with statements that this DID happen?

The end of the next paragraph also gives me a vague "we are working on
this"-feeling rather than "we have done this":

>    it is desirable to ensure secure interopability
>    by indentifying a mandatory-to-implement mechanism for establishing
>    transport-layer security services.

The start of the following sentence is not right; there are exceptions:

>    Because
>    these authentication mechanisms transmit credentials in plain text
>    form and other authentication mechanisms do not provide data
>    security services,

I suggest:
replace "Because these" with "Because many", (or several, some, ...?)
replace "and other authentication mechanisms" with "and/or".

> 1.2.1. Glossary of Terms

>      - "connection" and "LDAP connection" both refer to the underlying
>        transport protocol connection between two protocol peers.
>
>      - "TLS connection" refers to an LDAP connection with TLS
>        protection [TLS].
>
>      - "association" and "LDAP association" both refer to the
>        association of the LDAP connection and its current
>        authentication and authorization state.

Switch to new [Protocol] terminology: "connection", "TLS-protected
LDAP exchange", "association" (not "LDAP association").

Though maybe the latter should get a bit more explanation in Authmeth:

("I.e. the client's current authentication and authorization identity"
-- and possibly other factors such as strength of bind method etc.?)

> 2. Implementation Requirements

>    Implementations MAY support additional mechanisms of the simple and
>    SASL bind choices.  Some of these mechanisms are discussed below.

I would replace "additional mechanisms of the simple and SASL bind
choices" with "additional authentication mechanisms".

> 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/?  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:-)

> 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/?

> 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

Thus ensuring that "strong"AuthRequired is totally misnamed, since even
anonymous bind fixes this condition.  I think that needs to be noted
either in [Authmeth] or [Protocol].

>    This behavior is
>    explained here to help client implementers properly understand and
>    react to this situation.

Also, I suggest to add:

     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.

Or explicitly say the opposite, if that has been decided.  I seem to
remember a mention that someone disliked that the server could do this,
but I cannot find that now.

> 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"?

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

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

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, in that it may succeed but do something else
than what the simple authentication mechanism does?  If so, it is not
that mechanism and does not belong in this section, but in section 5.1;
and the Simple Authentication Mechanism should be redefined to be
specified by a non-empty DN and a non-empty password.  That would
require updates other places too, at least in the Security
Considerations section which refers to this mechanism.

If it is only undefined whether or not it succeeds as the Simple
Authentication Mechanism, that should be clarified here.

>    LDAP implementations MUST be
>    capable of protecting it by establish::qment of TLS (as discussed in
>    section 3) or other suitable data confidentiality and data integrity
>    protection(e.g. IPSec).

Maybe this should be turned around, since the section is about Bind and
not TLS:

     LDAP implementations SHALL NOT support this mechanism unless they
     can protect it by TLS.

(I removed "or other..."; see my 'TLS issues' message.)

> 10. SASL EXTERNAL Mechanism
> 11. SASL DIGEST-MD5 Mechanism

I suggest s/Mechanism/Authentication Mechanism/ in these titles.

> 12.1. General LDAP Security Considerations

>    Servers can minimize denial of service attacks by timing out idle
>    connections, and returning the unwillingToPerform resultCode rather
>    than performing computationally expensive operations requested by
>    unauthorized clients.

OpenLDAP returns adminLimitExceeded in some cases - e.g. if too many
entries are left to check after the indexes have been used.  That seems
reasonable to me, though I'm not sure what adminLimitExceeded originally
means (in X.500).

> 12.2. StartTLS Security Considerations

>    The goals of using the TLS [TLS] protocol with LDAP are to ensure
>    connection confidentiality and integrity, and to optionally provide
>    for authentication. TLS expressly provides these capabilities
>    (although the authentication services of TLS are available to LDAP
>    only in combination with the SASL EXTERNAL authentication method,
>    and then only if the SASL EXTERNAL implementation chooses to make
>    use of the TLS credentials).

That does not look like a security consideration to me.

>     Clients SHOULD either warn the user when the security level
>    achieved does not provide data confidentiality and/or integrity
>    protection, or be configurable to refuse to proceed without an
>    acceptable level of security.

I think this implies the wrong default.  I suggest s/SHOULD/SHOULD by
default/, and they may then be configurable to be _willing_ to proceed
anyway.

However, that 'acceptable level' is a moving target.  Maybe this should
be added somewhere (not under StartTLS):

   Unfortunately, old implementations are (at least by default) likely
   to consider poor security acceptable, since new attacks are regularly
   being discovered and increasing computing power makes more attacks
   practical.

>    Server implementors SHOULD allow server administrators to elect
>    whether and when data confidentiality and integrity are required, as
>    well as elect whether TLS authentication of the client is required.

"TLS authentication" = "demand a client certificate which the server can
verify", not "demand SASL/EXTERNAL afterwards"?

I asked for clarification, and I notice the wording has changed in that
direction, but I don't know if that was in response to my request.  I
would prefer more clearer words that "authentication" does not refer to
LDAP authentication (even to someone who has not read [TLS]), but if
others feel that the current wording is sufficient, that's OK.

> 12.3. Unauthenticated Mechanism Security Considerations

>    LDAP server
>    implementations will return a success response to an unauthenticated
>    bind request

s/LDAP server implementations will/LDAP servers may/.

> 13. IANA Considerations
>
>    The following IANA considerations apply to this document:
>
>    Please update the GSSAPI service name registry to point

"ldap"

>    to [Roadmap]
>    and this document.

> A.2. Actions that Affect LDAP Association State

>    A2  Client successfully performs anonymous simple bind
>    A3  Client successfully performs unauthenticated simple bind

I would merge these.  I previously suggested to also merge
SASL/ANONYMOUS, but if I remember correctly from the sasl list, that's
not anonymous in LDAP sense after all.

> A.4. LDAP Association State Transition Table

>    S1, the initial state for the state machine described in this table,
>    is the authentication state when an LDAP connection is initially
>    established.

Actually you could make that a separate action A0: "Connecting to the
LDAP server".

BTW, I noted previously that it would be easier to read the table if the
actions and/or states have names rather than numbers.  It's less
important now that the table is so much smaller, but it would still be
nice.

> Appendix B. Authentication and Authorization Concepts

Maybe "Data integrity protection" and "Confidentiality protection"
should also be explained?  (And the section would be renamed.)

> B.2. Access Control Factors
>
>    They might include

the association's authorization identity,

(That was actually not obvious to me at first; I wondered if ACFs were
more magical than that:-)

>    source IP address, encryption strength,
>    (...)

========

Editorial comments:

> 1. Introduction

s/indentifying/identifying/.

> 1.2.2. Security Terms and Concepts
> 3.2. Effects of TLS on a Client's Authorization Identity

"Appendix C" should be "Appendix B".

> 3.1.4. Client Certificate

s/suitablle/suitable/.
s/certifcate/certificate/.
s/external/EXTERNAL/.

> 3.2.1. TLS Connection Establishment Effects

>    The decision to keep or invalidate the established LDAP association
>    (section 12) after TLS connection establishment is a matter of local
>    server policy.

s/section 12/section 4.3/.

> 3.2.2. Client Assertion of Authorization Identity

>    specifying a SASL mechanism of EXTERNAL [SASL] (section 9).

s/section 9/section 10/.

> 5.1. Simple Authentication Choice

>     3. a simple authentication mechanism using credentials consisting
>        of a name (in the form of an LDAP distinguished name [LDAPDN])
>        and a password (section X).

I don't think that's the right section:-)

> 7. Unauthenticated Authentication Mechanism of Simple Bind

>    Unauthenticated binds can have significant security issues (see
>    section 14).

Section 12.3.  And maybe s/./:/.

> 8. Simple Authentication Mechanism of Simple Bind

>    capable of protecting it by establish::qment of TLS (as discussed in
Garbage:                         ^^^^^^^^^^^^^^^^

>    LDAP implementations
>    SHOULD support authentication with the "simple" authentication
>    choice when the connection is protected against eavesdropping using
>    TLS, as defined in section 4.

Section 3.

> 9.1. SASL Service Name for LDAP

>    The SASL service name for LDAP is "ldap", which has been registered
>    with the IANA as a GSSAPI service name.

Add a reference to the definition of "GSSAPI"?

> 10.2. Explicit Assertion

>    An explicit authorization identity assertion is performed by
>    invoking a Bind request of the SASL form using the EXTERNAL
>    mechanism name that includes the credentials octet string. This
>    string MUST be constructed as documented in section 3.4.1.

Section 10.4.

> 10.4. SASL Authorization Identity Syntax

>    authzId = dnAuthzId / uAuthzId

Use '::=' instead of '=', like the other ldapbis drafts.

>    DNCOLON  = %x64 %x6e %x3a ; "dn:"
>    UCOLON = %x75 %x3a ; "u:"

I would put these at the end of the grammar, so all definitions are
found below their use.

> 12.1.1.Password-related Security Considerations

Missing space after "12.1.1.".

> 12.2. StartTLS Security Considerations

>     Clients SHOULD either warn the user when the security level
>    achieved does not provide data confidentiality and/or integrity

Unindent "Clients".

> 12.4. Simple Mechanism Security Considerations
>
>    The simple authentication mechanism of simple bind discloses the
>    password to

the

>    server,

> 12.5. SASL DIGEST-MD5 Mechanism Security Considerations
>
>    The SASL DIGEST-MD5 mechanism is prone to the qop substitution
>    attack, as discussed in 6.2 of RFC 2831.  The qop substitution
>    attack can be mitigated (as discussed in 6.2 of RFC 2831).

RFC 2831 Section 6 is "Authors' Addresses".  Besides, I would think RFC
2831 should be [DIGEST-MD5] which will replace it, but its section 6 is
also "Authors' Addresses".

> 12.6. Related Security Considerations

Missing newline after header.

> Normative References

>    [StringPrep]         M. Blanchet, "Preparation of Internationalized

Unindent description.

> Appendix A. LDAP Association State Transition Tables
>
>    This section provides a state transition table to represent a state
>    diagram for the various authentication and TLS states

There are no TLS states in the table now.

> A.2. Actions that Affect LDAP Association State

Remove spurious "]"s in actions A5 and A6.

> A.4. LDAP Association State Transition Table

>    Action   State  Comment
>    -------  -----  -------------------------------------------------

If you expand the "Action" field, you can put things like
"A6, D1 or D2 = no" and "A6, D1 = D2 = yes" on a single line.

>    A8         no   [Protocol] section 4.14.2.1
>              change

I suggest to call that A8 "no change[*]" and add

[*] The server may invalidated the association after TLS
    establishment/closure; section 3.2.

> F.8. Changes for draft-ldapbis-authmeth-09

>      - Reworded sentence beginning, "It is also desirable to allow
>        authentication methods to carry identities based on existingù
>        non-LDAP DN-forms..."

s/ù//.  8-bit character.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 27 Sep 2004 15:31:58 -0700

At 08:25 AM 9/27/2004, Hallvard B Furuseth wrote:
>separate threads.

I tried to only respond here to those subjects which weren't split out.

>A number of the issues are copied (and sometimes

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,

>not "data confidentiality protection".

The latter should generally be used.

>s/MAY/may/?

Yes.

> What else than local security policy could the server use?

 From a technical specification point of view, there is no
clear distinction between "local security policy" and
"implementation-specific setting" and rightly so.

>>    the security level achieved.

Would be better to s/must/are to/ IMO.

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

I also think this text is a bit too perspective.

The point is that the server is free to change the association
at its will.  How the server behaves in response to future
operations depends on the association in place at that
time.  The client has, in general, treat responses as indicative
only of the requested operation's outcome and not necessarily
indicative of what it needs to do before submitting some
other operation.

strongAuthRequired means simply that the server is requires
strong(er) authentication to perform the request operation.

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

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

>I think that needs to be noted

I wouldn't object to renaming the strongAuthRequired result
code to be strongerAuthRequired code.   Don't think [protocol]
needs to enumerate all the instances in which a server might
choose to return this code, but instead be clear on what
that code means (strong(er) authentication is required).
I think [Protocol] does that already.

Again: less prescriptive, more descriptive.

>>    explained here to help client implementers properly understand and

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.

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

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

>exactly one password which that mechanism can use.

Other mechanisms are not LDAP-specific and are, in fact,
specified elsewhere.  This mechanism needs to adequately
specified here, using LDAP-specific terms as appropriate.

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

>in that it may succeed but do something else

(See my "TLS issues" response)

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 28 Sep 2004 23:56:43 +0200

Kurt D. Zeilenga writes:
>> (...) How about

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.

>  "implementation-specific setting" and rightly so.

OK.

>  Would be better to s/must/are to/ IMO.

OK.

>  that only while the association is invalid this code may

Yes, that's what my suggested text tried to solve.  Did I fail?
Here:

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.

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

>  the outcome of a request and requests are generally independent

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

>  code to be strongerAuthRequired code.

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

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

>  is itself implementation-specific.

OK.

>  specification, have lots of freedom here.

Right.

>  I think

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

>  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

>  fail such requests with an appropriate result code.

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

-- 
Hallvard