Re: [stir] Permitted spoofing

"Richard Shockey" <richard@shockey.us> Sat, 08 June 2013 20:23 UTC

Return-Path: <richard@shockey.us>
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 4B2FF21F9590 for <stir@ietfa.amsl.com>; Sat, 8 Jun 2013 13:23:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.81
X-Spam-Level:
X-Spam-Status: No, score=-101.81 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100]
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 J0LXwS8XcspA for <stir@ietfa.amsl.com>; Sat, 8 Jun 2013 13:23:32 -0700 (PDT)
Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 0C42521F9248 for <stir@ietf.org>; Sat, 8 Jun 2013 13:23:31 -0700 (PDT)
Received: (qmail 14815 invoked by uid 0); 8 Jun 2013 20:22:57 -0000
Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy9.bluehost.com with SMTP; 8 Jun 2013 20:22:57 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=P/ke3jt+If5rY8vKf8BkpIPMrtMnq8yp1L14lDP2xA8=; b=COps/QB6rHlYyoCl1YcSQfjHq3jhL7tYUX6K1MNK6KdVXKJbcUpPiYMi+zCcjASupq78l7MawevvtFn+Rd3+GzUqrfAXXt/nMKVpHb1uMiAwSpE4aspAnQ4wPgk8D+5u;
Received: from [72.66.111.124] (port=54135 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from <richard@shockey.us>) id 1UlPf7-0005cO-3m; Sat, 08 Jun 2013 14:22:57 -0600
From: Richard Shockey <richard@shockey.us>
To: 'Hadriel Kaplan' <hadriel.kaplan@oracle.com>, 'Henning Schulzrinne' <hgs@cs.columbia.edu>
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>
Date: Sat, 08 Jun 2013 16:22:53 -0400
Message-ID: <009401ce6485$f55e9ed0$e01bdc70$@shockey.us>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQHzDa2OziUvyJHeYP5EAIN/pOtmRALchml+AguTMeWYu6fg8A==
Content-Language: en-us
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us}
Cc: "'Rosen, Brian'" <Brian.Rosen@neustar.biz>, 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 20:23:41 -0000

Hadriel's thinking here makes a great deal of sense but we are coming really
close to dealing with issues that are the ultimately the provenance of the
NRA.  

First, it would be very helpful if anyone has any URL's that could point to
other legislation similar to the US Truth in Caller ID act.  It might be
helpful to understand some other views here.  Has the EC done anything
similar especially in relation to their Privacy Directives?

Second if you actually look at the FCC report to Congress Henning provided
you can pretty easily read between the lines here.  IMHO as an amateur
telecom lawyer you can easily see that Truth in Caller ID Act is pretty
useless.  First enforcement requires proof of "intent to defraud" which is
really hard to prove. So what is intent?  Sort of like "absence of malice"
in US Libel laws.  Second it gave the FCC zero "authority to act" in dealing
with third party service providers. 

The better solution would have been to make ALL spoofing of the signaling
data illegal period, except in the cases where the consumer or enterprise
could demonstrate a genuine need based on a strict set of criterion. Then
the consumer or enterprise could present a "certificate of need" to the
service provider that could provision the requirements as Hadriel suggests.
The FCC report clearly saw that Congress understood the legitimate need for
some permitted spoofing but took the wrong path to enforcing the
requirement. 

KISS .. keying off the Full E.164 should be relatively easy to do even in
intranational calling situations.  The To: and From: should always be
converted to + whenever possible at session origination. Describing how
Permitted Spoofing COULD BE achieved is useful to document. 

In any event we certainly have to understand these issues but ultimately the
definition of Permitted Spoofing is a NRA issue since the E.164 namespace is
under the absolute control of the nation state.    None of you wants to hear
any sad tales about ENUM and e164.arpa I'm sure. 

-----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