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

From: "Salter, Thomas A" <[email-masked]>
Date: Wed, 22 Dec 1999 10:51:50 -0500

It's not clear from this draft who has access to the clear text password.

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.

Perhaps there should be another syntax, authPasswordMatchValue defined as:
    scheme "$" [ info ] "$" clearTextValue.

It would also be able to explain how this attribute is used in conjunction
with an Ldap bind (or refer to an appropriate document).

 > -----Original Message-----
 > From: [email-masked] [mailto:[email-masked]]
 > Sent: Wednesday, December 22, 1999 6:57 AM
 > Cc: [email-masked]
 > 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:
	[email-masked].
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.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 22 Dec 1999 09:06:10 -0800

>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.

>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".

>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.

>implementation to automatically retrieve the ASCII version of the

----
Kurt D. Zeilenga		<[email-masked]>
Net Boolean Incorporated	<http://www.boolean.net/>

---

From: "Salter, Thomas A" <[email-masked]>
Date: Wed, 22 Dec 1999 13:43:44 -0500

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.

 > From: Kurt D. Zeilenga [mailto:[email-masked]]
 > Sent: Wednesday, December 22, 1999 12:06 PM
 > To: Salter, Thomas A
 > Subject: RE: I-D ACTION:draft-zeilenga-ldap-authpasswd-00.txt
 > 
 >

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Wed, 22 Dec 1999 14:50:35 -0800

I have a clarification question.
In section 3, "Background and Intended Use", it says:

  authPassword is intended to be used to store hashed password values
  for authentication purposes.  The attribute may be used by servers to
  implement LDAP simple bind and SASL [RFC 2222] user/password
  mechanisms such as DIGEST-MD5 [DIGEST-MD5].

Which "servers" are you referring to? In particular, is it intended to be
used by the LDAP server storing it for authentication purposes, or by other
servers?

Paul

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 22 Dec 1999 16:02:01 -0800

At 02:50 PM 12/22/99 -0800, Paul Leach (Exchange) wrote: 
> Which "servers" are you referring to? In particular, is it intended
> to be used by the LDAP server storing it for authentication purposes,
> or by other servers?

To clarify:
	The attribute may be used by LDAP servers to implement
	simple bind and SASL user/password mechanisms such as
	DIGEST-MD5.

That is, an LDAP server may use authPassword for in-directory
storage of authentication information.  AuthPassword may be
used for other applications, but that is not its intended use.

Note also that I am using the term "implement" in the general
sense.  I presume that LDAP implementors will leverage available
SASL services.

----

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Wed, 22 Dec 1999 16:33:26 -0800

> Sent: Wednesday, December 22, 1999 4:02 PM
> To: Paul Leach (Exchange)

Sorru, my question wasn't quite precise enough. Is it intended for use by
any other server, including other LDAP servers, than the one that stores the
authPassword attribute for a given a user object?

Paul

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 22 Dec 1999 16:56:28 -0800

At 04:33 PM 12/22/99 -0800, Paul Leach (Exchange) wrote: 
>Sorru, my question wasn't quite precise enough. Is it intended for use
>by any other server, including other LDAP servers, than the one that
>stores the authPassword attribute for a given a user object?

The attribute is primarily intended to be used by any server which
holds the entry containing the attribute.  This could be a master
or one of its replicas (shadows).  Through use of compare and
AuthPasswordMatch, it is also possible that a server-in-the-middle
(proxy) could make use the attribute.