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

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 05 May 2003 17:12:25 -0700

This message initiates a LDAPbis Working Group Last Call on the
document:

          LDAP: User Schema
          <draft-ietf-ldapbis-user-schema-05.txt>

The purpose of this WG Last Call it to ensure that the Working Group
has achieved consensus that the document is suitable for publication
as an IETF Draft Standard.

Please review the document for both technical and editorial problems.
Technical issues should be discussed on this list.  Editorial issues
may be sent to the document editor.

The Last Call period will end on Wednesday, May 21, 2003.

Upon completion of the last call, the WG chair(s) will take action
based upon the consensus of the WG.  Possible actions include:

  1) recommending to the IETF Application Area Directors that the
     document, after possible editorial or other minor changes, be
     considered by the IESG for publication as a Draft Standard
     (which generally involves an IETF-wide Last Call); or

  2) requiring that outstanding issues be adequately addressed prior
     to further action (including, possibly, another Last Call).

Remember that it is our responsibility as Working Group members to
ensure the quality of our documents and of the Internet Standards
process.  So, please read and comment!

 - Kurt Zeilenga
   LDAPbis co-chair

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 16 May 2003 11:50:53 -0700

Please note that the last call period will close soon....  Also,
if you have reviewed the latest revision of this I-D and find
no problems, you should still comment!  Thanks, Kurt

---

From: Norbert Klasen <[email-masked]>
Date: Mon, 19 May 2003 20:39:37 +0200

Hi,
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?

Norbert

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 19 May 2003 12:11:51 -0700

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.  Multiple
names leads to interoperability problems as it is inevitable
that some implementations will not recognize all of them.

Certainly LDAP implementations are allowed to recognize
additional names... but they should not assume others do.

Kurt

---

From: Michael Ströder <[email-masked]>
Date: Mon, 19 May 2003 20:51:09 +0200

Norbert Klasen wrote:
> 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'.

I guess this will take us to the name registry discussion again.

I'd like to see this aliases mentioned in draft-ietf-ldapbis-user-schema. 
This would make developers aware that these aliases exist.

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Mon, 19 May 2003 21:45:08 +0200

Kurt D. Zeilenga wrote:
>> 'stateOrProvinceName'.  Should this be reflected in the user-schema
>> document?
> 
> require implementations to recognize additional names.

Why would that "require" to recognize additional names? Maybe one could come 
up with a wording listing the mandantory attribute type names and the 
optional aliases?

>  Multiple

But there are already multiple names out there in the wild. And sure there 
are already interoperability problems with that. My point is that listing 
the aliases would make implementors aware of it.

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

Ciao, Michael.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 19 May 2003 12:56:58 -0700

At 12:45 PM 5/19/2003, Michael Ströder wrote:
>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.

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

>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: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 26 May 2003 11:41:06 -0700

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.

---

From: Michael Ströder <[email-masked]>
Date: Mon, 26 May 2003 21:40:29 +0200

> KurtZ raised a security consideration regarding session hijacking.

???

I can only find a this comment in mailing list archive:

"Add: Use of integrity protection is encouraged to prevent session hijacking."

Which session is meant here?

Ciao, Michael.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 26 May 2003 13:01:07 -0700

>I can only find a this comment in mailing list archive:

The comment was raised in "the laundry list".
  http://www.openldap.org/lists/ietf-ldapbis/200305/msg00084.html

>Which session is meant here?

The LDAP session.

If one uses a mechanism such as DIGEST-MD5 without
negotiating integrity protection to authenticate,
a man-in-middle can hijack the session after
authentication completes.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 26 May 2003 22:27:14 +0200

> authentication completes. 

What has that to do with schema?  Sounds like a protocol or authmeth
issue to me.

I'd also like to see this paragraph removed:

   It is required that strong authentication be performed in order to 
   modify directory entries using LDAP.

for the same reason.  I've mentioned that before, IIRC the answer was
that yes, it's covered elsewere - but not as a requirement.  I can't
find the thread now, though.

-- 
Hallvard

---

From: Michael Ströder <[email-masked]>
Date: Mon, 26 May 2003 22:45:52 +0200

> authentication completes. 

Does that really belong into draft-ietf-ldapbis-user-schema?
How does that relate to the schema definitions?

I can understand that one emphasizes security for e.g. userPassword (could 
be added to section 'Security Considerations', generalized and extended). 
But IMHO LDAP session security is out of scope in this document.

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Tue, 27 May 2003 10:43:28 +0200

HI!

Another issue:
Any reasonable *and* secure use-case for having multi-valued userPassword?

Maybe it's worth to note in section 'Security Considerations' that multiple 
attribute values for userPassword should be avoided. Especially 
reset/deletion of a password by an admin without knowing the old user 
password gets tricky or impossible if multiple values for different 
applications are present. This also somewhat relates to a similar discussion 
on ldap-ext list about possibly multi-valued attributes in 
draft-behera-ldap-password-policy.

The only use-case I could imagine for having multiple userPassword attribute 
values was working around the Octet String problem storing the *same* 
password with various character sets/encodings.

Ciao, Michael.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 27 May 2003 08:01:52 -0700

>Any reasonable *and* secure use-case for having multi-valued userPassword?

Yes.  Consider an environment where every month the user was expected
to use a different password generated by some automated system.  During
transitional periods, like say the last and first day of the periods, it
may be reasonable to allow two passwords for the two consecutive periods
to be valid in the system.

>Maybe it's worth to note in section 'Security Considerations' that multiple attribute values for userPassword should be avoided. Especially reset/deletion of a password by an admin without knowing the old user password gets tricky or impossible if multiple values for different applications are present. This also somewhat relates to a similar discussion on ldap-ext list about possibly multi-valued attributes in draft-behera-ldap-password-policy.

First, I note that the descriptive text in section 2.40 (as well as most every
other 2.x section) needs to be updated to describe the attribute type in
multi-valued terms.  It should be noted that when used for authentication
purposes [AuthMeth], the user need only prove she knows one of the values, not
all of the values.

Allowing multiple values obviously does raise a number of security considerations
and these need to be discussed in the document.

Certainly applications which intend to replace the userPassword with new value(s)
should use modify/replaceValues (or modify/deleteAttribute+addAttribute).
Additionally, server implementations should be encouraged to provide
administrative controls which, if enabled, restrict userPassword to one value.

>The only use-case I could imagine for having multiple userPassword attribute values was working around the Octet String problem storing the *same* password with various character sets/encodings.

Supporting legacy systems would be another reason.