Interesting stuff - completely agree that we could use clarification on how to do this stuff in some document. I have been wanting to so some work on an information document to help clarify this stuff so send me your gripes :-)
Inline On 8/19/03 13:05, "Udi Tirosh (Weintrob)" <[EMAIL PROTECTED]> wrote: > 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. > I agree with this logic - however, I don't see the problem. Say P1.com forms a TLS connection to P2.com and presents a certificate for p2.com and it arrived on file descriptor (fd) 7. Next time P2 wants to send a message to P2.com, it looks in it's table of current connections and finds that it can send to P2.com over fd 7. There is no post connection validation but there is no need for one either. The point is the name saved in the host to fd map must be the name from the cert presented not something pulled out of a via or elsewhere. If P2 wants to go police the via P1 inserted, that may be fine I don't know. It should certainly tag the received from via with something that will cause replies to go to the person fd 7 is connected to not somewhere else. > (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. I hope not, I suspect very few UA will be able to act as TLS servers because they won't have a FQDN or a certificate bound to it. > 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. UA does TLS connection to proxy.com. Proxy.com presents cert that says it is proxy.com. UA does post validation that is who it meant to connect to. Now UA registers at [EMAIL PROTECTED] and the proxy uses Digest to authenticate the UA is [EMAIL PROTECTED] The proxy now saves that any requests to [EMAIL PROTECTED] can be sent down this file descriptor. Some other proxy sends a sips:[EMAIL PROTECTED] to proxy.com, it looks this up, finds it has a TLS connection to this UA and sends it on down. The UA could have authenticated to the proxy with mutual TLS or some SIM card scheme and it would be about the same as above. > > Regards, > Udi Tirosh. > Hope this makes sense - I can try and explain better if this did not. Cullen _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
