authmeth-07 issues

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

Sometimes you say that to achieve X, one MUST do Y and then Z.  I think
this is a misuse of the "MUST" keyword.  Instead, say that one can
achieve X by doing Y and then Z.  In particular when the "to achive X,"
part seems to be indicated by the section header rather than stated
explicitly before the MUST.  I comment the instances I found below.

The information in sections 3-9 is rather confusingly arranged.
This is difficult to follow, and also leads to redundancy:
  bind/anonymous (3), SASL (3.3), EXTERNAL (3.3.6), SASL,
  TLS (4), EXTERNAL (4.1.5), TLS, EXTERNAL (4.2.2), bind (4.2.2.3), TLS,
  transition table (5),
  bind/anonymous again (6),
  simple bind (7.1), SASL DIGEST-MD5 (7.2), bind/TLS (7.3-4),
  TLS/EXTERNAL (8),
  TLS (9).
I suggest you rearrange it something like this:
  TLS, with nothing but a one-sentence forward reference to EXTERNAL,
  bind in general (e.g. error conditions),
  unbound connections,
  simple and anonymous bind,
  SASL,
    EXTERNAL,
    DIGEST-MD5,
    other SASL methods,
  transition table,
  TLS ciphersuites (section 9) here, or with the TLS section above?
Some comments about this follow below.

> 3.1. Unbound Connection Treated as Anonymous ("Implied Anonymous Bind")
>
>    (...) If the server
>    requires that the client bind before browsing or modifying the
>    directory, the server MAY reject a request other than binding,
>    unbinding or an extended request with the "operationsError" result.

"extended request"?  It should be allowed to reject extended requests
other than the StartTLS extended request.

Also abandon should be in the list above, since it cannot respond with
"operationsError".

Finally, I suggest you rephrase the above "If..." sentence to simply
say: "Over an anonymous LDAP association [or LDAP connection?], the
server MAY reject a request other than...".  That also takes care of
requests after a failed bind, and after TLS closure.  The "if the server
requires..." part is implicit in the rest of the sentence and can be
dropped.

> 3.2. Simple Authentication

Move the info about anonymous auth to a subsection of this.

>    The simple authentication option provides minimal authentication
>    facilities, with the contents of the authentication field consisting
>    only of a cleartext password.

Should this section mention how SASLprep is used on auth password and
DN?

> 3.3. SASL Authentication Profile
>
>    As LDAP
>    includes native anonymous and plaintext authentication methods, the
>    "ANONYMOUS" [ANONYMOUS] and "PLAIN" [PLAIN] SASL mechanisms are
>    typically not used with LDAP.

Why mention them at all?  They are not mentioned in rfc2222bis, so there
is no need for a disclaimer.

> 3.3.2. SASL authentication initiation and protocol exchange

>    client to respond to one or more server challenges by invoking the
>    BindRequest multiple times.

I think "the" should be dropped.

>    A client may abort a SASL bind negotiation by sending a BindRequest
>    with a different value in the mechanism field of SaslCredentials, or
>    an AuthenticationChoice other than sasl.

That new bindRequest is then started instead?

> 3.3.3. Octet where negotiated security mechanisms take effect
>
>    If any SASL-based integrity or confidentiality services are enabled,
>    they take effect following the transmission by the server and
>    reception by the client of the final BindResponse with a resultCode
>    of success.

Merge this with 3.5.

> 3.3.5. Rules for using SASL security layers

>    If the client is configured to support multiple
>    SASL mechanisms,

No, "If the client makes use of supportedSASLmechanisms,"

It might be support multiple SASL mechanisms in a way such that the
choice is controlled by something else than supportedSASLmechanisms,
e.g. by the user.

>    it SHOULD fetch the supportedSASLmechanisms list
>    both before and after the SASL security layer is negotiated.

>    If a lower level security layer (such as TLS) is negotiated, any
>    SASL security services SHALL be layered on top of such security
>    layers regardless of the order of their negotiation.

This is repeated in 3.5.  Delete one of the texts.
Actually, I suggest 3.5 is moved here.

