On Wed, Jul 6, 2011 at 4:54 PM, Olle E. Johansson <o...@edvina.net> wrote:
> > 6 jul 2011 kl. 17.28 skrev Brez Borland: > > > On Wed, Jul 6, 2011 at 4:13 PM, Iñaki Baz Castillo <i...@aliax.net> > wrote: > > 2011/7/6 Olle E. Johansson <o...@edvina.net>: > > >> Good question. However, checking a server certificate (matching the > > >> domain) just makes sense (IMHO) for requests. This is, an UAC sends a > > >> request to a proxy/server (depending Route or RURI). The proxy/server > > >> presents a TLS certificate including N certified domains. The UAC > > >> match the request destination domain against the domains in the > > >> certificate. > > >> > > >> But in case of a response I see no way to apply the same. Which is the > > >> destination of a SIP response? it must only be routed according to > > >> section XX.XX (sorry, no time now) of RFC 3261, this is, typically > > >> using the same connection if it's TCP/TLS or inspecting the Via > > >> sent-by/received/rport in case of UDP. So I don't fully understand > > >> when you say "the proxy tries to set up a secure connection for the > > >> response to 192.168.40.20". > > > > > > Unless the proxy receiving the request requested a client certificate > it can NOT reuse the connection for the response here if the Via has a SIPS: > uri. It needs to validate the SIPS session and get the server certificate > for the response... The UA can and should send the response trying to reuse > the same connection though. THat's why I used two proxys in this example. > > > > Maybe I cannot understand what you mean, but I think you are mixing > > sending requests (in-dialog) and sending responses. Correct me if I'm > > wrong: > > > > - Proxy A opens a TLS connection with Proxy B and validates the > > certificate sent by Proxy B. > > - But Proxy A does not present a certificate to Proxy B. > > - Proxy B anyhow accepts the request and gets a reponse from downstream. > > - Proxy B *can*^send the response to Proxy A reusing the existing TLS > > connection even if there is no certificate from Proxy A. > > > > Am I wrong? > > > > This is a proper scenario, you're right. > > > > > > > > In case of in-dialog requests sent to Proxy B to Proxy A, then we get > > into RFC 5923 "SIP Connection Reuse" (;alias parameter in Via header, > > TLS required, client and server certificate required...). > > Again I think the RFCs are unclear here. While RFC 3261 generally talks > about sending back on the connection a request was received on, it also > states that if that fails it has to open a connection using the Via header. > If the VIA header now contains a SIPS transport and a FQDN - that's an > interesting situation. > > This is interesting. So to clarify the issues again to make sure we're all > on the same square in the chess-game: > > - A proxy (A) forwards a SIP request with a SIPS r-uri to another proxy > (B). The VIA header indicates SIPS and has a domain name. The proxy that > receives the request shows a server CERT, but doesn't require a client > certificate. > > 1) For the response - can we reuse the connection? > Yes, you _should_ use established connection to send responses. It's a reliable connection, therefore "full-duplex". > 2) If the connection is lost, does proxy B has to open a new TLS > connection back to A, validating A's certificate agains the via header? > I don't know where how to back this, but IMHO the _response_ message indicates that upstream elements were "clients" as such. That is, if proxy is forwarding a, say, 2xx response and Via indicates a next hop to be TLS this says that that hop was a client to _this_ forwarding proxy. Deducting from here, the proxy that's forwarding the response should not be required to validate certificates of the upstream elements. But again, if somebody could back by pointing to the paper, would be great. 3) for a request from the UA behind proxy B to the UA behind proxy A > (contacts use TLS, record-route use TLS), can we reuse the existing > connection that was used for the connection from proxy A to proxy B? > Same as to (1). Regards, Brez > > What are your thoughts? > > /O > > > /O _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
