Re: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation

Jack Rickard <jack.rickard@microsoft.com> Tue, 26 October 2021 15:09 UTC

Return-Path: <jack.rickard@microsoft.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 E65513A128C for <stir@ietfa.amsl.com>; Tue, 26 Oct 2021 08:09:33 -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, DKIMWL_WL_HIGH=-0.001, 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, 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=microsoft.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 ssFdW5tt7OAA for <stir@ietfa.amsl.com>; Tue, 26 Oct 2021 08:09:28 -0700 (PDT)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on20714.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e1b::714]) (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 9D3F13A0A2C for <stir@ietf.org>; Tue, 26 Oct 2021 08:09:17 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KyA5oBe1TVIRpmFtU9oknyx5MJAR0pcdiQaIwpuMkeeX5rL5gTeWUFl1gsjNzE8nm1MuJrgpiqn51daNlX3PtGlacAqAXfaNO/p5s7qR7rS8Ln0U3SjfLVw+3BPo/H7we44QeStzYBnqT/tWDh8fMcIg19dm35CDwweID0AIRxsWebiCj0Uax+z3Bwq8SCdu4QUOUlBFQ394sZq2agIgcStDvGxwoFvcFmWj5DM9Z6VVLDJ/yp/I6kkj0PXPxN2reeevKmIr91/WP1Uhuwg4++0klDiInnbmhp0Gi7io02fDOasP0qdCj9mHuVQ+Yg3VmbI7UJXT53EELMcY8EfpyA==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dNK9xGxCNVQ8Q0KS286LCI8cv++0SHSnA8X6aoBl60s=; b=I3hi0RtOX8HsrYGoifHB9NJkyzmduOkH44mOhRGkrvLx6Sh/CDTiaeUNarmlA7OqwgKDNPr+4qxLAZlsnNNdE62/FeIMGP+PfWH0m2VsAlhFMhjVO87NUONwlKITQxC8gfAH3uNlP1JQDXLIct5TBzatHViz8IdQ3ktkoJJto8oj1bjcwxgpeRs6nmkUzI5InPFrrJOYCDXMnNiSdUgqrxGMeXXuexbzkPwXpvcS6riUvst1LsbbyHLVkW2gnYBY+AxQHdgD5F88uybcaopEL6EqlkkwsFE7phtvjfUM9fPUm8Oo7srBlyJkTMZyunbHqZaO7l3TPPXDF2n5S+BbFA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dNK9xGxCNVQ8Q0KS286LCI8cv++0SHSnA8X6aoBl60s=; b=YnniIcdDsfmY7RmsQrcRXIWNZdklohOGoFJcsNlvjHO2WYiTNMZB+LxUOO8TqCZeC5c5FWKkWLCg+mHZhasiyKiFYVMF1CCetYYApuw7tiHL7q6Z1ANIaj79z2vuwpGIsuvPDLV38z6FZFmDK3Zm7JFVHbfL2yOZdmecp4POwRk=
Received: from AM5PR83MB0355.EURPRD83.prod.outlook.com (2603:10a6:206:25::24) by AS8PR83MB0504.EURPRD83.prod.outlook.com (2603:10a6:20b:291::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.2; Tue, 26 Oct 2021 15:09:13 +0000
Received: from AM5PR83MB0355.EURPRD83.prod.outlook.com ([fe80::349b:ab5e:ec0f:629b]) by AM5PR83MB0355.EURPRD83.prod.outlook.com ([fe80::349b:ab5e:ec0f:629b%7]) with mapi id 15.20.4649.001; Tue, 26 Oct 2021 15:09:13 +0000
From: Jack Rickard <jack.rickard@microsoft.com>
To: Ben Campbell <ben@nostrum.com>, Alec Fenichel <alec.fenichel@transnexus.com>
CC: Chris Wendt <chris-ietf@chriswendt.net>, IETF STIR Mail List <stir@ietf.org>, Russ Housley <housley@vigilsec.com>
Thread-Topic: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation
Thread-Index: AdfKeyxX4m09LbUfSi+mAJ1snaJ1Tg==
Date: Tue, 26 Oct 2021 15:09:01 +0000
Deferred-Delivery: Tue, 26 Oct 2021 15:08:20 +0000
Message-ID: <AM5PR83MB0355F58CA54E96326129DCD688849@AM5PR83MB0355.EURPRD83.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=d7cc5647-f1eb-458d-bd7a-3db52e37a8d5; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-10-26T14:57:05Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=microsoft.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 008b2611-73f4-4198-811d-08d998929260
x-ms-traffictypediagnostic: AS8PR83MB0504:
x-microsoft-antispam-prvs: <AS8PR83MB0504237133AB97F339FC727B88849@AS8PR83MB0504.EURPRD83.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:2803;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 91bmZ7UinqQvgjMIP2iJ4wm5XYbhoyPwo5FqS0GrJF/oN9j1eOc1hkAsBtpHyQTdVBPxgjUrPEftRf7ke6raFnnLbzZmSxfRxTyhEQ13Jo4oMI+h9KBCZ6EDWZCakaaQBCpJPcBTf4t4ydRyhp2Lmqqlwrglp2KAuuRzpmJY/DTxINqu+jG3/jtEBxzwo1pG7+SKI6/rHuj381unEThoAof3Oz1idmb5WFVlEtEmcznnGW5Wakjvt7ENveCA4zsdX7pTlwA2XwyEtKtFKYhq1ZGZXiBS3t75Mzi97Tj9E5lMjmwXuHO6p2qDkRfOPqVAZKVL8xEYjehk4PK03B2eBxtH+2nQM6iGB/XwNhkP/M5bpgfX/968EJY/6oHmAkclxGBQVr9G95sy9kk04+IQ7E7emb2AYtLr1FHk8wpsoi6s/Vot3NnAIVjpXgeGSf108tEIgB/THcn8eiJTSFl7MTaaWM7hTfogdW7LvxKNsPMbBBYca0K13ijYB/MwLpgQVxXZjBv25/zFWutFCHfJLd+h3FnA8M10xN76DDYZT2VBkLYPhqrhyzGHT09yRkT+Q8iZ/YxzyOLYFQ4PfCIJlR9NHseziEdl2Xwtt5MHfUJirNH8RQp5MdWvPsr0HCfHq1wTMicbzYoVtPwT+6Lv93XG5On3Mw5b2T4NFqaYTTWPByQ8A4xSCYmiUehlPg/nLuNGw/XqCU45ZDMt41z940P6UhQtG+8tCy3Y4dptzcfyZS4FXKmVJIcyEj5rK20oH//8dP/26Xbnkgp8FT2OoIggsyXfqDBQcWKenjRT6qM=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM5PR83MB0355.EURPRD83.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(2906002)(122000001)(44832011)(8936002)(33656002)(66556008)(10290500003)(38070700005)(64756008)(30864003)(52536014)(66476007)(71200400001)(66446008)(38100700002)(66574015)(9686003)(166002)(110136005)(8676002)(186003)(54906003)(83380400001)(966005)(6666004)(86362001)(316002)(8990500004)(508600001)(4326008)(66946007)(76116006)(53546011)(82960400001)(6506007)(82950400001)(7696005)(5660300002)(55016002)(40140700001)(559001)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: WNhXCZKmvBpIi6HzWYxrzYMSSydx+atmbJquMAQV2Mt2fRii6cRyMe2+83FCJzzFCLmF20ZGqTZzocZPvbdD5RcCp7qsjXCcNjI1uoUUywCYh7KjdWwYG8m7tk11pOwrU+6lZRkPWoybEoy2TDlfHYximtDGVH18U0/RyCfIgiLvqvV5JsWCjnJhzOfdl662DGT91L+Z1Dvr9pInNpjenu4qHBQHgHEU8Y/GR1cPOFa2G8CZE2YoRgwdXg66mVyGqeYHXitoFEela+lgpjbwYY6E0qr2ihpjx7X9jsGmrMHeyCwZJ7+dwKP1A5AHTZIykZe67UdnXd2Nrc8ZgLG8FiK9k/+k+0QdMX0iHqb/RDBn0O0L9FL+8DlfciXJpEJLcGZmpgWQPpNoY464bXBM/7sK0nQgJThHROos2QE8Wm/Zpvow3i6cPxJ5aVxGsp+bPC6bRQh4y1UpNwOlb07H3Cz+47NBRoDB+7R9OtIx2sNb/LuzoEjMX9KijdOZ2O6+fcHdfIWIw4KswsGtzoBTPsPFIVfkW1VS1uAVqSnpSMfCdAQ1RzjDbWbFrd/kAWoj0+MKoqIXuR9aWhTRaokWvdSRGFKVfdpPqoTrymIQ2JyvfU/nF8yAJ5KHWxeoA/7wHotWKdjOWTRbyxxW6zq3H6gWNwl86gThdLLxiRlhA89wU/wp6uZi4q3vURQIWqA8+FeEKUSqc4Ht1nQk+vmtxbBss53MZzHEpq1bT9ujn9GiJDFIB1mJHZYr/ROf7o1+aves9UQ3XMTRzZKeYHmKNsO+N4yd5EzRtjUosv4raIIuwZG9ITXcMSvH6QqZsRfu9l0cmjWZDojixLTBGkTT3I2CnwtXB9MAx1OWmkCK2YENNIIEiXFfg+FuY8YwcviYywmYHl12xkJgEes3hZWXQ53bnVrc3jG0aWlXa6xpaBlOZd3EHfZjO93DqhNTKrmIRbc99h8JxUnVZbMQvLscN6uTSHOvPk9EUZewcey18DgH2ni3jmB7N2A7r02BGJ1UH5Ny56G/+/2sKftOevps+iM8cZ6XTg57Lc6cxfE49xtfcsUNl7/ZLQPICwayzg8X4AW6A78Fr70z1JO7dOSMpnBGpLhwCzK6TZKsjxPPZGRkHd5vq5uKQxgv2RuhzMug+82NOKKrBN0x5vQV2ENL5BRwR8B6xd2HN9xj4ajOKQcVvJRzZfgf141XdkSRE38CXAx27lVWPv2ZYrYYuCK44GJKBfSVo4NjX4FYiiZkJvpGMX5nNvr0DDkHYbhuTaj4EToJw6W9ab9h9Pcy9lqo8T1Lhpeaefxkbc1UjnbeJWS2oDEpACdqpCXAEApQs6Z0F/TdSnh5WT2/a+WTvVATporXog+Hax9mQpepedH1QA2v8BdH8Xp6xdHOMZk35fSPFJgwRMZRJJ3j9RRPRe3YlcBe71CghKKFGxaHF2Pa4jJ/CXVIUhmJsbXbzmc2xtvX5FXz/PgNzF0UDCAkPV0+PRlhikGrNutCqGQJe7zURoKpgghlWfvcxxIRRo/2Zk5oFjO9GGaf8BozIEF1FykcGXw2c0u1ufjy0VcklvV/M05pqvT/IGEBaBAsYUPnVvbAr+hrUm/jdSpgDIN6todlTI296Kzu6NfUy4CmY+PIi+Y=
Content-Type: multipart/alternative; boundary="_000_AM5PR83MB0355F58CA54E96326129DCD688849AM5PR83MB0355EURP_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM5PR83MB0355.EURPRD83.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 008b2611-73f4-4198-811d-08d998929260
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2021 15:09:13.6581 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: dSmyXN07TH+NLECgG8+DatzwNynZYQNnc+zb18Bs5hEJLrxip8NADlyOtl5BbDFw97CYhwMJTOGa+uq+wRJVbSUm3qlB/rhzpHC0b4v0NxE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR83MB0504
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/fG64gE3eOoaSKe_9Wp-NvpqDCxk>
Subject: Re: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation
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: Tue, 26 Oct 2021 15:09:34 -0000

I agree that "Any mechanism to convey RCDi must ensure the integrity of the RCDi hash itself", however that's also true of the RCD information itself (especially when rcdi isn't present). draft-ietf-sipcore-callinfo-rcd-02 is adding Call-Info to allow SIP to convey RCD information in a way that isn't at all protected, and if it passes on that information without the rcdi digests then there's no way to validate the contents of the dereferenced URL. My assumption that the point of the sipcore draft was to allow passing the RCD information internally, in a secure environment.

Jack

From: Ben Campbell <ben@nostrum.com>
Sent: 26 October 2021 15:52
To: Alec Fenichel <alec.fenichel@transnexus.com>; Jack Rickard <jack.rickard@microsoft.com>
Cc: Chris Wendt <chris-ietf@chriswendt.net>; IETF STIR Mail List <stir@ietf.org>; Russ Housley <housley@vigilsec.com>
Subject: [EXTERNAL] Re: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation

(as individual)

If I understand the question correctly, my knee-jerk reaction is to disagree.  Any mechanism to convey RCDi mustensure the integrity of the RCDi hash itself. We've standardized that with RCDi passports. If people want some other, nonstandard way of conveying it, that is up to them.

It would not surprise me to see 3GPP and/or IP-NNI come up with some verstat-like mechanism to say "I've already verified this so you don't have to", and presume a secure transport path to the recipient's UA. But that's not something we should standardize (or even encourage) in STIR.

Ben.


On Oct 26, 2021, at 9:29 AM, Alec Fenichel <alec.fenichel@transnexus.com<mailto:alec.fenichel@transnexus.com>> wrote:

Jack, I think so.

Sincerely,

Alec Fenichel
Senior Software Architect
alec.fenichel@transnexus.com<mailto:alec.fenichel@transnexus.com>
+1 (407) 760-0036
TransNexus

From: Jack Rickard <jack.rickard@microsoft.com<mailto:jack.rickard@microsoft.com>>
Date: Tuesday, October 26, 2021 at 08:01
To: Alec Fenichel <alec.fenichel@transnexus.com<mailto:alec.fenichel@transnexus.com>>, Ben Campbell <ben@nostrum.com<mailto:ben@nostrum.com>>, Chris Wendt <chris-ietf@chriswendt.net<mailto:chris-ietf@chriswendt.net>>
Cc: IETF STIR Mail List <stir@ietf.org<mailto:stir@ietf.org>>, Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>>
Subject: RE: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation
On a slightly separate note, does this mean that draft-ietf-sipcore-callinfo-rcd-02 needs to include a mechanism for forwarding rcdi information?

Jack

From: stir <stir-bounces@ietf.org<mailto:stir-bounces@ietf.org>> On Behalf Of Jack Rickard
Sent: 26 October 2021 11:42
To: Alec Fenichel <alec.fenichel@transnexus.com<mailto:alec.fenichel@transnexus.com>>; Ben Campbell <ben@nostrum.com<mailto:ben@nostrum.com>>; Chris Wendt <chris-ietf@chriswendt.net<mailto:chris-ietf@chriswendt.net>>
Cc: IETF STIR Mail List <stir@ietf.org<mailto:stir@ietf.org>>; Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>>
Subject: [EXTERNAL] Re: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation

I don't think the text in draft-ietf-stir-passport-rcd-14 agrees with what's been said here, for reference, here's the whole section:

9.1.  Verification rules

   A PASSporT that uses claims defined in this specification, in order
   to have a successful verification outcome, MUST conform to the
   following:

   *  abide by all rules set forth in the proper construction of the
      claims

   *  abide by JWT Claims Constraint rules defined in [RFC8226]
      Section 8 or extended in [I-D.ietf-stir-enhance-rfc8226] if
      present in the certificate used to sign the PASSporT

   *  pass integrity verification using "rcdi" if present.

   Consistent with the verification rules of PASSporTs more generally
   [RFC8225], if any of the above criteria is not met, the PASSporT
   verification should be considered a failed verification for all
   claims in the PASSporT.

   In some middle box scenarios, a relying party may not have the need
   to validate content that is referenced by URIs (e.g. only wanting to
   validate base PASSporT info like "orig" and "dest" or other "rcd"
   info like "nam" or "apn").  In these scenarios, this proceedure while
   not considered a full verification, can be performed without
   verifying the full integrity checks of URI referenced content.

I agree that RCDi verification must be separate from RCD passport verification for this to all make sense to implementors. From what's been discussed I'd expect this section to say something for along these lines:

9.1.  Verification rules

   A PASSporT that uses claims defined in this specification, in order
   to have a successful verification outcome, MUST conform to the
   following:

   *  abide by all rules set forth in the proper construction of the
      claims

   *  abide by JWT Claims Constraint rules defined in [RFC8226]
      Section 8 or extended in [I-D.ietf-stir-enhance-rfc8226] if
      present in the certificate used to sign the PASSporT

   Consistent with the verification rules of PASSporTs more generally
   [RFC8225], if any of the above criteria is not met, the PASSporT
   verification should be considered a failed verification for all
   claims in the PASSporT.

   If the "rcdi" claim exists, any party that dereferences a URI from
   the "rcd" claim MUST perform integrity validation of the content
   against the corresponding digest. Consequently, if "rcd" information
   is passed to another entity, the "rcdi" information MUST also be
   included. An entity that does not otherwise need to dereference a URI
   from the "rcd" claim SHOULD NOT dereference the URI solely to perform
   integrity verification.

The voice and tenses are a bit of a mess in there but hopefully it conveys the idea.

Jack

From: Alec Fenichel <alec.fenichel@transnexus.com<mailto:alec.fenichel@transnexus.com>>
Sent: 25 October 2021 23:46
To: Ben Campbell <ben@nostrum.com<mailto:ben@nostrum.com>>; Chris Wendt <chris-ietf@chriswendt.net<mailto:chris-ietf@chriswendt.net>>
Cc: Jack Rickard <jack.rickard@microsoft.com<mailto:jack.rickard@microsoft.com>>; IETF STIR Mail List <stir@ietf.org<mailto:stir@ietf.org>>; Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>>
Subject: [EXTERNAL] Re: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation

I like Ben's proposal: separate STI-VS verification (PASSporT, certificate, claim constraints, etc.) from integrity verification.

Sincerely,

Alec Fenichel
Senior Software Architect
alec.fenichel@transnexus.com<mailto:alec.fenichel@transnexus.com>
+1 (407) 760-0036
TransNexus

From: Ben Campbell <ben@nostrum.com<mailto:ben@nostrum.com>>
Date: Monday, October 25, 2021 at 18:42
To: Chris Wendt <chris-ietf@chriswendt.net<mailto:chris-ietf@chriswendt.net>>, Alec Fenichel <alec.fenichel@transnexus.com<mailto:alec.fenichel@transnexus.com>>
Cc: Jack Rickard <jack.rickard@microsoft.com<mailto:jack.rickard@microsoft.com>>, IETF STIR Mail List <stir@ietf.org<mailto:stir@ietf.org>>, Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>>
Subject: Re: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation
i wonder if we would be better off treating this as two separate procedures:

1) RCD passport verification - Verify of the passport signature, verify any claim constraints, and verify that the "orig" claim value is encompassed by the TnAuthList extension. This is completely independent of RCDi verification. The VS MUST do all of this.

