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

From: [email-masked]
Date: Wed, 22 Dec 1999 06:56:32 -0500

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-authpasswd-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: [email-masked] (Mark C Smith)
Date: Thu, 23 Dec 1999 10:01:14 -0500

> [RFC2222] authentication passwords in entries of a directory.

Kurt, I am glad you took the initiative to produce this document.  I
would note that IMHO the extended use of userPassword that was pioneered
by Netscape and others was a good thing because it allowed off the shelf
LDAP client applications -- even ones that set passwords -- to work in
the face of one-way hashed password values.  But formalizing this is a
good idea.

Some comments on your draft:

1) I would be more careful about the use of the term "encryption."  A
one-way hash is not encryption in my view.  Do you intend to support
encrypted, reversible storage schemes as well?  I see no reason not to,
although obviously there may be key distribution issues and so on for a
given scheme.

2) Why did you not include a crypt scheme?

3) For transition purposes (for those who have deployed with one-way
hashed userPassword values), it would be nice to use the same format
with the new authPassword, i.e., {SCHEME}HASHED-VALUED

3) The heading for section 4.3 is "supportedAuthSchemes" but the text
defines an attribute type called supportedAuthPasswordSchemes.

4) In section 4.5 you define an authPasswordObject auxiliary class which
includes authPassword as a required attribute.  I feel strongly that the
attribute should be optional as this simplifies client and server
interactions when adding or deleting authPassword values.

5) Why is MD5 a MUST and SHA1 a SHOULD for servers that support LDAP
simple bind?

6) In the security considerations, we should describe in more detail how
servers and clients should protect these values.  For example, for
auditing purposes and to enforce password policies, it is common to
disallow compare operations and required that all password tests come
through bind operations.

7) I assume if more than one authPassword value is present, a password
presented by a client is tried against all of the values.  This should
be clarified.

-- 
Mark Smith
iPlanet Directory Architect / Sun-Netscape Alliance
My words are my own, not my employer's.   Got LDAP?

---

From: Ludovic Poitou <[email-masked]>
Date: Thu, 23 Dec 1999 16:59:40 +0100

> with the new authPassword, i.e., {SCHEME}HASHED-VALUED

Yes. And it would be nice to use the same identifiers (SHA instead of SHA1).

> presented by a client is tried against all of the values.  This should

Would it be possible to have the same password hashed with different schemes ?
If so, how to deal with passwords modifications and deletion should be clarified.

Ludovic.

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 23 Dec 1999 10:47:48 -0800

>Yes. And it would be nice to use the same identifiers (SHA instead of SHA1).

If I were to use RFC 2307 syntax, I would have left identifiers alone.

However, since I introduced a new syntax, the authPassword
schemes names and RFC 2307 schemas do not directly relate.
My SHA1 schema is more like SSHA than SHA as it supports an optional
seed.

>Would it be possible to have the same password hashed with different schemes ?

Yes.

>If so, how to deal with passwords modifications and deletion

Like userPassword, authPassword is a user attribute and hence
has no special behavior (except that defined per schema) in
respect to interrogation and update operations.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 23 Dec 1999 10:47:39 -0800

>Some comments on your draft:

Much appreciated!

>1) I would be more careful about the use of the term "encryption."

I concur.

>A one-way hash is not encryption in my view.

I will reword section 4.4.

>Do you intend to support encrypted, reversible storage schemes as well?

authPassword is intended to be used with non-reversible storage
schemes AND to be flexible.

>2) Why did you not include a crypt scheme?

Two reasons:
 1) traditional crypt(3) (DES based) passwords are easily attacked
 2) enhanced crypt(3) (? based) passwords are platform specific

The only rational in favor of including them was to support migration
from UNIX based authentication to LDAP based authentication systems.
I would much rather see migrate_unix.pl take the particular pw_passwd
encoding used on a give box and map this into appropriate authPassword
schemes (then to support platform specific schemes).

For those directory managers who want tight integration, a number
of vendors are offering ties to existing external password stores.
For example, OpenLDAP 1.x support "{UNIX}kdz" (the server fetches
the kdz entry from /etc/password (or replacement) and use that
value for the comparison.   We intend to define an authPassword
scheme to support continued use of such external password stores.
I hope that this can be done is a generally useful way (non-platform
specific).

>with the new authPassword, i.e., {SCHEME}HASHED-VALUED

I definitely did consider just reusing the {SCHEME}HASHED-VALUED
syntax offered by RFC 2307.  I choose to use a different syntax
to resolve some nagging issues with the syntax.  In particular,
I wanted to add support:
	additional schema-specific information in a general way
	combine non-salted and salt variants ({MD5} vs {SMD5})

I weighted the expense of s/userPassword/authPassword/ change
against the expense of a new authPassword syntax.  I realized that
the expense was about the same, change is change.

On the other hand (for those who thing the change is significantly
more expensive), I would argue that we should not penalize those
vendors who did not abuse userPassword and desire to implement
authPassword by requiring some signficant change to all those who
want to support authPassword.

In addition, I plan on submitting additional drafts (or extend
this draft) such to support server side generation of hashed values
of new passwords without abusing "user" (non-operational) nature
of this attribute.

>defines an attribute type called supportedAuthPasswordSchemes.

Thanks.

>interactions when adding or deleting authPassword values.

I originally modeled authPasswordObject after simpleSecurityObject.
However, I later changed authPasswordObject to be a simple mix in class.
I concur that for this use that MAY would be more appropriate.

If specific objectclasses were needed to imply specific uses of
authPassword, these may be defined as well.

>5) Why is MD5 a MUST and SHA1 a SHOULD for servers that support LDAP

I wanted to MUST one and only one scheme for use with simple bind.
I choose MD5 as it provided a reasonable level of protection from
brute force attack AND implementations are available which are
highly portable and in the public domain.  Though SHA1 offers
better protection against brute force attack, I could not find
a implementation which as both highly portable and in the public
domain.  (If you know of such, send me a URL).

>servers and clients should protect these values.

Servers and clients should protect these values as if they were
plain text passwords.  The "more details of how", I believe, is
implementation specific.

>For example, for

As with any attribute, authPassword is subject to access controls.

>presented by a client is tried against all of the values.  This should

I specifically wanted to divorce password storage from password use.
A server may use a subset of the values to support a particular
authentication process.  A server may use values from multiple sources
to support an authentication process.