Jabber: xmpp:firstname.lastname@example.org?join MeetEcho: https://www.meetecho.com/ietf108/stir Notes: https://codimd.ietf.org/notes-ietf-108-stir# Jabber Archive: https://www.ietf.org/jabber/logs/stir/2020-07-31.html
Minute taker: Jean Mahoney Jabber scribe: Adam Roach
Order of presentations changed due to presenters not being available yet. Jon Peterson to cover post-WG LC docs first.
## draft-ietf-stir-oob (Jon)
Jon: Is in the RFC Editor queue.
## draft-ietf-stir-passport-divert (Jon)
Jon: Many comments in LC, DISCUSSES from security area.
Added a couple of high-level paragraphs discussing div-o to satisfy Roman's DISCUSS. Please read it, there's a new normative statement.
Question to the chairs: Do we want to bring it back to the WG to take a look?
RjS: I'm not particularly concerned, but if you think people aren't paying attention, we can create a deadline.
Jon: don't care.
RjS: Send reminder note to the list. People will have time to comment.
Jon: Jack raised issue around when you should trust "div". Can be replayed, captured by eavesdropper. Do we need to clarify what you need to trust "div" in general?
Jack: This summarizes what I was thinking well. The telephone numbers doing the redirections may not be quite as trusted, but you expect the SPs to take care of that.
Jon: The number of immediate implementations of STIR is small right now. We want to get it right.
Jack: Is it fine -- when UEs can't access the passports, ...
Jon: Provided that passport uses mkey and that rtcp used, this impersonation attack wouldn't work. Use sipbrandyish ... The deployment of ... of sip overall not wide.
Chris Wendt: If calls get to UE level, how much div happens?
Jon: This is more of a network feature. This is more about the attacker and the attacker's power. I don't what to discount this. The story is mkey.
Brian Rosen: Point out that mkey is useful, it may not be obvious to the reader. Point to original discussion. Your proposal is the right way forward.
Jon: I'll add text and draw attention to the group so they can review it.
## draft-ietf-stir-cert-delegation (Jon)
Russ: Haven't had a chance to read it yet.
Jon: I assume it's pretty good. I added text from the jabber room from last interim. I think it's good to advance.
RjS: I've read through it. I think it's good. Give Russ time to review.
Murray: Have you picked a Document Shepherd for this draft yet?
RjS: Russ and I will work it out between us.
Chairs to pick a Document Shepherd for draft-ietf-stir-cert-delegation.
Chris: Needs more people to review
RjS: Are there any additions that are still coming, or is it in a state for review and polish?
Chris: It has most of the things it needs. Reviewed by some IPPNI and 3GPP folks. Enough review to move forward. Think it's ready to go.
RjS: Anyone feel like it's not ready for WGLC? No objections (participants in jabber room said ready). We'll cue it for WGLC and be sure we get some dedicated reviews.
## draft-ietf-stir-passport-rcd (Chris)
Chris: Please review examples in wendt-sipcore-callinfo-rfd, ensure it's correct. Review the use of MUSTs.
Jon: The normative text is an interop question. Important to identify the fields that every receiver must understand.
Chris: Name, logo, reason are the top priorities. Can add others as time goes on. Need to initiate conversation on wendt-sipcore-callinfo-rfd. What else do we need to move forward?
Jon: the rcd draft is stable at this point, should look at how to exit it from the WG. sipcore will barf all over this. If people complain about various fields, it won't impact the rcd draft. They can move in parallel.
Chris: integrity in the rcd draft needs to be reviewed.
Brian: As sipcore WG chair, sipcore workload is not high, we can get working on it. I want the sip experts to weigh on it.
Jon: I'll send something to the sipcore list. Will we park rcd while sipcore discusses?
RjS: Might as will wait until we receive feedback from sipcore.
Jonathan Rosenberg: Concern that it works with enterprise use cases. How do deal with info provided by enterprise. Reason for call is dynamic. Not known by the authenticating carrier. Call-reason is important for enterprises.
Chris: That's the intention of this. The policy of who can sign is being discussed in other forums. Making sure that the logos are appropriate and the vetting of that info. A school of thought that would be used with certificate delegation. We want this to be a general.
jdr: it's unclear to me. if the enterprise is not using delegation...a subset of the jcard -- I didn't see a process like that in the doc.
Chris: if you put the rcd identity header in the sip invite and make sure that no one drops it.
Jon: call-reason is a separate scope of protection since it's dynamic, can be set by enterprises.
jdr: I want to ensure that the draft covers this use case. I'm happy to review and provide comments.
## draft-peterson-stir-servprovider-oob (Jon)
Chris: The concept of the CPS being in the terminating side is new to me. If I'm going to connect to various CPSes,... why send HTTP when I can send a SIP INVITE, are we solving the problem twice? Why not just create the VOIP network in the first place.
Jon: could be the GW's responsibility. If you assume massive IPPNI and islands of SPs, then you have GWs between. This draft is not talking to this. this is looking at the high-level security issues are. Assume that the CPS is tightly coupled with the O or T of call. I thought it would be interesting to document that case.
Chris: the GW makes the problem more tractable.
Jon: the vines group has the same problem - the intermediaries are not trusted, need a back channel to go around them.
Chris: international is a whole other thing. A country that doesn't adopt stir, needs a GW.
Jon: Should we do this? There's work being done in other fora. Is it worth the STIR WG time to do?
RjS: Let's do a hum: If you are interested in contributing in a WG setting, and you think the WG should take on and you will participate, Hum now.
RjS: Landed in the middle (Piano), which suggests that it's marginal. Not quite enough to call on list right now. If you are interested in this work, send a review to the list. See if it generates more interest.
Russ: Does anyone object to this going forward in the group? Not a hum. Please speak.
Chris: I don't object, I want my caveat addressed. Willing to review.
Subir: How to coordinate with GSMA?
Jon: I'm the editor of the GSMA spec. There are number of solutions being discussed there.
Subir: your objective is to do work in IETF and then take it to GSMA.
Jon: The IETF has a good track record of making good recommendations.
RjS: I'll issue a call to the list.
Chairs to issue a call for adoption for draft-peterson-stir-servprovider-oob on the ML.
Brian: Any questions?
## draft-burger-stir-iana-cert (Eric)
Eric couldn't be here to present. Skipped.
Jon: I revised my connected identity draft, and I'll be putting more energy into it going forward. I hope to have it more fleshed out next time.
Ben, Marc: +1
Jon: Is there appetite in this group for messaging? We should explain how these systems could use stir. A framework document.
In Jabber room: Ben and Marc.
Russ: Ben and I wrote a document on how to authenticate SIP MESSAGE.
Jon: explain 8296 credentials relevance to messaging.
Russ: more the SMIME approach.
Ben: We didn't talk about the applicability of stir. I find it interesting. A sipbrandy like thing for messaging.
Chris: I see value.
Jon: we need a 4960 update.
Jon: if MLS wanted to use stir credentials, what it would look like. Need it broad enough.
Russ: I'm supportive.
Jon: Chris and I will take a crack at that.
Jon: We can point out things that we get for free.