idnits 2.17.1 draft-dondeti-oma-mmusic-sdp-attrs-00.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 317. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 328. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 341. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 58 has weird spacing: '...tribute stkms...' == Line 167 has weird spacing: '...tribute stkms...' -- 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 (December 31, 2007) is 5961 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4566 (ref. '1') (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '5') (Obsoleted by RFC 5226) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Dondeti, Ed. 3 Internet-Draft QUALCOMM, Inc. 4 Intended status: Informational A. Jerichow 5 Expires: July 3, 2008 Nokia Siemens Networks GmbH and 6 Co.KG 7 December 31, 2007 9 Session Description Protocol (SDP) Attributes for OMA BCAST Service and 10 Content Protection 11 draft-dondeti-oma-mmusic-sdp-attrs-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on July 3, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document provides descriptions of SDP attributes used by the 45 Open Mobile Alliance's Broadcast Service and Content Protection 46 specification. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. New SDP Attributes . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 54 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 55 5.1. Registration of new SDP attributes . . . . . . . . . . . . 4 56 5.1.1. Registration of the attribute 57 bcastversion:. . . . . . . . . . . . . . 4 58 5.1.2. Registration of the attribute stkmstream: . . . . . . . . . . . . . . . . . . . 5 60 5.1.3. Registration of the attribute 61 SRTPAuthentication: . . . . . . . . . . . . . . . . . . . 5 63 5.1.4. Registration of the attribute SRTPROCTxRate: . . . . . . . . . . . . . . . . . . 6 65 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 68 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 70 Intellectual Property and Copyright Statements . . . . . . . . . . 9 72 1. Introduction 74 The Open Mobile Alliance (OMA)'s Broadcast (BCAST) group is 75 specifying service and content protection mechanisms for broadcast 76 services over wireless networks. As part of that specification, 77 several new SDP attributes are necessary to allow the broadcast 78 server to signal the service and content protection parameters to 79 clients. 81 Section 8.2.4 of RFC 4566 [1] requires that new SDP attributes are 82 registered through IANA with name, contact information and 83 description (and other similar parameters). A standards track 84 specification is RECOMMENDED if the new attribute(s) will have 85 widespread use and interoperability considerations. 87 OMA BCAST specifications are expected to be used by 3GPP MBMS, 3GPP2 88 BCMCS and DVB-H based broadcast wireless systems. 90 This document provides descriptions of the SDP attributes used in the 91 OMA BCAST Service and Content Protection specification [2]. 93 2. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [3]. 99 3. New SDP Attributes 101 The following new SDP attributes have been specified: 103 o a=bcastversion:. 105 o a=stkmstream: 107 o a=SRTPAuthentication: 109 o a=SRTPROCTxRate: 111 See Section 5 for details on IANA considerations. 113 4. Security Considerations 115 In addition to the notes in Section 7 of RFC 4566 [1], the following 116 considerations may be applicable: 118 The bcastversion parameter indicates the version of the broadcast 119 system used for distribution of broadcast content. In case future 120 versions indicated by this parameter allow for enhanced or additional 121 security features, the bcastversion parameter, if unprotected, could 122 be utilized for downgrade attacks. 124 The stkmstream parameter provides references to relevant key 125 management streams so that receivers can map the media streams to key 126 streams and retrieve the necessary keys to decrypt media. As such, 127 this parameter could be utilized, if unprotected, for DoS attacks. 129 5. IANA Considerations 131 This document, following the guidelines of [5], instructs IANA to 132 register a number of SDP attributes. 134 5.1. Registration of new SDP attributes 136 This memo provides instructions to IANA to register a number of OMA 137 BCAST only attributes in the Session Description Protocol Parameters 138 registry [1]. The registration data, according to RFC 4566 [1] 139 follows. 141 The registration templates below refer to the OMA-TS- 142 BCAST_SvcCntProtection specification [2]. 144 5.1.1. Registration of the attribute bcastversion:. 146 Contact: Anja Jerichow 148 Phone: +49 89 636-45868 150 Attribute name: bcastversion 152 Long-form attribute name: BCAST version 154 Type of attribute: session-level 156 This attribute is not dependent on charset. 158 Purpose: This attribute specifies the OMA BCAST version 159 "bcastversion" value in the format x.y. 161 Specification of attribute values: This attribute has a mandatory 162 value of the form ., where and are 163 non-negative decimal numbers. The att-value field is of XML data 164 type decimal. For details, see OMA-TS-BCAST_SvcCntProtection, 165 Section 10.1.1. 167 5.1.2. Registration of the attribute stkmstream: 170 Contact: Anja Jerichow 172 Phone: +49 89 636-45868 174 Attribute name: stkmstream 176 Long-form attribute name: Short Term Key Message stream identifyer 178 Type of attribute: session-level or media-level 180 The attribute can be at session level, in which case it applies to 181 all media streams, or it can be at media level, in which case it 182 only applies to the specified media and would overwrite possible 183 session level attributes. 185 This attribute is not dependent on charset. 187 Purpose: The stkmstream attribute specifies the mapping of Short 188 Term Key Message streams to media streams in the SDP. 190 Each session or media stream can have multiple stkmstream 191 attributes. By comparing the value of this attribute with the 192 identifier of each STKM stream, the terminal can figure out which 193 one to listen to and process. We note that this attribute is 194 optional and hence would not be there for unencrypted media 195 streams. 197 Specification of attribute values: This attribute has a mandatory 198 value of the form , a unique non-zero 199 integer identifying a particular key stream. Numbers are unique 200 within a particular SDP session i.e. no global numbering is 201 required. The att-value field is of XML data type unsignedShort. 202 For details, see OMA-TS-BCAST_SvcCntProtection, Section 10.1.3 204 5.1.3. Registration of the attribute SRTPAuthentication: 207 Contact: Anja Jerichow 209 Phone: +49 89 636-45868 210 Attribute name: SRTPAuthentication 212 Long-form attribute name: SRTP authentication algorithm value 213 identifyer 215 Type of attribute: media-level 217 This attribute is not dependent on charset. 219 Purpose: When SRTP is used, the attribute SRTPAuthentication states 220 which authentication algorithm to use. 222 Specification of attribute values: Based on [4], the identifier is a 223 transform-independent parameter of the cryptographic context for 224 SRTP in integer format. 226 One of the following three integrity transforms registered for the 227 three modes MUST be used: value "2" for RCCm1, "3" for RCCm2 and 228 "4" for RCCm3. For details, see OMA-TS-BCAST_SvcCntProtection, 229 Section 10.4. 231 5.1.4. Registration of the attribute SRTPROCTxRate: 234 Contact: Anja Jerichow 236 Phone: +49 89 636-45868 238 Attribute name: SRTPROCTxRate 240 Long-form attribute name: ROC transmission rate 242 Type of attribute: media-level 244 This attribute is not dependent on charset. 246 Purpose: When SRTP is used, the attribute SRTPROCTxRate defines the 247 ROC transmission rate, R. 249 Specification of attribute values: The attribute value MUST be a 250 decimal integer R between 1 and 65535 inclusive, as specified in 251 [4]. If the ROC transmission rate is not included in the 252 negotiation, the default value of 1 SHALL be used. For details, 253 see OMA-TS-BCAST_SvcCntProtection, Section 10.4. 255 6. Acknowledgments 257 Many thanks to Hosame Abu-Amara, Francois Ambrosini, David 258 Castleford, Miguel Garcia, Alfred Hoenes, Charles Lo, and Uwe 259 Rauschenbach for their help and support. 261 7. References 263 7.1. Normative References 265 [1] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 266 Description Protocol", RFC 4566, July 2006. 268 [2] Open Mobile Alliance, "Service and Content Protection for Mobile 269 Broadcast Services", OMA OMA-TS-BCAST_SvcCntProtection-V1_0- 270 20071218-D, 2007. 272 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 273 Levels", BCP 14, RFC 2119, March 1997. 275 [4] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity 276 Transform Carrying Roll-Over Counter for the Secure Real-time 277 Transport Protocol (SRTP)", RFC 4771, January 2007. 279 7.2. Informative References 281 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 282 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 284 Authors' Addresses 286 Lakshminath Dondeti (editor) 287 QUALCOMM, Inc. 288 5775 Morehouse Dr 289 San Diego, CA 290 USA 292 Phone: +1 858-845-1267 293 Email: ldondeti@qualcomm.com 294 Anja Jerichow 295 Nokia Siemens Networks GmbH and Co.KG 296 Martinstr. 76 297 81541 Munich 298 Germany 300 Phone: +49 89 636-45868 301 Email: anja.jerichow@nsn.com 303 Full Copyright Statement 305 Copyright (C) The IETF Trust (2007). 307 This document is subject to the rights, licenses and restrictions 308 contained in BCP 78, and except as set forth therein, the authors 309 retain all their rights. 311 This document and the information contained herein are provided on an 312 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 313 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 314 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 315 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 316 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 317 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 319 Intellectual Property 321 The IETF takes no position regarding the validity or scope of any 322 Intellectual Property Rights or other rights that might be claimed to 323 pertain to the implementation or use of the technology described in 324 this document or the extent to which any license under such rights 325 might or might not be available; nor does it represent that it has 326 made any independent effort to identify any such rights. Information 327 on the procedures with respect to rights in RFC documents can be 328 found in BCP 78 and BCP 79. 330 Copies of IPR disclosures made to the IETF Secretariat and any 331 assurances of licenses to be made available, or the result of an 332 attempt made to obtain a general license or permission for the use of 333 such proprietary rights by implementers or users of this 334 specification can be obtained from the IETF on-line IPR repository at 335 http://www.ietf.org/ipr. 337 The IETF invites any interested party to bring to its attention any 338 copyrights, patents or patent applications, or other proprietary 339 rights that may cover technology that may be required to implement 340 this standard. Please address the information to the IETF at 341 ietf-ipr@ietf.org. 343 Acknowledgment 345 Funding for the RFC Editor function is provided by the IETF 346 Administrative Support Activity (IASA).