STIR Working Group Interim 13 Sep 2021

Summary

Identity Header Error Handling

Chris Wendt led discussion on the Identity Header Error Handling
draft. Version 02 has extensive changes based on the discussion at
IETF 111. The group agreed that the draft should register a Reason
header field new protocol for "STIR". The update to RFC 3326 to allow
multiple Reason header fields for the same protocol will be separated
into a separate draft in SIPCORE. The working group will consider
adoption of the draft after the next revision.

RCD PASSporTs

Chris also led discussion on RCD PASSporTs. We received good
feedback and have been working through it on the list. This version adds
the "alternate presentation number" (APN) key to the "rcd" claim. This
originally included a prohibition against having both the apn key and a
jCard in the same PASSporT. Discussion concluded that we should remove
that prohibition. There was further discussion about the authority model
for "apn", which was stated to be the same as for other RCD values.

There was extensive discussion of the verification requirements for
rcdi, and whether a failure if the rcdi integrity check invalidates the
PASSporT itself. Discussion leaned towards saying that verification of
rcdi is not required for parties that do not rely on the external
content protected by it, but that relying parties must verify rcdi. This
needs further discussion once the authors propose concrete text.

There was a short discussion about icon formats, with the suggestion
that they use SVG. Any such guidance probably should come from SIPCORE.

Connected Identity

Discussion of connected identity was deferred due to time
constraints. The chairs thank Jon for volunteering to give up this time
in favor of the RCD discussion.

Upcoming Interim meeting

The chairs expect to have another interim meeting the second week of
October 2021 to resolve continued discussion about RCDi, and to discuss
connected identity.

Raw Notes:

Administrivia

• Agenda Bashing - No bashes
• Minute Taker - Jack Rickard
• Jabber Scribe - Not needed
• Bluesheets - Meetecho will provide them

Identity Header Error Handling (Deferred from IETF 111)

• Chris Wendt
• draft-wendt-stir-identity-header-errors-handling
• Discuss open issues; get ready for WG call for adoption

Has been extensively changed since last discussed.

Jon P: Looks good. Might be able to work around the requirement for
different protocol values. e.g. stir-shaken, stir-div, stir-rph etc.
Need to check how protocol values are defined.

Jon P: Might still want to register different protocols per ppt for
clarity.
Jack: Can't do it just by ppt type.
Jon: Worth communicating ppt type.
Robert Sparks: Could just try multiple reason
values with same protocol and see if things break.
Jon: 3326 IANA condiderations allow registering new protocols with an
RFC. That doesn't change whether anything breaks, but it gives us a way
to register different behaviors.
Roman Shpount: We do see multiple Reason headers in the world already.
Jack: Can't have a fixed set of protocols. E.g. might have 2 divs
Chris W: Could register a single protocol (e.g. stir) that allows
multiple Reason headers, just for that protocol.
Robert: Could update 3326 in small doc through SIPCORE. Register
identifiers separately.
Ben: Still have to update 3326?
Chris: yes, if we can quickly send through sipcore.
Jon: May be some utility for registering multiple ppt types, but can't
limit to one reason header per type. Worth registering STIR separately
from SIP. For now just do STIR, and if people want to register more
things they can.

Chris: Should the work group adopt this?

• Russ (as chair): Suggests one more revision cycle, then adopt. Remove
  "updates" and register a protocol identifier for STIR.
• Jack: Clarifies that we still need to update RFC 3326 to allow
  multiple reason header fields with the same protocol
• Russ: Separate draft?
• Robert Sparks: Has already written text for the update for multiple
  reason headers per protocol :P
• (From jabber) Robert working with Roman to turn the following into an
  Internet Draft in SIPCORE:

  "A SIP message MAY contain more than one Reason value (i.e.,
  multiple Reason lines). If the registered protocol for the Reason
  value specifies what it means for multiple values to occur in one
  message, more than one value for that protocol MAY be present.
  Otherwise, the MUST only one be one value per protocol provided
  (e.g., one SIP and another Q.850). An implementation is free to
  ignore Reason values that it does not understand."

Chris: Will submit update from today's feedback, will remove the
"UPDATES 3326" part.

PASSporT Extension for Rich Call Data

• Chris Wendt and Jon Peterson
• draft-ietf-stir-passport-rcd
• Resolve open issues from WG Last Call

