[Standards] [Fwd: domain-based service names redux]

Peter Saint-Andre stpeter at jabber.org
Mon Jun 11 17:49:57 CDT 2007


FYI. Discuss on the kitten at ietf.org list.

-------- Original Message --------
Date: Mon, 11 Jun 2007 16:42:02 -0600
From: Peter Saint-Andre <stpeter at jabber.org>
To: kitten at ietf.org
Subject: domain-based service names redux

Warning: I am far from a Kerberos or SASL expert, and this email mostly
channels feedback from several XMPP developers (cc'd on this message,
also cc'ing sasl at ietf.org). My apologies for any inaccuracies.

That said...

I'm working to understand if draft-ietf-kitten-gssapi-domain-based-names
and draft-ietf-kitten-krb5-gssapi-domain-based-names solve a problem
we're having in the XMPP community. As you may know, XMPP (RFC 3920)
essentially streams XML over a long-lived TCP connection. Large XMPP
deployments tend to require tens of thousands of TCP connections (or
more) from clients to a server, with the result that they are often
architected with multiple connection managers (perhaps one CM per 10k
clients) hooked into a core router. Client connections to the connection
managers are often managed through a front-end load balancer. We can
visualize as follows (where "CM" is a connection manager and "C" is a
client):

              XMPP ROUTER
             /     |    \
           CM     CM     CM
             \     |    /
             LOAD BALANCER
             /     |    \
            C      C     C

(Such a solution *could* be managed via SRV, but in practice that is not
feasible for some large XMPP deployments.)

The problem is that a client doesn't know which CM it has connected to
(e.g., cm6.example.com), since that information is hidden by the load
balancer in the middle (all clients appear to be connected to the IP
address of the load balancer). For non-Kerberos deployments that doesn't
matter, but it does matter for Kerberos deployments since a client needs
to know the address of its service.

My understanding of draft-ietf-kitten-gssapi-domain-based-names is that
it should be possible to name a CM in such a deployment as a
GSS_C_NT_DOMAINBASED_SERVICE name like so:

    xmpp at example.com@cm6.example.com

Where the form is "service at domain@hostname".

In the context of the Kerberos 5 GSS-API mechanism, that would result in
a principal name of:

    xmpp/cm6.example.com/example.com

Based on my reading of RFC 4752, I assume that in a SASL exchange using
the GSSAPI mechanism, the client can replace GSS_C_NT_HOSTBASED_SERVICE
with GSS_C_NT_DOMAINBASED_SERVICE in the following operation (Section
3.1 of RFC 4752):

     The client calls GSS_Init_sec_context, passing in
     input_context_handle of 0 (initially), mech_type of the Kerberos V5
     GSS-API mechanism [KRB5GSS], chan_binding of NULL, and targ_name
     equal to output_name from GSS_Import_Name called with input_name_type
     of GSS_C_NT_HOSTBASED_SERVICE (*) and input_name_string of
     "service at hostname" where "service" is the service name specified in
     the protocol's profile, and "hostname" is the fully qualified host
     name of the server.

Where the asterisk refers to the following note:

     (*) Clients MAY use name types other than GSS_C_NT_HOSTBASED_SERVICE
     to import servers' acceptor names, but only when they have a priori
     knowledge that the servers support alternate name types.  Otherwise
     clients MUST use GSS_C_NT_HOSTBASED_SERVICE for importing acceptor
     names.

It is less clear to me how this service name should be communicated to
the XMPP client. Currently in some XMPP implementations the Service
Principal Name of the connection manager is returned to the client from
the CM after the TCP connection is made (typically after TLS has been
negotiated):

http://mail.jabber.org/pipermail/xmppwg/2006-April/002379.html

This is a mere assertion, but no one in the XMPP community has yet
figured out a better method for communicating the CM's name to the
client (at least in a way that is deployable in existing organizational
environments).

Would the use of the GSS_C_NT_DOMAINBASED_SERVICE name provide
information that is stronger than a mere assertion by the CM? My reading
of draft-ietf-kitten-gssapi-domain-based-names indicates that the
"hostname" portion of the GSS_C_NT_DOMAINBASED_SERVICE name may be
obtained via insecure service discovery mechanisms (DNS SRV is
mentioned) as long as the service and domain are obtained in a secure
fashion. Would communication of the GSS_C_NT_DOMAINBASED_SERVICE name
after TLS negotiation with the service is complete qualify as obtaining
the service and domain in a secure fashion? It seems to me that before
TLS is negotiated, communication of the GSS_C_NT_DOMAINBASED_SERVICE
name from the CM to the client would indeed be a mere assertion, but
that after TLS is negotiated between the XMPP client and server, the
client has securely verified the identity of the XMPP server (e.g., the
combination of service name "xmpp" and domain name "example.com") and
therefore can accept the hostname asserted by the connection manager.
(Naturally, that hostname might also be discoverable via SRV through
resolution of "_xmpp-client._tcp.example.com.".)

If that is right, then the CM could legitimately communicate something
like the following to the client after they complete the TLS negotiation
(line breaks included for readability only):

    <stream:features>
      <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
        <mechanism
        GSS_C_NT_DOMAINBASED_SERVICE='xmpp at example.com@cm6.example.com'>
          GSSAPI
        </mechanism>
        <mechanism>DIGEST-MD5</mechanism>
        <mechanism>PLAIN</mechanism>
      </mechanisms>
    </stream:features>

I freely admit that I may be mistaken, so suggestions from folks in the
KITTEN and SASL WGs would be most welcome.

Thanks!

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20070611/d3e7725a/smime-0001.bin


More information about the Standards mailing list