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@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@example.com@cm6.example.com

Where the form is "service@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@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@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

domain-based service names redux

Attachment: smime.p7s