Subject: [stir] draft-ietf-stir-identity-header-errors-handling-00 privacy issues

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

Hi all,

As promised (if a bit late), these are the issues I see with the current draft as it relates to privacy.

This error handling mechanism provides a new way for callers to see how a call was diverted (and other potentially sensitive information in passports), this is a privacy issue as highlighted in the diversion RFC, rfc5806 (ietf.org)<https://datatracker.ietf.org/doc/html/rfc5806#section-7>, and the history-info RFC, rfc7044 (ietf.org)<https://datatracker.ietf.org/doc/html/rfc7044#section-10.1> (and who knows what private information may be put in passports in the future).

The current draft attempts to mitigate this issue with section 7:
  Removal of the Reason header field by Authentication Service

   When an Authentication Service [RFC8224] receives the Reason header
   field with a PASSporT it generated as part of an Identity header
   field and the authentication of a call, it should first follow local
   policy to recognize and acknowledge the error (e.g. perform
   operational actions like logging or alarming), but then MUST remove
   the identified Reason header field to avoid the PASSporT information
   from going upstream to a UAC or UAS that may not be authorized to see
   claim information contained in the PASSporT for privacy or other
   reasons.

However, this doesn't work: an intermediary that does not (yet) support this draft would not know to remove their passport from the reason headers, and so the information would be leaked upstream.

The two simplest solutions that I can immediately see are:

  1.  Enforce the use of compact form (potentially only send the signature), this removes all the useful information for anyone who had not seen the passports already.
  2.  Add a flag to the passport/identity indicating that you would like it sent back to you if there was an error with it. That would ensure that only AS's that understood this extension could leak data.

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

[Microsoft Logo]

---

From: Chris Wendt <[email-masked]>
Date: Tue, 18 Jan 2022 16:55:54 -0500

Hi Jack,

I think sticking with compact form (just signature) as key is reasonable, would like other opinions if we think we need a flag for sending entire PASSporT is necessary or not.

-Chris

> On Jan 14, 2022, at 1:25 PM, Jack Rickard <jack.rickard=[email-masked]> wrote:
> 
> Hi all,
>  
> This error handling mechanism provides a new way for callers to see how a call was diverted (and other potentially sensitive information in passports), this is a privacy issue as highlighted in the diversion RFC, rfc5806 (ietf.org) <https://datatracker.ietf.org/doc/html/rfc5806#section-7>, and the history-info RFC,rfc7044 (ietf.org) <https://datatracker.ietf.org/doc/html/rfc7044#section-10.1> (and who knows what private information may be put in passports in the future).
>  
> However, this doesn’t work: an intermediary that does not (yet) support this draft would not know to remove their passport from the reason headers, and so the information would be leaked upstream.
>  
> Enforce the use of compact form (potentially only send the signature), this removes all the useful information for anyone who had not seen the passports already.
> Add a flag to the passport/identity indicating that you would like it sent back to you if there was an error with it. That would ensure that only AS’s that understood this extension could leak data.
>  
>  
> Thanks,
> Jack Rickard 
> he/him 
> Software Engineer 
> [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>