2) RCDi verification - Any RCD mentioned in an RCDi claim MUST NOT be used without first verifying the associated hash. RCDi verification is a separate operation from passport verification. But it is dependent on passport verification, since it's pointless to verify the RCDi hashes without first verifying the passport signature.

Then if IP-NNI wants to translate these into SHAKEN requirements, the can do so.

Thanks!

Ben.


On Oct 25, 2021, at 4:47 PM, Chris Wendt <chris-ietf@chriswendt.net<mailto:chris-ietf@chriswendt.net>> wrote:

HI Alec,

Yeah i actually agree, but i think that's the point, we want those details to be in a separate spec, if needed.  But i would also caution about specifying local policy too prescriptively as well.

-Chris

On Oct 25, 2021, at 4:48 PM, Alec Fenichel <alec.fenichel@transnexus.com<mailto:alec.fenichel@transnexus.com>> wrote:

Hey Chris,

I don't feel that after reading the proposed text an originating service provider would properly implement verification. Maybe further details should be added in IP-NNI not here, but I think they need to be somewhere.

Sincerely,

Alec Fenichel
Senior Software Architect
alec.fenichel@transnexus.com<mailto:alec.fenichel@transnexus.com>
+1 (407) 760-0036
TransNexus

From: Chris Wendt <chris-ietf@chriswendt.net<mailto:chris-ietf@chriswendt.net>>
Date: Monday, October 25, 2021 at 14:27
To: Jack Rickard <jack.rickard@microsoft.com<mailto:jack.rickard@microsoft.com>>
Cc: Alec Fenichel <alec.fenichel@transnexus.com<mailto:alec.fenichel@transnexus.com>>, Ben Campbell <ben@nostrum.com<mailto:ben@nostrum.com>>, IETF STIR Mail List <stir@ietf.org<mailto:stir@ietf.org>>, Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>>
Subject: Re: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation
I will be submitting a new draft very soon, but here is the paragraph i added to the verification section (without modifying the existing text)  Hopefully this is a good compromise, I sort of think it is and captures what everyone has been discussing, but let me know.

