Subject: Re: proposed standard for password syntax

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 27 Oct 1999 15:07:24 -0700

Like it or not, userPassword is what it is.  Its syntax, encoding,
matching rules, etc. are well defined by RFC2256 and, I presume,
X.500 specifications.  As such, I believe that a proposal for a
replacement attribute type would be more appropriate.

Kurt

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

---

From: "Pat Felsted" <[email-masked]>
Date: Wed, 27 Oct 1999 17:21:56 -0600

The definition of a password is an octet string, however many systems have overloaded the syntax to add hashes as suggested in RFC 2307.  This proposal attempts to standardize this overloading only for backward compatibility and tries to define how we could use attribute descriptions to accomplish the same effect (once again suggested in RFC2307).

Pat Felsted
Novell, Inc.

>>> "Kurt D. Zeilenga" <[email-masked]> 10/27/99 04:07PM >>>

Kurt

----

---

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 27 Oct 1999 19:34:25 -0600

Kurt, I understand the issues you raise about the userPassword attribute.  That aside, the document also attempts to formally define a new attribute type option to achieve this functionality in a more standard way.  I'm interested if this is seen as problematic for any reason.

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 10/27/99 6:42:09 PM >>>
At 05:21 PM 10/27/99 -0600, Pat Felsted wrote:
>The definition of a password is an octet string.

No.  The LDAP definition is:

5.36. userPassword
   
    ( 2.5.4.35 NAME 'userPassword' EQUALITY octetStringMatch  
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
   
   Passwords are stored using an Octet String syntax and are not
   encrypted.

and is derived from X.500 specifications.  Suggestions to change
this attribute type should be directed to appropriate X.500
committees.

>however many systems have overloaded the syntax to add hashes
>as suggested in RFC 2307.

RFC2307 is Informational (and informational).  However, in this
case, it describes an ill advised practice, a practice which is
in direct conflict with RFC2256.

>This proposal attempts to standardize this overloading only for backward
>compatibility.

It's inappropriate to change to the specification of a standard
track RFC defined attribute type without changing it's name and OID.

	Kurt