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

Chris Wendt <chris-ietf@chriswendt.net> Mon, 13 September 2021 12:36 UTC

Return-Path: <chris-ietf@chriswendt.net>
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 B5DF43A0B26 for <stir@ietfa.amsl.com>; Mon, 13 Sep 2021 05:36:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 Fr8rAKMdtn87 for <stir@ietfa.amsl.com>; Mon, 13 Sep 2021 05:36:51 -0700 (PDT)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 1F0493A0B20 for <stir@ietf.org>; Mon, 13 Sep 2021 05:36:51 -0700 (PDT)
Received: by mail-qk1-x734.google.com with SMTP id t4so10201501qkb.9 for <stir@ietf.org>; Mon, 13 Sep 2021 05:36:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=9SP4oTFHyPjeAoq/LqxSOgAQPkjP1hTQwKs8zHW6a9k=; b=V0qhpt6dUeuT6lzLjvxWJ8TjvQQ95frPTDK6mvYa+72we/zF6w7e8PwRg7c7lKbbhW 5EQ2Ryf1CNorQEbMx9oHkeArfL1/u626sLQNdZgGoLZUl2JrP95jksVXHHX5Nwq6/8Vu wnHWTn5FWm5EVtmIp7BEqLIgeX/cZrEThyPAnynfcDacNAQQr8PuyGrad1rChrFqjbdD YlxkfCy9TrM9knN9JoJ9JKAEGt8D2Dw9uU+o5vn9gYCdtdLsCzRMM3MYIlbGVC0QJSFI vyKmGlMn1UokH7HcNzQekDmym9XqVjvMLU4cORt7Ps6zvz+yGFXfS5zoYx6RBpiOuo7Q Vj8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=9SP4oTFHyPjeAoq/LqxSOgAQPkjP1hTQwKs8zHW6a9k=; b=z/mShe/Az0KtYEAV2Sd9MJyyhIv+RIVpp5EccghvNAOr3bwAqmojZmSNxTfHhJ8+sx NrojgwG9TP/yTW8hk0oteaWiB60pJLqqpR4SJFcVeL2zN53d7jIXYQG+YArGXBibqAPN OjokrLcqHaRyk6Oou5e9ht+NvM5Qimek9+E+JuY6h+HDV+1kqWmZvOWARoumeuEcsnng WBvKhRqZJWjTVh3WCUK847Hc4jKYoYqRMRPyyg9V2mzUkP7iC0cJNbLDbGYi/xmvbOvV 1Fl6627l9GSwsgP5+zTACdOsHZArr66nJDxBzXZgLqZcpd3mnZtM6Vo+F/dONKbOVaO+ IA8w==
X-Gm-Message-State: AOAM531nWISoEGVEKUIDNhta5sl7FJtV358UrFp07r/CV6pyZn3tJ4Fu 1VKBl8jWHr+MZI2P0YRi2AV1vr/6AjtlcYqE
X-Google-Smtp-Source: ABdhPJzrkebBU0Cobx2d3Ae6eQdX/l6C1tJkjiFXfvhaEJ/kLeukrkHVAinHnsDwXBh1hCxxSwDCTQ==
X-Received: by 2002:a37:9581:: with SMTP id x123mr9593406qkd.477.1631536608978; Mon, 13 Sep 2021 05:36:48 -0700 (PDT)
Received: from smtpclient.apple (c-69-242-46-71.hsd1.pa.comcast.net. [69.242.46.71]) by smtp.gmail.com with ESMTPSA id i14sm4023887qtr.2.2021.09.13.05.36.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Sep 2021 05:36:48 -0700 (PDT)
From: Chris Wendt <chris-ietf@chriswendt.net>
Message-Id: <A379DF26-1BE5-4F05-AE55-AC9F232F75AA@chriswendt.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_816C63AB-409E-4030-BA7F-6215256A1EA9"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Mon, 13 Sep 2021 08:36:47 -0400
In-Reply-To: <76B3F052-BB10-4C49-BEBE-6F062542AC10@nostrum.com>
Cc: Jon Peterson <jon.peterson@team.neustar>, IETF STIR Mail List <stir@ietf.org>
To: Ben Campbell <ben@nostrum.com>
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>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/6mdMhwWxKrq-fJaRmspU_qwDZHU>
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 12:36:57 -0000

Inline

> On Sep 11, 2021, at 6:39 PM, Ben Campbell <ben@nostrum.com> wrote:
> 
> 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 <mailto: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.

Yeah, thanks, changed it to this format to make it a little clearer:
"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.  "

> 
>> 
>>> 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.

> 
>>> 
>>> §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.)
> 
> […]

Changed wording to 

6.2
"For the third mode described in the integrity overview section of this document, where only JWT Claim Constraint for "rcd" claims without an "rcdi" claim is required, the procedure should be when creating the certificate and the intent is to always include an "rcd" claim, to include a JWT Claim Constraint on inclusion of an "rcd" claim with the intended values required to be constrained by the certificate used to sign the PASSporT.

The "permittedValues" for the "rcd" claim may optionally contain multiple entries, to support the case where the certificate holder is authorized to use different sets of rich call data.

Only including "permittedValues" for "rcd" provides the ability to either have no "rcd" claim or only the set of constrained "permittedValues" values for an included "rcd" claim.”

8.1

“If the intent of the issuer of the certificate is to always including a call reason, a "mustInclude" for the "crn" claim indicates that a "crn" claim must be present."

> 
>