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

[Dave Cridland]

On 16 August 2016 at 15:51, 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).
>

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.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 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 (daunt

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

[Ralph Meijer]

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) 

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

[Christian Schudt]

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 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-unsubscr...@xmpp.org ___



___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Dave Cridland]

On 16 August 2016 at 14:09, Kurt Zeilenga  wrote:
>
>> On Aug 16, 2016, at 5:41 AM, Guus der Kinderen  
>> wrote:
>>
>> Interoperability problems galore!
>
> Welcome to DIGEST-MD5!
>
> I recommend avoiding this mechanism.  Use SCRAM instead (preferably PLUS 
> channel bindings) instead.
>

Openfire does offer SCRAM, sans -PLUS due to the missing bits of the TLS API.

But not everything can use SCRAM, and since DIGEST was the MTI for
many years, there's a large deployed base we cannot easily wish away
(including anything-but-latest Spark, when it's not doing GSSAPI).

> -- Kurt
> ___
> 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
___

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

[Ralph Meijer]

On August 16, 2016 3:09:31 PM GMT+02:00, Kurt Zeilenga 
 wrote:
>
>> On Aug 16, 2016, at 5:41 AM, Guus der Kinderen
> wrote:
>> 
>> Interoperability problems galore!
>
>Welcome to DIGEST-MD5!
>
>I recommend avoiding this mechanism.  Use SCRAM instead (preferably
>PLUS channel bindings) instead.
>
>-- Kurt
>
>
>
>___
>Standards mailing list
>Info: http://mail.jabber.org/mailman/listinfo/standards
>Unsubscribe: standards-unsubscr...@xmpp.org
>___

Well sure. It's been deprecated by the XMPP community, too. However it is still 
abundant in the wild.

It seems to me that we just have to live with the form xmpp/example.org, where 
the host part really is the domain instead of the hostname. Of course, 
accepting the more correct version of xmpp/foo.example.org/example.org is 
commendable, but not required.

FWIW, the XMPP SASL code in Twisted also does the 'wrong' thing.


-- 
ralphm___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Kurt Zeilenga]

> On Aug 16, 2016, at 5:41 AM, Guus der Kinderen  
> wrote:
> 
> Interoperability problems galore!

Welcome to DIGEST-MD5!

I recommend avoiding this mechanism.  Use SCRAM instead (preferably PLUS 
channel bindings) instead.

-- Kurt

smime.p7s
Description: S/MIME cryptographic signature
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Dave Cridland]

On 16 August 2016 at 13:41, Guus der Kinderen
 wrote:
> 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:

As a bit more background:

* RFC 6331 doesn't mention the digest-uri, because "everyone" knows
it's broken and shouldn't be checked. Apart from Oracle, it seems,
which validates it against the form serv-type "/" host
* RFC 2831 says it SHOULD [RFC 2119] be checked, because reasons.
* RFC 3920 includes a DIGEST-MD5 exchange as an example, which uses
xmpp/example.com as the digest-uri. It's not clear if this is the XMPP
service domain (ie, serv-name) or the "host".
* I've found the "xmpp" serv-type definition thanks to Ralph, but the
digest-uri really ought to be "xmpp/xmpp.example.com/example.com"
anyway. But if you did this Openfire definitely won't work, since the
Java DIGEST-MD5 implementation can't support that.

Dave.
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Guus der Kinderen]

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
___