Subject: [Sip] Proposal to Revise RFC 4474

From: Dean Willis <[email-masked]>
Date: Sat, 12 Apr 2008 03:26:20 -0500

We've had a lot of recent discussions about issues relating to the use  
of RFC 4474, and I've had a bunch of side conversations with people  
this week on the same topic.

Here's where I think we're at:

RFC 4474 is pretty good. Since it was published, we've learned more  
about the problem space. In the largest part, we've learned that the  
authors of RFC 4474 and the working group did an excellent job of  
analyzing the fundamental requirements for attaching forward  
authentication (as opposed to challenge-response) to SIP. We've also  
learned that the real world has some nastiness that isn't quite  
covered by RFC 4474, but it appears that very small adjustments to the  
specification could cover most or all of the cases we've discovered.

I'd therefore like to propose that the working group consider the task  
of narrowly revising RFC 4474 to account for four specific points:

1) Revising the "what gets signed" aspect to allow modification of the  
SDP by the SBCs we seem to keep encountering. While it is important to  
verify the SDP, we now have the DTLS-SRTP framework to vouch for the  
authenticity of the media channel. I suggest that there not be any  
optionality to "what gets signed", but that the fixed set of items be  
revised so as to allow SBC operations, and to note the dependency on  
DTLS-SRTP for media authentication.

2) RFC 4474 did not consider the requirements of calls transiting  
gateways and the issues related to expressing identities that  
originate outside the Internet, specifically phone numbers delivered  
via caller ID. While RFC 4474 can say nothing authoritative about the  
phone number, it seems that it could quite reasonably say something  
authoritative about the gateway. We've seen several proposals for  
doing this using conventions for the expression of "phone" identities  
in the From header field. I believe that a revised RFC 4474 is the  
place to document such a convention and any needed extension parameters.

3) There seems to be a valid model for what I call "stacked" Identity  
header fields that express transitive assertions.  Consider  
authentication domains A, B, and C, where B is a transit domain  
between A and C. B would be likely to trust assertions made by A, and  
might not know whether C is or is not equipped to evaluate assertions  
made by A. However,, it might be reasonable to expect that C would be  
able to validate assertions made by B. B might therefore choose to  
validate the Identity header inserted by A, and then (assuming the  
header authenticates) add another Identity header using its own  
credentials, saying in effect "B validated A's identity header and  
found it good".  If C can validate A's Identity header directly, it  
would do so. If not, it could choose to rely on B's assertion.

4) There are cases, including authentication services in the UAS and  
authentication services in a proxy having an "outbound" relationship  
(pre-authenticated persistent TLS) with the UAS where, in the absence  
of retargeting, an Identity header field could reasonably be included  
in a response as an alternative to using the more cumbersome connected- 
identity approach with UPDATE.  I expect this to be very useful in  
P2PSIP, but it has broader utility. So I would like to see RFC 4474  
extended to allow its use in  responses where it would work.

--
Dean
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 14 Apr 2008 07:53:14 -0700

Dean,

Thanks for taking the lead here on trying to get a handle on what
needs to be done.

Reading your message, what strikes me is that these issues are bigger
than just RFC 4474 - although in some cases changes to RFC 4474 may be
part of the solution.  So, I'd like to see the WG focus on is
getting a crisp definition of the problem and how to solve it,
rather than asking what changes to 4474 are required just yet.

On Apr 12, 2008, at 1:26 AM, Dean Willis wrote:
>
> We've had a lot of recent discussions about issues relating to the  
> use of RFC 4474, and I've had a bunch of side conversations with  
> people this week on the same topic.
>
> covered by RFC 4474, but it appears that very small adjustments to  
> the specification could cover most or all of the cases we've  
> discovered.
>
>
> I'd therefore like to propose that the working group consider the  
> task of narrowly revising RFC 4474 to account for four specific  
> points:
>
> 1) Revising the "what gets signed" aspect to allow modification of  
> the SDP by the SBCs we seem to keep encountering. While it is  
> important to verify the SDP, we now have the DTLS-SRTP framework to  
> vouch for the authenticity of the media channel. I suggest that  
> there not be any optionality to "what gets signed", but that the  
> fixed set of items be revised so as to allow SBC operations, and to  
> note the dependency on DTLS-SRTP for media authentication.

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.

> via caller ID. While RFC 4474 can say nothing authoritative about  
> the phone number, it seems that it could quite reasonably say  
> something authoritative about the gateway. We've seen several  
> proposals for doing this using conventions for the expression of  
> "phone" identities in the From header field. I believe that a  
> revised RFC 4474 is the place to document such a convention and any  
> needed extension parameters.

