[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Another possible limitation of DERIVE
At the end of the day it's just a form of return-routability test, subject to the same middle-box trust issues we already know and love. Not that there's anything wrong with that, just that I don't think they're claiming it does anything more than that.
With regards to your specific scenario, you said with 4474 if sp.net did NOT interfere with the From-uri then you can verify where the call really came from. (example.com) But if sp.net did not interfere with the From-uri, then Derive will also route to example.com.
4474 does not and cannot prevent sp.net from changing the From-uri to sp.net - it can only prevent sp.net from changing it to example.com, or foobar.com. If sp.net changed it to foobar.com, Derive could catch that in some cases, but obviously if the Derive message just happened to go through sp.net then sp.net can successfully lie and make the Derive check succeed. Whereas 4474 would catch the lie no matter what.
BTW, I think it still is subject to the Baiting attack. I make a Bank call me, and I then re-use its call-id+tag in an INVITE I send to you. Since it's the same call-id and tag, Bank will say "yes I'm making that call".
But I assume the purpose for Derive is not to try to prevent all kinds of middle-man/middle-box attacks, but rather prevent spray-spamming and some basic identity fraud scenarios in a better-than-nothing approach. No?
-hadrielFrom sip-bounces at ietf.org Wed Nov 19 12:45:57 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 8A5D23A694C;
Wed, 19 Nov 2008 12:45:57 -0800 (PST)
X-Original-To: sip at core3.amsl.com
Delivered-To: sip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id D9EE53A694C
for <sip at core3.amsl.com>; Wed, 19 Nov 2008 12:45:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.019
X-Spam-Level:
X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=0.580,
BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Nw3RAnqzP43Z for <sip at core3.amsl.com>;
Wed, 19 Nov 2008 12:45:56 -0800 (PST)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6])
by core3.amsl.com (Postfix) with ESMTP id CA8903A683E
for <sip at ietf.org>; Wed, 19 Nov 2008 12:45:55 -0800 (PST)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1;
Wed, 19 Nov 2008 15:44:28 -0500
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with
mapi; Wed, 19 Nov 2008 15:44:28 -0500
From: Hadriel Kaplan <HKaplan at acmepacket.com>
To: "Elwell, John" <john.elwell at siemens.com>, IETF SIP List <sip at ietf.org>
Date: Wed, 19 Nov 2008 15:39:54 -0500
Thread-Topic: Another possible limitation of DERIVE
Thread-Index: AclKYe9KsFiKYcthQeix/Vi2RV+1xAAHkSdw
Message-ID: <E6C2E8958BA59A4FB960963D475F7AC313720E5EAF at mail>
References: <0D5F89FAC29E2C41B98A6A762007F5D001483038 at GBNTHT12009MSX.gb002.siemens.net>
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001483038 at GBNTHT12009MSX.gb002.siemens.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Sip] Another possible limitation of DERIVE
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
At the end of the day it's just a form of return-routability test, subject to the same middle-box trust issues we already know and love. Not that there's anything wrong with that, just that I don't think they're claiming it does anything more than that.
With regards to your specific scenario, you said with 4474 if sp.net did NOT interfere with the From-uri then you can verify where the call really came from. (example.com) But if sp.net did not interfere with the From-uri, then Derive will also route to example.com.
4474 does not and cannot prevent sp.net from changing the From-uri to sp.net - it can only prevent sp.net from changing it to example.com, or foobar.com. If sp.net changed it to foobar.com, Derive could catch that in some cases, but obviously if the Derive message just happened to go through sp.net then sp.net can successfully lie and make the Derive check succeed. Whereas 4474 would catch the lie no matter what.
BTW, I think it still is subject to the Baiting attack. I make a Bank call me, and I then re-use its call-id+tag in an INVITE I send to you. Since it's the same call-id and tag, Bank will say "yes I'm making that call".
But I assume the purpose for Derive is not to try to prevent all kinds of middle-man/middle-box attacks, but rather prevent spray-spamming and some basic identity fraud scenarios in a better-than-nothing approach. No?
-hadriel
> ----
> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of
> Elwell, John
> Sent: Wednesday, November 19, 2008 11:15 AM
> To: IETF SIP List
> Subject: [Sip] Another possible limitation of DERIVE
>
> Suppose, for the sake of argument, we go with Hadriel's draft and
> OPTIONS, e.g., global call ID in INVITE request, sent back in OPTIONS
> request with global call ID to URI obtained from receive From.
>
> Now suppose the initial From URI is sip:+123456 at example.com;user=phone
> and this gets modified by callee's service provider to
> sip:+123456 at sp.net;user=phone. Callee UA sends OPTIONS request to the
> latter URI. B2BUA in sp.net acts as UAS for the OPTIONS request and
> returns 200 OK, on basis that it recognises the global call ID. What
> does this give me? Basically that the call arrived via my service
> provider, which I know anyway if it arrives over a TLS connection for
> which I have authenticated the service provider. The problem is, I don't
> know that sp.net has terminated the OPTIONS request. Even if the service
> provider has not acted in this way and the OPTIONS request has gone all
> the way back to the caller UA (or at least to its domain proxy/B2BUA), I
> have no evidence that this is so.
>
> Now contrast this with RFC 4474. With RFC 4474, sp.net can change the
> URI as above and re-sign (insert a new Identity header field). At least
> my UA can see that the only guarantee I have is that the call arrived
> via sp.net. On the other hand, if sp.net has not intervened in this way
> I can see where the call has really come from (subject to B2BUAs not
> breaking the signature). In other words, RFC 4474 tells me who is
> asserting that it sent the INVITE request, whereas DERIVE just tells me
> that someone is asserting that it sent the INVITE request.
>
> John
>
> _______________________________________________
> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
-Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of
> Elwell, John
> Sent: Wednesday, November 19, 2008 11:15 AM
> To: IETF SIP List
> Subject: [Sip] Another possible limitation of DERIVE
>
> Suppose, for the sake of argument, we go with Hadriel's draft and
> OPTIONS, e.g., global call ID in INVITE request, sent back in OPTIONS
> request with global call ID to URI obtained from receive From.
>
> Now suppose the initial From URI is sip:+123456 at example.com;user=phone
> and this gets modified by callee's service provider to
> sip:+123456 at sp.net;user=phone. Callee UA sends OPTIONS request to the
> latter URI. B2BUA in sp.net acts as UAS for the OPTIONS request and
> returns 200 OK, on basis that it recognises the global call ID. What
> does this give me? Basically that the call arrived via my service
> provider, which I know anyway if it arrives over a TLS connection for
> which I have authenticated the service provider. The problem is, I don't
> know that sp.net has terminated the OPTIONS request. Even if the service
> provider has not acted in this way and the OPTIONS request has gone all
> the way back to the caller UA (or at least to its domain proxy/B2BUA), I
> have no evidence that this is so.
>
> Now contrast this with RFC 4474. With RFC 4474, sp.net can change the
> URI as above and re-sign (insert a new Identity header field). At least
> my UA can see that the only guarantee I have is that the call arrived
> via sp.net. On the other hand, if sp.net has not intervened in this way
> I can see where the call has really come from (subject to B2BUAs not
> breaking the signature). In other words, RFC 4474 tells me who is
> asserting that it sent the INVITE request, whereas DERIVE just tells me
> that someone is asserting that it sent the INVITE request.
>
> John
>
> _______________________________________________
> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip