Subject: Comments on draft-zeilenga-ldap-authpasswd-01.txt

From: "Bob Joslin" <[email-masked]>
Date: Tue, 15 Feb 2000 13:27:50 -0800

Hi Kurt,

I have a few comments and questions about your draft.  I appreciate your
efforts to standardize this area.

3.  Background and Intended Use

  The authPassword attribute type is intended to be used to store hashed
  password values for authentication purposes.  The attribute type
  supports multiple storage schemes and provides an equality matching
  rule which allows clients to assert that a clear text password
  "matches" one of the attribute's values.  Storage schemes may make use
  of one-way hashing and encryption.

  The attribute may be used by LDAP servers to implement simple bind and
  SASL [RFC 2222] user/password mechanisms such as DIGEST-MD5 [DIGEST-
  MD5].

I may be a bit green in understanding DIGEST-MD5, but why would having an
already-hashed password help an LDAP server implement DIGEST-MD5 SASL binds?
Doesn't DIGEST-MD5 authentication require the server to generate a nonce
each time a bind is performed?  Thus, how is having a pre-hashed value
useful?

4.1. authPasswordSyntax

    ( authPasswordSyntaxOID
      DESC 'authentication password syntax' )

  Values of this syntax are encoded according to the following BNF:

    authPasswordValue = scheme "$" [ info ] "$" hashedValue
    scheme = <an IA5 string of letters, numbers, and "-", "_", and "/">
    info = <a base64 encoded value>
    hashedValue = <a base64 encoded value>

  where scheme describes the hash mechanism, info is a scheme specific,
  and hashedValue is the hashed value.  The info field is often a salt.

If the authPasswordSyntax requires a hashedValue, why not change the name
of the attribute to "hashPassword" instead of "authPassword?"  I would
think "hashPassword" would be a more descriptive name.  Besides, if I'm
not mistaken, the "authPassword" could not be used to perform DIGEST-MD5
authentication anyway.  (Please correct me if I don't understand this.)

5.      Schemes

  This section describes the "MD5", "SHA1", and "SASL/DIGEST-MD5".
  Other schemes may be defined by other documents.  Schemes starting
  with string "SASL/" indicate association with a SASL mechanism.
  Schemes which are not described by standard track documents SHOULD be
  named with a leading "X-" or, if associated with a SASL mechanism,
  "SASL/X-" to indicate they are a private or implementation specific
  extension.  Scheme names are case insensitive.

As Mark Smith pointed out, you omitted "crypt".  I reviewed your reply but
still think we would like to see your draft mention "crypt."  We work on a
project that implements RFC 2307.  Many of our customers would like to
be able to have a chose of security mechanisms, balancing that with
the functionality and security they receive.  Having a standard mention
this would increase the likelihood they'd have that choice.

Thanks.

Bob Joslin
Hewlett-Packard
[email-masked]

---

From: Mark Wahl <[email-masked]>
Date: Tue, 15 Feb 2000 15:37:38 -0600

> each time a bind is performed?  Thus, how is having a pre-hashed value

You might want to take a look at draft-wahl-ldap-digest-example-00.txt, which
describes how one vendor implements DIGEST-MD5 with hashed passwords.

Mark Wahl, Directory Product Architect
Innosoft International, Inc.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 15 Feb 2000 15:31:27 -0800

>already-hashed password help an LDAP server implement DIGEST-MD5 SASL binds?

DIGEST-MD5 is designed such that servers need not store the clear
text password; they may store a derived value instead.  The
authPassword draft describes how this derived value (with
other information useful in implementing the mechanism) may
be stored in the directory.  See DIGEST-MD5, Section 3.9.

>still think we would like to see your draft mention "crypt."

This document is intended for the standard track.  Inclusion
of a crypt scheme, IMO, is incompatible with this intent for
reasons previously stated.  I beleive it appropriate to handle
introduction of a crypt scheme as an extension described by a
separate document not on the standard track.