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

[Peter Saint-Andre <[e-mail]>]

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

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/