[Sipbrandy] Notes from SIPBRANDY 97 session

["A. Jean Mahoney" <[e-mail]>]

Hi all,

Here are my notes from the session this morning. Let me know if I missed 
anything.

Thanks!

Jean



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