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

RE: saslAuthz{To|From}

At 07:11 AM 12/19/2003, Howard Chu wrote:
>Well... specifying the realm is irrelevant,

After chewing on this a bit, yet, I think we need to treat
the SASL "realm" (e.g., the DIGEST-MD5 like realm) as irrelevant
in distinguishing userids.

In DIGEST-MD5, there is the authcid, the realm, and the authzid.
While realm is described as a "set of users", but really it
should be viewed as credentials database selector.  This because
if a realm truly mean that authcid in one realm and same
authcid in a different realm referred to two different users, then
the mechanism's authzid facility would be severely broken.
There would be no way for a user in one realm to assume the
identity of a user in another realm.  The obvious conclusion is
that a authcid in one realm and same authcid in a different realm
both refer to the same user.  This is consistent with why
realms were added to DIGEST-MD5: to support updating to a new
database in the event a database was exposed.

GSSAPI (Kerberos) is much different.  Same userids in different
different realms are different principals.  GSSAPI's authcid
format, a Kerberos principal, format embeds the realms.  Hopefully
here we can get Cyrus SASL just to provide us will fully qualified
Kerberos principals in the authcid parameter and forgo the realm
parameter.  (We might special case GSSAPI and fully qualify the
authcid if Cyrus SASL doesn't.)

So, I think we need to avoid the SASL realm in u: format.

Regarding mech, while I think PLAIN 'joe' and DIGEST-MD5 'joe'
can reasonable assumed to be the same Joe, I note that different
mechanisms may have different identity forms.  For example,
with Kerberos we may have "joe@EXAMPLE.COM" and in a X.509
based SASL mechanism could have another form, say "EXAMPLE.COM:joe".
Here the issue is not whether they are the same Joe, but
how do you distinguish the form of identity.  It can be
argued that the forms of the identity used today are
readily distinguishable without having a qualifier.

So, for simplicity sake, maybe the best approach is:
        1) Fully qualify Kerberos V principals where necessary
        2) Otherwise ignore the SASL realm field
        3) Never parse a 'realm' from an authcid/authzid
        4) leave distinguishing of particular form of the
        uAuthzid (u:) to the regexes

(If someone really wants to distinguish a particular
authzid form from the arbitrary UAuthzid form, they
should (as RFC 2829 suggests) introduce a new authzid
prefix (e.g., k:KerberosPrincipal).)

Comments?


>so allowing a fake mech is
>unnecessary. The sanity check is unnecessary, the call to slap_sasl_getdn()
>would simply fail if any of those fields are provided.
>
>> > Now, as to the "AUTHZ" pseudo-mech and where/when it gets used... I
>> > guess the purpose here is to distinguish proxying via SASL Bind from
>> > proxying via proxyAuthz control, yes? So in an LDAP user's entry, a
>> > saslAuthzTo rule for "u:joe.DIGEST-MD5" allows the user to SASL Bind
>
>Of course I meant "u.DIGEST-MD5:joe" above.
>
>> > using DIGEST-MD5 with the authzID set to "u:joe", but not for any other
>> > mechs, and not for proxyAuthz control. Whereas an unqualified rule
>> > allows all mechs and the proxyAuthz control. Yes?
>
>This raises another point, which is vaguely related to the problem of
>authorizing use of controls in the first place. I think it would be useful to
>restrict the proxyAuthz control based on the LDAP Operation. E.g., I may only
>want to authorize someone to proxy as me for Add operations, and nothing
>else. This is not quite the same as the ACLs, nor do we need to duplicate ACL
>functionality here. But it's something to consider.
>
>  -- Howard Chu
>  Chief Architect, Symas Corp.       Director, Highland Sun
>  http://www.symas.com               http://highlandsun.com/hyc
>  Symas: Premier OpenSource Development and Support