authcid v. realm in DIGEST-MD5 and elsewhere (Was: saslauthd + pam_mysql broken)

From: Kurt D. Zeilenga (Kurt at OpenLDAP dot org)
Date: Thu Mar 25 2004 - 21:01:43 EST

  • Next message: Dirk Tamme: "Re: Could not open DB"

    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. In particular,
    when a datastore is cracked, DIGEST-MD5 is designed to allow
    transition to a new store without changing 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 '@'.

    I believe SASL libraries (Cyrus included) should treat the
    DIGEST-MD5 username and realm strings as orthogonal values,
    especially when using external shared systems. 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.

    Same should apply to other mechanisms. That is, the Cyrus
    SASL library should provide uncooked mechanism values.

    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). And
    you make it hard on external secret store developers to support
    multiple SASL libraries.

    Kurt

    At 05:07 PM 3/25/2004, Roman Medina wrote:
    >On Thu, 25 Mar 2004 16:19:42 -0500 (EST), you wrote:
    >
    >>How, exactly? If we are the client, nothing will ever break (since the
    >>client side deals with either username at realm for the authnid, and also
    >>enables the caller to pass a realm name. On the server side, we
    >>define the realm= pareameter to be the FQDN of the server (as it is
    >>the right of the server to do). We then accept authnids whose format is
    >>defined to be username at somedomain, which, internally, we treat as the
    >>"realm". What the application sees as realm and what is on the wire as
    >>the digest-md5 realm parameter have *nothing* to do with eachother.
    >
    >Rob, I understand your position. But if you change the behaviour of
    >libsasl to split username into user + domain (as you said, to be
    >internally managed in the way you want, and consistent to other
    >functions), the only way not to break the client (seen in a global
    >way) is to also modify the auth process in order to send
    >"username"@"realm" (=user at domain) whenever it proceeds (for instance,
    >in the case of auth_pam). Perhaps now this is done (since I heard you
    >comitted Jeremy's patch which precisely is supposed to join
    >username+realm) but it was done when I began the thread. Indeed, when
    >I realized what the problem was, I was looking for any new options to
    >saslauthd to implement the joining. I thought it should exist such
    >option since it was not logical to think sasl auth had been completely
    >broken.
    >
    >Jeremy's patch is ok since it at least permits the user to _manually_
    >fix the broken behaviour introduced in last versions of cyrus sasl. I
    >said "manually" because the user will first have to realized cyrus
    >sasl code behaviour have changed and then respond to the changes by
    >activating the special option to concat user+realm.
    >
    >But I still think that if you break something, you should fix
    >something, not letting the user this task. Not all users are average
    >users nor have time to research this kind of things. For me it's late
    >because I already spent my time with this issue but I wouldn't like
    >others to live my same situation.
    >
    >Regards,
    > --Roman
    >
    >--
    >PGP Fingerprint:
    >09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742
    >[Key ID: 0xEAD56742. Available at KeyServ]


  • Next message: Dirk Tamme: "Re: Could not open DB"





    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs



    Powered By FreeBSD   Powered By FreeBSD