On 16 August 2016 at 15:51, Christian Schudt <[email protected]> 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" <[email protected]> > An: "XMPP Standards" <[email protected]> > 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: > [email protected] > _______________________________________________ > > _______________________________________________ > Standards mailing list > Info: http://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ > _______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
