more comments on authmeth-01 draft

[RL Bob Morgan <Bob.Morgan@Stanford.EDU>]

Here are my comments on draft-ietf-ldapext-authmeth-01.txt.  I'm sure some
of them overlap with Jeff's.  Sorry for the delay.

 - RL "Bob" Morgan
   Stanford

---

Quotes from the authmeth draft are written quoted as:

>     authmeth-draft text

My proposed new text is written indented as:

  Proposed new text.

General comments:

(1)  I think this doc is about specifying security-related conformance
requirements for LDAP client and server implementations.  It should
*not* try to specify what deployments should do, as the current
language sometimes apparently does.  Also, it should be explicit that
its protocol descriptions are for illustration only, ie that the
relevant spec documents are authoritative in case of conflicts.

(2)  Big nasty question: Do we really think that CRAM-MD5 is fully
defined as a SASL authentication mechanism by RFC 2195, a document
that does not even mention SASL?  Further, if the application of
CRAM-MD5 to LDAPv3 needs definition, this definition should IMHO be in
a separate doc, not in an applicability statement such as this one.

(3)  Another big nasty one:  The simple bind mechanism is inadequate
in that it does not support a separate authentication identity (as
SASL mechanisms are supposed to) and requires the client identity to
be a DN.  It would be far preferable to specify the use of the SASL
PLAIN mechanism for this purpose.  I know that SASL PLAIN is still in
draft and so this introduces yet another dependency; perhaps this
should motivate getting SASL PLAIN done.

(4)  Throughout sections 6 - 8, the term "user" is used, implying that
the client entity is a person, and furthermore is a person whose
directory entry happens to be in the directory being accessed.  These
are inappropriate assumptions.  Or perhaps I'm unfamiliar with a
broader definition of "user" in the LDAP/X.500 community.  If there is
such a definition, it should be repeated in this doc.  I suggest
replacing "user" with "client entity".

(5)  Many of my comments below have to do with considering the problems
posed by active network attacks in more detail.

The threats listed in section 3 include the possibility of the client
getting data from a source that is not the server it intended to
access, and of the data from the correct server being modified in
transit.  The deployment scenarios in section 4 don't take this threat
into account.  Eg:

>     (1)   A read-only directory, containing no sensitive data,
>           accessible to "anyone". This directory requires no security
>           functions except the service limits.

Obviously, if the client is using the returned directory data for any
sensitive or critical purpose, it has a requirement to ensure that the
server is authentic, and the data has not been modified in transit.
Such assurance might be supplied by digital signatures on the data, in
which case protocol support is not needed.  But in all other cases
protocol support for protecting the integrity of the data and
verifying the identity of the source is required.  It's certainly true
that in today's Internet we use unprotected data for critical purposes
all the time (eg DNS).  I suspect that the comment in some of the
section 4 scenarios:

>  TCP connection hijacking is not currently a problem

is meant to say that we don't have to worry about server impersonation
and data-in-transit modification.  I suggest that in a document
concerned with security requirements this problem can't simply be
swept under the rug.

Perhaps the concern is that if we take server impersonation and
data-in-transit modification as serious threats, we would come to the
conclusion that a mechanism like CRAM-MD5 login is useless since it
doesn't provide protection against these threats.  Obviously this is
not the right conclusion, since CRAM-MD5 does add value over
passwords-in-the-clear.  The point IMHO is that server impersonation
and data-in-transit modification are "active intermediary" attacks,
and we think that such attacks are harder to mount and less prevalent
in today's Internet than passive eavesdropping attacks (or active
client attacks, for that matter).  But as the doc already says, this
is the Internet we're talking about, and they do exist.

---

section 3:

>     2.  Threats to an LDAP directory

