> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Hadriel Kaplan > Sent: 16 April 2008 06:20 > To: Cullen Jennings; Dean Willis > Cc: SIP IETF; [EMAIL PROTECTED] > Subject: [Sip] What 4474 signs part-2 [was: Proposal to > Revise RFC 4474] > > > > -----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) [JRE] I am trying to figure out how things will work if a middlebox rewrites a GRUU. Consider this scenario. A sends GRUU1 to B in a dialog-forming request. Middlebox M rewrites the GRUU1 to GRUU2, so B receives GRUU2. B sends GRUU2 to C. B closes the dialog with A. C sends a new request to GRUU2, which I presume would be constructed so that the request reaches M. Is it certain that M will have retained the necessary state to map GRUU2 to GRUU1? In other words, how does M ensure that the lifetime of GRUU2 matches the lifetime of GRUU1?
John _______________________________________________ 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