> 3.3.6. Use of EXTERNAL SASL Mechanism

Move this section down to the rest of the text about EXTERNAL.

>    If a TLS session has not been established between the client
>    and server prior to making the SASL EXTERNAL Bind request

No, if there is no current TLS session.  A TLS session might have been
establised prior to the bind and then closed.  I don't think one should
use credentials from it in that case.

>    if during the process of establishing
>    the TLS session, the server did not request the client's
>    authentication credentials,

"authentication credentials" = "certificate"?  In 8.1 you say "the
server MUST request a certificate".  IIRC, yet another place you imply
that the client need not send a certificate even if the server requested
it.  I don't know what is right.  Maybe "the server did not request"
should be "if the client did not send"?

>    the SASL EXTERNAL bind MUST fail with a
>    resultCode of inappropriateAuthentication.

>    Any client authentication
>    and authorization state of the LDAP association is lost, so the LDAP
>    association is in an anonymous state after the failure (see
>    [Protocol] section 4.2.1).

This is not specific to EXTERNAL.  It should be moved to a section about
bind (and bind failure) in genereal.

> 3.4. SASL Authorization Identity
>
>    The authorization identity is carried as part of the SaslCredentials
>    credentials field in the Bind request and response.

What does it mean to have an authz id in the response?  Can it be
different from the authz identity that the client requested, or
something?  Will some clients need to check that the authz id it
received, is the one it wanted?

>    When the "EXTERNAL" SASL mechanism is being negotiated, if the
>    credentials field is present, it contains an authorization identity
>    of the authzId form described below.
>
>    Other mechanisms define the location of the authorization identity
>    in the credentials field.

I have trouble with what "other mechanisms" you refer to after all.
I suggest you reword as:

    "SASL mechanisms that use an authorization identity, define where
    in the credentials field it is found".

Then move the previous paragraph (about EXTERNAL authz id) to the
section about EXTERNAL, or swap the two paragraphs.

> 3.4.1. Authorization Identity Syntax

Rename this section, it is about more than authz id _syntax_.

> 3.5. SASL Integrity and Privacy Protections
>
>    Any negotiated SASL integrity and privacy protections SHALL start on
>    the first octet of the first LDAP PDU following successful
>    completion of the SASL bind operation.

3.3.3 said that.

State the effect of a failed SASL bind or a non-SASL bind on an existing
SASL security layer.  I expect it would be something like this:

  A bindRequest (successful or not) which is not successfully abandoned,
  cancels [is that the right word?] any previously established SASL
  security layer, so that the bindResponse is sent without that layer.

[Or - if there are outstanding, possibly-abandoned requests, will the
client know when the security layer gets cancelled?  Does the layer
itself necessarily contain a "cancel" operation so the client can tell?]

  TLS closure also cancels the SASL security layer.

[seems natural since the connection moves to anonymous state.]

>    If lower level security layer
>    is negotiated, such as TLS, any SASL security services SHALL be
>    layered on top of such security layers regardless of the order of
>    their negotiation.

3.3.5 said that.

> 4.1. Sequencing of the Start TLS Operation

>    Note that the precise effects, on a client's authorization identity,
>    of establishing TLS on an LDAP association are described in detail
>    in section 4.2.

No, in 4.2.1: It has no effect.  EXTERNAL has effect, but that's the
bind operation, not the start TLS operation.
Just delete this paragraph.

> 4.1.1. Requesting to Start TLS on an LDAP Association

>    In particular, there is no requirement that the client have or have
>    not already performed a Bind operation before sending a Start TLS
>    operation request. The client may have already performed a Bind
>    operation when it sends a Start TLS request, or the client might
>    have not yet bound.

The second sentence is redundant.  Delete it.

>    If the client did not establish a TLS connection before sending any
>    other requests, and the server requires the client to establish a
>    TLS connection before performing a particular request, the server
>    MUST reject that request by sending a resultCode of

"If the server wishes...then it MUST".  Don't say that.  You can replace
the above with:

     If a TLS connection is not established, the server MAY reject
     any request other than Start TLS [, unbind?] and abandon by
     sending...

