Subject: RE: please publish ldap password policy draft

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 21 Oct 1999 16:00:15 -0600

Bob,

<snip>
>>
>> Several 3-tier applications are using LDAP to perform password based
>> authentication. This can be the case of an web-ldap gateway, an
>> Mail server, an
>> FTP server...or the LDAP Pluggable Authentication Module (PAM).
>> It's true that opening a connection for each authentication doesn't really
>> scale.
>> Many of these applications open one connection, authenticate
>> themselves and
>> just check the user password using a compare operation using the
>> User DN and
>> the user password. The compare operation is much faster because
>> you don't have
>> to perform extra checking and computing that the bind operation has to do.
>>
>
>Thanks for the reply.  I do understand that this architecture will greatly
>improve performance of applications that maintain a connection to the LDAP
>server, such as an what you mentioned above.  My point is that I don't think
>LDAP PAM is a good example of this.  Most examples you provied above are
>servers (which can easily maintian the connection to the LDAP server.)  I've
>never seen an implementation of PAM that works like a server (though it's
>certianly possible.)

Good point, I had imagined a future where a PAM redirector *could* work this way.  For now it looks like it's more confusing than it's worth, we can take it out of the next version.

>> >
>> > Am I correct in understanding that you don't examine all password policy
>> > rules for a compare operation?  For example, suppose that the
>> entry has a
>> > login time of day restriction (defind outside the scope of this schema.)
>>
>> This is out of the scope of this draft. We're thinking about such
>> services but
>> they are not dealing with passwords. So they should appear in a separate
>> document.
>>
>
>Since 12.5 starts out by saying this feature is useful for authentication
>redirectors, I'm a bit concerned that the redirector may authenticate a user
>because a compare succeeded when other policy rules would have caused a
>failure.  I guess I'm concerned about promoting this type of architecture
>for those reasons.  But this is a subjective view.

I think we could state something in the draft like: "implementors should be aware that other authentication related policies (specifically login policies) could also be in force and that those policies may add additional behavior or restrictions to this operation".

We talked about including things like a allowed login time map, whether login was dis/enabled and so on, but decided it was removed enough from 'passwords' that it deserved its own draft. When that draft is written, this one will definitely reference it here.

>> > How should zero length password strings be treated?  In a bind
>> operation the
>> > null string is a special syntax that means bind anonymously.
>> What does it
>> > mean for a compare?
>>
>> It doesn't mean anything. You cannot compare with zero length
>> password. The
>> client should not call the compare operation if it
>> doesn't want to perform authentication.
>
>As one example, RFC 2256 defines userPassword to be an Octet String.  And if
>I am not mistaken, that means that the userPassword attribute can have zero
>length.  Thus a compare operation of a zero length string against a zero
>length userPassword attribute should succeed, no?

This is a problem which needs to be addressed somewhere. I don't feel like this is *really* the right place to do it because this document only means to say "if you're going to allow the compare operation to be used on the userPassword, you better be aware of and follow these password policies", it wasn't meant to patch this little problem. But... I guess since the definition of userPassword doesn't prevent one from storing a 0 length value, and since this is the only document that discusses the compare operation on the userPassword value, it could include a note to server implementors to not allow comparisons of empty values. Any other suggestions?

Jim

---

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 21 Oct 1999 18:16:04 -0600

>>> "Kurt D. Zeilenga" <[email-masked]> 10/21/99 9:06:43 AM >>>

>This draft proposes changes the behavior of userPassword attribute
>which are incompatible with the RFC2256 defined schema rules:
>
>  5.36. userPassword   
>    ( 2.5.4.35 NAME 'userPassword' EQUALITY octetStringMatch  
>      SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
>   Passwords are stored using an Octet String syntax and are not
>   encrypted.
>
>a) compare must use octetStringMatch

This draft avoids talking about how the actual comparison takes place. It only states that *if* a comparison happens, it better take the password policy information into account and behave accordingly.

>b) servers cannot encrypt (or hash) the password and store
>   it in userPassword.

I don't want to use this document to re-hash (he he) the whole 'syntax of userPassword' discussion we've had twice now. Suffice it to say, this draft was written in a way that supports the de facto standard way some servers are currently storing values of userPassword. If a server does not support storing userPassword as described in RFC2307, it should only allow the value of 'CLEARTEXT' to be set in the pwdDefaultStorageScheme attribute.

When a draft is submitted, which defines a 'crypt' attribute type option, and formalizes a standard way for LDAP servers to store hashed or encrypted passwords, this document will be updated to take that into account.

>The draft relies on LDAPv3 mechanisms (controls).  The
>draft, however, does not state that any protocol restrictions
>exist.  If LDAPv2 is to be supported, the document should state
>how a server should respond with the client attempts to bind
>or is bound using LDAPv2.

...being discussed on another thread...

>The draft uses results not allowed by RFC2251.  In particular,
>constraintViolation is not allowed in a bindResponse.

We discussed this and it was decided that in this case, the user was breaking a constraint set by the password policy. On the other hand, constraint violation is grouped with the attribute errors, not the security errors...

>Editing issues:
>  The draft should not be written in terms of the LDAP C API draft.
>  Please use names defined by RFC2251 instead of LDAP C API defines.
>	ie: use constraintViolation not LDAP_CONSTRAINT_VIOLATION

I agree, we should change them as you suggest.

Jim

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 21 Oct 1999 21:54:01 -0700

At 06:16 PM 10/21/99 -0600, Jim Sermersheim wrote:
>This draft avoids talking about how the actual comparison takes place.

Well, I argue that you actual comparison (and other simple
operations) acting upon userPassword are already well defined
by existing specifications.

>I don't want to use this document to re-hash (he he) the whole 'syntax of userPassword' discussion we've had twice now.

That wasn't my point.  userPassword is what it is.  Two standard
track documents should not be in direct conflict.  The conflict
should be resolved before the I-D is progressed.

I believe it would be wise to not meantion userPassword in your
draft.  I suggest adding an attribute type to the policy which
describes the attribute type that stores the hashed password
value.  Then, if implementors and/or admins choose to abuse
userPassword, they do so... but at their own risk.

- Kurt

----
Kurt D. Zeilenga <[email-masked]>
OpenLDAP Project <http://www.OpenLDAP.org/>

---

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 22 Oct 1999 09:05:33 -0600

I see your point now.  To paraphrase, you would like to see the word userPassword removed from the document and replaced by newly defined password storage attribute.  Alternately, I suppose the document could just refer to "the attribute holding the user's password", and leave it an implementation detail. That leaves an interoperability hole though.

There's a draft in the works that defines a 'crypt' attribute subtype which can be used with the userPassword attribute.  I'd like to just defer to the outcome of that for the definition of stored hashed passwords.

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 10/21/99 10:54PM >>>

- Kurt

----