Subject: Re: [xmpp] accommodating server-to-server (was: I-D Action:draft-saintandre-tls-server-id-check-10.txt)

From: =JeffH <[email-masked]>
Date: Fri, 05 Nov 2010 14:33:08 -0700

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 09 Nov 2010 10:05:20 +0800

On 11/6/10 5:33 AM, =JeffH wrote:
> 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.

You're right. I've scrubbed mention of "TLS client" from that paragraph:

      Note: In some application protocols that support server-to-server
      communication (e.g., XMPP), the procedure described in this
      section can be performed by an application server acting when
      verifying an incoming server-to-server connection, not only by an
      application client when verifying the server with which it is
      interacting to establish an outgoing client-to-server connection.
      In this case, the application server verifies the identity of the
      peer server that is attempting to connect and uses as its
      reference identifier the DNS domain name asserted by the peer
      server (e.g., as triggered by a request to send a message from an
      entity associated with the peer server to an entity associated
      with the application service).  Other than the source of the
      reference identifier and the reversal of roles, the verification
      process remains unchanged.

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

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

By "service" here we're talking about an application service, not a TLS
server. In the server-to-server scenario, we're talking about one
application service verifying the identity of a peer service.

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

I don't particularly want to do a lot of refactoring on this I-D to
incorporate the server-to-server case. Perhaps this note belongs in
documents that re-use the server-id-check methodology -- e.g., we could
add it to draft-ietf-xmpp-3920bis for the XMPP case.

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

I think that's out of scope for this I-D, and we already say so in
Section 1.4.2.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Philipp Hancke <[email-masked]>
Date: Tue, 09 Nov 2010 10:27:22 +0100

Hi Jeff,
[...]
> the other end of the incoming connection.

 From the TLS protocol level both occurences of "client" should have 
been "server", yes.

> on asserted app service identity.

Exactly.

Yes.

> such that we don't have to needlessly repeat text.

You might split this in such a way that you describe how to get the 
certificate and reference identifiers first (which is slightly different 
for client and server) and then the process of validation for a given 
certificate and a given reference identifiers (which no longer depends 
on whether a client or a server is doing that). Essentially, that means 
replacing most occurences of "client" with "verifying entity".

However, I am not sure if this really going to improve readability for 
anyone that is not looking for xmpp-s2s :-/

philipp

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 10 Nov 2010 06:02:12 +0800

On 11/9/10 5:27 PM, Philipp Hancke wrote:
> From the TLS protocol level both occurences of "client" should have been
> "server", yes.
> 

Right, which is why I think it's better to put this in 3920bis.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 10 Nov 2010 06:14:00 +0800

[trimmed to the XMPP WG list only]

> Right, which is why I think it's better to put this in 3920bis.

The best place seems to be Section 13.7.2.1 (on validation of server
certificates). I propose adding the following paragraph at the end of
that section:

   In the case of server-to-server communication, the matching procedure
   described in [TLS-CERTS] can be performed by an application server
   (receiving entity) when verifying an incoming server-to-server
   connection from a peer server (initiating entity).  In this case, the
   receiving entity verifies the identity of the initiating entity and
   uses as its reference identifier the DNS domain name asserted by the
   initiating entity.  However, the matching procedure described in
   [TLS-CERTS] remains unchanged and is applied in the same way.

/psa

---

From: Philipp Hancke <[email-masked]>
Date: Wed, 10 Nov 2010 21:58:28 +0100

[...]
>> Right, which is why I think it's better to put this in 3920bis.

I am not sure if I agree (yet).

>     receiving entity verifies the identity of the initiating entity and

s/the identity/the asserted identity/?

>     initiating entity.

in the stream's from attribute.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 11 Nov 2010 06:33:53 +0800

> I am not sure if I agree (yet).

It doesn't seem to belong in draft-saintandre-server-id-check, given
that the entire document is focused on application clients. Please note
Section 1.4.2 of that document, and how strictly we limited the scope.

> s/the identity/the asserted identity/?

I think that's potentially confusing, because nowhere in
draft-saintandre-server-id-check do we talk about asserted identity, and
that's covered anyway by explaining where the reference identifier comes
from in this case.

> in the stream's from attribute.

Changed to:

   ... asserted by the initiating entity in the 'from' attribute of the
   initial stream header.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/