_____
From: Jeroen van Bemmel [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 15, 2007 7:26 PM To: Hadriel Kaplan; [EMAIL PROTECTED] Cc: 'sip List' Subject: Re: SIPSEC comments (Was Re: [Sip] Question on SIPSecurityconsiderations forfuture extensions) 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.) Ahh, I think I understand what you mean - essentially stick a timed cookie param in the contact-uri or this header so that the UAS knows the incoming Invite was from a previous Connect. So not really stopping a MITM as much as just un-authorized Invites? I don't think it really stops MITM because the MITM will get the 200 ok of the Connect and thus know the contact/req-uri to use for the Invite. It's really the cert verification before the Invite that would prevent MITM, and thus my question in another email of what that verification would be. One could actually have the UAC and UAS stick their cert fingerprint in the Connect header, so that the UAS/UAC can check the new TLS connection is from that previous Connect, before even receiving an Invite. (but it would still not stop a MITM unless there was some way to verify the cert's validity) 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. Ahh, got it. But if a b2bua wanted to let the Connect happen it would get out of the way and not replace the contact. (but of course I don't think a b2bua would want to let that happen, because I don't think their owners would want to let it happen - and they have the control to stop it) Regards, Jeroen ----- Original Message ----- From: Hadriel <mailto:[EMAIL PROTECTED]> Kaplan To: 'Jeroen van Bemmel' <mailto:[EMAIL PROTECTED]> ; [EMAIL PROTECTED] Cc: 'sip List' <mailto:[email protected]> 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
