Subject: Re: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation

From: Ben Campbell <[email-masked]>
Date: Thu, 11 Nov 2021 17:29:53 -0600

Apologies for the late reply—I’m catching up on old email.

On reflection, I can see reasons to have a SIP native way to convey integrity, especially since we know that at least some voice SPs are likely to verify the passport in-network then pass RCD to the recipient device via native SIP header fields. I suspect there would be some complexity in mapping directly between that and rcdi, if we want to do that. Especially if there are more than one piece of external content that needs protecting.

But it seems like this is at least partly a SIPCORE discussion?

Thanks!

Ben.

> On Oct 26, 2021, at 3:02 PM, Chris Wendt <[email-masked]> wrote:
> 
> Hi Ben,
> 
> Yes that was the intent, as is probably already well-known the authors and others prefer keeping the RCD PASSporT in the chain as far as possible, but if you are in a “trusted zone” in your network and feel like you can pass things without signatures and integrity, that is your option, however in these times, the “trusted zone” in networks is getting less and less trusted so you milage may vary with whether these things pass modern security policies and best practices. ;)
> 
> -Chris
> 
>> On Oct 26, 2021, at 10:52 AM, Ben Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> (as individual)
>> 
>> If I understand the question correctly, my knee-jerk reaction is to disagree.  Any mechanism to convey RCDi mustensure the integrity of the RCDi hash itself. We’ve standardized that with RCDi passports. If people want some other, nonstandard way of conveying it, that is up to them.
>> 
>> It would not surprise me to see 3GPP and/or IP-NNI come up with some verstat-like mechanism to say “I’ve already verified this so you don’t have to”, and presume a secure transport path to the recipient's UA. But that’s not something we should standardize (or even encourage) in STIR.
>> 
>> Ben.
>> 
>> 
>>> On Oct 26, 2021, at 9:29 AM, Alec Fenichel <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Jack, I think so.
>>>  
>>> Sincerely,
>>>  
>>> Alec Fenichel
>>> Senior Software Architect
>>> [email-masked] <mailto:[email-masked]>
>>> +1 (407) 760-0036
>>> TransNexus
>>>  
>>> From: Jack Rickard <[email-masked] <mailto:[email-masked]>>
>>> Date: Tuesday, October 26, 2021 at 08:01
>>> To: Alec Fenichel <[email-masked] <mailto:[email-masked]>>, Ben Campbell <[email-masked] <mailto:[email-masked]>>, Chris Wendt <[email-masked] <mailto:[email-masked]>>
>>> Cc: IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>, Russ Housley <[email-masked] <mailto:[email-masked]>>
>>> Subject: RE: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation
>>> 
>>> On a slightly separate note, does this mean that draft-ietf-sipcore-callinfo-rcd-02 needs to include a mechanism for forwarding rcdi information?
>>>  
>>> Jack
>>>  
>>> From: stir <[email-masked] <mailto:[email-masked]>> On Behalf Of Jack Rickard
>>> Sent: 26 October 2021 11:42
>>> To: Alec Fenichel <[email-masked] <mailto:[email-masked]>>; Ben Campbell <[email-masked] <mailto:[email-masked]>>; Chris Wendt <[email-masked] <mailto:[email-masked]>>
>>> Cc: IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>; Russ Housley <[email-masked] <mailto:[email-masked]>>
>>> Subject: [EXTERNAL] Re: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation
>>>  
>>> I don’t think the text in draft-ietf-stir-passport-rcd-14 agrees with what’s been said here, for reference, here’s the whole section:
>>>  
>>> 9.1.  Verification rules
>>>  
>>>    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.
>>>  
>>>    Consistent with the verification rules of PASSporTs more generally
>>>    [RFC8225], if any of the above criteria is not met, the PASSporT
>>>    verification should be considered a failed verification for all
>>>    claims in the PASSporT.
>>>  
>>>    In some middle box scenarios, a relying party may not have the need
>>>    to validate content that is referenced by URIs (e.g. only wanting to
>>>    validate base PASSporT info like "orig" and "dest" or other "rcd"
>>>    info like "nam" or "apn").  In these scenarios, this proceedure while
>>>    not considered a full verification, can be performed without
>>>    verifying the full integrity checks of URI referenced content.
>>>  
>>> I agree that RCDi verification must be separate from RCD passport verification for this to all make sense to implementors. From what’s been discussed I’d expect this section to say something for along these lines:
>>>  
>>> 9.1.  Verification rules
>>>  
>>>    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
>>>  
>>>    Consistent with the verification rules of PASSporTs more generally
>>>    [RFC8225], if any of the above criteria is not met, the PASSporT
>>>    verification should be considered a failed verification for all
>>>    claims in the PASSporT.
>>>  
>>>    If the "rcdi" claim exists, any party that dereferences a URI from
>>>    the "rcd" claim MUST perform integrity validation of the content
>>>    against the corresponding digest. Consequently, if "rcd" information
>>>    is passed to another entity, the "rcdi" information MUST also be
>>>    included. An entity that does not otherwise need to dereference a URI
>>>    from the "rcd" claim SHOULD NOT dereference the URI solely to perform
>>>    integrity verification.
>>>  
>>> The voice and tenses are a bit of a mess in there but hopefully it conveys the idea.
>>>  
>>> Jack
>>>  
>>> From: Alec Fenichel <[email-masked] <mailto:[email-masked]>> 
>>> Sent: 25 October 2021 23:46
>>> To: Ben Campbell <[email-masked] <mailto:[email-masked]>>; Chris Wendt <[email-masked] <mailto:[email-masked]>>
>>> Cc: Jack Rickard <[email-masked] <mailto:[email-masked]>>; IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>; Russ Housley <[email-masked] <mailto:[email-masked]>>
>>> Subject: [EXTERNAL] Re: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation
>>>  
>>> I like Ben’s proposal: separate STI-VS verification (PASSporT, certificate, claim constraints, etc.) from integrity verification.
>>>  
>>> Sincerely,
>>>  
>>> Alec Fenichel
>>> Senior Software Architect
>>> [email-masked] <mailto:[email-masked]>
>>> +1 (407) 760-0036
>>> TransNexus
>>>  
>>> From: Ben Campbell <[email-masked] <mailto:[email-masked]>>
>>> Date: Monday, October 25, 2021 at 18:42
>>> To: Chris Wendt <[email-masked] <mailto:[email-masked]>>, Alec Fenichel <[email-masked] <mailto:[email-masked]>>
>>> Cc: Jack Rickard <[email-masked] <mailto:[email-masked]>>, IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>, Russ Housley <[email-masked] <mailto:[email-masked]>>
>>> Subject: Re: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation
>>> 
>>> i wonder if we would be better off treating this as two separate procedures:
>>>  
>>> 1) RCD passport verification - Verify of the passport signature, verify any claim constraints, and verify that the “orig” claim value is encompassed by the TnAuthList extension. This is completely independent of RCDi verification. The VS MUST do all of this.
>>>  
>>> 2) RCDi verification - Any RCD mentioned in an RCDi claim MUST NOT be used without first verifying the associated hash. RCDi verification is a separate operation from passport verification. But it is dependent on passport verification, since it’s pointless to verify the RCDi hashes without first verifying the passport signature.
>>>  
>>> Then if IP-NNI wants to translate these into SHAKEN requirements, the can do so.
>>>  
>>> Thanks!
>>>  
>>> Ben.
>>>  
>>>  
>>> On Oct 25, 2021, at 4:47 PM, Chris Wendt <[email-masked] <mailto:[email-masked]>> wrote:
>>>  
>>> HI Alec,
>>>  
>>> Yeah i actually agree, but i think that’s the point, we want those details to be in a separate spec, if needed.  But i would also caution about specifying local policy too prescriptively as well.
>>>  
>>> -Chris
>>>  
>>> 
>>> On Oct 25, 2021, at 4:48 PM, Alec Fenichel <[email-masked] <mailto:[email-masked]>> wrote:
>>>  
>>> Hey Chris,
>>>  
>>> I don’t feel that after reading the proposed text an originating service provider would properly implement verification. Maybe further details should be added in IP-NNI not here, but I think they need to be somewhere.
>>>  
>>> Sincerely,
>>>  
>>> Alec Fenichel
>>> Senior Software Architect
>>> [email-masked] <mailto:[email-masked]>
>>> +1 (407) 760-0036
>>> TransNexus
>>>  
>>> From: Chris Wendt <[email-masked] <mailto:[email-masked]>>
>>> Date: Monday, October 25, 2021 at 14:27
>>> To: Jack Rickard <[email-masked] <mailto:[email-masked]>>
>>> Cc: Alec Fenichel <[email-masked] <mailto:[email-masked]>>, Ben Campbell <[email-masked] <mailto:[email-masked]>>, IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>, Russ Housley <[email-masked] <mailto:[email-masked]>>
>>> Subject: Re: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation
>>> 
>>> I will be submitting a new draft very soon, but here is the paragraph i added to the verification section (without modifying the existing text)  Hopefully this is a good compromise, I sort of think it is and captures what everyone has been discussing, but let me know.  
>>>  
>>> -Chris
>>>  
>>> "In some middle box scenarios, a relying party may not have the need to validate content that is referenced by URIs (e.g. only wanting to validate base PASSporT info like "orig" and "dest" or other "rcd" info like "nam" or "apn"). In these scenarios, this proceedure while not considered a full verification, can be performed without verifying the full integrity checks of URI referenced content."
>>>  
>>> 
>>>  
>>> 
>>> On Oct 25, 2021, at 1:38 PM, Jack Rickard <jack.rickard=[email-masked] <mailto:jack.rickard=[email-masked]>> wrote:
>>>  
>>> I’d also lean towards SHOULD NOT, for the same reasons. Anyone who wants to check the digests is only going to cause harm unless they are in a very odd situation.
>>>  
>>> Jack 
>>>  
>>> From: stir <[email-masked] <mailto:[email-masked]>> On Behalf Of Alec Fenichel
>>> Sent: 25 October 2021 17:41
>>> To: Ben Campbell <[email-masked] <mailto:[email-masked]>>
>>> Cc: IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>; Jack Rickard <jack.rickard=[email-masked] <mailto:jack.rickard=[email-masked]>>; Russ Housley <[email-masked] <mailto:[email-masked]>>
>>> Subject: Re: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation
>>>  
>>> Ben,
>>>  
>>> I am flexible on the strength of the language in the spec. I just think we need to be very clear in the spec that the OSP verifying the integrity is all but useless. Resources are going to be cached. I would expect that just like certificates, the cache hit ratio will be extremely high (we see 99.99%+). So it is likely that one or both parties are just checking their cached copy of the resources, not the actual resources. So the OSP checking that the integrity matches does not indicate that it will match when the dereferencing entity checks the integrity.
>>>  
>>>  
>>>  
>>> > I think some of the big OSPs might choose not to send RCD claims at all if they cannot fully verify them at the time of transmission.
>>>  
>>> This check provides a false sense of security not any actual security. I just think we need to make sure that is understood.
>>>  
>>>  
>>>  
>>> > Local policy? Again, I suspect some operators will have a local policy of “send nothing I can’t be sure of”, even if that means “don’t send the other parts that might be fine."
>>>  
>>> They can’t be sure of it even if they check. Again, I think it is important that we make sure everyone understands that the OSP checking does not mean, or even imply, it will match when the dereferencing entity checks.
>>>  
>>>  
>>>  
>>> > No expectation to dereference is different than an expectation not to dereference. I support the former, not the latter, at least in the IETF spec.
>>>  
>>> I’m good with either so long as we make it clear what checking the integrity accomplishes (or in the OSP case, does not accomplish).
>>>  
>>>  
>>>  
>>> > But in any case, I’m not going to die on this hill. I prefer ‘MAY, or even just not saying anything. But If others want “SHOULD NOT”, I can live with it.
>>>  
>>> If we just say that the OSP MAY check, then this may be interpreted as something that is optional but provides better security, which it does not. So if we say MAY, then I think it is important to explain how checking doesn’t accomplish anything.
>>>  
>>>  
>>> Sincerely,
>>>  
>>> Alec Fenichel
>>> Senior Software Architect
>>> [email-masked] <mailto:[email-masked]>
>>> +1 (407) 760-0036
>>> TransNexus
>>>  
>>> From: Ben Campbell <[email-masked] <mailto:[email-masked]>>
>>> Date: Monday, October 25, 2021 at 12:10
>>> To: Alec Fenichel <[email-masked] <mailto:[email-masked]>>
>>> Cc: Jack Rickard <jack.rickard=[email-masked] <mailto:jack.rickard=[email-masked]>>, IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>, Russ Housley <[email-masked] <mailto:[email-masked]>>
>>> Subject: Re: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation
>>> 
>>> Hi, see inline:
>>>  
>>> 
>>> On Oct 25, 2021, at 10:45 AM, Alec Fenichel <[email-masked] <mailto:[email-masked]>> wrote:
>>>  
>>> I think SHOULD NOT is what we want.
>>>  
>>> What happens if the integrity check fails? I would argue the OSP should still send it downstream including inserting it into their “shaken” PASSporT. So dereferencing the resources just adds post dial delay if the outcome of checking the integrity doesn’t change the expected behavior.
>>>  
>>> I think some of the big OSPs might choose not to send RCD claims at all if they cannot fully verify them at the time of transmission. I recognize that is not ideal from an end-to-end trust model for RCD and delegate certs, but the current status quo is OSPs don’t send RCDl, and I get the impression that some operators are nervous about the idea of doing it in the first place.
>>>  
>>> I do suspect that, when they fully understand the cost of verifying RCDi for every call, they will choose not to do so. But I think that is their choice to make,
>>>  
>>>  
>>> 
>>>  
>>> Also, there could be a dozen resources (logos of various sizes). What if one of them failed to download (server 404) but the rest worked? How do you handle a partial failure? I think we want to avoid having to address this scenario.
>>>  
>>> Local policy? Again, I suspect some operators will have a local policy of “send nothing I can’t be sure of”, even if that means “don’t send the other parts that might be fine."
>>>  
>>>  
>>> We should make it clear that there is absolutely no expectation that the OSP dereferences the resources. The OSPs simply passes what they receive (assuming all of the other validation checks pass).
>>>  
>>> No expectation to dereference is different than an expectation not to dereference. I support the former, not the latter, at least in the IETF spec. (I could imagine IP-NNI strengthening the requirement to the latter). 
>>>  
>>> But in any case, I’m not going to die on this hill. I prefer ‘MAY, or even just not saying anything. But If others want “SHOULD NOT”, I can live with it.
>>>  
>>> Ben.
>>>  
>>> 
>>>  
>>> Sincerely,
>>>  
>>> Alec Fenichel
>>> Senior Software Architect
>>> [email-masked] <mailto:[email-masked]>
>>> +1 (407) 760-0036
>>> TransNexus
>>>  
>>> From: Ben Campbell <[email-masked] <mailto:[email-masked]>>
>>> Date: Monday, October 25, 2021 at 11:29
>>> To: Alec Fenichel <[email-masked] <mailto:[email-masked]>>
>>> Cc: Jack Rickard <jack.rickard=[email-masked] <mailto:jack.rickard=[email-masked]>>, IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>, Russ Housley <[email-masked] <mailto:[email-masked]>>
>>> Subject: Re: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation
>>> 
>>> Do you mean the second sentence to have the strength of a SHOULD NOT? I can imagine an OSP that might prefer not to transmit any RCD content without confirming it is valid at the time of transmission. Perhaps for liability or contractual reasons. Would we want to strongly discourage that, or just leave it as local policy? 
>>>  
>>> One particular use case I can imagine is an OSP that copies RCD claims into it's SHAKEN certificate to be signed with its own credentials. While that might not really require them to verify integrity if they include the RCDi claim, they may well have an aversion to signing something that they haven’t completely verified.  (Assuming they don’t also rehost the external content as part of this, in which case they would need to verify integrity)
>>>  
>>> Thanks!
>>>  
>>> Ben.
>>>  
>>>  
>>> 
>>> On Oct 25, 2021, at 10:18 AM, Alec Fenichel <[email-masked] <mailto:[email-masked]>> wrote:
>>>  
>>> Another way of putting it: the entity dereferencing the resource must verify that the resource matches the supplied integrity. The resource should not be dereferenced for the sake of verifying the integrity.
>>>  
>>> Sincerely,
>>>  
>>> Alec Fenichel
>>> Senior Software Architect
>>> [email-masked] <mailto:[email-masked]>
>>> +1 (407) 760-0036
>>> TransNexus
>>>  
>>> From: stir <[email-masked] <mailto:[email-masked]>> on behalf of Ben Campbell <[email-masked] <mailto:[email-masked]>>
>>> Date: Monday, October 25, 2021 at 11:07
>>> To: Jack Rickard <jack.rickard=[email-masked] <mailto:jack.rickard=[email-masked]>>
>>> Cc: IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>, Russ Housley <[email-masked] <mailto:[email-masked]>>
>>> Subject: Re: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation
>>> 
>>> (as individual)
>>>  
>>> I think I agree with you in general. To paraphrase the conclusions:
>>>  
>>> The VS MUST verify the passport signature and the claim constraints. That verifies that the claim values are correct has signed by the  AS, for example that the value in the rcdi is the correct value. Any party that uses RCD claims that are covered by an rcdi hash MUST verify that hash before trusting that content. Other parties MAY verify it according to local policy.
>>>  
>>> Does that match your thoughts?
>>>  
>>> 
>>> On Oct 20, 2021, at 6:37 AM, Jack Rickard <jack.rickard=[email-masked] <mailto:jack.rickard=[email-masked]>> wrote:
>>>  
>>> Hi all,
>>>  
>>> To clarify things, and hopefully reduce the number of rounds of review, this is a write-up of my position (and hopefully some alternative positions) on rcdi validation.
>>>  
>>> rcdi is a mechanism to ensure the integrity of the rcd information, and so any entity that retrieves/uses the rcd information clearly must validate that information against the rcdi digests, otherwise it could not trust what it had downloaded.
>>>  
>>> However, any verification service that does not need to retrieve the RCD information, cannot and possibly should not always retrieve and validate it, for a few reasons:
>>> There isn’t enough time – downloading and validating all the data (or in fact any data) takes a prohibitively long time, especially as an intermediate verification service does not know which bits of data are going to be used.
>>> The data could change – even if an intermediate does perform the validation, the end entity must repeat this as the information it retrieves could very well be different to what the intermediate validated.
>>> There was discussion in the meeting of a TSP that rehosted the RCD information, in that case it is the end entity in this discussion and realistically needs its own integrity mechanism on what it has rehosted.
>>> An intermediate could reject something that the end entity would accept – downloading information from the internet is not perfectly reliable, there could be firewall issues, or just temporary server issues that cause an intermediate validator to not be able to get the RCD information, in which case it would fail to validate the passport and throw out all the rcd information (and potentially all the STIR information). An end entity does not have to do this, it might be able to retrieve items the intermediate cannot, it might not want all the information in the first place, and in the worst case it can gracefully degrade the rcd information it cannot access.
>>>  
>>> Taking all of that, I believe that the rcd and rcdi information should be treated as “valid” in the context of PASSporT verification if the data in the PASSporT is correct (this would include checking JWTClaimConstraints), but not depend on any of the referenced information’s integrity.
>>>  
>>> There is a question there about “/rcd”,”/nam”, and “/apn” digests, for the sake of simplicity I’d suggest they also aren’t required to be checked by the verifier, but I don’t believe it matters.
>>>  
>>> There are some issues with this approach though:
>>> Security is more complicated – this split validation model introduces extra complexity to the security of RCD information in PASSporTs. As far as I can tell, this wouldn’t introduce any new attack vectors, but does place a greater burden on the end entity doing things correctly.
>>> This introduces a new entity – I don’t believe any previous documents have made a distinction between the end entity and verification services, just focusing on authentication services and verification services. This introduces actions that this end entity must perform for the system to conform to the standard.
>>>  
>>>  
>>> Those issues are not enough to change my mind; however, I welcome different opinions and there are almost certainly more I haven’t thought of or weren’t discussed.
>>>  
>>> Thanks,
>>> Jack Rickard 
>>> he/him 
>>> Software Engineer 
>>> [email-masked] <mailto:[email-masked]> 
>>> 
>>> <Picture (Device Independent Bitmap) 1.jpg>
>>>  
>>>  
>>>  
>>>  
>>> _______________________________________________
>>> stir mailing list
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/stir <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Calec.fenichel%40transnexus.com%7C657ab0ca495c4561cd6608d9987864d4%7C8e2972a2d21d49acb00518e8ceaadee3%7C0%7C0%7C637708465167795668%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yexkgq4aFWM24AHNafnnvnsO0a9M6RX1xFkMGGyc484%3D&reserved=0>
>>>  
>>> _______________________________________________
>>> stir mailing list
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/stir <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Calec.fenichel%40transnexus.com%7C657ab0ca495c4561cd6608d9987864d4%7C8e2972a2d21d49acb00518e8ceaadee3%7C0%7C0%7C637708465167805660%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FAQqrqCVupCh8BZGLsjjW1jW5Fts74UqaRiWNkKzU3c%3D&reserved=0>
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir