> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Cullen Jennings > > Based on the discussion I've seen so far, the primary use case for > this modification is to allow the SBC to do media steering so it can > steer the RTP through a path that provides better QoS. As you say, > this could be achieved by modifying the SDP and changing RFC 4474 to > allow that, but there are probably some other approaches we should be > considering as well, including ones that may need to be done outside > of SIP. If there's consensus that this is the problem > that needs solving, then I'll get with the SIP, SIPPING, and MMUSIC > chairs and figure out a process for how to evaluate the various > options and get this moving forward. If this isn't > the primary use case, then I think we probably need some more > discussion to get a clearer idea of what the problem is.
Part 2 of this series: Signing the Contact URI. I believe 4474 signs the Contact URI to prevent malicious attackers from intercepting a signed request and replacing the Contact in order to receive all later requests/responses. Or at least that's how I read rfc4474's reason for it: The Contact header field is included to tie the Identity header to a particular user agent instance that generated the request. Were an active attacker to intercept a request containing an Identity header, and cut-and-paste the Identity header field into its own request (reusing the From, To, Contact, Date, and Call-ID fields that appear in the original message), the attacker would not be eligible to receive SIP requests from the called user agent, since those requests are routed to the URI identified in the Contact header field. However, the Contact header is only included in dialog-forming requests, so it does not provide this protection in all cases. While I appreciate the desire, I don't see how signing the Contact actually accomplishes this goal in many cases. A malicious attacker can easily insert Via and Record-Route headers, to get any subsequent in-dialog requests/responses. This is in fact what the non-MitM baiting attack described in draft-kaplan-sip-baiting-attack-02 does. But there is potential for a Contact URI to be used for out-of-dialog requests, for example in later REFERs and certain Conference applications, which is what triggered the need for GRUU's. In that sense signing it may be valuable. Unfortunately that contradicts the goals of certain middle-boxes, and figuring out if those middle-boxes are changing it for malicious vs. legitimate reasons is an impossible task. Note that not signing the contact does not hurt the strength of the signed request directly (because the Record-Route issue already weakened that), but hurts the validity of the Contact for use in future out-of-dialog requests from the UAS. The question then is what exactly is harmed if a malicious attacker inserts itself in the Contact for such use-cases. If a later REFER or conference INVITE is sent to the attacker instead of the correct UA, it will only succeed in transferring or joining the call if it actually reaches the right UA. Certainly the attacker could pretend to be the correct UA, and thus either perform full impersonation, or simply view SIP signaling which it otherwise might not get to. However this form of attack is far less likely and less fruitful than those available to attackers by simply inserting Record-Routes as done in the baiting attack for the original request, and can be detected by RFC4916-type upstream signing in response to the REFER or conference INVITE. Therefore, I propose a straw-man: Allow the authenticating signer and/or the UAC to choose whether to sign the Contact URI, by having it add an Identity-Info param such as "no=contact". The inclusion of this param means the signature does not include the Contact addr-spec. The Identity-Info header is itself not signed, but that won't matter because if an attacker adds this but the signature did include the contact, it will invalidate the signature, and vice-versa if an attacker removes it. This weakens things as described earlier, but it's up to the originator to decide if they're ok with that. (A better-than-nothing approach) Regardless, I suggest we strongly recommend in any update to RFC 4474 that GRUU's be used for signed Contact URI's. When the Contact is a GRUU using the domain name instead of the UAC's host address, there is less need for middle-boxes to change the Contact. It is often changed to hide host-specific information, and with a GRUU that can be avoided. (it won't go away completely, but it increases the odds of success if it is still signed) -hadriel _______________________________________________ Sip mailing list https://www.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