This heading seems to be out of place (there isn't a "1.").

>     The basic threats to the LDAP service are:
> 
>      (1)   Unauthorized access to data via data-fetching operations,
> 
>      (2)   Unauthorized access to data by monitoring others' access,
> 
>      (3)   Unauthorized modification of data,
> 
>      (4)   Unauthorized modification of configuration,
> 
>      (5)   Unauthorized use of resources (denial of service), and
> 
>      (6)   Spoofing of directory: Tricking a client into believing
>            that information came from the directory when in fact it
>            did not.

I would write this as:

  (1) Excessive use of server resources leading to denial of
      service for others,

  (2) Unauthorized access to data via data-fetching operations,

  (3) Unauthorized modification of server data or server
      configuration via data-modification operations,

  (4) Theft of reusable client authentication information (e.g.,
      usernames and passwords) by eavesdropping on data in transit,
      leading to threats (2) and (3),

  (5) Unauthorized access to data by eavesdropping on data in
      transit,

  (6) Unauthorized modification of server data or configuration
      via modification of data in transit,

  (7) Supplying incorrect data to the client via modification of
      data in transit,

  (8) Supplying incorrect data to the client by causing it to
      communicate with an impostor host instead of the true
      directory server.

  Threats (1) through (3) are due to hostile clients.  Threats (4)
  through (8) are due to hostile agents on the path between client
  and server, or posing as servers.  Threats (4) and (5) are "passive"
  attacks, while all others are "active" attacks.  

  Threats (6), (7), and (8) are "active intermediary" attacks.  While
  these are a serious problem and have been observed in today's
  Internet, they are also the most difficult to perform, and the most
  difficult to guard against.

>     The LDAP protocol suite can be protected with the following
>     security mechanisms:
> 
>      (1)   Client authentication by means of the SASL mechanism set,
>            possibly backed by the TLS credentials exchange mechanism,
> 
>      (2)   Client authorization by means of access control based on
>            the authenticated identity,
> 
>      (3)   Snoop protection by means of the TLS protocol,
> 
>      (4)   Resource limitation by means of administrative limits on
>            service controls, and
> 
>      (5)   Server authentication by means of the TLS protocol.

The above list of protections doesn't include SASL-oriented
protections.  It should be:

  (1)  Client authentication by means of a SASL mechanism or
  the TLS credentials exchange mechanism,

  (2)  (as is)

  (3)  Integrity and confidentiality protection by means of a SASL
  mechanism or the TLS protocol, using a bulk encryption algorithm of
  appropriate strength,

  (4)  (as is)

  (5)  Server authentication by means of a SASL mechanism or the TLS
  protocol.

section 4:

I propose the following text:

  4.  Deployment scenarios

  The following scenarios are likely to be common for LDAP, and have
  very different security requirements.  In the following,
  "disclosure-sensitive" means data that will cause real damage to the
  owner if revealed; there may be data that is protected but not
  disclosure-sensitive; "integrity-sensitive" means data that will
  cause real damage to the owner or user if it is modified in transit
  or sent by an impostor source (data that can be verified by some
  out-of-band means, e.g. that is digitally signed, would not be
  integrity-sensitive).

  (1) A read-only directory, containing no sensitive data (of either
  kind), accessible to anyone (all stored data in such a directory
  would have to be integrity-protected, e.g. by digital signatures).
  This directory requires no security functions except service limits
  (and any other protections against denial of service attacks).

  (2) A read-only directory, containing integrity-sensitive but not
  disclosure-sensitive data, accessible to anyone.  This directory
  requires secure authentication of the server and
  integrity-protection of the transmitted data to protect against
  active intermediary attacks; otherwise it requires only service
  limits.

  (3) A read-only directory, containing integrity-sensitive but not
  disclosure-sensitive data, where access is controlled based on
  client identity. This directory requires secure authentication of
  the client to support access control; and secure authentication of
  the server and integrity-protection of the transmitted data to
  protect against active intermediary attacks.

  (4) A read-write directory, containing integrity-sensitive but not
  disclosure-sensitive data, where read access is available to any
  client but update access is controlled based on client identity.
  This directory requires secure authentication of the client to
  support update access control; and secure authentication of the
  server and integrity-protection of the transmitted data to protect
  against active intermediary attacks.

  (5) A directory containing integrity-sensitive and
  disclosure-sensitive data, where all access is controlled based on
  client identity.  This directory requires secure authentication of
  client and server, and integrity- and disclosure-protection (i.e.,
  encryption) of the transmitted data.

section 5:

>     Given the presence of the Directory, there is a strong desire to
>     see mechanisms where identities take the form of a Distinguished
>     Name and authentication data can be stored in the directory; this
>     means that either this data is useless for faking authentication
>     (like the Unix "/etc/passwd" file format used to be), or its
>     content is never passed across the wire unprotected - that is,
>     it's either updated outside the protocol or it is only updated in
>     sessions well protected against snooping.
> 
>     At the moment, only implementations using public key cryptography
>     satisfy the requirement that it be useless for faking
>     authentication.

I think this is trying to say that directories are likely to be used
as repositories for authentication data like passwords, and that it's
especially important to protect this data from disclosure in transit.
I'm not sure how this relates to the other content in this section.

To deal with the active attack issue, I suggest the following:

  As discussed above, active intermediary attacks are the most
  difficult for an attacker to perform, and for an implementation to
  guard against.  Methods that protect only against hostile client and
  passive eavesdropping attacks, while not providing complete
  protection, are still useful as a transition step to more
  comprehensive methods, and in situations where the cost of complete
  protection is not justified based on the perceived risk of active
  intermediary attacks.

I would rewrite this section's mandates thus:

  (1) Implementations MUST support password-based authentication 
  using CRAM-MD5, as described in section 7.1.  This provides client
  authentication with protection against passive eavesdropping
  attacks.  It does not provide protection against active intermediary
  attacks.

  (2) Implementations SHOULD support TLS as described in [5].  This
  support SHOULD include client authentication using a password as
  described in section 7.2, and SHOULD include client authentication
  using a certificate (or other TLS-supported credentials), as
  described in section 8.1.  Together, these methods provide
  integrity- and disclosure-protection of transmitted data, and
  authentication of client and server, including protection against
  active intermediary attacks.

Regarding anonymous authentication, it seems unnecessary to mandate
that implementations support it; is anyone out there doing an
implementation that requires identity-based access control for all
operations?  But if we want to say it, here's suggested language:

  (3) Implementations MUST support anonymous client authentication as
  described in 6.  Anonymous client authentication may be combined
  with mechanisms such as TLS which provide protection against
  eavesdropping and active intermediary attacks.

Better IMHO to have this in with the other mandates in section 5 than
embedded in section 6.  In fact better to have all of the "SHOULD
support" language in one place in section 5 rather than scattered
through sections 6 - 8.

section 6:

>    Anonymous authentication is suitable for users who do not intend to
>    modify directory entries and do not require access to protected 
>    attributes or entries.

It is obviously up to those deploying a server to decide what's
suitable and what's not.  How about:

  Directory operations that do not modify entries and do not access
  controlled attributes or entries generally do not require client
  authentication.

>    While there MAY be access control restrictions to prevent access to 
>    directory entries, an LDAP server MUST allow an anonymously-bound 
>    client to retrieve the supportedSASLMechanisms attribute of the root 
>    DSE.

If I want to configure all the clients at my site to use the strong
security protocol of my choice, and lock down my server to require
client authentication for all operations, I think I should be able to
do it.  I think the point this is trying to make is:

  If a site wants to allow LDAP clients to dynamically determine which
  security methods to use to authenticate, it MUST allow an
  anonymously-bound client to retrieve the supportedSASLMechanisms
  attribute of the root DSE.

section 6.2.:

>    An LDAP client MAY use the Start TLS operation [5] to negotiate the
>    use of TLS security [6].  If the client has not bound beforehand and
>    does not present a certificate during TLS negotiation, then the 
>    client is anonymously authenticated.

This should be:

   An LDAP client MAY use the Start TLS operation [5] to negotiate the
   use of TLS security [6].  If the client has not bound beforehand and
   does not perform a bind operation after the TLS session is established,
   client remains anonymously authenticated.

The point being that even if the client presents a cert nothing
changes until it does a bind.

section 7:

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

section 7.1:

>    A user who has a directory entry containing a userPassword attribute
>    may authenticate to the directory by performing a protected password
>    bind sequence based on the CRAM-MD5 mechanism [4].

Storing the client entity's password in a userPassword attribute in a
directory entry is only one way of supporting this mechanism, and only
is applicable if the client entity name is a DN, and the server in
question happens to hold an entry for the client entity.  This model
is used throughout this section, which is a mistake.  I suggest:

  A client entity may authenticate to a directory server using the SASL
  CRAM-MD5 mechanism if the server supports this mechanism and has
  access to the client entity's password (e.g., in a userPassword
  attribute in the entity's directory entry).

This text:

>    "tanstaaftanstaaf" is "b913a602c7eda7a495b4e6e7334d3890". The client
>    will send a bind request, with a different message id, in which the
>    version number is 3, the name field is the name of the user's entry,
>    the authentication choice is sasl, the sasl mechanism name is 
>    "CRAM-MD5", and the credentials field contains a concatenation of 
>    the name of the user's entry, a space character (ASCII 32), and the 
>    digest string.

also makes unwarranted assumptions about how the server will find the
user's password.  It also seems to mandate that the contents of the
bind name field be the same as the SASL authorization ID (CRAM of
course is broken, since it only permits one ID).  Instead, the bind
name field should be ignored, and the authorization ID should identify
the client entity which is authenticating, which can be any octet
string. 

>    The server will then, for each value of the userPassword attribute 
>    in the named user's entry, generate the digest value itself, and 
>    compare the result with the client's presented digest.  If there is 
>    a match, then the server will respond with resultCode success, 
>    otherwise the server will respond with resultCode invalidCredentials.
>    The serverSaslCreds field will be absent.

This should be:

  The server will then compare the client's presented digest value
  with a digest value generated using the server's version of the
  client entity's password.  If the two values match, the server will
  respond with resultCode success; otherwise the server will respond
  with resultCode invalidCredentials.  The serverSaslCreds field will
  be absent.

section 7.2:

This section also makes unwarranted assumptions about how the server
accesses the client entity's password.

   For this authentication procedure to be successful, the client and 
   server MUST negotiate a ciphersuite which contains a cipher 
   algorithm.  The following are NOT permitted:

"cipher algorithm" should be "bulk encryption algorithm" as used in
the TLS protocol spec.


section 8:

section 8.1:

>    A user who has a public/private key pair in which the public key has
>    been signed by a Certification Authority may use this key pair to
>    authenticate to the directory server.  The user's certificate 
>    subject field SHOULD be the name of the user's directory entry, and
>    the Certification Authority must be sufficiently trusted by the 
>    directory server to have issued the certificate.

Once again, it is inappropriate to specify how the server finds any
additional info it needs about the client entity; the SHOULD clause
above should be removed.

>    As deployments will require protection of sensitive data in transit,
>    the client and server MUST negotiate a ciphersuite which contains a 
>    cipher algorithm.  The following are NOT permitted:

As above, "cipher algorithm" should be "bulk encryption algorithm".

>    If the server receives a bind request with the EXTERNAL SASL
>    mechanism name and TLS has not been negotiated, it SHOULD return a
>    resultCode of invalidCredentials.

We addressed this point with the following more comprehensive text in
the ldapv3-tls draft:

  If a TLS session has not been established between the client and server
  (and there is no other external source of authentication credentials),
  or if, during the process of establishing the TLS session, the server
  did not request the client's authentication credentials, the SASL EXTER-
  NAL bind MUST fail, with a result code of inappropriateAuthentication.

Assuming we think this is correct, the authmeth draft should either
refer to this text or repeat it.