Minutes interim-2022-stir-01: Fri 10:00
minutes-interim-2022-stir-01-202204221000-00

Meeting Minutes Secure Telephone Identity Revisited (stir) WG
Date and time 2022-04-22 14:00
Title Minutes interim-2022-stir-01: Fri 10:00
State Active
Other versions markdown
Last updated 2022-04-29

minutes-interim-2022-stir-01-202204221000-00

STIR Working Group Virtual Interim on 22 April 2022

Administrivia

  • NOTE WELL
  • Agenda Bashing
  • Note Taker: Jack Rickard

PASSporT Extension for Rich Call Data

Request for re-review on changes from 15 -> 16.
Ben Campbell: Like "icn" addition.
Mary Barnes: Is the "icn" a URI or URL?
Chris Wendt: It's a URI.
Chris: Want to revert changes adding Constraints paragraph. What do people think?
Ben: We should explain consequences of decisiions, but shouldn't be trying to tell the industry the trust model.
Chris: Will go back to a note which is less persciptive.
Jack Rickard: There was nothing before?
Jack: That's not true.
Jon Peterson: Want to explain use case, but don't want to require JWT Claims Constraints. JWT Claims Constraints will sometimes be necessary, but in some situations it won't.
Jon: Want to separate integrity from JWT Claims Coinstraints.

Chris: Note that there's a privacy issue around Claims Constraints including RCD information in public certificates.

Ben: Has there been enough change since the last WG Last Call, to need another one?
Russ Housley: Regarding the current WG Last Call, the WG Chairs will ask whether the changes introduced new issues and whether all previous issues are resolved.

Connected Identity for STIR

Jon Peterson: Not a substantial update, mainly a maintenance update.
Chris: I plan to spend more time on this document (after RCD is done!).

Identity Header Error Handling

Robert Sparks: Do we need to do anything with the sipcore document?
Chris: It's good now; it can be published.

Jack: We need to be stronger about using compact form. Intermediaries might not implement this specification so will unknowingly leak their information if full form is used.
Chris: Will do.

Out-of-Band STIR for Service Providers

A version of this has been implemented by TransNexus see this webinar.

Jon: Can we have a downref to RFC 8816 for the REST API?
Ben: Have to get it past the ADs.
Russ: Raise the downref in IETF Last Call and ses if anyone objects.

Jon: Should we punt on the push interface?
Alec Fenichel: Can create a multi-tenanted service, as long as it's scoped in some way. For us, the TSP gave out tokens. Push is good because it's really fast, we always beat the call. Unfortunately, this pushes the problem to CPS discovery if you include the scoping in the URL.
Alec: People won't want to build a pub/sub solution, so if it is not in the specification, everyone to write their system.
Jon: Yes, don't want to reinvent the wheel.
Chris: Agreed.

Jack: Is the API as defined in RFC 8816 going to be normative?
Jon: I don't think we want to say there's no other posisble API, but might go for "mandatory to implement, but not mandatory to use". Does that assuage concerns?
Jack: Essentially just asking whether I need to review the API.
Chris: Problem with REST is that when you get to authentication is hard to specify. It looks simple but breaks down quickly. I'm not a big fan of standardising APIs like that.
Jon: The draft currently uses mutual TLS, but there are other approaches like directly signing things.
Alec: Mutual TLS can be a pain in public services.

Ben: Please think really hard about security considerations. Is there anything else we need to say here that we haven't said?
Jon: Replay not particularly useful for spam mitigation, but could be important for fraud prevention. Launching that attack is hard and pretty obvious once you've attempted it, but is worrying for large attacks.
Alec: Could we put something in the TDM signalling (like the UUI)? It would have to make it to the other end, which can be hard.
Jon: It doesn't seem likely that would make it through. I'm not worried about the substituion attack. It is more feasible to defeat this with security best practices than fixing ISUP.
Alec: Yes, this would be hard to execute, but there's another way to look at it. The CPS discovery is hard, could we put the CPS on the OSP and pass the URL to the CPS in the TDM. This deals with replay, discovery, and substituion.
Jon: That's interesting, we should discuss more offline. If there's a yard of PSTN in the middle of the network this gets complicated.
Alec: I'm thinking this is operated by the provider converting the call to TDM.
Jon: Figuring out how to stuff something in UUI isn't in the scope of the IETF.

