Re: [stir] I-D Action: draft-ietf-stir-passport-rcd-15.txt

[Jack Rickard <[e-mail]>]

Woops, I'd completely forgotten about the "iss" part of this standard, re-reading it I do think that solves all of this. I'd like the "Verification Service behaviour" section to mention that if "iss" exists then it can't treat this passport as asserting the identity, but that's a readability concern more than anything else.

From: Peterson, Jon <jon.peterson=[e-mail]>
Sent: 20 April 2022 13:37
To: Jack Rickard <[e-mail]>; Chris Wendt <[e-mail]>
Cc: IETF STIR Mail List <[e-mail]>
Subject: Re: [stir] I-D Action: draft-ietf-stir-passport-rcd-15.txt

Currently intermediaries are not able to add RCD passports: RFC 8224 Section 6.1 states "The authentication service MUST then determine whether or not the originator of the request is authorized to claim the identity given in the identity field.  In order to do so, the authentication service MUST authenticate the originator of the message.". As that clause applies to all passports, is not overridden by anything in the RCD spec, and intermediaries will not be able to authenticate the caller, they are not allowed to authenticate the caller. (I believe this issue affects RPH too). For intermediaries to be able to put RCD passports on a call that section must be overridden in the RCD standard.

It was overridden by the "div" spec (and as you say probably the "rph" spec), let alone the "rcd" spec. "div" PASSports are still PASSporTs, and they don't have this requirement. The entire "third-party usage" section of the "rcd" spec is quite clear that the intention of "rcd" PASSporTs in the third-party case is not to authenticate the original user. I'm not sure any further text is needed to "overwrite" RFC8224 here.

For a more concrete scenario as to why this is a problem:
Imagine an ecosystem where shaken passports are not required to authenticate a call, base passports are considered enough to say "I, <credential>, have authenticated the caller and they are allowed to use this identity" (I'm pretty sure this is compliant with RFC 8224). If you are an intermediary who has a credential that everyone trusts for everything, then you cannot put an RCD passport on the call, if you did then the callee would think that you are asserting that the caller is allowed to use the identity even though you have no idea if that's the case!

If I recall the basic idea for intermediary "rcd" usage was that the "iss" field, if present in the JWT header, differentiated PASSporTs that were not intended to assert the identity of the caller from those that were (combined of course with the "rcd" PPT). I guess I view "iss" PASSporTs as sort of like "div" PASSporTs, which again would not be naively mistaken for PASSporTs generated by the RFC8224 6.1 rules to assert who someone is - just like with "div", you need a separate PASSporT asserting the calling number for an "iss" PASSporT to be usable by relying parties. The further backstop against mistakenly treating this as an RFC8224 PASSporT is the signing certificate itself.

That said, I agree that the language in the second paragraph of 15 is too strong regarding JWT Claim Constraints - though it doesn't seem to be normative.

Jon Peterson
Neustar, Inc. (a TransUnion company)