Subject: Re: [Sip] SIP Dialog Match

From: aayush bhatnagar <[email-masked]>
Date: Sat, 1 Aug 2009 19:17:31 +0530

It is possible..and is standardized. 'C' can 'logically' Join an existing
dialog between 'A' (UAC) and 'B' (UAS), by including a Join header in the
INVITE request.
It may be a security concern to allow C to Join the existing dialog, but it
can be a way to implement a call screening server (call tapping) for lawful
interception services.

For more details look here: http://www.rfc-editor.org/rfc/rfc3911.txt
<http://www.rfc-editor.org/rfc/rfc3911.txt>

On Thu, Jul 30, 2009 at 09:28, Karunesh Sharma <
[email-masked]> wrote:

>  List:
>
>
>
> I am having a question about SIP dialog validation using src/dst ip. If
> there is established sip dialog between ‘A’ & ‘B’ then can ‘C’ who is not
> party to existing dialog and who somehow knows all sip dialog identifiers
> (Call-ID, To/From Tags) of the dialog between ‘A’ & ‘B’, sends target
> refresh request with its own IP in contact. This is a typical call hijacking
> case. If this is valid how to avoid that? Is Authentication is only way out
> or do we have other alternate as well?
>
>
>
> I didn’t find anything on this in 3261 or other related RFCs.
>
>
>
> Thanks
>
>
>
> K$
>
> _______________________
>
>
>
> _______________________________________________
> 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
>

-- 
aayush
----------------------------------------------------
"A philosopher always knows what to do...until it happens to him"

---

From: "Dale Worley" <[email-masked]>
Date: Sun, 02 Aug 2009 17:41:17 -0400

> On Thu, Jul 30, 2009 at 09:28, Karunesh Sharma
> <[email-masked]> wrote:

>         I am having a question about SIP dialog validation using
>         src/dst ip. If there is established sip dialog between ‘A’ &
>         ‘B’ then can ‘C’ who is not party to existing dialog and who
>         somehow knows all sip dialog identifiers (Call-ID, To/From
>         Tags) of the dialog between ‘A’ & ‘B’, sends target refresh
>         request with its own IP in contact. This is a typical call
>         hijacking case. If this is valid how to avoid that? Is
>         Authentication is only way out or do we have other alternate
>         as well?

For "basic" security, it is usually assumed that if an agent knows the
dialog identifiers, then it has the right to manipulate the dialog.
(See, e.g., the Replace and Join headers.)  For stricter security,
additional authentication mechanisms have to be deployed, but the IETF
has not standardized any such mechanism.

Dale

---

From: "Karunesh Sharma" <[email-masked]>
Date: Mon, 3 Aug 2009 20:49:24 +0530

What about sending INVITE to 'B' & getting all responses (which includes provisional response 1xx) from 'C'?

K$
_______________________

-----Original Message-----
From: Dale Worley [mailto:[email-masked]] 
Sent: Monday, August 03, 2009 3:11 AM
To: aayush bhatnagar
Cc: Karunesh Sharma; [email-masked]
Subject: Re: [Sip] SIP Dialog Match

Dale

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 03 Aug 2009 11:24:48 -0400

On Mon, 2009-08-03 at 20:49 +0530, Karunesh Sharma wrote:
> What about sending INVITE to 'B' & getting all responses (which
> includes provisional response 1xx) from 'C'?

I'm not sure what you mean.

Dale

---

From: "Karunesh Sharma" <[email-masked]>
Date: Mon, 3 Aug 2009 21:03:36 +0530

Dale:

Please see following trace

