Re: domain-based service names redux
Jeffrey Hutzelman <jhutz@cmu.edu> Tue, 12 June 2007 20:05 UTC
Return-path: <kitten-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCbz-0000JL-Os; Tue, 12 Jun 2007 16:05:07 -0400
Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1HyCby-0000Ie-7x for kitten-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 16:05:06 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCbw-0000G7-An for kitten@ietf.org; Tue, 12 Jun 2007 16:05:04 -0400
Received: from currant.srv.cs.cmu.edu ([128.2.194.193]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HyCZJ-0004VH-IK; Tue, 12 Jun 2007 16:02:25 -0400
Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l5CK2DXd028304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2007 16:02:17 -0400 (EDT)
Date: Tue, 12 Jun 2007 16:02:13 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Peter Saint-Andre <stpeter@jabber.org>, kitten@ietf.org
Message-ID: <4B0DFFA50C0FE2C052B56D29@sirius.fac.cs.cmu.edu>
In-Reply-To: <466DCFBA.9020001@jabber.org>
References: <466DCFBA.9020001@jabber.org>
Originator-Info: login-token=Mulberry:014JKSGkr6B44s3QqbExDCiXcEyUVnxgtNB8B/FhI=; token_authority=postmaster@andrew.cmu.edu
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: jhildebrand@jabber.com, linuxwolf@outer-planes.net, sasl@ietf.org, Jeffrey Hutzelman <jhutz@cmu.edu>
Subject: Re: domain-based service names redux
X-BeenThere: kitten@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/kitten>
List-Post: <mailto:kitten@lists.ietf.org>
List-Help: <mailto:kitten-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@lists.ietf.org?subject=subscribe>
Errors-To: kitten-bounces@lists.ietf.org
On Monday, June 11, 2007 04:42:02 PM -0600 Peter Saint-Andre <stpeter@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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten
- domain-based service names redux Peter Saint-Andre
- Re: domain-based service names redux Jeffrey Hutzelman
- Re: domain-based service names redux Martin Rex
- Re: domain-based service names redux Peter Saint-Andre
- Re: domain-based service names redux Jeffrey Hutzelman
- Re: domain-based service names redux Jeffrey Hutzelman
- Re: domain-based service names redux Joe Hildebrand
- Re: domain-based service names redux Peter Saint-Andre
- Re: domain-based service names redux Nicolas Williams
- Hostbased service names (Re: domain-based serviceā¦ Nicolas Williams
- Re: domain-based service names redux Michael B Allen
- Re: domain-based service names redux Nicolas Williams
- Re: domain-based service names redux Nicolas Williams
- Re: domain-based service names redux Martin Rex