Internet Draft H. Kaplan Document: draft-kaplan-best-srtp-keys-00.txt Acme Packet Expires: January 2007 July 2006 Best-case End-to-end SRTP Technique for Key Exchange interoperabilitY (BEST-KEY) Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines an opportunistic SRTP key exchange mechanism to get the best-case SRTP keys, using a slightly modified version of Security Descriptions model [secdes], followed by a second-stage media-plane key exchange based on [XXX]. There are several distinct advantages to this mechanism over others; these benefits are documented herein. The main goal of this draft is to put forth a strawman proposal to perform a 2-stage key-exchange, first via a [secdes] style mechanism, then through a media-plane mechanism. Kaplan Expires - January 2007 [Page 1] draft-kaplan-best-srtp-keys-00.txt July 2006 Table of Contents 1. Introduction................................................2 2. Notational Conventions......................................3 3. Applicability...............................................3 4. Benefits and Drawbacks of BEST-KEY..........................4 5. Changes to Security Descriptions for BEST-KEY...............5 6. Offer/Answer Model for BEST-KEY: Stage 1....................5 6.1 Generating the Initial Offer...............................6 6.2 Generating the Initial Answer..............................6 6.3 Processing the Initial Answer..............................7 7. Media-Plane Key Update for BEST-KEY – Stage 2...............8 8. Formal Syntax...............................................9 9. Security Considerations.....................................9 9.1 Security Implications vs. RFC 4568 [secdes]................9 9.2 Security Implications vs. Media-plane Mechanisms Alone....10 References.......................................................11 Author's Address.................................................11 Intellectual Property Statement..................................11 Disclaimer of Validity...........................................12 Copyright Statement..............................................12 Acknowledgments..................................................12 1. Introduction There are currently 11 proposed mechanisms for exchanging and negotiating keys for Secure Real-time Transport Protocol (SRTP) [srtp], none of which interoperate. Some of these are signaling- plane mechanisms, meaning the key exchange mechanism is handled in SDP carried in session signaling messages; other mechanisms are media-plane, meaning the key exchange is performed end-to-end between the originator and terminator of the SRTP streams. Of the signaling- plane mechanisms, the most popular is the RFC 4568 Security Descriptions mechanism [secdes]. Of the media-plane mechanisms, there is no clear leader currently. [Note to editor: change previous sentence to be the one media-plane mechanism chosen by the group]. The [secdes] mechanism has several benefits which make it attractive for a particular class of equipment: is incurs very little processing burden per session, and is the least complicated. But it also has several security weaknesses which make it less secure than other mechanisms. In general, stronger security typically costs more to implement and is only necessary for a smaller community, while weaker security generally costs less and is sufficient for a larger community; thus this author believes the popularity of the [secdes] model is unavoidable. Meanwhile, the security drawbacks are equally unpalatable for a significant set of use cases, and thus media-plane end-to-end mechanisms are more desirable. It also has the Kaplan Expires - January 2007 [Page 2] draft-kaplan-best-srtp-keys-00.txt July 2006 unfortunate characteristic that the other end must support [secdes] or else a new offer/answer must be performed. Therefore, this document proposes both: sessions begin with Security Descriptions (slightly modified), and after becoming established, attempt a media-plane key exchange mechanism. If both ends support the media-plane mechanism, then the SRTP keys are updated and the media session ends up with stronger security; if either end only supports Security Descriptions, then the weaker SECDES-based keys are used, which is still better than not performing SRTP at all; if one side only supports RTP, then RTP is used without having to perform a new offer/answer exchange. The changes to Security Descriptions outlined in this document are fairly minor, and are defined in order to successfully negotiate multiple mechanisms in one offer/answer exchange, even if the answerer only supports clear/non-secure RTP. These changes may be better defined in a separate draft, but are done here temporarily to expedite matters (namely, discussion in RTPSEC group). The main goal of this draft is to put forth a straw-man proposal to perform a 2- stage key-exchange, first via a [secdes] style mechanism, then through a media-plane mechanism. 2. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The terminology in this document conforms to [RFC2828], "Internet Security Glossary". The term 'media-plane mechanism' is used throughout this document to represent whatever end-to-end key exchange mechanism is chosen as the primary one by the RTPSEC group or RAI area WG. It is not intended to signify the chosen mechanism will be based on any particular proposed mechanism, nor whether it uses RTP packets, RTCP packets, or some other packets/protocol to perform the key exchange. The term 'signaling-plane mechanism' is used in this document to represent SRTP key exchange performed through SDP carried in an application protocol, such as SIP or MGCP. Such a mechanism follows the signaling path, getting transferred hop-by-hop by signaling intermediaries, such as proxies. 3. Applicability RFC 4568 [secdes] offers a similar type of key exchange method, since this draft uses it with some minor modification. In contrast, this Kaplan Expires - January 2007 [Page 3] draft-kaplan-best-srtp-keys-00.txt July 2006 draft proposes using a [secdes] style key exchange in a backward- compatible manner with legacy RTP devices in a first stage, and trying to update the keys with a media-plane mechanism if both ends support it in a second stage. This mechanism should provide a smoother migration path, broader applicability, and more rapid acceptance than [secdes] or a media-plane mechanism alone. 4. Benefits and Drawbacks of BEST-KEY The BEST-KEY mechanism provides several valuable benefits over using [secdes] or a media-plane mechanism alone: 1. It allows two ends to negotiate the strongest SRTP key possible, without multiple SDP offers/answers. 2. It is backwards-compatible, meaning a BEST-KEY offer to a non-BEST-KEY receiver still results in a successful session with media, although one using non-secure RTP. 3. It does not rely on signaling-plane security, if both ends support a media-plane mechanism which does not rely on it. 4. It supports the largest/broadest set of device performance classes: including devices which cannot afford the resource penalty of per-call media-plane key exchange mechanisms, and devices which can. In other words, it should achieve broad use because it is not limited in applicability. 5. It is a fairly trivial change from [secdes], which has already been implemented in some devices. Therefore it should not be too burdensome to modify the implementations in use. In fact, a BEST-KEY answerer will interoperate with a legacy [secdes] offerer. (but not vice-versa) 6. It is fully compliant with SDP RFC 4566 [sdp], and does not change the ABNF syntax of [secdes]. 7. It works for any application protocol which carries SDP and follows the offer/answer mechanism of [RFC3264]. 8. It should provide a way to achieve end-to-end SRTP even in mixed application signaling environments, as well as hop-by- hop for environments that require that. 9. It provides for a migration path from RTP to SRTP based on [secdes] style keys, and to SRTP based on end-to-end keys. It is this author's opinion that a migration path with broad applicability is critical to the success of any mandated IETF SRTP key exchange mechanism. There are already millions of RTP-capable devices in deployment that will not be replaced overnight on a "flag-day", and must be interoperated with, with as little pain as possible. The drawbacks to BEST-KEY are: 1. A successful bid-down attack will result in non-secure RTP, if neither end supports a media-plane mechanism. See the security section 9 for a discussion on this. Kaplan Expires - January 2007 [Page 4] draft-kaplan-best-srtp-keys-00.txt July 2006 2. For devices which can handle media-plane exchange mechanisms, BEST-KEY adds a bit of overhead/work since it mandates a [secdes] style key exchange as well. Since such devices are typically not resource-constrained, that should not be an issue. 3. It may provide a false sense of security to users if the User Interface is not properly handled. For example, if there is a single lock-icon which is on regardless of how the keys were exchanged, users will not realize a call which only uses a signaling-plane key is less secure than a media-plane one. This is debatable, however, as even the media-plane mechanisms are not perfectly secure, and at least BEST-KEY provides a migration path so that there's a reason to create a lock-icon in the UI. 5. Changes to Security Descriptions for BEST-KEY The ABNF syntax and protocol mechanics described in RFC 4568 SDP Security Descriptions for Media Streams [secdes] are adopted by this draft, with the following exceptions/changes: 1. The transport type encoded in SDP MUST NOT be the SRTP transport defined in [srtp] of "RTP/SAVP" or "RTP/SAVPF", unless the offerer wishes to *only* allow SRTP answers. Instead, this draft requires the transport encoding type MUST be the same one used if RTP were not secured (e.g., "RTP/AVP"). If the offerer wishes the offer to fail if the far-end does not support SRTP, then she would continue to use the same transport encoding mandated by [secdes] and [srtp]. [Note: that can already be done per [secdes] and does not require this draft at all, does it?] The purpose of this draft is to provide the best-case with call success, even if that results in non-secure RTP media. 2. BEST-KEY is defined to interoperate with legacy RTP devices, and thus some of the protocol rules are modified, as described later in this document. 3. Depending on the final media-plane SRTP key mechanism chosen by the RTPSEC BOF or RAI, there may be a need to provide an indication or identifying data (e.g., fingerprint) for the media- plane mechanism in SDP. Such content is expected to be encoded along with the crtypo attributes of [secdes], on separate attribute lines. Since the media-plane mechanism is not chosen yet, those details are not yet known. 6. Offer/Answer Model for BEST-KEY: Stage 1 Kaplan Expires - January 2007 [Page 5] draft-kaplan-best-srtp-keys-00.txt July 2006 BEST-KEY is based on the offer/answer method as defined by RFC 4568 SDP Security Descriptions for Media Streams [secdes], except the use of SAVP or SAVPF transport type encoding in SDP is not typically used, as described above in section 5. This also changes some of the offer/answer details and RTP processing behavior as described below. 6.1 Generating the Initial Offer A device supporting this draft offers the same crypto attributes and parameters as [secdes] except using a non-secure transport encoding in SDP, such as "RTP/AVP". The purpose for this is so that, should the receiver(s) of the offer not support SRTP, the offer will not be rejected. The offerer can still decide to end the session at any time should it wish to, of course, but if the offerer wanted to mandate use of SRTP they MUST continue to use the [secdes] encoding of SAVP or SAVPF as before. There is no advantage (or difference) to using this draft over [secdes] in that case. Once an offer is generated with one or more crypto attributes using a non-secure transport encoding in SDP, the offerer MUST be ready to receive non-secure RTP if it would have done so had it not offered any crypto attributes. This is necessary for compatibility with receivers/answerers of the offer that do not support this draft, or do not support SRTP, and simply follows the basic model defined previously in RFC 3264. 6.2 Generating the Initial Answer As per [secdes], the answerer MUST accept one of the offered crypto attributes it can support, and the first one in the list it can support if there are more than one. If it cannot support any, however, it MUST accept the offer as if no crypto-attributes had been offered. In other words, if the answerer's local policy is to only allow SRTP media and not accept non-secure RTP, it may reject the offer. If the answerer's policy allows non-secure RTP, it can accept the offer as if it had been so. If the offer used an SAVP or SAVPF transport encoding in SDP, per [srtp] and [secdes], then it MUST operate as in [secdes] and answer using an SAVP or SAVPF encoding syntax. Thus an answerer supporting this draft will interoperate with an offerer supporting only legacy [secdes]. The answerer must then generate SRTP as it would have done in [secdes], and may optionally include an MKI in the SRTP per [secdes]. If the offer uses a non-secure transport encoding in SDP, but offered crypto attributes which were acceptable and answered, the answerer Kaplan Expires - January 2007 [Page 6] draft-kaplan-best-srtp-keys-00.txt July 2006 MUST generate SRTP packets using the answered information. The answerer MUST also include an MKI in the SRTP packets, but MAY stop doing so when it has an indication the offerer has received the answer. For example, receiving an SRTP packet from the offerer implies the offerer has received and processed the answer. If the answerer does not wish to continue using an MKI for the duration of the session, it MAY choose not to encode the MKI and length in the SDP attribute. In such a case, it MUST use an MKI value of 1 and length of 4 in the SRTP packets if it adds them. The reason for doing this is described in the next section. 6.3 Processing the Initial Answer As per [secdes], the answer is checked for matching crypto attributes and key information. If no crypto attribute lines are found in the answer, however, and the offered transport was a non-secure type (i.e., not SAVP) then the negotiation MUST NOT be considered to have failed. Instead, non-secure RTP is used as if the offer had not included any crypto attributes to begin with. If a crypto attribute line is found in the answer, but does not have a matching tag, included key, or contain all of the mandatory negotiated session parameters, then the negotiation MUST fail. This would represent a protocol failure. If a crypto attribute line is found in the answer, with a matching tag, valid key, and contains all the necessary negotiated session parameters, then the offerer MUST stop accepting non-secure RTP media and only accept SRTP using the key and other values in the answer, as described in [secdes]. The offerer would then begin generating SRTP as per [secdes] and [srtp]. An interesting property of the above rule is that it allows a call to start with non-secure RTP and "upgrade" to secdes-based SRTP without a second, updated offer being generated by the offerer – only an updated answer need be received. For example, using SIP, the Invite would offer this draft's SDP encoding, a 183 would contain a non- crypto answer in SDP, and the 200 ok would contain a crypto final answer. Such a case could be useful for rich-ringtone and early- announcement services in use today, which probably don't need secure RTP for ringtone. (unless it's a DRM issue :) Note: one would think this may cause a short period of no media, and degrade the service, but that is not the case. If non-secure RTP were actually being sent by the far-end, it means they received the offer and do not actually support SRTP or this draft; otherwise they would be using their key to transmit SRTP. Since the keys offered in [secdes] are the transmit keys, an offerer cannot truly process Kaplan Expires - January 2007 [Page 7] draft-kaplan-best-srtp-keys-00.txt July 2006 received SRTP until an answer is received regardless. Therefore this draft makes the situation no worse than [secdes], while still supporting non-secure early media for cases where the far-end does not support SRTP. A problem with accepting non-secure RTP before the answer, or upgrading to SRTP on a second answer, is that the SRTP media will most likely reach the offerer before the SDP answer indicating SRTP is accepted (and what the key is). Since SRTP packets follow the RTP packet format, such early packets would actually be decoded as RTP and possibly rendered, resulting in illegible audio tones and video display. This would not have occurred in [secdes] because non-secure RTP would not be accepted at all in that mechanism, and this new behavior is probably not acceptable in general. Therefore, per section 6.2, a device supporting BEST-KEY will add the MKI tag to SRTP packets when it is the answerer and the offer did not specify a secure transport. It is possible, though, that it does not encode the MKI value and length in the answer, if it did not wish to use an MKI for the duration of the session. In such a case it would use an MKI value 1 and a length of 4, and the offerer MUST recognize such as SRTP packets. The MKI is thus used as a RTP vs. SRTP differentiator, and a BEST-KEY offerer MUST NOT attempt to render such marked packets as un-encrypted RTP until it has received the decrypt key in the answer and handles it as SRTP. [Note: is this complexity worth it? Forcing MKI may raise the bar too much for easy changes to secdes-based devices. Maybe we should not support RTP until the answer.] 7. Media-Plane Key Update for BEST-KEY – Stage 2 After negotiating the initial SRTP keys through the offer/answer model using crypto attributes as described previously, the media- plane key exchange mechanism is initiated. Depending on the primary media-plane mechanism chosen by the IETF, this may only occur if the SDP included appropriate information to do so. If the media-plane mechanism chosen includes sufficient information in the SDP which could negotiate without using the crypto attribute provided keys, the crypto-attribute keys provided through SDP MUST be used if the media-plane mechanism fails to negotiate successfully. The only exception to this is if either end has a local policy to reject such a case, in which case the session MUST be explicitly terminated. The SDP exchange and key exchange per this draft is considered to have succeeded, so session signaling must be used to end the session. [Note: this will probably depend on the mechanism chosen in the end, so this will be cleaned up later] Kaplan Expires - January 2007 [Page 8] draft-kaplan-best-srtp-keys-00.txt July 2006 If the media-plane mechanism chosen does not include sufficient information in the SDP to immediately exchange SRTP media, the crypto-attribute provided keys MUST be used for RTP while the media- plane mechanism is attempted. This is necessary in case the far-end does not support the media-plane mechanism, and for early media support. Assuming the media-plane mechanism supports it, regardless of whether the received SDP offer or answer contained indication for BEST-KEY and SRTP, the media-plane mechanism MUST be attempted. This is to try to overcome any bid-down attack in the signaling-plane. This assumes the media-plane mechanism chosen is such that it can be attempted blindly without causing interoperability problems for legacy SRTP or RTP devices. [Note: that's a big assumption, maybe we shouldn't try this if signaling didn't agree] 8. Formal Syntax [Note: I'm not sure any formal syntax is warranted, is it? No ABNF changes from [secdes] anyway, though IANA registry might need a change] 9. Security Considerations Like [secdes], SDP using the mechanism in this draft is conveyed in an encapsulating application protocol which MUST provide both strong eavesdropping and authentication mechanisms. The security requirements in [secdes] MUST be followed for this draft as well. [Note: I'm considering relaxing that a bit, because it's (a) going to be ignored anyway, (b) not necessary for some situations, and (c) may not be necessary depending on the media-plane mechanism chosen. I'll have to think on it some more.] 9.1 Security Implications vs. RFC 4568 [secdes] The BEST-KEY mechanism proposed in this draft is less secure than [secdes] because it allows a bid-down attack to establish non-secure RTP sessions, even if both ends supported SRTP and BEST-KEY. This is by design, however, in order to facilitate interoperability. No mechanism proposed so far truly prevents a bid-down attack, as far as this author knows. The difference is that [secdes] and some other mechanisms would result in a failed session negotiation, whereas this mechanism would not. The author considers that a benefit of BEST- KEY, not a drawback. Neither party needs to accept a session using non-secure RTP: the offerer can simply use the [secdes] offer model of secure transport encoding in SDP, and the answerer can simply Kaplan Expires - January 2007 [Page 9] draft-kaplan-best-srtp-keys-00.txt July 2006 reject offers which do not offer a BEST-KEY or [secdes] offer; or either end can terminate the session or re-offer at any time. Those are local policy decisions which are available for any mechanism. A second issue is that this draft opens the possibility for a middle- man snooper to send non-secure RTP to the offerer, before the answer is received indicating SRTP should be used. Thus, even if the middle-man cannot view the SRTP-specific information in the SDP, he may be able to inject false RTP for a short time by guessing the media port (it's typically not hard to guess, as it's often a fixed offset from one used in a device's previous session). That is essentially unavoidable if we allow early media. 9.2 Security Implications vs. Media-plane Mechanisms Alone Like [secdes], BEST-KEY has specific security weaknesses. Unlike [secdes], BEST-KEY has the ability to use a more-secure key exchange mechanism if both ends can, while still providing SRTP support for those that cannot perform the media-plane mechanism, and fallback to RTP support for those that cannot perform SRTP at all. In particular, the following are recognized weaknesses of BEST-KEY and [secdes]: 1. The use of S/MIME is incredibly rare, SIPS is uncommon, and there is virtually no way to guarantee all the hops along the signaling path use TLS or IPSEC; even using TLS or IPSEC, if the SDP is passed through intermediate systems (proxies, b2bua's, etc.) without SDP-level encryption, then the intermediate systems have access to the keys, can modify them, etc. This is likely still more secure than sending them in the clear, but is an obvious point of vulnerability. The benefit of BEST-KEY is this only affects the media exchanged before a media-plane mechanism updates the keys, if a media-plane mechanism is available. 2. If the SDP is provided to more than one party, for example in a forked SIP request, then even the party which did not answer has access to the keys for media being generated by the offerer. This is similar to (1) above, and the benefit of BEST-KEY is the same as for (1) above. Furthermore, the offerer is free to create an updated offer with new keys at any time after session establishment, if she so wishes. 3. Unlike some other mechanisms which use the signaling-plane, it is not sufficient to only integrity protect BEST-KEY and [secdes], without also encryption. This means use of a mechanism such as sip- identity [zzzz] is not sufficient, because it leaves the SDP as cleartext. An eavesdropper need only see the SDP to be able to decrypt the SRTP streams, or even inject her own. Proponents of Kaplan Expires - January 2007 [Page 10] draft-kaplan-best-srtp-keys-00.txt July 2006 other signaling-based or media-plane-based mechanisms argue this makes an [secdes] style mechanism inferior. It should be noted, however, that sip-identity is neither ubiquitous today, nor would it actually provide end-to-end integrity protection. Sip-identity is expected to be typically signed by an intermediate system, such as the first-hop proxy, and possibly verified and re-signed by a last- hop proxy. Those systems can modify the contents of SDP at will; for example, SBCs are such intermediate systems. References [secdes] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Description for Media Streams", RFC 4568, July 2006 [sdp] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [srtp] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [sip] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [Note: I'm sure I forgot some... will add later if this gets taken as anything more than a straw-man] Author's Address Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803 Email: hkaplan@acmepacket.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights Kaplan Expires - January 2007 [Page 11] draft-kaplan-best-srtp-keys-00.txt July 2006 might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgments The author of this draft did not personally conceive the two-stage approach. He has been unable to find the originator of it, and so decided to write this draft as a straw-man for the RTPSEC focus group to move the process along. If you are the originator, and wish to take over editorial control, feel free to contact the current author; he will be more than happy to give credit and editorial responsibility to another. The "BEST-KEY" acronym however, is solely the author's fault. Kaplan Expires - January 2007 [Page 12]