[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Comments on draft-zeilenga-ldap-authpasswd-01.txt
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