RE: please publish ldap password policy draft

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

> > >      The compare operation may be used to compare a userPassword. This
> > >      might be performed when a client wishes to verify that user's
> > >      supplied password is correct. An example of this is an LDAP PAM
> >
> > When you say PAM, are you referring to a Posix compliant system that
> > supports the Open Group defined PAM subsystem?  If so, how does
> the compare
> > operation help?  I am having trouble coming up with feasable
> implemtation
> > where the pam_authenticate back-end procedure does not need to
> open a new
> > connection to the LDAP server each time it is called.  Thus I
> don't see how
> > that example shows how you can eliminate the overhead of the
> bind operation.
> >
>
> 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.)

> >
> > >      redirector or an LDAP HTTP authentication redirector. It is
> > >      desirable to use this rather than performing a bind operation in
> > >      order to reduce possible overhead involved in performing a bind.
> > >      ACLs may be used to restrict this comparison from being made.
> > >
> > >      If a server supports this behavior, it MUST comply with the
> > >      following. Otherwise the password policy described in this
> > >      document may be circumvented.
> > >
> > >    12.5.1 During a compare operation on the userPassword attribute
> > >
> > >      The server should
> > >
> > >       1. Check the pwdAccountUnlockTime attribute. If it
> exists, return
> > >          LDAP_UNWILLING_TO_PERFORM to indicate that the account is
> > >          locked.
> > >
> > >       2. If ACLs permit, compare the password.
> >
> > How are the ACLs evaluated?  Are ACLs applied for the user who
> is calling
> > the compare operation or as the one being tested?  I assume the
> former but
> > would like clairification.
> >
>
> ACL are applied for the user who is calling the compare operation.
>
>
> >
> > >
> > >       3. If the password compares true, the server should clear the
> > >          failure counter. If it compares false, it should check to see
> > >
> > >    Behera, Chu, Poitou, Sermersheim  Expires 20 April 2000
> [Page 14]
> > >
> > >
> > >    Internet-Draft             Password Policy           20
> October 1999
> > >
> > >          if it's time to reset the failure counter, if so, set the
> > >          failure counter to 1, otherwise increment the
> failure counter.
> > >          If the failure counter exceeds the allowed maximum value, the
> > >          server MUST lock the user account.
> >
> > 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.

>
> >
> > Suppose a rule exists that says the DN may not bind from the
> hours of 6:00pm
> > to 6:00am?  If a compare operation is performed at 7:00pm,
> should it return
> > true (assuming no other failure conditions?)
>
> This would have to be specified for a "Constrained Login Service".
>
>
> >
> >
> > Should the compare operation return the extented controls that
> indicate if a
> > password is about to expire, etc...?
> >
>
> I think it should. This will be clarified in the next version of
> the document.
>
>
> >
> > 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?

>
> Ludovic.
>
> --
> Ludovic Poitou
> Sun Microsystems Inc.
> Sun-Netscape Alliance - Directory Group - Grenoble - France
>
>
>