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

Ben Campbell <ben@nostrum.com> Mon, 13 September 2021 14:41 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 8AF0D3A08E5 for <stir@ietfa.amsl.com>; Mon, 13 Sep 2021 07:41:25 -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 2d1RLwZSVAXF for <stir@ietfa.amsl.com>; Mon, 13 Sep 2021 07:41:20 -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 BE5DB3A08E1 for <stir@ietf.org>; Mon, 13 Sep 2021 07:41:20 -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 18DEfGps083156 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 13 Sep 2021 09:41:16 -0500 (CDT) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1631544077; bh=RwsoFa7v5hULDL1wN9nA55T7mVWal7bMz8ksvSKiNZM=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=WUZVTp4CHVTJVKGhF1GVH0CPA340Tm4rZ5Wy4W5040vuex6W5XhY2saMN75u6VE0E 5EEzfdBCF3R9s6LAl7kEkfBjom/WjrMSM9vMs7aZhqN/k12+yd5f/RdY4GL2Nm8M5y cHxof9K4GIYg9aPDVjq2Kb9jfGgLYO36Bb2Upvlc=
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: <098930EF-0969-412E-ADB5-BDADC0E5F0E4@nostrum.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0E465E9C-7664-4B56-9AC0-D251F04151AF"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Mon, 13 Sep 2021 09:41:10 -0500
In-Reply-To: <A379DF26-1BE5-4F05-AE55-AC9F232F75AA@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> <76B3F052-BB10-4C49-BEBE-6F062542AC10@nostrum.com> <A379DF26-1BE5-4F05-AE55-AC9F232F75AA@chriswendt.net>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/5IByxmH7y4uoEGBCbq8q-DRKgOw>
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: Mon, 13 Sep 2021 14:41:26 -0000


> On Sep 13, 2021, at 7:36 AM, Chris Wendt <chris-ietf@chriswendt.net> wrote:
> 
>>> 
>>> 
>>>> 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.
>> 
>> […]
> 
> RFC8225 does have the rule that you can ignore claims you don’t understand, and i think for ’shaken’ specifically, we don’t have a PASSporT extension type that includes both ’shaken’ claims and ‘rcd’ claims, even though people have talked about putting both in a single PASSporT, so i think we are ok.  I just feel uncomfortable trying to “cross the streams” and cover other extension types in this spec. Would we expect all future specs to cover every combination of claims/extension types?  I still think that is left for IPNNI type specs to define more specific usage.
> 
> Put more simply, this spec is about “rcd” PASSporT rules, using “rcd” claims in another PASSporT type is not in scope for this spec.
> 

Unless I misunderstand what people have in mind, the use case doesn’t involve mixing rcd and shaken claims in a single PPT. To be more precise:

1. Caller AS signs an passport with a delegate cert. with “ppt” : “rcd”. It includes an RCD claim with external references, and therefore an “rcdi” claim.
2. OSP VS verifies the RCD passport and checks that the “orig” claim is encompassed by the cert's TnAuthList. It wants to ignore the RCD claims because it doesn’t care about them, but IIUC it cannot ignore them because of the “rcd” value in “ppt”.
3. OSP AS inserts a SHAKEN passport, with an attestation level (hopefully A), based on the results of step 2.
4. OSP forwards the INVITE with both the SHAKEN and RCD passport.

The way I understand things, step 2 will require verification of the rcdi claim, and therefore downloading of the external content. Am I missing something? 

I think this means the caller is using the same passport for two purposes (authentication, RCD assertion) with two separate relying parties (OSP, TSP or recipient), Is this an invalid approach? I’m willing to accept that one should not do this, but I think it will surprise some consumers of the spec. I recognize this is not the only approach people are thinking about (e.g. the OSP might verify the RCD claims and insert them into its SHAKEN ppt.)

Thanks!

Ben.