idnits 2.17.1 draft-kaplan-mmusic-best-effort-srtp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 766. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 743. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 750. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 756. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 2006) is 6403 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) == Unused Reference: 'RFC3550' is defined on line 676, but no explicit reference was found in the text == Unused Reference: 'RFC4585' is defined on line 689, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group H. Kaplan 3 Internet Draft Acme Packet 4 Expires: April 2007 F. Audet 5 Nortel Networks 6 October 2006 8 Session Description Protocol (SDP) Offer/Answer Negotiation 9 For Best-Effort Secure Real-Time Transport Protocol 10 draft-kaplan-mmusic-best-effort-srtp-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on February 24, 2007. 37 Abstract 39 This document defines the requirements and a proposed solution for 40 an SDP Offer/Answer exchange model for negotiating best-effort SRTP 41 keys, i.e., in a backward-compatible manner with non-SRTP devices. 42 The proposed solution is a trivial interpretation of the usage of 43 the profile and the usage of SDP indication of [sdesc] and [kmgmt]. 45 Table of Contents 47 1. Introduction................................................2 48 2. Notational Conventions......................................4 49 3. Applicability...............................................5 50 4. Requirements................................................5 51 5. Solution Overview...........................................6 52 6. SRTP Attribute..............................................7 53 7. Offer/Answer Model:.........................................8 54 7.1. Generating the Initial Offer...........................8 55 7.1.1 Offering Unique SRTP Payload Types................... 9 56 7.2. Generating the Initial Answer..........................9 57 7.2.1 Answering Unique SRTP Payload Types................. 10 58 7.3. Processing the Initial Answer.........................11 59 8. Forked Offers and Multiple Answers.........................12 60 9. Clipping and Changing Transport Types......................12 61 10. Example Offer/Answer Exchange..............................12 62 11. Security Considerations....................................14 63 11.1. Security Implications vs. [sdesc] and [kmgmt].........14 64 12. References.................................................15 65 12.1. Normative References..................................15 66 12.2. Informative References................................15 67 Author's Address.................................................16 68 Intellectual Property Statement..................................16 69 Disclaimer of Validity...........................................17 70 Copyright Statement..............................................17 71 Acknowledgments..................................................17 73 1. Introduction 75 The support of SRTP has been increasing recently, but its adoption 76 has still been relatively slow. One of the reasons for this is that 77 the currently defined mechanisms for exchanging SRTP keys are based 78 on an all-or-nothing approach, i.e., "Always secure" or "Always not 79 secure". If the offer indicates SRTP and the answerer cannot 80 support SRTP, or the particular key exchange mechanism, the entire 81 offer, or the actual session invitation, will fail. When the 82 desired policy is "Always secure", the current established mechanism 83 works perfectly well. 85 However, a need has been identified for a third policy: "Best-Effort 86 Security". Best Effort Security means that you prefer that SRTP be 87 used, but you are willing to use RTP if the other end does not 88 support it. There are different reasons why one may wish to use a 89 Best Effort policy. It could be to allow for interoperability with 90 many devices that may not support SRTP. In other cases, it may be as 91 a migration strategy or introducing new equipment that support SRTP, 92 cohabitating with devices that do not support SRTP until the older 93 equipment is replaced. 95 Today, there is no generally accepted (and backward compatible) way 96 to indicate Best Effort SRTP key negotiation. Therefore, an SRTP- 97 capable device must either be prepared to re-attempt to establish a 98 media stream with RTP after failing with SRTP, or simply not offer 99 SRTP by default, and upgrade to SRTP when possible. 101 With the current mechanism, it may in the best case be possible to 102 start without SRTP initially (i.e., with the AVP [rtp] profile), and 103 then negotiate through another Offer/Answer [RFC3264] with either 104 [kmgmt] or [sdesc] the usage of SRTP and the session keys. This is 105 an extremely cumbersome process, and has the implication that every 106 call will use an additional Offer/Answer exchange, and will also 107 have the consequence that every call will start without SRTP, which 108 is undesirable. 110 Also with the current mechanism, starting with SRTP (i.e., the SAVP 111 profile) and downgrading to RTP is only achievable by rejecting the 112 whole session. However, rejecting a session in SIP (normally with a 113 4XX response code), has very negative implications because of the 114 [herfp] issue. To summarize the issue [herfp] means that the 115 rejection sent by the UAS, when used with forking, is very unlikely 116 to reach the UAC. Since that rejection is intended to cause a re- 117 negotiation without SRTP, the net effect is that the call fork fails 118 completely. In the best case scenario, another fork may answer 119 (e.g., a voicemail system), and in the worst case scenario, the 120 other forks also fails, which means that the calls fails entirely. 121 This is clearly unacceptable and a great impediment to the 122 deployment of SRTP. Note that this is an issue for both parallel 123 and sequential forking. 125 Note: Some may argue that one may reject the Offer setting the 126 port in the answer to zero as per [RFC3264], and then do a second 127 Offer/Answer; however, since the endpoints that do not support 128 the SAVP profile most likely do not behave this way in the first 129 place (they will reject the whole session), this means it would 130 not be backward compatible to use an Offer rejection mechanism. 131 Furthermore, many UAs automatically generate a BYE if they 132 receive an SDP answer with no accepted media lines 134 This document proposes a solution to Best Effort SRTP and backward 135 compatibility problem by introducing a third Policy to the existing 136 ones. 138 The existing supported mechanisms as of today are as follows: 139 * SAVP (and associated keys) means secure transport only, i.e. 140 "SRTP only" 141 * AVP means insecure transport only, i.e. "RTP only" 143 This drafts proposes a Third mechanism: 144 * AVP with associated SRTP attributes means "Best-Effort SRTP" 146 The mechanism outlined in this document is fairly trivial, and is 147 defined in order to successfully negotiate multiple mechanisms in 148 one offer/answer exchange, even if the answerer only supports 149 clear/non-secure RTP, and it is backward compatible. Examples are 150 given for [kmgmt] and [sdesc]. This mechanism only applies to 151 Offer/Answer-based applications. 153 The procedures described in this specification represent a technique 154 that has already been used and deployed in the real-world. It has 155 also been briefly mentioned in [sdp-neg], which lists many 156 techniques used today. Of all the techniques described in [sdp-neg], 157 it is by far the simplest one to address the "Best Effort SRTP" 158 problem, and the only one that does not risk "breaking" any 159 implementations. 161 It has been argued in [sdp-neg] that using "RTP/AVP" violates 162 [srtp]. After reviewing [srtp], the authors could not find any 163 justification to this claim. Rather, the authors claim that "if 164 SAVP is indicated, we can infer that SRTP is to be used, but the 165 reverse is not necessarily true, i.e., if AVP is used, it does not 166 mean that SRTP will not be used". In other words, there is a well- 167 defined encoding for using SRTP which is "SAVP", but that does not 168 preclude an offerer from offering "AVP" and proposing SRTP 169 dynamically. RFC 3407 [sim-cap] essentially already allows such a 170 model, whereby the backward-compatible encoded media profile may be 171 of one type, while the [sim-cap] offered alternate capability may 172 change the profile for those that understand [sim-cap]. This draft 173 essentially employs a similar model, but using the [sdesc] or 174 [kmgmt] attributes as the explicit alternate profile offer. It 175 should also be noted that [zrtp] already uses AVP for SRTP traffic. 177 A second requirement of this draft allows the offerer to indicate to 178 the answerer to use unique payload types for SRTP packets, in order 179 to make them distinguishable from clear RTP packets. This is 180 mandatory if the offerer needs to render media before receiving the 181 answer, and cannot do so until it has the keys in the answer to do 182 so. 184 2. Notational Conventions 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in RFC 2119. The 189 terminology in this document conforms to RFC 2828, "Internet 190 Security Glossary". 192 3. Applicability 194 This draft proposes using a [sdesc]/[kmgmt] style key exchange in a 195 backward-compatible manner with legacy RTP devices, for Offer/Answer 196 exchange-based applications. This mechanism should provide a 197 smoother migration path, broader applicability, and more rapid 198 acceptance than [sdesc] or [kmgmt] mechanism used only in the "SRTP 199 only" mode. 201 The rules of this specification apply to AVP/SAVP. 203 OPEN ISSUE: The same technique arguably could be used with AVPF 204 [RFC4585]/SAVPF[savpf]. Should it? We have assumed only 205 AVP/SAVP, but it could easily be expanded to cover 206 AVPF/SAVPF. 208 4. Requirements 210 Unlike the requirements addressed in [sdpng] and [sdp-cap-neg], this 211 mechanism is not trying to address all the general issues with SDP 212 capability negotiation. Instead, it is trying to provide a solution 213 to a very short and defined set of requirements: 215 REQ-1: It MUST be possible to indicate and negotiate RTP vs. SRTP 216 profiles, on a per media stream basis. 218 REQ-2: It MUST be possible to offer SRTP profile to an RTP-only 219 answerer, and successfully negotiate RTP, without additional 220 offer/answers. 222 REQ-3: It MUST be possible to offer SRTP without allowing a fallback 223 to RTP, if the answerer does not support SRTP but the offerer only 224 wishes to either use SRTP or fail the negotiation. 226 REQ-4: The mechanism MUST be backwards compatible for SIP RTP-only 227 devices, without requiring them to change. 229 REQ-5: The mechanism MUST be media-type agnostic. (i.e., work with 230 any media type of any codec, etc.) 232 REQ-6: The mechanism MUST work in the presence of SIP forking. 234 REQ-7: The mechanism SHOULD support RTCP-based feedback, e.g. AVPF. 235 OPEN ISSUE: Should REQ-7 be a requirement? 236 We believe the above to be the necessary and sufficient requirements 237 set to achieve broad applicability and deployment of SRTP in the 238 near future. Below, we provide a proposed solution meeting those 239 requirements. 241 5. Solution Overview 243 The basic concept is: 245 If an SRTP-capable device wishes to *only* offer SRTP and will only 246 accept SRTP be used, then it performs exactly the same steps as 247 defined in [sdesc] or [kmgmt], including indicating the SAVP 248 profile. The answerer would do the same. This is per current 249 practice. 251 If a device wishes to offer RTP only, then it uses the AVP profile, 252 and does not use [sdesc] or [kmgmt]. The answerer does the same. 253 This is also per current practice. 255 If an SRTP-capable device wishes to offer SRTP but will accept an 256 RTP answer if the far-end only supports that for a given media 257 stream, then it indicates SRTP support as an alternative, by 258 inserting the same media-level crypto attributes of [sdesc] or key 259 management attributes of [kmgmt], or both, into the offer using non- 260 secure transport profiles (e.g., "AVP" instead of "SAVP"). The 261 offerer may also indicate SAVP support for media lines when a 262 session-level key is used, using a new attribute. The offerer may 263 also indicate unique Payload Type mapping values for SRTP/SRTCP 264 packets in a new attribute, if she wishes to distinguish SRTP from 265 RTP before the SDP answer comes back. 267 A legacy RTP-only device will ignore these unknown attributes and 268 answer as if they did not exist, i.e. using the "AVP" profile 269 without any crypto or key-mgmt attributes. The offerer then knows 270 they don't support it and will establish the session using regular 271 RTP. 273 A device supporting this draft and SRTP understands the attributes 274 indicate a willingness to use the SAVP profile instead, and responds 275 accordingly, by including a crypto or key-mgmt attribute in the 276 answer (but still using "AVP" encoding), resulting in SRTP. If the 277 offer included the payload type mappings, the answerer would use 278 them for SRTP packets. 280 * The main difficulty with offering SRTP-attributes using non- 281 secure transport profiles is that SRTP packets are virtually 282 indistinguishable from RTP packets - there is no "SRTP flag". 283 That means the offerer must either wait for the answer before 284 knowing how to handle received RTP packets, or a distinguishing 285 factor must be defined. This specification supports both models, 286 by allowing the offerer to indicate its preference, and mandating 287 the answerer support both. 289 6. SRTP Attribute 291 This draft introduces a new media-level SRTP attribute ("a=srtp"), 292 for the purpose of indicating SRTP is desired for a media stream 293 when it would otherwise be ambiguous, and for indicating payload 294 type mappings for the RTP payload types in the m= media line. 295 Examples of the new attribute are as follows: 296 a=srtp 297 a=srtp: map:0=96,18=97,101=102 299 The first example shows the attribute being used solely to indicate 300 the associated media line is capable of SRTP. 302 The second example indicates the associated media line is capable of 303 SRTP, and if SRTP is used, it will accept/receive SRTP on payload 304 type 96 for SRTP in place of payload type 0 (PCMU), 97 for 18 305 (G729), and 102 for 101. 307 Following the ABNF rules used in [sdp], the new attribute is defined 308 in ABNF as follows: 309 att-field = "srtp" 310 att-value = space srtp-options 311 srtp-options = srtp-payload-mapping | ([srtp-payload- 312 mapping] 1*(byte-string)) 313 srtp-payload-mapping = "map:" map-list 314 map-list = map *("," map) 315 map = rtp-pt "=" srtp-pt 316 rtp-pt = 1*3(DIGIT) 317 srtp-pt = 1*3(DIGIT) 318 ;typically dynamic payload types 319 ;in the range 96-127 321 Note that, per the ABNF definition of attribute in [sdp], the att- 322 value field is optional. Thus having both "a=srtp" and "a=srtp:..." 323 forms is legitimate. The is optional if more 324 byte-strings are present, in case some future extension of this 325 attribute does not need the mapping but wishes to use the srtp- 326 capability semantic. 328 The srtp attribute payload mapping list identifies which payload 329 type numbers offered in the m= media line should be replaced with 330 different payload type numbers if SRTP is chosen. As such, the rtp- 331 pt (RTP payload type) values MUST correspond to fmt payload types in 332 the media-description line in an SDP offer. The srtp-pt (SRTP 333 payload type) values MUST be in the dynamic payload type range of 334 96-101, unless that is insufficient. The srtp-pt numbers MUST NOT 335 conflict with any of the offered fmt RTP payload type numbers. 337 7. Offer/Answer Model: 339 This draft is based on the offer/answer method of [RFC3264] as used 340 by [sdesc] and [kmgmt], except the use of secure transport (e.g., 341 "SAVP") type encoding in SDP is not always used, as described above 342 in section 6 and detailed below. This also changes some of the 343 offer/answer details and RTP processing behavior as described below. 345 7.1. Generating the Initial Offer 347 If a device supporting this draft wanted to mandate use of secure 348 transport (i.e., SRTP) for a particular media stream they MUST 349 continue to use the [sdesc] or [kmgmt] prescribed secure transport 350 encoding, i.e. "SAVP", as before. 352 A device supporting this draft that wishes to use secure transport 353 if the answerer supports it, but is willing to accept non-secure 354 transport otherwise (i.e., best effort SRTP), offers the same media- 355 level crypto attributes and parameters as [sdesc], and/or media- 356 level key-mgmt attributes of [kmgmt], except that it will indicate 357 the "RTP/AVP" profile in SDP. The purpose of this is that, should 358 the receiver(s) of the offer not support SRTP, or not support it for 359 that particular media stream, the offer will not be rejected. The 360 offerer can still decide to end the session at any time should it 361 wish to. 363 An offerer MAY offer both [sdesc] crypto attributes and [kmgmt] key- 364 mgmt attributes in the same SDP offer, for the same media sessions. 365 The offerer SHOULD order them in the order it prefers - the first 366 type offered is the most preferred, per media stream. 368 A potential complication is that KMGMT allows for supporting either 369 session level key management, media level key management, or both. 370 When used with best-effort negotiation and in conjunction with 371 [sdesc], an explicit indication is needed to indicate which media 372 streams are potential SRTP candidates, when session-level [kmgmt] is 373 used. This specification requires that if Best Effort SRTP is used, 374 and session-level keys are offered, then a media-level srtp 375 attribute MUST be included in the offer for each media stream the 376 offerer wishes to offer SRTP for. If both session-level and media- 377 level attributes are offered, for example a session-level key-mgmt 378 and media-level crypto, the srtp attribute encoding MUST be used for 379 every media stream the offerer wishes to use SRTP for. Note that 380 the media-level key will always be assumed to be more preferred than 381 the session-level one. An offerer MAY include the srtp attribute 382 for any media stream it wishes to offer SRTP for, even if it is not 383 offering a session-level key type. 385 7.1.1 Offering Unique SRTP Payload Types 387 In general, the offerer cannot definitively know whether the 388 received media is SRTP or RTP until it receives the answer, because 389 there is no distinguishing factor in the packets. If the offerer 390 wishes to render media before an SDP answer is received, it MUST 391 also include the srtp attribute with the payload mapping list, 392 defined earlier, to indicate unique SRTP payload types for the same 393 offered payloads as the media line. This will indicate to the 394 answerer which payload types to use for SRTP packets, if it accepts 395 the offer using SRTP. The offerer can then safely render RTP media 396 before the answer arrives, for payload types in the media line, 397 while ignoring received packets using the SRTP payload types mapped 398 in the srtp-attribute types until the answer arrives with the key to 399 decrypt SRTP. If the key type used is such that the offerer can 400 decrypt SRTP before the answer, the offerer MAY render it at any 401 time. If the offerer does not wish to render media until an answer 402 is received, it is OPTIONAL whether to include the payload mapping 403 list. 405 OPEN ISSUE: do we even make it optional, or mandate that the 406 offerer always include the mapping list? 408 In summary, the offerer encodes a secure transport type (SAVP) for 409 every media stream it demands be secured, while encoding a non- 410 secure transport type (AVP) but with the crypto and/or key-mgmt 411 attributes for every media stream it would accept non-secure 412 transport for. If it offers session-level keys, it includes the 413 srtp attribute for each media line it would have previously used 414 SAVP for. The offerer also indicates unique payload types for SRTP 415 media in the srtp attribute, if it needs to distinguish RTP from 416 SRTP before the answer arrives. 418 7.2. Generating the Initial Answer 420 If the offer contained both crypto and key-mgmt attributes, it is up 421 to answerer's local policy which key mechanism the answerer wishes 422 to use. The answerer SHOULD accept the first one in the offer it 423 understands and can support, per media stream. It MUST only encode 424 the like attribute type it chose to use for SRTP per media stream, 425 in the answer. In other words, it cannot choose both crypto and 426 key-mgmt for the same media stream. 428 Regardless of local-policy preference for which particular key type 429 to accept, the answerer MUST accept either one or the other if it 430 can. In other words, the offerer has indicated it wishes to use 431 SRTP, and the answerer MUST agree to do so if possible. 433 As per [sdesc] and [kmgmt], if the answerer chooses to accept crypto 434 attributes or key-mgmt, it MUST use the first attribute in the 435 offered list of attributes per media stream it can support if there 436 are more than one offered attributes for a given key exchange type. 437 For example if two crypto-style keys are offered for a given media 438 stream, the answerer must select the first one it supports. 440 If it cannot support any of the offered crypto or key-mgmt 441 attributes, however, it MUST treat the offer as if *no* crypto- 442 attributes had been offered. In other words, if the answerer's 443 policy allows non-secure RTP, it can accept the offer as if it had 444 been so. If the answerer's local policy is to only allow SRTP media 445 and not accept non-secure RTP, it MAY reject the offer. This lets a 446 key-mgmt-only offerer successfully negotiate non-secure RTP with a 447 crypto-only answerer, and vice-versa. 449 If the offer used a secure transport encoding in SDP, per [sdesc] or 450 [kmgmt], then it MUST operate as in [sdesc] or [kmgmt] and answer 451 using a secure transport encoding syntax if it can for the same 452 media stream, or fail the offer. Thus an answerer supporting this 453 draft will interoperate with an offerer supporting only legacy 454 [sdesc] or [kmgmt]. 456 If the offer uses best effort SRTP (using RTP/AVP profile), but 457 offered crypto or key-mgmt attributes which were acceptable and 458 answered, the answerer encodes its chosen key type and values and 459 MUST continue to use the insecure transport encoding, i.e., the 460 RTP/AVP profile. If the offer included the srtp attribute, the 461 answerer MUST include the srtp attribute for each media stream the 462 answerer wishes to use SRTP for. 464 7.2.1 Answering Unique SRTP Payload Types 466 If the offer indicated unique payload types for SRTP, by including 467 the srtp attribute and payload mapping list, the answerer MUST use 468 the indicated payload types for SRTP packets it sends, if it accepts 469 the SRTP offer. This is so that the offerer can distinguish RTP 470 from SRTP packets arriving before the answer, which can often be the 471 case. If the answerer used the same payload types for SRTP packets 472 as indicated in the m= media line, the offerer would attempt to 473 render them as RTP, which would produce a degraded user experience. 475 The answerer MUST answer such an offer using the actual/real payload 476 types it is going to use for RTP or SRTP packets. Therefore, if it 477 selects to use SRTP and the offerer indicated payload type mappings 478 in the srtp attribute, the answerer will answer using the srtp- 479 specific payload type values in the m= media line of its answer. 481 If the offer included the optional payload mappings in an srtp 482 attribute, the answerer MUST include the srtp attribute for each 483 media stream the answerer wishes to use SRTP for, with the same 484 payload mappings, for those formats it is answering with. 486 7.3. Processing the Initial Answer 488 As per [sdesc] and [kmgmt], the answer is checked for matching 489 crypto or key-mgmt attributes and key information. If the answer 490 uses the RTP/AVP profile, and no crypto or key-mgmt attribute lines 491 are found in the answer, however, and the originally offered 492 transport was "AVP", then the negotiation MUST NOT be considered to 493 have failed. Instead, non-secure RTP is used regardless if the 494 original offer included any crypto or key-mgmt attributes to begin 495 with. This lets a Best-Effort SRTP offerer successfully negotiate 496 with a non-SRTP answerer, and a key-mgmt-only offerer successfully 497 negotiate non-secure RTP with a crypto-only answerer, and vice- 498 versa. 500 If a crypto attribute line is found in the answer, but does not have 501 a matching tag, included key, or contain all of the mandatory 502 negotiated session parameters, then the session negotiation MUST 503 fail. If a key-mgmt line is found in the answer, but does not pass 504 key management protocol processing, then the session negotiation 505 MUST fail. If both a crypto attribute and key-mgmt line is found in 506 the answer, at the media-level for the same media stream, then the 507 session negotiation MUST fail. If an answer contains a valid crypto 508 or key-mgmt attribute but they were not of the same key exchange 509 type as the offer for that media stream, then the session 510 negotiation MUST fail. These would all represent protocol failures. 512 If a key-mgmt line is found in the answer at the session level and a 513 key-mgmt or crypto attribute at the media level, and such was also 514 offered, then the media-level answers are used for each respective 515 media stream, and the session-level one used for the remaining SAVP 516 media streams (ones without media-level crypto or key-mgmt answers). 517 This is the same as best current practice today. 519 For each media stream which an acceptable answer is received at the 520 media level, and for all remaining SAVP media streams if an 521 acceptable session-level answer, the offerer MUST only accept SRTP 522 using the key and other values in the answer. It would do so as 523 described in [sdesc] or [kmgmt], as if the original Offer and Answer 524 used SAVP secure transport encoding. The offerer would then begin 525 generating SRTP based on the answer as per [sdesc] or [kmgmt] and 526 [srtp]. 528 8. Forked Offers and Multiple Answers 530 The generated Offer may be forked along the path, resulting in 531 multiple Answers. It is typically up to local-policy how to handle 532 such situations. 534 9. Clipping and Changing Transport Types 536 This draft does not rely on an Answer before processing RTP media, 537 but may rely on such for SRTP media. Such is the case typically for 538 SRTP today regardless, as the offered keys are usually the transmit 539 keys - so an Answer has to be received to know how to decrypt 540 received SRTP. NAT traversal using ICE has this limitation as well. 541 [sdesc] and [mikey-rsa-r] also have this limitation. Security 542 preconditions, as defined in [sec-pre], and/or sending the SDP 543 answer in provisional responses as soon as possible, are RECOMMENDED 544 for such cases. 546 This draft, however, provides a solution for rendering RTP media 547 safely, without worry it is SRTP, before the answer arrives. For 548 cases where the decrypt key is known at the time of the offer, this 549 draft also provides the ability to render SRTP media before the 550 answer arrives. 552 A second issue is changing transport types, in an updated 553 offer/answer. Since media typically reaches the UAC before an 554 answer, it may be difficult to know when to switch from RTP to SRTP 555 or vice-versa. This draft provides a solution to that problem as 556 well, by simply offering new dynamic payload types. 558 10. Example Offer/Answer Exchange 560 In the following example, Alice is proposing to establish an 561 unsecure RTP H.263 video channel in conjunction with a Best Effort 562 SRTP voice channel using either G.711 or G.729, using either [kmgmt] 563 or [sdesc]. Alice wishes to use payload type values 96 and 97 for 564 the RTP payload types of 0 and 18. Note that the a=crypto and the 565 a=key-mgmt lines are really 2 long lines. 567 v=0 568 o=alice 2890844526 2890842807 IN IP4 192.0.2.2 569 s=Best effort secured discussion 570 e=alice@example.com (Alice) 571 c=IN IP4 192.0.2.2 572 t=2873397496 2873404696 573 m=video 51372 RTP/AVP 34 574 a=rtpmap:34 H263/9000 575 m=audio 49170 RTP/AVP 0 18 576 a=rtpmap:0 PCMU/8000 577 a=rtpmap:18 G729/8000 578 a=srtp: map:0=96,18=97 579 a=crypto:1 AES_CM_128_HMAC_SHA1_80 580 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 581 a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyONQ6gAAAAAGEE 582 oo2pee4hp2UaDX8ZE22YwKAAAPZG9uYWxkQGR1Y2suY29tAQAAAAAAAQA 583 k0JKpgaVkDaawi9whVBtBt0KZ14ymNuu62+Nv3ozPLygwK/GbAV9iemnG 584 UIZ19fWQUOSrzKTAv9zV 586 In this sample Answer below, Bob does not support SRTP, and 587 therefore ignores the [kmgmt] and [sdesc] attributes and selects RTP 588 for the voice channel, and also accepts the video channel. 590 v=0 591 o=bob 2890890210 807082634 IN IP4 192.0.2.4 592 s=Open discussion 593 e=bob@example.net (Bob) 594 c=IN IP4 192.0.2.4 595 t=2873397496 2873404696 596 m=video 4900 RTP/AVP 34 597 a=rtpmap:34 H263/9000 598 m=audio 32640 RTP/AVP 0 599 a=rtpmap:0 PCMU/8000 601 In this sample Answer below, Bob does support SRTP, selects [sdesc] 602 for the voice channel, and also accepts the video channel. Note Bob 603 includes the srtp attribute and payload mapping info, and will 604 accept SRTP packets using payload type 102 for RTP of 0 (PCMU). 606 v=0 607 o=bob 2890890210 807082634 IN IP4 192.0.2.4 608 s=Secret discussion 609 e=bob@example.net (Bob) 610 c=IN IP4 192.0.2.4 611 t=2873397496 2873404696 612 m=video 4900 RTP/AVP 34 613 a=rtpmap:34 H263/9000 614 m=audio 32640 RTP/AVP 102 615 a=rtpmap:102 PCMU/8000 616 a=srtp: map:0=102 617 a=crypto:1 AES_CM_128_HMAC_SHA1_80 618 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 620 11. Security Considerations 622 Like [sdesc], SDP using the mechanism in this draft with crypto 623 attributes is conveyed in an encapsulating application protocol 624 which MUST provide both strong eavesdropping and authentication 625 mechanisms. The same may be true of key-mgmt lines, depending on 626 the key management protocol. The security requirements in [sdesc] 627 and [kmgmt] MUST be followed for this draft as well. 629 11.1. Security Implications vs. [sdesc] and [kmgmt] 631 The best-effort mechanism proposed in this draft may be considered 632 less secure than [sdesc] and [kmgmt] because it allows a bid-down 633 attack to establish non-secure RTP sessions, even if both ends 634 supported SRTP. It is however more secure than not using SRTP at 635 all. This is by design, however, in order to facilitate 636 interoperability and migration from RTP to SRTP. No mechanism 637 proposed so far truly can prevent a bid-down attack. The difference 638 is that [sdesc] and [kmgmt] would result in a failed session 639 negotiation, whereas this mechanism would not. The authors consider 640 that a benefit of this draft, not a drawback. This draft still 641 mandates using SAVP if the offerer *only* accepts secure transport. 642 If the offerer would accept less anyway, then a malicious attacker 643 can as easily bid-down [sdesc] or [kmgmt] simply by failing the 644 session, since by definition such an offerer will re-signal using 645 non-secure transport encoding. Therefore, this draft's mechanism is 646 only more susceptible to bid-down in a trivial way - namely because 647 it will happen in fewer messages. 649 Using S/MIME or signing bodies using [identity] may also prevent 650 bid-down attacks. 652 Neither party needs to accept a session using non-secure RTP: the 653 offerer can simply use the secure transport encoding in SDP, and the 654 answerer can simply reject offers which do not offer such; or either 655 end can terminate the session or re-offer at any time. Those are 656 local policy decisions which are available for any mechanism. 658 12. References 660 12.1. Normative References 662 [sdesc] Andreasen, F., Baugher, M., and D. Wing, "Session 663 Description Protocol (SDP) Security Description for Media Streams", 664 RFC 4568, July 2006 666 [kmgmt] Arkko, J., et al, "Key Management Extensions for Session 667 Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", 668 RFC 4567, July 2006 670 [sdp] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 671 Description Protocol", RFC 4566, July 2006. 673 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 674 with Session Description Protocol (SDP)", RFC 3264, June 2002. 676 [RFC3550] Schulzrinne, Casner, Frederick and Jacobson, "RTP: A 677 Transport Protocol for Real-Time Applications", RFC 3550, July 2003. 679 [srtp] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 680 Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, 681 March 2004. 683 [sip] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 684 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 685 Session Initiation Protocol", RFC 3261, June 2002. 687 12.2. Informative References 689 [RFC4585] Ott, Wenger, Sato, Burmeiste, Rey, "Extended RTP Profile 690 for Real-time Transport Control Protocol (RTCP)-Based Feedback 691 (RTP/AVPF)", RFC 4585, July 2006 693 [sim-cap] Andreasen, "Session Description Protocol (SDP) Simple 694 Capability Declaration", RFC 3407, October 2002 696 [herfp] Mahy, "A Solution to the Heterogeneous Error Response 697 Forking Problem (HERFP)in the Session Initiation Protocol (SIP)", 698 draft-mahy-sipping-herfp-fix-01 700 [identity] Peterson, Jennings, "Enhancements for Authenticated 701 Identity Management in the Session Initiation Protocol (SIP)", 702 draft-ietf-sip-identity-06 704 [mikey-rsa-r] Ignjatic, Dondeti, Audet, Lin, "An additional mode of 705 key distribution in MIKEY: MIKEY-RSA-R", draft-ietf-mikey-rsa-r-07 707 [savpf] Ott, Carrara, "Extended Secure RTP Profile for RTCP-based 708 Feedback (RTP/SAVPF)", draft-ietf-avt-profile-savpf-06 710 [sdp-neg] Andreasen, "SDP Capability Negotiation", draft-andreasen- 711 mmusic-sdp-capability-negotiation-00 713 [sec-pre] Andreasen, Wing, "Security Preconditions for Session 714 Description Protocol (SDP) Media Streams", draft-ietf-mmusic- 715 securityprecondition-02 717 [zrtp] Zimmermann, "ZRTP: Extensions to RTP for Diffie-Hellman Key 718 Agreement for SRTP", draft-zimmermann-avt-zrtp-01 720 Author's Address 722 Hadriel Kaplan 723 Acme Packet 724 71 Third Ave. 725 Burlington, MA 01803, USA 726 Email: hkaplan@acmepacket.com 728 Francois Audet 729 Nortel Networks 730 4655 Great America Parkway 731 Santa Clara, CA 95054, USA 732 Email: audet@nortel.com 734 Intellectual Property Statement 736 The IETF takes no position regarding the validity or scope of any 737 Intellectual Property Rights or other rights that might be claimed 738 to pertain to the implementation or use of the technology described 739 in this document or the extent to which any license under such 740 rights might or might not be available; nor does it represent that 741 it has made any independent effort to identify any such rights. 742 Information on the procedures with respect to rights in RFC 743 documents can be found in BCP 78 and BCP 79. 745 Copies of IPR disclosures made to the IETF Secretariat and any 746 assurances of licenses to be made available, or the result of an 747 attempt made to obtain a general license or permission for the use 748 of such proprietary rights by implementers or users of this 749 specification can be obtained from the IETF on-line IPR repository 750 at http://www.ietf.org/ipr. 752 The IETF invites any interested party to bring to its attention any 753 copyrights, patents or patent applications, or other proprietary 754 rights that may cover technology that may be required to implement 755 this standard. Please address the information to the IETF at ietf- 756 ipr@ietf.org. 758 Disclaimer of Validity 760 This document and the information contained herein are provided on 761 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 762 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 763 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 764 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 765 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 766 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 768 Copyright Statement 770 Copyright (C) The Internet Society (2006). This document is subject 771 to the rights, licenses and restrictions contained in BCP 78, and 772 except as set forth therein, the authors retain all their rights. 774 Acknowledgments 776 The authors wish to thank Alan Johnston who first suggested the idea 777 (we believe). We also thank Flemming Andreasen, Dan Wing, Randell 778 Jessup, Andrew Zmolek, Robert Gilman and John Elwell for their 779 suggestions and comments.