172.16.31.30 -> 10.0.4.6     SIP/SDP Request: INVITE
sip:[email-masked], with session description
192.168.4.67 -> 172.16.31.30 SIP Status: 100 Trying
192.168.4.67 -> 172.16.31.30 SIP/SDP Status: 183 Session Progress, with
session description
172.16.31.30 -> 192.168.4.67 SIP Request: PRACK
sip:[email-masked]:5060
192.168.4.67 -> 172.16.31.30 SIP Status: 200 OK
192.168.4.67 -> 172.16.31.30 SIP/SDP Status: 200 OK, with session
description
172.16.31.30 -> 192.168.4.67 SIP Request: ACK
sip:[email-masked]:5060
192.168.4.67 -> 172.16.31.30 SIP Request: BYE
sip:[email-masked]:5060

172.16.31.30 (read as 'A') sent INVITE to 10.0.4.6 (read as 'B'). But
somehow 192.168.4.67 (read as 'C') responds. Now 'A' knows nothing about
'C', but still based on SIP dialog identifiers 'A' accepts that.

So is there any way to challenge or deny such rouge responses?

I was reading one draft
(http://ietfreport.isoc.org/idref/draft-cao-sip-response-identity/) but
that is expired.

K$
_______________________

-----Original Message-----
From: Dale Worley [mailto:[email-masked]] 
Sent: Monday, August 03, 2009 8:55 PM
To: Karunesh Sharma
Cc: aayush bhatnagar; [email-masked]
Subject: RE: [Sip] SIP Dialog Match

Dale

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 03 Aug 2009 11:46:38 -0400

> So is there any way to challenge or deny such rouge responses?

Have you inquired as to how C knows of the dialog identifiers, and why
it is sending the responses?

Dale

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 03 Aug 2009 12:02:37 -0400

On Mon, 2009-08-03 at 21:21 +0530, Karunesh Sharma wrote:
> I am trying to get that info how 'C' has this dialog identifiers but I
> was wondering this as a major security issue for any SIP network.

If C can obtain the dialog identifiers but it is not supposed to be
participating in the dialog, then that is a major security issue.

Dale

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 03 Aug 2009 12:04:49 -0400

On Mon, 2009-08-03 at 21:28 +0530, Karunesh Sharma wrote:
> Is this a valid behavior for scenario like 'Call-Forwarding'?

In principle, the responses to a request should almost always come from
the address to which the request was sent.  But that is not usually
enforced, and there may be good reasons why it isn't happening in a
particular instance.

In regard to an observed instance of this behavior, you must first
determine the complete routing of the request in question and the reason
for each routing step.

Dale

---

From: "Karunesh Sharma" <[email-masked]>
Date: Mon, 3 Aug 2009 21:28:43 +0530

K$
_______________________

-----Original Message-----
From: Karunesh Sharma 
Sent: Monday, August 03, 2009 9:22 PM
To: 'Dale Worley'
Cc: aayush bhatnagar; [email-masked]
Subject: RE: [Sip] SIP Dialog Match

K$
_______________________

-----Original Message-----
From: Dale Worley [mailto:[email-masked]] 
Sent: Monday, August 03, 2009 9:17 PM
To: Karunesh Sharma
Cc: aayush bhatnagar; [email-masked]
Subject: RE: [Sip] SIP Dialog Match

Dale

---

From: "Karunesh Sharma" <[email-masked]>
Date: Mon, 3 Aug 2009 21:21:43 +0530

K$
_______________________

-----Original Message-----
From: Dale Worley [mailto:[email-masked]] 
Sent: Monday, August 03, 2009 9:17 PM
To: Karunesh Sharma
Cc: aayush bhatnagar; [email-masked]
Subject: RE: [Sip] SIP Dialog Match

Dale

---

From: "T Satyanarayana-A12694" <[email-masked]>
Date: Tue, 4 Aug 2009 00:31:37 +0800

In short, if some one wants to fake another client, it is possible since
the communication is in clear. If there are security concerns, then
security mechanisms (privacy etc) should be used.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dale Worley
Sent: Monday, August 03, 2009 9:35 PM
To: Karunesh Sharma
Cc: [email-masked]
Subject: Re: [Sip] SIP Dialog Match

Dale

_______________________________________________
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: "Karunesh Sharma" <[email-masked]>
Date: Mon, 3 Aug 2009 22:05:00 +0530

Are you talking about *privacy* headers? I fail to understand here how
*privacy* header will help in such cases.

K$
_______________________

-----Original Message-----

Dale

---

From: "T Satyanarayana-A12694" <[email-masked]>
Date: Tue, 4 Aug 2009 00:36:48 +0800

No, privacy using encryption.

-----Original Message-----
From: Karunesh Sharma [mailto:[email-masked]] 
Sent: Monday, August 03, 2009 10:05 PM
To: T Satyanarayana-A12694; Dale Worley
Cc: [email-masked]
Subject: RE: [Sip] SIP Dialog Match

K$
_______________________

-----Original Message-----

Dale

---

From: "T Satyanarayana-A12694" <[email-masked]>
Date: Tue, 4 Aug 2009 00:49:24 +0800

No, this isn't how it usually works. For call forwarding, there is
usually a proxy (or a softswitch) which does it on behalf of B.

However, if B chooses to do it himself: C (forwardee) gets it like a
regular call from B (forwarding agent) and C doesn't reply to A - it
replies to B. B then can shuffle the calls so that the call is directly
between A and C (through a set of target refreshes). However, this is
just hypothetical and not usually done in reality.

Regards
Satya T

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Karunesh Sharma
Sent: Monday, August 03, 2009 9:29 PM
To: Dale Worley
Cc: [email-masked]
Subject: Re: [Sip] SIP Dialog Match

K$
_______________________

-----Original Message-----
From: Karunesh Sharma
Sent: Monday, August 03, 2009 9:22 PM
To: 'Dale Worley'
Cc: aayush bhatnagar; [email-masked]
Subject: RE: [Sip] SIP Dialog Match

K$
_______________________

-----Original Message-----
From: Dale Worley [mailto:[email-masked]]
Sent: Monday, August 03, 2009 9:17 PM
To: Karunesh Sharma
Cc: aayush bhatnagar; [email-masked]
Subject: RE: [Sip] SIP Dialog Match

Dale

---

From: "Karunesh Sharma" <[email-masked]>
Date: Fri, 7 Aug 2009 18:37:11 +0530

Dale:

It's simple scenario where 'A' sent INVITE to 'B'. 'C' is man in middle
captured the INVITE and sent the response back to 'A'. I wonder why no
one ever had such case ever and why there is no established guidelines.

K$
_______________________

-----Original Message-----
From: Dale Worley [mailto:[email-masked]] 
Sent: Monday, August 03, 2009 9:35 PM
To: Karunesh Sharma
Cc: aayush bhatnagar; [email-masked]
Subject: RE: [Sip] SIP Dialog Match

Dale

---

From: "T Satyanarayana-A12694" <[email-masked]>
Date: Fri, 7 Aug 2009 21:28:42 +0800

Well, strictly speaking, this is possible and most SIP networks are
vulnerable to this. This is no different from HTTP or SMTP where this is
possible.

The guidelines (there could be others as well) to overcome this are:

1. Implement a known-good-source kind of logic where you accept
responses coming only from a well known proxy. Ofcourse, this works only
when there is a proxy and when the source IP address of the response
itself is not modified.

2. Implement encryption (e.g. TLS) for signaling

Regards
Satya T

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Karunesh Sharma
Sent: Friday, August 07, 2009 6:37 PM
To: Dale Worley
Cc: [email-masked]
Subject: Re: [Sip] SIP Dialog Match

Dale:

K$
_______________________

-----Original Message-----
From: Dale Worley [mailto:[email-masked]]
Sent: Monday, August 03, 2009 9:35 PM
To: Karunesh Sharma
Cc: aayush bhatnagar; [email-masked]
Subject: RE: [Sip] SIP Dialog Match

Dale