[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] What 4474 signs part-2 [was: Proposal to Revise RFC 4474]
> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> Behalf Of Hadriel Kaplan
> Sent: 16 April 2008 06:20
> To: Cullen Jennings; Dean Willis
> Cc: SIP IETF; jon.peterson at neustar.biz
> Subject: [Sip] What 4474 signs part-2 [was: Proposal to
> Revise RFC 4474]
>
>
> > -----Original Message-----
> > From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip