Subject: [stir] Malformed PASSporTs

From: Jack Rickard <[email-masked]>
Date: Fri, 14 Jan 2022 16:28:18 +0000

Hi all,

What's the intended behaviour of a verification service when it encounters a PASSporT with badly formed claims, but is otherwise valid?

There's a progression of possibilities here which range from being able to do nothing to being entirely ignorable. I'm worried there are interop or security issues I haven't thought of with being maximally permissive.

  1.  Fundamental field totally invalid

"orig": [2]

It's impossible to validate this passport no matter how lenient you are as there's no way to verify this against the From header.

  1.  Fundamental field partially invalid

"dest": { "tn": ["12345556789"], "uri": 6 }

Theoretically you could validate this passport if the INVITE was to 12345556789, however processing this would be awkward, and for the sake of the ecosystem it may be better to reject it.

  1.  Extra field invalid

"ppt": "rph", "rph": "invalid"

This is not a useable RPH passport but could degrade to a base passport and provide some authority. RPH may be a bad example because I'm not sure it's meant to attest to the caller, however if the ppt field was malformed you wouldn't know that...

  1.  Optional field invalid

"ppt": "shaken", "rcd": {}

The field isn't mandatory, nor is it the primary focus of this passport. Ignoring the "rcd" field would do very little harm, bar allowing dodgy implementations to proliferate.

  1.  Unnecessary non-STIR field invalid

"aud": 6

I doubt many STIR implementations even check if non-STIR fields exist, let alone whether they have the right type. Completely ignoring this feels like the right thing to do, however rejecting it would also be reasonable, if everyone agreed.

Although, not checking this specific field is in violation of the JWT standard, so maybe this should be rejected?

  1.  Completely unexpected field

"foo": "bar"

AS this is JSON I'm pretty sure this should be accepted and ignored.

I haven't been able to find much in the standards addressing this, so I'm interested to know your opinions. I've been unable to come to much of an opinion myself, being permissive feels sensible, but could have negative effects on the ecosystem and generally raises more questions than answers. Being draconian is probably simplest, but could cause interop problems, especially as things change.

Thanks,
Jack Rickard
he/him
Software Engineer
[email-masked]<mailto:[email-masked]>

[Microsoft Logo]

---

From: Alec Fenichel <[email-masked]>
Date: Fri, 14 Jan 2022 19:33:19 +0000

As an implementer, I generally prefer being permissive about unknown fields and draconian about known fields. Put another way, we are looking for specific fields. We expect these fields to follow the required format. If they don’t, we will reject the PASSporT. If there are extra fields that we aren’t explicitly looking for, they are completely ignored, so they can be invalid. Note “rcd” is a known field, it doesn’t matter what the ppt is, if you include “rcd”, it needs to be properly formatted.

Sincerely,

Alec Fenichel

Senior Software Architect

[email-masked]

+1 (407) 760-0036

TransNexus

From: stir <[email-masked]> on behalf of Jack Rickard <jack.rickard=[email-masked]>
Date: Friday, January 14, 2022 at 11:29
To: IETF STIR Mail List <[email-masked]>
Subject: [stir] Malformed PASSporTs

Hi all,

What’s the intended behaviour of a verification service when it encounters a PASSporT with badly formed claims, but is otherwise valid?

There’s a progression of possibilities here which range from being able to do nothing to being entirely ignorable. I’m worried there are interop or security issues I haven’t thought of with being maximally permissive.

Fundamental field totally invalid

“orig”: [2]

It’s impossible to validate this passport no matter how lenient you are as there’s no way to verify this against the From header.

Fundamental field partially invalid

“dest”: { “tn”: [“12345556789”], “uri”: 6 }

Extra field invalid

“ppt”: ”rph”, “rph”: “invalid”

This is not a useable RPH passport but could degrade to a base passport and provide some authority. RPH may be a bad example because I’m not sure it’s meant to attest to the caller, however if the ppt field was malformed you wouldn’t know that…

Optional field invalid

“ppt”: “shaken”, “rcd”: {}

The field isn’t mandatory, nor is it the primary focus of this passport. Ignoring the “rcd” field would do very little harm, bar allowing dodgy implementations to proliferate.

Unnecessary non-STIR field invalid

“aud”: 6

Completely unexpected field

“foo”: “bar”

AS this is JSON I’m pretty sure this should be accepted and ignored.

I haven’t been able to find much in the standards addressing this, so I’m interested to know your opinions. I’ve been unable to come to much of an opinion myself, being permissive feels sensible, but could have negative effects on the ecosystem and generally raises more questions than answers. Being draconian is probably simplest, but could cause interop problems, especially as things change.

Thanks,

Jack Rickard
he/him
Software Engineer
[email-masked]

---

From: Chris Wendt <[email-masked]>
Date: Tue, 18 Jan 2022 17:04:50 -0500

Hi Jack,

Generally, we do have MUST level requirements for the defined claims in RFC8225, for example, MUST be canonicalized according to RFC8224 for “orig".  And as you point out, if there is claim keys that aren’t defined or are not understood by the implementation they should be ignored.
Let me look specifically at all of your cases and see if there is anything missing, but above is the general intent.  Note that SHAKEN specs to provide additional guidance, but this is above and beyond the basics of JSON rules and the specific claim guidance.

-Chris

> On Jan 14, 2022, at 11:28 AM, Jack Rickard <jack.rickard=[email-masked]> wrote:
> 
> Hi all,
>  
> [email-masked] <mailto:[email-masked]> 
> 
>  
>  
> _______________________________________________
> stir mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>

---

From: Chris Wendt <[email-masked]>
Date: Tue, 18 Jan 2022 17:06:05 -0500

Yeah i think Alec, you have captured the general intent. 

> On Jan 14, 2022, at 2:33 PM, Alec Fenichel <alec.fenichel=[email-masked]> wrote:
> 
> [email-masked] <mailto:[email-masked]>
> +1 (407) 760-0036
> TransNexus
>  
> From: stir <[email-masked] <mailto:[email-masked]>> on behalf of Jack Rickard <jack.rickard=[email-masked] <mailto:jack.rickard=[email-masked]>>
> To: IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>
> <image001[37].png>