# STIR Working Group Interim 13 Sep 2021 {#stir-working-group-interim-13-sep-2021} ## Summary {#summary} ### Identity Header Error Handling {#identity-header-error-handling} Chris Wendt led discussion on the [Identity Header Error Handling draft][1]. 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 {#rcd-passports} Chris also led discussion on [RCD PASSporTs][2]. 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 {#connected-identity} Discussion of [connected identity][3] 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 {#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: {#raw-notes} ### Administrivia {#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) {#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 {#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 {#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) {#any-other-business-if-time-permits} The chairs will organize another interim meeting in or around the second week of October. [1]: https://datatracker.ietf.org/doc/html/draft-wendt-stir-identity-header-errors-handling-02 [2]: https://www.ietf.org/archive/id/draft-ietf-stir-passport-rcd-13.html [3]: https://datatracker.ietf.org/doc/html/draft-peterson-stir-rfc4916-update-04