Chris: Got good comments. Working through on list. Added new "apn" claim
value for alternate presentation number.
Russ Housley: When would "apn" be used?
Jon P: "nam" was a one-off concession, separate from jcard. Could do
"apn" by making a simple jCard, but "apn" is a common enough usecase
worth having a one-off like "nam".
Jack R: Why is "apn" different to "nam" in that it requires "tel" to not
be in the jCard.
Jon: Make it clear if you are doing jcard for other reason, don't have
shortcuts. What if there is a conflict? Haven't though if same should
apply to "nam"
Alec Fenichel: There's no obvious "nam" equivalent field in jCard.
Jon: Doesn't want to undersell ambiguities.
Chris Wendt: fn (formatted text) property of jCard is similar to nam,
but we haven't defined it that way.
Alec Fenichel: Today we put RCD in SHAKEN ppt. Will take the "nam" value
for PAI. First name, last name, etc combinations in jCards may exceed
length limites, etc. The same might apply with tel, a jCard can have
multiple tel so not clear what to use. "nam" provides an unambigious
statement that this is what we want. apn may be similar.

Russ Housely: Is the PASSporT signer expected to validate the "apn". Are
they authoritative?
Jon Peterson: Yes, but no specific policy.
Jon: May be reasons to include apn with jcard. May be reasons to remove
the restriction.
Alec Fenichel: Number display and name display are standard features, so
having separate name and presentation number fields is useful.
Jack: Name and presentation number have standard ways of presenting to
user already. Worth keeping them unique. Remove restriction obout having
both tel and jCard.
Hala Mowafy: Does the passport vouch that the caller is authorized to
use whatever appears in apn?
Jon P: This is not the network number but is the number that the should
be displayed to the user.
Hala Mowfay: So how do you validate that the originator owns that
telephone number.
Jon: Interaction with JWTConstraints is identical.
Chris: Validated like other RCD information.
Subir Das: Who determines to put the "apn" value in?
Jon P: Whoever creates the passport, probably the OSP. Is tied to the
same trust model as everything else.
Subir Das: Is there a use case where the end user tells the OSP that
they want to use the alternate presentation number?
Chris Wendt: Depends on authority model. Would need to be applied for
and vetted.
Russ Housley: Should add some text to the security considerations to be
clear about this. Don't sign if you don't have confidence in the
information.
Hala Mowafy: Needs to be clear who is vetting authorization to use the
"apn".
Jon P: There are a number of existing standard ways to do this, don't
want to stipulate explicitly.

Chris: List discussion on consistency of rules around constraints, URI
recursion rules. Update hashes

Ben Campbell: The clarified rules on verification state that the
verifier must verify everything, can't half verify a PASSporT. A use
case is an end user AS signs an RCD passport to authenticate themselves
with the OSP and produce RCD info for the call endpoint. Concern is that
OSP has to verify rcdi, which could be slow and require download of
logos. Could put undue burden on OSP. OTOH, partial validation can lead
to confusion.
Alec Fenichel: I view rcdi verification as something that should be done
by the end device that displays it, as that can only verify the stuff
that it needs. Then the OSP and TSP can verify everything but the rcdi
digests. Also, what is logo server is down?
Chris Wendt: I like to think about specs as the pure implementation of
things. Actual implementations could split responsibilities of the VS.
Talking about this explicitly in the spec would just muddy it.
Robert Sparks: I agree
Jack Rickard: The approach described by Alec is likely to be the main or
only way this is implemented, but I don't disagree keeping that detail
out of the spec.
Jon: Is there are use cases you don't want to share fate between things,
but them into separate passports. But likes idea of rcdi being verified
by end device. But expects shenanigans at TSP.
Alec: Don't need to mention SHAKEN. Integrity should be verified at
device about to display the URL.
Chris Wendt: Is it a bad idea for the OSP to validate the rcdi info?
Ben Campbell: The OSP needs to do that if they read the RCD info and
copy it into their SHAKEN PASSporT.
Alec Fenichel: I disagree with that. OSP doesn't need to verify
integrity as long as they verify cert and copy the rcdi forward.
Ben Campbell: Current text precludes separating fates of these. Can
write this without talking about SHAKEN.The party that relies
on/consumes the RCD data should be validating it. We don't need to
legislate on how it gets messed about with.
Jon Peterson: Depends on meaning of "consumes" The OSP copying the RCD
into their shaken is vouching for it though. Relying party verifies it.

