[Members] SASL's DIGEST-MD5: host or domain?

Guus der Kinderen guus.der.kinderen at gmail.com
Tue Aug 16 12:42:48 UTC 2016

Hargh! Apologies for using the wrong list. Consider this thread closed -
I've reposted to the standards mailinglist.

 - Guus

On 16 August 2016 at 14:28, Guus der Kinderen <guus.der.kinderen at gmail.com>

> Hi,
> Over the last few days, some of us at IgniteRealtime have been having fun
> with the DIGEST-MD5 SASL Mechanism - specifically, with it's digest-uri
> value. The syntax of this value is:
> serv-type "/" host [ "/" serv-name ]
> It's generally accepted [1] that the applicable value for the serv-type
> part is "xmpp". So far, we've not used the optional "serv-name" part. The
> "host" part is a cause of confusion though.
> We found that, when handling the server side of things, Openfire expects
> the "host" part of the digest-uri value to be an XMPP domain name. This
> conflicts with the specification in RFC2831, which defines the "host" part
> as follows:
> "*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."*
> Clearly, this defines a host name to be used, not the service domain name.
> This is further confirmed on "our" wiki [3] where "host" is defined as:
> "*The DNS hostname or IP address for the service requested (though the
> DNS hostname is preferred). For XMPP, this should be set to the hostname of
> the remote server.*"
> All of the above let me to experiment with changing our implementation:
> instead of expecting the client to send the domain name, let's have a fully
> qualified host name [4].
> Interoperability problems galore!
> The change above, although "correct" in the terms of following the RFC,
> appears to clash with existing XMPP client implementations. So far, we've
> found that Smack, Conversations, and Gajim will use the XMPP domain name,
> instead of the fully qualified host name when constructing the digest-uri
> value. They were the first three implementations that we checked. With the
> three out of three score, I'm assuming that most other implementations will
> behave the same. (How does your implementation do this?)
> How, as a community, should we tackle this, if at all? On one hand: if
> indeed everyone is doing the same thing now, it would probably hurt
> interoperability when "fixes" are applied. Then again, there's bound to be
> some implementations that actually follow the specifications, and now fail
> to authenticate.
> For Openfire (and perhaps all server implementations), I'd love to work
> towards a solution in which the DIGEST-MD5 mechanism implementation will
> accept both the domain name as well as the fully qualified host name. That
> will allow both variants to connect successfully, but has practical issues
> [5].
> Regards,
>   Guus
>    1. Now that Dave has come around
>    2. https://tools.ietf.org/html/rfc2831
>    3. http://wiki.xmpp.org/web/SASLandDIGEST-MD5
>    4. This change was needed to resolve another, unrelated issue, which
>    is why we started looking into this in the first place
>    5. We either have to implement our own implementation (daunting task),
>    or find a suitably licensed third party implementation (haven't found one
>    yet)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/members/attachments/20160816/7f7468f3/attachment.html>

More information about the Members mailing list