2011/7/7 Olle E. Johansson <o...@edvina.net>: >>> But SIP outbound says that this only applies when we have mutual TLS >>> identification - client and server certificate. >> >> Correct me if I'm wrong, but I don't think that SIP outbound requires >> each UA/client to have an own certificate.
> We're still talking proxy2proxy here. > The idea with SIP outbound is that the client manages the connection, so if > it goes down, the client reopens. That means, as you say, that the client > doesn't have to have a cert. But you were speaking about "SIP outbound", right? :) >> Yes, I know. I just think that "failover in responses" is a too much >> exotic stuf. Never seen that working, never. Also, in any other >> internet protocol there is no "failover for responses". > Not many protocols have such a long time between request and response as SIP > has in the INVITE transaction. Good point. However, have you ever seen SIP response failover working in any implementation? not me :( >> However, client/server certification validation could occur in any >> case. A proxy B could be configured to require and validate >> certificate from proxy A. This becomes funny when: >> >> - Proxy A connects TLS to proxy B. >> - Proxy A validates certificate of proxy B. >> - Proxy A sends its certificate to proxy B. >> - Proxy B verifies certificate of proxy A (but take into account that >> there is no SIP request yet, so can only verify cert expiration, >> signature and so). >> - After validation, proxy A sends a request with From (or PAI, or ...) >> a specific domain xxx.org. >> - Proxy B now must *authorize* such request (it would inspect the cert >> of proxy A and lockup for xxx.org domain within it). >> - If so, the request is authorized. If not => 403? (but the TLS >> connection remains open, I hope). >> - Later proxy A could send another request with a different originator >> domain (in From) to proxy B. >> - Authorization in proxy B should be performed for *each* received request. >> >> So, initially there is cert validation (signature, expiration, >> revocation...). Later, for each SIP request there must be >> authorization (based on request originator domain and domains included >> within the validated certificated). >> >> >> I suppose XMPP works in this way when using federation between >> different domains. > Yes, it becomes complicated. I don't really know, have to re-read RFCs, how a > SIP server requests a client cert. All I said above is what I understood by reading RFC 5922 (which updates RFC 3261). > Let's continue the research! > THis is a very good discussion. When I get a sips/TLS inter-domain communication, I can die in peace :) -- Iñaki Baz Castillo <i...@aliax.net> _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
