RE: authmeth-09 comments

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

I'm surprised that a DSS cipher suite is required when using TLS. This was acceptable while the RSA patent was in force but it is surely not acceptable now. Has anyone ever seen a DSS certificate?

Ron

-----Original Message-----
From: owner-ietf-ldapbis@OpenLDAP.org
[mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Hallvard B Furuseth
Sent: Sunday, 4 January 2004 02:36
To: ietf-ldapbis@OpenLDAP.org
Subject: authmeth-09 comments


authmeth-09 says:

> 1. Introduction

>    (6) Unauthorized or excessive use of resources (denial of service),
>        and

Remove 'or', and maybe 'unauthorized' as well.  Unauthorized use of
resources need not be denial of service, and in any case I'm not
sure if it's relevant whether the use of resources is unauthorized
or not.

>    (7) Spoofing of directory: Tricking a client into believing that
>        information came from the directory when in fact it did not,
>        either by modifying data in transit or misdirecting the client's
>        connection. Also, tricking a client into sending privileged
>        information to a hostile entity that appears to be the directory
>        but is not.

s/tricking a client/tricking a user or client/.  I believe tricking
users is the worst problem of the two, or at least the one which is
hardest to prevent.

>    Threats (1), (4), (5) and (6) are due to hostile clients. Threats
>    (2), (3) and (7) are due to hostile agents on the path between
>    client and server or hostile agents posing as a server.

I think it should be mentioned that threat (7) - and maybe (2) and
(3)? - can also be in part due to IP spoofing.

>    LDAP can be protected with the following security mechanisms:
>
>    (1) Client authentication by means of the Secure Authentication and
>        Security Layer (SASL) [SASL] mechanism set

...or LDAP's simple password mechanism...

(or maybe you should just delete the part about SASL and just say
'Client authentication'.)

>    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 mechanisms like the LDAP
>    simple bind using clear text passwords that provide inadequate
>    security for most circumstances.

Hey, don't hassle Simple Bind!  It's fine with TLS, and the best
alternative for a lot of us.  I suggest:

     or worse, they will support only clear text passwords that
     provide inadequate security for most circumstances.

> 3. Bind Operation

>    The new LDAP association
>    is established upon successful completion of the authentication
>    exchange.

Remove 'successful'.  A failed bind establishes a new association
too.

> 3.3.3. Octet where negotiated security mechanisms take effect
>
>    When negotiated, SASL security layers take effect following the
>    transmission by the server and reception by the client of the final

...success...?

>    BindResponse in the exchange.

> 4.1.3. TLS Version Negotiation
>
>    Negotiating the version of TLS or SSL to be used is a part of the
>    [TLS] Handshake Protocol. Please refer to that document for details.

SSL is not mentioned elsewhere in the document.  Either remove it,
or explain.  Is SSL a TLS version now?

> 4.2.1. TLS Connection Establishment Effects

>    The decision to keep or invalidate the established authentication
>    and authorization identities in place after TLS is negotiated is a
>    matter of local server policy. If a server chooses to invalidate
>    established authentication and authorization identities after TLS is
>    negotiated, it MUST reply to subsequent valid operation requests
>    until the next TLS closure or successful bind request with a
>    resultCode of strongAuthRequired to indicate that the client needs
>    to bind to reestablish its authentication. If the client attempts to
>    bind using a method the server is unwilling to support, it responds
>    to the with a resultCode of authMethodNotSupported (per [Protocol])
>    to indicate that a different authentication method should be used.

As Kurt and I said in the thread about this, 'invalidating' the
association belongs in a separate section, not a TLS-specific one.
Also, the "MUST" above should be removed - there should simply be
an explanation of how invalidated associations (normally?) behave.
The same goes for invalidation after TLS closure below.

> 8. LDAP Association State Transition Tables

The more I look at this section, the less I like it...  How about
moving it to a non-normative appendix?  I *really* hope this section
doesn't contain any information which must be read and can't be seen
elsewhere in the draft.

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

Previously I asked if this implied that implementations MUST NOT
support weaker ciphersuites.  Kurt later mentioned use of null
ciphersuites, so I don't think so.  Therefore, I assume 'offering
equivalent or better protection' should be removed, though maybe you
should add "SHOULD NOT support weaker ciphersuites unless other
protection (such as a SASL security layer) is in place"?

----------------

Editorial comments:

In my 'authmeth-08 comments' message, I said:

> I don't know if this will happen, but the text "UTF-8" is lost if the
> RFC Editor replaces [UTF-8] with [RFCnnnn].  If so, you need to write
> 'UTF-8 [UTF-8]'.

Never mind.  Kurt says that the RFC Editor shouldn't do that.

> INTERNET-DRAFT                                      Editor: R. Harrison
> draft-ldapbis-authmeth-09.txt                              Novell, Inc.

s/draft-/draft-ietf-/.

> Obsoletes: 2251, 2829, 2830                             5 December 2003

s/Obsoletes: /Obsoletes: RFC /.

> Status of this Memo

>    Technical discussion of
>    this document will take place on the IETF LDAP Extension Working

s/Extension/Revision/.

> 1.1. Relationship to Other Documents

The document header says 'Obsoletes:... 2251', but this section does
not mention that.

> 2.1. Glossary of Terms

>      - "TLS connection" refers to a TLS-protected LDAP connection.

Suggest [TLS] reference for 'TLS-protected'.

> 3.3.2. SASL authentication initiation and protocol exchange

>    A challenge is indicated by the server
>    sending a BindResponse with the resultCode set to
>    saslBindInProgress. This indicates that the server requires the
>    client to send a new bind request, with the same sasl mechanism to
>    continue the authentication process.

Remove the comma (or add a comma after 'mechanism').

> 3.3.4. Determination of supported SASL mechanisms
>
>    An LDAP client may determine the SASL mechanisms a server supports
>    by performing a

...base object...

>    search request

...with filter (objectClass=*)...
(and I suggest you remove 'request', BTW)

>    on the root DSE

...(See [Models] Section 5.1)...

>    , requesting the
>    supportedSASLMechanisms attribute. The values of this attribute, if
>    any, list the mechanisms the server supports

...in the current LDAP session state.

> 3.3.6.2. Explicit Assertion

>    The server MUST

...verify...

>    that the client's authentication identity as
>    supplied in its TLS credentials is permitted to be mapped to the
>    asserted authorization identity.

> 3.3.6.4 Authorization Identity Syntax

>    The dnAuthzId choice allows clients to assert authorization
>    identities in the form of a distinguished name to be matched in
>    accordance with the distinguishedName matching rule [Syntaxes].

s/distinguishedName/distinguishedNameMatch/.

>    compared octet-wise. The format of utf8string is defined as only a

s/utf8string/userid/.

> 4. Start TLS Operation
>
>    The Start Transport Layer Security (Start TLS) operation defined in
>    section 4.13 of [Protocol] provides the ability to establish [TLS]
>    on an LDAP association.

s/association/connection/.  The TLS establishment will survive
replacing an association with a new one.  (The same change a few
other places, commented later.)

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

s/association/connection/ as in section 4.

> 4.1.1. Start TLS Request

>    The client MAY send the Start TLS extended request at any time after
>    establishing an LDAP connection, except:
>    (...)
>       - when there are one or more outstanding LDAP operations on the
>         connection.

Nitpick: I would remove 'one or more'.  The sentence is fine without it.

>    The result of violating any of these requirements is a resultCode of
>    operationsError, as described in [Protocol] section 4.13.2.2. Client
>    implementers should note that it is possible to receive a resultCode
>    of success for a Start TLS operation that is sent on a connection
>    with outstanding LDAP operations and the server has sufficient time

s/and/if/.

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

Last sentence is redundant, remove it.  I'd remove 'in particular' too.

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

I would say

     ... before sending _some_ other request, ... before performing
     _that_ request, ... (without the '_'s:-)

since the server may accept some requests without TLS, but require TLS
for others.

>    the server
>    MUST reject that request by sending a resultCode of
>    confidentialityRequired or strongAuthRequired.

> 4.1.4. Discovery of Resultant Security Level
>
>    After a TLS connection is established on an LDAP association, both

s/association/connection/ as in section 4.

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

s/association/connection/ as in section 4.

> 4.2.3. TLS Connection Closure Effects
>
>    The decision to keep or invalidate the established authentication
>    and authorization identities in place after TLS closure is a matter
>    of local server policy. If a server chooses to invalidate
>    established authentication and authorization identities after TLS is
>    negotiated,

No, after TLS closure.

>    it MUST reply to subsequent valid operation requests
>    until the next TLS closure or successful bind request with a

s/TLS closure or successful bind/successful StartTLS or bind/.

> 5.2. Anonymous Authentication and TLS
>
>    An LDAP client may use the Start TLS operation (section 5) to
>    negotiate the use of [TLS] security. 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.

This belongs in a general TLS section, not about just anonymous
connection, if you generalize it a bit and say that the association
(authentication and authorization ID) are not affected by Start TLS.

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

Move those two paragraphs, they are not related to anonymous auth.

> 6. Password-based Authentication

>    The transmission of passwords in the clear--typically for
>    authentication or modification--poses a significant security risk.
>    This risk can be avoided by using SASL bind [SASL] mechanisms that
>    do not transmit passwords in the clear and by negotiating transport
>    or session layer confidentiality services before transmitting
>    password values.

s/and/or/.

> 6.2. Digest Authentication

>    syntactically simple strings and semsantically simple realm and

s/semsantically/semantically/.

> 6.3.1. simple Authentication Choice

The text in this section is not specific to TLS, and should not be a
subsection of '6.3. simple authentication choice under TLS encryption'.

> 10. Security Considerations

>    Security issues are discussed throughout this memo; the
>    (unsurprising) conclusion is that mandatory security is important
>    and that session confidentiality protection is required when
>    snooping is a problem.

I would s/(unsurprising)/unsurprising/.

>    Servers are encouraged to prevent modifications by anonymous users.

This is now stated in [Protocol] security considerations, where it
belongs.  Since this text is about modify requests and not about
bind/StartTLS, it does not belong in [Authmeth].

>    A connection on which the client has not performed the Start TLS
>    operation

or uses something like IPSec

>    or negotiated a suitable SASL mechanism for connection
>    integrity and encryption services is subject to man-in-the-middle
>    attacks to view and modify information in transit.

> 10.1. Start TLS Security Considerations

>    Once established, TLS only provides for and ensures confidentiality
>    and integrity of the operations and data in transit over the LDAP
>    association--and only if the implementations on the client and

s/association/connection/ as in section 4.

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

...data...                [added according to rfc2828]

>    integrity protection,

> Acknowledgements
>
>    This document combines information originally contained in RFC 2829
>    and RFC 2830.

The document header says 'Obsoletes:... 2251', but this section does
not mention that.

> Normative References

I think the references would be easier to search if the descriptive
text was intended all the way past the reference names.

>        (http://www.unicode.org/reports/tr27/) and by the "Unicode

s/"/"/.  The former is an 8-bit character.

> Author's Address
>
>    Roger Harrison
>    Novell, Inc.
>    1800 S. Novell Place
>    Provo, UT 84606

The country name is missing.

> F.7. Changes for draft-ldap-bis-authmeth-09

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

s/-/ -- /.  The former is an 8-bit character.

-- 
Hallvard