[Standards] SASL's DIGEST-MD5: host or domain?
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:
> when using Java's SASL API , 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 :
> 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
> 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?
> 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
> 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
> 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
> 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 .
> 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
> Now that Dave has come around
> 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