idnits 2.17.1 draft-dondeti-oma-sip-sdp-attrs-02.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 a=stk...' == Line 143 has weird spacing: '...tribute a=bca...' == Line 164 has weird spacing: '...tribute a=stk...' == Line 200 has weird spacing: '...tribute a=SRT...' == Line 229 has weird spacing: '...tribute a=SR...' -- 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 16, 2007) is 6037 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 (~~), 6 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: April 18, 2008 Nokia Siemens Networks GmbH and 6 Co.KG 7 October 16, 2007 9 Session Description Protocol (SDP) Attributes for OMA BCAST Service and 10 Content Protection 11 draft-dondeti-oma-sip-sdp-attrs-02 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 April 18, 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 a=bcastversion:. . . . . . . . . . . . . 4 58 5.1.2. Registration of the attribute a=stkmstream: . . . . . . . . . . . . . . . . . . . 5 60 5.1.3. Registration of the attribute 61 a=SRTPAuthentication: . . . . . . . . . . . . . . . . . . . 5 63 5.1.4. Registration of the attribute 64 a=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 Some of the new SDP parameters indicate the version, type of the key 119 management system used for service or content protection of broadcast 120 content. Others provide references to relevant key management 121 traffic streams so that receivers can map the media streams to key 122 streams and retrieve the necessary keys to decrypt media. 124 Modification of references to key streams will result in DoS attacks, 125 but nothing more. However, if the kmsversion parameter is sent 126 unprotected, there may be possibilities for downgrade attacks. 128 5. IANA Considerations 130 This document, following the guidelines of [5], instructs IANA to 131 register a number of SDP attributes. 133 5.1. Registration of new SDP attributes 135 This memo provides instructions to IANA to register a number of OMA 136 BCAST only attributes in the Session Description Protocol Parameters 137 registry [1]. The registration data, according to RFC 4566 [1] 138 follows. 140 Note to the RFC Editor: replace "RFC XXXX" with the RFC number of 141 this specification. 143 5.1.1. Registration of the attribute a=bcastversion:. 145 Contact: Anja Jerichow 147 Phone: +49 89 636-45868 149 Attribute name: bcastversion:. 151 Long-form attribute name: BCAST version 153 Type of attribute: session-level 155 This attribute is not dependent on charset. 157 Description: This attribute specifies the OMA BCAST version 158 "bcastversion" Value in the format x.y. The Value field is of XML 159 data type Decimal. 161 Specification: RFC XXXX and OMA-TS-BCAST_SvcCntProtection, Section 162 10.1.1 [2] 164 5.1.2. Registration of the attribute a=stkmstream: 167 Contact: Anja Jerichow 169 Phone: +49 89 636-45868 171 Attribute name: stkmstream: 173 Long-form attribute name: Short Term Key Message stream identifyer 175 Type of attribute: session-level or media-level attribute 177 The attribute can be at session level, in which case it applies to 178 all media streams, or it can be at media level, in which case it 179 only applies to the specified media and would overwrite possible 180 session level attribute. 182 This attribute is not dependent on charset. 184 Description: The stkmstream attribute specifies mapping Short Term 185 Key Message streams to media streams in the SDP. 187 Each session or media stream can have multiple stkmstream 188 attributes. Using this attribute, the terminal can lookup the 189 corresponding STKM stream announcements and figure out which one 190 to listen to and process. We note that this attribute is optional 191 and hence would not be there for unencrypted media streams. 193 This field specifies the type of keystream as a string. The valid 194 values are "stkm" for short term key messages and "ltkm" for long 195 term key messages. 197 Specification: RFC XXXX and OMA-TS-BCAST_SvcCntProtection, Section 198 10.1.3 [2] 200 5.1.3. Registration of the attribute a=SRTPAuthentication: 203 Contact: Anja Jerichow 205 Phone: +49 89 636-45868 207 Attribute name: SRTPAuthentication: 210 Long-form attribute name: SRTP authentication algorithm value 211 identifyer 213 Type of attribute: media-level 215 This attribute is not dependent on charset. 217 Description: When SRTP is used, the attribute SRTPAuthentication 218 states which authentication algorithm to use. Based on , the 219 identifier is a transform-independent parameter of the 220 cryptographic context for SRTP in integer format. 222 One of the following three integrity transforms registered for the 223 three modes MUST be used: value "2" for RCCm1, "3" for RCCm2 and 224 "4" for RCCm3. 226 Specification: RFC XXXX and OMA-TS-BCAST_SvcCntProtection, Section 227 10.4 [2] 229 5.1.4. Registration of the attribute a=SRTPROCTxRate: 232 Contact: Anja Jerichow 234 Phone: +49 89 636-45868 236 Attribute name: SRTPROCTxRate: 238 Long-form attribute name: ROC transmission rate 240 Type of attribute: media-level 242 This attribute is not dependent on charset. 244 Description: When SRTP is used, the attribute SRTPROCTxRate is used 245 to define the ROC transmission rate, R, which is given in network 246 byte order. 248 R MUST be a non-zero unsigned integer between 1 and 65535 249 inclusive, as specified in [4]. If the ROC transmission rate is 250 not included in the negotiation, the default value of 1 SHALL be 251 used. 253 Specification: RFC XXXX and OMA-TS-BCAST_SvcCntProtection, Section 254 10.4 [2] 256 6. Acknowledgments 258 Many thanks to Charles Lo, Uwe Rauschenbach, David Castleford, Hosame 259 Abu-Amara, and Miguel Garcia 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 20070504-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).