-Chris

"In some middle box scenarios, a relying party may not have the need to validate content that is referenced by URIs (e.g. only wanting to validate base PASSporT info like "orig" and "dest" or other "rcd" info like "nam" or "apn"). In these scenarios, this proceedure while not considered a full verification, can be performed without verifying the full integrity checks of URI referenced content."


On Oct 25, 2021, at 1:38 PM, Jack Rickard <jack.rickard=40microsoft.com@dmarc.ietf.org<mailto:jack.rickard=40microsoft.com@dmarc.ietf.org>> wrote:

I'd also lean towards SHOULD NOT, for the same reasons. Anyone who wants to check the digests is only going to cause harm unless they are in a very odd situation.

Jack

From: stir <stir-bounces@ietf.org<mailto:stir-bounces@ietf.org>> On Behalf Of Alec Fenichel
Sent: 25 October 2021 17:41
To: Ben Campbell <ben@nostrum.com<mailto:ben@nostrum.com>>
Cc: IETF STIR Mail List <stir@ietf.org<mailto:stir@ietf.org>>; Jack Rickard <jack.rickard=40microsoft.com@dmarc.ietf.org<mailto:jack.rickard=40microsoft.com@dmarc.ietf.org>>; Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>>
Subject: Re: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation

Ben,

I am flexible on the strength of the language in the spec. I just think we need to be very clear in the spec that the OSP verifying the integrity is all but useless. Resources are going to be cached. I would expect that just like certificates, the cache hit ratio will be extremely high (we see 99.99%+). So it is likely that one or both parties are just checking their cached copy of the resources, not the actual resources. So the OSP checking that the integrity matches does not indicate that it will match when the dereferencing entity checks the integrity.



