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

[Bob Joslin <bobj@cup.hp.com>]

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
bobj@cup.hp.com