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

RE: [JunkMail] Re: Bug in LDAP_CONTROL_PROXY_AUTHZ (ITS#2871)



> -----Original Message-----
> From: owner-openldap-bugs@OpenLDAP.org
> [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of igor@ipass.net

> Thanks.
>
> Is this patch going to be backported to 2.1.x?

I think the <absent mech> patch should be backported. I don't think we've
resolved the realm handling satisfactorily yet.

The client "-R" option can only ever affect the DIGEST-MD5 mech, it's not
used anywhere else. It can only have any effect if the server supplies more
than one realm in the DIGEST-MD5 challenge. The Cyrus DIGEST-MD5 mech never
supplies more than one realm. I don't know if anyone else's SASL
implementation behaves differently, but my tendency is to completely ignore
this realm in any further thinking, as the Cyrus code already ignores it.

The realm-embedded-in-the-authID trick that Cyrus uses is not documented by
any of the SASL mechanism RFCs. I think we should ignore this as well, and
never do any parsing of the provided authIDs. Even for Kerberos, which has
explicit realms, Cyrus leaves the realm part in the username when it's a
non-default realm.

So, our SASL DNs should only ever be of the form:
	uid=<username>,cn=<mech>,cn=auth

Any objections?

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support