From: ekr Subject: Minutes of RTPSEC BOF Date: 17-Jul-06 including updated summary of Architecture hum on 7-Aug-2006 [Based on the audio feed and Jim Fenton's Jabber logs] EXECUTIVE SUMMARY ----------------- REQUIREMENTS The topics covered in the requirements discussion and the Hum responses follow: 1. Forking and retargeting MUST work with all end-points being SRTP. MUST work with mix of SRTP and RTP endpoints. Not acceptable for all endpoints to see the keys with forking. OK to start with RTP and then upgrade to SRTP. 2. Avoid clipping media before SDP answer No clear consensus. Probably SHOULD avoid clipping without additional signalling. 3. Shared-key encryption for conferencing Consensus not to work on that now. 4. Attack protection Passive attack protection a MUST. MUST somehow consider active attacks but no clear requirements established. Complicated issue. 5. Perfect Forward Secrecy Protocol MUST be able to support PFS. 6. Future algorithm negotiation Protocol MUST support this. 7. Endpoint identification when forking Offeror must be able to associate answer with the appopriate flow. (Weak consensus) 8. Self-signed certs/PKI Protocol MUST NOT require 3rd-party certs. (Strong consensus) If two parties share an auth infrastructure they should be able to use it. (Moderate consensus) ARCHITECTURE The question of SIP-path versus media-path keying was discussed. Hum was taken on: 1. Solely in the signalling path. 2. (a) Solely the media path or (b) In the signalling path *and* the media path Consensus was for 2 without distinguishing 2(a) or 2(b). No clear consensus for RTP-plane versus RTCP-plane. DETAILED MINUTES ---------------- REQUIREMENTS DISCUSSION SIP Forking and Retargeting --------------------------- - Forking (when your call gets sent to both Carol and Bob). Need to have different keys. - Retargeting (when you call Carol and get sent to Bob) Requirements: 1. Forking and retargeting MUST be possible when all endpoints are SRTP. Robert Sparks: Do you mean in one basic SIP transaction round or would it be OK to discover in one round and then do a reinvite? A: For this reqt. it doesn't matter. In the next, there's a mix. Michael Richardson: Must be possible means that the protocol allows it but the implementations might not? A: Yes. MR: It must be possible to make theat work, or you can fail the call completely? A: When all the endpoints are SRTP, it's easy. When there's a mix, how does that behave. Will get to that later. MR: One possible answer is that with a mix initial invite would fail? A: Yes. HUM: This is a MUST. 2. Forking and retargeting MUST allow establishing SRTP or RTP with mixed of SRTP- and RTP-capable targets. Q: This doesn't mean that you have to end up with SRTP, just that it's possible if that's the fork you eventually choose. A: Yes. Q: [unheard] A: Yes, policy might prohibit everything other than SRTP. RH: this implies some negotiation. HUM: This is a MUST 3. Forking and Retargeting MUST/SHOULD be secure. Issues: 1. Maybe I can set up the key and then rekey later with a fresh key. XXX: What do you mean by secure? Key results is secure. A: Yes. EKR: Best case scenario is to have separate keys initially. Not acceptable to have all forks see keys. Massively attractive to let you distinguish keying material between forks. A: I cover that requirement later. Roni Evans: Are the first two bullets to enable the protocol to do it or are they policies? A: Policies. Flemming Andreeassen: Does immediately include early media? A: We'll have slides on that soon. FlA: But what does it mean on this slide? A: I'll get to that. Alan Johnston: Doing RTP initially and then negotiating up is reasonable. One problem with SIP is you don't know when forking is occurring. So, if you need a reinite to rekey, this might mean every call needs a reinvite. A: Yes. XXX: The key is in the signalling message and readable to everyone. What about DH? A: DH may be the answer but we're looking for the requirement. But e.g., MIKEY RSA-R doesn't have this problem. XXX: It should not be mandatory to have a solution which only works with upgrading. Would be good to be able to have SRTP from the beginning. A: We'll vote. Q: It's OK to have this option, but shouldn't be the only one. A: OK. We'll hum on this. Michael Richrdson: HUM: Is it acceptable for forks and other targets to see the keys? No. HUM: Is it OK to start with RTP and move to SRTP afterwards? 2/3 Yes. Q: what does that mean? A: It's an acceptable solution. HUM: Does the security need to be in place at the completion of the SIP message? Clarification: should another INVITE be required? EKR: this isn't the same question? A: Did anybody else mis understand it? FlA: well, that's only one way to do it. EKR: well, my point is that you shouldn't have to do more SIP signalling. That's bad. If it means that you can't have a short period of RTP and then switch over without more SIP activity, that might be OK. RH: That's the middle bullet. EKR: I read what Dan was saying was that immediately here meant no more SIP activity. That seems highly undesirable. MR: Were you in favor of point 2? EKR: That was fine. MR: The not version of point 1 means point 2. EKR: Consider MIKEY in DH, where you can do early media in RTP but then you cut over into SRTP but without SIP activity. The SIP activity is what I don't like. RH: This bullet doesn't distinguish these issues. EKR: Let's not take a hum on this bullet. MTR: We need trinary logic: in scope, out of scope, need argument. I think some activity, SIP or not, is fine. But if I know ahead of time, I would like to skip it. DW: The difference between these two bullets is: second one is: RTP first, then SRTP first one is: OK to tell everyone the key so we can get session set up (to enable forking) RH: That's point 3. XXX: I thought point 3 was forver. EKR?:I see, shared key initially then cut over. That's horrifically awful. DW: I apologize, rest of these slides are awesome. XXX: I'm still struggling with this? What's the issue? Separate offer answer or what? DW: need to move on. Avoid Clipping Media Before SDP Answer -------------------------------------- PhilZ: Is it you don't know who's going to answer and so you send the keys to everyone and then you rekey. This doesn't happen in my scheme. DW: Right, that's true with others too but not all. We're trying to establish the requirement. DW: Want to receive SRTP before receiving the SDP. Is this a MUST or a SHOULD--without preconditions or PRACK? Do we need to allow early media to be encrypted. Cullen Jennings: Highly desirable. PRACK and preconditions impls. are minimal. Ron ??? from BBN: We're trying to force VoIP into the PSTN model. DW: That's a tough oen. FlA: Not mandating the force. Just trying to avoid clipping. Gonzalo Camarillo: ICE may obviate this since you need to wait for the answer anyway. DW: But do we want to require ICE. HUM: MUST avoid clipping without additional signalling. (some hums) HUM: SHOULD avoid clipping without additional signalling. (more hums) HUM: Additional signalling is OK to avoid clipping. No clear answer. Francois Audet: We're not going to solve this today. It's a tough topic. bring back to the list. DW: Yes. FrA: We need to define exactly what we mean by clipping. Best-Effort Encryption ---------------------- DW: There is a big problem with retargeting because you get weird behaviors if you have one UAS which supports SRTP and one which doesn't. This gets messy. You can get bounced to the wrong phone or forced into insecure mode even if one of the UASes is SRTP-capable. XXX: How is this different from the first requirement. DW: Maybe it's not. Skip it. This is the second retargeting requirement. Shared-Key Encryption --------------------- DW: There are a lot of cases in which you have conferencing. Nice to have shared keys for perf reasons. Example: PTT Should we require this. Should either end be able to provide shared key? Dave McGrew: What are the scope of the requirements. Is this for standards track protocol to solve the point-to-point needs? Do they apply to any SRTP key management protocol. CJ: My hope is to get an idea of prioritized set of reqts to help us design standards track protocols. Figure out how to move forward. Might be that we selected a contradictory set. Strong guidance, not mandatory but gives you an idea of what we'd like. MR: Must a single protocol support all of these options and everything else? Maybe PTT system is not the same as talking to my banker. I know we have multiple mechanisms. My impression was PTT was solved by one of the existing systems. Do we need to obsolete everything but one. EKR: Michael makes sense. Historically point-to-point protocols are designed differently from group protocols. Crypto can be very different, esp. for rocket science protocols. What's the immediate problem: point-to-point. Kill that now and then kill the group problem later or ratify something existing later. Jon Peterson: This is a diverse environment. Hard to find one size fits all. This is an important exercise for finding out what the common cases are. DW: I agree. Lakshminath Dondeti: not too hard to optimize for both. FlA: You're glossing over multicast/unicast. Let's focus on point-to-point. PhilZ: Are you talking about using the same session key for each edge. What if you send different data? DW: It won't be. PhilZ: You know about stream cipher safety, right? DW: Yes. HUM: Do we want to try shared key? Strong hum for NO. Attack Protection ----------------- DW: Passive versus active attackers, MITM, downgrading, etc. Questions: 1. MUST protect against passive attack. 2. MUST/SHOULD protect against active attack. EKR: Must protect against passive attack--otherwise I go to the bar. Active attack protection is impossible without some sort of integrity for the SIP messages. The important thing is to be able to block the attacker impersonating you to either side. The attacker blocking you from getting into secure mode is only sort-of-detectable. You know you're in insecure mode but don't know why. If you have SIP Identity or something like it, you should be safe from active attack. MR: Parties should have the same view of the situation. You've defined active attack as including proxy. That makes life much more complicated. What are the CALEA-type implications of protecting against proxy attack? Sam Hartman: I don't think the active attack is properly stated on this slide. Multiple situations: 1. Support modes of detecting and preventing active attack with SIP Identity or a cert. 2. Detect no security or MITM. 3. Care about proxies. Asking this question is useless. EKR: This is too complicated to take a hum on except for the passive question. We all agree we want some level of active attack protection. SH: Can we take a hum on active attack. EKR: We need to assume SIP identity. SH: EKR: It's hard to parse this cause there are a bunch of different attacks. If you tell me which one you mean I can tell you which ones are important. RH: No hum on first one. We all agree. HUM: if you want to ignore active attacks. No support. Perfect Forward Secrecy ----------------------- DW: Do we want it. SH: What's this mean? DW: MUST be able to establish. SH: I agree it's MUST support but you also need a mode without it. Performance... Hum first on whether we need support for PFS and then hum on whether we need other options. FlA: If I use a new symmetric key every single time does this satisfy it? DW: No. EKR: Some PFS is desirable but SSL experience is that some people don't always want to PFS. LD: We should be able to have a non-PFS version. XXX: Just because you can do SRTP doesn't mean you can do a DH for every call. PhilZ:If we allow a non-PFS mode does this mean device may not be able to do PFS. RH: MUST be able to do PFS. HUM: MUST be able to support PFS. (Strong support). Future Algorithm Negotiation ---------------------------- DW: With some techniques you need to perform a crypto operation for each algorithm you want to offer. This makes upgrade difficult. Desirable to avoid this. EKR: This is clearly important. Experience shows that people want to negotiate. Especially in light of the perf gap between ECC and RSA. MR: This is important. SIP is like IKE aggressive mode. I really want negotiation. FlA: How can you do this without additional expense? DW: Need to do crypto for each exchange. EKR: Do negotiation in one round trip and key management in next. Media channel is fast. FlA: Requirement for single offer-answer exchange. EKR: then it can't be done. FlA: Mutually exclusive. Oran:Meta-problem. Bifurcation about everything in media plane versus everything in the signalling plane. Do we need to move everything in the media plane? Is it important to have a system which works entirely in the media plane or uses signalling plane to prime things. SH: We don't have a system which works entirely in the media plane. XXX: ZRTP does. SH: Not standard, it's a proposal. EKR: There are three approaches: signalling, media, hybrid. DO: We're not ruling out hybrid, then? EKR: That's what I like. SH: 1 offer answer round trip plus whatever you do in the media plane. DW: Right. FlA: Not constrianing total round trips, just the round trips in the signalling plane. DW: Want to constrain computation effort. FlA: But as many round trips in media plane as you want. DW: This belongs in lakshminath's presentation. PZ: Don't do any precalculations. Offer a menu and then do calculations after menu. RH: That's what we're discussing. PZ: We had several protocols that don't meet that requirement. Let's not preclude doing everything in the media plane. HUM: MUST support multiple cipher suites without additional computational expense. Strong support. Computational Effort When Forking --------------------------------- DW: What happens if you have a lot of forking. Don't want to do DH for everyone. Associate the SDP response with the right DH exchange and only do that one. EKR: This requirement conflicts with early media/clipping. DW: I can't do 20 DH operations. EKR: You can design a protocol where you can do either not do all the DHs *or* not clip, but not both at once. DW: If there's only one stream, then you don't want to clip but if there are 20 then I'll clip. EKR: Seems right. Roni:What about multiple parallel media streams. MR: Is it possible that you get a lot of media streams? DW: This happens a lot. MR: You could throw this stuff away? DW: There's no way to mix all those streams and play it back. You want to talk to the steam which is a real person. Doing DHs for the wrong guy is wasted heat. FlA: You seem to be assuming one solution. That you need to receive the SDP answer before you process the flow. What about EKT? EKR: I'm not sure computational requirement is the right phrasing. For security reasons you want to associate the SRTP flow with the right SDP answer if the forks aren't in the same trust boundary. Not sure that the DH is the right issue. HUM: Offerer must be able to associate answer with the appropriate flow. (Positive but not real strong). Self-Signed Certs ----------------- DW: Endpoints might have self-signed certs. EKR: Phrased wrong. Shouldn't need 3rd party certificates. You might not need certs at all. PZ: I'm not using signatures, let alone certs. RH: Then you're fine. DM: Should be able to use PKI when present. PZ: I have seen many problems with PKI in the e-mail arena. Road is littered with grinning skeletons. In a monolithic system like Skype you can build PKI, but in an interoperable multiparty system. The need for PKI is even less with phones because phone calls are ephemeral. It's a mistake to say MUST have PKI. RH: It says MUST without. CJ: I like the question as-is. Add another question. If there is PKI, it should be able to use it. SH: Other things besides PKI. What's special about PKI. If I two parties share an authentication system, they should be able to use it. XXX: Work with shared keys. XXX: System whouls work with any credentials two parties share. PZ: S/MIME has a big deployment advantage over PGP but nearly nobody uses it. Nearly all e-mail encyryption uses PGP because of the low activation energy for PGP. Because no need to use PKI. This goes in spades for phones. The reasons PGP is so successful despite PKI being supported by MS and despite everyone has it is for much the same reasons. The way we encrypt phone calls is much easier to get done without PKI. Systems that don't use a PKI will probably have the same competitive outcome that PGP had over S/MIME. XXX: This isn't a or b. HUM: MUST be able to interoperate without third party certs (Strong positive). HUM: If two parties share an auth infrastructure they should be able to use it to provide authentication. (Positive) ARCHITECTURE DISCUSSION SIP-path versus Media-Path Keying (Lakshminath Dondeti) ------------------------------------------------------- LD runs through slides. Since he fairly closely follows them, I'll only note the places where he says something not on them. FlA: Any inband keying solution has an issue with NATs. You need the response to let you open up the pinholes. I'm concerned about using RTP port for key management with quality of service. LD: ICE uses that same port. RE: Impact of packet loss? LD: Would expect key management system has retransmit. Alan Johnston: ZRTP does retransmissions. SIP Path transport has been done. We should focus on media path. UDP transport on fixed port is a problem with NAT. RTP port works with ICE. RTCP is not deployed so we shouldn't base on it. EKR: On... bandwidth chewup from keying. LD: RTP or RTCP? EKR: Both but usually I hear RTP. Usual concern is a slotted scheduler. There are two times when traffic is concerned: (1) startup (2) rekeying. Rekeying happens in three contexts (a) re-PFSing (b) group keying revocation. (c) key refresh. You can send a lot of data before key refresh in SRTP. This is primarily an issue in video contexts where the overhead is fairly small. Remember that you key refresh is very small. So, the main issue is the opening stanzas, which are order 1K or so. MR: NAT problem. If you can make RTP work, you can get traffic btwn endpoints. An issue that's important is that certs get big and if you are running UDP, you get fragmentation which is a problem. IKE has none. I don't think that the bandwidth issue is important. FlA: With RTP, let's not design based on specific assumptions about rekeying. RE: RTP is unidirectional. RTCP is bidirectional. But it may not be deployed, but if you need to do it for keying you would. LD: Right. I'd forgotten about send-only. LD: Take hums? RH: Get all presentations first. Best-Effort SRTP (Alan Johnston) -------------------------------- AJ runs through slides. Since he fairly closely follows them, I'll only note the places where he says something not on them. AJ: None of the standardized solutions support best-effort. I guess this means we've learned our lesson. Mark Baugher: Does this mean you're deprecating SAVP? AJ: If you use a=crypto, etc. then you basically are. MB: You're not proposing that are you? AJ: No, but if we use a signalling-based system you basically are. DM: Switch codecs before negotiating crypto? How would that work? AJ: If you choose codecs before going secure and then you choose a codec that doesn't work with your crypto algorithm. PZ: I've done a lot of measurements and codecs take fare more CPU time than the block cipher. I don't believe there is CPU hardware that can do the code but not has enough room to do the block cipher. DM: Perhaps you've never worked on an optimized SRTP impl. I have had that experience. PZ: Then perhaps you don't have room to do crypto. The difference between AES-128 and AES-256 is only about 20%. DM: Take this offline. RE: Disagreeing. (not clear about what). AJ: Anyway, you might want to swith codecs. AJ: We've tested this mechanism. EKR: In order to make this work properly, you offer AVP and not SAVP in the initial exchange. AJ: Yes. EKR: In that respect it's similar to offering in an attribute. AJ: Yes. FlA: (Re Slide 10) Having a single feature tag in SIP feature tag probably won't work well with multiple streams. Keep media things where they belong. EKR: Discussion about which bullets are AVP vs. SAVP. What are advantages of having an SAVP profile if you're doing crypto? AJ: Need to have some indication. Some people argue that it should be in SDP. At least in signalling. If we don't, then we're deprecating SAVP. Maybe we should just deprecate it, though. Hadriel Kaplan: Why are you reinviting? AJ: So other devices like proxies know it's a secure media session. HK: One of the main benefits of doing it in the media is so proxy doesn't know. And now you're telling them. And then they can react. PZ: It's not something I would do but it's something other people asked for. HK: To me the benefit is not adding signalling overhead. AJ: We don't currently do this in ZRTP. Shared-Key Conferencing (David McGrew) -------------------------------------- Who's going to talk? DM is going to talk. DM runs through slides. Since he fairly closely follows them, I'll only note the places where he says something not on them.n DM: We already decided shared key wasn't a priority, but I'll walk through the issues and so maybe it will be clear why people aren't so concerned about it. Slide 4 EKR: Revocation doesn't require new key handshakes in some of the crypto rocket science group key modes. If you want it to look like any key management protocol anyone uses, then Dave is right about performance. LD: Did we already punt on this? DM: Not the most important problem to solve. RH: We wanted people to have background on what the hub meant. LD: What did we sign up for? RH: Exactly. RE: In other protocols, e.g., H.323, the key exchange is done by the master/bridge. There's no race condition. It's up to the bridge how to do it. AJ: As co-chair of Xcon, I hope this continues. Bernie H: Does this scenario assume all users are using encryption. DA: If people aren't secure, just don't encrypt to them. BH: Introduces problems in mixed modes. DM: Yes. RE: Some customers want all participants secure, some don't care. Hums On Architecture (RAI ADs) ------------------------------ CJ: We tried to make sense out of what was said. JFP: It was great to see how decisive a lot of the hums were. More clear-cut than I thought it would be. I hope when we get the minutes sorted out this will be a strong basis for figuring out what protocols would achieve consensus. We're really psyched. CJ: We got a pretty strong feeling people wanted to do signalling not in the signalling band. CJ: Setting up the hum. Do we want to do all the keying negotiation in the SIP signalling channel. In the media-plane path we're including hybrid approaches as "out-of-band". PZ: Doing it in the media plan is out of band? That's in-band. Colin Perkins: ...and we have a media control layer: RTCP. Use it! PZ: I hear people call ZRTP a layering violation. I think it's a layering violation to do it in the signalling. We should do media encryption negotiation in the media layer. PZ: I want to do media-plane only. CJ: Second option does not rule out ZRTP. HUM: Only do keying in SIP/SDP signalling (Weak) HUM: Media plane + SIP/SDP (Strong) CJ: Second question. RTP? RTCP? [To JFP] you want to phrase the question since I blew the other one. JFP: I don't think you could blow this one. AJ: There's RTP and then RTP ports. Shall we lump these together. JFP: Lump them together. FlA: I'm not sure we should just say RTP. There are other protocols, such as STUN. JFP: They'd be multiplexed over the same ports. FlA: Yes. JFP: We'll consider those to be the same for purposes of this hum. HUM: RTP HUM: RTCP EKR: I think we need more discussion. CJ: No clear consensus and since it involves other WGs we'll take it to the list. Wrapup (RAI ADs) ---------------- CJ: Chairs and the appropriate ADs (including Sam) will work on getting minutes out here that are solid and that we can use as guidance and then move on towards figuring out which protocols will work and selecting one for moving forward.