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
