Re: [certid] accommodating server-to-server (was: I-D Action:draft-saintandre-tls-server-id-check-10.txt)
=JeffH <Jeff.Hodges@KingsMountain.com> Fri, 05 November 2010 21:32 UTC
Return-Path: <Jeff.Hodges@KingsMountain.com>
X-Original-To: certid@core3.amsl.com
Delivered-To: certid@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix)
with ESMTP id 14C823A695A for <certid@core3.amsl.com>;
Fri, 5 Nov 2010 14:32:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.24
X-Spam-Level:
X-Spam-Status: No, score=-101.24 tagged_above=-999 required=5 tests=[AWL=0.425,
BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_83=0.6,
USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLS-SRPi6Klu for
<certid@core3.amsl.com>; Fri, 5 Nov 2010 14:32:58 -0700 (PDT)
Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com
[69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id C0E063A6905 for
<certid@ietf.org>; Fri, 5 Nov 2010 14:32:57 -0700 (PDT)
Received: (qmail 17246 invoked by uid 0); 5 Nov 2010 21:33:10 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by
cpoproxy1.bluehost.com with SMTP; 5 Nov 2010 21:33:10 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com;
h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User;
b=oFfiJB/kjvB4FswvJrIS5YJJuXQOyJcVmXv37rHeOoLaOIk/XfRkRGuPpcbApGhjtd8WtXeKEcJVGKK7FV+UMSMZc1FzJVM4tOs+nubUHJNebG98AVUZwkq09y0iUuLe;
Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.163]) by
box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69)
(envelope-from <Jeff.Hodges@KingsMountain.com>) id 1PETuI-0004Ef-9n;
Fri, 05 Nov 2010 15:33:10 -0600
Message-ID: <4CD47814.3010508@KingsMountain.com>
Date: Fri, 05 Nov 2010 14:33:08 -0700
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: IETF cert-based identity <certid@ietf.org>,
XMPP Working Group <xmpp@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com}
{sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com}
Subject: Re: [certid] accommodating server-to-server (was: I-D
Action:draft-saintandre-tls-server-id-check-10.txt)
X-BeenThere: certid@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Representation and verification of identity in certificates
<certid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/certid>,
<mailto:certid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/certid>
List-Post: <mailto:certid@ietf.org>
List-Help: <mailto:certid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/certid>,
<mailto:certid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Nov 2010 21:32:59 -0000
Peter Saint-Andre replied: > > Philipp Hancke replied: > >> Peter Saint-Andre wrote: >>> >>> Note: In some application protocols, the procedure described in >>> this section can be performed by an application server acting as a >>> TLS client when verifying a server-to-server connection, not only by >> >> s/TLS client/TLS server/ > > In XMPP at least, if Romeo's personal server (montague.lit) attempts to > connect to Juliet's personal server (capulet.lit), he asserts to her > that he is montague.lit and she takes that as her reference identifier. > Thus her server is acting as a TLS client in relation to the presented > identifiers in the certificate that Romeo's personal server provides. > This is what's distinctive about the server-to-server case -- an > application service is acting as a TLS client. > > ... > >> I think it is not clear who is verifying > > If you try to connect to me, I'm going to verify you -- even if I'm an > XMPP server. > >> (probably because both parties >> are for xmpp-s2s). > > Yes, ideally the verification happens in both directions. To me, what Peter wrote in the proposed "Note:" is confusing because it is labeling an entity as a "TLS client" that is not a TLS client in the TLS protocol sense -- it is playing the TLS server role, and is only behaving as a "TLS client" would in the sense of verifying the entity at the other end of the incoming connection. In this case we ostensibly have the "peer server" -- legitimately acting as a TLS client -- presenting its certificate during the TLS handshake, and thus the application service is obliged to perform the same checks on the peer server's asserted identity, as an actual TLS client performs on asserted app service identity. yes? If so, it seems we're linguistically standing on our heads here trying to shoehorn the notion of "verification of client identity (by the app service)" into section 4 "Verification of Service Identity". I propose that we need to perhaps have a separate section for the former and figure out how to refactor the more detailed section 4 subsections such that we don't have to needlessly repeat text. It also seems we ought to do this in a general fashion such that its applicable for any TLS server processing an inbound connection where the client elects to assert its identity (eg by presenting a cert). =JeffH
- Re: [certid] accommodating server-to-server (was:… =JeffH
- Re: [certid] accommodating server-to-server (was:… Peter Saint-Andre
- Re: [certid] [xmpp] accommodating server-to-serve… Philipp Hancke
- Re: [certid] [xmpp] accommodating server-to-server Peter Saint-Andre
- Re: [certid] accommodating server-to-server (was:… =JeffH