From: Kurt D. Zeilenga (Kurt at OpenLDAP dot org)
Date: Mon Mar 29 2004 - 12:38:12 EST
Let me try a different tact on this.
Cyrus SASL 2 does not, I believe, support storage of the DIGEST-MD5
shared secret (the hash) and instead stores the actual user password.
In this case, the DIGEST-MD5 realm is extraneous. That is,
as long as both client and server use the same realm value,
the authentication process will work properly. Of course,
if the password store is cracked, then you do need to stop
using those passwords (where in if a DIGEST-MD5 shared secret
database is cracked, you can continue to use the passwords
from which the shared secrets are derived (such as in PLAIN,
possible supporting transition to a new shared secret store).
As such, I would be fine if Cyrus SASL DIGEST-MD5 just published
a statically configured realm, used that in DIGEST-MD5 exchange,
but not otherwise. In particular, don't use the DIGEST-MD5
realm in selecting the password store.
Instead, if multiple passwords stores are desired, use a portion
of the authentication identity to do this selection. This because,
as you note, PLAIN and CRAM-MD5 don't have any concept of a
REALM and you want to support multiple password stores there as
However, in doing so, leave the authentication identity alone.
That is, I don't mind so much in you parsing the authentication
identity and even providing what you parse out as a separate
field (not called a realm), but also be sure to provide the full
and complete authentication identity to the application servers.
But, as you want to do the same for PLAIN, CRAM-MD5, and DIGEST-MD5,
don't call what you parse out from the authentication identity
a "realm" because, in DIGEST-MD5, that would lead to two different
things being called a "realm" (the part parsed from the authentication
identity and the DIGEST-MD5 realm).
So, use another term. Maybe "domain". Or maybe "group".
At 08:14 AM 3/29/2004, Rob Siemborski wrote:
>On Thu, 25 Mar 2004, Kurt D. Zeilenga wrote:
>> It's my personal opinion is that that DIGEST-MD5 realm concept
>> is far different that in Kerberos. In DIGEST-MD5, unlike in
>> Kerberos, the realm is NOT part of the authentication identity.
>> The DIGEST-MD5 is best not thought of a 'collection of accounts',
>> but as as shared-secret datastore selector.
>Ok, but in the Cyrus SASL case these are essentially equivalent.
>> In particular, when a datastore is cracked, DIGEST-MD5 is designed to
>> allow transition to a new store without changing authentication
>This is possible using any of our stores. (I don't see what
>specific authentication identities have to do with the store being cracked
>-- you fix this by changing passwords, not authentication identities)
>> I note that the '@' sign is allowed in both DIGEST-MD5
>> authentication identity string and the realm string. That is,
>> user "kurt at example dot org" in realm "users at example dot org" is
>> a quite expectable. Note that RFC 2831 provides an example
>> of a realm containing an '@'.
>Of course they're allowed. The Cyrus SASL scheme for authentication
>identifiers wouldn't work if @ was forbidden in the authentication
>identity (obviously, the presence or absence of @ in the realm identity
>is irrelevant in this case).
>If the server doesn't *have* a users at example dot org realm, then naturally all
>authentications will fail to it. Cyrus SASL's DIGEST implementation
>takes this to the extreme of "we only support one realm in the realm
>parameter". Likewise, if a server doesn't have foo at bar@baz authentication
>id, all authentications to it will fail regardless. As far as
>client-server inter-operability is concerned, this shouldn't be an issue.
>> Otherwise, the SASL library will have problems providing compatible
>> services. That is, consider one external system supporting multiple
>> servers each using a different SASL library, each applying
>> library-specific semantics to protocol values.
>Actually, the biggest problem I've faced as an application developer is
>dealing with the differences in the mechanisms that the library should
>otherwise be hiding. I really shouldn't have to care if I get a mechanism
>that supports realms or not -- and many users *want* to be able to use
>the *concept* of realms with mechanisms such as PLAIN and CRAM-MD5, which
>don't have the *machinery* of realms that DIGEST does. Even worse, they
>want to do this at the same time as supporting DIGEST auth.
>> Same should apply to other mechanisms. That is, the Cyrus
>> SASL library should provide uncooked mechanism values.
>The library provides the authorization identity to the application server
>as it was provided by the client. The fact that the only way to represent
>the realm concept in CRAM-MD5 and PLAIN is with authorization ids of
>foo at bar (or some other similar "cooking") is unfortunate, but unlikely
>to ever be fixed.
>saslauthd is probably the place where this hits us worst. But it also
>only applies to authentication identifiers (not authorization identifiers)
>which are the responsibility of the mechanism & its implementation, and
>outside the purview of the application.
>> In summary, cooking the values is making it hard on application
>> server developers, especially those who have there own secret
>> stores, to do 'the right thing' (based upon their needs).
>What do you propose is a good way to address the concerns of application
>developers and operators who want to be able to use a similar storage and
>authorization scheme with CRAM-MD5, PLAIN, and DIGEST-MD5, utilizing the
>concept of realms?
>> And you make it hard on external secret store developers to support
>> multiple SASL libraries.
>There isn't currently any standardization effort underway for secret
>stores to integrate with SASL libraries. As such, any secret store
>developer is going to run into this sort of problem regardless (as it
>happens, our auxprop API doesn't currently offer a way to pass the realm
>of an identifier for lookup -- which is probably a deficiency).
>Would you still have a problem if the secret store authors had a way of
>receiving the realm and username as separate strings via the auxprop API?
>While this doesn't address the "this isn't a perfect DIGEST-MD5 userid"
>issue, it does prevent the "cooking" that the internal mechanisms we have
>do from crossing an API boundary (the mechanisms would be responsible for
>determining the authnid and realm for any given lookup, not the auxprop
>It also allows for another DIGEST-MD5 implementation to make further use
>of the realm parameter in whatever way it sees fit.
>Frankly, I think that the people who are running these systems care less
>about what the protocol looks like on the wire (as long as it is
>inter-operable) than the fact that the that are provided by the library
>work as consistently as possible.
>Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
>Research Systems Programmer * /usr/contributed Gatekeeper