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

[=JeffH <[e-mail]>]

On Tue, 09 Nov 2010, PeterSA replied:
 >
 > 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.


great, thx, that works for me and seems much clearer.


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

good, we're on same page.


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

Ok.


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

Ok, good idea.


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

ah ha, yes, you're correct, nevermind.

thanks,


=JeffH