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)
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
