RFC 5159

RFC 5159 🎀 Session Description Protocol (SDP) Attributes for Open Mobile Alliance (OMA) Broadcast (BCAST) Service and Content Protection

okay bestie, let's get into it 💖 this one's from the Network Working Group (the IETF crew) and it's an Informational RFC, so it's sharing info and it's not a standard 🧚. It's dated March 2008. The editor is Lakshminath Dondeti from QUALCOMM, Inc., and Anja Jerichow from Nokia Siemens Networks is the co-author 🫶. Nothing in the title block says it obsoletes or updates anything, so it's a standalone doc ✨.

---

Status of This Memo 🌸

okay so this memo is just giving info to the Internet community. It is NOT a standard of any kind 🙈 and anyone can distribute it as much as they want, no limits 💅.

Abstract 🦋

so this doc describes some Session Description Protocol (SDP) attributes that the Open Mobile Alliance's Broadcast Service and Content Protection spec uses 💜.

Table of Contents 🍓

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3.  New SDP Attributes  . . . . . . . . . . . . . . . . . . . . . . 2
4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 3
5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3
  5.1.  Registration of New SDP Attributes  . . . . . . . . . . . . 3
    5.1.1.  Registration of the Attribute
            bcastversion:<major>.<minor>  . . . . . . . . . . . . . 3
    5.1.2.  Registration of the Attribute stkmstream:<id of
            the stkm stream>  . . . . . . . . . . . . . . . . . . . 4
    5.1.3.  Registration of the Attribute
            SRTPAuthentication:<id for SRTP authentication
            algorithm value>  . . . . . . . . . . . . . . . . . . . 5
    5.1.4.  Registration of the Attribute SRTPROCTxRate:<ROC
            transmission rate>  . . . . . . . . . . . . . . . . . . 5
6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
  7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
  7.2.  Informative References  . . . . . . . . . . . . . . . . . . 6

1. Introduction ✨

okay so the Open Mobile Alliance (OMA) Broadcast (BCAST) group is writing up service and content protection mechanisms for broadcast services over wireless networks 📡. As part of that, a bunch of new SDP attributes are needed so the broadcast server can tell clients what the service and content protection parameters are 🎀.

Section 8.2.4 of RFC 4566 [1] says new SDP attributes have to get registered with IANA, including a name, contact info, and a description (plus other similar parameters) 📝. A standards track specification is RECOMMENDED if the new attribute(s) will see widespread use and have interoperability considerations 🔥.

OMA BCAST specs are expected to be used by broadcast wireless systems 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) 📺. Now, this would normally count as a "widespread" use 👀, but the IETF went with a non-standards-track RFC to register the SDP attributes anyway, because OMA keeps change control over the docs that define what the attribute values mean 💅.

This document describes the SDP attributes used in the OMA BCAST Service and Content Protection specification [2] 🦋.

2. Terminology 🧚

so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read the way RFC 2119 [3] describes 💜.

3. New SDP Attributes 🌈

these are the new SDP attributes that 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>

check Section 5 for the IANA considerations details 🫶.

4. Security Considerations 🔐

okay this part is SERIOUS, so pay attention 🚨. In addition to the notes in Section 7 of RFC 4566 [1], the following considerations may be applicable:

The bcastversion parameter tells you which version of the broadcast system is being used to distribute the broadcast content 📻. If future versions that this parameter points to add better or extra security features, then a bcastversion parameter that isn't protected could be used for downgrade attacks 😱. That's not a vibe.

The stkmstream parameter points to the relevant key management streams, so receivers can map media streams to key streams and grab the keys they need to decrypt the media 🗝️. Because of that, if this parameter isn't protected, it could be used for denial-of-service (DoS) attacks 💀. Protect your stuff, bestie.

5. IANA Considerations 📋

per this document, which follows the guidelines of [5], IANA has registered a bunch of SDP attributes ✨.

5.1. Registration of New SDP Attributes 🎀

IANA registered a bunch of OMA BCAST-only attributes in the Session Description Protocol Parameters registry [1] 💖. The registration data follows RFC 4566 [1] 📝.

The registration templates below all point to the OMA-TS-BCAST_SvcCntProtection spec [2] 🦋.

5.1.1. Registration of the Attribute bcastversion:<major>.<minor> 🌸

• Contact: Anja Jerichow <anja.jerichow@nsn.com>
• Phone: +49 89 636-45868
• Attribute name: bcastversion
• Long-form attribute name: BCAST version
• Type of attribute: session level

This attribute doesn't depend on charset 💅.

• Purpose: this one tells you the OMA BCAST version, the bcastversion value written in the x.y format ✨.
• Specification of attribute values: this attribute has a mandatory value in the form <major>.<minor>, where <major> and <minor> are non-negative decimal numbers 🔢. The att-value field is of XML data type decimal. For the deets, check OMA-TS-BCAST_SvcCntProtection, Section 10.1.1 📖.

5.1.2. Registration of the Attribute stkmstream:<id of the stkm stream> 🦋

• Contact: Anja Jerichow <anja.jerichow@nsn.com>
• Phone: +49 89 636-45868
• Attribute name: stkmstream
• Long-form attribute name: Short Term Key Message stream identifier
• Type of attribute: session level or media level

okay so this attribute can live at session level, where it applies to all the media streams, or at media level, where it only applies to the specified media and overrides any session-level attributes it clashes with 🎬. It doesn't depend on charset either 💜.

• Purpose: the stkmstream attribute maps Short Term Key Message streams to the media streams in the SDP 🗺️. Each session or media stream can have multiple stkmstream attributes 🧩. The terminal compares this attribute's value with each STKM stream's identifier to figure out which one to listen to and process 👂. Just so you know, this attribute is optional, so it won't be there for unencrypted media streams 🙌.
• Specification of attribute values: this attribute has a mandatory value in the form <id of the stkm stream>, which is a unique non-zero integer that identifies a particular key stream 🔑. Numbers only have to be unique within a particular SDP session, so no global numbering is needed 🌍. The att-value field is of XML data type unsignedShort. For details, see OMA-TS-BCAST_SvcCntProtection, Section 10.1.3 📖.

That's the first half, bestie! 🌈✨

Intellectual Property 🎀

Okay so bestie, this last bit is all about the legal stuff 💅 The IETF is basically saying it does not take a position on whether any rights that might be claimed over the tech in this document are valid, or how far they reach, or whether a license for them is even available 🙈 It also hasn't gone hunting for any of those rights itself. If you want the rules for rights in RFC docs, check out BCP 78 and BCP 79 📚

Copies of IPR disclosures sent to the IETF Secretariat live in the IETF online IPR repository at http://www.ietf.org/ipr ✨ You can also find any assurances of licenses that have been promised, plus results from anyone who tried to get a general license or permission for implementers or users to use those proprietary rights 🫶

The IETF is inviting anyone who knows about it to speak up 📣 If you know about any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard, tell them at ietf-ipr@ietf.org 💖 Literally just send the info there and they'll take it from there 🦋