SRV records and canonicalization

[Donn Cave]

In article <443E4034.3010606 at sxw.org.uk>,
 simon at sxw.org.uk (Simon Wilkinson) wrote:

> I'm interested in what people feel the 'correct' approach is to the
> following situation.
> 
> XMPP (the 'Jabber' protocol) uses DNS SRV records to determine the
> location of a Jabber service for a given DNS domain. In some
> implementations there may be multiple servers, running on multiple
> different machines, all of which can accept an incoming connection.
> In current Jabber (and MIT Kerberos) implementations, the service
> principal used for the SASL/GSSAPI/Kerberos connection is the canonical
> version of the hostname returned from the results of the SRV query.
> 
> This is obviously bad, as the use of an insecure directory service (DNS)
> to perform both of these lookups presents an opportunity for a MITM
> attack. Worse is a current proposal that the server should be able to
> tell the client the principal name to use.
> 
> So, for a Jabber connection to 'example.org', should we connecting to
> the service principal 'xmpp/example.org'? But, how does this work where
> 'example.org' is providing multiple XMPP servers - should they all have
> a copy of the same key material, and does this present further concerns?

Domain based names may be interesting, but the drafts are not
clear to me.  I imagine someone in my organization knows addresses
for the kitten working group mailing lists, so they may be hearing
more on that.

Some years ago, I believe a certain large software company's
LDAP clients would include the service port number in their
service principal name.  So if you wanted to support Kerberos
access to an LDAP server running on port 777 on oc.bo.co, you
would want to provide it with a key for LDAP:777/oc.bo.co (or
LDAP/oc.bo.co:777 or something, I don't remember.)

We didn't particularly appreciate it at the time, and I would
be a little surprised if anyone is doing anything like that today.
Technically I believe it may address your second point, and at
least it's easy for both parties to determine the service-specific
name, but the service distinction probably shouldn't really be
tied to a service port number.

   Donn Cave, donn at u.washington.edu