RE: I-D ACTION:draft-zeilenga-ldap-authpasswd-00.txt

["Salter, Thomas A" <Thomas.Salter@unisys.com>]

Thanks.  You've clarified it for me.  

Contrary to what I suggested before, I think the match rule syntax should
specify either:
a. the algorithm and the clear text value, or
b. just the clear text value.

In case a, you would use the algorithm to choose among several stored values
which specify different algorithms.  In case b, you would need to try them
all.

The salt can always be obtained from the stored value.  

Use b since it's simpler.  Then the relationship to bind is obvious since
you only need a clear text password and not any algorithm information.


 > -----Original Message-----
 > From: Kurt D. Zeilenga [mailto:kurt@boolean.net]
 > Sent: Wednesday, December 22, 1999 12:06 PM
 > To: Salter, Thomas A
 > Cc: ietf-ldapext@netscape.com
 > Subject: RE: I-D ACTION:draft-zeilenga-ldap-authpasswd-00.txt
 > 
 > 
 > At 10:51 AM 12/22/99 -0500, Salter, Thomas A wrote:
 > >It's not clear from this draft who has access to the clear 
 > text password.
 > 
 > The value of authPassword is designed to store a hash of the user's
 > password.  The values of authPassword may be protected by ACLs
 > or other mechanisms.
 > 
 > >The definition of authPasswordMatch uses the same syntax as 
 > the authPassword
 > >attribute.  One of these must contain the clear text 
 > password if the server
 > >is going to recompute the hash.
 > 
 > I may have defined the match incorrectly.  I intended the client to
 > only provide the clearTextValue and for the server to do
 > "The Right Thing".
 > 
 > >It would also be able to explain how this attribute is used 
 > in conjunction
 > >with an Ldap bind (or refer to an appropriate document).
 > 
 > I would be willing to add a section describing how the attribute
 > MAY be used with LDAP bind.  I do not want to limit bind to any
 > particular storage mechanism or limit any particular storage
 > mechanism to LDAP bind.  That is, I intend to maintain clear and
 > distinct separation of authentication protocol and storage
 > of authentication information.
 > 
 > 
 > > > -----Original Message-----
 > > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
 > > > Sent: Wednesday, December 22, 1999 6:57 AM
 > > > Cc: ietf-ldapext@netscape.com
 > > > Subject: I-D ACTION:draft-zeilenga-ldap-authpasswd-00.txt
 > > > 
 > > > 
 > > > A New Internet-Draft is available from the on-line 
 > > > Internet-Drafts directories.
 > > > 
 > > > 
 > > > 	Title		: LDAP Authentication Password Attribute
 > > > 	Author(s)	: K. Zeilenga
 > > > 	Filename	: draft-zeilenga-ldap-authpasswd-00.txt
 > > > 	Pages		: 7
 > > > 	Date		: 21-Dec-99
 > > > 	
 > > > This document describes schema for storing authentication 
 > > > passwords in
 > > > a LDAP [RFC2251] directory.  The document provides 
 > schema definitions
 > > > for authPassword and related schema definitions.  The 
 > authPassword is
 > > > meant to used instead of clear text password storage 
 > mechanisms such
 > > > as userPassword [RFC2256].  The attribute may be used to 
 > store SASL
 > > > [RFC2222] authentication passwords in entries of a directory.
 > > > 
 > > > A URL for this Internet-Draft is:
 > > > http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-authp
 > >asswd-00.txt
 > >
 > >Internet-Drafts are also available by anonymous FTP. Login 
 > with the username
 > >"anonymous" and a password of your e-mail address. After logging in,
 > >type "cd internet-drafts" and then
 > >	"get draft-zeilenga-ldap-authpasswd-00.txt".
 > >
 > >A list of Internet-Drafts directories can be found in
 > >http://www.ietf.org/shadow.html 
 > >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
 > >
 > >
 > >Internet-Drafts can also be obtained by e-mail.
 > >
 > >Send a message to:
 > >	mailserv@ietf.org.
 > >In the body type:
 > >	"FILE /internet-drafts/draft-zeilenga-ldap-authpasswd-00.txt".
 > >	
 > >NOTE:	The mail server at ietf.org can return the document in
 > >	MIME-encoded form by using the "mpack" utility.  To use this
 > >	feature, insert the command "ENCODING mime" before the "FILE"
 > >	command.  To decode the response(s), you will need "munpack" or
 > >	a MIME-compliant mail reader.  Different MIME-compliant 
 > mail readers
 > >	exhibit different behavior, especially when dealing with
 > >	"multipart" MIME messages (i.e. documents which have been split
 > >	up into multiple messages), so check your local documentation on
 > >	how to manipulate these messages.
 > >		
 > >		
 > >Below is the data which will enable a MIME compliant mail reader
 > >implementation to automatically retrieve the ASCII version of the
 > >Internet-Draft.
 > >
 > >
 > 
 > ----
 > Kurt D. Zeilenga		<kurt@boolean.net>
 > Net Boolean Incorporated	<http://www.boolean.net/>
 >