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

Dave Cridland dave at cridland.net
Tue Aug 16 15:13:05 UTC 2016


On 16 August 2016 at 15:51, Christian Schudt <christian.schudt at gmx.de> wrote:
> Hi,
>
> when using Java's SASL API [1], you would use the following to create a SASL
> client for DIGEST-MD5 authentication:
>
> Sasl.createSaslClient("DIGEST-MD5", authzid, "xmpp", serverName, null, cbh);
>
> The fourth parameter "serverName" will be used in the digest-uri
> It's documented as [1]:
> serverName - The non-null fully-qualified host name of the server to
> authenticate to.
>
> So I think it correctly sticks to the specification (host is correct, domain
> is wrong).
>

Actually you need both... Which Java won't do (and will reject if it sees it).

> That said, I did it wrong, too in my implementation, but will fix it (i.e.
> use hostname instead of domain), so that I comply with the API contract,
> too. Thanks for pointing it out.
>

No, don't - then it won't work anywhere that checks the
digest-uri-value (ie, Java).

And yeah, I know, this sucks a bit.

> -- Christian
>
> [1]:
> https://docs.oracle.com/javase/8/docs/technotes/guides/security/sasl/sasl-refguide.html
> [2]:
> https://docs.oracle.com/javase/7/docs/api/javax/security/sasl/Sasl.html#createSaslClient(java.lang.String[],%20java.lang.String,%20java.lang.String,%20java.lang.String,%20java.util.Map,%20javax.security.auth.callback.CallbackHandler)
>
> Gesendet: Dienstag, 16. August 2016 um 14:41 Uhr
> Von: "Guus der Kinderen" <guus.der.kinderen at gmail.com>
> An: "XMPP Standards" <Standards at xmpp.org>
> Betreff: [Standards] SASL's DIGEST-MD5: host or domain?
> 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
>
> Now that Dave has come around
> https://tools.ietf.org/html/rfc2831
> http://wiki.xmpp.org/web/SASLandDIGEST-MD5
> This change was needed to resolve another, unrelated issue, which is why we
> started looking into this in the first place
> 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-unsubscribe at xmpp.org
> _______________________________________________
>
> _______________________________________________
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>


More information about the Standards mailing list