> I think some of the big OSPs might choose not to send RCD claims at all if they cannot fully verify them at the time of transmission.

This check provides a false sense of security not any actual security. I just think we need to make sure that is understood.



> Local policy? Again, I suspect some operators will have a local policy of "send nothing I can't be sure of", even if that means "don't send the other parts that might be fine."

They can't be sure of it even if they check. Again, I think it is important that we make sure everyone understands that the OSP checking does not mean, or even imply, it will match when the dereferencing entity checks.



> No expectation to dereference is different than an expectation not to dereference. I support the former, not the latter, at least in the IETF spec.

I'm good with either so long as we make it clear what checking the integrity accomplishes (or in the OSP case, does not accomplish).



> But in any case, I'm not going to die on this hill. I prefer 'MAY, or even just not saying anything. But If others want "SHOULD NOT", I can live with it.

If we just say that the OSP MAY check, then this may be interpreted as something that is optional but provides better security, which it does not. So if we say MAY, then I think it is important to explain how checking doesn't accomplish anything.


Sincerely,

Alec Fenichel
Senior Software Architect
alec.fenichel@transnexus.com<mailto:alec.fenichel@transnexus.com>
+1 (407) 760-0036
TransNexus

From: Ben Campbell <ben@nostrum.com<mailto:ben@nostrum.com>>
Date: Monday, October 25, 2021 at 12:10
To: Alec Fenichel <alec.fenichel@transnexus.com<mailto:alec.fenichel@transnexus.com>>
Cc: Jack Rickard <jack.rickard=40microsoft.com@dmarc.ietf.org<mailto:jack.rickard=40microsoft.com@dmarc.ietf.org>>, IETF STIR Mail List <stir@ietf.org<mailto:stir@ietf.org>>, Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>>
Subject: Re: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation
Hi, see inline:

