Re: domain-based service names redux

[Jeffrey Hutzelman <jhutz at cmu.edu>]

On Monday, June 11, 2007 04:42:02 PM -0600 Peter Saint-Andre 
<stpeter at jabber.org> wrote:

> 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).

So, the model we had in mind was that you'd do a SRV record or reverse DNS 
lookup and use the result of that for the "hostname" part of the 
domain-based service name, with the "domain" part being whatever domain the 
client was configured to talk to.  Of course, that doesn't work when you 
use a "transparent" load balancer; as you noted, you need some other way of 
discovering the hostname.


> 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?

No.  It is not good enough for the service and domain to be obtained via a 
secure channel; they also have to come from a trusted source, and the 
server that is trying to prove its identity to you doesn't qualify.

The service is actually easy - it's a constant specified by the application 
protocol, at both the GSS and SASL layers.  The domain is trickier, but 
only a little - this is the string the user provided (perhaps as part of a 
URI) that says what domain he wants to talk to.  For XMPP, that is probably 
the name you used for the SRV record lookup.



> 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.".)

That seems fishy.  I think if you do that, you need to verify that the name 
the server is asserting matches its certificate.  And, of course, that the 
cert matches what the user asked for.


-- Jeff


_______________________________________________
Kitten mailing list
Kitten at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten