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
- Re: [stir] Call Forward/Follow-me Alan Johnston
- [stir] Call Forward/Follow-me Rosen, Brian
- Re: [stir] Call Forward/Follow-me Paul Kyzivat
- Re: [stir] Call Forward/Follow-me Hadriel Kaplan
- Re: [stir] Call Forward/Follow-me Bernard Aboba
- Re: [stir] Permitted spoofing Henning Schulzrinne
- Re: [stir] Permitted spoofing Richard Barnes
- Re: [stir] Permitted spoofing Hadriel Kaplan
- Re: [stir] Permitted spoofing Michael Hammer
- Re: [stir] Permitted spoofing Hadriel Kaplan
- Re: [stir] Permitted spoofing Richard Shockey
- Re: [stir] Permitted spoofing Rosen, Brian
- Re: [stir] Call Forward/Follow-me Paul Kyzivat
- Re: [stir] Permitted spoofing Michael Hammer
- Re: [stir] Permitted spoofing Michael Hammer
- Re: [stir] Permitted spoofing Rosen, Brian
- Re: [stir] Permitted spoofing Rosen, Brian
- Re: [stir] Permitted spoofing Dave Crocker
- Re: [stir] Permitted spoofing Wilhelm Wimmreuter
- Re: [stir] Permitted spoofing Rosen, Brian
- Re: [stir] Permitted spoofing Wilhelm Wimmreuter
- Re: [stir] Permitted spoofing Dave Crocker
- Re: [stir] Permitted spoofing Wilhelm Wimmreuter