STIR IETF 102 2018 July 18, Wednesday 15:20-16:50 Van Horne Chairs: Russ Housley, Robert Sparks Minute taker - Jean Mahoney Jabber Scribe - Rich Salz Summary: draft-ietf-stir-passport-shaken received a Last Call comment about whether SHAKEN should have a compact form. Chris will send a sketch of the text to add to the draft to the list. Sean Turner, Mary Barnes, Christer Holmberg and Eric Burger volunteered to review draft-ietf-stir-passport-divert (Eric handed a marked up printout to Jon during the meeting). Whether nesting should be a MUST or SHOULD was discussed. The sense of those in the meeting was to go with MUST. Further discussion was sent to the list. draft-ietf-stir-oob is ready for WG Last Call. Those in the meeting were comfortable publishing an architecture and outline of what a concrete protocol might look like, but not publishing a concrete protocol at this time. The filed errata against the "iat" content in RFCs 8224 and 8225 were discussed, and those in the meeting agreed that the current use of the same timestamp as in the Date header addresses our threat model best, and that we want more operational experience before saying anything different. The errata against the "mky" content were also discussed, and Jon reminded the group that DTLS-SRTP was the mechanism chosen to secure RTP audio. The discussion in the meeting noted that we would be better off not creating a generic mechanism for allowing other technologies (such as securing MSRP with TLS). Instead, if including such technologies in PASSporTs is desired, separate documents exploring the specific security properties of covering them in the PASSporT would need to be written. Those in the meeting supported continuing work on the callflow examples showing the interaction of divert and history-info. The proposal to protect P-Charge-Info in a PASSporT was discussed. There was insufficient interest from those in the meeting to take the proposal further. =========================Notes==================================== Robert Sparks - Status of WG documents in flight - normal and in progress, nothing is stuck. Do we need to talk about SHAKEN? ----------------------------------------------------------------- PASSporT SHAKEN Extension Mary Barnes draft-ietf-stir-passport-shaken Mary Barnes - No comments from WGLC. Are the chairs ok with that? Jon Peterson - Why doesn't SHAKEN have a compact form? There are shadow P-headers in the 3GPP, there's no reason that it can't. Mary - I'm not in 100% agreement. People are already starting to implement. We can look at it later. The P-headers should be brought here. I talked about it at the 3GPP meeting. Jon - It seems like an easy thing to add/specify. Don't have to use it. Mary - Those P-headers aren't in our documents. They exist in slides. That's the only documentation. We can push for standardization. Russ Housley - There is nothing to reference at this point. Robert - Putting the capability into the document, even if we don't have anything to point to. Mary - We need to talk to Chris. Robert - If he shows up, we'll come back to it. Otherwise we take to the list. Russ - Jon, would you please make your comment on the list? ACTION: Jon Peterson to ask on list about compact form for SHAKEN. ----------------------------------------------------------------- PASSporT divert Jon Peterson draft-ietf-stir-passport-divert https://datatracker.ietf.org/meeting/102/materials/slides-102-stir-divert-out-of-band-00 Eric Burger - A 50Kbyte SIP message, or one with 50Kbyte long lines will be properly digested... Can go either way. If the driver is OOB, it is not compelling to me, though. A SHOULD would not be implemented. Pick one and make it a MUST. Jon - The previous sense of the room was to leave it as an option. Didn't want to make a MUST. Eric - This will drive people to use History-Info. Jon - History-Info is service logic tracker. Not in our threat model to preserve service logic. Not why we are doing this. This is extra credit. Mary - History-Info is generic. Originally it was service logic. You will do more work capturing this information than doing History-Info. Jon - If you put some of that information into your index ... Mary - That's what I'm saying, makes those scenarios easier. Jon - I think there are ordinary use cases that won't need things you are describing, not going to see more than one layer of nesting in 99.9% of cases. Mary - There's enterprise cases. Jon - That's a profile that is specific to the way SHAKEN treats endpoints that I wouldn't build generically for STIR. Mary - Doing it generically is a better thing. Eric - When I said you can zip up the different things, it is not to compress it. The signatures won't compress unless we failed on our choices. It is the concept - if you want to put a thing into this CPS and get back this thing, that's independent of this. Jon - We discussed whether we should do nesting only for the CPS case, but for 99.9% of the redirect cases, nesting makes more sense. If you are forking it, you need to make 5 different PASSporTs - the server side would work better to nest those. It was the 302 thing that put us over the line on this. It is extra credit. You use Diversion when a 302 came back. And you can sign something that you got from the redirect server. New invite go out with a new target that led to the complexity. That we would need nesting for the in-band cases. Eric - Lead with that, and then BTW that OOB could happen. Instead of, "we gotta do this for OOB". And then I would offer MUST. Jon - There were people who wanted to do it with separate Identity headers. We would like operational experience. I rather not say you MUST NOT do this with individual identity headers. I want to say you SHOULD do it this way. If it doesn't work in a particular deployment, I don't want them to be out of compliance with the STIR specification. Eric - Sounds like the Rich Shockey infinite employment program plan; it is experimental. Jon - In the RFCplusplus BoF we talked about what it means to be a Draft Standard and Proposed Standard. I think this meets the bar for Proposed Standard. Eric - We will leave that to our chairs and ADs. slide 4: A nesting optimization Jon - Is this a good idea or a bad idea? Can remove it but would prefer to keep the text. Russ - Anyone object to it staying the document? Mary - I don't think it is a good idea because you are revealing too much information and you are including privacy headers as well. Jon - It is your server and you're redirecting, you are deciding, and then generating the PASSporT. And the one who does the redirecting generates the passport. They get to chose whether it is ok to share. Mary - We just won't do it in SHAKEN. slide 5: Issues Russ - Who will review the draft? Sean, Mary, Christer, Eric volunteered. ACTION: Sean Turner, Mary Barnes, Christer Holmberg and Eric Burger to review draft-ietf-stir-passport-divert. (Eric has already completed a redline review) Eric - I'll start the discussion about SHOULD/MUST on list. ACTION: Eric Burger to start discussion of whether nesting should a be a MUST or SHOULD. (Completed.) Jon - How about - it MAY be MUST? (laughter) Rich Shockey - Editorial - it is ATIS and the SIP Forum joint task force. Just ask about MUST vs SHOULD here for using nesting. Jon - For using nesting in inband? That would mean you are not allowed to have an identity header with a div in it unless it has a nested PASSporT in it. That is what MUST means. Russ - Let's take a hum. Do you prefer the document to say: - MUST - SHOULD - Don't care Russ - Consensus - The hum was slightly louder for MUST. Jon - I'll have to write up something about the trade offs. ----------------------------------------------------------------- STIR Out of Band Jon Peterson draft-ietf-stir-oob https://datatracker.ietf.org/meeting/102/materials/slides-102-stir-divert-out-of-band-00 Jon - Anyone want to convince me to do a protocol in addition to the framework? Robert - Is anyone working on an OOB implementation? Jon - Is it important to solve the case where it is not SIP end-to-end? Richard Shockey - Yes, do it at some future time when we find the one carrier on the planet that wants to do this. Attitudes can change. Take this to WG Last Call. Robert - Do we need to specify a protocol right now? Eric - Do we run the risk that people will think that we have solved OOB? Robert - It is clear that it is an architecture document. Eric - If someone implements ts something that doesn’t follow this document, will the work group say we cannot work on it because it doesn’t follow this document? Jon - I don't believe because we published BGP when someone came along with ISIS it meant they couldn't have an RFC. Russ - No. The IETF does voluntary standards. (Chris arrived, and the conversation here shifted back to the -shaken- document) Chris Wendt - I haven't received any comments during WG Last Call. Robert - There this late comment about compact form. Jon - Shadow P-headers exist in 3GPP. Mary - We build a PASSporT with these P-headers. They don't leave the service providers' networks. Jon - So it is illegal for the P-headers to leave the network, but not for the passport to carry those P-headers out of the network. That's madness! Chris - My thought it would be info, not P-header - that would be the easiest way to do it. Jon - If want to just add a parameter that had the same function. I'd rather that they are in public specifications. Chris - In the IPNNI task force, the plan is not to use those. If there is a noncontroversial way to define compact form and add them as identity header parameters. Jon - That's fine, doesn't matter to me. This started in our conversations about PASSporTs were getting too big and you want to cut them down, the obvious way is compact form in SHAKEN. If you want to use P-headers or parameters that's fine. I don't want to prevent that. Chris - You want them to be optional, so if you are doing full form you wouldn't need them. Mary - Correct. I don't want that to be a dependency for this document to have that all specified. You need to define the normative behavior for those. Chris - Purely there to support compact form. Mary - Correct, they are not in the proposal. Proposal is to capture them as soon as they come into the service provider network. If they leave the network, build the PASSporT then. If they are not signing as it hops through their network. Chris - This is representing the origin id and the attest parameter, so if you are using compact form ... Mary - That's fine. Chris - I can add some text around that. Robert - Please send a note to the list outlining what you are planning to add. Chris - Yes, maybe I can also send the text. ACTION: Chris Wendt to send to the list an outline of compact form additions to draft-ietf-stir-passport-shaken. ----------------------------------------------------------------- Technical Errata for "iat" content and inclusion of "mky" (RFCs 8224 and 8225) Tolga Asveren https://datatracker.ietf.org/meeting/102/materials/slides-102-stir-errata-00 Jon - What's the risk of this? Tolga went over the use case on slide 3: "iat" Content/Call Flow Jon - We don't define what SBCs do. This is not an ordinary PSTN situation. I'm ok with that being the MAY case. And what is in the documents should be the SHOULD case. I'm unpersuaded. This doesn't apply to the style of impersonation attacks we are are trying to defeat. How do you exploit this? It encourages us to make our recommended date window larger, which makes it easier for hackers. This is not how most calls occur. I'm ok without SHOULD for most calls and a MAY for sometimes things. Tolga Asveren - The main reason to rely on Date was for the sake of compact form. How much value is there saving on the time information itself? Is it something tangible compared to the size of the message. Jon - That's the tradeoff. If we want to save bits, but 99.9% of the time theres a small difference. We assume clock drift, and it is unlikely to have an attack in the time. It is because of that, we assume the difference is insignificant. I asked around about JWTs and "iat" and looked at RFC 7519, I don't think it mandates much. Chris - The philosophy of the correlating the date and the "iat" as our primary replay attack mechanism. In IPNNI, we have been focusing on full form. What did we want to represent the "iat" as it is meant to be? If you do have these application scenarios where INVITEs are held up in the network, then you have to deal with that in your application. We should stick to the fundamental philosophy. Tolga - What is the opinion of using the current time as the preferred form if full form is used rather than compact form? Jon - If the "iat" is different, you must use full form. Tolga - To turn it around - if you need to use the full form for some other reason, would it be preferable to use current time over date? Jon - If it doesn't make a difference in the threat model, then we don't have a problem. 500ms makes no difference in how the validate service validates the PASSporT. This was designed - the UE side signs it, the first SBC puts a new Date on it, but if you did full form, it should still work. You want to allow this - SIP stuff gets munged in the middle of the network. Tolga - If you change the date, you should generate a new PASSporT. It is not given that an SBC would definitely change the date. Mary - I'm going to agree with Jon. Let's get operational experience to see if we have a problem. slide 4: Inclusion of "mky" in PASSporT Jon - When you are doing TLS self-signed certificates in MSRP do you include a fingerprint in the SDP? Adam Roach/Ben Campbell - Yes. Jon - Yeah, ok. I could see that. How to errata that in RFC 8224? MRSP usage with self-signed certficates - a separate specification and to integrate that in. Is there burning interest? Tolga - I agree there is not a burning interest. For your proposed approach, wouldn't you run the risk that if you need to use it for something else, you would need to come up with a new document. Jon - Remember our threat model - beat an impersonation attack. SRTP - impersonation deeply tied to telephone numbers. I don't know if there's a lot of use cases. Ben, what are you working on? Russ - S/MIME for messaging, but we are not using self-signed certificates. Ben - It is transport neutral. Jon - We put out one specification to update RFC 8224. I don't want to do it speculatively - a=fingerprint. Get some consensus that we want to do that in STIR. Tolga - Jon - We had the RTPSEC BoF about this - solutions for secure realtime media. The STIR threat model is about incoming telephone calls. Hadriel was here. There was going to be something in the PASSporT. Tie into a crypto instrument... different device than the media was coming from. Tolga - Why the restriction? What is the optimization? Jon - We had our Thunderdome. We decided to do DTLS-SRTP. When we built STIR, we wanted to create that binding between media layer and signaling layer, and a mandatory strength requirement. Ben - MSRP does require the use of the fingerprint attribute if one uses self-signed certificates. Definition comes from the COMEDIA over TLS stuff. Robert - Jon's reminder of the conversation when we added the MUST. It was a well-considered, and widely participated group decision. We put this to bed. The only shortcoming in the document is that we didn't write down enough why. Jon - It is not crazy to say how to do it with MSRP. It doesn't beat our threat model. Robo-calls are really annoying but not MSRP. I wouldn't object for a document that can do this for a some specific use case like MSRP. Robert - And the properties get vetted as opposed to creating a generic thing. Jon - Exactly. I don't want to say anything goes. Russ - To our AD - there are two errata that you have to process. Do you need anything more from the WG? Adam - Probably not. If I need something later, I'll reach out. Robert - Then we will assume that you have all the info you need unless you indicate something later. ----------------------------------------------------------------- Other Business (if time allows) ----------------------------------------------------------------- SIP Call Flow Examples with PASSporT Diversion and History-Info Mary Barnes draft-barnes-stir-passport-div-hi-callflows-00 slide 1: Title slide 2: Background slide 3: Example Christer - I haven't read the text. You are only signing the index. Mary - Correct. Christer - This doesn't sign the History-Info itself. Mary - It doesn't sign History-Info, you want to make the target the same. Christer - Is there text about that? Jon - All we are protecting are History-Infos to help you sequence it. Mary - Marianne Mohali will have to do this in 3GPP. Christer - I want to be clear - this is not a method for signing all of History-Info. Mary - Right. slide 4: Discussion Points Jon - The gateway information isn't in the PASSporT? Mary - Yes, this is our SHAKEN PASSporT. slide 5: Discussion Points slide 6: Way Forward Mary - Should I continue with this? Jon - I support. Chris - I think it is a good idea. Christer - We should have examples. Mary - If someone wants to help, that would be nice. Christer - Should we include the Reason? You should define a compact form and put the value in the PASSporT. Mary - When we work through the work cases. We'll see if it will work. Robert - When would this complete? I don't want this to be a frogboiling exercise. Mary - I was going to pick through History-Info call flows. I can be more complete for the next meeting. See if it is enough. ----------------------------------------------------------------- PASSPorT Extension for P-Charge-Info Header Tolga Asveren draft-asveren-stir-p-charge-info-00 slide 1: Title slide 2: P-Charge-Info Tolga - Used in SHAKEN context, and it pertains to billing. Are people interested in my continuing this work? Chris - PASSporT is really based on origin/destination things. P-charge-info is on one side of a domain. I understand signing it. I don't have strong feelings about it. Christer - Where is this is going to be used? It is used between trusted nodes. Procedure wise - I'm concerned about it. It is an Informational draft. What if someone brings up Diversion header? Do we do Proposed Standard for the PASSporT draft? Tolga - The notion of trust is not 100% black and white, there are different shades of gray. I understand the concern and point. Trust is not an on/off thing. Jon - How long have I waited to hear that! RFC 3324 Spec(T)s and trust domains and how black and white they were. If you are asking us for consensus on something that you couldn't get consensus on this. Sean Turner - PCI is an acronym in other contexts. Robert - My initial feel of the room is there is not a lot of enthusiasm for taking it further. And reasons to not to. Tolga, do you understand? Tolga - Yes, if there is a change of opinion, they can express it on the list, but now there's not sufficient interest. No need to progress this further. ----------------------------------------------------------------- Wrap Up Robert - Do we need to meet in Bangkok? It feels to me that we are in a tail mode. With exception of History-Info call flow drafts. Jon - We need to work on certificate stuff. Not super pressing. It would organize acme work into how it plays here. The connected identity stuff that Chris and I were working on. I hear from people that they want this. Robert - We should request a meeting, it should be short. Jon - We are at the point now. Let's look at what people do with this. Over the hump on this definitely. Robert - Any other other business? Robert - We are done.