RTPSEC Minutes -- IETF 68, Prague MONDAY, March 19, 2007, 15:20-17:20 Chairs: Russ Housley, housley@vigilsec.com Dan Wing, dwing@cisco.com ----- 15:20 Agenda bash (Chairs) Busy agenda, high expectations ----- 15:20 Goals of this BoF (Jennings, 5) Working to Montreal requirements, doing protocols, we now understand what they would be like as RFCs. Want to know what to move to RFC. Not a BOF to form a working group, it's a BOF to make decisions. Tight agenda, please present quickly, audience will be holding questions until the end. ----- 15:25 Summary of Montreal discussion (Wing, 5) Three presentations, three priorities Need to do SRTP, for point-to-point, unicast Secure with forking and retargeting Key exchange in media path Requirements captured (with a couple of co-authors), but everyone seems to have read draft in last two weeks :-( ----- 15:30 Status of MMUSIC SDP negotiation work (Andreasen, 10) draft-ietf-mmusic-sdp-capability-negotiation-05 Since last IETF, formed design team with weekly conference calls and additional input/feedback Split document into requirements and solutions Wanted a general-purpose capability negotiation, but wanted to be responsive to transport protocol negotiation-only crowd SDP capability negotiation provides capability negotiation for transport protocols and attributes, plus an extensibility mechanism Goal is to issue revised draft with WGLC before Chicago ----- 15:40 Requirements Evaluation (Wing, 15) Intrinsic Features of DTLS-SRTP, MIKEYv2, ZRTP Path Forward draft-wing-media-security-requirements-01 Slide with "interesting implementation" of requirements. Proposals may meet requirements in different ways (using capability negotiation or probing, for example). DTLS uses certificates that contain only keys, ZRTP does nothing with PKI Dan not presenting detailed comparison slides, but they are in the proceedings. MIKEYv2 probably needs peer review, too. Room seems (show of hands) to know less about MIKEYv2 EKR - what peer review? Algorithms are CFRG. We found stuff in IKEv2 peer review. Would be in the RAI area with strong security backing. Some discussion on list about infrastructure requirements (terminating security in gateways, middleboxes that would block until session is set up). Any comments on these requirements? Good discussion, happened very late. Would be very helpful if middlebox vendors could comment on what they do with non-RTP packets - not just RTPsec, but ICE is affected as well. ----- 15:55 DTLS-SRTP (Rescorla, 15) draft-mcgrew-tls-srtp-02 draft-fischl-mmusic-sdp-dtls-02 draft-fischl-sipping-media-dtls-02 Signaling goop is crypto-binding signaling to MPKM, and authentication Can you authenticate without signaling? Crypto handshake isn't secure in many settings (MITM attacks when you don't know the people you're calling, cut and paste), doesn't work when gatewaying to PSTN. Impersonation attacks - no way to distinguish attacker from legitimate answerer (variant of the classic "mafia attack"). Even easier to do with IVR systems because you know exactly what's coming Can be social-engineered to fail in subsequent calls, as well SAS has limited coding space - people will happily read their SAS to you. Base-256 works better but IVRs are still fairly easy to impersonate. DTLS uses certificates, but they're only carrying self-generated keys, and peers don't have to check them because the fingerprints are in the signaling. Doesn't matter what user name is in the certificate. But if you have 3rd-party certificates, they work seamlessly. What if I don't have secure signaling? DTLS-SRTP uses SSHish key continuity feature Multiple devices - if you don't use the same key everywhere, you leak which device you're using (bad) How do you know other side will do security? Probing, Signal in SDP. Using capability negotation, but could use probing. What's new? DTLS ClientHello, some way to signal willingness to do DTLS-SRTP, SAS mode can be done. ----- 16:10 MIKEYv2 (Dondeti, 15) draft-dondeti-msec-rtpsec-mikeyv2-01 MIKEY designed for SRTP keying, used in 3GPP and OMA. Need to add crypto negotiation, mode negotiation. Finishes in 1 RTT. Same code reuse argument as TLS. MIKEYv2 - can do whatever DTLS or ZRTP does - no impossibilities Changing key exchange algorithm, of course we need peer review CAPability exchange is new, includes crypto and MIKEY modes that you support Mostly 3830 with MAC over capabilities message that was received so sender can verify Concerns about other proposals - separation of keying and data encapsulation (TLS), client-server paradigm (TLS), chattiness (ZRTP), not sure when ZRTP actually finishes If we choose something else, please minimize RTTs, support initiation through SDP, make protocol peer-to-peer, support multiple sessions If you start a new media session, do you have to set up a new DTLS session? EKR - if you are running comedia, this helps (realized this at lunch) Rohan - does 1 RTT ever get exceeded? If you fork, sure. Christer - few RTTs is a good thing. Do you want to go as far as sending unencrypted media to save setup? ----- 16:25 ZRTP (Zimmermann, 15) draft-zimmermann-avt-zrtp-03 ZRTP is architected to be easy to deploy, so it's really deployed today. It's optimized for human-to-human communication. Short authentication string - most of the time, people are talking about the weather. People will check the SAS when they care about security. Don't think a team of attackers will splice your voice out of multiple calls (with different background noise). Can do key continuity, as in SSH "ZRTP deserves to be standardized" - made many changes for architecture and new requirements Rohan - if we have change control, we can add anything we need. If we don't have change control and we want to make a change, that's a significant issue. Are you OK with that? Phil has been asking for, and getting, suggestions from other proposals. What if someone makes a suggestion Phil doesn't agree with? Sam Hartman - 2026 requires change control for IETF standards track. If the IETF pursues this, are you willing to give change control? What is the IPR situation? If we make a change you don't like, do we have an IPR problem? Jon Peterson - if we change the editor, is that OK? Phil: Would probably resist if you change every molocule in the spec... Russ - goal is to publish mandatory-to-implement on standards track. Other two proposals have definitely given change control. ----- 16:40 Discussion (All, 35) Jonathan - you didn't answer the change control question. Sometimes editors don't agree with WG consensus. This is a yes or no question. Phil - this is a gray scale, not yes or no. Sam - this is a process requirement. You have to say "yes" to move forward. You can do whatever you want, if we change it in a way you don't agree with. But you have to say "yes" to go standards-track. Christer - middlebox doesn't really have requirements yet. Dan - all of these fail if you block their media packets... Christer - but that's not the only failure mode. Can be more or less robust if you have to decrypt media. Dan - like transcoding with knowledge of the endpoint (Christer nods) Henry - different usage scenarios - room for two, could even be room for three - we have so many codecs for different situations. Hope IETF doesn't drop end-to-end principle. Alan - change control is required, but I'm talking about lack of SIP integrity until Identity is deployed. Why is it OK to trust hopwise TLS for key exchange? EKR - it's not OK. It's a stopgap. I think it sucks, but we may need it. Charlie - easy question - can end nodes really support them all? hard question - as people steal ideas, will there be IPR issues with all of the proposals? Phil - just rumor - recently filed, won't know what claims emerge until it's granted. Never thought my patent would apply to other protocols. Don't know if patent applies to other protocols. I gave it away free. I need to make a living somehow. If they pick the other protocol, I can't license them software. Dan Petrie - are these techniques applicable to TCP framing? John Elwell - not sure about key continuity - same person on same terminal. May be going to PSTN gateways, routed to different gateways at different times. Middleboxes are important issues. PSTN gateway, SBC, transcoding. Astute user knows what his security covers. Jonathan - new to this work. Read all the documents for this session, these protocols are starting to look pretty similar. We are approaching an encoding decision - that's all. To me, I've been told time and again to pick what's been around for a long time. This is why we did TLS for SIP. Peer review takes a long time. DTLS-SRTP is already a known item. The Comedia proposal says how we secure TLS, too. This is perfectly consistent with what we're doing in SIP. Use what's in the right direction, start with DTLS-SRTP and make the changes we need. Last point is about use cases. I'm more interested in system-to-system communication, which covers PSTN gateways, transcoders, etc. I understand how this works with DTLS-SRTP. Adriel Kaplan - what does mandatory mean? Russ - we're picking the one we'll use in this environment. Others may be used. Adriel - but there's not way to make people implement it. Other point - Comedia-TLS works through most SBCs today, it's configurable. Sam - someday, a Security AD is going to ask you what your mandatory-to-implement story is. We do make people add mandatory-to-implement. 3261bis might not be the right place to put it, but we'll find a place - that's how we handle security in the IETF. All these protocols like SSH key cache, and that's not always a good thing. Support costs of changing compromised keys is too high to justifiy changing them. Don't assume SSH is perfect. Humm - pick one protocol today? very close in the room. Humm - pick one eventually? more support for picking one, but not today. Rohan - in IMPP, we needed the union of the requirements for both camps. Maybe we should look carefully at the requirements. Do we care about multicast key exchange being the same as unicast? Number of RTTs, done, doing comedia, operating without identity header - all potential requirements, we need to agree on what the requirements really are. ??? - we're trying to do lots of things here. We're using ZRTP for peer-to-peer gateways - available, deployed, does the job we need to do today. Don't want to leave it behind for proposals that don't meet this. Christer - RTP mixer is already part of RTP spec, would not make sense to adopt key management protocol that doesn't support RTP mixers. Colin Perkins? - San Diego AVT consensus was that key exchange packets must not look like RTP - I think all do. We said "mandatory-to-implement", and that's wholly unrealistic - billion to one fan-in is completely different. Philip - would be nice to choose a protocol with no reliance on infrastructure, because we'd like to do this protocol for P2PSIP. Think this should be a requirement. Cullen - question was simple - none of the proposals need a centralized infrastructure. ??? - Would like to talk to people with working stacks for interop in a couple of months. Francois - getting to the point of writing requirements to choose a protocol, instead of choosing a protocol today. Looks like one author wants to keep control - clear what we should do. Phil - need to think about it, of course. ... finally flogged into saying he would probably give change control to IETF and show up at the meetings to share opinions. ??? - people aren't going to verify SAS for every call - not realistic. Dave Oran - SPEECHSC has long conversation about speech identification, applicable to SAS verification. Thinks we're less than five years away from attacker who can be Alice's voice to anyone if attacker has talked to Alice. ??? - think ZRTP and DTLS are both easy to implement - other opinions? Craig - for people who hummed for two protocols, I've chaired a WG that did this in PKIX. AD and co-chair said it was worst mistake they ever made in the IETF. Still suffering today. Can we not make that mistake again? Tim - that's something you can't get back, if you go down the two-protocol path. Please don't go there. Cullen - if IETF made arbitrary changes, is IPR still granted? Phil - was going to answer questions from other guy - not a dichotomy, you get the protocol on every call, SAS is just a way to tell whether there's a MITM. May send SAS out-of-band. May send it signed. Multiple ways to achieve this requirement. To Cullen's question: you're asking me in a public forum to say "yes" or "no", I've put a lot of thought into IPR statement. IPR is tied to disclosure flag - has social benefits. There's a lot of wiretapping going on now. Either disclose that you're surrendering the key or pay for the patent license. EKR - don't care if people screw with DTLS as much as they want. ??? - haven't finished requirements phase, that's getting in the way of choosing. Security to automated system matters, too. Christer - two scenarios, one with keying infrastructure and one without. Changes the evaluation when you change scenarios. Perhaps choose a protocol for each scenario? Hummm - does current document capture requirements? Hummm was "no" - Jon says requirements work can be endless, Cullen unclear on what's missing (because everything people mentioned is in the document). Hannes - people on list aren't looking at requirements, they are looking at the name of the protocol. Jonathan - requirements are sufficient to choose THE BASIS for our work - that's the question. ----- 17:15 Hums (Chairs, 5) Hums: * Have we captured requirements sufficiently to select the basis of future work today. Result: Strong but not overwhelming yes. * Do we have enough information to select a protocol as the basis for protocols work today Result: 90/10 in favor of yes. * if you think DTLS-SRTP should be the basis of future work * if you think MIKEYv2 should be the basis of future work * if you think ZRTP should be the basis of future work Result: Very weak support for MIKEYv2, Decide to drop MIKEY out and do again. * DTLS * ZRTP Result: Not a huge consensus but DTLS was louder.