It seems to me that there are actually two issues here:

- To have a way for the gateway to say: 'this URI corresponds to
  a phone number'
- To have a way for receiver of the above assertion to determine
  whether to trust it.

These are actually separable. The first function may be useful as an
indicator even if we don't have a technical mechanism for enforcing
it. In fact, based on the discussion in Philadelphia, there seemed to
be some feeling that 'user=phone' already performed this function.
So, I would encourage the WG to figure out whether that's so or
not and if not,  and if it is not, and we decide we need a way to do  
this,
clearly the some WG could go construct something that did indicate this
(a "userpart=e164" sip uri tag for example).

The second function sees substantially more complicate, and while it
might involve modifying 4474, it might be something completely
external to RFC 4474 (e.g., enum, Dan's return routability draft).
This seems like a much more complicated problem than a simple indicator,
and I'd like to see the WG study the solution space some before
trying to close on a single approach

>
>
> 3) There seems to be a valid model for what I call "stacked"  
> Identity header fields that express transitive assertions.  Consider  
> between A and C. B would be likely to trust assertions made by A,  
> and might not know whether C is or is not equipped to evaluate  
> assertions made by A. However,, it might be reasonable to expect  
> that C would be able to validate assertions made by B. B might  
> therefore choose to validate the Identity header inserted by A, and  
> then (assuming the header authenticates) add another Identity header  
> using its own credentials, saying in effect "B validated A's  
> identity header and found it good".  If C can validate A's Identity  
> header directly, it would do so. If not, it could choose to rely on  
> B's assertion.

This transitive trust seems to be something that is used in real
deployments and it would be good to have some discussions around it.
That said, while there's been a fair bit of mailing list discussion,
I'm not sure the requirements are. For example if C is willing go
trust B, but B wants to lie, can B just remove A assertion forcing C
to rely on B's assertion? How much information does C need to
include about its evaluation policies?  I would be looking for
more consensus and understanding about what the problem
before charting some work on a solution.

> (pre-authenticated persistent TLS) with the UAS where, in the  
> absence of retargeting, an Identity header field could reasonably be  
> included in a response as an alternative to using the more  
> cumbersome connected-identity approach with UPDATE.  I expect this  
> to be very useful in P2PSIP, but it has broader utility. So I would  
> like to see RFC 4474 extended to allow its use in  responses where  
> it would work.
>

I like this idea. Once outbound is done, as you point out, it opens up  
some
ways for a proxy to authenticate both requests and responses coming
from a UA which in turn might allow Identity like assertions in
response. I be keen on drafts that extended 4474 and outbound
to do this, provided that outbound does not get blocked on these
changes.

So, while all four of these points seem to be coupled with areas where
we need discussion and work, I think it's a bit premature to decide
that what's needed is an update to RFC 4474. Rather, I'd like to see
the WG (and other WGs as required) figure out what the best technical
approach is for each of these points, and if that requires changing
4474 or 3261 or anything else, we can do that.

Cullen <with my AD hat on>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 15 Apr 2008 10:26:14 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Cullen Jennings
> Sent: Monday, April 14, 2008 10:53 AM
>

I think there are several problems with what 4474 signs, and SDP is only one of them, so I'll break it up into separate emails.  As far as I can tell, in this world there are lots of B2BUA's - and no I'm not just talking SBC's.  Most of the people on this mailing list work for companies that make some form of B2BUA or other which are not SBC's.  Some of those B2BUA's change things which will break 4474.  Whether 4474 *should* fail in such cases is a separate but important topic.

This is part-1: Signing the Call-ID.  Some of those B2BUA's change the Call-ID, even though at a higher layer it's clearly the same "request".

I believe RFC 4474 signs the Call-ID to provide cut-paste attack protection such that the Verifier can detect when a SIP request is being replayed.  To do that, the Verifier keeps a table of received call-id's and identity header signatures with their date.  If a request is received with the same identity header value for the same call-id and date (which are both signed in that identity header value's signature), then it's a replay.  Clearly valid in-dialog requests will have the same call-id, but because their date and cseq values will be different, their identity header values will be unique and not detected as a replay.

I think there are actually legitimate technical reasons why this wouldn't always work right, even in a fully rfc3261-compliant world.  For one, the request could get forked, but end up at the same verifier.  The forked requests could have unique request-uri's or Route header lists, identifying unique final targets, but the verifier would consider all but one of them a replay.  Similarly, a legitimate spiral through a verifier would be detected as a replay.  For another, the request could be responded to by the UAS with a 302, which triggers an upstream proxy to recurse the request again through the same verifier but a new final target, which would be detected as a replay.  Lastly, I believe that if UDP transport is used, the verifier can legitimately get retransmissions of requests, using the same cseq, which it would detect as replays but may really need to pass on. (ie, non-Invite requests)

