[Members] SASL's DIGEST-MD5: host or domain?
Guus der Kinderen
guus.der.kinderen at gmail.com
Tue Aug 16 12:28:33 UTC 2016
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  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
"*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
Clearly, this defines a host name to be used, not the service domain name.
This is further confirmed on "our" wiki  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
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 .
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
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
1. Now that Dave has come around
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Members