I have two thoughts (doubts) regarding SIP standard and TLS: (1). TLS and mutual authentication handshake: When initiating a proxy to proxy (say P1 and P2) connection, both parties will want to authenticate thus mutual hand shake will be used. Lets assume that P1 initiated the connection. Both parties will validate the certificates they have received. P1 (which is the proxy that initiated the request) can perform a post connection assertion Vs. the address it holds of P2. P2, however, can not perform post connection assertion until it has received the first message. After that message has been received, still there is no sure way to post connection assert. If compared to the VIA header, the altDNS field of the certificate might be wrong because of nut ( as via usually is an IP address and altDNS is usually an FQDN). If compared to the from header, it might be wrong if the request was proxied. I see no way to post connection assert from the side of P2. The way I see it if P2 wants to have a secure connection with P1, it can not use the mutual auth built-in mechanism of TLS, and must initiate it's own connection.
(2). rfc3261 section 18 it is advised that 2 proxies wanting to use persistent connection will need to open two connections, one for each direction. I think that can be extrapolated to UA<->proxy connections as well. In section 26.3.2.1, however, the rfc recommends to save the connection of the registering client and have the proxy use that connection to send messages to the client. Now, the proxy can send incoming requests to the UA opening a new connection, but this connection is not authenticated by the UA. (if it wants to authenticate the connection we are back in (1). I think more clarification is needed for the mechanism to use in order to match connection to transactions. Regards, Udi Tirosh. _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