>    confidentialityRequired or strongAuthRequired.

strongAuthRequired sounds wrong.  Auth is bind, and bind won't help.

>    In response, the
>    client MAY send a Start TLS extended request, or it MAY choose to
>    close the connection.

Delete this, it is obvious from the above.

> 4.1.4. Discovery of Resultant Security Level

>    If the client or server decides that the level of authentication or
>    privacy is not high enough for it to continue, it SHOULD gracefully
>    close the TLS connection immediately after the TLS negotiation has
>    completed (see [Protocol] section 4.13.3.1 and section 4.2.3 below).

Is there any problem if the client and the server initiate TLS closure
at the same time?

>    If the client decides to continue, it MAY gracefully close the TLS
>    connection and attempt to Start TLS again, it MAY send an unbind
>    request, or it MAY send any other LDAP request.

This paragraph seems redundant to me.  But if you keep it, reword to:

    "If the client decides to continue after TLS closure, it MAY..."

since it might have been the server which closed TLS.

> 4.1.5. Assertion of Client's Authorization Identity
>
>    The client MAY, upon receipt of a Start TLS response indicating
>    success,

no, after a successful TLS connection has been established.  The
response might be success but the following TLS negotiation might fail.

Besides, it may do this with (at least) IPv6 too.

>    assert that a specific authorization identity be utilized
>    in determining the client's authorization status. The client
>    accomplishes this via an LDAP Bind request specifying a SASL
>    mechanism of "EXTERNAL" [SASL] (see section 4.2.2 below).

However, I think this entire section should be deleted.  You mention
EXTERNAL enough places as it is.

> 4.1.6. Server Identity Check

>    The
>    client MAY need to make use of local policy information.

s/MAY/may/.

> 4.2. Effects of TLS on a Client's Authorization Identity
>
>    This section describes the effects on a client's authorization
>    identity brought about by establishing TLS on an LDAP association.

It has no effect.

> 4.2.1. Default Effects

Rename.  "Default" is something which can be overridden.  EXTERNAL
does not override the effect of TLS, it is a separate operation.

> 4.2.2. Client Assertion of Authorization Identity

Move this and subsections to one section about EXTERNAL.  No need to
have a separate section about EXTERNAL for TLS.

> 4.2.2.1. Implicit Assertion
> 4.2.2.2. Explicit Assertion

>    An implicit authorization identity assertion is accomplished after
>    TLS establishment

Is implicit (and 4.2.2.2 explicit) association a TLS term, or do the
terms apply to EXTERNAL with e.g. IPv6 too?

