idnits 2.17.1 draft-ietf-avt-profile-savpf-10.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 768. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 744. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 751. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 757. 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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 668 has weird spacing: '...hnology tel...' -- 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 (August 2007) is 6092 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) ** Obsolete normative reference: RFC 4566 (ref. '6') (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 2326 (ref. '10') (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 3851 (ref. '12') (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 2818 (ref. '13') (Obsoleted by RFC 9110) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Joerg Ott 3 Helsinki University of Technology 4 draft-ietf-avt-profile-savpf-10.txt Elisabetta Carrara 5 KTH 6 February 2007 7 Expires August 2007 9 Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF) 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 An RTP profile (SAVP) is defined for secure real-time 38 communications, and another profile (AVPF) is specified to provide 39 timely feedback from the receivers to a sender. This memo defines 40 the combination of both profiles to enable secure RTP 41 communications with feedback. 43 Table of Contents 45 1 Introduction..................................................2 46 1.1 Definitions..............................................3 47 1.2 Terminology..............................................4 48 2 SAVPF Rules...................................................4 49 2.1 Packet Formats...........................................5 50 2.2 Extensions...............................................5 51 2.3 Implications from combining AVPF and SAVP................5 52 3 SDP Definitions...............................................6 53 3.1 Profile Definition.......................................6 54 3.2 Attribute Definitions....................................6 55 3.3 Profile Negotiation......................................6 56 3.3.1 Offer/Answer-based Negotiation of Session Descriptions.6 57 3.3.2 RTSP-based Negotiation of Session Descriptions.........7 58 3.3.3 Announcing Session Descriptions........................8 59 3.3.4 Describing Alternative Session Profiles................9 60 3.4 Examples.................................................9 61 4 Interworking of AVP, SAVP, AVPF, and SAVPF Entities..........13 62 5 Security Considerations......................................13 63 6 IANA Considerations......................................... 14 64 7 Acknowledgements ........................................... 15 65 8 Authors' Addresses.......................................... 15 66 9 Bibliography................................................ 15 67 9.1 Normative references................................... 15 68 9.2 Informative References................................. 16 69 10 IPR Notice.................................................. 17 70 11 Disclaimer of Validity...................................... 17 71 12 Full Copyright Statement ................................... 17 72 13 Acknowledgment.............................................. 17 74 1 Introduction 76 The Real-time Transport Protocol (RTP/RTCP) [1] and the associated 77 profile for audiovisual communications with minimal control [2] 78 define mechanisms for transmitting time-based media across an IP 79 network. RTP provides means to preserve timing and detect packet 80 losses, among other things, and RTP payload formats provide for 81 proper framing of (continuous) media in a packet-based environment. 82 RTCP enables receivers to provide feedback on reception quality and 83 allows all members of an RTP session to learn about each other. 85 The RTP specification provides only rudimentary support for 86 encrypting RTP and RTCP packets. SRTP [4] defines an RTP profile 87 ("SAVP") for secure RTP media sessions, defining methods for proper 88 RTP and RTCP packet encryption, integrity and replay protection. 89 The initial negotiation of SRTP and its security parameters needs 90 to be done out of band, using e.g. the Session Description Protocol 91 (SDP) [6] together with extensions for conveying keying material 92 [7][8]. 94 The RTP specification also provides limited support for timely 95 feedback from receivers to senders, typically by means of reception 96 statistics reporting in somewhat regular intervals depending on the 97 group size, the average RTCP packet size, and the available RTCP 98 bandwidth. The extended RTP profile for RTCP-based feedback 99 ("AVPF") [3] allows session participants statistically to provide 100 immediate feedback while maintaining the average RTCP data rate for 101 all senders. As for SAVP, the use of AVPF and its parameters needs 102 to be negotiated out-of-band by means of SDP [6] and the extensions 103 defined in [3]. 105 Both SRTP and AVPF are RTP profiles and need to be negotiated. 106 This implies that either one or the other may be used, but both 107 profiles cannot be negotiated for the same RTP session (using one 108 SDP session level description). However, using secure 109 communications and timely feedback together is desirable. 110 Therefore, this document specifies a new RTP profile ("SAVPF") that 111 combines the features of SAVP and AVPF. 113 As SAVP and AVPF are largely orthogonal, the combination of both is 114 mostly straightforward. No sophisticated algorithms need to be 115 specified in this document. Instead, reference is made to both 116 existing profiles and only the implications of their combination 117 and possible deviations from rules of the existing profiles are 118 described as is the negotiation process. 120 1.1 Definitions 122 The definitions of [1], [2], [3], and [4] apply. 124 The following definitions are specifically used in this document: 126 RTP session: 127 An association among a set of participants communicating with 128 RTP as defined in [1]. 130 (SDP) media description: 131 This term refers to the specification given in a single m= 132 line in an SDP message. An SDP media description may define 133 only one RTP session. Grouping of m= lines in SDP may cause 134 several SDP session level descriptions to define (alternatives 135 of) the same RTP session for the same media type. 137 Media session: 138 A media session refers to a collection of SDP media 139 descriptions that are semantically grouped to represent 140 alternatives of the same communications means. Out of such a 141 group, one will be negotiated or chosen for a communication 142 relationship and the corresponding RTP session will be 143 instantiated. Or the media session will be rejected. 144 In the simplest case, a media session is equivalent to an SDP 145 media description and equivalent to an RTP session. 147 1.2 Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 150 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 151 in this document are to be interpreted as described in RFC 2119 152 [5]. 154 2 SAVPF Rules 156 SAVP is defined as an intermediate layer between RTP (following the 157 regular RTP profile AVP) and the transport layer (usually UDP). 158 This yields a two layer hierarchy within the Real-time Transport 159 Protocol. In SAVPF, the upper (AVP) layer is replaced by the 160 extended RTP profile for feedback (AVPF). 162 AVPF modifies timing rules for transmitting RTCP packets and adds 163 extra RTCP packet formats specific to feedback. These functions 164 are independent of whether or not RTCP packets are subsequently 165 encrypted and/or integrity protected. The functioning of the AVPF 166 layer remains unchanged in SAVPF. 168 The AVPF profile derives from [1] the (optional) use of the 169 encryption prefix for RTCP. The encryption prefix MUST NOT be used 170 within the SAVPF profile (it is not used in SAVP, as it is only 171 applicable to the encryption method specified in [1]). 173 The SAVP part uses extra fields added to the end of RTP and RTCP 174 packets and executes cryptographic transforms on (some of) the 175 RTP/RTCP packet contents. This behavior remains unchanged in 176 SAVPF. The average RTCP packet size calculation done by the AVPF 177 layer for timing purposes MUST take into account the fields added 178 by the SAVP layer. 180 The SRTP part becomes only active whenever the RTP or RTCP was 181 scheduled by the "higher" AVPF layer or received from the transport 182 protocol, irrespective of its timing and contents. 184 2.1 Packet Formats 186 AVPF defines extra packet formats to provide feedback information. 187 Those extra packet formats defined in [3] (and further ones defined 188 elsewhere for use with AVPF) MAY be used with SAVPF. 190 SAVP defines a modified packet format for SRTP and SRTCP packets 191 that essentially consists of the RTP/RTCP packet formats plus some 192 trailing protocol fields for security purposes. For SAVPF, all 193 RTCP packets MUST be encapsulated as defined in section 3.4 of [4]. 195 2.2 Extensions 197 Extensions to AVPF RTCP feedback packets defined elsewhere MAY be 198 used with the SAVPF profile provided that those extensions are in 199 conformance with the extension rules of [3]. 201 Additional extensions (e.g., transforms) defined for SAVP following 202 the rules of section 6 of [4] MAY also be used with the SAVPF 203 profile. The overhead per RTCP packet depends on the extensions 204 and transforms chosen. New extensions and transforms added in the 205 future MAY introduce yet unknown further per-packet overhead. 207 Finally, further extensions specifically to SAVPF MAY be defined 208 elsewhere. 210 2.3 Implications from combining AVPF and SAVP 212 The AVPF profile aims at -- statistically -- allowing receivers to 213 provide timely feedback to senders. The frequency at which 214 receivers are, on average, allowed to send feedback information 215 depends on the RTCP bandwidth, the group size, and the average size 216 of an RTCP packet. SRTCP (see Section 3.4 of [4]) adds extra 217 fields (some of which are of configurable length) at the end of 218 each RTCP packet that are probably at least some 10 to 20 bytes in 219 size (14 bytes as default). Note that extensions and transforms 220 defined in the future, as well as the configuration of each field 221 length, MAY add greater overhead. By using SRTP, the average size 222 of an RTCP packet will increase and thus reduce the frequency at 223 which (timely) feedback can be provided. Application designers 224 need to be aware of this, and take precautions so that the RTCP 225 bandwidth shares are maintained. This MUST be done by adjusting 226 the RTCP variable "avg_rtcp_size" to reflect the size of the SRTCP 227 packets. 229 3 SDP Definitions 231 3.1 Profile Definition 233 The AV profiles defined in [2], [3], and [4] are referred to as 234 "AVP", "AVPF", and "SAVP", respectively, in the context of e.g. the 235 Session Description Protocol (SDP) [3]. The combined profile 236 specified in this document is referred to as "SAVPF". 238 3.2 Attribute Definitions 240 SDP attributes for negotiating SAVP sessions are defined in [7] and 241 [8]. Those attributes MAY also be used with SAVPF. The rules 242 defined in [7] and [8] apply. 244 SDP attributes for negotiating AVPF sessions are defined in [3]. 245 Those attributes MAY also be used with SAVPF. The rules defined in 246 [3] apply. 248 3.3 Profile Negotiation 250 Session descriptions for RTP sessions may be conveyed using 251 protocols dedicated for multimedia communications such as the SDP 252 offer/answer model [9] used with SIP, RTSP [10], or SAP [11] but 253 may also be distributed using email, NetNews, web pages, etc. 255 The offer/answer model allows the resulting session parameters to 256 be negotiated using the SDP attributes defined in [7] and [8]. In 257 the following subsection, the negotiation process is described in 258 terms of the offer/answer model. 260 Afterwards, the cases that do not use the offer/answer model are 261 addressed: RTSP-specific negotiation support is provided by [7] as 262 discussed in subsection 3.3.2 and support for SAP announcements 263 (with no negotiation at all) is addressed in subsection 3.3.3. 265 3.3.1 Offer/Answer-based Negotiation of Session Descriptions 267 Negotiations (e.g. of RTP profiles, codecs, transport addresses, 268 etc.) are carried out on a per-media session basis (i.e. per m= 269 line in SDP). If negotiating one media session fails, others MAY 270 still succeed. 272 Different RTP profiles MAY be used in different media sessions. 273 For negotiation of a media description, the four profiles AVP, 274 AVPF, SAVP, and SAVPF are mutually exclusive. Note, however, that 275 SAVP and SAVPF entities MAY be mixed in a single RTP session (see 276 section 4). Also, the offer/answer mechanism MAY be used to offer 277 alternatives for the same media session (e.g. using the same 278 transport parameters) and allow the answered to choose one of the 279 profiles. 281 An offerer that is capable of supporting multiple of these profiles 282 for a certain media session SHOULD always offer all alternatives 283 acceptable in a certain situation. The alternatives SHOULD be 284 listed in order of preference and the offerer SHOULD prefer secure 285 profiles over non-secure ones. The offer SHOULD NOT include both a 286 secure alternative (SAVP and SAVPF) and an insecure alternative 287 (e.g. AVP and AVPF) in the same offer as this may enable bidding 288 down and other attacks. Therefore, if both secure and non-secure 289 RTP profiles shall be offered (e.g., for best-effort SRTP [14]), 290 care SHOULD be taken to appropriately protect the negotiation 291 signaling.. 293 If an offer contains multiple alternative profiles the answerer 294 MUST select exactly only one and reject the other(s), e.g., by 295 setting the port number in the respect m= line to 0. If supported, 296 the answerer SHOULD prefer a secure profile over non-secure ones. 297 Among the secure or insecure profiles, the answerer SHOULD select 298 the first acceptable alternative to respect the preference of the 299 offerer. 301 If a media description in an offer uses SAVPF and the answerer does 302 not support SAVPF, the media session MUST be rejected. 304 If a media description in an offer does not use SAVPF but the 305 answerer wants to use SAVPF, the answerer MUST reject the media 306 session. The answerer MAY provide a counter-offer with a media 307 description indicating SAVPF in a subsequently initiated 308 offer/answer exchange. 310 3.3.2 RTSP-based Negotiation of Session Descriptions 312 RTSP [10] does not support the offer/answer model. However, RTSP 313 supports exchanging media session parameters (including profile and 314 address information) by means of the "Transport:" header. SDP- 315 based key management as defined in [7] adds an RTSP header 316 (KeyMgmt:) to support conveying a key management protocol 317 (including keying material). 319 The RTSP "Transport:" header MAY be used to determine the profile 320 for the media session. Conceptually, the rules defined in section 321 3.3.1 apply accordingly. Detailed operation is as follows: 322 An SDP description (e.g., retrieved from the RTSP server by means 323 of DESCRIBE) contains the description of the media streams of the 324 particular RTSP resource. To offer two or more alternative RTP 325 profiles for a particular media stream, the SDP description MUST 326 contain exactly one m= line for this media stream for each profile 327 and all the same transport address (IP address and port number). 328 The profiles SHOULD be listed in the order of preference. This is 329 similar to formulating an offer per section 3.3.1. 331 The RTSP client MUST select exactly one of the profiles per media 332 stream it wants to receive. It MUST do so in the SETUP request. 333 The RTSP client MUST indicate the chosen RTP profile by indicating 334 the profile and the full server transport address (IP address and 335 port) in the Transport: header included in the SETUP request. The 336 RTSP server's response to the client's SETUP message MUST confirm 337 this profile selection or refuse the SETUP request (the latter of 338 which it should not do after offering the profiles in the first 339 place). 341 Note: To change any of the profiles in use, the client needs 342 tear down the RTSP session (using the TEARDOWN method) and re- 343 establish it using SETUP. This may change as soon as media 344 updating (similar to a SIP UPDATE or re-INVITE) becomes 345 specified. 347 When using the SDP key management [7], the keymgmt: header MUST be 348 included in the appropriate RTSP messages if a secure profile is 349 chosen. If different secure profiles are offered in the SDP 350 description (e.g., SAVP and SAVPF) and different keying material is 351 provided for these, after choosing one profile in the SETUP 352 message, only the keymgmt: header for the chosen one MUST be 353 provided. The rules for matching keymgmt: headers to media streams 354 according to [7] apply. 356 3.3.3 Announcing Session Descriptions 358 Protocols that do not allow negotiate session descriptions 359 interactively (e.g. SAP [11], descriptions posted on a web page or 360 sent by mail) pose the responsibility for adequate access to the 361 media sessions on the initiator of a session. 363 The initiator SHOULD provide alternative session descriptions for 364 multiple RTP profiles as far as acceptable to the application and 365 the purpose of the session. If security is desired, SAVP may be 366 offered as alternative to SAVPF -- but AVP or AVPF sessions SHOULD 367 NOT be announced unless other security means not relying on SRTP 368 are employed. 370 The SDP attributes defined in [7] and [8] may also be used for the 371 security parameter distribution of announced session descriptions. 373 The security scheme description defined in [8] requires a secure 374 communications channel to prevent third parties from eavesdropping 375 on the keying parameters and manipulation. Therefore, SAP security 376 (as defined in [11]), S/MIME [12], HTTPS [13], or other suitable 377 mechanisms SHOULD be used for distributing or accessing these 378 session descriptions. 380 3.3.4 Describing Alternative Session Profiles 382 SAVP and SAVPF entities MAY be mixed in the same RTP session (see 383 also section 4) and so MAY AVP and AVPF entities. Other 384 combinations -- i.e. between secure and insecure profiles -- in the 385 same RTP session are incompatible and MUST NOT be used together. 387 If negotiation between the involved peers is possible (as with the 388 offer/answer model per section 3.3.1 or RTSP per section 3.3.2), 389 alternative (secure and non-secure) profiles MAY be specified by 390 one entity (e.g., the offerer) and a choice of one profile MUST be 391 made by the other. If no such negotiation is possible (e.g., with 392 SAP as per section 3.3.3) incompatible profiles MUST NOT be 393 specified as alternatives. 395 The negotiation of alternative profiles is for further study. 397 RTP profiles MAY be mixed arbitrarily across different RTP 398 sessions. 400 3.4 Examples 402 Example 1: The following session description indicates a secure 403 session made up from audio and DTMF for point-to-point 404 communication in which the DTMF stream uses Generic NACKs. The key 405 management protocol indicated is MIKEY. This session description 406 (the offer) could be contained in a SIP INVITE or 200 OK message to 407 indicate that its sender is capable of and willing to receive 408 feedback for the DTMF stream it transmits. The corresponding 409 answer may be carried in a 200 OK or an ACK. The parameters for 410 the security protocol are negotiated as described by the SDP 411 extensions defined in [7]. 413 v=0 414 o=alice 3203093520 3203093520 IN IP4 host.example.com 415 s=Media with feedback 416 t=0 0 417 c=IN IP4 host.example.com 418 m=audio 49170 RTP/SAVPF 0 96 419 a=rtpmap:0 PCMU/8000 420 a=rtpmap:96 telephone-event/8000 421 a=fmtp:96 0-16 422 a=rtcp-fb:96 nack 423 a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD... 425 Example 2: This example shows the same feedback parameters as 426 example 1 but uses the secure descriptions syntax [8]. Note that 427 the key part of the a=crypto attribute is not protected against 428 eavesdropping and thus the session description needs to be 429 exchanged over a secure communication channel. 431 v=0 432 o=alice 3203093520 3203093520 IN IP4 host.example.com 433 s=Media with feedback 434 t=0 0 435 c=IN IP4 host.example.com 436 m=audio 49170 RTP/SAVPF 0 96 437 a=rtpmap:0 PCMU/8000 438 a=rtpmap:96 telephone-event/8000 439 a=fmtp:96 0-16 440 a=rtcp-fb:96 nack 441 a=crypto:AES_CM_128_HMAC_SHA1_32 442 inline:d/16/14/NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj/2^20/1 443 :32 445 Example 3: This example is replicated from example 1 above but 446 shows the interaction between the offerer and the answered in an 447 offer/answer exchange, again using MIKEY to negotiate the keying 448 material: 450 Offer: 452 v=0 453 o=alice 3203093520 3203093520 IN IP4 host.example.com 454 s=Media with feedback 455 t=0 0 456 c=IN IP4 host.example.com 457 a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD... 458 m=audio 49170 RTP/SAVPF 0 96 459 a=rtpmap:0 PCMU/8000 460 a=rtpmap:96 telephone-event/8000 461 a=fmtp:96 0-16 462 a=rtcp-fb:96 nack 464 Answer: 466 v=0 467 o=alice 3203093521 3203093521 IN IP4 host.another.example.com 468 s=Media with feedback 469 t=0 0 470 c=IN IP4 host.another.example.com 471 a=key-mgmt:mikey ushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD... 472 m=audio 53012 RTP/SAVPF 0 96 473 a=rtpmap:0 PCMU/8000 474 a=rtpmap:96 telephone-event/8000 475 a=fmtp:96 0-16 476 a=rtcp-fb:96 nack 478 Example 4: This example shows the exchange for video streaming 479 controlled via RTSP. A client inquires a media description from a 480 server using DESCRIBE and obtains a static SDP description without 481 any keying parameters but the media description shows that both 482 secure and non-secure media sessions using (S)AVPF are available. 483 Note that a future grouping mechanism will allow to explicitly 484 identify these as alternatives in the session description. The 485 client then issues a SETUP request and indicates its choice by 486 including the respective profile in the Transport parameter. 487 Furthermore, the client includes a KeyMgmt: header to convey its 488 security parameters which is matched by a corresponding KeyMgmt 489 header from the server in the response. Only a single media 490 session is chosen so that the aggregate RTSP URI is sufficient for 491 identification; if several media sessions shall use different 492 keying material, the a=control: attribute needs to be included in 493 the SDP description. 495 RTSP DESCRIBE request-response pair (optional): 497 DESCRIBE rtsp://movies.example.org/example RTSP/2.0 498 CSeq: 314 499 Accept: application/sdp 501 200 OK 502 CSeq: 314 503 Date: 25 Nov 2005 22:09:35 GMT 504 Content-Type: application/sdp 505 Content-Length: 316 507 v=0 508 o=alice 3203093520 3203093520 IN IP4 movies.example.com 509 s=Media with feedback 510 t=0 0 511 c=IN IP4 0.0.0.0 512 m=video 49170 RTP/SAVPF 96 513 a=rtpmap:96 H263-2000/90000 514 a=rtcp-fb:96 nack 515 m=video 49172 RTP/AVPF 96 516 a=rtpmap:96 H263-2000/90000 517 a=rtcp-fb:96 nack 519 RTSP SETUP request-response pair 521 SETUP rtsp://movies.example.org/example RTSP/2.0 522 CSeq: 315 523 Transport: RTP/SAVPF;unicast;dest_addr=":53012"/":53013" 524 KeyMgmt: prot=mikey;url="rtsp://movies.example.org/example"; 525 data="uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnD..." 527 200 OK 528 CSeq: 315 529 Date: 25 Nov 2005 22:09:36 GMT 530 Session: 4711 531 Transport: RTP/SAVPF;unicast;dest_addr=":53012"/":53013"; 532 src_addr="192.0.2.15:60000"/"192.0.2.15:60001" 533 KeyMgmt: prot=mikey;url="rtsp://movies.example.org/example"; 534 data="ushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD..." 535 Accept-Ranges: NPT, SMPTE 537 Example 5: The following session description indicates a multicast 538 audio/video session (using PCMU for audio and either H.261 or 539 H.263+) with the video source accepting Generic NACKs for both 540 codecs and Reference Picture Selection for H.263. The parameters 541 for the security protocol are negotiated as described by the SDP 542 extensions defined in [7], used at the session level. Such a 543 description may have been conveyed using the Session Announcement 544 Protocol (SAP). 546 v=0 547 o=alice 3203093520 3203093520 IN IP4 host.example.com 548 s=Multicast video with feedback 549 t=3203130148 3203137348 550 a=key-mgmt:mikey uiSDF9sdhs7494ghsd/dhsoKkdOokdo7eWsnDSJD... 551 m=audio 49170 RTP/SAVP 0 552 c=IN IP4 224.2.1.183 553 a=rtpmap:0 PCMU/8000 554 m=video 51372 RTP/SAVPF 98 99 555 c=IN IP4 224.2.1.184 556 a=rtpmap:98 H263-1998/90000 557 a=rtpmap:99 H261/90000 558 a=rtcp-fb:* nack 559 a=rtcp-fb:98 nack rpsi 561 4 Interworking of AVP, SAVP, AVPF, and SAVPF Entities 563 The SAVPF profile defined in this document is a combination of the 564 SAVP profile [4] and the AVPF profile [3](which in turn is an 565 extension of the RTP profile as defined in [2]). 567 SAVP and SAVPF use SRTP [4] to achieve security. AVP and AVPF use 568 plain RTP [1] and hence do not provide security (unless external 569 security mechanisms are applied as discussed in section 9.1 of 570 [1]). SRTP and RTP are not meant to interoperate, the respective 571 protocol entities are not supposed to be part of the same RTP 572 session. Hence, AVP and AVPF on one side and SAVP and SAVPF on the 573 other MUST NOT be mixed. 575 RTP entities using the SAVP and the SAVPF profiles MAY be mixed in 576 a single RTP session. The interworking considerations defined in 577 section 5 of [3] apply. 579 5 Security Considerations 581 The SAVPF profile inherits its security properties from the SAVP 582 profile; therefore it is subject to the security considerations 583 discussed in [4]. The SAVP profile does not add, nor take away, 584 any security services compared to SAVP. 586 There is a desire to support security for media streams and, at the 587 same time, for backward compatibility with non-SAVP(F) nodes. 588 Application designers should be aware that security SHOULD NOT be 589 traded for interoperability. If information is to be distributed 590 to closed groups (i.e. confidentially protected), it is RECOMMENDED 591 not to offer alternatives for a media session other than SAVP and 592 SAVPF as described in sections 3.3 and 3.4, unless other security 593 mechanisms will be used, e.g. the ones described in Section 9.1 of 594 [1]. Similarly, if integrity protection is considered important, it 595 is RECOMMENDED not to offer the alternatives other than SAVP and 596 SAVPF, unless other mechanisms are known to be in place that can 597 guarantee it, e.g. lower-layer mechanisms as described in Section 9 598 of [1]. 600 Offering secure and insecure profiles simultaneously may open to 601 bidding down attacks. Therefore, such a mix of profile offer SHOULD 602 NOT be made. 604 Note that the rules for sharing master keys apply as described in 605 [4] (e.g., Section 9.1). In particular, the same rules for avoiding 606 the two-time pad (keystream reuse) apply: a master key MUST NOT be 607 shared among different RTP sessions if the SSRCs used are unique 608 across all the RTP streams of the RTP sessions that share the same 609 master key. 611 The key management MUST be called to provide new master key(s) 612 (previously stored and used keys MUST NOT be used again), or the 613 session MUST be terminated, when 2^48 SRTP packets or 2^31 SRTCP 614 packets have been secured with the same key (whichever occurs 615 before). 617 Different media sessions may use a mix of different profiles, 618 particularly including a secure profile and an insecure profile. 619 However, mixing secure and insecure media sessions may reveal 620 information to third parties and thus the decision to do so MUST be 621 in line with a local security policy. For example, the local 622 policy MUST specify whether it is acceptable to have e.g. the audio 623 stream not secured and the related video secured. 625 The security considerations in [3] are valid too. Note in 626 particular, applying the SAVPF profile implies mandatory integrity 627 protection on RTCP. While this solves the problem of false packets 628 from members not belonging to the group, it does not solve the 629 issues related to a malicious member acting improperly. 631 6 IANA Considerations 633 The following contact information shall be used for all 634 registrations included here: 636 Contact: Joerg Ott 637 mailto:jo@acm.org 638 tel:+358-9-451-2460 640 The secure RTP feedback profile as a combination of Secure RTP and 641 the feedback profile needs to be registered for the Session 642 Description Protocol (specifically the type "proto"): "RTP/SAVPF". 644 SDP Protocol ("proto"): 646 Name: RTP/SAVPF 647 Long form: Secure RTP Profile with RTCP-based Feedback 648 Type of name: proto 649 Type of attribute: Media level only 650 Purpose: RFC XXXX 651 Reference: RFC XXXX 653 All the SDP attribute defined for RTP/SAVP and RTP/AVPF are valid 654 for RTP/SAVPF, too. 656 NOTE TO THE RFC EDITOR: Please replace all occurrences of RFC XXXX by 657 the RFC number assigned to this document. 659 7 Acknowledgements 661 This document is a product of the Audio-Visual Transport (AVT) 662 Working Group of the IETF. The authors would like to thank Magnus 663 Westerlund and Colin Perkins for their comments. 665 8 Authors' Addresses 667 Joerg Ott mailto:jo@netlab.hut.fi 668 Helsinki University of Technology tel:+358-9-451-2460 669 Otakaari 5A 670 FI-02150 Espoo 671 Finland 673 Elisabetta Carrara mailto: carrara@kth.se 674 Royal Institute of Technology 675 Stockholm 676 Sweden 678 9 Bibliography 680 9.1 Normative references 682 [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP 683 - A Transport Protocol for Real-time Applications," RFC 3550 684 (STD0064), July 2003. 686 [2] H. Schulzrinne and S. Casner, "RTP Profile for Audio and Video 687 Conferences with Minimal Control," RFC 3551 (STD0065), March 688 2003. 690 [3] J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey, "Extended 691 RTP Profile for RTCP-based Feedback (RTP/AVPF), RFC 4585, 692 July 2006. 694 [4] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman, 695 "The Secure Real-time Transport Protocol", RFC 3711, March 696 2004. 698 [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement 699 Levels," RFC 2119, March 1997. 701 [6] M. Handley, V. Jacobson, and C. Perkins, "SDP: Session 702 Description Protocol", RFC 4566, July 2006. 704 [7] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. Norrman, 705 "Key Management Extensions for Session Description Protocol 706 (SDP) and Real Time Streaming Protocol (RTSP)," RFC 4567, July 707 2006. 709 [8] F. Andreassen, M. Baugher, and D. Wing, "Session Description 710 Protocol Security Descriptions for Media Streams," RFC 4568, 711 July 2006. 713 [9] J. Rosenberg and H. Schulzrinne, "An offer/answer model with 714 SDP," RFC 3264, June 2002. 716 [10] H. Schulzrinne, A. Rao, and R. Lanphier, "Real Time Streaming 717 Protocol (RTSP)," RFC 2326, April 1998. 719 9.2 Informative References 721 [11] M. Handley, C. Perkins, and E. Whelan, "Session Announcement 722 Protocol," RFC 2974, October 2000. 724 [12] B. Ramsdell (ed.), "Secure/Multipurpose Internet Mail 725 Extensions (S/MIME) Version 3.1 Message Specification," RFC 726 3851, July 2004. 728 [13] E. Rescorla, "HTTP Over TLS," RFC 2818, May 2000. 730 [14] H. Kaplan and F. Audet, "Session Description Protocol (SDP) 731 Offer/Answer Negotiation For Best-Effort Secure Real-Time 732 Transport Protocol," draft-kaplan-mmusic-best-effort-srtp-01, 733 Work in Progress, October 2006. 735 10 IPR Notice 737 The IETF takes no position regarding the validity or scope of any 738 Intellectual Property Rights or other rights that might be claimed 739 to pertain to the implementation or use of the technology described 740 in this document or the extent to which any license under such 741 rights might or might not be available; nor does it represent that 742 it has made any independent effort to identify any such rights. 743 Information on the procedures with respect to rights in RFC 744 documents can be found in BCP 78 and BCP 79. 746 Copies of IPR disclosures made to the IETF Secretariat and any 747 assurances of licenses to be made available, or the result of an 748 attempt made to obtain a general license or permission for the use 749 of such proprietary rights by implementers or users of this 750 specification can be obtained from the IETF on-line IPR repository 751 at http://www.ietf.org/ipr. 753 The IETF invites any interested party to bring to its attention any 754 copyrights, patents or patent applications, or other proprietary 755 rights that may cover technology that may be required to implement 756 this standard. Please address the information to the IETF at ietf- 757 ipr@ietf.org. 759 11 Disclaimer of Validity 761 This document and the information contained herein are provided on 762 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 763 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 764 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 765 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 766 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 767 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 768 FOR A PARTICULAR PURPOSE. 770 12 Full Copyright Statement 772 Copyright (C) The IETF Trust (2007). This document is subject to 773 the rights, licenses and restrictions contained in BCP 78, and 774 except as set forth therein, the authors retain all their rights. 776 13 Acknowledgment 778 Funding for the RFC Editor function is currently provided by the 779 Internet Society.