Re: [stir] Review of draft-ietf-stir-rph-emergency-services

Jack Rickard <Jack.Rickard@metaswitch.com> Wed, 19 August 2020 11:19 UTC

Return-Path: <Jack.Rickard@metaswitch.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 AED113A0406; Wed, 19 Aug 2020 04:19:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.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 J75lw6CFl4Dd; Wed, 19 Aug 2020 04:19:25 -0700 (PDT)
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2104.outbound.protection.outlook.com [40.107.94.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6684F3A043A; Wed, 19 Aug 2020 04:19:24 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WA4lvbVwPm1iLGT7XAwQqxL4yrxTftut4A77mWHNHKOEdK0NlIzliXvkEuRob3QKR8+0mcgYXVn3R8NwBDSP/lRK0ZEdrPX45RwOS/QRp4pCkNdJ8r5vj4kHlgt0K7s/xzL7BIWfXwMAEjE75KJWDNXiprLtq7/PH6vW/ZY0kj1b9ipQL7zOGbo4Q/bJiLtWGO6+QY39pkm1sAH/OgmKyPGrcjQQOYwE7Ww4eqtyxcMzpjqmdQyr8IH1cKnfRWflUK/WfmhUAxEhPjsCBOyzdTB+bnbRywtiMxBk+rtWs4EQGfzo+InmF5pXlg9644KzRRsF+cg/fW/5VeuG66rUgw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=484NmkYRAcBU+6csuInkUKVK8hVmABiWNzYneABogts=; b=E27Mi8SwNzWYO2f09yC0rbJ7tnAUABPSJU37UU9K8Mp8WRu0ANLe7gHtFdYfScHtJfu8PVcwEDEGs8iuof7HwVqonDmimI93RLRRVSzKh+lj3Sjls+7vDQ5795/3e/OewS7Ojc+dwXWj9ItrMfB19yDa/SvIcADHTEPCRqxa70dSHrwDPg3kT7xMBe8ekmj9wy+HzdPd2jqhQnaUwIv7bXzB9Q85ELhoM6HkiwUG1VEtBhU74to5cOItKlDAKZA7QKJYKRub+o85bbrRrnm9bggNtgzraYNzc1Upabru4S0msEsTyz7vP+CMkInCQbs2Wmm2Nmc2St8SH4SAdqQUKA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=metaswitch.com; dmarc=pass action=none header.from=metaswitch.com; dkim=pass header.d=metaswitch.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=484NmkYRAcBU+6csuInkUKVK8hVmABiWNzYneABogts=; b=Dy9UqZmu66/8xRya9OKLsb8grILkjuoG/Wr5eQmZU8SLyGyvrPPg8/elzQusH+cOriSWiv3zPmekL3w49AxiADu/ruspN+eizm3es5yfdgAvDOVu7y7BGVxa+UvZYRA8eb+XVGTxAqYIy1i+VOBQaIBDnI+0G4PzKU67SFE/4AY=
Received: from BYAPR02MB5189.namprd02.prod.outlook.com (2603:10b6:a03:62::29) by BY5PR02MB6292.namprd02.prod.outlook.com (2603:10b6:a03:1b0::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.16; Wed, 19 Aug 2020 11:19:18 +0000
Received: from BYAPR02MB5189.namprd02.prod.outlook.com ([fe80::d4d5:e9b6:c079:2718]) by BYAPR02MB5189.namprd02.prod.outlook.com ([fe80::d4d5:e9b6:c079:2718%7]) with mapi id 15.20.3283.028; Wed, 19 Aug 2020 11:19:18 +0000
From: Jack Rickard <Jack.Rickard@metaswitch.com>
To: Brian Rosen <br@brianrosen.net>
CC: "draft-ietf-stir-rph-emergency-services@ietf.org" <draft-ietf-stir-rph-emergency-services@ietf.org>, "stir@ietf.org" <stir@ietf.org>
Thread-Topic: [stir] Review of draft-ietf-stir-rph-emergency-services
Thread-Index: AdZrPXk4d/f2kRt0QXimDVa1DUwOuwKaVPgAABiWh4A=
Date: Wed, 19 Aug 2020 11:19:18 +0000
Message-ID: <BYAPR02MB5189BE4C40E7A72BCFC8BD03F35D0@BYAPR02MB5189.namprd02.prod.outlook.com>
References: <BYAPR02MB51891E95480910389FE0FDC7F3400@BYAPR02MB5189.namprd02.prod.outlook.com> <AB059D94-9BCA-4794-BCD4-211D7E8E80F2@brianrosen.net>
In-Reply-To: <AB059D94-9BCA-4794-BCD4-211D7E8E80F2@brianrosen.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: brianrosen.net; dkim=none (message not signed) header.d=none;brianrosen.net; dmarc=none action=none header.from=metaswitch.com;
x-originating-ip: [84.92.33.46]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7b8e3ab9-67a1-4f55-d522-08d84431b6f1
x-ms-traffictypediagnostic: BY5PR02MB6292:
x-microsoft-antispam-prvs: <BY5PR02MB6292A7E059A8BCA13A24EF14F35D0@BY5PR02MB6292.namprd02.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: bTBlbNWOnuSaGhckdE2jzjfKTuUbNhfwL9GkVe5xqpOWRroXOXTWWn1feo4q7sw1Pm4JTAsg2jafEbuAblWVyCOlyVQszuemKmh9+46pJaNerMUlWbRKXKU0qM4INaNN9YZsVLDmQ38EBoB3FmWK2c0FnhNPAi2p5egtC4cZcHgMxx8X6Pai4TS1OdnpkaRot1Yxc0n3z7aynrzdcVWXD7EXnFmRyKEMsyj2il4xTq/gL5EZBCBkSSMveHrr/28cfMDnI6mfjwqZn127tRvXFAg0MwRzn+DLD76PM94BCFA4v9KeFxqNQgJYl7a09yU80qMD7vTv+NFj79uS6jaQRJsvROSF496tMT9uEmNezvBVKX8/DY5CYkzoQFShVw7iqSZ50nmdvYEuAz/8EKRGAw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR02MB5189.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(366004)(39850400004)(376002)(396003)(64756008)(66446008)(71200400001)(5660300002)(66556008)(8936002)(966005)(66476007)(8676002)(66946007)(26005)(52536014)(53546011)(6506007)(55016002)(76116006)(478600001)(2906002)(316002)(9686003)(86362001)(7696005)(54906003)(33656002)(166002)(6916009)(77540400001)(186003)(4326008)(83380400001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: z8F26CqNGU9LiG+2TqMg9+rUAjNxsgqFy1JPIbN3G/O+XhkAXDgYKTokugqRrBQibaNePxtAz3nhjT3wUq6gSwQ3QMd1SVe0S3iy/N60/0B6WNuYJ7jCRscYIQFp2c95DPJTWBzSQ/Tlv0pKXAJwW7tj7CkLXD9cqONP3LKFwPTMY6UmtchhRHUJ+2VV4whpClRiMAQTyUhWcvDSMjASmKhrrYmZRpaLH0NSDUanpAy3pe5/ryJucz40nPOMeTBpir9veYzFFJ53uX+vFbCUI5V2kBCjGaDIVS9rHWy6TCK7Bvzl1UHMvC6F0etiN9GEuppx1XrgQQTWm7i/LQ42xTXHxvuR95+9C8Yn44MjvXcfJns2j9klWN4z5g5EHA95/eQDziJWI7GLqNtrouFev2b5P3TB0g0GAGDyqXUKMYWQj3/zFySO4DBCFtc506n9XKjkwKGr6N+3MnqwG9fMH3tDVWBm4eodd6WW1UDPlYmnBTogXxi7dQjRMaeNIzVsmINZso5/L7vLVWFaNmPuZUnqev3PqrJEr0h3XMFEMHhM1pfFc67SzyU/U1FB1sEpyCICJ6jenCvO1vX+YULFy6CCf3yCreEuGFTITD5b491QiuREGa4bX8PUgGqqZ62xXjewySVn4Teea+M5zYtY7w==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BYAPR02MB5189BE4C40E7A72BCFC8BD03F35D0BYAPR02MB5189namp_"
MIME-Version: 1.0
X-OriginatorOrg: metaswitch.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR02MB5189.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7b8e3ab9-67a1-4f55-d522-08d84431b6f1
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2020 11:19:18.4364 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: vEFFLB7y4qoZiT/4niXWvqpdXHdOSYIpkO+9jTAkIa6sMqN4ORen8xo3VixAiWBz7t9a+1xbKfmdjE2w3L3eDw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR02MB6292
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/PMa_kI_sAJH5bNPQ91-KzMe97FQ>
Subject: Re: [stir] Review of draft-ietf-stir-rph-emergency-services
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 19 Aug 2020 11:19:28 -0000

Thanks, that's really useful, however, I'm not convinced.

For ESorig, as far as I know this isn't currently always the case, I am aware of situations where emergency calls just look like normal calls with a number of 911. I'm also still unclear about what affect this has, as you can currently already sign emergency calls using the standard mechanisms (barring the whole "urn:service:sos" tn which I don't believe is standardised for STIR yet?)  by putting "esnet.0" in the auth field of an rph passport.

For EScallback, if the sph and "rph.auth" claims cover theis entirely why is EScallback needed? I'm also still unclear what the verification service behaviour is here.

I'm still unclear as to how this spec helps with allowing and preventing malicious use of emergency calls. You can already put esnet resource priority pairs in the "rph.auth" claim and that seems to provide as much security as this does. I do agree the sph claim does provide value, however.

I did just realise that the esnet Resource Priority needs to be in the "rph.auth" claim or the logic from that rfc will kick in and remove it, as per:
RFC 8443, section 4.2
   In such scenarios, the SIP 'Resource-Priority' header field SHOULD be
   stripped from the SIP request, and the network entities should treat
   the call as an ordinary call.

I'll note that some of my questions and concerns haven't been addressed yet, I'm happy to resolve this first, just making a note so that they don't get lost/I don't forget about them.
Jack

From: Brian Rosen <br@brianrosen.net>
Sent: 18 August 2020 22:31
To: Jack Rickard <Jack.Rickard@metaswitch.com>
Cc: draft-ietf-stir-rph-emergency-services@ietf.org; stir@ietf.org
Subject: Re: [stir] Review of draft-ietf-stir-rph-emergency-services

Let’s keep the two use cases separate:
ESorig is an emergency call (user to authority).
EScallback is a call from authority to user.

For ESorg, the call is marked with a Request-URI of urn:service:sos.  The “To” field is ignored in routing and handling the call.  That’s how you know this is an emergency call.   For stir purposes, the From is an ordinary identifier, and gets treated in the normal way.  However, the rph value can only be used by a valid emergency call, and a valid emergency call is a Request URI of urn:service:sos, and a valid From.  So you don’t have any knowledge of emergency services identifiers, only the Request URI of urn:service:sos.

For EScallback, the marking is a distinguished value in SIP Priority.  If a call has that value, it’s a call back.  The originating service provider knows who are the authorities who are allowed to place call backs, so the check is what is in SIP Priority, and one of the allowed authorities in From.  As a practical matter, in most cases, the call will be signed by the emergency authorities themselves, who will be able to get appropriate credentials for this purpose.  In most cases I’m aware of, the To in an emergency call won’t match the From in a Callback, but it’s possible for that to happen, and we want to allow it.

Esnet is a Resource Priority Header namespace, not a SIP Priority value.  We’re allowing emergency calls and call backs to use rph, and we’re protecting against malicious use of it.  So unless the call has urn:service:sos in Request URI, or the right SIP Priority in a call back (and from an authorized authority) they can’t use rph with the esnet namespace.  Generally, unless under attack, emergency calls go through even if there isn’t a passport.  Many networks won’t offer actual priority to emergency calls, but the emergency services networks (ESInets) will.

If a call arrives anywhere with an rph using esnet, and isn’t an emergency call, with the appropriate passport,  any intermediary can refuse to give it any priority,  The emergency authorities may accept a call without a valid passport, but they might treat it with much more suspicion than they would any other call.

For call backs, the network may have special behavior.  For example, it may send the call to the device that placed the emergency call, rather than, for example, voice mail.  The network has to be able to trust that SIP Priority is set appropriately.  It will also have rph using esnet, and the network can grant it appropriate priority if it has that capability, and would not allow esnet otherwise.

The only value in covering other uses of SIP Priority is to protect against middle boxes modifying it.  We don’t really have use cases for that.  It probably wouldn’t hurt to allow it though.

Does that help?

Brian



On Aug 14, 2020, at 1:21 PM, Jack Rickard <Jack.Rickard=40metaswitch.com@dmarc.ietf.org<mailto:Jack.Rickard=40metaswitch.com@dmarc.ietf.org>> wrote:

I have reviewed draft-ietf-stir-rph-emergency-services-02 and have some concerns and questions. I don't believe this spec is implementable in its current form.

Thanks,
Jack

Why are "ESorig" and "EScallback" distinct?
They seem to serve a very similar purpose with the only difference being whether orig or dest should be the emergency services. I don't believe there's any check that can be done to validate:
   When using "ESorig" as the "rph" assertion value, the "orig" claim of
   the PASSporT MUST represent the calling party number that initiates
   the call to emergency services.
This (and the equivalent statement for EScallback) don't seem possible to me to check (barring the standard orig/dest checking)..
This would make the check "at least one of the parties should be the emergency services" enough to validate that this was a reasonable call.


Why have them at all rather than just using auth?
This is very possibly an issue with my understanding, but I'm not clear on why "ESorig" and "EScallback" even need to exist. "esnet.0" etc. are SIP Resource Priority headers, so should be included in the "auth" field anyway by the RPH spec. This spec appears to apply extra constraints (that a one of the callers must be the emergency services) for the "esnet" namespace but it's not clear why entirely separate claims are needed.

In a similar vein, what should a verifier do if it receives a call containing an invalid "ESorig" or "EScallback" value or the passport is invalid/untrusted, I'm assuming the behaviour is the same as for auth but this isn't clear. Although stripping the fact that this is an emergency call is potentially dangerous..


Specify the type of the "ESorig" and "EScallback" claims.
This specification currently doesn't specify the type of the new fields, there are only examples and this isn't enough. It looks like they both follow the same scheme as the rph "auth" claim, however "esnet,x" doesn't quite fit into that due to the comma and that x isn't a valid priority value.


Why is sph limited to psap-callback? What should the verifier do if it isn't that? What should it do if it is?
I'm not entirely clear on the purpose of the sph claim, however, it seems odd that it doesn't cover the full range of possible values for the SIP Priority Header. Is there a reason that it doesn't cover the "non-urgent", "normal", "urgent", or "emergency" values?
There is also no verifier behaviour defined here, should the verifier remove the Priority header if it receives an invite with no passports signing for it? That seems dangerous to me but would be consistent with rph. Alternatively, what should the verifier do if it receives an invite with a valid passport claiming sph but with no Priority header should it add it in? I'm not sure the spec needs to be too prescriptive here, however some mention of verifier behaviour and the associated security considerations would be useful.


Should the spec be stronger about the compact form?
Section 3 currently states

   The use of the compact form of PASSporT is not specified in this

   document.
However, a compact-form passport following this spec would be hard to verify as it introduces multiple possible rph variants, I think this spec could go further and say you shouldn't/mustn't.


What is the requirement of these new parameters.
As I understand it, the passport spec allows you to create a passport containing whatever JWT fields you want and verifiers should just ignore any fields they don't understand. Unless the "ppt" claim is set, which indicates that verifiers should discard it if they don't recognise that passport type. As this spec adds additional fields to an existing passport type it isn't immediately clear what the behaviour should be. Specifically, is an rph passport containing only "rph.ESorig" valid now (where it wouldn't be before because auth isn't present), is an rph passport containing no rph and only sph valid, and what does a non-rph passport with sph or ESorig set mean?

_______________________________________________
stir mailing list
stir@ietf.org<mailto:stir@ietf.org>
https://www.ietf.org/mailman/listinfo/stir<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=02%7C01%7CJack.Rickard%40metaswitch.com%7C1da6b58cfadb48a6cef308d843bdf44e%7C9d9e56ebf6134ddbb27bbfcdf14b2cdb%7C1%7C0%7C637333830454755078&sdata=pFRkcyo37w0eVGz86WYmhiijHPeRYMA570KExOU9uis%3D&reserved=0>