On May 13, 2011, at 11:06 , Glenn Maynard wrote:

> On Fri, May 13, 2011 at 5:10 AM, Dave Cridland <[email protected]> wrote:
> On Fri May 13 01:37:37 2011, Glenn Maynard wrote:
> SASL mechanisms require the FQDN of the host being connected to[1].  With
> xbosh, you can't always tell what the FQDN of the real server is.
> 
> I recall a lengthy discussion on this a while back, specifically with 
> DIGEST-MD5.
> 
> I havn't been able to find it.  Any idea where it was?
> 
> I think it can be summarized as:
> 
>  Always just use the service domain, and never the hostname, when 
> constructing the DIGEST URI.
> 
> By "service domain", you mean the domainpart of the JID?  Is this for all 
> XMPP authentication and not just xbosh?

Yes, "service domain" == "domainpart" in this context.  This the general 
consensus for all XMPP authentication.

> 
> If that's what clients are expected to do, this should be specced, since 
> implementors are guessing.  (The implementation I'm looking 
> at--smack--doesn't even handle this consistently internally.)  I'm guessing 
> that it's not that simple, though.  For example, rfc6120 4.7.1 mentions that 
> with GSSAPI, the client doesn't even know the JID before authentication.
> 
> Also, DIGEST-MD5 is moving (has moved?) to historic. (Approved document 
> making it thus has not yet been published).
> 
> I think GSSAPI also has its own dependencies on the hostname of the server, 
> and the parameter required by APIs like javax.security.sasl won't go 
> away--this might always crop up in other mechanisms.
> 

As I far as I can remember, only DIGEST-MD5 and GSSAPI have any sort of need 
for the hosting FQDN.  There are efforts to try and mitigate that need in 
GSSAPI (e.g. domain-based names); and DIGEST-MD5 is now "replaced" with SCRAM, 
which doesn't want that information.

The general consensus within the XMPP community has been to use the service 
domain for the hosting FQDN.


- m&m

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to