Subject: Re: IETF ldapbis WG Last Call: draft-ietf-ldapbis-user-schema-05.txt

From: John McMeeking <[email-masked]>
Date: Mon, 19 May 2003 15:53:27 -0500

I would rather not see these aliases added to the user schema draft.

I've seen LDAP servers that recognize commonName as an alias of cn, and was
tempted to say that we ought to list this as optional aliases.  But I've
also seen the headaches that result when applications mix cn and commonName
(or other aliases), particularly when one application is either unaware of
the alias, or unaware of aliases in general.

I don't recall seeing a standard that says commonName is an alias for cn,
just that cn is the LDAP equivalent to X.500 commonName.

John  McMeeking

                      "Kurt D. Zeilenga"                                                                                            
                      <[email-masked]>         To:       Michael Ströder <[email-masked]>                                  
                      Sent by:                    cc:       Norbert Klasen <[email-masked]>,        
                      owner-ietf-ldapbis@O         [email-masked]                                                        
                      penLDAP.org                 Subject:  Re: IETF ldapbis WG Last Call:    draft-ietf-ldapbis-user-schema-05.txt 

                      05/19/2003 02:56 PM                                                                                           

At 12:45 PM 5/19/2003, Michael Ströder wrote:
>Kurt D. Zeilenga wrote:
>>At 11:39 AM 5/19/2003, Norbert Klasen wrote:
>>
>>>the schema in many LDAP servers contains an alternate name for those
>>>attributes, whose name is an abbreviation from the name of the
>>>respective X.500 attribute type, e.g. 'cn' and 'commonName' or 'st' and
>>>'stateOrProvinceName'.  Should this be reflected in the user-schema
>>>document?
>>Personally, I think they should not be listed as that would
>>require implementations to recognize additional names.
>
>Why would that "require" to recognize additional names?

Because its expected that all implementations recognize the
attribute types and other elements by the names listed.

>Maybe one could come up with a wording listing the mandantory attribute
type names and the optional aliases?

Maybe, but why?  Adding additional names only leads to interoperability
problems.  It is far better to have one and only name per schema element.

>> Multiple
>>names leads to interoperability problems as it is inevitable
>>that some implementations will not recognize all of them.
>
>But there are already multiple names out there in the wild.

There are also many implementations which don't recognize the
various names one might find in use in the wild.

>And sure there are already interoperability problems with that.

Well, there are always problems when implementations using names
other than those which the standard track specifications say to
use.  This problem cannot be solved by adding more names.  Instead
we should clarify the specifications that use of other names will
lead to interoperability.

>My point is that listing the aliases would make implementors aware of it.

Implementors shouldn't have to be aware of non-standard names.

>>Certainly LDAP implementations are allowed to recognize
>>additional names... but they should not assume others do.
>
>IMHO either we'd be able to disallow use of aliases or we have to make
implementors aware of them.

I think it unwise to disallow implementations from being
"liberal in what they accept".  However, implementations
should be "strict in what they produce".

Kurt

---

From: "Ramsay, Ron" <[email-masked]>
Date: Tue, 27 May 2003 17:05:59 +1000

"I note that the requirement is applied by applications on input
to the directory.  To the directory service, they are still
octets strings matched octet-wise."

- Sounds good to me! Thanks for the clarification.

Ron

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Tuesday, 27 May 2003 16:55
To: Ramsay, Ron
Cc: [email-masked]
Subject: RE: IETF ldapbis WG Last Call:
draft-ietf-ldapbis-user-schema-05.txt

At 09:19 PM 5/26/2003, Ramsay, Ron wrote:
>I agree with the resolutions, except for passwords. For passwords, I agree that there was WG consensus.

Noted.

>My own opinion, however, is that these are octet strings and that a password matches only if the sequence of octets is the same.

I note that the requirement is applied by applications on input
to the directory.  To the directory service, they are still
octets strings matched octet-wise.

>I think I have only seen about five names in messages to the list - is this enough to declare consensus?

All the input was enough to gain a good sense of WG consensus
and to suggest courses of action for the WG to consider.
We'll have to wait a few days to see whether we really
have consensus or not.

Kurt

---

From: Michael Ströder <[email-masked]>
Date: Tue, 27 May 2003 09:56:22 +0200

Ramsay, Ron wrote:
> Yes, thanks, I did see the discussion. I am just saying that I wasn't
> moved by it. I don't see how you can actually talk meaningfully about
> 'textual' passwords

I would define 'textual' passwords as passwords manually typed in by a user
on the keyboard or a similar character-based input device. More formally one
could define textual passwords as a character sequence with a known
character set and encoding.

