Re: [stir] Permitted spoofing

Henning Schulzrinne <hgs@cs.columbia.edu> Sat, 08 June 2013 02:23 UTC

Return-Path: <hgs@cs.columbia.edu>
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 07F9A21F9990 for <stir@ietfa.amsl.com>; Fri, 7 Jun 2013 19:23:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.199
X-Spam-Level:
X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 CTXsUcBKMAkH for <stir@ietfa.amsl.com>; Fri, 7 Jun 2013 19:23:33 -0700 (PDT)
Received: from salak.cc.columbia.edu (salak.cc.columbia.edu [128.59.29.6]) by ietfa.amsl.com (Postfix) with ESMTP id E25FF21F998D for <stir@ietf.org>; Fri, 7 Jun 2013 19:23:32 -0700 (PDT)
Received: from [10.0.1.2] (c-98-204-176-168.hsd1.va.comcast.net [98.204.176.168]) (user=hgs10 mech=PLAIN bits=0) by salak.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r582NVIx009393 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 7 Jun 2013 22:23:32 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: Henning Schulzrinne <hgs@cs.columbia.edu>
In-Reply-To: <5DDB5576-CAEF-453C-8C90-0C6709DAD84F@neustar.biz>
Date: Fri, 07 Jun 2013 22:23:31 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <172B7D9C-1E4F-49C7-90E5-5848682625CF@cs.columbia.edu>
References: <5DDB5576-CAEF-453C-8C90-0C6709DAD84F@neustar.biz>
To: "Rosen, Brian" <Brian.Rosen@neustar.biz>
X-Mailer: Apple Mail (2.1283)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6
Cc: "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 02:23:45 -0000

On Jun 7, 2013, at 2:17 PM, Rosen, Brian wrote:
> 
> Please note that there are another class of calling party number spoofing circumstances we CAN do something about.  Suppose a doctor wants to place a call on her mobile that appears to come from her office number.  In that case the doctor can authorize the service that arranges that call.  They can get the cert for the office number and authorize the service to place calls with that number by giving them a cert for that authorization.  This also works for, as an example, a call center placing calls for an enterprise.


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.