>    by invoking a Bind request of the SASL form using
>    the "EXTERNAL" mechanism name [SASL] [Protocol] that SHALL NOT
>    include the optional credentials octet string (found within the

s/that SHALL NOT include/which does not include/.  Similar for 4.2.2.2.
Since you define implicit/explicit assertion by how it is done.

> 4.2.2.3. Error Conditions

>    Additionally, with either form of assertion, if a TLS session has
>    not been established between the client and server prior to making
>    the SASL EXTERNAL Bind request and there is no other external source
>    of authentication credentials (e.g. IP-level security [RFC2401]), or
>    if during the process of establishing the TLS session, the server
>    did not request the client's authentication credentials, the SASL
>    EXTERNAL bind MUST fail with a result code of
>    inappropriateAuthentication.

Delete, you already said that in 3.3.6.

>    After the above Bind operation failures, any client authentication
>    and authorization state of the LDAP association is lost (see
>    [Protocol] section 4.2.1), so the LDAP association is in an
>    anonymous state after the failure.  The TLS session state is
>    unaffected, though a server MAY end the TLS session, via a TLS
>    close_notify message, based on the Bind failure (as it MAY at any
>    time).

Move to a section about bind.  It applies to bind in general, not to
just TLS/EXTERNAL.

> 6. Anonymous Authentication

Move to subsection of 3.2 (simple auth)

>    LDAP implementations MUST support anonymous authentication, as
>    defined in section 6.1.
>
>    LDAP implementations MAY support anonymous authentication with TLS,
>    as defined in section 6.2.

Huh?  What's the point of allowing anon/TLS to be unsupported?
Clients might want to use TLS for data integrity or something, but
they can still be read-only and have no need to bind.

> 6.1. Anonymous Authentication Procedure

>    An LDAP client MAY also choose to explicitly bind anonymously. A
>    client that wishes to do so MUST choose the simple authentication
>    option in the Bind Request (...)

"If the client wishes, it MUST".  Don't say that.  Try:

     An LDAP client MAY also choose to explicitly bind anonymously, by
     choosing the simple authentication
     option in the Bind Request (...)

> 6.2. Anonymous Authentication and TLS

>    An LDAP client MAY use the Start TLS operation (section 5) to
>    negotiate the use of TLS security [RFC2246]. If the client has not
>    bound beforehand, then until the client uses the EXTERNAL SASL
>    mechanism to negotiate the recognition of the client's certificate,
>    the client is anonymously authenticated.

What's the point of this paragraph?  The reader knows this already.

>    Recommendations on TLS ciphersuites are given in section 9.
>
>    An LDAP server which requests that clients provide their certificate
>    during TLS negotiation MAY use a local security policy to determine
>    whether to successfully complete TLS negotiation if the client did
>    not present a certificate which could be validated.

The the above two paragraphs have noting to do with anonymous auth.
Move them.

> 7.1. Simple Authentication
>
>    LDAP implementations SHOULD NOT support authentication
>    with the "simple" authentication choice

and a non-empty password

>    unless the data on the
>    connection is protected using TLS or other data confidentiality and
>    data integrity protection.

> 7.2. Digest Authentication

>    Support for subsequent authentication

     as defined in DIGEST-MD5 [DIGEST-MD5]

[Added because a reader might have no idea what you are talking about
otherwise.]

>    is OPTIONAL in clients and
>    servers.

>    o=Ace Industry ", are syntactically allowed, however DIGEST-MD5

Remove space before <">.

> 7.3. "simple" authentication choice under TLS encryption

What's the point of this section?  You just say that we can do simple
auth with TLS by doing TLS and then simple auth.  That has been said
before.  And it's already stated that the server shouldn't accept them
in the reverse order.

> 7.3.1. "simple" Authentication Choice
>
>    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. If the presented password matches any member of that set,
>    then the server will respond with resultCode success, otherwise the
>    server will respond with resultCode invalidCredentials.

Move this to the section about simple auth.  Maybe mention that
server-side passwords should be prepared with SASLprep.

> 7.4. Other authentication choices with TLS
>
>    It is also possible, following the negotiation of TLS, to perform a
>    SASL authentication that does not involve the exchange of plaintext
>    reusable passwords. In this case the client and server need not
>    negotiate a ciphersuite that provides confidentiality if the only
>    service required is data integrity.

I don't see the point of this paragraph either.
If you mean EXTERNAL, we know that.  If you mean DIGEST-MD5, we know
that too - and we don't need TLS for that, though TLS doesn't hurt.
Also, with "negotiate a ciphersuite", do you mean TLS ciphersuite or
SASL cipersuite?

> 8. Certificate-based authentication
>
>    LDAP server implementations SHOULD support authentication via a
>    client certificate in TLS, as defined in section 8.1.

This should probably be moved to the discussion about EXTERNAL.

> 8.1. Certificate-based authentication with TLS

This section is confusing, it mixes up info about TLS, EXTERNAL, and
bind in general.  This info should be split out to three such different
sections at different places in the document.

>    A user who has a public/private key pair in which the public key has
>    been signed by a Certification Authority

I'm not sure how this works.  Can't the server have a store of trusted
unsigned certificates?

>    may use this key pair to
>    authenticate to the directory server if the user's certificate is
>    requested by the server.

>    The user's certificate subject field SHOULD
>    be the name of the user's directory entry,

Why?  Certificate handling (like OpenSSL) can be completely separate
from the LDAP directory.  You even say below that how to validate the
certificate path is out of scope for LDAP.

>    A server MAY support mappings for certificates in which the subject
>    field name is different from the name of the user's directory entry.

Yes...

>    A server which supports mappings of names MUST be capable of being
>    configured to support certificates for which no mapping is required.

Why?

>    The client will use the Start TLS operation [Protocol] to negotiate
>    the use of TLS security [RFC2246] on the connection to the LDAP
>    server.

Said that before.

>    The client need not have bound to the directory beforehand.

Said that before too.

>    In the TLS negotiation, the server MUST request a certificate. The
>    client will provide its certificate to the server,

I've certainly used LDAP/TLS without client certificates.  Do you mean
that IF one wishes to do certificate-based auth, this must be done?  If
so, you should instead say that the client can do cert-based auth by
sending a cert during TLS establishment and then an EXTERNAL bind.
Though I suspect this is redundant; you say a lot about EXTERNAL
elsewhere.

>    and the server
>    MUST perform a private key-based encryption, proving it has the
>    private key associated with the certificate.

private key-based encryption of what?

>    In deployments that require protection of sensitive data in transit,
>    the client and server MUST negotiate a ciphersuite that contains a
>    bulk encryption algorithm of appropriate strength. Recommendations
>    of cipher suites are given in section 9.

What has this to do with certificate-based auth?

>    Following the successful completion of TLS negotiation, the client
>    will send an LDAP bind request with the SASL "EXTERNAL" mechanism.

if it wants to do cert-based auth.

> 9. TLS Ciphersuites

>    A client or server that supports TLS MUST support
>    TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and MAY support other ciphersuites
>    offering equivalent or better protection.

does this imply that it MUST NOT support ciphersuites with poorer
protection?

> 10. Security Considerations

I think you should say that if the connection is already bound when
startTLS is performed, servers SHOULD reject operations that follow
StartTLS other than bind, unbind and abandon (with strongAuthRequired?).

bind before startTLS is an insecure combination, and that an attacker
also may insert a bind before a startTLS when the client expects to do
anonymous operations with TLS.

Or SHOULD the server reject these operations even if the connection is
anonymous?  The attacker could have inserted an anonymous bind, though
that doesn't seem like much of a problem.

> Normative References

>    [ROADMAP] K. Zeilenga, "LDAP: Technical Specification Road Map",
>        draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.

Insert a blank line here.

>    [SASL] Melnikov, A. (editor), "Simple Authentication and Security
>        Layer (SASL)", draft-ietf-sasl-rfc2222bis-xx.txt, a work in
>        progress.

> Informative References

>     [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May

This line is indented one space too much.

> B.1. Access Control Policy
>
>    An access control policy is a set of rules defining the protection
>    of resources, generally in terms of the capabilities of persons or
>    other entities accessing those resources. A common expression of an
>    access control policy is an access control list.

So what's an access control list? :-)

>    Security objects
>    and mechanisms, such as those described here, enable the expression
>    of access control policies and their enforcement.

>    Access control
>    policies are typically expressed in terms of access control factors
>    as described below.

Delete this.  You say this again under B.2, except the "typically" is
left out.  I suggest you move B.2 above B.1, but put the last paragraph
of B.2 under B.1 instead of B.2.

> B.2. Access Control Factors
>
>    A request, when it is being processed by a server, may be associated
>    with a wide variety of security-related factors (section 4.2 of
>    [Protocol]). The server uses these factors to determine whether and
>    how to process the request. These are called access control factors
>    (ACFs). They might include source IP address, encryption strength,
>    the type of operation being requested, time of day, etc. Some
>    factors may be specific to the request itself, others may be
>    associated with the connection via which the request is transmitted,
>    others (e.g. time of day) may be "environmental".
>
>    Access control policies are expressed in terms of access control
>    factors. E.g., a request having ACFs i,j,k can perform operation Y
>    on resource Z. The set of ACFs that a server makes available for
>    such expressions is implementation-specific.

> Appendix C. RFC 2829 Change History
> Appendix D. RFC 2830 Change History

I presume most of these chapters will be deleted from the final RFC?
If so, will you keep the main changes and rename the chapters to
something like "Changes since RFC xxxx"?

-- 
Hallvard