As current practical experience shows arguing that you can stuff anything
(here an arbitrary character sequence and encoding) into an Octet String
leads to bad interoperability of LDAP applications.

At the moment the only almost safe way is to limit passwords to ASCII since
ISO-8859-1 and UTF-8 both used by some applications share the very same byte
encoding for ASCII. But there might be users who don't have a single ASCII
character on their input device...and there might be an application stuffing
UTF-16 into the password.

> - do you scan a password first to see if it is valid
> UTF-8 and, if so, convert it to unicode and apply stringprep?

No, off course!

Usually you can differentiate in the LDAP application where your password 
comes from. Most times the application receives the password from the user 
by some input device/input form etc. And then you know which character set 
it is and you can easily convert it to UTF-8.

> I can't get excited about that.

Let us clarify things:
Octet Strings for passwords are used because there could be a "locally 
defined" mechanism for using arbitrary Octet Strings in Simple Bind (e.g. 
automatically generated tickets, scanned mouse moves, biometric data or 
similar). In this scenario an LDAP application will likely not interact with 
a human user through a keyboard to ask for a password. This is still 
possible with Kurt's recommendation.

Ciao, Michael.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 28 May 2003 18:29:53 -0700

I have directed the editor to prepare a revision addressing
outstanding technical issues as previously summarized with
excepted noted below.  Once published, I will ask the WG to
confirm that the changes made adequately address these issues.
Presently, I do not think another WG Last Call will be necessary
as I believe I believe we have WG (good to rough) consensus
on how to resolve outstanding issues, however I will defer
this decision until after the editor has made the changes and
the WG has had an opportunity to consider those changes.

While waiting for the editor to make these changes, I suggest we
turn our energy to reviewing the [Protocol] and [AuthMeth] I-Ds.

-- Kurt, LDAPbis co-chair

At 11:41 AM 5/26/2003, Kurt D. Zeilenga wrote:
>This message serves to summarize issues to be addressed
>before this I-D is progressed.  For each issue, I have suggested
>a course of action which I believe to be consistent with WG
>consensus.  If you don't believe the this course of action
>is appropriate, please comment within the next couple of days.
>Otherwise, the chairs will declare these issues resolved and
>direct the editor to revise the document accordingly.
>
>KurtZ raised concerns regarding the ommission of an 'uid' attribute
>type specification.  He made a proposal to add it.  No one opposed
>this proposal, implement it.
>
>MarkH raised concerns regarding suggested upper limits.
>StevenL proposed that all suggested upper limits be removed
>to avoid confusion.  No one opposed this proposal, implement it.
>
>KurtZ raised concerns regarding internationalization of textual
>user passwords.  Kurt proposed that it be recommended that applications
>prepare textural passwords by first transcoding them to Unicode,
>apply SASLprep, and then encoding them as UTF-8.  Hallvard offered
>some word smithing which was found acceptable.  No one opposed this
>proposal, implement it.
>
>NorbertK raised concerns regarding alternative names used for
>in some implementations which do not appear in the attribute
>type's formal description and suggested they be added.  Objections
>to the proposal were raised.  The proposal is rejected.
>
>KurtZ provided a laundry list of issues.  For brevity, I will
>only summarize technical issues.  There were no opposing comments
>to any of his proposals.
>
>KurtZ noted that most attribute types are discussed in single
>value terms though are declared as multiple values.  Kurt
>proposed that the editor reword each description to reflect
>their multi-valued-ness.  Clarify.
>
>KurtZ noted that the description of 'dc' is needs further
>clarification.  Clarify as noted.
>
>KurtZ noted 'destinationIndicator' specification does not
>include a statement of how the attribute type is used.  Clarify.
>
>KurtZ noted the description of 'givenName' is inconsistent
>with that provided in X.520.  Clarify.
>
>KurtZ proposed that the 'domain' object class should not have
>been added to the specification.  Remove.
>
>KurtZ raised a security consideration regarding session hijacking.
>Add consideration.

MichaelS and HallvardF noted that this was misplaced (belongs in
[Protocol] and/or [AuthMeth]).  The editor should not added
this consideration.

HallvardF noted the statement
   It is required that strong authentication be performed in order to 
   modify directory entries using LDAP.
is also misplaced (also belongs in [Protocol] and/or [AuthMeth]).
The editor should remove this statement.

MichaelS raised an issue with multi-valued userPasswords.  Kurt
suggested considerations be stated.  The editor should add
appropriate considerations.