RE: [Sip] RE: Identity after reinvite
"Peterson, Jon" <jon.peterson@neustar.biz> Tue, 16 November 2004 22:39 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 RAA03732 for <sip-web-archive@ietf.org>; Tue, 16 Nov 2004 17:39:12 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUC12-0005a3-6U for sip-web-archive@ietf.org; Tue, 16 Nov 2004 17:41:36 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUBky-0005NN-3h; Tue, 16 Nov 2004 17:25:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUBA7-0003Jl-C8 for sip@megatron.ietf.org; Tue, 16 Nov 2004 16:46:58 -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 QAA20766 for <sip@ietf.org>; Tue, 16 Nov 2004 16:46:53 -0500 (EST)
Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUBCO-0001Xp-KC for sip@ietf.org; Tue, 16 Nov 2004 16:49:17 -0500
Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id iAGLkN10031069; Tue, 16 Nov 2004 21:46:23 GMT
Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id <T32L82YV>; Tue, 16 Nov 2004 16:46:23 -0500
Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF4377@stntexch04.cis.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: 'Paul Kyzivat' <pkyzivat@cisco.com>, Jonathan Rosenberg <jdrosen@cisco.com>
Subject: RE: [Sip] RE: Identity after reinvite
Date: Tue, 16 Nov 2004 16:46:19 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985
Cc: Cullen Jennings <fluffy@cisco.com>, sip@ietf.org
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: 0770535483960d190d4a0d020e7060bd
> > 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. > > Very good point! This is a more significant problem with mid-dialog requests and the request identity system, agreed. > > The identity service will then reject these requests. > > Hmm. Will the request be rejected, or will it just not get a > authentication that it is valid? I suppose that is local policy. It may > be necessary to permit this, without authentication, just to avoid > breaking these common scenarios. Yes, this is the crux of the matter. The text in Section 6 of sip-identity-03 says the following: If the identity field contains a SIP or SIPS URI, the authentication service MUST extract the hostname portion of the identity field and compare it to the domain(s) for which it is responsible... If the authentication service is not responsible for the identity in question, it MAY handle the request normally, but it MUST NOT add an Identity header; see below for more information on authentication service handling of an existing Identity header. 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. > > 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. > > Yes, this would be a good solution, if we can sort out the compatibility > issues getting to it. I am extremely wary of predicating request identity on solving the connected-party problem, in part because I believe doing so will dictate a direction for the response identity problem. If we go down this path here (changing the From header field value), we will be forced to do the same for response identity. I think this is the wrong approach, as sip-identity-02 suggested; I think we are sacrificing certain valuable security properties for the long term if we go down this path. 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. - 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. - 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. > > 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. > > If we were going to switch to this, then it could begin with the first > response to the invite. That would be the first step to really solving > the connected-partiy-id problem. Not just 'could begin' but 'should begin'. If the identity you see in the response to the INVITE does not equal the identity you see in requests in the backwards direction, I believe that is extremely problematic. Yes, this is what I mean by solving the response identity problem. > > 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. > > Well, if there are multiple hops that isn't proof against every possible > attack. But it certainly makes it harder. And the kinds of attacks that > would work here could probably just as well compromise the > authentication server itself. > 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. > > 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. > > As I mention above, if the To were changed in responses, then the caller > would know right away, without the extra request. But it wouldn't be > signed. However then the way forward would be clear - have a callee > suthentiation server sign the To header of responses. > Yet more justification for the idea that this solution must share its core with our longer-term response identity mechanism. > >> 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. SIPS would be sufficient if it were not crippled by restrictions about the final administrative domain, and the ambiguity about finality in the context of retargeting. Jon Peterson NeuStar, Inc. _______________________________________________ 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