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

Chris Wendt <chris-ietf@chriswendt.net> Mon, 13 September 2021 18:58 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 8A4EC3A1505 for <stir@ietfa.amsl.com>; Mon, 13 Sep 2021 11:58:04 -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 cgnjwqKy1TZU for <stir@ietfa.amsl.com>; Mon, 13 Sep 2021 11:57:59 -0700 (PDT)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 BE37A3A1503 for <stir@ietf.org>; Mon, 13 Sep 2021 11:57:58 -0700 (PDT)
Received: by mail-qt1-x82f.google.com with SMTP id r21so9017940qtw.11 for <stir@ietf.org>; Mon, 13 Sep 2021 11:57:58 -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=I3CRowtNQVCcEVTo76d5r/rGzc9+BYzoIJ6Qgy87Dxo=; b=BppQpz2UfmbmCMGXIL0djWQfgvq6UPIjNY66LP+0OC5eseNHpBcgyQThJJllKxgQMc JzkT8qBYckWbPNYO591QIWPIwMHmd31B2paacPk/4q1II2aNCHmcnkTpD7NgWu2cjLjt cygL2bRyAeEDK93iemkbjmkjBkvPxd6ensXHIv0PAjsjNBlE6KWjjIGwQCeyBAN3dA7i L5CoEJnxKGMH3kD9ngo1wWoCG9a/E5DS7QbsXQXqGuZoyjA5/ibqdv+USu+5g4fhNx2l ccYOW13WnUrshJiNYs4bEAia6JyMIdqmvzIInswxqIgAxLkLNcr7me5b3cQf9Ld13C2t dSCw==
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=I3CRowtNQVCcEVTo76d5r/rGzc9+BYzoIJ6Qgy87Dxo=; b=XstTx1jtcBaOZqAXZtZ4AnwmYdOG1JNr/EnhuH1BoepTARDG5c6hCqGEXS/If8DTt1 Et/cdUGHEHNfaLuu6HtTffhCxm2wS2Lk4o1ezwRh9CCbvHvGv+lx7uug8YnKkJvuWeB3 bKc0cboijAu+vgXvb4vawmBxkuOJUGt7OK3Osn1fsQZvkHcluD7SaDhN3AD4NQ00aYz+ PMolq8erfPCTPWe6sQ12qfNHNL9HJ+pmK0uuQvzeV7KtY0Fq8P5nAmUhtUgx+Kz6gjfv YUbYqTbYVClwAUifNmcubJ+7G7EuvqoYuSt/3p7e8TXpHV8ZhPtwT5yCHQRXsxWUE+aQ lV6w==
X-Gm-Message-State: AOAM531JQTMI5fDOUki3Dnl9I48Wv0YJlBpqijJSYGLqYEzJca8c5i27 EHHIie1PRHHcL1fP2MO55jthHg==
X-Google-Smtp-Source: ABdhPJxphN5OAaHAQdSBCnWPCcvSkJUw2OifG+466XOUYR8U5DW0gUBVV41kk5p+Y9lNakj/Gabh0Q==
X-Received: by 2002:a05:622a:1792:: with SMTP id s18mr1044438qtk.136.1631559476381; Mon, 13 Sep 2021 11:57:56 -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 q10sm6100813qke.108.2021.09.13.11.57.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Sep 2021 11:57:56 -0700 (PDT)
From: Chris Wendt <chris-ietf@chriswendt.net>
Message-Id: <B529284B-BE1A-4449-BA1E-653C469CE9DE@chriswendt.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E7D96024-7DA8-45EB-B323-1FCB77BD6D62"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Mon, 13 Sep 2021 14:57:54 -0400
In-Reply-To: <E4CE716F-5F95-448F-A7E1-FE6E23E8A4F4@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> <A379DF26-1BE5-4F05-AE55-AC9F232F75AA@chriswendt.net> <098930EF-0969-412E-ADB5-BDADC0E5F0E4@nostrum.com> <36324285-573A-4EE3-899D-EA87653B668D@chriswendt.net> <E4CE716F-5F95-448F-A7E1-FE6E23E8A4F4@nostrum.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/MVsdH2dhR-l64r5EqtsxzTG2Q8o>
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 18:58:05 -0000


> On Sep 13, 2021, at 2:52 PM, Ben Campbell <ben@nostrum.com> wrote:
> 
> 
> 
>> On Sep 13, 2021, at 1:47 PM, Chris Wendt <chris-ietf@chriswendt.net <mailto:chris-ietf@chriswendt.net>> wrote:
>> 
>> inline
>> 
>>> On Sep 13, 2021, at 10:41 AM, Ben Campbell <ben@nostrum.com <mailto:ben@nostrum.com>> wrote:
>>> 
>>> 
>>> 
>>>> On Sep 13, 2021, at 7:36 AM, Chris Wendt <chris-ietf@chriswendt.net <mailto: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.)
>> 
>> Ok, that clarifies the use-case, but i think i still would like to stay a level higher. Focus on the security (and integrity) and not give excuses for half-steps or “optimizations”.  If the “identity” includes RCD information with integrity turned on encoded in a PASSporT, you should have to decode the entire PASSporT to achieve pass/fail. Otherwise, we get into some thorny scenarios, IMHO.
>> Like i said before (even though i misunderstood your use-case), I think you provide one example on how the industry might implement this, but i could imagine others.  But, however things turn out, i don’t think we should change the fundamental rules of we have already established or create shortcuts in the protocol specifications.  RCD is fundamentally not about “A” attestation, although as we have said it’s a side benefit, that said, i would hate to cripple things for a shortcut or potentially create a hole.
>> 
> 
> Just to be clear, I agree we should stay at a higher level in the spec. I think from a higher level, the rules that would allow the use case I mentioned would be to say something like the VS MUST verify the signature and that any JWT Claim Constraints are satisfied, and MUST NOT rely on integrity-protected RCD claims without verifying the rcdi claim.
> 
> I’m perfectly okay if the answer is still “verify everything or rely on nothing”; I’m just probing to make sure we have considered how this will be used in practice.

Right, understood, I think the integrity was included for a specific purpose, one that is a non-trivial part of the overall “identity” of the caller so it should still be considered in verification. Open to hearing others opinion and we can discuss in few minutes, but i don’t want to give up on that lightly :)  But, as you said, good to talk about it explicitly, so glad you are bringing it forward.

> 
> Thanks!
> 
> Ben.