Re: [Sip] RE: Identity after reinvite

Jonathan Rosenberg <jdrosen@cisco.com> Tue, 16 November 2004 08:11 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02384 for <sip-web-archive@ietf.org>; Tue, 16 Nov 2004 03:11:11 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTySs-00073B-Hw for sip-web-archive@ietf.org; Tue, 16 Nov 2004 03:13:26 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTyMv-0008Ae-Jy; Tue, 16 Nov 2004 03:07:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTyLu-0007yM-Iq for sip@megatron.ietf.org; Tue, 16 Nov 2004 03:06:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01660 for <sip@ietf.org>; Tue, 16 Nov 2004 03:06:12 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTyO2-0006ti-KG for sip@ietf.org; Tue, 16 Nov 2004 03:08:28 -0500
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 16 Nov 2004 00:18:36 -0800
Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAG85S3O009948; Tue, 16 Nov 2004 00:05:28 -0800 (PST)
Received: from [192.168.1.100] (sjc-vpn4-1387.cisco.com [10.21.85.106]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFT54216; Tue, 16 Nov 2004 00:05:36 -0800 (PST)
Message-ID: <4199B4D0.30606@cisco.com>
Date: Tue, 16 Nov 2004 03:05:36 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Peterson, Jon" <jon.peterson@neustar.biz>
Subject: Re: [Sip] RE: Identity after reinvite
References: <7927C67249E4AD43BC05B539AF0D129801AF4372@stntexch04.cis.neustar.com>
In-Reply-To: <7927C67249E4AD43BC05B539AF0D129801AF4372@stntexch04.cis.neustar.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Content-Transfer-Encoding: 7bit
Cc: Cullen Jennings <fluffy@cisco.com>, sip@ietf.org, "'Paul Kyzivat'" <pkyzivat@cisco.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a8a20a483a84f747e56475e290ee868e
Content-Transfer-Encoding: 7bit


Peterson, Jon wrote:

> Well, yes, now one begins to appreciate why we originally coupled the
> request identity problem with the response identity problem. :)
> 
> In the next revision of the identity draft, which will incorporate the list
> comments up to date, I do intend to include some text about dialogs. I agree
> that the draft should apply to requests regardless of the dialog context.

I do believe there are issues related to mid-dialog requests, but I'm 
not sure I agree that Paul's characterization is the problem.

The problem is that, due to retargeting, the URI in the To field of the 
INVITE may not identify the user that was eventually reached. In RFC 
3261, requests from the called party to the caller carry the value from 
the original To field in the From. As a result, the requests will have a 
 From field value which does not actually correspond to the originator 
of the reuqest. The identity service will then reject these requests.

The solution, which rfc3261 warns of, is that a UA has to put its actual 
identity in the From field URI, not what it saw in the To field of the 
original request. This will break all compatibility with rfc2543, but 
will work with other rfc3261 compliant endpoints, since the URI is no 
longer used for dialog identification.


> 
> Moreover, I don't think the problem you raise below is limited merely to
> re-INVITEs within a dialog. I believe it applies equally to BYE requests
> sent in the backwards direction in a dialog. Ideally, the originator of the
> dialog should have some assurance that requests sent in the backwards
> direction come from the same identity that positively responded to the
> dialog (i.e., the sender of the 200 and any provisional responses).

Useful, yes, but a different problem. I like the current scope of the 
identity draft - to provide the identity of the sender of a request. 
That is not a panacea for all of our security problems, of course.

> 
> In the absence of response identity, though, it is difficult for Alice to
> have any such assurance. Equally, as you point out below, Bob can have no
> assurance that his BYE or re-INVITE has been fielded by Alice if he is
> unable to get a cryptographically-assured 200 response to his own requests.
> Alice can't even be certain that she actually connected to Bob, thanks to
> retargeting; this is the essence of the connected-ID/response identity
> problem, and threatens to drag us back into the morass of retargeting
> restrictions and so on that populated the sip-identity-02 draft.
> 
> A lack of such a strong binding of backwards-direction BYE requests to the
> dialog is a significant limitation; if BYE can be spoofed, then an attacker
> can terminate existing dialogs.

Doesn't sips prevent that? With sips, you won't be able to identify the 
called party from the 200 OK, but it will guarantee that no one except 
the party you reach can terminate the call.

Indeed, it occurs to me that one can "simulate" response identity by 
having the called party send an UPDATE or nearly any other request in 
the reverse direction immediately upon receipt of the ACK. If you 
structure the From field of that request as I have proposed above, the 
net result provides a form of response identity - it tells you who was 
reached. This doesnt tell you *why* it was reached (as redirection 
would), but it seems valuable nonetheless.


  However, I'm not sure that the situation is
> so dire as you suggest below. Without identity, it is trivial for any
> attacker to impersonate a dialog-forming request. It is harder, though, for
> an attacker to impersonate a response or mid-dialog request; this requires
> the attacker to gather dialog state through eavesdropping or some similar
> means. There is a very important distinction in sophistication between an
> attacker who can merely formulate a plausible dialog-forming request with an
> inappropriate From header field versus an attacker who can capture
> dialog-forming requests and improvise appropriate responses (with correct
> tags, correct Call-ID/CSeq, etc).

sips, of course, prevents this fully.

> 
> Ultimately, request identity can protect against the former but not the
> latter.

But, its not supposed to. Its not supposed to provide all of the 
security functions for sip - just the function which identifies the 
originator of a request.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip