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

From: [email-masked]
Date: Thu, 13 Jul 2000 06:27:30 -0400

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-03.txt
	Pages		: 9
	Date		: 12-Jul-00
	
This document describes schema for storing information in support of
user/password authentication in a LDAP [RFC2251] directory.  The
document defines the authPassword attribute type and related schema.
The attribute type is used to store values derived from the user's
password(s) (commonly using cryptographic strength one-way hash).
authPassword is intended to used instead of clear text password
storage mechanisms such as userPassword [RFC2256].  The values of
authPassword may be used to support both LDAP 'simple' and SASL
[RFC2222] password authentication mechanisms [RFC2829].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-authpasswd-03.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-03.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-03.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: Rich Salz <[email-masked]>
Date: Fri, 14 Jul 2000 11:20:33 -0400

"It is recommended that the value of (SHA-1 hashes) be protected as if
they were plaintext.  (Sec 5.2)"

Why?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 14 Jul 2000 09:05:45 -0700

>they were plaintext.  (Sec 5.2)"

Because if a flaw is found in the SHA-1 algorithm, your
directory would be vulnerable to attack if you exposed
SHA-1 values.  The use of SHA-1 (or other algorithms)
offers an additional layer of protection such that if
one layer fails (access controls upon the values), other
layers will offer some protection against immediate
access to the directory.  Reliance upon a single layer
of security is unwise.

I will add some text to the next revision discussing
this security consideration.

Kurt

---

From: Rich Salz <[email-masked]>
Date: Fri, 14 Jul 2000 13:08:57 -0400

> SHA-1 values.

If a flaw is found in SHA-1 then the entire public-key world will fall
apart.

I fail to see the point of hashing something if the hash is perceived no
more secure than the plaintext.  The recommendation should be dropped.
	/r$

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 14 Jul 2000 10:43:54 -0700

>If a flaw is found in SHA-1 then the entire public-key world will fall

Note that in the public key world it is generally recommended to
key private keys protected by multiple layers of security.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 14 Jul 2000 11:15:22 -0700

I have added to "Background and Intended Usage"

Storage schemes often use of cryptographic strength one-way hashing. 
Though the use of one-way hashing reduces the potential that exposed
values will allow unauthorized access to the Directory (unless the 
hash algorithm/implementation is flawed), the hashing of passwords
is intended to be as an additional layer of protection.  It is
RECOMMENDED that hashed values be protected as if they were clear 
text passwords.

and to "Security Considerations"

As flaws may be discovered in the hashing algorithm or with a 
particular implementation of the algorithm, values of AuthPassword
SHOULD be protected as if they were clear text passwords.  When  
values are transferred, privacy protections, such as IPSEC or TLS,
SHOULD be in place.