On August 16, 2016 4:51:51 PM GMT+02:00, Christian Schudt
<christian.sch...@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).
>
>
>
>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.
>
>
>
>-- 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.kinde...@gmail.com>
>An: "XMPP Standards" <Standards@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
>aroundhttps://tools.ietf.org/html/rfc2831http://wiki.xmpp.org/web/SASLandDIGEST-MD5This
>change was needed to resolve another, unrelated issue, which is why we
>started looking into this in the first placeWe 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
>_______________________________________________
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Standards mailing list
>Info: http://mail.jabber.org/mailman/listinfo/standards
>Unsubscribe: standards-unsubscr...@xmpp.org
>_______________________________________________
I think that it is unwise for clients to start "fixing" this, to be honest.
There doesn't appear to be an advantage at this point, beyond correctness. If
anything, it will decrease interop.
--
ralphm
_______________________________________________
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
