Hadriel, MITM encrypting its own URI: true, but it would not be able to determine which Contact URI the UAS proposed (it could be different from the UAS' own IP address+port). If the MITM would try to impersonate the caller while "guessing" the Contact, the UAS would detect that the request URI did not contain its magic bits. The UAS could formulate these bits such that it can correlate a request after CONNECT with an earlier CONNECT, and refuse all "out-of-the-blue" requests (and do things like enforce a maximum time interval, etc.)
My point about the additional benefit of using a header different from "Contact", is that current B2BUA implementations (e.g. SBC) typically insert their own Contact. However, some do pass headers unknown to them, so a new header could survive a B2BUA that would otherwise unknowingly/unintentionally block a CONNECT. Regards, Jeroen ----- Original Message ----- From: Hadriel Kaplan To: 'Jeroen van Bemmel' ; [EMAIL PROTECTED] Cc: 'sip List' Sent: Thursday, August 16, 2007 1:09 AM Subject: RE: SIPSEC comments (Was Re: [Sip] Question on SIPSecurityconsiderations forfuture extensions) I don't see how the contact encryption would prove anything about either side. A middle-man can just as easily use the key from the Connect message to encrypt its own contact URI. As for the last point, any b2bua or proxy wanting to block the Connect would simply block the Connect (reject it with a 420 or 501, for example). They don't need to muck with the contact. -hadriel ------------------------------------------------------------------------------ From: Jeroen van Bemmel [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 15, 2007 1:23 PM To: [EMAIL PROTECTED] Cc: sip List Subject: Re: SIPSEC comments (Was Re: [Sip] Question on SIPSecurityconsiderations forfuture extensions) Frank, Elaborating on: 4 - would be nice to have a mechanism to encrypt the Contact URI in the response, specifically for the caller. An incoming request to a contact that was sent encrypted gives higher trust. At least it should be integrity protected somehow. Suppose the UAS would include a new header "Secure-Contact" containing a contact URI encrypted using a key that the caller passed in its CONNECT request. That would provide: - a means for the UAC to check the integrity of the contact - a means for the UAS to verify that the caller is the same as the party that CONNECTed before (i.e. by including some unique bits in the contact URI) - a way to avoid B2BUA elements blocking CONNECT by not forwarding the UAS Contact header Furthermore, the draft could talk about how the UAS could specify a different machine than itself, for example a proxy with which it maintains an outbound connection. This could be a different proxy than the one through which the CONNECT came in. It could also be a proxy with which the UAS maintains a non-SIP connection (say a VPN/IPSec connection). Such a proxy might not be able to present a certificate on behalf of the UAS, but at least it would provide a mechanism to side step the SIP proxy infrastructure Regards, Jeroen
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