On Oct 25, 2021, at 10:45 AM, Alec Fenichel <alec.fenichel@transnexus.com<mailto:alec.fenichel@transnexus.com>> wrote:

I think SHOULD NOT is what we want.

What happens if the integrity check fails? I would argue the OSP should still send it downstream including inserting it into their "shaken" PASSporT. So dereferencing the resources just adds post dial delay if the outcome of checking the integrity doesn't change the expected behavior.

I think some of the big OSPs might choose not to send RCD claims at all if they cannot fully verify them at the time of transmission. I recognize that is not ideal from an end-to-end trust model for RCD and delegate certs, but the current status quo is OSPs don't send RCDl, and I get the impression that some operators are nervous about the idea of doing it in the first place.

I do suspect that, when they fully understand the cost of verifying RCDi for every call, they will choose not to do so. But I think that is their choice to make,



Also, there could be a dozen resources (logos of various sizes). What if one of them failed to download (server 404) but the rest worked? How do you handle a partial failure? I think we want to avoid having to address this scenario.

Local policy? Again, I suspect some operators will have a local policy of "send nothing I can't be sure of", even if that means "don't send the other parts that might be fine."


We should make it clear that there is absolutely no expectation that the OSP dereferences the resources. The OSPs simply passes what they receive (assuming all of the other validation checks pass).

