Subject: [ldapext] [Fwd: Re: [OpenDS-users] LDAP Password Modify Extended Operation]

From: Howard Chu <[email-masked]>
Date: Sun, 13 Jul 2008 20:43:34 -0700

Looks like we need some clarification of RFC3062...

-------- Original Message --------
Subject: Re: [OpenDS-users] LDAP Password Modify Extended Operation
Date: Mon, 14 Jul 2008 02:37:30 +0200
From: Anton Bobrov <[email-masked]>
Reply-To: [email-masked]
Organization: Sun Microsystems, Inc.
To: [email-masked]
References: <[email-masked]> <[email-masked]> 
<[email-masked]> <[email-masked]> 
<[email-masked]>

yeah, i think it is confusing and should be clarified.
to me [since the same thing used elsewhere] it is what
Kurt did imply, you sure could ask him to comment on
that but as long as its not clarified in the RFC its
somewhat a hanger really. i leave it to Kurt and Ludo
[Ludo, are you reading this ?].

Howard Chu wrote:
> Anton Bobrov wrote:
>> Michael, its mentioned a bit earlier in that RFC, see
>> "1. Background and Intent of Use" section there which
>> specifically talks about that and has a reference to
>> RFC2829 where related to your question see section 9.
>> "Authorization Identity".
>
> Oddly enough, RFC3062 could have plainly said that the userIdentity was
> an RFC2829 Authorization Identity, but it doesn't. It says it may (or
> may not) be an LDAPDN, and LDAPDNs clearly do not begin with a "dn:"
> prefix. Maybe this should be clarified in an IETF forum.
>
>> Michael Ströder wrote:
>>> Michael Dugan wrote:
>>>> Michael Ströder wrote:
>>>>> I'm testing LDAP Password Modify Extended Operation (RFC 3062) with
>>>>> OpenDS 1.0. I just sent the new password in the request, bound as
>>>>> "cn=Directory Manager". Are there any restrictions?
>>>>>
>>>>> I get the following error:
>>>>>
>>>>> ---------------------------- snip ----------------------------
>>>>> Protocol error:
>>>>> The password modify extended request cannot be processed because it
>>>>> contained an invalid authorization ID that did not start with either
>>>>> "dn:" or "u:". The provided authorization ID string was "cn=Fred
>>>>> Feuerstein,ou=People,dc=opends,dc=stroeder,dc=local"
>>>>> ---------------------------- snip ----------------------------
>>>>>
>>>>> Frankly I don't understand what it says. To me it sounds rather an
>>>>> error message related to "Who Ami I? ext. op.".
>>>> Since "cn=Fred Feuerstein,ou=People,dc=opends,dc=stroeder,dc=local"
>>>   >
>>>> looks like a DN, you
>>>> probably need to prefix it with "dn:". For example,
>>>>
>>>>    "dn:cn=Fred Feuerstein,ou=People,dc=opends,dc=stroeder,dc=local"
>>>>
>>>> if not it assumes it is not a DN and tries to use an identity mapper
>>>> to process the request.
>>> Could you please point me to the part of RFC 3062 which talks about
>>> adding a "dn:" prefix?
>>>
>>> I only found:
>>>
>>> ------------------------------------------------------------------
>>>     PasswdModifyRequestValue ::= SEQUENCE {
>>>       userIdentity    [0]  OCTET STRING OPTIONAL
>>>       oldPasswd       [1]  OCTET STRING OPTIONAL
>>>       newPasswd       [2]  OCTET STRING OPTIONAL }
>>> [..]
>>>     The userIdentity field, if present, SHALL contain an octet string
>>>     representation of the user associated with the request.  This string
>>>     may or may not be an LDAPDN [RFC2253].  If no userIdentity field is
>>>     present, the request acts up upon the password of the user currently
>>>     associated with the LDAP session.
>>> ------------------------------------------------------------------
>>>
>>> My understanding is that the server has to detect whether it's a valid
>>> DN or not and act accordingly.
>>>
>>> Ciao, Michael.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email-masked]
>>> For additional commands, e-mail: [email-masked]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email-masked]
>> For additional commands, e-mail: [email-masked]
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email-masked]
For additional commands, e-mail: [email-masked]

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/
_______________________________________________
Ldapext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ldapext

---

From: Kurt Zeilenga <[email-masked]>
Date: Sun, 13 Jul 2008 21:30:25 -0700

> Looks like we need some clarification of RFC3062...

The userIdentity string is either an RFC 4514 LDAP string  
representation of a DN, or some other string representation of a DN  
(LDAP generally allows alternative string representations), or some  
string representation of some other authentication identity form (such  
as a SASLprep user name used in PLAIN, CRAM-MD5, DIGEST-MD5).

The intent is for the field to carry the same user identity (authcid)  
string that the user would normally use for password authentication.   
For instance, "[email-masked]" or "uid=kurt,dc=example,dc=com".

