Pre review of 3GPP MIME type for RTP payload format
Hi, I would like to have a pre registration request review of the below propsed MIME type for a RTP payload format. This registration request is intended to use the updated registration procedure based on specification available from other standards body. The specification that the registration belongs to can be found in the following 3GPP contribution: http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_32/Docs/S4-040460.zip Which is the specification delta that included the RTP payload format defined within to the following specification: http://www.3gpp.org/ftp/Specs/latest/Rel-6/26_series/26234-600.zip The registration template for this looks like the following: ------------------------------------------------------------ MIME media type name: audio, video, text, application, image MIME subtype name: rtp.enc.aescm128 Required parameters: opt: The payload type number of the payload type contained in the encrypted payload. An integer value between 0-127. rate: The timestamp rate of this payload type, which shall be the same as that of the original payload type. This is an integer value between 1 and 2^32. ContentID: The OMA DRM content ID [75] used to identify the content when establishing a crypto context. The value is an RFC 2396 [60] URI, which shall be quoted using <">. RightsIssuerURL: The right issuer URL as defined by OMA DRM [75]. The value is an URI in accordance with RFC 2396 [60], which shall be quoted using <">. IVnonce: The value of this parameter is the nonce that forms the IV as specified by the crypto transform, encoded using Base 64 [69]. Optional parameters: SelectiveEncryption: Indicates if this stream is selectively encrypted. Allowed values are 0 (false) and 1 (true). If not present, selective encryption shall not be used. Please note that unless this indicator is integrity protected, it fulfils no purpose. Encoding considerations: This type is only defined for transfer via RTP (RFC 3550). Security considerations: See considerations raised in RTP RFC 3550 [9] and any applicable profile like RFC 3551 [10] or RFC 3711 [72]. Further see 3GPP TS 26.234, Release 6, Annex K for comments on security issues. The main issues that exists are: - This RTP payload format only confidentiality protects the RTP payload, thus header information is leaked, similarly to SRTP. - The use of stream ciphers as AES CM and no integrity protection allows an attacker to purposefully attack the content of the encrypted RTP payload by switching individual bits. - The usage of selective encryption without integrity protection allows for an attacker to perform any replacements of complete RTP payloads and packets it desires. - The payload format makes the receiver vulnerable to denial of service attacks that inserts RTP packets into the stream, that the receiver then interprets as being encrypted thus wasting computational resources. To prevent this attack, authentication needs to be used. Interoperability considerations: Published specification: 3GPP TS 26.234, Release 6. Open Mobile Alliance DRM Content Format V2.0 Applications which use this media type: Third Generation Partnership Project (3GPP) Packet-switched Streaming Service (PSS) clients and servers, which supports the Open Mobile Alliance's specification of Digital Rights Management version 2.0. Additional information: Magic number(s): N/A File extension(s): N/A Macintosh File Type Code(s): N/A Person & email address to contact for further information: magnus.westerlund@ericsson.com Intended usage: Common Author/Change controller: 3GPP TSG SA ---- End of template --- Hope for comments within a week. Otherwise any changes within 3GPP will be more difficult. Thanks Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
Hi, We have detected a copy and paste error of the complete Appendix K in the first of the below references, and it has been replaced with the following version. http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_32/Docs/S4-040481.zip Cheers Magnus Magnus Westerlund wrote:
Hi,
I would like to have a pre registration request review of the below propsed MIME type for a RTP payload format. This registration request is intended to use the updated registration procedure based on specification available from other standards body.
The specification that the registration belongs to can be found in the following 3GPP contribution:
http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_32/Docs/S4-040460.zip Which is the specification delta that included the RTP payload format defined within to the following specification:
http://www.3gpp.org/ftp/Specs/latest/Rel-6/26_series/26234-600.zip
The registration template for this looks like the following: ------------------------------------------------------------
MIME media type name: audio, video, text, application, image
MIME subtype name: rtp.enc.aescm128
Required parameters:
opt: The payload type number of the payload type contained in the encrypted payload. An integer value between 0-127.
rate: The timestamp rate of this payload type, which shall be the same as that of the original payload type. This is an integer value between 1 and 2^32.
ContentID: The OMA DRM content ID [75] used to identify the content when establishing a crypto context. The value is an RFC 2396 [60] URI, which shall be quoted using <">.
RightsIssuerURL: The right issuer URL as defined by OMA DRM [75]. The value is an URI in accordance with RFC 2396 [60], which shall be quoted using <">.
IVnonce: The value of this parameter is the nonce that forms the IV as specified by the crypto transform, encoded using Base 64 [69].
Optional parameters:
SelectiveEncryption: Indicates if this stream is selectively encrypted. Allowed values are 0 (false) and 1 (true). If not present, selective encryption shall not be used. Please note that unless this indicator is integrity protected, it fulfils no purpose.
Encoding considerations: This type is only defined for transfer via RTP (RFC 3550).
Security considerations:
See considerations raised in RTP RFC 3550 [9] and any applicable profile like RFC 3551 [10] or RFC 3711 [72]. Further see 3GPP TS 26.234, Release 6, Annex K for comments on security issues. The main issues that exists are:
- This RTP payload format only confidentiality protects the RTP payload, thus header information is leaked, similarly to SRTP.
- The use of stream ciphers as AES CM and no integrity protection allows an attacker to purposefully attack the content of the encrypted RTP payload by switching individual bits.
- The usage of selective encryption without integrity protection allows for an attacker to perform any replacements of complete RTP payloads and packets it desires.
- The payload format makes the receiver vulnerable to denial of service attacks that inserts RTP packets into the stream, that the receiver then interprets as being encrypted thus wasting computational resources. To prevent this attack, authentication needs to be used. Interoperability considerations:
Published specification: 3GPP TS 26.234, Release 6. Open Mobile Alliance DRM Content Format V2.0
Applications which use this media type: Third Generation Partnership Project (3GPP) Packet-switched Streaming Service (PSS) clients and servers, which supports the Open Mobile Alliance's specification of Digital Rights Management version 2.0.
Additional information:
Magic number(s): N/A File extension(s): N/A Macintosh File Type Code(s): N/A
Person & email address to contact for further information: magnus.westerlund@ericsson.com
Intended usage: Common
Author/Change controller:
3GPP TSG SA
---- End of template ---
Hope for comments within a week. Otherwise any changes within 3GPP will be more difficult.
Thanks
Magnus Westerlund
Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
-- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
Hi Larry, Thanks for taking a look. Larry Masinter wrote:
MIME media type name: audio, video, text, application, image
'application' alone makes more sense than registering any of the rest.
The problem is that the RTP payload format this defines is capable of wrapping any other payload format. As any other payload format theoretically has any of the media types, this format needs to handle all of the types. Currently there is MUST requirement to handle "audio" "video" and most likely "text" (depends somewhat on the result of the timed text discussion). "Application" and "Image" are kind of thrown in there for completeness. "model" "multipart" and "message" has so far not made any sense at all for RTP. It is both RTP and the signalling that puts requirement on the media type for a wrapper payload format to be the same as what it wraps. Earlier IETF examples of this are the type audio/parityfec that are also registered in video, text. So from my perspective, I don't see a problem with removing "Image" and "application" from the registration. The other three are needed. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
The problem is that the RTP payload format this defines is capable of wrapping any other payload format.
Yes, the 'application' is the 'application as a wrapping technology'.
As any other payload format theoretically has any of the media types, this format needs to handle all of the types.
This isn't inconsistent with using 'application'.
So from my perspective, I don't see a problem with removing "Image" and "application" from the registration. The other three are needed.
I think we differ on the meaning of the top level media type. You imagine that you need to use 'image' when the body is an image, and I don't think it is necessary at all. I think it is harmful to register multiple media types when one will do nicely. It isn't necessary that every MIME label be completely descriptive of the content, but just that the MIME label contain sufficient information to find the appropriate reciever. And, since you can't do anything with the content without decrypting it, and leaking information about the content is a concern, why not just use 'application' all the time? Like with ZIP files or PDF files. Larry
Hi, U have a question about the usage of "." in the subtype name. Is this usage okay, as it can/should be interpret as belonging to a tree named RTP? Magnus Westerlund wrote:
MIME media type name: audio, video, text, application, image
MIME subtype name: rtp.enc.aescm128
Please advice Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
U have a question about the usage of "." in the subtype name. Is this usage okay,
Not unless there's a specification for an rtp facet I'm unaware of.
as it can/should be interpret as belonging to a tree named RTP?
Exactly. The first dot in a media type name serves as a separator between the facet name and the remainder of the type name. At one point I specified an std. facet so that names could be registered in the standards tree with dots in them, but everyone else pretty much hated the notion so I dropped it. Ned
participants (3)
-
Larry Masinter -
Magnus Westerlund -
ned.freed＠mrochek.com