No expectation to dereference is different than an expectation not to dereference. I support the former, not the latter, at least in the IETF spec. (I could imagine IP-NNI strengthening the requirement to the latter).

But in any case, I'm not going to die on this hill. I prefer 'MAY, or even just not saying anything. But If others want "SHOULD NOT", I can live with it.

Ben.


Sincerely,

Alec Fenichel
Senior Software Architect
alec.fenichel@transnexus.com<mailto:alec.fenichel@transnexus.com>
+1 (407) 760-0036
TransNexus

From: Ben Campbell <ben@nostrum.com<mailto:ben@nostrum.com>>
Date: Monday, October 25, 2021 at 11:29
To: Alec Fenichel <alec.fenichel@transnexus.com<mailto:alec.fenichel@transnexus.com>>
Cc: Jack Rickard <jack.rickard=40microsoft.com@dmarc.ietf.org<mailto:jack.rickard=40microsoft.com@dmarc.ietf.org>>, IETF STIR Mail List <stir@ietf.org<mailto:stir@ietf.org>>, Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>>
Subject: Re: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation
Do you mean the second sentence to have the strength of a SHOULD NOT? I can imagine an OSP that might prefer not to transmit any RCD content without confirming it is valid at the time of transmission. Perhaps for liability or contractual reasons. Would we want to strongly discourage that, or just leave it as local policy?

