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

[Chris Wendt <[e-mail]>]

inline

> On Sep 13, 2021, at 10:41 AM, Ben Campbell <[e-mail]> wrote:
> 
> 
> 
>> On Sep 13, 2021, at 7:36 AM, Chris Wendt <[e-mail] <mailto:[e-mail]>> 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.


> 
> Thanks!
> 
> Ben.
> 
> 
> 
>