idnits 2.17.1 draft-ietf-mmusic-opportunistic-negotiation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3551], [RFC3711], [RFC4585]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC4585, but the abstract doesn't seem to directly say this. It does mention RFC4585 though, so this could be OK. -- The draft header indicates that this document updates RFC4568, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4568, updated by this document, for RFC5378 checks: 2003-02-25) (Using the creation date from RFC4585, updated by this document, for RFC5378 checks: 2001-07-16) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 5, 2017) is 2488 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-sipbrandy-osrtp-02 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Hutton 3 Internet-Draft Unify 4 Updates: 4568,4585 (if approved) R. Jesske 5 Intended status: Standards Track Deutsche Telekom 6 Expires: December 7, 2017 A. Johnston 7 Unaffiliated 8 G. Salgueiro 9 Cisco 10 B. Aboba 11 Microsoft 12 June 5, 2017 14 Negotiating SRTP and RTCP Feedback using the RTP/AVP Profile 15 draft-ietf-mmusic-opportunistic-negotiation-00 17 Abstract 19 This document describes how the use of the Secure Real-time transport 20 protocol (SRTP) [RFC3711]. can be negotiated using the AVP (Audio 21 Video Profile) defined in [RFC3551]. Such a mechanism is used to 22 provide a means for encrypted media to be used in environments where 23 support for encryption is not known in advance, and not required. 24 The same mechanism is also applied to negotiation of the Extended RTP 25 Profile for Real-time Transport Control Protocol Based Feedback (RTP/ 26 AVPF) [RFC4585]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 7, 2017. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Normative Language . . . . . . . . . . . . . . . . . . . . . 3 64 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Use of RTP/AVP profile with SRTP . . . . . . . . . . . . . . 3 66 5. Use of RTP/AVP profile with RTCP Feedback . . . . . . . . . . 4 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 4 72 9.2. Informative References . . . . . . . . . . . . . . . . . 5 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 75 1. Introduction 77 Opportunistic Security [RFC7435] is an approach to security that 78 defines a third mode for security between "cleartext" and 79 "comprehensive protection" that allows encryption and authentication 80 to be used if supported but will not result in failures if it is not 81 supported. In terms of secure media, cleartext is RTP [RFC3550] 82 media which is negotiated with the AVP (Audio Video Profile) profile 83 defined [RFC3551]. Comprehensive protection is Secure RTP [RFC3711], 84 negotiated with a secure profile, such as SAVP or SAVPF [RFC5124]. 86 [I-D.ietf-sipbrandy-osrtp] describes how Secure Real-time transport 87 protocol (SRTP) can be negotiated opportunistically. 89 [RFC4568] however requires that SRTP is only negotiated using the 90 RTP/SAVP profile [RFC3711] or the RTP/SAVPF profile [RFC5124]. This 91 document relaxes this rule by allowing SRTP to be used with the RTP/ 92 AVP profile when negotiated opportunistically. 94 Similarly [RFC4585] requires that the RTCP extended reports are only 95 used in media sessions for which the "AVPF" profile is specified. 96 This document therefore also relaxes this rule allowing RTCP based 97 feedback to be used with the RTP/AVP profile. 99 2. Normative Language 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in BCP 14, RFC 2119 104 [RFC2119]. 106 3. Motivation 108 In theory SDP [RFC4566] allows different RTP profiles such as SAVP, 109 AVPF, and AVP to be offered as separate m-lines, and allows the 110 answerer to reject profiles it does not support or does not wish to 111 use. However the use of multiple m-lines for such a negotiation is 112 not well defined and implementations receiving such an offer are 113 likely to reject the SDP Offer rather than use the profile they 114 support. This negotiation failure has been observed when negotiating 115 the secure profile (SAVP) and also when negotiating RTCP based 116 feedback messages [RFC4585] (RTP/AVPF) or both (RTP/SAVPF). 118 To avoid using multiple m-lines to negotiate RTP profiles this draft 119 recognized that existing implementation of SRTP, and RTCP feedback, 120 make use of the relevant SDP attributes to indicate such 121 capabilities. The approach therefore taken in this draft uses the 122 "a=" lines in SDP to negotiate these capabilities in a single offer/ 123 answer exchange, by offering the AVP profile but indicating the 124 supported functionality in a=lines. 126 4. Use of RTP/AVP profile with SRTP 128 To negotiate SRTP in an opportunistic way such as that described in 129 [I-D.ietf-sipbrandy-osrtp] requires a fallback to unencrypted media 130 to occur if the remote endpoint does not support SRTP. 132 Therefore when negotiating SRTP opportunistically the SDP offerer 133 MUST use the AVP profile [RFC3551]. This is independent of the key 134 exchange mechanism used. 136 The SDP answerer MUST use the AVP profile if it does not encrypt the 137 media and MAY use the AVP if it encrypts the media. The exact 138 negotiation mechanism is however outside the scope of this document, 139 an example mechanism can be found in [I-D.ietf-sipbrandy-osrtp]. 141 5. Use of RTP/AVP profile with RTCP Feedback 143 Negotiating the use of the Extended RTP Profile for RTCP Based 144 Feedback (RTP/AVPF) [RFC4585] opportunistically also requires the 145 offerer to use the AVP profile otherwise the offer is likely to be 146 rejected by an answerer who does not support AVPF. 148 Therefore when negotiating RTCP Based Feedback opportunistically the 149 SDP offerer MUST use the AVP profile [RFC3551] and include the 150 "a=rtcp-fb" SDP attribute as described in [RFC4585]. 152 The SDP answerer indicates support for RTCP Based Feedback by 153 including the "a=rtcp-fb" SDP attribute in the SDP Answer. The RTP 154 profile in the SDP answer MAY be set to AVP (SAVP) or AVPF (SAVPF). 156 This is an update to [RFC4585] which requires that the "a=rtcp-fb" 157 attribute is only used with the AVPF profile. All other [RFC4585] 158 procedures remain unchanged. 160 6. IANA Considerations 162 None 164 7. Security Considerations 166 The security considerations of [RFC7435] apply to any opportunistic 167 approach to SRTP. 169 It is important to note that negotiating SRTP in an opportunistic way 170 makes no changes, and has no effect on media sessions in which the 171 offer contains a secure profile of RTP, such as SAVP or SAVPF. As 172 discussed in [RFC7435] this is the "comprehensive protection" for 173 media mode. 175 8. Acknowledgements 177 This document is dedicated to our friend and colleague Francois Audet 178 who is greatly missed in our community. His work on improving 179 security in SIP and RTP provided the foundation for this work. 181 9. References 183 9.1. Normative References 185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 186 Requirement Levels", BCP 14, RFC 2119, 187 DOI 10.17487/RFC2119, March 1997, 188 . 190 9.2. Informative References 192 [I-D.ietf-sipbrandy-osrtp] 193 Johnston, A., Aboba, B., Hutton, A., Jesske, R., and T. 194 Stach, "An Opportunistic Approach for Secure Real-time 195 Transport Protocol (OSRTP)", draft-ietf-sipbrandy-osrtp-02 196 (work in progress), May 2017. 198 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 199 Jacobson, "RTP: A Transport Protocol for Real-Time 200 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 201 July 2003, . 203 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 204 Video Conferences with Minimal Control", STD 65, RFC 3551, 205 DOI 10.17487/RFC3551, July 2003, 206 . 208 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 209 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 210 RFC 3711, DOI 10.17487/RFC3711, March 2004, 211 . 213 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 214 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 215 July 2006, . 217 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 218 Description Protocol (SDP) Security Descriptions for Media 219 Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, 220 . 222 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 223 "Extended RTP Profile for Real-time Transport Control 224 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 225 DOI 10.17487/RFC4585, July 2006, 226 . 228 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 229 Real-time Transport Control Protocol (RTCP)-Based Feedback 230 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 231 2008, . 233 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 234 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 235 December 2014, . 237 Authors' Addresses 239 Andrew Hutton 240 Unify 241 Brickhill Street 242 Milton Keynes MK15 0DJ 243 UK 245 Email: andrew.hutton@unify.com 247 Roland Jesske 248 Deutsche Telekom 249 Heinrich-Hertz-Strasse 3-7 250 Darmstadt 64295 251 Germany 253 Email: R.Jesske@telekom.de 255 Alan Johnston 256 Unaffiliated 257 Bellevue, WA 258 USA 260 Email: alan.b.johnston@gmail.com 262 Gonzalo Salgueiro 263 Cisco 264 7200-12 Kit Creek Road 265 RTP, NC 27709 266 USA 268 Email: gsalguei@cisco.com 270 Bernard Aboba 271 Microsoft 272 One Microsoft Way 273 Redmond, WA 98052 274 USA 276 Email: bernard.aboba@gmail.com