Return-Path: 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 9FAFDC06EEF2; Mon, 21 Oct 2024 09:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=transunion.com header.b="Pbok4386"; dkim=pass (1024-bit key) header.d=transunion.onmicrosoft.com header.b="Zjh87nEk" Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbvRzxh3jjQH; Mon, 21 Oct 2024 09:11:29 -0700 (PDT) Received: from mx0b-00030c01.pphosted.com (mx0b-00030c01.pphosted.com [67.231.153.155]) by ietfa.amsl.com (Postfix) with ESMTP id 8E717C23A85B; Mon, 21 Oct 2024 09:11:29 -0700 (PDT) Received: from pps.filterd (m0216089.ppops.net [127.0.0.1]) by mx0a-00030c01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 49L9S7Hx004192; Mon, 21 Oct 2024 11:11:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transunion.com; h=cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=tuppdkim; bh=t7CnmPg0nJHO6OzLA7gc+4hc6 KWvQhcr35p6YGF0nqg=; b=Pbok4386ORqSMqEPbfdTH7fmynbzci06BZtwlcyAL 2A0GdlhKkRexyxHMCGHqzVIpPml/DbGp3AjJgXB5mEtKN5dLMSUA+1qEZr1iCZLN kGHt/342qfUQZSPU7dNtKMl8Q0QW3H365v+g4FZ40eGcxSoS0GbH9oYh9OogXx7w dgz/6jUvlkgOazy3ct/v3tO/NSLqtQc61X9qFuROkHoiJxRp55FbOp8+SdyyXXE5 5/z7oSZQxdOx9szzzpr58fnar6s/pXJM4ORsA5oN1UETRpMNB8v5q9waOGkJ1KMR /CtWb7HwWQ2eofoeGwSeYXcGSmnbZJxz9WXNt48DqMhOA== Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2047.outbound.protection.outlook.com [104.47.58.47]) by mx0a-00030c01.pphosted.com (PPS) with ESMTPS id 42cvcbmm2p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 Oct 2024 11:11:27 -0500 (CDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ajiL8JzYkDmtDYFGJhpbYGhHEtvnmrnstquSizrtw39f6HTKUtKhoIacHgd0EmdI9slSTyZJOlt9QSr4O/LGeG0GG67fkl6OFjrdVauARmlu/ddhTSA6pUU+7k4iH6AG1XWC4eB2iS+ug9AhdDC1JeP0+N7/7EdLPgyWuI7I/vygq8TGDwDiJckSVIg6rd1+/buvoLVD+5UyZ88pDqJmxe81fBAoHEJvLK7yGzaD/l/mnhVj3L5Lx32Xgg4DIKGZ3RpCXNvvSWDeCqAnna0fUtFxQb/GarfrBmG/+EbZD9UXECBFyS1rH5mp5lATKWjC8Wp8bGsns669HO8OeUyktw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=t7CnmPg0nJHO6OzLA7gc+4hc6KWvQhcr35p6YGF0nqg=; b=EtOIkcVkYyfnivrxL7YXYIrtW9TBa0z3hV57UbKM2pIIilAErWRFQeCa5QpRo5H3EYcto/JaHnV6JeptU98yETYsZ1gRL0bTyvTljcx7ajwmGU3aGKl4honUo+MMBdzI6ldo/QGw6SZa4XAdMaPU3rPtxlYA0ucimQ6kub0L/zfiMNsk3tmEn3hH/DCPrQj6sSVl2zF7VjQCmlc4ysZlCVI9TalpEwbOb73K/mtTqpMlupbmPV8HdRP2/QyMf5HzvtRULqZrYMKp0TqRZ80KtkDN9XNLKnVFqg8Yp1wPjfVR3YnV6j/sfGYfCQHgkDh+Jlf7xuU+qXmwJx/9yi069w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=transunion.com; dmarc=pass action=none header.from=transunion.com; dkim=pass header.d=transunion.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transunion.onmicrosoft.com; s=selector2-transunion-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t7CnmPg0nJHO6OzLA7gc+4hc6KWvQhcr35p6YGF0nqg=; b=Zjh87nEk/BARSEiT/q0V2ysIoj/QliZm0JhgqpbrQdXjFnSD5n4fhdOlJJYc0rgKv6LEo40Z9GziVi3bItxqOJzcTXqFSo839NIcjGMMItDorZqJhl3SSYZbnckCjiKE5RYmYHMQ+GDh+nKhaWJpqhT6WI2hkPdDMBy96/Sg1is= Received: from CO6PR17MB4978.namprd17.prod.outlook.com (2603:10b6:303:139::23) by PH7PR17MB7124.namprd17.prod.outlook.com (2603:10b6:510:2f6::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8069.26; Mon, 21 Oct 2024 16:11:25 +0000 Received: from CO6PR17MB4978.namprd17.prod.outlook.com ([fe80::ac66:9d7e:2419:fd2a]) by CO6PR17MB4978.namprd17.prod.outlook.com ([fe80::ac66:9d7e:2419:fd2a%4]) with mapi id 15.20.8069.027; Mon, 21 Oct 2024 16:11:24 +0000 From: "Peterson, Jon" To: Orie Steele Thread-Topic: [stir] AD Evaluation: draft-ietf-stir-rfc4916-update-05 Thread-Index: AQHa4Qi3N5C8ya/QVkKYpmEbkmVPmLKR1rFi Date: Mon, 21 Oct 2024 16:11:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-reactions: allow x-ms-publictraffictype: Email x-ms-traffictypediagnostic: CO6PR17MB4978:EE_|PH7PR17MB7124:EE_ x-ms-office365-filtering-correlation-id: 53046369-a7be-4430-cd17-08dcf1eb02fa x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|8096899003|38070700018; x-microsoft-antispam-message-info: =?Windows-1252?Q?MpSf2jFxEhuad2l4ukwdVSLxYFdyE9E71XXXgOzI8unYCeiNuygfHDNc?= =?Windows-1252?Q?KCd+apImOKqufmd7cQzFlFbTosnHUYv4m/tflIRkoYQVz8jhisxhH4Lv?= =?Windows-1252?Q?vJy5Qr3awCerzqqT5Q4sIAX3tk0r/ldX84lIJh8PT2Kypx7QNCsUR+ge?= =?Windows-1252?Q?HTO7h8mPZgS+uaO8dINqeBgPYWT6SsXqFtz7GhCVInmeYRdXEMGrGxEx?= =?Windows-1252?Q?XWFKIrNuW+bgw3mgs3gJRLfBwSZD4y/pgSAj0FnpflL6em1SupIKwjT4?= =?Windows-1252?Q?jAwiWVrGS8sCD3k/nKvP2rouwYsH+j3taHqHXhtFf9Q2p++syI8Qvvsw?= =?Windows-1252?Q?4RgBsvGeNPUqbpJUCMPXzpEy2tiG3C7JjKONoVRmJQKUXGa1l+XjkQPq?= =?Windows-1252?Q?DBRN5beMcpWwx0qqFr0TV/VbGDQggrg2G31zh3W4FtZt/55dCSgY2iXL?= =?Windows-1252?Q?dqN4NDlTfASjijFT2ghvbCh7U1llj7/fty5O6Pk+uoWBfuf8R4vb8m6Q?= =?Windows-1252?Q?8g56Gu2QUyShqfYfEJ7jB7rQONx+EStULGQmAgKlRFfGUtn6hqgxzSTI?= =?Windows-1252?Q?qduXkips3v6LpsIrvzSYGFFlvRmEl/Yr8/cso9Isb38+0+5tu/HDO/Dv?= =?Windows-1252?Q?qvYqlkA7Wk5QvWMOj+0xdLW5uXOJXaIULlSRALxCg4RNkdYCPqF1SOYL?= =?Windows-1252?Q?Ur1KSrURrfUf6tS0pAgQkOzYPilYdaxTTbB5R3Cui3n5UHhZWCWwifhu?= =?Windows-1252?Q?BswloyXUTGaj2QYgOXr1+Ez4QUBlKJG7TRt5vACLdLrK0LStfWY1nt46?= =?Windows-1252?Q?Zi0HYHRiqn/NiGpym9yhZW05nTogY8gMVb1/+mmzFmKsMC8rdNcaOXhj?= =?Windows-1252?Q?WhzdD4v2DCio6uqi/kSRPYoged+spqWRyYwQD7ja/mUnzpaB+OBpFV+x?= =?Windows-1252?Q?lJcMEXaOqK9wKT8zZvdAtOkVLch/mtgKL32+XnM0bZtnoLU++rklW4KU?= =?Windows-1252?Q?iZfVR3f9ef7cnUmyCOr3GguF4mMdyB7uJnj8bPnoItqCfDxu5XydxZsY?= =?Windows-1252?Q?wqJu42esskCaGNfBNgoHc96Nu6YIkC35Jx8Z0qzXAjbEpxKbp+V5GfiT?= =?Windows-1252?Q?gL4Z4LFpezqG2smE0kzx8vt9rryyFETNUi77erGjAkY2op0uFMExUCup?= =?Windows-1252?Q?M7cn7vM6pDag0oQ4vnOZWV1nJeRh/mHaD2Q12mW94pPZdRaSs1uT+0HS?= =?Windows-1252?Q?JtKZCwJMCabAY1JEyFueFP9tUD4/FtTKYzOaGj5owgNUdWAZlC2nZbkV?= =?Windows-1252?Q?T3qwhh+LcIysUGcq6PoG+ZncmyeIp/86aiMtwkOaTtZ39co9ZDRnjltF?= =?Windows-1252?Q?HqsgsvaKy7rZgW4UR+x5GT0h0dtbuLebLJe+D626qtqYLuVOis66S8Db?= =?Windows-1252?Q?3SJVHIS762AU0tOj2z/Udsf+3qW9peOVIxsOaDkbNYI=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CO6PR17MB4978.namprd17.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(8096899003)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?TIJWqc1EMA/gpy5WwlnxQe7GX3z9eoCHP2Ta1eB5NPx9oCSQXa69+BjL?= =?Windows-1252?Q?0hN3nzMy6/kGg5RWO9edKmRRjKy5WzUbnUPJJaucg3sij/aw0YJIVHb+?= =?Windows-1252?Q?ZzTj3jyMliHF8AV1CL2ylQDHEdaMBW+TpV5+Issn2JXJ5A5TvD5q6T22?= =?Windows-1252?Q?iX8W3dxk2y/bwCKQwV5f3xsm6Ck2Jhlm8otvic/sotyYKGI8Q/agsobR?= =?Windows-1252?Q?PD1k9XFh6bQ55KaklA3GE0A+G4YaDwT+mZj+Aq1PLc/iY9WiKXeWj9f9?= =?Windows-1252?Q?9Xgv7miI2ovR4O99bolk6F2nXEtIe66zYNat/3x94SLZorfevu9IPjsi?= =?Windows-1252?Q?Sbn4eGWvB5Q2eQPdOYUveFt/G0/m9z1myfNBP8I+dLlaWiC1bPTAbDYV?= =?Windows-1252?Q?Ig8f9conj3gn3DabtpKIUNHACqRfMC2LIR2CbvZc8H96fsSmV69u4kHr?= =?Windows-1252?Q?nNcRjcWZZnEtp5ytZ1+s0yfh5Oak3r7p5lcYIO0rc3Tu/jjCYMh2aoaQ?= =?Windows-1252?Q?eyEVb3T0sxrBxs2rlquK0hBMkygyTz307Kw/1iP5OSvPyaJ6Zm4gbiN0?= =?Windows-1252?Q?/dCSH2AjMgRqg/Q2h2rhs0AQnJAbllnsmmhA4QexlWRFNvn54+5pCSqI?= =?Windows-1252?Q?SJaT5l+HnCeNRppA03RR1FkVlLJOlpDTuNhKTFFfTcIHc8Ed/4vvFVzS?= =?Windows-1252?Q?izFNjSieuJr4e8MAR95FIh4Py4/7G5+yvrykj5tvPLKoloJf/rdzop7g?= =?Windows-1252?Q?y7Q7+ylbqqhOBQ3PlRC6f+dxOwN0sCh4F3WkU8rkxjD9wmfo9YD3w1HK?= =?Windows-1252?Q?U3tvdAtZIZsZn+542mMSrICEH92g9glXjV4/bqMmSTxsTycJv0H+xxGJ?= =?Windows-1252?Q?Bv4iUAtdfOxsgsNc/enjJq1ZRsqzCHrVMxlQ7ltCyHdvHv81zy/jAfms?= =?Windows-1252?Q?APEqRVPBy+ukAAjEXf/2h/17XqyjGvKPpRPLY5gN1qmRjGYBIwbTEBVT?= =?Windows-1252?Q?5p/OlkXQoei8ryVB8w66wA9DZr1talcNST6B/SCpy2qSLhOxlWO+N6jN?= =?Windows-1252?Q?DU5kf2h6s5dNDhiNXS/gQugH5YGTRDYWwxDPxcBh4WhMgA/SZL726LKp?= =?Windows-1252?Q?9u+rKrjHwL47kOeZ04XgF8rffde1tRCq5RNO0zLwA8cR7PSxX7rBr/wQ?= =?Windows-1252?Q?bNdskvJBGsls+XGuWhmEcPFxMemPliv5YWTAZMWN5HS1UgIp0yGyZNuU?= =?Windows-1252?Q?Xob7y6hB19ZOry3W6K3VQjkC1E/df43BMvtYNFGBhei7erhk4xP5dIkB?= =?Windows-1252?Q?hmuvhheiTbCfb7e5QPJeEQCUdzqbkvO8mLJiBcTTb2fAyj9gcQGP1vIe?= =?Windows-1252?Q?Kne+TI921+nDfqH0xmBheqcH0NQZCWtNtdbBrDzVcpoQjeWtGksbDtBr?= =?Windows-1252?Q?uGzBb+K6Ze2bdGxcr6AgzDttWSig78czg8gDNZAJHgzFc4hO6glxrhpw?= =?Windows-1252?Q?x0gHJMhCgQNnaQN5cg3KTxzMC8rWpAwIHs7oOqy/zQY+IZdxrMbBBcFj?= =?Windows-1252?Q?yivlyTStEfbYW7GMA5bbXa2JKKGqY28zW2sBdNbY7LXl2jQ0WFJkvAK3?= =?Windows-1252?Q?a6HxPSRPtCYMdsq6AHDH83APFm74A1EHt4lVEAwXDpmMFwD1PxncVK/3?= =?Windows-1252?Q?cgQ5Aww/TyfgB+XRSDchIgiMwTyOo0vKa3bo+2JUc0K1QU0FLdYoQg6B?= =?Windows-1252?Q?zn9cGNZbGQHhCirjoJ4=3D?= Content-Type: multipart/alternative; boundary="_000_CO6PR17MB4978B4C974AB1CD829015FC0FD432CO6PR17MB4978namp_" MIME-Version: 1.0 X-OriginatorOrg: transunion.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO6PR17MB4978.namprd17.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 53046369-a7be-4430-cd17-08dcf1eb02fa X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2024 16:11:24.9002 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0685d760-4332-4f24-b2ea-ffbbc2383f15 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: eIZ80p/r5fAYPtdLmdEI8cWuwdtWUkMcnU+sfv9J+HlcxXYrBSWpXqSXy+Nnh1vjupY+9DiyYr9j89KIO9aU6BpWrkB0tdZQ4yyE6hJAioU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR17MB7124 X-Proofpoint-GUID: 89NLYky8JU2hwJfJdw-UyKmndfAIDpTk X-Proofpoint-ORIG-GUID: 89NLYky8JU2hwJfJdw-UyKmndfAIDpTk X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1051,Hydra:6.0.680,FMLib:17.12.62.30 definitions=2024-10-05_03,2024-10-04_01,2024-09-30_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 clxscore=1011 impostorscore=0 priorityscore=1501 phishscore=0 malwarescore=0 mlxlogscore=999 adultscore=0 suspectscore=0 mlxscore=0 lowpriorityscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2409260000 definitions=main-2410210115 Message-ID-Hash: LAPGGAZVKVIVI7TFF5D2ZEH7DRU2PQGV X-Message-ID-Hash: LAPGGAZVKVIVI7TFF5D2ZEH7DRU2PQGV X-MailFrom: Jon.Peterson@transunion.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-stir.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "stir-chairs@ietf.org" , IETF STIR Mail List X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bstir=5D_Re=3A_AD_Evaluation=3A_draft-ietf-stir-rfc4916-update-0?= =?utf-8?q?5?= List-Id: Secure Telephone Identity Revisited Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --_000_CO6PR17MB4978B4C974AB1CD829015FC0FD432CO6PR17MB4978namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Orie, Thanks for the review. There=92s a new version with these fixes. A few res= ponses below inline. I have only a few comments and several nits. For the "stylistic nits", please feel free to ignore them. I'm providing a corrected announcement to be sent from the writeup here (Ru= ss feel free to make any additional corrections): Technical Summary The SIP Identity header conveys cryptographic identity information about the originators of SIP requests. However, the Secure Telephone Identity Revisited (STIR) framework provides no means for determining the identity of the called party in a traditional telephone calling scenario. This document updates prior guidance to reflect changes to SIP Identity that accompanied STIR, and offers a way to tell the originator the "connected identity". That is, the telephone number of the party that answered the call, even if the call was retargeted to party trying to impersonate the intended destination. Working Group Summary The STIR WG reached consensus, and there is support for publication of this document as a standards-track RFC. Document Quality Several people have expressed interest in implementing this specification. Personnel Russ Housley is the Document Shepherd. Orie Steele is the Responsible Area Director. ## Comments ### Clarifying div requirements ``` 293 This specification introduces another alternative. When sending a 294 "rsp" PASSporT type in a SIP response, a UAS MAY also include (in 295 Identity header field values) any "div" PASSporTs it received in the 296 INVITE that initiated this dialog. Thus, PASSporTs of type "div" MAY 297 also appear in SIP responses. These "div" PASSporTs can enable the 298 originating side to receive a secure assurance that the call is being 299 fielded by the proper recipient per the routing of the call. In this 300 case, the "dest" signed in the "rsp" PASSporT will be the address-of- 301 record of the party who was reached, rather than the "dest" of the 302 PASSporT received in the dialog-initiating INVITE. ``` Consider: the "dest" signed in the "rsp" PASSporT MUST be the address-of-... You=92re correct, changed to MUST. I also wonder if this paragraph could be rephrased to include a single MAY = and then several MUST / SHOULDs. I mean, as I read it, there=92s normative language where it should be in th= is paragraph (apart from the fix you suggested above), the rest is really m= ore descriptive. I found it a bit difficult to grok, but I am not a SIP or STIR expert. ### Clarifying why SHOULD ``` 343 limited to provisional dialog requests. Once a dialog has been 344 established with connected identity, any re-INVITEs from either the 345 originating and terminating side, as well as any BYE requests, SHOULD 346 contain Identity headers with valid PASSporTs. If only the 347 terminating side supports connected identity, obviously the 348 originator cannot be expected to know that it needs to send PASSporTs 349 for subsequent requests like BYE. Doing so prevents third-parties ``` I think this reads as "SHOULD... unless only the terminating side supports = connected identity..." Is that right? Yes that=92s right. The RECOMMENDED that follows this might be redundant, but I don't mind it. Cool. ### can vs MUST ``` 376 Mid-dialog requests also require special handling in diversion cases. 377 Relying parties who intended to trust an "rsp" PASSporT MUST validate 378 any "div" chain back to the "rsp" PASSporT on any Identity header 379 field values received in responses. The dialog initiator can then 380 treat the certificate that signed that "rsp" PASSporT as the 381 appropriate certificate to sign any further mid-dialog or dialog- 382 terminating requests received in the backwards direction. ``` Is the dialog initiator required to treat the certificate that signed that = "rsp" PASSporT... ? Or is this "can" descriptive of the behavior implied by the MUST above? The vague =93can=94 on the originating side reflects the reality that it=92= s a policy decision about authorization on the originating side that determ= ines how the cert will be treated there =96 phrasing it that the originato= r MUST treat the cert that signed the =93rsp=94 as =93appropriate=94 sounds= like we=92re depriving the originator of the ability to not trust the cert= because they don=92t trust the root that issued it or whatever. Make sense= ? For a non expert like myself, this could be clearer. ### MUST be opt-in ``` 524 cases. From a user experience perspective, this would likely work 525 similarly to current systems for sharing numbers, names, and even 526 pictures from calling parties to called parties -- users have 527 considerable control over that experience, and similarly for 528 connected identity this must be an opt-in choice for users. In ``` Can this be a normative privacy requirement? It's not really prescriptive of any bits-on-the-wire protocol behavior =96 = this is more text about what sorts of configuration options a user might ha= ve on their UA (their phone or whatever), a sort of user experience matter = that we don=92t typically give normative guidance for in my experience at t= he IETF. Perhaps we can seperate the user experience part from the opt in part, and = make this stronger. I=92m not really sure how to do that =96 that is, how we can mandate that y= ou MUST NOT use connected identity unless some user experience box has been= ticked, because to do that we=92d need to design the box. What qualifies a= s an adequate opt-in to permit connected identity? Those sorts of questions= . The nits below are fixed in the new -06 (along with the normative change ab= ove). Thanks, Jon Peterson TransUnion ## Nits ### Expand on first use PSTN, UAS, UAC, SRTP ``` 165 Today, sophisticated adversaries can redirect calls on the PSTN to 166 destinations other than the intended called party. For some call ``` ``` 293 This specification introduces another alternative. When sending a 294 "rsp" PASSporT type in a SIP response, a UAS MAY also include (in 295 Identity header field values) any "div" PASSporTs it received in the 296 INVITE that initiated this dialog. Thus, PASSporTs of type "div" MAY ``` ``` 370 response has been received from a UAS. This specification does not 371 forbid a UAC from sending a CANCEL for its own PASSporT-protected ``` ``` 406 This is analogous to a situation where SRTP negotiation fails because 407 the keys exchanges at the media layer do not match fingerprints ``` ### Would or might, not both ``` 242 While it would might seem attractive to provide identity for failure 243 response codes (4XX, 5XX, 6XX), those explicitly do not form dialogs 244 or connections, and are thus outside the scope of this specification. ``` ### sunny-day Consider "basic" or "primary" alternatives which improve comprehension for = international readers. ``` 252 numbers are the identifiers used by the caller and callee. For 253 sunny-day use cases, a PASSporT in a 183 or 200 OK should be 254 sufficient to secure media keys for the purposes of SIPBRANDY 255 [RFC8862]. ``` ``` 495 However, the complexity of this mechanism makes it impractical to 496 deploy for both the "sunny day" use case and the diversion use case ``` ### a different ``` 307 received in a dialog-forming request with aidfferent "dest" value ``` ### non normative may ``` 309 used in responses. "div" is not universally supported, so calls may 310 be retargeted without generating a "div" PASSporT, in which case the 311 use of "rsp" PASSporTs will not be possible. Note that the decision 312 to trust any "div" or "rsp" PASSporT is, as always in STIR, a matter 313 of local policy of the relying parties: some stricter systems may not 314 want to trust any "rsp" that differs from the "dest" in the PASSporT 315 of the original request. ``` Consider changing a few lower case "may" to "might" for better clarity here= . The =94may not want to trust=94 is again not bits-on-the-wire behavior but = a policy decision =96 but the first MAY in =93so calls may be=94 that shoul= d be normative. ### extra sent ``` 367 Identity header with a PASSporT. However, CANCEL requests can also 368 sent be sent by stateful proxy servers engaged in parallel forking; ``` ### automata vs automated system The word "automata" appears twice, where "automated system" might improve c= omprehension for international readers. ### his/their contributions ``` 506 We would like to thank Russ Housley and Jonathan Rosenberg for his 507 contribution to this specification. ``` Regards, OS, ART AD --_000_CO6PR17MB4978B4C974AB1CD829015FC0FD432CO6PR17MB4978namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

 

Hi Orie,=

 

Thanks for the revi= ew.  There=92s a new version with these fixes. A few responses below i= nline.



I have only a few comments and several nits.
For the "stylistic nits", please feel free to ignore them.

I'm providing a corrected announcement to be sent from the writeup here (Ru= ss feel free to make any additional corrections):

Technical Summary

   The SIP Identity header conveys cryptographic identity informa= tion
   about the originators of SIP requests.  However, the Secu= re Telephone
   Identity Revisited (STIR) framework provides no means for dete= rmining
   the identity of the called party in a traditional telephone ca= lling
   scenario.  This document updates prior guidance to reflec= t changes to
   SIP Identity that accompanied STIR, and offers a way to tell t= he
   originator the "connected identity".  That is, = the telephone number of
   the party that answered the call, even if the call was retarge= ted to
   party trying to impersonate the intended destination.

Working Group Summary

  The STIR WG reached consensus, and there is support for
  publication of this document as a standards-track RFC.

Document Quality

  Several people have expressed interest in implementing this
  specification.

Personnel

  Russ Housley is the Document Shepherd.
  Orie Steele is the Responsible Area Director.


## Comments

### Clarifying div requirements

```
293   This specification introduces another alternative.  When se= nding a
294   "rsp" PASSporT type in a SIP response, a UAS MAY also = include (in
295   Identity header field values) any "div" PASSporTs it r= eceived in the
296   INVITE that initiated this dialog.  Thus, PASSporTs of type= "div" MAY
297   also appear in SIP responses.  These "div" PASSpo= rTs can enable the
298   originating side to receive a secure assurance that the call is = being
299   fielded by the proper recipient per the routing of the call.&nbs= p; In this
300   case, the "dest" signed in the "rsp" PASSpor= T will be the address-of-
301   record of the party who was reached, rather than the "dest&= quot; of the
302   PASSporT received in the dialog-initiating INVITE.
```

Consider:

the "dest" signed in the "rsp" PASSporT MUST be the add= ress-of-...

You=92re correct, c= hanged to MUST.


I also wonder if this paragraph could be rephrased to include a single MAY = and then several MUST / SHOULDs.

 

I mean, as I read i= t, there=92s normative language where it should be in this paragraph (apart= from the fix you suggested above), the rest is really more descriptive.



I found it a bit difficult to grok, but I am not a SIP or STIR expert.


### Clarifying why SHOULD

```
343   limited to provisional dialog requests.  Once a dialog has = been
344   established with connected identity, any re-INVITEs from either = the
345   originating and terminating side, as well as any BYE requests, S= HOULD
346   contain Identity headers with valid PASSporTs.  If only the=
347   terminating side supports connected identity, obviously the
348   originator cannot be expected to know that it needs to send PASS= porTs
349   for subsequent requests like BYE.  Doing so prevents third-= parties
```

I think this reads as "SHOULD... unless only the terminating side supp= orts connected identity..."

Is that right?

 

Yes that=92s right.=



The RECOMMENDED that follows this might be redundant, but I don't mind it.<= /p>

 

Cool.



### can vs MUST

```
376   Mid-dialog requests also require special handling in diversion c= ases.
377   Relying parties who intended to trust an "rsp" PASSpor= T MUST validate
378   any "div" chain back to the "rsp" PASSporT o= n any Identity header
379   field values received in responses.  The dialog initiator c= an then
380   treat the certificate that signed that "rsp" PASSporT = as the
381   appropriate certificate to sign any further mid-dialog or dialog= -
382   terminating requests received in the backwards direction.
```

Is the dialog initiator required to treat the certificate that signed that = "rsp" PASSporT... ?

Or is this "can" descriptive of the behavior implied by the MUST = above?

 

The vague =93can=94= on the originating side reflects the reality that it=92s a policy decision= about authorization on the originating side that determines how the cert w= ill be treated there =96 phrasing it  that the originator MUST treat the cert that signed the =93rsp=94 as =93appropriate= =94 sounds like we=92re depriving the originator of the ability to not trus= t the cert because they don=92t trust the root that issued it or whatever. = Make sense?



For a non expert like myself, this could be clearer.

### MUST be opt-in

```
524   cases.  From a user experience perspective, this would like= ly work
525   similarly to current systems for sharing numbers, names, and eve= n
526   pictures from calling parties to called parties -- users have 527   considerable control over that experience, and similarly for
528   connected identity this must be an opt-in choice for users. = ; In
```

Can this be a normative privacy requirement?

 

It's not really pre= scriptive of any bits-on-the-wire protocol behavior =96 this is more text a= bout what sorts of configuration options a user might have on their UA (the= ir phone or whatever), a sort of user experience matter that we don=92t typically give normative guidance for in= my experience at the IETF.



Perhaps we can seperate the user experience part from the opt in part, and = make this stronger.

 

I=92m not really su= re how to do that =96 that is, how we can mandate that you MUST NOT use con= nected identity unless some user experience box has been ticked, because to= do that we=92d need to design the box. What qualifies as an adequate opt-in to permit connected identity? Those sorts = of questions.

 

The nits below are = fixed in the new -06 (along with the normative change above).

 

Thanks,<= /span>

 

Jon Peterson

TransUnion

 



## Nits


### Expand on first use

PSTN, UAS, UAC, SRTP

 

 



```
165   Today, sophisticated adversaries can redirect calls on the PSTN = to
166   destinations other than the intended called party.  For som= e call
```

```
293   This specification introduces another alternative.  When se= nding a
294   "rsp" PASSporT type in a SIP response, a UAS MAY also = include (in
295   Identity header field values) any "div" PASSporTs it r= eceived in the
296   INVITE that initiated this dialog.  Thus, PASSporTs of type= "div" MAY
```

```
370   response has been received from a UAS.  This specification = does not
371   forbid a UAC from sending a CANCEL for its own PASSporT-protecte= d
```

```
406   This is analogous to a situation where SRTP negotiation fails be= cause
407   the keys exchanges at the media layer do not match fingerprints<= br> ```

### Would or might, not both

```
242   While it would might seem attractive to provide identity for fai= lure
243   response codes (4XX, 5XX, 6XX), those explicitly do not form dia= logs
244   or connections, and are thus outside the scope of this specifica= tion.
```

### sunny-day

Consider "basic" or "primary" alternatives which improv= e comprehension for international readers.

```
252   numbers are the identifiers used by the caller and callee. = For
253   sunny-day use cases, a PASSporT in a 183 or 200 OK should be
254   sufficient to secure media keys for the purposes of SIPBRANDY 255   [RFC8862].
```

```
495   However, the complexity of this mechanism makes it impractical t= o
496   deploy for both the "sunny day" use case and the diver= sion use case
```

### a different

```
307   received in a dialog-forming request with aidfferent "dest&= quot; value
```

### non normative may

```
309   used in responses. "div" is not universally supported,= so calls may
310   be retargeted without generating a "div" PASSporT, in = which case the
311   use of "rsp" PASSporTs will not be possible.  Not= e that the decision
312   to trust any "div" or "rsp" PASSporT is, as = always in STIR, a matter
313   of local policy of the relying parties: some stricter systems ma= y not
314   want to trust any "rsp" that differs from the "de= st" in the PASSporT
315   of the original request.
```

Consider changing a few lower case "may" to "might" for= better clarity here.

 

The =94may not want= to trust=94 is again not bits-on-the-wire behavior but a policy decision = =96 but the first MAY in =93so calls may be=94 that should be normative.



### extra sent

```
367   Identity header with a PASSporT.  However, CANCEL requests = can also
368   sent be sent by stateful proxy servers engaged in parallel forki= ng;
```

### automata vs automated system

The word "automata" appears twice, where "automated system&q= uot; might improve comprehension for international readers.

### his/their contributions

```
506   We would like to thank Russ Housley and Jonathan Rosenberg for h= is
507   contribution to this specification.
```

Regards,

OS, ART AD

--_000_CO6PR17MB4978B4C974AB1CD829015FC0FD432CO6PR17MB4978namp_--