Re: [stir] Third WGLC: draft-ietf-stir-passport-rcd-12

Ben Campbell <ben@nostrum.com> Sat, 11 September 2021 22:40 UTC

Return-Path: <ben@nostrum.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 E29833A12D4 for <stir@ietfa.amsl.com>; Sat, 11 Sep 2021 15:40:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.279
X-Spam-Level:
X-Spam-Status: No, score=-0.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, MAY_BE_FORGED=1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 gYEqrqxoXe5t for <stir@ietfa.amsl.com>; Sat, 11 Sep 2021 15:40:08 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BCF83A12D2 for <stir@ietf.org>; Sat, 11 Sep 2021 15:40:06 -0700 (PDT)
Received: from smtpclient.apple (mta-70-120-133-87.satx.rr.com [70.120.133.87] (may be forged)) (authenticated bits=0) by nostrum.com (8.17.1/8.16.1) with ESMTPSA id 18BMdw8x058332 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 11 Sep 2021 17:39:59 -0500 (CDT) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1631399999; bh=K3CKGH/Ho4my8ELSBQEl2jrhEGaicDrx9EStZ3XbVGQ=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=oFm9L1INy0T9PKEliXwtrUAnNFW6WG4O1QpEWhEP/xqJtRN2nTNyHKqInjal+MDMK btOLUngHOITGU/9zYQOhkFpCsw1Fc9pf4BLhuHQA3p0MCDUboAYafeD8HPY8u4d8Kk 57uU7grC+QEYrTL5bumc6eiW9tCEGo7c3kg0Od5E=
X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-133-87.satx.rr.com [70.120.133.87] (may be forged) claimed to be smtpclient.apple
From: Ben Campbell <ben@nostrum.com>
Message-Id: <76B3F052-BB10-4C49-BEBE-6F062542AC10@nostrum.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_700BDDF3-5EC8-44BE-B146-5B190840B6BA"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Sat, 11 Sep 2021 17:39:52 -0500
In-Reply-To: <4869F8BC-BF1D-4DB3-B2E0-3047CB41301F@chriswendt.net>
Cc: Jon Peterson <jon.peterson@team.neustar>, IETF STIR Mail List <stir@ietf.org>
To: Chris Wendt <chris-ietf@chriswendt.net>
References: <ACBAF452-EC41-4EAF-8ED1-AFF705671D19@vigilsec.com> <7B072388-9236-4845-996D-1ECE52EC1557@nostrum.com> <4869F8BC-BF1D-4DB3-B2E0-3047CB41301F@chriswendt.net>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/TBX5sJI2tLzHeE62DgMd6sEsB-I>
Subject: Re: [stir] Third WGLC: draft-ietf-stir-passport-rcd-12
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: Sat, 11 Sep 2021 22:40:13 -0000

Hi

Comments inline. I’ve removed sections that don’t seem to need further discussion.

> On Sep 9, 2021, at 7:27 PM, Chris Wendt <chris-ietf@chriswendt.net> wrote:
> 
> HI Ben,
> 
> Thanks for the review!  Comments inline:
> 
>> On Aug 13, 2021, at 6:01 PM, Ben Campbell <ben@nostrum.com <mailto:ben@nostrum.com>> wrote:
>> 

[…]

>> Substantive:
>> 
>> General:
>> 
>> I still have some questions about expected verifier behavior after multiple passes. I think that the verification service discussion should be expanded to address the following:
>> Is a verifier _required_ to verify that all claims are valid according to any JWTClaimConstraints? What does it mean if a given claim violates the constraints? Is the whole ppt considered invalid and discarded? Can relying parties still use parts of the passport that were either not constrained or did not violate the constraints?
>> Same questions for RCDi digest verification.
>> If RCDi digest verification is optional, does that change if there is a claim constraint on it? 
> The simple answer is that we think the entire PASSporT validation should fail if any part of it fails validation either because of signature, JWTConstraint, or rcdi integrity failure.  I will add text to make this clear.

The new text in version 13 is helpful. But it seems to say the passport MUST abide by claim construction rules OR JWT Claim Constraints OR pass integrity verification. Were those meant to be AND?

I also note the new text doesn’t mention signature verification—but I’m willing to believe that goes without saying.

Also see comments below re: SHAKEN use case.

> 
>> For an example use case related to these questions. Imagine a SHAKEN environment, where the caller UA signs an RCD passport with a delegate-certificate. The cert has JWTClaimConstraints for the “rcd” and “rcdi” claims. The UA also includes an rcdi claim, because the “rcd” claim points to an external icon.
>> 
>> The UA forwards the INVITE to an originating service provider (OSP). The OSP doesn’t care what’s in the “rcd” claims. All it wants to do is see that the call is signed with the private key associated with the caller’s certificate and verify that the cert has a TNAuthList extension that encompasses the number in the From header field. If that is true, the OSP adds it’s own SHAKEN passport with full attestation and forwards the INVITE to a Terminating Service Provider (TSP) with both passports.   As far as the OSP is concerned, it’s the TSP’s problem to verify the RCD bits.
>> 
>> Would the OSP be required to verify the JWTClaimConstraints and RCDi digest in this case? Consider that verifying the RCDI digest probably requires downloading an icon from a potentially arbitrary source, which the OSP might not be willing to do.
> 
> I agree that in case of SHAKEN, OSP at a minimum only cares about telephone number for STI-VS and uses the delegate certificate TNAuthList telephone number and ‘orig’/From/Paid to determine attestation level.  That said, i think the mechanics of what OSP or TSP do with a delegate cert is a SHAKEN concept and doesn’t need to be addressed in the ‘rcd’ draft, so i’d prefer to leave that to IPNNI documents.

I agree we should not define SHAKEN semantics in STIR. But I think we need to avoid precluding expected SHAKEN behavior without a good reason.

From the new text in §9.1, I understand that in the example of an RCD PASSporT with an rcdi claim that covers content included by reference, a VS MUST verify the RCDi claim, which requires it to download the external content. At least for “ppt”:“rcd”. And and the AS that inserted the rcd passport MUST include the RCDi claim, due to the external content. 

Am I reading that right? If so, in the SHAKEN OSP example above, do you think it is reasonable to make the OSP download and verify an icon it will never use for potentially every call it processes? I fear that might be a barrier to the idea of an OSP using the TnAuthList from a delegate cert for SHAKEN attestation purposes. At least for RCD passports that reference logos and such.

OTOH, I realize that the idea of a partially-verified passport might be tricky to implement safely, so that nothing downstream of a VS accidentally relies on unverified claims.

[…]

>> 
>> §8.1: Does you envision a use case where one might want to constrain a claim value if it is present, but it’s okay for it to not be present at all?
> 
> Yes, i believe that is handled by not having a “mustInclude” for the claim, but having “permittedValues” for the constrained claim value.

Both section 6.2 and 8.1 say “mustInclude” must be included. (So does 7, but leaving out “mustInclude” probably makes less sense there.)

[…]