SRV records and canonicalization - Kerberos

This is a discussion on SRV records and canonicalization - Kerberos ; 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 ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: SRV records and canonicalization

  1. SRV records and canonicalization

    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?

    Cheers,

    Simon.
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. Re: SRV records and canonicalization

    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?
    >
    > Cheers,
    >
    > Simon.


    What we want in this case is the use of Domain-based Service Names
    as described in

    draft-ietf-kitten-gssapi-domain-based-names-01.txt
    draft-ietf-kitten-krb5-gssapi-domain-based-names-01.txt

    Please review the drafts and send any feedback you may have to
    the Kitten WG and Kerberos WG mailing lists.

    Jeffrey Altman

  3. Re: SRV records and canonicalization

    On Thu, Apr 13, 2006 at 01:12:36PM +0100, Simon Wilkinson wrote:
    > I'm interested in what people feel the 'correct' approach is to the
    > following situation.


    See:

    draft-ietf-kitten-gssapi-domain-based-names-01.txt
    draft-ietf-kitten-krb5-gssapi-domain-based-names-01.txt

    You have found a third example use case for domain-based service
    principal names.

    Which reminds me, I need to jump on that...

    Nico
    --
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  4. Re: SRV records and canonicalization

    In article <443E4034.3010606@sxw.org.uk>,
    simon@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@u.washington.edu

+ Reply to Thread