Then of course there is also a world with B2BUA's.  I think a legitimate argument can be made that a 4474-signed signature *shouldn't* remain valid crossing such Call-ID-changing systems, because otherwise it opens up the door for replay attacks. [note: I am only talking Call-ID's, not other fields]

But there are ways of providing such replay protection *without* signing the Call-ID field value.  I can suggest two alternatives:

1) Create a new header or parameter to be signed and verified, which is unique per new out-of-dialog request the UAC creates - to be added by the UAC or Authenticator before signing.  Ultimately, I believe the Call-ID was signed because it was an already existing header - it was very convenient.  However, if 4474 fails to be usable in many cases were we think it should work, then it's very *inconvenient*.

2) Mandate that UAC's _STOP_ using IP Addresses in Call-ID's, with whatever new response code and mechanics we need to make that transition.  If we were to re-create SIP today, I would argue for this to the end.  If we want middle-boxes like SBC's to stop changing things we don't want them to change, stop putting things in which their owners feel compelled to change.  This obviously can't be avoided for some things, but the Call-ID is one of my pet peeves because it didn't have to be one of them.

Note that Option 2 would only work for SBC's really, not other B2BUA's who change it because they think they need to or really do need to for other reasons.  And it would have a serious problem of needing some installed SBC's to be upgraded, whereas option 1 above would have a greater chance of working today.  So my preference is Option 1.  But doing Option 2 will also solve a lot of other problems in the future, so my real preference is to do BOTH. (Option 1 for 4474, Option 2 for general practice)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 16 Apr 2008 01:19:52 -0400

> 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

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 18 Apr 2008 09:15:49 +0100

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hadriel Kaplan
> Sent: 16 April 2008 06:20
> To: Cullen Jennings; Dean Willis
> Cc: SIP IETF; [email-masked]
> Subject: [Sip] What 4474 signs part-2 [was: Proposal to 
> Revise RFC 4474]
> 
> 
> 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:
> 
> 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.
> 
> 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

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 18 Apr 2008 09:16:19 +0100

A good analysis.

John 

> Sent: 15 April 2008 15:26
> Subject: [Sip] What 4474 signs, part-1 [was: Proposal to 
> Revise RFC 4474]
> 
> 
> Behalf Of
> I think there are several problems with what 4474 signs, and 
> SDP is only one of them, so I'll break it up into separate 
> emails.  As far as I can tell, in this world there are lots 
> of B2BUA's - and no I'm not just talking SBC's.  Most of the 
> people on this mailing list work for companies that make some 
> form of B2BUA or other which are not SBC's.  Some of those 
> B2BUA's change things which will break 4474.  Whether 4474 
> *should* fail in such cases is a separate but important topic.
> 
> This is part-1: Signing the Call-ID.  Some of those B2BUA's 
> change the Call-ID, even though at a higher layer it's 
> clearly the same "request".
> 
> I believe RFC 4474 signs the Call-ID to provide cut-paste 
> attack protection such that the Verifier can detect when a 
> SIP request is being replayed.  To do that, the Verifier 
> keeps a table of received call-id's and identity header 
> signatures with their date.  If a request is received with 
> the same identity header value for the same call-id and date 
> (which are both signed in that identity header value's 
> signature), then it's a replay.  Clearly valid in-dialog 
> requests will have the same call-id, but because their date 
> and cseq values will be different, their identity header 
> values will be unique and not detected as a replay.
> 
> I think there are actually legitimate technical reasons why 
> this wouldn't always work right, even in a fully 
> rfc3261-compliant world.  For one, the request could get 
> forked, but end up at the same verifier.  The forked requests 
> could have unique request-uri's or Route header lists, 
> identifying unique final targets, but the verifier would 
> consider all but one of them a replay.  Similarly, a 
> legitimate spiral through a verifier would be detected as a 
> replay.  For another, the request could be responded to by 
> the UAS with a 302, which triggers an upstream proxy to 
> recurse the request again through the same verifier but a new 
> final target, which would be detected as a replay.  Lastly, I 
> believe that if UDP transport is used, the verifier can 
> legitimately get retransmissions of requests, using the same 
> cseq, which it would detect as replays but may really need to 
> pass on. (ie, non-Invite requests)
> 
> Then of course there is also a world with B2BUA's.  I think a 
> legitimate argument can be made that a 4474-signed signature 
> *shouldn't* remain valid crossing such Call-ID-changing 
> systems, because otherwise it opens up the door for replay 
> attacks. [note: I am only talking Call-ID's, not other fields]
> 
> But there are ways of providing such replay protection 
> *without* signing the Call-ID field value.  I can suggest two 
> alternatives:
> 
> 1) Create a new header or parameter to be signed and 
> verified, which is unique per new out-of-dialog request the 
> UAC creates - to be added by the UAC or Authenticator before 
> signing.  Ultimately, I believe the Call-ID was signed 
> because it was an already existing header - it was very 
> convenient.  However, if 4474 fails to be usable in many 
> cases were we think it should work, then it's very *inconvenient*.
> 
> 2) Mandate that UAC's _STOP_ using IP Addresses in Call-ID's, 
> with whatever new response code and mechanics we need to make 
> that transition.  If we were to re-create SIP today, I would 
> argue for this to the end.  If we want middle-boxes like 
> SBC's to stop changing things we don't want them to change, 
> stop putting things in which their owners feel compelled to 
> change.  This obviously can't be avoided for some things, but 
> the Call-ID is one of my pet peeves because it didn't have to 
> be one of them.
> 
> Note that Option 2 would only work for SBC's really, not 
> other B2BUA's who change it because they think they need to 
> or really do need to for other reasons.  And it would have a 
> serious problem of needing some installed SBC's to be 
> upgraded, whereas option 1 above would have a greater chance 
> of working today.  So my preference is Option 1.  But doing 
> Option 2 will also solve a lot of other problems in the 
> future, so my real preference is to do BOTH. (Option 1 for 
> 4474, Option 2 for general practice)
> 
> -hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Apr 2008 08:23:08 -0400

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 18 Apr 2008 10:15:24 -0400

