idnits 2.17.1 draft-ietf-mmusic-opportunistic-negotiation-01.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 (September 14, 2017) is 2414 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 / Atos 4 Updates: 4568,4585 (if approved) R. Jesske 5 Intended status: Standards Track Deutsche Telekom 6 Expires: March 18, 2018 A. Johnston 7 Rowan University 8 G. Salgueiro 9 Cisco 10 B. Aboba 11 Microsoft 12 September 14, 2017 14 Negotiating SRTP and RTCP Feedback using the RTP/AVP Profile 15 draft-ietf-mmusic-opportunistic-negotiation-01 17 Abstract 19 This document describes how the use of the Secure Real-time transport 20 protocol (SRTP) [RFC3711]. can be negotiated using the RTP/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 https://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 March 18, 2018. 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 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 RTP/AVP (Audio Video Profile) 83 profile defined [RFC3551]. Comprehensive protection is Secure RTP 84 [RFC3711], negotiated with a secure profile, such as RTP/SAVP or RTP/ 85 SAVPF [RFC5124]. 87 [I-D.ietf-sipbrandy-osrtp] describes how Secure Real-time transport 88 protocol (SRTP) can be negotiated opportunistically. 90 [RFC4568] however requires that SRTP is only negotiated using the 91 RTP/SAVP profile [RFC3711] or the RTP/SAVPF profile [RFC5124]. This 92 document relaxes this rule by allowing SRTP to be used with the RTP/ 93 AVP profile when negotiated opportunistically. 95 Similarly [RFC4585] requires that the RTCP extended reports are only 96 used in media sessions for which the RTP/AVPF profile is specified. 97 This document therefore also relaxes this rule allowing RTCP based 98 feedback to be used with the RTP/AVP profile. 100 2. Normative Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in BCP 14, RFC 2119 105 [RFC2119]. 107 3. Motivation 109 In theory SDP [RFC4566] allows different RTP profiles such as RTP/ 110 SAVP, RTP/AVPF, and RTP/AVP to be offered as separate m-lines, and 111 allows the answerer to reject profiles it does not support or does 112 not wish to use. However the use of multiple m-lines for such a 113 negotiation is not well defined and implementations receiving such an 114 offer are likely to reject the SDP Offer rather than use the profile 115 they support. This negotiation failure has been observed when 116 negotiating the secure profile (RTP/SAVP) and also when negotiating 117 RTCP based feedback messages [RFC4585] (RTP/AVPF) or both (RTP/ 118 SAVPF). 120 To avoid using multiple m-lines to negotiate RTP profiles this draft 121 recognized that existing implementation of SRTP, and RTCP feedback, 122 make use of the relevant SDP attributes to indicate such 123 capabilities. The approach therefore taken in this draft uses the 124 "a=" lines in SDP to negotiate these capabilities in a single offer/ 125 answer exchange, by offering the RTP/AVP profile but indicating the 126 supported functionality in a=lines. 128 4. Use of RTP/AVP profile with SRTP 130 To negotiate SRTP in an opportunistic way such as that described in 131 [I-D.ietf-sipbrandy-osrtp] requires a fallback to unencrypted media 132 to occur if the remote endpoint does not support SRTP. 134 Therefore when negotiating SRTP opportunistically the SDP offerer 135 MUST use the RTP/AVP profile [RFC3551]. This is independent of the 136 key exchange mechanism used. 138 The SDP answerer MUST use the RTP/AVP profile if it does not encrypt 139 the media and MAY use the RTP/AVP if it encrypts the media. The 140 exact negotiation mechanism is however outside the scope of this 141 document, an example mechanism can be found in 142 [I-D.ietf-sipbrandy-osrtp]. 144 5. Use of RTP/AVP profile with RTCP Feedback 146 Negotiating the use of the Extended RTP Profile for RTCP Based 147 Feedback (RTP/AVPF) [RFC4585] opportunistically also requires the 148 offerer to use the RTP/AVP profile otherwise the offer is likely to 149 be rejected by an answerer who does not support RTP/AVPF. 151 Therefore when negotiating RTCP Based Feedback opportunistically the 152 SDP offerer MUST use the RTP/AVP profile [RFC3551] and include the 153 "a=rtcp-fb" SDP attribute as described in [RFC4585]. 155 The SDP answerer indicates support for RTCP Based Feedback by 156 including the "a=rtcp-fb" SDP attribute in the SDP Answer. The RTP 157 profile in the SDP answer MAY be set to RTP/AVP (SAVP) or RTP/AVPF 158 (SAVPF). 160 This is an update to [RFC4585] which requires that the "a=rtcp-fb" 161 attribute is only used with the RTP/AVPF profile. All other 162 [RFC4585] procedures remain unchanged. 164 6. IANA Considerations 166 None 168 7. Security Considerations 170 The security considerations of [RFC7435] apply to any opportunistic 171 approach to SRTP. 173 It is important to note that negotiating SRTP in an opportunistic way 174 makes no changes, and has no effect on media sessions in which the 175 offer contains a secure profile of RTP, such as RTP/SAVP or RTP/ 176 SAVPF. As discussed in [RFC7435] this is the "comprehensive 177 protection" for media mode. 179 8. Acknowledgements 181 This document is dedicated to our friend and colleague Francois Audet 182 who is greatly missed in our community. His work on improving 183 security in SIP and RTP provided the foundation for this work. 185 9. References 187 9.1. Normative References 189 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 190 Requirement Levels", BCP 14, RFC 2119, 191 DOI 10.17487/RFC2119, March 1997, 192 . 194 9.2. Informative References 196 [I-D.ietf-sipbrandy-osrtp] 197 Johnston, A., Aboba, B., Hutton, A., Jesske, R., and T. 198 Stach, "An Opportunistic Approach for Secure Real-time 199 Transport Protocol (OSRTP)", draft-ietf-sipbrandy-osrtp-02 200 (work in progress), May 2017. 202 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 203 Jacobson, "RTP: A Transport Protocol for Real-Time 204 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 205 July 2003, . 207 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 208 Video Conferences with Minimal Control", STD 65, RFC 3551, 209 DOI 10.17487/RFC3551, July 2003, 210 . 212 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 213 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 214 RFC 3711, DOI 10.17487/RFC3711, March 2004, 215 . 217 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 218 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 219 July 2006, . 221 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 222 Description Protocol (SDP) Security Descriptions for Media 223 Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, 224 . 226 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 227 "Extended RTP Profile for Real-time Transport Control 228 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 229 DOI 10.17487/RFC4585, July 2006, 230 . 232 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 233 Real-time Transport Control Protocol (RTCP)-Based Feedback 234 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 235 2008, . 237 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 238 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 239 December 2014, . 241 Authors' Addresses 243 Andrew Hutton 244 Unify / Atos 245 4 Triton Square 246 London NW1 3HG 247 UK 249 Email: andrew.hutton@atos.net 251 Roland Jesske 252 Deutsche Telekom 253 Heinrich-Hertz-Strasse 3-7 254 Darmstadt 64295 255 Germany 257 Email: R.Jesske@telekom.de 259 Alan Johnston 260 Rowan University 261 Glassboro, NJ 262 USA 264 Email: alan.b.johnston@gmail.com 266 Gonzalo Salgueiro 267 Cisco 268 7200-12 Kit Creek Road 269 RTP, NC 27709 270 USA 272 Email: gsalguei@cisco.com 273 Bernard Aboba 274 Microsoft 275 One Microsoft Way 276 Redmond, WA 98052 277 USA 279 Email: bernard.aboba@gmail.com