One particular use case I can imagine is an OSP that copies RCD claims into it's SHAKEN certificate to be signed with its own credentials. While that might not really require them to verify integrity if they include the RCDi claim, they may well have an aversion to signing something that they haven't completely verified.  (Assuming they don't also rehost the external content as part of this, in which case they would need to verify integrity)

Thanks!

Ben.


On Oct 25, 2021, at 10:18 AM, Alec Fenichel <alec.fenichel@transnexus.com<mailto:alec.fenichel@transnexus.com>> wrote:

Another way of putting it: the entity dereferencing the resource must verify that the resource matches the supplied integrity. The resource should not be dereferenced for the sake of verifying the integrity.

Sincerely,

Alec Fenichel
Senior Software Architect
alec.fenichel@transnexus.com<mailto:alec.fenichel@transnexus.com>
+1 (407) 760-0036
TransNexus

From: stir <stir-bounces@ietf.org<mailto:stir-bounces@ietf.org>> on behalf of Ben Campbell <ben@nostrum.com<mailto:ben@nostrum.com>>
Date: Monday, October 25, 2021 at 11:07
To: Jack Rickard <jack.rickard=40microsoft.com@dmarc.ietf.org<mailto:jack.rickard=40microsoft.com@dmarc.ietf.org>>
Cc: IETF STIR Mail List <stir@ietf.org<mailto:stir@ietf.org>>, Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>>
Subject: Re: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation
(as individual)

I think I agree with you in general. To paraphrase the conclusions:

The VS MUST verify the passport signature and the claim constraints. That verifies that the claim values are correct has signed by the  AS, for example that the value in the rcdi is the correct value. Any party that uses RCD claims that are covered by an rcdi hash MUST verify that hash before trusting that content. Other parties MAY verify it according to local policy.

Does that match your thoughts?

On Oct 20, 2021, at 6:37 AM, Jack Rickard <jack.rickard=40microsoft.com@dmarc.ietf.org<mailto:jack.rickard=40microsoft.com@dmarc.ietf.org>> wrote:

Hi all,

To clarify things, and hopefully reduce the number of rounds of review, this is a write-up of my position (and hopefully some alternative positions) on rcdi validation.

rcdi is a mechanism to ensure the integrity of the rcd information, and so any entity that retrieves/uses the rcd information clearly must validate that information against the rcdi digests, otherwise it could not trust what it had downloaded.

However, any verification service that does not need to retrieve the RCD information, cannot and possibly should not always retrieve and validate it, for a few reasons:

  1.  There isn't enough time - downloading and validating all the data (or in fact any data) takes a prohibitively long time, especially as an intermediate verification service does not know which bits of data are going to be used.
  2.  The data could change - even if an intermediate does perform the validation, the end entity must repeat this as the information it retrieves could very well be different to what the intermediate validated.

  1.  There was discussion in the meeting of a TSP that rehosted the RCD information, in that case it is the end entity in this discussion and realistically needs its own integrity mechanism on what it has rehosted.

  1.  An intermediate could reject something that the end entity would accept - downloading information from the internet is not perfectly reliable, there could be firewall issues, or just temporary server issues that cause an intermediate validator to not be able to get the RCD information, in which case it would fail to validate the passport and throw out all the rcd information (and potentially all the STIR information). An end entity does not have to do this, it might be able to retrieve items the intermediate cannot, it might not want all the information in the first place, and in the worst case it can gracefully degrade the rcd information it cannot access.

Taking all of that, I believe that the rcd and rcdi information should be treated as "valid" in the context of PASSporT verification if the data in the PASSporT is correct (this would include checking JWTClaimConstraints), but not depend on any of the referenced information's integrity.

There is a question there about "/rcd","/nam", and "/apn" digests, for the sake of simplicity I'd suggest they also aren't required to be checked by the verifier, but I don't believe it matters.

There are some issues with this approach though:

  1.  Security is more complicated - this split validation model introduces extra complexity to the security of RCD information in PASSporTs. As far as I can tell, this wouldn't introduce any new attack vectors, but does place a greater burden on the end entity doing things correctly.
  2.  This introduces a new entity - I don't believe any previous documents have made a distinction between the end entity and verification services, just focusing on authentication services and verification services. This introduces actions that this end entity must perform for the system to conform to the standard.


Those issues are not enough to change my mind; however, I welcome different opinions and there are almost certainly more I haven't thought of or weren't discussed.

Thanks,
Jack Rickard
he/him
Software Engineer
jack.rickard@microsoft.com<mailto:jack.rickard@microsoft.com>

[Image removed by sender.]<Picture (Device Independent Bitmap) 1.jpg>




_______________________________________________
stir mailing list
stir@ietf.org<mailto:stir@ietf.org>
https://www.ietf.org/mailman/listinfo/stir<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Cjack.rickard%40microsoft.com%7C0f537df9aadd4b0efb9108d998904023%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637708567708142926%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xl2UbuL9ApodKeiGzp33rh5X13t3SVbxGBW0JkANzR4%3D&reserved=0>

_______________________________________________
stir mailing list
stir@ietf.org<mailto:stir@ietf.org>
https://www.ietf.org/mailman/listinfo/stir<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Cjack.rickard%40microsoft.com%7C0f537df9aadd4b0efb9108d998904023%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637708567708152927%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jbn%2F%2FFrcMH8MU1RC9LMFU3C%2FW2sCGUfNBevnwWdx4eY%3D&reserved=0>