> From: Elwell, John [mailto:[email-masked]]

That is a hard question to answer, because I think it depends on where the middle-box is and what its purpose is for rewriting the contact.  In other words, its "role".

For example, for an SBC-type middle-box on the access side (as an outbound proxy between UA's and the core registrar/app-server), I think it should leave the gruu alone.  The gruu should already be hiding device-specific IP addressing info, and thus hiding topology.  We tested that at sipit and it seemed to work fine, but we haven't encountered gruu use in the wild much yet.  If it isn't hiding such, the contact has to be changed unfortunately.

For an SBC-type box on the peering side (between providers or enterprises), there are definitely cases where even a gruu will have to be changed based on policy.  Some SBC's already have a proprietary way to provide a "global contact", which encrypts the original - they had to do this because the need for a contact to be reusable in the style of gruu has already happened, long before anyone was doing gruu.  The lifetime is left up to operator policy.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 18 Apr 2008 16:41:35 -0400

> 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 3 of this series: Signing the MIME body.

This is probably the big one in terms of being contentious.  For some MIME bodies, signing it presents no issue for current B2BUA's, as far as I know - notably a MESSAGE request body for UI rendering.  A MESSAGE has no Contact, so just avoiding Call-ID signing as described in part-1 of this thread should be good enough.

As we all know, RFC 4474 signs the MIME body of the request.  It does this because:
   There is little purpose in establishing the identity of the user that
   originated a SIP request if this assurance is not coupled with a
   comparable assurance over the media descriptors.
While I don't disagree that assuring the media *identity* is highly valuable, I don't believe 4474 gives that assurance per se by signing just descriptors, and I happen to think there *is* value in establishing the identity of a user that originated a SIP request regardless anyway.

The main issue is of course application/sdp.  For direct-connection models, where the authenticating domain is sending the request directly to the verifying domain, there's no issue.  I personally don't see the need for rfc4474 much in those cases anyway, because mutual-TLS can be used at the transport layer, which would provide a lot more significant security benefits than just 4474 does - plus it would generally scale better.  But anyway, there's no issue in those cases.

The sticky part is when the request goes through intermediate domains, such as transit providers.  There are plenty of B2BUA's which modify it, for a whole bunch of reasons.  Most of them are for reasons specific to an originating or terminating domain, where rfc4474 would not really be an issue.  One notable exception I can think of is when transcoding is performed by media-servers inside intermediate domains.  But the biggest one is undoubtedly SBC-type systems at the borders of those intermediate domains.

One argument proposed by some is that these intermediate domains would just verify the signature, change SDP, and re-sign.  While that may be technically possible for E.164 number URI's, it would present a significant start-up problem of needing everyone to do it; and obviously doesn't work for non-E.164 URI's.

Another argument is that domains using intermediates for request routing essentially rely on and expect a chain-of-trust domain model, and may not even care about a 4474 signature if the signing domain is not their local link to that chain.  While I don't disagree that is the current situation, at some future time as more and more peering interconnect happens, this chain will become brittle.  The question is what types of threats it will face...

Clearly there is an argument to be made that such intermediate domains are indistinguishable from a MitM.  Much of the IETF community is concerned with MitM attacks, but I don't think providers or even average users are too concerned about that - or rather, if something can become a MitM between or among the providers, it's a much bigger deal than just your media frankly.  They expect and need to be able to ferret that out regardless of 4474.

What they're more concerned with, imho, is insecure ends of that trust chain creating spam or fraud.  In other words, that some enterprise or provider at the end is less secure about who it lets create requests to begin with.  You can think of this in the context of email I think.  I don't live in that world, but my guess is that more people are concerned with spammers generating email through open relays or bots, than they are about an active MitM intercepting emails for the purpose of modifying their contents en route.

The reason I think it's important to understand that fear factor difference, is that 4474 attempts to provide protection for both things at the same time: request originator user identity, and MitM modification/replay protection.  That is in fact why I wrote the baiting attack draft, to both point out that one does not even need to be a real MitM to act like one, and that even *with* rfc4474 it's not stopped.  It will take something different to stop it.

Furthermore, it should be quite clear that signing SDP isn't enough - IP addresses for media are obviously spoof-able.  And if it's a MitM you're worried about and it can see the SDP, there's a fairly good chance it can successfully spoof and intercept that media addressing too.  Afaik, only SRTP using signed fingerprints or IBE/IBS can truly prevent that, which is why Kai and Dan's drafts only need to sign the fingerprints instead of the whole SDP.  To put this another way - most of us would laugh at the idea of putting SRTP security-descriptions keys in the SDP and signing that with RFC 4474, because it is weak and would lead to a false sense of security; but that's the same as RFC 4474 signing of normal SDP is today.

So... I propose that once again the originator of the request be given an option: it can sign the MIME body, or not, based on its preference.  This can be done in another parameter or param value of the Identity-Info header, similar to the Contact one proposed in part-2 of this thread; and again this parameter does not need to be signed itself because forging it or removing it implicitly breaks the signature calc anyway.  The authenticator can likewise decide if it wants to accept a request with this parameter or not.

The semantics of this are such that the authenticator is saying "me.com verified user [email-masked] generated this request with these To, From, and Date, but not necessarily the SDP."  This would be useful for spam avoidance, but not much more. (just as 4474 arguably is)
If a srtp fingerprint is also signed, then it means a lot more.

Alternatively, we could just recommend that such an originator simply send offerless-Invite's, since that is perfectly legal in 4474 and avoids this issue.  But somehow I don't think that would be such a good idea. ;)

