Re: [stir] Permitted spoofing

Michael Hammer <michael.hammer@yaanatech.com> Sat, 08 June 2013 18:30 UTC

Return-Path: <michael.hammer@yaanatech.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6135721F949F for <stir@ietfa.amsl.com>; Sat, 8 Jun 2013 11:30:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+J3iUcrBShC for <stir@ietfa.amsl.com>; Sat, 8 Jun 2013 11:30:13 -0700 (PDT)
Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA4721F949D for <stir@ietf.org>; Sat, 8 Jun 2013 11:30:13 -0700 (PDT)
Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Sat, 8 Jun 2013 11:30:13 -0700
From: Michael Hammer <michael.hammer@yaanatech.com>
To: "hadriel.kaplan@oracle.com" <hadriel.kaplan@oracle.com>, "hgs@cs.columbia.edu" <hgs@cs.columbia.edu>
Thread-Topic: [stir] Permitted spoofing
Thread-Index: AQHOY+81k0Rag7WUmkWt6dxCH9sPJpkslruA//+M/0A=
Date: Sat, 08 Jun 2013 18:30:11 +0000
Message-ID: <00C069FD01E0324C9FFCADF539701DB3A03DAAEF@ex2k10mb2.corp.yaanatech.com>
References: <5DDB5576-CAEF-453C-8C90-0C6709DAD84F@neustar.biz> <172B7D9C-1E4F-49C7-90E5-5848682625CF@cs.columbia.edu> <15ABDCF6-F127-4E8B-807F-FC3FAD78B905@oracle.com>
In-Reply-To: <15ABDCF6-F127-4E8B-807F-FC3FAD78B905@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.17.100.35]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0022_01CE6454.AE51A5E0"
MIME-Version: 1.0
Cc: "Brian.Rosen@neustar.biz" <Brian.Rosen@neustar.biz>, "stir@ietf.org" <stir@ietf.org>
Subject: Re: [stir] Permitted spoofing
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stir>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Jun 2013 18:30:17 -0000

Question:  Do we really care how many redirections occurred in the middle
network hops if we know what the original source of the signaling was?

Put another way, if we have a legitimate scape-goat for a problem call, do
you need to catch all the stooges all at once?

Mike


-----Original Message-----
From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of
Hadriel Kaplan
Sent: Saturday, June 08, 2013 2:19 PM
To: Henning Schulzrinne
Cc: Rosen, Brian; stir@ietf.org
Subject: Re: [stir] Permitted spoofing


On Jun 7, 2013, at 10:23 PM, Henning Schulzrinne <hgs@cs.columbia.edu>
wrote:

> That's probably something we might want to flesh out a bit. My very rough
vision in the central database case would be something like the following:
> 
> (1) Owner [doctors' office] says: "Please mint a cert that entitles Doctor
Smith [public key attached] to use our number 555 1234." [signed by
assignee]
> (2) Database returns cert, which is handed to doctor.
> (4) Doctor uses cert just like any other.

If we want such a thing to work in the near-term timeframe, I don't think it
can work that way.  For one thing I don't expect phones to be able to do the
signing themselves, nor their access service providers to believe/trust the
phones.  As far as I know, today the Doctor phone's service provider has to
be in on it, and the provider equipment is provisioned to know the Doctor's
phone can claim another caller-id (e.g., P-Associated-URI).  I think it's a
big jump to expect them to let any subscriber to claim to be any number just
because the supposed holder of that number "authorized" them to.  Even
ignoring the P/S-CSCF type equipment, there're a lot of other systems
involved in this stuff, for billing, CALEA, troubleshooting, etc.

A more likely scenario is:
(1) Doctor's office submits a request form with its service provider to add
Doctor's phone as authorized user for office number caller-id, or with
Doctor phone's service provider as a pull request.

(2) The service providers fax each other authorization forms with legal
signatures.

(2b) If there is some big central database model, then the Doctor phone's
service provider gets added as second source for the Office number.

(3) The Doctor phone's service provider adds into its databases the Office
caller-id as an authorized associated number for the phone to use for
outbound calls, which triggers associated identity handling during next
phone registration.

(4) The Doctor makes an outbound call using the Office number, which the
service provider authorizes and signs using its own cert.

-hadriel

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir