John,
There are a number of cases (e.g. IMS) where once gruus are used a b2bua
will be in exactly the situation you describe. So its not an idle question.
For reasonable features to work, the b2bua will need have the ability to
make the translation for out of dialog requests. And it will need to do
so for a period of time that is hard to predict. When the original gruu
was a permanent one, the translation should be supported for as long as
the AOR the gruu was based on remains valid, which could be months or
years. For temporary gruus its impossible to guess. Often the period may
be relatively short, but there is no way to know how long.
The safest way to ensure that this will work wold be to generate the new
gruu so it contains an encrypted form of the original gruu.
There of course may be cases where its goal to limit the lifetime. For
instance if a call was anonymous it is probably good to limit the
lifetime of the gruu to the duration of the original dialog. But such
special cases need to be considered very carefully.
Paul
Elwell, John wrote:
>
>
>> -----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
>
_______________________________________________
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