-hadriel

---

From: "Fischer, Kai" <[email-masked]>
Date: Mon, 21 Apr 2008 12:59:42 +0200

> Sent: Freitag, 18. April 2008 22:42
> Subject: [Sip] What 4474 signs part-3 [was: Proposal to 
> Revise RFC 4474]
> 
> ...
> 
> So... I propose that once again the originator of the request 
> be given an option: it can sign the MIME body, or not, based 
> on its preference.  This can be done in another parameter or 
> param value of the Identity-Info header, similar to the 
> Contact one proposed in part-2 of this thread; and again this 
> parameter does not need to be signed itself because forging 
> it or removing it implicitly breaks the signature calc 
> anyway.  The authenticator can likewise decide if it wants to 
> accept a request with this parameter or not.

I think the flexibility of elements covered by a (RFC4474bis) signature
is an interesting idea. RFC 4474 shall be applied for different
scenarios and therefore the set of elements which needs to be signed
vary. For the protection of the DTLS-SRTP fingerprint only a few
elements need to be signed. However, the flexibility causes also some
interoperability issues like B expected header field x to be signed
whereas A doesn't sign it. The risk exists that both parties fall back
to the least common denominator (all mandatory elements), which is not
applicable resp. secure for all intended scenarios. So it could be
useful to define some RFC4474 signature profiles. These profiles are
also extendable for future use cases without a need to revise RFC4474bis
again.

Kai

> 
> The semantics of this are such that the authenticator is 
> saying "me.com verified user [email-masked] generated this 
> request with these To, From, and Date, but not necessarily 
> the SDP."  This would be useful for spam avoidance, but not 
> much more. (just as 4474 arguably is)
> Alternatively, we could just recommend that such an 
> originator simply send offerless-Invite's, since that is 
> perfectly legal in 4474 and avoids this issue.  But somehow I 
> don't think that would be such a good idea. ;)
> 
> -hadriel