[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: saslAuthz{To|From}
At 09:51 AM 12/19/2003, Kurt D. Zeilenga wrote:
>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
(I can live without this item. Special cases do suck.)
> 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