Ben: We're talking about providing extra information to bind the PASSporT to the signalling. If there's an extra SIP header it would be trusted not to mess with it to tie the PASSporT to the call, something like message integrity.
Jon: OOB isn't specific to the TDM problem. Policy is probably number one reason passports don't make it to their destination. STIR SOLID had a mechanism to tunnel passports in the telephone number, but that was a bad idea.
Jack: STIR needs the signalling to be tied to the passports to be secure, div already introduced a vulnerability here. So this doesn't make things worse, but it isn't a great place to be.
Jon: Should think about robocalling, this makes it more expensive for them, even if it isn't perfect.

STIR for Messaging

Jon: Added some text on freshness.
Ben: Verification of "iat" should be done as close to the recipient as possible, to get as much end-to-end security as possible. Messages are sometimes delayed. After you have received them, there is also message history. Should we add text about that?
Jon: My philosophy is that PASSporTs should go to end devices as much as posisble, is worth documenting inbox services that consume PASSporTs.
Norbert Angell: If the service consumes the PASSporT it can just record that it is verfied. Can't see why you'd need to store PASSporTs.
Jon: If the message and PASSporT are stored together, you get non-repudiation-like result since the PASSporT has the signature.
Chris: All mainstream message protocols end up being store-and-foward. A bigger topic is, how are people keeping PASSporTs and certificates? We don't have recommendations here for things like forensic non-repudiation.
Jon: It would be interesting to look into foresic obligations.
Chris: Relevant to traceback and so on.
Alec: SHAKEN PASSporTs aren't that useful for non-repudiation, only tell you that a telephone number that sent the message, not which person.
Jon: I hear you, but in most cases, it will be pretty good. You can use service provider records to link telephone numbers to people.
Ben: This links to messages from things, not from telephone numbers.
Chris: We've had philosphical discussion on non-repudiation, you could have a desk phone that someone else picks up and uses to place an illegal call. There are limits.
Robert: This links to connected identity.

Ben: I think the text about CPIM metadata looks correct.

Jon: Conferencing is an open issue. Might need a new working group for applying MLS to SIP. Suggest we punt that topic for now.
Ben: There were discussion about applying MLS to other messaging frameworks, but don't know where that went.
Chris: The state of group messaging for MMS is pretty messy. If you want to have trust across groups, we'd need to do something.
Russ (in chat): Don't wait for MLS to progress this document.

Ben: I think this is pretty close to WGLC.
Russ: Let's do WGLC to get everyone reading it. Any objections?
No objections

Any Other Business (if time permits)

Jack: What's wrong with by-reference?
Jon: The thing you need to download can be big, and some people are going to be reluctant to list all telephone numbers that they own.
Jack: Big is good, we generally have to cache everything. We don't have time to make a call out for every PASSporT.

Russ: In a SHAKEN environment, certificates only containing an service provider code.
Jon: We talking about using OCSP exclusively for delegate certificates.

Alec: A big problem with by-reference is the unknown expiration date. OCSP is also useful for by-value, because of OCSP stapling. CRL means you need two round trips. We should require OCSP stapling.
Jon: The interesting question is what's the difference between OCSP stapling and short-lived certificates.

Chris: I'm supportive of looking at both and potentially implementing both.
Alec (in chat): Jon, I agree on exploring both short-lived certificates and OCSP. I think OCSP stapling need to be in the PASSporT or the Identity header as a parameter on the PASSporT. There could be multiple PASSporTs signed with different certificates, so a separate SIP header would make identifying which one goes with which.