Re: [stir] 4474bis: Why only RECOMMEND when multiple identities?

Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> Fri, 16 September 2016 17:45 UTC

Return-Path: <Henning.Schulzrinne@fcc.gov>
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 A4CDB12B02B for <stir@ietfa.amsl.com>; Fri, 16 Sep 2016 10:45:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.708
X-Spam-Level:
X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gemKx8Rlqd09 for <stir@ietfa.amsl.com>; Fri, 16 Sep 2016 10:45:44 -0700 (PDT)
Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E03112B0BE for <stir@ietf.org>; Fri, 16 Sep 2016 10:45:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0PFizY8rCXQpW72r39EUcNEv4q1EfQdDPJF8CpRLLjc=; b=A3Dxq62RjD4MWoJiAJGECUtOUngf7ig7Y3lD8iI0hI8dkyqcfmRLkDx0UsWg+xxksnhikV3NNUq2pIGMBU9Emg+QH50eavSdRJAbuk5WXmg69nu7RxNrsNvEsquHQoXOujTShczeAVmfHBN3P1zNapt4JswD1beKGNKs4ZfQwQc=
From: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>
To: Brian Rosen <br@brianrosen.net>
Thread-Topic: [stir] 4474bis: Why only RECOMMEND when multiple identities?
Thread-Index: AQHSCr0aO2cgMkmCPEuSpwV160N6wqB2ILfggAG0jACAAxZugIAABekAgAABcQCAAB1nAIAACmAAgAAGigCAAEpQgIAAMowAgACobACAAAXhAIAAFN2AgAAGG2CAAAR+gIAAAFvn
Date: Fri, 16 Sep 2016 17:45:38 +0000
Message-ID: <CY1PR09MB063491C2A7B48FCF9E078731EAF30@CY1PR09MB0634.namprd09.prod.outlook.com>
References: <D3F837FA.1AD7F7%jon.peterson@neustar.biz> <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> <D3FDCA67.1B0885%jon.peterson@neustar.biz> <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> <4CCADA42-7919-4613-ABAC-F89ACD028484@brianrosen.net> <FAE66922-7E6D-4CF1-A61F-DC2955AF0870@gmail.com> <D4004AA8.1B3224%jon.peterson@neustar.biz> <01AE9B64-F8E4-492A-B4F7-DEDE5A8565A4@brianrosen.net> <D4006533.1B345A%jon.peterson@neustar.biz> <853CEC21-117D-4093-A0DE-4CAED384E325@gmail.com> <D400BE81.1B3BFD%jon.peterson@neustar.biz> <7C2E7C13-55A1-4259-B31C-8B24C78C42A3@gmail.com> <d01f33f5-0da9-6a99-9e1b-07acdb50479b@alum.mit.edu> <BCA22B87-26EF-40D4-A5C7-39157DBA5161@gmail.com> <CY1PR09MB06340A685CE5890FE14FC15BEAF30@CY1PR09MB0634.namprd09.prod.outlook.com>, <B5F2D704-AA4A-48B8-A12A-766FB332F3D7@brianrosen.net>
In-Reply-To: <B5F2D704-AA4A-48B8-A12A-766FB332F3D7@brianrosen.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov;
x-ms-office365-filtering-correlation-id: 0b55c135-57dd-4061-e45a-08d3de59457f
x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 6:WhFUB40Oh+BvRCfyS3N6FvRlXlu1S7QHPAVDpFXqop0nCODjf2hYxiN7mdB1so0v+quJwbfB9Cxf/VWlLUXteVpIO3SC5MwExtql6e2FSkuvF8b28h7IskEllEgCf5ZAtcWR9svOu3bqYFBAv5tqfmAqFZUdfbr6lA2y0fv75KSBTIbitoTI2ptqruMzM9BrjVMVLT6gMSTEW/GlZ/an8CnOgWJMPlG/BFiody5NoOzXpL+ub2etZYUxnEUX/ZRAwFvFhqroEdBvonhU6eFqcLZ/uO/9zLSKadSZ3euy3tM=; 5:7BRjYSyj+jYexw1mWn7F7+zIjPrUliTg/n8modnhtzW0TnvmE4DX2orjq3QWLbX3/uhHlvEmaYtfLrDwcRb71RvVZcZeS8DpH4zEdaWY5oPFTGxXf8AC2gmc95OduYnkLAhzHsoIF4mi6hnHiI0Ezw==; 24:h41o6IaKtZGMLOifQ/I7nW6D42u6M3Lo3KD9miNKJHISdScAVGYvHNL6Kfr52yKtzqp+fRoqrefWy+lj7N1ePM+hq2uKKJzl64ubILEdO9E=; 7:WE40oB77ZTl7GGls8nlz75ocq9bWf765BRCoqXQb1VtQdYZlHpjCeujInrSMGocMBUmjLRtgolw6qUO4ZCiK/t2X5UVvLQSD/9BmcaS+4DAeNMM4QjSpQ68BbNiiv61wep0oO77Hb4BInCZGUZH+5ZzSRMOBAOdHd+++dPx+jpdeF9cigGIm5zEeYI98cj5yrqhSDIyolHRcCZ9WG33sLF81wWQDLwercc5vwf13iCvaz/Hp24Gn4XgFqFmbYP3x
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0636;
x-microsoft-antispam-prvs: <CY1PR09MB06362D83AF5472E5C26EF681EAF30@CY1PR09MB0636.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636;
x-forefront-prvs: 0067A8BA2A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(377454003)(199003)(54094003)(189002)(106356001)(10400500002)(19625215002)(7736002)(7846002)(7906003)(5660300001)(86362001)(5002640100001)(33656002)(8676002)(189998001)(76576001)(68736007)(81156014)(6116002)(586003)(81166006)(97736004)(102836003)(11100500001)(99286002)(50986999)(2906002)(106116001)(4326007)(54356999)(76176999)(7696004)(3660700001)(2950100001)(19580395003)(105586002)(93886004)(9686002)(3280700002)(16236675004)(19580405001)(8936002)(2900100001)(122556002)(15975445007)(87936001)(19627405001)(77096005)(19617315012)(101416001)(92566002)(74316002)(110136003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR09MB063491C2A7B48FCF9E078731EAF30CY1PR09MB0634namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Sep 2016 17:45:38.5984 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636
X-OriginatorOrg: fcc.gov
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/MegiCkAJxWzjr6-_6FxX5vEbGpc>
Cc: "stir@ietf.org" <stir@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>, Alan Ford <alan.ford@gmail.com>
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities?
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 16 Sep 2016 17:45:47 -0000

Wouldn't this seem like something that SIPConnect 2.0 should address?


My general impression is that there are a small number of ways to do things well, and a near-infinite number of ways to make life difficult for everybody else. Trying to accommodate and detect the latter seems like a fool's errand, given that we want validation to work as close to 100% as possible. This discussion seems to have yielded a number of reasonable guidelines, along the lines of:


* consistently use PAI or From (i.e., be clear what should be used within a particular operating context, such as SIPConnect or SIP NNI)

* only convey return-callable global (E.164) numbers outside your own closed network

* separators in tel URIs should be expected

* short codes, N11 and similar numbers will likely only work within a national context


Thus, "be predictable, boring and conservative in what you send, and don't expect the receiver to be liberal".


Here, we have a penalty function: Being "creative" will likely get your call flagged as unvalidated.


Henning

________________________________
From: Brian Rosen <br@brianrosen.net>
Sent: Friday, September 16, 2016 1:35:35 PM
To: Henning Schulzrinne
Cc: Alan Ford; Paul Kyzivat; stir@ietf.org
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities?

I think it probably would within the ATIS kind of environment, but Alan is talking about things that are beyond that: his example is a SIP URI from an enterprise PBX that doesn’t have a phone number in the identity.

I personally think we need to get the PBX vendors on board as fast as we can in order to be able to support “authorized spoofing”, like call centers calling on behalf of other enterprises.  I think getting the service providers to sign in those cases will be complicated, and if they can push the problem off to the call center, it will work out better.  So, I think its worth solving all/most of the problems the PBX folks think they have.

Having said that, the only circumstance I can think of where there is an identity like he is describing is an intra-enterprise call (possibly between sites, but within the same enterprise).  In those environments, identity spoofing is much harder to mount because the intra-enterprise traffic tends to be entirely within the corporate network, and they don’t allow calls from sources they don’t know.  Doesn’t mean stir should not work, but it’s pretty far down in my list of things to worry about.

Brian

On Sep 16, 2016, at 1:27 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov<mailto:Henning.Schulzrinne@fcc.gov>> wrote:

Without taking a position on whether to canon-ize or not (that's a papal thing and I'm not catholic), I wonder if ATIS/SIPForum NNI best practices will largely moot this issue, i.e., within a particular context the use of PAI vs. From and the encoding will be constant and ruled by best practices, so that real devices will just have a configuration setting that says "Look at PAI; only if absent, look at From". Clearly, for calls within a carrier network, this is not likely to be an issue.

Not ideal, but the good guys will have an incentive to adhere to common practice, as they want validation to work.

I haven't looked at the details of the SIP NNI spec to see if that spec is sufficiently precise or whether, say, the SHAKEN ATIS document could provide that level of specificity.

Unless a parameter can short-circuit the exploration completely ("only look at X"), I'm not sure 'canon' helps with the resource exhaustion issue.

Henning
________________________________
From: stir <stir-bounces@ietf.org<mailto:stir-bounces@ietf.org>> on behalf of Alan Ford <alan.ford@gmail.com<mailto:alan.ford@gmail.com>>
Sent: Friday, September 16, 2016 12:57:39 PM
To: Paul Kyzivat
Cc: stir@ietf.org<mailto:stir@ietf.org>
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities?

Hi Paul,

> Surely the caller and signer bear some responsibility here. If they create a situation where there is ambiguity about which address is being signed then either they should do something to resolve it (e.g., in include canon) or else be prepared for the consequences if the callee can't validate. It is in the caller's interest that the call be validated, so they should be expected to make that feasible. This ultimately comes down to quality of implementation.

The sender may or may not know that there would be ambiguity at the receiving side. For example, the sender may only deal in SIP URIs and not know the receiver is also a PSTN gateway.

But in general, I agree, but feel this should be codified. This is why my proposed resolution here would be to mandate canon unless the sender knows for certain the receiving environment will follow the same canonicalisation scheme - or words to that effect.

> But there is also a brute force solution available to the validator: try validation using each of the supplied identities in turn until one validates or none do. While that might cost a bit of extra computation, the cost of that might be less than the cost of carrying the canon parameter from end to end.

That’s certainly true, but in my opinion the cost of bits is much cheaper than the cost of computation. What’s more, a brute-force receiver could generate a modest denial-of-service attack vector - send a signature for something completely different, and let the verification service munch through cycles trying various combinations to see if any validate (they won’t, of course). Minimum would be four combinations tried for just one src and one dest (trying tn: vs sip: combinations) - and this could be many more if you start to include other identifiers such as PAI or RPID. Whereas, if the canon was included, there would be one single crypto operation to verify the signature against known data.

Regards,
Alan

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

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