SIPBRANDY (SIP Best-practice Recommendations Against Network Dangers to privacY) - IETF 97 Monday November 14, 2016, 11:00-12:00 Grand Ballroom 2 WG chairs: Gonzalo Camarillo and Gonzalo Salgueiro Responsible AD: Ben Campbell Jabber scribe: Jonathan Lennox Minute taker: Jean Mahoney ----------------------------------------------------------------- 11:00 - 11:05 Introduction Presenters: Gonzalo Camarillo and Gonzalo Salgueiro Presentation: https://www.ietf.org/proceedings/97/slides/slides-97-sipbrandy-chair-slides-00.pptx slide 1: Title slide 2: Note well slide 3: Agenda Gonzalo Camarillo - Nothing new to present on OSRTP and Alan is not here. Ben, anything on PS versus Informational on the OSRTP draft? did the WG give you the input you needed? Ben Campbell - I think I got input - we are updating a current PS that piece needs to be PS. I need to talk to other ADs about whether the organization is ok. Gonzalo Camarillo - we're concerned about the energy within the working group. But with the lull in STIR, we should see more energy. Jon Peterson - We don't need a whole lot of energy. There's a limited amount of work left to do here, and we'll be able to do it. ----------------------------------------------------------------- 11:05 - 12:00 BCP for Securing RTP Media Signaled with SIP Presenter: Jon Peterson Presentation: https://www.ietf.org/proceedings/97/slides/slides-97-sipbrandy-best-practices-for-securing-rtp-media-signaled-with-sip-00.pptx Draft: https://datatracker.ietf.org/doc/draft-ietf-sipbrandy-rtpsec/ slide 1: Title slide 2: Media Confidentiality with SIP slide 3: Two pronged strategy slide 4: The WG -01 STIR has been rapidly changing over the last 4 months. We can now apply those changes to SIPBRANDY work. And there won't be a lot to do after this. As we discussed in Berlin, we removed the pointer to PERC since it was not mature enough. We removed a lot of OSRTP, you can read Alan's draft about that. slide 5: A STIR profile slide 6: Media Security Using DTLS-SRTP was somewhat contentious in Berlin. MUST for DTLS-SRTP. Is this still how we want to do it? [no objections from the room] slide 7: Credential Management Needs some work. The guidance is inspirational rather than specific. Credential acquisition is the only thing that show that the passport was signed by an end-user device. Russ Housley - who are we going to mandate to have the cert, then we can talk about how they can get it. STIR accommodates signatures at different points of the call path. Will this say which place MUST support? Can't answer the question until you know who the assigner is. Jon - This is for e2e security. The credentials required to sign this must reside on the end point. SIP makes this problematic - endpoints are an abstraction, there are end user gateways for black phones. I'm trying to determine the best assurance, multifactor auth to couple this to the device. Eric Rescorla - about SP certs, transparency mechanisms like ct can alleviate these concerns. Cullen Jennings - at a meta level - we don't have to prescribe other ways but we need some way. We need someway, a solution to this. This is the hard part of it. Should be in our scope. Jon - TLS doesn't solve this problem, how to get the certs. I know we want to give guidance. Is there better guidance? Chris Wendt - It's not mentioned explicitly, but service providers have to do MITM. We have to be able to do some legal things. Jon - There's some wording on siprec, a mechanism that supports that. This mechanism is for enabling E2E security. Chris - I want e2e media security. It would be beneficial if it could happen, but we have MITM requirements. Jon - I understand that. PERPASS model understands that and we are coding to that. slide 8: Connected Identity STIR only works on requests not responses. End points need connected identity. Need to sign for that identity. Does RFC4916 need an update? I'm not sure it does. If some else could read it and give an assessment. Jonathan Lennox - could examples go in one of the other drafts? Jon - could do that. Gonzo - could we have a volunteer to look at this? Jon - Given the deltas between 4474bis and 4474, do we need to update 4916? Adam Roach - Last time I volunteered, it took me a whole IETF cycle to get to it, but put my name down and then bother the crap out of me. ACTION: Bother the crap out of Adam to review RFC 4916 to see if it needs updating. slide 9: Opportunistic Use Do people want Opportunistic use? I could document it. Or do we want to take a strong stand against it. Gonzalo Salgueiro, from the floor - Document it in this draft? Jon - yes Cullen - We should describe this for practical deployments. And then decide to say, We hate this, but we know you'll do it anyway, all in caps. Christer - Isn't this more generic and need to be documented in a STIR document? Jon - this is how it works in STIR now. This is a profile of STIR, we could fail it. We could allow it explicitly - explain how to do it. Right now, we don't say either way. If we say nothing, we allow it. Christer - assume that I'm the verifier and I only support STIR. I get an INVITE with msec, and I don't know msec. Is it still ok to indicate that call is verified? I don't want to reject it. Jon - we're not changing that behavior. The change here is on the authentication service side, that when the verifier sends back the response - if it doesn't have msec, you HAVE to fail out. Lennox - What about warnings like, this guy did msec yesterday, but not today. Jon - more complex policy and analytics is not in immediate scope. The tofu stuff should have guidance like that. Lennox - it's like inverse tofu. Related thing - do want anything in baseline stir - basic comprehension mandatory. If you don't understand this field, ignore identity or fail the call? Jon - This is documented already. We don't prescribe in STIR, local policy up to you. We doing something different here and can make it stricter if we want. Eric Rescorla - You offer 3 options: pass on silently, document, forbid. I think documenting would be useful. Jon - The sense I get is that people are cool with documenting. ekr - tofu hasn't worked out well. People are reluctant to decide on keying material. Losing their key and the consequence is that no one can call them again - not a good outcome. Jon - I think we'll go with explicitly documenting that this loophole exists and what it would look like to do this opportunistically. slide 10: Path Forward Jon - can tighten msec text. We can start adding concrete examples. Need to work on rtcweb alignment. Possible to have e2e security with a sip endpoint using STIR and a rtcweb endpoint. That was a stretch goal. Just make sure we don't close doors. Cullen's draft is appreciated, and gives context around those doors. Cullen - status on this - we may hit the stretch goal. I think it will work with what we have now. Martin Thomson - I'm cautious until I've implemented. Haven't done it yet. Relatively trivial, though. Jon - Provided that STIR doesn't change 15 more times, we should be in good shape by March. Gonzalo - When Jon revises the draft, please review and send comments. AOB? (none) 12:00 Meeting ends