Note that authzid is for representing authorization identities, not  
authentication identities.  Hence, it was not my intent that the user  
provide an authzid.  However, it would be reasonable for  
implementations to accept these IN ADDITION to user's authentication  
identity strings.

-- Kurt

>
>
> -------- Original Message -------
> References: <[email-masked]>  
> <[email-masked]> <[email-masked]> <[email-masked] 
>>>>> Since "cn=Fred

---

From: Howard Chu <[email-masked]>
Date: Mon, 14 Jul 2008 01:48:34 -0700

> implementations to accept these IN ADDITION to user's authentication

That seems like a friendly thing to do, but it's blurring the distinction 
between authcID and authzID, to the point of meaninglessness.

In linguistic terms, the authzID is a Subject (the entity that is acting), and 
in this op the userID/authcID is an Object (the entity that is being acted 
on). Semantically they're very different. This blurring seems like A Bad Thing 
to me.

On the flip side, using an explicitly tagged authzID has the advantage of not 
making the server try to guess what form of userID has been provided...

As a complete aside, there seems to be a disconnect here - it appears that 
there ought to be a way to specify which password validation mechanism's 
password is being changed. E.g., it's possible for a user to have a valid 
directory entry with a local userPassword attribute, as well as a valid 
password in an external store, e.g. sasldb. (Ugly, but this used to come up 
frequently.) The local userPassword would be used for Simple Binds, and the 
sasldb would be used for SASL Binds. Similarly for SASL Binds, not all mechs 
will necessarily use the same password, so it may be desirable to specify 
which mech's password to set. (E.g., SASL/OTP)
>> From: Anton Bobrov<[email-masked]>
>> References:<[email-masked]>

---

From: Michael Ströder <[email-masked]>
Date: Mon, 14 Jul 2008 11:05:57 +0200

Howard Chu wrote:
> On the flip side, using an explicitly tagged authzID has the advantage 
> of not making the server try to guess what form of userID has been 
> provided...

Yes, this could lead to serious issues.

> As a complete aside, there seems to be a disconnect here - it appears 
> that there ought to be a way to specify which password validation 
> mechanism's password is being changed. E.g., it's possible for a user to 
> have a valid directory entry with a local userPassword attribute, as 
> well as a valid password in an external store, e.g. sasldb. (Ugly, but 
> this used to come up frequently.) The local userPassword would be used 
> for Simple Binds, and the sasldb would be used for SASL Binds. Similarly 
> for SASL Binds, not all mechs will necessarily use the same password, so 
> it may be desirable to specify which mech's password to set. (E.g., 
> SASL/OTP)

Most times there is already a server-side mapping from authc-ID to 
authz-ID in form of a DN. So if the authz-ID is sent in form of a DN for 
userIdentity in the PasswdModifyRequestValue the server has to apply the 
reverse mapping to find the accompanying authc-ID for which to change 
the password.

Ciao, Michael.

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 14 Jul 2008 07:54:02 -0700

On Jul 14, 2008, at 1:48 AM, Howard Chu wrote:

> On the flip side, using an explicitly tagged authzID has the  
> advantage of not making the server try to guess what form of userID  
> has been provided...

If a user (at a UI dialog box) enters:  cn=uid, should that be  
prefixed by dn: or u:.  How is the client to know whether it's a DN or  
a userid?   Likewise, if the user entered uid.domain, how is the  
client to know this is a userid and not some alternative DN format?   
(There are few restrictions on alternative DN formats.)

Just like most clients pass whatever user identity string is inputted  
to simple Bind or SASL/PLAIN bind onto the wire without verification,  
the clients should do the same here.  The server can easily figure  
format its in (based upon local rules).

The u: and dn: prefixes seem to only help the server, they are pain to  
clients.

> As a complete aside, there seems to be a disconnect here - it  
> appears that there ought to be a way to specify which password  
> validation mechanism's password is being changed.

This extension was purposely designed to support only a single  
password per user.

> E.g., it's possible for a user to have a valid directory entry with  
> a local userPassword attribute, as well as a valid password in an  
> external store, e.g. sasldb. (Ugly, but this used to come up  
> frequently.) The local userPassword would be used for Simple Binds,  
> and the sasldb would be used for SASL Binds. Similarly for SASL  
> Binds, not all mechs will necessarily use the same password, so it  
> may be desirable to specify which mech's password to set. (E.g.,  
> SASL/OTP)

-- Kurt

---

From: Michael Ströder <[email-masked]>
Date: Mon, 14 Jul 2008 20:24:31 +0200

Kurt Zeilenga wrote:
> 
> Just like most clients pass whatever user identity string is inputted to 
> simple Bind or SASL/PLAIN bind onto the wire without verification, the 
> clients should do the same here.  The server can easily figure format 
> its in (based upon local rules).

Yupp. Especially since the use-case is most times: Navigate to the user 
entry and then choose a UI function "Change Password". So it's easy for 
the client to simply pass along the user entry's DN, it's a pain doing 
something else.

Ciao, Michael.