QUALCOMM, Inc.

5775 Morehouse Dr San Diego CA USA +1 858-845-1267 ldondeti@qualcomm.com

Nokia Siemens Networks GmbH and Co.KG

Martinstr. 76 81541 Munich Germany +49 89 636-45868 anja.jerichow@nsn.com

SDP IANA registration OMA BCAST This document provides descriptions of Session Description Protocol (SDP) attributes used by the Open Mobile Alliance's Broadcast Service and Content Protection specification.

The Open Mobile Alliance (OMA) Broadcast (BCAST) group is specifying service and content protection mechanisms for broadcast services over wireless networks. As part of that specification, several new SDP attributes are necessary to allow the broadcast server to signal the service and content protection parameters to clients. Section 8.2.4 of RFC 4566 requires that new SDP attributes are registered through IANA with name, contact information, and description (and other similar parameters). A standards track specification is RECOMMENDED if the new attribute(s) will have widespread use and interoperability considerations. OMA BCAST specifications are expected to be used by broadcast wireless systems that are based on 3rd Generation Partnership Project (3GPP) Multimedia Broadcast/Multicast Service (MBMS), 3GPP2 Broadcast and Multicast Services (BCMCS), and Digital Video Broadcasting - Handheld (DVB-H). Although this would typically be considered a "widespread" use, in this case IETF chose to use a non-standards-track RFC to register the SDP attributes because OMA maintains change control of the documents that specify the interpretation of the values in the attributes. This document provides descriptions of the SDP attributes used in the OMA BCAST Service and Content Protection specification .

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 .

The following new SDP attributes have been specified: a=bcastversion:<major>.<minor> a=stkmstream:<id of the stkm stream> a=SRTPAuthentication:<id for SRTP authentication algorithm value> a=SRTPROCTxRate:<ROC transmission rate> See Section 5 for details on IANA considerations.

In addition to the notes in Section 7 of RFC 4566 , the following considerations may be applicable: The bcastversion parameter indicates the version of the broadcast system used for distribution of broadcast content. In case future versions indicated by this parameter allow for enhanced or additional security features, the bcastversion parameter, if unprotected, could be utilized for downgrade attacks. The stkmstream parameter provides references to relevant key management streams so that receivers can map the media streams to key streams and retrieve the necessary keys to decrypt media. As such, this parameter could be utilized, if unprotected, for denial-of-service (DoS) attacks.

Per this document, which follows the guidelines of , IANA has registered a number of SDP attributes.

IANA has registered a number of OMA BCAST only attributes in the Session Description Protocol Parameters registry . The registration data, according to RFC 4566 follows. The registration templates below refer to the OMA-TS-BCAST_SvcCntProtection specification .

Anja Jerichow <anja.jerichow@nsn.com> +49 89 636-45868 bcastversion BCAST version session level This attribute is not dependent on charset. This attribute specifies the OMA BCAST version "bcastversion" value in the format x.y. This attribute has a mandatory value of the form <major>.<minor>, where <major> and <minor> are non-negative decimal numbers. The att-value field is of XML data type decimal. For details, see OMA-TS-BCAST_SvcCntProtection, Section 10.1.1.

Anja Jerichow <anja.jerichow@nsn.com> +49 89 636-45868 stkmstream Short Term Key Message stream identifier session level or media level The attribute can be at session level, in which case it applies to all media streams, or it can be at media level, in which case it only applies to the specified media and would overwrite possible session-level attributes. This attribute is not dependent on charset. The stkmstream attribute specifies the mapping of Short Term Key Message streams to media streams in the SDP. Each session or media stream can have multiple stkmstream attributes. By comparing the value of this attribute with the identifier of each STKM stream, the terminal can figure out which one to listen to and process. We note that this attribute is optional and hence would not be there for unencrypted media streams. This attribute has a mandatory value of the form <id of the stkm stream>, a unique non-zero integer identifying a particular key stream. Numbers are unique within a particular SDP session, i.e., no global numbering is required. The att-value field is of XML data type unsignedShort. For details, see OMA-TS-BCAST_SvcCntProtection, Section 10.1.3.

Anja Jerichow <anja.jerichow@nsn.com> +49 89 636-45868 SRTPAuthentication SRTP authentication algorithm value identifier media level This attribute is not dependent on charset. When SRTP is used, the attribute SRTPAuthentication states which authentication algorithm to use. Based on , the identifier is a transform-independent parameter of the cryptographic context for SRTP in integer format. One of the following three integrity transforms registered for the three modes MUST be used: value "2" for RCCm1, "3" for RCCm2, and "4" for RCCm3. For details, see OMA-TS-BCAST_SvcCntProtection, Section 10.4.

Anja Jerichow <anja.jerichow@nsn.com> +49 89 636-45868 SRTPROCTxRate ROC transmission rate media level This attribute is not dependent on charset. When SRTP is used, the attribute SRTPROCTxRate defines the ROC transmission rate, R. The attribute value MUST be a decimal integer R between 1 and 65535 inclusive, as specified in . If the ROC transmission rate is not included in the negotiation, the default value of 1 SHALL be used. For details, see OMA-TS-BCAST_SvcCntProtection, Section 10.4.

Many thanks to Hosame Abu-Amara, Francois Ambrosini, David Castleford, Miguel Garcia, Alfred Hoenes, Charles Lo, and Uwe Rauschenbach for their help and support.

Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Note that the force of these words is modified by the requirement level of the document in which they are used. This document defines an integrity transform for Secure Real-time Transport Protocol (SRTP; see RFC 3711), which allows the roll-over counter (ROC) to be transmitted in SRTP packets as part of the authentication tag. The need for sending the ROC in SRTP packets arises in situations where the receiver joins an ongoing SRTP session and needs to quickly and robustly synchronize. The mechanism also enhances SRTP operation in cases where there is a risk of losing sender-receiver synchronization. [STANDARDS TRACK] Open Mobile Alliance This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS TRACK] IBM Corporation

3039 Cornwallis Ave. PO Box 12195 - BRQA/502 Research Triangle Park NC 27709-2195 919-254-7798 narten@raleigh.ibm.com

Maxware

Pirsenteret N-7005 Trondheim Norway +47 73 54 57 97 Harald@Alvestrand.no

General Internet Assigned Numbers Authority IANA Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication algorithm for IPSec). To insure that such quantities have consistent values and interpretations in different implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA). In order for the IANA to manage a given name space prudently, it needs guidelines describing the conditions under which new values can be assigned. If the IANA is expected to play a role in the management of a name space, the IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a name space and provides guidelines to document authors on the specific text that must be included in documents that place demands on the IANA.