Uploaded image for project: 'ejabberd development'
  1. ejabberd development
  2. EJAB-1529

ejabberd's interpretation of digest-uri causes Pidgin to fail authorization


    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: ejabberd 2.1.9, ejabberd 2.1.10
    • Fix Version/s: ejabberd 2.1.11
    • Component/s: Authentification
    • Labels:


      This bug is related to and probably a continuation of #EJAB-569.

      RFC 2831[1] states how the digest-uri value should look like, here's a quote of the relevant parts:

      digest-uri = "digest-uri" "=" <"> digest-uri-value <">
      digest-uri-value = serv-type "/" host [ "/" serv-name ]
      The DNS host name or IP address for the service requested. The
      DNS host name must be the fully-qualified canonical name of the
      host. The DNS host name is the preferred form; see notes on server
      processing of the digest-uri.
      Indicates the name of the service if it is replicated. The service
      is considered to be replicated if the client's service-location
      process involves resolution using standard DNS lookup operations,
      and if these operations involve DNS records (such as SRV, or MX)
      which resolve one DNS name into a set of other DNS names. In this
      case, the initial name used by the client is the "serv-name", and
      the final name is the "host" component. For example, the incoming
      mail service for "example.com" may be replicated through the use
      of MX records stored in the DNS, one of which points at an SMTP
      server called "mail3.example.com"; it's "serv-name" would be
      "example.com", it's "host" would be "mail3.example.com". If the
      service is not replicated, or the serv-name is identical to the
      host, then the serv-name component MUST be omitted.

      Now let's look at an XMPP server that runs at foo.example.com and provides a service for the domain example.com where the host lookup for example.com is done with SRV records.
      In this case the host would be foo.example.com as it is the fqdn of the host and serv-name would be example.com .
      The definition of serv-name only forces me to use the short version of the uri if host and serv-name are identical, but it doesn't force me to use the long version in any case.

      So a client should be able to authenticate with either a digest-uri of "xmpp/foo.example.com" or "xmpp/foo.example.com/example.com".

      ejabberd seems to expect that the client either sends the "wrong" uri "xmpp/example.com" (which is what Psi is doing) or "xmpp/foo.example.com/example.com". Pidgin on the other hand is sending the "correct" uri "xmpp/foo.example.com", but is denies access.

      The offending code is in cyrsasl_digest.erl, specifically in the function is_digesturi_valid which is only passed the serv-name and not the fqdn.

      I'm attaching a patch that fixes this problem for me (against ejabberd-2.1.10). It defines a config option fqdn to set the fqdn of the host in ejabberd.cfg and modifies is_digesturi_valid so that it accepts the following digest-uris:
      xmpp/host, xmpp/serv-name and xmpp/host/serv-name

      I think that this is the best compromise to keep supporting current clients.

      The config statement looks like this:

      {fqdn, "foo.example.com"}


      [1] http://www.ietf.org/rfc/rfc2831.txt

        Issue Links



            No work has yet been logged on this issue.


              • Votes:
                1 Vote for this issue
                2 Start watching this issue


                • Created: