Re: [Sip] RE: Identity after reinvite
Jonathan Rosenberg <jdrosen@cisco.com> Wed, 17 November 2004 16:17 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 LAA14464 for <sip-web-archive@ietf.org>; Wed, 17 Nov 2004 11:17:43 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUSXZ-0004s1-F4 for sip-web-archive@ietf.org; Wed, 17 Nov 2004 11:20:17 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUSTO-0005T6-Og; Wed, 17 Nov 2004 11:15:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUSLq-0003t6-7t for sip@megatron.ietf.org; Wed, 17 Nov 2004 11:08:10 -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 LAA12788 for <sip@ietf.org>; Wed, 17 Nov 2004 11:08:07 -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 1CUSOH-0004Yn-Gv for sip@ietf.org; Wed, 17 Nov 2004 11:10:41 -0500
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 17 Nov 2004 08:21:20 -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 iAHG823O021528; Wed, 17 Nov 2004 08:08:02 -0800 (PST)
Received: from [161.44.55.231] (dhcp-161-44-55-231.cisco.com [161.44.55.231]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFU42519; Wed, 17 Nov 2004 08:08:03 -0800 (PST)
Message-ID: <419B7763.30309@cisco.com>
Date: Wed, 17 Nov 2004 11:08:03 -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: Paul Kyzivat <pkyzivat@cisco.com>
Subject: Re: [Sip] RE: Identity after reinvite
References: <7927C67249E4AD43BC05B539AF0D129801AF4377@stntexch04.cis.neustar.com> <419A87CB.3030505@cisco.com>
In-Reply-To: <419A87CB.3030505@cisco.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d
Content-Transfer-Encoding: 7bit
Cc: Cullen Jennings <fluffy@cisco.com>, sip@ietf.org, "Peterson, Jon" <jon.peterson@neustar.biz>
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: d2b46e3b2dfbff2088e0b72a54104985
Content-Transfer-Encoding: 7bit
inline. Paul Kyzivat wrote: >> So it isn't that the auth service will reject the request; it MAY just >> forward the request normally. What will happen in that instance? Well, if >> the auth service role is instantiated by a proxy server, it will >> forward the >> request in accordance with the URI without adding an Identity header; it >> won't challenge the request, or what have you. > > > Good. You confirm what I was assuming. The MAY isn't good enough here. You want to be certain it WONT reject the request just because the From is wrong. > > I agree the basic request identity problem is separable from the others. > But it does seem that connected-party, response-identity, and reverse > direction requests in dialog are all entangled, and that changing > to/from may be a single solution good for all of them. I see a clear line between the various problems, but perhaps its just because I've not thought about it enough ;) One problem, which I am calling the "request identity problem", is how to identify the sender of a request. That problem exists for initial requests and mid-dialog requests alike. indeed, because the identity exists on a request by request basis, the fact that a request is part of a dialog has no bearing. If you buy this argument, it would strongly argue in favor of the approach I suggested - modifying the From for reverse requests in a dialog so that the From properly identifies the sender. A separate problem is how a UAC can securely determine the sequence of events that led to a request being retargeted. This is the much harder problem that I think is out of scope right now. Another problem is how to identify the sender of a response, and it is the exact inverse of the request identity problem. > >> I have a number of arguments about this, but here are just three: >> >> - Identity will succeed in the marketplace if it can be used >> opportunistically. Requiring UAs to change the From header field in this >> fashion forces them to become identity-aware, which is an impediment to >> adoption. Basically, we force UAs to be either backwards-compliant with >> RFC2543 or compliant with Identity. Tough choice, especially given >> that the >> UA might not be aware of its need to be either of those things. > > > Agree. This is a fair point. There is a middle ground though. If a UA doesn't set the From properly, the identity service simply doesn't sign the request. Thus, it is always OK for a client to do nothing to support identity. The consequence is that, in the case of retargeting, their identity won't be delivered to the caller for a mid-dialog request. I think that this is reasonable. However, if a UA wants, it can set the From properly, and then these requests can be signed. > >> - I also question whether or not the callee UA will even know which >> identity >> it needs to stick in the From header of requests in the backwards >> direction: >> after all, if the UA is registered under multiple AoRs, what exactly >> about >> the dialog-forming request will tell it definitively which identity it is >> supposed to use? While in some cases, this could be inferred from the >> Request-URI of the dialog-forming requests, it won't be sufficient in all >> cases, I think. The previous hop (last proxy server to handle the >> request) >> might also be a hint. Now, it could be that there's a good answer to this >> question, but if so, we need to know that answer. > > > There are many reasons why a UA with multiple registrations needs to > know which one was the source of an incoming call. And the UA can easily > achieve this by using distinct contacts in the registrations. I don't > think we need to lose sleep over those that choose not to do so. I don't see the problem. It should be able to use any identity it might otherwise assert in a request outside of the dialog. If the route set doesn't include the identity service for that domain, then there won't be any asserted identity. What this means is that servers that provide the identity service probably should record-route. > >> - Retargeting is inherently insecure, and no amount of wiggling with the >> sip-identity mechanism will repair this. If Alice sent a request to >> Bob, and >> a new request in the backwards direction comes from Edgar, I think >> there is >> -no- circumstance in which Alice should not view this as a potential >> security risk, regardless of the presence or absence of an Identity >> header, >> SIPS, or what have you. Trying to explain this aware flies in the face of >> common sense, and will be incomprehensible to actual users who will >> need to >> make security decisions based on the evidence collected from the >> protocol by >> their user agent. > > > Of course it is a potential security risk, which is why it is good to > report that it happened. (A good UA will hopefully note that the > connected party is not the called party and make a big fuss at its UI.) > But it is still good to know who in fact you ended up talking to. I agree. Indeed, with SIP today you not only don't know its been retargeted, nothing evne identifies who its been retargeted to. This seems even more of a risk. >> Don't forget, for example, that SIPS does not apply after the domain >> indicated by the Request-URI of the request, and so on. SIPS is not a >> powerful mechanism. Until we all acknowledge that we were mistaken in our >> formulation in RFC3261, and that SIPS, when present, signifies >> unambiguously >> that TLS should be used end-to-end, I do not think SIPS can be said to >> solve >> any of our problems. Once we have the connect-reuse mechanism nailed down >> firmly, I think it will be possible to shift to that understanding of >> SIPS, >> if we want to. SIPS is clear that there MUST be a secure channel at each hop - it just doesn't mandate TLS. In hindsight I agree it should have ideally done that, it does imply a security property which does, IMHO, prevent outsiders from launching the attack you describe. -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
- [Sip] Identity after reinvite Paul Kyzivat
- [Sip] RE: Identity after reinvite Peterson, Jon
- Re: [Sip] RE: Identity after reinvite Jonathan Rosenberg
- [Sip] Re: Identity after reinvite Paul Kyzivat
- Re: [Sip] RE: Identity after reinvite Paul Kyzivat
- Re: [Sip] RE: Identity after reinvite Cullen Jennings
- Re: [Sip] RE: Identity after reinvite Paul Kyzivat
- Re: [Sip] RE: Identity after reinvite David R Oran
- Re: [Sip] RE: Identity after reinvite Jonathan Rosenberg
- Re: [Sip] RE: Identity after reinvite Paul Kyzivat
- RE: [Sip] RE: Identity after reinvite Peterson, Jon
- Re: [Sip] RE: Identity after reinvite Paul Kyzivat
- RE: [Sip] RE: Identity after reinvite Peterson, Jon
- Re: [Sip] RE: Identity after reinvite Jonathan Rosenberg
- Re: [Sip] RE: Identity after reinvite Jonathan Rosenberg
- Re: [Sip] RE: Identity after reinvite Dean Willis