[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: AuthMeth issue summary



Title: RE: AuthMeth issue summary


> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.Org]
> Sent: Tuesday, December 07, 1999 1:07 PM
> To: Mark Wahl
> Cc: ietf-ldapext@netscape.com
> Subject: Re: AuthMeth issue summary
>
>
> AuthMeth draft provides a secure Bind mechanism (DIGEST-MD5)
> for authentication users who provide a simple username/password.
> Though the mechanism describes how to provide an LDAP DN
> authorization identity, it doesn't not allow an LDAP DN
> authentication identity (DIGEST-MD5 username) [and it shouldn't].

Yes, it does allow an LDAP DN as an authentication ID. It in fact places no constraints on the form of authentication IDs at all (other than that they be strings, ASCII or UTF-8, and that the user supply exactly the same value (including case, etc) as the server stored when the users account was created).

Obviously, the security subsystem on the server would have to use DNs as usernames in order for users to supply DNs as user names. Most servers' OSes, of course, have security subsystems that use a different user naming scheme than that. Even so, that needn't stop a determined LDAP server writer from creating their own security subsystem just for the LDAP server (or similarly the mail server writer, or FTP server writer, or Telnet server writer) -- at the cost of making users understand a different form of user name for (potentially) every different server, and the sysadmin having to administer all the attendant security databases).

>
> However, I do believe that we need to provide a secure Bind
> mechanism for authentication users who provide an LDAP DN as
> their authentication identity.

I believe all the necessary protocol elements are in place so that systems can be built that use LDAP DNs as their authentication IDs. And for ones that don't.

Paul