Alec Fenichel: Only one entity needs to validate the rcdi. Could do
something like, if you remove rcdi you need to verify it, but if you
pass the digests downstream then you don't need to verify it.

[Apparent conclusion: The rcdi is verified by the party that relies on
it. Not requried for validationg ppt signature.]

Jack R: The OSP doesn't need to verify the "rcd" matches the "rcdi",
they only need to check that the "rcdi" digests are trusted. They
vouched for the contents of "rcdi".
Alec: Integrity check failure does not mean ppt failure. If you pass
integrity hash downstream, verification is not your responsibility.
Jon: Don't constrain who can be the relying party.
Ben Campbell: The relying party of the rcdi is different to the relying
party for the rest of the PASSporT. It's whoever needs it, for whatever
reason.
Robert Sparks: Call attention to what trust means. The trust model for
the URIs is quite different to the trust model for the rest of the
PASSporT. If we skip the integrity check, must be clear that the trust
requires that integrity check to be made. Need to consider that the
server might not be entirely under anyone's control, might serve a
competely different thing. Need to be clear on trust model.
Russ Housley: We put the hash of thing thing your fetching to make sure
that if someone swapped the image, then it'd fail. Whether the image is
appropriate is still a policy question.
Alec Fenichel: OSP and TSP verifying the rcdi is meaningless, the
contents of the URL could change between the TSP verifying it and the
end user using it.
Chris Wendt: There could be value for the caller to check that the rcdi
is correct on the happy path.
Jack R: The rcdi failing shouldn't be considered a passport failing
verification. Even if a logo fails digest matching, you can still trust
the "nam" field.
Jon P: Gateway is only allowed to sign B's and C's (e.g. delegate cert
with JWT claims constraint) but generates an A SHAKEN PASSporT. Should
the TSP reject the orig and dest fields. (Jon thinks "no")
Ben: Validating JWTClaimConstraints is part of the signature
verification.
Alec F: rcdi is different because it has to be validated at the end. The
device that consumes the URL.
Jon P: I'm imaging the TSP consuming the rcd.
Alec F: If the TSP is consuming the RCd and, for example, rehosting it.
It is their problem, they're the end user.
Jack R: If a middle entity verifies the rcdi they can't do anything.
Jon P: They could fail it.
Jack R: But then they're getting rid of other valid rcd information.
Chris: Better to find errors sooner than later.
Jon P: For any PASSporT, if some constraint that is not just orig and
dest, if that's not illegitemate should you reject it. The difference
for RCD is external content. Can kick that can down the road. But if
someone finds a passport problem, they can reject it.
Jack: Agrees in general. Thinks rcdi is different.
Alec F: It's just going to be too slow, to dereference.
Chris Wendt: Can have cake and eat it? Don't say that if the integrity
is broken it's still valid, can we say in a creative way that you might
be interested in partial info and not everyone is going to be capable of
checking.
Jon P: There are two categories of validation for rcd. Validating the
URLs and not. Anyone relying on the URLs must make sure to validate the
URLs.
Ben Campbell: Could go further, completely decouple PASSporT
verification from rcdi verification. rcdi is signed, but providing
additional validation that the end user must do.
Jon P: Don't want to say that. Security feels very complicated there.
Russ H: Could say, if you fetch that information then it must match.
Alec F: Decouple the rcdi validation from the
Ben Campbell: Must be really careful to pass the rcdi forward. Mention
in security considerations.

Robert Sparks: Going to call it there, need people to go off and think
Expects to need another interim 2nd week of October. Continue discussion
in email.

Alec F: It might be worth recomending vectorised images.
Chris Wendt: That's more for the sipcore draft.
Ben Campbell: Worried about specifying that at the IETF level. This may
get used in situations that aren't standard telephone calls or devices
with different display characteristics.
Chris: Probably okay to just put SVG there.

Connected Identity for STIR

• Jon Peterson and Chris Wendt
• draft-peterson-stir-rfc4916-update
• Discuss potential recharter
• Discuss open issues; get ready for WG call for adoption

Any Other Business (if time permits)

The chairs will organize another interim meeting in or around the second
week of October.